Bis 8:00 eine Messung pro 3 Minuten
ab 12:00 eine Messung pro 15 Minuten
Der Akku wird sehr langsam entladen. Dauer muss noch gemessen werden.
Bis 8:00 eine Messung pro 3 Minuten
Prima, dann hat der LiPo also doch einen Schutz vor Tiefenentladung, wenn auch sehr “weit unten” eingestellt. Ich hatte ja auch eher etwas weiter oben erwartet, aber immerhin es ist einer da.
Ja, man sollte mit einem anderen, höheren threshold, z.B. 3,2 V, das Ganze per software schon vorher in den never ending deep sleep schicken.
machine.sleep(1000*35, True)
Da sollten die Wlan Probleme weg sein. Das True sagt das WLAN nach dem light sleep wiederhergestellt werden soll.
Edit:
OK hilft dir auch nicht wirklich weiter hast du ja in Punkt 3 schon versucht.
Punkt 4 ist ja eigendlich der Befehl der anstatt Punkt 2und 3 verwendet werden sollte. Denke Mal die Problematik dreht sich um die reconect Wlan geschichte.
Hast du beobachtet, ob er vor oder nach dem Schlafen abgestürzt ist?
Um den Stromverbrauch zu untersuchen habe ich mir einen neuen WiPy zum Vergleich mit dem FiPy gekauft:
WiPy Firmware 1.18.2.r1 [v1.8.6-849-e0fb68e] on 2018-12-08;
FiPy Firmware 1.20.1.r1-0.7.0-vanilla-dragonfly-onewire [13d82ea5-dirty] on 2019-11-17
Das Testprogram macht Folgendes:
30 sec RGB-Led an, 30 sec time.sleep(30), 30 sec machine.deepsleep(30*1000)
Der WiPy verbraucht wesentlich weniger Strom als der FiPy, vermutlich weil er nur WLAN und BLE, aber kein Sigfox, Lora und LTE an Board hat.
Der BOB-HAT verbraucht im Leerlauf ca. 25 bis 29 mW für BME280, 5 x DS18B20 und HX711, obwohl sie nicht angesteuert werden, also auch bei deepsleep.
Die RGB-Led verbraucht bei voller Ansteuerung über 100 mW.
Besonders groß ist der Unterschied beim deepsleep: WiPy 42 mW, FiPy 328 mW , also das 7 fache.
Bei vollem Akku mit 4.1V fliessen gut 10 mA beim WiPy, weshalb in den Datenblättern von uA geschrieben wird, kann ich nicht nachvollziehen.
Kannst du deinen Testcode mit uns Teilen. Ist zwar schon eine ganze Weile her, aber ich habe schon mehrfach den Deepsleep iim uA Bereich gemessen.
Zuletzt Hier
Selbst im light waren es nur 1,8mA mit angeschlossenen Sensoren und SD Karte.
Wenn ich raten müßte würde ich sagen, das das WLAN Modul oder BT Modul nicht sauber runter gefahren wird.
Ich hatte damals auch 10 mA (WiPy) und 75 mA (FiPy) mit der hiveeyes-Software ohne Optimierung gemessen, s. Stromsparmaßnahmen für die MicroPython-Firmware im Batteriebetrieb - #15 by clemens
War mit dem BOB-Hat auch das expansion board angeschlossen? Das expansion board braucht ja auch noch Strom. Daher war mir am Anfang auch so wichtig, dass unser komplettes System auch ohne expansion board läuft! Hier gibt es z.B. einen thread zum expansion board: Fipy & Expansion board 3.1 - deepsleep power consumption | Pycom user forum Angeblich sind das aber alle Verbrauche im Bereich von unter 1 mA.
Auch das kann mit expansion board und FiPy helfen:
Bei uns sind vermutlich aber Abschaltung des Funk-Moduls und die Sensoren, besonders der HX711 das Problem. Normalerweise versorgt der HX711 die Wägezelle mit einer Spannung und die macht den hohen Verbrauch im deep sleep aus. Wir müssen also dafür sorgen, dass der Treiber des HX711 die Spannung abschaltet. Weiter muss der pin state gehalten werden. Für die Terkin-Software hatten wir das hier damals lange erforscht, Ergebnis war dann:
Eines jener Yaks ist also immer noch nicht ganz geschoren. [image] Körper Danke @weef. Softwareseitig haben wir diesen Teil ja nun drin: Beine und Hintern Dies ist uns glücklicherweise möglich, da und die erfüllt ist, siehe oben bei Strom sparen beim Einsatz der MicroPython-Firmware im Batteriebetrieb. Herkunft des Yaks: Annapurna. Digitales Abbild: File:Bos grunniens at Letdar on Annapurna Circuit.jpg - Wikipedia
Mit diversen Verbesserungen sind wir mit der Terkin-Software und einem FiPy damals auf 70 uA gekommen, s. Stromsparmaßnahmen für die MicroPython-Firmware im Batteriebetrieb - #173 by clemens
Nur leider hat sich in der Zwischenzeit wieder ein bug eingeschlichen. :-/
Ich messe den neuen WiPy Firmware 1.18.2.r1 [v1.8.6-849-e0fb68e] on 2018-12-08; auf einem ExpansionBoard 3.1 ohne SD-Karte mit folgendem Code:
import pycom
import time
import machine
pycom.heartbeat(False)
for cycles in range(10): # stop after x cycles
print('loop', cycles)
print('RGB-LED 30 sec')
pycom.rgbled(0xffffff) # weiss
time.sleep(30)
pycom.rgbled(0x000000) # aus
print(' sleep 30 sec')
time.sleep(30)
print('deepsleep 30 sec')
machine.deepsleep(30*1000)
und messe Spannung Strom und Leistung mit einem USB-Meter von Elektor an einem USB-Netzteil:
Das sind sehr ähnliche Werte, wie ich sie auch mit dem INA219 auf dem Board BOB-Strom ( siehe oben ) messe.
Leider muss ich mit USB versorgen. Die Akkuspannung reicht nicht für das USB-Meter.
Firmware 1.18.2.r1 [v1.8.6-849-e0fb68e] on 2018-12-08;
Das ist ja auch sehr alt, bringt ein update ggf. schon was?
Ich wollte zuerst den fabrikneuen WiPy testen. Jetzt kommen die Firmwareupdates.
@didilamken, habe mal deine Zeilen code auf einen WiPy geladen, den dann auf die nackte BOB-Platine gesetzt und damit 16 uA im deep sleep gemessen:
Nun den WiPy umgesetzt auf eine Platine bei der alle BOB-Sensoren angeschlossen waren und damit verbraucht er dann schon 8 m(!)A im deep sleep:
Wenn du jetzt am Ausgang der HX711-Platine E+ und E- misst wirst du ca. 2,4 V angezeigt bekommen, das ist u.a. der Grund warum der noch so viel Strom verbraucht, der HX711 und damit die excitation voltage der Wägezelle wird nicht korrekt abgeschaltet.
Firmware war die 1.20.2.rc6-0.10.2-vanilla-squirrel-nosmartconfig [v1.20.1.r2-122-gd82a6f43e-dirty] on 2020-03-06 von Andreas.
Leider muss ich mit USB versorgen. Die Akkuspannung reicht nicht für das USB-Meter.
Vielleicht ist das auch ein weiteres Probelm, die sind ggf. nicht für so kleine Ströme geeignet wie andere Messgeräte.
Ich werde heute abend weiter testen mit div. USB-Testern und Multimetern.
Ich habe aber keinen CurrentRanger.
Der deepsleep-Strom des WiPy auf einer nackten BOB-Platine ist so klein, dass ich ihn mit meinen Mitteln nicht mehr gut messen kann: 20 uA
Ich habe also bislang immer den Standbystrom des ExpansionBoards gemessen.
Während der WiPy auf der nackten BOB-Platine einen sehr kleinen deepsleep-Strom hat, ist das beim FiPy leider nicht der Fall. Den Strom habe ich mit einem Multimeter und dem INA219 auf BOB-Strom-V2 gemessen. Die Unterschiede in der Anzeige sind gering, so dass ich im folgenden die Werte des INA219 benutze, da sie sekündlich ausgelesen und aufgezeichnet werden. Ebenfalls benutze ich zum Vergleich nicht die Stromstärke in mA, sondern die Leistung in mW, da es schon ein Unterschied ist, ob ich die Schaltung mit USB ( 5.2V ), vollem Akku ( 4.1V ) oder leerem Akku ( 3.2V ) betreibe.
Das Testprogramm ist wieder RGB-Led an ( 30 sec ), time.sleep(30), machine.deepsleep(30*1000):
dann habe ich das ExpansionBoard angesteckt: LED 1280 mW sleep 1150 mW deepsleep 290 mW
Zum Schluss habe ich das ExpansionBoard über den USB-Anschluss eingespeist:
LED 1040 mW sleep 910 mW deepsleep 370 mW
Warum der FiPy bei Einspeisung über USB so viel weniger Leistung verbraucht, ist mir ein Rätsel.
Ergänzung 30.9.20
Der gleiche Messzyklus mit einem WiPy zeigt einen deutlich sparsameren Microcontroller:
Das ist sehr viel weniger als beim FiPy. Wenn also LoRa oder LTE nicht gebraucht werden, könnte der billigere WiPy besser sein als die eierlegende Wollmilchsau FiPy. Um beim FiPy Strom zu sparen, braucht man also die Strom-Abschaltung mit dem DS3231. Per Software wird man nicht viel erreichen.
Die einfachste Stromspar-Maßnahme: FiPy gegen WiPy tauschen:
Der Stromverbrauch ist praktisch halbiert. Man kann auch noch in der Software optimieren, wird aber nicht so viel erreichen
Ich habe die Software zum Board BOB-Strom-V2 so erweitert, daß ich das Entladen und Laden des 2000 mAh Akkus mit Spannung, Strom und Leistung messen kann. Die Leistung wird so aufsummiert, daß ich die Energie in mWh erhalte.
Zuerst wurde der Akku mit einem FiPy und Sensoren mit 5 sec Messintervall ohne Deepsleep entladen, dann wurde er an USB wieder aufgeladen.
die aufsummierte Energie:
interessant ist auch das Verhalten am Ende des Entladens:
Inzwischen habe ich 3 Solarlader für 6 V Solarmodule und 3 MPP-Solarlader für 12 V Solarmodule im Test, und versuche auch mit der mageren Solarausbeute an einem trüben Novembertag noch messen zu können. Dazu steuert der Alarm der RTC DS3231 die Versorgung des Mess-FiPy oder -WiPy. Er schaltet den Strom für 30 sec ein, damit der FiPy booten, messen und senden kann. Dann schaltet er abhängig von der Akku-Spannung für viele sec aus.
if Uaus0 < 4.0: IntervalAlarmAus = 30 # 1 min
if Uaus0 < 3.8: IntervalAlarmAus = 90 # 2 min
if Uaus0 < 3.6: IntervalAlarmAus = 270 # 5 min
if Uaus0 < 3.4: IntervalAlarmAus = 570 # 10 min
if Uaus0 < 3.2: IntervalAlarmAus = 1170 # 20 min
if Uaus0 < 3.0: IntervalAlarmAus = 1770 # 30 min
So erhält man 60 bis 2 Messungen pro Stunde.
Mein erster Test sieht so aus:
Blau zeigt die Spannung eines kleinen LiPo-Akkus ( 3.7V 300 mAh ). Er war um 8 Uhr praktisch leer, mittags auf 3.7 V aufgeladen, nachmittags wieder leer.
Grün zeigt die Leistung einer angeschlossenen elektronischen Last. Sie wurde für 30 sec angeschaltet. Von 11:00 bis 13:30 30 mal und später nur 2 mal pro Stunde.
Bei dem trüben Wetter ist es schwierig, auch durch ein 50 W Solarmodul genügend Energie für häufige Messungen zu erhalten.
Rot: Die Solarlade-Leistung war max. 350 mW ( von einem 50 W Modul ! ) und ergab eine Energie von 1400 mWh ( schwarz ).
Grün: die elektr. Last wurde unterschiedlich oft für 30 sec eingeschaltet, die Leistung ist stark abhängig von der Akku-Spannung. Die aufsummierte Energie betrug 600 mWh ( grüne Treppe ) .
Die Firmware des WiPy läuft leider nicht stabil. Er bootet häufig neu - trotz GarbageCollector und Watchdog. Das führt zu dem nicht ganz gleichmässigen Einschalten. Gestern gab es Hänger, wo nur noch Strom aus/ein weiterhalf.
Da ich jede Sekunde 8 Werte messe und aufzeichne, ergeben sich 60 x 60 x 24 x 8 = 692200 Messwerte pro Tag und ca. 11 MByte auf der SD-Karte.
Kann diese Datenmenge sinnvoll über Internet übertragen und mit Grafana angezeigt werden ?
Da ich jede Sekunde 8 Werte messe und aufzeichne, ergeben sich 60 x 60 x 24 x 8 = 692200 Messwerte pro Tag und ca. 11 MByte auf der SD-Karte.
Kann diese Datenmenge sinnvoll über Internet übertragen und mit Grafana angezeigt werden ?
Hallo Didi, lieben Dank für deine Beobachtungen und Messungen! Die Datenmenge ist für Grafana kein Problem. Ich weiß aber nicht, ob die Messfrequenz mit der Datenübertragung hinterher kommt. Sensoren auslesen, ggf. Verbindung aufbauen, Daten absetzen könnte mehr als 1 Sekunde dauern. hälst du die Verbindung “alive” oder muss die jedes mal neu aufgebaut werden?
Inzwischen läuft die Strommessplatine stabil mit Firmware 1.20.2.r3 und ich vergleiche die Energieausbeute an einem trüben Wintertag ( 28.12.2020 ):
Ein 6 Volt / 5 Wpeak Modul mit Solarlader CN3163 an 2000 mAh - LiPo. Das Lademodul mit dem CN3065 scheint nicht mehr erhältlich zu sein.
Ein 12 Volt / 50 Wpeak Modul mit MPP-Solarlader CN3791 an 2000 mAh - LiPo
Das Lademodul mit dem CN3065 scheint nicht mehr erhältlich zu sein.
Welches meinst du? Die kleine rote Platine scheint noch erhältlich zu sein:
Solarzellen mit einer Nennspannung von 5V eignen sich am besten für diesen Laderegler. Typ Linearregler. Für den Betrieb sind keine weiteren Bauteile nötig (siehe Beispielapplikation). Durch Veränderung des Widerstands R2 kann diese Grenze verändert...