HBus

a_kouz
Сообщения: 40
Зарегистрирован: Вт апр 18, 2017 11:25 am
Благодарил (а): 0
Поблагодарили: 8 раз

HBus

Сообщение a_kouz » Вс авг 13, 2017 2:04 pm

HBus - сокращение от Home Bus. Я разрабатываю этот интерфейс уже в течении нескольких лет. Сейчас очередная итерация более-менее приблизилась к уровню, пригодному для повторения, поэтому я начинаю здесь его неспешно описывать.

HBus задуман как открытый интерфейс, сопоставимый по возможностям с EIB/KNX и C-Bus. Это проводной интерфейс, который по одному кабелю передает данные и питание для маломощных устройств. Скорость обмена невысокая, 25 кбит/сек (для сравнения: C-Bus - 5 кбит/сек, KNX - 9.6 кбит/сек). Низкая скорость выбрана сознательно для того, чтобы обеспечить работоспособность в сети с произвольной топологией прокладки кабеля. То есть, кабель можно класть как угодно, и "змейкой", и "звездой", и вообще как бог на душу положит. Терминатор шины один, он должен находиться примерно где-то в середине инсталляции.

Несколько большая, чем в KNX и C-Bus скорость обмена накладывает бОльшие ограничения на суммарную длину кабеля: если C-Bus и KNX позволяют укладывать до 1 км кабеля, то для HBus придется ограничить длину до 300 м. Для стадионов и заводских цехов это будет существенным ограничением, однако для обычных домовладений, я думаю, проблем не возникнет.

Кабель - стандартный Cat 5 или Cat 6. Одна витая пара используется для данных, одна - общий провод, одна - питание 12В, одна пара запасная. Суммарный ток питания в кабеле ограничен на уровне 1 А, чтобы обеспечить пожаробезопасность. Типично устройство HBus берет от кабеля порядка 10-20 мА питания,так что на шину можно навесить порядка сотни устройств.

На физическом уровне обмен ведется при помощи приемопередатчиков CAN. Однако контроллеры CAN, не используется, обмен ведется при помощи обычных UART. Первые устройства я сделал на основе микроконтроллеров PIC24F, в дальнейшем планирую перейти на 8-битные Ардуино. Вследствие отказа от контроллеров CAN, длина сообщений не ограничена 8-ю байтами, в HBus можно передавать достаточно длинные сообщения.

Обмен сделан по принципу CSMA/CA. Любое устройство вправе начать передавать сообщение, если шина свободна. Коллизии (т.е. столкновения передатчиков) обнаруживаются и разруливаются на программном уровне.

Аналогично KNX и C-Bus предусматривается два режима работы:
- Режим конфигурирования, когда РС адресует каждое устройство индивидуально и задает ему настройки.
- Режим нормальной работы, когда любое устройство, "имеющее что сказать", отправляет широковещательное сообщение на шину, а исполнительные устройства выбирают из потока сообщений нужные и отрабатывают их. Этот принцип работы называется "производитель - потребитель", и это именно тот трюк, который при низкой пропускной способности шины обеспечивает отличное время реакции на команды пользователя. Для упрощения согласования с верхними уровнями управления, в этом режиме используется протокол, максимально приближенный к MQTT-SN.

К настоящему моменту более-менее устоялись основные принципы, на которых строится HBus. Сделано и отлажено первое устройство - шлюз USB-HBus с гальванической развязкой. Программа для РС имеется, но пока что мало развита.
HBus_PC_photo.png
HBus_PC_photo.png (430.58 КБ) 10549 просмотров
HBus_PC_rev_1_0.pdf
(75.77 КБ) 335 скачиваний
Следующим будет устройство управления группой светодиодных светильников: печатные платы заказаны, в течении пары месяцев планирую его собрать.
За это сообщение автора a_kouz поблагодарили (всего 3):
Denis_k (Вс авг 13, 2017 7:33 pm) • kalina (Пн авг 14, 2017 3:28 pm) • directman66 (Сб фев 09, 2019 6:46 pm)
Рейтинг: 3.49%
Aven
Сообщения: 529
Зарегистрирован: Сб мар 12, 2016 6:33 pm
Откуда: Ухта, Россия
Благодарил (а): 3 раза
Поблагодарили: 154 раза

Re: HBus

Сообщение Aven » Вс авг 13, 2017 7:32 pm

KNX это передача по одной паре, по двум проводам. Почему бы не использовать RS485? Для него есть куча готового железа, вопрос только в программном уровне...
Напряжение 12В плохая идея, слишком велики потери, лучше обратить внимание на 24В, готовые резервируемые источники питания есть под это напряжение. А для питания конечных устройств напряжение все равно нужно понижать до 5В, разницы с какого особо нет.
a_kouz
Сообщения: 40
Зарегистрирован: Вт апр 18, 2017 11:25 am
Благодарил (а): 0
Поблагодарили: 8 раз

