La technologie Bluetooth brise énergiquement sa place dans l'Internet des objets. Une partie de cette technologie, appelée Bluetooth LE ( Bluetooth Low Energy , alias Bluetooth Smart , alias BLE ) se positionne directement comme un choix idéal pour l' IoT ( Internet des objets ). Difficile d'être en désaccord. BLE sait déjà comment acheminer le trafic Internet, déterminer les coordonnées dans les pièces, connecter les contrôleurs logiques industriels programmables, prendre en charge les serveurs WEB , connecter les balances, les thermomètres, les moniteurs de fréquence cardiaque, les oxymètres, les tensiomètres et bien d'autres choses. C bleDe nombreux problèmes inhérents aux solutions Wi-Fi sont automatiquement résolus . Peu de temps avant le moment où les appareils avec BLE peuvent être organisés dans le réseau MESH , en utilisant une technologie similaire à ZigBee . Cela se reflète déjà dans la spécification Bluetooth 5.0.

Par conséquent, lors du développement de mon module IoT , j'ai préféré inconditionnellement BLE plutôt que d'utiliser le Wi-Fi . Je considérerai la partie périphérique du réseau BLE en utilisant le module de débogage K66BLEZ comme exemple .

Ici, je voudrais décrire mon itinéraire de développement, de l'ignorance presque complète du BLE à la production en série.

La familiarité avec le module K66BLEZ1 a commencé dans ces articles:

.
. FatFs
.

Le module K66BLEZ utilise la puce MKW40Z160 ( 48 MHz Cortex-M0 +, 160 Ko Flash, 20 Ko RAM ) produite par NXP comme émetteur-récepteur BLE . La puce est intéressante en ce que, avec BLE, elle peut également fonctionner comme un émetteur-récepteur de signaux de la norme 802.15.4 . Et le standard 802.15.4 , comme vous le savez, est le support de la technologie ZigBee . La pile ZigBee elle-même pour le MKW40Z n'a pas été publiée, mais un firmware est déjà proposé où 802.15.4 fonctionne simultanément avec BLE . Un schéma d'une partie d'un module avec une puce BLE est illustré ci-dessous.

(Cliquez pour agrandir)

Aplace de la puce MKW40 ont déjà puce MKW41 avec un volume de 128 KoRAM, capacité 512 KB Flash et support pour tousprotocoles populaires: BLE 4.2, BLE la maille, le ZigBee, Enfilez A, le 6LoBLE IPv6 . Il n'y a pas encore de documentation ouverte sur la nouvelle puce, mais elle promet d'être compatible avec le MKW40.

La puce MKW40 BLE du module se connecte au microcontrôleur principal MK66 avec des interfaces SPI et I2C. L'interface I2C connecte également la puce à la puce du chargeur. Le canal de communication principal est implémenté sur l'interface SPI avec un débit binaire de 6 Mbit / s.

Le débogage du programme dans la puce MKW40 peut être effectué via l'interface SWD à l'aide de l'adaptateur JTAG et via l'interface de débogage UART0 également sortie vers le connecteur de débogueur X4.
NXP fournit plus de deux douzaines d'exemples de mise en œuvre de diverses applications sur la puce MKW40, notamment: pression, glucose, température, capteurs de proximité, cardiofréquencemètres, etc. Il existe des applications pour UART sans fil et chargeur de démarrage sans fil.

J'ai refactorisé en profondeur le framework NXP pour ces puces et créé de nouveaux profils avec des programmes de démonstration sur PC Windows qui ne nécessitent pas d'adaptateur séparé du côté PC. Mais plus à ce sujet plus tard.

Bluetooth LE est difficile à apprendre. La raison en est la spécification volumineuse et un grand nombre de ses brèves paraphrases dans la documentation des fabricants, commençant immédiatement par une terminologie inhabituelle. Commençons donc avec.

Décodage et traduction des termes et abréviations, 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) : , , .

Lors du choix d'une puce pour BLE, j'ai effectué une petite analyse des offres des fabricants les plus connus. Surtout, je m'intéressais à la composition des logiciels, des frameworks et des outils de compilation-assemblage-débogage proposés pour les projets sous le noyau ARM. Un facteur important a été la continuité avec l'environnement IAR et le cadre RTOS MQX qui sont utilisés lors du développement de l'application sur le processeur principal du module.

SEMI-CONDUCTEUR NORDIQUE

