ZigBee-модулі XBee: нові можливості

1. Мережевий протокол DigiMesh
2. Стек протоколів ZigBee-Pro
3. Управління модулем в режимі API
4. Бездротовий датчик температури
5. висновок
6. Інші статті на цю тему:

2008

Компанія Digi випустила нові версії популярних модулів XBee з встановленим програмним забезпеченням, що відповідає вимогам новітнього стандарту ZigBee Pro. Застосування модулів XBee спрощує і істотно скорочує час розробки систем передачі даних. У статті розглянуті нові можливості та практичні аспекти роботи з модулями XBee в режимі API. Наведено схему побудови датчика температури і описаний алгоритм отримання інформації з віддаленого вузла.

ZigBee-модулі XBee є готовими до застосування пристроями, здатними самостійно об'єднуватися в бездротові мережі з різною топологією - точка-точка, зірка, MESH (чарункова мережа). Підключений до мережі модуль забезпечує передачу даних на будь-який інший вузол мережі або на всі вузли одночасно. Передача даних здійснюється по інтерфейсу UART від зовнішнього хост-процесора, в якості якого може виступати персональний комп'ютер або найпростіший 8-розрядний мікроконтролер вартістю менше $ 1. Завдяки вбудованому ПО всі операції по формуванню мережі, приєднання нових пристроїв, прокладання оптимальних маршрутів повідомлень здійснюються автоматично, без участі зовнішнього мікроконтролера. На даний момент компанія Digi пропонує для модулів XBee кілька варіантів мережевих протоколів - це стандартні стеки ZigBee-2006, ZigBee Pro і фірмовий протокол DigiMesh.

Мережевий протокол DigiMesh

Мережевий протокол DigiMesh був випущений компанією Digi восени 2008 року у вигляді прошивок (firmware) для модулів XBee 802.15.4, побудованих на базі радіочастотної мікросхеми Freescale MC13213. Унікальною особливістю протоколу DigiMesh є можливість побудови мережі зі сплячими ретрансляторами (роутерами). У мережі DigiMesh немає координатора з виділеної роллю - кожен з вузлів мережі може взяти його функції на себе. Прокладка і відновлення маршрутів в даній мережі здійснюється автоматично. Подібна побудова гарантує проходження інформації при виході з ладу будь-якого вузла, так як в мережі DigiMesh немає «слабкої ланки», відмова якого міг би привести до повної непрацездатності системи. Структурна схема мережі DigiMesh приведена на рис. 2.

Переваги мережі DigiMesh в порівнянні з ZigBee полягають в наявності сплячих роутерів (в ZigBee сплячий режим можливий тільки для кінцевих пристроїв), більш простому процесі запуску і більшої гнучкості при розширенні мережі. Крім того, реалізація протоколу DigiMesh вимагає менших ресурсів пам'яті мікроконтролера. Можливість переведення роутерів в режим сну обумовлена ​​реалізованим механізмом тимчасової синхронізації всіх вузлів мережі. Як маяка виступає координатор - один з вузлів мережі, призначений розробником. Якщо він виходить з ладу, його функції починає виконувати будь-який інший вузол мережі. Протоколом передбачено спеціальні механізми «номінування» (Nomination) і «Виборів» (Election), які дозволяють вирішувати колізії, якщо відразу кілька вузлів мережі намагаються взяти на себе функції координатора. За допомогою команд конфігурації можна визначити вузли, які будуть мати переваги при «виборах» координатора. Підключення нових вузлів до мережі виконується таким чином - необхідно включити новий вузол і помістити його в зоні дії мережі. Після першого включення новий вузол буде постійно включений на прийом, чекаючи синхронизирующего пакета координатора. В отриманому широкомовному пакеті синхронізації міститься інформація про тимчасові параметри мережі - часи сну і неспання, що дозволяє новому вузлу перейти в режим сну до наступного сеансу синхронного обміну інформацією з іншими вузлами мережі.

Стек протоколів ZigBee-Pro

Компанія Digi випустила нове програмне забезпечення на базі стека протоколів EmberZNet PRO 3.1. Нове програмне забезпечення дозволяє будувати бездротові мережі, що відповідають вимогам специфікації ZigBee-2007 (ZigBee-Pro). Нове ПЗ (ZB firmware) можна завантажити з сайту Digi і завантажити за допомогою безкоштовної програми X-CTU в модулі XBee ZNet 2.5 (XBee Series 2). Залежно від функціонального призначення вузла і типу управління необхідно вибирати відповідну версію прошивки (таблиця).

