[syoma 1]

Quote

А не проще уж тогда дублировать пакет? Все равно у вас почти 64 бита уже получается.

Вы ж смотрите, какие у меня требования.

Во первых канал передачи требует DC- балансировку. Т.е. это уже +2 бита к каждым 8-и, если использовать 8B10B кодирование. То есть получаем из 32-х бит уже 40 бит. Вы хотите дублировать пакет? Тогда это 80 бит.

Во вторых в то время, когда ничего не передается, на линии передается idle последовательность, то есть нужно еще распознавать начало пакета - т.е. нужен Start of Frame - это еще 10 бит. 

 

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

[ViKo 1]

Нужно знать вероятность возникновения ошибок - одиночных, двойных, и т.д.

Нужно посчитать вероятность обнаружения таких ошибок. 

Ни одна контрольная сумма не соответствует некой уникальной последовательности битов. Есть много других последовательностей с той же суммой.

[syoma 1]

1 hour ago, ViKo said:

Нужно знать вероятность возникновения ошибок - одиночных, двойных, и т.д.

Допустим это вероятность известна отдельно для каждого типа ошибок. Она же будет перемножаться с вероятностью обнаружения этих ошибок?

 

1 hour ago, ViKo said:

Нужно посчитать вероятность обнаружения таких ошибок. 

Вот и вопрос - как ее посчитать, если известен алгоритм подсчета контрольной суммы?

 

1 hour ago, ViKo said:

Ни одна контрольная сумма не соответствует некой уникальной последовательности битов. Есть много других последовательностей с той же суммой.

Это понятно.

[ViKo 1]

Да, будет перемножаться.
Кое-что по теме есть в книге Б. Скляр, Цифровая связь. 

[vadon 0]

Если очень важна достоверность сообщения и есть достаточно вычислительных ресурсов посмотрите в сторону хеш функций к примеру MD5

[blackfin 14]

2 hours ago, vadon said:

Если очень важна достоверность сообщения и есть достаточно вычислительных ресурсов посмотрите в сторону хеш функций к примеру MD5

Вы цифру назовите!!!

Число, величину, значение, вероятность...

Как вам написать, чтобы было понятно? Вы читать умеете? :)

 

Вот тут:

On 7/30/2020 at 3:02 PM, syoma said:

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

[vadon 0]

Quote

Вы цирфру назовите!!!

Число, величину, значение, вероятность...

на такой длине сообщения MD5 даст 100% достоверность сообщения. 

[blackfin 14]

4 minutes ago, vadon said:

на такой длине сообщения MD5 даст 100% достоверность сообщения. 

Вы как тот студент из сельхоза:

Quote

Студент сельхоза выучил на экзамен только строение блохи.

Ну тянет он билет — там строение собаки. Вот он и начинает:
— Собака — животное на четырех лапах, покрыто шерстью. А в шерсти водятся блохи…И дальше про блох все что знает.
Препод:
— Ладно, ладно. Расскажите нам о строении коровы.
— Ну, корова, это животное на четырех ногах, питается травой, покрыто шерстью. А вот в шерсти водятся блохи, ну и дальше по тексту.
— Ладно, хватит. Расскажите нам тогда про строение рыбы.
— Рыба живет в воде, шерсти у нее конечно нет, но вот если бы она у нее была, то в ней обязательно водились бы блохи…

[syoma 1]

1 hour ago, vadon said:

на такой длине сообщения MD5 даст 100% достоверность сообщения. 

При длине хэша в 128 бит? Это хорошо, конечно

[vadon 0]

2 hours ago, syoma said:

При длине хэша в 128 бит? Это хорошо, конечно

Ну зато 100%, ничего считать не надо, можно еще и анекдоты про собак почитать 
А если по теме это к примеру я дал направление в какую сторону посмотреть хеш функций много и на разные случаи.

Фишка хеш функции что очень тяжело найти на определенной длине одинаковый хеш, это называется колизией (это и отлличает хеш от CRC если расматривать в контексте проверки целостности). В crc найти колизии очень просто. Нахождение колизий в хеш функциях занимается очень много народа за очень большие деньги. 

 

[AlexandrY 2]

25 minutes ago, vadon said:

Фишка хеш функции что очень тяжело найти на определенной длине одинаковый хеш, это называется колизией (это и отлличает хеш от CRC если расматривать в контексте проверки целостности). В crc найти колизии очень просто. Нахождение колизий в хеш функциях занимается очень много народа за очень большие деньги. 

 

CRC и есть хэш.  А вы наверно путаете с криптографическими хэшами типа SHA
Не поленитесь почитать википедию - https://en.wikipedia.org/wiki/List_of_hash_functions

Криптографические заточены на максимальную вариабельность от единственного различия,
а коммуникационные типа CRC  на гарантированную вариабельность от n-битного различия.

Так что советовать криптографические хэши здесь довольно глупо.

[Doka 1]

On 7/30/2020 at 11:24 AM, arhiv6 said:

В этой статье сравнивали стойкость различных видов контрольных сумм. Т

в статье автор классифицирует стойкость CRC в зависимости от битности, что не совсем корректно,

вот тут постарался раскрыть почему это не так: http://idoka.ru/who-is-better-than-crc32/

 

 

On 7/30/2020 at 10:40 AM, syoma said:

В общем упрощаю задачу:

Надо передать четыре 8-и битных числа по последовательному каналу в виде одного пакета.

тут надо бы знать статистические свойства канала - начиная от вероятности появляения ошибки при заданной энергетике до распределения ошибок - для этого кстати, совместно с  с помехозащищенным кодированием применяют перемежение данных (уже после наложения кодирования), вероятно , что в вашем случае (передача 32бит на адекватной скорости) перемежать уже "нечего", и более првильный подход - повторение передачи после таймаута + номинальная проверка целостности с CRC.

 

посмотрите что-то типа СС1101 TI - там в даташите хорошо расписано как сделана встроенная защита при передаче "коротких" пакетов

[Doka 1]

On 8/3/2020 at 12:25 PM, vadon said:

на такой длине сообщения MD5 даст 100% достоверность сообщения. 

про коллизии всё верно, но в данном кейсе хеши использовать небюджетно и расточительно:

получаем хеш из 32бит (перед этим "добив" нулями и длиной сообщения до 512бит) длиною 128 бит:

и получим что при равномерном распределении одиночных ошибок 80% сообщений с неповреждённым 32битным "телом" будут отбрасываться как повреждённые из-за md5.

 

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