The NFC Data Exchange Format (NDEF) is a standardized data format that can be used to exchange information between any compatible NFC device and another NFC device or tag. The data format consists of NDEF Messages and NDEF Records.
In this series of articles, I will explain how an NDEF message can be constructed and stored on an NFC tag. Assume a company wants to issue tags that can be used in public transport systems as a replacement for paper tickets. These tags can be tapped on an NFC-enabled Android device which will scan the tag and register the entry and exit time of the user. I won’t be going into how the application logic should be constructed but will be dealing with how the required data can be put on the tags.
Which NFC tag is recommended?
In my experience, I found Mifare Ultralight C to be suitable in most of the standard use-cases. Here’s a link to its datasheet which you might use when you start digging deeper into its specifications. If you are just getting started then you can buy the 10 pack of Mifare Ultralight C from Amazon or if you want to order in bulk then get the 100 pack instead.
Apart from Ultralight C, I found Mifare Classic 1k to be a great choice for some scenarios when your data size is larger. Here’s a link to its datasheet for more details. You can easily get a pack of 100 cards from Amazon.
In this article let's get an overview of how NDEF messages are constructed.
NDEF messages are the basic transport mechanism for NDEF records, with an NDEF message containing one or more NDEF records.
For this use case the tag primarily needs the following records on it:
- A user identifier, say username to identify the user.
- An application identifier, to tell the android system which app will be handling the NFC tag.
NDEF Records contain a specific payload and have the following structure that identifies the contents and size of the record. The basic elements that construct an NDEF record are:
- TNF ie. Type Name Format Field
typewhich is a value corresponding to bits set in the TNF field
- ID value
- payload value
More specifically an NDEF record can be composed in the following way.
Bit 7 6 5 4 3 2 1 0
------ ------ ------ ------ ------ ------ ------ ------
[ MB ] [ ME ] [ CF ] [ SR ] [ IL ] [ TNF ][ TYPE LENGTH ][ PAYLOAD LENGTH ][ ID LENGTH ][ RECORD TYPE ][ ID ][ PAYLOAD ]
NDEF record explained
An NDEF record starts with 8 bits header that describes the record.
TNF: The Type Name Format or TNF Field of an NDEF record is a 3-bit value that describes the record type.
IL [ID Length bit]: The IL flag indicates if the ID Length Field is present or not.
SR [Short Record bit]: The SR flag is set to 1 if the payload length field is 1 byte (8 bits/0–255) or less. This allows for more compact records.
CF [Chunk Flag bit]: The CF flag indicates if this is the first record chunk or a middle record chunk. For the 1st record of the message, it is set to 0 and for subsequent records, it is set to 1.
ME [Message End bit]: The ME flag indicates if this is the last record in the message. It is set to 1 for the last record.
MB [Message Begin bit]: The MB flag indicates if this is the first record in the message. It is set to 1 for the first message.
For our application, we need the following NDEF records.
- tnf: TNF_MIME_MEDIA,
- type: application/vnd.com.tickets [in bytes]
- id: null
- payload: byjwdH_6DNsuU4iTSrVaNEe6e52VLhhr4v_iGTRP7jQ= [in bytes]
Android Application Record(AAR)
- tnf: TNF_EXTERNAL_TYPE
- type: android.com:pkg [in bytes]
- id: null
- payload: com.example.tickets [in bytes]
While working on Android, the following constructor can be used to construct an
public NdefRecord (short tnf,
NdefRecord you can construct an
public NdefMessage (NdefRecord record,
We have seen an overview of the different parts of an NDEF message. In the next part of this article, we will see how these two NDEF records can be written on a tag using Android’s NFC capabilities.
We will also discuss the memory structure of two kinds of tags ie. Mifare Ultralight C and Mifare Classic.