Таблиця. Функціонал програмного забезпечення

Особливості ПО ZB версії 2x20:

• підтримка режимів API і AT;
• сплячі кінцеві пристрої з пробудженням по лінії виведення або таймером;
• збільшене число ретрансляцій для адресних передач (команда NH);
• розширений ідентифікатор 64 біт PAN ID (команди EI, OE);
• конфігурація профілю ZigBee (команда ZS);
• дистанційне конфігурування модулів в режимі API;
• доступ до рівня ZigBee APS layer за допомогою API-фрейма 0x11. Установка значень полів «APS endpoint», «cluster ID», «profile ID»;
• підтримка ZigBee-безпеки. Завдання ключів шифрування «Network» і «link».

Тим, хто розробляє додатки на базі стека протоколів ZNet 2.5, немає необхідності в обов'язковому порядку оновлювати програмне забезпечення. Компанія Digi продовжує випуск модулів XBee ZNet 2.5, заснованих на ПО EmberZNet 2.5. Слід враховувати, що модулі XBee з новою прошивкою (ZB) будуть несумісними з модулями XBee ZNet 2.5. Нова прошивка дозволяє створювати ZigBee-пристрої, які можуть взаємодіяти з ZigBee-вузлами будь-яких інших виробників, якщо останні відповідають версії специфікації ZigBee-Pro.

Управління модулем в режимі API

Для управління модулем XBee і передачі даних передбачено два режими взаємодії: за допомогою AT-команд (прозорий режим) або за допомогою структурованих пакетів (API-режим). У деяких випадках XBee-модулі можуть працювати як абсолютно самостійні вузли, без застосування зовнішнього керуючого пристрою. Наприклад, модуль може самостійно, в автоматичному режимі передавати по радіоканалу стан вхідних цифрових портів і відліки вбудованого АЦП. Управляти модулем, який працює без зовнішнього мікроконтролера, можна за допомогою команд, що передаються через ефір будь-яким іншим вузлом мережі. Режим AT-команд дуже простий для розуміння і оптимальний при передачі безперервних потоків даних в мережах з простою топологією. Недоліком AT-команд є повільний перехід з прозорого режиму передачі даних в режим прийому модулем команд управління. Режим API набагато більш гнучкий, особливо при управлінні за допомогою зовнішнього мікроконтролера, так як дозволяє передавати і дані, і команди управління в загальному потоці. Крім того, деякі можливості в режимі AT-команд просто недоступні. Наприклад, послати по ZigBee-мережі AT-команду віддаленого модулю можна тільки в API-режимі. Робота з API-пакетами вимагає обчислення контрольних сум, що не дуже зручно при ручному формуванні пакета в вікні програми X-CTU (рис. 3), однак не представляє великої складності при управлінні XBee-модулем за допомогою зовнішнього мікроконтролера.

В якості практичного прикладу розглянемо подачу звичайної AT-команди ND в API-режимі. Ця команда дозволяє виявити всі вузли в мережі. Команду ND можна подавати не тільки з координатора, а й з будь-якого іншого вузла мережі. При подачі цієї команди вузол відсилає широковещательное повідомлення, яке транслюється іншими вузлами мережі. У теорії, дане широковещательное повідомлення повинно досягти всіх вузлів мережі. При отриманні повідомлення вузол відправляє інформацію про себе - свій мережевий і 64-бітову адресу, тип пристрою (координатор, роутер або кінцевий пристрій), ім'я пристрою у вигляді текстового рядка (якщо задано) і деякі інші свої параметри. Для того щоб відповідні повідомлення не заважали один одному, кожен виявлений вузол робить випадкову затримку перед відсиланням відповіді. Тому при кожній відсилання команди ND відповіді від виявлених вузлів будуть надходити в різному порядку. Максимальний час затримки на відповідь вузла за замовчуванням становить 6 с. Нижче наведені API-фрейми, отримані на виході UART модуля XBee ZNet 2.5, з якого був відправлений запит на виявлення всіх вузлів в мережі. Всього було отримано чотири відповіді. Як видно з наведених відповідей, в мережі було виявлено два роутера і два кінцевих вузла.

Розберемо докладніше відсилає АТ-команду ND і отримані відповіді від вузлів мережі:

