So verlängern Sie die Batterielaufzeit eines IoT-BLE-Gerätes

Das Internet der Dinge basiert auf Edge-Geräten, die Daten sammeln und an die Cloud senden. Normalerweise sind diese Geräte klein, batteriebetrieben und erfordern wenig Wartung. Benutzer stellen in der Regel hohe Erwartungen daran, was das Gerät leisten soll und wie lange die Batterie halten muss. Entwickler müssen daher vielen Anforderungen gerecht werden. Eine der wichtigsten davon ist ein möglichst geringer Stromverbrauch, um Benutzern eine optimale Batterielebensdauer zu liefern.

In diesem Artikel werfen wir einen genaueren Blick auf das L-Tek FF1502, ein auf Bluetooth Low Energy (BLE) basierendes Sensortag, das als Broadcaster oder auch Beacon, arbeitet. Beacons sind typischerweise Geräte mit einer geringen Leistungsaufnahme, die sich die meiste Zeit im Ruhemodus befinden und kurz aufwachen, um Nachrichten an in der Nähe befindliche tragbare elektronische Geräte (wie z. B. Mobiltelefone) zu übermitteln. Wir zeigen Ihnen, wie Sie die Batterielebensdauer einer auf dem Beacon laufenden Anwendung optimieren können. Dafür setzen wir den ULINKplus Debug-Adapter mit einer hochpräzisen Leistungsanalyse zusammen mit Arm® Keil® MDK ein.

Arm Keil MDK und ULINKplus

Keil MDK ist eine umfassende Softwareentwicklungslösung für Arm-basierte Mikrocontroller. Sie enthält alle Funktionen, die zum Entwickeln, Erstellen und Debuggen von eingebetteten Anwendungen erforderlich ist. Keil MDK ist ein leistungsfähiges und äußerst benutzerfreundliches Entwicklungssystem.

Die μVision IDE, die Teil von Keil MDK ist, bietet einzigartige Debugging-Funktionen, wenn sie in Verbindung mit dem Debug-Adapter der Produktreihe ULINK verwendet werden. Das neueste Mitglied dieser Produktreihe ist der ULINKplus, der eine isolierte Debug-Verbindung, Leistungsmessung und I/O für die Testautomatisierung kombiniert. Er liefert Einblicke in die Funktionen, das Timing und den Stromverbrauch eingebetteter Anwendungen.

ULINKplus ist einfach zu bedienen und kann mit Arm Cortex-basierten Geräten verbunden werden. Es unterstützt alle klassischen Debug-Funktionen wie einfache und komplexe Breakpoints, SWV-Trace und sogar Multi-Core-Debugging. Zusammen mit Arm Keil MDK, bilden die Funktionen Event Recorder und Event Statistics Anwendungen für Zeitplanung und Energieverbrauch ab. Der neue Systemanalysator in μVision korreliert zudem den Stromverbrauch mit Ereignissen, Threads, Unterbrechungen und Variablenänderungen, wodurch die Optimierung von stromfressendem Code noch einfacher wird.

Das L-Tek FF1502

Das L-Tek FF1502 verfügt über einen kompakten Formfaktor sowie eine XBee-kompatible Pinbelegung, die es zum idealen Baustein für IoT-Anwendungen macht. Das Gerät kann über eine einzelne Knopfzellenbatterie CR2032 oder über einen USB-Anschluss mit Strom versorgt werden. Es basiert auf dem Mikrocontroller der Baureihe nRF51822 von Nordic (Arm Cortex-M0-basiert) mit integriertem Bluetooth-Funkgerät. Verschiedene Sensoren sind per I2C mit dem Mikrocontroller verbunden:

• Temperatur- und Feuchtigkeitssensor (Si7020-A20)
• Lichtsensor (BH1750)
• Beschleunigungsmesser (MMA8653FC)
• Gyroskop (FXAS21002C)
• Magnetometer (MAG3110)

Der USB-Stecker und die Batterie CR2032 sind mit einem DC/DC-Schalter verbunden, der die gesamte Schaltung (einschließlich des Kondensator-Netzwerks) mit Strom versorgt.

Die Anwendung

Während der Laufzeit ruht die Anwendung die meiste Zeit, während sich die MCU und die Sensoren im Energiesparmodus befinden. Alle zehn Sekunden wacht es periodisch auf und liest die Sensoren (Temperatur, Feuchtigkeit und Licht) ab. Anschließend werden die Sensordaten per BLE übertragen und das Gerät fährt wieder in den Ruhezustand.

