умный дом [выбор интерфейса] Опции

[qnx]

начал подумывать о автоматизации процессов в доме, в частности управлении и контроле.
структуру думаю примерно следующую.

ПК (веб сервер, умеющий работать с железкой с портами ВВ, шим, аналоговыми (на которые в дальнейшем навешиваются объекты контроля и управления))

ПК соединен с вайфай роутером, для видения его внутри и по интернету.

и собственно вопрос в выборе железки.
думаю найти usb плату, умеющую работать с портами, но ничего подходящего не нахожу (или не то/так ищу)

на сколько понимаю много оборудования сейчас делается так: ПК->USB->COM->uart-переферия

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

[NicSm]

=AK=
Вы смеетесь? Про 485 и 422? В устройствах что я смотрел микросхемы драйверов одинаковые.
Разница первый полудуплекс второй полный.

[=AK=]

=AK=
Вы смеетесь? Про 485 и 422? В устройствах что я смотрел микросхемы драйверов одинаковые.
Разница первый полудуплекс второй полный.

Мне больше плакать хочется, когда я снова и снова слышу наивное недоумение по этому поводу. Да, разница именно в этом. Низкое выходное сопротивление постоянно включенного драйвера RS-422 очень эффективно давит наведенные в линии помехи. Давит намного эффективнее, чем вшивые резисторы растяжки. Настолько эффективнее, насколько ниже выходное сопротивление драйвера в сравнении с резисторами растяжки. RS-422 десятки и сотни раз более помехоустойчив, чем RS-485 с паршивым протоколом, который в плане помехоустойчивости полагается только нa растяжки.

2. В чем разница между RS-485 и RS-422? На физическом уровне. Почему для RS-485 подтяжки надо, а для RS-422 Не надо?

RS-422 - это "точка-точка", передатчик постоянно включен. А RS-485 - это шина, все передатчики большую часть времени выключены и линия свободно болтается, ловя любые помехи.

[A. Fig Lee]

Мне больше плакать хочется, когда я снова и снова слышу наивное недоумение по этому поводу. Да, разница именно в этом. Низкое выходное сопротивление постоянно включенного драйвера RS-422 очень эффективно давит наведенные в линии помехи. Давит намного эффективнее, чем вшивые резисторы растяжки. Настолько эффективнее, насколько ниже выходное сопротивление драйвера в сравнении с резисторами растяжки. RS-422 десятки и сотни раз более помехоустойчив, чем RS-485 с паршивым протоколом, который в плане помехоустойчивости полагается только нa растяжки.


RS-422 - это "точка-точка", передатчик постоянно включен. А RS-485 - это шина, все передатчики большую часть времени выключены и линия свободно болтается, ловя любые помехи.

Понятно. Спасибо. То бишь RS-422 самый стойкий к помехам? А CAN bus?

[=AK=]

То бишь RS-422 самый стойкий к помехам?

RS-485 с правильным протоколом ничуть не хуже.

А CAN bus?

Примерно такой же, как RS-485 с плохим протоколом и резисторами растяжки.

[A. Fig Lee]

RS-485 с правильным протоколом ничуть не хуже.


Примерно такой же, как RS-485 с плохим протоколом и резисторами растяжки.

И при чем тут "правильный протокол"?

[=AK=]

И при чем тут "правильный протокол"?

При том, что сеть RS-485 с правильным протоколом настолько же помехоустойчива, насколько помехоустойчива связь по RS-422. Че-то до вас ничего не доходит, по пять раз прихoдится повторять. Сказка про белого бычка...

[A. Fig Lee]

При том, что сеть RS-485 с правильным протоколом настолько же помехоустойчива, насколько помехоустойчива связь по RS-422. Че-то до вас ничего не доходит, по пять раз прихoдится повторять. Сказка про белого бычка...

Не хамить воспитание не позволяет?

[Ruslan1]

Не хамить воспитание не позволяет?

