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

Bee Observer BOB Entwicklung
, ,
67

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.

68

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.

69

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.

70

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:

71

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:

72

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

73

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
74

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
76

Hi Michael,

merci fürs Dranbleiben.

FiPy-Peripherie komplett abschalten

Ja, das sehe ich auch so. Vermutlich ist es das LTE-Modem. Eine verlässliche Quelle berichtete mir:

Strom sparen durch Laufzeitoptimierung

Absolut. Selbst wenn es im Vergleich dann nicht mehr so signifikant viel am Stromverbrauch einsparen wird, würde ich das alleine aus Laufzeitoptimierungsgründen exakt so tun.

Erstmal müssen wir aber die deutlich teurere Peripherie abschalten – Pflicht vs. Kür ¹.

Grundsätzlich würde ich aber sehr sehr gerne die Verarbeitung von Teilen der verschiedenen Subsysteme im Hintergrund erledigen. Durch das wunderbare FreeRTOS unter der Haube und die Ausführung per Threads innerhalb von Python ist das grundsätzlich voll erschlossen, will dann aber natürlich auch ordentlich koordiniert werden, damit das Gesamtsystem weiterhin robust bleibt.

Ich hoffe das passt für Dich.

Viele Grüße,
Andreas.

¹ An den Spruch “premature optimization is the root of all evil” muss ich mich manchmal auch diszipliniert selbst halten - mag er auch manchmal nicht angebracht sein (Ausnahmen bestätigen die Regel). Selbstverständlich immer mit Augenzwinkern ;].

– http://wiki.c2.com/?PrematureOptimization

P.S.: Neulich schonmal bei… ;]

77

Running with lte.deinit() before deep sleep

Einleitung

Dies hier sieht nicht schlecht aus: Knapp 18 Stunden Laufzeit hat der Kleine hinter sich und immer noch 3.6V, wenn wir mit der Batteriespannungsmessung (Batterieüberwachung, voltage divider und attenuation für MicroPython-Firmware - #71 by roh) nun alles richtig gemacht haben. Bei mir ganz ohne SIM-Karte im Slot, was ja auch noch ein fraglicher Aspekt bei der Angelegenheit ist.

Daten

image
image836×540 32.9 KB

amo-fipy-testbench with lte.deinit().

Datenherkunft

Das Gerät ist weiterhin jenes, das oben bei Akkulaufzeit malen und beobachten ins Spiel kam – ohne jegliche Peripherie, auf dem Expansion Board – daher zwar nicht unbedingt repräsentativ für den eigentlichen Einsatz, als Vergleichsobjekt aber gerade für die aktuellen Aufgaben hervorragend geeignet.

Commit

78

@clemens meinte dazu vorhin noch, dass man mit den Ergebnissen noch vorsichtig sein sollte (wie immer! ;]), weil sich der LiPo vielleicht erst durch ein paar Ladezyklen warmlaufen muss, damit er seine volle Kapazität entfalten kann. Ist da was dran?

1 Like
79

@Andreas haben wir es den schon mit

Ich habe eben oben noch aufgeschnappt, das es nach aktivierung des “Fly-Mode” und evtl der Anrufsperre dennoch klappt.
Habe aber noch nicht gefunden wie ich ihn aktivieren könnte.
Der Flymode klingt auf alle fälle sehr logisch, das er das Problem umschiffen könnte, da ich weiß, das bei einem “normalem” Handy in diesem Modus die Sim abgeschaltet wird.
Ein Handy ist ohne Sim oft kaum zu bedienen im Flymode aber nahezu problemlos. Einen versuch wär es sicher wert.

80

Hi Michael,

Bei diesem Beitrag im Pycom-Forum geht es vor allem um ein spezielles Deepsleep-Board, das bei erwähnten frühen Hardware-Versionen einer Reihe von Pycom Geräten als Workaround nötig war.

Der FiPy ist von diesem Problem nicht betroffen.

Trotzdem kann sich in dem Beitrag das ein oder andere verirrt haben, was mit dem FiPy zu tun hat und uns weiterhilft, man muss aber ordentlich differenzieren, weil andere durch die Umstände ebenfalls manchmal verwirrt sind. Einen vorgefilterten Einblick vermittelt LTE-Modem des Pycom FiPy komplett stilllegen.

Hatte ich auch irgendwo gestreift, danke. Hast Du vielleicht noch den Direktlink im Tab?

Viele Grüße,
Andreas.

81

Das galt mal und gilt bei NiCd und NiMH, aber nicht mehr bei Lithium-Systemen. Es ist kein priming oder Formieren mehr nötig.

