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

Bee Observer BOB Entwicklung
, ,
131

Vielen Dank fürs Nachmessen!

… und das, obwohl wir den bei [Backlog] Terkin-Datenlogger für BOB - #2 by Andreas sowie Versuchsaufbau "Autonome Zelle" #1 & #2: Solar-Feinstaub-Wetter-Vergleichsding erwähnten “forced mode” für die BME280 noch nicht aktiv implementiert haben?

132

2 posts were merged into an existing topic: Kontinuierliche Verbesserungen des Terkin-Datenloggers (600er)

133

Mein Testsystem braucht gerade 73 µA, hmmmm??

134

Ich hab diesmal ja andere BME280 mit nur ausgeführten I²C Bus verwendet. Vielleicht liegt es auch daran.
Werde die beiden heute Nacht Mal beide Durchmessen. Hast Du @clemens auch ds1820 mit dran?

1 Like
135

Ja, 5 Stück.

136

9 posts were merged into an existing topic: BME280 optimaler mit MicroPython ansteuern

146

Neuigkeiten

image
image.png868×524 31.9 KB

– amo-fipy-testbench-power – 39h runtime on batteries

147

Wär jetzt interessant zu wissen, wie viele Sendezyklen er jetzt im vergleich zu 0.5.1 geschafft hat. soweit ich mitgekommen bin hast du ja die Wachzeit versucht zu verkürzen.

Aber 1,5 Std. weniger als 0.5.1? Ist aber trotzdem echt schwer einzuschätzen, ob da nicht noch andere Faktoren mitgespielt haben. Optimierung Wartezeiten der DS1820? evtl auch Verschleiß der AKKUS, da sie ja immer bis an die Maximalgrenze gefahren werden? Das Expansionsboard? usw.

148

Ich wollte es einfach nur mal wieder laufen lassen. Ja, wir hatten ursprünglich gehofft, dass die ahead-of-time Bytecode-Kompilierung hier Zeitersparnis bringt – v.a. um die Turnaround-Zeit zu optimieren.

Joa, eben. Ist ja nun aber auch nicht so weit auseinander. Vielleicht war es das letzte Mal der andere Akku oder der Watchdog braucht nun auch ein wenig mehr Strom oder irgendwas. Auf jeden Fall ist der durchlaufene Code nicht weniger geworden und die ahead-of-time Kompilierung hat erstmal leider auch nicht die gewünschten Verbesserungen gebracht, die sich ja auch positiv aufs Strombudget hätten auswirken können.

150

Ich habe vorgestern auch mal die Stromaufnahme nachgemessen…
Beim SETUP selber habe ich nicht Mikro sondern Milliampere … Die Last beim Senden kenne ich noch nicht, messe ich demnächst aber auch noch…

Ich habe von Diren gehört, dass über ein Intervall beim Senden von 10sec. nachgedacht wird, Während dieser 10sec. ist dann aber doch der µC mit DS18B20 Abfragen antriggen und aufnehmen beschäftigt… Dann kann ich doch nicht in den DeepSleep …. oder ist das die “Nachtabsenkung” ?

Kann man ggf. für die Intervallzyklen DAY und NIGHT ggf. auch Parameter auf der CONFIG Seite mit aufnehmen ? So muss man nicht wieder neu flashen …
Und bei der späteren Datenanalyse denke ich wird ohnehin auf Viertelstunden / Stunden oder gar Tagesscheiben verdichtet ?

151

Nein, solche häufigen Meßzyklen sind nicht unbedingt für den deep sleep Modus geeignet, den man ohnehin meist haben will, wenn Akkubetrieb angesagt ist.

In diesem Szenario muss die Appliance an eine ordentliche dauerhafte Stromversorgung und dann kann man auch auf den deep sleep Modus verzichten.

Korrigiert mich bitte, falls ich hier einen Denkfehler habe.

1 Like
152

Ja … hab ich mir schon gedacht…

wie verhält es sich denn mit der Konfig Frage iSv. Zyklusvariablen beim SETUP?
DAY = 10sec. oder 30 sec.
Night = 240sec.

z.B.

153

Unabhängig davon, dass die dort angegebene Zeit derzeit nur die Schlafdauer angibt (muss verbessert werden), wollen wir das Meßintervall gerne zukünftig dynamisch regeln und auch vom Ladezustand des Akkus abhängig machen.

Für eine sinnvolle Steuerung in Abhängigkeit von der Tageszeit muss die exakte Zeit vorhanden sein. Diesen Aspekt haben wir bisher beim Terkin-Datenlogger noch nicht berücksichtigt.

154

5 posts were merged into an existing topic: ESP32 RTC clock im Deep Sleep Modus

157

Folgende Beiträge habe ich gerade noch im Pycom Forum aufgeschnappt:

158

@robert-hh said:

@KenM My best experience with going to sleep is by setting pins, which drive external loads, to input mode before going to deep_sleep. Then it is guaranteed to be in high impedance state. Unless of course you need it to drive something, which of course then consumes power.

2 Likes
159

Das ist zwar nicht vollständig unser Metier, weil wir bei BOB keinen Pysense benutzen, es ist aber für alle die das interessant finden trotzdem eine sehr wichtige Information, deswegen reihe ich das mal hier an.

Dank

verbraucht der Eumel dann nur noch

Ich denke beim Pytrack wird es genauso funktionieren.

cc @tonke

160

Nun ist die Frage wie die das machen? Sind es irgendwelche Einstellungen am WiPy / GPy / FiPy oder übernimmt die Kontrolle in deep sleep das expansion board? Irgendwo stand doch bei Pysense was von PIC. Ich kenne das PySense-board aber nicht.

Mit dem WiPy3, der Arduino-IDE und dem Arduino-Core komme ich mit einem einfachen deep sleep Zweizeiler ohne jegliche Optimierung auf etwas unter 20 uA.

Wenn wir z.B. an den pin states noch schrauben könnten um da noch weiter runter zu kommen wäre das prima, falls das die Stellschraube sein sollte und es nicht das board ist.

161

Ich vermute es. pycoproc.py steuert den PIC an. Dort sind die entsprechenden Routinen untergebracht, um ihn per I2C anzusteuern – konkret bei pycom-libraries/lib/pycoproc/pycoproc.py at 7e980233fa6316b05e35681c9793e0ad4faf3c7f · pycom/pycom-libraries · GitHub.

Vermutlich läuft das konzeptionell ganz ähnlich wie es @wtf, @weef und @roh bei Versuchsaufbau "Autonome Zelle" #1 & #2: Solar-Feinstaub-Wetter-Vergleichsding - #11 by wtf mit dem RTC-Baustein gemacht haben.

166

siehe: RTC in combinattion with deepsleep unusable | Pycom user forum

There are two different ways to achieve deep sleep:

  • machine.deepsleep uses the internal ESP32 deep sleep mode. That one will keep the RTC alive.
  • Pysense-controlled deep sleep (using the setup_sleep / go_to_sleep from the Pysense library) just completely switches off the ESP32, including the RTC (it really cuts all power to the ESP32).