BLE, Bluetooth Low Energy, oder Bluetooth Smart ist ein und das selbe und in aller Munde. Jedes modernere Smartphone hat zumindest Bluetooth 4.0 implementiert und könnte somit theoretisch mit einem BLE Gerät kommunizieren. Als Entwickler befinde ich mich gerade in der Situation, dass eine in die Tage gekommene Funkstrecke mit einem moderneren, energiesparenden Verfahren ersetzt wird. Also warum nicht mit BLE?

Das Protokoll, dass von der Bluetooth Special Interest Group als Bluetooth 4.0 definiert und später mit 4.1 aktualisiert wurde ist modular aufgebaut. Ein Hersteller eines BLE Peripherie Gerätes kann das Gerät so aufbauen, dass es für den Host (Mobiltelefon oder PC/Laptop) selbsterklärend ist, welche Daten es zur Verfügung stellt. Dazu werden im Protokoll Stack verschiedene Client/Server Strukturen angeboten. Somit ist es möglich ohne spezielle Software auf der Host-Seite ein BLE Peripherie Gerät zu verwenden. Dabei hat man sich auf eineige Profile geeinigt, die von der Bluetoth SIG veröffentlicht und betreut werden.

Da mein aktuelles Projekt nicht in sehr hoher Stückzahl produziert werden wird (< 10000 / a) lohnt es sich nicht die RF-Hardware selbst zu implementieren und zu zertifizieren. Für diesen Zweck eignet sich ein Modul, dass bereits alle Zertifizierungen im RF-Bereich mitbringt. Die Auswahl an marktreifen Modulen von diversen Anbietern ist groß und viele weitere sind angekündigt. Daher habe ich mich auf eine kleine Auswahl beschränkt.

Jedes dieser Module habe ich auf meinem Tisch liegen, oder mir näher anschauen können. Jedes Modul hat seine Vor- und Nachteile und spezielle Anwendungsgebiete.

Beginnen wir mit dem RFduino. Wie man an dem Namen schon erahnen kann, ist das Modul im Arduino-Universum angesiedelt. Es kommt mit einem Plugin für die Arduino-IDE und ermöglicht mit einer Bibliothek des einfachen Einstieg in die Entwicklung von BLE-Geräten. Die Einfachheit der Umgebung ist gleichzeitig auch das große Manko dieses Moduls. Wenn die Arduino IDE als Entwicklungunsumgebung verwendet wird, ist man auf die in der Bibliothek vorgegebene Funktionalität beschränkt. Vom ordentlichen Debuggen ganz zu schweigen. Mehr als ein printf() kann man dem Chip dann nicht abverlangen. Wenn jedoch der Arduino Bootloader mit einem J-Link überschrieben wird, kann man den Chip auf dem Board in vollem Umfang programmieren. Dann nicht mehr in der Arduino IDE sondern zum Beispiel in µVision und dem SDK von Nordic. Dass der RFduino allerdings in einigen Jahren noch lieferbar ist, ist zweifelhaft.

Das BL600 von Laird kommt mit einem etwas ungewöhnlichen Aufzug daher. Es wird nicht wie üblich cross-compiliert, sondern dem Modul wohnt ein BASIC Interpreter inne, der Skripte entweder zur Laufzeit, oder vorab als Bytecode interpretiert. Die Skripte werden in einem Teil des Flash-Speichers abgelegt und von dort dann auch Aufgerufen. Die Debug-Möglichkeiten halten sich hier auch begrenzt an ein printf(). Das Ausweichen auf eine richtige IDE mit SDK ist von Laird wohl nicht vorgesehen. Dafür ist der Einstieg mit der BASIC Programmiersprache wesentlich einfacher als bei den anderen Modulen. Die werden in C oder C++ programmiert und haben ein teilweise Echtzeit OS. All das bleibt dem BASIC Anwender verborgen.

