Erforschung der geheimnisvollen Welt von Bluetooth 4.2 Low Energy (BLE)

Heutzutage kann man den Eindruck haben, dass nahezu alles drahtlos und „smart“ ist. Wenn Ihr smartes Gerät nicht gerade damit beschäftigt ist, an DDoS-Angriffen auf Brian Krebs teilzunehmen, kann es Spaß machen, einen Blick unter die Haube zu werfen und nachzuschauen, wie das alles funktioniert. In dieser Folge von „Was Sie an einem Tag machen können“ werden wir uns (kostengünstig) mit Bluetooth Low Energy (BLE) amüsieren.

Bluetooth 4.2 Low Energy (BLE)

Was macht also BLE (oder auch Bluetooth Smart), wenn es zu Hause eingesetzt wird? Wenn Sie bereits ein Bluetooth-Veteran sind, können Sie diesen Abschnitt wahrscheinlich überspringen und direkt zu „Blick unter die Haube“ weiter unten gehen. Ansonsten schnallen Sie sich an für den Executive Précis™.

Die erste schöne Sache bei BLE ist, dass, obwohl es wie das Classic Bluetooth im lizenzfreien 2,4 GHz Frequenzband arbeitet, es sich tatsächlich um eine kleine Untergruppe von Bluetooth 4.2 mit unterschiedlicher Herkunft bezüglich der Kernspezifikation handelt (es wurde aus dem Protokoll „Wibree“ von Nokia entwickelt). Aus diesem Grund ist BLE nicht kompatibel mit Classic Bluetooth in Drahtlos-Anwendungen für kurze Distanzen.

Was BLE für Entwickler so attraktiv macht, ist seine Einfachheit (mit bedeutend weniger gesetzlichen Hürden, um ein Produkt zur Marktreife zu bringen) und sein Schwerpunkt auf geringe Leistungsaufnahme. BLE-Geräte verbringen die meiste Zeit schlafend. Wenn sie aufwachen, um Daten zu senden, verwenden sie ein sehr einfaches Link Layer, das für schnelle Verbindungen entwickelt wurde, und brauchen nur wenige Millisekunden (gegenüber 100 ms bei Classic Bluetooth) zur Übertragung von Nachrichten mit einstellbarer Länge und einem Tastverhältnis, das bei 0,1 % liegen kann. All dies ermöglicht einen unglaublich niedrigen Stromverbrauch und bedeutend länger haltende Akkus: Denken Sie eher in Jahren als in Stunden oder Tagen.

Abbildung 1

BLE teilt das 2,4-GHz-Band (2402 MHz – 2480 MHz) in 40 Kanäle (3 „Advertising“-Kanäle und 37 Datenkanäle) im Abstand von 2 MHz auf und verwendet dabei die GSFK-Modulation (Gaussian Frequency Shift Keying) und das adaptive Kanalsprungverfahren.

BLE-Verbindungen

Bei einer BLE-Verbindung gibt es zwei Akteure: ein Peripheriegerät und ein Zentralgerät. Das Peripheriegerät (üblicherweise irgendein Sensor oder Wächter) zeigt allen Geräten, die eventuell auf der Suche nach einer Verbindung sind, sein Vorhandensein auf den „Advertising“-Kanälen an. Das Peripheriegerät ist ein Protokoll-Slave, der einen Server zur Verteilung der von ihm erzeugten Daten betreibt. Das Zentralgerät (üblicherweise ein Smartphone oder Tablet) scannt die „Advertising“-Kanäle nach Peripheriegeräten, mit denen es eine Verbindung herstellen kann. Ein Zentralgerät ist ein Protokoll-Initiator, der einen Client zum Empfang der vom Peripheriegerät gesendeten Daten betreibt. Wie die Geräte in diesem Stadium miteinander interagieren, ist im Generic Access Profile (GAP) ganz genau festgelegt.

