[metrolog 0]

Есть работающие ZigBee сети среднего размера (от десятка до сотен устройств), они передают трафик в режиме Many To One от множества медленно перемещающихся автономных устройств на сервер, а обратно воспринимают различные команды. В среднем на каждое устройство передается одно сообщение (полезная нагрузка несколько байт) в несколько секунд, все меры по распределению во времени трафика и контроля наличия связи с каждым устройством в реальном времени берет на себя протокол пользовательского уровня, реализованный на внешних МК. Ещё раз повторю, что это всё отлажено и давно работает, сетей таких есть много.

С недавнего времени участились случаи ухудшения качества связи, которые выражаются увеличением времени задержки и уменьшением вероятности доставки пакетов транспортного уровня до критических значений. Причина тому - появление в зоне действия сетей ZigBee активных сетей WiFi, работающих на тех же частотах. Искать свободные от WiFi каналы бесполезно, т.к. роутеры в режиме Auto встают на произвольные каналы, а не только на 1, 6 и 11 как в рекламных картинках... Работа WiFi оборудования регулированию не подлежит, т.е. по условиям игры оно периодически может появлятся на различных каналах и с этим нужно как-то справляться.

Решений я вижу два:

1) Накапливать статистику по Wi-Fi оборудованию в тех местах, где развертываются сети, и сформировать маску наиболее благоприятных каналов.

2) При возникновении вышеописанной ситуации автоматически переводить сеть на другой канал.

 

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

По первому пункту: какие программные и аппаратные средства для этого необходимы? Пока в своих экспериментах пользовал только NetStumbler для мониторинга ситуации с WiFi, InSSIDer к сожалению на моих машинах не пошел.

 

Самое интересное как быть со вторым пунктом? В описаниях на модули написано, что координатор в течение задаваемого времени при формировании сети осуществляет поиск самого чистого канала из доступных и там стартует сеть. По моим наблюдениям при старте сети, кроме редких случаев она стартует на прежнем канале независимо от его фактической занятости WiFi (в режиме реальной передачи данных), причем время старта сети зависит от установленного времени поиска. Может все каналы одинакого забиты на 100%?) Есть специальная команда по сбросу настроек радиотракта, вот она всегда приводит к изменению номера канала, однако канал меняется на случайный и нередки случаи, когда снова занимается реально занятый канал со всеми вытекающими...

Ещё интересны мнения на счет выработки критериев необходимости смены канала, есть ли команды возвращающие качество связи независимо от того как проложены маршруты в данный момент?

 

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

Изменено 25 сентября, 2012 пользователем metrolog

[proxi 0]

что либо чего-то неправильно понимаю,

ну да так есть, все ваше полупроводниковое хозяйство апроксимируется экспонентой ( а значит обилие гармоник в режиме большого синала ) при уровнях сигналов вокруг ( не канальная частота там разговор совсем другой) -40dBm у ваших LNA растет коэфициент шума, при -20dBm они начинает компресить, при -10dBm искажает данные FSK и затыкаются и это в лучшем случае, не считая многочисленных unwonted каналов и всяких пораженных точек о которых производители не любят распространяться

[metrolog 0]

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

 

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

Изменено 25 сентября, 2012 пользователем metrolog

[proxi 0]

значит -20dB уже спасает

К слову сказать я фигурально. Строго говоря конкретные цыфры зависят от конкретных условий но не очень существенно.

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

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

[Simeon 0]

Можно узнать какеи конкретно ZB-модули от DiGi вы используете?

[metrolog 0]

XB24-Z7WIT-004 и другие совместимые из этой же ленейки со всеми доступными 16 каналами.

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

[Simeon 0]

802.15.4 предусматривает процедуру энергетического сканирования на канале. В процессе этого сканирования выполняется определение пикового значения энергии в канале. Минимальное время сканирование 32мс (если память не изменяет). Можно использовать этот механизм для оценки среднего времени занятости канала помехами, если прокручивать энергетическое сканирование несколько раз. EM250 с родным стеком это позволяет делать.

 

