nTag213 ISO 14443A Tag Erkennung funktioniert nicht

tom · 20. August 2025 um 13:39

Habe espuino vom DEV Branch gebaut, der verwendet

GitHub - tueddy/PN5180-Library: PN5180 library for Arduino ;v2.3.5

Mein Verständnis ist, dass eine PN5180ISO14443 instanz den TypA 14443-4 nTag213 mit einschließen sollte.

ISO 14443 Karten funktionieren.

nTag213 kann mit dem iPhone gelesen werden:

TagType: ISO 14443-4 Mifare
Serial number wird angezeigt
Karten sind beschreibbar

Hardware: board lolin_d32_pro_sdmmc_pe mit PN5180

PN5180 Firmware is 4.0

Power supply über USB Docking Station mit MacBook Air 30W PD Netzteil.
espuino reported 3.4V

Habe dann zusätzlichen debug output in der Erkennungsschliefe in RfidPn5180.cpp eingebaut.

Debug output – Keine Karte in Reichweite:

D [509127] *** Attempting to read ISO14443 card ***

D [509901] *** readCardSerial returned: -1 bytes ***

D [509901] *** No card detected or readCardSerial failed (returned -1) ***

D [509901] *** Timeout exceeded, clearing lastCardId ***

Debug output – nTag213 in Reichweite / aufgelegt.

[49305] *** Attempting to read ISO14443 card ***

D [49435] *** readCardSerial returned: 0 bytes ***

D [49435] *** No card detected or readCardSerial failed (returned 0) ***

D [49435] *** Timeout exceeded, clearing lastCardId ***

D [49613] *** Attempting to read ISO14443 card ***

D [49692] *** readCardSerial returned: -2 bytes ***

D [49692] *** No card detected or readCardSerial failed (returned -2) ***

D [49692] *** Timeout exceeded, clearing lastCardId ***

Es wird also was erkannt, wenn das nTag213 in der Nähe ist, aber mehr auch nicht.

Kann man mit espuino und PN5180 ISO 1443-4 Type A nTag213 erkennen?

Was müsste geändert werden, damit das geht?

tom · 23. August 2025 um 08:58

@tueddy könntest du mir bitte einen Tipp geben, ob ich da auf dem Holzweg bin oder ob das nTag213 einfach nur zu klein ist.

tom · 24. August 2025 um 15:58

habe diesen Beitrag gefunden. Also scheint die Größe der Antenne der limitierende Faktor bei nTag213 mit PN5180 zu sein? Das dem PN5180 beiliegende ISO14443 Tag ist nicht größer und wird gut erkannt. Die vorliegenden “Popel”-nTag213 haben 25mm Durchmesser und werden vom Smartphone auch mit Abstand gelesen.

Johannes · 24. August 2025 um 18:24

Also ich bin mir nicht 100% sicher, aber, ich meine, ntag213 haben eine ganz andere Lesefunktion und es kann sein das die Bibliothek dafür gar keine Funktion hat.

Johannes · 24. August 2025 um 18:26

Ich habe bei mir extra für den PN5180 eine neue Funktion zum lesen geschrieben.

tom · 24. August 2025 um 18:42

@Johannes das habe ich vermutet, dass da noch was fehlt, wobei es in der verwendeten lib calls bzgl. ISO14443A gibt.

