+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.
Dachte eher an einen WiPy oder Firebeetle mit Transistor und FET und SIM800 Breakout.
@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.
Edit: richtiger Typ gefunden: Bauteil: DS3231 - Mikrocontroller.net
uPy libs gibt es auch dafür, z.B.:
mpy-lib/misc/DS3231 at master · micropython-Chinese-Community/mpy-lib · GitHub
1 Like
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.
Das könnte mit externer RTC und Abschalten weiterhelfen: Gibt es Alternativen zum TPL5110? - Mikrocontroller.net
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?
Dit Konzept hatten @weef, @roh und icke mal in dem Versuchaufbau “Autonomen Zelle #2” realisiert. @weef hat dazu etwas aufgeschrieben, leider mit nicht allzuviel Doku so weit, @roh hat in diesem Thread noch ein paar Gedanken/Skizzen zur Implementation.
[Edit: Ich hab grad im ersten Thread noch etwas zur C-Implementierung davon weggespeichert.]
1 Like
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.
2 Likes
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?
Ich wäre hier dankbar für Hinweise, was wir diesbzgl. auch bei der Terkin-Firmware noch weiter verbessern könnten.
‘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.
Woher diese Peaks kommen, weiss ich aber auch nicht.
1 Like
So als Idee:
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.
Das hört sich nicht gut an:
Auch das hört sich nicht gut an: When battery powered, will not start if battery bellow ~4V · Issue #11 · Xinyuan-LilyGO/LilyGo-T-Call-SIM800 · GitHub
My goal was to somehow make the system wake up after power failure.
Apparently that is not possible, reset has to be pressed.
Und auch hier bei TinyGSM example wont start from battery · Issue #8 · Xinyuan-LilyGO/LilyGo-T-Call-SIM800 · GitHub hat man nach Lösungen gesucht und nix gefunden:
Tried many ways, no success.
[EDIT] Hier auch noch an einer weiteren Stelle:
1 Like
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.
Hier geht es um den TTGO T-Call mit SIM800, bei dem es leider nicht so einfach wie beim FiPy ist, ggf. ist ein Hardware-Design-Fehler daran Schuld.
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.
2 Likes
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.
Translated section of IP5306 datasheet: "IP5306 can recognize long key and short key operation, PIN5 pin is vacant when the key is not needed. ● The button lasts longer than 50ms, but less than 2s, it means […]
TinyGSM example wont start from battery · Issue #8 · Xinyuan-LilyGO/LilyGo-T-Call-SIM800 · GitHub
- Change IP5306 "KEY"circuit so that it auto-starts upon VBAT input. If voltage goes very low IP5306 will shutdown and it then needs a reset button press to wake up. This is not good for unattended deployments with solar charging batteries.
Suggestion for next revision · Issue #13 · Xinyuan-LilyGO/LilyGo-T-Call-SIM800 · GitHub
PIN5 pin is vacant when the key is not needed.
… und wenn man die Leiterbahn zum pin trennt - schaltet der sich dann allein wieder an nach ‘power restored’ ?
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 haben hier zwei Probleme:
- 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?
Zum Thema basic battery reading gibt es hier ein posting: How to power the board? · Issue #29 · Xinyuan-LilyGO/TTGO-T-Call · GitHub, gemessen wird an pin35, der einen 100 k / 100 k voltage divider hat, (6 V source würden dann 3 V output liefern, oder 4,2 V source 2,1 V output).
Der Faktor 2380 unten wurde empirisch ermittelt. Im posting steht 2350, was bei mir mit Nachmessen nicht so gut gepasst hat.
void setup() {
// Set console baud rate
Serial.begin(9600);
delay(10);
}
void loop() {
// basic voltage reading
int batteryLevelRaw = analogRead(35);
float voltage = batteryLevelRaw / 2380.0 * 4.20;
Serial.print("basic battery lavel: ");
Serial.println(voltage);
delay(1000);
}
Über die (Un-)Genauigkeit des ADCs beim ESP hat @weef schon an anderer Stelle geschrieben, diese Grafik sagt schon sehr viel: [Answered] What are the ADC input ranges? - ESP32 Forum, daher ist es wohl auch egal, ob der Faktor nun 2380 oder 2350 oder doch was anderes ist.
Siehe auch: ESP32 Analog Input with Arduino IDE | Random Nerd Tutorials
https://github.com/m5stack/M5Stack/issues/156#issuecomment-487809103
Once the IC has gone into standby (deepSleep device for more than 30 seconds), you cannot wake it without connecting power. Such a shame this IP5306 was chosen for the M5.
Das kann ich so für den T-Call nicht bestätigen. Auch nach 60 Sekunden deep sleep wacht der wieder auf, auch 5 Minuten funktionieren, jetzt teste ich 30 Minuten … [edit1] geht auch! Bei 2 Stunden hatte ich erst mal ein Problem, 7.200 Sekunden x 1.000.000 us sind 7,2 Milliarden, da ich diese Konstanten aus einem Beispiel heraus per #define festgelegt hatte funktionierte der deep sleep nicht, mit 30 Minuten, d.h. 1,8 Milliarden us ging noch.
// timekeeping / deep sleep
#define uS_TO_S_FACTOR 1000000 /* Conversion factor for micro seconds to seconds */
#define TIME_TO_SLEEP 30 /* Time ESP32 will go to sleep (in seconds) */
[...]
// Put ESP32 into deep sleep mode (with timer wake up)
// Configure the wake up source as timer wake up
esp_sleep_enable_timer_wakeup(uS_TO_S_FACTOR * TIME_TO_SLEEP);
esp_deep_sleep_start();
Ich denke, dass default eine uint32_t verwendet wird, für die der 2 Stunden-us-Wert zu groß ist, nun habe ich statt dessen const uint64_t TIME_TO_SLEEP = 7200LL; verwendet … [edit2] und auch das funktioniert gut!
Warum kann der T-Call auch nach über 30 Sekunden aufgeweckt werden? Hat es was mit
if (en) {
Wire.write(0x37); // Set bit1: 1 enable 0 disable boost keep on
zu tun, dass es funktioniert?
1 Like