La tecnología Bluetooth está rompiendo enérgicamente su lugar en Internet de las cosas. Parte de esta tecnología, llamada Bluetooth LE ( Bluetooth Low Energy , también conocido como Bluetooth Smart , también conocido como BLE ) se posiciona directamente como una opción ideal para IoT ( Internet de las cosas ). Difícil de estar en desacuerdo. BLE ya sabe cómo enrutar el tráfico de Internet, determinar las coordenadas en las habitaciones, conectar controladores lógicos programables industriales, admitir servidores WEB , conectar básculas, termómetros, monitores de frecuencia cardíaca, oxímetros, monitores de presión arterial y muchas otras cosas. C bleMuchos problemas inherentes a las soluciones de Wi-Fi se resuelven automáticamente . No mucho antes del momento en que los dispositivos con BLE se pueden organizar en la red MESH , utilizando una tecnología similar a ZigBee . Esto ya se refleja en la especificación Bluetooth 5.0.

Por lo tanto, al desarrollar mi módulo IoT , preferí incondicionalmente BLE en lugar de usar Wi-Fi . Consideraré la parte periférica de la red BLE usando el módulo de depuración K66BLEZ como ejemplo .

Aquí me gustaría describir mi ruta de desarrollo desde la ignorancia casi completa de BLE hasta la producción en serie.

La familiaridad con el módulo K66BLEZ1 se inició en estos artículos:

.
. FatFs
.

El módulo K66BLEZ utiliza el chip MKW40Z160 ( 48 MHz Cortex-M0 +, 160 KB Flash, 20 KB RAM ) producido por NXP como un transceptor BLE . El chip es interesante porque, junto con BLE, también puede funcionar como un transceptor de señales del estándar 802.15.4 . Y el estándar 802.15.4 , como saben, es el operador de la tecnología ZigBee . La pila ZigBee para el MKW40Z no se ha lanzado, pero ya se ofrece un firmware donde 802.15.4 funciona simultáneamente con BLE . El diagrama de la parte del módulo con el chip BLE se muestra a continuación.

(Click para ampliar)

En lugar del chip MKW40 ya tienen chip de MKW41 con un volumen de 128 KB de RAM, 512 capacidad KB Flash y soporte para todos los protocolos populares: BLE 4.2, ble de la malla, la ZigBee, hilo A, el IPv6 6LoBLE . Todavía no hay documentación abierta sobre el nuevo chip, pero promete ser compatible con pin MKW40.

El chip MKW40 BLE del módulo se conecta al microcontrolador principal MK66 con interfaces SPI e I2C. La interfaz I2C también conecta el chip al chip del cargador. El canal de comunicación principal se implementa en la interfaz SPI con una velocidad de bits de 6 Mbit / s.

La depuración del programa en el chip MKW40 se puede realizar a través de la interfaz SWD utilizando el adaptador JTAG y a través de la interfaz de depuración UART0 también se envía al conector del depurador X4.
NXP proporciona más de dos docenas de ejemplos de la implementación de varias aplicaciones en el chip MKW40, que incluyen: presión, glucosa, temperatura, sensores de proximidad, medidores de frecuencia cardíaca, etc. Existen aplicaciones para UART inalámbrico y cargador de arranque inalámbrico.

Hice una refactorización profunda del marco NXP para estos chips y creé nuevos perfiles con programas de demostración en PC con Windows que no requieren un adaptador separado en el lado de la PC. Pero más sobre eso más tarde.

Bluetooth LE es difícil de aprender. La razón es la voluminosa especificación y una gran cantidad de sus breves paráfrasis en la documentación de los fabricantes, comenzando inmediatamente con una terminología inusual. Entonces comencemos con eso.

Decodificación y traducción de términos y abreviaturas, argot.

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) : , , .

Al elegir un chip para BLE, realicé un pequeño análisis de las ofertas de los fabricantes más famosos. Sobre todo, estaba interesado en la composición del software propuesto, los marcos y las herramientas de compilación-ensamblaje-depuración para proyectos bajo el núcleo ARM. Un factor importante fue la continuidad con el entorno IAR y el marco RTOS MQX que se utilizan al desarrollar la aplicación en el procesador principal del módulo.

