A tecnologia Bluetooth está quebrando energicamente seu lugar na Internet das coisas. Alguma desta tecnologia, conhecida como o Bluetooth LE ( o Bluetooth A baixa energia , é o Bluetooth Smart , aka BLE ) diretamente se posicionou como a escolha ideal para a Internet das coisas ( da Internet das coisas ). Difícil de discordar. O BLE já sabe como direcionar o tráfego da Internet, determinar coordenadas nas salas, conectar controladores lógicos programáveis industriais, dar suporte a servidores WEB , conectar balanças, termômetros, monitores de freqüência cardíaca, oxímetros, monitores de pressão arterial e muitas outras coisas. C bleMuitos problemas inerentes às soluções Wi-Fi são resolvidos automaticamente . Não muito antes do momento em que os dispositivos com BLE podem ser organizados na rede MESH , usando uma tecnologia semelhante ao ZigBee . Isso já está refletido na especificação Bluetooth 5.0.

Portanto, ao desenvolver meu módulo de IoT , preferi incondicionalmente o BLE em vez de usar o Wi-Fi . Considerarei a parte periférica da rede BLE usando o módulo de depuração K66BLEZ como exemplo .

Aqui, eu gostaria de descrever minha rota de desenvolvimento, da quase completa ignorância do BLE à produção em série.

A familiaridade com o módulo K66BLEZ1 foi iniciada nestes artigos:

.
. FatFs
.

O módulo K66BLEZ usa o chip MKW40Z160 ( Cortex-M0 + 48 MHz, Flash de 160 KB, RAM de 20 KB ) produzido pelo NXP como um transceptor BLE . O chip é interessante, pois, juntamente com o BLE, também pode funcionar como um transceptor de sinais do padrão 802.15.4 . E o padrão 802.15.4 , como você sabe, é o portador da tecnologia ZigBee . A pilha do ZigBee para o MKW40Z não foi lançada, mas já é oferecido um firmware em que o 802.15.4 trabalha simultaneamente com o BLE . Um diagrama de uma parte de um módulo com um chip BLE é mostrado abaixo.

(Clique para ampliar)

No lugar do chip MKW40 já tem chip de MKW41 com um volume de 128 KB de RAM, 512 capacidade KB Flash e suporte para todos os protocolos populares: BLE 4.2, BLE o Mesh, o ZigBee, Thread A, o IPv6 6LoBLE . Ainda não existe documentação aberta sobre o novo chip, mas ele promete ser compatível com os pinos do MKW40.

O chip MKW40 BLE no módulo se conecta ao microcontrolador principal MK66 com interfaces SPI e I2C. A interface I2C também conecta o chip ao chip do carregador. O principal canal de comunicação é implementado na interface SPI com uma taxa de bits de 6 Mbit / s.

A depuração do programa no chip MKW40 pode ser realizada através da interface SWD usando o adaptador JTAG e através da interface de depuração UART0 também transmitida para o conector do depurador X4.
O NXP fornece mais de duas dezenas de exemplos da implementação de várias aplicações no chip MKW40, incluindo: pressão, glicose, temperatura, sensores de proximidade, medidores de freqüência cardíaca, etc. Existem aplicativos para UART sem fio e carregador de inicialização sem fio.

Fiz uma refatoração profunda da estrutura NXP para esses chips e criei novos perfis com programas de demonstração no PC com Windows que não exigem um adaptador separado no lado do PC. Mas mais sobre isso mais tarde.

É difícil aprender o Bluetooth LE. O motivo é a volumosa especificação e um grande número de suas breves paráfrases na documentação dos fabricantes, começando imediatamente com uma terminologia incomum. Então, vamos começar com isso.

Decodificação e tradução de termos e abreviações, gírias.

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

Ao escolher um chip para o BLE, realizei uma pequena análise de ofertas dos fabricantes mais famosos. Acima de tudo, eu estava interessado na composição do software proposto, estruturas e ferramentas de compilação-montagem-depuração para projetos sob o núcleo do ARM. Um fator importante foi a continuidade com o ambiente IAR e a estrutura RTOS MQX , que são usadas no desenvolvimento do aplicativo no processador principal do módulo.

