Warum ist Enerbei der Wearablegieeffizienz -Entwicklung so entscheidend?
Share
Winzige-leiterplatte-ultrakompaktes-wearable-design

Ein Wearable mit 72-Stunden-Laufzeit bei 150-mAh-Zelle ist kein Marketingziel – es ist ein Systemdesign-Problem mit konkurrierenden Constraints: PCB-Footprint unter 4 cm², BLE-Konnektivität mit <15 ms Latenz, Hauttemperatursensor mit 1-Hz-Abtastrate, und ein BOM-Ziel von unter 18 € bei 5.000 Stück. Zwei grundlegend verschiedene Lösungspfade existieren: aggressive Hardware-Schlafstrategien mit ereignisgesteuerter Firmware, oder duty-cycled Kommunikation mit lokalem Datenpuffering. Beide erfordern, dass Low-Power-Design ab Revision 1 im Schaltplan verankert ist – nicht als Nachoptimierung.

Hardware-Design, Firmware-Architektur und Kommunikationsprotokoll bestimmen gemeinsam die Akkulaufzeit. Wer einen dieser drei Faktoren isoliert optimiert, verschenkt Potenzial auf den anderen zwei Ebenen.

Warum Energieeffizienz die Kernarchitekturentscheidung bei Wearables ist

Ein Wearable-Formfaktor begrenzt die Zellkapazität typischerweise auf 80–300 mAh. Bei einem durchschnittlichen Systemstrom von 5 mA ergibt das 16–60 Stunden Laufzeit – bevor Ladezyklen, Kapazitätsdegradation und Peak-Ströme beim BLE-Advertising eingerechnet werden. Jede Komponente, die 100 µA Ruhestrom über das Notwendige hinaus zieht, kostet bei 150 mAh rund 62 Stunden theoretische Laufzeit.

Ineffizienz erzeugt thermische Last direkt an der Haut. IEC 60601-1 begrenzt Oberflächentemperaturen für Körperkontaktflächen auf 41 °C im Dauerbetrieb. Ein schlecht dimensionierter LDO, der 200 mW in Wärme umwandelt, kann diesen Grenzwert auf einem 2-cm²-PCB überschreiten – mit direkten Zertifizierungskonsequenzen, nicht nur Komforteinbußen.

Energieeffizienz reduziert direkt die BOM-Kosten: Ein 80-mAh-Akku kostet bei 10K Stück ca. 0,60–0,90 €, ein 200-mAh-Pendant 1,40–2,10 €. Der Unterschied skaliert mit dem Volumen und beeinflusst gleichzeitig Gehäusedicke und Gesamtgewicht. Teams, die erst in der Validierungsphase auf Stromverbrauch optimieren, stehen vor Redesign-Zyklen von 6–10 Wochen – bei CE/FCC-Neuzertifizierung entsprechend länger.

Energieverbrauch nach Subsystem quantifizieren

OLED-Displays ziehen im aktiven Betrieb typischerweise 10–30 mA bei 1-Zoll-Diagonale, abhängig von Helligkeit und Bildinhalt. Bei einer durchschnittlichen Display-On-Zeit von 10 % des Tages ergibt das einen mittleren Beitrag von 1–3 mA zum Systemstrom – mehr als viele MCUs im normalen Betrieb verbrauchen. Wer das Display nicht per GPIO-gesteuertem Power-Rail abschaltet, sondern nur das Signal abschaltet, hält den OLED-Treiber im Standby mit 0,5–2 mA Ruhestrom.

BLE-Module verbrauchen im Advertising-Modus 0,5–3 mA im Peak, mit einem mittleren Strom von 10–150 µA je nach Advertising-Intervall. Bei 100-ms-Intervall und 0,5-mA-Peak über 0,625 ms ergibt sich ein mittlerer Strom von ca. 3 µA – bei 1000-ms-Intervall entsprechend weniger. Der häufige Fehler: Verbindungsparameter werden für Latenz optimiert, nicht für Energie. Ein Connection Interval von 7,5 ms statt 1000 ms erhöht den mittleren BLE-Strom um den Faktor 100.

