Einleitung

Irgendwann entsteht der Wunsch, den ESP vom Steckbrett zu befreien und ihn sinnvolle Tätigkeiten im Heimnetzwerk erledigen zu lassen. Dabei stellt sich die Frage nach der Stromversorgung. In vielen Fällen lassen sich Geräte nur im Batteriebetrieb sinnvoll versorgen.

Ein ESP32 gönnt sich bei eingeschaltetem Radio-IF ca. 100mA. Eine 3,3V-Batterie mit einer Kapazität von 1000mAh wäre damit 2x täglich zu wechseln. Das ist natürlich völlig inakzeptabel. Batteriestandzeiten von >= 1 Jahr sollten angestrebt werden.

Der ESP32 kennt verschiedene Stromsparmodi. Für Sensoren oder Melder, die in größeren Zeitabständen Daten zu übertragen haben, ist der Deep-Sleep-Modus eine geeignete Wahl.
Ein Großteil der internen Komponenten wird dabei spannungslos geschaltet. Lediglich ein Teil der RTC-Einheit bleibt in Betrieb. Das genügt, um den Chip zeit- oder ereignisgesteuert aufzuwecken.
Aktiv bleiben der CoProzessor-Timer, mit dem sich der ULP-Prozessor in definierbaren Zeitintervallen starten lässt, sowie die RTC-RAM-Blöcke, in denen der ULP-Programmcode und Daten des Hauptprogramms die Tiefschlafphasen überdauern.
Die Angaben zum Stromverbrauch differieren zwischen 6 und 10µA. Lässt man andere Faktoren außer Acht wären mit o.g. 1000mAh-Batterie Standzeiten von >10 Jahren möglich (theoretisch !).
Dies soll nur die mögliche Spanne zwischen 10 Stunden(Vollbeschäftigung) und 10 Jahren(tut garnix) zeigen. Dazwischen gilt es, ein vernünftiges Maß zu finden und HW-/SW-Desing darauf zu optimieren.

Allerdings kann ein ESP nicht per Radio-IF aus dem Tiefschlaf geweckt werden. Geräte, die ständig empfangsbereit sein müssen, lassen sich mit begrenztem Batteriebudget nicht realisieren.

Ein Wort zur Hardware vornweg. Stromsparende Schaltungen lassen sich nicht mit NodeMCU und anderen Entwicklungsboards bauen. Der schaltungstechnische Overhead, der später nichts zur Funktion beiträgt, zieht nur unnötig Strom. Eine Ausnahme bilden Boards, die in jüngerer Zeit auf den Markt gekommen sind bzw. angekündigt wurden und speziell auf's Stromsparen getrimmt wurden. Andernfalls sollte man zu Breakoutboards mit minimaler Außenbeschaltung oder WROOM-Modulen greifen.

Software-Design (Deep-Sleep)

Der obige Vergleich zeigt, dass die erreichbare Batteriestandzeit erheblich von der Laufzeit des Hauptkerns incl. Datenübertragung abhängt.
Als Beispiel soll ein einfacher Temperatursensor mit dem DS18B20 dienen. Messung und Datenübertragung erfolgen in 5min-Intervallen. Die Kommunikation auf dem One-Wire-Bus und Bereitstelung der Daten übernimmt der Co-Prozessor.
Betrachtet wird die erforderliche Batteriekapazität bei einer Laufzeit von 1 Jahr = 8760h und 100.000 Messzyklen (100kCycles). Die Stromaufnahme wurde über in Reihe geschaltete Shunt in der 3,3V-Versorgung des ESP ermittelt.
Bei den Energiebetrachtungen wird von einer Direktversorgung aus einer stabilen 3,3V - Batterie ausgegangen, die aber (wie weiter unten zu sehen) nur bedingt realisierbar ist.

Ein Betriebszyklus lässt sich in fünf Phasen einteilen. Diese sollten zur Optimierung getrennt betrachtet werden.
Angenommen, das System wurde in einem ersten Zyklus bereits initialisiert und in den Tiefschlaf geschickt, dann ergibt sich folgender Ablauf:

Deep-Sleep

In dieser Phase werden die RTC-Mem-Blöcke und der Timer des CoProzessors mit Spannung versorgt. Der ULP-Prozessor hat sich selbst über einen HALT im letzten Zyklus zur Ruhe begeben. Messen lässt sich die Stromaufnahme über einen 10kΩ Shunt. Während der Initialisierungsphase wird der Widerstand überbrückt. Ein Wert von 10mV entspricht 1µA. Die erwartete Messgröße von 10µA lässt sich so mit einem vernünftigen Voltmeter hinreichend genau bestimmen.
Messungen an einigen Exemplaren haben die Herstellerangaben bestätigt. Stromaufnahmen von 6-8µA sind realistisch.
Damit liegt der Jahresverbrauch dieser Phase bei ca. 70mAh (230mWh).

Es lohnt sich, diesen Wert in der eigenen Schaltung nachzumessen. Designfehler in Hard- oder Software, die nicht auf den ersten Blick erkennbar sind, können zu deutlich höheren Werten führen.

Beispiel: Zur Vermeidung von UART-Logout während des Bootprozesses kann GPIO15 über 10kΩ nach Masse gezogen werden. Dies spart Zeit. Dieser Pin muss dann allerdings im Hauptprogramm vor dem DeepSleep hochohmig geschaltet werden. Auch andere Ports, die mit eigener HW belegt sind, können unerwartete Ableitströme verursachen.

    //allgem. Stromsparmaßnahmen
    rtc_gpio_isolate(GPIO_NUM_12);
    rtc_gpio_isolate(GPIO_NUM_15); 

ULP-Programm

Im untersuchten Beispiel wird die aktive Phase durch den zeitgesteuerten Start des ULP-Programms eingeleitet. Der Programmcode wurde in der Initialisierungsphase einmalig in den RTC-SLOW-MEM geladen. Solange Spannung anliegt und das System fehlerfrei arbeitet, bleiben die Daten in diesem Speicherbereich erhalten.

Per OWP-Protokoll wird der DS18B20 zu einer Temperaturmessung veranlasst. Zur Bereitstellung der Daten benötigt er ca. 700ms. Auslesen der Daten und CRC-Prüfung erledigt wieder der ULP-Prozessor.

Der Vorgang dauert ca. 710ms. Die Stromaufnahme des ESP beträgt währenddessen 420µA. Nach 100kCycles liegt der Jahresverbrauch bei ca. 8.3mAh (27.3mWh).
Der Strom auf der Datenleitung des Sensors spielt keine signifikante Rolle. Der DB18B20 selbst gönnt sich während des Messvorgangs zusätzlich etwa 0,5mA auf der 3,3V-Leitung. In allen anderen Phasen ist er äußerst genügsam.

Kanal A(gelb) zeigt den Stromverlauf, gemessen über einem 360Ω-Shunt. Kanal B(blau) wird über einen Debug-Port zur Abgrenzung der Phasen gesteuert.
Der WAKE-Befehl ist in diesem Beispiel auskommentiert, sodass der Chip sofort wieder in den Tiefschlaf fällt. Mit dem Spannungsabfall über dem Shunt würde die nächste Phase nicht funktionieren.
Viel ist dem Oszillogramm nicht zu entnehmen. Es zeigt lediglich eine konstante Stromaufnahme über die gesamte Phase. Der ULP-Prozessor arbeitet während >90% der Zeit den WAIT-Befehl ab. Dem Bild lässt sich entnehmen, dass damit keine Leistungsreduzierung verbunden ist.

420µA bei 3.3V entspricht einer Leistungsaufnahme von 1.4mW. Das wäre für einen Dauerbetrieb noch recht hoch. ULP-Messungen in kürzerer Folge und das Aufwecken des Hauptprozessors nur bei signifikanten Änderungen der Messwerte wäre aber möglich.

Die ULP-Phase ist optional. Je nach Anwendungsfall kann das Aufwecken des Hauptsystems auch aus zahlreichen anderen Quellen erfolgen.

Die Arbeit des Co-Prozessors ist aber nicht auf die Tiefschlafphase des Hauptkerns beschränkt. Zeitkritische Steuerungen lassen sich damit in Echtzeit ausführen, ohne Gefahr zu laufen, von einem höher priorisierten Task unterbrochen zu werden.

Deep Sleep Wakeup

Unmittelbar nach Erwachen aus dem Tiefschlaf, noch vor dem zeitraubenden Booten, führt die Applikation einen Deep Sleep Wake Stub aus. In diesem Codeblock lassen sich bspw. Messvorgänge starten, Spannungsregler hochtasten oder Entscheidungen treffen, ob der Vorgang fortgesetzt oder der Chip sofort wieder in den Tiefschlaf geschickt wird.

Zum Zugriff auf diesen Code-Block muss im Haupt-Quelltext lediglich folgende Funktion eingefügt werden:

void RTC_IRAM_ATTR esp_wake_deep_sleep(void) {
    esp_default_wake_deep_sleep();
    // Add additional functionality here
}

Das Attribut RTC_IRAM_ATTR sorgt dafür, dass der Code nach einem allgemeinen Reset in den RTC Fast Memory geladen wird, in dem er den Deep Sleep überdauert und nach dem Aufwachen sofort ausgeführt werden kann.
Innerhalb dieser Funktion muss esp_default_wake_deep_sleep() aufgerufen werden. Damit wird das Booten verzögert, um dem Flash-Chip zusätzliche Zeit zur Initialisierung zu geben. In der Config "ESP32_specific" lässt sich eine Zeitspanne von 0-5000µs einstellen.

Das Ganze hat allerdings auch einen Haken. Zu diesem Zeitpunkt sind die Bibliotheken des Framework noch nicht geladen. Daher kann nur auf fest im Chip vorhandene ROM-Funktionen zurückgegriffen werden. Die Dokumentation hierfür fällt etwas spärlich aus. Nutzbare Funktionen sind in den Header-Files zu finden.

$IDF_PATH/components/esp_rom/include/esp32/rom/

GPIOs lassen sich über vordefinierte Makros setzen (s. gpio.h). Oft wird man aber auf direktes Lesen und Schreiben von Registern zurückgreifen müssen.

Ohne Einfügen der Funktion in den Quelltext läuft im Hintergrund lediglich die Boot-Verzögerung ab. Eine Kürzung der voreingestellten Zeit (2ms) hätte bei den Energiebetrachtungen keinen praktischen Nutzen, könnte aber zu Instabilitäten des Systems führen.

Boot-Prozess

Der Programmcode des Hauptkerns wird im IRAM ausgeführt, Daten lagern größtenteils im DRAM. Beide Speicherblöcke verlieren während der Tiefschlafphase ihren Inhalt, da sie nicht mit Spannung versorgt werden.

Der ESP-Chip selbst besitzt nur einen kleinen ROM-Bereich, in dem der Bootloader und rudimentäre SW-Schnittstellen untergebracht sind. Nach dem Start des Hauptkerns müssen Code und Daten erst aus dem Flash-ROM geladen werden. Der Vorgang ist vergleichbar mit dem Booten eines PC von einer Festplatte und dem Nachladen von Anwenderprogrammen.

Um das Booten selbst muss man sich nicht kümmern. Toolchain und Flashprozess haben dafür gesorgt, dass alles an passender Stelle landet und der Bootprozess nach einem Reset automatisch abläuft.

Allerdings kostet dieser Vorgang Zeit, in der sich das ESP-Modul mit etwa 30mA aus der Batterie bedient.

Der Vorgang lässt sich durch Ändern von Systemvariablen in der SDK-Configuration des Projektes erheblich beeinflussen.
Die Dauer hängt natürlich auch von der Größe des zu ladenden Datenblocks ab. Im Beispielprogramm dauert das Booten unter Verwendung der Voreinstellungen 266ms bei einer durchschnittlichen Stromaufnahme von 32mA. Das ergibt bei 100kCycles einen Bedarf von 236mAh (780mWh). Ein recht hoher Wert, in Anbetracht der Tatsache, dass während dieser Zeit keine nützliche Arbeit durch die Hauptprozessoren verrichtet werden kann. Aber wie gesagt, es gibt Schrauben, an denen gedreht werden kann.

Der größte Gewinn steckt in der Option zur Datenvalidierung nach einem DeepSleep, zu finden in der Abteilung Bootloader config. Mit Auswahl dieser Option verkürzt sich die Bootzeit auf 42ms (!) bei 27,5mA.