Eines meiner favorisierten Lösungen ist das SaBLE-x von LSR. Das Modul bringt den Texas Instruments CC2540 mit, der der neueste BLE Chip von Texas ist und erst seit einigen Monaten auf dem Markt. Zusammen mit dem Fundus an Beispielen und Applikationen auf der Webseite von Texas Instruments, der kostenlosen IDE Code Composer Studio und dem XDS100v3 auf dem Evalboard steht einer erfolgreichen Entwicklung nichts im Weg.

Eines meiner favorisierten Lösungen ist das SaBLE-x von LSR. Das Modul bringt den Texas Instruments CC2540 mit, der der neueste BLE Chip von Texas ist und erst seit einigen Monaten auf dem Markt. Zusammen mit dem Fundus an Beispielen und Applikationen auf der Webseite von Texas Instruments, der kostenlosen IDE Code Composer Studio und dem XDS100v3 auf dem Evalboard steht einer erfolgreichen Entwicklung nichts im Weg.

SaBLE-x mit dem CC2640 auf einem kleinen Prototyp-Board

Das PAN1740 war eines der ersten Module, die ich getestet habe. Es hat im Gegensatz zu den anderen hier aufgezeigten Chipsätzen einen Dialog DA14580 an Board. Dieser besitzt kein Flash Speicher, sondern lediglich ein OTP ROM. Das bedeutet, dass jedesmal, wenn ein Update der Firmware gemacht werden soll das ROM weiter beschrieben wird, bis kein Platz mehr drauf ist und der Chip unbrauchbar. Während der Entwicklungsphase wird der Code im RAM getestet. Das Problem dabei ist, dass das Gerät nicht mit Batterie getestet werden kann, da bei einem Batteriewechsel der Code aus dem RAM verschwindet. Es fällt somit leider für meine Zwecke as.

Ein weiterer Favorit ist das PRoc von Cypress. PRoC steht für Programmel Radio on Chip und ist mit der PSoC (Programmable System on Chip) Familie von Cypress verbunden. Die Entwicklungsumgebung von Cypress, das PSoC Creator, ist eine hervorragende kleine IDE mit Code Generator, Compiler, Debugger und Online Hilfe.

BLE Grundlagen

Die obige Abbildung zeigt die Grundstruktur eines BLE Geräts. Jedes Gerät besitzt mindestens ein Profil. Dieses beinhaltet dann mindestens einen Service (GAP) und diese enthalten Charakteristiken, die Daten des Geräts. Schon zu Beginn wird klar, um BLE zu verstehen und zu Verwenden, müssen einige Begriffe geklärt werden. Es gibt bereits eineige umfangreiche Literatur [1] und viele Webseiten [2], die einen Einblick in BLE geben, daher hier nur das nötigste.

GAP, GATT

