приветствую всех.

была поставлена следующая задача. есть прибор состоящий из двух блоков.
первый блок это измерительный который расположен на улице. второй блок это индикатор плюс 1 кнопка для листания параметров индикации который устанавливается в помещении. растояние между ними не более 100 метров будем считать по прямой видимости. Для каждого дома в поселке устанавливается отдельной свой индивидуальный прибор. растоянии между домами не более 100 метров. на краю поселка находится контрольный пунк с удалением не более 100 метров от крайнего прибора.
необходимо обеспечить считывания информации с блоков №1 каждого прибора в контрольном пунке. Необходимо выводить индикацию на блоке №2 только своего прибора. Необходимо обеспечить простое (горячее) подключении дополнительных контрольных пунктов при необходимости а также их безболезненное отключение.
Необходимо обеспечить автоматическую смену маршрута передачи данных от приборов при изменение внешних условий.
Блок №1 питается от сети. Блок №2 предположительно питается от батареки.
Скорость передачи данных от каждого прибора не более 2кбит. Допускается поочередное считывания информации с приборов в контрольном пункте.
Количество приборов в одной сети не более 10 тысяч. Время задержки передачи данных от наиболее удаленного прибора до контрольного пункта не более 10 сек.
Необходимо иметь возможность разделение нескольких сетей.
само устройство обеспечивающее передачу расположенные в 1 и 2-ом блоках в сумме должны быть не дороже 10$ в партии 10к штук.

все описанное по моему виденью относится к zigbee сети возможно по верх которой поставлен ip/tcp протоколы. опыта в zigbee нет потому есть сомнения начинать лм разработку основывась на этом протоколе.

Возможно уже все решено, возможно решено частично и требует доработки. Если кто решал подобные задачи прошу совета по данной задачи.

На правах рекламы. ATmega64RFR2 + LwMesh уложится в цену и условия задачи.

Из условий не ясно, но ZigBee может не подойти, так как максимальная глубина сети - 15 устройств.

TCP/IP поверх ZigBee тоже смысла не имеет.

интересно спасибо. поизучаю это направление.

Туча различных уровней(протоколов, стеков)
ANT, Bluetooth, Bluetooth low energy, RFID/NFC,PurePath Wireless audio, ZigBee, IEEE 802.15.4,ZigBee RF4CE, 6LoWPAN, Wi-Fi
все они обеспечивают передачу данных.
нет ли какой сводной даблицы по их характеристикам? Дабы не изучть каждый в отдельности а отсеять лишнее и копать уже в данном направлении.

Вот для примера очень дешевый чип CC2543 со встроенным процом 8051. Если его совместить с предложенным стеком LwMesh получится достаточно дешевое решение. (длаго LwMesh исходники открыты).

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

Я такой таблицы не видел, но из перечисленных только ZigBee и возможно 6LoWPAN могут обеспечить хотя бы 100 устройств в сети.

Это будет против лицензии на LwMesh. Русский способ решения проблемы всегда возможен, конечно.

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

итого.
после расмотрения всех вариантов реализация
данной задачи была признана не реальной за срок порядка 2-3х месяцев.
Были расмотрены
6LoWPAN - необходим нехилый роутер с линуксом
ZigBee - необходим концентратор
ATmega64RFR2 + LwMesh - был отвергнут сразу другими разработчиками (основание - т.к. атмел)
Wi-Fi - аналогично нужна точка подключения

в итоге задача трансформировалась
необходимо обеспечить связь блока 1 с блоком 2 прибора, все остальные требования (относящиеся к сетевой структуре) отпадают
высказано пожелание использовать
Bluetooth (Bluetooth low energy)




вот такой чип вроде нрмальный
LMX9830
http://www.ti.com/lit/ds/symlink/lmx9830.pdf
дороговато конечно 7$, но что делать.

вопрос такой если я поставлю его в блоке №1 то какой чип мне нужно будет ставить в блоке №2 дабы они нормально обменивались инфой?

Это зависит от того, где будете стек брать. Зачастую достаточно просто более мощного чипа типа ARM Cortex-M3/M4 с дофига ОЗУ.

Это как раз одна из проблем, которую я решал изобретая LwMesh. Большинство протоколов будут требовать центральное устройство.

Можете еще на SimpliciTI от TI посмотреть.

