Einer der kritischsten Aspekte beim Programmieren batteriebetriebener Geräte ist die Kontrolle des Stromverbrauchs. Es reicht nicht aus, dass ein Programm gut funktioniert, während es mit der Entwicklungsplattform verbunden ist – die meisten Nutzer erwarten mindestens ein Jahr Batterielebensdauer, und Anfragen für 5–10 Jahre sind üblich.
Bevor wir unsere Anwendung einem breiten Publikum zur Verfügung stellen, ist es sehr wichtig zu messen, wie viel Strom die Anwendung verbraucht. Das Worst-Case-Szenario ist, dass das Gerät überhaupt nicht in den Deep-Sleep-Modus wechselt und die Batterie innerhalb von ein oder zwei Wochen entleert.
Das Messen des Stromverbrauchsprofils und des durchschnittlichen Stromverbrauchs war früher eine relativ aufwändige Aufgabe, die spezielle High-End-Ausrüstung im Wert von Tausenden von Dollar erforderte. Nordic Semiconductor hat die Hürde zur Überprüfung des Stromverbrauchs mit ihrem Power Profiler Kit gesenkt, das weniger als hundert Dollar kostet und bequem auf einem nRF52-Entwicklungsboard sitzt.
Um mit dem Profiling zu beginnen, modifizieren wir zunächst den RuuviTag ein wenig, um ihn mit dem Power Profiler zu verbinden. Drähte werden an die Batterieanschlüsse gelötet, und es werden absolut keine anderen elektrischen Verbindungen zum Device Under Test (DUT) hergestellt.
Ich lade das zu testende Programm in der Regel über den DFU-Bootloader auf das DUT hoch. So muss ich keine Drähte an das DUT anschließen und stelle außerdem sicher, dass das Programm, das ich teste, die gleichen Bedingungen hat wie Endnutzer, die das Image per DFU aufspielen. Das Programm, das wir hier testen, ist eine Work-in-Progress-Version des GATT-Profils für RuuviTag.
Das Power Profiler Kit läuft sowohl unter Windows als auch unter Linux, wahrscheinlich auch unter Mac OSX. Du solltest beachten, dass das Update 1.1.0 unter Linux nicht funktioniert – verwende stattdessen 1.0.0. Schauen wir uns an, wie der Stromverbrauch beim Booten aussieht.
Wir können sehen, dass es ungefähr alle 500 ms eine Stromspitze gibt. Das ist unser Beacon, der seinen Namen bewirbt und auf eine Verbindung wartet. Bis hierhin sieht’s gut aus. Zoomen wir auf die Grundebene und prüfen, wie effizient unser Sleep-Modus ist.
Hier können wir sehen, dass etwas nicht zu 100 % optimal ist. Der Sleep-Strom liegt vielleicht bei 10 µA, was deutlich höher ist als erwartet, wenn alles schläft. Der Sleep-Strom kann wahrscheinlich auf unter 3 µA reduziert werden. Die Optimierung des Stromverbrauchs ist jedoch Thema eines anderen Blogbeitrags.
Als Nächstes wollen wir prüfen, wie der Stromverbrauch durch das Herstellen der BLE-Verbindung beeinflusst wird.
Wir können sehen, dass es eine kurze Phase sehr dichter Stromspitzen gibt, während die Verbindung hergestellt und Parameter ausgehandelt werden. Diese Firmware hat sehr kurze Connection-Interval-Einstellungen, sodass nach dem Verbindungsaufbau viel Datenverkehr stattfindet.
Sobald die Verbindung hergestellt ist, können wir sehen, dass der Stromverbrauch von vorher 39 µA auf fast 64 µA gestiegen ist. Die Änderung betrug etwa 25 µA. Als Nächstes schalten wir den Umgebungssensor BME280 ein und lassen ihn im kontinuierlichen Modus mit 1 Sekunde Intervall zwischen den Messungen laufen.
Der Verbrauch ist um weitere 5 µA auf 69 µA gestiegen. Schauen wir uns an, wie sich das Einschalten des Beschleunigungssensors LIS2DH12 mit 10 Hz auf den Verbrauch auswirkt. Wir verwenden den internen First-in-First-out-Puffer des Beschleunigungssensors, um die Anzahl der Male zu reduzieren, die die MPU aufwachen muss, um die Daten zu lesen.
Der Stromverbrauch ist um weitere 7 µA auf 76 µA gestiegen. Schauen wir uns abschließend an, wie sich MPU-intensive Arbeit auf den Stromverbrauch auswirkt, indem wir eine IOTA-MAM-Nachricht erstellen.
Die IOTA-MAM-Erstellung ist deutlich als 5-mA-Spitze sichtbar, während der die MPU überhaupt nicht schläft. Es ist wichtig zu beachten, dass die MPU selbst nur ~4 mA verbraucht und die Aktivitäts-LED weitere 1 mA verbraucht. Da die MAM-Erstellung ein einmaliges Ereignis ist, können wir nicht wirklich einen durchschnittlichen Verbrauch für MAM berechnen. Wir könnten jedoch die Kosten von MAM in Energie ausdrücken: 8 Sekunden * 5 mA sind ungefähr 8 s * 5000 µA = 40.000 µAs oder 11 µAh. Um das in Perspektive zu setzen: Wir haben gerade in 8 Sekunden fast so viel Energie verbraucht, wie der Beschleunigungssensor und der Umgebungssensor zusammen in einer Stunde verbrauchen werden.
Eine weitere bemerkenswerte Entdeckung ist, dass das Versenden der Daten den Stromverbrauch nicht wesentlich erhöht: Der Tag verbindet sich mit der durch das Connection Interval definierten Rate, unabhängig davon, ob Daten zum Senden bereitstehen oder nicht.
Schauen wir uns abschließend an, wie der Grundverbrauch des Tags jetzt mit laufenden Sensoren aussieht:
Das Grundniveau liegt immer noch bei etwa 10 µA, also keine Überraschungen. Wir können jetzt Spitzen in etwa 100-ms-Intervallen sehen, was dem Beschleunigungssensor entspricht, der mit 10 Hz läuft.
Zusammenfassend:
- Grundverbrauch 10 µA
- Advertising 28 µA
- Verbindung 25 µA (zusätzlich zum Advertising)
- Umgebungssensor 5 µA
- Beschleunigungssensor 7 µA
- Gesamt 75 µA
Es ist jetzt offensichtlich, dass der größte Teil des Stromverbrauchs in unserer Anwendung von BLE-Funkübertragungen stammt. Insgesamt sind 75 µA nicht schlecht, allerdings können wir nur etwas über ein Jahr Lebensdauer mit einer CR2477 im RuuviTag erwarten, es sei denn, wir können den Stromverbrauch senken. Bleib dran für den Beitrag zur Stromoptimierung.