SEMICONDUCTOR NÓRDICO

proporciona un SDK para el chip nRF51822 con el núcleo Cortex - M0 . Compilado en IAR, KEIL, GCC. La pila BLE está representada por una biblioteca monolítica sin códigos fuente llamada SoftDevice donde se implementan todas las API: GAP, GATT, L2CA, HCI. Alrededor de esta biblioteca se construye un marco con controladores. El marco viene con dos RTOS: Keil's RL-ARM RTX y FreeRTOS . El marco utiliza la tecnología de serialización protobuf y la depuración de Segger RTT .

Además, se ofrece el nrf5 IoT SDK .. Incluye los códigos fuente de los protocolos MQTT, COAP, TLS (tomados del proyecto MBED), cJSON, lwip (pila de protocolos TCP / IPv4 / IPv6 libre), interfaz de socket, adaptador IPv6. También hay 6LoWPAN , pero sin código fuente.

Texas Instruments

en ARM solo produce chips BLE de 2 núcleos CC2640 ( Cortex-M3 y Cortex-M0 ), pero las especificaciones correspondientes son Bluetooth 4.2 . Para la descarga, proporciona la pila de software SDK SimpleLink Bluetooth de baja energía 2.2.0 , compilada por el propio entorno de desarrollo de Code Composer Studio, y en el entorno IAR. Viene con su propio RTOS TI-RTOS 2.16 y un marco desarrollado alrededor de las bibliotecas de la pila BLE. SDK como uno de los escenarios implica el uso de un procesador de aplicaciones externo: Simple Application Processor (SAP). El chip CC2640 en sí mismo se conoce como el procesador de red simple (SNP). Entre ellos, la comunicación se establece bajo un protocolo llamado Interfaz de procesador de red unificada(NPI) En el lado CC2640, TI-RTOS se usa necesariamente, en el lado del procesador SAP, puede usar RTOS a su discreción. El código fuente para el protocolo NPI se suministra con el SDK tanto para el lado de SAP como para el lado de SNP. Esta es la tecnología SimpleLink .

La pila BLE se divide en 3 bibliotecas precompiladas sin fuentes: host, controlador, HCI. Las tres bibliotecas solo funcionan en el procesador Cortex-M3, que es parte del chip CC2640. Además de estudiar TI-RTOS, el usuario deberá estudiar un mecanismo o protocolo de software especial para interactuar con la pila BLE llamada iCall.

Microchip-atmel

fabrica chips ATBTLC1000 Bluetooth LE en el núcleo Cortex-M0 . Toda la pila de chips está escrita en ROM. No se encontraron herramientas abiertas para programar estos chips en el sitio web de Atmel. En cambio, Atmel sugiere usar un microcontrolador externo para interactuar con el ATBTLC1000. El software para un microcontrolador externo y ejemplos se encuentran en Atmel Software Framework. Compila en Atmel Studio (shell para GCC) o en IAR.

Cypress Semiconductor Corp.

produce una familia de chips BLE programables en el núcleo Cortex-M0 : PSoC 4: PSoC 4XX8 y PRoC CYBL1XX7X que admiten la especificación Bluetooth 4.2 . Los proyectos para chips se crean en un IDE PSoC Creator especial. Los chips de Cypress difieren en que no hay una configuración periférica preparada (UART, SPI, I2S, PWM, etc.), debe crearse a partir de elementos de biblioteca en un editor de circuitos con la adición de bibliotecas de software. Esto está diseñado para proporcionar cierta flexibilidad. Aunque agrega mucho trabajo al desarrollador. Un proyecto configurado puede ser compilado por una de las cadenas de herramientas: GCC, IAR, Keil. BLE hay una de las bibliotecas. La pila BLE se entrega como una biblioteca monolítica precompilada sin códigos fuente que combinen el host BLE, el controlador BLE y la HCI. Sin embargo, la compañía publicó el código fuente para las aplicaciones de Android e iOS que trabajan con BLE.

Laboratorios de silicio