Der Datenaustausch zwischen externem Flash und ESP-Chip erfolgt seriell per SPI-Interface. Espressif lässt den Modulherstellern die Wahl, ob die Anbindung über 2 oder 4 Leitungen erfolgt. Letzendlich kauft man immer ein Überraschungspaket, denn von außen sieht man dem Modul nicht an, was sich unter der Metallkappe verbirgt.
Die Auswahl wieviele Adress-/Datenleitungen das System nutzen soll, wird wieder in der SDK-Configuration getroffen. In der Abteilung Serial flasher config lässt sich die Breite des Busses umstellen. Per Default ist dort DIO gewählt.

Welcher Flash-Chip nun aber verbaut ist, lässt sich, wenn überhaupt nur sehr umständlich ermitteln.

esptool.py flash_id

In einer weiteren Option lässt sich der SPI-Takt ändern. Die Erhöhung von 40 auf 80MHz verringert zwar die Ladezeit auf 29ms, erhöht aber auch den Strombedarf auf durchschnittlich 30mA. Das bringt unter dem Strich wenig, erhöht aber das Risko, dass man sich außerhalb der Chip-Spezifikation bewegt und das System unter veränderten Umgebungsbedingungen instabil wird.

Unterm Strich benötigt der Bootprozess nach Optimierung 26mAh (86mWh) bei 100kCycles.

Das Oszillogramm zeigt die Stromaufname nach Optimierung bei 40MHz SPI-Takt. Die Bootphase wird durch den Low-Pegel des B-Kanals markiert. Die Stromaufnahme wurde über einen 1Ω-Shunt gemessen und über diesen Zeitram gemittelt.

Hauptprogramm

Nach dem Bootprozess startet das Hauptprogramm. Als Beispiel muss wieder das Wifi-Station-Example herhalten. Kleine Änderung: Das Programm wir hier zum Abschluss in den DeepSleep geschickt.

Markiert wird diese Phase durch den High-Pegel des B-Kanals. Zu Beginn der Phase liegt die Stromaufnahme bei etwa 50mA. Es dauert cirka 40ms bis das WLAN-IF hochgefahren ist. Dann steigt die Stromaufnahme auf 100mA. Während der Tx-Bursts fließen 250mA. Das Oszillogramm zeigt die Verbindungsaufnahme zur Fritzbox bis hin zur Zuweisung der IP-Adresse. Die Verbindungsaufnahme zum Server und Datenübermittlung sind hier nicht enthalten und müssten auf der X-Achse rechts noch addiert werden. Der Protokolloverhead dauert 1060ms bei einer durchschnittlichen Stromaufnahme vom 80mA. Dieser Wert stammt aus der Mittelwertberechnung des Oszis (nicht nachgeprüft, scheint aber nach grobem Überschlag glaubhaft).

Das ergibt 2355mAh (7.8Wh) bei 100kCycles und sieht damit für unsere 1000mAh-Batterie nicht mehr so freundlich aus. Und das wohlgemerkt nur für den Protokolloverhead. Optimierngsmöglichkeiten wurden nicht weiter untersucht.

Espressif hat für seine Chips ein verbindungsloses Wifi-Protokoll mit der Bezeichnung ESP-NOW entwickelt. Damit lässt sich eine PeerToPeer-Kommunikation zwischen zwei ESP-Modulen (auch ESP8266) aufbauen, bei der ausschließlich Datenpakete mit bis zu 250Bytes gesendet werden. Der Overhead zur Verbindungsaufnahme entfällt. Beide Geräte müssen lediglich im gleichen WLAN-Kanal arbeiten. Die Zustellung der Datenpakete erfolgt über MAC-Adressen. IP-Adressen kennt dieses Protokoll nicht.

Das Oszillogramm zeigt mit gleicher Auflösung den Vergleich zum obigen Bild. Hier wird ein Datenpaket eines ESP-Witterungs-Sensors (BME280+DS18B20) an den ESP-Gateway, der als zentrale Stelle im ESP-Zoo agiert, gesendet (1.Tx-Peak). Der Gateway antwortet mit einem Datenpaket, was der Sensor mit einem Response quittiert (2.Tx-Peak). Damit sind die Daten ausgetauscht und der Sensor geht wieder in den Tiefschlaf. Das Ganze dauert im Beispiel 126ms und zieht im Mittel 67mA. Damit liegt der Jahresbedarf bei nur noch 234mAh (770mWh). Somit ein klares Votum für das ESP-Now-Protokoll.
Ob der Einsatz sinnvoll ist, hängt vom Anwendungsfall ab. Bei Meldern, die bspw. Kontakte überwachen, die nur selten betätigt werden, sieht die Leistugnsbilanz völlig anders aus.

Die Stromspitzen des Senders lassen sich durch Reduzierung der Sendeleistung dämpfen. In der SDK Configuration kann der Initialwert unter Component config/PHY vorgegeben werden. Die Sendeleistung kann von +20dBm (default) bis auf +10dBm reduziert werden.

Beispiel - linker Peak: Übertragung eines ESP-Now Datenpaketes (120 Datenbytes) mit 20/14/10dBm

Dies bezieht sich nur auf den Initialwert nach dem Booten. Im Hauptprogramm lässt sich die Sendeleistung jederzeit im Bereich 10.0dBm .. 20.5dBm anpassen.

esp_wifi_set_max_tx_power(uint8_t power) //0.25dBm steps [40..82]

Der ESP32 kann nebenbei im Sniffer-Betrieb arbeiten. Es lassen sich neben dem Inhalt der Datenpakete auch Parameter wie die Rx-Feldstärke auswerten. Die Feststation könnte ihrem batteriebetriebenen Gegenüber mitteilen, ob mit dem nächsten Paket die Sendeleistung erhöht oder gesenkt werden soll.
In der Gesamt-Leistungsbilanz wird das vermutl. keine bedeutende Rolle spielen. Es lassen sich aber evtl. Spannungseinbrüche verhindern, die den Prozessor ins Nirvana schicken bzw. einen Brownout-Reset auslösen und damit könnte sich die Batteriestandzeit erhöhen.

