Проблема как раз в другом, и заключается в вопросе - чего вы собственно хотите?
Если у вас есть требования предъявляемые заказчиком - давайте обсудим.
Ели требований нет - тогда можно взять из ГОСТа любые понравившиеся.
Отсюда проблемы в трактовке и анализе уровня помехозащищенности.
На рис. приведены относительные уровни - для того чтобы показать лишь принцип.
Выводов может быть несколько:
1. Нет смысла дробить защиту на заголовок и тело в предложеном виде
2. Если уровня защиты хватит - можно остановиться лишь на общем CRC16
3. Для случая "обычного канала связи" где p=10е-4, P=7.4е-8 (для 2304 бит)
и вы попадаете в 3-ю колонку изделий по ГОСТ 26.205-88 , табл.3
4. Если уровня защиты не хватит - это предмет для обсуждения, но тогда
укажите подробнее о задаче.
5. Если у вас есть желание привести цифры к интенсивностям отказов (1/час)
и т.д. - тема отдельного разговора
6. Здесь все то что не вошло в предыдущие пять пунктов ...

PS. Прошу прощения - не увидел что речь идет именно о 2048 байтах данных,
это уж слишком большой блок для CRC16 по определению....
Вам нужно обратиться к стандарту Ethernet IEEE 802.3 (CRC32) в любом случае.

Спасибо за ответы, я для себя в общем-то всё прояснил. Заголовок будем продолжать закрывать CRC8, а а для поля данных изменим CRC16 на CRC32. Тем более, что лишние 2 байта - это ничто по сравнению с 2048 байт, так что не жалко.

У нас бывает, что заголовки передаются без поля данных. Тогда для унификации лучше пусть CRC8 будет в любом случае.

А всё же, по моему списку, не могли бы Вы разъяснить ответы на вопросы 1, 3, 5?

Как ни банально звучит, в чистом виде ответов ни в инете ни в книгах нет.
Теорий и формул много, но на практике, с приемлемой точностью можно
использовать простую комбинаторику. Здесь принимается модель
последовательного канала связи с простейшим потоком ошибок (пуассонов).
Для работы например с ПЛИС, следует использовать другую модель,
где равновероятны любые сочетания и т.д.

После этого CRC тестируется на помехозащищенность заданного блока
данных используя как метод прямого перебора, так и Монте-Карло.
Корректируются теоретические модели (например разные полиномы
CRC8 показывают помехозащищенность отличающуюся на порядки).

Относительно вероятностей - нужно понимать опять-же что вам нужно.
Если задача привести ваш канал связи к уровню стандартов в системах
с повышенной безопасностью (интенсивность 10е-15 1/час), то это одно,
а вот просто сказать - что все ок, это другое. В последнем случае не
заморачиваясь, принимайте CRC32 на базе IEEE 802.3 - это общепринято,
правда для блоков до 1500 байт.

Остальные вопросы заданы в общем виде и слишком объемны для рамок форума.
Чтобы понять какой вам нужен уровень защищенности ответьте на вопрос:
достоточна ли защита блока данных от всех ошибок нечетных кратностей (1х, 3х, 5х ...),
защита от всех ошибок 2х кратности и защита от 129 ошибок из 130 кратности 4х, 6х ... ?
Это уровень обеспечивается CRC8. Под ошибками понимаем инверсию битов в блоке данных.
Пока не понятны ваши критерии оценки, как только они определятся, можно решить
задачу о требуемом протоколе канала связи.

Ладно, сдаюсь, применяем CRC32, и успокаиваемся. Особенно учитывая, что ещё будет снаружи 8B/10B. Остальные вопросы снимаю.

8B/10B больше актуален для оптики в качестве выравнивателя потока 0/1 и имеет слабую помехозащищенность,
в среднем улучшение в 4 раза. Если особых требований нет, то конечно CRC32 + несложная доп. защита наиболее
ответственных блоков данных (поле адреса, поле управления и т.д.) с помощью CRC8.

почитайте сообщение пользователя i-mir, возможно поможет
http://electronix.ru/forum/index.php?showt...%F1%F3%EC%EC%E0