Muss er auch nicht, ohne die dritte Zelle baut das schon gleich viel flacher (und ist auch nicht ganz so ein Schlauchboot-Anker).
Super Sache, Danke!.
Habe jetzt mit dem FePo-Board und den Spannungen ein bisschen experimentiert. Also normalerweise (mit D32 pro/LiPo) habe ich ein positives Offset von 0,1 V eingestellt, da der ESP32 sonst tendenziell eher zu wenig misst: ESPuino/settings-lolin_d32_pro_sdmmc_pe.h at fc3d5005cddde88c154b6231ea2f35e1dafa6e09 · biologist79/ESPuino · GitHub. Bei meinem FePo-Board passen hier 0,2 V vermutlich besser. Also wie es war, als der Akku ganz voll war, weiß ich nicht mehr so genau, aber spätestens so ab 3,3 V war die Messung des ESP32 immer etwa 0,1 V zu niedrig.
Ich habe jetzt mal bis auf 2,7 V etwa entladen, da wurde noch weiterhin Musik (auch von SD) abgespielt und auch RFID (nur PN5180 habe ich getestet) lief noch. Neu starten konnte ich den ESP32 jedoch nicht mehr. So bei 2,8 V etwa ging das noch. Also irgendwo dazwischen wird es potentiell kritisch.
Für die Akku-Parameter in der GUI würde ich auf Basis meines empirischen Versuchs folgende Werte vorschlagen (sofern oben auf 0,2 V Offset korrigiert wird - bitte im Einzelfall aber überprüfen!):
Alle LEDs an: 3,3 V (weil Spannungen über 3,3 V hat man eh nur so 1-2 min lang nach einem kompletten Aufladevorgang)
Warnung ab: 3 V
Eine LED: ab 3 V (siehe Messreihe)
Zwei Bugs sind mir beim Testen aufgefallen, die ich fixen muss:
- Sobald die Spannung ich glaube 2,9 V unterschritt, führte das manuelle Auslösen der Spannungsmessung dazu, dass diese zwar von den LEDs angezeigt wurde, aber anschließend nicht mehr verschwand. Ich denke das hatte etwas damit zu tun, dass ich 2,9 V in der GUI konfiguriert hatte.
- Die geschätzte Restkapazität in den Infos der GUI wurde negativ angegeben.
Fazit:
Insgesamt bekräftigt mich das in der Tatsache, keinen Boost-Converter benutzt zu haben. Ich bin überrascht, dass der ESPuino auch bei solch geringen Spannungen noch funktioniert. Unterhalb von 3 V, spätestens ab 2,9 V, geht es doch relativ schnell mit der Spannung weiter nach unten. Groß was gewonnen, außer konstante 3.3 V-Verhältnisse, hätte man mit einem Boost-Converter nicht, zumal der selbst ja auch Verluste hat.
1 „Gefällt mir“
Unterhalb von 3V läuft der ESP32-WROVER-E außerhalb der Spezifikation. Dabei könnte sich das ein oder andere „komische“ Verhalten zeigen. Der ESP32 an sich läuft ja noch bis 2.3V, aber die 3V beziehen sich dann wohl auf den Flash- und/oder PSRAM-Baustein des WROVER-Moduls. Bei mir hat sich bei niedrigen Spannungen das Modul aufgehängt und selbst im Netzbetrieb lief er nicht mehr an. Beheben konnte ich das nur durch einen Reset. Wenn kein Boost-Convert gewünscht ist, wäre vllt. ein Voltage Protector auf den EN Pin sinnvoll: #315 How to use Voltage Supervisors to protect ESP32, Raspberry Pi, and Batteries - YouTube
1 „Gefällt mir“
Gut, ich sage ja nicht, dass das erstrebenswert ist, den ESP32 unterhalb von 3 V zu betreiben. Nur in meinem Feldversuch hat es funktioniert. Wenn man einen Boost-Converter einbaut, dann hat der glaube ich einen Wirkungsgrad von ca. 90%. Ich habe aber so meine Zweifel, dass unterhalb von 3 V noch 10 % nutzbar sind für uns.
Auf dieses Develboard würde es eh nicht mehr passen. Es erzeugt halt zusätzliche Kosten und irgendwie ist unklar, ob das wirklich Mehrwert bringt.
Danke für den Link, interessant!
Wenn man so ein Monitoring irgendwann mal angeht, dann könnte der TPS3839G33 (schaltet bei 3,08 V) passen. Gibt’s auch für etwa 50 Cent bei JLC. Bei AliExpress knapp 30 Cent.
Am Samstag kamen noch zehn weitere Platinen für ein solches Develboard an. Bisher hielt sich das Interesse an diesem Board recht in Grenzen. Von daher werde ich das bis auf Weiteres nur bei Bedarf von Hand löten. Also meldet euch.
Die kürzlich von von Daniel (Eremit) versprochenen Akkus sind nun scheinbar lieferbar:
https://www.eremit.de/p/3-2v-4000mah-pack-mit-schutz-flach
Wer so einen Akku (4000 mAh) benötigt, der sollte sich mit der Bestellung beeilen, da es (wohl vorerst) nur eine Kleinserie ist.
1 „Gefällt mir“
Hi, ich hätte Interesse an 3 Boards sofern noch vorhanden.
Hallo,
Ich habe auch Interesse an zwei Platinen, komme aber erst in meinem Urlaub dazu das Thema intensiver zu betrachten weshalb ich mich bisher zurück gehalten habe.
Wie ist denn der derzeitige Stand?
Beste Grüße
Morik
Habe @Teian eben schon geschrieben wegen den drei Stück. Könnte aber noch zwei weitere löten. Danach brauche ich aber erstmal wieder neue Bauteile.
Dank der tollen Arbeit von Torsten bin ich schon seit einigen Wochen im Besitz eines Devel-Boards. Da sich meine Kinder weigern, ihren Espuino für den Umbau rauszugeben (sie haben wohl Angst, dass der Papa etwas kaputt macht), habe ich den Aufbau bisher nur fliegend getestet. Nach anfänglichen Schwierigkeiten funktioniert das Teil einwandfrei. Ich bin erstaunt, das so ein Board (noch) nicht serienmässig angeboten wird. Die Vorteile überwiegen doch stark: USB-C für die Zukunft und LiFePo für die Sicherheit.
Nun zum Problem (ist zwar offtopic): Ich kriegte die Meldung, dass die SD-Karte nicht initialisiert. Nach langer Suche und dann durch Zufall entdeckte ich, dass es unterschiedlich aufgebaute Reader gibt. Der eine hat nebst den Widerständen nur 1 Kondensator verbaut, der andere 2. Anhand der Lücke können sie gut unterschieden werden. Ganz nach dem Motto: „Je mehr, desto besser“ funktionierte der mit 2 Kondensatoren. Mangels zweitem 1C-Reader konnte ich den Fehler nicht reproduzieren.
Der obere Reader funktionierte nicht, der untere hingegen schon.
Kannst du mal durchmessen wo der zweite C liegt? dann könnte man den ersten vlt fixen…
Der erste hat ein anderes Layout der Leiterbahnen. Es gibt da gar keine Lötpunkte für einen Kondensator.
Das heißt ja nicht das man da nicht einen unterbringen könnte 
Fliegend geht alles…
Von der Idee her gefällt mir ein LiFePo4 Board ja eigentlich ganz gut, aber zwei Fragen zur aktuellen Ausführung hätte ich noch:
-
Soweit ich das sehe gibt es derzeit keinerlei Möglichkeit das Board komplett auszuschalten, außer man hat gerade USB eingesteckt und zieht den EN Pin auf 0, oder? Sobald man kein USB mehr eingesteckt hat, nützt der EN Pin nichts mehr und auch im Deepsleep werden 1,4mA gezogen. Könnte man noch irgendwie das EN Signal an den Q2 weiterleiten, so dass man auch die Batterie trennen kann?
-
Bzgl. Akkustandsmessung gibt es doch noch den Trick von hier: » Measuring the battery without draining it » JeeLabs , also Spannungsteiler mit zwei 10M und einem 0.1 uF Kondensator. Würde so ein Trick beim ESP32 nicht auch funktionieren, wenn man die Spannung nur alle paar Sekunden misst? Wird schon einen guten Grund haben, dass das auf keinem Board so verbaut ist…
Wenn sich zumindest das Ein-/Ausschalten lösen lässt, hätte ich Interesse…
Grundsätzlich hatten wir hier auch schon andere Ansätze, beispielsweise den LTC2954, um alles auszuschalten. Das Problem ist hierbei so ein bisschen, dass das Teil relativ teuer geworden und auch gar nicht so gut zu kriegen ist. Und da ich mir halt eher Konzepte überlegen muss, die für alle relativ einfach + günstig umsetzbar sind, bin ich für’s Erste bei einem einzelnen P-Mosfet gelandet. Das ist natürlich nicht perfekt, aber das Ganze muss aus meiner Sicht auch nicht auf Hocheffizienz getrimmt sein. In den ESPuinos meiner Kinder sind LiPo-Akkus mit 2500 mAh. Sagen wir, dass 90% der Energie nutzbar sind, dann dauert es gut 67 Tage, bis der Akku leer ist. Klar sind 1,4 mA im Kontext von Mikrocontrollern viel, aber „Einfachheit“ ist in Zeiten von fehlenden Bauteilen auch was wert.
Nichtsdestotrotz habe ich mir bereits Gedanken daarüber gemacht, ob sich das Ganze nicht mit einfachen Mitteln verbessern ließe. Eine Idee dazu habe ich hier (zweites Bild) mal publiziert: Espuino mit LiFePo4 Akku betreiben - #55 von biologist. Nur getestet habe ich das (bisher) nie.
EN_APUR war hier als Enable-Pin für den STBB1-APUR gemeint (Boost-Buck-Converter). Da würde ich der Einfachheit halber inzwischen eher einen stinknormalen LDO nehmen. VIN ist der kombinierte Spannungspfad aus USB oder Akkuspannung. Was man halt vermutlich bräuchte, ist einen zweiten ME6211, der den Port-Expander (PE) immer mit 3.3 V versorgt. Irgendwie so.
Zeichne mal einen Schaltplan von deinem Vorhaben, dann können wir drüber reden.
Zum Spannungsteiler: Ich verwende 2x300k, was im Endeffekt 5,5 uA bedeutet bei 3.3 V. Also das ist nicht der ausschlaggebende Punkt bei den 1,4 mA, hehe.
Auf den EN-Pin des LDOs hast du ja beim Develboard direkten Zugriff. Da bist du völlig frei, wenn du dir einen ESPuino-PCB designst 
.
EDIT:
Für einfach umzusetzende Verbesserungen bin ich total offen. Beim Develboard ist man jedoch in der Größe auch etwas eingeschränkt.
Willst du per SW schalten können? (da würde ja nur AUS gehen, er kann sich ja nicht selbst anschalten)
Ich habe einfach in die Akku + Leitung einen Schalter verbaut, und schon sinkt mein „Aus“ Verbrauch auf 0 mA 
„Einfach“ ein Schalter in der Leitung heißt aber wohl, dass der ESPuino immer angeht, wenn man USB einsteckt, aber nicht immer lädt, wenn man USB einsteckt, oder?
Aber ich hab nochmal drüber nachgedacht und bin auf folgende Schaltung gekommen, die in Kombination mit entsprechender Software hoffentlich funktioniert:
- Wenn eingeschaltet werden soll, muss der Schalter lange genug gedrückt werden, dass der ESP bootet. Hoffentlich sollten so ca. 3sec ausreichen? Dann wäre das für mich voll in Ordnung, und die Tochter ist es sowieso von der alten Tigerbox-ohne-touch so gewohnt.
- Beim Booten schaut der ESP erstmal nach, ob GPIO2 auf 1 ist. Wenn ja geht er zum normalen Bootvorgang über. Wenn nein, geht er in den Modus ChargeOnly („ESP läuft, weil USB eingesteckt wurde, aber eigentlich nicht eingeschaltet wurde“)
- Im normalen Bootvorgang wird erstmal GPIO1 auf 1 gesetzt, damit man den Knopf wieder loslassen kann, dann wird alles so gemacht wie immer und GPIO2 kann bei kurzem Drücken als Play/Pause, bei langem drücken als „Power Off“ verwendet werden.
- In der „Power Off“ Funktion wird der aktuelle Status gespeichert, damit das Hörbuch an der richtigen Stelle weitergeht etc., es wird gewartet, bis der Knopf wieder losgelassen wurde, und am Ende wird GPIO1 auf 0 gesetzt. Wenn der ESP ausgeht ist alles gut, wenn nicht dann wird er wohl an USB hängen. Dann sollte er mit der nächsten Instruktion zu init() zurückkehren (resetFunc() oder sowas), und kommt dann voraussichtlich in den Modus ChargeOnly.
- Im Modus ChargeOnly wird auch erstmal der GPIO1 auf 1 gesetzt, damit der Akku verbunden wird und geladen werden kann. Dann wird gewartet bis entweder der Knopf gedrückt wird (GPIO2 ist 3 sec. auf 1 oder wie man es auch mag) - in diesem Fall wird der Modus ChargeOnly verlassen, man macht ganz normal mit init() weiter. Alternativ sollte ChargeOnly verlassen werden, wenn kein USB mehr eingesteckt ist und somit nicht mehr geladen wird (CHRG Pin auf 0) - dann wird GPIO1 auch ausgeschaltet und alles ist aus. Oder, wenn es keinen CHRG Pin gibt, wird einfach alle 10-30sec oder alle paar Minuten mal probehalber GPIO1 auf 0 gesetzt - wenn der ESP dann noch nicht aus ist, muss er noch am USB hängen und sollte somit weiter laden und warten.
Dann fragt sich nur noch:
- Was hab ich übersehen?
- Was macht der Ladechip, wenn kein Akku verbunden ist bzw. der Schalter auf „aus“ steht?
- Laut Soft Switch (2810) with Battery - #4 by RyanSchnitzler - Other Pololu products - Pololu Forum sollte es möglich sein, durch den Slide Switch zu laden, während es bei deren Pushbutton Switch nicht geht.
- Wahrscheinlich kann man das auch irgendwie einfacher haben, wenn man sich mit MOSFETs besser auskennt als ich.
Wenn man die Idee mit den Sub-Platinen aus dem anderen Thread aufnehmen möchte, könnte man meiner Meinung nach mit einem LiPo/LiFePo4 Charger mit Load-Sharing anfangen, der dann aus dem Laderegler besteht mit Lötbrücke um zwischen LiPo und LiFePo4 zu wählen, aber auch einen Teil der „Power“-Schaltung hätte. Stelle ich mir ungefähr so vor:
Dadurch sollte sichergestellt sein, dass nur entweder vorzugsweise an VBUS_SW oder nachrangig an VBAT_SW eine Spannung anliegt. Je nach Lust und Laune kann man dann z.B.:
- Für LiPo Akkus VBUS_SW und VBAT_SW zusammenführen an den Eingang eines 3.3V Reglers bzw. ein ganzes DevBoard anschließen
- oder für LiFePo4 den VBUS_SW an einen LDO anschließen und VBAT_SW direkt an den 3.3V Pin
- oder, wenn man mal 5V bräuchte, einen Boost an VBAT_SW anschließen und dessen Ausgang mit VBUS_SW verbinden…
- …und natürlich Schalter verbauen, wo und wie man möchte, aber unabhängig davon immer Akkus laden.
Den meisten Ladeplatinen, die ich sonst so gefunden habe, fehlt der Load-Sharing Teil und über LiFePo4 bzw. getrennte Ausgänge braucht man gar nicht erst reden. Daher denke ich schon dass so eine Platine für sich genommen einen Wert hätte.
Ich will eigentlich, dass ich mittelfristig von den Breadboards wegkomme, damit ich nicht so viel von Hand löten muss. Insofern ist das für mich nicht zielführend, hier noch ein weiteres Breadboard wieder einzuführen. Aber das soll dich natürlich nicht davon abhalten, dir das so zu bauen, wie du das gerne hättest .
Muss halt schauen, dass sich das Ganze auch erstmalig flashen lässt. Weil ganz am Anfang ist halt noch keine Firmware drauf.
Er schaltet CHRG ständig an und wieder aus, so dass eine dort angeschlossene LED dann blinkt. Als Leerlaufspannung zum Laden des FePo-Akkus kann man dann etwa 3,6 V messen. Ist ein Akku angeschlossen und er wird geladen, so wird CHRG auf LOW gezogen (Open Drain). Ist ein Akku angeschlossen und er wird nicht geladen, so wird CHRG auf HI gezogen.
Was man bestimmt machen könnte, ist einen Schalter, wie von @JHB zu integrieren, den man auf der einen Seite auf GND anlötet und auf der anderen Seite an EN. Damit zieht man den Enable-Pin des ME6211 auf GND und damit kommt hinten nix raus. Die Ladeschaltung würde davon nicht beeinflusst.
Aber die LiFePo Akkus umgehen doch den Laderegler und gehen direkt an den ESP, oder nicht? Dann nützt EN auch nichts mehr.