NDEF Message Format

Hallo zusammen und frohes, neues Jahr!

Zu Weihnachten habe ich mir ein NFC/RFID-Bricklet geschenkt. Ich möchte darauf gerne NDEF-konforme Nachrichten speichern. Ich habe es auch geschafft, einige korrekte Nachrichten zu erzeugen, allerdings sind bei mir da noch einige Fragen offen, was das Format angeht. Kennt jemand eine gute(!) Dokumentation dafür (und ich meine nicht die Spezifikation https://github.com/Tinkerforge/nfc-rfid-bricklet/raw/master/datasheets/specification_ndef.pdf)?

Meine Fragen im Einzelnen:

[*]Ich habe die "NFC Forum Typ 2"-Tags aus dem TF-Shop. Ich dachte, man sollte/darf erst ab Page 5 eigene Daten schreiben. Warum beginnt die "vorinstallierte" Nachricht dann schon bei Page 4?

[*]Wo in der Spezifikation steht, dass eine NDEF Nachricht mit 0x03 beginnen muss? Ich habe das nur auf einer anderen Internetseite gefunden, dass dies so sein muss zur Identifikation als NDEF-Nachricht. Gibt es noch andere definierte "Startbytes"?

[*]Nach dem 0x03 steht die Gesamtlänge der Nachricht in einem Byte. Wie kann ich dann Nachrichten mit mehr als 255 Bytes erzeugen? Seltsamerweise gibt es bei den einzelnen Records die Möglichkeit, dass diese 2³²-1 Bytes lang werden können (mit eigenem Längenfeld). Das macht doch aber keinen Sinn, wenn die Nachricht sowieso nur 255 Bytes lang werden kann, oder?

[*]In der vorinstallierten Nachricht folgt als nächstes 0x91 als erstes Header-Byte. Dies bedeutet, dass das Message-End Bit, das Short Record Bit ID-Length Bit gesetzt sind und als TNF "Absolute URI".

• Müsste da nicht zumindest auch das Message Begin-Bit gesetzt sein?
  
• 
  Warum ist das Message End-Bit gesetzt? Es folgt doch noch eine weiterer Record.
   
  
• ID-Length ist gesetzt, aber ich konnte in der Nachricht keine ID finden. Ist das bei Absolute URI automatisch der Payload? Falls ja, wo kann man das Nachlesen?
  
• Warum wird "Absolute URI" verwendet bzw. was ist der Unterschied zu "Well-Known" (0x01)? Es kommt ja noch ein Byte, das den Typ angibt. Da muss bei URI 0x55 stehen. Wie würde die vorinstallierte Nachricht mit TNF 0x01 aussehen (hat bei mir nicht funkktioniert)? Auf einer anderen Seite habe ich gelesen, dass man TNF 0x03 nicht verwenden sollte, sondern 0x01 (leider ohne Begründung)
  

[*]In der vorinstallierten Textnachricht steht als Header-Byte 0x51. Auch hier ist das Message Begin Bit nicht gesetzt, keine ID und TNF ist 0x01.

Kann es sein, dass in einer Nachricht, keine 2 Records gleichen Typs stehen dürfen, d.h. deshalb wurde für URI TNF 0x03 genommen, damit man noch eine Textnachricht mit TNF 0x01 anhängen kann?

Falls dem nicht so ist, hat jemand ein Beispiel, wie z.B. zweimal die Nachricht "Hallo" aussehen würde (d.h. in zwei eigenen Records)?

[*]

Nach dem Typ (0x54 für Text und 0x55 für URI) folgt ein Statusbyte. Nach einiger Suche konnte ich eine Spezifikation dafür im Falle einer Textnachricht finden, allerdings nicht vollständig erklärt. Wie ist die Spezifikation dafür für URIs?

Ich könnte mich natürlich durch das TF-Beispielprogramm wühlen, aber einerseits steht da dann "nur" dass es so ist und nicht warum und andererseits würde mich schon auch interessieren, woher die Informationen sind (ich konnte zumindest einiges nicht in der Spezifikation finden, wie z.B. das Startbyte 0x03).

Vielen Dank!

Jemand eine Idee oder einen Tipp?

Zu 1:

über das Problem bin ich auch gestolpert, da hast Du im anderen Thread ja drauf geantwortet. Ich bin übrigens auf 184 Byte brutto bekommen, da in der Page 3 ein Größenbyte drin ist. Und das ergibt bei mir 184 Bytes.

Zu 2/3: weiss ich nicht genau

Zu 4: 0x91  ist  0b10010001 - da ist das MB Bit doch gesetzt und ME nicht? Hast Du vielleicht eine falsche Bit-Reihenfolge? In C sieht meine Struktur so aus:

    struct MessageFlags {
        unsigned TNF: 3;
        unsigned IL : 1;
        unsigned SR : 1;
        unsigned CF : 1;
        unsigned ME : 1;
        unsigned MB : 1;
    } ATTRIBUTE_PACKED;

Und damit konnte ich die auf den Tags vordefinierte Message inzwischen korrekt auslesen.

Die Message verwendet doch well-known-types?

0x55 beim Message Typ ist "URI", das Byte danach definiert den URI Prefix, 0x01 ist "http://www.", das wird vor den Rest der Daten gepackt. Ergibt dann "http://www.tinkerforge.com" (bin nicht ganz sicher, was Du hier meinst).

Zu 5. 0x51 ist binär 0b01010001 - da ist MB=0 und ME=1, ist doch OK?

Zu 6. 0x54 ist Text, 0x02 danach ist die Länge eines Language-Code (kommt direkt danach), hier 0x65 0x6E = "en" und danach kommt dann der eigentliche Text in UTF-8.

Hallo,

danke für die Antwort!

Zu 1:

über das Problem bin ich auch gestolpert, da hast Du im anderen Thread ja drauf geantwortet. Ich bin übrigens auf 184 Byte brutto bekommen, da in der Page 3 ein Größenbyte drin ist. Und das ergibt bei mir 184 Bytes.

Das ist auch so ein Punkt: Bei mir steht an dem Längenbyte (Page 3, drittes Byte) 0x17 (=23), d.h., es müssten 23*8=184 Bytes sein. Das Tag hat aber nur 42 Pages zu je 4 Bytes, also 168 Bytes. Ebenso ist es bei mir bei der NFC Scheckkarte. Hier steht bei mir 0x7d (=125), was genau 1000 Bytes wären. Allerdings hat die Karte nur 231 Pages, also 924 Bytes. Warum ist das so bzw. funktioniert es trotzdem?

Zu 4: 0x91  ist  0b10010001

Zu 5. 0x51 ist binär 0b01010001

Hmm, was hab ich denn da gemacht? So habe ich es erwartet (und so ist es auch). Ich denke, ich habe dezimal 91 (51) in Binär umgerechnet  Sorry, mein Fehler (man sollte solche Sachen vmtl. nicht machen, wenn man von einem Virus dahingerafft wurde ...)

Zu 6. 0x54 ist Text, 0x02 danach ist die Länge eines Language-Code (kommt direkt danach)

Ich meinte das Byte 0x02. Dies ist ein Statusbyte. Die Informationen dazu habe ich mittlerweile gefunden. Zur Info: Es enthält neben der Länge des Language-Codes auch das Encoding, d.h., ob es UTF-8 oder UTF-16 ist (höchstwertiges Bit=0 --> UTF-8, höchstwertiges Bit=1 --> UTF-16, die 6 niederwertigsten Bits geben die Länge an und das verbleibende Bit ist reserviert (for future use) und muss 0 sein.

Das hat mir geholfen, danke!

Weiss jemand, wie man NDEF-Nachrichten mit mehr als 255 Bytes erzeugen kann?

Also ich kann 44 pages (ab page 2) erfolgreich lesen. Damit habe ich insgesamt 46 pages, wovon nicht alle nutzbar sind, aber es ergibt die 184 Bytes (NFC Aufkleber, sollte aber mit Anhänger identisch sein).

Hmm, das ist komisch. Mit dem Brick-Viewer kann ich alle Pages von 0-44 auslesen, mit meinem Handy hört es aber bei Page 41 auf. Vielleicht zeigt mein Handy diese Daten einfach nicht an.

Ich komme aber bei Pages 0-44 auch "nur" auf 45 Seiten, d.h. 180 Bytes, also trotzdem 4 Bytes zu wenig.

Im Brick-Viewer kann man nur bis Page 99 als Startpage einstellen (ist das so gewollt?), von daher kann ich nicht sagen, wie es bei der Scheckkarte ist. Mein Handy liest hier bis Page 230 aus.

Im Brick-Viewer kann man nur bis Page 99 als Startpage einstellen (ist das so gewollt?).

Das ist ein Bug, wird in der nächsten Brick Viewer Version behoben sein, danke für den Hinweis.