Технология Bluetooth энергично пробивает себе место в сфере интернета вещей. Часть этой технологии, именуемая Bluetooth LE (Bluetooth Low Energy, она же Bluetooth Smart, она же BLE) прямо позиционирует себя как идеальный выбор для IoT (Internet of things). Трудно не согласится. BLE уже умеет маршрутизировать Internеt трафик, определять координаты в помещениях, подключать промышленные программируемые логические контроллеры, поддерживать WEB серверы, подключать весы, термометры, пульсометры, оксиметры, тонометры и массу других вещей. C BLE автоматически решается множество проблем присущих решениям с использованием Wi-Fi. Недолго осталось до момента, когда устройства с BLE смогут организовываться в MESH сети, по технологии схожей с ZigBee. Это уже отражено в спецификации Bluetooth 5.0
Поэтому при разработке своего IoT модуля я безусловное предпочтение отдал именно BLE в противоположность использованию Wi-Fi. Периферийную часть сети BLE я буду рассматривать на примере отладочного модуля K66BLEZ.
Здесь я хотел бы описать свой маршрут разработки от почти полного неведения о BLE до выпуска серийного изделия.
Знакомство с модулем K66BLEZ1 было начато в этих статьях:
Модуль универсального контроллера для интернета вещей. Вдыхаем жизнь
Модуль универсального контроллера для интернета вещей. Тестирование FatFs
Модуль универсального контроллера для интернета вещей. Основы программирования
Схема модуля
Репозитарий проекта
Модуль K66BLEZ в качестве приемо-передатчика BLE использует чип MKW40Z160 (48 MHz Cortex-M0+, 160 KB Flash, 20 KB RAM) производства копании NXP. Чип интересен тем, что наряду с BLE может работать и как приемо-передатчик сигналов стандарта 802.15.4. А стандарт 802.15.4, как известно, является несущей в технологии ZigBee. Непосредственно стек ZigBee для MKW40Z не выпущен, но уже предлагается фирмваре где 802.15.4 работает одновременно с BLE.
Схема части модуля с чипом BLE приведена ниже.
(Кликнуть для увеличения)
На смену чипу MKW40 уже есть чип MKW41 с объёмом RAM 128 кБ, объёмом Flash 512 кБ и поддержкой всех популярных протоколов: BLE 4.2, BLE Mesh, ZigBee, Thread, IPv6 6LoBLE. На новый чип пока нет открытой документации, но он обещает быть pin совместимым с MKW40.
BLE чип MKW40 на модуле соединяется с главным микроконтроллером MK66 интерфейсами SPI и I2C. Интерфейс I2C также соединяет чип с микросхемой зарядника. Главный канал связи реализован на интерфейсе SPI со битовой скоростью 6 Мбит/сек.
Отладка программы в чипе MKW40 может выполняться через SWD интерфейс с помощью JTAG адаптера и через отладочный интерфейс UART0 также выведенный на разъем отладчика X4.
Фирма NXP предоставляет более двух десятков примеров реализации различных приложений на чипе MKW40 среди которых: измерители давления, уровня глюкозы, температуры, датчики приближения, измерители частоты сердечных сокращений и т.д. Есть приложения для беспроводного UART и беспроводного загрузчика.
Мной был проделан глубокий рефакторинг фреймворка от NXP для этих чипов и созданы новые профили с демонстрационными программами на Windows PC не требующими отдельного адаптера на стороне PC. Но об этом позже.
Bluetooth LE трудно изучать. Причина — объёмная спецификация и большое количество её кратких пересказов в документации производителей, сразу начинающихся с непривычной терминологии. Поэтому начнём с неё.
Расшифровка и перевод терминов и сокращений, сленг.
Pairing — связывание (пайринг). Процесс создания парами BLE устройств одного или более совместных секретных ключей для последующего шифрования трафика. Пользователь оказывается вовлечён в этот процесс, когда система просит ввести PIN код.
Bonding — привязка(бондинг). Процесс сохранения совместных секретных ключей для использования при последующих доверительных соединениях пар BLE устройств.
Device authentication — проверка(аутентификация) на предмет того, что два устройства имеют одинаковые секретные ключи.
Advertising — Процесс широковещательной трансляции BLE устройством пакетов оповещений(адвертайсинг). В этих пакетах устройство сообщает своё имя и адрес, сообщает о сервисах, которые предоставляет, а также специальную информацию.
Scanning — Процесс приёма пакетов адвертайсинга от других BLE устройства при пассивном сканировании. При активном сканировании отсылка пакетов запросов на дополнительную информацию от устройств, работающих в режиме адвертайсинга.
Profile — профиль. Набор перечней функций, свойств, поведений и ролей для совокупности уровней определённого стека протоколов.
UUID — universally unique identifier. 128-и битный уникальный идентификатор атрибута.
BLE Host — хост. Часть программного обеспечения стека BLE выполняющаяся на главном процессоре, на котором выполняется и основное приложение либо выполняется функциональность моста к основному приложению. Хост содержит GAP, GATT, базу данных GATT, L2CA.
BLE Controller — контроллер. Часть программного обеспечения стека BLE выполняющаяся на радио-чипе Bluetooth.
HCI — Host Controller Interface. Протокол или API в зависимости от контекста для взаимодействия между BLE хостом и BLE контроллером.
GAP — Generic Access Profile, типовой профиль доступа. Обычно сразу же это называют layer (слой). Но это довольно странно называть профиль слоем. В исходниках это представлено как множество макросов, объявления и функций для установления и поддержания связи между BLE устройствами.
GATT — Generic Attribute Profile, типовой профиль атрибутов. В исходниках это набор функций для обмена данными между устройствами. Атрибуты — это единицы данных разных типов (строки, числа, структуры...) организованные в виде иерархического дерева узлами которого являются сервисы, характеристики, дескрипторы и т.д. Атрибут характеризуется тем, что имеет уникальный идентификатор UUID.
L2CA — Logical Link Control and Adaptation Layer. Программный слой с соответствующим протоколом ответственный за установления и поддержание логических каналов связи. Занимается планированием пересылок, контролем ошибок, сегментацией пакетов, управлением потоками, мультиплексированием пакетов между протоколами верхнего уровня. Является частью BLE хоста.
SMP — Security Manager Protocol. Протокол используемый для пайринга. Работает по выделенному каналу в L2CA.
LTK — Long-Term Key. Секретный ключ применяющийся при шифровании BLE трафика.
IRK — Identity Resolving Key. Ключ для расшифровки реального адреса устройства из запутанного публичного.
CSRK — Connection Signature Resolving Key. Ключ для подписи сообщений.
RAND — 64-х битная случайная величина, применяется для формирования LTK
EDIV — 16-и битная случайная величина, применяется для формирования LTK
MITM — man-in-the-middle. Попытка вскрыть третьей стороной совместный секретный ключ двух устройств внедряясь в канал связи между устройствами как промежуточное звено.
Message integrity — защита от подделки сообщений.
Фреймворк — так я здесь называю программное обеспечение в исходных текстах, призванное упростить создание приложений на определённой аппаратной платформе с определёнными библиотеками стеков коммуникационных протоколов. Включает обычно в себя BSP (board support package), HAL (hardware abstraction layer), OSA (OS abstraction layer), промежуточное программное обеспечение (middleware) такое как: менеджеры памяти, файловые системы, планировщики и таймеры и проч.
Анализ конкурирующих решений
При выборе чипа для BLE я провёл небольшой анализ предложений от наиболее известных производителей. Больше всего меня интересовал состав предлагаемого программного обеспечения, фреймворки и инструменты компиляции-сборки-отладки проектов под ядро ARM. Важным фактором была преемственность со средой IAR и фреймворком RTOS MQX которые используются при разработке приложения на главном процессоре модуля.
NORDIC SEMICONDUCTOR
предоставляет SDK для чипа nRF51822 с ядром Cortex-M0. Компилируется в IAR, KEIL, GCC. Стек BLE представлен монолитной библиотекой без исходных кодов под названием SoftDevice где реализованы все API: GAP, GATT, L2CA, HCI. Вокруг этой библиотеки строится фреймворк, с драйверами. Фреймворк поставляется с двумя RTOS: RL-ARM RTX от фирмы Keil, и FreeRTOS. Во фреймворке использована технология сериализации protobuf и отладки Segger RTT.
Кроме этого предлагается пакет nrf5 IoT SDK. В него входят исходники протоколов MQTT, COAP, TLS (взятый из проекта MBED), cJSON, lwip (свободный стек протоколов TCP/IPv4/IPv6), интерфейс сокетов, адаптер к IPv6. Есть и 6LoWPAN, но без исходных текстов.
Texas Instruments
на ARM делает только 2-х ядерные BLE чипы CC2640 (Cortex-M3 и Cortex-M0), но соответствующие спецификации Bluetooth 4.2.Для скачивания предоставляет SDK SimpleLink Bluetooth low energy Software Stack 2.2.0 Компилируется собственной средой разработки Code Composer Studio, а также в среде IAR. Поставляется с собственной RTOS TI-RTOS 2.16 и развитым фреймворком вокруг библиотек стека BLE. SDK как один из сценариев предполагает использование внешнего процессора приложений — Simple Application Processor (SAP). Сам же чип CC2640 именуют как Simple Network Processor (SNP). Между ними налаживается связь по протоколу, называемому Unified Network Processor Interface (NPI). На стороне CC2640 используется обязательно TI-RTOS, на стороне процессора SAP можно использовать RTOS по усмотрению. С SDK поставляются исходники протокола NPI как для стороны SAP, так и для стороны SNP. Это и есть технология SimpleLink.
Сам стек BLE разделён на 3-и прекомпилированные библиотеки без исходных текстов: хост, контроллер, HCI. Все три библиотеки работают только на процессоре Cortex-M3, который является частью чипа CC2640. Помимо изучения TI-RTOS, пользователю здесь понадобится изучить специальный программный механизм или протокол взаимодействия с BLE стеком называемый iCall.
Microchip-Atmel
производит Bluetooth LE чипы ATBTLC1000 на ядре Cortex-M0. Весь стек в чипах записан в ROM. Открытых инструментов для программирования данных чипов на сайте Atmel не обнаружено. Atmel вместо этого предлагает для взаимодействия с ATBTLC1000 использовать внешний микроконтроллер. Софт для внешнего микроконтроллера и примеры находятся в пакете Atmel Software Framework. Компилируется в среде Atmel Studio (оболочка для GCC) или в IAR.
Cypress Semiconductor Corp.
производит семейства программируемых BLE чипов на ядре Cortex-M0 — PSoC 4: PSoC 4XX8 и PRoC CYBL1XX7X поддерживающие спецификацию Bluetooth 4.2. Проекты для чипов создаются в специальной IDE PSoC Creator. Чипы от Cypress отличаются тем, что там нет готовой конфигурации периферии (UART, SPI, I2S, PWM и т.д.), её надо создавать из библиотечных элементов в схемном редакторе с добавлением программных библиотек. Это призвано обеспечить некую гибкость. Хотя и добавляет разработчику немалый объем работы. Сконфигурированный проект может компилироваться одним из тулчейнов: GCC, IAR, Keil. BLE там одна из библиотек. BLE стек поставляется в виде прекомпилированной монолитной библиотеки без исходных текстов совмещающей BLE хост, BLE контроллер и HCI. Однако фирма выложила исходники приложений для Android и iOS работающих с BLE.
Silicon Labs
производит EFR32 Blue Gecko Bluetooth Smart SoCs на ядре ARM Cortex-M4 поддерживающие спецификацию Bluetooth 4.2 Чипы типа EFR32BG1P332F256GMxx могут выдавать мощность до 19.5 dBm и совмещают отдельный радиоканал на 868 MHz с мощностью до 20 dBm и чувствительностью -121.4 dBm. Фишкой чипов Silicon Labs является огромный выбор альтернативных функций пинов и система, называемая Peripheral Reflex System (PRS). Хотя периферию и нельзя создать как у чипов от Cypress, но зато её подключение к пинам практически произвольное, наличие PRS даёт возможность взаимодействовать периферии между собой без привлечения процессора. Стек BLE от Silicon Labs способен принимать результаты генерации профилей программой Bluetooth Developer Studio речь о которой пойдёт ниже. Silicon Labs предлагает два стека Bluetooth. Один из них предназначен для модулей Bluegiga и поддерживает кроме BLE ещё и обычный Bluetooth. Второй стек соответствует спецификации 4.2 и только LE. BLE стек поставляется в виде монолитной прекомпилированной библиотеки без исходных текстов. Для варианта с внешним микроконтроллером предлагается последовательный протокол и API в исходниках. Компилироваться может как GCC, так в IAR и в Keil. Все выполняется в единой среде разработки Simplicity Studio V4. Сопровождающий стек фреймворк не поддержан RTOS. Но в исходниках Simplicity Studio можно найти такие перлы как Speex под 8 кбит/сек годный для передачи голоса по BLE и мощное оконное GUI от Segger.
STMicroelectronics
делает чипы сетевых контроллеров BlueNRG на базе Cortex-M0 содержащие стек BLE по спецификации Bluetooth 4.1
Сами чипы не программируются, но имеют последовательный интерфейс application command interface (ACI) через который с ними должен общаться внешний микроконтроллер. Для ACI разработан фреймворк, и он может входить как составная часть в фирменную среду разработки STM32Cube от ST.
CSR PLC
не делает BLE чипы на ARM Cortex, но заинтересовала своей реализацией MESH сети на Bluetooth модулях. Видео здесь. Выкладываются исходники различных BLE приложений для Android и iOS. Есть SDK.
Renesas
делает BLE чипы на своём 16-и битном ядре RL78. BLE стек выдаётся только премиум пользователям. Все своё — компилятор, RTOS, хост микроконтроллер. Но есть плагин к Bluetooth Developer Studio
Dialog Semiconductor
предлагают, как они утверждают, самые маленькие BLE чипы. Впрочем, чипы с Flash памятью DA14583 (остальные только с ROM) нельзя назвать самыми маленькими — 5x5 мм. Ядро Cortex-M0. Максимальная мощность 0 dBm. Поддержка спецификации Bluetooth 4.1. Чтобы получить SDK от компании надо зарегистрироваться и пройти проверку. Но с такими параметрами чипа я даже не стал пробовать получить SDK.
Итак, исходники MQTT, COAP, TLS, SPEEX, LwIP и проч. входящие в разные SDK нас мало интересуют, их и так можно свободно найти на Github без привязки к конкретным фреймворкам. Поддержка спецификации Bluetooth 4.2 мало что даёт поскольку на PC это пока использовать невозможно.
Нишевые RTOS вроде TI-RTOS или специальные планировщики нам затруднят освоение, стараемся избегать таких решений.
Я остался доволен что выбрал именно решение на Kinetis.
Чем интересен стек Bluetooth LE от NXP для семейства Kinetis.
Стек BLE для Kinetis, как и у других идёт в виде прекомпилированных библиотек. Вокруг этих библиотек выстроен многозадачный фреймворк включающий драйвера и слой аппаратной абстракции в исходных текстах независимый от операционной системы. Фреймворк может быть сконфигурирован для работы без операционной системы, а может и использовать оную. Сразу в поставке фреймворк адаптирован под FreeRTOS. Но взаимодействует он с FreeRTOS через вспомогательный набор функций, называемый слоем абстракции от операционной системы (OS abstraction, OSA).
Благодаря OSA вместо FreeRTOS можно подставить любую другую операционную систему, поддерживающую очереди сообщений, вытеснение, флаги и таймера. Например, RTOS MQX. Компилируется стек, как ни странно, только в среде IAR. К счастью в моём случае это не проблема.
Интереснее то что стек поделён на две библиотеки — BLE host и BLE controller. И библиотека BLE host может работать на другом чипе.
Взаимодействуют библиотеки друг с другом в этом случае через протокол HCI. Т.е. там, где другие производители придумывают ещё один коммуникационный протокол взаимодействия приложения на внешнем микроконтроллере со стеком BLE (вспомним SimpleLink), NXP предлагает стандартное решение. А главное, при таком подходе перемещая BLE host на более мощный внешний микроконтроллер мы значительно увеличиваем возможности нашей GATT базы данных и сервисов.
Кратко о BLE
Открытая версия спецификации Bluetooth версии 4.2 доступна здесь. Описание нижнего уровня BLE (уровень Controller) в неё входит как «Vol.6 Core System Package [Low Energy Controller volume]» со страницы 2544. Верхний уровень (уровень Host) с описанием ATT протокола и GATT профиля находится в части «vol.3 Core System Package [Host volume]» документа со страницы 1693.
Линейка используемых частот
(Кликнуть для увеличения)
Три частоты (на рисунке выше обозначены номерами каналов 37,38,39) выделены для широковещательных безадресных посылок, а остальные для передачи пакетов при установлении логических каналов связи между устройствами. Известной особенностью Bluetooth является то, что при передаче пакетов каждый следующий пакет передаётся на другой частоте выбираемой псевдослучайно из списка разрешённых.
Все данные в пакетах BLE могут шифроваться и удостоверяться. Также применяются динамическая случайная генерация адресов устройств и их идентификация с использование хеширования, т.е. перехватив в эфире адрес устройства мы не сможем его использовать дольше 15 мин, поскольку адрес за это время изменится по неизвестному для нас алгоритму.
Модули BLE могут работать как однонаправленные передатчики, т.е. без установки двунаправленного соединения, просто транслировать в эфир какие-то данные в форме пакетов объявлений, например, температуру. Для этого может использоваться тип данных в Advertising пакетах обозначенный как Manufacturer Specific Data. Компьютер или планшет могут принимать данные с сотен таких передатчиков без лишних предварительных действий по поиску, установлению соединения, вводу пинкода и проч.
Другой возможностью передать данные без установки канала связи является передача в режиме запрос-ответ (запрос — пакет ScanRequest, ответ модуля — пакет ScanResponce). Этим BLE существенно отличаются от Wi-Fi, где даже для простейшего термометра надо устанавливать соединение, отнимающее ресурсы роутера.
Стек протоколов BLE
Ниже на рисунке дано представление BLE как его видит программист микроконтроллеров. Стек BLE состоит из двух программных частей: Host и Controller. Программная часть Host занимается высокоуровневыми функциями организации и управления данными, подключениями, а Controller управляет физической периферией приёмопередатчика, работает с секретными ключами и занимается другими низкоуровневыми функциями. Названные части соединены программным интерфейсом HCI (Host Controller Interface). В реализации для ПК часть Host работает на компьютере, а часть Controller работает в аппаратном приемо-передатчике Bluetooth, а протокол HCI чаще всего передаётся по USB. В реализации на микроконтроллере обе части работают на одном чипе, а интерфейс HCI превращается просто в прямую передачу данных из задачи (программного модуля) хоста в задачу (программный модуль) контроллера и обратно.
По сути программист видит несколько наборов API работающих на уровне Host: называемые GATT, GAP, L2CA, SMP, HCI. С помощью GAP API устанавливается режим работы устройства — Central, Peripheral, Observer, Broadcaster и устанавливается соединение, когда нужно. А с помощью GATT API выполняется непосредственная передача и приём полезных данных и их разбор.
(Кликнуть для увеличения)
Большинство существующих устройств пока поддерживают версию BLE 4.1, несмотря на существование версии 4.2.
Все отличия версии 4.2 от предыдущей касаются именно улучшений в части BLE: увеличение скорости, возможность передачи IP протокола и HTTP трафика, усиление криптографической защиты и неопознаваемости для внешних наблюдателей.
Важной особенностью BLE по сравнению с Wi-Fi является специфицирование не только канала связи, но и самих прикладных приложений его использующих. Это называется профилями и сервисами. Профили с сервисами описывают роли устройств, предназначение данных, состав и формат данных, защиту данных, порядок, типы и события обмена, а не только то, как передаются данные. Это позволяет не изобретать велосипед из протоколов при разработке, например, датчика температуры тела или измерителя пульса. Спецификации уже даны, остаётся на стороне устройства только заполнить нужные поля для отправки результатов измерений. Клиенты таких устройств в виде смартфонов, планшетов, ПК или кухонной техники распознают эти данные автоматически и отобразят их или используют соответствующим образом. Все благодаря тому, что все производители руководствуются одними и теми же спецификациями BLE по поводу того, как представлены данные о температуре или пульсе и как с ними работать. Но остаётся место и для фантазии разработчика, так как профили имеют механизмы для расширений функциональности.
Ниже приведена грубая иерархия атрибутов в BLE устройстве.
(Кликнуть для увеличения)
Ниже чуть более подробное типовое дерево атрибутов. Это не полное дерево, большинство опущено поскольку заняло бы слишком много места. Цветами выделяются уровни дерева, каждый атрибут имеет уникальный номер — UUID. Запись стандартных номеров сокращается до 16-и бит. На данном рисунке все номера стандартные. Профили GAP и GATT тоже представлены как сервисы со своими стандартными характеристиками. У каждого сервиса может быть своя модель защиты и авторизация. Все дерево целиком в устройстве хранится как база данных называемая базой GATT, обычно в виде простой таблицы с перекрёстными ссылками.
У характеристик сервисов есть множество характеристик, как показано ниже. Здесь придётся извиниться за тавтологию, но в BLE действительно существует какой-то кризис терминологии. Одним словом, у характеристики принадлежащей сервису могут специфицироваться допуски на чтение, запись, необходимость извещений, подтверждений, подписей и проч.
BLE это серьёзная технология, поэтому многое сделано для обеспечения безопасности и максимальной формализации, что должно в свою очередь облегчить достижение совместимости.
Обмен данными между BLE устройствами производится записью и чтением значений характеристик. Потоковых каналов таких как TCP или UART здесь нет. А если устройства их имеют, то значит их организуют программные надстройки более высокого уровня.
Инструменты разработки
Средства разработки с предлагаемые сайтом Bluetooth Special Interest Group (Bluetooth SIG) — https://www.bluetooth.com/develop-with-bluetooth/developer-resources-tools
На сайте главной организации стандартизации — Bluetooth SIG предлагаются следующие полезные инструменты:
Bluetooth Developer Studio
Bluetooth Developer Studio — инструмент позволяющий правильно формировать и вставлять профили, сервисы, характеристики и дескрипторы в реализацию BLE устройства, т.е. создавать базу данных. Если купить дополнительный аппаратный Bluetooth адаптер за 99$ то программа позволяет перехватывать, расшифровывать и отображать пакеты протоколов Bluetooth. Есть в программе и возможности по отладке и тестированию создаваемых сервисов.
Поскольку в BLE утверждённые профили весьма детально описаны, то даже мелкие ошибки по поводу формата, нумерации, доступности и проч. в этих профилях вызовут проблемы совместимости. Но и для нестандартных профилей очень трудно обойтись без инструмента, точно конструирующего дерево сервисов, характеристик, дескрипторов с соблюдением всех спецификаций. Легко запутаться в названиях сервисов, характеристик, дескрипторов и их многобайтных уникальных номерах — UUID.
Результатом работы инструмента в частности являются сгенерированные XML файлы описывающие профили, сервисы, характеристики и дескрипторы в проекте пользователя. Эти XML файлы напрямую используются средой разработки Simplicity IDE от Silicon Labs для интеграции в embedded проекты для их чипов.
(Кликнуть для увеличения)
Другим результатом работы инструмента может быть исходный код для устройства работающий с базой данных BLE. Но для этого пользователю нужно написать свой плагин на JavaScript. Программа же предоставит плагину пользователя доступ к базе данных через специальное API на JavaScript.
Есть некоторое количество готовые плагинов, формирующих на выходе различные исходные текстовые файлы пригодные для компилирования в средах и программных фреймворках сторонних производителей.
Для решений на основе фреймворка NXP Kinetis KW40Z Connectivity Software плагинов пока нет.
Application accelerator
Application accelerator 2.1 — набор демонстрационных проектов с исходными текстами для разных операционных систем Android 6.0, Blackberry, iOS 9, Tizen 2.4 и Windows 10. Для Windows 10 проекты есть лишь для среды разработки Visual Studio под архитектуру Universal Windows Platform (UWP). Т.е. эти проект нельзя скомпилировать под фреймворками Windows Forms или WPF c .NET. А мосты для перевода обычных Windows приложений в UWP только создаются.
Надо отметить, что UWP даёт возможность размещать приложения в Windows Store, но при этом уже не создаётся простого исполняемого .exe файла, который можно просто скопировать и запустить. Первый запуск приложения UWP всегда сопровождается инсталляцией. Все это создаёт трудности разработчику. Да и функциональность демонстрационных проектов оставляет желать лучшего.
(Кликнуть для увеличения)
Выше приведён скриншот единственного демонстрационного приложения для Windows — BLEServiceBrowser.
Gateway Smart Satarter Kit
Gateway Smart Starter Kit — Проект шлюза BLE устройств к WEB серверу и сам WEB сервер реализующий пользовательский интерфейс для сети BLE устройств. Все реализовано в среде Node.js. Развёртывать предлагается на микрокомпьютере Raspberry Pi 2 model B с операционной системой Raspbian Jessie. Непосредственно для подключения Raspberry Pi к устройствам BLE используется интерфейс Bluetooth HCI сокетов к уровню L2CAP и USB HCI адаптер. Чтобы запустить под Windows надо установить специальный заменитель стандартного драйвера Bluetooth HCI. Решение работает на очень ограниченном числе типов аппаратных адаптеров в связи с ограниченность драйвера HCI.
Peryton
Среди коммерческих инструментов интересен анализатор BLE трафика от фирмы Perytons Программа анализатор работает ПК с Windows начиная с 7-й версии. Это важный момент, поскольку нативные драйвера BLE под Windows работают только начиная с 8-й версии. Анализатор работает с ограниченным списком аппаратных BLE адаптеров
При работе с адаптерами также есть ограничения в анализе, вызванные шифрованием трафика в BLE.
(Кликнуть для увеличения)
Однако даже от триальной версии программы можно получить много пользы. Программа сопровождается демонстрационными записями перехватов обмена реальных устройств. Эти записи после загрузки в программу дают подробнейшую картину работы всего стека протоколов BLE. Просмотр одного такого перехвата заменяет изучение всей спецификации Bluetooth.
Bus Hound
Если требуется просто как-то наблюдать за активностью между компьютером и BLE устройством и можно обойтись без подробного разбора протокола, то сгодится известный перехватчик трафика драйверов Windows под названием Bus Hound.
На скриншоте ниже виден поток принимаемых пакетов адвертайзинга. Хорошо заметна неравномерность интервалов времени приема пакетов. Это говорит о значительных потерях пакетов. Интервал адвертайзинга у BLE устройства был установлен равным 20 мс.
(Кликнуть для увеличения)
Скриншоте ниже показывает представление BLE устройства в окне Bus Hound после пайринга с PC. Для каждого сервиса устройства после пайринга появляется свой логический канала связи. Здесь же можно увидеть UUID устройства и сервисов.
Анализатор BLE траффика (сниффер) USB-KW40Z
Это инструмент из комплекта поддержки разработки на платформе Kinetis. Поэтому остановлюсь на нём подробнее.
Страница сниффера на сайте NXP.
Сниффер разработан фирмой NXP (вернее бывшей Freescale) и его можно недорого приобрести в популярных on-line магазинах радиодеталей: Mouser, Digi-Key, Farnell… Он предлагается фирмой NXP как инструмент наблюдения за радио-пакетами, посылаемыми BLE устройствами.
С помощью этого устройства можно изучать структуру пакетов, вести их запись в лог, анализировать плотность трафика.
Схема снифера открыта для изучения, однако программа микроконтроллера поставляется в виде двоичного файла.
Сниффер позволяет фильтровать пакеты по значению адреса.
Скачать программное обеспечение для PC к снифферу можно по следующему поисковому запросу на сайте www.nxp.com — Kinetis_Protocol_Analyzer_Adapter.exe
Поскольку сниффер кроме основной функции может быть ещё и отладочной платформой для разных приложений, то к нему прилагаются бинарные файлы базовой прошивки, с помощью которых можно восстановить функциональность снифера после экспериментов. Файлы идут с пакетом KW40Z Connectivity Software, который скачивается с сайта www.nxp.com по поисковому запросу KW40Z_Connectivity_Software. Файлы будут называться Sniffer_processing_core_usbkw40z_k22f.bin (для микроконтроллера MK22FN512 на плате сниффера) и Sniffer_radio_core_usbkw40z_kw40z.bin (для микроконтроллера MKW40Z на плате сниффера). Файлы программируются с помощью SWD отладчиков: JLink, STLink, OpenSDA…
Со стороны ПК устройство воспринимается как композитное USB устройство с одним COM портом и одним отладочным портом согласно спецификации, OpenSDA с прошивкой CMSIS-DAP. Таким образом в среде IAR можно свободно программировать и отлаживать чип MKW40Z снифера используя другой его чип MK22FN512 в качестве носителя функциональности отладочного адаптера. Но оба чипа на плате имеют стандартные разъёмы SWD для внешнего отладочного адаптера.
Сниффер не гарантирует приём всех пакетов, передающихся в эфире. Его легко зафлудить, после чего он перестаёт принимать какие-либо пакеты, поэтому рекомендуется включать фильтрацию по адресу, чтобы получать только пакеты от интересующего узла с достаточно редким трафиком.
Ниже показано окно программы анализатора пакетов. В окне включён перехват по всем трём каналам
(Кликнуть для увеличения)
При инсталляции ПО анализатора на ПК, оно создаёт виртуальный Ethernet адаптер, который конвертирует пакеты, снятые через виртуальный COM порт снифера в вид Ethernet пакетов. В моем случае такой виртуальный адаптер автоматически получил незатейливое название — Ethernet.
Чтобы увидеть пакеты дополнительно нужно инсталлировать программу сниффер Ethernet пакетов Wireshark.
Вид главного окна программы Wireshark во время наблюжения за трафиком. Wireshark подробно описывает все битовые поля пакетов протокола низкого уровня Link Layer (LE LL), однако после установки соединения между устройствами и начала рааботы протокола L2CAP содержимое пакетов не распознается поскольку оно передается зашифрованным.
(Кликнуть для увеличения)
Приветствуются замечания, дополнения, исправления и возражения по поводу информации в этой статье.
Автор: Indemsys