Zeile 88: int8_t PN5180ISO14443::activateTypeA(uint8_t *buffer, uint8_t kind) {

die wird intern aufgerufen

aber weiter bin ich noch nicht eingestiegen. ich wollte als nächstes eine minimale Testumgebung bauen und dann weiter erproben.

würdest du die modifizierte Datei teilen ?

und wie ist es dann mit der Reichweite - ich habe hier 25mm nTag213, die mit Smartphone sehr gut funktioniern.

Johannes · 24. August 2025 um 18:58

Ja, genau die Funktion ist für ISO14443, aber die Speicherstruktur der Tags ist eine andere.

NTAG213s sind allerdings angenehm günstig .



bool NFCReader::readNtagData(uint32_t &number, uint8_t *uid) {

    uint8_t block6Data[8] = {0};
    char numStr[9] = {0}; // Platz für 8 Zeichen + Nullterminator

    //ntag213PageRead(6, block6Data);
    ntag213FastPageRead(block6Data); // das klappt beides
    
    // Daten in String zusammensetzen.
    memcpy(numStr, block6Data, 8);     
    numStr[8] = '\0';                   // Nullterminator

    // String in Zahl konvertieren
    char *endptr;
    number = strtoul(numStr, &endptr, 10); // Basis 10

    Serial.print(F("Gelesene Nummer: "));
    Serial.println(number);

    if(number == 0) {
        return false;
    } 

    if (*endptr != '\0') { // Prüfe, ob die Konvertierung erfolgreich war
        Serial.println(F("Fehler bei der Konvertierung der gelesenen Daten."));
        return false;
    }

    return true;
}

uint8_t NFCReader::ntag213FastPageRead(uint8_t *buffer) { // man könnte die Funktion noch nach 10.3 FAST_READ im Datenblatt umbauen - damit kann man von bis Sheets lesen
    uint8_t response[8]; // Puffer für die 4 Bytes Antwortdaten + 2 Byte CRC (Nicht benötigt, wenn readData die Bytes direkt verarbeitet)
    uint8_t result;
    uint8_t startAddr = 0x06;
    uint8_t endAddr = 0x07;
    // benötigt von bis Seiten-Adressen
    // befehl ist cmd 3Ah, startAddress, endAddress, CRC
     

    uint8_t cmd[] = { 0x3A, startAddr, endAddr };
    bool sended = _nfc.sendData(cmd, sizeof(cmd), 0x00); 
    // Der Buffer ist schon quatsch Result: 1 Buffer: FF FF FF FF FF FF FF FF

    result = _nfc.readData(8, buffer);  

    Serial.print("Result: ");
    Serial.println(result);
    Serial.print("Buffer: ");
    for (int i = 0; i < 8; i++)
    {
        Serial.print(buffer[i], HEX);
        Serial.print(" ");
    }
    Serial.println();

    if (!result) {  
        return 0xFF; 
    }

    return 0x0A;
}

Ich garantiere für nix :D. Das sind nur die wichtigsten Ausschnitte. Ist schon ein paar Monate her, dass ich das programmiert habe und ich bin kein professioneller Coder. Es ist dafür gebaut nicht den kompletten Tag zu lesen, sondern nur die ersten 8? Zeichen.

Johannes · 24. August 2025 um 19:03

Ich merke keinen wirklichen Unterschied in der Reichweite. Da macht die Qualität des PN5180 mehr aus.

tom · 24. August 2025 um 19:22

Ja, genau und schreib/lesbar mit smartphone. und als transperaten Tags wunderbar in Objekte zu integrieren…

Vielen Dank. Das sind ja super gute Neuigkeiten.

Wo kommt der code rein in die lib oder in die RfidPn5180.cpp ? Wer ruft das auf?

könntest du bitte die erweiterten Dateien komplett teilen? - ich kenne mich mit dem RFID Zeugs noch nicht aus und das Einbauen der paar LOGs oben hat (für mich) schon gedauert.

ich brauche auch erstmal einen zweiten PN5180, da der Würfel schon in Verwendung ist… ESPs habe ich noch da.
gerne PN, wer noch einen PN5180 erübrigen kann (China dauert ca 2Wochen).

Johannes · 24. August 2025 um 19:55

Ja, ich würde dir wirklich gerne alles schicken, allerdings ist der Code außerhalb der Bibliothek und auch eigentlich nicht für den Espuino gedacht. Man müsste das alles nochmal vernünftig schreiben. Der Code oben ist voll von veralteten Kommentaren und sogar einem ziemlich peinlichen Rechtschreibfehler: „sended“. Ich verwende auch viel zu viel Speicherplatz. Es ist eher als Orientierung, wie die Funktion zum Lesen funktioniert.

Man müsste die readcardserial-Funktion über SAK um eine Überprüfung des Tag-Typs erweitern und dann darauf basierend die korrekte Funktion aufrufen.

tom · 24. August 2025 um 20:04

@Johannes alles klar, damit komme ich bestimmt weiter. Was ist SAK ?
Nochmals vielen Dank.

von @biologist bekomme ich kurzfristig ein PN5180, dann es mit der min Umgebung mal losgehen. Die Woche bekommen wir Besuch aber etwas Zeit wird sich finden …

Und vielleicht hat ja @tueddy Interesse die lib für Tag21x für espuino zu erweitern?

Johannes · 24. August 2025 um 20:16

Klar, gerne. Ich freue mich, hier weiterhelfen zu können.

Das ist der Teil der empfangenen Daten in der readCardSerial welcher weitere Informationen über den Tag-Typ gibt.

Gibt einen netten Kommentar dazu im Code:

buffer : must be 10 byte array

* buffer[0-1] is ATQA

* buffer[2] is sak

* buffer[3..6] is 4 byte UID

* buffer[7..9] is remaining 3 bytes of UID for 7 Byte UID tags

* kind : 0 we send REQA, 1 we send WUPA

Naja, ich war faul und mein Code prüft einfach, wie lang die UID ist. Ich meine, 4 ist mifare und 7 war ntag.

tueddy · 25. August 2025 um 20:03

Hab’ mal in meiner NFC-Kiste gekramt und einige NTAG-213 Tags hervorgekramt:

Diese werden mit den Apps NXP-NFC-Taginfo & NFC.cool auch als NTAG 213 angezeigt:

und im ESPuino mit einer ID erkannt:

N [31290] RFID-Karte erkannt: 04-f4-a9-8a 
N [31290] Card type: ISO-14443
I [31291] RFID-Karte empfangen: 004244169138
E [31294] RFID-Karte ist im NVS nicht hinterlegt.
D [60005] RSSI: -74 dBm

@tom Ich weiß jetzt nicht warum deine Tags nicht funktionieren.

tom · 25. August 2025 um 22:49

@tueddy Danke für das Testen.

Dann braucht es ja keine Änderungen. Sehr gut. Aber warum funktionieren meine nTag213 mit dem Smartphone und nicht mit dem espuino/PN5180? Ich habe jetzt noch andere mit 38mm bestellt, die teste ich dann … und ich bekomme noch einen weiteren PN5180. Dann sollte sich das hoffentlich aufklären.

tom · 26. August 2025 um 08:11

hier der Vergleich mit den Apps.

NXP NFC Info meckerte zunächst fehlenden NDEF Record. Nur NFC.cool konnte den Text schreiben. NFC Info sagte er kennt diese Karte nicht.

Danach Meckert NXP tool zwar noch immer - man kann den gespeicherten Text aber lesen.

Der Tag ist wohl ein China Clone … wäre interessant, woran sich die espuino/PN5180 Erkennungsroutine stört.

Verlangt ISO14443A NDEF?

Bin gespannt auf die 38mm Tags.

tueddy · 27. August 2025 um 12:32

Wir lesen immer nur die ID des Tags aus & beschreiben da nix. Deshalb ist es egal ob der Tag ein NDEF-Record enthält oder nicht.

Evt. liegt es am Typ, ich habe hier ISO14443-3 & deine sind ISO14443-4? Ich weiß allerdings nicht genau wo da der Unterschied ist.

tom · 27. August 2025 um 13:42

Die 38mm nTag213 sind gerade angekommen.

Das ist es… originale nTag2xx mit NXP Chip werden erkannt.

Vielen Dank @tueddy .

tom · 30. August 2025 um 22:10

@tueddy habe das Problem gefunden.

Gegenüberstellung der gelesenen Daten mit NFC.cool:

NFC-Tag	Smartrac NTAG213	Unbekanntes ISO14443A Tag
NDEF INHALT	Leerer NFC-Tag	Record 1 „Test mit unbekanntem Tag (nach Schreiben)“
TAG INFORMATIONEN.
Technologie	MiFare (ISO14443 Type A)	MiFare (ISO14443 Type A)
Typ	NTAG213	15014443 Type A Compatible Tag
ID	04: 3E: 83:8A: EB: 17:91	FF:OF: 10:21:E1:00:00
Hersteller	NXP Semiconductors (04)	Unknown Manufacturer (FF)
Speichergröße	180 bytes	not available
STATUS
NDEF-fähig	Ja	Ja
NDEF Formatiert	Nein	Ja ( nach Schreiben)
Status schreiben	Lesen/Schreiben	Lesen/Schreiben
Gesperrt	Nein	Nein
Passwortgeschützt	Ja	Nein
ZUSÄTZLICHE INFORMATIONEN
ATQA	0x4400	0x4400
SAK	Ox00	0x00
Vendor ID	Ox04	0xFF
Product Type	Ox04	Ox04
Product Sub Type	0x02	0x02
Major Version	Ox01	Ox01
Minor Version	Ox00	Ox00
Storage Size	OxOF	OxOF
Protocol Type	Ox03	Ox03
Total Pages	45 pages	45 pages
User Pages	41 pages	41 pages
Total Memory	180 bytes	180 bytes
Total Pages	45 pages	45 pages
User Pages	41 pages	41 pages
Total Memory	180 bytes	180 bytes
User Memory	144 bytes	144 bytes
Memory Layout	45 pages (180 bytes total, 144 bytes user)	45 pages (180 bytes total, 144 bytes user)
Get Version Response	00: 04:04:02:01:00:0F: 03	OF: FF: 04:02:01:00:0F: 03
MiFare Family	MIFARE Ultralight	Unknown
NTAG Specific Info	NTAG213: ATQA=0x4400, SAK=0x00, 45 pages (180 bytes total)	NTAG213: ATQA=0x4400, SAK=0x00, 45 pages (180 bytes total)

Die Karte wird als Unknown Manufacturer (FF) ausgewiesen, ansonsten gibt es keine Unterschiede und beide Karten sind Technologie MiFare (ISO14443 Type A) . Das hat mich ermutigt mit einer minimalen Testumgebung aus ESP32-C3 + PN5180 und dem Beispiel PN5180-ISO14443.ino aus der Lib weiter zu forschen.

In der Lib PN5180ISO144443.cpp Zeile ab 392:

	// first UID byte should not be 0x00 or 0xFF
	if ((response[3] == 0x00) || (response[3] == 0xFF)) 
	uidLength = 0;

wird eine UID, die mit der Hersteller-ID 0xFF beginnt, für ungültig erklärt.

Wenn ich nun unbekannte Hersteller erlaube (0xFF),

	// first UID byte should not be 0x00
	// explicitly allow unknown manufacturer ID 0xFF
	if (response[3] == 0x00)  
	uidLength = 0;

dann wird das Tag im Test erkannt.

...
TRANSCEIVE_STATE=0x04
card serial successful, UID=FF:F:1021E1003F

Vielleicht ist es möglich zu prüfen, ob die Nutzung der Hersteller-ID 0xFF in der Lib toleriert werden könnte. Mein Argument dafür: iOS und die verwendeteten NFC Apps lesen es ja auch. Es muss dem Anwender nur bewusst sein, dass die Adressen nicht notwendigerweise einzigartig sind.

trainbird · 31. August 2025 um 08:02

Wie realistisch ist ein ID-Clash denn? Falls das nennenswert ist, sollte man vllt eine Meldung anzeigen wenn so ein RFID gespeichert wird?

tom · 31. August 2025 um 11:22

naja, wahrscheinlich sehr gering. Zusätzliche Logik dafür würde ich nicht vorschlagen. Wichtig wäre ja nur, dass nicht die gleich Adresse mehrfach vergeben wird. ESPuino würde in diesem Fall den alten Tag überschreiben. Ob man das sofort merkt?

Die Nachbauten mit 0xFF scheinen sehr verbreitet; wahrscheinlich spart man sich eine Gebühr oder Lizenz.

Warten wir mal ab, was @tueddy dazu sagt