Проверка возможностей обнаружения ошибок полиномов CRC

Question

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

Я знаю, что существуют различные возможности обнаружения ошибок, которые могут (или не могут) применяться к произвольному полиномом:

1. Обнаружение одной битовой ошибки: Все ЗПК могут сделать это, так как это требует только ширина CRC> = 1.

2. Обнаружение ошибок пакета: Все CRC могут обнаруживать ошибки пакетов до размера, равного их ширине.

3. Обнаружение нечетных чисел ошибок в битах: CRC с полиномами с четным числом членов (что означает четное число 1-битов в полном двоичном полиноме).

4. Обнаружение случайных ошибок в битах (в зависимости от размера кадра): У меня есть готовый к использованию алгоритм C, который позволяет рассчитывать максимальный размер кадра для данного HD и poylnomial. Я не понял его полностью, но он работает.

Предположим, что 16-кратный многочлен CRC x¹⁶ + x¹² + x⁵ + 1 = 0x11021. Этот полином может:

• обнаружение всех ошибок одного бита (независимый размер данных).
• обнаруживает все пакетные ошибки шириной до 16 бит (независимый размер данных).
• обнаруживает все нечетные числа битовых ошибок (так как имеет 4 полиномиальных члена, независимый размер данных).
• обнаруживает 3-разрядные ошибки (HD4) до 32571 бит.

Правильно ли это?

Есть ли дополнительные возможности обнаружения ошибок CRC? Если да, то как я могу проверить (без глубоких математических знаний), если их поддерживает полином?

Answer 1

В этом paper by Koopman and Chakravarty рассматриваются несколько показателей эффективности CRC, описывающие меры и результаты для многих полиномов. Короче говоря, определение «хорошего» многочлена зависит от длины сообщения, к которому оно применяется, которое зависит от приложения. Основными мерами являются расстояние Хэмминга, которое представляет собой минимальное количество бит в сообщении, которое вам нужно будет изменить, чтобы вернуться к одному и тому же CRC, и производительность с заданной скоростью с низким уровнем ошибок.