[_Ivana 0]

Есть задача - сделать электронную систему обслуживания соревнований (бег/авто/мото/вело/ролики и т.п.) Это должна быть территориально распределенная сеть датчиков и устройств, развернутая на достаточно локальной территории (около 1-2 кв км.), управляющихся и посылающих сигналы в единый центр - датчики старта, финиша, стартовые ворота/светофоры, информационные табло и т.п. Количество периферийных устройств невелико - порядка 10-20. Система должна быть удобной в плане быстрой развертки на любой местности - лес, горы, центр мегаполиса и т.п. Объем передаваемых данных небольшой - запустить отсчет стартового светофора, отобразить пару строк на табло, принять данные от датчиков старта/финиша/промежуточных и т.п. Периферийные устройства будут на МК, центр - ноутбук.

 

Было принято решение использовать ZigBee. Сейчас изучаю стандарт и пару модулей от Telegesis. RFM был отклонен по причине низкой помехозащищенности - судьи общаются по рациям, которые глушат сигналы модулей даже на других соседних каналах. WiFi и т.п. также отклонили из-за низкой помехозащищенности и малого радиуса действия.

В связи с вышеперечисленным возникают многие вопросы. Например, стартовать периферийные устройства как конечные точки или как роутеры? Если послать команду на спящее конечное устройство - дойдет ли она до него при первом его пробуждении и надо ли внешне задавать период пробуждений для проверки поступивших команд? Что такое "мобильное конечное устройство" - MED? Можно ли будет в случае большой площади развертывания просто включить несколько дополнительных роутеров - и все будет работать точно так же? И много других вопросов, которые наверное тривиальны, но мне нужно в них разобраться (по понятным причинам :) ) Если у кого есть что сказать вообще и в принципе по теме, по выбору интерфейса связи и т.п., с удовольствием почитаю.

[jcxz 236]

Раз речь идёт о датчиках старта/финиша и фиксации времени, то как вы будете время синхронизировать на устройствах?

Если будете использовать ZigBee, то тогда нужен будет отдельный канал для времени (GPS к примеру) на каждый датчик.

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

Наверное это зависит от конкретного модуля. У CC2480/CC2530 насколько помню есть возможность задать.

Можно ли будет в случае большой площади развертывания просто включить несколько дополнительных роутеров - и все будет работать точно так же?

можно

Если исключить функцию синхронизации времени на устройствах, думаю - ZigBee вполне подойдёт.

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

[_Ivana 0]

Раз речь идёт о датчиках старта/финиша и фиксации времени, то как вы будете время синхронизировать на устройствах?

Если будете использовать ZigBee, то тогда нужен будет отдельный канал для времени (GPS к примеру) на каждый датчик.

Именно так и планируется сделать. Свой GPS модуль на каждый датчик и синхронизировать время по точному фронту начала секунды. Я не стал акцентировать на этом внимание, как и на сложностях с ложным срабатыванием / дребезгом оптических датчиков и т.п., хотел выделить только вопрос организации связи.

 

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

 

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

[egikforever 0]

Что такое "мобильное конечное устройство" - MED?

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

 

Было принято решение использовать ZigBee. Сейчас изучаю стандарт и пару модулей от Telegesis.

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

А почему выбрали модули Telegis? Довольное редкие модули.:)

Не смотрели на ZE51-2.4 от Telit?Эти модули сделаны на базе CC2530 и на них можно задать период пробуждения. Выходная мощность и чувствительность у них выше, а габариты этих модулей меньше.

Документация у телита гораздо более полная и с примерами приложений. И если вдруг решите перейти на субгигогерцовый диапазон, то у них pin-to-pin совместимые модули.

[_Ivana 0]

Спасибо, про MED уже прочитал. А почему Telegesis - их посоветовали, и есть три модуля в наличии для экспериментов. Хотя есть ещё XBee Pro-2 от DIGI, которые мне кстати так и не удалось связать в сеть с модулями Telegesis, я прочитал на форуме что есть сложности с построением сети из разных модулей и мы решим это проще - будем использовать модули одного производителя. И, кстати, систему придется писать так, чтобы можно было легко при желании сменить модули на другие - те же рекомендуемые вами ZE51-2.4 или другие, просто переписав драйвер модуля. Например, вдруг нас не устроит максимальная мощность/дальность связи и т.п. А это значит, в числе всего прочего, что, например, не придется разбираться с тем что такое Sink - поскольку это фишка исключительно Telegesis и в других модулях такого нет, также у нас периферийные модули не будут спать, поскольку оптические датчики на них все равно потребляют много энергии, значит отпадает проблема частоты опроса родительского узла. И вообще до сих пор не понятно, делать датчики конечными устройствами или роутерами, раз они все равно не будут спать. Так что от драйвера модулей потребуется только грамотная организация внутренней защищенной сети и посылка строки из центра в устройство и обратно. А этот минимум вроде должен быть в любых модулях. Хотя, есть также желание менять прошивку периферийных модулей посылая её по тому же ZigBee, непонятно в режиме Data mode есть ли контроль очередности и доставки посылок... Скорее всего нет, поэтому этим режимом пользоваться не будем, а будем слать малыми порциями по n байт последовательно получая подтверждение о приеме. В общем, вопросов действительно остается немало :)