SEMICONDUTOR NÓRDICO

fornece um SDK para o chip nRF51822 com o núcleo Cortex - M0 . Compilado em IAR, KEIL, GCC. A pilha BLE é representada por uma biblioteca monolítica sem códigos-fonte chamada SoftDevice, na qual todas as APIs são implementadas: GAP, GATT, L2CA, HCI. Em torno desta biblioteca é construída uma estrutura com drivers. A estrutura vem com dois RTOS: RL-ARM RTX de Keil e FreeRTOS . A estrutura usa a tecnologia de serialização protobuf e a depuração Segger RTT .

Além disso, o nrf5 IoT SDK é oferecido.. Inclui os códigos-fonte dos protocolos MQTT, COAP, TLS (extraídos do projeto MBED), cJSON, lwip (pilha de protocolos TCP / IPv4 / IPv6 grátis), interface de soquete, adaptador IPv6. Há também 6LoWPAN , mas sem código fonte.

Texas Instruments

no ARM, ele fabrica apenas chips BLE de dois núcleos CC2640 ( Cortex-M3 e Cortex-M0 ), mas as especificações correspondentes são o Bluetooth 4.2.Para fazer o download, fornece o SDK SimpleLink Bluetooth de baixa energia Software Stack 2.2.0 É compilado pelo próprio ambiente de desenvolvimento do Code Composer Studio no ambiente IAR. Ele vem com seu próprio RTOS TI-RTOS 2.16 e uma estrutura desenvolvida em torno das bibliotecas de pilha BLE. O SDK como um dos cenários envolve o uso de um processador de aplicativo externo - Simple Application Processor (SAP). O próprio chip CC2640 é conhecido como SNP (Simple Network Processor). Entre eles, a comunicação é estabelecida sob um protocolo chamado Unified Network Processor Interface(NPI). No lado do CC2640, o TI-RTOS é necessariamente usado; no lado do processador SAP, você pode usar o RTOS a seu critério. O código-fonte para o protocolo NPI é fornecido com o SDK para o lado SAP e o SNP. Esta é a tecnologia SimpleLink .

A própria pilha do BLE é dividida em 3 bibliotecas pré-compiladas sem fontes: host, controlador, HCI. Todas as três bibliotecas funcionam apenas no processador Cortex-M3, que faz parte do chip CC2640. Além de estudar o TI-RTOS, o usuário precisará estudar um mecanismo ou protocolo de software especial para interagir com a pilha BLE chamada iCall.

Microchip-atmel

fabrica chips ATBTLC1000 Bluetooth LE no núcleo Cortex-M0 . Toda a pilha de chips é gravada na ROM. Nenhuma ferramenta aberta para programar esses chips foi encontrada no site da Atmel. Em vez disso, a Atmel sugere o uso de um microcontrolador externo para interagir com o ATBTLC1000. O software para um microcontrolador externo e exemplos estão no Atmel Software Framework. Compila no Atmel Studio (shell para GCC) ou no IAR.

Cypress Semiconductor Corp.

produz uma família de chips BLE programáveis baseados no núcleo Cortex-M0 - PSoC 4: PSoC 4XX8 e PRoC CYBL1XX7X que suportam a especificação Bluetooth 4.2 . Projetos para chips são criados em um IDE PSoC Creator especial. Os chips do Cypress diferem pelo fato de não haver configuração periférica pronta (UART, SPI, I2S, PWM etc.), eles devem ser criados a partir de elementos de biblioteca em um editor de circuitos com a adição de bibliotecas de software. Isso foi projetado para fornecer alguma flexibilidade. Embora isso adicione muito trabalho ao desenvolvedor. Um projeto configurado pode ser compilado por uma das cadeias de ferramentas: GCC, IAR, Keil. BLE existe uma das bibliotecas. A pilha BLE é entregue como uma biblioteca monolítica pré-compilada sem códigos-fonte que combinam o host BLE, o controlador BLE e o HCI. No entanto, a empresa publicou o código-fonte para aplicativos Android e iOS que trabalham com o BLE.

Laboratórios de silício

