Форум РадиоКот

доброго всем вечера!

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

на мой взгляд - на нечетность

если можно - примеры и ссылки, но без трехэтажной математики: она меня доводит до трехэтажного мата

СПАСИБО!

Тут в самом вопросе смешаны мухи и котлеты, которые, как советовавл ВВП, нужно держать отдельно. Четность или нечетность используются для контроля приема/передачи одного байта и производится аппаратно. CRC считается программно и позволяет проконтролировать правильность приема всего сообщения ( я не рассматриваю шины вроде CAN, с которй не знаком и которая тоже вроде бы это делает аппаратно) . Я в своих прогах отключаю контроль четности и считаю CRC16, которая теоретически пропускает необнаруженную ошибку с вероятностью 1/65536 .
Тут еще маячит другой вопрос. Обнаружив ошибку, ведущий перезапрашивает у ведомого повтор, на это уходит дополнительное время. Теоретически можно доказать, что при относительно большом уровне искажений и длинных сообщениях вероятность удачного приема стремится к нулю. В особо ответственных случаях я упаковывал информацию в короткие блоки, которые в пакет укладывал в 3 экземплярах. На приемном конце проверялся каждый, и если в двух из 3 CRC оказывалась не битой, прием считался успешным.
В официальных протоколах я такого не встречал, и за "самодеятельность" получал "шпинделей" от шефа, на что ему резонно отвечал : "А вам шашечки нужны или ехать?" Надежная работа системы, по-моему, важнее тупого следования стандарту.

Оба способа одинаково ненадежны.

я про CRC ничего не писал

я планирую бит четности одного байта в протоколе нижнего уровня, а поверх еще и CRC на три байта, CRC - четвертый

я понимаю, что чем длинее посылка, тем выше вероятность повреждения
И про уменьшение скорости обмена из-за запросов и повтором, но тут надежность прежде всего!

aleksandr-zh писал(а):я понимаю, что чем длинее посылка, тем выше вероятность повреждения

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

хм, я не уверено, но это получится уже не контроль, а восстановление поврежденных данных... Да и математика для МК получится несколько излишняя

Думаю, что сделать как планировал:
- нижний уровень, передача по 4 бита и бит четности
- верхний уровень, три байта данных + байт с контрольной суммой

думаю, что будет достаточно, чтобы "не включилось" при поврежденных данных

а делать повторный запрос и дольше, и вероятность повреждения значительно увеличивается

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

aleksandr-zh писал(а):хм, я не уверено, но это получится уже не контроль, а восстановление поврежденных данных... Да и математика для МК получится несколько излишняя

Верно. Например, если передавать 4 бита данных + 3 контрольных, то можно гарантированно исправить одиночную ошибку, обнаружить двойную и с высокой степенью вероятности обнаружить ошибку большей кратности.

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

Кстати, передача будет средствами UART или собственным специальным интерфейсом?

Goldsmith писал(а): Насчет математики - она очень простая и ненапряжная. Контроль по Хэммингу даже аппаратно делается без больших затрат, его часто реализуют на оперативной памяти для ответственных приложений.

я уже почитал в Сети о данных кодах. Надо подумать: стоит ли игра свечь

Goldsmith писал(а): Кстати, передача будет средствами UART или собственным специальным интерфейсом?

нет, всё свое: передача по сети 220 Вольт, в паузах - при переходе тока через ноль

Достиг скорости (транспортной) в 1900 бит: Старт-бит + 8 данных+Четности + 8 данных+Четности

Думаю, изменить на:
Старт + 4 данных+Четность +4 данных+Четность + 2НомерПакета+Четность
Транспортная -ниже, данных меньше передам, но надежность - выше

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

я пока в процессе разработки, но планирую два уровня
Первый - транспортный, с минимально достаточной проверкой целостности данных (тот же бит четности или нечетности)
Второй- информационный, там тоже будет CRC на 2-4 байта (планирую: два под адрес и один - под данные)

имхо, ничего, кроме разрастания кода и снижения скорости вы не добъетесь своими уровнями... если вы опираетесь на "декларируемое" везде "небольшое количество помех в сети вблизи перехода через 0", то наоборот было бы логичнее стараться передать как можно больше битов в этот промежуток и повторить весь пакет спустя 10 мс, если он с ошибками, чем медленно и печально по несколько лбит передавать с контролем ошибок...

на самом деле помех около нуля мало? по-моему, это немного не так... без привязки к нулю разве плохо доставляются данные?

aleksandr-zh писал(а):я про CRC ничего не писал

Наверное, у меня галюцинации. Иду пить валерьянку.

Всех благодарю за советы
буду думать

тему можно закрыть - попер флуд