Lolin32 D32 pro mit RC522 als RFID-Leser

@biologist Wird es auch eine Version mit dem PN5180 geben?
Bin mit dem RC522 nicht so glücklich und würde gern beim zweiten Versuch auf den PN5180 so wie den D32 Pro wechseln.

Hätte ansonsten ebenfalls Interesse an einem PCB :slight_smile:

Ich bin aktuell dabei, einen PCB zu machen, der Lolin d32 pro mit pn5180 verwendet. Zusätzlich würde ich aber einen externen SD-Reader nutzen (für SD MMC), einen Port-Expander nebst SMD-Mosfets und Widerständen benutzen.
Würde dir das weiterhelfen?

externen SD-Reader hätt ich da, aber Mosfets und Widerstände als SMD müsst ich extra Ordern.
Ist den die Nachfrage dazu hier wirklich vorhanden?

Das weiß ich so genau nicht. Mir ging es in erster Linie darum, mal eine Testplattform für den von mir unterstützten Port-Expander zu haben. Weil aktuell muss ich das immer umständlich zusammenstecken. Der Vorteil ist halt auch, dass ich dann sowas wie i2c rausführen kann, so dass man auch ein Display anschließen könnte.

Der Punkt ist halt, dass es mit den GPIOs eng ist, wenn man den pn5180 verwendet. Externer SD Slot mag etwas unsinnig erscheinen, wenn man schon einen internen hat. Jedoch ist der interne leider nur per spi anzubinden, was einerseits langsamer ist und andererseits nen GPIO mehr braucht.

Was vielleicht passen könnte ist Lolin d32 pro mit sdmmc, pn5180 - aber ohne Anschluss für Kopfhörerplatine.

Dann noch ohne SMD und ich hätte meine gewünschte Platine :joy:

Muss ich mal schauen, wann ich da Zeit finde. Für das AZ-Delivery-Board wollte ich ja auch noch einen machen. Fürs Erste kann ich nur das hier anbieten: Lolin32 mit SD (SD_MMC) und PN5180 als RFID-Leser.
Davon habe ich auch noch welche da.

Wie gesagt, lieber nen D32 pro mit Pn5180. Leider kann ich mit KiCAD noch nicht umgehen, sonst würde ich selbst ein Board designen :wink:

Hi, erst mal danke für deine Arbeit. Ich hätte auch Interesse an einem PCB wenn du noch eines hast.

Viele Grüße
Joachim

Hab dir ne PM geschrieben.

Na, schon bisschen nen fortschritt in Sicht? Oder bisher noch gar nichts geschafft?

An der SMD-Platine habe ich immer mal wieder ein bisschen gearbeitet, aber fertig ist sie noch nicht. Um es kurz zu machen: Es fehlt der Bock momentan :rofl:

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:

  1. 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.

  2. 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 :pleading_face:

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.