fabrica SoCs Smart Bluetooth EFR32 Blue Gecko baseados no núcleo ARM Cortex-M4 que suporta a especificação Bluetooth 4.2 Os chips do tipo EFR32BG1P332F256GMxx podem fornecer potência de até 19,5 dBm e combinar um canal de rádio separado de 868 MHz com potência de até 20 dBm e sensibilidade -121,4 dBm. O chip Silicon Labs é uma grande variedade de funções alternativas de pinos e um sistema chamado Sistema de Reflexo Periférico(PRS). Embora os periféricos não possam ser criados como chips Cypress, mas sua conexão com os pinos seja quase arbitrária, a presença do PRS torna possível interagir uns com os outros sem envolver o processador. Pilha BLE da Silicon Labs capaz de aceitar resultados de geração de perfil pelo Bluetooth Developer Studioque será discutido abaixo. O Silicon Labs oferece duas pilhas Bluetooth. Um deles foi projetado para módulos Bluegiga e, além do BLE, também suporta Bluetooth comum. A segunda pilha está em conformidade com a especificação 4.2 e apenas LE. A pilha BLE é entregue como uma biblioteca pré-compilada monolítica sem fontes. Para a opção com um microcontrolador externo, é oferecido um protocolo serial e API nas fontes. O GCC, o IAR e o Keil podem compilar. Tudo é feito em um único ambiente de desenvolvimento Simplicity Studio V4 . A estrutura da pilha que o acompanha não é suportada pelo RTOS. Mas no código-fonte do Simplicity Studio você pode encontrar pérolas como Speex a 8 kbps, adequadas para transmitir voz sobre BLE e uma poderosa GUI de janela da Segger.

STMicroelectronics

fabrica chips controladores de rede BlueNRG baseados no Cortex-M0 que contêm uma pilha BLE de acordo com a especificação Bluetooth 4.1 .

Os próprios chips não são programáveis, mas possuem uma interface de comando de aplicativo serial (ACI) através da qual um microcontrolador externo deve se comunicar com eles. Uma estrutura foi desenvolvida para a ACI e pode ser incluída como parte do ambiente de desenvolvimento proprietário da ST, STM32Cube.

PLC CSR

não fabrica chips BLE no ARM Cortex, mas está interessado em implementar a rede MESH nos módulos Bluetooth . O vídeo está aqui . Os códigos-fonte de vários aplicativos BLE para Android e iOS são apresentados. Existe um SDK.

Renesas

produz chips BLE em seu núcleo RL78 de 16 bits . A pilha BLE é emitida apenas para usuários premium. Todos eles próprios - compilador, RTOS, microcontrolador host. Mas há um plug-in para o Bluetooth Developer Studio

Dialog Semiconductor

oferecem, como afirmam, os menores chips BLE . No entanto, os chips com memória Flash DA14583 (o restante é apenas com ROM) não podem ser chamados de menores - 5x5 mm. O núcleo de Cortex-a M0 . Potência máxima 0 dBm . Suporte para a especificação Bluetooth 4.1. Para obter o SDK da empresa, você precisa se registrar e passar no teste. Mas com esses parâmetros de chip, nem tentei obter um SDK.

Assim, as fontes de MQTT, COAP, TLS, SPEEX, LwIP e assim por diante. aqueles em diferentes SDKs nos interessam pouco, eles podem ser encontrados livremente no Github sem vincular a estruturas específicas. O suporte para a especificação Bluetooth 4.2 faz pouco, pois não é possível usá-lo em um PC.

RTOS de nicho, como TI-RTOS ou agendadores especiais, dificultam o domínio; tentamos evitar essas decisões.

Fiquei satisfeito por ter escolhido a solução no Kinetis.

O que é interessante sobre a pilha NXP Bluetooth LE para a família Kinetis.

A pilha BLE do Kinetis, como outras, vem na forma de bibliotecas pré-compiladas. Em torno dessas bibliotecas, é criada uma estrutura de multitarefa que inclui drivers e uma camada de abstração de hardware no código-fonte independente do sistema operacional. A estrutura pode ser configurada para funcionar sem um sistema operacional ou pode ser usada. Imediatamente na entrega, a estrutura é adaptada para o FreeRTOS. Mas ele interage com o FreeRTOS através de um conjunto auxiliar de funções chamado camada de abstração do sistema operacional (abstração do SO, OSA).

