Bluetooth le device что это
Bluetooth с низким энергопотреблением
Bluetooth с низким энергопотреблением (LE) является спецификацией, определяющей протоколы для обнаружения и обмена данными между энергоэффективными устройствами. Обнаружение устройств выполняется с помощью протокола Generic Access Profile (GAP). После обнаружения обмен данными между устройствами выполняется с помощью протокола Generic Attribute (GATT). В этом разделе содержится краткий обзор Bluetooth с низким потреблением в приложениях UWP. Более подробные сведения о Bluetooth с низким энергопотреблением см. в разделе Основные характеристики Bluetooth версии 4.0, где представлена технология Bluetooth с низким энергопотреблением.
Роли GATT и GAP были представлены в Windows 10 версии 1703
Протоколы GATT и GAP можно внедрить в приложение UWP с помощью указанных ниже пространств имен.
Центральное и периферийное устройство
Две основные роли обнаружения называются центральное устройство и периферийное устройство. Как правило, Windows работает в режиме центрального устройства и подключается к различным периферийным устройствам.
Атрибуты
Распространенная аббревиатура, которую можно увидеть в API Windows Bluetooth, — это Generic Attribute (GATT). Профиль GATT определяет структуру данных и режимы работы, по которым взаимодействуют два устройства Bluetooth с низким энергопотреблением. Атрибут является основным блоком построения GATT. Основными типами атрибутов являются службы, характеристики и дескрипторы. Эти атрибуты действуют по-разному между клиентами и серверами, поэтому полезнее обсудить их взаимодействие в соответствующих разделах.
Служба частоты пульса выражена в форме API на сервере GATT
Клиент и сервер
После установления подключения устройство, которое содержит данные (обычно небольшой датчик IoT или носимое устройство), называется сервером. Устройство, которое использует данные для выполнения функций, называется клиентом. Например, компьютер под управлением Windows (клиент) считывает данные с монитора частоты пульса (сервер) для отслеживания оптимальных тренировок пользователя. Дополнительные сведения см. в разделах Клиент GATT и Сервер GATT.
Наблюдатели и издатели (маяки)
Кроме ролей центрального и периферийного устройств, существуют роли наблюдателя и вещателя. Вещатели обычно называются маяками, они не взаимодействуют через GATT, поскольку используют ограниченное пространство, предоставленное в пакете объявления для передачи данных. Аналогично наблюдатель не должен устанавливать подключения для получения данных, он сканирует ближайшие рекламные объявления. Чтобы настроить Windows для отслеживания ближайших рекламных объявлений, используйте класс BluetoothLEAdvertisementWatcher. Чтобы транслировать полезные данные маяка, используйте класс BluetoothLEAdvertisementPublisher. Дополнительные сведения см. в разделе Рекламные объявления.
Bluetooth LE (Low Energy) — что это такое?
Особенности и преимущества Bluetooth LE с низким энергопотреблением.
Bluetooth LE (Low Energy) — технология беспроводной связи, разработанная для передачи данных с низким энергопотреблением. BLE работает в том же диапазоне, что и обычный Bluetooth, но имеет другой принцип работы. Функции и отличия технологии подробнее рассмотрены в этой статье.
Технология Bluetooth LE
Технология Bluetooth Low Energy была создана для устройств, которым необходимо держать непрерывную связь между собой. Например, связь между смартфоном и наушниками. Протокол энергосбережения работает следующим образом:
Эта технология позволяет значительно снизить потребление энергии, поэтому она применяется в случаях, когда устройствам необходимо долгое время поддерживать передачу данных.
Устройства с Bluetooth LE
Bluetooth с низким энергопотреблением могут поддерживать следующие устройства:
Все вышеперечисленные устройства оснащены однорежимным модулем Bluetooth LE. Д_вухрежимные модули предназначены для смартфонов, ПК, планшетов и ноутбуков. Разделение по модулям характеризует и разделение ролей устройств в передаче данных:
Отличие Bluetooth LE от обычного Bluetooth
Технология Bluetooth LE была создана для современных беспроводных устройств, которые нуждаются в постоянном обмене данными. Основными потребностями гаджетов стали низкое энергопотребление, быстрое и стабильное соединение, а также безопасность. На этих пунктах и базируются отличия BLE от стандартного Bluetooth:
Как узнать, поддерживает ли устройство Bluetooth LE?
Мобильные устройства под управлением Android поддерживают BLE с версии 4.3. Чтобы узнать, работает ли конкретный смартфон со стандартом Bluetooth LE, можно воспользоваться одним из следующих способов:
Bluetooth Low Energy обеспечивает постоянную передачу небольших объемов данных, которые характерны для карманных гаджетов, фитнес-трекеров и других похожих устройств. Основное отличие протокола заключается в значительном энергосбережении и обеспечении долгосрочного, надежного и стабильного соединения.
Разработка IoT устройств с использованием Bluetooth LE
Технология 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 было начато в этих статьях:
Модуль 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 трудно изучать. Причина — объёмная спецификация и большое количество её кратких пересказов в документации производителей, сразу начинающихся с непривычной терминологии. Поэтому начнём с неё.
Расшифровка и перевод терминов и сокращений, сленг.
Анализ конкурирующих решений
При выборе чипа для BLE я провёл небольшой анализ предложений от наиболее известных производителей. Больше всего меня интересовал состав предлагаемого программного обеспечения, фреймворки и инструменты компиляции-сборки-отладки проектов под ядро ARM. Важным фактором была преемственность со средой IAR и фреймворком RTOS MQX которые используются при разработке приложения на главном процессоре модуля.
NORDIC SEMICONDUCTOR
Кроме этого предлагается пакет 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
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) нельзя назвать самыми маленькими — 5×5 мм. Ядро 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
Надо отметить, что 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 содержимое пакетов не распознается поскольку оно передается зашифрованным.