Итак, имею задумку, но для практической проверки просто не хватит модулей (((

Значит так, имею три модуля ZigBee900 от Meshnetics-a. Дальность порядка 4-5 ти км.

Хочу применить в системе мониторинга за обьектами и продукцией по территории предприятия...

Собираю разную статистику с датчиков и раз в сек отправляю на сервер, обьектов около 1000.

Проблема в том что 80% обьектов перемещается по всему предприятию, а это более 20 км. т.е. бардак будет полный.

свои три штуки верчу как хочу , все работает, вопрос как поведет себя сеть при больших обьемах перестройки, и в больших условиях перемещения.

Все устройства имеют стационарное питание, и предполагаю конфигурацию 1 координатор (Возможно и 10 координаторов, если это поможет). и остальные FFD.

Кто что думает?
просто покупать 100-ню дорогих модулей для проверки не хочется, а с ZigBee пока на Уважительных тонах (((

Если 20 км - протяженность площадки, то придется ставить стационарные раутеры - ретрансляторы. Помимо этого, сразу надо оценить "емкость канала" - на 1000 устройствах один раз в секунду передавать данные не получится, даже 1 байт - я Вас уверяю. Т.к., например, доступ к среде (процедура CSMA) будет занимать очень много времени... тем более, если вы используете низкоскоростные каналы и модуляции subgigahertz диапазона. Есть еще возможность разбить площадку и использовать в разных ее участках разные каналы - тем самым снизить загруженность эфира... но тогда будете иметь несколько точек выхода информации с площадки (равное количеству используемых каналов) и усложнение логики написанного поверх ZigBee стека приложения... Устройства, которые перемещаются по площадке правильнее сделать спящими end device-ами, хотя если у Вас нет проблем с питанием - тогда не обязательно. Что бы хоть как-то спрототипировать - нужно все же больше устройств... других вариантов я не вижу.

P.S. Вы немного путаетесь в терминологии - FFD (full functional device) и RFD (reduced functional device) - это термины IEEE802.15.4 (MAC & PHY layers of ZigBee), ZigBee оперирует понятиями Coordinator, Router & End Device.



В догонку: кстати, как там в Украине - у Вас разрешено использование этих частотных диапазонов? В России, например, нет...

868 диаппазон пока никто не отменял, даже в новой сетке частот (под цифровое ТВ заточеный).

Как я понял полно функциональный девайс является и роутером и оконечным устройством одновременно (тесты на трех штуках подтверждают). т.е. Mesh сеть.

Думал истользовать девайсы так чтобы они ретранслировали чужые пакеты и посылали свои...

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

1 сек . тоже не критично обойдусь и 1 минутой, но 20-ю байтами...

модуль, кстати, поддерживает скорость 1000 kbit/s - PSDU length of 127 octets. хотя я наверное не доконца понимаю эту PSDU )))

вот нашел хорошее описание принципа работы ZigBee http://www.kit-e.ru/assets/files/pdf/2005_04_144.pdf

буду изучать...

PSDU - это максимальная длина кадра в эфире с точки зрения PHY уровня. В эти 127 байт необходимо еще впихнуть заголовки всех верхних уровней (MAC, APS, NWK...). И того, в результате мы имеем на уровне приложения в несекъюрной сети длина полезного для пользователя payload равна примерно 84 байтам. Если использовать секьюрити, то и того меньше - 54 байта. Вам необходимы узлы для моделирования статической части сети (узлов ретрансляторов), которая покроет всю территорию и несколько узлов для моделирования перемещений. Узлы, которые будут перемещаться можно заставить отправлять данные гораздо более часто, чем это будет при большой реальной сети - что бы смоделировать нагрузку реальной сети. Таким образом Вы сможете оттестировать логику Вашего приложения в реальных условиях.

ZigBee для этой задачи выбран очень неудачно.

Есть некоторое непонимание того что ZigBee сеть это не mesh сеть, а сеть с возможностью mesh роутинга.
ZigBee сеть организуется по строгому иерархическому древовидному принципу.
И только после ее организации в виде дерева вожможна mesh маршрутизация.
Так вот характеристики вашей задачи: слишком мощные передатчики, большое количество узлов, невозможность планирования топологии, говорят о том, что задача для ZigBee пратически нереализуема.
Т.е. MAC уровень как-то можно использовать, но APS и NWK уровни ZigBee здесь сыграют злую шутку.

Имхо на сегодняшний день, Мешь уже хороше реализован в "Фирменном" стеке (Готовые модули).
За счет увеличения колва стационарных роутеров, и разбития сети на несколько зон со своими координаторами, ИМХО позволят максимально свести все к звездам, и мелким деревьям.

Передатчики БЕЗ усилителей. дальность только за счет частоты...

Мобильные девайсы наверное будут сконфигурированы как мобильные спящие... те которые будут очень мобильные возможно переведу на ЖСМ...

Если есть ИДЕИ и Знания как реализовать на Радио канале, то оставте координаты в ЛС, возможно посотрудничаем (Это для всех), проект на март- апрель 2009 года...

Вы, я вижу, не поняли в чем проблема.

Проблема в принципе создания сети.
Напомню мои изыскания на эту тему: http://aly.ogmis.lt/Articles/ZigBee/Direction-ZigBee.htm

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

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

Т.е. перед вами только один путь в такой задаче - делать свои модули.

В Zigbee 2007 это проблема вроде как решена за счет 3.6.1.7 Stochastic Address Assignment Mechanism
с последующим 3.6.1.9.2 Detecting Address Conflicts и 3.6.1.9.3 Resolving Address Conflicts при использовании PRO профиля.
К тому же этот профиль имеет nwkMaxDepth = 15.

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

Тем более, AlexandrY правильно заметил, что Ваша задача не относится к стандартным приложениям ZigBee и Вам придется вносить изменения, но только в рамках тех настроек и параметров, которые позволяет изменять стандарт. Внести более серьезные изменения не позволит закрытость модуля. Есть вариант сделать свой модуль и использовать стек от производителя, но даже открытость исходных кодов стека сильно не поможет, т.к. потребуется глубокое понимание как самого ZigBee, так и конкретной его программной реализации.


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

В описанном выше случае есть возможность обойтись считанным количеством раутеров, которые будут иметь стационарные позиции и не будут перемещаться... остальные подвижные устройства будут End Device-ами, которые при смене позиций будут инициировать новые rejoin-ы, если удалятся от своего родителя на столько, что перестанут его слышать. Ни о какой особой "глубине" речь тут не идет и меняться она (глубина) не будет.

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

Добавляем в устройство модуль GPS, (Уменьшение затрат на связь (при использовании GPRS) того стоит) и таблицу расположения стационарных роутеров.

Передача данных только в контрольных точках, или по событию.

разбиваем сеть на несколько ID (Если нужно)

При вхождении модуля в определенную зону устройство заранее знает к кому конектиться..

Возможен отказ даже от полного модуля а использование частей http://meshnetics.com/opensource/mac/ MeshNetics OpenMAC с чипом RF212 и Атмегой на которую есть порт MeshNetics eZeeNet SDK http://atmel.com/dyn/products/tools_card.a...p;family_id=676



Это тоже один из вариантов.
но девайсов как мне кажется многовато... Какое колличество роутер может через себя пропускать, или просто держать на себе?

А Вас не смущает увеличение стоимости устройства... если их "тысяча"? ИМХО - это совсем излишне.


Хочу Вас расстроить... на сколько я знаю ни OpenMAC, ни eZeeNet не поддерживают RF212... Его поддерживает только текущий стек от Meshnetics - BitCloud.


Т.к. раутер в ZigBee в себе содержит таблицы устройств, то действительно может возникнуть проблема с нехваткой RAM. Как отмечалось ранее, если у Вас вся площадь может быть покрыта стационарными раутерами, то очень разумно использовать просто MAC (IEEE802.15.4). MAC сам по себе не содержит никаких таблиц и не помнит, какие конкретно устройства были ассоциированы. Кроме того, это гораздо более простое ПО - содержит в себе меньше ошибок, а значит будет выше стабильность. Также могут быть реализованы и спящие устройства.

Вообще мы изначально хотели GPS ставить, так что нормально... а вот устройств, по последним переговорам, уже 2800

И площадь увеличивается до 120 на 20 км. ))) так что есть над чем подумать...

