Ultra-Low-Power-Management des ESP32 für WiFi-IoT-Module nutzen

| Autor / Redakteur: Stefan Tauschek, Matthias Ahrens * / Michael Eckstein

Testaufbau: Unter realitätsnahen Betriebsbedingungen kommt das komplette Funktionsmodul im Idle-Modus mit lediglich 175 Mikroampere aus.
Testaufbau: Unter realitätsnahen Betriebsbedingungen kommt das komplette Funktionsmodul im Idle-Modus mit lediglich 175 Mikroampere aus. (Bilder: Macnica)

Entscheidend für eine lange Standzeit von IoT-Devices ist eine geringe Energieaufnahme im Idle-Modus, wenn also keine Daten gesendet werden. Der Mikrocontroller spielt eine wichtige Rolle dafür.

WiFi gilt als leistungshungrig. Das liegt jedoch weniger am IEEE 802.11-Protokoll als an der Art und Weise, wie WiFi implementiert wird. Konventionelle „High-Power“-WiFi-Geräte benötigen etwa 1 bis 17 Joule für das Übertragen von 1 MByte Daten. Mit diesem Energieverbrauch können selbst ineffiziente Implementierungen mit einem Satz AA-Batterien jeden Tag 1 MByte an Daten über eine Dauer von vier Jahren übertragen.

Bei Aktor-/Sensorknoten für das IoT, die relativ geringe Datenmengen in großem zeitlichen Abstand senden, ist vor allem die Zeit zwischen den „Bursts“ von entscheidender Bedeutung. Während dieser Phasen so wenig Strom wie möglich zu verbrauchen ist der Schlüssel für lange Batteriestandzeiten. Entscheidend dafür ist ein effizientes Power-Management im eingesetzten Controller. Heutzutage sind SoCs erhältlich, deren Management auf einen extrem niedrigen Stromverbrauch in solchen Idle-Phasen ausgelegt ist. Ein Beispiel ist der Espressif ESP32 SoC mit seinem Ultra-Low-Power-(ULP)-Coprozessor. Wir haben ihn einem Hands-on-Test unterzogen.

Stromverbrauch mit dem ESP32-Wrover-Kit messen

Zum Messen des Stromverbrauchs eignet sich das ESP32-Wrover-Kit: In der 3,3-V-Spannungsschiene ist ein 0-Ohm Widerstand eingebaut. Wir messen über diesen Pfad den Stromverbrauch des gesamten Moduls, einschließlich des integrierten Flash- und PSRAM-Speichers. Im Deep-Sleep Mode des SoCs schaltet die Stromversorgung die Speicher ab, so dass diese nahezu keinen Strom ziehen. Das PSRAM auf dem Chip ist ein Serial-Pseudo-SRAM-Speicher mit 64 MBit Er wird über das Serial Peripheral Interface (SPI) angesprochen.

Der zusätzliche Arbeitsspeicher von 8 MByte kommt vor allem bei Audio-Anwendungen zum Einsatz. So ist das PSRAM beispielsweise zum Betrieb von Alexa-Voice-Service-Applikationen erforderlich. Im normalen Betriebsmodus des SoCs verbraucht es etwa 400 µA, auch wenn nicht gelesen oder geschrieben wird. Nur im Deep Sleep ist es komplett spannungslos geschaltet. IoT-Applikationen mit Sensorabfragen, Aktor-Betätigungen und einer Handvoll TCP/IP-Protokollen kommen ohne PSRAM aus. Hier reicht ein ESP32-Wroom-Modul.

Der ULP ist ein recht einfacher, hocheffizienter Coprozessor, der auch in der Deep-Sleep-Betriebsart des Haupt-SoCs aktiv bleibt. So können Programme verarbeitet werden, die im RTC-Memory gespeichert sind. Der ULP kann dabei auf Peripherieeinheiten zugreifen, auf interne Sensoren und RTC-Register und damit den Hauptprozessor bei bestimmten Ereignissen oder Parameterveränderungen aufwecken – etwa bei steigenden Temperaturen. Der Coprozessor verfügt über 8 kByte SRAM für Instruktionen und Daten und wird vom RTC_FAST_CLK mit 8 MHz getaktet. Er ist in allen Power-Save-Betriebsarten, also “Light Sleep” und “Deep Sleep” aktiv und kann den SoC aufwecken sowie einen Interrupt schicken. Er beinhaltet 4 General-Purpose-Register R0 - R3 zum Handling von Daten und Speicherinhalten. Weiterhin verfügt er über ein 8-Bit-„stage_cnt“-Register für die ALU (Arithmetisch-logische Einheit) und zum Gebrauch bei JUMP-Instruktionen.