fournit un SDK pour la puce nRF51822 avec le noyau Cortex - M0 . Compilé dans IAR, KEIL, GCC. La pile BLE est représentée par une bibliothèque monolithique sans code source appelée SoftDevice où toutes les API sont implémentées: GAP, GATT, L2CA, HCI. Autour de cette bibliothèque est construit un framework avec des pilotes. Le framework est livré avec deux RTOS: le RL-ARM RTX de Keil et FreeRTOS . Le cadre utilise la technologie de sérialisation protobuf et le débogage Segger RTT .

De plus, le SDK IoT nrf5 est proposé.. Il comprend les codes sources des protocoles MQTT, COAP, TLS (extraits du projet MBED), cJSON, lwip (pile de protocoles TCP / IPv4 / IPv6 gratuite), interface socket, adaptateur IPv6. Il existe également 6LoWPAN , mais sans code source.

Texas Instruments

sur ARM ne fabrique que des puces BLE à 2 cœurs CC2640 ( Cortex-M3 et Cortex-M0 ), mais les spécifications correspondantes sont Bluetooth 4.2 . Pour le téléchargement, il fournit le SDK SimpleLink Bluetooth low energy Software Stack 2.2.0 Il est également compilé par l'environnement de développement de Code Composer Studio. dans l'environnement IAR. Il est livré avec son propre RTOS TI-RTOS 2.16 et un cadre développé autour des bibliothèques de pile BLE. Le SDK comme l'un des scénarios implique l'utilisation d'un processeur d'application externe - Simple Application Processor (SAP). La puce CC2640 elle-même est appelée processeur de réseau simple (SNP). Entre eux, la communication est établie selon un protocole appelé interface de processeur de réseau unifié(NPI). Côté CC2640, TI-RTOS est forcément utilisé, côté processeur SAP, vous pouvez utiliser RTOS à votre discrétion. Le code source du protocole NPI est fourni avec le SDK pour le côté SAP et le côté SNP. Il s'agit de la technologie SimpleLink .

La pile BLE elle-même est divisée en 3 bibliothèques précompilées sans sources: hôte, contrôleur, HCI. Les trois bibliothèques fonctionnent uniquement sur le processeur Cortex-M3, qui fait partie de la puce CC2640. En plus d'étudier TI-RTOS, l'utilisateur devra étudier un mécanisme ou un protocole logiciel spécial pour interagir avec la pile BLE appelée iCall.

Microchip-atmel

fabrique des puces Bluetooth LE ATBTLC1000 sur le noyau Cortex-M0 . La pile de puces entière est écrite dans la ROM. Aucun outil ouvert pour programmer ces puces n'a été trouvé sur le site Web d'Atmel. Au lieu de cela, Atmel suggère d'utiliser un microcontrôleur externe pour interagir avec l'ATBTLC1000. Les logiciels pour un microcontrôleur externe et des exemples se trouvent dans le cadre logiciel Atmel. Compile dans Atmel Studio (shell pour GCC) ou dans IAR.

Cypress Semiconductor Corp.

produit une famille de puces BLE programmables basées sur le noyau Cortex-M0 - PSoC 4: PSoC 4XX8 et PRoC CYBL1XX7X prenant en charge la spécification Bluetooth 4.2 . Les projets de puces sont créés dans un créateur IDE PSoC spécial. Les puces de Cypress diffèrent en ce qu'il n'y a pas de configuration périphérique prête à l'emploi (UART, SPI, I2S, PWM, etc.), elle doit être créée à partir d'éléments de bibliothèque dans un éditeur de circuits avec l'ajout de bibliothèques de logiciels. Ceci est conçu pour fournir une certaine flexibilité. Bien que cela ajoute beaucoup de travail au développeur. Un projet configuré peut être compilé par l'une des chaînes d'outils: GCC, IAR, Keil. BLE il y a une des bibliothèques. La pile BLE est fournie sous la forme d'une bibliothèque monolithique précompilée sans codes source combinant l'hôte BLE, le contrôleur BLE et HCI. Cependant, la société a publié le code source des applications Android et iOS fonctionnant avec BLE.

Laboratoires de silicium

