Bluetooth
« | 18 Mar 2019 | »Ich erinnere mich noch an die alten Zeiten, wo wir mit Großmutter nach Brombeeren und Blaubeeren im Wald suchten und danach mit den blau gefärbten Zähnen Grimassen schnitten.
Das ist heute leider eine längst vergangene Geschichte, und obwohl es solche Beeren auch im Supermarkt zu kaufen gibt, es ist einfach nicht mehr das selbe wir damals mit Oma.
Doch dafür haben wir ja Bluetooth … die “andere” WLAN -artige Technologie, die uns (theoretisch) Freude bereiten sollte.
Bluetooth ist wie USB ohne Kabel.
So könnte man diesen drahtlosen Funkstandard vereinfachend beschreiben. Denn es gibt eine Vielzahl von Geräten die “Bluetooth können” obwohl die benutzten Datenpakete und Funktionsweisen ganz unterschiedlich sind.
So ähnlich ist das auch bei USB. Denn das interne USB-Datenaustauschprotokoll stellt nur sicher, dass mehrere angeschlossene Geräte in einer Sternarchitektur mit einem Host verbunden werden können und eindeutig adressiert werden.
Anwendungen gibt es viele, und jede sieht anders aus. Letztendlich kümmern sich Gerätetreiber um die eigentliche Funktion und erzeugen im Betriebssystem virtuelle Geräteinstanzen wie COM Ports, Soundkarten, Dateisysteme, Tastaturen, Mäuse und andere Ein- und Ausgabeformen.
Bluetooth macht das gleiche ohne Kabel, sendet ähnlich wie WLAN im 2.4 GHz Bereich und ist auf kurze Distanzen von 1 bis zu 10 Meter ausgelegt. (Es soll auch stärkere Signalspezifikationen geben, doch die habe ich nie in der Praxis zu Gesicht bekommen.) Von daher kann es beim gleichzeitigen WLAN Betrieb auch zu Überlagerungen kommen, doch beide Protokolle sind fair zu einander und lassen sich gegenseitig “leben”.
Programmiert wird Bluetooth normalerweise nicht über den Userspace, denn dort sind nur die virtuellen Geräte sichtbar. Man schreibt also Treiber für “sein” Bluetoothgerät und nutzt dann die entsprechenden anderen OS-APIs um das virtuelle Gerät zu bedienen.
Es gibt allerdings 2 Ausnahmen:
- Einerseits kann man das Scannen nach Bluetooth Geräten und das Verbinden
mit diesen per Code anstoßen.
Das Pairing (die Verbindung zwischen Computer und Endgerät) über die übliche 4-stellige PIN kann so automatisiert werden, weil jedes Geräte (ähnlich wie Netzwerk-Adapter) eine eindeutige MAC-Adresse hat und auch einen Vendor-Code und einen Typen-Identifizierer generisch zur Verfügung stellt. - RFCOMM ist ein Bluetooth-Unterprotokoll, welches (ohne spezielle Gerätetreiber) mehrere Datenkanäle zum Datenaustausch zwischen 2 Systemen bereitstellen kann. Und unsere Betriebssysteme überlassen uns den Zugang dazu über: YAY! Sockets!
Und somit kann man über RFCOMM bestehenden TCP/UDP Socket Code recyclen und über den Wechsel des Family-Flags von INET auf BTH relativ leicht seine eigenen Protokolle auf Bluetooth portieren.
Unter Windows kann man verbundene Bluetooth-Geräte über Setup-Device-Interface API auflisten, doch seit Windows XP SP2 liefert Microsoft auch eine eigene Bluetooth-API aus, die ähnlich zur FindFirstFile-API eine BluetoothFindFirstDevice Funktionsreihe bereitstellt.
Unter Linux habe ich bisher noch keine Programmiererfahrung mit Bluetooth sammeln können doch das werde ich hoffentlich in Zukunft mal nachholen können.
Im GATE Projekt ist die Windows-Bluetooth API im system Modul jedenfalls
implementiert. Neben Bluetooth existiert auch das moderne
Bluetooth LE,
das basierend auf dem BTH Standard 4.x eine erweiterte Spezifikation für
Geräte mit geringer Leistung bereitstellt und mit dem GATT Profile
(Generic Attribute Profile) eine neue Subprotokollspezifikation einführt,
die das generisch Auslesen und Verwaltung von Bluetooth LE Geräten
und Sensoren ermöglicht.
Doch dazu kommen wir ein anderes mal.