перевожу на русский:
RS-485 имеет неопределенное состояние в случае, когда никто не передает. То есть состояние линии может быть любое и меняться с любой скоростью.
=AK= использует протоколы, которые чувствительны к этому, то есть они не имеют эффективной защиты от этого "горя".
Некоторые (условно назовем их "остальные") использует протоколы, которым все равно что происходит на линии в то время, когда данные по ней не передаются. Как результат- эти некоторые (и разработанные ими устройства) не видят разницу между "линией, в которой есть неопределенность при отсутствии передачи" и "линией состояние которой между передачами детерменировано"
Еще более некоторые (назовем их "гурманы"), предпочитают, чтобы их драйвер RS-485 не выдавал ложных переходов в микроконтроллер если линия в неопределенном состоянии. Они действуют двумя способами:
1) применяют драйверы RS-485, которые при неподключенной линии выдают неактивный уровень в RX, например SN75LBC184
2) применяют резисторы, "растягивающие" линию из неопределенного состояния в определенное.
3) применяют (1) + (2) вместе.

[Herz]

Господа! Воздержитесь от наездов! Не хватает терпения объяснять спокойно - никто не принуждает участвовать. Тему частично почистил.

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

Один вопрос дилетанта: как приёмники знают, что данные сейчас не передаются?

[Ruslan1]

Один вопрос дилетанта: как приёмники знают, что данные сейчас не передаются?

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

[Herz]

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

Тогда налицо противоречие: чтобы понять, что данные не передаются, приёмники всё равно должны "слушать линию", обрабатывать получаемые сигналы и принимать решение о том, данные ли это. Так это в любой асинхронный протокол в той или иной степени должен проделывать. Говорить в этом случае, что "ему всё равно, что в это время творится на линии" - явное преувеличение.

[Ruslan1]

Тогда налицо противоречие: чтобы понять, что данные не передаются, приёмники всё равно должны "слушать линию", обрабатывать получаемые сигналы и принимать решение о том, данные ли это. Так это в любой асинхронный протокол в той или иной степени должен проделывать. Говорить в этом случае, что "ему всё равно, что в это время творится на линии" - явное преувеличение.

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

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

[Dog Pawlowa]

Приемник, конечно, слушает линию и может делать какие-то проверки, но это внутренние действия.

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

И вряд ли опровержение этого банального факта может лечь в основу Вашей диссертации по философии

[Ruslan1]

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

Я не вижу что тут опровергать и зачем. Вы ни коим образом не опровергаете мои слова.
То что Вы написали, в случае практически любого протокола будет определено как не-данные: отсев будет либо по неправильному байту (не принят STOP), либо по неправильному адресу, либо по CRC, либо по содержимому пакета принятых байтов, либо по длине этого принятого пакета.

А философии действительно не хватает в приборостроении. Может, замутить новое течение... Философия переходов... Полупроводниковая диалектика.... Хм. Надо подумать.....

P.S.
топикстартеру, по существу: не бойтесь Вы CAN или RS485.
CAN сильно серьезней и лучше в подобных задачах с разношерстной аппаратурой . больше уровней ISO включает прямо в спецификацию и больше чего решает аппаратно внутри, до доставки дейтаграммы на программый уровень. CAN любит хорошие провода и правильное терминирование. Ну и меньше придумывать нужно, все уже придумано и стандартизировано, от Heartbeat до LSS (CANopen).

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

если CAN- то CANopen (все основное открыто или открывают после звонка/письма в головной офис, что закрыто- то доставабельно в интернете). Но CAN-приборы обычно дороже чем RS-485.
если RS485- то MODBUS RTU или ASCII (все открыто). Я только RTU пользую, но уже лет пять как к ASCII приглядываюсь- при приеме в компьютер с ним сильно проще.

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

ОК, я бы назвал это просто: помехоустойчивым алгоритмом. Приёмник по определению не может быть безразличен к тому, что происходит на линии. Он вынужден реагировать на все изменения и анализировать их. Центральный контроллер, которому, в конечном итоге, предназначены данные, может не заниматься этой рутиной: функции распознавания и фильтрации помех просто выносятся на периферию. Но никаких чудес, конечно, не происходит: шина остаётся шиной со всеми её проблемами. И объём вычислений остаётся тем же.
Определяемый протоколом. Так?

