📗 Was ist LPCD und wie funktioniert es?

Einleitung

Wird der RFID-Reader PN5180 verwendet, so kann über settings.h das Feature PN5180_ENABLE_LPCD aktiviert werden. Zwingend notwendig ist dafür, dass die Firmware-Version des PN5180 mindestens auf dem Stand 4.0 ist (ESPuino zeigt die Version an). Üblicherweise ist sie nach dem Kauf älter, so dass man ein Update durchführen muss. Wie man FW4.0 auf den PN5180 kriegt steht hier und hier. Spoiler: Ist schon ein bisschen Arbeit :slight_smile: Falls Probleme auftreten: LPCD funktioniert nicht.
Hinweis: ESPuino zeigt beim Startvorgang die FW-Version des PN5180 an. Hier kannst du also sehen, ob bereits 4.0 aufgespielt ist.

Wie funktioniert LPCD?

Um im Deepsleep des ESP32 Strom zu sparen, wird der RFID-Reader normalerweise spannungslos geschaltet. Dies darf hier natürlich nicht passieren. Daher bieten Complete und mini4L die Möglichkeit, LPCD auf der Rückseite per Lötjumper zu aktivieren. Ist es aktiviert, so wird der RFID-Reader von der Spannungsabschaltung ausgenommen.
Hinweis: Die Aktivierung von LPCD sorgt für einen leicht erhöhten Stromverbrauch im Deepsleep.

Normalerweise wird der ESP32 mit einem Tastendruck aufgeweckt, so dass ESPuino startet. Das funktioniert so, dass der Spannungslevel an einem Tasteneingang „in Ruhe“ 3.3 V ist und das Drücken eines Tasters gewissermaßen ein „Kurzschluss“ nach GND ist, so dass sich das Spannungslevel auf 0 V ändert. Das wird entweder direkt vom ESP32 registriert (wenn der Taster direkt an einem GPIO hängt) oder über einen Port-Expander, der seinerseits an einem GPIO des ESP32 hängt und dort einen Interrupt wirft. Ein Interrupt ist im Prinzip nichts Anderes als ein Tastendruck: Das Spannungslevel wird kurzzeitig auf 0 V gezogen.
Mittels LPCD kann das Ganze derart erweitert werden, dass das Aufwecken auch über das Auflegen einer Karte funktioniert. Der PN5180 hat hierfür einen IRQ-Pin, den man direkt an einen GPIO des ESP32 hängt. Der PN5180 wirft im Normalbetrieb zahlreiche Interrupts (etwa alle 0,3 s), diese werden jedoch nicht ausgewertet.

Was passiert nach dem Aufwecken per LPCD?

Das hängt davon ab, ob der IRQ-Pin des PN5180 an einem Pin des Port-Expanders hängt oder direkt am ESP32.

Für LPCD wird ein separater/zusätzlicher GPIO verwendet, für den ESPuino eine eigene Aufweck-Routine besitzt. D.h. ESPuino kann dieses Event von einem normalen Tastendruck unterscheiden. Es wird nun geprüft, ob die Kartenerkennung ein Fehlalarm war oder ob die Karte noch vorhanden ist. Im Falle eines Fehlalarms geht der ESP32 sofort wieder schlafen. Man sieht den Vorgang auf dem Neopixel auch nicht: Die periphere Hardware, die für den Deepsleep spannungslos geschaltet wurde, bleibt spannungslos. Vorteil: Erweiterte Erkennung, die mit „Fehlalarm“ besser umgeht. Nachteil: Ein zusätzlicher GPIO notwendig und es kann nicht jeder beliebige verwendet werden, da dieser RTC-fähig sein muss. Das ist nur bei Folgenden der Fall: 0, 4, 12, 13, 14, 15, 25, 26, 27, 32, 33, 34, 35, 36, 39.

Was ist nötig, um LPCD an’s Laufen zu bringen?

Die nachfolgende Beschreibung setzt (zumindest teilweise) voraus, dass eine Complete oder eine mini-Platine verwendet wird.

  • Firmware des PN5180 muss >= 4.1 (siehe oben).
  • In settings.h muss PN5180_ENABLE_LPCD aktiviert werden.
  • In z.B. settings-lolin_d32_pro_sdmmc_pe.h bzw. settings-complete.h muss ggf. RFID_IRQ angepasst werden. Im Normalfall jedoch nicht, da alles passend eingestellt sein sollte (GPIO 32).
  • Für mini4L und Complete müssen auf der Rückseite der Platine Lötjumper gesetzt werden. Welche genau das sind, ist auf den zuvor verlinkten Seiten dokumentiert.