Если не секрет, на каких объектах случаются проблемы с WiFi - торговые центры, выставочные повильоны или что-то еще???

[metrolog 0]

802.15.4 предусматривает процедуру энергетического сканирования на канале. В процессе этого сканирования выполняется определение пикового значения энергии в канале. Минимальное время сканирование 32мс (если память не изменяет). Можно использовать этот механизм для оценки среднего времени занятости канала помехами, если прокручивать энергетическое сканирование несколько раз. EM250 с родным стеком это позволяет делать.

 

Если не секрет, на каких объектах случаются проблемы с WiFi - торговые центры, выставочные повильоны или что-то еще???

 

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

Выводы следующие:

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

2) Отключение режима BOOST по документации уменьшает усиление на 1dB, на экспериментах это тоже никак не сказывается, разве что разброс автоматически-выбираемых каналов незначительно возрастает.

3) В общем в реальных условиях выбор канала работает правильно и всё соответствует теории как всегда)))

 

Но остались некоторые тонкости и нерешенные вопросы.

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

2) Какие критерии выработать для автоматического переразвертывания сети на другом канале и как это сделать максимально быстро в рамках используемых модулей.

 

Т.е. задача свелась к выбору оптимальных настроек и алгоритмов работы.

 

Сабжевые сети работают в самых разных общественных местах, в том числе и в перечисленных или по соседству.

[proxi 0]

еще одно соображение... в зависимости качества и солидности модуля не мешало бы вульгарно проверить опорник ( 30МГц ? или сколько там ) каким либо не инвазивным методом...типично допустимый расброс +- 10ppm или около того.

[uve 3]

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

Основная масса Wi-Fi сетей работают ЭМВ вертикальной поляризации. Можно значительно ослабить помехи использованием на центральном модуле вашей сети антенны кругового излучения с горизонтальной поляризацией. На моём опыте, такая замена помогала, правда развязывал я помехи двум сетям Wi-Fi на одной территории. Если будут трудности с покупкой такой антенны, пишите в личку - я Вам её изготовлю.

[metrolog 0]

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

 

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

 

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

 

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

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

 

еще одно соображение... в зависимости качества и солидности модуля не мешало бы вульгарно проверить опорник ( 30МГц ? или сколько там ) каким либо не инвазивным методом...типично допустимый расброс +- 10ppm или около того.

 

До опорника в этих модулях добраться достаточно сложно, нужно снимать экран, а он там достаточно качественно установлен. Эти модули расчитаны на широкий индустриальный диапазон рабочих температур, с опорником должно быть всё в порядке, хотя фактических данных нет. На счет солидности.. порядка 20 баксов за штуку у производителя)

Субъективно я не думаю, что это опорник, всеже на свободной частоте и мощность и чувствительность соответствуют заявленным, а если канал откровенно занят, то стабильность опорника врядли чего решит, хотя конечно для FSK это бесспорно важно, особено в таких пограничных ситуациях. Ради интереса попробую вскрыть убитый, но при любом результате измерений пока не ясно какие нужно предпринимать действия)

Изменено 29 сентября, 2012 пользователем metrolog

[Simeon 0]

На сайте www.zigbee.org поиском можно найти документ "ZigBee – WiFi Coexistence". Там среди прочего написано: "...two ZigBee nodes can be 30 m apart in free space if the WiFi interferer is at least 2 m apart and the frequency offset is greater or equal to 25 MHz".

 

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

[metrolog 0]

На сайте www.zigbee.org поиском можно найти документ "ZigBee – WiFi Coexistence". Там среди прочего написано: "...two ZigBee nodes can be 30 m apart in free space if the WiFi interferer is at least 2 m apart and the frequency offset is greater or equal to 25 MHz".

 

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

 

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

[alexvu 5]

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

[metrolog 0]

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

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

 

 

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