Ich glaube Claude mal auf diesen Evergreen angesetzt. Ausgangslage war, dass 700 ms Debounce nicht gereicht hat, dass das Feature stabil läuft. Es waren mind. 800 ms notwendig. Ich habe mal folgenden Change eingebracht:
dev ← fix-pn5180-unnecessary-reset
offen 09:32PM - 11 Jul 26 UTC
Root-caused via targeted timing instrumentation (measuring vTaskDelay overrun vs… . per-state processing time) that a card sitting continuously on the reader was periodically mistaken for removed and reapplied, even at zero read distance. Two contributing issues in RfidPn5180.cpp:
- The state machine routed back through a full PN5180 hardware reset (RST-pin toggle + reboot wait) on every ~20ms poll while a tag was being tracked - both via the ACTIVE-state bypass and, more importantly, via the "same card as last poll" fast path, which forced a reset+continue on every single successful re-read of an already- known tag (the dominant case while a tag sits on the reader). Both paths now poll again directly (READCARD/GETINVENTORY) without resetting the chip in between.
- issueISO15693Command() (PN5180-Library) never clears the chip's IRQ status register before checking for a fresh response, so a stale RX-IRQ flag left over from an earlier successful read could look like a new response arrived. Added an explicit clearIRQStatus() before each ISO15693 poll.
Neither fix alone eliminated the worst-case ~700-800ms poll stalls observed on hardware; further instrumentation traced those to two hardcoded timeouts in the (forked, git-pinned) PN5180-Library itself - setRF_on()/setRF_off()'s RF-field-ready wait (500ms) and activateTypeA()'s PN5180_TS_WaitTransmit wait (200ms), neither of which uses the already-configurable commandTimeout member. Repinned platformio.ini to a patched fork (biologist79/PN5180-Library) with both lowered to 100ms, which cut the worst observed stalls from ~780ms to ~260ms on the same hardware.
The remaining debounce needed to mask occasional multi-poll dropouts is now a configurable NVS-backed setting (General -> RFID-Reader -> PN5180 Debounce, default 500ms, requires a restart to apply) instead of a hardcoded 1000/400ms split between ISO14443/ISO15693.
Vielleicht testen das mal ein paar Leute, die das Feature benutzen. Die Debounce-Zeit ist jetzt zusätzlich über das Webinterface zwischen 0 und 2 s konfigurierbar. Es wurde eine Änderung an der Lib vorgenommen. Dafür habe ich kurzerhand die PN5180-Lib geforkt.
Also testet das mal ein bisschen, ob es das Verhalten verbessert. Wenn nicht, dann rolle ich es halt wieder zurück.
Es kam jetzt gestern noch ein zweiter Fix hinterher:
dev ← sadilek:fix/pn5180-inwindow-reset
offen 06:15PM - 23 Jul 26 UTC
**Problem** (follow-up to #428): with a card resting on the reader, playback sti… ll restarts (or pauses with `pauseIfRfidRemoved`) every few seconds to minutes. Serial-log instrumentation on a PN5180 + ESP32-D0WD-V3 ("complete" board, build 04f1cc1): stable phases are random (4.5–66 s), but removal→re-detect is always ~270–280 ms — a deterministic reset→rescan path, not RF recovery. Raising `pn5180Debounce` to 1000 ms did not prevent removals; distance/tag-type variations had no effect.
**Root cause:** after a successful `readCardSerial()` the PICC is left SELECTed (ACTIVE). Per ISO-14443-3 an ACTIVE PICC answers neither REQA nor WUPA — and since #428 removed the per-poll reset (correctly!), nothing returns it to IDLE except an incidental field cycle inside `loadRFConfig`. So most polls at rest fail by design, and any unlucky streak longer than the debounce is declared a removal. The debounce masks the symptom but cannot fix the mechanism.
**Fix (two commits):**
1. `deterministic ISO-14443 re-read via WUPA + HLTA` — poll with **WUPA** (`activateTypeA(buf, 1)`, answered from IDLE *and* HALT) and park the card in **HALT** (`mifareHalt()`, currently unused in the library) after each successful read. Re-reads become deterministic; first detection (IDLE) is covered by WUPA as well.
2. `disambiguate a wedged reader from a removed card` — at the debounce boundary, instead of declaring removal immediately, run **one silent cross-protocol re-init sweep** with muted side effects: re-found → it was a chip wedge, heal silently (no removal, no re-apply, no pause); not found → declare removal (~0.8 s total). This also heals genuine PN5180 wedges — the chip can become unresponsive after corrupted responses (as described by tueddy in ATrappmann/PN5180-Library#48) and only recovers via reset.
**Results on hardware:** resting card: zero false removals/re-applies over extended tests (previously: median 15 s between incidents, n=59). Card placement: single apply. Card removal: pause after ~0.8 s. Instrumented DEBUG lines (`wedge/removal suspected` / `silent heal recovered` / `gave up`) make the behaviour observable in the serial log.
Happy to split the two commits into separate PRs if preferred. Intermediate attempts and their failure modes (e.g. why an extra `setupRF()` after the ISO-14443 reset breaks the fast path, and why healing after only ~150 ms of failed reads churns on normal sub-debounce dropout runs) are documented and I can share the full measurement logs.