×
Namespaces

Variants
Actions
(Difference between revisions)

Understanding NFC Data Exchange Format (NDEF) messages

From Nokia Developer Wiki
Jump to: navigation, search
hamishwillee (Talk | contribs)
m (Hamishwillee - Bot update - Fix Article Metadata and other minor issues)
hamishwillee (Talk | contribs)
m (Hamishwillee - Add Abstract. Tidy wiki text)
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]]
 +
{{Abstract|This article explains the structure of a NDEF message with simple uniform resource identifier (URI) that describes web page address.}}
 +
 
 
{{ArticleMetaData <!-- v1.2 -->
 
{{ArticleMetaData <!-- v1.2 -->
 
|sourcecode= [[Media:Qttestapp.zip]]
 
|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.  
 
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   
<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]]
 
[[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.
 
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
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.
<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>
03 <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)  
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>
+
 
[[File:ndeftnf.png]]
 
[[File: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>
 
[[File:ndeffullrecod.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 <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 ==
 
== Qt Mobility TestApplication ==
  
 
[[File: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]]
 
+
[[File: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:MeeGo]] [[Category:Symbian]]
+
[[Category:Code Examples]]
+

Revision as of 13:05, 23 February 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 (23 Feb 2012)

Contents

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 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.

Qt Mobility TestApplication

File:Qttestapp.zip

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

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/
2308 page views in the last 30 days.
×