Folgende Beiträge habe ich gerade noch im Pycom Forum aufgeschnappt:
@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
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
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.
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.
siehe: RTC in combinattion with deepsleep unusable | Pycom user forum
There are two different ways to achieve deep sleep:
machine.deepsleepuses the internal ESP32 deep sleep mode. That one will keep the RTC alive.- Pysense-controlled deep sleep (using the
setup_sleep/go_to_sleepfrom the Pysense library) just completely switches off the ESP32, including the RTC (it really cuts all power to the ESP32).
gibt dadurch dann wieder ein bekanntes problem Lopy + Pytrack: How to keep track of time in deep sleep | Pycom user forum den Lösungsversuch finde ich aber interessant. kann man vielleicht über einen weiteren interupt Timer erzeugen, der kurz vor dem WDT aktiv wird und die aktuelle zeit zwischenspeichert. als lösungsansatz für RTC time does not survive WDT | Pycom user forum
Für kurze Messintervalle ist bei der Terkin sicher noch der light sleep interessant. Ist im enteffekt ein Deep sleep nur, das der Speicher noch mit Strom versorgt wird. Pins müssen mit Hold wie beim Deep sleep gehalten werden. Radios gehen auch alle aus die RTC läuft weiter.
Bei Pin interupt bin ich dran sollten auch gehen ist bei Pycom nur schlecht dokumentiert sollte aber wie beim deep sleep funktionieren.
Wlan logt sich automatisch wieder ein.
from machine import sleep
sleep (ms)
1 Like
Hi Michael,
Lightsleep müsste drin sein. Vielen Dank!
Der Eintrag fehlt aber noch in der Blaupause für die Konfiguration, deswegen ahnt man es nicht.
Hier einfach 'lightsleep': True schreiben, damit sollte das klappen.
Ich komm zwar grad nicht drauf, aber irgendwas war noch damit (komisch) – es hatte einen Grund, warum ich nicht die Konfigurationsblaupause damit bestückt habe. Vielleicht täusche ich mich aber auch und alles klappt so wie es sollte.
Viele Grüße,
Andreas.
Gut zu. Wissen. Werde das nochmal überprüfen. Evtl. wurde ja bereits stillschweigend ein Bugfix gemacht.
Der riesige Vorteil von light sleep ist, das man den niedrigen Stromverbrauch nicht extrem teuer durch lange Bootphasen, in den sehr viel Strom verbraucht wird, erkaufen muß.
Bei Hiverize/Fipy/Kamerun kann man z.B. mit der gleichen Energie anstatt nur einmal 7 Mal messen. Und ich hab dabei nochnichtmal berücksichtigt, das dort beim booten ein vielfaches an Strom fließt, als im Normalbetrieb.
Aktuell tippe ich dort, mit den anderen teilweise radikalen Stromspar-Maßnahmen auf eine Akkulaufleistung von über 8 Tagen. Vorher waren es 7h.
1 Like
Leider konnte ich den Light Sleep im terkin Datalogger noch nicht testen. Allerdings gehen im Light Sleep wie im deep Sleep die Buttons nicht.
In deep kann man ja auch Interrupts auf gipo Pins legen die dann allerdings ebenfalls ein Reset auslösen. Mann muß nach den aufwachen dann den Grund des resets auf die spur gehen.
Im light Sleep wird ja kein Reset ausgelöst, man könnte also dann rein theoretisch gleich weiter machen.
Leider ist light Sleep bei Pycom praktisch gar nicht richtig dokumentiert.
Wär schön wenn jemandem was nützliches dazu einfällt oder über den Weg läuft.
Habe jetzt einen echt mekwürdeigen Fehler gefunden wo ich verzweifle.
habe machine.pin_sleep_wakeup verwendet um vorzeitig aus dem leichten Schlaf zu kommen, was auch vorzüglich funktioniert der AP oder Send wird auch artig nach dem Aufwachen gestartet. Nur hängt sich anscheinend die ausgabe vom sleep interrupt auf. Wenn ich jetzt mit dem Resetbutton resette. Fährt er normal hoch und macht seine erste Messung und geht dann in den schlaf und sofort nach dem aufwachen wird dann der AP oder Send button interupt aktiviert und er startet ihn wieder.
Als ob der status des Pins gepuffert und an den Interupt weitergeleitet wird.
Kurzeitiges Trennen vom Strom oder der Resetbutton bringt gar nichts einzig der WDT und ein machine.reset() schafft es den Interupt wieder zurückzusetzen. Nach jedem Aufwachen das gleiche spiel. Mit einem zuvor gespeicherten “state = disable_irq()”-state habe ich es leider auch schon erfolglos versucht. scheint als würde es irgendwo im ULP co-processor oder im RTC speicher hängen.
@Andreas viellecht hast Du ja eine Idee, wie man den zurücksetzen könnte.
Hier mal eine Messung des Stromverbrauchs mit der Hiveeyes-Terkin-Datalogger-Software und Datenübertragung via LTE. Am FiPy sind angeschlossen: Bosche H30 als Waage, 6 DS18B20, der “BOB”-BME280. Gemessen wurde mit einem CurrentRanger der per bluetooth die Messdaten auf einen Rechner übertrug.
Im Betrieb waren das um die 250 mA, was die Daten oben auch zeigen.
Im deep sleep ging der Verbrauch nur auf ca. 80 uA runter. Eigentlich zu hoch!
Das Messinterval war gerade auf 1 Minute, ggf. hat das LTE-Modem da keine Zeit sich aus dem Netz zu verabschieden und runterzufahren (?). Nun das Messintervall auf 20 Minuten gesetzt, tut sich aber nichts, immer noch die 75 uA Verbrauch. Habe den BME280 (das BOB-Modell, das auch 5 V verträgt) abgeklemmt, damit sind es dann ca. 20 uA weniger, aber immer noch 50 uA.
1 Like
Wäre Klasse, wenn Du die gleiche Messreihe auch Mal mit Light-Sleep machen könntest.
Dieser hat zwar etwas mehr Stromverbrauch als der Deep-Sleep, da aber das relativ lange hochfahren wegfällt, wird im Durchschnitt weniger Leistung verbraucht.
Ich würde gerne Wissen/Ausrechnen ab welchem Messintervall Deep-Sleep besser als Light Sleep ist.
Gab es noch einen Grund warum es noch nicht korrekt funktionieren sollte?
Light Sleep hat bei Pycom noch ein Wake on Button/Touch Interrupt Problem. Und zu dem Zeitpunkt als @Andreas diesen Text schrieb nur in der Beta von Pycom unterstützt.
Das Problem hat mit dem ermitteln des Aufwachgrund und festhängen des Interrupts nach dem Aufwachen bis hin zu Core Panik zu tun. Solange man ihn nur mit wakeup on time nutzt macht er keine Probleme.
Habe da mit der Hiverize-Kamerun-Firmware schon so einiges probiert. Solange ich ihn nicht per Button aus dem Schlaf wecken wollte lief er mit einem 2000mA Akku mit abgeschalteten WLAN und Speichen auf SD stolze 8,5 Tage ununterbrochen durch.
Scheint mit LTE nicht zu gehen, bleibt nach dem ersten light sleep-Zyklus hier hängen:
34.0494 [terkin.telemetry.core ] INFO : MQTT payload: {"system.uptime": 177.267, "system.voltage.battery": 11.328, "system.temperature": 4.956528, "system.time": 154, "system.memfree": 2454784, "system.runtime": 146}
Wenn das Modem im Rahmen der (deep) sleep-Einleitung herunterfährt wirds aktuell glaube ich nicht mehr neu initialisiert.
OK, danke für den Versuch.
Schau ich mir gleich an, vielleicht wird der Light-Sleep auch nicht richtig ein- oder aus-geleitet.
Andreas könnte damals ja anscheinend auch nicht richtig testen.
Ohne Deep-Sleep mit Sleep bzw. Delay funktioniert das Modem aber hoffe ich oder? Sonnst Brauch ich gar nicht testen, dann liegt es daran.
Ja, das geht! Connection loss ist noch nicht berücksichtigt, daher ist der deep sleep code stabiler als der ohne bei dem nur ein mal eingewählt wird und dann davon ausgegangen wird, dass die Verbindung stehen bleibt.
Habe leider gerade wieder Probleme mid der Sandbox - make setup
kann daher nix probieren.
allerdings bin ich darauf gestoßen das Machine:sleep() veraltet ist.
https://docs.micropython.org/en/latest/library/machine.html
also müßte in device.py:441 anstat
machine.sleep(int(interval * 1000))folgendes stehen
machine.lightsleep(int(interval * 1000))ob das das lightsleep problem löst, weiß ich nicht
Allerdings gab es in der 19.x Beta auch schon Probleme mit dem automatischen Neustart von Modems. Finde das leider nicht mehr.
Es wurde seitens der Firmwareentwickler versprochen Abhilfe zu schaffen.
Es wurde aber auch empfolen, das Modem solange selbst neu zu initialisieren und zu verbinden.