fabrica los SoC inteligentes Bluetooth Blue Gecko EFR32 basados en el núcleo ARM Cortex-M4 que admite la especificación Bluetooth 4.2 . Los chips de tipo EFR32BG1P332F256GMxx pueden suministrar energía hasta 19.5 dBm y combinar un canal de radio separado de 868 MHz con una potencia de hasta 20 dBm y sensibilidad -121.4 dBm. El chip de Silicon Labs es una gran selección de funciones de clavijas alternativas y un sistema llamado Sistema de reflejo periférico(PRS) Aunque la periferia no se puede crear como los chips Cypress, pero su conexión a los pines es casi arbitraria, la presencia de PRS permite interactuar entre sí sin involucrar a un procesador. Silicon Labs BLE Stack capaz de aceptar resultados de generación de perfil por Bluetooth Developer Studioque se discutirá a continuación. Silicon Labs ofrece dos pilas Bluetooth. Uno de ellos está diseñado para módulos Bluegiga y, además de BLE, también es compatible con Bluetooth normal. La segunda pila cumple con la especificación 4.2 y solo LE. La pila BLE se entrega como una biblioteca precompilada monolítica sin fuentes. Para la opción con un microcontrolador externo, se ofrecen un protocolo serie y API en las fuentes. GCC, IAR y Keil pueden compilar. Todo se hace en un único entorno de desarrollo Simplicity Studio V4 . El marco de pila que lo acompaña no es compatible con RTOS. Pero en el código fuente de Simplicity Studio puede encontrar perlas como Speex a 8 kbps adecuadas para transmitir voz sobre BLE y una potente GUI de ventana de Segger.

STMicroelectronics

hace chips de controlador de red BlueNRG basan en el Cortex-M0 que contiene especificación pila BLE para el Bluetooth 4.1 .

Los chips en sí no son programables, pero tienen una interfaz de comando de aplicación en serie (ACI) a través de la cual un microcontrolador externo debe comunicarse con ellos. Se ha desarrollado un marco para ACI y se puede incluir como parte del entorno de desarrollo patentado STM STC32Cube.

PLC CSR

no fabrica chips BLE en ARM Cortex, pero está interesado en su implementación de la red MESH en módulos Bluetooth . El video está aquí . Se presentan los códigos fuente de varias aplicaciones BLE para Android e iOS. Hay un SDK.

Renesas

fabrica chips BLE en su núcleo RL78 de 16 bits . La pila BLE solo se emite a usuarios premium. Todos ellos propios: compilador, RTOS, microcontrolador host. Pero hay un complemento para Bluetooth Developer Studio

Dialog Semiconductor

ofrecen, como afirman, los chips BLE más pequeños . Sin embargo, los chips con memoria Flash DA14583 (el resto son solo con ROM) no se pueden llamar los más pequeños: 5x5 mm. El núcleo de la Cortex-la M0 . Potencia máxima 0 dBm . Soporte para la especificación Bluetooth 4.1. Para obtener el SDK de la empresa, debe registrarse y aprobar el examen. Pero con tales parámetros de chip, ni siquiera intenté obtener un SDK.

Entonces, las fuentes de MQTT, COAP, TLS, SPEEX, LwIP, etc. aquellos en diferentes SDK son de poco interés para nosotros, se pueden encontrar libremente en Github sin vincularse a marcos específicos. El soporte para la especificación Bluetooth 4.2 hace poco, ya que aún no es posible usarlo en una PC.

Nichos de RTOS como TI-RTOS o programadores especiales nos dificultarán dominar, tratamos de evitar tales decisiones.

Me complació haber elegido la solución en Kinetis.

Lo interesante de la pila NXP Bluetooth LE para la familia Kinetis.

La pila BLE para Kinetis, como otras, viene en forma de bibliotecas precompiladas. Alrededor de estas bibliotecas, se construye un marco multitarea que incluye controladores y una capa de abstracción de hardware en el código fuente independiente del sistema operativo. El marco se puede configurar para funcionar sin un sistema operativo, o se puede utilizar. Inmediatamente en la entrega, el marco está adaptado para FreeRTOS. Pero interactúa con FreeRTOS a través de un conjunto auxiliar de funciones llamado capa de abstracción del sistema operativo (abstracción del sistema operativo, OSA).

