Hmm, vielleicht kannst dir den hier ausborgen:
Hallo, ich habe den ESPuino nun wie oben beschrieben zusammengebaut nun habe ich das Problem, wenn ich das System mit dem Drehenkoder in den Deep Sleep schicke und ihn anschließend wieder erwecke werden keine Karten mehr erkannt der RFID Reader arbeitet gar nicht. Woran kann das liegen?
Vielleicht hat einer von Euch ne Idee.
Ich mache heute Abend mal auf meine Lolin D32 pro-Plattform die aktuelle Firmware drauf und versuche mal, ob ich das nachstellen kann.
Sorry, ich hab’s leider noch nicht geschafft.
@biologist Mir ist aufgefallen: wenn ich auf „Ausschalten“ klicke oder im Sleep-Modus leuchtet die blaue LED leicht gedimmt, aber permanent. Besteht die Möglichkeit diese auszuschalten, damit es Akku nicht aussaugt.
Wie kann man man allgemein komplett vom Strom trennen?
Das hatte ich noch nicht gesehen, kann es gedanklich allerdings nachvollziehen. An der Stelle muss ich leider tatsächlich zugeben, dass mir hier ein konzeptioneller Fehler in der Schaltung unterlaufen ist. Und zwar wenn man sich den Schaltplan anschaut, dann sieht man, dass mit GPIO5 eine LED verbunden ist. Die LED ist dauerhaft mit 3.3V verbunden, kriegt ihr GND dann vom GPIO5. D.h. würde man an GPIO5 einen Taster anschließen, dann würde die LED immer dann leuchten, wenn dieser gedrückt ist.
Jetzt verwende ich ausgerechnet GPIO5 halt, um das Gate des IRL3103 anzusteuern. D.h. im eingeschalteten Zustand ist der GPIO5 auf HIGH. Im ausgeschalteten Zustand ist es undefiniert, aber durch die beiden externen Widerstände R1 (1k) und R2 (10k) wird der Ausgang definiert auf GND gezogen (PullDown), damit der Mosfet auch wirklich sicher nicht durchsteuert. Das führt jetzt hier aber dazu, dass die LED, die ja dauerhaft mit 3.3V verbunden ist, über einen Gesamtwiderstand von 11k mit GND verbunden ist. Das führt zu einer (unnötigen) Stromaufnahme von 300 uA, mit der der LED dann offenbar bei dir leuchtet. Nehmen wir an, wir haben einen LiPo mit 2500 mAh und davon könnte man 90% Kapazität nutzen, dann wäre dieser aufgrund des Design-Fehlers (andere Verbräuche außen vor) in 7500 Stunden (312 Tage) leer. Bedeutet: Ist natürlich unnötig, aber die Ausmaße sind jetzt auch nicht dramatisch.
Behebung:
-
Ursächlich beheben kann man das in diesem Falle jetzt nur, wenn man die LED auslötet (gebraucht wird sie ja nicht). Da sollte man eine etwas größere Lötspitze nehmen, so dass auch hinreichend viel Wärmeenergie auf die LED übertragen wird. Wenn die LED heiß genug ist, kann man die zur Seite schieben - nicht zu viel Druck aufwenden, so dass nicht irgendwie eine Leiterbahn ausreißt oder so. Und sicherstellen, dass die beiden SMD-Pads der LED anschließend keinen Kurzschluss haben. Also es macht sicher Sinn, da im Anschluss mit Entlötlitze mal drüber zu gehen.
-
Man könnte ein bisschen experimentieren, ob man die Widerstände nicht auch bissl vergrößern kann. Speziell R2, das ist der zweite von unten (direkt oberhalb des 1k), da gehen vielleicht auf 47k oder 100k - das würde den Strom nochmal deutlich reduzieren.
Das geht im aktuellen Design nicht (außer man baut einen Schalter ein). Nur @compactflash hat hier einen weiteren Ansatz, bei dem er den LTC2954 verwendet. Dieser wird dem ESP32 vorgeschaltet und schaltet dessen Betriebsspannung. Das ist ne schöne Lösung, die er auch hier u.a. präsentiert hat. Schön daran ist auch, dass man damit den ESP32 auch komplett ausschalten kann, wenn dieser mal nicht reagieren sollte. Sie hat halt den Nachteil, dass man dafür SMD löten muss. Ich habe hier halt geschaut, dass das relativ einfach zu löten ist, damit das auch von mehr Leuten genutzt werden kann.
Wie auch immer: Sorry für den Designfehler in meinem PCB 
Alles klar, das hört sich gar nicht so schlimm an. Herzlichen Dank für die sehr ausführliche Antwort!
Ist O.K. wäre super wenn du Zeit hast und Mal drüber schauen kannst. Danke
Kann das Problem nicht nachvollziehen. Also klappt bei mir.
Problem ist bei mir nur, dass ich ihn per Drehencoder gerade nicht in den Deepsleep kriege, musste das über die Webgui machen.
Kriege aktuell via Drehencoder auf dem Lolin D32 pro:
Ein Karten-Modifikator existiert nicht vom Typ 0 !
Muss ich mal auf die Suche gehen, was da los ist…
EDIT: War nur zu doof, die settings.h richtig zu konfigurieren.
@Ajuko Vielleicht postest mal deine Configs.
Hab den Fehler jetzt auf den RC522 eingegrenzt. Der bisher verwendete war wohl defekt mit einem anderen funktioniert alles.
Ich danke dir fürs nachsehen.
1 „Gefällt mir“
Habe auch den Fehler mit typ 0, wo soll es angepaßt werden oder es ist schon commited?
Ich hatte GPIOs in der settings.h doppelt vergeben. Nachdem ich das korrigiert hatte, war es gut.
ok, pin 32 ist es, was doppelt ist. soll es auf einen belibiegen geändert werden oder die zweite doppelte Belegung muss geändert werden?
Es muss natürlich auf den richtigen Wert gesetzt werden. Ganz oben hier in diesem Thread findest du die gesamte Belegung in einer Tabelle.
danke, habe dran gar nicht gedacht. sorry.
Würde mich freuen, wenn das machbar wäre… lg Björn100k gingen bei mir nicht, dann hat die Abschaltung nicht mehr funktioniert.
Ok, danke für’s Feedback.
Ich schreib auch hier mal rein: Habe zwar keinen Lolin D32 pro, aber auch nen RC522 und der will nicht mehr nach dem Deep-Sleep per Drehencoder.
Bei mir ist der RC522 ebenfalls über SPI angebunden. Pins sind soweit ich das sagen kann, nicht doppelt vergeben.
Ich werde mal testen, ob es einen Unterschied macht, wie ich den ESPuino in den Tiefschlaf schicke.
Es gab ja jetzt schon Teilnehmer hier, die Probleme mit einem speziellen MAX hatten und es mit einem anderen dann ging. Könnt ihr dazu vielleicht mal einen Link posten? Weil dann korrigiere ich meinen Link weiter oben.
Danke.