Кодирование пакета из трех полез. байт для передачи по UART

[MarkTok]

Добрый день!
Подскажите простой способ "кодирования" пакета из трех полезных байт (команда 8bit + значение 16bit) для передачи по UART и последующего гарантрированного получения этих трех байт на другом устройстве, без использования эха, то есть за одну передачу. Понимаю, полный пакет должен быть с достаточным избытком, соответсвенно с определением ошибок и возможностью их исправления.
Чтобы задать хоть какието границы "избытка" принимаем (прочитав спор двух спецов из соседней темы в этой ветке) вероятность ошибки передачи данных порядка 1/8...1/4 так как используется в достаточно зашумленной среде.
Готов на передачу этих трех байт тратить до 8..10 байт

Непонимаю с чего начинать и как. Кто то может подсказать на пальцах, кроме общих фраз CRC8 и полиномов

[КРАМ]

MarkTok писал(а):

с чего начинать и как.

На пальцах не выйдет.
Вам нужен код с исправлением ошибок. Такие кода обнаруживают ошибок больше, чем исправляют. Избыточность определит количество обнаруживаемых и количество исправляемых ошибок.
Из заявленного:
БЧХ-коды (код Рида-Соломона).
Код Хемминга.
Но требуется комментарий.
Дело в том, что коды с исправлением ошибок не помогают при тотально зашумленном канале. Эти коды работают при случайной и относительно редкой помехе. Они не способны вытащить сигнал из под шума. Теорема Шеннона-Хартли определяет пропускную способность канала с шумами.
Поэтому нужно не ошибки исправлять, а правильно модулировать сигнал в канале передачи, чтобы минимизировать потери информации, а лишь затем применять коды с исправлением ошибок.

[MarkTok]

Может я переборщил с вероятностью ошибок, но даже с 1/8 мне в голову приходит только посылка этих трех байт три раза подряд.
Получается при этой вероятности испортиться может только один, максимум два байта, и ещё более мало вероятно что именно один и тот же байт из трех повредится дважды. Но этот способ какойто уж жутко топорный

[КРАМ]

Лучше расскажите нам про канал связи. Откуда там помехи?

MarkTok писал(а):

мне в голову приходит только посылка этих трех байт три раза подряд.

Я же вам сообщил виды кодирования. Причем тут посылка подряд?

[MarkTok]

это сварочный аппарат, данные передаются от источника в механизм подачи проволоки. Что в источнике импульсные помехи, что в механизме подачи проволоки электромагнитные помехи от двигателя, все фонит. Пробовал делать с эхом, возможно допустил ошибку, но передатчик и приемник сильно занимались тем что обменивались "охами и ахами" вместо полезной работы. В результате сделал без эха, просто перестал принимать искаженные пакеты, но в результате стали проглатываться иногда пакеты, не часто, впринципе работает, поэтому и говорю что скорее всего переборщил с вероятностью ошибки в верхнем посту. Но меня это всё равно "муляет", пусть лучше пошлю данные с огромным избытком, но приемник должен принять все без исключения команды!

[КРАМ]

MarkTok писал(а):

это сварочный аппарат, данные передаются от источника в механизм подачи проволоки.

Ну и что в этом необычного? Как физически организован канал?

[MarkTok]

сейчас через CAN драйвера, ранее пробовал и через развязный оптопарами UART, скорость достаточно небольшая 38400

[КРАМ]

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

[MarkTok]

я не ракету запускаю на орбиту Луны ))) ничего подобного не видел ни у одного производителя сварочного оборудования, повидимому решают сугубо программным путем за счет кодирования ... собственно с чего и начал данную тему

[КРАМ]

MarkTok писал(а):

я не ракету запускаю

Какая еще нахрен ракета? Ровно одна микросхема. Причем совершенно стандартное решение.
Просто учите матчасть.
Никто не компенсирует безграмотную схемотехнику и конструкцию сложными алгоритмами, тем более, что это невозможно по определению.

[DX168B]

Вместо CAN драйвера возьмите драйвер, предназначенный для этого: MAX485 или иной, для шины RS-485. В CAN драйверах всякие зашиты от зависаний бывают и потому, если тайминги сигнала ему не понравятся, он отвалится от шины. Помимо этого, в CAN шине есть доминантные и рецессивные состояния (для разрешения коллизий на шине), в RS-485 таких состояний нет, потому драйвера 485 лучше держат уровень сигналов при воздействии на них помех. Соединять стороны нужно витой парой. На обоих концах должны стоять терминирующие резисторы сопротивлением, равным волновому сопротивлению витой пары. Это чтобы устранить эффекты отражения сигналов на линии. Не нужно забывать и о защитах линии и драйверов от сильных всплесков, иначе драйвера умрут.
КРАМ прав абсолютно. Сначала нужно по максимуму очистить среду от помех, потом уже заниматься защитой данных.

[MarkTok]

я так и знал, этот ситуация, когда лучше было бы не говорить для чего нужно кодирование, чтобы не было идей "все исправить и поделить между всеми поровну" ....
DX168B все что Вы предложили уже сделано, отработано и работает .... НО я знаю что можно сделать лучше, ведь сам и прошел весь этот предыдущий путь, знаю всю систему досканально и где узкие места.
Поэтому и пришел сюда чтобы спросить о том чего не знаю, может кто подскажет

[КРАМ]

Это прикольно...
Приходит персонаж с вопросом. Ему на него отвечают люди, которые этим вопросом занимаются профессионально. А он начинает их учить жить.
Любезный, зачем вас учить? Вас учить - только портить...

[DX168B]

Бывает... К сожалению часто бывает.

Тогда пусть берет код Рида-Соломона или код Хеммига и реализует его.
Только если канал жестко засран помехами, то ничто уже не поможет.
Это как картину Пикассо замазать толстым слоем гомна, а потом пытаться разглядеть ее из под слоя гомна с помощью рентгенаппарата.

[MarkTok]

ну я же в третьем же сообщении признался что "В результате сделал без эха, просто перестал принимать искаженные пакеты, но в результате стали проглатываться иногда пакеты, не часто, впринципе работает" ... ну немного приукрасил силу проблемы, чтобы поняли что это важно и нужно, а ведь реально все работает уже более семи лет, всех то устраивает .... НО меня не устраивает, так как знаю что не идеально .... А в общем КРАМ спасибо, код Хемминга скорее всего самое лучше подойдет ... думал что как профессионалы подскажут что лучше подойдет, у какого метода преимущества и недостатки, но похоже все самому все самому

[roman.com]

люди давно уже придумали изернет)) с симметричным входом и выходом... гальванической развязкой... и заземлением...
причём заземление не только экрана но и сигнальных проводов...

лучше только оптика)) но это уже другая тема...

[jcxz]

Лучше RS-485 или RS-422 с драйверами "токовая петля" через витые пары.