Gracias a OSA, en lugar de FreeRTOS, puede sustituir cualquier otro sistema operativo que admita colas de mensajes, preferencia, indicadores y temporizadores. Por ejemplo, RTOS MQX. Stack compila, curiosamente, solo en el entorno IAR. Afortunadamente, en mi caso, esto no es un problema.

Es más interesante que la pila se divida en dos bibliotecas: host BLE y controlador BLE. Y la biblioteca de host BLE puede funcionar en otro chip.

Las bibliotecas interactúan entre sí en este caso a través del protocolo HCI. Es decir donde otros fabricantes proponen otro protocolo de comunicación para la interacción de la aplicación en el microcontrolador externo con la pila BLE (recuerde SimpleLink), NXP ofrece una solución estándar. Y lo más importante, con este enfoque, al mover el host BLE a un microcontrolador externo más potente, aumentamos significativamente las capacidades de nuestra base de datos y servicios GATT.

Brevemente sobre BLE

Una especificación abierta de Bluetooth versión 4.2 está disponible aquí . La descripción del nivel BLE inferior (nivel del controlador ) se incluye en él como "Vol.6 Core System Package [volumen de controlador de baja energía]" de la página 2544. El nivel superior (nivel del host ) con una descripción del protocolo ATT y el perfil GATT se encuentra en el "vol.3 Paquete del sistema central [Volumen de host] ”del documento de la página 1693.

Rango de frecuencia utilizado

(Haga clic para ampliar)

Tres frecuencias (en la figura anterior se indican mediante los números de canal 37.38.39) se asignan a paquetes de difusión sin dirección, y el resto para la transmisión de paquetes cuando se establecen canales de comunicación lógica entre dispositivos. Una característica bien conocida de Bluetooth es que cuando se transmiten paquetes, cada paquete subsiguiente se transmite a una frecuencia diferente, seleccionada de forma seudoaleatoria de la lista de permitidos.

Todos los datos en paquetes BLE se pueden cifrar y autenticar. También se utiliza la generación aleatoria dinámica de direcciones de dispositivos y su identificación mediante hashing, es decir Habiendo interceptado la dirección del dispositivo en el aire, no podremos usarla durante más de 15 minutos, porque la dirección cambiará de acuerdo con un algoritmo desconocido para nosotros durante este tiempo.

Los módulos BLE pueden funcionar como transmisores unidireccionales, es decir sin establecer una conexión bidireccional, simplemente transmita algunos datos en forma de paquetes de publicidad, por ejemplo, temperatura. Para esto se puede utilizar el tipo de datos en los paquetes de publicidad designados como Datos específicos del fabricante . Una computadora o tableta puede recibir datos de cientos de dichos transmisores sin pasos preliminares innecesarios para buscar, establecer una conexión, ingresar un código PIN, etc.
Otra posibilidad para transferir datos sin configurar un canal de comunicación es la transmisión en el modo solicitud-respuesta (la solicitud es el paquete ScanRequest , la respuesta del módulo es el paquete ScanResponce ). Este BLE es significativamente diferente del Wi-Fi, donde incluso para el termómetro más simple es necesario establecer una conexión que tome los recursos del enrutador.

Pila de protocolo BLE

La siguiente figura muestra BLE como lo ve un programador de microcontroladores. La pila BLE consta de dos partes de software: Host y Controlador . El software host se ocupa de las funciones de alto nivel de organización y gestión de datos, conexiones, y el Controlador gestiona la periferia física del transceptor, trabaja con claves secretas y se ocupa de otras funciones de bajo nivel. Las partes nombradas están conectadas por la interfaz de software HCI ( Host Controller Interface ). En una implementación de PC, la parte del Host se ejecuta en una computadora y la parte del Controlador se ejecuta en un transceptor de hardwareBluetooth , y el protocolo HCI se transmite con mayor frecuencia a través de USB . En la implementación en el microcontrolador, ambas partes operan en el mismo chip, y la interfaz HCI simplemente se convierte en transferencia directa de datos desde la tarea del host (módulo de software) a la tarea del controlador (módulo de software) y viceversa.
De hecho, el programador ve varios conjuntos de API que funcionan en el nivel del host : llamados GATT , GAP, L2CA, SMP, HCI . Con la API de GAP , se establece el modo de funcionamiento del dispositivo: Central, Periférico, Observador, Emisor y la conexión se establece cuando es necesario. Y con la API del GATTSe realiza la transmisión y recepción directa de datos útiles y su análisis.

(Haga clic para ampliar)

La mayoría de los dispositivos existentes actualmente admiten BLE 4.1, a pesar de la existencia de la versión 4.2.

Todas las diferencias de la versión 4.2 con respecto a la anterior se relacionan específicamente con las mejoras en la parte BLE: mayor velocidad, la capacidad de transmitir el protocolo IP y el tráfico HTTP, mayor protección criptográfica e irreconocibilidad para los observadores externos.

Una característica importante de BLE en comparación con Wi-Fi es la especificación no solo del canal de comunicación, sino también de las propias aplicaciones que lo usan. Esto se llama perfiles y servicios. Los perfiles con servicios describen las funciones de los dispositivos, el propósito de los datos, la composición y el formato de los datos, la protección de datos, el orden, los tipos y los eventos del intercambio, y no solo cómo se transmiten los datos. Esto le permite no reinventar la rueda de los protocolos al desarrollar, por ejemplo, un sensor de temperatura corporal o un medidor de pulso. Las especificaciones ya se han dado, permanece en el lado del dispositivo solo para completar los campos necesarios para enviar los resultados de la medición. Los clientes de dichos dispositivos en forma de teléfonos inteligentes, tabletas, PC o electrodomésticos de cocina reconocerán estos datos automáticamente y los mostrarán o usarán en consecuencia. Todo gracias aque todos los fabricantes siguen las mismas especificaciones BLE con respecto a cómo se presentan los datos de temperatura o frecuencia cardíaca y cómo trabajar con ellos. Pero todavía hay espacio para la imaginación del desarrollador, ya que los perfiles tienen mecanismos para expandir la funcionalidad.

La siguiente es una jerarquía aproximada de atributos en un dispositivo BLE.

(Haga clic para ampliar)

A continuación se muestra un árbol de atributos típico un poco más detallado. Este no es un árbol completo; la mayoría se omite porque ocuparía demasiado espacio. Los colores resaltan los niveles de los árboles, cada atributo tiene un número único: UUID. La grabación de números estándar se reduce a 16 bits. En esta figura, todos los números son estándar. Los perfiles GAP y GATT también se presentan como servicios con sus características estándar. Cada servicio puede tener su propio modelo de seguridad y autorización. Todo el árbol en el dispositivo se almacena como una base de datos llamada base de datos GATT, generalmente en forma de una tabla simple con referencias cruzadas.

(Click para ampliar)
Las características del servicio tienen muchas características, como se muestra a continuación. Aquí tienes que disculparte por la tautología, pero en BLE realmente hay algún tipo de crisis de terminología. En una palabra, las características del servicio que le pertenece pueden especificar la lectura, escritura, la necesidad de notificaciones, confirmaciones, firmas, etc.

(Haga clic para ampliar)

BLE es una tecnología seria, se ha hecho mucho para garantizar la seguridad y la máxima formalización, lo que a su vez debería facilitar el logro de la compatibilidad.

El intercambio de datos entre dispositivos BLE se lleva a cabo escribiendo y leyendo los valores de las características. Los canales de transmisión como TCP o UART no están aquí. Y si los dispositivos los tienen, entonces están organizados por complementos de software de un nivel superior.

Herramientas de desarrollo

Herramientas de desarrollo con el sitio web propuesto para Bluetooth Special Interest Group (Bluetooth SIG) : https://www.bluetooth.com/develop-with-bluetooth/developer-resources-tools

Las siguientes herramientas útiles se ofrecen en el sitio de la organización principal de estandarización: Bluetooth SIG :

Estudio para desarrolladores de Bluetooth

Bluetooth Developer Studio es una herramienta que le permite formar e insertar correctamente perfiles, servicios, características y descriptores en la implementación de un dispositivo BLE , es decir crear una base de datos Si compra un adaptador Bluetooth de hardware adicional por $ 99, el programa le permite interceptar , descifrar y mostrar paquetes de protocolo Bluetooth. El programa también tiene la capacidad de depurar y probar los servicios creados.