Sobald eine Verbindung hergestellt wurde, ist sie exklusiv (d. h., ein Peripheriegerät kann zur selben Zeit immer nur mit einem Zentralgerät verbunden sein), sodass das Peripheriegerät das Senden der Meldungen zu seinem Vorhandensein (das „Advertising“) stoppt. Das Zentralgerät legt die Verbindungsparameter zwischen sich und dem Peripheriegerät fest. Diese Interaktion wird vom GATT-Profil (Generic Attribute) festgelegt, das den Datenfluss steuert.

Abbildung 2

Dienste, Eigenschaften und ihre Deskriptoren werden gemeinsam als Attribute bezeichnet und sind durch Universally Unique Identifiers (UUIDs) gekennzeichnet.

UUIDs sind entweder 128-Bit-Werte (z. B. 126e4589-e87b-12d3-a456-926344550000), können aber auch 16-Bit-Werte (z. B. e87b) für Bluetooth SIG Standardprofile sein.

Das Zentralgerät findet heraus, welche Daten das Peripheriegerät anbietet, indem es eine Diensterkennung durchführt. Zurück erhält das Zentralgerät ein Profil, das im Wesentlichen einen Umschlag für einen oder mehrere Dienste (die angebotenen Datentypen) darstellt, die wiederum aus Eigenschaften bestehen (die optional über einen Deskriptor verfügen können). Sie können sich die Eigenschaften als Container für die Daten vorstellen, die wir haben möchten, während die Deskriptoren die Etiketten für diese Daten sind. Eigenschaften enthalten immer mindestens zwei Attribute: die Eigenschaftsdeklaration (die Metadaten über die eigentlichen Daten bietet) und den Eigenschaftswert (die eigentlichen Daten), die über ihre Handles adressiert werden. Keine Angst, das macht alles viel mehr Sinn, wenn wir uns etwas später mit unserem Beispiel aus der realen Welt beschäftigen.

Zur Unterstützung der Interoperabilität hat die Bluetooth Special Interests Group (SIG) eine Anzahl von Standardprofilen für verschiedene Anwendungstypen festgelegt. Es gibt Standardprofile für Umgebungssensoren, Herzfrequenz, Blutzuckermessung und Lokalisierung (zum Finden von verlorenen Schlüsseln usw.) und viele weitere Anwendungen. Natürlich können auch benutzerdefinierte Profile erstellt werden.

Betrachten wir als Beispiel das Heart Rate Profile. Dieses Profil hat zwei Dienste: den Dienst Heart Rate (Herzfrequenz) und den Dienst Device Information (Geräteinformation). Beim Dienst Heart Rate finden Sie eine Eigenschaft Herzfrequenz, eine Eigenschaft Körpersensorplatzierung und eine Eigenschaft Herzfrequenz-Steuerpunkt.

Blick unter die Haube

Für unseren kleinen Praxisversuch verwenden wir einen LattePanda mit einem Cypress CY5677 USB-Dongle als Zentralgerät. Unser Peripheriegerät ist ein Sensirion SHT31 Smart Humigadget für Feuchte- und Temperaturmessungen.

„Warum verwenden wir einen LattePanda?“, höre ich Sie schon denken. Dafür gibt es zwei gute Gründe: 1. Ich finde, er ist für einen PC mit Windows 10 für unter 100 £ ziemlich cool, und 2: Unsere kleine Exkursion beantwortet die übliche LattePanda-Frage, die da lautet: „Klar ist er cool, aber kann ich eigentlich irgendetwas Nützliches mit ihm machen?“ Unser Testaufbau sieht also folgendermaßen aus:

Erste Schritte

Laden wir zuerst die kostenlose Cysmart Software von der Cypress Website herunter.

 Sie müssen sich dazu bei der Site anmelden und die Akamai NetSession Interface Software einrichten, die Cypress als Download-Manager verwendet:

Abbildung 3

Stellen Sie nun sicher, dass .NET Framework 3.5 aktiviert ist, damit diese Software laufen kann:

