Wi-Fi блокирует сеть ZigBee на модулях Digi, должно же быть какое-то решение.. Опции

[metrolog]

Есть работающие ZigBee сети среднего размера (от десятка до сотен устройств), они передают трафик в режиме Many To One от множества медленно перемещающихся автономных устройств на сервер, а обратно воспринимают различные команды. В среднем на каждое устройство передается одно сообщение (полезная нагрузка несколько байт) в несколько секунд, все меры по распределению во времени трафика и контроля наличия связи с каждым устройством в реальном времени берет на себя протокол пользовательского уровня, реализованный на внешних МК. Ещё раз повторю, что это всё отлажено и давно работает, сетей таких есть много.
С недавнего времени участились случаи ухудшения качества связи, которые выражаются увеличением времени задержки и уменьшением вероятности доставки пакетов транспортного уровня до критических значений. Причина тому - появление в зоне действия сетей ZigBee активных сетей WiFi, работающих на тех же частотах. Искать свободные от WiFi каналы бесполезно, т.к. роутеры в режиме Auto встают на произвольные каналы, а не только на 1, 6 и 11 как в рекламных картинках... Работа WiFi оборудования регулированию не подлежит, т.е. по условиям игры оно периодически может появлятся на различных каналах и с этим нужно как-то справляться.
Решений я вижу два:
1) Накапливать статистику по Wi-Fi оборудованию в тех местах, где развертываются сети, и сформировать маску наиболее благоприятных каналов.
2) При возникновении вышеописанной ситуации автоматически переводить сеть на другой канал.

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

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

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

Сообщение отредактировал metrolog - Sep 25 2012, 18:35

[alexvu]

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

[metrolog]

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

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


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