О. Пушкарев
Новости Электроники 3, 2008
Применение ZigBee-модулей с предустановленным программным обеспечением существенно сокращает время разработки ZigBee-сети. В статье рассмотрены практические аспекты работы с модулями XBee ZNet 2.5 (Series 2) компании Digi (бывшая компания MaxStream) в режиме API. Разработчикам пригодится в работе пример построения беспроводного датчика на базе модуля XBee ZNet 2.5 для сбора данных о температуре.
Модули ZigBee XBee ZNet 2.5 (Series 2) (рис. 1) являются законченными узлами, способными самостоятельно подключаться к сети с MESH-топологией и передавать данные, поступающие от внешнего хост-процессора.
Рис. 1. Модули XBee ZNet 2.5 (Series 2)
Благодаря встроенному ZigBee-стеку все операции по формированию сети, присоединению новых устройств, прокладке оптимальных маршрутов сообщений осуществляются автоматически, без участия внешнего микроконтроллера. Для передачи данных существует ограниченный набор простых управляющих команд, которые могут выполняться даже на самом недорогом 8-разрядном внешнем микроконтроллере. Модули XBee ZNet 2.5 могут выступать и как абсолютно самостоятельные узлы. В этом случае источником или приемником информации выступают имеющиеся на модуле периферийные узлы - порты ввода-вывода, АЦП и ЦАП. При использовании модуля без внешнего микроконтроллера прием или передача данных будет происходить под управлением команд, поступающих по эфиру от координатора или любого другого узла сети.
Работа в API-режиме
Подача команды ATND в режиме API и ответ от конечного устройства
Модули XBee могут работать в режиме управления с помощью AT-команд или в API-режиме [2,3]. Для управления с помощью внешнего микроконтроллера режим API гораздо более удобен, так как позволяет передавать и данные, и команды управления в общем потоке. Кроме того, некоторые возможности в режиме AT-команд просто недоступны. Например, послать по ZigBee-сети AT-команду удаленному модулю можно только в API-режиме. Работа с API-пакетами требует вычисления контрольных сумм, что не очень удобно при ручном формировании пакета в окне программы X-CTU (рис. 2а, б), однако не представляет большой сложности при управлении XBee-модулем с помощью внешнего микроконтроллера. Для практических экспериментов с API-фреймами оказалось более удобным использовать программу-терминал «Terminal v1.9b» [4], которая позволяет заранее составить набор отсылаемых API-фреймов в виде макросов и отсылать их нажатием одной кнопки.
Рис. 2а. Подача команды ATIS в режиме API и ответ от конечного
устройства
Рис. 2б. Примеры работы в API-режиме в программе X-CTU
Например, чтобы обнаружить все узлы сети, нужно составить фрейм AT-команды «ND» и отослать его с любого модуля сети. Ниже приведены API-фреймы, полученные на выходе UART модуля XBee ZNet 2.5, с которого был отправлен запрос на обнаружение всех узлов сети. Всего было получено 4 ответа, Как видно из приведенных ответов, в сети было обнаружено 2 роутера и 2 конечных узла.
Таблица 1. API-фреймы, полученные на выходе UART модуля XBee ZNet 2.5
Расшифровка структуры фрейма (для первой строки Табл. 1)
Ниже, в таблице 2, приведены дополнительные примеры API-фреймов, полученные от различных узлов в ZigBee-сети в различных реальных ситуациях.
Таблица 2. Примеры API-фреймов
Различные блоки фрейма выделены цветом и типом шрифта. Приведенные примеры могут быть полезными при изучении раздела, посвященному разделу по работе с API-фреймами в оригинальном описании производителя [5] (русскоязычный перевод данного документа доступен по запросу на [email protected]).
Практическая часть - делаем беспроводной датчик температуры
Мы воспользуемся возможностью отсылки API-команды для удаленного измерения температуры c помощью ZigBee-модуля. Схема измерительного модуля очень проста (рис. 3).
Рис. 3. Принципиальная схема температурного датчика
Измерение температуры производится с помощью аналогового датчика LM19, преобразующего температуру в диапазоне от -55 до 130°С в выходное напряжение, измеряемое с помощью АЦП модуля XBee ZNet 2.5 (Series 2). В связи с тем, что диапазон выходного напряжения LM19 (0,303...2,485 В) превышает максимальное измеряемое напряжение АЦП модуля (1,2 В), в схеме применен делитель напряжения на резисторах, понижающий выходное напряжение LM19 в 2 раза. Ток потребления LM19 составляет менее 10 мкА, поэтому датчик позволяет существенно экономить энергию батарей при работе ZigBee-модуля в спящем режиме. Измерительный модуль работает от 2 батарей типа "AA". Светодиод «HL1» отображает режим работы модуля: если он светится постоянно - модуль не присоединился к ZigBee-сети, если мигает 2 раза в секунду - произошло присоединение модуля к ZigBee-сети, редкие короткие вспышки - модуль находится в спящем режиме и периодически просыпается для запроса данных от родительского узла. В этом простом проекте применение встроенного АЦП и возможность удаленной отсылки команд позволило отказаться от применения внешнего микроконтроллера.
Для проверки работоспособности беспроводного датчика температуры развернем простейшую ZigBee-сеть на базе набора XB24-BPDK PBF. Во все XBee-модули, используемые в данном эксперименте (1 координатор и 1 роутер), должна быть загружена прошивка для работы в API-режиме. В качестве координатора и промежуточных роутеров могут использоваться модули, установленные на переходные платы, входящие в отладочный набор. Единственным нестандартным узлом будет наш датчик температуры, собранный на отдельной печатной плате (рис. 4).
Рис. 4. Температурный датчик на базе модуля XBee
Конечно, можно припаять термодатчик и 2 резистора делителя непосредственно к переходной плате из отладочного набора XB24-BPDK PBF. Однако это не рекомендуется делать по нескольким причинам. Во-первых, «лишние» элементы на переходной плате (драйвер RS-232, стабилизатор и пр.) не позволяют существенно снизить ток потребления от батареи в спящем режиме. Во-вторых, диапазон рабочих температур переходной платы производителем не нормируется и поэтому неясно, будет ли она нормально работать при температуре -40°С (предельная рабочая температура для модулей XBee ZNet 2.5).
До начала эксперимента необходимо сделать следующие настройки для XBee-модуля, который будет работать с нашим температурным датчиком:
1. Задать текстовое имя нашему удаленному модулю, например 12345 (команда NI).
2. Разрешить работу АЦП на выводе AD1 (команда D1=2).
Эти настройки удобно сделать с помощью закладки установок параметров в программе X-CTU.
В нашем тестовом проекте мы с помощью координатора, подключенного к ПК, будем отправлять запросы и получать пакеты, содержащие информацию о температуре удаленного узла. Для простейшего эксперимента лучше ограничиться сетью из 2 узлов - только координатора и нашего температурного датчика (работающего постоянно, т.е. не в спящем режиме). Удаленный модуль должен включаться после того, как координатор успешно стартовал (красный светодиод мигает один раз в секунду). При включении наш модуль с температурным датчиком самостоятельно подключится к координатору, на UART-выходе которого мы получим API-фрейм идентификации подключенного узла (рис. 5).
Рис. 5. API-фрейм с параметрами присоединенного узла сети
Данный фрейм мы также будем получать на выходе координатора при нажатии кнопки «Идентификация» на нашем температурном датчике.
Для отправки запроса на удаленное считывание значения АЦП (температуры), нам необходимо знать 64-разрядный уникальный и 16-разрядный сетевой адрес нашего удаленного узла. Эти значения можно взять из полученного сообщения о присоединении (00 13 A2 00 40 0A 0F 47 и 22 62 соответственно). Теперь мы можем сформировать API-пакет на удаленное считывание АЦП. Контрольную сумму для отправляемых пакетов в данном случае мы рассчитываем вручную. После отправки пакета мы получим ответный API-фрейм, содержащий значение напряжения АЦП, которое можно пересчитать в температуру (рис. 6).
Рис. 6. Ответный API-фрейм
Для преобразования аналого-цифровых данных в милливольты, используйте следующий алгоритм:
AD (мВ) = (значение ADIO/0x3FF)*1200 мВ [5]
Из полученного пакета мы видим, что значение АЦП = 02 8F (предпоследние 2 байта в API-фрейме), что в абсолютном исчислении составляет 0,768 В. С учетом делителя, напряжение на выходе LM19 было 0,891 х 2 = 1,536 В, что соответствует температуре 24,5°C. Формулы для пересчета выходного напряжения в значения температуры можно найти в документации на LM19.
По мере освоения API-команд можно добавлять в сеть новые узлы и тестировать передачу данных с ретрансляцией пакетов. Для минимизации энергопотребления модуль можно перевести в спящий режим (SM=4) с периодическим пробуждением по встроенному таймеру, например каждые 3 секунды (SP=0x12С, ST=0x1F4). В этом случае модуль будет периодически просыпаться, отсылая запрос «родительскому» узлу на проверку наличия информации для себя. При этом рекомендуется задать с некоторым запасом время хранения сообщений на родительском узле, например SP=0x2BC (7 секунд).
Пропускная способность и задержки
Разработка конечного устройства, которое будет использовать MESH-сеть для передачи данных, требует повышенного внимания разработчика на этапе определения параметров будущей сети. Например, одно из частых заблуждений относительно свойств ZigBee-сети - это завышенные представления о скорости передачи данных между узлами сети. Несмотря на относительно высокую фиксированную скорость передачи данных в радиоканале, равную 250 кБит/сек, реальная скорость может быть меньше на порядок! Для объяснения этого факта необходимо понимать логику сетевого взаимодействия узлов сети и не забывать про задержки на подтверждение пакетов. Кроме того, обработка данных на нижних уровнях стека также занимает определенное время. Производители с неохотой отвечают (если вообще отвечают) на вопросы о реальной скорости передачи данных в ZigBee-сети и возникающие задержки (latency). Обычный ответ сводится к туманной фразе что «эти параметры зависят от топологии сети и могут существенно варьироваться в зависимости от текущего уровня помех и напряженности трафика». Как бы нам нравился или не нравился подобный ответ, он отражает реальное положение дел - можно только грубо оценивать реальные параметры скорости передачи данных и возникающие задержки.
Исходя из практического опыта работы с модулями Digi (MaxStream) (рис. 1), можно говорить о средней скорости передачи данных порядка 4-5 кБайт/сек на уровне 802.15.4 (связь точка-точка, модули XBee 802.15.4 (Series 1), передача файла »100 кБайт, скорость UART 115200).
При работе в MESH-сети реальная скорость будет ниже, однако, с моей точки зрения, не это является критичным параметром, т.к. ZigBee-сети не предназначены для передачи больших объемов данных. В системах сбора информации с беспроводных датчиков объем полезных данных составляет десятки-сотни байт, что не предъявляет высоких требований к средней скорости передачи данных. Однако кроме скорости передачи, в сетях с MESH-топологией при передаче данные будут передаваться к узлу-получателю с переменной задержкой, которую необходимо учитывать в алгоритме поведения центрального узла сбора информации. Прежде всего, необходимо правильно выбирать величину времени ожидания ответа от удаленного узла, если пакет данных ретранслируется несколькими маршрутизаторами (роутерами). Грубо оценим максимальную задержку при следующих начальных условиях:
1. Допустим, что расстояние от координатора-отправителя до удаленного узла - 8 хопов (ретрансляций).
2. Время передачи пакета между двумя узлами (одна попытка) »30 мcек (точное значение зависит от конкретной программной реализации ZigBee-стека, MAC-уровня и микросхемы трансивера).
3. Число ретрансляций на уровне 802.15.4 - 3 (типовая фиксированная величина).
Таким образом, максимальное время передачи сообщения от одного узла к другому составляет »90 мc (30 мc х 3 попытки), столько же потребуется для передачи подтверждения (уровня приложения). В маршруте с 8 ретрансляциями максимальная задержка составит 8 x 90 x 2 = 1,44 секунд на одну попытку отправки сообщения. Разумеется, если мы отправили данные и не получили ответ, то можно попытаться повторить отправку, скажем 3 раза. Тогда наше приложение будет делать вывод о недоступности узла получателя (нет связи) только через примерно 5 секунд. Сама по себе эта цифра не большая и не малая - все зависит от того приложения, которое использует MESH-сеть для передачи данных. Для системы АСКУЭ, где пакеты данных передаются один раз в час, задержка в 5 секунд не является критической. В то же время, такая задержка будет совершенно неприемлемой, если нужно синхронно управлять комплексом светофоров на крупной транспортной развязке. Именно задержки при ретрансляции пакета являются главным ограничителем при построении «вытянутых» ZigBee-сетей. При количестве ретрансляций равном 100 максимальное время ожидания реакции удаленного узла будет достигать одной минуты! По-видимому, именно из этих соображений даже в самой последней спецификации ZigBee-Pro максимальная глубина ZigBee-сети ограничена 30 ретрансляциями. В модулях XBee ZNet 2.5 максимальное время ожидания ответов для команд ND (поиск узлов) и DN (прокладка маршрута) не может превышать 25 секунд (параметр NT). При использовании модулей XBee ZNet 2.5 глубина сети (число хопов) формально не ограничена, однако число ретрансляций при рассылке широковещательных сообщений не может быть более 15. Это означает, что конкретный узел просто не сможет обнаружить другие узлы, расположенные на расстоянии более 15 хопов от него.
Заключение
Практическое построение беспроводной сети на базе модулей XBee ZNet 2.5 не требует глубоких знаний ZigBee-спецификации и может быть выполнено в сжатые сроки разработчиком средней квалификации. Однако при разработке ZigBee-сетей с MESH-топологией необходимо понимать процедуры сетевого взаимодействия и учитывать реальную скорость передачи данных и возникающие задержки.