Porque en BLElos perfiles aprobados se describen con gran detalle, incluso errores menores con respecto al formato, numeración, accesibilidad, etc. en estos perfiles causará problemas de compatibilidad. Pero para los perfiles no estándar, es muy difícil prescindir de una herramienta que construya con precisión un árbol de servicios, características y descriptores que cumplan con todas las especificaciones. Es fácil confundirse con los nombres de servicios, características, descriptores y sus números únicos de múltiples bytes: UUID .

El resultado de la herramienta en particular son los archivos XML generados que describen perfiles, servicios, características y descriptores en el proyecto del usuario. Silicon Labs Simplicity IDE utiliza directamente estos archivos XML para integrarlos en proyectos integrados para sus chips.

(Click para ampliar)

Otro resultado de la herramienta puede ser el código fuente del dispositivo que trabaja con la base de datos BLE . Pero para esto, el usuario necesita escribir su complemento en JavaScript . El programa también proporciona plug-in de acceso del usuario a la base de datos a través de un especial API de JavaScript .
Hay una serie de complementos listos para usar que generan varios archivos de texto fuente adecuados para la compilación en entornos de terceros y marcos de software.

Todavía no hay complementos para soluciones basadas en el marco del software de conectividad NXP Kinetis KW40Z .

Acelerador de aplicaciones

Application accelerator 2.1 : un conjunto de proyectos de demostración con textos fuente para diferentes sistemas operativos Android 6 . 0 , Blackberry , iOS 9 , Tizen 2 . 4 y Windows 10 . Para Windows 10, los proyectos son solo para el entorno de desarrollo de Visual Studio para la arquitectura de la Plataforma universal de Windows (UWP). Es decir estos proyectos no pueden compilarse bajo los formularios Windows Forms o WPF c .NET . Y puentes para traducir aplicaciones regulares de Windows a UWPsolo siendo creado

Cabe señalar que UWP hace posible colocar aplicaciones en la Tienda Windows , pero no crea un archivo .exe ejecutable simple , que simplemente puede copiar y ejecutar. El primer lanzamiento de una aplicación para UWP siempre va acompañado de una instalación. Todo esto crea dificultades para el desarrollador. Y la funcionalidad de los proyectos de demostración deja mucho que desear.

(Haga clic para ampliar)

Arriba hay una captura de pantalla de la única aplicación de demostración para Windows: BLEServiceBrowser .

Kit Gateway Smart Satarter

Gateway Smart Starter Kit : el proyecto de la puerta de enlace del dispositivo BLE para el servidor WEB y el servidor WEB mismo que implementa la interfaz de usuario para la red de dispositivos BLE . Todo se implementa en Node.js. Se propone implementar en un microordenador modelo B Raspberry Pi 2 con el sistema operativo Raspbian Jessie . La conexión directa de la Raspberry Pi a los dispositivos BLE utiliza la interfaz Bluetooth HCI de enchufes al nivel L2CAP y USB HCIAdaptador Para ejecutar en Windows, debe instalar un sustituto especial para el controlador Bluetooth HCI estándar . La solución funciona en un número muy limitado de tipos de adaptadores de hardware debido al controlador HCI limitado.

Peryton

Entre las herramientas comerciales, un interesante analizador de tráfico BLE de Perytons es el programa analizador, que se ejecuta en PC con Windows a partir de la versión 7. Este es un punto importante, ya que los controladores BLE nativos para Windows solo funcionan a partir de la versión 8. El analizador funciona con una lista limitada de adaptadores BLE de hardware .

Cuando se trabaja con adaptadores, también hay limitaciones en el análisis causadas por el cifrado de tráfico en BLE.

(Click para ampliar)

Sin embargo, incluso desde la versión de prueba del programa puede obtener muchos beneficios. El programa se acompaña de grabaciones de demostración de intercepciones que intercambian dispositivos reales. Estos registros, después de cargarlos en el programa, ofrecen una imagen detallada del funcionamiento de toda la pila de protocolos BLE. Ver una de esas intercepciones reemplaza la exploración de toda la especificación Bluetooth.

Sabueso del autobús

