Может быть, не решил пока. Мороки с этим много, не мой профиль, я разработчик. Кроме того, производство в Австралии слишком дорого стоит, а уж пересылка по почте - можете представить... Может, скооперируюсь с кем-нибудь, если проект наберет популярность.
HBus
-
- Сообщения: 254
- Зарегистрирован: Ср июл 09, 2014 3:48 pm
- Благодарил (а): 6 раз
- Поблагодарили: 41 раз
Re: HBus
-
- Сообщения: 18
- Зарегистрирован: Сб мар 16, 2019 6:13 pm
- Благодарил (а): 0
- Поблагодарили: 0
Re: HBus
Что т я не совсем понял у вас схема передатчика на преобразователе КАН а приемника на токовом ключе? т.е. Устройства не могут общаться. А вообще еще на заре микроконтроллеров когда в ходу МК 80С51 были - была придумана однопроводная двунаправленная схема приема передатчика на основе токовых ключей, с опторазвязкой и питанием от 24в. (промышленный стандарт) , с эхом, протоколов я не знаю, но схему могу дать. Если я правильно понял то питание и земля отдельно два провода + данные один. Чем КАН не устраивает? Лишний провод? Кстати КАН прекрасно работает и не на витой паре, проверенно на лифтовых подвесных кабелях длинной 80 метров с кучей наводок и силовых жил.
-
- Сообщения: 254
- Зарегистрирован: Ср июл 09, 2014 3:48 pm
- Благодарил (а): 6 раз
- Поблагодарили: 41 раз
Re: HBus
А я не понял, откуда вдруг появился "токовый ключ" (наверное, подразумевается "токовая петля"?). То, что я делаю, не имеет никакого отношения к "токовой петле".anatoliyrnd писал(а): ↑Вс мар 17, 2019 10:53 pmЧто т я не совсем понял у вас схема передатчика на преобразователе КАН а приемника на токовом ключе? т.е. Устройства не могут общаться.
Я писал ранее, что использую приемопередатчики CAN. "Приемопередатчик" - значит, что одна микросхема является и приемником CAN, и передатчиком CAN. Я уже давал ссылку на проект на GitHub-е. Там есть схемы устройств, а также описание, какие витые пары кабеля Cat5 я предлагаю использовать.
-
- Сообщения: 14
- Зарегистрирован: Пн янв 16, 2017 12:26 pm
- Благодарил (а): 1 раз
- Поблагодарили: 2 раза
Re: HBus
Я тоже слежу за темой! Как раз ищу решение по проводному каналу связи по дому, но пока надо запустить то, что уже запланировано на ненадежном Wi-Fi. Следующий этап переход на проводной канал, все равно к каждому устройству тяну питание от безперебойника на 24В.
Пока толком не вник в вашу реализацию до конца, но почему не использовать CAN с CAN трансивером на низкой скорости? Где то эта идея поднималась давно, ее разнесли в пух и прах, хотя там и доминантность передающего и контрольная сумма на аппаратном уровне, но длинна всего 8 Байт. Как в Вашей сети реализовано разрешение коллизий? Одновременная передача по уарт и прием, т.е. полчение результата об успешной передаче только после отправки хотя бы одного байта? Как дальше действуют узлы?
Пока толком не вник в вашу реализацию до конца, но почему не использовать CAN с CAN трансивером на низкой скорости? Где то эта идея поднималась давно, ее разнесли в пух и прах, хотя там и доминантность передающего и контрольная сумма на аппаратном уровне, но длинна всего 8 Байт. Как в Вашей сети реализовано разрешение коллизий? Одновременная передача по уарт и прием, т.е. полчение результата об успешной передаче только после отправки хотя бы одного байта? Как дальше действуют узлы?
-
- Сообщения: 254
- Зарегистрирован: Ср июл 09, 2014 3:48 pm
- Благодарил (а): 6 раз
- Поблагодарили: 41 раз
Re: HBus
Вполне нормальное решение. Так сделана бельгийская система Velbus: нормальный CAN, но на скорости 19.2 kbps. Я именно с этого и начинал несколько лет назад, использовал CAN контроллер MCP2515, естественно, с CAN трансивером. Но за счет CAN контроллера все получалось в разы сложнее чем то, что я делаю сейчас, и железо, и софт. Я это забросил, когда CAN у меня заработал, но для дальнейшего развития надо было или осваивать CANopen/CanFestival, или делать нечто подобное ему самостоятельно.
Вообще, "верхний уровень" софта является самым большим камнем преткновения, но в HBus он решается тривиально просто за счет JSON, MQTT и возможности настройки узлов путем написания Ардуино скетчей под задачу. В "фирменных" системах автоматизации, KNX, C-Bus, Velbus и т.п., об этом даже мечтать не приходится, все ПО закрытое и для применения настраивается специальными программами. Поэтому ПО сложное и дорогое, а узлы не очень-то универсальные. Из-за этого все очень дорого получается, шутка ли, содержать такую ораву разработчиков и программистов. И за счет сложности использования без профессионального инсталятора не всякий решится такую систему установить, а это еще цену увеличивает раза в полтора, наверное, или даже более того. Для тех, кто умеет паять и писать Ардуино скетчи, система HBus обойдется, я думаю, более чем на порядок дешевле, чем "фирменная", при сопоставимых свойствах и возможностях. На CAN такого достичь не удастся, все будет дороже и намного сложнее.
"Доминантность" определяется физическим уровнем, а не протоколом. Поскольку на физическом уровне я использую приемопередатчики (трансиверы) CAN, то, соответственно, в HBus и "доминантность" есть, и вообще все свойства физического уровня CAN, а там еще много чего хорошего. Вместо контрольной суммы и CAN, и HBus используют CRC. Вычисление CRC в HBus сделано программно и не занимает много места или времени.
Я не вижу, в чем HBus уступал бы "настоящему CAN" для своей области применения - автоматизации дома. CAN быстрее, но для дома это не достоинство, а недостаток: при скоростях 1 Mbps нельзя делать длинный кабель, нельзя использовавать свободную топологию прокладки кабеля, нельзя делать большие ответвления, надо обязательно ставить терминаторы с обих сторон. Тогда как опыт Velbus показывает, что при 19.2 kbps физический уровень CAN позволяет использовать частичное терминирование и свободную топологию с суммарной длиной кабеля до 1 км. Еще CAN в принципе позволяет обеспечить более устойчивую работу в условиях сильных помех. Однако контроллер CAN сложен, в нем огромное количество всяких регистров, что чрезмерно раздувает сложность ПО.
И наоборот, в родной для CAN области применения, в автомобилях, применять HBus было бы довольно глупо. Вот там вся эта система обработки ошибок, быстрой пересылки коротких сообщений, автоматической выборки нужных сообщений из потока, и т.п. - играют во всей красе, несмотря на сложность ПО. Для автомобилей это оправдано, в критической ситуации такая система управления мотором и т.п. не подведет, а от этого может зависеть жизнь. Ну а в доме все это зачем? C-Bus и KNX, гораздо более простые и медленные чем CAN, прекрасно справляются со своими задачами.
Два варианта. Дешевые узлы используют обнаружение коллизий, CSMA/CD. При передаче узел все время слушает шину, если эхо не совпало с переданным байтом - выключает передатчик. Более дорогое решение - избегание коллизий, CSMA/CA. Для этого использован внешний арбитр на микроконтроллере PIC16. Арбитр на битовом уровне слушает передаваемый и принимаемый сигналы и блокирует передачу при несовпадении.
После обнаружения коллизии передающий узел выдерживает случайную паузу 2...12 мс, и, если на шине в течении 2 мс нет сигналов, повторяет попытку передачи. Сейчас узел делает до 3-х попыток, даже не пытаясь увеличивать свой приоритет передачи, после чего "сдается".
-
- Сообщения: 254
- Зарегистрирован: Ср июл 09, 2014 3:48 pm
- Благодарил (а): 6 раз
- Поблагодарили: 41 раз
Re: HBus
Для измерителя мощности HBus_Power_Meter выложил работающий скетч. Благо модуль более старой ревизии 1.0 был у меня уже готов. Старый скетч, без HBus, немного причесал и тоже выложил под именем Sole_Power_Meter.
Измерения тока делаются раз в 1.024 мс, синхронно с сетью, 19 измерений за полный период сети. Сетевое напряжение не меряется, оно полагается стабильным и синусоидальным. Мгновенная мощность считается после каждого измерения, затем мощности суммируются и усредняются. Получается почти rms. В этом существенное отличие от более простых поделок, где измеряется пиковый ток один раз за период. Модуль раздельно считает общее потребление и мощность от солнечной электростанции. Измеренные мощности выдаются в HBus, а также отображаются на светодиодной RGB ленте: потребляемая из сети - красным цветом, уходящая в сеть - синим, произведенная и использованная локально - зеленым. Измерения выдаются при изменении усредненной мощности более чем на 10 Вт, но не чаще чем 2 раза в секунду. Кроме того, измерения выдаются регулярно, раз в 20 сек, безотносительно к тому, именились показания или нет.
Для измерения тока используются два токовых трансформатора на 100 А. Один трансформатор меряет суммарный ток, второй - ток солнечной электростанции. Для индикации использована светодиодная лента длиной 1м на 12V с индивидуальным управлением RGB LEDs, в сумме 60 светодиодов, 20 групп по 3 последовательно соединенных RGB LEDs; использована библиотека FastLED. Для удобства лента может располагаться в нескольких десятках метров от от самого измерителя, для этого дополнительно используется модуль "LED драйвер". Соединение между измерителем и драйвером - кабелем Cat5, в нем и сигнал, и питание. Для связи измерителя с драйвером использован интерфейс RS485 (вернее, RS422, если быть совсем точным).
Измерения тока делаются раз в 1.024 мс, синхронно с сетью, 19 измерений за полный период сети. Сетевое напряжение не меряется, оно полагается стабильным и синусоидальным. Мгновенная мощность считается после каждого измерения, затем мощности суммируются и усредняются. Получается почти rms. В этом существенное отличие от более простых поделок, где измеряется пиковый ток один раз за период. Модуль раздельно считает общее потребление и мощность от солнечной электростанции. Измеренные мощности выдаются в HBus, а также отображаются на светодиодной RGB ленте: потребляемая из сети - красным цветом, уходящая в сеть - синим, произведенная и использованная локально - зеленым. Измерения выдаются при изменении усредненной мощности более чем на 10 Вт, но не чаще чем 2 раза в секунду. Кроме того, измерения выдаются регулярно, раз в 20 сек, безотносительно к тому, именились показания или нет.
Для измерения тока используются два токовых трансформатора на 100 А. Один трансформатор меряет суммарный ток, второй - ток солнечной электростанции. Для индикации использована светодиодная лента длиной 1м на 12V с индивидуальным управлением RGB LEDs, в сумме 60 светодиодов, 20 групп по 3 последовательно соединенных RGB LEDs; использована библиотека FastLED. Для удобства лента может располагаться в нескольких десятках метров от от самого измерителя, для этого дополнительно используется модуль "LED драйвер". Соединение между измерителем и драйвером - кабелем Cat5, в нем и сигнал, и питание. Для связи измерителя с драйвером использован интерфейс RS485 (вернее, RS422, если быть совсем точным).
-
- Сообщения: 18
- Зарегистрирован: Сб мар 16, 2019 6:13 pm
- Благодарил (а): 0
- Поблагодарили: 0
Re: HBus
Да пардон совершенно верно - Токовая петля. И да чего-то не найду откуда я взял это, возможно что-то перепутал, было очень много схем открыто.
Весьма интересное решение.
"Дешевые узлы используют обнаружение коллизий, CSMA/CD" " - Это реализовано в библиотеке HBuss.cpp?
Весьма интересное решение.
"Дешевые узлы используют обнаружение коллизий, CSMA/CD" " - Это реализовано в библиотеке HBuss.cpp?
-
- Сообщения: 254
- Зарегистрирован: Ср июл 09, 2014 3:48 pm
- Благодарил (а): 6 раз
- Поблагодарили: 41 раз
Re: HBus
Да, это сделано в библиотеке. В файле HBrxtx.cpp функция Hb_rxtx::tx() во время передачи все время слушает эхо и при несовпадении возвращает ошибку. А в файле HBus.cpp в задаче coos_task_HBus_rxtx() это вызовет окончание передачи и, после паузы, повторную попытку передачи.anatoliyrnd писал(а): ↑Сб мар 23, 2019 10:15 pm"Дешевые узлы используют обнаружение коллизий, CSMA/CD" " - Это реализовано в библиотеке HBuss.cpp?
К сожалению, библиотека HBus пока что довольно рыхлая. В том смысле, что ее нельзя установить как Ардуино библиотеку и больше не трогать. Пока что ее приходится копировать в каждый проект и кое-что редактировать под задачу. Доводить до состояния "настоящей библиотеки" я буду позже, когда погоняю систему получше.
-
- Сообщения: 254
- Зарегистрирован: Ср июл 09, 2014 3:48 pm
- Благодарил (а): 6 раз
- Поблагодарили: 41 раз
Re: HBus
1. Выложил схему еще одного модуля - PIR Sensor. Название условное, поскольку к нему можно не только PIR сенсор движения подключать, и к тому же 3-канальный выход на P-MOSFET пригоден для управления всякими RGB лентами. Попробовал микроволновый сенсор RCWL-0516, очень понравился, любое движение фиксирует четко.
2. Получил заказанные ранее PCB. Для начала собираю модуль MOSFET, но не все 4 канала, а только один. Есть у меня место в доме куда я его поставлю, там у меня белая светодиодная лента. Сейчас работает от автономной Ардуинки с реле, включается от фоторезистора когда стемнеет, светит 4 часа, потом выключается. Вот на нем и обкатаю.
Собранный модуль с одним MOSFET выходoм:
2. Получил заказанные ранее PCB. Для начала собираю модуль MOSFET, но не все 4 канала, а только один. Есть у меня место в доме куда я его поставлю, там у меня белая светодиодная лента. Сейчас работает от автономной Ардуинки с реле, включается от фоторезистора когда стемнеет, светит 4 часа, потом выключается. Вот на нем и обкатаю.
Собранный модуль с одним MOSFET выходoм:
Последний раз редактировалось akouz Ср апр 17, 2019 8:27 am, всего редактировалось 1 раз.
-
- Сообщения: 14
- Зарегистрирован: Пн янв 16, 2017 12:26 pm
- Благодарил (а): 1 раз
- Поблагодарили: 2 раза
Re: HBus
Какой лучше трансивер CANа взять (MCP2551; SN65HVD230; PCA82C250)? Читал описание на гите, но может еще еще какие то соображения на этот счет? Пока HBus единственный приемлимый вариант, хочу попробовать собрать сеть и потестировать.