[ilkz 0]

Последовательный протокол передачи данных (все это сделано на ПЛИСе).

Простейший пакет вида [MASK][DATA][CRC] (младший бит справа).

Маска - это сигнатура, по которой синхрится приемник (не участвует в подсчете контрольной суммы).

Данные - это данные )))

CRC - это контрольная сумма данных.

 

Непонятно мне вот что - как рассчитать, какой должна быть длина контрольной суммы для соответствующей длины данных? Много чего читал, но как-то явно про это нигде не говорится.

Т.е., например, какой длины должна быть CRC для данных разрядностью 32 бита? А 64 бита? А 80 бит?

Сейчас использую 4-битную CRC при длине данных порядка 70 бит. Глубокое ощущение что этого мало, но не могу разобраться как посчитать нужную разрадность CRC.

 

И еще - стоит ли включать в подсчет CRC маску пакета?

Если да, то становится не очень понятно как тогда налаживать синхронизацию, ведь CRC придется считать вообще постоянно и после захвата маски ее нужно бы сбросить, а уже нельзя, т.к. маска участвует в вычислении CRC...

[demiurg_spb 0]

ИМХО вопрос немного не корректен.

Всё определяется желаемой вероятностью обнаружения ошибок и, уже как следствие, зависит от длины посылки для которой считается CRC.

[ilkz 0]

Ну мне не нужно определять тип ошибки (сбойнувшие биты и т.п.) - достаточно просто отбраковывать плохие пакеты по несовпадению контрольной суммы.

По-моему, очевидно что вероятность обнаружения ошибки нужно свести к минимум. Я понимаю, что, например, CRC-32 для 70 бит даст почти нулевую вероятность, а CRC-4 для тех же 70 бит будет гораздо менее "помехоустойчива", но как посчитать разумный оптимум? Так что вопрос пока остается открытым...

[xemul 0]

стоит ли включать в подсчет CRC маску пакета?

Если да, то становится не очень понятно как тогда налаживать синхронизацию, ведь CRC придется считать вообще постоянно и после захвата маски ее нужно бы сбросить, а уже нельзя, т.к. маска участвует в вычислении CRC...

CRC(const) == const

По достаточной разрядности CRC - для 70 бит 7-битовая CRC естесно реализует все базовые свойства CRC по обнаружению ошибок. В конфе обсуждалось.

[ilkz 0]

Ув. xemul, почему именно 7 бит? Почему не 6 и не 8? А если данные будут 72 бита? А если 67 бит? А если 115 бит? Как вы это посчитали?

 

Как же все-таки можно посчитать оптимальную разрядность контрольной суммы для заданной разрядности данных?

 

Поясню к чему я это затеял:

1. Просто хочется понять суть.

2. Хочу доработать трансивер, чтобы он на этапе компиляции сам рассчитывал оптимальную длину CRC и синтезировалась соответствующая логика (ну это уже чисто плисерские замуты).

[Ruslan1 17]

Ну мне не нужно определять тип ошибки (сбойнувшие биты и т.п.) - достаточно просто отбраковывать плохие пакеты по несовпадению контрольной суммы.

По-моему, очевидно что вероятность обнаружения ошибки нужно свести к минимум. Я понимаю, что, например, CRC-32 для 70 бит даст почти нулевую вероятность, а CRC-4 для тех же 70 бит будет гораздо менее "помехоустойчива", но как посчитать разумный оптимум? Так что вопрос пока остается открытым...

Опттимум у каждого свой. Одним кофеваркой управлять, другим многотонный двигатель мониторить. Если у Вас задана (В ТЗ например) вероятность обнаружения ошибки (или, что то же самое, требуемая вероятность принятия битого пакета за небитый), то исходя из этого можно четко сказать какой длины CRC нужно. Если на глазок пальцем направление ветра определяете (ТЗ молчит)- то берите CRC32 если ресурса хватает или CRC16 если не хватает. Применение более коротких CRC нужно уже обосновывать.

 