Referenz-Design

Im Folgenden wird das ursprüngliche Hardware- und Software-Design als „Referenzdesign“ bezeichnet. Die anfängliche Leistungsmessung zeigt den folgenden energieintensiven Zyklus (mit einer Dauer von 51 ms), der periodisch wiederholt wird (alle zehn Sekunden):

Laut dem System Analyzer von μVision beträgt die gesamte elektrische Ladung für den aktiven Zyklus:

Der Zyklus kann in folgende Phasen unterteilt werden:

• Auslösen von Sensoren über den I2C-Bus, um eine einzelne Messung zu starten
• Auslesen von Sensordaten über den I2C-Bus
• Übertragen der Sensordaten über BLE
• vor und nach dem Ruhemodus

Auslösende Sensoren

Die Sensormessung wird ausgelöst, indem Befehle über den I2C-Bus ausgegeben werden. Anschließend wird gewartet, bis die Daten bereit sind. Es gibt eine 4,2-mA-Stromspitze zu Beginn, wenn die MCU mit voller Geschwindigkeit läuft und über I2C kommuniziert. Dies wird erwartet, da sich der typische MCU-Laufstrom (gemäß dem Datenblatt der MCU) auf 4 mA beläuft. Danach wartet die MCU im Energiesparmodus etwa 20 ms lang ab. Der erwartete Strom, der von den Sensoren während der Messung benötigt wird (gemäß den Datenblättern der Sensoren), beträgt etwa 300 μA.

Daher scheint der tatsächliche Strom von etwa 1,6 mA zu hoch zu sein und sollte untersucht werden. Die gesamte elektrische Ladung zum Auslösen von Sensoren beläuft sich auf:

Auslesen von Sensordaten

Sensordaten werden im Polling-Modus über eine I2C-Verbindung gelesen. Die MCU ist während des gesamten Lesevorgangs aktiv, was dem gemessenen Durchschnittsstrom von 4,6 mA entspricht. Der gesamte Lesevorgang dauert jedoch etwa 19 ms, was aufgrund der geringen Anzahl ausgeführter I2C-Übertragungen lang scheinen mag.

Auf dieser Basis muss die Lesezeit untersucht werden und es sollte eine Alternative zum Abfragemodus, wie die ereignisgesteuerte I2C-Kommunikation, in Betracht gezogen werden.

Die gesamte elektrische Ladung zum Auslesen von Sensoren ist:

Eine ähnliche Analyse kann für die Ruhe- und die Sendephase durchgeführt werden. Da die Sendephase jedoch vollständig von der Funk-Firmware abhängt, die vom Siliziumhersteller bereitgestellt wird, besteht kein Optimierungsbedarf.

Software-Untersuchungen

Nach der Überprüfung der verschiedenen Ausführungsphasen der Anwendung können einige Probleme identifiziert werden, die weitere Untersuchungen erforderlich machen:

Ein unerwartet hoher Strom während der Sensor-Trigger-Phase

Aufgrund eines Fehlers in der Software wird eine zusätzliche I2C-Schreiboperation ausgegeben, die zu einer Erhöhung des Sensorstroms führt. Wenn dieser Code entfernt wird, fällt der Strom während der Sensorauslösephase von etwa 1,6 mA auf die erwarteten 300 μA ab. Dies reduziert die elektrische Ladung für die Triggering-Sensor-Phase von 33 μA auf 6,5 μAs.

Lange I2C-Übertragungszeit während der Lesephase des Sensors

Die lange I2C-Übertragungszeit wird durch denselben Softwarefehler verursacht, der den Sensorstrom erhöht und I2C-Taktdehnung durch den Sensor verursacht. Die Lesephase wird nach Entfernen des zusätzlichen I2C-Schreibvorgangs drastisch verkürzt. Dies reduziert die elektrische Ladung für das Auslesen der Sensordaten von 84 μA auf nur noch 8,3 μAs.

Ereignisgesteuerte I2C-Übertragungen im Vergleich zu Abfragemodi

Durch die Verwendung von ereignisgesteuerten I2C-Übertragungen kann die MCU in den Ruhezustand versetzt werden, während sie darauf wartet, dass die I2C-Übertragung abgeschlossen wird (anstatt mit voller Leistung zu arbeiten, während der I2C-Übertragungsstatus abgefragt wird). Dies reduziert den erforderlichen Strom während des Auslesens der Sensordaten. Der Einfluss ist jedoch aufgrund der bereits verkürzten I2C-Übertragungszeit gering.

