Интересуюсь литературой по организации WSN.Именно по организации ,
с конкретными расчетами цифрами и графиками.
Схемотехническая сторона в данный момент не интересует вообще.
Интересует практический подход к организации сети.
Есть масса "неудобных" вопросов которые конюктурщики от продавцов
пописывающие статейки обходят стороной.

А может Вы зададите конкретные примеры "неудобных" вопросов, которые Вас интересуют? Что именно Вы хотите рассчитать?

Если кратко то время работы оконечного устройства от батареи в реальных условиях.

Реальные условия:
WSN базирующаяся на зигби модулях.
Батарея 1000ма/час.
Ток TX=25ма , RX=25ма ,спящий режим 5мка.Токи приведены с учетом питания цпу.
Время выхода из спящего режима 10мс (нужно запускать кварц в цпу поскольку радиомодули с уартом )
20...30 оконечных устройств(датчики) с батарейным питанием в общей зоне радиовидимости.
Периодичность съема информации с датчиков , скажем раз в месяц.
Снимает информацию приезжий гастролер-координатор.
Время на съем информации со всех датчиков , ну скажем не более 2-3минут.
Наличие рядом 1-3 "чужих" зигби сетей время от времени возможно развлекающих мою сеть "пустыми разговорами".
И никаких хопов естественно!

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


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

Еще есть вопрос насчет реальной скорости обмена , но ответ на него я знаю и эти унылые цифры меня устраивают.

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

Вопросы эти не "не удобные", а просто на них невозможно ответить не применительно к конкретному сценарию работы.

Реальная скорость получается около 100 kbps в режиме точка-точка.

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

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

Вот именно про логику функционирования речь и идет.
Как известно разработчики зигби пытались достичь офигенной универсальности , в связи с чем логика работы очень тяжелая и как следствие требует много времени и соответственно энергии.
Никаких конкретных примеров с цифрами найти пока не удалось.
Производителям такие примеры кость поперек горла.
Половина разработчиков вообще не в теме.
Они на полном серьезе считают что радиомодуль в спящем режиме с ВЫКЛЮЧЕННЫМ приемником можно разбудить сигналом внешнего передатчика.

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

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

В том и смысл применения готовых решений что не надо быть специалистом.

По поводу координатора , предполагается что он присутствует при конфигурировании сети.
А затем основное время система обходится без него .Датчики иногда просыпаются не находят координатор ,говорят "ну и хрен с ним " и засыпают до следующего раза.

Зигби или не зигби? А пофиг!
Есть еще вариант от TI очень симпатичный , вполне возможно применение его.Но зигби вроде как более распространен поэтому пока ориентируемся на него.


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


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

Это не первая беспроводная сеть которыю я рожаю , были и раньше.
Но то была эпоха до зигби , вся логика работы была самописная.
Можно конечно использовать прикупить RFM22B (а может даже TRC105 из соображений экономии энергии) использовать старые наработки ,приспособить но это будет небыстро , негибко и безумно дорого.

Короче говоря ищу любые примеры полных расчетов подобных сетей с теоретическими выкладками.

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











А как часто надо просыпаться чтоб процесс опроса 20 несинхронизированных датчиков опросить за 2-3минуты?
А сколько времени займет установление связи с каждым.
А если помехи ?
Вопросы в многом статистические.
Поверхностно перелопатил кучу книжек и статеек англоязычных в основном.
Все грешат одной болезнью сначала долго жуют про примитивные (для меня как радиоинженера) вещи
потом резко переходят к выводу "все классно".
Каких-либо реально интересных цифр мало.

Есть несколько книжек с очень заманчивыми названиями которые не удалось скачать.Ищу.
Если есть что посоветовать из толковой литературы , советуйте.

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

Хочу сразу пояснить, я - один из разработчиков ZigBee стека компании Atmel, так что мое мнение может быть предвзято.

Кому известно? Изначально у ZigBee было одно приложение - Smart Energy, оно и остается приоритетом, все остальное прибилось после. Так что с универсальностью у ZigBee проблемы большие.

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

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

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

По моим данным, если исключить студентов, то модули применяют не из-за простоты, а из-за отсутствия необходимости сетрифицировать изделие.

ZigBee сети так не могут. Для координатора нет штатного способа вернуться в сеть + в общем случае сети нужен координатор для работы.

Лично я бы использовал single chip решение и свой простой протокол. С разработкой под ATmega1281RFA1 могу помочь советами и кодом, но решения от TI в конечном счете могут буть дешевле и доставабельнее.

Это и будет самая точная оценка.

У вас сети как таковой не будет, если вам нужно снимать данные раз в месяц, то и включайте эти модули раз в месяц.

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


Просыпатся нужно так часто чтобы:
1. Координатор не забыл про это устройство. Это определяется настройками сети.
2. Было удобно пользоваться. Период 1 час. Приехал человек на объект данные снять, а устройство только что проснулось и уже заснуло - ему нужно час ждать.

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