Re: HBus

Сообщение a_kouz » Пн авг 14, 2017 2:45 am

Aven писал(а):KNX это передача по одной паре, по двум проводам. Почему бы не использовать RS485? Для него есть куча готового железа, вопрос только в программном уровне...
Напряжение 12В плохая идея, слишком велики потери, лучше обратить внимание на 24В, готовые резервируемые источники питания есть под это напряжение. А для питания конечных устройств напряжение все равно нужно понижать до 5В, разницы с какого особо нет.
C-Bus и KNX были разработаны в расчете на то, что будут передавать сигнал и питание по одной витой паре. Тем не менее, KNX использует кабель с двумя витыми парами, а C-bus - кабель Cat5 c четырьмя витыми парами. И зачем, спрашивается, было городить огород с совмещением сигнала и питания в одной паре?

Замена шинников c CAN на RS485 не дает никаких преимуществ. Шинники RS485 не позволяют сделать интерфейс CSMA/CA, поскольку про одновременном включении нескольких передатчиков получается короткое замыкание. Поэтому на базе RS485 невозможно сделать интерфейс, работающий по принципу "производитель-потребитель", а это весьма необходимая вещь для "умного дома". Тогда как шинные формирователи CAN широко доступны и стоят столько же, сколько шинные формирователи RS485.

В принципе можно подавать и 24В, поскольку я использую регуляторы 7805 со входным до 30В. Однако напряжение 12В выбрано сознательно. Сопротивление одной жилы кабеля Cat5 составляет 84 Ома на километр. Десяток узлов с потреблением 10 мА, находящиеся на расстоянии 20 м от источника питания, дадут падение напряжения на кабеле всего 1.7 В. Если кабель длинный, то источников питания по длине кабеля можно поставить несколько, никто не мешает.

При этом питание 12В дает следующие преимущества:
- возможность использования в узлах дешевых линейных регуляторов, намного меньше потери мощности в узлах при использовании линейных регуляторов
- возможность питания от автомобильного аккумулятора
- имеется гораздо более широкий выбор микросхем питания с предельным входным напряжением 16В, чем 30В.

В ходе разработки вариант 24В рассматривался, вплоть до создания работающих прототипов. Но затем был отброшен, как не дающий никаких преимуществ для домашних применений, на которые заточен HBus.
Aven
Сообщения: 529
Зарегистрирован: Сб мар 12, 2016 6:33 pm
Откуда: Ухта, Россия
Благодарил (а): 3 раза
Поблагодарили: 154 раза

Re: HBus

Сообщение Aven » Пн авг 14, 2017 8:45 am

Я не знаю что такое C-Bus, но в KNX очень удобно, когда используется всего одна пара.
Кабель используется не простая UTP, а J-Y(ST) 2x2x0,8, что позволяет его просто втыкать в самозащимные клемники.

Изображение
Изображение

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

Что нельзя сделать многомастерную схему на RS-485 скажите разработчикам HDL например.

Использовать 7805 для понижения до 5в неправильно, слишком много тепла рассеивается, нужен радиатор, я несколько лет назад пытался там Arduino Mega запитать, все нафиг выгорело через сутки. Нужно использовать DC-DC понижающий преобразователь (себестоимость копейки), тогда станет неважным, 24в или 12в у вас, в маленькой инсталяции можно и 12 использовать, только смысл?

10мА это только с микропроцессором? :) Посчитайте когда еще реле появятся... Питание должно быть стабильное на всем участке линии.
Aven
Сообщения: 529
Зарегистрирован: Сб мар 12, 2016 6:33 pm
Откуда: Ухта, Россия
Благодарил (а): 3 раза
Поблагодарили: 154 раза

Re: HBus

Сообщение Aven » Пн авг 14, 2017 8:49 am

Шлюз в USB считаю неудобным и даже вредным в связи с ненадежностью самого USB (ну максимум для первоначального конфигурирования). Надо делать сразу в Ethernet.
a_kouz
Сообщения: 40
Зарегистрирован: Вт апр 18, 2017 11:25 am
Благодарил (а): 0
Поблагодарили: 8 раз

Re: HBus

Сообщение a_kouz » Пн авг 14, 2017 12:16 pm

