BLE-Integration in Wearables scheitert selten an der Funktechnologie selbst. Die typischen Probleme entstehen beim Zusammenspiel von Connection-Parametern, Antennenplatzierung und Firmware-Architektur – unter den realen Randbedingungen eines batteriebetriebenen Geräts mit unter 500 mAh Kapazität, einem PCB-Footprint unter 4 cm² und einem Zertifizierungsbudget, das keine zweite Hardwarerevision erlaubt. Zwei Lösungspfade stehen dabei regelmäßig gegeneinander: ein proprietärer BLE-Stack mit maximalem Tuning-Spielraum versus ein zertifiziertes Softdevice mit eingeschränkter Flexibilität, aber kürzerer Time-to-Market.

Dieser Artikel behandelt die kritischen Entscheidungen bei der BLE-Implementierung in Wearables: Protokollarchitektur, Firmware-Stack-Auswahl, Energieoptimierung, Fehlerszenarien und Zertifizierungsrisiken – mit konkreten Zahlen und Bedingungen, unter denen die jeweiligen Empfehlungen gelten.

BLE-Konnektivität in Wearables: Protokollarchitektur und Systemrelevanz

BLE ist für Wearables nicht wegen seiner Reichweite oder Bandbreite relevant, sondern wegen seiner Duty-Cycle-Architektur. Das Funkmodul ist in den meisten Betriebsphasen inaktiv und wird nur für definierte Übertragungsfenster aktiviert. Bei einem Connection Interval von 500 ms und einem Übertragungsfenster von 1,25 ms liegt die Radio-Aktivzeit unter 0,3 % – was bei einem 3,0-V-System mit 10 mA Peak-Stromaufnahme im Schnitt unter 30 µA ergibt. Dieser Wert ist nur unter der Bedingung erreichbar, dass der restliche Systemstrom ebenfalls optimiert ist; ein MCU im Active Mode mit 5 mA dominiert dann die Energiebilanz vollständig.

Für Wearables, die dauerhaft in der Nähe eines Smartphones betrieben werden, ist BLE die einzige Funktechnologie, die gleichzeitig native Smartphone-Unterstützung, akzeptable Latenz und eine Akkulaufzeit im Bereich von Wochen ermöglicht. NB-IoT und LTE-M bieten direkte Cloud-Konnektivität, verbrauchen aber im Sendebetrieb 100–300 mA und erfordern SIM-Management sowie Mobilfunkzertifizierung – was bei einem Consumer-Wearable weder kostenseitig noch regulatorisch sinnvoll ist. Wi-Fi scheidet bei Coin-Cell- oder kleinen LiPo-Designs wegen des Einschaltstroms von 150–300 mA in der Regel aus.

Ein häufig übersehenes Risiko: Bluetooth 5.x-Features wie Long Range (Coded PHY) oder 2M PHY sind nicht automatisch auf allen Zielgeräten verfügbar. iOS unterstützt Coded PHY bis heute nicht vollständig. Wer Long Range für ein medizinisches Wearable einplant und das erst in der Systemvalidierung bemerkt, verliert 4–8 Wochen für eine Protokollrevision.

BLE-Protokollstack: Schichtarchitektur und Implementierungsrisiken

Advertising und Verbindungsaufbau

BLE-Peripheriegeräte senden Advertising-Pakete auf den Kanälen 37, 38 und 39. Das Advertising Interval ist konfigurierbar zwischen 20 ms und 10,24 s. Ein Intervall von 100 ms ist ein praxistauglicher Kompromiss: Der Verbindungsaufbau dauert typischerweise unter 200 ms, und der durchschnittliche Advertising-Stromverbrauch liegt bei etwa 15–25 µA auf einem Nordic nRF52-System. Bei 20 ms Intervall steigt dieser Wert auf 80–120 µA – relevant für Geräte, die dauerhaft im Advertising-Modus verbleiben, etwa Asset-Tracker ohne feste Verbindung.

Ein bekanntes Fehlerszenario beim Verbindungsaufbau: Wenn Central und Peripheral unterschiedliche Preferred Connection Parameter aushandeln und der Host (z. B. iOS) die vorgeschlagenen Parameter ablehnt, fällt das Gerät auf Default-Parameter zurück – häufig 30–50 ms Intervall mit hohem Slave Latency von 0. Das Ergebnis ist ein Energieverbrauch, der zwei- bis dreimal über dem projektierten Wert liegt, ohne dass ein offensichtlicher Fehler im Log erscheint.

GATT-Profile und Charakteristiken

