Вас кто-то ввёл в заблуждение что CRC не выявляет ошибки более 3 бит.



Поняли. На половину хотя бы.
Просто "пугает" неизвестность. Правильных цифр здесь пока не знает никто.
Результат может быть приемлемым. А может быть и нет.

В данном случае передавать адрес без всяких ЦРЦ будет намного надёжнее, чем выковыривать его косвенно при помощи дохленького ЦРЦ7.

Возвращаемся к истокам

Я исходил из поставленной задачи.
CRC7 не выявит больше 3 ошибочных бит на всё сообщение, это можете не сомневаться.
Вообще, за это время можно уже модельку накидать.
И увидеть всё наглядно.

Воды долили? Принципиально ничего не изменилось.


Насколько? Без цифр пустой разговор.

Не знаю какой у вас полином, но если вы тоже ещё не знаете - возьмите полином из (63,56) БЧХ кода с корнями 0, 1, то есть примитивный двоичный полином степени 6, умноженный на полином x+1. У него минимальное расстояние будет равно 4. Вероятность пропуска ошибок при белом шуме с вероятностью ошибки одного бита p будет порядка (21*p)^4 для 128 устройств на шине, или порядка (17*p)^4 для одного устройства на шине. Вероятность пропуска полностью случайного блока будет N/16384, где N - число устройств на шине.



Для полного диапазона адресов в 128 устройств абсолютно бессмыссленное занятие. Вероятность неправильного приема не отличается от просто передачи 7 бит адреса вместо поля CRC.

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


А более точно можно посчитать только с учетом реального распределения кодовых слов, но результат кардинально хуже нормального дополнительного СRС поля и передаваемого адреса на белом шуме, и существенно хуже для полностью случайных блоков.

Но можно кое-что оценить исходя из 7 бит на адрес плюс проверку. Для двух устройств у нас остается один бит адреса и 6 бит проверочных, что позволяет использовать код Хэмминга с минимальным расстоянием 3 и еще довольно низкой вероятностью необнаружения одиночных ошибок. Для 2 бит адреса остается 5 проверочных бит, то есть двоичный циклический код неизбежно будет пропускать некоторые двойные ошибки. Однако можно получить линейный код с расстоянием 2 из кода Хэмминга длиной 63, выкинув, в том числе, 1 проверочный бит. Уже для 3 бит адреса такой метод гарантированно оставляет расстояние лишь 1, что бессмыссленно по сравнению с просто контролем четности.



Спорим, выявит 6 указанных мною ошибочных бит?

Кто сказал что диапазон адресов = 128? Паша вроде байт хотел сэкономить.

Но вообще, прошу заметить, что идея не моя Мне как и ТС любопытен был ответ в количественном виде.

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

Передаем 4 байта. Один бит исказился. Сообщение ошибочное. 256 устройств высчитали CRC, добавив свой адрес. У кого-то CRC совпадет.
(В-принципе, CRC не обязательно у кого-то должен совпасть, но очень вероятно. Для этого, собственно, CRC и создан. Чтобы для любых даже слабо отличающихся кодов создать сильно отличающийся результат. Поэтому, представив, что результат вычисления CRC будет иметь равномерную плотность вероятности, получить можно любой код.)

Засчёт более короткого сообщения (по сравнению с махlen=127)? Возможно.
Под рукой таблиц нет, искать некогда.
Поверю на слово.


Лучше бы сказал, для чего он это хотел.

Странно, ведь задача не поставлена - а вы хотите в цифрах ответ.
Из-за этого куча шума на ветке, хотя вопрос далеко не сложный.
Мало того, можно и абсолютный уровень по безопасности вывести
для наиболее тяжелого условия работы канала связи (например
включаем рядом дрель, усиливаем и XOR в канал).
Все эти модели есть и прекрасно работают. Но для получения
ответа дайте корректное условие в цифрах.

За счет того, что любой систематический циклический код обнаруживает бурсты ошибок длиной, не превышающей его количества проверочных бит.

Для того и хотел, имхо. Укоротить длину сообщения.

Если нетрудно, ткните носом, где это написано. Полазил-полазил по википедии - не нашёл.
Меня заинтересовал вопрос зависимости оптимально применимой длины поля CRC от длины пакета. Т.е. для каких длин пакетов применяется CRC8, для каких CRC16 и т.д. Хотя бы "среднепотолочные" цифры, для распространённого случая.
Если кто знает, пошлите, пожалуйста, по ссылке )))

В свое время писал об этом.
http://electronix.ru/forum/index.php?s=&am...st&p=898290

ПС. Википедия не дает и не может давать глубоких ответов - только стартовую точку ...

Сообщение отредактировал i-mir - Apr 26 2011, 05:47

Есть там.
Надо развернуть "плюсики" с приведёнными примерами.
Ну а если хотите серьёзно разобраться - это надо литературу читать.
Я в своё время диплом писал по корректирующим кодам, больше всего пользы извлёк из 500-страничной книжки с красной обложкой, автор какой-то японец.
То ли Токура, то ли что-то в этом роде...
Не эта ли?
Блин, а я в читальном зале часами сидел, домой не выдавали такие раритеты...

Вот ещё...

Ну и далее в том же духе.

До кучи

Проблема в том, что приведенные примеры не дадут вам "динамики" работы СRC,
для этого пишется свой код и проводятся испытания, порой длительные.



Если будет хоть немного конкретики - можно ответить на вопрос, предложить хороший полином,
проанализировать помехоустойчиовсть и т.д. Что передается, в каком объеме, в каких
условиях, требования к надежности/безопасности и т.д. ?