Wichtiger wäre höchstens, daß ein Akku für derart kleine Entladeströme und solche kleiner Kapazität zu Beginn seines Einsatzes einmal einige Minuten lang 0,5C oder 1C Entladestrom gesehen hat, wenn er die gesamte Zeit danach mit nur 0,01C oder noch viel weniger entladen wird. Aber selbst ohne so eine Prozedur kommt der Akku klar, da er ja zwischen seinen Schlafphasen kurzzeitig auch mal größere Ströme liefern muß (je nach Funk-Interface oder zu speisenden Sensoren).

Hier die beiden Entladekurzen mal mit gleichem Anfang, und was ich hier sehe, ist ganz klar ein Fortschritt:

fipy-moll

Aber es gibt offenbar keine ordentliche Abschaltung, unter 3,3V kommt keine Energie mehr aus dem verwendeten Akku, außerdem leidet er durch Entladung unterhalb Entladeschlußspannung (im Bild roter Punkt) und dankt das mit permanent verringerter Speicherfähigkeit und verkürzter Haltbarkeit - aber das Thema gehört auch woanders hin, und wissen auch alle eh ;) …

Leider weiß ich nicht genau, wo das Ding mißt, denn über 4,2V an dieser zelle sind unplausibel (das ist über Ladeschlußspannung), oder sie wäre Dir schon ‘entgegen gekommen’…

2 Likes
82

Das müssen wir noch in die Firmware einbauen, steht im Backlog. Oder ist dafür normalerweise eine Hardwarekomponente zuständig?

Dachte ich mir auch schon. Ich gehe bei der nächsten Runde wieder von 11dB runter auf 6dB Dämpfung am VCC-ADC, ich glaube da waren die Werte plausibler. Quatsch oder Nonsense? :P

Werte plausibler mit 6dB Dämpfung am VCC-ADC.

Proof.

image
image776×460 31.7 KB

https://swarm.hiveeyes.org/grafana/d/-jm-KRVWz/amo-fipy-testbench-power?orgId=2&from=1560887000566&to=1560990656090

83

Wenn es also wirklich weiterhin notwendig ist, lte.deinit() zu rufen, dann denke ich mir: “Warum nicht gleich nach dem Aufwachen, als kurz vor dem Schlafengehen?”, solange wir das Modem ohnehin nicht brauchen.

84

image

86

Bei Releases · hiveeyes/hiveeyes-micropython-firmware · GitHub gibt es ein neues Release zum Testen. Weitere Details dazu:

Da es ein paar neue Konfigurationseinstellungen gibt, könnte man die aktuelle Konfiguration 1:1 aus hiveeyes-micropython-firmware/settings.example-bob.py at 0.5.1 · hiveeyes/hiveeyes-micropython-firmware · GitHub übernehmen, dort sollte alles enthalten sein.

Vielen Dank schon im Voraus!

87

Ja nicht direkt, aber Probleme macht er ja trotzdem. Zumindest sind nirgendwo wo ich bisher geschaut habe, klare Bedingungen für den wirklichen Deep Sleep von ~20µA zu finden.
Meinte aus dem obigen Thread diesen.

image
image875×117 7.73 KB

Da geht es auf alle fälle um den FiPy und dem Flymode

Die letzten Beiträge und antworten diesem Thread (unten) sind auch äußerst interessant.
https://forum.pycom.io/topic/4877/deepsleep-on-batteries/10
Scheint auch eine Möglichkeit zu geben das Modem on Boot aus zu lassen.
aber auch neue Probleme unter 4V.

88

Interessante Verwirrung / Überblick

Ja, ich finde auch alles ziemlich hochinteressant. Leider aber gleichermaßen widersprüchlich an manchen Stellen. Aber ja: Intensives Lesen dort im Forum machte die Firmware im aktuellen Stand überhaupt erst möglich.

Hier habe ich vieles im aktuellen Kontext Relevantes zusammengetragen. Jeweils chronologisch, damit man besser im Blick hat was alt und was neu ist.

Deepsleep-Shield bitte ignorieren

Den älteren Beiträgen von ~2017 würde ich im Vergleich keine allzu starke Beachtungen schenken, da liegen hoffentlich Äonen dazwischen im Vergleich zu dem was wir jetzt auf dem Tisch haben.

Gerade alle Beiträge zum “Deepsleep-Shield” können wir getrost ignorieren.

Hier dazu auch eine gute Zusammenfassung:

LTE Modem Flugmodus (fly mode)

Bis jetzt kam mir dieser noch nirgendwo unter – vermutlich muss man dafür das Modem erst initialisieren. Die neueren Beiträge geben darauf aber keinerlei Hinweise, die Reise geht eher in Richtung “in Ruhe lassen, dann passt alles schon”. Momentan wird aber sowohl LTE Modem als auch Bluetooth bei Systemstart heruntergefahren: