[adnega 11]

но вот и я также подумал

Все мы по-маленьку делаем жилище умнее. У мну тоже есть умный дом поверх CAN на своих контроллерах аж с 2008 года.

Если интересно, то могу предоставить больше инфы через личку.

[typedef 0]

Все мы по-маленьку делаем жилище умнее. У мну тоже есть умный дом поверх CAN на своих контроллерах аж с 2008 года.

Если интересно, то могу предоставить больше инфы через личку.

конечно интересно!

любая инфа приветствуется, а то мозг пухнет уже :)

 

А зачем CAN с проводами? Если есть беспроводные 802.15.4?

когда "курил" тему про CAN что то мне попадалось про Wireless Can (ZegBee и т.п.) и были там отзывы не очень.

Что конкретно уже не помню, но для себя решил что не стоит.

 

Интересно услышать конечно мнение профессионалов. А то может и правда не стоит морочиться с проводами...

[A. Fig Lee 0]

когда "курил" тему про CAN что то мне попадалось про Wireless Can (ZegBee и т.п.) и были там отзывы не очень.

Что конкретно уже не помню, но для себя решил что не стоит.

 

Интересно услышать конечно мнение профессионалов. А то может и правда не стоит морочиться с проводами...

А я про ZigBee ничего не говорил. Только про физический уровень. Передача пакетов на 802.15.4

Майкрочиповские модули по цене грязи: 12 долларей за штуку на диджикий.

Есть еще кстати, майкрочиповский Miwi протокол сверху 802.15.4

Мы на работе отсебятину гоняем.

 

[Ruslan1 16]

Интересно услышать конечно мнение профессионалов. А то может и правда не стоит морочиться с проводами...

Я вообще не понимаю зачем тут CAN. Возьмите рабоче-крестьянский RS485 и вперед. Все гораздо предсказуемей. И отлаживаться проще и в разводке неприхотливо, и в оборудовании доступней. Почему CAN? Вам не нужны те навороты, для которых разрабатывался CAN, но все его требования Вы должны выдержать от и до, иначе он совсем работать не будет.

[typedef 0]

А я про ZigBee ничего не говорил. Только про физический уровень. Передача пакетов на 802.15.4

Майкрочиповские модули по цене грязи: 12 долларей за штуку на диджикий.

Есть еще кстати, майкрочиповский Miwi протокол сверху 802.15.4

Мы на работе отсебятину гоняем.

а Вы не могли бы для чайников типа меня немного разжевать поподробнее.

Какие компоненты и как физически должна выглядеть подобная CAN сеть в частном доме?

Можно ткнуть носом в интернет, я почитаю.

 

Я вообще не понимаю зачем тут CAN. Возьмите рабоче-крестьянский RS485 и вперед. Все гораздо предсказуемей. И отлаживаться проще и в разводке неприхотливо, и в оборудовании доступней. Почему CAN? Вам не нужны те навороты, для которых разрабатывался CAN, но все его требования Вы должны выдержать от и до, иначе он совсем работать не будет.

на самом деле интересно. Может быть потом и получится RS485, сейчас главное провода правильно разложить.

Конкретно сейчас еще задумался может и впрямь рядом с витой парой какой-нить ШВВП положить под питание узлов.

[A. Fig Lee 0]

а Вы не могли бы для чайников типа меня немного разжевать поподробнее.

Какие компоненты и как физически должна выглядеть подобная CAN сеть в частном доме?

Можно ткнуть носом в интернет, я почитаю.

A почему именно CAN? Дался он вам..

802.15.4 посылает пакеты до 250 кбит (видел и 2 мбит) размером 127 байт или меньше.

Может посылать по таймслотам, может использовать коллижн механизм.

Вот пример майкрочип: соединение простое SPI, с той стороны такой же модуль и SPI.

 

MRF24J40MA

 

 

Шаг стандарный 0.1 дюйма как у дип корпусов. Работать довольно легко, есть примеры.

 

[typedef 0]

A почему именно CAN? Дался он вам..

802.15.4 посылает пакеты до 250 кбит (видел и 2 мбит) размером 127 байт или меньше.

Может посылать по таймслотам, может использовать коллижн механизм.

Вот пример майкрочип: соединение простое SPI, с той стороны такой же модуль и SPI.

 

MRF24J40MA

пытаюсь почитать на эту тему. Все в основном крутится вокруг ZigBee...

Я так понимаю, Вы предлагаете использовать только физический уровень, безо всяких контроллеров и маршрутизаторов. Т.е. каждый узел сети посредством MRF24J40MA читает\пишет из\в сеть. Протокол общения свой, или я не так понял?

 

[A. Fig Lee 0]

пытаюсь почитать на эту тему. Все в основном крутится вокруг ZigBee...

Я так понимаю, Вы предлагаете использовать только физический уровень, безо всяких контроллеров и маршрутизаторов. Т.е. каждый узел сети посредством MRF24J40MA читает\пишет из\в сеть. Протокол общения свой, или я не так понял?

Да. Вместо CAN bus. Ну на CAN у Вас же "свой" протокол, правильно? И тут тоже.

Ему сказали доставить 100 байт в пункт Б, он доставил. По прилету откуда либо говорит "у меня есть 15 байт от Ц".

