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

Die SIM muß nur überhaupt lesbar sein und braucht kein Guthaben. Danke, @weef.

Von letzterem würde ich mich nicht per se abschrecken lassen. Das ist vermutlich nur irgendwelchen Vertriebs-Policies geschuldet, die Pycom ihrerseits wahrscheinlich mit ihren Zulieferern eingehen musste – in diesem Fall dem Hersteller des Sequans Modems bzw. des Baseband-Chips, der darin verbaut ist.

Diese Domäne konnte bisher leider noch nicht von Open Source Implementierungen erschlossen werden, da das Know-How von den entsprechenden Herstellern intensiv gehütet wird. Entsprechend sensibel und diffizil gestaltet sich oft der Umgang mit jeglichen Firmwarebestandteilen in diesem Bereich.

1 Like

Habe jetzt aber mal was richtig Gutes zu verkünden. Ich habe den Test mal mit dem WiPy wiederholt.
und was soll ich sagen 0.00A im Deep Sleep mit allen Sensoren und WLAN nur die MQTT und HTML Übertragung war aus genau so wie gestern mit dem FiPy.
Unter 0.00A konnte ich allerdings nicht Messen, da ich mein Messgerät in der Firma liegen lassen habe und mein Digitalnetzteil es nicht genauer ausspuckt.

Testbedingungen:

  • Datalogger 0.4.0
  • WiPy 3.0
  • Firmware 1.20.0.rc11
  • Clemens Solar Board V0.0.14 ohne Solarregler!
  • Bosche H40
  • Hx711 mit pullup
  • 6X DS1820
  • 1x BME280
  • WLAN an und verbunden
  • keine Datenübertragung aktiv
  • Eingangsspannung 4.2V

image

Großes Lob an dich @Andreas und alle die dir auf dem weg geholfen haben.
Wär doch gelacht, wen wir den FiPy nicht auch noch kleinlaut bekommen.

1 Like

Hi Michael,

Sehr schön!

Bei Dir hat es im Vergleich zu vorher also vor allem der

gebracht? In dem Fall gebe ich das Lob gerne an die Hardware-Gurus unter uns weiter.

Ich frage mich noch, ob gerade für die korrekte Ansteuerung des Pullups der commit Sleep for 80 microseconds after pulling HX711 clock pin to high · hiveeyes/terkin-datalogger@fedbe6f · GitHub relevant ist, der nach dem 0.4.0 Release dazugekommen ist. Hast Du also sicher die 0.4.0 drauf oder den aktuellen HEAD/master aus dem Git repository?

Am Ende ist die leichte Softwareanpassung vermutlich sogar wurscht, weil ja nach dem Einschlafsignal ohnehin nicht mehr mit dem HX711 kommuniziert wird und er auch ohne die Verbesserung der Software alleine durchs Vorhandensein des Pullups nun sauber einschläft.

Mutmaße ich hier richtig?

Aktuelles master also inkl. pause
image
Ist aber der gleiche stand, von gestern Abend mit dem FiPy. Wenn Du möchtest kann ich das gerne mal rauskommentieren.

Ja sollte wurscht sein wichtig ist nur das das Signal min 80 microsekunden lang ist. und das ist es ja, auch wenn der WiPy in diesem falle vorher schon einnickt.

ja, hast Du nun den pull-up (an PD_SCK) dran oder nicht?

Ja habe ich.
Allerdings einen recht hohen 1MOhm.
10 K gingen nicht, da der HX711 dann nicht immer zuverläßig aufgewacht ist.
Ich vermute, das das Gate nur nach 3V3 hochgezogen wird und im False zustand offen / Hochohmig ist.

Im Sinne von

wollte ich an dieser Stelle nochmals auf Low power ESP32: Software tweaking (less hardware) verweisen, vor allem aber explizit auf die Inhalte bei Schaltbare Stromversorgung für Verbraucher bei Pycom Modulen hinweisen.

Vermutlich machen wir gerade alles richtig alles besser als bisher, aber Luft nach oben ist bekanntlich immer ;]. Remember: I’m not the hardware guy here, so don’t believe me anything about that topic and think for yourself first ;].

Danke an alle fürs mittun!

Was ich hierzu noch im Hinterkopf hatte: Set Level of GPIO at sleep. Es scheint eine Funktion rtc_gpio_set_level() zu geben. Kann man damit etwa mit der RTC-Einheit emulieren, was wir gerade mit dem Hinzufügen des Pullup erreicht haben oder ist das kompletter nonsense?

emulieren? wie kommst Du denn dadrauf? ;) nein. rtc_ meint in diesem Kontext die “backup domain” oder “RTC domain”, eben alles, was im deep sleep noch mit Strom versorgt wird. Einige GPIOs sind in der backup domain, daher lassen sich deren level und states ‘einfrieren’ vor und für den deep sleep.

