Stromsparmaßnahmen für die MicroPython-Firmware im Batteriebetrieb

[MKO]

@Andreas klingt doch schon Mal vielversprechend.
Hoffe Mal das sind nicht nur blasen.

@clemens Ja ich weiß Deep Sleep ist unumgänglich.
Das Testsetup würde ich auch dazu nutzen, um zu schauen, wie häufig man messen kann, und ob es zusätzlich zu Deep Sleep noch weitere Möglichkeiten zum Strom sparen gibt.
z.B. WLAN nur für die eigentliche Übertragung aktivieren und vielleicht erst Mal ein paar Daten sammeln um dann alle xx min senden.

[Andreas]

@clemens

Wir müssen dringend den deep sleep-mode für BOB implementieren .

Introduction

With one of the recent commits Add deep sleep, see #2 · hiveeyes/terkin-datalogger@3e73a3f · GitHub, the Hiveeyes MicroPython Datalogger Firmware for BOB should support deep sleep. As more things will be following to become version 0.4.0, we didn’t cut a new release yet.

Configuration

https://github.com/hiveeyes/hiveeyes-micropython-firmware/blob/master/settings.example.py#L11-L12

Discussion

Implement deep sleep between readings

---

Please note

that

• we upgraded to the most recent Pycom MicroPython 1.20.0.rc11 firmware with no effort [1] to stay up to date.
• we switched from FatFS to LittleFS with no effort [2] to stop filesystem corruption in brownout conditions.

[1] https://github.com/hiveeyes/hiveeyes-micropython-firmware/blob/master/doc/pycom-firmware-upgrade.rst#install-and-acquire-prerequisites
[2] https://github.com/hiveeyes/hiveeyes-micropython-firmware/blob/master/doc/getting-started.rst#switch-to-littlefs

---

Happy testing!

[clemens]

@Andreas

Happy testing!

Mit dem Hiveeyes-code messe ich 30 mA mit expansion board und 10 mA ohne in der 30 sekündigen Schlafphase, hmmm viieeeel zu viel verglichen mit den postulierten 0.02 mA beim WiPy, gut, es ist ein FiPy, aber 10 mA vs. 0,02 mA, da muss noch was nicht passen!

Ohne angeschlossene Sensoren sind es 4 mA, deutlich weniger aber immer noch nicht im Bereich von 0,02 mA!

Falls per default LTE angeschaltet ist sollte es abgeschaltet werden. Ggf. brauchts dazu eine SIM-Karte, ggf. muss man auch einfach nur länger als 30 s warten, ein paar Sachen hier dazu.

[Andreas]

@Nicht registrierter User schrieb am 16.04.2019

Ich wäre echt froh, wenn es 2 Monate (wie im u.a. Artikel erwähnt) wären. Ich nutze den ESP32 um die Werte eines moisture sensors (capacitive) auszulesen und via Bluetooth Low Energy zu senden.

Der ESP32 läuft im deep sleep hibernation state und sollte dabei 25 micro Ampere verbrauchen. Er wacht alle zwei Stunden auf, führt seine Messung durch und sendet die Werte per BLE, das dauert in etwa 2-3 Sekunden. Danach wieder deep sleep.

Versorgt wird der Chip mit zwei 2200 mA Batterien. BLE sollte etwa 100 mA im TX-Modus brauchen. Das Ganze hält 1 Woche.

– via: https://www.elektronikpraxis.vogel.de/forum/messages.cfm?threadid=563DD5C3-A3AE-4FA9-B04CE2FA8771036B
– via: Ultra-Low-Power-Management des ESP32 für WiFi-IoT-Module nutzen

[clemens]

Auf Sensorebene gibt es beim HX711 in der C-Bibliothek die Möglichkeit den schlafen zu schicken. Kann das sie uP-lib auch?

[Andreas]

@clemens

Auf Sensorebene gibt es beim HX711 in der C-Bibliothek die Möglichkeit den schlafen zu schicken.

bogde/HX711/blob/0.7.2/src/HX711.cpp#L266-L273

@clemens

Kann das sie uP-lib auch?