Хорошее основание, ну да ладно. Я сам не фанат AVR, но радио в этих чипах действительно лучшее из всех IEEE 802.15.4 на текущий момент.

И еще 10000 устройств без навороченной инфраструктуры не получить, что уже не $10.



При бюджете канала связи 80-90 дБ 100 метров на 2.4 ГГц даже по прямой видимости не получить.

В datasheet достаточно расписано:
page 40: LMX9830 acts only as slave
page 41: LMX9830 at both sides
page 42: LMX9830 acts as master for several slaves

Что делается то а Когда TI купила National эти два чипа (LMX9838 & LMX9830) висели в NRND, а теперь опять Active, что есть весьма гуд IMHO

А то, что дальность у LMX9830 не более 1.5 метров, никого не смущает? Он работает по классу два, а выходная мощность у него вообще 0dBm.
Он реально больше 1метра еле вытягивает. А внешний ретранслятор вешать на BT это не самая простая задачка.
Я бы посмотрел, как тут советовали, в сторону TI Chipcon трансиверов. Там кстати и штатные усилители предусмотрены.
И если уж вопросы тут задаете, оптимальнее всего купить готовые модули, реализовать систему на них, а уж потом разводить собственное решение на микросхеме.

Для построения интеллектуальной сети (автоматическая маршрутизация, ретрансляция, самовосстановление и т.д.) емкостью 100 узлов советую посмотреть вот на эти модули http://www.atoma.spb.ru/catalog/676/moduli...-868-i-ne50-433
Чабочая частота 433 или 868 МГц дает дальность связи до 1500 метров на открытом пространстве. Есть встроенные сетевой стек (бесплатный, в отличие от ZigBee), режимы пониженного энергопотребления. Но вот цена в 10$ вряд ли достижима даже в партии 10К штук. Недавно узнавал, там минимум около 15$ в больших партиях.

Bluetooth Low Energy - это конечно круто. Но если будете брать чип, то к нему надо будет где-то брать стек. У TI вроде есть какие-то стеки BT4.0 для своих чипов. Но под какие процессоры и какой степени готовности (надо ли будет что-то самому дописывать там), надо узнавать у представителей TI.
Есть еще хороший вариант взять модуль со встроенным стеком BT4.0. Типа вот такого http://www.mt-system.ru/catalog/bluetooth-modul-ble112
Будет, конечно, подороже. Но зато не надо ничего дорабатывать. И можно свои скрипты в модуль загружать.
BT4.0 пока поддерживается только Apple и вроде бы Samsung Galaxy. В ноутбуках и прочих планшетниках этот стандарт пока массово не используется. Поэтому для внедрения BT4.0 в персональный компьютер очень полезен может оказаться USB-донгл типа такого http://www.mt-system.ru/catalog/bluetooth-modul-bled112
Кстати, на этом же сайте есть интересная инфа по модулям WiFi со встроенным стеком http://www.mt-system.ru/catalog/modul-wizfi210
И по модулям BT2.0 тоже со встроенным стеком http://www.mt-system.ru/catalog/bluetooth-modul-wt12
Может, пригодится Вам.

ne50, BLE112 - больше 10$
все что больше 10$ не дадут применить как бы хорош небыл

итого после следующей итерации.
железо как бы устаканилось на уровне
2 * (сс1101 + сс1190) ~ 9.5$

по стекам
основая ветвь расматривается
simpliciti