Graças ao OSA, em vez do FreeRTOS, você pode substituir qualquer outro sistema operacional que suporte filas de mensagens, preemções, sinalizadores e cronômetros. Por exemplo, RTOS MQX. A pilha compila, por incrível que pareça, apenas no ambiente IAR. Felizmente, no meu caso, isso não é um problema.

É mais interessante que a pilha seja dividida em duas bibliotecas - host BLE e controlador BLE. E a biblioteca host BLE pode funcionar em outro chip.

As bibliotecas interagem entre si neste caso através do protocolo HCI. I.e. onde outros fabricantes criam outro protocolo de comunicação para a interação do aplicativo no microcontrolador externo com a pilha BLE (lembre-se do SimpleLink), o NXP oferece uma solução padrão. E o mais importante, com essa abordagem, movendo o host BLE para um microcontrolador externo mais poderoso, aumentamos significativamente os recursos de nosso banco de dados e serviços GATT.

Brevemente sobre BLE

Uma versão aberta 4.2 da especificação do bluetooth está disponível aqui . A descrição do nível mais baixo de BLE (nível do controlador ) está incluída como "Pacote do sistema principal do Vol.6 [volume do controlador de baixa energia]" da página 2544. O nível superior (nível do host ) com uma descrição do protocolo ATT e perfil do GATT está localizado no "vol.3 Pacote do sistema principal [volume do host] ”do documento da página 1693.

Faixa de frequência usada

(Clique para ampliar)

Três frequências (na figura acima são indicadas pelos números de canal 37.38.39) são alocadas para pacotes sem endereço de broadcast e o restante para transmissão de pacotes ao estabelecer canais de comunicação lógicos entre dispositivos. Uma característica bem conhecida do Bluetooth é que, ao transmitir pacotes, cada pacote subsequente é transmitido em uma frequência diferente, selecionado pseudo-aleatoriamente na lista de permitidos.

Todos os dados nos pacotes BLE podem ser criptografados e autenticados. A geração aleatória dinâmica de endereços de dispositivos e sua identificação usando hash também são usadas, ou seja, Tendo interceptado o endereço do dispositivo no ar, não poderemos usá-lo por mais de 15 minutos, porque o endereço será alterado de acordo com um algoritmo desconhecido para nós durante esse período.

Os módulos BLE podem operar como transmissores unidirecionais, ou seja, sem estabelecer uma conexão bidirecional, basta transmitir alguns dados na forma de pacotes de anúncios, por exemplo, temperatura. O tipo de dados nos pacotes de publicidade designados como dados específicos do fabricante pode ser usado para isso . Um computador ou tablet pode receber dados de centenas desses transmissores sem etapas preliminares desnecessárias para pesquisar, estabelecer uma conexão, inserir um código PIN e assim por diante.
Outra possibilidade de transferir dados sem instalar um canal de comunicação é a transmissão no modo solicitação-resposta (a solicitação é o pacote ScanRequest , a resposta do módulo é o pacote ScanResponce ). Esse BLE é significativamente diferente do Wi-Fi, onde, mesmo para o termômetro mais simples, é necessário estabelecer uma conexão que consome os recursos do roteador.

Pilha de protocolos BLE

A figura abaixo mostra o BLE como um programador de microcontrolador vê. A pilha BLE consiste em duas partes de software: Host e Controlador . O software host lida com funções de alto nível de organização e gerenciamento de dados, conexões e o Controller gerencia a periferia física do transceptor, trabalha com chaves secretas e lida com outras funções de baixo nível. As partes nomeadas são conectadas pela interface do software HCI ( Host Controller Interface ). Em uma implementação de PC, a parte Host é executada em um computador e a parte Controller é executada em um transceptor de hardwareO Bluetooth e o protocolo HCI costumam ser transmitidos via USB . Na implementação no microcontrolador, ambas as partes operam no mesmo chip, e a interface HCI se transforma simplesmente em transferência direta de dados da tarefa host (módulo de software) para a tarefa do controlador (módulo de software) e vice-versa.
De fato, o programador vê vários conjuntos de APIs funcionando no nível do host : chamados GATT , GAP, L2CA, SMP, HCI . Usando a API GAP , o modo de operação do dispositivo é definido - Central, Periférico, Observador, Locutor e a conexão é estabelecida quando necessário. E com a API do GATTA transmissão e recepção direta de dados úteis e sua análise são realizadas.