Так. Объем "вычислений" определяется физической шиной и применяемым протоколом. Примеры "вычислителей":
1) Компаратор с гистерезисом, определяющий переход больше 120 мВ
2)логический автомат приема бита, работающий по принципу совпадения 3 из 5
3) CAN: прием дейтаграммы ведется контроллером CAN, и какая его часть сделана аппаратной логикой а какая вшитой микропрограммой- это внутреннее дело разработчика МК.
4) уже пользовательское: разборка содержимого, счет CRC(тоже бывает вшитая микропрограмма), реакция.

[=AK=]

То что Вы написали, в случае практически любого протокола будет определено как не-данные: отсев будет либо по неправильному байту (не принят STOP), либо по неправильному адресу, либо по CRC, либо по содержимому пакета принятых байтов, либо по длине этого принятого пакета.

А вы никогда не задумывались, что будет происходить при использовании ваших протоколов, если помех много и они приходят часто?

[Ruslan1]

А вы никогда не задумывались, что будет происходить при использовании ваших протоколов, если помех много и они приходят часто?

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

Мне кажется, что это очевидно. Что именно Вас смущает?

Кстати, лет 17 назад сталкивался с таким: стояла в одной организации система сбора данных (ЦТ-5000), по республике у них было расставлено полтора десятка точек сбора. Там сложная каналообразующая аппаратура, передача по ЛЭП с переприемами, что-то поменять в канале связи практически невозможно. Так у них была одна точка, которая за много лет работы ни разу не смогла нормально завершить обмен данными с сервером. НИ РАЗУ. Ну, такой разработчики протокол применили, им же виднее было. Там помеха валила примерно каждый 15й байт (скорость выделенного канала была 100 бод). Мы в своем нижнем уровне тогда применили доморощенный протокол с длиной 11 байт, проработало много лет успешно.

на сколько потенциально могло бы подойти найденное решение посредствам Ethernet?

Если "не мастерить и быстро-стандартно" - то Ethernet это идеальный вариант. В сочетании с технологией PoE вообще крастота. но проводами, wifi применим только как временное решение и для некоторых узлов.

Насчет конкретного линка- тут от метода покупки зависит, я бы начал с ебея-алиэкспресса,
Например, у этого болгарина целый склад вкусностей на эту тему (галантерейщики и кардинал, тьфу, телемеханика и езернет)
http://stores.ebay.com/DAEStore?_trksid=p2047675.l2563

[=AK=]

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

Вы ошибаетесь. Данные в этом случае не будут переданы никогда только в случае использования второсортных протоколов, которые вы ранее обозначили словом "остальные". А в случае использования протоколов, которые вкратце были описаны мною ранее, они будут успешно доставлены по назначению.

Не все так очевидно, как вам кажется.

Кстати, лет 17 назад сталкивался с таким: стояла в одной организации система сбора данных (ЦТ-5000), по республике у них было расставлено полтора десятка точек сбора. Там сложная каналообразующая аппаратура, передача по ЛЭП с переприемами, что-то поменять в канале связи практически невозможно. Так у них была одна точка, которая за много лет работы ни разу не смогла нормально завершить обмен данными с сервером. НИ РАЗУ. Ну, такой разработчики протокол применили, им же виднее было. Там помеха валила примерно каждый 15й байт (скорость выделенного канала была 100 бод). Мы в своем нижнем уровне тогда применили доморощенный протокол с длиной 11 байт, проработало много лет успешно.

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

[Ruslan1]

Вы ошибаетесь. Данные в этом случае не будут переданы никогда только в случае использования второсортных протоколов, которые вы ранее обозначили словом "остальные". А в случае использования протоколов, которые вкратце были описаны мною ранее, они будут успешно доставлены по назначению.

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

[=AK=]

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

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

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

[Herz]

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

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