Si solo necesita monitorear de alguna manera la actividad entre la computadora y el dispositivo BLE y puede hacerlo sin un análisis detallado del protocolo, entonces lo hará el conocido interceptor de tráfico de controladores de Windows llamado Bus Hound .

En la captura de pantalla a continuación, puede ver la secuencia de paquetes publicitarios recibidos. La irregularidad de los intervalos de tiempo de recepción de paquetes es claramente visible. Esto indica una pérdida significativa de paquetes. El intervalo de tiempo de espera para el dispositivo BLE se estableció en 20 ms.

(Haga clic para ampliar) La

siguiente captura de pantalla muestra la representación del dispositivo BLE en la ventana Bus Hound después de emparejar con una PC. Para cada servicio de dispositivo, después del emparejamiento, aparece un canal de comunicación lógica. Aquí puede ver el UUID del dispositivo y los servicios.

Analizador de tráfico BLE (sniffer) USB-KW40Z

Esta es una herramienta del kit de soporte de desarrollo de Kinetis. Por lo tanto, me detendré en ello con más detalle. Página de sniffer de NXP.

El sniffer fue desarrollado por NXP (o más bien, el antiguo Freescale) y se puede comprar a bajo costo en tiendas populares de componentes de radio en línea: Mouser, Digi-Key, Farnell ... Es ofrecido por NXP como una herramienta para monitorear paquetes de radio enviados por dispositivos BLE.

Con este dispositivo, puede estudiar la estructura de los paquetes, registrarlos en un registro y analizar la densidad del tráfico. El circuito sniffer está abierto al estudio, pero el programa del microcontrolador se suministra como un archivo binario. Sniffer le permite filtrar paquetes por valor de dirección.

Puede descargar el software de PC para el sniffer mediante la siguiente consulta de búsqueda en el sitio web www.nxp.com - Kinetis_Protocol_Analyzer_Adapter.exe

Dado que el sniffer, además de la función principal, también puede ser una plataforma de depuración para diferentes aplicaciones, se le adjuntan archivos de firmware básicos binarios, con los cuales Puede restaurar la funcionalidad de sniffer después de experimentar. Los archivos vienen con el paquete de software de conectividad KW40Z , que se descarga de www.nxp.com para la consulta de búsqueda KW40Z_Connectivity_Software. Los archivos se llamarán Sniffer_processing_core_usbkw40z_k22f.bin (para el microcontrolador MK22FN512 en la placa del sniffer) y Sniffer_radio_core_usbkw40z_kw40z.bin(para el microcontrolador MKW40Z en la placa del sniffer). Los archivos se programan utilizando depuradores SWD: JLink, STLink, OpenSDA ...

Desde el lado de la PC, el dispositivo se percibe como un dispositivo USB compuesto con un puerto COM y un puerto de depuración de acuerdo con la especificación, OpenSDA con firmware CMSIS-DAP. Por lo tanto, en el entorno IAR, puede programar y depurar libremente el chip sniffer MKW40Z utilizando su otro chip MK22FN512 como soporte para la funcionalidad del adaptador de depuración. Pero ambos chips en la placa tienen conectores SWD estándar para un adaptador de depuración externo.

Sniffer no garantiza la recepción de todos los paquetes transmitidos al aire. Es fácil inundarlo, después de lo cual deja de aceptar paquetes, por lo que se recomienda habilitar el filtrado por dirección para recibir solo paquetes del nodo de interés con tráfico bastante raro.

La siguiente ventana muestra el programa analizador de paquetes. La ventana incluye la intercepción en los tres canales:

(Haga clic para ampliar)

Al instalar el software del analizador en una PC, crea un adaptador Ethernet virtual que convierte los paquetes disparados a través del puerto COM virtual del sniffer en paquetes Ethernet. En mi caso, dicho adaptador virtual recibió automáticamente un nombre simple: Ethernet.
Para ver los paquetes, también necesita instalar el programa sniffer de paquetes Wireshark Ethernet.

Vista de la ventana principal del programa Wireshark mientras se monitorea el tráfico. Wireshark describe en detalle todos los campos de bits del paquete de protocolo Link Layer (LE LL), sin embargo, después de establecer una conexión entre los dispositivos e iniciar el protocolo L2CAP, el contenido del paquete no se reconoce porque se transmite cifrado.