Kann LPCD auch mit dem RFID-Reader RC522 verwendet werden?

Nein, das geht nicht.

Vielen Dank dir für diese Zusammenfassung!
Zwei kleine Anmerkungen:

Danke @Joe91, ich habe die Punkte aufgenommen.

Warum wird gefühlt empfohlen LPCD nicht zu verwenden? Ist doch ein tolles feature.

Meine Tochter hat das mit vorher aufwecken noch nicht gecheckt.

Es wurde mehrfach berichtet, dass es nicht ordentlich funktioniert - mit dem Ergebnis, dass es von diesen Leuten deaktiviert wurde. Ob’s überhaupt jmd. produktiv benutzt weiß ich nicht. Inzwischen spare ich es mir auch, nach Feedback zu fragen - weil es kommt üblicherweise keines.

Gleichzeitig kümmert sich im Sinne eines Maintainers niemand drum (testen und ggf. fixen). Und da auch niemand aus der breiten Userbase mehr (war früher anders) groß Lust hat, mal ne kleine Extrarunde zu drehen, um entwickelte Sachen zu testen (aktuelles Beispiel: Bluetooth-Reiter in der Web UI), wird sich daran wohl auch nix ändern.

Und insofern ist es aus meiner Sicht in einem unklaren/schlechten Zustand. Daher rate ich von der Benutzung ab. Bleibt das weiterhin dauerhaft so, dann habe ich ehrlich gesagt keine Scheu, das auszubauen.

Kurze Frage zur Reader Firmware version.

Wird jetzt >= 4.0 oder 4.1 benötigt? Im Text am Anfang meinst du mindestens 4.0, in der übersicht am Ende aber >=4.1 :smiley:

An dieser Unstimmigkeit hat sich Claude auch schon gestört. Ich meine, dass es mal 4.1 hieß. Habe das KIchen dann mal in die Lib schauen lassen und da kam raus, dass es ab 4.0 gehen müsste. Werden wir nur erfahren, wenn es wer ausprobiert.

Das hat NXP selbst vermatscht:
in den Releasenotes zu 4.1 schreibt NXP nix zu LPCD.
Für 4.1 nennt NXP als Änderungen gegenüber 4.0 insbesondere verbessertes FeliCa-EMD-Handling sowie die Behebung eines DPC-Corner-Cases (nix zu LPCD)
Die führen in der Version 4.1 „Low Power Card detection“ ausdrücklich als unterstützte Funktion auf. In der Version 4.0 jedoch nicht. Aber die Version 4.0 wird benannt mit „No functional difference to Firmware Version 3.A“.
Und bei 3.A steht als unterstützt:

  1. LPCD_REFERENCE_VALUE im EEPROM
  2. Defaultwert 8
  3. LPCD Selection
  4. Auto Calibration
  5. Self Calibration

:exploding_head:

Da bin ich auch beim umbauen der Reader-Anzeige gestolpert und habe mich auf stumpfes anzeigen der FW beschränkt

Ok mein Reader ist noch auf 4.0.

Am Montag nehme ich meine Box fix mit zur Arbeit und nehme die HW Modifikationen vor und teste es dann mal und geb Bescheid.

Je nach dem welche Hardware du hast. Das Update geht aber auch recht fix

Oder

Ich habe es jetzt einfach mal eingeschaltet.

Hardwareseitig funktioniert alles. Aaaaber…

N [65052] Gehe jetzt in Deep Sleep!
N [65052] shutdown webserver..
N [65053] shutdown audioplayer..
N [65082] shutdown rfid-reader..
N [65083] shutdown PN5180..
D [65375] PN5180 firmware version=4.1
N [65375] prepare low power card detection...
D [65514] PN5180 IRQ PIN (32) state: 0
N [65523] switch to low power card detection: success
N [65523] shutdown amplifier..
N [65523] Lautsprecher ausgeschaltet
N [65524] shutdown LED..
N [65536] shutdown SD card (SD_MMC)..
N [65742] deep-sleep, good night.......
E (532) esp_core_dump_flash: No core dump partition found!
E (532) esp_core_dump_flash: No core dump partition found!
D [113] RFID: Checking PN5180...
D [1185] RFID: PN5180 firmware read ok=1 version=0.0
D [1185] RFID: PN5180 not present or unreadable
I [1185] RFID: Auto-detecting reader type...
D [1196] RFID: Checking PN5180...
D [2268] RFID: PN5180 firmware read ok=1 version=0.0
D [2268] RFID: PN5180 not present or unreadable
D [2268] RFID: Checking MFRC522 (SPI)...
D [2329] RFID: MFRC522 (SPI) version=0x00
D [2329] RFID: Checking MFRC522 (I2C)...
D [2930] RFID: MFRC522 (I2C) version=0xFF
E [2930] RFID: No reader detected
E [2930] RFID: Failed to auto-detect reader type, using default
I [2942] RFID: Using reader type: 3 (PN5180)
*** FATAL: Reading more than 508 bytes is not supported!
I [7658] Kartenerkennung via 'low power' erfolgreich durchgeführt
E [7658] ESP32 wurde vom Kartenleser aus dem Deepsleep aufgeweckt. Allerdings wurde keine bekannte Karte gefunden. Gehe zurück in den Deepsleep...