Neu gestaltete Software

Die Software des Referenzdesigns wurde aufgrund von Erkenntnissen aus den Softwareuntersuchungen aktualisiert. Der I2C-Schreibfehler wurde behoben und die ereignisgesteuerte Kommunikation wurde eingeführt. Das neu gemessene Leistungsprofil zeigt den aktualisierten energieintensiven Zyklus, der jetzt bei 38 ms wesentlich kürzer ist.

Hardware-Untersuchungen

Die Messungen der Ruhephasen zeigen einen durchschnittlichen Strom von 13,6 μA, der höher ist als die erwarteten 9 μA (basierend auf den Datenblättern). Um das Problem zu isolieren, wird die Anwendung modifiziert, so dass die MCU sofort in den Energiesparmodus ohne jegliche andere Funktionalität (keine Sensorlesung oder BLE-Übertragung) geht. Dies führt zu Stromimpulsen mit einer durchschnittlichen Periode von 4,4 ms (wie in der Anwendung). Der Reststrom von 5 µA ist immer noch vorhanden.

Neu gestaltete Hardware

Das Hardwaredesign wird analysiert, um die Quelle des zusätzlichen Stromverbrauchs von 5 μA zu bestimmen. Die Analyse zeigt, dass dies durch den Sperrstrom der Schutzdiode D2 verursacht wird.

Der Austausch der ursprünglichen D2-Diode der Baureihe PMEG4005EJ gegen ein Modell der Baureihe PMEG6010CEH eliminiert diesen Strom fast vollständig (weniger als 0,2 μA), und der Gesamtstrom im Ruhemodus reduziert sich auf 8 μA.

Batterielaufzeit

Der FF1502 läuft über eine CR2032-Batterie mit folgender Kapazität:

Der FF1502 erfasst und sendet alle zehn Sekunden Sensorwerte. Um den Gesamtenergieverbrauch zu berechnen, kann Qref_active durch dieses Übertragungsintervall geteilt werden und liefert so den durchschnittlichen Stromverbrauch. Zusammen mit dem Ruhemodusstrom ergibt dies den Gesamtstromverbrauch.

Referenz-Design

Neu gestaltete Software und Hardware

Verdopplung der Batterielebensdauer

Die Optimierung eingebetteter Anwendungen für die Gesamteffizienz sollte ein wesentlicher Bestandteil des Entwicklungsprozesses sein, da es wichtig ist zu verstehen, wie Peripheriegeräte, Softwarealgorithmen und Energiesparmodi zusammenarbeiten. Um dies zu vereinfachen, haben wir ULINKplus entwickelt, einen universellen Debug- und Trace-Adapter, der eine Leistungsmessung umfasst. Zusammen mit Keil MDK gibt Ihnen diese Debug-Unit einen beispiellosen Einblick in den Betrieb Ihrer Mikrocontroller-Anwendungen. Die Lösung zeigt Ihnen, welche Teile Ihres Anwendungscodes mehr Strom verbrauchen, und hilft Ihnen dabei, den Einsatz energiesparender Konfigurationen zu überprüfen.

ULINKplus wurde für Softwareingenieure entwickelt und lässt sich leicht mit Zielhardware verbinden. Im Vergleich zu Oszilloskopen erfordert es keine komplexen Konfigurationseinstellungen und weist einen höheren Dynamikbereich auf, mit dem Sie kleine Stromunterschiede erkennen können. Es korreliert sogar die Leistungsmessung mit der Programmausführung, wenn Trace- oder Ereignisanmerkungen verwendet werden.

In diesem Beispiel haben wir gezeigt, dass die Reduzierung der Gesamtenergie, die von einer vorhandenen Anwendung genutzt wird, durch eine Optimierung von Software und Hardware absolut erreichbar ist. Tatsächlich wurde die ursprüngliche Lebensdauer der Batterie als Ergebnis der Optimierung mehr als verdoppelt. Erfahren Sie mehr über ULINKplus auf www.keil.com/ulinkplus

So verlängern Sie die Batterielaufzeit eines IoT-BLE-Gerätes Datum der Veröffentlichung: 15. Juni 2018 von Farnell