TR61

Hallo Masder, bin mir jetzt nicht ganz sicher wie RFID und NFC vom Speicheraufbau miteinander verwand sind, aber ich versuch dir einfach mal zu helfen Ich habe mich mit NFC beschäftigt gehabt und mir hat damals folgendes geholfen: http://www.nxp.com/documents/data_sheet/NTAG213_215_216.pdf Seiten 11-15 waren mir hilfreich beim locken des Speichers. Wie gesagt, weiß ich nicht ob es dir hilft, weil die doku speziell für NFC ist. eventuell kann dir auch meine Forum Frage helfen: http://www.tinkerunity.org/forum/index.php/topic,3312.0.html Grüße TR

Das wäre echt schade wenn's nicht geht. Zu diesem Punkt wäre jetzt eine klare Ansage von einem TF Mitarbeiter nötig, der sich in dem Bereich auskennt und deine Aussage bestätigen kann. Trotzdem schaue und versuche ich es weiter.

Hallo, du hast recht, in der Spezifikation wird das nicht angesprochen. Leider. Mit meinem Handy kann ich den Tag beschreiben und ein Passwortschutz drüber ziehen, damit man es lesen kann aber nicht mehr ändern. Nach Eingabe des Passwortes kann ich wieder alles ändern und beschreiben. Mit dem Bricklet kann ich die Info auch lesen aber nicht ändern, so wie es auch sein soll. Ich weiß das kann man nicht so direkt vergleichen aber ich meine ja nur. Daher müsste es ja auch mit dem bricklet gehen. Im Augenblick kämpfe ich mich durch Folgenden Seite durch: Punkt 8.5 und 10.7 sind für den Anfang Interessant http://www.nxp.com/documents/data_sheet/NTAG213_215_216.pdf Was mich sehr irritiert, ist laut 8.5 im pdf, 4 Bytes für das Passwort (PWD) reserviert. Also Page 43 nur Passwort. Aber laut 10.7 müsste der Aufbau folgendermaßen sein: cmd/PWD/CRC/PACK/CRC in der Summe 9Bytes (vorausgesetzt es hat alles funktioniert) oder cmd/PWD/CRC/NAK auch 9 Bytes (vorausgesetzt es hat nicht geklappt) Da überlege ich mir, wenn das PWD schon 4Bytes benötigt, wohin soll ich den die anderen 5 Bytes schreiben Also die Info würde sich auf Page 42 und 44 Überlappen. Sollte das so sein? Mir macht auch die Zeit etwas sorgen, weil soweit ich es verstanden habe liegt die Antwort vom tag sehr kurz an (laut pdf 359us bzw 59us). Das könnte fürs Labview etwas zu kurz sein, da die Kommunikation ja nicht direkt läuft... Ist der Ansatz den ich verfolge überhaupt richtig? weil ich gerade nicht wirklich weiter komme. Hat wer eine besser Idee? Gruß TR

Mensch, wie mein Lehrer immer zu uns sagte: "Leutz schaltet euer Hirn ein und analysiert!". Das Problem mit dem Schreiben von beliebig großem Text (natürlich Speicherabhängig) in den Tag habe ich gelöst, habe tatsächlich ein schritt in der Beschreibung nicht berücksichtigt... Aufbauend auf den Erfolg, möchte ich gerne auch den Tag per Passwort schützen, damit man es zwar lesen kann aber nicht ohne das Passwort ändern. Hat da jemand ein guten Ansatz oder hat schon mal so was gemacht? Im Internet bin ich leider auch nicht so richtig fündig geworden. Im Anhang ist das funktionsfähige .vi LV2010 für das Schreiben auf den Tag. Wer den Tag auslesen möchte muss nur den oberen Schreiben Bereich aus kommentieren und das untere Lesen Aktivieren. Gruß TR Versuch_Example_Write_Read_Type_2.vi