Apropos Brownout: In der SDK-Configuration kann unter Component config/ESP32-specific bestimmt werden, ob die Betriebsspannung überwacht und bei Unterschreiten ein Reset ausgelöst wird.

Durchaus sinnvoll, um nach Resetauswertung entsprechend reagieren zu können. Andererseits ärgerlich, wenn die Batterie noch lange laufen könnte.
Ggf. ist es besser, die Batteriespannung per ADC-Messung zu überwachen und bei Unterschreitung eines Grenzwertes zu reagieren.

Am Ende des Hauptprogramms wird der nächste Wakeup initialisiert und der Chip wieder in den Tiefschlaf geschickt.

Batterieauswahl

Der ESP32 und Bauteile in der Peripherie stellen gewisse Ansprüche an die Spannungsversorgung. Für seine WROOM-Modul empfiehlt Espressif einen Spannungsbereich von 3.0V bis 3.6V. Mit Überspannungen sollte nur experimentieren wer zuviel von den Teilen hat. Nach unten sind aber durchaus Spielräume offen.

Bei mir läuft seit einigen Jahren ein geschlossenes ESPNOW-Netzwerk unter dem Begriff "Heimautomation". Die Kommunikation mit allen ESP-Sensoren und -Aktoren regelt ein zentraler ESP-Gateway. Die Daten aus dem Netz leitet er an einen Raspberry weiter, der sich um die intelligenteren Dinge wie MQTT oder Node-Red kümmert.
Die Aktoren im Netz werden über 50Hz versorgt, da sie ständig erreichbar sein müssen (Heizungs- und Pumpensteuerung, schaltbare Steckdosen). Die andere Spezies sind die Sensoren, die über Haus und Garten verteilt sind. Der Aufwand, diese mit Netzspannung zu versorgen wäre zu hoch.
Dies soll kein Beitrag über das Netzwerk werden. Das befindet sich ohnehin ständig im Umbau. Einige Experimente mit Batteriebetrieb habe ich aber schon hinter mir. Nur.... zu der Weisheit letzter Schluss bin ich noch nicht gelangt.

Die Urvariante basierte auf dem ESP8266. Die Sensormodule wurden mit 2x 1,5V (AAA) ausreichend lang versorgt. Bis dahin bestand kein Grund über andere Lösungen nachzudenken.
Das änderte sich mit dem Einsatz der ESP32, die anscheinend deutlich giftiger auf kurzzeitige Unterspannungen reagieren. Also mussten andere Lösungen her.

3.6V Primary Lithium-Thionyl Chloride (Li-SOCl2)

Die technischen Daten der Zellen LS14500 scheinen optimal zu sein. Die Nennspannung von 3.6V passt zur oberen Spannungsgrenze. Meine Exemplare (ca. 10Stück von unterschiedlichen Lieferanten) haben auch im Neuzustand diese Grenze nicht überschritten. Die Leerlaufspannung lag bei Anlieferung zwischen 3.5 .. 3.6V. Ob das daran lag, dass die Teile überlagert waren oder aus Klone-Produktion stammen, lässt sich nicht klären.
Die Klemmspannung wird in meinen Schaltungen bei aktivem WLan-IF, also bei einer Belastung von 100mA gemessen. Dabei zeigt sich relativ schnell ein Abfall in einen Bereich um 3.3V bei Zimmertemperatur. Die Spannung bleibt dann über einen längeren Zeitraum oberhalb 3.0V stabil.
Allerdings ist eine starke Temperaturabhängigkeit zu verzeichnen. Batterien im Außenbereich, die im Sommer 3.3V haben, fallen im Winter auf unter 2.9V und zeigen im nächsten Sommer wieder 3.2V.

Fazit:
Mit diesen Batterien lässt sich der ESP32 problemlos und vor allem direkt versorgen. Bei meinen Experimeten gab es bisher nur einen ungeklärten, vorzeitigen Ausfall. Einige Zellen sind schon auf dem zweiten Board verbaut, da sie langlebiger sind als so manches HW-Design. Das macht es aber auch schwer, ein objektives Bild zur ermitteln. Der subjektive Gesamteindruck ist aber positiv.
Auf der Negativseite steht der Preis. Die Teile kosten mehr als ein WROOM! Außerdem sind sie nicht im lokalen Einzelhandel erhältlich, sodass ggf. noch Versandgebühren dazukommen. Und auf Vorrat möchte man diese Luxusteile auch nicht kaufen. Also gilt es weiter zu suchen.

Links: Pegelsensor für Regenwasserzisterne
Rechts: Temperatur & Luftfeuchtigkeit DHT22

1.5V Alkaline - Direktversorgung

Alkaline Batterien sind von der Verfügbarkeit her optimal. Da sie auch in zahlreichen anderen Geräten zum Einsatz kommen, sind sie meist ohnehin vorhanden.
Batterien der Größe LR03 haben samt Batteriehalter erträgliche Ausmaße. Paarweise eingesetzt starten sie im Neuzustand bei 3.2V, sinken aber relativ schnell unter 3.0V.
Ein Testaufbau mit dem Klimasensor BME280 erreichte knapp 40000 Messzyklen nach etwa 5 Monaten. Schluss war bei einer Batteriespannung von 2.5V, gemessen bei einer Last von 100mA.
Das ist noch lange vor dem Lebensende der Batterie. Ursache sind vermutlich Spannungseinbrüche während der Tx-Bursts. Mit einem Stütz-Elko von 1000µF nahm die Schaltung ihren Betrieb ersteinmal wieder auf.
Bei 2.4V bewegt man sich aber ohnehin in einem Bereich, den Espressif als kritisch ansieht. Nicht umsonst beträgt die minimal einstellbare Brownout-Spannung 2.43V

1.5V Alkaline mit StepUp-Regler

Im Bastelvorrat fand sich noch ein StepUp-Regler U1V11F3. Er setzt einen Eingangsspannungsbereich von 0.5V..5.5V auf 3.3V um, liefert ausreichend Strom für den ESP32 und scheint daher geeignet, die Experimente mit 2x 1.5V (AAA) weiterzuführen.

Der Hersteller gibt einen Wirkungsgrad von 70-90% an. Das gilt jedoch nur unter Lastbedingung. Im Tiefschlafmodus des ESP32 (6µA) zieht die Schaltung 120µA aus der Batterie. Ein viel zu hoher Wert für einen Batterie-Dauerbetrieb. Aus diesem Grund entstand nachfolgende Schaltung. Die Auswahl der Bauelemente erfolgte nach Verfügbarkeit aus Restbeständen vorheriger Projekte.

