ich bin gerade dabei mir eine Übersicht über die Komponenten und den Features zu machen.
Nun wollte ich einmal euren Rat einholen ob sich meine Wünsche umsetzen lassen und ob ich die richtigen Komponenten hierfür gewählt habe.
+Web GUI
+FTP Upload
+Batteriebetrieb (Deepsleep wenig Strom/Ladeelektronik (LiFePO4?))
+Deepsleep aufwecken
+Kopfhörer
+Webradio
+TonieID auslesen
+5 Tasten
(+OTA)
(+Display [evtl. später mal angedacht])
-kein Neopixel
-kein BT
Komponenten
Lolin D32 pro
MAX98357a
PN5180
SPI 2GB/8GB SDHC Card 3.3V ESP8266
Visaton FR 10HM 20W
LiFePO4 3.2V mit Schutzschaltung
PCA9555 Port Expander
+Widerstände etc.
Für BT braucht es keine extra Hardware. Das gibt es quasi „geschenkt“, weil der ESP32 das eh kann.
Für LiFePO4 gibt es aktuell kein Board, weil es dafür (meines Wissens) kein Develboard gibt. Das Ganze ist bissl aufwändiger, weil man dafür (zumindest in gut) nicht nur einen Laderregler sondern auch einen Buck-Converter braucht.
Um einen Port-Expander wirst du wohl nicht rumkommen, wenn du 5 Tasten, i2c (Display) und PN5180 möchtest.
Kopfhörerbuchse gibt’s aber muss bisher selbst gelötet werden. Aber das ist ja aktuell was in der Mache…
Von keinem Neopixel würde ich eher abraten, du kriegst vom ESPuino sonst echt wenig Feedback, was gerade passiert. Zumindest eine einzelne WS2812b-LED würde ich einbauen.
Mein Aufbau ist sehr ähnlich, nur ohne Port Expander und daher weniger Buttons (aber Neopixel).
Für den LiFePO4 kann ich ein Board mit TP5000 empfehlen. Das hat eremit sogar im Shop.
Es gibt wohl aktuell keine Abschaltung bei niedriger Batterie, ich habe das aber bei mir im Fork implementiert und hoffe das irgendwann bei biologist zu mergen (Ist aber auch kein Hexenwerk). Beim LiFePO4 wirst du ohnehin keine Erkennung haben wie voll er ist. Bei mir blieb die Spannung tatsächlich bis 20% bis auf 2 Nachkommastellen gleich. Wenn er unter 3V fällt könntest du ihn dann natürlich als „leer“ behandeln.
Ich weiß nicht ob ich dem so zustimmen kann. Im Netz finden sich haufenweise Beiträge dazu den ESP32 direkt von LiFePO4 zu betreiben. Der ESP32 kann 2.4V (oder so) bis 3.6V offiziell ab. Das ist genau die Spannung die der Akku haben kann.
Bei mir akzeptieren alle Komponenten die geringere Spannung problemlos. Der Verstärker ging als erstes aus bei ~2.7V, wo der Akku ja schon fast leer ist.
Und wieso meinst du man benötigt einen Buck-converter? Die Spannung ist ja niedriger als bei LiPo, und die haben ja alle einen LDO.
Zusammengefasst heißt das, du kannst den LiFePO4 direkt an 3.3V am ESP anschließen. Vermutlich ist es gut da noch nen großen Kondensator parallel zu schalten, da der TP5000 als Schaltregler theoretisch eine unsaubere Spannung ausgibt. (Ich habe kein Oszilloskop, daher keine genaue Aussage an dieser Stelle).
Beachte, dass bei den meisten (allen?) Boards während der ESP32 mit 3.3V versorgt wird keine 5V angeschlossen werden sollten. Also nur noch Updates über OTA oder 3.3V trennen wenn USB angeschlossen ist.
Wie @biologist schon sagte musst du zumindest für die Ladeelektronik was eigenes bauen.
Wenn du dazu noch irgendeine Frage hast, versuche ich gerne zu helfen.
Das ist ein valider Einwand. Ich glaube nicht dass das ein Problem ist, aus zwei Gründen: Das Ladegerät lädt den Akku ja abhängig von seiner Spannung, und die bricht nicht sofort ein nur weil der ESPuino im Betrieb ist (laden mit 1A und ESPuino ca 150mA Verbrauch).
Selbst wenn das Ladegerät „verwirrt“ ist von dem Betriebsstrom, lädt es im Zweifel den Akku weniger voll, was nichts schlechtes ist, im Gegenteil.
Disclaimer: Ich bin kein Experte was das anbelangt, also im Zweifel recherchier nochmal ob das dem Akku schaden kann.
Den ESPuino (ich schreibe extra nicht ESP32) ohne Festspannungsregler zu betreiben, da bin ich nicht so der ganz große Fan von. Also wenn man so nen ESP32 in einem Setting einsetzt, wo es auf jedes uA quasi ankommt, dann bin ich voll bei dir. Aber beim ESPuino gibt es doch auch so ein paar Abhängigkeiten. Also ich hatte zB schon das Problem, dass der ESPuino irgendwann komisch reagiert hat und es lag einfach daran, dass die Akkuspannung zu gering war. Das muss man dann halt zu deuten wissen. Klar: Lässt man den LDO weg, dann gewinnt man natürlich die Spannungsdifferenz, die man sonst am LDO verlieren würde (0,2 V oder so). Aber man verliert auch „konstante Verhältnisse“. Verstehe mich nicht falsch: Ich sage nicht, dass das falsch ist oder dass das nicht geht. Aber diejenigen, die das so betreiben, denen muss halt klar sein, dass das ne potentielle Fehlerquelle ist. Wenn man damit umzugehen weiß, dann bin ich da völlig d’accord. Es ist nur keine Lösung, die ich jetzt propagieren würde, weil ich es sonst am Ende supporten muss .
Weil man damit auch 3.3V rauskriegt, obwohl die Spannung unter 3.3V gefallen ist. Da kann man z.B. einen STBB1-APUR verwenden, dem kannst du eine zu kleine oder eine zu große Spannung geben - hinten kommt dann das Passende raus. Zumindest habe ich das so verstanden, eingebaut habe ich ihn noch nicht.
Das muss aber unterscheiden können zwischen kein Akku angeschlossen und es ist einer dran, der halt ne niedrige Spannung hat .
EDIT:
Ich meine übrigens gelesen zu haben, dass der TP5000 eine Unterspannungserkennung integriert hat. Aber das wird man dann mit Mosfets extra beschalten müssen und das wird mit dem TP5000-Develboard dann vermutlich nicht gehen.
Absolut gerechtfertigt. Persönliche Evidenz ist dass es keine Probleme macht, aber das will nichts heißen. Vielleicht verhält sich LiFePO4 aber auch einfach anders und kann auch bei niedriger Spannung besser mit Stromspitzen umgehen als andere Akkus.
Hat ein potentielles „complete“ board mit LiFePO4 support denn einen step-up verbaut? Eine bessere Lösung wäre es natürlich schon.
Ah, für mich ist die die Unterscheidung „Buck“ für Spannung reduzieren und „Boost“ oder „step-up“ für Spannung höher. Das wäre dann ein „Buck-Boost“. Keine Ahnung ob das so richtig ist.
Wenn man den STBB1-APUR verlöten will, kann man auch gleich noch nen MAX17055 als Batteriemanagement dazunehmen, der hat das gleiche Package.
Guter Einwand, das behalte ich mal im Hinterkopf für den Code. Bei LiFePo4 tritt das Problem ja nicht auf, da ohne Akku nicht <3.2V anliegen sollten.
(Okay ich habe mal geschaut. Ein leerer LiPo liegt ja genau um die 3.3V, da wird das nur mit Spannungsmessung nichts. Wer davon ausgeht, das der ESPuino auch ohne Akku betrieben wird muss das Feature eben ausschalten.)
Ich denke das würde man so lösen, wie das beim Lolin D32 pro auch gelöst ist: Man hat einen P-Channel-Mosfet, dessen Gate man mit einem Pulldown verbindet und zudem mit VUSB. Das führt dann dazu, dass der Mosfet gesperrt ist, wenn eine Spannungsversorgung über USB stattfindet. Leiten würde man über diesen Mostfet die Stromversorgung des Akkus. VUSB ist seinerseits natürlich dann auch am TP5000 angeschlossen, damit dieser den Akku laden kann.
Die Ausgangsspannung des Akkus müsste man einfach auf den 3.3V-Anschluss des Lolin D32 pro führen können, was zur Folge hat, dass die Abschaltung der Peripherie via Mosfet-Schaltung unverändert bleiben kann.
Ja.
Ja stimmt schon .
Tja, das ist immer so die Sache. Im Endeffekt reicht es falsche Werte einzutragen in die Settings-Files und dann wird die Spannung falsch berechnet. Dass da „Mondwerte“ rauskommen geht schnell .
Ja stimmt. Ich habe bei mir den Akku auch per mosfet abgekoppelt wenn 5V anliegen.
Als Perfektionist wollte ich aber auch, dass der ESPuino nicht abstürzt wenn man 5V zum laden anschließt. Bei mir hat es dafür etwas experimentieren und im Endeffekt einen sehr kleinen (470) Pull-down (ergibt 10mA Verluststrom) und großen (1000 µF) Kondensator gebraucht, um eineserseits die Abschaltgeschwindigkeit beim Mosfet zu haben und andererseits die Spannung zu stabilisieren.
Muss man wissen ob man das braucht. Schalten die fertigen Boards da eigentlich schnell genug oder bricht die Spannung kurz ein wenn der Stecker gezogen wird?
Ob die einbricht (wird sie sicherlich ein bisschen tun) müsste ich mir mal auf meinem Oszi anschauen. Aber auf jeden Fall nicht so, dass es dem ESP32 was macht. Also abstürzen tut da nix.
Okay, kurze Recherche ergibt, dass es kein Problem ist die Batterie im System zu lassen wenn geladen wird. Solarladegeräte und ähnliches machen das auch so. Da gibt es ja auch keine externe Spannungsquelle auf die kurz umgeschaltet wird. (Naja Netzstrom gäbe es, aber wenn die Sonne scheint will man das ja auch nutzen )NEIN! Seid vorsichtig was ihr mit LiPos macht.
Der Mosfet beim D32 pro scheint laut schematic nur zu existieren, damit die Batterie keine 5V von VBUS abbekommt. Durch die Body diode kann die Batterie eigentlich immer Spannung abgeben. Dann dürfte es auch keinen Verlust der Spannung geben. Ich habe die Batterie in beide Richtungen abgetrennt, weil ja an 3v3 keine Spannung liegen soll wenn 5V anliegen.
Also wenn die Batterie direkt an 3V3 soll würde ich mich daran nicht orientieren. Wenn Batterie und 5V als parallel geschaltet werden und dann durch einen Regulator gehen passt das aber besser.
Also auf jeden Fall beim Laden alles über 5V betreiben, sonst weiß der TP5000 nicht wann er aufhören muss zu laden. Gilt zwar für normalie Li-Ion, aber ist bei LiFePO4 sicher auch nicht verkehrt.
Ich habe mir das Develboard für den TP5000 mal angeschaut. Der ist so kompakt, dass man ihn sogar auf meiner rev3 unten im Bereich der USB-Buchse am Lolin D32 pro noch integrieren könnte - mit recht wenig Aufwand in der Anpassung des Leiterbahn-Routings. Nur scheinen die Löcher aber recht groß zu sein. Keine Ahnung, ob das so Sinn macht, das auf einen normalen Pinsocket zu löten, um es zu sockeln auf dem rev3-PCB.
Wie war das von wegen nicht offiziell propagieren?
Dann benötigst du ja die Mosfet-Schaltung (die hat man dann doppelt beim D32 Pro). Doppelt hätte man dann auch die Spannungsmessung (wenn zusätzlich). Und einen TP4054 ungenutzt zum TP5000.
Das kann man natürlich machen, aber ob das sinnvoll ist beim D32 Pro? Wenn du in die Richtung gehen willst wäre das vermutlich spannender für die Boards die normalerweise gar keine Akku-Unterstützung haben, also z.B. DevkitC. Oder einfach den 3V3 extern zugänglich machen, wenn das jemand braucht kann er es selbst bauen.
PS: Die Löcher passen auf ganz normales 2.54mm Format.
Hehe. Also sagen wir es mal so: Ich kann so ne PCB-Anpassung recht einfach machen, aber mein Bock hält sich so ein bisschen in Grenzen das zu testen + zu supporten.
Korrekt.
Ich selbst eigentlich nicht, weil das wird mir dann in der Breite auch langsam zu viel. Aber ich könnte PCB-technisch was beisteuern, wenn es jmd. hilft.
Da hast du natürlich Recht. Für DevKit C wäre das eine Option sowas nachzurüsten. Welchen benutzt du denn da mit einem WROVER drauf?
Ich hatte schonmal etwas in der Richtung geschrieben dass man vielleicht ein extra Board entwerfen könnte für die Stromversorgung. Also USB (C) rein, 5V, 3.3V raus mit Batterieanschluss und Ladeelektronik und evtl. die USB data lanes noch durchschleifen um debugging zu haben.
Kann man dann für jedes Board verwenden. Man könnte optional einen ordentlichen LDO verwenden (nicht AMS1117) der auch im Deepsleep gut ist.
Man ist dann halt langsam an einem Punkt wo man das Devboard weglassen könnte und direkt den Wrover verbaut.
Das ist letztendlich deine Entscheidung wie viel du noch extra entwerfen und supporten willst, daher lass dir nicht zu viel reinquatschen, haha.
Ich mache da erstmal nix, hehe.
Denke ich werde eher mal ne Complete machen; habe noch fünf ESP32-Wrover hier liegen, die ich irgendwann mal mitbestellt hat.
Gut egal, wird jetzt offtopic. @Kinimod Zusammenfassung: Also es schon Mittel und Wege. Aber ist auf jeden Fall nix, was es jetzt schon irgendwie fertig gäbe.
Und nur falls das jetzt untergegangen ist: Das einzige wirkliche Problem ist der LiFePO4.
Falls du den dennoch verwenden willst ist hier meine Schaltung. Ich weiß nicht ob die Schaltung gut ist aber sie funktioniert.
.
.
)