1. Відсилається API-фрейм «AT-команда ND» (дана сукупність електронних даних подається через UART на XBee-модуль):

Розшифровка структури подається API-фрейми:

2. Отримані відповіді (дана сукупність електронних даних видається на вихід UART XBee-модуля)

* Розшифровка структури фрейму відповіді (для першого рядка)

Бездротовий датчик температури

Як приклад роботи модуля XBee без використання вбудованого мікроконтролера розглянемо варіант побудови датчика температури. Для віддаленого вимірювання температури скористаємося можливістю віддаленої відсилання API-команди по ефіру. Схема вимірювального модуля досить проста і приведена на рис. 4. В якості вимірювача температури використаний аналоговий інтегральний датчик LM19. Мікросхема LM19 перетворює температуру в діапазоні від -55 до +130 ° С в вихідна напруга, яке можна виміряти за допомогою вбудованого в модуль XBee АЦП. У зв'язку з тим, що діапазон вихідної напруги LM19 (0,303-2,485 В) перевищує максимальне вимірюється напруга АЦП модуля (1,2 В), в схемі застосований дільник напруги на резисторах, понижуючий вихідна напруга LM19 в 2 рази. Розглянутий бездротової датчик (рис. 5) температури працює від двох батарей типу «AA». Світлодіод HL1 відображає режим роботи модуля: світиться постійно - модуль не долучився до ZigBee-мережі, блимає два рази в секунду - відбулося приєднання модуля до ZigBee-мережі.

Для перевірки працездатності датчика температури розгорнемо найпростішу ZigBee-мережу з двох вузлів - координатора і бездротового датчика. В якості координатора будемо використовувати XBee-модуль, встановлений на перехідну плату з комплекту отладочного набору XB24-BPDK і підключений до ПК за допомогою кабелю USB або RS-232. До початку експерименту необхідно зробити наступні настройки для XBee-модулів за допомогою закладки установок параметрів в програмі X-CTU:

1. XBee-модуль координатора повинен мати прошивку v. Тисяча сто сорок сім ZNET 2.5 COORDINATOR API.
2. XBee-модуль датчика температури повинен мати прошивку v. 1347 ZNET 2.5 ROUTER / END DEVICE API.
3. Задати текстове ім'я для XBee-модуля датчика температури, наприклад 12345 (команда NI).
4. Дозволити роботу АЦП для XBee-модуля датчика температури на виведення AD1 (команда D1 = 2).

У тестовому проекті будемо за допомогою координатора, підключеного до ПК, відправляти запити і отримувати пакети, що містять інформацію про температуру віддаленого вузла. Для найпростішого експерименту спочатку обмежимося найпростішої мережею з 2 вузлів - тільки координатор і температурний датчик. Датчик температури буде працювати постійно, тобто без використання сплячого режиму. Після включення XBee-модулів відбудеться автоматичне підключення температурного датчика до координатора. При цьому на виході UART координатора через закладку Terminal програми XCTU можна спостерігати API-фрейм ідентифікації з інформацією про параметри приєднаного вузла (рис. 7). Даний фрейм ми також будемо отримувати на виході координатора при натисканні кнопки «Ідентифікація» на температурному датчику.

Для відправлення запиту на віддалене зчитування значення АЦП (температури) необхідно знати 64-розрядний унікальний і 16-розрядний мережеву адресу віддаленого вузла. Ці значення можна взяти з отриманого повідомлення про приєднання (00 13 A2 00 40 0A 0F 47 і 22 62 відповідно). Тепер можна сформувати API-фрейм на віддалене зчитування АЦП. Контрольну суму для відправляються пакетів в даному випадку розраховуємо вручну. Після відправки пакета ми отримаємо відповідь API-фрейм (рис. 6), що містить значення напруги АЦП, яке можна перерахувати в температуру. Для перетворення аналого-цифрових даних в мілівольтах використовуйте наступний алгоритм:

З отриманого пакета бачимо, що значення АЦП = 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 с).

висновок

Пропоновані компанією Digi різні мережеві протоколи дозволяють будувати бездротові мережі, оптимізовані під конкретні вимоги користувача програми. Завдяки спрощеному інтерфейсу управління, практичне побудова бездротової мережі на базі модулів XBee не вимагає глибоких знань ZigBee-специфікації і може бути виконано в стислі терміни розробником середньої кваліфікації.

Завантажити статтю в форматі PDF

Інші статті на цю тему:

повідомити про помилку