Das Generic Access Protocol (GAP) koordiniert das Advertising und die Datenübertragung, wenn keine Verbindung (Bonding) zwischen den Geräten besteht. Weiterhin leitet es bei Bedarf die Verbindung ein, kümmert sich um Authentifizierung und Verschlüsselung der Verbindung. Das Generic Attribution Profile (GATT) ist das Herzstück des Protokolls und kümmert sich um die einzelnen Charakteristiken und wie deren Daten übertragen werden. Es greift, sobald ein Bondig besteht und transferiert aus Charakteristiken und Descriptoren Daten anhand der UUID oder des Handles.  Um den Kommunikationsfluss zwischen Device (Peripheral) und Basis (Central) zu steuern wird der CCCS eingesetzt. Der Client Configuration Characteristic Server. Dieser ist eine GATT Characteristic, die angibt, welche Daten veränderlich sind, ob und wann geschrieben, oder gelesen werden darf, oder ob eine Notification stattfindet, sobald der Wert sich geändert hat. All das sieht auf den ersten Blick sehr komplex aus und alles Andere als Energiesparend. Allerdings kommt hier zu Gute, dass die Kommunikation über BLE ein verbindungsloses Verfahren ist, das bedeutet, dass der ganze Aufwand nur einmalig getrieben wird um eine Verbindung mit Verschlüsselung zu erzeugen und das Gerät kennen zu lernen. Wenn auf beiden Seiten dieses Bonding eingeleitet wurde, kann die Verbindung anhand der ausgehandelten Verbindungsparametern weitergeführt werden. Dieser Teil ist dann erstaunlich energiesparend. Eine Funkstrecke funktioniert nur dann, wenn auf beiden Seiten das Radio eingeschaltet ist. Der Empfänger kann nur dann die Daten empfangen, wenn der Empfangsverstärker eingeschaltet ist. Ebenso kann der Sender nur senden, wenn der Sendeversteärker eingeschaltet ist. Ein Mitteilen, dass eine Sendung folgt muss über die Funkstrecke geschehen und so ist es schwierig eine energiesparende Konfiguration zu wählen, wenn der stromhungigste Teil der Schaltung immer aktiv ist. Daher hadelt das BLE-Protokoll zu Beginn einer Verbindung eine Wiederaufnahmezeit aus, nach der sich das Central wieder bei dem Peripheral meldet. Zu diesem Zeitpunkt muss das Peripheral dann sein Radio eingeschaltet haben um auf Anfragen des Centrals am GATT Server zu hören. Das ganze klingt relativ komplex, wenn man aber einmal die grundlgende Struktur verstanden hat stellt sich BLE als simples Protokoll heraus, das darauf ausgelegt ist, möglichst wenig Daten in sehr kurzer Zeit über die Funkstrecke zu senden und dann den größten Teil der Existenz im Tiefschlaf zu verbringen.

Zwei Übertragungsarten

BLE besitzt im Grund zwei Arten der Datenübertragung. Eine unidirektionale, verbindungslose Übertragung von kleinen Datenmengen. Diese Werden in einem so genannten Advertisement Paket verschickt. Dieses Paket besitzt eine Länge von maximal 32 byte und überträgt eine festlegbare Payload. Diese beinhaltet zum Beispiel den Namen des Gerätes, die ID, oder um weche Art es sich handelt. Erzeugt und gehandhabt wird das Paket vom GAP Server. Hier wird dem Zuhörer mitgeteilt, welche Möglichkeitem für eine weitergehende Verbindung bestehen. Verbindungslos bedeutet aber auch, dass die 32 Byte ausgesendet werden, wenn gerade niemand zuhört. Somit besteht für das Peripheral keine Möglichkeit zu erkennen, ob die Daten empfangen wurden. Der Rückkanal ist normalerweise für eine gebondete Verbindung vorgesehen. Dennoch wurde im GAP eine Möglichkeit geschaffen, eine Empfangsbestätigung zu simulieren. Das Peripheral sendet ein Advertisement Paket mit Scanable Flag aus und wartet dann für kurze Zeit auf einen Scan Request.

Sobald ein Central ein Advertisement Paket mit diesm Flag empfängt, kann es diesen Scan Request abschicken und dem Peripheral so einerseits mitteilen, dass das Paket empfangen wurde, andererseits auch noch weitere Daten gewünscht sind. Der Scan Request selsbt kann keine Payload übertragen. Für eine echte Bidirektionale Verbindung muss dann auf eine GATT Verbindung mit Bonding zurück gegriffen werden. Soweit erst einmal zu BLE. Der zweite Teil folgt dann in Kürze und wird den GATT-Server sowie eineige Profile näher betrachten.

[1] Townsend, Getting Started with Bluetooth Low Energy: Tools and Techniques for Low-Power Networking (2014) http://www.amazon.de/gp/product/B00K1N23LA [2] Ti.com,TI Bluetooth Smart tutorial – How to get started part 1 (2013) https://training.ti.com/ti-bluetooth-smart-tutorial-how-get-started-part-1