Einleitung
Kommend von Strom sparen beim Einsatz der MicroPython-Firmware im Batteriebetrieb sowie [Sammlung] Stromsparmaßnahmen für den Pycom Fipy soll dieser Beitrag das Backlog werden – nicht zwingend nach Prioritäten geordnet, aber manchmal teils ein wenig. Its content mixes German and English, for which we would like to apologize. C’est la vie!
Wir sammeln hier konkrete Maßnahmen, die wir uns vielleicht noch vornehmen werden, um die Stromaufnahme des FiPy in unserem Szenario noch weiter zu verringern. Dabei versuchen wir ein wenig Ordnung in die Möglichkeiten zu bringen, die jeweils oft unterschiedliche Domänen betreffen.
Weil ähnliche Dinge in anderen Kontexten meist leicht anders implementiert werden wollen, können uns hier klarere Einordnungen weiterhelfen, die Dinge passend zu differenzieren.
Höchste Ausbeute bei RF
RF-Peripheriegerätschaften (WiFi, BLE, LoRa, Sigfox) müssen wir an der kürzesten Leine halten. Jede unnötige Zeit zu lange aktiv kostet das am meisten Strom. Dabei müssen aber natürlich auch die Aufwände bei der Implementierung berücksichtigt werden, an dieser Stelle Optimierung zu betreiben ¹.
- Explicitly shut down LTE and Bluetooth at system start already.
- Investigate the exact procedure to keep the LTE modem turned off completely.
- Investigate LTE modem energy consumption with and without SIM card.
- Skip WiFi-Scan on startup when station and its auth mode are known already.
- Upgrade all firmwares of all devices and peripherals, esp. the Sequans LTE modem in order to eventually unlock improved power saving control. This is a maybe.
- Investigate LTE airplane mode? Is it better than just “off”?
¹ – gerade letzteres ist hier derzeit der Hemmschuh, weil die Geräte nicht diskret auf dem Tisch liegen sondern verkapselt im FiPy nur durch die Pycom-MicroPython-API angesteuert werden können und derzeit immer noch teilweise unklar ist, ob z.B. ein per Software angesteuertes "lte.off()" so funktioniert wie versprochen oder eben nur manchmal bzw. unzuverlässig oder ob – wie immer schon so oft(!) – einfach nur entsprechende Beschaltung durch die Hardware fehlt und wir uns hier mal wieder mit nicht unbedingt direkt für den Produktivbetrieb vorgesehenen Developer-Boards einen Ast…
We should really ask people of Pycom about the specific topic of LTE-Modem des Pycom FiPy komplett stilllegen again.
Andere Peripheriegeräte
Wenn Peripheriegeräte auch im Tiefschlafmodus der MCU angeschaltet bleiben, sind natürlich alle weiteren Optimierungen an anderen Stellen für die Katz. Beim HX711 braucht man dafür minimal zwingend einen pull-up Widerstand, der den Pegel auch im Schlafzustand hält, der ADS1231 sieht für diesen Zweck einen eigenständigen Eingang vor, den man nur einmalig signalisieren muss.
Laufzeitoptimierungen
Wenn alles andere nichts mehr hilft, können wir uns auch vornehmen, den Energieverbrauch des Prozessors selbst zu verringern. Das geschieht über die beiden Achsen “Dauer” und “Last”.
-
Prozessortakt verringern.
Laut Quick reference for the ESP32 — MicroPython 1.11 documentation lässt sich mit MicroPython auf dem ESP32 zwar grundsätzlich die Taktfrequenz des Prozessors verringern, bei der Pycom Implementierung scheint dies jedoch nicht möglich zu sein.>>> machine.freq(80000000) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: function takes 0 positional arguments but 1 were given -
“Let me compile that for you.” aka. saving cycles / reducing system load aka. decreasing boot time and runtime by pre-compiling and freezing Python modules with
mpy-cross. -
Bestimmte Aufgaben bzw. Subsysteme parallel oder asynchron ausführen.
Da es keine Perpetuum Mobile gibt, tauschen wir hier grundsätzlich nur höhere Systemlast gegen kürzere Betriebsdauer ein. Es lohnt sich also grundsätzlich nur, wenn die Hardware und vor allem das Betriebssystem die Angelegenheit gut optimiert und insgesamt effizienter macht. Allerdings gibt es durch Parallelisierung noch die Möglichkeit, die RF-Laufzeit intelligent zu optimieren (siehe unten), so wird ein Schuh draus.
RF-Laufzeitoptimierungen
sind Verbesserungen, die sich an der Schnittstelle zwischen reinen Laufzeitoptimierungen und RF-Optimierungen befinden. Solche sind durchaus interessant und haben weiterhin erhöhte Aufmerksamkeit verdient.
-
Infrastructure-loss cut-off.
Wenn kein WiFi verfügbar ist und solange noch nicht auf SD-Karte gepuffert wird, sollte der Datenlogger am besten gleich wieder einschlafen. Die aktuelle Implementierung sollte in Folge noch verbessert werden, um Dinge wie exponential backoff bzw. Binary Exponential Backoff anzuwenden, wenn es um die Bestimmung des nächsten Aufwachzeitpunktes zur Datenübermittlung geht. Derzeit geht hier unnötig Strom drauf.
Stromverbrauch am Beispiel während dem Ausfall der WiFi-Infrastruktur durch Stromausfall. Siehe auch amo-fipy-testbench-power during power- and network-outage. -
Bestimmte Aufgaben bzw. Subsysteme parallel oder asynchron ausführen.
Verbesserungen an dieser Stelle können durchaus in Richtung RF-Optimierung sinnvoll sein. Beispiel: Telemetrie-Subsystem wird erst (rechtzeitig) dann angefahren, wenn Meßdaten verschickt werden wollen. -
Don’t run telemetry on each duty cycle, instead buffer some readings to the SD-card or elsewhere. Espressif also sells nicely(?) packaged ESP-PSRAM64 modules which talk SPI. There are rumors that some PSRAM modules consume down to about 3μA-10μA in deep power-down (DPD) mode, e.g. IS66/IS67.
Optimizing the last but not least aspect will probably have the most significant impact on overall runtime on batteries as soon as we have mitigated the other more relevant issues related to this topic.
Standby-Optimierungen
“Im Standby alles abschalten” ist ganz klar die effektivste Variante fürs Stromsparen.