Kontinuierlich betriebene Sensoren akkumulieren Ruhestrom. Ein PPG-Sensor für Herzfrequenzmessung zieht im Dauerbetrieb 1–5 mA. Wird er nur 2 Sekunden pro 30 Sekunden aktiviert, sinkt der mittlere Beitrag auf 67–333 µA. GPS-Module sind der kritischste Fall: 20–80 mA im Acquisition-Modus, und ein Cold-Start dauert 30–90 Sekunden. GPS im Dauerbetrieb in einem 150-mAh-Wearable bedeutet unter 2 Stunden Laufzeit.

Hardware-Architektur für minimalen Ruhestrom

Die MCU-Wahl bestimmt den Ruhestrom-Boden des Systems. STM32L4-Varianten erreichen 300 nA im Standby mit RTC, NXP LPC55S6x liegt ähnlich. Nordic nRF52840 kombiniert ARM Cortex-M4 mit integriertem BLE-Stack und erreicht 1,5 µA im System-Off-Modus mit RAM-Retention. Für Designs, bei denen BLE und MCU auf separaten Dies liegen, summieren sich Ruhestrombudgets – ein häufig unterschätzter Effekt bei Dual-Chip-Architekturen.

Spannungsversorgung: DC-DC-Wandler erreichen 85–95 % Wirkungsgrad, LDOs typischerweise 60–80 % bei typischen Wearable-Lasten. Bei 3,7-V-Zelle und 1,8-V-Versorgungsschiene mit 5 mA Last verliert ein LDO ca. 9,5 mW als Wärme, ein DC-DC-Wandler unter 2 mW. Auf 24 Stunden gerechnet entspricht das 228 mWh vs. 48 mWh Verlust – bei 150-mAh-Zelle und 3,7 V nominal sind das 555 mWh Gesamtkapazität. Der LDO-Verlust allein konsumiert 41 % der Kapazität als Wärme.

PCB-Layout beeinflusst Leckströme direkt. Pull-up-Widerstände auf ungenutzten I²C-Leitungen gegen VCC erzeugen bei 10 kΩ und 3,3 V kontinuierlich 330 µA – über alle unbenutzten Busse summiert ein relevanter Beitrag. Spannungsteiler für Batteriemessung mit 100-kΩ-Widerständen ziehen 33 µA dauerhaft; per GPIO-gesteuertem High-Side-Switch auf 0 µA im Schlafmodus reduzierbar. EMI-Filterkapazitäten auf Power-Rails erzeugen keinen Gleichstromverlust, beeinflussen aber das Einschaltverhalten von DC-DC-Wandlern und können Soft-Start-Zyklen verlängern.

Firmware-Strategien zur Laufzeitverlängerung

Interruptbasierte Verarbeitung statt Polling ist die Grundvoraussetzung für effektives Power-Management. Ein MCU im WFI (Wait For Interrupt) mit abgeschaltetem Peripherietakt verbraucht auf STM32L4 ca. 1 mA im Sleep-Modus gegenüber 5–10 mA im Run-Modus. Polling mit 1-ms-Tick-Rate hält den MCU dauerhaft im Run-Modus – der Unterschied ist kein Optimierungsdetail, sondern ein Faktor 5–10 im Stromverbrauch.

Zephyr RTOS bietet ein PM-Subsystem mit definierten Power-States (PM_STATE_SUSPEND_TO_IDLE bis PM_STATE_SOFT_OFF) und automatischem Tickless-Idle. FreeRTOS erfordert manuelles Implementieren des tickless Idle-Hooks und explizites Peripherie-Shutdown im Idle-Task. Der operative Unterschied: Zephyr abstrahiert Hardware-spezifische Sleep-Sequenzen über Device-PM-APIs, was Portierbarkeit erhöht, aber Latenz beim Aufwachen um 50–200 µs erhöhen kann – relevant für Anwendungen mit harten Echtzeitanforderungen unter 1 ms.

Batch-Verarbeitung reduziert die Anzahl der BLE-Verbindungsaufbauten. Statt jeden Herzfrequenzwert einzeln zu senden, puffert die Firmware 60 Sekunden Daten im SRAM und überträgt einmalig. Bei BLE-Verbindungsaufbau mit 3–5 mA über 50–100 ms ergibt das 60 Verbindungsaufbauten pro Stunde vs. einen – eine Reduktion des verbindungsbedingten Energieanteils um ca. 98 %. Der Trade-off: Datenverzögerung von bis zu 60 Sekunden, inakzeptabel für Echtzeit-EKG-Monitoring, akzeptabel für Aktivitätstracking.

Dynamische Taktfrequenzanpassung (DVFS) ist auf Cortex-M4-Klasse-MCUs verfügbar, aber der Energiegewinn ist nichtlinear: Halbierung der Taktfrequenz reduziert dynamische Verluste um ca. 50 %, statische Leckströme bleiben konstant. Bei modernen Ultra-Low-Power-MCUs dominieren statische Verluste unterhalb von 8 MHz Taktfrequenz – weiteres Heruntertakten bringt dann unter 10 % zusätzliche Einsparung.

BLE vs. Wi-Fi vs. NB-IoT: Protokollwahl nach Energiebudget

BLE 5.x im Advertising-Modus mit 1000-ms-Intervall erreicht mittlere Ströme von 3–15 µA. Im Connected-Modus mit 1000-ms-Connection-Interval und kurzen Datenpaketen 20–80 µA. Wi-Fi 802.11b/g/n im aktiven Betrieb: 80–300 mA, im DTIM-10-Power-Save-Modus 1–5 mA mittlerer Strom. Wi-Fi ist für Wearables mit unter 300 mAh Kapazität nur dann vertretbar, wenn Übertragungen auf unter 5 % Duty Cycle begrenzt werden können.

NB-IoT und LTE-M sind relevant für Wearables ohne Smartphone-Anbindung, etwa industrielle Lone-Worker-Devices oder medizinische Fernüberwachung. NB-IoT im PSM (Power Saving Mode) mit 24-Stunden-TAU-Timer erreicht mittlere Ströme unter 5 µA – vergleichbar mit BLE. Der entscheidende Unterschied: NB-IoT-Module kosten 4–12 € bei 10K Stück, BLE-integrierte MCUs 1–3 €. Dazu kommen SIM-Kosten und monatliche Konnektivitätsgebühren von 0,50–2 € pro Gerät, die bei 50.000 Einheiten über 3 Jahre einen siebenstelligen Betrag ausmachen können.

Ein bekanntes Fehlerbild bei BLE: Verbindungsabbrüche erzwingen Reconnect-Sequenzen mit erhöhtem Advertising-Strom über 5–30 Sekunden. In Umgebungen mit hoher 2,4-GHz-Interferenz (Produktionshallen, Krankenhäuser) können Reconnects mehrmals pro Stunde auftreten und den mittleren BLE-Strom um Faktor 3–8 gegenüber dem Laborwert erhöhen. Wer das Energiebudget im Labor validiert, ohne Interferenzszenarien zu testen, wird im Feld systematisch zu kurze Laufzeiten messen.

Typische Low-Power-Fehler mit messbaren Konsequenzen

Komponenten ohne dokumentierten Ruhestrom in der Stückliste sind ein Projektrisiko. Viele MEMS-Sensoren spezifizieren Ruhestrom nur für den typischen Fall, nicht für den Worst Case über Temperatur. Bei -10 °C bis 50 °C Betriebsbereich kann der Leckstrom eines MOSFET-basierten Power-Switches um Faktor 2–5 vom 25-°C-Datenblattwert abweichen. Für ein industrielles Wearable, das im Außenbereich eingesetzt wird, ist das kein Randfall.