fabrique des SoC intelligents Bluetooth Blue Gecko EFR32 basés sur le noyau ARM Cortex-M4 prenant en charge la spécification Bluetooth 4.2 . Les puces de type EFR32BG1P332F256GMxx peuvent fournir une puissance jusqu'à 19,5 dBm et combiner un canal radio 868 MHz séparé avec une puissance allant jusqu'à 20 dBm et une sensibilité de -121,4 dBm. La puce Silicon Labs est une vaste sélection de fonctions de broches alternatives et un système appelé Peripheral Reflex System(PRS). Bien que la périphérie ne puisse pas être créée comme les puces Cypress, mais sa connexion aux broches est presque arbitraire, la présence de PRS permet d'interagir les uns avec les autres sans impliquer de processeur. Stack BLE de Silicon Labs capable d'accepter les résultats de génération de profil par Bluetooth Developer Studioqui sera discuté ci-dessous. Silicon Labs propose deux piles Bluetooth. L'un d'eux est conçu pour les modules Bluegiga et, en plus de BLE, prend également en charge le Bluetooth standard. La deuxième pile est conforme à la spécification 4.2 et uniquement à LE. La pile BLE est livrée sous la forme d'une bibliothèque monolithique précompilée sans sources. Pour l'option avec un microcontrôleur externe, un protocole série et une API dans les sources sont proposés. GCC, IAR et Keil peuvent compiler. Tout est fait dans un seul environnement de développement Simplicity Studio V4 . Le cadre de pile qui l'accompagne n'est pas pris en charge par RTOS. Mais dans le code source de Simplicity Studio, vous pouvez trouver des perles telles que Speex à 8 kbps adaptées à la transmission de la voix via BLE et une puissante interface graphique de fenêtre de Segger.

STMicroelectronics

fabrique des puces de contrôleur de réseau BlueNRG basés sur le Cortex-M0 contenant la spécification de pile BLE pour le Bluetooth 4.1 .

Les puces elles-mêmes ne sont pas programmables, mais ont une interface de commande d'application série (ACI) à travers laquelle un microcontrôleur externe doit communiquer avec elles. Un cadre a été développé pour ACI, et il peut être inclus dans le cadre de l'environnement de développement propriétaire STM32Cube de ST.

CSR PLC

ne fabrique pas de puces BLE sur ARM Cortex, mais s'intéresse à sa mise en œuvre du réseau MESH sur des modules Bluetooth . La vidéo est ici . Les codes sources de diverses applications BLE pour Android et iOS sont présentés. Il existe un SDK.

Renesas

fabrique des puces BLE sur son cœur RL78 16 bits . La pile BLE n'est délivrée qu'aux utilisateurs premium. Tous leurs propres - compilateur, RTOS, microcontrôleur hôte. Mais il existe un plug-in pour Bluetooth Developer Studio

Dialog Semiconductor