вот с 212 плохо ((( прийдется править с 230-й

Вообщем у вас наиболее приемлемый вариант - это применить транкинговую связь, как делается в крупных городах для объединений в единую систему планирования и управления трафика пасажирского транспорта и светофоров.
ZigBee здесь и рядом не лежало.

Дистанция работы ZigBee модулей даже на 800 МГц без усилителей составит не более 100-200 м, кто бы какие байки не расказывал о их дальнобойности.
Усилители добавят еще максимум 100-200 м
Т.е. глубина сети в реальных условиях сразу же перейдет все допустимые пределы.
Тем более, что на 868 МГц у ZigBee есть всего один канал!

Лежит на столе 3 модуля, 4 - 5 км. легко... + 863 to 870 MHz т.е. 3 кнала.. (На остнове 86rf212

Где почитать о транкинговых системах?

Можно ли создать транкинговую систему на 86rf212 ?

Купились на рекламу Atmela?
Сочувствую.

3-канала говорите.., ну тогда ZigBee точно отдыхает,это уже какой-то доморощенный стандарт.
4-е километра на 300 Кбит/сек при +10 dBm..., Покажите тогда антены и на какой высоте устанавливали.
Такие антены сводят идею ZigBee к абсурду.

86rf212 - дешевый широкополосный трансивер, на таких транкинговые системы не делают.
Ищите например по слову TETRA.
http://ru.wikipedia.org/wiki/TETRA

Subgigahertz (212-й) былобы лучше использовать... в этом диапазоне, очевидно, лучше проникновение сквозь препятствия и дальность значительно выше. Заявленная дальнсть в 4 - 5км действительно реальсность на открытой местности. А чем Вас свежий стек от Meshnetics не устраивает?


Антены соответствующие диапазону ставят - тут чудес не бывает - см по 15 длинной. А вообще, первый раз слышу про то, что идея ZigBee в размере антен оказывается...


На 868МГц скорости далеко не 300kbps, а ниже на порядок...

Я не против использования ZigBee в тех местах для которых она предназначалась, но и непротив нестандартных применений...

для передачи 1КБ раз в 5 мин, думаю прокатит.

Антены стандартные GSM900 (Не укороченые)

Алгоритм работы предполагаю следующий:

Координатор, с сетью стационарных роутеров, на крышах зданий, (Заодно контроль лифтов можно будет подтянуть)

Мобильные устройства, включают модуль и пытаются соединиться с роутером,

Соеденился, передал свой 1КБ.
Спросил нет-ли ему какой либо инфы.
Отсоеденился , уснул.

Вот еще модуль.
http://www.digi.com/products/wireless/poin...bee-pro-868.jsp
Уже даже есть из чего выбирать )))

Подскажет ли кто, усилитель для 868 диаппазона, для применения с 86RF212 ?

Нашел хорошую табличку:
ИМХО ZigBit900 Meshnetics немного переигрывает остальных...

Нажмите для просмотра прикрепленного файла

Читай про DSSS сам в шоке... ru.wikipedia.org/wiki/DSSS

может кто тут подскажет. Использую ziggbee с Bitcloud. Кооррдинатор отвечает каждому енддевайсу один раз в секунду. Как уменьшить это время ответа? За секунду надо передать кучу информации, а получается только одна посылка. Енддевайс шлет ему постоянно а отвечает он ровно один раз в секунду, елси 2-е енддевайса то 2-а раза в секунду.

Открываете файл configServer.h и настраиваете параметры под свою систему.
Там в частности вот что есть


End device должен полить чаще своего родителя.

пробовали уже меня его, не помогает , уменьшал его в 2-раза на координаторе, толку нету, ничего не меняется. Если в енддевайс убрать подтверждения приема с координатора, то он постоянно начинает слать посылки.
messageParams.txOptions.acknowledgedTransmission = 0; вот так ставишь и он постоянно передает, а координатор один фиг принимает один раз в секунду.

TETRA обеспечит дальность до 50 км от БС, но посылка телеметрии через SDS с периодом 1 секунда при количестве абонентов 1000 - невозможна - произойдет блокирование контрольного канала.