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.
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 ;].
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.
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.
@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?
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.
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?
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:
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’…
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
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.
Es könnte nun auch ohne externen pull-up funktionieren, dass sich der HX711 schlafen legt. So wie oben geplant per internem pull-up inkl. “hold” für den deep sleep.
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.
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.
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.
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:
Genau. Daher können wir sie ignorieren bzw. überlesen. machine.deepsleep() sollte mittlerweile überall gut funktionieren.
Es ist zwar interessant was die da früher getrieben haben, aber wir müssen die Spreu vom Weizen trennen. Viel interessanter und relevanter ist vermutlich eher, was Pycom auf Basis des Learnings scheinbar draus gemacht hat:
Im neuen Release 0.5.1 habe ich versucht, möglichst vielen Dingen Rechnungen zu tragen, die aus den Inhalten im Pycom-Forum herausdestilliert wurden. Die Unsicherheiten müssten wir ggf. gegentesten, aber generell würde ich sagen,
… wir sind jetzt soweit.
Speziell im RF-Bereich, also bzgl. der Abschaltung des LTE Modems sowie des Bluetooth und das ebenfalls neue Weglassen des WiFi-Scans sollten wir hier nun nochmal ein wenig stromsparender unterwegs sein.
könnte sich durch die aktuellen Änderungen perspektivisch noch weiter verbessert haben.
Auf dem Expansion Board habe ich nun auch noch die drei RTS-, CTS- und LED-Jumper gezogen, wie hier zusammengefasst:
Auch die UART-Schnitte hastenichjesehn wird alles explizit abgeschaltet, im aktuellen Fall sogar ebenfalls schon bei Programmstart, weil sie in den Einstellungen dekonfiguriert wurde. Dadurch belasten das System nun auch keinerlei Log-Ausgaben.
Beim aktuellen Testlauf amo-fipy-testbench-power » “now() until now()+35h” ist der Schlafzyklus jetzt 20 Sekunden lang, damit wir nicht so lange wie vorhin auf entscheidene Beobachtungen und Ergebnisse warten müssen.
I’m a bit surprised by the last bit of the quote above though (“any other additional circuits (LoRa, Sigfox, etc) (…) are switched off during deep sleep”), not sure it reflects the reality of the boards.<
Ist sicher nicht die aktuelle Realität sonnst hätten nicht “fast” alle Probleme mit dem Tiefschlaf in dem μA bereich zu kommen.
Aktueller Stand bei mir mit BOB MicroPython Datalogger 0.5.1 und dem FiPy Auf Clemens weißen Platine :
54,3 mA mit Pullup am HX711
54,3 mA ohne Pullup am HX711
Super dann kann zumindest der weg.
Spannung ist allerdings jetzt daneben 4.854 V bei 5,20V
Hattest glaube ich auf 6dB runter gestellt.
Ja, irgendwo gibt es vielleicht noch verstecktes Geheimwissen. Achjeh.
Danke!
Das ist ja leider immer noch nicht im μA-Bereich. Aber ist es denn nun besser als bei den vorherigen Tests?
Schade.
Ja genau. Weil es mit 11dB bei mir über Expansion Board an Batterie unplausible (zu hohe) Werte gab und ich wusste, dass dies auf die Erhöhung Dämpfung zurückzuführen war. Ich weiß allerdings nicht wirklich, was ich da tue und nehme weiterhin gerne Vorschläge an, wie man es besser machen kann.
=> Unterschiedliche Dämpfungen für “am Netzteil” vs. “am Akku” verwenden?
Für mich ist damit ¹ das Maximum erreicht, was ich aktuell mit sowieso schon ungeplanten Aufwänden aus der MicroPython-Firmware herausholen kann. Repräsentativ sind diese Ergebnisse ohnehin nicht, weil ich den Eumel hier auf dem Expansion Board ² fahre und dessen Einsatz im Feld optional ist, soweit ich das richtig verstanden habe.
Gleichzeitig nochmals mein üblicher Disclaimer, dass bei der Hardware für mich normalerweise “black box thinking” einsetzt, also alles was ich hier darüber berichte meistens als unqualifiziert angesehen werden sollte ;].
¹ Den Schlafzyklus habe ich von 60 Sekunden auf 20 Sekunden verkürzt, um schneller Ergebnisse zu erhalten. Recap: Beim ersten ernstzunehmenden Testlauf konnten wir eine Gesamtlaufzeit von 29 Stunden beobachten (bei 60 Sekunden Schlaf), aktuell also nun 14,75 Stunden (bei 20 Sekunden Schlaf). Ich habe für die Interpretation mal frech Linearität angenommen, so kämen wir hochgerechnet auf 44,25 Stunden Laufzeit bei 60 Sekunden Schlafdauer, um es direkt vergleichen zu können. Vermutlich ist das jedoch Quatsch und Ihr sagt mir auch gleich, warum ;].
² Mit dem allerdings - mindestens seit der Firmware-Version 0.0.11 vom Februar 2019 - durchaus möglich zu sein scheint, ebenfalls mit wenig Energieverbrauch in der Tiefschlafphase zu arbeiten.
Bedankt
Ich denke wir konnten gemeinsam einiges herausholen und ein paar Schürfwunden Pflaster spendieren. Vielen Dank für Eure Geduld und Eure wertvollen Beiträge im Verlauf dieser Arbeiten.
Ansteuerung zur Abschaltung des HX711 nun in Software – auch per MCU-internem pull-up
Den internen pull-up am Pin des SCK-Ports des HX711 haben wir nun per hold so programmiert, dass er auch in der Tiefschlafphase den richtigen Pegel hält. @MKO konnte durch Nachmessen bestätigen, dass das klappt.
Danke!
Explizites Abschalten der nicht benötigten RF-Peripherie
Das LTE Modem und die Bluetooth Einheit schalten wir nun per Software explizit kurz nach dem Systemstart ab. Ob das alles etwas bringt, ist fraglich und müsste entsprechend gegengeprüft und nachgemessen werden. Bei Sigfox und LoRa tun wir das nicht, weil deren versehentliche Aktivierung (ohne Antenne) zur Zerstörung des Geräts führen kann. Diese Vorgehensweise hinkt also à la “Warum dort wenn hier nicht?”. Als Antwort muss hier derzeit: “Weil alles nicht überall gleich ist.” herhalten, ich finde das jedoch ebenso unbefriedigend.
Weitere Abschaltungen
Noch ein paar andere Dinge wurden nebenher gemacht, dies geht jedoch im Vergleich zu den essentiellen Dingen in den Bereich der Mikrooptimierungen. z.B.
Abschalten des Loggings sowie der kompletten UART-Schnitte, sofern die Software daran etwas per "uart.deinit()" überhaupt tun kann – ebenso bereits explizit kurz nach dem Systemstart.
