Модулі 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 мс (30 мс х 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-топологією необхідно розуміти процедури мережевої взаємодії і враховувати реальну швидкість передачі даних і виникають затримки.
Список літератури
- О. Пушкарьов. Системи бездротової передачі даних компанії MaxStream , Новини Електроніки, №2, 2006
- О. Пушкарьов. ZigBee-модулі Maxstream - нові можливості , Новини Електроніки, №2, 2007
- О. Пушкарьов. ZigBee-модулі XBee Series 2 з підтримкою Mesh-топології , Новини Електроніки, №16, 2007
- http://www.mikrocontroller.net/attachment/24594/term20041226.zip
Product Manual v1.x.2x - ZigBee Protocol
Отримання технічної інформації, замовлення зразків, поставка -
e-mail: [email protected]
Про компанію Digi Int.
Компанія Digi International, Міннеаполіс, США випускає бездротові пристрої, процесорні модулі та Ethernet-продукцію. Після придбання в 2007 році компанії Maxstream, в лінійку продукції увійшли ZigBee-модулі і конструктивно закінчені модеми для передачі даних в діапазонах частот 800 МГц ... 2,4 ГГц. Компанія робить простим підключення до мереж різнорідних пристроїв, розвиваючи продукти і технології доступні за ціною і легкі у використанні. Digi просуває свої продукти через глобальну сет ... читати далі