- •2. Принципы построения беспроводных сетей на основе технологии ZigBee.
- •2.2. Стек протоколов ZigBee.
- •2.3. Три класса устройств.
- •2.4. Механизмы доступа в сеть.
- •2.5. Профили устройств сетей ZigBee.
- •2.6. Сетевые возможности ZigBee стека.
- •2.6. Аппаратные средства для построения ZigBee сетей.
- •2.6.1. Обзор трансиверов стандарта 802.15.4.
- •2.6.4 Программные решения стека ZigBee .
- •Глава 3. Описание и принципы работы модуля Xbee.
- •3.1. Структура модуля и его характеристики.
- •3.2. Режимы работы модуля.
- •3.3. Примеры подключения модуля к внешнему микроконтроллеру или пк.
- •3.4. Программирование модуля.
- •3.5. Адресация.
- •3.6. Обмен данными.
- •3.7. Контроль данных.
- •3.8. Работа в режиме ретрансляции.
- •3.9. Поддержка интерфейса программного приложения api.
- •Api- типы.
- •Формат api-specific Structure при посылке сообщения о статусе
- •Формат api-specific Structure при посылке ат команды.
- •3.10. Формат данных.
- •3.11. Поддержка api режима.
- •4. Разработка интерфейсной платы rs-232.
- •4.1. Структурная схема интерфейсной платы и описание её работы.
3.9. Поддержка интерфейса программного приложения api.
Поддержка уровня APIэто поддержка режима альтернативного режиму ретрансляции.APIэто такой режим работы модуля, когда возможно сетевое взаимодействие нескольких устройств.
В APIрежиме, все данные, входящие и исходящие из модуля, содержаться в специальном фрейме, который определяет операции или действия над ними вне модуля.
Фрейм данных (полученных по линии DI) включает в себя:
Фрейм переданных данных;
Командный фрейм.
Фрейм данных (отсылаемых по линии DO) включает в себя:
Фрейм RF-полученных данных;
Ответ на команду;
Уведомления (сброс, соединение, разъединение)
APIподдерживает альтернативные способы конфигурации модулей с возможностью маршрутизации данных в слое приложения хоста.
Приложение хоста может посылать фреймы данных в модуль, содержащие адрес и дополнительную информацию, а так же фреймы для определения адреса модуля без необходимости использования командного режима.
Модуль, в свою очередь, благодаря API, может посылать приложению фреймы данных, содержащие сообщения статуса, а так жеRSSIи дополнительную информацию по пакету (идентификация данных).
Таким образом, APIпозволяет следующее:
Передача данных в нескольких направлениях без входа в командный режим (широковещательные посылки);
Возможность получения информации об успешной передаче пакета или об ошибке;
Контроль целостности данных;
Определение адреса источника каждого полученного пакета;
Сетевое взаимодействие модулей не возможно без подключения интерфейса программного приложения API.
Применение параметров конфигурации модуля:
АР=0, модуль работает в режиме ретрансляции (этот параметр установлен по умолчанию).
AP=1,API оператор подключен
AP=2,APIоператор (с дополнительной характеристикой) подключен.
Применение параметров конфигурации модуля:
АР=0, модуль работает в режиме ретрансляции (этот параметр установлен по умолчанию).
AP=1,API оператор подключен
AP=2,APIоператор (с дополнительной характеристикой) подключен.
Структуры фреймов данных в APIрежиме .
Структура данных (АР=1) будет выглядеть следующий образом:
Структура данных (AP=2) будет выглядеть следующим образом:
Переходная (выходная) характеристика: при передаче или получении uartданных их необходимо сигнализировать, чтобы избежать пересечений при работе модулей.
Необходимые информативные байты:
0х7Е – фрейм ограничения
0х7D– потеря(смена)
0х11 – XON
0x13 – XOFF
Контрольная сумма:
Служит для проверки целостности данных.
Вычисляется: не включая фрейм ограничения и длина, прибавляя все байты, следующие за 8 битом результата и вычитая за 0хFF.
Api- типы.
Структура фрейма данных и APIspecificstructure.
cmdID-APIидентификатор показывает какое сообщение должно быть вcmdData. Каждый тип сообщения имеет свой идентификационное значение.(например, если посылаем команду, тоcmdID=0x08).
Данные передаются а обратном порядке.
Формат api-specific Structure при посылке сообщения о статусе