(Clique para ampliar)

A maioria dos dispositivos existentes atualmente suporta o BLE 4.1, apesar da existência da versão 4.2.

Todas as diferenças da versão 4.2 da anterior se referem especificamente a melhorias na parte BLE: maior velocidade, capacidade de transmitir protocolo IP e tráfego HTTP, maior proteção criptográfica e irreconhecibilidade para observadores externos.

Uma característica importante do BLE em comparação com o Wi-Fi é a especificação não apenas do canal de comunicação, mas também dos próprios aplicativos que o utilizam. Isso é chamado de perfis e serviços. Os perfis com serviços descrevem as funções dos dispositivos, a finalidade dos dados, a composição e o formato dos dados, a proteção dos dados, a ordem, os tipos e os eventos da troca, e não apenas como os dados são transmitidos. Isso permite que você não reinvente a roda dos protocolos ao desenvolver, por exemplo, um sensor de temperatura corporal ou um medidor de pulso. As especificações já foram fornecidas, ele permanece no lado do dispositivo apenas para preencher os campos necessários para o envio dos resultados da medição. Os clientes desses dispositivos na forma de smartphones, tablets, PCs ou utensílios de cozinha reconhecerão esses dados automaticamente e os exibirão ou os usarão de acordo. Tudo graças aque todos os fabricantes sigam as mesmas especificações BLE sobre como os dados de temperatura ou freqüência cardíaca são apresentados e como trabalhar com eles. Mas ainda há espaço para a imaginação do desenvolvedor, pois os perfis têm mecanismos para expandir a funcionalidade.

A seguir, é apresentada uma hierarquia aproximada de atributos em um dispositivo BLE.

(Clique para ampliar)

Abaixo está uma árvore de atributos típicos um pouco mais detalhada. Esta não é uma árvore completa; a maioria é omitida porque ocuparia muito espaço. As cores destacam os níveis da árvore, cada atributo tem um número exclusivo - UUID. A gravação de números padrão é reduzida para 16 bits. Nesta figura, todos os números são padrão. Os perfis GAP e GATT também são apresentados como serviços com seus recursos padrão. Cada serviço pode ter seu próprio modelo de segurança e autorização. A árvore inteira no dispositivo é armazenada como um banco de dados chamado banco de dados GATT, geralmente na forma de uma tabela simples com referências cruzadas.

(Clique para ampliar)
As características do serviço têm muitas características, como mostrado abaixo. Aqui você precisa se desculpar pela tautologia, mas no BLE realmente há algum tipo de crise de terminologia. Em uma palavra, as características do serviço pertencente a ele podem especificar a leitura, gravação, a necessidade de notificações, confirmações, assinaturas etc.

(Clique para ampliar) O

BLE é uma tecnologia séria, muito foi feito para garantir a segurança e a formalização máxima, o que por sua vez deve facilitar a obtenção de compatibilidade.

A troca de dados entre dispositivos BLE é realizada escrevendo e lendo os valores das características. Canais de streaming como TCP ou UART não estão aqui. E se os dispositivos os tiverem, eles serão organizados por complementos de software de nível superior.

Ferramentas de desenvolvimento

Ferramentas de desenvolvimento com o site proposto pelo Bluetooth Special Interest Group (Bluetooth SIG) - https://www.bluetooth.com/develop-with-bluetooth/developer-resources-tools

As seguintes ferramentas úteis são oferecidas no site da principal organização de padronização - Bluetooth SIG :

Bluetooth Developer Studio

O Bluetooth Developer Studio é uma ferramenta que permite formar e inserir corretamente perfis, serviços, características e descritores na implementação de um dispositivo BLE , ou seja, crie um banco de dados. Se você comprar um adaptador Bluetooth de hardware adicional por US $ 99, o programa permitirá interceptar , descriptografar e exibir pacotes de protocolo Bluetooth. O programa também tem a capacidade de depurar e testar os serviços criados.