Fehlende Abschaltlogik für zeitweise genutzte Peripherie ist der häufigste Einzelfehler in frühen Prototypen. Ein I²C-Umgebungslichtsensor mit 0,5 mA Ruhestrom, der nie per Power-Rail abgeschaltet wird, kostet 12 mAh pro Tag – bei 150 mAh Zellkapazität sind das 8 % der Gesamtkapazität für eine Funktion, die nur bei Display-On benötigt wird.

Zu späte Energiemessung im Entwicklungsprozess ist ein strukturelles Problem. Wer erstmals in der DVT-Phase (Design Validation Testing) systematisch mit einem Sourcemeter wie dem Otii Arc oder dem Nordic PPK2 misst, entdeckt häufig Ruhestrom-Anomalien, die Schaltungsänderungen erfordern. Jede Schaltungsänderung nach dem ersten PCB-Spin kostet 3–6 Wochen und 2.000–8.000 € für Neufertigung und Neuzertifizierung betroffener Module. Energiemessung gehört ab Prototyp-Revision 1 zum Standardprozess.

Eine verbreitete Annahme ist, dass ein niedrigerer MCU-Ruhestrom automatisch längere Akkulaufzeit bedeutet. Das gilt nur, wenn der MCU-Ruhestrom den Systemstrom dominiert. In einem typischen BLE-Wearable mit Display trägt die MCU im Sleep-Modus unter 5 % zum Gesamtverbrauch bei – die restlichen 95 % verteilen sich auf Display-Treiber, Sensorversorgung und BLE-Advertising. Wer ausschließlich die MCU optimiert, adressiert den falschen Engpass.

Wie Oxeltech energieeffiziente Wearables entwickelt

Energieeffizienz entsteht durch Designentscheidungen, die in jeder Projektphase getroffen werden: Komponentenauswahl in der Konzeptphase, Schaltungsarchitektur im Schematic-Review, Firmware-Struktur beim ersten Bring-up, und Verbrauchsprofiling in jeder Testiteration. Wer einen dieser Punkte überspringt, zahlt in späteren Phasen mit Redesign-Aufwand.

Oxeltech begleitet Wearable-Projekte von der ersten Systemspezifikation bis zur Serienreife mit integriertem Low-Power-Ansatz:

  • Komponentenauswahl mit dokumentiertem Ruhestrombudget pro Subsystem, auf Basis von ARM-Cortex-Architekturen, STM32L-Serie und Nordic nRF52/nRF53
  • Firmware-Entwicklung auf Zephyr oder FreeRTOS mit definierten Sleep-Wake-Sequenzen und messbaren Stromzielen pro Betriebszustand
  • Protokollauswahl nach Energieprofil, Latenzanforderung und Konnektivitätskostenmodell: BLE, NB-IoT, LTE-M oder LoRa
  • Systematisches Verbrauchsprofiling ab Revision 1 mit Otii Arc oder Nordic PPK2, mit dokumentierten Messwerten pro Betriebszustand
  • PCB-Layout-Review mit Fokus auf Leckströme, Power-Domain-Isolation und EMI-konforme Leitungsführung ohne zusätzliche Verluste

Über 20 Hardwareprodukte wurden von Oxeltech vom Konzept bis zur Serienproduktion begleitet, darunter medizinische Wearables mit IEC 60601-1-Anforderungen und industrielle Sensorsysteme mit 5-Jahres-Batterielebensdauer. Wenn Ihr Projekt definierte Laufzeitziele hat und Sie diese ab der ersten Revision systematisch verfolgen möchten, nehmen Sie jetzt Kontakt mit uns auf.

Subscribe Our Newsletter