Folgende Idee steckt hinter dieser Schaltung:
Im DeepSleep ist GPIO33/RTC_GPIO8 low. Damit sind T2 und T1 gesperrt. Die Spannungsversorgung der Schaltung erfolgt über D2. Da die Batterie nicht belastet wird, hat sie in dieser Zeit eine relativ hohe Leerlaufspannung. Dem ESP32 reichen in dieser Phase 1.5V um die aktiven RTC-Bereiche zu versorgen.
Die aktive Phase beginn durch timergesteuertes Starten des ULP-Prozessors. Mit den ersten Befehlen wird RTC_GPIO8 nach oben gezogen, steuert T2 und T1 durch, der StepUp-Regler startet und der ESP32 incl. Peripherie wird über D3 versorgt. Den kurzen, relativ hohen Anlaufstrom soll C4 abfangen, um schwache Batterien nicht vorzeitig in die Knie zu zwingen.
Vor dem DeepSleep zieht das Hauptprogramm den Port RTC_GPIO8 wieder nach unten. Der ESP benötigt dann noch einige Millisekunden bis er sich zur Ruhe begibt. Diese Zeit überbrücken C3/R6, indem sie T1 offen halten.
Mit dabei ist wie in allen meinen Batterieschaltungen der Spannungsteiler R4/R5, über den die Batteriespannung gemessen wird.

Dieses Prinzip funktioniert bei Verwendung des ULP-Prozessors als WakeUp-Quelle. Denkbar wäre auch ein Wakeup durch exerne Quellen, wobei der Wandler einige ms vor dem SOC hochgetastet werden müsste.

Hier der Spannungsverlauf auf der Batterieseite (Kanal A) und am ESP32 (Kanal B). In den ersten 700ms der aktiven Phase arbeitet der ULP-Prozessor. Links ohne Stützelko / Rechts mit 1000µ.

Nachteil dieser Schaltung: Beim Einlegen schwacher Batterien startet die Schaltung nicht selbstständig, da die Spannung nur hochtastet wird, wenn der ESP32 aus dem DeepSleep kommt und die direkte Batteriespannung ggf. zu niedrig ist. Für diesen Fall ist Jumper J2 vorgesehen, mit dem der Regler kurzzeitig in den Dauerbetrieb geschaltet wird.
Bedingt durch die Wandlerverluste steigt die Leistungsaufnahme in der aktiven Phase um 30-40%.

Die Schaltung funktioniert mit Eingangsspannungen >1.5V. Batterien, die in Schaltungen ohne StepUp-Regler, nicht mehr funktionierten, laufen in dieser Variante problemlos weiter.

Klimasensor BME280: Temperatur, Luftfeuchtigkeit, Luftdruck
& Temperatur DS18B20 für Vergleichsmessung

Gemessen wurde in 5min-Intervallen. Die Standzeit der (Marken-)Batterien betrug ca.15 Monate. Die Hauptkerne waren dabei in Summe weniger als 5 Stunden aktiv. Das zeigt die Bedeutung der Laufzeitoptimierung.

3V Lithium Battery - CR123 & Co.

Grundsätzlich geben die Modulhersteller für den ESP32 einen zulässigen Spannungsbereich von 3.0V bis 3.6V an. Praktische Erfahrungen zeigen aber, das die Teile auch bei 2.4V noch arbeiten. Bei eingeschränkten Ansprüchen an Betriebssicherheit oder Sendeleistung lässt sich dieser Bereich durchaus nutzen.

Die CR123 werden i.A mit einer Nennkapazität von 1400mAh angegeben. Die Selbstentladung ist sehr gering. Die Batterien sind hochstromfähig, sodass Tx-Spitzen über längere Betriebsdauer verkraftet werden und die Entladekennlinie passt zu den Erfahrungswerten des ESP32.
Die Spannung startet bei 3.0V, sinkt über die Lebensdauer der Batterie auf ca. 2.6/2.5V und fällt danach steil ab. Ein Wertebereich in dem der ESP funktionieren sollte.
Hauptkriterium für die Lebensdauer dürfte das Spannungsverhalten bei Stromspitzen nach fortgeschrittener Betriebsdauer sein. Das ist aber ein Problem jeder Batterieversorgung.

Der Spannungsverlauf legt eine Direktversorgung aus der Batterie nahe. Der Einsatz eines Stepup-Reglers ist hinsichtlich des Aufwandes und der zusätzlichen Leistungsverluste fraglich.

Soweit die Theorie.
Bei mir sind seit etwa 10 Monaten zwei Sensoren mit der CR123 im Einsatz. Der eine misst in 15-Minuten-Intervallen den Pegel in einer Wasserzisterne und war in dieser Zeit Temperaturen von -3 bis >60°C ausgesetzt. Die minimal gemeldete Spannung betrug 2.88V. Nach saisonbedingtem Abbau und Akklimatisierung auf 15°C beträgt die Klemmspannung unter Prozessorlast noch 2.98V !!! Und das nach knapp 25.000 Messzyklen. Das lässt für die nächste Saison hoffen.
(Nachtrag Okt 2021) Auch nach der zweiten Gartensaison (weitere 20.000 Messzyklen) beträgt die Spannung 2.99V.

Der andere Sensor überwacht die Paketbox, meldet hin und wieder seine Spannung und wird sonst nur aktiv, wenn der Paketbote vorbeikommt. Daher für einen Belastungstest eher ungeeignet.

Im Bild links der Pegelsensor zur Überwachung von Regenwassertonnen aus meinem Ur-Projekt "Gartenbewässerung im Urlaub". Mein bisher letzter Versuch einer langen Reihe, die Gehäuse wasser- und luftdicht zu verschließen.
Der Kopf sitzt unterhalb des Tonnendeckels über der Wasseroberfläche und ist im Sommer Saunabedingungen ausgesetzt.
Falls die Frage aufkommt: Was soll da der BME280 ? -> Der überwacht die Luftfeuchtigkeit im Gehäuseinneren.

