Understanding NFC Data Exchange Format (NDEF) messages - Revision history

Hamishwillee: Hamishwillee - Fix layout

2012-11-27T06:00:15Z

Hamishwillee - Fix layout

Hamishwillee: Text replace - "Category:MeeGo" to "Category:MeeGo Harmattan"

2012-06-13T10:58:37Z

Text replace - "Category:MeeGo" to "Category:MeeGo Harmattan"

Hamishwillee: moved Inside NFC: Understanding NDEF message to Understanding NFC Data Exchange Format (NDEF) messages: Better topic name

2012-02-23T10:06:19Z

moved Inside NFC: Understanding NDEF message to Understanding NFC Data Exchange Format (NDEF) messages: Better topic name

Hamishwillee: Hamishwillee - Add Abstract. Tidy wiki text

2012-02-23T10:05:25Z

Hamishwillee - Add Abstract. Tidy wiki text

Hamishwillee: Hamishwillee - Bot update - Fix Article Metadata and other minor issues

2012-02-23T04:56:12Z

Hamishwillee - Bot update - Fix Article Metadata and other minor issues

Hamishwillee: Hamishwillee - Addition to article of: Category:MeeGo Category:Symbian. (Add platform categories)

2012-02-15T05:29:01Z

Hamishwillee - Addition to article of: Category:MeeGo Category:Symbian. (Add platform categories)

Lpvalente: Lpvalente -

2011-11-27T01:09:18Z

Lpvalente -

Hamishwillee: Hamishwillee - Bot addition of Template:ArticleMetaData

2011-11-07T00:21:13Z

Hamishwillee - Bot addition of Template:ArticleMetaData

Lpvalente: Lpvalente - broken links

2011-08-09T14:01:31Z

Lpvalente - broken links

Mahbub s60: Mahbub s60 -

2011-07-12T07:27:27Z

Mahbub s60 -

@@ Line 1: / Line 1: @@
-[[Category:Qt]][[Category:Qt Mobility]][[Category:Near Field Communication (NFC)]][[Category:MeeGo Harmattan]][[Category:Symbian]][[Category:Code Examples]]
+[[Category:Qt]][[Category:Qt Mobility]][[Category:Near Field Communication (NFC)]][[Category:MeeGo Harmattan]][[Category:Symbian]][[Category:Code Examples]][[Category:Getting Started]]
 {{Abstract|This article explains the structure of a NDEF message with simple uniform resource identifier (URI) that describes web page address.}}
@@ Line 26: / Line 26: @@
 == Introduction ==
 Most NFC tags are passive elements those store data for reader (for NFC enabled mobile phones) in NDEF (NFC Data Exchange Format) format. When we touch our phones with any NFC forum enabled tags, actually we read the NDEF message by our application. Those happen via NFC application to protocol stack then low level driver and finally the radio frequency (RF) parts to retrieve data from tags.
 In this article, we try to explain the structure of NDEF message with simple uniform resource identifier (URI) to describe web page address. We provide an example Qt mobility application that can be used to test it.
 == NDEF message and NDEF record ==
 The NFC Data Exchange Format (NDEF) specification defines a message encapsulation format to exchange information, e.g. between an NFC Forum Device and another NFC Forum Device or an NFC Forum Tag. NDEF is a lightweight, binary message format that can be used to encapsulate one or more application-defined payloads of arbitrary type and size into a single message.
 An NDEF message is composed of one or more NDEF records. There can be multiple records in a NDEF message.  Basically NDEF message is array of NDEF records. How many records we can encapsulate in a NDEF message that depends on our application and the tag type. For our analysis purposes we use only one NDEF records. This NDEF record stores