Porque no BLEperfis aprovados são descritos em grande detalhe, até pequenos erros em relação a formato, numeração, acessibilidade etc. nesses perfis causará problemas de compatibilidade. Porém, para perfis não padronizados, é muito difícil prescindir de uma ferramenta que construa com precisão uma árvore de serviços, características e descritores em conformidade com todas as especificações. É fácil confundir os nomes dos serviços, características, descritores e seus números únicos de vários bytes - UUID .

O resultado da ferramenta, em particular, são os arquivos XML gerados que descrevem perfis, serviços, características e descritores no projeto do usuário. Esses arquivos XML são usados diretamente pelo Silicon Labs Simplicity IDE para integrar projetos embarcados para seus chips.

(Clique para ampliar)

Outro resultado da ferramenta pode ser o código fonte do dispositivo que trabalha com o banco de dados BLE . Mas, para isso, o usuário precisa escrever seu plugin em JavaScript . O programa também fornece plug-in acesso do usuário ao banco de dados através de uma especial API para JavaScript .
Existem vários plug-ins prontos que geram vários arquivos de texto de origem adequados para compilação em ambientes de terceiros e estruturas de software.

Ainda não existem plugins para soluções baseadas na estrutura do software NXP Kinetis KW40Z Connectivity .

Acelerador de aplicativo

Application accelerator 2.1 - um conjunto de projetos de demonstração com textos de origem para diferentes sistemas operacionais Android 6 . 0 , Blackberry , iOS 9 , Tizen 2 . 4 e Windows 10 . Para o Windows 10, os projetos são apenas para o ambiente de desenvolvimento do Visual Studio para a arquitetura Universal Windows Platform (UWP). I.e. esses projetos não podem ser compilados nas estruturas Windows Forms ou WPF c .NET . E pontes para traduzir aplicativos regulares do Windows para UWPapenas sendo criado.

Observe que o UWP possibilita colocar aplicativos na Windows Store , mas não cria um arquivo .exe executável simples , que você pode simplesmente copiar e executar. O primeiro lançamento de um aplicativo UWP é sempre acompanhado por uma instalação. Tudo isso cria dificuldades para o desenvolvedor. E a funcionalidade dos projetos de demonstração deixa muito a desejar.

(Clique para ampliar)

Acima está uma captura de tela do único aplicativo de demonstração para Windows - BLEServiceBrowser .

Kit Gateway Smart Satarter

Gateway Smart Starter Kit - O projeto do gateway do dispositivo BLE para o servidor WEB e o próprio servidor WEB implementando a interface do usuário para a rede de dispositivos BLE . Tudo é implementado no Node.js. Propõe-se implantar em um microcomputador Raspberry Pi 2 modelo B com o sistema operacional Raspbian Jessie . A conexão direta do Raspberry Pi a dispositivos BLE usa a interface Bluetooth HCI dos soquetes para o nível L2CAP e o USB HCIadaptador. Para executar no Windows, você precisa instalar um substituto especial para o driver Bluetooth HCI padrão . A solução funciona em um número muito limitado de tipos de adaptadores de hardware devido ao driver HCI limitado.

Peryton

Entre as ferramentas comerciais, um interessante analisador de tráfego BLE da Perytons é o programa analisador, que roda em PCs com Windows a partir da versão 7. Este é um ponto importante, pois os drivers BLE nativos para Windows funcionam apenas a partir da versão 8. O analisador trabalha com uma lista limitada de adaptadores BLE de hardware .

Ao trabalhar com adaptadores, também existem limitações na análise causadas pela criptografia de tráfego no BLE.

(Clique para ampliar)

No entanto, mesmo na versão de teste do programa, você pode obter muitos benefícios. O programa é acompanhado por gravações de demonstração de interceptações trocando dispositivos reais. Esses registros, depois de carregados no programa, fornecem uma imagem detalhada da operação de toda a pilha de protocolos BLE. A visualização de uma dessas interceptações substitui a exploração de toda a especificação Bluetooth.

Cão de caça