GATT strukturiert die Datenkommunikation über Services und Charakteristiken. Standardisierte Profile – z. B. Heart Rate Service (0x180D) oder Battery Service (0x180F) – sind interoperabel und werden von iOS und Android ohne zusätzliche App-Entwicklung unterstützt. Proprietäre Profile bieten mehr Flexibilität, erfordern aber eine dedizierte App und schließen die direkte Integration in Drittplattformen aus.

Notifications sind gegenüber Polling die korrekte Architekturentscheidung für ereignisgesteuerte Daten: Das Peripheral sendet nur bei Änderung, das Central muss nicht aktiv abfragen. Der Fehler, der in der Praxis regelmäßig auftritt: Notifications werden aktiviert, ohne dass das Central den CCCD (Client Characteristic Configuration Descriptor) nach einem Reconnect erneut schreibt. Nach einem Verbindungsabbruch bleiben Notifications dann stumm, ohne Fehlermeldung – ein Datenverlust, der im Feld schwer zu reproduzieren ist und oft erst durch Nutzerberichte auffällt.

Energieoptimierung: Parameter, Mechanismen und Grenzen

Das Connection Interval ist der stärkste Einzelhebel für die BLE-Energiebilanz. Der konfigurierbare Bereich liegt zwischen 7,5 ms und 4 s. Für eine Herzfrequenzmessung, die einmal pro Sekunde aktualisiert wird, ist ein Intervall von 1 s ausreichend und spart gegenüber 50 ms etwa 85 % der Radio-Energie. Für eine kontinuierliche IMU-Datenübertragung mit 100 Hz sind kurze Intervalle unvermeidlich – hier muss die Energiebilanz über den Systemschlaf der MCU kompensiert werden, nicht über den BLE-Stack.

Slave Latency erlaubt dem Peripheral, eine konfigurierbare Anzahl von Connection Events zu überspringen, wenn keine Daten vorliegen. Bei einem Intervall von 100 ms und einer Slave Latency von 9 reagiert das Gerät im Ruhezustand nur alle 1 s, bleibt aber formal verbunden. Dieser Mechanismus reduziert den durchschnittlichen BLE-Strom auf unter 10 µA bei gleichzeitig kurzer Reaktionszeit bei eingehenden Daten. Die Einschränkung: Hohe Slave Latency verlängert die Latenz für Schreiboperationen vom Central zum Peripheral – relevant für Geräte, die Konfigurationsbefehle empfangen müssen.

Eine verbreitete Fehlannahme ist, dass der BLE-Stack die dominierende Stromkomponente im Wearable darstellt. Bei einem gut optimierten Design liegt der BLE-Anteil bei 10–30 % des Gesamtverbrauchs. Sensoren, Displays und MCU-Aktivphasen dominieren häufig die Bilanz. Wer ausschließlich den BLE-Stack optimiert und den Systemschlaf vernachlässigt, erreicht keine relevante Laufzeitverbesserung.

Technologievergleich: BLE gegen Wi-Fi, Zigbee, NB-IoT und klassisches Bluetooth

Die Wahl der Funktechnologie ist eine Systementscheidung mit direktem Einfluss auf Zertifizierungsaufwand, Stückliste und Firmware-Komplexität. Die folgende Einordnung gilt für batteriebetriebene, körpernahe Geräte mit Smartphone-Anbindung als primärem Use Case.

• BLE vs. klassisches Bluetooth: Klassisches Bluetooth (BR/EDR) ist für kontinuierliche Hochdatenraten ausgelegt – Audio, SPP-Profile. Der Ruhestrom liegt eine Größenordnung über BLE. Für sporadische Sensordaten unter 1 Mbit/s ist BR/EDR keine sinnvolle Option. Dual-Mode-Chips (z. B. nRF5340) ermöglichen beide Modi, erhöhen aber Stücklistenkosten um ca. $0,30–$0,60 bei 10K Units.
• BLE vs. Wi-Fi: Wi-Fi-Module (z. B. ESP32) kosten $1,50–$3,00 bei 10K Units, verbrauchen 150–300 mA im Sendebetrieb und erfordern eine WLAN-Infrastruktur. Sinnvoll für Wearables mit hohem Datendurchsatz oder direkter Cloud-Anbindung ohne Smartphone-Gateway – nicht für Standard-Consumer-Wearables.
• BLE vs. Zigbee: Zigbee-Mesh ist für stationäre Sensornetze in der Gebäudeautomation optimiert. Kein modernes Smartphone unterstützt Zigbee nativ. Für Wearables entsteht dadurch zwingend ein Gateway-Requirement, das die Systemarchitektur verkompliziert und die Zertifizierungslast erhöht.
• BLE vs. NB-IoT / LTE-M: NB-IoT und LTE-M sind für stationäre oder mobile IoT-Geräte mit direkter Netzwerkkonnektivität konzipiert. Modulkosten liegen bei $4–$8 bei 10K Units, zuzüglich SIM-Management und laufenden Datenkosten. Für industrielle Wearables ohne Smartphone-Nähe – z. B. Lone-Worker-Tracker – ist LTE-M eine valide Alternative. Für Consumer-Wearables ist der Overhead in Kosten und Zertifizierung nicht gerechtfertigt.

