Namespaces

Variants
Actions

Please note that as of October 24, 2014, the Nokia Developer Wiki will no longer be accepting user contributions, including new entries, edits and comments, as we begin transitioning to our new home, in the Windows Phone Development Wiki. We plan to move over the majority of the existing entries over the next few weeks. Thanks for all your past and future contributions.

(Difference between revisions)

Understanding NFC Data Exchange Format (NDEF) messages

From Wiki
Jump to: navigation, search
mahbub_s60 (Talk | contribs)
(Mahbub s60 -)
hamishwillee (Talk | contribs)
m (Hamishwillee - Fix layout)
 
(8 intermediate revisions by 2 users not shown)
Line 1: Line 1:
[[Category:Java ME]][[Category:Qt]][[Category:Qt Mobility]][[Category:Symbian C++]]
+
[[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.}}
 +
 
 +
{{ArticleMetaData <!-- v1.2 -->
 +
|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'') -->
 +
|sdk= <!-- SDK(s) built and tested against (e.g. [http://linktosdkdownload/ Nokia Qt SDK 1.1]) -->
 +
|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 -->
 +
|capabilities= <!-- Capabilities required by the article/code example (e.g. Location, NetworkServices. -->
 +
|keywords= <!-- APIs, classes and methods (e.g. QSystemScreenSaver, QList, CBase -->
 +
|language= <!-- Language category code for non-English topics - e.g. Lang-Chinese -->
 +
|translated-by= <!-- [[User:XXXX]] -->
 +
|translated-from-title= <!-- Title only -->
 +
|translated-from-id= <!-- Id of translated revision -->
 +
|review-by= <!-- After re-review: [[User:username]] -->
 +
|review-timestamp= <!-- After re-review: YYYYMMDD -->
 +
|update-by= <!-- After significant update: [[User:username]]-->
 +
|update-timestamp= <!-- After significant update: YYYYMMDD -->
 +
|creationdate= 20110630
 +
|author= [[User:Mahbub s60]]
 +
}}
 
== Introduction ==
 
== 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.
 
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.
 
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 ==  
 
== 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.  
 
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   
 
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   
http://nokia.com. 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>.  
[[Image: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>
+
03 0e d1 01 0a 55 03 6e 6f 6b 69 61 2e 63 6f 6d fe
+
<br>
+
03 <br>
+
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<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>
+
[[Image:ndeftnf.png]]
+
<br>
+
In our case:<br>
+
MB = 1 (message Begin is true means this is first record in the NDEF message) <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) <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>
+
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:ndefrecod.png|none]]
 +
 +
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.
 +
03 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.
 +
* 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>
 +
* d1 - NDEF records are variable length records with a common format illustrated in the figure below.
 +
d1 is binary code (11010001)
 +
[[File:ndeftnf.png]]
 
   
 
   
01 (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)
0A (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)
55 (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.
03
+
* 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
0x03 URI identifier (“http://”) <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 ==
 
== 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>
+
[[File:ndefscreenshot.png|none|frame|Modified example from Qt mobility example, address and corresponding NDEF messages are shown in the edit box]]
Screenshot <br>
+
[[Image:ndefscreenshot.png]]
+
<br>
+
  
 
== References ==
 
== References ==
1. http://www.developer.nokia.com/info/sw.nokia.com/id/bdaa4a0f-fcf3-4a4b-b800-c664387d6894/Introduction_to_NFC.html <br>
+
<references />
2. http://www.nfc-forum.org/specs/
+
 
+
 
+
 
+
 
+
[[Category:Near Field Communication (NFC)]]
+

Latest revision as of 06:00, 27 November 2012

This article explains the structure of a NDEF message with simple uniform resource identifier (URI) that describes web page address.

Article Metadata
Code Example
Source file: Media:Qttestapp.zip
Compatibility
Platform(s):
Symbian
Article
Created: mahbub_s60 (30 Jun 2011)
Last edited: hamishwillee (27 Nov 2012)

Contents

[edit] 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.

[edit] 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 http://nokia.com. Following figure shows the general view of NDEF message[1][2].

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.

03 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.
  • 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.
  • d1 - NDEF records are variable length records with a common format illustrated in the figure below.
d1 is binary code (11010001) 

Ndeftnf.png

In our case:

  • MB = 1 (message Begin is true means this is first record in the NDEF message)
  • 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)
  • 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)
  • 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.)
  • 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)
  • 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)
    Ndeffullrecod.png
  • 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
  • 55 (type The value of the TYPE field is an identifier describing the type of the payload, The URI record type (“U”) )
  • 03 - 0x03 URI identifier (“http://”)
  • Pay Load - The rest of the string in UTF-8 (nokia.com)
  • FE Terminator byte. This is final byte added by platform.

[edit] Qt Mobility TestApplication

File:Qttestapp.zip

Modified example from Qt mobility example, address and corresponding NDEF messages are shown in the edit box

[edit] References

  1. http://www.developer.nokia.com/info/sw.nokia.com/id/bdaa4a0f-fcf3-4a4b-b800-c664387d6894/Introduction_to_NFC.html
  2. http://www.nfc-forum.org/specs/
This page was last modified on 27 November 2012, at 06:00.
1952 page views in the last 30 days.

Was this page helpful?

Your feedback about this content is important. Let us know what you think.

 

Thank you!

We appreciate your feedback.

×