Ein Nachteil der CR123 ist der große Durchmesser, der den praktischen Einsatz einschränken könnte. 3V-Lithium-Batterien gibt es aber in unterschiedlichsten Bauformen. Es dürfte die generelle Aussage gelten: Je kleiner, desto früher wird das Lebenslicht erlöschen.

Es sind aber auch die Zeiten vorbei, da die CR123 im Supermarkt am Haken hingen. Mit Aussterben der analogen Fotoapparate führen die Teile ein Nischendasein und sind i.d.R. nur noch über den Versandhandel erhältlich.

Meine Erfahrungen in den beiden Versuchen verliefen positiv. Es muss aber klar sein, dass man sich bei einer Direktversorgung aus dieser Batterie außerhalb der Spezifikation bewegt.

Akkumulatoren

Hinsichtlich Kostenreduzierung und Müllvermeidung können Akkus eine sinnvolle Alternative zur Einweglösung mit Primärzellen darstellen. Auch das Experimentieren geht leichter von der Hand, wenn am Ende nur ein Ladevorgang und nicht die Entsorgung ansteht.
Bei der Auswahl der Technologie ist zu beachten, dass die Nennspannung der Zellen angegeben wird. Die Ladeschlussspannung kann wie bei LiOn deutlich oberhalb liegen, sodass ein Betrieb innerhalb der Spezifikation nur mit Zusatzaufwand möglich ist.

Die altbekannten NiCd/NiMH-Akkus haben eine relativ hohe Selbstentladung, sodass sich diese Technologie bereits in früheren Versuchen für den Langzeitbetrieb als ungünstig herausgestellt hat.
Als moderne Alternative haben sich Lithium-Akkus unterschiedlicher Technologien im Modellbau etabliert.

LiFePO₄ - Akkus

Der Spannungsbereich der LiFePO₄-Akkus passt optimal zur Spezifikation des ESP32. Die Nennspannung einer Zelle beträgt 3,2V bis 3,3V. Die Ladeschlussspannung geben die Hersteller mit 3,55 bis 3,65V an. Über einen Bereich von ca. 90% eines Entladezyklus liegt die Spannung zwischen 3,3V und 3,1V. Danach fällt sie rapide ab.

Der Direktbetrieb des ESP ist somit problemlos möglich. Ein zusätzlicher 100nF-Stützkondensator in der Nähe des 3V3-Modulpin genügt theoretisch.
Diese Technologie wird oft als "eigensicher" beschrieben. Die Gefahr der Selbstentzündung durch inneren Kurzschluss wird diesem Typ nicht nachgesagt.
Gefahrlos betreiben lassen sich die Teile allerdings nur unter Einhaltung der Lade- und Entladeparameter. Da Einzelzellen (derzeit) über keine internen Schutzschaltungen verfügen, ist man für die Einhaltung der Parameter selbst verantwortlich. Einen funktionstüchtigen Feuerlöscher in seiner Nähe zu wissen, kann beruhigend wirken.
Es gibt einige Ladegeräte, die mit diesem Zelltyp umgehen können. Es ist aber auch möglich, die Zellen an einem Labornetzteil per I/U-Kennlinie aufzuladen. Es ist dabei sicherzustellen, dass die Ladeschlussspannung nicht überschritten wird. Besser bleibt man noch 50mV bis 100mV darunter. Ist diese Grenze zu hoch eingestellt, zieht der Akku weiterhin Strom, die Spannung steigt und die zusätzliche Leistung wird in Wärme umgesetzt. Im Extremfall müsste dann o.g. Feuerlöscher zum Einsatz kommen.
Im Kurzschlussfall können die Teile extrem hohe Ströme liefern. Eine Absicherung der Versorgungsleitung sollte nicht als Luxus angesehen werden.
Auch die Entladeschlussspannung muss überwacht werden. Es bietet sich an, den Brownout-Detector des ESP zu aktivieren und den Reset-Grund nach dem Booten auszuwerten. Wurde ein Brownout erkannt, wird das ESP-Modul in den Dauertiefschlaf geschickt. Dabei darf die Peripherie natürlich keinen signifikanten Strom ziehen.
Soweit ist alles perfekt. Einen kleinen Haken haben die LiFePO₄-Zellen allerdings: Die Technologie ist noch nicht so recht im Modellbau angekommen (Stand: Juni 2022).
Es sind nur relativ wenige Bauformen mit brauchbaren Abmessungen verfügbar. Bei den kleineren Akkus handelt es sich um Rundzellen. Recht preiswert sind Ersatz-Akkus für Solarleuchten in der Bauform 14500 (AA) / 600mAh zu bekommen. Steht mehr Platz zur Verfügung, sind in puncto Kapazität und Geldbeutel kaum Grenzen nach oben gesetzt.
Beim Vergleich von Baugröße und Kapazität schneiden die LiFePO₄ relativ schlecht ab. Li-SOCl₂-Batterien bringen bei gleicher Bauform die 4-fache Kapazität mit. LiIon-Akkus bringen es bei vergleichbarem Gewicht auf etwa die doppelte Kapazität.
Auf meiner Wunschliste steht der Solarbetrieb mit diesen Akkus. Leider fehlt mir noch das passende Projekt. Derzeit laufen hier zwei Sensoren mit 600mAh-Akkus im Austausch gegen Li-SOCl₂-Batterien.

Fazit: Sofern Platz und Gewicht zum eigenen Projekt passen, sind LiFePO₄ - Akkus optimal geeignet.

LiIon / LiPo - Akkus

Lithium-Ionen bzw. Lithium-Polymer-Akkus werden mit Nennspannungen von 3,6V bzw. 3,7V angegeben und scheinen auf den ersten Blick optimal zur oberen Betriebsspannungsgrenze der ESP-Module zu passen.
Dies ist aber nur ein Wert, der sich aus dem elektrochemischen Aufbau der Zellen ergibt. Der tatsächliche Spannungsbereich reicht im geladenen Zustand von 4,1(4,2)V bis zur Entladespannung von 3,0(3,3)V und liegt damit an der oberen Grenze eindeutig über dem zulässigen Maximalwert.

Ein besonderes Augenmerk ist bei dieser Technologie auf die Einhaltung von Lade- und Entladespannung zu legen. Akkus quittieren eine Nichtbeachtung i.A. mit verkürzter Lebensdauer. Li-Akkus stehen zusätzlich im Ruf, Brände zu verursachen.

