Tatsächlich ist die Reichweite erheblich besser. Allerdings habe ich irgendwie die Erfahrung gemacht, dass die nicht zwangsläufig auch mitgeliefert werden. Oft sind beide Tags 14443. Beim offenen Versuchsaufbau habe ich mit 15693 eine Reichweite von etwa 12cm.
@biologist @tueddy danke für eure Tipps. Die Reichweite hatte ich erst auch im Verdacht. Allerdings eher die minimale Reichweite, da zwischen Leser und Karte nur 5mm Holz sind. Habe dann den Abstand vergrößert, ohne Erfolg.
Aber ich glaube ich habe einen Störer im Gehäuse und habe schwer den Lautsprecher im Verdacht. Außerhalb des Gehäuses mit den gleichen Parametern (Leser<->5mm Holz<->Karte) funktioniert alles bestens. Die Reichweite ist auch wesentlich besser. Ich habe auch schon den Neopixel abgeklemmt und das Lolin D32 Pro Träger Board aus dem Gehäuse genommen, ohne Erfolg. Da bleibt eigentlich nur der Lautsprecher übrig :D. Dieser stammt aus einem alten Lautsprecher-Projekt und hat einen etwas dickeren Magneten.
Interessant, dass hier der RC522 weniger störanfällig ist.
Na ich weiß nicht, ob man das so sagen kann. Für diesen ist das Feature bisher nicht implementiert (,weil dessen Programmierung so schrecklich ist).
@Harry Bist bei der Fehlersuche schon weitergekommen?
Ich für meinen Teil habe auf jeden Fall die Erfahrung gemacht, dass die Reichweite bei RFID deutlich nachlässt, wenn viel „metallischer Kram“ in der Nähe ist. Also im ESPuino meiner Tochter geht es relativ eng zu und da hatte ich mit dem RC522 doch deutliche Probleme. Mit dem PN5180 hatte ich hier keine Probleme.
Das hier angesprochene Feature habe ich dort allerdings auch noch nicht getestet.
Ja bin ich und ich habe das Gleiche festgestellt, was du beschrieben hast 
Bei meinem Gehäusedesign geht es auch eng zu und der RFID Leser befindet sich mittig unter dem Neopixelring. Der Ring beeinflusst den PN5180 so stark, dass die Reichweite komplett einbricht und ich das beschriebene Verhalten habe. Der RC522 lässt sich etwas weniger vom Neopixel stören. Da habe ich lustigerweise eine bessere Reichweite, aber diese ist auch nicht zufriedenstellend. Wahrscheinlich werde ich den PN5180 erstmal provisorisch an eine andere Stelle im Gehäuse packen und mich mittelfristig an ein neues Gehäuse wagen.
Hier noch was zu Problemen beim PN5180: RC522: Erkennung wann Karte aufliegt und wann nicht - #23 von tueddy
Ich schreibe jetzt einfach mal hier rein anstatt ein neues Thema aufzumachen.
Bei mir tritt das Problem auf, dass der ESPuino, wenn er nicht von einer LPCD Karte aufgeweckt wird und direkt wieder schlafen geht, sofort wieder aufwacht und in einer Schleife endet. Die Schleife kann nur beendet werden indem eine passende LPCD Karte aufgelegt wird, nicht aber durch ein aufwecken per Button.
Aufwecken mit LPCD Karte funktioniert normal, er bleibt ja dann auch an.
Den Beiträgen hier im Forum zufolge sollte ja kein pullup oder pulldown nötig sein. Auch software pinMode pullup/pulldown hilft nichts.
Hat jemand eine Idee, was hier das Problem sein könnte?
Hmm, muss ich mir dann wohl noch mal anschauen. @tueddy hast du das Problem auch?
Auf jeden Fall ein ganz schön aufwändiges Feature muss ich sagen (von der Zeit, die ich da schon investiert habe) für gar nicht mal sooo viel Ertrag 
.
Es gibt ja zwei Möglichkeiten den ESPuino aufzuwecken, über den Button (EXT0) oder über Auflegen einer Karte (IRQ-Pin EXT1). Beim Start wird ja in der Konsole der Aufwachgrund ausgegeben. Ist das wirklich der Button? Ist der Button Pin kompatibel mit EXT0? Und PN5180 IRQ-Pin kompatibel mit EXT1?
So eine Schleife habe ich nicht, allerdings wacht mein ESP alle 2 Sekunden auf, prüft auf Karte und legt sich wieder schlafen. Das scheint mit dem Umdrehen der Logik auf dem IRQ Pin zusammenzuhängen, muss ich noch genauer anschauen.
Nur als Hinweis an den Rest: Normalerweise ist es so, dass der PN5180 den GPIO auf LOW zieht und im Falle eines Interrupts dann auf HIGH. Das hat sich für den Anschluss an einen Pin des Port-Expanders jedoch als unpraktisch erwiesen. Durch Schreiben in ein spezielles Register kann man dieses Verhalten jedoch umkehren:
Also für mich sieht es schon so aus wie von mir beschrieben. IRQ hängt an 33 und funktioniert eben auch für ISO-14443 tags. EDIT: Der ESPuino stürzt immer ab, auch wenn nur ein 14443-Tag aufgelegt wird. Der wird danach aber sofort gelesen.
Nur eben wenn eine ISO-15693 aufgelegt wird hängt er sich auf. Mir ist eben auch aufgefallen dass das anschließende lesen eines 14443-Tags den Fehler nicht behebt, sondern zu einem Absturz und Neustart führt.
Vielleicht könnt ihr ja aus dem Log den ich angehängt habe noch etwas rauslesen.
espuino_log.txt (6,2 KB)
Kannst Du das einmal compilieren mit
monitor_filters = esp32_exception_decoder
Also in der Platform.ini:
[env:ttgo_t8]
;https://docs.platformio.org/en/latest/boards/espressif32/esp-wrover-kit.html
board = esp-wrover-kit
;board_build.partitions = huge_app.csv
board_build.partitions = custom_4mb_noota.csv
build_flags = -DHAL=5
-DBOARD_HAS_PSRAM
-mfix-esp32-psram-cache-issue
-DLOG_BUFFER_SIZE=10240
monitor_filters = esp32_exception_decoder
Dann bekommst Du den Aufrufstack. Evt. kann man dann mehr sehen.
Cool, das wusste ich gar nicht. Hab das immer umständlich via Arduino IDE gemacht.
Der Fehler wird irgendwo in freertos geworfen in diesem Funktionsaufruf…
xQueueSend(gRfidCardQueue, cardIdString.c_str(), 0); // If PAUSE_WHEN_RFID_REMOVED isn't active, every card-apply leads to new playlist-generation
Backtrace: 0x40096594:0x3ffbb1d0 0x4009680d:0x3ffbb1f0 0x40097b56:0x3ffbb210 0x400d705d:0x3ffbb250 0x4009825e:0x3ffbb2a0
#0 0x40096594:0x3ffbb1d0 in invoke_abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
#1 0x4009680d:0x3ffbb1f0 in abort at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/esp32/panic.c:715
#2 0x40097b56:0x3ffbb210 in xQueueGenericSend at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/queue.c:2520
#3 0x400d705d:0x3ffbb250 in Rfid_Task(void*) at src/RfidPn5180.cpp:49
#4 0x4009825e:0x3ffbb2a0 in vPortTaskWrapper at /home/runner/work/esp32-arduino-lib-builder/esp32-arduino-lib-builder/esp-idf/components/freertos/port.c:355
Update: gRfidCardQueue ist an dieser Stelle null, wurde vorher aber initialisiert…
Nachdem ich mir das jetzt eine Weile angeschaut habe, bin ich zu dem Schluss gekommen, dass es eine race condition zwischen Queues_Init(void) und lesen der RFID Karten gibt. Bei mir werden konsistent die RFID Karten schneller initialisiert und gelesen als die Queues erstellt werden können.
Warum das nur bei mir ist kann ich nicht verstehen.
Diese Theorie kann ich bestätigen, indem ich beim drücken des Reset-Knopfs (also sauberer Boot, kein Deepsleep) einen Tag auflege. Dann stürzt der ESPuino ebenso ab (aber nur 14443).
Also: Den Crash habe ich behoben. Das Problem mit der Aufwachschleife besteht weiterhin.
Kannst mal kurz runterschreiben, wie du das gefixt hast? Denke das sollte ich schon aufnehmen.
Ich kann den Crash hier nicht nachstellen, aufgelegte 14443 Karte + Hard-Reset → Musik wird sofort abgespielt…
Klar, einfach Queues_Init(); in der setup() weiter nach oben setzen. Ich habe es direkt nach Log_Init() geschrieben. Besser wäre vielleicht in Rfid_Init() zu warten bis die queue nicht null ist, aber mir reichte der Workaround.
Ja, ich finde auch mysteriös, dass das nur bei mir auftritt… Vielleicht liegt das am WROVER-E den mein Board hat?
Hallo,
ich habe das Verhalten das mein PN5180 „zu empfindlich“ ist…
D.h. wackeln an der Box/Hand vor den Leser halten lässt den ESP aufwecken, der dann bis zum eingestellten Sleep zeit aktiv bleibt… irgendwie doof…
Kann man da was einstellen?
btw ich hatte mal die LPCD aktiv, hab das aber wieder rausgenommen, scheint aber trotzdem weiterhin aktiv zu sein…
Aufbau: Lolin D32 pro mit SD_MMC, PN5180, max. fünf Buttons und Port-Expander (SMD)
@JHB hast Du ein Metall-Implantat in Deiner Hand? 
Der PN5180 misst sich im LPCD Mode selbst ein und wacht dann nur bei Änderungen im RF-Feld auf.
Verrwendest Du den aktuellen Master? Da wurden für LPCD noch kleinere Fehlerkorrekturen gemacht.
Wenn Du LPCD deaktiveren möchtest geht das ja in den Settings.h mit PN5180_ENABLE_LPCD.
Evt. hilft dann ein Clean + Build. Danach sollte das Feature deaktiviert sein.