Aven писал(а):Я не знаю что такое C-Bus
https://en.wikipedia.org/wiki/Clipsal_C-Bus
Предтеча и "старший брат" KNX. В истоках C-Bus и KNX стоят одни и те же люди из не очень широко известной датской фирмы.
Aven писал(а): Кабель используется не простая UTP, а J-Y(ST) 2x2x0,8, что позволяет его просто втыкать в самозащимные клемники.
Кабель KNX в несколько раз дороже обычного UTP. Для удобства работы профессиональных инсталляторов, кабель UTP просто обжимается в разъем RJ-45 с прорезанием изоляции. Для того, чтобы потом продолжить прокладку кабеля, на устройствах C-bus стоят два гнезда RJ-45.

Изображение

Однако мне удобнее работать с терминалами "под винт", поэтому я ставлю их. Хотя они немного дороже.
Aven писал(а): Что нельзя сделать многомастерную схему на RS-485 скажите разработчикам HDL например.
Какое отношение имеет HDL к "многомастерной схеме на RS-485"? Я их знаю как китайскуя фирму, делающую сравнительно дешевые устройства KNX. Ни разу ни от кого кроме вас не слышал, чтобы HDL упоминали как неких экспертов в RS485. В чем же состоят их достижения в RS485, коль вы на них ссылаетесь? Будьте любезны, приведите ссылку.

Принцип "производитель-потребитель" - это вовсе не мультимастер. При использовании принципа "производитель-потребитель" в сети вообще нет мастера, есть только "производители информации" и "потребители информации". Но при этом никто никем не командует.

На RS485 мультимастер достаточно просто реализуется в виде протокола с передачей токена. Так сделано, например, в Profibus. Однако интерфейс "производитель-потребитель" на RS485 сделать нельзя. Для того, чтобы его правильно реализовать, передатчик должен иметь или открытый коллекторный выход (так сделано в C-bus и KNX), или, как вариант, дифференциальный "открытый коллекторный выход" (так сделано в CAN). Единственный способ хоть как-то прилепить шинник RS485 - это использовать несколько извращенную схему его включения, чтобы имитировать характеристики шинника CAN. Собственно,самые первые реализации CAN именно так и были сделаны, пока настоящие шинники CAN не появились.
Aven писал(а): 10мА это только с микропроцессором? :) Посчитайте когда еще реле появятся...
От регулятора 5В - ровно столько же. Реле будут запитаны напрямую от 12В.
kalina
Сообщения: 180
Зарегистрирован: Пн фев 22, 2016 11:01 pm
Благодарил (а): 29 раз
Поблагодарили: 90 раз

Re: HBus

Сообщение kalina » Пн авг 14, 2017 3:48 pm

Проводная система ИМХО всегда надёжней беспроводной, хотя плюсы и минусы есть везде. У меня есть к вам пару вопросов:
1. Как планируете интегрировать вашу разработку в MajorDomo (и планируете ли вообще)?
2. Может ли проблема отдельно взятого узла "положить" всю проводную сеть? Если да, то как можно определить проблемный узел?
3. Насколько ваша разработка открытая - схемотехника, исходники, описание протокола и т.д.?
4. Планируется ли коммерческая версия в будущем?
5. Переход на ардуино обусловлен дешевизной, массовостью и аудиторией? Как планируете аппаратно приводить схемотехнику под ваши нужды?
Raspberry PI3 + образ 3.31 | MDMSGate | Lighting | LightingX2 | Power | Multisensor
a_kouz
Сообщения: 40
Зарегистрирован: Вт апр 18, 2017 11:25 am
Благодарил (а): 0
Поблагодарили: 8 раз

Re: HBus

Сообщение a_kouz » Пн авг 14, 2017 4:34 pm

kalina писал(а): 1. Как планируете интегрировать вашу разработку в MajorDomo (и планируете ли вообще)?
Чуть позже сделаю WiFi шлюз на ESP8266.
kalina писал(а): 2. Может ли проблема отдельно взятого узла "положить" всю проводную сеть?
Эта проблема решается на уровне шинника. Во все CAN шинники намертво встроен защитный механизм, который переводит выход передатчика в пассивное состояние, если микроконтроллер пытается долго держать активный (доминантный) уровень на шине.
kalina писал(а): Если да, то как можно определить проблемный узел?
Последовательным пингованием всех узлов в режиме конфигурирования (т.е. в режиме индивидуальной адресации). Кто не отвечает - у того проблемы.
kalina писал(а): 3. Насколько ваша разработка открытая - схемотехника, исходники, описание протокола и т.д.?
Открытая. Выкладывать пока не тороплюсь, поскольку все еще вношу изменения. Но постепенно вывалю все на Гитхаб.
kalina писал(а): 4. Планируется ли коммерческая версия в будущем?
Очень-очень вряд ли. У меня таких планов нет.
kalina писал(а): 5. Переход на ардуино обусловлен дешевизной, массовостью и аудиторией?
Да
a_kouz
Сообщения: 40
Зарегистрирован: Вт апр 18, 2017 11:25 am
Благодарил (а): 0
Поблагодарили: 8 раз