-<nowiki>http://nokia.com</nowiki>. Following figure shows the general view of NDEF message<ref>http://www.developer.nokia.com/info/sw.nokia.com/id/bdaa4a0f-fcf3-4a4b-b800-c664387d6894/Introduction_to_NFC.html</ref><ref>http://www.nfc-forum.org/specs/</ref>. <br>
+<nowiki>http://nokia.com</nowiki>. Following figure shows the general view of NDEF message<ref>http://www.developer.nokia.com/info/sw.nokia.com/id/bdaa4a0f-fcf3-4a4b-b800-c664387d6894/Introduction_to_NFC.html</ref><ref>http://www.nfc-forum.org/specs/</ref>.
 [[File:ndefrecod.png]]
 When we communicate with our NFC reader devices (mobile phones) to read or write data to NFC tag we read basically (for example http: //nokia . com) the following hexa code.

← Older revision		Revision as of 10:58, 13 June 2012
Line 1:		Line 1:
−	[[Category:Qt]][[Category:Qt Mobility]][[Category:Near Field Communication (NFC)]][[Category:MeeGo]][[Category:Symbian]][[Category:Code Examples]]	+	[[Category:Qt]][[Category:Qt Mobility]][[Category:Near Field Communication (NFC)]][[Category:MeeGo Harmattan]][[Category:Symbian]][[Category:Code Examples]]
	{{Abstract\|This article explains the structure of a NDEF message with simple uniform resource identifier (URI) that describes web page address.}}		{{Abstract\|This article explains the structure of a NDEF message with simple uniform resource identifier (URI) that describes web page address.}}

@@ Line 1: / Line 1: @@
-[[Category:Qt]][[Category:Qt Mobility]][[Category:Near Field Communication (NFC)]]
+[[Category:Qt]][[Category:Qt Mobility]][[Category:Near Field Communication (NFC)]][[Category:MeeGo]][[Category:Symbian]][[Category:Code Examples]]
 {{ArticleMetaData <!-- v1.2 -->
 |sourcecode= [[Media:Qttestapp.zip]]
@@ Line 28: / Line 30: @@
 The NFC Data Exchange Format (NDEF) specification defines a message encapsulation format to exchange information, e.g. between an NFC Forum Device and another NFC Forum Device or an NFC Forum Tag. NDEF is a lightweight, binary message format that can be used to encapsulate one or more application-defined payloads of arbitrary type and size into a single message.
 An NDEF message is composed of one or more NDEF records. There can be multiple records in a NDEF message.  Basically NDEF message is array of NDEF records. How many records we can encapsulate in a NDEF message that depends on our application and the tag type. For our analysis purposes we use only one NDEF records. This NDEF record stores
-<nowiki>http://nokia.com</nowiki>. Following figure shows the general view of NDEF message [1]. <br>
+<nowiki>http://nokia.com</nowiki>. Following figure shows the general view of NDEF message<ref>http://www.developer.nokia.com/info/sw.nokia.com/id/bdaa4a0f-fcf3-4a4b-b800-c664387d6894/Introduction_to_NFC.html</ref><ref>http://www.nfc-forum.org/specs/</ref>. <br>
 [[File:ndefrecod.png]]
-<br>
 When we communicate with our NFC reader devices (mobile phones) to read or write data to NFC tag we read basically (for example http: //nokia . com) the following hexa code.
-<br>
+0e d1 01 0a 55 03 6e 6f 6b 69 61 2e 63 6f 6d fe
-0e d1 01 0a 55 03 6e 6f 6b 69 61 2e 63 6f 6d fe
+* 03 - This is one byte that defines the type of record this is. An NDEF record is represented by the hex byte 03, with Qt mobility API we don’t provide this, those are added for us.
-<br>
+* 0e - This is one byte that tells the reader how many bytes are in the payload. With Qt mobility API we don’t provide this, those are added for us by platform. <br>
-<br>
+* d1 - NDEF records are variable length records with a common format illustrated in the figure below.
-This is one byte that defines the type of record this is. An NDEF record is represented by the hex byte 03, with Qt mobility API we don’t provide this, those are added for us. <br>
+ d1 is binary code (11010001)
-e<br>
 This is one byte that tells the reader how many bytes are in the payload. With Qt mobility API we don’t provide this, those are added for us by platform. <br>
-d1 <br>
-NDEF records are variable length records with a common format illustrated in the figure below. <br>
-d1 is binary code (11010001) <br>
 [[File:ndeftnf.png]]
-(Type Length) <br>
+In our case:
-The TYPE_LENGTH field is an unsigned 8-bit integer that specifies the length in octets of the
+* MB = 1 (message Begin is true means this is first record in the NDEF message)
-TYPE field. The TYPE_LENGTH field is always zero for certain values of the TNF field. <br>
+* ME = 1 (Message end, means it is last record in the NDEF message, if it is 0 that tells application that more records are ahead)
-A (Pay load Length)<br>
+* CF = 0 (means this is not chunked message, An NDEF message can contain zero or more chunked payloads. Each chunked payload is encoded as an initial record chunk followed by zero or more middle record chunks and finally by a terminating record chunk, in our case we simplify our record as not chunked)
-The PAYLOAD_LENGTH field is an unsigned integer that specifies the length in octets of the
+* SR = 1 (SR stands for short record, if set, that the payload length field is a single octet.This short record layout is intended for compact encapsulation of small payloads which will fit within PAYLOAD fields of size ranging between 0 to 255 octets.)
-PAYLOAD field (the application payload). The size of the PAYLOAD_LENGTH field is determined by the value of the SR flag
+* IL = 0(IL stands for identification length, if set, that the ID_LENGTH field is present in the header as a single octet. If the IL flag is zero, the ID_LENGTH field is omitted from the record header and the ID field is also omitted from the record)
-<br>
+* TNF = 001(The TNF field value indicates the structure of the value of the TYPE field. The value 0x01 (NFC Forum well-known type) indicates that the TYPE field contains a value that follows the RTD type name format defined in the NFC Forum RTD specification)
-(type The value of the TYPE field is an identifier describing the type of the payload, The URI record type (“U”) )
+*: [[File:ndeffullrecod.png]]
-<br>
+* 01 (Type Length) - The TYPE_LENGTH field is an unsigned 8-bit integer that specifies the length in octets of the TYPE field. The TYPE_LENGTH field is always zero for certain values of the TNF field.
+* 0A (Pay load Length) - The PAYLOAD_LENGTH field is an unsigned integer that specifies the length in octets of the PAYLOAD field (the application payload). The size of the PAYLOAD_LENGTH field is determined by the value of the SR flag
-x03 URI identifier <nowiki>(“http://”)</nowiki> <br>
+* 55 (type The value of the TYPE field is an identifier describing the type of the payload, The URI record type (“U”) )
-<br>
+* 03 - 0x03 URI identifier <nowiki>(“http://”)</nowiki> <br>
-Pay Load <br>
+* Pay Load - The rest of the string in UTF-8 (nokia.com)
-Rest string in UTF-8 (nokia.com)
+* FE Terminator byte.  This is final byte added by platform.
-<br>
 FE Terminator byte.  This is final byte added by platform.
-<br>
 == Qt Mobility TestApplication ==
 [[File:Qttestapp.zip]]
-<br> Modified example from Qt mobility example, address and corresponding NDEF messages are shown in the edit box <br>
+[[File:ndefscreenshot.png|none|frame|Modified example from Qt mobility example, address and corresponding NDEF messages are shown in the edit box]]
-−
-[[File:ndefscreenshot.png]]
-<br>
 == References ==
-. http://www.developer.nokia.com/info/sw.nokia.com/id/bdaa4a0f-fcf3-4a4b-b800-c664387d6894/Introduction_to_NFC.html <br>
+<references />
-. http://www.nfc-forum.org/specs/[[Category:MeeGo]] [[Category:Symbian]]
-[[Category:Code Examples]]

@@ Line 1: / Line 1: @@
 [[Category:Qt]][[Category:Qt Mobility]][[Category:Near Field Communication (NFC)]]
-{{ArticleMetaData
+{{ArticleMetaData <!-- v1.2 -->
-|sourcecode=[[Media:Qttestapp.zip]]
+|sourcecode= [[Media:Qttestapp.zip]]
 |installfile= <!-- Link to installation file (e.g. [[Media:The Installation File.sis]]) -->
 |devices= <!-- Devices tested against - e.g. ''devices=Nokia 6131 NFC, Nokia C7-00'') -->
@@ Line 7: / Line 7: @@
 |platform= <!-- Compatible platforms - e.g. Symbian^1 and later, Qt 4.6 and later -->
 |devicecompatability= <!-- Compatible devices e.g.: All* (must have internal GPS) -->
 |dependencies= <!-- Any other/external dependencies e.g.: Google Maps Api v1.0 -->
-|signing=<!-- Signing requirements - empty or one of: Self-Signed, DevCert, Manufacturer -->
+|signing= <!-- Signing requirements - empty or one of: Self-Signed, DevCert, Manufacturer -->
-|capabilities=<!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
+|capabilities= <!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
 |keywords= <!-- APIs, classes and methods (e.g. QSystemScreenSaver, QList, CBase -->
-|id= <!-- Article Id (Knowledge base articles only) -->
+|language= <!-- Language category code for non-English topics - e.g. Lang-Chinese -->
-|language=<!-- Language category code for non-English topics - e.g. Lang-Chinese -->
+|translated-by= <!-- [[User:XXXX]] -->
-|review-by=<!-- After re-review: [[User:username]] -->
+|translated-from-title= <!-- Title only -->
-|review-timestamp=<!-- After re-review: YYYYMMDD -->
+|translated-from-id= <!-- Id of translated revision -->
-|update-by=<!-- After significant update: [[User:username]]-->
+|review-by= <!-- After re-review: [[User:username]] -->
-|update-timestamp=<!-- After significant update: YYYYMMDD -->
+|review-timestamp= <!-- After re-review: YYYYMMDD -->
-|creationdate=20110630
+|update-by= <!-- After significant update: [[User:username]]-->
-|author=[[User:Mahbub s60]]
+|update-timestamp= <!-- After significant update: YYYYMMDD -->
 }}
 == Introduction ==
@@ Line 27: / Line 29: @@
 An NDEF message is composed of one or more NDEF records. There can be multiple records in a NDEF message.  Basically NDEF message is array of NDEF records. How many records we can encapsulate in a NDEF message that depends on our application and the tag type. For our analysis purposes we use only one NDEF records. This NDEF record stores
 <nowiki>http://nokia.com</nowiki>. Following figure shows the general view of NDEF message [1]. <br>
-[[Image:ndefrecod.png]]
+[[File:ndefrecod.png]]
 <br>
 When we communicate with our NFC reader devices (mobile phones) to read or write data to NFC tag we read basically (for example http: //nokia . com) the following hexa code.
@@ Line 40: / Line 42: @@
 NDEF records are variable length records with a common format illustrated in the figure below. <br>
 d1 is binary code (11010001) <br>
-[[Image:ndeftnf.png]]
+[[File:ndeftnf.png]]
   <br>
 In our case:<br>
@@ Line 46: / Line 48: @@
 ME = 1 (Message end, means it is last record in the NDEF message, if it is 0 that tells application that more records are ahead) <br>
 CF = 0 (means this is not chunked message, An NDEF message can contain zero or more chunked payloads. Each chunked payload is encoded as an initial record chunk followed by zero or more middle record chunks and finally by a terminating record chunk, in our case we simplify our record as not chunked) <br>
-SR = 1 (SR stands for short record, if set, that the payload length  field is a single octet.This short record layout is intended for compact encapsulation of small payloads which will fit within PAYLOAD fields of size ranging between 0 to 255 octets.) <br>
+SR = 1 (SR stands for short record, if set, that the payload length field is a single octet.This short record layout is intended for compact encapsulation of small payloads which will fit within PAYLOAD fields of size ranging between 0 to 255 octets.) <br>
 IL = 0(IL stands for identification length, if set, that the ID_LENGTH field is present in the header as a single octet. If the IL flag is zero, the ID_LENGTH field is omitted from the record header and the ID field is also omitted from the record) <br>
 TNF = 001(The TNF field value indicates the structure of the value of the TYPE field. The value 0x01 (NFC Forum well-known type) indicates that the TYPE field contains a value that
 follows the RTD type name format defined in the NFC Forum RTD specification ) <br>
-  [[Image:ndeffullrecod.png]]
+  [[File:ndeffullrecod.png]]
@@ Line 60: / Line 62: @@
 PAYLOAD field (the application payload). The size of the PAYLOAD_LENGTH field is determined by the value of the SR flag
 <br>
-(type  The value of the TYPE field is an identifier describing the type of the payload, The URI record type (“U”) )
+(type The value of the TYPE field is an identifier describing the type of the payload, The URI record type (“U”) )
 <br>
-x03  URI identifier <nowiki>(“http://”)</nowiki> <br>
+x03 URI identifier <nowiki>(“http://”)</nowiki> <br>
 <br>
 Pay Load <br>
@@ Line 73: / Line 75: @@
 == Qt Mobility TestApplication ==
-[[Image:Qttestapp.zip]]
+[[File:Qttestapp.zip]]
 <br> Modified example from Qt mobility example, address and corresponding NDEF messages are shown in the edit box <br>
-[[Image:ndefscreenshot.png]]
+[[File:ndefscreenshot.png]]
 <br>
@@ Line 82: / Line 84: @@
 . http://www.developer.nokia.com/info/sw.nokia.com/id/bdaa4a0f-fcf3-4a4b-b800-c664387d6894/Introduction_to_NFC.html <br>
 . http://www.nfc-forum.org/specs/[[Category:MeeGo]] [[Category:Symbian]]

@@ Line 81: / Line 81: @@
 == References ==
 . http://www.developer.nokia.com/info/sw.nokia.com/id/bdaa4a0f-fcf3-4a4b-b800-c664387d6894/Introduction_to_NFC.html <br>
-. http://www.nfc-forum.org/specs/
+. http://www.nfc-forum.org/specs/[[Category:MeeGo]] [[Category:Symbian]]

@@ Line 56: / Line 56: @@
 <br> Modified example from Qt mobility example, address and corresponding NDEF messages are shown in the edit box <br>
 Screenshot <br>
-[[Image:screenshot.png]]
+[[Image:ndefscreenshot.png]]
 <br>