offrent, comme ils le prétendent, les plus petites puces BLE . Cependant, les puces avec mémoire flash DA14583 (les autres ne sont qu'avec ROM) ne peuvent pas être appelées les plus petites - 5x5 mm. Le noyau de la Cortex-M0 . Puissance maximale 0 dBm . Prise en charge de la spécification Bluetooth 4.1. Pour obtenir le SDK de l'entreprise, vous devez vous inscrire et passer le test. Mais avec de tels paramètres de puce, je n'ai même pas essayé d'obtenir un SDK.

Ainsi, les sources de MQTT, COAP, TLS, SPEEX, LwIP et ainsi de suite. ceux des différents SDK ne nous intéressent guère, ils peuvent être trouvés librement sur Github sans se lier à des frameworks spécifiques. La prise en charge de la spécification Bluetooth 4.2 ne fait pas grand-chose, car il n'est pas encore possible de l'utiliser sur un PC.

Des RTOS de niche comme TI-RTOS ou des planificateurs spéciaux nous rendront difficile la maîtrise, nous essayons d'éviter de telles décisions.

J'étais content d'avoir choisi la solution sur Kinetis.

Ce qui est intéressant à propos de la pile NXP Bluetooth LE pour la famille Kinetis.

La pile BLE pour Kinetis, comme d'autres, se présente sous la forme de bibliothèques précompilées. Autour de ces bibliothèques, un framework multitâche est construit qui inclut des pilotes et une couche d'abstraction matérielle dans le code source indépendant du système d'exploitation. Le cadre peut être configuré pour fonctionner sans système d'exploitation, ou il peut être utilisé. Immédiatement à la livraison, le framework est adapté pour FreeRTOS. Mais il interagit avec FreeRTOS via un ensemble de fonctions auxiliaires appelé la couche d'abstraction du système d'exploitation (OS abstraction, OSA).

Grâce à OSA, au lieu de FreeRTOS, vous pouvez remplacer n'importe quel autre système d'exploitation qui prend en charge les files d'attente de messages, les préemptions, les indicateurs et les minuteurs. Par exemple, RTOS MQX. Stack compile, curieusement, uniquement dans l'environnement IAR. Heureusement, dans mon cas, ce n'est pas un problème.

Il est plus intéressant de noter que la pile est divisée en deux bibliothèques - l'hôte BLE et le contrôleur BLE. Et la bibliothèque hôte BLE peut fonctionner sur une autre puce.

Les bibliothèques interagissent dans ce cas via le protocole HCI. C'est-à-dire où d'autres fabricants proposent un autre protocole de communication pour l'interaction de l'application sur le microcontrôleur externe avec la pile BLE (rappelez-vous SimpleLink), NXP propose une solution standard. Et surtout, avec cette approche, en déplaçant l'hôte BLE vers un microcontrôleur externe plus puissant, nous augmentons considérablement les capacités de notre base de données et de nos services GATT.

En bref sur BLE

Une version 4.2 de la spécification Bluetooth ouverte est disponible ici . La description du niveau inférieur de BLE (niveau du contrôleur ) y est incluse en tant que «Vol.6 Core System Package [Low Energy Controller volume]» de la page 2544. Le niveau supérieur (niveau de l' hôte ) avec une description du protocole ATT et du profil GATT se trouve dans le «vol.3 Package système central [volume hôte] »du document de la page 1693.

Gamme de fréquences utilisée

(Cliquez pour agrandir)

Trois fréquences (dans la figure ci-dessus sont indiquées par les numéros de canal 37.38.39) sont allouées pour la diffusion de paquets sans adresse, et le reste pour la transmission de paquets lors de l'établissement de canaux de communication logiques entre les périphériques. Une caractéristique bien connue de Bluetooth est que lors de la transmission de paquets, chaque paquet suivant est transmis à une fréquence différente, sélectionnée de manière pseudo-aléatoire dans la liste des autorisés.

Toutes les données des paquets BLE peuvent être chiffrées et authentifiées. La génération aléatoire aléatoire d'adresses d'appareil et leur identification à l'aide du hachage sont également utilisées, c'est-à-dire Après avoir intercepté l’adresse de l’appareil en ondes, nous ne pourrons pas l’utiliser pendant plus de 15 minutes, car l’adresse changera selon un algorithme qui nous est inconnu pendant cette période.

Les modules BLE peuvent fonctionner comme des émetteurs unidirectionnels, c'est-à-dire sans établir de connexion bidirectionnelle, diffusez simplement certaines données sous la forme de packages publicitaires, par exemple la température. Le type de données dans les packages publicitaires désignés comme données spécifiques au fabricant peut être utilisé pour cela . Un ordinateur ou une tablette peut recevoir des données de centaines de ces émetteurs sans étapes préliminaires inutiles pour rechercher, établir une connexion, entrer un code PIN, etc.
Une autre possibilité de transférer des données sans installer de canal de communication est la transmission en mode requête-réponse (la requête est le package ScanRequest , la réponse du module est le package ScanResponce ). Ce BLE est significativement différent du Wi-Fi, où même pour le thermomètre le plus simple, il est nécessaire d'établir une connexion qui prend les ressources du routeur.

Pile de protocoles BLE

La figure ci-dessous montre BLE comme un programmeur de microcontrôleur le voit. La pile BLE se compose de deux parties logicielles: l' hôte et le contrôleur . Le logiciel hôte traite des fonctions de haut niveau d'organisation et de gestion des données, des connexions et le contrôleur gère la périphérie physique de l'émetteur-récepteur, fonctionne avec des clés secrètes et traite d'autres fonctions de bas niveau. Les pièces nommées sont connectées par l' interface logicielle HCI ( Host Controller Interface ). Dans une implémentation PC, la partie hôte s'exécute sur un ordinateur et la partie contrôleur s'exécute sur un émetteur-récepteur matérielBluetooth et le protocole HCI sont le plus souvent transmis via USB . Dans l'implémentation sur le microcontrôleur, les deux parties fonctionnent sur la même puce, et l'interface HCI se transforme simplement en transfert direct de données de la tâche hôte (module logiciel) vers la tâche contrôleur (module logiciel) et vice versa.
En fait, le programmeur voit plusieurs ensembles d'API fonctionnant au niveau de l' hôte : appelés GATT , GAP, L2CA, SMP, HCI . À l'aide de l' API GAP , le mode de fonctionnement de l'appareil est défini - Central, Périphérique, Observer, Broadcaster et la connexion est établie si nécessaire. Et avec l' API GATTLa transmission et la réception directes des données utiles et leur analyse sont effectuées.

(Cliquez pour agrandir)

La plupart des appareils existants prennent actuellement en charge BLE 4.1, malgré l'existence de la version 4.2.

Toutes les différences de la version 4.2 par rapport à la précédente concernent spécifiquement les améliorations de la partie BLE: vitesse accrue, capacité à transmettre le protocole IP et le trafic HTTP, protection cryptographique accrue et méconnaissance pour les observateurs externes.

Une caractéristique importante du BLE par rapport au Wi-Fi est la spécification non seulement du canal de communication, mais aussi des applications qui l'utilisent. C'est ce qu'on appelle des profils et des services. Les profils avec services décrivent les rôles des appareils, la finalité des données, la composition et le format des données, la protection des données, l'ordre, les types et les événements de l'échange, et pas seulement la manière dont les données sont transmises. Cela vous permet de ne pas réinventer la roue des protocoles lors du développement, par exemple, d'un capteur de température corporelle ou d'un pulsomètre. Des spécifications ont déjà été données, il ne reste du côté de l'appareil que pour remplir les champs nécessaires à l'envoi des résultats de mesure. Les clients de ces appareils sous forme de smartphones, tablettes, PC ou appareils de cuisine reconnaîtront automatiquement ces données et les afficheront ou les utiliseront en conséquence. Merci àque tous les fabricants respectent les mêmes spécifications BLE concernant la présentation des données de température ou de fréquence cardiaque et la manière de les utiliser. Mais il y a encore de la place pour l'imagination du développeur, car les profils ont des mécanismes pour étendre les fonctionnalités.

Voici une hiérarchie approximative d'attributs dans un périphérique BLE.

(Cliquez pour agrandir)

Voici un arbre d'attributs typique légèrement plus détaillé. Ce n'est pas un arbre complet; la plupart sont omis car cela prendrait trop de place. Les couleurs mettent en évidence les niveaux des arbres, chaque attribut a un numéro unique - UUID. L'enregistrement des nombres standard est réduit à 16 bits. Dans cette figure, tous les nombres sont standard. Les profils GAP et GATT sont également présentés comme des services avec leurs fonctionnalités standard. Chaque service peut avoir son propre modèle et autorisation de sécurité. L'arbre entier de l'appareil est stocké sous forme de base de données appelée base de données GATT, généralement sous la forme d'un simple tableau avec des références croisées.

(Cliquer pour agrandir)
Les caractéristiques de service ont de nombreuses caractéristiques, comme indiqué ci-dessous. Ici, vous devez vous excuser pour la tautologie, mais dans BLE il y a vraiment une sorte de crise de terminologie. En un mot, les caractéristiques du service lui appartenant peuvent préciser la lecture, l'écriture, la nécessité de notifications, confirmations, signatures, etc.

(Cliquer pour agrandir) Le

BLE est une technologie sérieuse, tant a été fait pour assurer la sécurité et la formalisation maximale, ce qui devrait à son tour faciliter la réalisation de la compatibilité.

L'échange de données entre les appareils BLE se fait en écrivant et en lisant les valeurs des caractéristiques. Les canaux de streaming tels que TCP ou UART ne sont pas ici. Et si les appareils en ont, ils sont organisés par des extensions logicielles d'un niveau supérieur.

Outils de développement

Outils de développement avec le site proposé du Bluetooth Special Interest Group (Bluetooth SIG) - https://www.bluetooth.com/develop-with-bluetooth/developer-resources-tools

Les outils utiles suivants sont proposés sur le site de la principale organisation de normalisation - Bluetooth SIG :

Bluetooth Developer Studio

Bluetooth Developer Studio est un outil qui vous permet de former et d'insérer correctement des profils, des services, des caractéristiques et des descripteurs dans la mise en œuvre d'un appareil BLE , c'est-à-dire créer une base de données. Si vous achetez un adaptateur Bluetooth matériel supplémentaire pour 99 $, le programme vous permet d'intercepter , de déchiffrer et d'afficher les paquets de protocole Bluetooth. Le programme a également la capacité de déboguer et de tester les services créés.

Parce que dans BLEles profils approuvés sont décrits en détail, même des erreurs mineures concernant le format, la numérotation, l'accessibilité, etc. dans ces profils entraînera des problèmes de compatibilité. Mais pour les profils non standard, il est très difficile de se passer d'un outil qui construit avec précision un arbre de services, de caractéristiques, de descripteurs en conformité avec toutes les spécifications. Il est facile de se confondre dans les noms de services, les caractéristiques, les descripteurs et leurs numéros uniques à plusieurs octets - UUID .

Le résultat de l'outil en particulier est les fichiers XML générés décrivant des profils, des services, des caractéristiques et des descripteurs dans le projet de l'utilisateur. Ces fichiers XML sont directement utilisés par Silicon Labs Simplicity IDE pour s'intégrer dans des projets intégrés pour leurs puces.

(Cliquer pour agrandir)

Un autre résultat de l'outil peut être le code source du périphérique fonctionnant avec la base de données BLE . Mais pour cela, l'utilisateur doit écrire son plugin en JavaScript . Le programme offre également un accès plug-in utilisateur à la base de données via une spéciale API de JavaScript .
Il existe un certain nombre de plug-ins prêts à l'emploi qui génèrent divers fichiers texte source adaptés à la compilation dans des environnements tiers et des cadres logiciels.

Il n'y a pas encore de plugins pour les solutions basées sur le framework NXP Kinetis KW40Z Connectivity Software .

Accélérateur d'applications

Accélérateur d'applications 2.1 - un ensemble de projets de démonstration avec des textes sources pour différents systèmes d'exploitation Android 6 . 0 , Blackberry , iOS 9 , Tizen 2 . 4 et Windows 10 . Pour Windows 10, les projets sont uniquement destinés à l'environnement de développement Visual Studio pour l' architecture UWP (Universal Windows Platform). C'est-à-dire ces projets ne peuvent pas être compilés sous les cadres Windows Forms ou WPF c .NET . Et des ponts pour traduire les applications Windows normales en UWPvient d'être créé.

Il convient de noter que UWP permet de placer des applications dans le Windows Store , mais il ne crée pas un simple fichier exécutable .exe , que vous pouvez simplement copier et exécuter. Le premier lancement d'une application UWP s'accompagne toujours d'une installation. Tout cela crée des difficultés pour le développeur. Et la fonctionnalité des projets de démonstration laisse beaucoup à désirer.

(Cliquez pour agrandir)

Ci-dessus est une capture d'écran de la seule application de démonstration pour Windows - BLEServiceBrowser .

Gateway Smart Satarter Kit

Gateway Smart Starter Kit - Le projet de la passerelle d' appareil BLE vers le serveur WEB et le serveur WEB lui-même implémentant l' interface utilisateur pour le réseau d' appareils BLE . Tout est implémenté dans Node.js. Il est proposé de déployer sur un micro-ordinateur Raspberry Pi 2 modèle B avec le système d'exploitation Raspbian Jessie . La connexion directe du Raspberry Pi aux appareils BLE utilise l' interface Bluetooth HCI des prises au niveau L2CAP et USB HCIadaptateur. Pour fonctionner sous Windows, vous devez installer un substitut spécial pour le pilote Bluetooth HCI standard . La solution fonctionne sur un nombre très limité de types d'adaptateurs matériels en raison du pilote HCI limité.

Peryton

Parmi les outils commerciaux, un analyseur de trafic BLE intéressant de Perytons est le programme d'analyseur qui fonctionne sur les PC Windows à partir de la version 7. C'est un point important, car les pilotes BLE natifs pour Windows ne fonctionnent qu'à partir de la version 8. L'analyseur fonctionne avec une liste limitée d'adaptateurs BLE matériels .

Lorsque vous travaillez avec des adaptateurs, il existe également des limitations dans l'analyse causées par le chiffrement du trafic dans BLE.

(Cliquer pour agrandir)

Cependant, même à partir de la version d'essai du programme, vous pouvez obtenir de nombreux avantages. Le programme est accompagné d'enregistrements de démonstration d'interceptions échangeant de vrais appareils. Ces enregistrements, après avoir été chargés dans le programme, donnent une image détaillée du fonctionnement de l'ensemble de la pile de protocoles BLE. La visualisation d'une telle interception remplace l'exploration de la spécification Bluetooth entière.

Chien de bus

Si vous avez juste besoin de surveiller l'activité entre l'ordinateur et le périphérique BLE et que vous pouvez vous passer d'une analyse détaillée du protocole, alors l'intercepteur de trafic de pilotes Windows bien connu appelé Bus Hound fera l'affaire .

Dans la capture d'écran ci-dessous, vous pouvez voir le flux des packages publicitaires reçus. L'inégalité des intervalles de temps de réception des paquets est clairement visible. Cela indique une perte importante de paquets. L'intervalle de temporisation pour le périphérique BLE a été défini sur 20 ms.

(Cliquez pour agrandir) La

capture d'écran ci-dessous montre la représentation du périphérique BLE dans la fenêtre Bus Hound après le couplage avec un PC. Pour chaque service de périphérique, après l'homologation, un canal de communication logique apparaît. Ici, vous pouvez voir l'UUID de l'appareil et des services.

Analyseur de trafic BLE (renifleur) USB-KW40Z

Il s'agit d'un outil du kit de support de développement Kinetis. Je vais donc m'y attarder plus en détail. Page de renifleur NXP.

Le renifleur a été développé par NXP (ou plutôt l'ancien Freescale) et peut être acheté à peu de frais dans les magasins de composants radio en ligne populaires: Mouser, Digi-Key, Farnell ... Il est proposé par NXP comme un outil pour surveiller les paquets radio envoyés par les appareils BLE.

À l'aide de cet appareil, vous pouvez étudier la structure des paquets, les enregistrer dans un journal et analyser la densité du trafic. Le circuit renifleur est ouvert à l'étude, mais le programme du microcontrôleur est fourni sous forme de fichier binaire. Sniffer vous permet de filtrer les paquets par valeur d'adresse.

Vous pouvez télécharger le logiciel PC pour le renifleur par la requête de recherche suivante sur le site www.nxp.com - Kinetis_Protocol_Analyzer_Adapter.exe

Étant donné que le renifleur, en plus de la fonction principale, peut également être une plate-forme de débogage pour différentes applications, des fichiers binaires de micrologiciel de base y sont attachés, avec lesquels Vous pouvez restaurer la fonctionnalité de renifleur après avoir expérimenté. Les fichiers sont fournis avec le package du logiciel de connectivité KW40Z , qui est téléchargé sur www.nxp.com pour la requête de recherche KW40Z_Connectivity_Software. Les fichiers seront appelés Sniffer_processing_core_usbkw40z_k22f.bin (pour le microcontrôleur MK22FN512 sur la carte sniffer) et Sniffer_radio_core_usbkw40z_kw40z.bin(pour le microcontrôleur MKW40Z sur la carte sniffer). Les fichiers sont programmés à l'aide des débogueurs SWD: JLink, STLink, OpenSDA ...

Côté PC, l'appareil est perçu comme un périphérique USB composite avec un port COM et un port de débogage selon la spécification, OpenSDA avec firmware CMSIS-DAP. Ainsi, dans l'environnement IAR, vous pouvez librement programmer et déboguer la puce renifleur MKW40Z en utilisant son autre puce MK22FN512 comme support pour la fonctionnalité de l'adaptateur de débogage. Mais les deux puces de la carte ont des connecteurs SWD standard pour un adaptateur de débogage externe.

Sniffer ne garantit pas la réception de tous les paquets transmis en direct. Il est facile de l'inonder, après quoi il cesse d'accepter les paquets, il est donc recommandé d'activer le filtrage par adresse afin de ne recevoir que les paquets du nœud d'intérêt avec un trafic assez rare.

La fenêtre suivante montre le programme d'analyseur de package. La fenêtre comprend l'interception sur les trois canaux:

(Cliquez pour agrandir)

Lors de l'installation du logiciel d'analyseur sur un PC, il crée un adaptateur Ethernet virtuel qui convertit les paquets capturés via le port COM virtuel du renifleur en paquets Ethernet. Dans mon cas, un tel adaptateur virtuel a automatiquement reçu un nom simple - Ethernet.
Pour voir les paquets, vous devez en outre installer le programme renifleur de paquets Ethernet Wireshark.

Vue de la fenêtre principale du programme Wireshark tout en surveillant le trafic. Wireshark décrit en détail tous les champs de bits du paquet de protocole de couche liaison (LE LL), cependant, après avoir établi une connexion entre les périphériques et démarré le protocole L2CAP, le contenu du paquet n'est pas reconnu car il est transmis crypté.