Von seiner Konstruktion her ist der ULP ein programmierbarer Zustandsautomat , also eine Finte-State-Machine (FSM). Wie eine General-Purpose-CPU verfügt er über einen Satz an Instruktionen zur Realisierung durchaus komplexer Mimiken und auch über einige Instruktionen speziell für RTC-Controller und für die Peripherie. Auf die 8 kByte SRAM-RTC-Memory können sowohl der ULP Co-Prozessor als auch die CPU zugreifen, daher wird er zum Speichern von Instruktionen für den ULP und zum Austausch von Daten zwischen ULP und CPU verwendet. Dabei hat der ULP auch Zugriff auf nahezu alle Module des RTCs, entweder über entsprechende Instruktionen oder über RTC-Register. Der ULP kann mittels Software gestartet werden oder periodisch durch einen Timer, die Programmausführung endet schließlich durch eine HALT-Instruktion.

Kurzes Programm versetzt ESP32 in den Tiefschlaf

Für unsere Verbrauchsmessungen haben wir ein Programm aus dem ESP32-IDF-Repository verwendet. Es versetzt den Controller für 20 Sekunden in den Deep-Sleep-Mode und weckt ihn über Timer oder Tastendruck wieder auf. Wahlweise kann auch konfiguriert werden, das SoC bei einem Temperaturanstieg über 5 °C zu wecken. Compiliert wurde die nur etwa 300 Zeilen lange Software innerhalb der Espressif-Entwicklungsumgebung. Unsere Messungen ergaben einen durchschnittlichen Stromverbrauch von 175 µA auf der 3,3-Volt-Schiene zum Modul. Dieses Ergebnis ist auch im Einklang mit Messungen anderer User aus der Espressif-Community, die noch etwas niedriger, nämlich bei etwa 150 µA liegen. Die Ursache dieser Differenz dürfte im aktiven Wakeup-Timer liegen, der zum regelmäßigen Aufwachen aus dem Deep-Sleep Mode notwendig ist. Das PSRAM des ESP32-Wrover-Modules scheidet als Ursache aus, das es genau wie das serielle FLASH im Deep-Sleep-Mode über einen Schaltausgang des ESP32 von der Stromversorgung getrennt wird.

In der Software ist auch die Abfrage des Temperatursensors über ADC deaktiviert. Dieser Schritt senkt den Stromverbrauch um etwa 25 µA gegenüber einem ersten Messwert von ca. 200 µA. Um nun eine Abschätzung zum Einsatz des ESP32 in einer batteriebetriebenen Anwendung geben zu können, gehen wir vom Einsatz einer kompakten Lithium-Batterie vom Typ CR123 mit einer Kapazität von 1.500 mAh aus. Dieser Batterietyp hat eine sehr geringe Selbstentladung von weniger als 1 % pro Jahr, so dass dieser Effekt vernachlässigt werden kann. Weniger elegant ist der Umstand, dass dieser Batterietyp 3 V Nennspannung besitzt und bis zum Ende der Standzeit auf etwa 1,8 V absinkt. Deswegen ist für den Batteriebetrieb auf jeden Fall ein Dual-Mode Spannungsregler nötig, etwa ein Ricoh RP600. Dieser gewährleistet eine konstante Versorgungsspannung unabhängig von der Eingangsspannung. Wir setzen für diese Umsetzung einen Wirkungsgrad von 90 % an. Die effektiv verfügbare Batteriekapazität sinkt auf 1.350 mAh (bei 22 °C).

Zum Abschätzen des Energieverbrauchs bei der WiFi-Übertragung gehen wir von einer stündlichen Datenübertragung mit einer Dauer von jeweils 1 Sekunde und einem Stromverbrauch von 140 mA aus. Grundsätzlich können solche WiFi-Bursts mit wenigen 100 Bytes einschließlich des Bootens eines RTOS (Echtzeit-Betriebssystems) innerhalb von etwa 100 ms durchgeführt werden. Wir nehmen jedoch für diese Abschätzung ein Worst-Case-Szenario an.Nun ergibt sich für den Deep-Sleep-Betrieb pro Tag 175 µA * 24 h = 4.2 mAh, für die Sendebursts 140 mA * 1 s / 3600 s/h * 24 = 0,93 mAh, in Summe also 5,13 mAh je Tag. Angesichts der gegebenen Batteriekapazität ergibt sich daraus eine Standzeit von 263,16 Tagen. Ein WiFi-Sensorknoten auf Basis eines ESP32 lässt sich also in diesem Modell etwa ein Dreivierteljahr mit einer Lithium CR123 Zelle betreiben – ein durchaus akzeptabler Wert.

* Stefan Tauschek ist Applikationsingenieur und Technologieberater bei Macnica,

* Matthias Ahrens ist Vertriebsingenieur für komplexe Halbleiterbeusteine bei Macnica

Kommentar zu diesem Artikel abgeben
Ich wäre echt froh, wenn es 2 Monate (wie hier erwähnt) wären. Ich nutze den ESP32 um die Werte...  lesen
posted am 16.04.2019 um 08:57 von Unregistriert

Der Ricoh RP600 braucht 780 + 50 µA Betriebsstrom. Damit kommen zu obiger Rechnung noch mal ~...  lesen
posted am 22.11.2018 um 12:25 von Unregistriert


Mitdiskutieren
copyright

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 45372856 / Mikrocontroller & Prozessoren)