помехо защищенное кодирование, кто может уже делал Опции

[asen]

Вот есть задача передачи команд по RS485 данные при передаче теряются решил закодировать
передаются команды длинной 64 бита
без применения помехозащищенного кодирования теряется порядко 5-10% покетов
т.е 5-10 % приходет с ошибкой до 4 бит на пакет
вот и вопрос наверника ктото такую проблему реша ведь оно не нова может есть гденибуть библиотеки или куски исходников с алгоритмами помехозащищеного кодирования типа кодов БЧХ или Рида Соломона.
Все реализуется на LPC2294 в IAR 4.30
Зарание благодарен!!!

[aaarrr]

А причина возникновения ошибок установлена? ИМХО, не с той
стороны пытаетесь решить проблему...

[Alex03]

ИМХО в первую очередь надо бороться с самими ошибками, точнее источником их возникновения.
Перерабатывать линии связи, и т.д. (уити на CAN например)
кодирование с избыточностью и восстановление данных более важно для рилтаймовых систем, где как в законе мясорубки ("фарш невозможно прокрутить назад") повторная передача уже не имеет смысла. Или для систем где действительно очень не ненадёжен канал связи (КЛА и т.п.), к коим на мой взгляд RS-485 не относится.
Ибо где есть 5-10% ошибок при незначительном измененении окружающей обстановки может случиться 100% ошибок.
Всё это сугубо ИМХО.

Ну а по существу я ничего не скажу!
Во первых надо понять какая избыточность данных для Вас приемлима.
Во вторых какую вероятность ошибки после восстановления данных желаете, и т.д.
Насколько Вам важна информация об наличии ошибке. (Тот же простейший Хэмминг восстанавливает одну ошибку, но легко пропускает 2 и более)
Ну и надо учесть специфику RS-485, а именно его асинхронность. Например при ошибке распознования приёмником старт-бита (а вероятность такого события насколько я понимаю далеко не нулевая) в одном случае портиться только соответствующий байт, в другом (например если байт 0xFF) этот байт пропускается и делее весь пакет со сдвигом в байт (а если Вы ждёте конкретное число байт в пакете - не дождётесь), в третьем случае нулевой стоп-бит и соответственно какая-то (а какая?) обработка ошибки приёма.

[asen]

причина как раз в том и заключается что линия прокладывается в близи мощных линий электра передач по которым текут ударные токи до нескольких кило ампер
потеря информации вызвана как раз наведением помех во время срабатывания коммутирующих устройств и вносит как я уже сказал инверсию до 2-3 бит запас по скорости огромен в данный момент скорость устраиваемая меня 9600 кбит/с испытания проводились на скорости 1 Мбит/с так что кодирование как раз возможно и желательно

теперь что требуется получить вероятность ошибки не более 10 в -6, 10 в -7,

скорость не менее 9600кбит/с

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

эффектов с потерей пакета всего или ложным запуском не удалось засечь

не уж-то не кто не пробовал исправить подобные ситуации в своей практике?

[aaarrr]

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

[asen]

при инвертировании нескольких бит может случится так что получится другая команда и она будет выполнена и подтверждение тоже не поможет так что в этом случаи придется повышать качество связи
расстояние по времени между байтами пакета больше чем время передачи байта пакета так что при ошибке синхронизации будет потерян только первый байтно такое событие еще менее вероятно так как по итогам проведенных испытаний небело зарегистрировано ошибки более 3 бит

я передали почти 4 гигабайта информации

[Alex03]

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

[vladec]

Мне представляется, самым тупым по реализации и в тоже время достаточно действенным при таком запасе по скорости, будет мажоритарное троирование (или даже пятикратное повторение) данных в потоке, с формированием контрольной суммы (8 или 16 бит) на исходный (однократный) поток.

[vladec]