1. Drücken Sie [Windows-Taste] + [R] auf der Tastatur, um das Fenster „Ausführen“ zu öffnen.
2. Geben Sie „appwiz.cpl“ in das Feld „Öffnen“ ein und drücken Sie die [EINGABETASTE].
3. Klicken Sie in dem sich nun öffnenden Fenster „Programme und Features“ links oben auf den Link mit der Bezeichnung „Windows-Features aktivieren oder deaktivieren“.
4. Das Fenster „Windows-Features“ öffnet sich. Stellen Sie sicher, dass die Option „NET Framework 3.5 (enthält .NET 2.0 und 3.0)“ aktiviert ist, und klicken Sie auf „OK“.

Nachdem Sie die Cysmart Software installiert und den Dongle in den USB-Port gesteckt haben, können Sie den gesamten Aufbau anwerfen. Vielleicht erfahren Sie aber auch (wie ich), dass der Dongle noch mit einer alten Firmware läuft:

Abbildung 4

In diesem Fall müssen Sie die PSoC Programmer Software herunterladen und installieren, um die Dongle-Firmware auf die neuste Version zu programmieren:

Starten Sie den PSoC Programmer.

1. Klicken Sie auf File (Datei) > Load (Laden) (oder drücken Sie [F4]), um die Hex-Datei zu laden.
2. Wählen Sie die Datei in C:\Program Files\Cypress\CySmart\1.2\dongle\CY5677\BLE_4_2_Dongle_CySmart_256K.hex
3. Klicken Sie auf File (Datei) > Program (Programm) (oder drücken Sie [F5]), um die Firmware zu programmieren.

Wenn dies alles erledigt ist, sind wir bereit, BLE in Aktion zu sehen.

Verwenden von Cysmart

Beim ersten Start der Software wird folgendes Fenster angezeigt:

Abbildung 5

Bevor wir die Schaltfläche „Start Scan“ (Scan starten) drücken, um zu sehen, mit welchen verfügbaren Geräten eine Verbindung aufgebaut werden kann, sollten wir sicherstellen, dass unser Sensorgerät Sensirion SHT31 sein Vorhandensein auf BLE bekannt gibt. Dies tun wir, indem wir die Taste auf der Vorderseite so lange drücken, bis „rFon“ auf dem LCD-Display zu sehen ist. Außerdem wird eine 4-stellige Zahl angezeigt, mit der das von uns verwendete Gerät identifiziert wird, wenn mehr als ein Gerät vorhanden sein sollte. So, lassen Sie uns nun einen Scan durchführen:

Abbildung 6

Sobald die Liste der verfügbaren Geräte angezeigt wird, können wir den Scan stoppen. Es sieht so aus, als ob sich außer unserem Peripheriegerät noch einige andere Bluetooth-Geräte (hauptsächlich Telefone) in der Nähe befinden. Wenn wir unser Smart Humigadget wählen, können wir uns anschauen, was es anzubieten hat.

Abbildung 7

Wenn wir uns die Registerkarte „Advertisement data“ (Werbungsdaten) auf der rechten Seite anschauen, sehen wir dort ein „Flags“-Datenbyte, über das Scangeräte erfahren können, welche Verbindungen zur Verfügung stehen. In diesem Fall wird ein 0x06 ausgegeben, das uns mitteilt, wenn wir auf die nachstehende Beschreibung schauen, dass das Humigadget im Bluetooth LE General Discovery Mode arbeitet und BR/EDR (Basic Rate/Enhanced Data Rate), d. h. die Bluetooth Kernspezifikation, nicht unterstützt. Das Gerät sagt mit anderen Worten: „Ich spreche BLE, aber nicht Classic Bluetooth“.

Wenn wir uns eines der Telefone in unserer Umgebung anschauen, sehen wir, dass es die gesamte Bluetooth-Spezifikation unterstützt und (da es „Simultaneous LE and BR/EDR to Same Device Capable“ [Controller + Host] unterstützt) es sich eher um ein Zentralgerät als um ein einfaches Peripheriegerät wie unser Humigadget handelt:

Abbildung 8