Hybridarchitekturen – BLE für die lokale Smartphone-Verbindung, NB-IoT oder LTE-M als Fallback für Außerbetrieb-Szenarien – sind technisch möglich, verdoppeln aber den Zertifizierungsaufwand und erhöhen die Stücklistenkosten um $5–$10. Diese Architektur ist nur dann gerechtfertigt, wenn der Use Case eine Konnektivitätsgarantie ohne Smartphone-Nähe explizit erfordert.

BLE-Firmware-Implementierung: Stack-Auswahl, GATT-Design und Sicherheit

Stack-Auswahl und RTOS-Integration

Die Stack-Entscheidung bestimmt den Zertifizierungsaufwand, den verfügbaren Flash-Speicher und die Portierbarkeit der Firmware. Nordic SoftDevice ist ein vorqualifizierter, binärer BLE-Stack für nRF-Chips. Er ist Bluetooth-SIG-qualifiziert, was die eigene Qualifizierungspflicht reduziert, schränkt aber den Zugriff auf Low-Level-Parameter ein und belegt 100–140 KB Flash. NimBLE (Apache) ist Open Source, vollständig konfigurierbar und läuft auf mehreren Plattformen – erfordert aber eine eigene Bluetooth-SIG-Qualifizierung, die je nach Umfang 4–10 Wochen und $5.000–$15.000 kosten kann. Zephyr RTOS integriert NimBLE und den BabbleBee-Stack nativ und wird von Nordic, NXP und STMicroelectronics offiziell unterstützt.

Die Entscheidung für Nordic SoftDevice ist sinnvoll, wenn das Design auf nRF52- oder nRF53-Chips festgelegt ist und die Qualifizierungslast minimiert werden soll. NimBLE auf Zephyr ist die bessere Wahl bei Multi-Chip-Strategie oder wenn tiefes Stack-Tuning erforderlich ist. Der Fehler, der Teams regelmäßig Zeit kostet: den Stack-Wechsel nach abgeschlossenem GATT-Design zu vollziehen. GATT-Definitionen und Sicherheitskonfigurationen sind stack-spezifisch genug, dass eine Migration 3–6 Wochen Nacharbeit erzeugen kann.

GATT-Design und Datensicherheit

GATT-Services sollten frühzeitig und vollständig spezifiziert werden – Änderungen nach Beginn der App-Entwicklung erzeugen Synchronisationsaufwand auf beiden Seiten. Für medizinische Wearables gilt: Proprietäre GATT-Profile, die personenbezogene Gesundheitsdaten übertragen, müssen mit AES-CCM-Verschlüsselung und authentifiziertem Pairing (LESC, Numeric Comparison oder Passkey Entry) gesichert sein. Ein unverschlüsselter BLE-Link überträgt Daten im Klartext und ist mit handelsüblichen Sniffern (z. B. Ubertooth One) passiv abhörbar. Unter MDR (EU 2017/745) und HIPAA ist das ein Zulassungsrisiko, kein akademisches Problem.

Bonding – das persistente Speichern von Pairing-Informationen – reduziert den Verbindungsaufbau-Overhead bei Reconnects. Die Einschränkung: Der NVM-Schreibzyklus für Bonding-Daten belastet den internen Flash. Bei häufigen Reconnects auf Geräten mit begrenzten Flash-Endurance-Zyklen (typisch 10.000–100.000 Zyklen je nach MCU) kann das nach 1–3 Jahren Feldeinsatz zu Datenverlust führen. Wer Bonding implementiert, muss den NVM-Wear-Pfad explizit im Design berücksichtigen.

Häufige Entwicklungsfehler und deren Systemauswirkungen

Die folgenden Fehler treten nicht vereinzelt auf – sie entstehen systematisch, wenn BLE-Parameter isoliert optimiert werden, ohne den Systemkontext zu berücksichtigen.