Sollte der PD_SCK also an einem in der RTC domain befindlichen GPIO sein, könntest Du das auch in sw machen. Wenn aber extern dann auch noch ein PU ist, dann liegen die parallel, und je nach Wert des externen Widerstands wird der Gesamt-R vielleicht zu klein für den ESP32 und seine Fähigkeit, diesen pin dann auch noch nach LOW zu ziehen.

Interne pull-ups (und -downs) sind ‘weak’ und schwanken in weiten Bereichen auch im gleichen device: ab 20k bis 80k oder manchmal 100k findet man. Ein externer Widerstand dazu sollte also auch weak sein, also hier nie kleiner als 20k, besser 50k oder 100k, fast egal. Auch 1M gehen, sind aber nicht allzu störfest.

Auf diese Weise würde ein ausreichend großer externer PU nie stören, wenn eine entsprechende Funktion in der fw dennoch eingebaut wäre; die fw kann von der Annahme ausgehen, daß es egal ist, ob ein externer R an PD_SCK ist oder nicht, sobald die von Dir erwähnte Funktionalität erschlossen sein sollte.

Solange das nicht der Fall ist, oder PD_SCK an einem nicht in der backup domain befindlichen GPIO: dann hilft hier nur ein externer weak pull-up.

1 Like

Danke, @weef!

GPIO state im deep sleep einfrieren

Herzlichen Dank für die genaue Beschreibung und die Aufklärung über RTC == “backup domain”. So in der Art meinte ich das, “emulieren” war unglücklich gewählt, weil mir der passende Jargon und v.a. das Fachwissen leider gänzlich fehlt.

Wir könnten also alternativ zum externen Pullup anstreben, jenes Feature hier zu benutzen?

Zusammenspiel zwischen internem “hold” und externem PU

Praktisch!

Fazit

Ich würde das softwareseitig so erschließen, wenn niemand Veto einlegt. Hardwareseitig: Kümmern sich diejenigen um dieses Detail, die hier mitlesen und sich zuständig fühlen? Danke!

Voraussetzung dafür ist, daß PD_SCK an einem der genannten GPIO ist:

Das sind laut Angabe also P2-P20 modulo P5, P7, P11 und P12.

=> Scheint so:


Damit hätten wir also vermutlich “How could this ever have worked?” bestens aufgeklärt. Danke!

Würde ich erst mal mit Vorsicht genießen die Aussage! Den ADS und auch den HX711 nutze ich ohne externe pull-ups! Beim ADS hatte ich den Stromverbrauch gemessen und der war ok, was ich damals - mehr aus Vorsicht als aus Wissen gemacht habe - den ADS mit einem normalen Pin mit Strom versorgt, dann kann man den kompletten Zweig abschalten. Meinen HX711 mit dem ESP8266 bzw. ESP32 und dem C-Code muss ich nochmal durchmessen!

Doof sind immer Pins, die high einen sleep mode oder “ausgeschaltet” triggern. Diese brauchen dann für unsere Verhältnisse recht viel Strom.

Die Aussage ist natürlich völliger Schrott, mea culpa.

Vielen Dank für diese Erklärung, @weef. Irgendwann kann ich sogar die Hardware verstehen.

Also: Noch nicht ganz. Die Frage “Wie das jemals hatte funktionieren können???” ist weiterhin ungeklärt, ich habe jedoch Vermutungen. Dazu will ich kurz stichpunkthaft Bilanz ziehen. Vielleicht fällt Euch ja was dazu ein.

Einleitung

  • Nachdem @clemens oben schrieb, dass der HX711 nicht bzw. v.a. auch die Wägezelle in unserem aktuellen FiPy-Setup nicht stromlos wird, war ich davon ausgegangen, dass das in den frühen Open Hive Implementierungen der Fall war und entsprechend überprüft wurde.

  • Nun stellte sich heraus, dass

    @clemens:

    [Nur] beim ADS hatte ich den Stromverbrauch gemessen und der war ok. […] Meinen HX711 mit dem ESP8266 bzw. ESP32 und dem C-Code muss ich nochmal durchmessen!

  • Bei den frühen Open Hive Implementierungen wurden niemals externe pull-ups verwendet.

    @clemens:

    Den ADS und auch den HX711 nutze ich ohne externe pull-ups!

Nanu?

HX711 power down control (Hardware)

Gute Recherchen im Datenblatt des HX711 auf Seite 5 haben folgendes ergeben.

Wir nehmen hier also mit:

HX711 power down control (Software)

Weitere gute Recherchen haben ergeben, dass diese Spezifikation so nicht im kanonischen Treiber für die Arduino-HAL implementiert ist, zumindest nicht exakt so.

Wie kann es also theoretisch funktioniert haben? (Falls überhaupt, wahrscheinlicher ist es nach dem aktuellen Stand der Erkenntnisse, dass es nicht funktioniert hat).