hiveeyes/terkin-datalogger/blob/0.3.0/lib/hx711.py#L120-L125

=> Ja, wird aber noch nicht angesteuert. Danke!

[clemens]

Die DS18B20 sollten unkritisch sein, brauchen quasi nix, den BME280 sollten wir noch checken. Gibt es für den bzw den ganzen I2C-Ast auch die Möglichkeit das auszuschalten?

Expansion Board (falls verwendet) muss ich mir gesondert anschauen, da ist die SD und ich glaube auch eine Dauer-an-LED, gibt ggf Jumper auf den board, um was abzuschalten.

[clemens]

Wir haben ja nun den deep sleep mode implementiert und im Thread Batterieüberwachung, voltage divider und attenuation für MicroPython-Firmware - #42 by MKO die Grundlagen geschaffen um den Batteriezustand unserer nodes zu überwachen. Dort hat Andras auch schon erste Messungen über die Zeit gepostet:

@Andreas

Bei VCC-Panel auf FiPy-Testbench-Dashboard. Mit Annotationen.

Eine Laufzeit von 8h – mit deep sleep! – allerdings alle 60 Sekunden Messung ist nicht sooo berauschen, schauen wir, wie wir das besser machen können!

[clemens]

Hier ein paar Zahlen, gemessen mit der aktuellen Firmware:

Der WiPy braucht im deep sleep 10,6 mA

… der FiPy im deep sleep 74,5 mA

Das spricht erst mal dafür, dass wir die radios oder was anderes FiPy-spezielles noch nicht ordentlich abgeschaltet haben. Aber auch die 10 mA des WiPys sind jenseits von Gut und Böse:

@clemens

The new version 3.0 of the WiPy has a power consumption of 0.02 mA in sleep mode .

[Andreas]

Mir fiel vorhin noch ein: “Serielle Schnitte abschalten – ist das möglich?”.

[clemens]

Einige Boards haben ja eine USB-Schnittstelle, die braucht Strom, ist bei uns aber auf das Expansion Board ausgelagert, d.h. dort könnte man sie abschalten, müssten wir aber nicht, wenn wir nur die Platine verwenden. Braucht die Serielle Strom, wenn man nix schickt? Und im Deep Sleep ist die doch sowieso aus, oder?

[clemens]

Ok, further research! Habe den WiPi am Multimeter, der im deep sleep 10 mA verbraucht und nacheinander die einzelnen Sensoren abgeklemmt.

kritischer Stromverbrauch einzelner Sensoren im deep sleep

Keine DS18B20 reduzieren den Verbauch nicht sonderlich, auch der BME280 ist erst mal unkritisch. Der faule Apfel oder gärige Honig ist die Wägezelle / der HX711. Wenn man E+ abklemmt geht der Verbauch von 10 mA auf ca. 3,5 mA zurück.

Ab Zeile 101 gibt es in der /hiveeyes/sensor_hx711.py eine power_off mit

hiveeyes/hiveeyes-micropython-firmware/blob/df2e78a82578cf2426a4f3920a325fe83f74201c/hiveeyes/sensor_hx711.py#L101-L103

und auch das logging sagt

32.4655 [hiveeyes.sensor_hx711    ] INFO   : Turning off HX711

scheint aber irgendwie nicht zu greifen!

Unsere Standard-Arduino-Bibliothek kann den HX711 bzw. über den HX711 den Verbraucher Wägezelle gut abschalten, an der Hardware sollte es also nicht scheitern. Müsste 'ne Software-Geschichte sein.

[Andreas]

Hi Clemens,

@clemens

"Turning off HX711" scheint irgendwie nicht zu greifen!

Unsere Standard-Arduino-Bibliothek kann den HX711 bzw. über den HX711 den Verbraucher Wägezelle gut abschalten, an der Hardware sollte es also nicht scheitern. Müsste 'ne Software-Geschichte sein.

Schade. Also Haube auf…

Die C++-Implementierung sieht folgendermaßen aus:

bogde/HX711/blob/0.7.2/src/HX711.cpp#L266-L273

Die MicroPython-Implementierung sieht ganz gleich aus:

hiveeyes/terkin-datalogger/blob/0.4.0/lib/hx711.py#L120-L125

