Hallo, ich bin auf der Suche nach einem bestimmten Lesegerät für Mifare DESFire EV1 Karten. Die Karten sind vorhanden und nur die UID soll gelesen werden. Mehr Informationen werden hier garnicht benötigt, da keine Sicherheitsbereiche damit aufgeschlossen werden und eine Manipulation ausgeschlossen wird. Leider finde ich keine wirklich geeigneten Lesegeräte oder Module dafür, die das wirklich können. Bei dem RFID-RC522 steht DESFire z.B. auch angegeben, die Karten werden aber garnicht erst erkannt wenn die im Feld sind. (Davon habe ich etliche hier liegen, oder geht das vielleicht doch und ich habe nur absolut falschen Code oder sonstiges? Ich glaube eigentlich nichtmehr dran..) Das Gerät kann gerne auch fertig mit USB Schnittstelle sein, es wird vermutlich direkt am Raspberry Pi angeschlossen, falls andere Kommunikation kann auch ein Arduino vorgeschaltet werden. Hat da schon jemand Erfahrungen? Wie gesagt nur lesen der UID, nichts anderes und keine Schreibfunktionen werden benötigt. Dementsprechend ist eine günstige Lösung bevorzugt. (Und nach Möglichkeit hier bestellbar, nicht in China ;))
Soweit ich weiß, senden die EV1 ihre UID nur ein einziges Mal, d.h. du weißt nicht, wie lange sie im Feld bleibt, wenn du nur die UID liest. Danach erst wieder wenn Du sie erneut ins Feld hälst. Der PN532 von NXP dürfte die aber lesen können. Oder Du hast fehlerhaften Code, das dürfte auch nicht ganz unwahrscheinlich sein.
PN532 Habe ich keinen hier, nur RC522. Dieser wird auf allen Seiten auch mit DESFire beworben, im Netz habe ich noch niemanden gefunden, der das auch geschafft hat. (S50 Karten z.B. funktionieren ohne Probleme..) Es ist nicht notwendig zu wissen wielange die Karte im Feld bleibt, damit soll man sich nur in einem System "einscannen", dafür muss die UID nur einmal gefangen werden. Den PN532 habe ich bislang auch gesehen, ich wollte nur ungerne 40$ in China zahlen für ein Produkt, was dann wieder nicht funktioniert und deshalb erst hier nachhören. Vielleicht hat ja noch jemand etwas anderes, oder sofort ein "fertiges" USB-Gerät in einem solchen Preisbereich.
Die UID einer EV1 geht auf jeden Fall mit dem RC522. Bis dahin ist das eine ganz normale Iso14443A Karte. Die UID ist bei denen die ich bisher in den Fingern hatte 7 Byte lang.
Aaaha, das hört sich doch interessant an. Ich dachte eben auch, dass es bis dahin total irrelevant ist, welcher Chip genutzt wird und nur die anderen Daten nicht auslesbar/veränderbar sind. Du sprichst davon, dass du sowas scheinbar öfter gemacht hast, hast du dazu zufällig noch Code? Du kannst mich gerne auch per PN kontaktieren und da sagen wo wir sprechen sollen. Laut Datasheet ist die UID 7 bytes, das ist richtig, mit dem Read oder Dump Sketch die bei den normalen Libs dabei sind passiert aufjedenfall garnichts. Also keine Ausgabe, auch nicht, dass es eine falsche Karte oder ähnliches ist und im Netz finde ich leider auch nichts genaueres dazu wo sowas schonmal einer ans laufen bekommen hat...
Ein fertiges RC522-Modul bekommt man z.B. über http://www.amazon.de/Neuftech-IC-Card-RFID-Module/dp/B00QFDRPZY/ref=sr_1_1?ie=UTF8&qid=1445623487&sr=8-1&keywords=rc522 (1. Treffer bei der Suche). Das Teil ist billig und lässt sich problemlos an einen Arduino und zur Not auch an einen Raspberry anschließen. Zusätzlich bietet NXP auf deren Website auch das Datenblatt und etliche Application Notes zu diesem Chip an mit denen man schnell was anfangen kann. Früher hat NXP auch eine Reader-Library angeboten - weiß allerdings nicht mehr, ob es die noch gibt. Der RC522 unterstüzt den ISO 14443 (A) Standard und kann damit nicht nur DESFire- sondern auch Mifare- und viele andere -Karten lesen. Da du nur die UID lesen willst, sollte das völlig ausreichend sein. Wenn man sich ein wenig mit Kryptographie beschäftigt kann man mit dem RC522 ebenfalls die gesamten Funktionen einer DESFire Karte nutzen (siehe Datenblatt des DESFires). Falls es noch mehr Fragen gibt, einfach bescheid sagen.. lg. Andi
Diese Module habe ich zu etlichen hier liegen, S50 Auslesung z.B. funktioniert ohne Probleme schon seit längerem. Nun ist ja z.B. der Unterschied, dass die Mifare DESFire EV1 Karte eine 7byte UID hat, die anderen nur 4byte. Verwendet habe ich zahlreiche verschiedene Librarys dazu, z.B. die von Miguel Balboa, allerdings bei den Desfire's alle ohne Erfolg. Ich bin doch nicht der 1. Mensch, der dazu Google bemüht, es gibt aber nirgends bislang einen Lösungsansatz oder eine Library dazu. Wie gesagt, bislang stehe ich auf dem Punkt, dass meine 4byte Karten funktionieren, die 7byte aber nicht. Sobald ich die Karte in den Leser halte passiert nichts, keinerlei Reaktion.
Zu den Libs die im Umlauf sind kann ich nichts sagen. Ich habe das in C auf einem Pic selber geschrieben. Bei NXP auf der Seite findet man Beispielcode für die Rc522 und Rc523. Ist zwar für ein 8031 Derivat, kann man aber als Basis gut verwenden
Ich habe die MFRC522 Seite von NXP jetzt schon 5x durchsucht und noch immer keinen Hinweis auf Beispiele gefunden, lediglich die ausführliche Dokumentation, welche leider meinen Wissensstand überschreitet. Ich hätte dir gerne ein PN oder Mail geschrieben, damit das hier nicht so hin und her ohne wirklichen Wissensstand ist, du bist aber leider als Gast hier unterwegs. Wenn du damit einverstanden bist, schreibe mir bitte kurz eine Mail an JumpY2k3@gmx.net. Danke dir
Ich benutze den PN532, da ich später noch die P2P-Funktion brauche, die der RC522 nicht hat. Auf jeden Fall funktioniert da das auslesen der UIDs auch von den DESFires (Studentenausweis, nPA). (Wie kommst Du eigentlich darauf, das Modul mit dem PN532 würde 40€ kosten? Ich habe 16€ bezahlt...) Hier sagt jemand, dass es mit dem RC522 nicht geht: http://arduino.stackexchange.com/questions/1329/how-do-i-use-rfid-rc522-with-an-arduino https://regnerischernachmittag.wordpress.com/2013/08/03/5euro-rfidnfc-modul-rc522-zum-auslesen-von-mifare-tags/ Wofür brauchst Du eigentlich in Deiner Umgebung die DESFire-Karten?
Ich habe mir eben auch ein PN532 Board gekauft, hat ~23€ gekostet. (Hatte zunächst das Seeedstudio im Auge, das war für 40 zu haben..) Die beiden Seiten habe ich natürlich schon gesehen, ebenfalls wie ca. 10 andere Seiten die sagen, dass es nicht funktioniert. Die arbeiten allerdings alle mit den Libs die so im Netz zu finden sind, damit funktioniert es ja nicht, habe ich ja auch festgestellt. Ich kann zwar dann das PN532 Board nutzen, wenn das bei mir funktioniert, wäre aber trotzdem fein, wenn man wüsste wie es mit den RC522 funktioniert.(Davon habe ich immerhin 10 Stück hier liegen..) Die Mifare DESFire EV1 Karten liegen mir für mein Projekt vor, heißt ich muss diese nutzen. Das sind eigentlich Karten mit Zutrittsberechtigung in verschiedene Bereiche, dass soll nur ein kleines seperates System sein, wo man sich mit der Karte "einbuchen" kann. Wie bereits erwähnt spielt dabei Sicherheit keine Rolle, es muss dementsprechend nur die UID erkannt werden.
OK - nur damit ich es auch richtig verstehe - du kannst die 4-Byte UID
einer Mifare-Karte (z.B. S50) lesen, nicht aber die 7-Byte UID einer
DESFire Karte, korrekt ?
In dem Fall würde ein schneller Blick in
o) den ISO 14443-Standard
o) den NFC-Standard (z.B. ECMA 340)
o) die vielen Application Notes von NXP zum Thema Kartenaktivierung
("PICC
Selection")
o) das DESFire Datenblatt selbst
helfen.
Kurze Zusammenfassung:
======================
1. Reader sendet "Request-A" (0x26)
2. Karte antwortet mit ATQA (2 Byte)
3. Reader sendet "AntiCollision" (0x93 0x20)
4. Karte antwortet mit 4-Byte UID + BCC ( = XOR über die 4-Byte UID)
5. Reader sendet "Select" (0x93 0x70 + UID + BCC)
6. Karte antwortet mit SAK (1 Byte, 1 Bit darin bestimmt ob die UID
komplett ist, was bei deiner DESFire Karte dann entsprechend gesetzt
ist; glaube es ist invertierte Logik "UID not Complete")
7. Wenn die UID nicht komplett ist, schickt der Reader ein weiteres
AntiColiision mit 0x95 0x20 danach gehts bei Schritt 4 weiter (Select
dann auch mit 0x95 0x70 ..).
8. Solltest du mal eine Karte mit 10-Byte haben, schickst du für
AntiCollision 0x97 0x20.
Der ganze Prozess wird komplizierter wenn sich mehr als 1 Karte im Feld
befindet, aber ich denke dass das bei deiner Anwendung nicht der Fall
ist.
Ansonsten kann ich hier gerne helfen.
Für den DESFire muss also irgendwo in deiner verwendeten Library eine
AntiCollision-Sequenz, d.h. irgendwas mit 0x93 0x20, geben.
Wenn es sich nur auf diese Sequenz beschränkt, kann die Library auch nur
4-Byte UIDs lesen. Aber das sollte sich dann problemlos erweitern lassen
(eben AntiCollision Level 2 mit 0x95 0x20).
Ein paar Application Notes für den Beginn:
o) AN10834 MIFARE ISO/IEC 14443 PICC Selection
o) AN10927 MIFARE and handling of UIDs
o) AN10833 MIFARE Type Identification Procedure
Sind alle von NXP.
lg.
Andi
Ja, hast du komplett richtig verstanden. Deine Erläuterung dazu ließt sich zumindest schonmal seh gut, ich hoffe dazu Informationen finden zu können die ich auch umsetzten kann. (Werde das hoffentlich heute in Angriff nehmen können) Falls du dich weiter dafür interessierst, bei mir wird z.B. aktuell folgende Library verwendet. Darin steht auch etwas zu 4,7,10 bytes UID, das habe ich schon gelesen, die Anwendung aber nicht richtig verstanden. (Warscheinlich wegen fehlendem Hintergrundwissen) Zu finden ist das in der MFRC522.cpp ab Zeile 574. Lib: https://github.com/miguelbalboa/rfid Nochmals kurz zur Info: Es passiert rein garnichts! Es ist also nicht so, dass die ersten 4 Bytes ankommen oder ein Lesefehler oder sonstiges angezeigt wird. Es passiert absolut garnichts, wenn man die Karte in den Lesebereich hält. (Deswegen weiß ich auch nicht 100%ig, ob der Code überhaupt dafür ausgelegt ist, oder ob es ganz anderen Code oder eine andere Lib benötigt) Gruß
@jumpy: als ich den oben verlinkten Blogartikel geschrieben hatte (vor 2 Jahren?) war der RC522 Code nur für 4Byte UID ausgelegt. In meinem Github Repository hatte ich dann den erweiterten (7Byte UID) Code eingecheckt. Wie ich mich dran erinnern kann konnte waren die aufgelisteten NFC Tags/Karten Gar nicht dazu bewegen von dem RC522 erkannt zu werden, als wenn sie nicht ins Feld gehalten werden. Entweder ist die Antenne schlecht kalibriert/designt/ausgelegt oder der DESFire hat noch irgendwelche Restriktionen???? An dem RC522 Code Methodenaufruf Parametern konnte man glaub ich nichts weiter ändern.....ich schaue aber heute Abend evtl nochmal drauf und gebe Feedback. Klar mit dem PN532 hat man mehr Freiheiten, ist die bessere Wahl
Rena Z. schrieb: > Entweder ist die Antenne schlecht kalibriert/designt/ausgelegt oder der > DESFire hat noch irgendwelche Restriktionen???? Weder noch, die Kartenaktivierung (=Auslesen der UID + Auswählen) beim DESFire funktioniert wie bei jeder anderen ISO 14443(A) kompatiblen Karte auch. Der DESFire spezifische Teil beginnt erst wenn man das T=CL (= ISO 14443-4) Protokoll aktiviert. Und selbst dann kann damit noch arbeiten. Die Antenne ist auch in Ordnung, denn sonst könnte ja die 4-Byte UID einer Mifare-Karte auch nicht gelesen werden. lg.
Ich habe gerade nochmal nachgsehen, die Karten und Schlüsselanhänger des Typs "MIFARE Classic (MF1S50)" werden mit dem RC522 Modul und der Lib von miguelbalboa ohne Probleme gelesen. Die andere Karte wie bereits erwähnt nicht. Ich habe mir die Dateien dazu mal angesehen, muss aber feststellen, dass mir das eine Nummer zu tief in die ganze Sache eingreift als das ich daran selber etwas ändern könnte. Die Kollisionswerte 93/95/97 sind in der MFRC522.h enthalten. Die Library prüft meiner Meinung nach schon die UID Längen und wertet dann entsprechend aus. (An mehreren Stellen ist dort etwas von 4byte, 7byte und 10byte zu sehen) Hier hört mein Wissensstand darüber nun leider auf. Ich kann nicht feststellen, ob es jetzt doch "nur" eine Codefrage ist, oder ob die Hardware da doch eine gewisse Rolle spielt. Gibt es eine Prüfmöglichkeit, ob die Karte überhaupt durch den Leser erfasst wird? Ich wäre nach wie vor sehr daran interessiert, die UID irgendwie auslesen zu können. Falls sich jemand dazu bereiterklärt den Code nachzuvollziehen oder sogar einen Code dazu hat, wäre ich diesem sehr dankbar. (Heizer hat das ja weiter oben schonmal angesprochen, dass er sowas gehabt hat, vielleicht existiert das ja noch und er würde es zur Verfügung stellen, wenn er sich dann nochmal meldet.) Mich wundert es allerdings noch immer, dass niemand diese Idee bereits aufgefasst hatte oder daran etwas gearbeitet hat. (Zumindest das, was man auf Github dazu findet) Die Entwickler der normalen Librarys sind ja vermutlich ziemlich Fit in dem Umgang damit gewesen, da kann ich es mir leider nicht richtig vorstellen, dass diese nicht weiter daran gearbeitet hätten oder nie auf die Idee der DESFire Auslesung gekommen sind. Gruß JumpY EDIT: In der Datei MFRC522.h stehen im Header übrigens verschiedenste Kartentypen aufgelistet, wo DESFire nicht aufgeführt wird. Dafür ist Beispielsweise der Typ "MIFARE Ultralight" aufgeführt und dieser nutzt ebenfalls eine 7-byte UID. Somit müsste das ja eigentlich möglich sein, wenn die Karte dann erkannt wird im Feld?
:
Bearbeitet durch User
Simon W. schrieb: > Gibt es eine > Prüfmöglichkeit, ob die Karte überhaupt durch den Leser erfasst wird? Ja, in der verlinkten Library gibt es in der Datei MFRC522.cpp in Zeile 480 die Methode "PICC_RequestA". Wenn du diese in deinem Code ausführst und von der DESFire-Karte 2 Byte empfängst (= ATQA), dann weißt du, dass sowohl dein Leser als auch deine Karte prinzipiell funktioneren. Achtung: Das Kommando funktioniert nur jedes 2. Mal, da die Karte nach einem erfolgreichen Request-A den internen State wechselt. Ich kann hier nur nochmal auf einen kurzen Blick in die ISO 14443 hinweisen...
Ich habe das jetzt mal versucht, allerdings ohne Erfolg. Ich wusste nicht 100%ig wie ich die Funktion da richtig aufrufen kann, deswegen habe ich in der Funktion "PICC_IsNewCardPresent()" ein "Serial.println(bufferATQA[2]);" eingebaut. Damit sehe ich bei den S50 Tags eine Veränderung der Ausgabe wenn ich die in Reichweite halte, bei den DESFire-Karten aber nicht. Leider bin ich in C relativ unbeholfen, besonders wenn es so umfangreich ist. Vielleicht findet ja jemand er anderen die noch daran arbeiten möchten etwas, ansonsten muss ich da wohl eher passen. Und ja, der Hinweis mit der ISO 14443 ist schön und gut, wenn man den Code der hier verwendet wird nicht nachvollziehen kann, ist das leider schlecht anwendbar.
Simon W. schrieb: > Damit sehe ich bei den S50 > Tags eine Veränderung der Ausgabe wenn ich die in Reichweite halte, bei > den DESFire-Karten aber nicht. Wenn beim Senden eines Requests bei Mifare eine Änderung der Ausgabe erhältst, bei den DESFire-karten aber nicht sieht das nach defekten Karten aus. Das ist sehr ungewöhnlich, kann aber vorkommen. Hast du irgendwie die Möglichkeit zu prüfen, ob das wirklich DESFire-Karten sind ? Oder handelt es sich dabei um irgendwelche unbeschrifteten Karten und / oder z.B. Schlüsselanhänger. Simon W. schrieb: > Und ja, der Hinweis mit > der ISO 14443 ist schön und gut, wenn man den Code der hier verwendet > wird nicht nachvollziehen kann, ist das leider schlecht anwendbar. Sorry wenn ich immer wieder auf den Standard / die Spezifikation verweise - es ist nicht meine Absicht hier irgendwie zu nerven. Es soll nur ein nützlicher Hinweis sein. Aber in dem Dokument sind einfache Ablaufdiagramme enthalten, welche die Kartenaktivierung ohne viel Text sehr gut beschreiben - und gerade wenn man in dem Umfeld - wie du selbst sagst - nicht viel Erfahrung hat, ist das meiner Meinung nach unerlässlich um überhaupt zu verstehen, was der Code macht. Ich habe mir den Code angesehen und abgesehen, dass der Author nicht alle HW-Features des Chips verwendet sondern viel manuell macht (z.B. automatische Berechnung + Senden der CRC_A Checksumme), sieht das alles korrekt aus. Daher mein Verdacht, dass die Karten entweder defekt (unwahrscheinlich) sind oder dass es sich dabei nicht wirklich um DESFire-Karten sondern um Karten handelt, die nicht zu ISO 14443-A kompatibel sind. Andere Frage noch - hast du oder jemand in deinem Umfeld zufällig ein Smartphone welches NFC unterstützt ? Falls ja, gibt genug freie Apps zum Auslesen von Karten - damit könnte man ebenfalls noch prüfen was es für ein Kartentyp ist und / oder ob die Karten defekt sind. Je nach verbautem NFC-Chip unterstützt dieser auch Standards neben der ISO 14443-A. Ein Versuch wäre es Wert.
Irgendwo hatte ich weiter oben erwähnt, dass ich überhaupt nur durch das Smartphone weiß, dass dies Mifare DESFire EV1 Karten sind. Unten in den Links ist ersichtlich, welche Daten mir die App auf meinem Handy dazu ausgibt. Die Karte Funktioniert zu 100%, hätte sogar noch eine DESFire EV1 Karte hier, die aus einer anderen Charge kommt. (Mensakarte der FH) Gewünschte Karte: http://pastebin.com/W6sXT6Gk Mensakarte: http://pastebin.com/UzRuvMJJ Ich habe da gewisse Stellen durch XXX unkenntlich gemacht, weil ich nicht genau wusste durch welche Informationen auf die UID etc. schließen kann. Überall wo ein X ist, war also vorher eine Zahl/Buchstabe. Was mir auffällt, die Mensakarte ist zwar auch eine DESFire EV1 Karte, allerdings mit 4-byte UID. Diese lässt sich allerdings auch nicht auslesen (zumindest nicht ohne Veränderung des Codes). Warscheinlich existiert keine richtige Routine für die DESFire Karten in der Lib? Frage: Wärest du vielleicht bereit, mir einen Arduinosketch zu senden, wie du meinst, dass ich eine Änderung feststellen müsste? Ich weiß jetzt nicht genau ob da ein Sketch ausreicht, oder ob du etwas an der Lib ändern musst, falls ja diese dann auch. Natürlich nur wenn du dazu Lust und vorallem Zeit hast, so könnte ich zumindest prüfen, ob der Leser irgend eine Reaktion wahrnimmt... Ich denke für erfahrene Nutzer bzw. C-Könner ist das dann doch mehr oder weniger einfach, weiß es aber eben nicht. EDIT: Bei der Mensakarte ist das glaube ich ein Anzeigefehler. Die Karte wird zwar in der NXP-eigenen App als DESFire angezeigt, in anderen Apps aber als unbekannt. (Die gewünschte Karte ist überall DESFire!!) Die Mensakarte wechselt nach jedem Lesevorgang die UID, anders als die gewünscht Karte, die behält ihre UID schön bei.
:
Bearbeitet durch User
Aus gegebenem Anlass habe ich nochmal meine Kartensammlung durchprobiert und auch den Blogartikel https://regnerischernachmittag.wordpress.com/2013/08/03/5euro-rfidnfc-modul-rc522-zum-auslesen-von-mifare-tags/ aktualisiert Folgende Karten reagieren nicht mal auf ein PICC_REQIDL = 0x26 (bzw kehrt der entsprechende Request-Aufruf nicht zurück): * Mifare Ultralight C (MF0ICU2), 7byte-UID * Mifare Classic 1K 'MF1 IC S5009' alias Mifare Plus S (MF1SPLUS60) * Mifare DESFire EV1 (MF3ICD21) HW v1.0 * Mifare DESFire (MF3ICD40) HW v0.2 * Mifare DESFire EV1 (MF3ICD81) HW v1.0 * Mifare Classic 1K (emulated) Bei folgenden Tags konnte zumindest die UID gelesen * Mifare Classic * Mifare Classic (MF1S70) * NTAG203 (NT2H0301) * NTAG215 (NT2H1511) alias amiibo cards * NTAG216 (NT2H1611G0DUx) * Mifare Classic Futan FM11RF08 * Mifare Classic Clonable China Card * Miafre Ultralight (MF0ICU1) alias GVB card * Infineon ??? Chip alias Geldkarte
Rena hat hier ja super Arbeit geleistet, habe auch nochmal ausführlicher mit ihm gesprochen. Wir haben verschiedenste Librarys auf Arduino und Raspberry Pi getestet, alle ohne Erfolg. Auch die Befehle innerhalb der Library die unterscheiden ob eine Karte im Feld gefunden wurde oder nicht geben auch keinen Erfolg. Jetzt kann es eigentlich nur 2 Möglichkeiten geben: Entweder der gesamte Vorgang wie die Libs aufgebaut sind funktionieren nicht und da sind irgendwelche Register falsch gesetzt, welche wir aber nicht finden, oder es ist mit den fertigen Modulen einfach nicht möglich. Ich würde mich weiterhin sehr darüber freuen, wenn die 2 Personen die hier scheinbar Erfahrung damit haben sich mit mir kurzschließen würden und mir dazu etwas sagen könnten. Ich denke mal, dass zumindest der Code für die Erkennung der Karte (ohne Auslesen) nicht sonderlich aufwendig wäre und würde mich freuen wenn diese Personen mir soetwas zeigen könnten. "Heizer" vom Beginn des Threads hat sowas ja sogar schon fertig umgesetzt, mit ein bisschen Glück schaut er nochmal hier rein und kann seinen Code zeigen oder erinnert sich zumindest noch daran was er gemacht hat. Ansonsten sehe ich leider nicht mehr viele Chancen das zum Laufen zu bekommen.
Hallo, ich habe exakt die gleichen Erfahrungen mit dem RC522 und der Desfire EV1 gemacht. Mifare Classic Karten funktionieren problemlos, Desfire Karten werden nicht mal erkannt. Ich wäre auch sehr an einer funktionierenden Lösung mit dem RC522 interessiert und biete gerne Unterstützung beim testen an. Gruß Axel
Das scheint es leider hier gewesen zu sein. Ich habe keine weitere Idee mehr und alle Tests die ich umsetzen konnte sind abgschlossen. Vielleicht meldet sich irgendwann ja nochmal jemand, schade.
Ich habe mir gestern noch einmal etwas genauer mit dem RC522 beschäftigt und mal mit dem Oszi gemessen, was zwischen PCD und PICC wirklich passiert. Dort sind definitiv Unterschiede zwischen einer Desfire und einer Classic Karte zu sehen, die Desfire scheint gar nicht zu antworten. Ein schneller Vergleich mit einem PN532 zeigt, dass das Kommando vom PCD gleich aussieht. Leider hatte ich gestern nur Zugriff auf das "kleine" Oszi, sobald ich das größere zur Verfügung habe, werde ich ein paar Bilder online stellen. Was mir auch aufgefallen ist, dass die gemessenen Spannungspegel an der Antenne bzw. mit einer Schnüffelspule am PN532 Breakout Board deutlich größer sind als am RC522. Vielleicht genügt die Feldstärke nicht für die Desfire? Habt ihr mal versucht, mit den Parametern des MFRC522 zu experimentieren, die die Antennentreiber und Empfangsteile beeinflussen (RFCfgReg, GsNReg, CWGsPReg, ModGsPReg, ...)? Ich habe leider erst kommende Woche wieder Zugriff auf die Hardware, werde mir das Thema aber noch weiter anschauen. Gruß Axel
Das klingt durchaus interessant. Meine Vermutung war es ebenfalls, dass es nicht am Chip, sondern an der Verarbeitung der Platine/der Ansteuerung liegt. Die Antenne und alles sonstige ist evtl. durch den Code anders abgestimmt und es gibt deshalb Probleme, ebenfalls könnte die Feldstärke tatsächlich zu klein sein. Mit den Einstellungen selber habe ich noch nichts gemacht, da ich keine passende Hardware habe um Signale zu verfolgen. Mit einem Oszi und der nötigen Erfahrung kann man aber bestimmt an den Werten schrauben und vielleicht eine Veränderung sehen, würde mich sehr freuen wenn du dazu nochmal berichtest. Ich habe mitlerweile auch ein PN532 Board erhalten, bis auf einen kleinen Kommunikationsfehler in der Software funktionierte das Teil auf Anhieb innerhalb 5 Minuten. Alle vorhandenen Karten können gelesen werden, gibt also keine Probleme. (Also meine Karten scheinen alle i.O. zu sein ;))
@Axel: Prima, das ist genau das was ich auch beobachtet habe: der DESFire antwortet nicht auf das REQA. Das Feld für den DESFire muss stärker sein da DESFire uController-basiert ist und mehr Leistung als der Mifare Classic ASCI-basierte Chip benötigt. Rumgespielt hatte ich bis jetzt aber nur mit dem RFCfgReg Register für die RxGain, wobei der maximale Wert von 48 dB keine Unterschiede gebracht hatte. Ich werde mir die anderen Register nochmal anschauen.
Bei einer MF3ICD40 Mifare DESFire Karte bekomme ich nun ab und zu (zu 3% = scheint sehr instabil zu sein bzw die Registerwerte scheinen noch nicht alle zur Antenne zu passen?) eine Antwort auf mein REQA!
Ach du meine Güte, das gibt's ja garnicht! :) Info: Das PN532 Board wird ja im Vergleich zum R522 über 5V gespeist. Ich habe mein RC522 mal ausversehen per 5V gespeist, habs zumindest damit nicht zerstört, ich weiß allerdings nicht welches das Spannungsbegrenzende Bauteil auf der Platine ist. (Also das Teil welches nur 3.3V darf) Ist ja eigentlich auch mehr oder weniger logisch, dass bei 5V ein größeres Feld aufgebaut werden könnte, oder irre ich micht da? Es wäre natürlich genial, wenn du mit der Einstellung alleine da etwas bewirken könntest, vielleicht braucht die Antenne aber auch einfach mehr Saft, aber der Chip ist auf 3.3V ausgelegt?
@ Simon: so einfach ist das nicht. Im RC522 Datenblatt http://www.nxp.com/documents/data_sheet/MFRC522.pdf steht supply voltage: 3.3V, max: 3.6V -> freu Dich wenn Du den Chip damit nicht gebraten hast. PN532 http://www.adafruit.com/datasheets/pn532ds.pdf VBAT darf 5V sein, weil er intern noch einen Regulator hat. Mehr ist nicht immer besser ;-)
@Rena Sehr schön. Welche Registerwerte hast du jetzt angepasst? GsNReg und CWGsPReg, so dass maximale Power ausgegeben wird (ist das eigentlich 0 oder F?) und RFCfgReg auf maximale Verstärkung? Ich wollte mir auch noch mal den Aufbau der Antenne anschauen. Hat jemand zufällig einen Schaltplan? Ich hatte gestern den Schaltplan der Antenne teilweise erstellt, um mir den Antennenaufbau genauer anschauen zu können. Dabei ist mir aufgefallen, dass dieser zu keiner der in den Appnotes genannten Vorschläge passt. Vielleicht ist auch nur die Abstimmung der Antenne schlecht. Ich wollte zu Testzwecken den MFRC522 mal an den Antennenaufbau eines PN532 hängen und schauen, ob das etwas verbessert. Beim Aufbau meiner eigenen Platine (allerdings mit PN532) habe ich schon die Erfahrung gemacht, dass die Antennenabstimmung durch sehr diffizil ist. Leider stehen mir aber nicht alle in der Appnote genannten Werkzeuge zur Verfügung. Gruß Axel
@Axel: Registerwerte habe ich jetzt nach diversem Rumspielen eigentlich gar nicht geändert nur die Antenne (4 Wicklungen Lackdraht an das Board gelötet https://regnerischernachmittag.files.wordpress.com/2015/11/rc522_my_antenna.jpg). Damit kann man dann bei Millimetergenauer Ausrichtung die DESFire Karten ansprechen.
:
Bearbeitet durch User
Ich habe heute noch mal mit den Registerwerten experimentiert. Mit GsNReg und CWGsPReg kann ich durchaus das Feld beeinflussen, das lässt sich auch gut im Oszi beobachten. Nur reicht ein volles aufdrehen nicht, um die Desfire Karten lesen zu können. Ich werde mir in den nächsten Tagen mal die Antenne vornehmen und mittels der Appnote versuchen, diese abzustimmen. Gruß Axel
@Axel: was ändert sich denn am Feld, wenn Du an den angegebenen Registerwerten drehst?
Ich messe mit ein paar Windungen Draht am Tastkopf des Oszi zwischen RC522 und RFID Karte. Wenn ich die Registerwerte Richtung Null ändere, wird die induzierte Spannung kleiner, wenn ich sie erhöhe größer. Gegenüber dem Resetwert kann ich die Spannung noch um ein paar mV erhöhen, reicht aber scheinbar nicht. Gruß Axel
Kennst du eigentlich die folgenden Seiten: https://www.mikroe.com/forum/viewtopic.php?f=147&t=64203 https://revspace.nl/RC522Hacking In beiden Fällen schient eine Fehlanpassung der Bauteile die Ursache der Probleme zu sein. Ich habe heute auch mal versucht, einen Schaltplan zu zeichnen. Im Netz findet sich bspw. folgender http://www.elecrow.com/download/MFRC522_ANT.pdf Der kommt dem von mir ermittelten schon recht nahe, die Bauteile der Antenne sind auf jeden Fall so angeordnet, wie ich es ermittelt habe. Was die Bauteilgrößen insbesondere der Kondensatoren angeht, kann ich noch nicht sagen, ob die Werte so korrekt sind. Gegenüber der NXP Appnote (http://www.nxp.com/documents/application_note/AN1445_An1444.zip) ist vor allem der Empfangsteil anders. Auch die Bauteilwahl (zumindest wie im Schaltplan angegeben) kann ich anhand der Appnote noch nicht nachvollziehen. Gruß Axel
Netter Fund! Kannte ich noch nicht. Dann mal angestellt den SMD-Backofen...
Juhu, es läuft. Ich habe zunächst wie in [1] beschrieben, die Kondensatoren getauscht. Auf meiner Platine sind das C10 und C11. Diese haben ursprünglich einen gemessenen Wert von 280pF (kommt unter Berücksichtung der Toleranz den 220pF recht nahe) und ich habe sie durch 100pF ersetzt. Dies hat jedoch die Situation nicht verbessert. Dann habe ich mich an den Tausch der Induktivitäten L1 und L2 gemacht, wie in [2] beschrieben. Mangels Auswahl habe ich folgende neue Induktivitäten verwendet: [3]. Mit dieser Konfiguration bekomme ich endlich eine Antwort der Defire Karte auf den REQA. Ich habe die Kondensatoren auch wieder durch die Originale ersetzt, so dass der Tausch der Induktivitäten die einzige notwendige Änderung ist. Ich würde nun mal schauen, welche passenden und beschaffbaren Induktivitäten denn eingesetzt werden könnten. Als nächstes würde ich schauen, ob ich die weiterführende Kommunikation mit der Desfire Karte lauffähig bekomme. Hier sehe ich aber gute Chancen, ohne weitere Probleme ans Ziel zu kommen. Gruß Axel [1]: https://revspace.nl/RC522Hacking [2]: https://www.mikroe.com/forum/viewtopic.php?f=147&t=64203 [3]: http://katalog.we-online.de/pbs/datasheet/744032002.pdf
Hallo Axel, ich habe deinen Beitrag zwar sofort gelesen, hatte aber bislang relativ wenig Zeit mir darüber Gedanken zu machen. Freut mich sehr, dass es bei dir zu einem gewissen Erfolg gekommen ist, hast du daran schon weiter gemacht? Mir würde die Bestimmung der UID z.B. ja ausreichen, weitere Fälle würden auch deutlich mehr Aufwand mit sich bringen. Was aber wichtig wäre: Hast du nochmal die Standardkarten versucht? Es wäre ja schon wichtig, dass diese weiterhin wie gewohnt funktionieren. (Dann könnte man ein kleines Kombisystem daraus machen) Gruß Simon
Hallo Simon, ja, ich habe weiter gemacht. Ich habe das Modul an einem Beaglebone Black betrieben und konnte mit Hilfe der Bibliothek von Miguel Balboa [1] auch direkt auf die Desfire Karten zugreifen (lediglich bzgl. der SPI Anbindung musste ich kleinere Änderungen vorsehen) und die UID auslesen. Ich habe bislang nicht getestet, ob die Classic Karten weiterhin funktionieren, kann mir aber keinen Grund vorstellen, was das verhindern sollte. Auf Basis der Bibliothek habe ich einige weitere Desfire Funktionen implementiert (SelectApplication, Authenticate, GetValue, Debit, ReadData - alle auf Basis von AES), mit deren Hilfe ich auf von mir mit anderer Hardware formatierte Karten erfolgreich zugreifen kann. Aktuell versuche ich mich mit einer Portierung auf einen STM32, meinem eigentlichen Zielprozessor. Gruß Axel [1]: https://github.com/miguelbalboa/rfid
Klasse, das hört sich doch sehr gut an. Dann müsste ich das wohl auch mal in Angriff nehmen und testen, dann könnte ich mein Projekt um Mifare's erweitern, und noch ein anderes Projekt angehen. Wenn du da irgendwann etwas ansehnliches fertig hast, wäre es interessant den Code davon zu sehen. (Die Bib von Balboa kenne ich, die nutze ich auf dem PI aktuell ebenfalls ohne Probleme mit den Standardkarten)
Tut mir bitte leicht fur mein Deutsch. Du kanst benutzt mfrc522 und Desfire EV1 einwnderfrei, mit des/2k3des/aes. Die 3DES - 120ms Authorisierung process mit dem Atmega329p Und mit AES128 - 5-10ms. Ich habe kaine library dieses Zeit, aber du kanst mir fragen shtelle uber algorithm und theorie. Ich habe viele log's auf einem russishe forum geshriebt, und immer noch weitere logirung. http://radiokot.ru/forum/viewtopic.php?f=2&t=145789&sid=e9fb435e01cc1dd63b4a1f37274286b4&start=80
@Stanislav: Hast Du denn ein fertiges Board gekauft oder die Induktivitäten L1 und L2 (wie in "MFRC522 from Ebay - tips how to get more RF power" https://forum.mikroe.com/viewtopic.php?f=147&t=64203 beschrieben) ausgetauscht?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.