Wenn wir wieder zurückgehen und uns die Registerkarte „Scan Response Data“ (Antwortdaten scannen) für unser Humigadget anschauen, sehen wir, dass uns das Gerät hier seinen Namen mitteilt. Im ersten Byte sehen wir die „Characteristic Declaration“ (Eigenschaftsdeklaration). Dies sind die Metadaten, die dem Zentralgerät sagen, wie viele Daten sich in der Eigenschaft „Complete Local Name“ (Vollständiger lokaler Name) befinden: 0x11 (oder 17 dezimal) Bytes.

Abbildung 9

Wenn wir nun auf die Schaltfläche „Connect“ (Verbinden) klicken, können wir unsere exklusive Verbindung zum Humigadget herstellen:

Auf dem Display des Humigadget sehen wir, dass es nicht mehr die Meldungen zu seinem Vorhandensein („Advertising“) sendet. Um ein Profil des Humigadget zu erhalten, klicken wir auf die Schaltfläche „Discover All Attributes“ (Alle Attribute anzeigen). Es kann jetzt eine kleine Weile dauern, aber dann erhalten wir ein hübsches Profil zu unserem Humigadget:

Abbildung 10

Die Abbildung zeigt den Aufbau eines Profils. Rechts oben sehen wir den ersten Dienst, der im Profil deklariert wird. Dies ist ein primärer Dienst, der den Zugriff auf das Gerät regelt und (zusammen mit dem folgenden Dienst „Generic attribute“ [Generisches Attribut]) ein obligatorischer Dienst für BLE-Geräte ist. Innerhalb dieses Dienstes sehen wir die einzelnen Eigenschaften (und dass zu jeder Eigenschaft eine Deklaration gehört, gefolgt von Eigenschaftswerten, d. h. den Daten).

Wir sehen auch, dass jedes Attribut über ein inkrementierendes Handle adressiert wird und einen UUID (Universally Unique Identifier) besitzt. Da diese frühen Attribute alle zu den von Bluetooth SIG vordefinierten Attributen gehören, sind sie nur 2 Bytes (16 Bit) lang. Wie Sie sehen, erscheint der UUID 0x2803 mehr als einmal in unseren Bildern. Es handelt sich dabei um die zugeordnete UUID-Nummer für eine GATT-Eigenschaftsdeklaration.

Wenn wir jetzt auf die Schaltfläche „Pair“ (Koppeln) und dann auf „Enable All Notifications“ (Alle Meldungen aktivieren) klicken, wird unser Zentralgerät mit dem Peripheriegerät gekoppelt. Und wenn wir dann auf der Seite nach unten scrollen, sehen wir, dass unsere Daten aktualisiert wurden:

Abbildung 11

Natürlich werden die von unserem Zentralgerät empfangenen Rohdaten (blau hervorgehoben) vom Debugger im Hexadezimalformat angezeigt. Wenn wir sie normal lesbar machen wollen, müssen wir sie in der App umwandeln, die wir zum Auslesen der Daten auf einem Telefon oder Tablet erstellen.

Beachten Sie die 128-Bit-UUIDs für unsere Dienstdaten, da wir benutzerdefinierte Eigenschaften verwenden. Jede besteht aus einem 16-Bit-Dienst-UUID und dem Basis-UUID. In unserem Fall lautet der Basis-UUID 0000-xxxx-B38D-4985-720E-0F99-3A68-EE41 während die von uns verwendeten Dienst-UUIDs 0x1235 bzw. 0x2235 sind.

Schlussfolgerung

Es gibt natürlich eine Menge weiterer Erkundungsmöglichkeiten, die Sie ab hier durchführen können, und dann ist es nur noch ein relativ kleiner Sprung bis zum Kauf eines BLE-Entwicklungskits und der Erstellung Ihrer eigenen BLE-Anwendungen. Ich hoffe, dass diese kleine Einführung in BLE Ihr Interesse an dieser schönen neuen Welt geweckt hat. Die Hürden zur Teilnahme an dieser drahtlosen Revolution wurden hinsichtlich des benötigten technischen Fachwissens und der verbundenen Kosten beträchtlich gesenkt. Was hält Sie jetzt noch auf?