Durch die Auto-Erkennung dauert der Startvorgang viel zu lange, wenn man die Karte nur tappt. Das sind Sekunden die hier vergehen.

Das doofe ist, der Reader steht in den settings auf PN5180. Trotzdem passiert ein auto-detect.

Der clue ist vermutlich
D [113] RFID: Checking PN5180...
D [1185] RFID: PN5180 firmware read ok=1 version=0.0
D [1185] RFID: PN5180 not present or unreadable

PS: Firmware version ist 4.1. Aber der eprom read dort im code failed. Ich bastel ein bisschen…
PPS: All das passirt vor RfidPn5180_WakeupHandling. ich denke das ist ein bug…

D [65375] PN5180 firmware version=4.1

Hier wird die Version aber gefunden.
Die Web-Gui zeigt dann aber auch nicht die Firmware an oder?

Hast du mal deine Kabel und Stecker geprüft?

Ich bin gestern noch vom Hölzchen zum Stöckchen gekommen. Grundproblem ist wohl dass überhaupt Rfid_WakeupHandling() RfidConfig_Init() aufruft. Das kann nur schief gehen und tut es dann auch. Und die timeouts sind noch zu lange gesetzt..
RfidPn5180_WakeupHandling ist eigentlich device specific, da muss eh kein auto-probe pasieren.

Ich bin dann in einer Wahnwitzigen AI troubleshooting session gelanded die ziemlich eskaliert ist. Mittlerweile ist der code pfad entweder schnell (anstatt sekunden) oder failed ganz. Leider intermittend.

Ist das Kabel sensibel? Es ist recht lang so dass die Gehäusehälten offen nebeneinander liegen können. Sagen wir ca 18cm.

Also grundsätzlich ist das alles schon gelaufen. Man muss natürlich halt aber sehen, dass sich nicht nur ESPuino weiterentwickelt, sondern wir ab und zu halt auch Libs aktualisieren (neu pinnen). Und aber vor allem passiert ja auch viel im Hintergrund - also im IDF-Core bzw. ESP32-Arduino.

Vor dem Hintergrund ist es halt wichtig, dass man sich das immer mal wieder anschaut und re-validiert. Das Feature hat tueddy damals implementiert und auch betreut, der scheint inzwischen aber das Interesse an ESPuino verloren zu haben. Was ja sein gutes Recht ist, aber wenn sich um das Thema niemand mehr kümmert, dann baue ich es lieber aus, bevor es schlecht oder gar nicht funktioniert.

Mit KI hat man es da inzwischen zum Glück deutlich einfacher. Wobei das noch nicht automatisch heißt, dass das in der Praxis einen nach vorne bringt. Beim Feature, dass man die Karte auf dem ESPuino liegen lässt und das Wegnehmen zu PAUSE führt, haben wir dieses Jahr viel umgebaut und ich hatte in Tests auch den Eindruck, dass das trägt. Final muss man aber doch sehen, dass die Umgebungsbedingungen (ESPuino-Gehäuse) so dermaßen heterogen sind, dass erfolgreiches Testen bei Person A noch nix über Person B aussagt.

On top ist auch unklar, wie unterschiedlich die PN5180 sind. Am liebsten hätte ich die ja durch Fertigung bei JLCPCB unter eigener Kontrolle, zumal ich dann auch ne Buchse dranmachen könnte, so dass man nicht mehr löten muss. Aber das dafür notwendige Antennendesign übersteigt einfach meine Kenntnisse. Weiß nicht, ob ich da mal Expertise einkaufen müsste.

Und aktuell ist es gar so, dass dort, wo ich die PN5180 einkaufe, relativ wenige Reader in Stock sind. Ich hatte schon andere Händler probiert, aber da gab’s viel „Ausschuss“.

So ich hab jetzt mal die Lötbrücken gesetzt mit Reader Version 4.0 und im Webinterface den Haken gesetzt.

Ein wake up mit einer Karte ist NICHT möglich.

Also wohl wirkliche =>4.1

