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.
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.
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!
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.
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:
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:
Da steht aber das der FiPy keinen braucht.;-)
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.
Die letzte Laufzeit von 29 Stunden
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 :
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.
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.
Die Reise hört hier nicht auf, bei [Agenda] Stromsparmaßnahmen für den MicroPython-Datenlogger auf Basis des Pycom FiPy mit Peripherie sammeln wir alle Dinge komprimiert zusammen, denen wir uns gerne weiterhin widmen können. Dies ist ein Wiki-Beitrag, daher kann jede:r dazu beitragen.
Beizeiten machen wir also vermutlich bei Kontinuierliche Verbesserungen des Terkin-Datenloggers (600er) - #38 by Andreas ff. wieder verstärkt weiter.
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!
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.
Noch ein paar andere Dinge wurden nebenher gemacht, dies geht jedoch im Vergleich zu den essentiellen Dingen in den Bereich der Mikrooptimierungen. z.B.
"uart.deinit()" überhaupt tun kann – ebenso bereits explizit kurz nach dem Systemstart.Falls ich noch offene aber wichtige Punkte bei dieser Übersicht vergessen haben sollte, ergänzt sie gerne für mich.
@MKO misst derzeit 54,3 mA Verbrauch im deep sleep, wir kommen noch nicht in den uA-Bereich.
Andere berichten über ähnliche Probleme, daher schläft vermutlich irgendeine interne Domäne noch nicht ordentlich ein. Die Vermutungen liegen hier vorerst bis auf weiteres beim LTE-Modem. Haben wir es denn schon mit eingelegter SIM-Karte versucht?
Allerdings deutet die Messung auf “Messung inkl. Peripherie” hin. Wenn wir uns dort also ebenfalls noch nicht sicher sind, brauchen wir für die Erlangung des Soll-Stroms im Deep-sleep noch einmal eine Messung ohne Peripherie ¹.
¹ Ob dabei der Einsatz des Expansion Boards sinnvoll oder kontraproduktiv ist, kann ich nicht einschätzen. Grundsätzlich sollte es jedenfalls wohl auch damit funktionieren, wenn man die aktuellste Firmware drauf hat:
ja war eine Messung mit Peripherie (Sensoren) aber ohne Expansionsboard.
Allerdings verbrauchen die (Sensoren) im Deep Sleep nicht viel. Es sind 0,3mA wenn ich die Werte vom WiPy mit gleicher Softwarversion nehme.
Eine Antenne hätte ich da, um zu testen ob es evtl. (Sigfox und LoRa) ist, was noch hängt allerdings bin ich noch nicht weit genug im Thema um das im Programm zu realisieren, wär schon wenn du mal in einem Test-Branch dafür erstellen könntest oder anderweitig bescheid gibst, was ich wo einfügen und Ändern müsste.
Eine Sim Karte habe ich auch schon mal rein getan, jedoch ohne irgendwelche Änderung im Stromverbrauch. Evtl mußte diese aber noch Angemeldet werden bzw. der Pin angegeben oder deaktiviert werden.
Hi Michael,
danke für die weiteren Tests auch bei Dir.
Darum ging es mir an dieser Stelle nicht ganz. Eher darum, als Referenzmessung die Variante zu versuchen, in der ein xPy niemals während des Meßzyklus überhaupt jemals etwas tut, also auch nicht mit Sensoren kommuniziert geschweige denn sie anspricht – am besten ist dann eben auch überhaupt nichts angeschlossen, was ungünstig Einfluß nehmen könnte.
Das gleiche will ich gern auch noch einmal mit “komplett ohne WiFi” unternehmen, also WiFi niemals überhaupt erst anschalten.
Hier geht es mir nun eher um Grundlagentests, die sich jenseits des praxisnahen Einsatzzwecks abspielen. Ursache ist vermutlich, das halbe Pycom Forum zum Thema komplett durchgelesen zu haben. Oh my ;]. Das heißt aber noch lange nicht, dass Ihr oder Du da mittun müsst. Irgendwann lasse ich mir Geräte zum selber Nachmessen hinstellen und muss dann niemanden mehr dafür einspannen -- lasst uns hier ruhig beim praxisnahen Einsatz (mit Sensoren) bleiben.Danke!
Schade!
Hm. Das wäre ja richtig irre. Kann ich mir kaum vorstellen, bin dabei aber vielleicht immer wieder zu optimistisch. Ich will nur sagen: Die Realität ist schon wild genug, da will ich nicht noch wildere Vermutungen obendrauf setzen ;].
Danke weiterhin! Ich bin generell genauso ratlos, will aber positiv bleiben und einfach mit der Funktionalität weitermachen ;].
Viele Grüße,
Andreas.
Stimmt, habe auch schon überlegt, ob irgend eine Kommunikation ihn wach hält. Aber warum nur den FiPY und nicht den WiPy.
In der Doku zum FiPy habe ich auch gelesen, das man den RX und Tx Jumper auf dem Expansionsboard entfernen soll , da das Modem diese ebenfalls nutzt und der depp Sleep dadurch verhindert werden kann.
Aber welche meinen sie P0 & P1 oder wie im Pinout angegeben P15 & P17-P20
Muß glaube ich Mal alles mit Sim durchtesten.
Telefonieren können wir gerne mal, schick dir gleich mal ne PN
Vermutlich doch, weil es einfach das LTE Modem ist ;].
Bis später!
Wie schon gesagt, benutze das Board schon seit 2-3 Wochen nicht mehr.
Mache alles nur noch über USB>TTL an P0 und P1 allerdings hatte ich ihn ab und an beim testen nicht mit abgezogen. Auch habe ich die Eingangs- Spannung nicht berücksichtigt das sie nicht zu niedrig werden sollte. SIM hatte ich auch nur Recht kurz drin dort also auch nicht die anderen Störfaktoren berücksichtigt worden.
Werde den FiPy heute Abend Mal kompl
nackig machen und nur an VCC > 4,20V mit Sim betreiben und ein paar der
