NDEF (NFC Data Exchange Format) is the standardized binary message format that underpins Near Field Communication (NFC), enabling seamless data transfer between devices like smartphones, RFID tags, and readers. At the heart of every NDEF message are **NDEF records**—the fundamental building blocks that structure and transport data. To effectively use NFC technology, a clear grasp of NDEF record anatomy is essential.
### Key Components of an NDEF Record
An NDEF record consists of two core parts: a **header** and a **payload**. The header (8 bits long) acts as a “blueprint” for the record, containing four critical fields:
1. **TNF (Type Name Format)**: A 3-bit field defining how the record’s type is structured.
2. **Flags**: 5 bits that control record behavior (e.g., marking the start/end of a message).
3. **Type Length**: An 8-bit integer specifying the length of the type field.
4. **Payload Length**: An 8-bit integer indicating the payload’s byte count.
#### TNF: Structuring the Type Field
The TNF value dictates the format of the **type field** (which labels the payload’s data type). Common TNF values include:
– `TNF_NFCWELLKNOWN (0x01)`: Uses a standardized “well-known” type (e.g., “T” for text or “U” for URI).
– `TNF_MEDIATYPE (0x02)`: Follows MIME type conventions (e.g., `image/png`).
– `TNF_ABSURI (0x03)`: Represents an absolute URL (e.g., `https://example.com`).
– `TNF_EXTERNALTYPE (0x04)`: Supports custom types for niche applications.
This flexibility allows NDEF records to handle everything from simple text to complex application-specific data.
#### Flags: Controlling Record Behavior
The 5-bit flag field includes critical indicators:
– **MB (Message Begin)**: Marks the first record in an NDEF message.
– **ME (Message End)**: Marks the last record in a message.
– **SR (Short Record)**: Signals a payload under 255 bytes (simplifying length storage).
– **IL (ID Length)**: Indicates the presence of an optional ID field (for unique record identification).
#### Payload and Optional ID
The **payload** is the actual data being transported—any sequence of bytes, from a text string to sensor readings. If the IL flag is set, the record also includes an **ID field** (a unique byte sequence for record identification).
### A Simple NDEF Record Example
To tie these concepts together, consider this sample NDEF record:
“`
0001 0101 02 03 04 05 06 07
“`
Here’s how the header maps to data:
– TNF = `0x01` (NFC well-known type).
– Flags = `0x01` (MB flag set—first record in the message).
– Type Length = `0x01` (1 byte for the type field).
– Payload Length = `0x03` (3 bytes of payload data).
The type field is “02”, and the payload is “04 05 06″—a concise example of how header metadata translates to real data.
### Real-World Use Cases
NDEF records power practical NFC applications, from contactless payment tags to event access systems. For instance, **RFID wristbands at music festivals** use NDEF records to store attendee info, enabling fast entry and cashless transactions. Discover how these wristbands leverage NFC in practice at [RFID wristbands at music festivals](https://www.dorfidreader.com/rfid-wristbands-at-music-festivals/).
### Why NDEF Structure Matters
Mastering NDEF record structure is the first step to building interoperable NFC solutions. Whether you’re developing a smart tag or integrating NFC into a consumer device, understanding these basics ensures your applications work seamlessly across devices. From simple text records to multi-record messages, NDEF provides the flexibility to bring NFC ideas to life.
By breaking down the header, flags, type, and payload, you can unlock NFC’s full potential—and create experiences that are efficient, reliable, and user-friendly.