По личному опыту- CRC16 совершенно хватает в промышленных масштабах (в составе MODBUS-RTU), пакеты от 5 до 256 байт. Дополнительно проверяется конечно и адрес и валидность информации представленной в служебных полях пакета, в-общем все то что уже содержится в модбасовском пакета.

 

Для ваших коротких пакетов CRC32 все-таки еще тот оверхед. Берите CRC16. А может быть и CRC8, но тут уже считать нужно, хватит вам CRC8 или нет. И еще проверьте на передачу вырожденного пакета выбранный вами полином- скажем, чтобы пакет из одних FF или 00 не давал CRC равное тому же FF или 00, иначе такой мусорный пакет будет воспринят как нормальный.

 

Это думаю вы уже видели и по ссылкам в конце ходили.

[ilkz 0]

Ruslan, большое спасибо за подробный ответ! То, что нужно. Википедию и ссылки с нее читал.

 

В ТЗ требования к CRC никак не прописаны, более того, протоколы также никак не определены, так что тут я волен делать что душе угодно. Есть только скорость передачи данных по каналу.

 

Насчет вырожденных пакетов - передаются значения с АЦП, так что там может сидеть что угодно - как все нули, так все и единицы, поэтому в моем случае это, думаю, неактуально...

[Ruslan1 17]

Насчет вырожденных пакетов - передаются значения с АЦП, так что там может сидеть что угодно - как все нули, так все и единицы, поэтому в моем случае это, думаю, неактуально...

Очень актуально! И не зависит от природы данных, а зависит только от природы линии связи. Оборвался провод- пошли все FF, закоротился на землю- пошли все 0 (если данные и тактирование приемника по разным проводам).

полином CRC должен быть такой, чтобы пакет вида 0,0,0,0,0 не был воспринят приемником как правильный пакет с переданным в конце CRC=0. Обычно это достигается тем, что начальное значение регистра CRC до рассчета не 0, а что-то иное.

То есть если пакет номальный, то вы примете пакет "0,0,0,ненулеваяCRC", а если битый, то "0,0,0,0" и сможете отличить битый от небитого.

[i-mir 0]

Ув. xemul, почему именно 7 бит? Почему не 6 и не 8? А если данные будут 72 бита? А если 67 бит? А если 115 бит? Как вы это посчитали?

Как же все-таки можно посчитать оптимальную разрядность контрольной суммы для заданной разрядности данных?

Такие вопросы задаются очень часто. Приведу один из возможных путей расчета, если в ТЗ/ТУ явно требований к CRC нет.

За отправную точку берется ГОСТ 26.205-88 Комплексы и устройства телемеханики. Общие ТУ. п. 2.11.

Вероятность искажения одного бита данных 10-4 (для критических систем 10-3). Далее простая комбинаторика для

обеспечения вероятности опасной трансформации команды на уровне 1, 2 или 3. Например для бытовых нужд 10-7.

Т.е. вероятность того, что мы примем ложную команду и она воспримется системой как корректная.

 

Теперь рассматриваем коды (привожу укрупненно только как пример):

1. Код Хемминга (7,4) пакет 7 бит, 3 проверочных бита. - Ловит все 1-х и 2-х ошибки.

2. CRC-4 (8,4) пакет 8 бит, 4 проверочных бита. - Ловит все 1-х и 2-х ошибки.

3. Инверсный код (8,4) пакет 8 бит, 4 проверочных бита. - Ловит все 1-х и 2-х и 3-х ошибки.

4. Для сравнения, простое удвоение 4-х битной посылки: - Ловит только все 1-х ошибки.

 

Далее считаем вероятность появления ошибок кратности t, для информационного сообщения длиной n:

Р=p^t*(1-p)^(n-t), где р=10-4, а вместо n - длина пакета.

 

Вот и все. Выбираете наиболее подходящий код для вашей посылки, чтобы обеспечить 10-7.

Аналогично расчеты для CRC-8 или CRC-16 ...

Расчет можно показать на живом примере.