Für Vorschläge und Nachforschungen wäre ich sehr dankbar. Gerade habe ich noch Turn off interrupts when powering down the HX711 · hiveeyes/terkin-datalogger@1d88b63 · GitHub hinzugefügt, aber dann bin ich mit meinem Latein am Ende. Wäre vorstellbar, dass der ESP32 auch hier zu schnell unterwegs ist und man daher zwischen dem Zuppeln am SCK kurz mal warten sollte?

Merci,
Andreas.

P.S.: Falls das “zwischendrin warten” irgendwie Sinn machen sollte – so ginge es:

import time
time.sleep_ms(50)

[Andreas]

Hi there,

@Andreas

P.S.: Falls das “zwischendrin warten” irgendwie Sinn machen sollte – so ginge es:

import time
time.sleep_ms(50)

Just learned from [SOLVED/WORKEDAROUND] Having problems with HX711 load cell sensor - MicroPython Forum (Archive) that

def powerDown(self):
    """
    Power the HX711 down as per datasheet.
    Setting high longer than 60 microseconds.
    """
    self.pdsckPin.low()
    self.pdsckPin.high()
    time.sleep_us(80)

Which is also confirmed through the datasheet and Electrical Engineering Stack Exchange:

When PD_SCK pin changes from low to high and stays at high for longer than 60µs, HX711 enters power down mode.

– https://cdn.sparkfun.com/datasheets/Sensors/ForceFlex/hx711_english.pdf
– esp8266 - HX711 Power Down Handling - Electrical Engineering Stack Exchange

A GPIO-based implementation for the RaspberryPi is also doing it likewise:

dcrystalj/hx711py3/blob/master/hx711.py#L99-L115

That research was easy.

Cheers,
Andreas.

[MKO]

Bin zu dem gleichen Ergebnis wie @Clemens gekommen, was ich mich jetzt noch frage ist, was macht der Pycom im Deep Sleep modus draus. Habe mich noch nicht viel damit beschäftigt, aber fällt der SCK dann nicht wieder auf False und der HX711 fährt dann wieder hoch?

[Andreas]

@MKO

was ich mich jetzt noch frage ist, was macht der Pycom im Deep Sleep modus draus. Habe mich noch nicht viel damit beschäftigt, aber fällt der SCK dann nicht wieder auf False und der HX711 fährt dann wieder hoch?

Exakt jenes frage ich mich auch. Ich hoffe wir wissen grob was wir tun und es klappt aufgrund von PULL-UP/PULL-DOWN Charakteristika ebenfalls genau so wie anderswo auch. Wenn jemand unsere Zweifel fundiert vom Tisch wischen kann: Her damit!

[MKO]

Das schnellste was mir jetzt auf die schnelle einfallen würde, wär ein externer Pullup.

Den könnte man auch zum testen mal auf die schnelle unten auf die Platine klöppeln.

[Andreas]

@Andreas

When PD_SCK pin changes from low to high and stays at high for longer than 60µs, HX711 enters power down mode.

Per Sleep for 80 microseconds after pulling HX711 clock pin to high · hiveeyes/terkin-datalogger@fedbe6f · GitHub jetzt mal so implementiert wie auch anderswo gesehen – mit der Bitte um Review und Tests.

[Andreas]

@MKO

Das schnellste was mir jetzt auf die schnelle einfallen würde, wär ein externer Pullup.

Andere sagen das auch:

Set the PD_SCK pin to the output mode before readings, and to the HIGH-Z/INPUT mode before esp8266/hx711 powerdown, use pullup resistor.

– esp8266 - HX711 Power Down Handling - Electrical Engineering Stack Exchange

---

Und/oder:

Use a FET to allow Open Drain operation.

simulate this circuit – Schematic created using CircuitLab

The RUM001L02 has a very low VGS(threshold) and is readily available. Remember your PD_SCK is now logically inverted.

– esp8266 - HX711 Power Down Handling - Electrical Engineering Stack Exchange

---

Haben wir das schon vorgesehen und hier berücksichtigt? Steht bestimmt schon irgendwo im Forum… ;].