Технология 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-M0PSoC 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.comKinetis_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 содержимое пакетов не распознается поскольку оно передается зашифрованным.


(Кликнуть для увеличения)


Вид окна программы Wireshark с расшифровкой пакета объявления

Содержимое пакета Scan Request

Содержимое пакета Scan Responce

Содержимое пакета Connection Request с параметрами, определяющими скорость канала связи

Последовательность пакетов при установлении соединения


Приветствуются замечания, дополнения, исправления и возражения по поводу информации в этой статье.
Поделиться с друзьями
-->

Комментарии (26)


  1. IronHead
    04.10.2016 11:31
    +2

    Потрясающая статья, спасибо! Может сделаете еще одну статью с примерами кода, для тех кто только вливается?
    Ну то есть: BLE + термодатчик -> простенькое приложение на андроид с выводом данных на экран.


    1. doom369
      04.10.2016 11:40
      +1

      Ну то есть: BLE + термодатчик -> простенькое приложение на андроид с выводом данных на экран.

      Если цель быстро создать прототип, то рекомендую наш продукт — Blynk. Список БТ железа.


      1. IronHead
        04.10.2016 11:48

        Нет, цель изучить ble и его интеграцию в готовые продукты. То есть, есть у меня например самописное приложение и датчик температуры с bluetooth каналом связи на базе китайских HC-05 с самописным протоколом. Хотелось бы от этого уйти, так как и HC-05 нерационально вещает постоянно во времени, к тому же требует паринга устройств. Все таки в 21 веке живем, пора осваивать новые вещи.


        1. a_usoltsev
          04.10.2016 13:14
          +1

          Тогда берите BLE Pioner Kit от Cypress. У кипарисовцев отличная IDEшка с доками прямо там.
          А на youtube выложен мини-курс из порядка 12 уроков по 5 минут, пройдя который, Вы напишите прошивку+программу на IOS.
          Реально занимает выходные, чтобы разобраться(я не работал до того с cypress) с тем, как писать прошивки под эти МК и как на них поднимать БЛЕ.
          Сам кит+сниффер стоит 49$ или коколо того, что намного гуманнее, чем у NXP. + почти любая ножка выводится на любой пин(за некоторыми исключениями)-реально потом уложиться в двуслойку.
          У kinetis-ов с БЛЕ сложнее разобраться с наскоку. Имея неделю в запасе, я даже не стал пытаться, хотя большую часть своих проектов делаю именно на кинетисах.


          1. webself
            05.10.2016 08:18

            Этот комплект «out of stock» на сайте производителя…


  1. Danila24
    04.10.2016 13:15

    Хорошая стать. Спасибо. Почему в список контроллеров не вошёл http://toshiba.semicon-storage.com/ap-en/product/assp/applite/tz1000.html ?


    1. Indemsys
      04.10.2016 13:29

      Недоглядел.


      1. Danila24
        04.10.2016 13:32

        Хотелось бы просто небольшой обзор по нему увидеть, т.к. насколько я понял альтернатив ему нет в плане датчиков встроенных...


  1. hoary
    04.10.2016 13:15

    Dialog со своим SDK совсем как Штирлиц.
    Сначала надо получить доступ на сайт. У меня на подтверждение запроса ушла неделя, спамил в формы обратной связи и в твиттер. Потом только появляется возможность запросить доступ к SDK. При этом до того, что на SDK нужен отдельный доступ, ещё надо догадаться.


    1. kronos13
      04.10.2016 17:06

      Подскажите, пожалуйста, SDK поставляются монолитно? Исходники есть?


      1. hoary
        04.10.2016 17:08

        Только на днях получил доступ к нему, ещё руки не дошли.
        Вечером посмотрю и сообщу.


      1. hoary
        04.10.2016 21:37

        Особенностью SoC от Dialog-Semiconductors является расположение ble-стека во встроенном ROM, так что блобы — это уже часть идеологии использования.
        С самим SDK ещё не разобрался, но могу предоставить tree его папки.


  1. Jaromir
    04.10.2016 14:38
    +1

    > Технология Bluetooth энергично пробивает себе место в сфере интернета вещей

    Жаль, что wi-fi пробивает намного энергичнее на тех же частотах. Как-то было дело, выставляли zigbee-оборудование на выставке. В офисе всё идеально работало. На выставке не работало от слова «совсем».

    433 и 868 наше всё


    1. asdfghjk12
      04.10.2016 19:07
      -1

      Просто на выставке все каналы были заняты и зафлужены с других стендов. Увеличением мощности передатчика вы бы ничего не добились, потому что остальные тоже увеличили бы… На выставке вайфай-оборудования зигби работало бы гораздо лучше вайфая, вы бы тоже рекомендовали всем зигби как «более энергичное»?


      1. Jaromir
        05.10.2016 01:38

        Да я не спорю, что эти технологии могут уживаться вместе и вполне себе уживаются в квартирах у заказчиков. Но не всегда. В общественных местах как правило всё очень плохо если у вас автоматизация на 2.4 Ггц и слабее чем Wi-fi. При этом оборудование на других частотах работает вполне сносно. Хотя бывают и исключения, когда система ОПС в здании забивает весь 433 канал. В идеале устройства должны быть перенастраивыемые на разные частоты.

        > Просто на выставке все каналы были заняты

        Угу. Все три. Благо у нас в офисе мало соседей и Wi-fi на 5 Ггц. Иначе тоже работает с небольшими, но сбоями

        > На выставке вайфай-оборудования зигби работало бы гораздо лучше вайфая, вы бы тоже рекомендовали всем зигби как «более энергичное»?

        К сожалению, реальноcть такова, что одновременно нужно и то и другое


        1. Costic
          05.10.2016 20:36

          В вашем случае Bluetooth, думаю, лучше, т.к. умеет частоты менять.


  1. aronsky
    04.10.2016 15:28
    -1

    Вот это подход написанию статьи! Спасибо, было очень интересно почитать.


  1. Celtis
    04.10.2016 15:36

    Лучшие из имеющихся у меня BLE-маяков устойчиво работают в пределах одной комнаты.
    Пока BLE-Mesh не будет стандартизирована и совместима на уровне контроллеров различных производителей, о использовании BLE в качестве основного канала связи IoT говорить еще рано, несмотря на все преимущества.


  1. Balldir
    05.10.2016 07:29

    Согласно спецификации (Core Specification Supplement (CSS) v6 p. 10) UUID так же может быть 16 и 32 битным.
    Что б получить доступ к исходникам CSR нужно купить devkit. И даже в этом случае много чего будет библиотекой без исходников + sdk только для windows (но внутри gcc и 8051).


  1. lingvo
    05.10.2016 07:55
    +1

    Количество потерянных пакетов ужасает… Как же с такими данными данная технология сможет конкурировать в IoT?


  1. dernuss
    05.10.2016 09:11

    Странный девайс, огромный многоногий чип у которого видимо очень много ног не используется, из за этого большая плата…


  1. a_gusarov
    06.10.2016 09:16

    Дополню, потому что по Atmel-Microchip получился совсем куцый обзор.

    У Atmel кроме ATBTLC1000 есть еще ATSAMB11, который представляет собой тот же ATBTLC1000 + Cortex-M0 для пользовательского приложения. То есть в случае использования ATSAMB11 внешний контроллер не нужен. Кроме того, существуют не только эти чипы, но и модули на их основе.
    Для работы с BLE предоставляется библиотека в составе ASF. В открытом виде библиотека не предоставляется и не дается описание интерфейса работы с ATBTLC1000. Для B11 это не проблема (контроллер уже внутри и он Atmel'овский), а вот для того чтобы ATBTLC1000 подружить с «чужим» контроллером это серьезное препятствие. Также на Хабре была статья коллег про быстрый старт ATBTLC1000+SAML21

    Номенклатуру Microchip я знаю не очень хорошо, но чипы под BLE у них есть, причем со встроенным контроллером (IS1870/71).


  1. alexpic
    06.10.2016 17:11

    Стоило упомянуть о Nordic nRF52 и ST BlueNRG-1.
    Первый — пожалуй, самый продвинутый на сегодняшний день BLE SoC с 512 кБ флеши, Cortex-M4 и NFC на борту. А второй — это уже SoC с Cortex-M0 (в отличие от пробного BlueNRG), имеет очень хорошее потребление и низкую цену.


  1. wigneddoom
    06.10.2016 20:40

    У Nordic есть ещё NRF52 c Cortex-M4. Но этот их SoftDevice та ещё поделка.

    А у TI интресным решением является СС1350, там Cortex-M3 и поддержка как BLE, так и 868 МГц. TI-RTOS легко выкидыватется на мороз.


  1. onegray
    12.10.2016 19:16

    Спасибо, отличный обзор! Один за одним узнавал чипы, которые недавно искал и добавлял для себя в закладочки. Тоже для себя отметил MKW41, отличающийся максимальным количеством RAM, быстрым 16-бит ADC, и 12-бит DAC.
    Однако победу я бы отдал Nordic! Новый NRF52 хорош по набору фич, относительно большой набор инструментов, большое коммьюнити разработчиков и первоклассная поддержка. И еще… Просто оставлю ссылку: http://mynewt.incubator.apache.org/


    1. Indemsys
      12.10.2016 23:12

      Спасибо за наводку.
      Соглашусь что после выхода в mynewt полностью открытого в исходниках стека BLE 4.2, который поддерживает только Nordic-и тема сильно меняется.
      Придется похоже переходить на NRF52.