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
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?
Zwischenbeobachtungen mit Kaiserschmarrn
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.
Backlog
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.
Ausblick
Beizeiten machen wir also vermutlich bei Kontinuierliche Verbesserungen des Terkin-Datenloggers (600er) - #38 by Andreas ff. wieder verstärkt weiter.
Zwischenbericht
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. - Heartbeat-Profil der RGB-LED abschalten.
Nun nur noch zweimal kurz grün beim Start der Datenloggersoftware. - Ein paar Jumper auf dem Expansion Board weniger sollen für besseres Verhalten sorgen. Drei Jumper abgezogen und geparkt.
Noch mehr
Falls ich noch offene aber wichtige Punkte bei dieser Übersicht vergessen haben sollte, ergänzt sie gerne für mich.
Zwischenfazit
Versprochener deep sleep current wird weiterhin nicht erreicht
@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.
Tests mit oder ohne Sensoren
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.Tests mit oder ohne SIM-Karte
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
Tests mit oder ohne Sensoren
Vermutlich doch, weil es einfach das LTE Modem ist ;].
Zwischenbericht » Weitere Abschaltungen
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
1 Like
Disclaimer: Bitte alle diese Abbildungen und Werte mit “a grain of salt” nehmen, da ich zwar den Spannungsteiler auf die passenden Werte fürs Expansion Board konfiguriert habe, da allerdings noch das Board von @clemens dazwischenhängt, das ja noch einen eigenen Spannungsteiler mitbringt.
Vermutlich Gewiß clipped daher daher der Spannungswert im vollgeladenen Zustand .
Die Erkennbarkeit der Fortschritte wird dadurch hoffentlich nicht allzu stark eingetrübt.
Why does this always happen to me…? ;]
1 Like
Ihr habt bis bis jetzt, entgegen aller Widersprüchlichen Meldungen in den div anderen Foren, einen tollen Job gemacht.
Der FiPy fährt jetzt auch problemlos in den Deep Sleep. (auf 3 x FiPy ohne SIM getestet).
Die Stromaufnahme im Deep Sleep ist dort erstaunlicherweise vergleichbar mit dem was wir beim WiPy schon gesehen haben.
= 320μA
- 170μA für die 6 DS1820
- 98 μA HX711
- 29 μA BME280
- 23 μA FiPY 3.0
somit ist Software-seitig (bis auf kleine Laufzeit-Optimierungen) maximal Mögliche erreicht.
Interessant wird es natürlich wieder, wenn wir das Modem im FiPy für einige Übertragungsvarianten (LTE) wieder in zeitweisen Betrieb nehmen müssen.
Getestet habe Ich mit der folgenden Config:
Testbedingungen:
- Datalogger master 0.5.1 Latest commit [8bfda9c]
- FiPy ohne Sim Karte
- Logging über Usb via TTL Adapter
- Firmware FiPy 1.20.0.rc11
- Modem Firmware = Auslieferungszustand
- Clemens Solar Board V0.0.14 mit und ohne Solarregler
- Bosche H40
- Hx711 (ohne Pullup)
- 6X DS18b20
- 1x BME280
- WLAN an und verbunden
- Beidseitige Datenübertragung zu Hiveeyes und BOB
- Eingangsspannung 5V-3V
Echt eine tolle Arbeit die Ihr und vor allem @Andreas bisher geleistet haben.
Ich persönlich habe noch nie eine Software so schnell reifen gesehen!!!
1 Like
Wär traumhaft, wenn du rausfinden könntest, wie viel Datenübertragungen er in den 40,5 Std geschafft hat, dann könnten wir die Laufzeiten für längere Schlafpausen errechen. Auch für spätere vergleiche, der Softwareversionen ist es sicher hoch interesssant, wie viel mAh eine einzelne Übertragung “kostet”.
Du hast doch noch die Vorversion, die grüne Platine, die ist ohne Spannungsteiler fürs battery monitoring??
Wow!!
Bei den DS18B20 kann was nicht stimmen, laut Datenblatt (Seite 2) brauchen die maximal 1000 nA, also 1 µA! … oder wir haben uns irgendwelchen China-Schrott reingezogen.
1 Like
Das bezieht sich auf den einzelnen Ds18b20 denke mal da spielt der 4,7K Widerstand sicher auch eine recht große Rolle und evtl sind auch unter der Kappe noch zusätzliche Halbleiter wie Dioden oder so verbaut. ich kann aber gerne mal ohne den 4,7K messen.
die 170µA finde ich aber gar nicht so Dramatisch.
beim aktuellen verbrauch von 320μA im deep sleep kann der FiPy 260 Tage schlafen bis der Akku leer ist.
Wenn ich jetzt ganz Grobe, (ohne @Andreas Werte zu kennen)
mit 1600 Übertragungen (ca.40/h) im Kopf überschlage und mit Stündlicher
Übertragung umrechne, sollten wir etwa bei etwa 50 Tage bei 320μA landen. Bei 100μA Deep Sleep währen wir etwa bei ca. 60Tage.
Übertragen wir häufiger wird auch der Unterschied kleiner.
2/h ca 29Tage zu 32 Tage
4/h ca 15,5 Tage zu 16,3 Tage
10/h ca 6,5 Tage zu 6,6 Tage
hoffe mal ich habe so halbwegs richtig gerechnet.