Hmm, hört sich ja irgendwie nach Mist an! Warum hat bei solchen Teilen niemand deep sleep beim Design auf dem Schirm?
Das Board, das ich hier habe schaut mehr oder weniger so aus wie https://github.com/Xinyuan-LilyGO/TTGO-T-Call/blob/master/datasheet/board.jpg . Vom Layout und der Lage der Baubeile könnte das die gleiche Version sein. Auch bei mir steht im silk screen BLYNK_V1.3 20190610 die mit grünem Preil markierten Bauteile sind bei mir aber nicht bestückt:
Ja, wir haben das ja hier schon länger erschlossen: Low Cost GSM/GPRS-(SIM800)-Node - #8 by clemens – pfff, doch eine eigene kleine Platine als sich hier über schlechtes Design zu ärgern und Fehler anderer suchen zu müssen?
+1 von mir. Per 1-wire UART mit einem ATTiny sprechen der fürs schlafen/wecken zuständig ist, erscheint mir eine sinnvolle Lösung. Ich meine auch, sowas schonmal irgendwo geshen zu haben als fertige Lösung. Finde es aber leider nicht mehr. Wir sind ja nicht die ersten mit so einem Problem.
@clemens & ich haben gestern ein bißchen telefoniert und auch über die stromspar Lösung per Abschaltung gesprochen. Ich bin beim googeln über diesen etwas längeren Thread gestossen. Interessant ist vor allem dieser Post: https://www.mikrocontroller.net/topic/279121#2945591
TL;DR: entweder bastelt man sich selber was mit einem ATTiny oder man nimmt einen Uhrzeitbaustein (NXP/Maxim) mit dem man per I2C kommuniziert. Die Bausteinlösung klingt natürlich verlockend, weil es was Fertiges ist und man als Bonus auch gleich eine RTC dazu bekommt. Da müsste man ‘nur’ noch den richtigen Typ finden.
So weit ich das sehe bringt uns eine RTC hier nichts. Mein Seeduino Stalker hatte in der ganz alten Version eine DS3231 drauf, die neue Version hat die etwas ungenauere DS1337S, die macht aber nichts anderes als mit einem Interrupt dem Microcontroller zu signalisieren, dass er nun aufstehen soll. Der Microcontroller ist dabei die komplette Zeit im deep sleep, die RTC sagt nur wann er aufwachen soll. Das können wir beim ESP32 billiger mit der internen RTC.
Ein Mosfet-Treiber ist allerdings nicht integriert, der Int-Ausgang ist Open-Drain. Da müsstest Du also z.B. noch ein Logikgatter dahinter schalten.
Was wir gestern diskutiert hatten wäre eine Lösung, die komplett den Strom zum ESP abdreht. Das wäre so was, nur ist der nicht “extern” und dynamisch einstellbar:
Maximale Schlafzeit ist beim TPL5110 aber nur 2 Stunden und “current up to 1.1A” könnte mit dem SIM800 ggf. knapp werden. Weiter braucht das T-Call einen reset zum Start im Batteriebetrieb. Darum müsste man sich dann auch kümmern.
Da fehlt natürlich noch ein P-Kanal MOSFET. Der ist, wenn ich das richtig verstehe, solange an (leitend) bis er aktiv ausgeschaltet wird.
D.h. der Ablauf ist dann so, das der uC seine Arbeit tut, dann dem DS3231 mitteilt, wann er geweckt werden will und sich schliesslich selbst von der Spannungsversorgung trennt.
Der DS3231 wacht dann irgendwann auf und schaltet das MOSFET über den Alarmausgang ein, der uC erwacht und alles beginnt von vorne.
Oder nicht?
Hab mal den power tree vom TTGO T-Call aufgemalt, da sieht man, daß der IP5306 eine zentrale Stellung einnimmt und nicht einfach “ausgeschaltet” werden kann, denn dann ist im Fall von Speisung durch einen Akku nichts mehr angeschaltet.
Schaltbar, und das ist ein schönes feature, ist lediglich der modem-DC/DC-Schaltregler (1U1, einer der beiden SY8089), der braucht ausgeschaltet nominell 100 nA, max. 1µA. Alles andere aber ist immer an:
SY8089 (1U2), min. 55 µA
ME6211 (U8): 40µA nom.
Für den SY8089 verrraten sie uns nicht, was der bei Last braucht: die IQ = 55µA sind die Angabe für IOUT = 0 A, bei Last kann das nur mehr werden ! ;)
Nebenbei: der Hersteller leistet sich den “Scherz”, zwei power rails mit fast gleichem Namen zu verwenden: “5V” und “+5V”, und für die Sicherungen haben sie, da die Dinger im SOD123-Gehäuse sind, einfach Dioden-Schaltbilder genommen, anstatt ein neues Symbol zu malen… :(
Also, ich sehe noch nicht, daß, und wenn ja, wie die ihre behaupteten 300 µA schaffen können. Deine 800µA, @clemens, dürften dicht an dem erreichbaren Minimum liegen. Sollten die Spannungsteiler (siehe andere postings oben) ungünstig bestückt sein, läßt sich durch Entfernen der unteren Zweige noch etwas rausholen.
Außerdem möchte ich behaupten, daß noch nicht alle verwendeten GPIO des ESP derart geschaltet / konfiguriert waren, um ein für deep sleep bevorzugtes Verhalten zu zeigen - aber das ist primär firmware, also nicht mein Ding ;).
Der zentrale PMIC, der IP5306, ist ein IC, der primär für USB power banks entwickelt wurde (daher auch seine nicht-I2C-Variante mit vier LEDs für Ladezustand). Von der überwiegenden Mehrzahl dieser power banks ist das Verhalten bekannt, daß diese sich bei allzu kleinen Lasten wie dem deep sleep von MPUs am 5V-Ausgang abschalten, ein Verhalten, das schon @einsiedlerkrebs genervt hat, und auch @didilamken wird das kennen. Damit sind diese Geräte für uns nicht brauchbar (auch das Ding hier ist keine Alternative, denn es will auch mindestens 20 mA Strom sehen, sonst geht es auch aus).
Nun hat der IP5306 ein Register, mit welchem sich dieses Abschalt-Verhalten abschalten ließe - wenn das nicht auch noch kaputt wäre:
genau damit schlagen sich die M5Stack-Leute auch schon fast ein Jahr herum (dort ist der gleiche IC verbaut, wie schon geschrieben):
sorry, @poesel, aber dafür kann ja nun micropython nichts: sowohl bei Arduino als auch µpy hängt beim ESP noch ein FreeRTOS dahinter, also vergleichbare Bedingungen. Auch µpy kann GPIOs ausschalten bzw. hochohmig setzen vor dem deep sleep… Da mußt Du schon mit jenen von @clemens verwendeten Betriebszuständen vergleichen. Es ist nicht einzusehen, warum µpy nicht die gleichen knapp 1mA (also ca. 800 µA) erreichen sollte, die Clemens mit einen Ardu-sw-stack gemessen hat.
Dann mal eine Verständnisfrage: können GPIOs Strom verbrauchen, wenn sie an überhaupt nichts angeschlossen sind? Ich hab den Test nur mit dem Board gemacht ohne irgendetwas anzuschliessen.
Könnte der hohe Verbrauch – jenseits der GPIO states im deep sleep – hier nicht auch an “mit / ohne REPL” liegen, was bedeutet das konkret bei dir? Hast du auch eine Serielle Schnittstelle angeschlossen? Mit vs. ohne hast du oben 14 mA Unterschied, falls der Takt keinen Einfluss hat könnte es sein, dass du ohne REPL schon auf 5 bis 6 mA kommst. Magst du das erst mal testen?
‘mit REPL’ bedeutet hier, das der TTGO per USB am Rechner hängt. VSC mit dem pycom plugin dient als serielle Schnittstelle.
Im Akkubetrieb sieht das dann schon etwas besser aus. Hier ist 1mV/mA - also etwa 8mA aber bei 5V Versorgungsspannung.
Problem ist hier beim Abschalten mit dem TPL5110 (oder auch beim stromlos schalten durch ein anderes Bauteil), dass der T-Call mit “nur Batterie anschließen” nicht losläuft, er braucht dann noch einen reset-Impuls! Hier ist mir nicht ganz klar, was das Problem ist bzw. ob man es lösen kann. Hier berichtet crash007 von eime cap TinyGSM example wont start from battery · Issue #8 · Xinyuan-LilyGO/LilyGo-T-Call-SIM800 · GitHub
So I put a capacitor 470uF between GDN and 5v and now it works good.
Mir ist nicht klar, ob das Anschalten per Taster danach bei ihm ging oder das Anstecken der Batterie reicht. So aus dem Kontext befürchte ich, dass nur der Taster bei ihm danach korrekt funktionierte.
Mein FiPy bootet immer wenn er Strom bekommt, danach werden Sensoren, WLAN und Modems initialisiert. Ich stecke ihn jetzt ja auch in den PC oder über Nacht an eine Powerbank und es funktioniert.
Automatisiertes An- und Ab-Schalten sollte auch funktionieren.
Leider hat @clemens recht - der T-Call startet nicht, wenn man ihn einfach nur an den Strom steckt.
Er verbraucht zwar Strom, aber er läuft erst los, nachdem man den Reset-Knopf gedrückt hat. Das passiert übrigens nicht, solange man ihn per USB versorgt. Da könnte man meinen, das das die Lösung ist. Leider nur halb. Mit USB funktioniert der Deepsleep nicht richtig. Da kommen dann die Ströme raus, die ich oben gemssen habe.
Deepsleep in 3 verschiedene Anschlussvarianten:
per USB am PC: 19,2mA
per USB am Akku: 8mA
direkt per JST am board: 620uA
Das war der Fehler - so angeschlossen liegt man mit uPy in den selben Regionen wie mit Arduino-code.
Mit den Komponenten kann man das im Grunde genommen nur so lösen, wie Clemens grade vorgeschlagen hat. Das man beim TPL5110 die Zeiten nur fix einstellen kann ist zwar nicht hübsch, aber für die Einfachvariante wohl tragbar.
Sollten wir hier vor dem Deepsleep noch weitere GPIOs auf hold() setzen / einfrieren, ähnlich wie bei der Ansteuerung des HX711, bevor wir das Gerät schlafen legen? Im Datenblatt stehen scheinbar
Ich frage natürlich auch, ob das dann nicht auch beim FiPy weiteren Strom sparen könnte, wenn wir da bisher noch etwas nicht ganz richtig bzw. unvollständig implementiert haben.
ja, vielleicht auch dereinst-demnächst, das ist dann der Feinschliff - aber im Moment ist die Tatsache, daß sie als PMIC einen IP5306_I2C (oder wie auch immer die Nicht-LED-Variante heißt) ausgewählt haben, deutlich mehr Spaßbremse.
Die beschriebenen Probleme mit dem Nicht-wieder-starten-nach-power-restore-Verhalten rühren von der Herkunft dieses IC als power bank controller.
pin5 (key) ist ja beim T-Call mit dem reset button gekoppelt, dann hängt da noch VCC3V3 dran, so und jetzt steig ich aus, die ist doch nur vorhanden, wenn der IP5306 läuft?? Das ist vermutlich auch der Fall, wenn der T-Call am USB angeschlossen ist, da brauche ich nämlich reset nicht drücken, nur wenn der T-Call über LiPo wieder angeschlossen wird (‘power restored’) muss ich zwingend reset (und damit den PI5306) triggern damit das Gesamtsystem hoch läuft.
Wie löse ich ein reset für den IP5306 aus, wenn der T-Call komplett vom Strom getrennt ist, z.B. durch einen Timer / externe RTC mit FET
Was passiert nach einer längeren Schlafzeit, können wir ihn wieder reaktiveren?
Generelle Überlegung:
Könnten wir den Vin pin des IP5306 mit aktuell VBUS / den 5 V-Zweig des USB als Eingang für den LiPo nehmen? Um das Einschalt-Problem via reset zu umgehen? Vermutlich nicht!
Macht es Sinn mit einem deep sleep-Verbrauch von 800 uA das Ding mit Batterie / Solar zu versorgen oder sollen wir uns auf was anderes konzentrieren?
Wir sind ja nicht die ersten mit so einem Problem.