Aber was tun mit der überschüssigen Spannung? Eine Spannungsreduzierung mit einem Längsregler ist ungünstig, da selbst in Low-Drop-Ausführung 0,5-0,6V über dem Baustein abfallen und die Eingangsspannung zur Ausregelung der 3V3 mindestens 3,8V betragen müsste. Eine Reihenschaltung von zwei 2 Li-Zellen kommt aus Aufwandsgründen nicht in Betracht.

Als Alternative sind DC/DC-Wandler möglich. Da die Schaltung ständig aktiv sein muss, verlangt sie auch permanent nach Leistung. Bei einem Wandler der sich ständig mit 150µA aus dem Akku bedient, sind alle Bemühungen die Ruhestromaufnahme der restlichen Schaltung unter 10µA zu drücken für die Katz.

Welchen Aufwand man treiben möchte/muss hängt vom Anwendungsfall und dem erwarteten Ergebnis ab. Ein 4000mAh-Akku würde es theoretisch schaffen, diesen Wandler 3 Jahre lang mit Ruhestrom zu versorgen. Das stellt zusätzlichen Schaltungsaufwand in Frage. Aber ohne Wunsch nach Optimierung wäre der ganze Artikel sinnlos.

Es ist ist eine Weiterentwicklung des Alkaline-Schaltreglers (s.o.) entstanden.

Hauptelemente der Schaltung sind:

• LiPo-Akku (1100mAh)
• Lade-Modul TP4056
• StepUp-Regler U1V11F3
• Längsregler LDO 2,8V - MCP1702T-2802

Speziell das Lademodul ist im 10er-Pack für einen so unglaublich niedrigen Preis zu bekommen, dass sich die Frage nach einem Selbstbau nicht stellt. Aber auch bei den Schaltwandlern würde ich nur noch auf Fertigmodule zurückgreifen.

Folgende Idee hinter der Schaltung:
In der Tiefschlafphase ist GPIO33 low. Damit sind T1 und T2 gesperrt und der DC/DC-Wandler (V2) ist spannungslos. Die Versorgungsspannung des ESP wird über den LDO (V1) auf 2,8V geregelt und über D1 eingekoppelt.
Die Wahl der Spannung scheint auf den ersten Blick ungewöhnlich, hat aber folgenden Hintergrund: In dieser Phase genügt dem ESP eine geringere Spannung. Versuche haben gezeigt, dass der RTC-Block auch mit Vcc <2V funktioniert. Andererseits schafft es der hier gewählte Längsregler, die Spannung bis an die untere Akkugrenze von 3V sauber auszuregeln. Bei den geringen Strömen genügt die Spannungsreserve von 200mV.
Die Wahl fiel speziell auf diesen Typ wegen der geringen Ruhestromaufnahme von nur 2µA. Alternativen sind natürlich möglich.
D2 ist währenddessen gesperrt und verhindert Rückströme über den Ausgang des Wandlers.

Möglichst frühzeitig vor oder in der aktiven Phase des Hauptkerns muss GPIO33 auf high gezogen werden. Dies kann im vorgelagerten ULP-Programm erfolgen. Wenn das nicht vorhanden ist, weil das Aufwecken bspw. durch einen GPIO-Interrupt ausgelöst wird, sollte der Port im Wakeup Stub angesteuert werden, um bereits vor der Bootphase die Vcc-Spannung hochzutasten.

High an GPIO33 steuert T1 und T2 durch. Damit liegt Spannung am DC/DC-Wandler (V2) und an dessen Ausgang liegen nach ca. 300µs 3,3V. Diese Spannung wird über D2 an den ESP gekoppelt. D1 sperrt und verhindert Rückströme über den LDO (V1).

Die Akku-Spannung liegt nun auch am Spannungsteiler R1/R2. Über den Abgriff misst der ESP über den Analogeingang GPIO35 die relative Akku-Spannung. Die Widerstände sind so gewählt, dass die Spannung am Messeingang bei vollem Akku die Referenzspannung des ESP32 von 1100mV nicht überschreitet. Der Rest ist ein wenig Mathematik und das Studium der ADC-Funktion.

Am Ende der aktiven Phase wird GPIO33 wieder nach low gezogen und T2 sperrt. Über das RC-Glied R3/C1 wird T1 noch ca. 50ms offen gehalten, um den Chip mit hoher Spannung zur Ruhe zu bringen.
Der DC/DC-Wandler verfügt zwar über einen Steuereingang. Diesen auf low zu ziehen bringt aber keine signifikante Stromreduzierung.

Als Portbezeichnung habe ich zum allgemeinen Verständnis GPIO33 verwendet. Von der Funktion her muss es an dem Pin aber der RTC_GPIO8 sein, da nur ein RTC-Port die Ansteuerung während des Deep-Sleep ermöglicht.
Die korrekte Funktionsbezeichnung des Analogeingangs an GPIO35 ist ADC1_CH7.

Das Lademodul muss auf den verwendeten Akku abgestimmt sein. Optional lässt sich der Akku natürlich auch extern laden oder das Lademodul an die Schaltung anstecken. Andere Akkus haben eine Ladeschaltung bereits integriert.
Ein Rückstrom aus dem Akku in das Lademodul konnte nicht nachgewiesen werden.

Die Wahl der restlichen Bauelemente ist auf Basis meiner Vorräte getroffen worden. D1, D2 und D11 müssen Schottky-Dioden sein. Über normalen Si-Dioden würde eine zu hohe Spannung abfallen. D11 ist optional, um den ESP beim flashen mit 3.3V aus dem USB/UART-Wandler zu versorgen. Das funktioniert aber auch mit den 2,8V aus V1.
Der P-MOS T1 sollte einen möglichst geringen Durchlasswiderstand Rds(on) < 100mOhm aufweisen. T2 ist ein simpler NMOS - BS170 o.ä.
Die Kondensatoren sind einfache keramische Kondensatoren. Der Wandler und der LDO sollten an Ein- und Ausgängen mit je 100nF gestützt werden. Dies vermindert die Schwingneigung. C4 puffert kurze Einbrüche in der Einschaltphase und fängt Stromspitzen des Senders ab.

