asen 0 17 мая, 2006 Опубликовано 17 мая, 2006 · Жалоба да это верно но в моем случии передача байтовая с приличными интервалами между байтов так что при потере 1 байта получается 8 бит из пакето 64 бита это в принципе тоже востоновимо Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andy_Mozzhevilov 0 20 мая, 2006 Опубликовано 20 мая, 2006 · Жалоба В нашем случии как раз выполняются все три приведенных ниже требования Если рассуждать о применение кодов с исправлением ошибок, то эти коды имеет смысл применять: 1. если канал симплексный Почему RS-485 стал симплексным? Конечно, любой канал можно использовать как симплексный, но по сути RS485 - полу-дуплекс. 2. если время распространения сигнала от передатчика до приемника несоизмеримо больше времени передачи самого пакета (спутниковые каналы) Да ну, бросьте, в вашем случае это время вообще можно не учитывать. 3. если необходимо произвести доставку сообщения за время "не более чем", а ширина канала не позволяет организовать перезапрос искаженных кадров. Судя по тому, что время между между байтами у вас больше, чем время передачи байта (по вашим словам), то канал используется крайне неэффективно, соответсвенно запас по ширине есть. а насчет Кроме того, нужно учесть, что коды с исправлением ошибок не могут эффективно работать с асинхронными приемопередатчиками. Если код с исправлением ошибок используется, то используется и синхронный канал связи. я не согласен какая разница мехду данными принятыми по асинхронному и синхронному каналу если ошибочный запуск не выполняется. Сергей тут сделал правильное уточнение. да это верно но в моем случии передача байтовая с приличными интервалами между байтов так что при потере 1 байта получается 8 бит из пакето 64 бита это в принципе тоже востоновимо А при помехе между байтами у вас будет принят лишний байт, и возможно искажен следующий, биты будут сдвинуты. В общем, не тем путем вы идете, поверьте Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ASN 0 20 мая, 2006 Опубликовано 20 мая, 2006 · Жалоба asen IMHO, Вы очень усложняете задачу там, где это не требуется. Суммируя сказанное vladec, Andy Mozzhevilov, Сергей Борщ и _artem_ 1. Проработать вопрос организационно-технических мероприятий по обеспечению надлежащего качества линия связи. Для этого можно использовать набор тестовых последовательностей, измеряющих это самое качество. Если оно не удовлетворяет – обеспечить средствами заказчика. Это не Ваши проблемы. 2. Правильно реализовать согласование линий связи (проанализировать схемотехнику устройтсва). 3. Использовать обыкновенную защиту CRC16 (или CRC32) на основе протокола modbus serial line protocol. 4. Если есть запас по скорости, то передавать команду нечётное число раз и принимать решения абонентом методом мажоритирования. 5. Если есть требование гарантированной доставки команду, то лучше всегда периодически возвращать статус устройтсва. Это позволяет с большей достоверностью определить прошла команда или нет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Andy_Mozzhevilov 0 22 мая, 2006 Опубликовано 22 мая, 2006 · Жалоба asen 4. Если есть запас по скорости, то передавать команду нечётное число раз и принимать решения абонентом методом мажоритирования. При использовании CRC16/32 смысла в каком-либо мажорировании не вижу. 5. Если есть требование гарантированной доставки команду, то лучше всегда периодически возвращать статус устройтсва. Это позволяет с большей достоверностью определить прошла команда или нет. Лучше не периодически подтверждать статус, а использовать квитирование на каждую команду. В общем модбас взять и реализовать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