А что за данные это уже каждый как хочет пляшет.

В CANe разве не так?

[adnega 11]

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

Если нужно чтобы контроллеры могли обмениваться событиями минуя некий "центр", то однозначно CAN.

По-моему, достаточно кинуть витуху от узла к узлу. Потребление контроллеров на уровне 1..2 Вт не требует отдельного силового кабеля.

Лучше использовать постоянное напряжение максимально-возможного значения, скажем, 24 В. Безопасно, до 40 В легко найти микросхему для импульсного БП в узле. Для CAN нужна одна витая пара, например, голубая CAN-H, бело-голубая CAN-L; для питания "общий", например, зеленая и бело-зеленая, для питания "+24В", например, оранжевая и бело-оранжевая; коричневая пара в резерве (или RS-485 для потока данных).

[typedef 0]

Да. Вместо CAN bus. Ну на CAN у Вас же "свой" протокол, правильно? И тут тоже.

Ему сказали доставить 100 байт в пункт Б, он доставил. По прилету откуда либо говорит "у меня есть 15 байт от Ц".

А что за данные это уже каждый как хочет пляшет.

В CANe разве не так?

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

 

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

Если нужно чтобы контроллеры могли обмениваться событиями минуя некий "центр", то однозначно CAN.

По-моему, достаточно кинуть витуху от узла к узлу. Потребление контроллеров на уровне 1..2 Вт не требует отдельного силового кабеля.

Лучше использовать постоянное напряжение максимально-возможного значения, скажем, 24 В. Безопасно, до 40 В легко найти микросхему для импульсного БП в узле. Для CAN нужна одна витая пара, например, голубая CAN-H, бело-голубая CAN-L; для питания "общий", например, зеленая и бело-зеленая, для питания "+24В", например, оранжевая и бело-оранжевая; коричневая пара в резерве (или RS-485 для потока данных).

возможность есть, третий день штробим стены, раскидываем электрику, эзернет, тв :)

Проблема в том, что витуху кинуть надо ко всем узлам, точное местоположение которых пока неизвестно, да и количество их тоже пока туманно. А вот как разместить в стене датчик температуры, сделав из него CAN узел и чтобы выглядело это все прилично для меня вообще загадка. По большому счету вся моя ветка этому и посвящена, как физически смонтировать CAN сеть. Пока вертится мысль пропустить по периметру всех помещений в районе плинтуса витую пару, оставив небольшие петли в районе предполагаемых узлов. Сегодня прикинул, общая длина получается более 100м.

[A. Fig Lee 0]

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

Сами модули наверное будут дороже. Можно по dgikey проверить. К CAN стоимость проводов надо добавить.

И! Провода то еще развести надо както..

[AlexandrY 3]

Да. Вместо CAN bus. Ну на CAN у Вас же "свой" протокол, правильно? И тут тоже.

Ему сказали доставить 100 байт в пункт Б, он доставил. По прилету откуда либо говорит "у меня есть 15 байт от Ц".

А что за данные это уже каждый как хочет пляшет.

В CANe разве не так?

 

Нет в CAN-е не так.

Во первых 100 байт в рабочем режиме там никто не посылает.

Обмен идет единичными переменными размером байт, максимум 8 или просто вписанными в ID пакета.

Датчики посылают или отдают температуру, вентили и переключатели принимают или отдают свое состояние.

 

Потом там нет адресатов, там есть транслируемые всем переменные. И сообщения от ошибках если кто-то из всех не смог принять.

 

А главное в CAN-е это мапинг. Это больше похоже на настройку DMA внутри микроконтроллера между разной периферией.

[typedef 0]

Нет в CAN-е не так.

Во первых 100 байт в рабочем режиме там никто не посылает.

Обмен идет единичными переменными размером байт, максимум 8 или просто вписанными в ID пакета.

Датчики посылают или отдают температуру, вентили и переключатели принимают или отдают свое состояние.

 

Потом там нет адресатов, там есть транслируемые всем переменные. И сообщения от ошибках если кто-то из всех не смог принять.

ну да, читаем мануал:

 

In the CAN protocol, the bus nodes do not have a specific address. Instead, the address information is contained in the identifiers of the transmitted messages, indicating the message content and the priority of the message.

 

все бы хорошо, да вот с прокладкой самой шины все как то кривовато выходит.

буду тянуть внизу за плинтусом, а там поглядим...

[adnega 11]

все бы хорошо, да вот с прокладкой самой шины все как то кривовато выходит.

буду тянуть внизу за плинтусом, а там поглядим...

Я на месте планируемых узлов установил коробки у пробросил с запасом витуху к ним.

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

В технологических нишах обычные DIN-рейки на которые можно навесить автоматы, контроллеры, блоки питания и т.п.

[typedef 0]

Я на месте планируемых узлов установил коробки у пробросил с запасом витуху к ним.

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

В технологических нишах обычные DIN-рейки на которые можно навесить автоматы, контроллеры, блоки питания и т.п.

у меня идея подобная, но везде коробок не навтыкаешь (жена не поймет).

возможно ли нарастить петлю путем соединителя в случае добавления узла в ранее непредусмотренном месте?