Re: HBus

Сообщение a_kouz » Вт авг 15, 2017 1:53 pm

Чуть больше технических деталей про HBus.

Кая я упомянул выше, в приемопередатчиках CAN имеется защитный межанизм, который выключает передатчик, если на его выходе длительное время имеется активный (доминантный) уровень. Точное время защитного тайм-аута в даташитах не приводится, однако минимальное гарантированное время оговорено - не менее 300 мкс. Значит, передатчик HBus должен выдавать "нули" в течении не более чем 300 мкс. Для "настоящего" CAN, который работает на скоростях порядка 1 Мбит/сек это не является препоной. А вот для HBus, бодовая скорость которого выбрана как можно более низкой, это проблема.

Напомню, что HBus использует обычный UART, в котором старт-бит тоже выдается в виде "нуля". При скорости 25 кбит/сек только две кодовые комбинации, поданные на передачу, могут вызвать срабатывание защиты в приемопередатчике CAN:
- код 0x00, с учетом старт-бита это 9 подряд идущих "нулей", доминантный уровень в течении 360 мкс
- код 0x80, с учетом старт-бита это 8 подряд идущих "нулей", доминантный уровень в течении 320 мкс

Эти две кодовые комбинации являются запрещенными в HBus. Для того, чтобы избавиться от них, используется байт-стаффинг. Выдаваемая на выход информация проверяется, вместо встреченных в потоке символов 0x00 и 0x80 подставляются специальные пары символов. При приеме производится обратная операция, специальные пары символов заменяются обычными.

Однако следует ожидать, что символы 0x00 и 0x80 встретятся в передаваемом потоке гораздо чаще, чем прочие символы. Как-то расточительно было бы передавать по два символа вместо одного популярного. Чтобы избавиться от такой расточительности, над всеми символами перед записью в UART производится операция XOR ("исключающее или") с числом 0x11. Соответственно, 0x00 превращается в 0x11, а 0x80 - в 0x91. И наоборот, 0x11 превращается в 0x00, а 0x91 - в 0x80. Если делать байт-стаффинг до операции XOR, то теперь из потока надо убирать символы 0x11 и 0x91, которые встречаются не так часто.

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

В сумме таблица специальных пар символов выглядит так:
0xEE-0x02 - начало сообщения "точка-точка"
0xEE-0x03 - начало сообщения "точка-многоточка"
0xEE-0x07 - конец сообщения
0xEE-0x08 - заменить на 0x11
0xEE-0x09 - заменить на 0x91
0xEE-0x0A - заменить на 0xEE
0xEE-0x0B - заменить на 0x11-0x11
0xEE-0x0C - заменить на 0x91-0x91
0xEE-0x0D - заменить на 0xEE-0xEE

Последние 3 пары - это уже "рюшечки". Они позволяют не сильно раздувать размер сообщения когда в нем много одинаковых символов 0x11, 0x91 или 0xEE.

PS: Здесь я расписываю все подробно и по-русски. На Гитхабе все будет более скупо и по-английски.
a_kouz
Сообщения: 40
Зарегистрирован: Вт апр 18, 2017 11:25 am
Благодарил (а): 0
Поблагодарили: 8 раз

Re: HBus

Сообщение a_kouz » Пт сен 15, 2017 2:13 pm

HBus_LED_lamp_rev_1_0.pdf
(138.59 КБ) 321 скачивание
Наконец-то пришли печатные платы для первого практического HBus устройства. Это будет устройство управления для кластера из 6 потолочных светодиодных 12W 230Vac светильников. Задачи для него будут такие:
- питание устройства - от источника 12В, которое берется от автомобильного аккумулятора, заряжаемого от солнечной панели
- после паузы, первое включение выключателем - загораются все 6 светильников, после быстрого передергивания выкл-вкл - остаются включенными 2 светильника из 6
- при пропадании сетевого напряжения, один из 6 светильников продолжает работать от 12В с возможностью плавного диммирования яркости
- встроенный RF приемник на 433 МГц, который получает сигнал от передатчика с герконовым контактом на входной двери; передатчик без батарейки, питается от суперконденсатора, заряжаемого маленькой солнечной панелькой
- связь с центральным сервером и с другими устройствами - по HBus

Устройство спаяно, следующий этап - отладка:
Board_rev_1_0.jpg
Board_rev_1_0.jpg (293.8 КБ) 10056 просмотров
Схема устройства:
HBus_LED_lamp_rev_1_0.pdf
(138.59 КБ) 321 скачивание
Ответить