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

Я уже много раз ссылался на Modbus RTU. Если вы не понимаете, как он работает в условиях частых помех, поясню:
- в начале фрейма, еще до начала пакета данных, передатчик включает свой трансивер на передачу и выдерживает паузу в 3.5 байт-интервала, не передавая никаких байтов
- поскольку максимально допустимая пауза между байтами внутри пакета данных не может превышать 1.5 байт-интервала, все приемники успевают закончить прием ложных байтов, после чего, обнаружив длинную паузу на линии, очищают свои буфера приема от мусора, нанесенного помехами во время пассивного периода между фреймами
- после этого все приемники, без какой-либо коррекции ошибок, благополучно принимают неиспорченный пакет данных (передатчик, конечно же, гонит весь фрейм как одно целое, ни в коем случае не переводя трансивер в третье состояние во время фрейма).

Естественно, подразумевается, как и в случае RS-422, что помеха не может пересилить включенный передатчик. Чтобы пересилить передатчик RS-485, помехе требуется в сотни раз большая мощность, чем для пересиливания резисторов растяжки (или для пересиливания рецессивного состояния передатчика CAN). Поэтому в паузах между фреймами помехи могут вызывать прием ложных байтов, а во время фрейма, когда передатчик включен - бессильны это сделать.

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

Вы издеваетесь? Сначала написали одно, потом "уточнением" изменили свою точку зрения на противоположную.

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


Не так. Не бывает абстрактно "плохих" и "хороших" протоколов, если не указаны условия применения.
Если протокол не способен работать в конкретных условиях, предоставляемых конкретной средой передачи- он не подходит (он плохой).


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

А помеха, которая глушается активным передатчиком- это классика, MODBUS RTU на это заточен. Это "хороший" протокол для линий, в которых помеха заглушается активным передатчиком. Если Вы попробуете необдуманно применить MBRTU на линиях, в которых помехи сильнее передатчика- он не справится, и, соответственно, перейдет в разряд "плохих" протоколов.

Во всем треде я последовательно излагаю свои взгляды касательно протоколов для RS-485 без малейших изменений: раз, два, три, четыре, пять, шесть, семь, восемь, и т.д. Так что не в кассу.


Слив засчитан. Однако в вашем положении обтекать более пристало молча.


Не переливайте из пустого в порожнее, речь все время шла о RS-485, для которого это всегда имеет место.

Вот здесь вы несли глупости на тему RS-485, a вот это объяснение - проигнорировали, очевидно, вcледствие непонимания. В этом диалоге o RS-485: 1 - 2 - 3 - вас практически прямым текстом спросили, как обеспечить помехоустойчивость, когда незадолго до начала пакета помеха навела ла линию ложный символ; из диалога видно, что в тот момент ответа вы не знали. И вот теперь, когда вам разжевали и в рот положили, и до вас, наконец-то, дошло, вы делаете поворот оверкиль и вместo "это невозможно" начинаете говорить "это очевидно" и обвиняете меня в "непоследовательности". Смешно.

Если возвращаться к теме, то я бы делал или на Ethernet или на Lonworks.
Для себя выбрал Ethernet, т.к. более универсальный, уже развел по 1-2 кабеля в каждое помещение, получилось как раз 16 - свич занят полностью.
Пока подключены интернет и прочее телевидение.
Единственно, что непонятно - нужен ли вообще "умный дом". Термоголовка надежнее привода клапана.
В планах только автоматический полив.

Ethernet хорошо, но пока дороже прочих решений и зачастую избыточен.

Да, это как дорогое бухло - дорого и избыточно

Ну как сюда не предложить такой вариант:Основная идея, И еще ссылочка:Ссыль

еще немного и убийцо MODBUS будет готов...