Se você só precisa monitorar de alguma forma a atividade entre o computador e o dispositivo BLE e pode fazer isso sem uma análise detalhada do protocolo, o conhecido interceptador de tráfego de driver do Windows chamado Bus Hound o fará .

Na captura de tela abaixo, você pode ver o fluxo de pacotes de publicidade recebidos. A irregularidade dos intervalos de tempo de recepção de pacotes é claramente visível. Isso indica perda significativa de pacotes. O intervalo de tempo limite para o dispositivo BLE foi definido para 20 ms.

(Clique para ampliar) A

captura de tela abaixo mostra a representação do dispositivo BLE na janela Bus Hound após o pareamento com um PC. Para cada serviço de dispositivo, após o peering, um canal de comunicação lógica é exibido. Aqui você pode ver o UUID do dispositivo e serviços.

Analisador de tráfego BLE (sniffer) USB-KW40Z

Esta é uma ferramenta do kit de suporte ao desenvolvimento Kinetis. Portanto, vou me debruçar sobre isso em mais detalhes. Página do sniffer do NXP.

O sniffer foi desenvolvido pela NXP (ou melhor, a antiga Freescale) e pode ser comprado barato em lojas populares de componentes de rádio on-line: Mouser, Digi-Key, Farnell ... É oferecido pelo NXP como uma ferramenta para monitorar pacotes de rádio enviados por dispositivos BLE.

Usando este dispositivo, você pode estudar a estrutura dos pacotes, registrá-los em um log e analisar a densidade do tráfego. O circuito farejador está aberto para estudo, mas o programa de microcontrolador é fornecido como um arquivo binário. O sniffer permite filtrar pacotes pelo valor do endereço.

Você pode fazer o download do software do PC para o sniffer através da seguinte consulta de pesquisa no site www.nxp.com - Kinetis_Protocol_Analyzer_Adapter.exe

Como o sniffer, além da função principal, também pode ser uma plataforma de depuração para diferentes aplicativos, são anexados arquivos binários de firmware básico, com os quais Você pode restaurar a funcionalidade do sniffer após experimentar. Os arquivos vêm com o pacote do software de conectividade KW40Z , que é baixado de www.nxp.com para a consulta de pesquisa KW40Z_Connectivity_Software. Os arquivos serão chamados Sniffer_processing_core_usbkw40z_k22f.bin (para o microcontrolador MK22FN512 na placa sniffer) e Sniffer_radio_core_usbkw40z_kw40z.bin(para o microcontrolador MKW40Z na placa sniffer). Os arquivos são programados usando depuradores SWD: JLink, STLink, OpenSDA ...

Do lado do PC, o dispositivo é percebido como um dispositivo USB composto com uma porta COM e uma porta de depuração de acordo com a especificação OpenSDA com firmware CMSIS-DAP. Portanto, no ambiente IAR, você pode programar e depurar livremente o chip sniffer MKW40Z usando seu outro chip MK22FN512 como portador da funcionalidade do adaptador de depuração. Mas os dois chips da placa possuem conectores SWD padrão para um adaptador de depuração externo.

O farejador não garante a recepção de todos os pacotes transmitidos no ar. É fácil inundá-lo, após o qual ele deixa de aceitar pacotes, portanto, é recomendável ativar a filtragem por endereço para receber apenas pacotes do nó de interesse com tráfego bastante raro.

A janela a seguir mostra o programa analisador de pacotes. A janela inclui interceptação nos três canais:

(Clique para ampliar)

Ao instalar o software analisador em um PC, ele cria um adaptador Ethernet virtual, que converte pacotes disparados pela porta COM do sniffer virtual em pacotes Ethernet. No meu caso, esse adaptador virtual recebeu automaticamente um nome simples - Ethernet.
Para ver os pacotes, você também precisa instalar o programa sniffer de pacotes Wireshark Ethernet.

Vista da janela principal do programa Wireshark enquanto monitora o tráfego. O Wireshark descreve detalhadamente todos os campos de bits do pacote de protocolo Link Layer (LE LL), no entanto, após estabelecer uma conexão entre os dispositivos e iniciar o protocolo L2CAP, o conteúdo do pacote não é reconhecido porque é transmitido criptografado.