Falsch konfigurierte Connection-Parameter: Ein Connection Interval von 15–30 ms, gewählt zur Latenzsenkung, erhöht den durchschnittlichen BLE-Strom auf 200–400 µA. Bei einer 200-mAh-Batterie bedeutet das eine BLE-bedingte Laufzeit von unter 25 Tagen – unabhängig von allen anderen Optimierungen. Die korrekte Vorgehensweise ist, das minimale Intervall aus dem Datenrate-Requirement abzuleiten, nicht aus einer Latenz-Intuition.

Antennenplatzierung: BLE-PCB-Antennen (Chip-Antenne oder gedruckte Meanderstruktur) sind gegenüber Masseflächen, Metallgehäusen und dielektrischen Materialien wie dem menschlichen Gewebe sensitiv. Eine Chip-Antenne, die 2 mm von einer Massefläche entfernt platziert wird, verliert typischerweise 3–6 dB Gewinn – was die effektive Reichweite halbiert. Das Antennen-Keep-out muss im PCB-Layout von Anfang an reserviert werden; nachträgliche Korrekturen erfordern eine neue Layoutrevision und erneute RF-Qualifizierung (FCC/CE), was 6–10 Wochen kostet.

Verbindungsmanagement in der Firmware: Ein robustes Reconnect-Verfahren ist kein optionales Feature. Verbindungsabbrüche durch Körperbewegung, Interferenz im 2,4-GHz-Band (WLAN, andere BLE-Geräte) oder Smartphone-seitiges Verbindungsmanagement sind im Feldbetrieb die Regel. Firmware ohne expliziten Reconnect-Mechanismus und Datenpuffer verliert Messdaten und erzeugt inkonsistente Zustände, die im Labor nicht reproduzierbar sind. Das Testen dieser Szenarien erfordert systematische Fault-Injection – ein Schritt, den viele Teams bis zum Feldtest überspringen und dann mit Nutzerbeschwerden bezahlen.

Sicherheit als nachträgliche Ergänzung: BLE-Sicherheitsmechanismen – Pairing, Bonding, Verschlüsselung – nachträglich in ein bestehendes GATT-Design zu integrieren, ist aufwändiger als eine Neuimplementierung. Charakteristiken, die ohne Sicherheitsanforderungen definiert wurden, müssen neu spezifiziert, die App-seitige Pairing-Logik ergänzt und das gesamte Verbindungsverhalten neu getestet werden. Bei medizinischen Produkten unter MDR ist das zusätzlich ein dokumentierter Änderungsprozess mit Auswirkung auf die technische Dokumentation.

BLE-Entwicklung für Wearables mit Oxeltech

Oxeltech entwickelt BLE-fähige Wearables von der Systemarchitektur bis zur Serienreife. Der Fokus liegt auf Projekten, bei denen Energiebudget, Zertifizierungsanforderungen und Produktionsskalierung von Anfang an als Designparameter behandelt werden – nicht als nachgelagerte Optimierungsaufgaben.

Unsere Leistungen im Bereich Firmware- und Embedded-Software-Entwicklung umfassen:

• Stack-Auswahl und Integration (Zephyr/NimBLE, Nordic SoftDevice) mit Bewertung der Qualifizierungsimplikationen für FCC, CE und Bluetooth SIG
• GATT-Profildesign für standardisierte und proprietäre Services, inklusive Sicherheitsarchitektur nach MDR- und HIPAA-Anforderungen
• Optimierung von Connection-Parametern gegen ein definiertes Energiebudget und Latenz-SLA
• PCB-Antennendesign mit Keep-out-Spezifikation und RF-Validierung vor der Zertifizierungsphase
• Firmware-Architektur für robustes Verbindungsmanagement, Reconnect-Logik und Datenpufferung bei Verbindungsverlust
• Begleitung durch FCC Part 15, CE RED und Bluetooth SIG Qualification bis zur Produktfreigabe

Wenn Ihr Projekt konkrete Anforderungen an BLE-Performance, Zertifizierungspfad oder Energiebudget hat: Sprechen Sie direkt mit unserem Engineering-Team – ohne Vorgespräch mit dem Vertrieb.

Ähnliche Beiträge

• Wie sichert man die Datenübertragung in medizinischen Wearables ab?
• Wie wählt man den richtigen Mikrocontroller für ein IoT-Gerät aus?
• Was ist der Unterschied zwischen einem Wearable für Menschen und für Tiere?
• Was sind die größten technischen Herausforderungen bei der Wearable-Entwicklung?
• Was sind die häufigsten Designfehler bei der ersten Wearable-Hardware-Version?