Minimal Hardware Design GSM-Stockwaage mit TTGO T-Call

well… schreibt der hersteller irgendwo, ob mit den angeblichen 300uA noch irgendwas funktioniert das die 300uA wert macht? - nich falsch verstehen, aber meiner erfahrung nach ist sone aussage nix wert wenn man sie nicht selber gemessen hat. auch nicht bei ‘qualitaetsanbietern’ ;)

hier haben jemand angebliche 240uA nicht gereicht… die loesung ist wie immer… ein load switch/pchannel fet.
https://blog.zakkemble.net/remote-mail-notifier-and-gps-tracker/

ich will nicht sagen das seine hardware toller ist (nur anderst) - aber die probleme und ansaetze sind die gleichen wie hier. er hat einen attiny als deep-sleep controller und einen pchannel fet gewaehlt.

Da muß dann aber etwas anderes Grundsätzliches nicht stimmen, denn allein der Unterschied zwischen quiescent current und shutdown current beim SY8089 macht lt. Datenblatt über 50 µA aus - diesen Unterschied hättest Du gemessen…

Da gab es doch jenes Register, welches GPIOs in der RTC domain per HOLD festnageln konnte, damit sie im deep sleep ihren state nicht verlieren - wir hatten das z.B. hier im Forum für micropython.

Hier gibt es noch Infos zum Thema deep sleep current.

I think there is no simple way to turn off power converters. You even can not turn off IP5306 programatically, because its KEY pin (where you would send LOW for more than 2s) is also connected to reset of ESP32. You can program IP5306 to switch off 32s after ESP32 goes to sleep, but then you can only wake it manually by pressing reset. I was trying to find a way how to shut down everything and just keep ESP32 in sleep powered directly to 3.3V rail, but a) power was still about 1mA, b) I could not wake the board only manually

Ich dachte ja, das Ausschalten des “PowerBoosts” reiche schon um den IP5306 zu deaktivieren, das ist aber nicht so. Im Batteriebetrieb muss man das board mit einem reset starten. Der reset-Knopf ist aber nicht nur reset für den ESP, sondern auch Anschalter für den IP5306 , d.h. der ist an, auch wenn ich den nicht per Software aktiviere.

Das Ding hat zwei SY8089 (heißen dort “1U1” sowie “1U2”).

1U1 macht die etwa 4 V für das Modem, und 1U2 die 3V3 für v.a. den ESP32. Beide haben einen ENABLE-Eingang, welcher bei 1U1 auch benutzt wird (GPIO23 schaltet die Modemversorgung), 1U2 ist dauerhaft angeschaltet. Laut Datenblatt darf dieser Eingang nicht unbeschaltet bleiben, braucht also immer pull-up oder pull-down.

Was machen die aber? Sie bauen einen Spannungsteiler (jeweils 100k/100k an beiden ICs) an diesen Eingang, so daß mindestens beim 1U2 immer VCC/2, also 2,5V am EN-Eingang anliegen. Wäre ja OK, wenn 1R18 (der untere Zweig) nicht wäre: dadurch, daß dieser nicht weggelassen wurde, braucht die Eingangsbeschaltung des EN dauerhaft unnötig 25µA … unglaublich.

image

Umgekehrt ist es bei 1U1: das Modem ist im Normalzustand OFF, daher kann ein EN dauerhaft einen pull-down bekommen. Da 1R7 und 1R4 beide auch als NC angegeben sind, weiß ich nicht, wie das “in echt” ist, also welche tatsächlich bestückt sind. @clemens, kannst Du bitte mal schauen, was von den beiden wirklich bestückt ist? Nicht, daß der auch noch bestückt ist (und nochmal 25µA braucht)…

image

(Das GND-Symbol über der 2 ist wohl ein vergessenes Artefakt…)

Sie lassen auch noch die community im github features vorschlagen, und dann verk… sie es bei solchen Details.
Wenn ich mir als Hardware-Entwickler derartige Schaltungsdetails ansehen muß, habe ich keinerlei Sorge, daß es zu der von China angestrebten Rolle einer globalen Technologieführerschaft tatsächlich kommen könnte…

2 Likes

Ich hab mal den nackten (keine Peripherie, kein Programm) T-Call mit uPy ans Meßgerät gehängt. Da kam folgendes raus:

Ruhe, ohne REPL - 24,1mA
Ruhe, mit REPL - 38,7mA

Bis hier 160MHz. Ab hier immer mit REPL.

80Mhz - 35,3mA
40Mhz - 28,6mA
20Mhz - 23,5mA (<20MHz geht nicht)
lightsleep - 20,3mA
deepsleep - 19,2mA

Schneller Vergleich mit dem ESP32 mit HX711 & BMP280 braucht im lightsleep ca. 45mA.

Wenn es da nicht ein paar Tricks gibt wird das ohne externen Timer und Komplettabschaltung nix. Sollte das die Lösung sein, dann müssen wir aber mal kräftig an der Bootzeit vom Terkin arbeiten. Der braucht fast eine Minute für den Kaltstart.

Hmm, mit MicroPython fast 20 mA im deep sleep und mit Arduino 850 uA!? Komisch!

Den Kaltstart bekommen bzw. haben wir schon schneller hinbekommen wenn der Code gleich beim build der Firmware eingefroren wird, wir waren bei ca. 5 Sekunden!

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 TTGO-T-Call/board.jpg at master · Xinyuan-LilyGO/TTGO-T-Call · GitHub . 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:

Um die traces zu checken muss ich mit Vergrößerung ran.

Der SOT23-5 in der Mitte könnte unser gesuchter SY8089 sein.

Ja, wir haben das ja hier schon länger erschlossen: Low Cost GSM/GPRS-(SIM800)-Node – 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. :frowning: 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/TTGO-T-Call · 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/TTGO-T-Call · 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/TTGO-T-Call · 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