Wir fassen nochmals komprimierend-schlußfolgernd zusammen:

  • @clemens hatte keine externen pull-ups. Die verwendete MCU war ein AVR.
  • Die Software implementiert die Einschlafspezifikation unzureichend.
  • Für ordentliches Power Saving sollte PD_SCK auch im Deepsleep-Modus auf HIGH gehalten werden, was am pragmatischsten mit einem externen pull-up implementiert wird.
  • Wahlweise kann aber auch ein MCU-interner PU verwendet werden, wenn er in der dessen RTC-Domäne liegt und entsprechend konfiguriert wurde, den Zustand auch im Deepsleep-Modus einzufrieren (hold).

Nochmal komprimierter:

  1. Der Softwaretreiber implementiert den Einschlafvorgang nur unzureichend.
  2. Die Hardware fehlt augenscheinlich.

Meiner Meinung nach kann es an dieser Stelle also nur funktioniert haben, wenn - nachdem PD_SCK auf HIGH gezogen wurde - die MCU mindestens 60 us braucht um einzuschlafen und danach irgendein pull-up (sei es extern oder intern) übernimmt, der PD_SCK dauerhaft auf HIGH hält.

Das kann nicht anders sein, weil der Aufwachvorgang definitiv durch PD_SCK auf LOW determiniert ist:

When PD_SCK returns to low, chip will reset and enter normal operation mode.

An dieser Stelle ist auch die Implementierung korrekt:

Nun meine eigentliche Frage zur vermuteten Folgerung:

Kann es sein, dass auf dem Breakout-Board (oder nur auf bestimmten?) ein entsprechender pull-up verbaut ist? Das würde nach dem aktuellen Stand der Recherchen für mich absolut Sinn machen und wäre gleichzeitig die letzte Hoffnung für eine entsprechende Erklärung, wie es überhaupt funktioniert haben könnte.

Ansonsten bleibt nur:

Eines jener Yaks

ist also immer noch nicht ganz geschoren.

image

Körper

Danke @weef. Softwareseitig haben wir diesen Teil ja nun drin:

Beine und Hintern

Dies ist uns glücklicherweise möglich, da

und die

erfüllt ist, siehe oben bei Stromsparmaßnahmen für die MicroPython-Firmware im Batteriebetrieb - #63 by Andreas.


Herkunft des Yaks: Annapurna. Digitales Abbild: File:Bos grunniens at Letdar on Annapurna Circuit.jpg - Wikipedia

So Konnte jetzt mal den WiPy im Deep Sleep mit allen Sensoren Messen. Im Deep Sleep braucht er mit dem pullup im Deep Sleep 320μA ohne pullup 8,7mA.
ob die 80ns in der Software sind oder nicht ist egal.

Die 320μA Teilen sich wie gefolgt auf:

  • 171μA für die 6 DS1820
  • 98 μA HX711
  • 29 μA BME280
  • 22 μA WiPY 3.0

Mehr können wir denke ich nur noch Sparen, wenn wir den ganzen 3,3V Zweig mit einer FET Schaltung wie die hier von @Andreas angefragt und von @clemens schon angedeutet .
image
mit einem beliebigen Pin Ein und ausschalten.
Pxx False = 3V3 Aus
Pxx True = 3V3 An

Muß mal schauen ob ich noch ein paar kleine MOSFET in der Grabbelkiste finde.
Vielleicht baue ich die Schaltung mal auf.

Ich denke aber, da wir den Deep Sleep beim FiPy nicht mal ansatzweise Erreichen, sollten wir uns besser erstmal darauf konzentrieren.
Irgendwas Läuft da intern auf alle fälle voll Durch, was beim WiPy nicht vorhanden ist.

1 Like

Was ich hier noch als Thema fürs Strom sparen vermisse ist die Zeit in dem der Node wach ist.
Lässt diese sich evtl verkürzen? wenn wir jezt beim WiPy schauen ist der Unterschied Wach und Schlafmodus in einem so großen Verhältnis, das es evtl nur ein paar Sekunden mehr Gesammt-Laufzeit bringt im Schlafmodus Strom einzusparen. aber es bringt bestimmt Einige Stunden - Tage oder sogar Wochen , wenn man den Wachzustand verkürzt.
Gibt es da eine Möglichkeit?
Kann man einige Sachen parallel oder im Hintergrund laufen lassen? z.B. WLAN Starten und die Sensoren hochfahren und danach erst testen ob die Verbindung geklappt hat. Die Einstellungen der DS1820 zwischenspeichern um nicht jedes mal nachfragen zu müssen Wer und wo bist Du.

Oder Sensoren die recht lange zum starten brauchen, sich aber nur recht langsam die Werte ändern oder nicht so interessant sind nur jedes 2. bis 3. mal auszulesen und zu übertragen.

1 Like