смотрится еще на вариант
one-net (http://one-net.info/)

one-net ставится поверх cc110x

всем спасибо.
в итоге вышли на железо
CC430F5135IRGZ + CC430F6135IRGZ

стек
simpliciti

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

PS: Устройства номер1 это как я понимаю - счётчики (скорей всего электроэнергии) ?

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

У НЗиФ есть подобный счетчик - СЭБ-1ТМ.02. Интересно, что они используют?

А у нас есть счётчик, собирающийся в сети по ZigBee. И скоро будет кроме того ещё и с беспроводным пультом, как Вы описываете

Ну тогда желаю Вам удачи.

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

Добрый вечер!

Подскажите пожалуйста такой нюанс по поводу ZigBee.
К примеру у меня топология многоячейковая сеть, т.е. есть центральный координатор, маршрутизаторы и оконечные узлы.
Расположение элементов такое что некоторые из маршрутизаторов не могут напрямую обратиться к координатору т.к. не достают по дальности. Обратиться они могут только через промежуточные маршрутизаторы.
В описании ZigBee пишется что в таких сетях используется синхронный доступ.
У меня возник вопрос - координатор посылает сетевой сигнальный пакет с полезной информацией для остальных узлов и относительно него они вроде как должны синхронизироваться.
Однако не все узлы получают его напрямую, получается что к части узлов(которые он не может охватить по дальности) эти сигнальные пакеты идут через промежуточные маршрутизаторы и соответственно они сдвинуты по времени.
Вроде как уже неудобно по таким пакетам с задержкой синхронизироваться...
Или я что-то неправильно понял?
Как в таком случае осуществляется синхронизация?
В частности интересует как дальние узлы могут принимать участие в состязательном доступе к каналу и попадать четко в отведенные для этого тайм-слоты ведь начало этих тайм-слотов отсчитывается от синхропакета координатора, а до них синхропакеты доходят с задержкой...

Нет такого в описании ZigBee. Цитату можно?

Это похоже на описание Slotted CSMA, но он был опционален в ZigBee 2004 и был убран совсем из ZigBee PRO.

Промежуточные устройства являются сами по себе источниками синхропакетов (beacons). Это была попытка использовать все что только можно из IEEE 802.15.4, но попытка провалилась, так как это очень фигово масштабируется и микроконтроллеры не имеют достаточно ресурсов для попадания в свои слоты.

Я эту информацию почерпнул не из самого описания оригинального ZigBee, а из статьи "Программно-аппаратное обеспечение беспроводных сетей на основе технологии ZIGBEE/802.15.4" журнал "Электронные компоненты" №12,2004г. стр.81
Цитата:
'Функция синхронизированного доступа применяется в сетях с расширенной топологией, такой как "кластерное дерево" и "многоячейковая" сеть.'
Может я просто неправильно понял что-то...


Тоесть получается что сеть с древовидной топологией как-бы разбивается на части(на небольшие отдельные сети) с топологиями "звезда" где маршрутизатор находящийся в центре является как-бы координаторов в своей небольшой подсети и он формирует синхропакеты?
Чтобы исключить коллизии то делается временной сдвиг между синхропакетами соседних координаторов чтобы узлы находящиеся между ними могли нормально воспринять и один и второй синхропакет без наложения.
Я правильно понимаю суть?

Да, на момент публикации эта информация верна. Спецификация ZigBee PRO официально вышла в 2006. Там этого уже нет.


Да, между суперфреймами (синхропакет + слоты для всех устройств) есть промежуток по времени равный длине самого суперфрейма, чтобы роутеры могли туда свои посылки вставить. Очевидно это не работает на сильно сосредоточенных сетях, поэтому это никогда не работало на деле.

Спасибо большое за пояснения!

Скачал NXP ZipBee PRO Stack User Guide, но не нашел там ничего по поводу синхронизации в ZigBee PRO.
Не подскажете где можно найти какую-то информацию по этой теме?

Вас все еще интересует механизм 2004 года или что-то другое?
Как slotted режим на MAC уровне нужно читать IEEE 802.15.4, как оно именно использовалось в ZigBee тогда - это нужно искать тот стандарт, я понятия не имею есть-ли он еще в доступе где.

PS: Сорри, не прочитал, что PRO. Никакой синхронизации нет, устройство, которое хочет передать данные слушает эфир, если тихо - шлет.

Это называется CSMA/CA, описано все в том же IEEE 802.15.4-2006.

У меня вообще такая задача что есть сеть беспроводных датчиков на базе CC1101. Изначально она сделана под топологию звезда, т.е. у меня есть главный коммуникатор и много датчиков. Все датчики работают только через коммуникатор.
Проблема в том что довольно часто возникает ситуация когда не получается соблюсти такую топологию и часть датчиков оказываются вне зоны действия коммуникатора.
Потому у меня стоит задача переделать программное обеспечение с тем чтобы каждый датчик еще имел и функцию роутера, т.е. мог через себя удлинить радиус действия коммуникатора, пропустить через себя пакет к дальнему датчику.
Вот я и думаю пока как лучше к этому подойти. С точки зрения маршрутизации мне понравилась идея насчет LwMesh, которую Вы предложили в этой ветке.
Вопрос встал по поводу синхронизации всей сети.
Дело в том что в данный момент датчики имеют постоянное питание и потому можно не ломать голову насчет экономии энергии. Однако я понимаю что вскоре встанет задача относительно того чтобы и портативные датчики с батарейным питанием тоже могли выполнять роль ретрансляторов. А тут мне без синхронизации насколько я понимаю не обойтись, потому что много потребляют микросхемы в режиме приема.
Потому я и задавал изначально вопрос по поводу прохождения синхропакетов через роутеры, сдвиги по времени...я просто пытаюсь понять как можно синхронизировать систему.
Если питание постоянное то тут могу просто сделать как в PRO слушая эфир, но хотелось бы всетаки синхронизировать как-то все узлы.
Можете подсказать какие-то соображения по поводу всего этого?
Вообще асинхронный режим мне конечно удобнее всего, т.к. если какой-то из датчиков охранных дает сработку то пакет сразу пойдет к центральному блоку а не будет ждать своей очереди. Однако как быть с режимом ретрансляции в датчиках...без периодического просыпания и слушания эфира в момент потенциально возможной передачи не обойтись.

Как часто нужно просыпаться? Если периоды короткие (порядка мс), то это не просто. Нужно смотреть на архитектуру всей системы.

Если спать нужно по несколько часов, то в одном из профилей ZigBee есть режим спящих маршрутизаторов, вся сеть просыпается в заранее оговоренный момент времени, но маршрутизаторы просыпаются немного раньше. Насколько немного - определяется точность часов на устройствах.

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

Это очень тяжело сказать, нужно по месту смотреть. Хорошего универсального решения нет. Самое простое, наверное, если нужно отправлять только сигнал тревоги и редко, то можно при тревоге слать непрерывный поток сообщений. При просыпании все остальные устройства слушают в течении некоторого времени и если сообщение принято, то пытаются отправить его дальше.

Ну или изобретать систему синхронизации по времени. Все дети конкретного устройства засыпают по команде от родителя на определенное время. когда просыпаются опять ждут команды. Таким образом если кто-то не услышал команду, то он не спит следующие 100-200 мс. Если обнаружена тревога, то никто команд на сон не отдает и никто не спит, соответственно.

Александр, спасибо большое за советы!
По поводу засыпания по команде - действительно получается если возникла тревога то датчик начинает непрерывно слать тревогу пока не наступил момент когда проснутся окружающие датчики, главный из них принял тревожный пакет, команду на сон он не дает в таком случае и все(кроме датчика в тревоге) работают непрерывно на прием, ожидают возможных пакетов которые требуют ретрансляции.
Надо будет подумать в этом направлении и по какому признаку выбирать управляющие датчики(координаторы) - я так понимаю что нужно привязываться к уровням сигнала, т.к. эти дополнительные координаторы должны находиться одновременно и в зоне действия главного координатора и в то же время достаточно далеко друг от друга чтобы не мешать друг другу и охватывать те датчики которые не попадают в зону действия основного координатора.
В таком случае возможно и не нужно придумывать динамическую маршрутизацию а дальние(подчиненные) датчики работают напрямую на дополнительные маршрутизаторы т.к. они уже точно имеют выход на главный, т.е. путь однозначно правильный для пакета.
Т.е. впринципе получается главное чтобы датчики правильно определили свои роли, определили кто из них берет на себя функцию дополнительных маршрутизаторов, кто будет подчиненными, а дальше подчиненные уже напрямую работают через дополнительные маршрутизаторы.

Достаточно чтобы все кто слышит тревогу тоже начали слать пакеты с тревогой. Получается как бы broadcast и маршрутизация по сути не нужна.

Спасибо большое за помощь!

Добрый день!
Конечно, собрать сеть из 10000 устройств нереально. Но мы собирали сети ZigBee из 200-300 устройств. Сеть прекрасно работала. Модули на CC2530 плюс СС2591. На этих же модулях собирали сетки на несколько 10 устройств со стеком SimpliciTI. Есть модули и на CC430 с тем же SimpliciTI или 6LoWPAN. Для организации сети в 10000 нужно делать несколько подсетей (в зависимости от различных параметров на 100- 500 устройств). Задача вполне решаемая, если еще актуальна, можем помочь.