Die Gesamtstromaufnahme incl 6-pol BME280 beträgt im Ruhezustand ca. 11µA.

Links im Kanal A der Verlauf der Ausgangsspannung zwischen 2,8 und 3,3V über einen aktiven Zyklus. Kanal B markiert die Zeit vom Wakeup bis zum Sleepdown.
Rechts die Startphase - höher aufgelöst.

Die Schaltung muss ihre Praxistauglichkeit noch auf einem Steckbrett nachweisen.
Rechts ein Vorschlag wie sich auch SMD-Bauelemente in Testschaltungen einsetzen lassen.

Der Versuch zeigt das erwartete Ergebnis. Die Laufzeit der Hauptkerne (ohne Booten) betrug etwa 11Std. Im Bereich von 4,15 bis 3,35V fiel die Spannung kontinuierlich, gemessen bei Prozessorlast. Unterhalb von 3,3V ist die Schlussspannung des LiPo-Akkus erreicht und die Kurve fällt steil ab. Bei Einsatz eines LiPo-Akkus sollte die Schaltung ab 3,3V in einen Dauertiefschlaf geschickt werden.

Die Oszillogramme (oben) wurden bei geladenem Akku aufgenommen. An der unteren Spannungsgrenze zeigen die Bilder exakt den gleichen Verlauf.

Angesichts von Baugröße und Anschaffungskosten stellen diese Akkus eine interessante Alternative zu Primärzellen dar. Auf der Negativseite steht der Schaltungsaufwand für die Spannungswandlung.

Im Bild ein Universalmodul mit einigen häufig genutzten Ports auf Steckpfosten. Auf der Unterseite ist der 1100mAh-LiPo-Akku mit doppelseitigen Klebeband befestigt. Aufgesteckt ist eine Adapterplatte mit BME280 und DS18B20.
Das Lademodul wird aus Platzgründen im Bedarfsfall extern aufgesteckt.

Schlussbemerkungen

Die Versuche zeigen, dass der Betrieb eines ESP32 mit Batterien und Akkus möglich ist. Es sind jedoch Kompromisse erforderlich. Speziell die aktive Zeit der Hauptprozessoren muss auf ein Minimum beschränkt werden.
Bei einem Vorhaben, Daten im Minutentakt per WLan auszuliefern, werden zumindest die hier betrachteten Batterien frühzeitig ihren Dienst quittieren. Dagegen sind Intervalle von >= 5min per ESP-Now praktikabel.

Nicht betrachtet wurde die Leistungsbilanz der Perepherie. Wie auch? Dazu sind die Projekte zu unterschiedlich.
Grundsätzlich ist festzustellen, dass die üblichen Entwicklungsboards des ESP32 wie NodeMCU & Co auf Grund ihres Overheads in Batterieschaltungen unbrauchbar sind.

Welche Schaltungsteile dauerhaft aus der Batterie versorgt werden dürfen, hängt von deren Ruhestromaufnahme ab.
Das Messen der Stromaufnahme während der Tiefschlafphase sollte in jedem Entwicklungsmuster zur Pflicht werden. So kann schon der Wechsel eines Elkos zu Überraschungen in Form von Leckströmen führen.
Einfach einen 10kOhm-Widerstand in die Spannungszuführung legen, ein Voltmeter dazu parallel und den Widerstand überbrücken. Dann das Programm starten, warten bis der ESP im Tiefschlaf ist und die Brücke öffnen. Sollten nun mehr als 100mV angezeigt werden, muss man sich fragen, warum.
Bei der Messung darf kein USB-Adapter am ESP angesteckt sein. Die Versorgung sollte bei der Messung aus der Batterie erfolgen. Die Restwelligkeit eines Netzteils kann das Ergebnis verfälschen.

Aber auch bei viel verwendeten Sensoren wie bspw. dem BME280 kann eine Messung Überraschungen zutage fördern. Das sind faszinierende Teile, wenn es um Messungen des Luftdrucks geht. Die anderen Daten... naja, aber das nur nebenbei.
Die Breakout-Boards gibt es in 4- und 6-poliger Version. Die 4-poligen bringen als Overhead einen Längsregler und Pegelanpassungen mit, deren Ruhestromaufnahme um ein vielfaches höher liegt als die des Sensorchips selbst.

Und was passiert am Lebensende der Batterie? Es ist zu vermuten, dass dieses in der aktiven Phase eintritt. Durch eine Stromspitze wird die Spannung einbrechen und die Prozessoren ins Nirvana schicken. Damit erreicht der ESP die nächste Tiefschlafphase nicht mehr und zieht dauerhaft hohen Strom. Früher wären die Batterien dann irgendwann ausgelaufen.
Alternativ ließe sich der Spannungseinbruch über einen Brownout-Reset abfangen und nach dem nächsten Booten der Chip in einen Dauertiefschlaf schicken. Dann befindet er sich zwar in einem sicheren Zustand, hätte aber vielleicht noch ein Weilchen arbeiten können.

Der Artikel kratzt insbesondere beim Thema Batterieauswahl nur an der Oberfläche. Es gibt noch eine Vielzahl an Batterien und Akkus zu entdecken. Es lässt sich auch keine grundsätzliche Aussage treffen, ob ein Typ geeignet ist. Unterschiedliche Hersteller liefern unterschiedliche Qualitäten. Von Clonen ganz zu schweigen.

Auch die eingesetzten Wandler und Längsregler sind nicht optimal. Die Auswahl basiert auf meinen Vorräten und der Verfügbarkeit im Einzelhandel.
In kommerziellen Schaltungen sind immer wieder Bauteile mit geringerer Ruhestromaufnahme oder höherer Ausgangsleistung zu finden. Aber woher nehmen? Versandkosten und Lieferzeiten begrenzen das Sortiment des gewöhnlichen Bastlers. Und irgendwo sind auch die Möglichkeiten meiner Lötkolbenspitze begrenzt.

Hier sind nur meine eigenen Experimente geschildert und die Erfahrungen sind subjektiv wiedergegeben. Es war ohnehin nicht geplant, fertige Lösungsvorschläge oder ein Kochbuch zu präsentieren.

Empfehlung: Selbst überlegen, messen, sowie hin und wieder den Taschenrechner bemühen.