Hallo Equinox, vielen Dank für deine Antwort. Ich habe mich jetzt einfach mal durch die ganzen NDEF Spezifikationen gekämpft und habe es endlich hinbekommen eine Nachricht über den Brick Viewer zb."123" auf den Tag (im NDEF Format) zu schreiben und es mit einem Lesegerät wieder ausgelesen. Damit ich mir das erneute durchlesen der Spezifikationen später ersparen kann und anderen es einfach und verständlich erklären kann, habe ich meine eigene Headerbeschreibung auf zwei Word Seiten erstellt . So jetzt kommt das nächste Problem. Ich kann soweit ich es verstanden habe nur 16 Bytes vom Anfang der Page (den ich ja selber vorgeben kann (natürlich Page>2)) beschreiben. Ich habe mich auch an die Anleitung auf der Homepage gehalten (siehe link unten). Also wenn ich 16 Byte ab page 3 übergebe, werden alle Bytes bis einschließlich page 6 dementsprechend gesetzt. Soweit so gut, aber wie mache ich es wenn mein Info etwas mehr platz braucht ? Mein Ansatz war: Warte auf Bricklet bis Write.Ready; nehme die Info und zerhacke sie in 16 Byte Blöcke und übergebe sie so den "WritePage" Baustein. Wenn der wert übergeben wurde, erhöhe ich den Page +4 damit ich im nächsten Bereich bin; Warte wieder bis Write.Ready kommt und übergebe die nächsten 16 Byte usw. usw. Leider klappt es nicht... Mache ich da was grundlegend falsch oder hat da einer ne bessere Idee/Ansatz?? Das auslesen der Information funktioniert aber nach dem Prinzip... komisch Siehe BrickletNFCRFID.WritePage(page, data) http://www.tinkerforge.com/de/doc/Software/Bricklets/NFCRFID_Bricklet_LabVIEW.html#BrickletNFCRFID.RequestPage Im Anhang ist das veränderte Beispiel .vi ab LV 2010 damit ihr nachvollziehen könnt, was ich meine oder gemacht habe. Bitte keine Anmerkungen über mein Programmierstyl Natürlich dürft ihr es auch so verändern das es funktioniert und es hier für mich und allen anderen zur Verfügung stellen Grüße TR Versuch_Example_Write_Read_Type_2.vi

Hallo NFC freunde, ich habe mir neulich das nfc/rfid bricklet mit allem drum und dran geholt. Leider habe ich einige Probleme was das beschreiben bzw. auslesen der Information angeht. Ich habe die "example read write.vi" von der TF Homepage verwendet und es funktioniert alles auch sehr schön und gut. Aber genau da fängt mein Problem an. Nach dem Beschreiben kann ich mit herkömmlichen NFC Lesegeräten/Handy die Tags nicht mehr auslesen (kein NDEF Format). Also war klar die Info muss in das NDEF Format konvertiert werden. Tja ich habe auch das Python Beispiel auf der TF Homepage gefunden aber leider habe ich keine Ahnung wie ich das bei mir implementieren soll habe es auch mit labpython versucht leider kein Erfolg. Hat hier einer eine gute Idee oder ein entsprechendes .vi bereit, dass die Konvertierung oder das Lesen/schreiben erleichtert? Eine Beschreibung der einzelnen (wichtigen) Page´s mit den Bedeutungen der Byte´s Oder die Info im Header mit den Hex-Werten wäre eventuell auch hilfreich, dann könnte ich versuchen mir was zusammen zu schustern. Die Anwendung, die ich entwickle, soll später als .exe auf ausgewählten PCs laufen, daher wäre es mir auch lieber, dass ich abgesehen von den TF Software/Treiber auch nicht viel mehr Installieren müsste aber wenn es nicht anders geht, wäre es natürlich auch kein Problem. Im Bereich NFC bin ich ein Neuling, daher hoffe ich auf Verständnis wenn ich etwas nicht auf anhieb verstehe. Ich hoffe ich konnte mein Problem verständlich schildern. Grüße TR