[Agenda] Stromsparmaßnahmen für den MicroPython-Datenlogger auf Basis des Pycom FiPy mit Peripherie

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.

SD need the expansion board and needs power. Do we have an other low power save storage? Can we save it in an variable array?

SD dosn’t need an expansion board. If we have the rigth libary.
We need an SPI bus and an cs pin.
But the most of the external card reader habe an level converter from 5V to 3V3.
If we want to save Power, we must find one without an level converter.
I’ve also used one in the Arduino universe without a library, is not a witchcraft.

I have one time see an sd-card that soldered direct to an spi bus.
soldered like this.

There are memory and eprom which are can addressed via the i²C bus.
But i do not know, how much power they need.

1 Like

When looking at the article at External SD Card | Pycom user forum you are referring to, people seem to be

running into a lot of issues.

So I’m a bit hesitant and would not encourage someone to go down that route.

I would prefer some off-the-shelf part like the PSRAM module referenced above.

Maybe @roh or @weef will know something to recommend here for us.

A post was merged into an existing topic: LTE-Modem des Pycom FiPy komplett stilllegen

RGB LED and deep sleep

Bei TinyPICO haben wir vom TinyPICO – der genauso wie die Pycom Geräte eine RGB LED beherbergt – folgendes Interessantes aufgeschnappt:

Hier wird beschrieben, wie man die DATA und CLOCK pins zur RGB LED softwareseitig ordentlich beschalten sollte, damit keine Leckströme entstehen können.

Als Nicht-Hardware-Mensch frage ich mich dabei naiv, ob es solche Dinge u.U. auch bei den Pycom Geräten zu berücksichtigen gilt. Da meine Fähigkeiten beim Lesen und richtigen Interpretieren entsprechender Details in den Datenblättern begrenzt sind, will ich diese Frage gerne in die Runde weitergeben. Bitte geht dieser Angelegenheit aber natürlich nur nach, sofern Ihr hier Potential für sinnvolle Verbesserungen beim Power-Budget seht.

Merci.


Es gibt scheinbar mindestens drei populäre RGB LEDs.

1 Like

absurd, sowas. Aber ja - es sind ja nicht mehr nur LEDs, sondern ein schnelles Schieberegister mit Lampen dran ;) .

Daher sehr guter Einwand, selbst ganz vergessen: auch die WS2812 braucht Ruhestrom, nämlich 0,7 mA. (Seite 3 in diesem datasheet)