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.
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.
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 ;].
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
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
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.
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
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”.
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.
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
Das deute ich ebenfalls als gutes Zeichen. Das heißt wir haben es mit der aktuell verwendeten Software- und Hardwarekonfiguration geschafft, die noch nicht benötigte (Modem-)Peripherie so abzuschalten, dass sie nicht beim Energiebudget aufträgt. Wunderbar.
Ja. Ein wenig mehr könnte noch gehen. Gerade vom Freezing der Python-Quellen verspreche ich mir noch ein wenig Optimierung zur Laufzeit.
Robustheit geht aber vor [1] und derzeit sind wir schließlich noch recht aktiv in der Entwicklung. Daher haben solche Dinge noch keine so hohe Priorität bzw. wir denken derzeit noch nicht aktiv ans Freezing – schließlich haben wir endlich Sommer. Gebt gern Bescheid, wenn Euch daran gelegen ist, solche Aspekte früher als geplant zu verbessern.
Vielen herzlichen Dank für Deine Tests, Michael!
Um die Robustheit sind wir derzeit weiterhin vor allem froh. Dass das Teil einigermaßen stabil zu rennen scheint, erzählte man sich neulich schon beim Späti. Dass es nun auch bei @clemens, @MKO und anderswo passabel klappt, ist vielversprechend. Den Dank will ich vor allem an @einsiedlerkrebs weitergeben, der nicht nur bei der Grundsteinlegung für den MicroPython-Datenlogger ordentlich mit angepackt hat sondern weiterhin mit Rat und Tat auf Hard- und Softwareebene zur Seite steht. Vielen Dank aber auch an alle, die durch die folgenden gemeinsamen Diskussionen zu einem guten Gelingen beigetragen haben und nicht zuletzt an @caro, @Diren, @vinz und @didilamken von Hiverize, die dies durch die Bee Observer Workshops überhaupt erst ermöglicht haben. ↩︎
Der Wert aber für den BME280 ist noch zu hoch: das ist eine Größenordnung mehr, als der im ‘normal mode’ bei 1Hz (f. Luftdruck, Temperatur und Feuchte) hat - jedenfalls ein Bosch-Orginal laut Datenblatt ! ;) Dort sind das 3,6 µA.
Den BME280 will man im ‘forced mode’ betreiben (Punkt 3.3.3. im Datenblatt), da mißt er nur auf Anforderung und geht selbsttätig in den sleep danach - da braucht er nur noch 0,1 µA.
Ohne im code selbst geschaut zu haben: fliegt Ihr den BME280 im forced mode?