Да еще мажорируемые данные в потоке лучше разнести, что бы одна помеха не портила несколько мажорируемых байт.
Для напоминания: если есть три байта a, b, c то мажоритарная функция M = (a & | (a & c) | (b & c).

[_artem_]

Я не занимался помехозашишенными кодами но предполагаю что есть несколько методов в этом деле :
- обнаружение ошибок - то что делается проверяется посредством CRC или checksum. Если ошибка в пакее то передается снова.
- исправление ошибки - типа код рида соломона или хемминга (если не ошибаюсь) позволяет исправлять определенное количество потерянной информации
http://en.wikipedia.org/wiki/Hamming_code
http://en.wikipedia.org/wiki/Convolutional_code
http://en.wikipedia.org/wiki/Reed-Solomon_error_correction
http://en.wikipedia.org/wiki/Binary_Golay_code
http://en.wikipedia.org/wiki/Reed-Muller_code
http://en.wikipedia.org/wiki/Turbo_code

- введение избыточности - когда одни и теже данные передаются два ili bolee раза
- перемешивание данных (по моему interleaving называется ) - меняется последовательност передачи битов из пакета так что выпадение нескольких битов подряд приводит к одиночной ошибке которая может быть восстановлена исправляюшим кодированием

Если нужно могу найти книгу по кодированию на аглицком правда. Если можно исправить кодированием и никаких религиозных ошибок при установке рс485 произведено не было - то кодирование самый дешевый способ исправить положение .

[KRS]

До 4 бит на 64 битный пакет можно легко востсановить.
Самое изветсное кодирование пожалуй рида-соломна

Можно и попроще что использовать например код Хемминга

здесь статью неплохую на русском можно скачать
http://www.samag.ru/cgi-bin/go.pl?q=articles;n=08.2003;a=05

[dx40]

Тут http://dsp-book.narod.ru/zip.html есть готовые исходники.

[Andy Mozzhevilov]

при инвертировании нескольких бит может случится так что получится другая команда и она будет выполнена и подтверждение тоже не поможет так что в этом случаи придется повышать качество связи
расстояние по времени между байтами пакета больше чем время передачи байта пакета так что при ошибке синхронизации будет потерян только первый байтно такое событие еще менее вероятно так как по итогам проведенных испытаний небело зарегистрировано ошибки более 3 бит

я передали почти 4 гигабайта информации

Как то сумбурно, но имхо:
Для решения вашей задачи необходимо реализовать 2 механизма, которые должны:
1. Обеспечить определенную вероятность необнаруженной ошибки. Для защиты от этого:

может случится так что получится другая команда и она будет выполнена

2. Обеспечить контроль получения команды.

Первое обычно решается протоколом на канальном уровне. Он должен быть хорошо продуман, пакеты должны быть защищены кодом, обнаруживающим ошибки. В вашем случае достаточно применить CRC16.
Протокол можно взять "modbus serial line protocol". Там многие вещи продуманы, хотя и не нестолько, как хотелось бы.

Второе решается квитированием.

Если рассуждать о применение кодов с исправлением ошибок, то эти коды имеет смысл применять:
1. если канал симплексный
2. если время распространения сигнала от передатчика до приемника несоизмеримо больше времени передачи самого пакета (спутниковые каналы)
3. если необходимо произвести доставку сообщения за время "не более чем", а ширина канала не позволяет организовать перезапрос искаженных кадров.

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

[asen]

В нашем случии как раз выполняются все три приведенных ниже требования

Если рассуждать о применение кодов с исправлением ошибок, то эти коды имеет смысл применять:
1. если канал симплексный
2. если время распространения сигнала от передатчика до приемника несоизмеримо больше времени передачи самого пакета (спутниковые каналы)
3. если необходимо произвести доставку сообщения за время "не более чем", а ширина канала не позволяет организовать перезапрос искаженных кадров.

а насчет

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

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

[Сергей Борщ]

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

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

[asen]

да это верно но в моем случии передача байтовая с приличными интервалами между байтов так что при потере 1 байта получается 8 бит из пакето 64 бита это в принципе тоже востоновимо

[Andy Mozzhevilov]

В нашем случии как раз выполняются все три приведенных ниже требования

Если рассуждать о применение кодов с исправлением ошибок, то эти коды имеет смысл применять:
1. если канал симплексный

Почему RS-485 стал симплексным? Конечно, любой канал можно использовать как симплексный, но по сути RS485 - полу-дуплекс.

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

Да ну, бросьте, в вашем случае это время вообще можно не учитывать.

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

Судя по тому, что время между между байтами у вас больше, чем время передачи байта (по вашим словам), то канал используется крайне неэффективно, соответсвенно запас по ширине есть.

а насчет

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

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

Сергей тут сделал правильное уточнение.

да это верно но в моем случии передача байтовая с приличными интервалами между байтов так что при потере 1 байта получается 8 бит из пакето 64 бита это в принципе тоже востоновимо

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

[ASN]

asen

IMHO, Вы очень усложняете задачу там, где это не требуется.
Суммируя сказанное vladec, Andy Mozzhevilov, Сергей Борщ и _artem_
1. Проработать вопрос организационно-технических мероприятий по обеспечению надлежащего качества линия связи. Для этого можно использовать набор тестовых последовательностей, измеряющих это самое качество. Если оно не удовлетворяет – обеспечить средствами заказчика. Это не Ваши проблемы.
2. Правильно реализовать согласование линий связи (проанализировать схемотехнику устройтсва).
3. Использовать обыкновенную защиту CRC16 (или CRC32) на основе протокола modbus serial line protocol.
4. Если есть запас по скорости, то передавать команду нечётное число раз и принимать решения абонентом методом мажоритирования.
5. Если есть требование гарантированной доставки команду, то лучше всегда периодически возвращать статус устройтсва. Это позволяет с большей достоверностью определить прошла команда или нет.

[Andy Mozzhevilov]

asen

4. Если есть запас по скорости, то передавать команду нечётное число раз и принимать решения абонентом методом мажоритирования.

При использовании CRC16/32 смысла в каком-либо мажорировании не вижу.

5. Если есть требование гарантированной доставки команду, то лучше всегда периодически возвращать статус устройтсва. Это позволяет с большей достоверностью определить прошла команда или нет.

Лучше не периодически подтверждать статус, а использовать квитирование на каждую команду.
В общем модбас взять и реализовать.