Das ist ja schon mal eine gute Info,
Falls du den reader auf 4.1 heißt, dann gib mal bitte eine Rückmeldung ob es da läuft. Dann könnte man die Doku noch gerade ziehen

Ich musste leider abbrechen. Ich habe aus Versehen den Vibe-Troubleshooted git worktree verloren. Und am Ende hat es eh nicht ausreichend gut funktioniert.

Am Ende, nach viel optimieren, war immer noch eine hohe Chance dass der Reader immer noch sekunden brauchte um ready zu sein. 80% war der reader sofort da, aber wenn nicht daurte es immer noch inaxeptabel lang bis die karte gelesen werden konnte.

Leider hatte ich die letzten Tage wenig Zeit. Und Montag bekommt meine Tochter den Player geschenkt, dann wird Zugang erst mal problematisch.

Ich habe die Lötbrücken erst mal zurück gesetzt. Ich weis noch nicht wie ich weiter mache, vielleicht mit neuer Hardware… Ich hatte am Ende das Gefühl das Problem ist Hardware. Die langen Kabel, power spikes. Dann mit mehr debug code und eventuell einem logic analyzer.

Clanker hat den Fiebertraum zusammengefasst: ESPuino PN5180 LPCD wakeup troubleshooting: findings, rebuild notes, and the espduino-rfid skill · GitHub

PS: Ich habe definitiv fw 4.1

Ich habe das letztens auch mal debuggd und schlussendlich aufgegeben.

Ausgangssituation war, dass ich eine 4 Jahre espuino box habe auf welcher LPCD mit der neusten Firmware hervorragend funktioniert. Dann eine zweite Box gebaut mit der mini4L Platine und es funktioniert nicht.

Soweit ich das beurteilen kann gibt es mit der mini4L (auch mit der complete insofern ich richtig geschaut habe) 2 Probleme:

  1. Die Platine wacht immer sofort auf wenn LPCD aktiviert ist. Ich habe sowohl den card reader der funktionierenden Box dran gehängt als auch den neuen. Solange alles auf dem Tisch ausgebreitet ist, wacht sie nur alle halbe Stunde mal auf, wenn in der Box verbaut quasi direkt nach dem suspend. Der Unterschied hierbei ist, dass bei der alten Platine das noch über den Port Expander ging, während bei den neuen Platinen das direkt am ESP angeschlossen ist. Offensichtlich hatte sich der Port Expander an der Stelle als nützlich erweisen was das Filtern von Störsignalen betrifft und die alte box hat somit quasi keine false positive wake ups, die neuen Platinen permanent. Ich habe bereits versucht Kondensatoren dazwischen zu löten um das Signal zu glätten, aber mangels tieferer Erfahrung mit elektronik, ohne Erfolg und habe dann aufgegeben.
  2. Als zweites Problem kommt noch hinzu, dass die Software da böse mitspielt. Eigentlich sollte die Software ja bei den neuen Platinen erkennen können ob es ein wake-up der LPCD Interrupts war oder nicht (dies ist der Unterschied zwischen Port Expander vs direkt am ESP angeschlossen). Jetzt ist es aber so, dass durch diese false positive wake ups, jedesmal dieser code getriggert wird, welcher dann direkt nachschaut ob im Speicher des Readers noch die Kartennummer drin steht und falls nicht, direkt wieder schlafen geht. Dies hat in Kombination mit den false positive wake-ups den Effekt, dass die Box in ner Endlosschleife aus suspend und wake-up landet und selbst wenn dann wirklich eine Karte drauf liegt, diese in 90% der Fälle nicht erkannt wird weil das System damit beschäftigt ist noch den letzten false positive zu verarbeiten. Damit wird die Box durch das aktivieren des LPCD praktisch komplett unbrauchbar.

Am Ende hab ich meinem Kind dann halt beigebracht, dass die neue Box kein LPCD mehr kann, das war leichter.

Gut, wenn man den Zustand wiederherstellen möchte, kann man natürlich den IRQ-Pin des Readers auch auf den extConn1-Konnektor legen und dort auf einen PE-Anschluss legen. Muss dann allerdings ne Custom-Firmware bauen.

Genau, das ist der entscheidende Vorteil.

Gut, ich denke das könnte man schon analysieren und sich das mal anschauen.

Jap. Das Hauptproblem warum ich aufgegeben habe waren allerdings die false positives beim wake-up, welche glaub ich einen Hardware fix benötigen. Direkt auf einen Pin des port expanders legen und die Firmware dann quasi wieder auf den alten Mechanismus zu konfigurieren wäre sicherlich eine Variante, aber hatte sich nicht nach dem richtigen Weg angefühlt und ich hatte dann die Motivation dafür nicht.