RFID, NFC & UWB · Study deck

NFC Tag Programming

Picture a maintenance tag that opens the wrong asset record after it is fixed to a metal cabinet.

Radio Remi is your guide for this deck.

appsprogrammingtags

Radio Remi, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will be able to:

Plan URI, Text, MIME, and external-type NDEF records for an IoT tag without storing secrets in public payloads.
Check tag capacity, write state, and platform support before attempting a write.
Implement safe write patterns for Android, Python/nfcpy, and PN532-based embedded readers.
Verify a written tag by reading it back and validating the payload, type, length, and application policy.

Major section

Start With the Story

A writer's green tick is not enough.

The team must prove what a real phone reads in the final place.
An application programming interface is a defined way for software parts to request work; API is its short name.
Near field communication, or NFC, lets nearby devices exchange small records.

Major section

Checkpoint: Minimum Viable Understanding

Programming is not just writing bytes: A safe tag write includes record planning, capacity checks, write access checks, write, read-back verification, and a release record.

NDEF is public unless another layer protects it: Do not store passwords, access tokens, private keys, or one-time codes as ordinary NDEF text.
UIDs and NDEF records have different jobs: A UID can identify a tag, while an NDEF record can identify content or launch an app.
Tag memory is tight: Small Type 2 tags work well for one URL or compact app link; larger or protected records need a tag with explicit headroom.

Major section

Programming Workflow

The same workflow applies whether the writer is an Android phone, a USB reader, a Raspberry Pi, or a microcontroller with a PN532 module.

Its NDEF message is 38 bytes, so the chosen tag must be formatted, writable, and have enough capacity before the write.
A write-success flag alone cannot establish that the decoded URI is correct.

NFC tag programming workflow from record plan through capacity check, write, read-back validation, protection, and release evidence.

Major section

Programming Is Records Plus Lifecycle

Writing an NFC tag has two halves that are easy to blur.

A poster sticker anyone could overwrite and a tamper-resistant asset tag may use the same records but opposite lifecycle choices.
The team needs 80 labels.
The tag should not contain a technician password, service command, or bearer token.

NFC write and verify release workflow showing plan, inspect, write, read back, validate, protect or lock, and record evidence.

Major section

Programming Is Records Plus Lifecycle (continued)

Each tap should open one maintenance record, show a short human label, and let the app request authenticated service actions.

The tag selects context; the app and backend decide whether the current technician may do anything privileged.
That split gives you a release checklist.
A pass requires all fields to agree.

Major section

Programming Is Records Plus Lifecycle (continued)

During writing, reject tags that are read-only, already protected, too small, or not NDEF formatted.

Their combined 75 bytes are the expected message, not evidence of a physical tag capture.
After writing, decode both records from the tag and compare type, order, host, asset ID, language, text, and lengths with the plan.
The release record then adds tag batch, protection state, app version, target surface, and replacement plan.

Major section

NDEF Record Planning

NDEF messages can contain multiple records, but a good programming workflow keeps the record set small and predictable.

The first record sets MB and the last sets ME, while SR declares a payload below 256 bytes and IL declares an optional ID field.
The writer must size and verify those fields before committing the tag.

An NDEF message orders records whose headers define boundaries, short payloads, optional identifiers, and type interpretation.

Major section

Record Types and Validation Rules

The record type determines both the platform behavior and the validation rule.

A message can hold several records, and order matters: the first record usually drives the primary action while later records act as fallbacks or hints.
A "tap to open the app, or the web page if the app is missing" tag is one multi-record message, not two unrelated tags.
For a batch station, make the checks mechanical.

Major section

PN532 Embedded Reader Pattern

An embedded reader is usually better for reading and validating tags in a product flow than for mass programming.

If it writes tags, keep the write flow supervised and include verification.
The printed loop antenna must couple to the tag before any NDEF read or write can be judged.

A PN532 reader board combines the controller and the loop antenna that must couple to the tag. Its physical orientation, read distance, nearby metal, selected I2C or serial interface, and exact driver version all belong beside the supervised read/write flow below. Photo: oomlout, CC BY-SA 2.0

Major section

Write and Verify Loop

The worked message has URI then Text records and totals 75 bytes; capacity and lock bits must be checked before writing.

A mismatch is a reject path, not a reason to protect the tag.
Protect: Lock or password-protect only after read-back passes and the replacement process is documented.

NFC write and verify loop showing detect, inspect capability, write, read back, compare expected records, protect tag, and record release evidence.

Major section

Lock Bits and Password Protection on NTAG

NTAG213, NTAG215, and NTAG216 provide roughly 144, 504, and 888 bytes of user memory, respectively.

Their memory model gives you two different write controls, and confusing them creates deployment bugs.
Static and dynamic lock bits are one-way; once a page is locked, it cannot be rewritten.

The lock bytes and PWD/PACK registers described above live on a chip like this one -- once the lock bits on a physical tag like this are set, no software update can reverse them, which is why the read-back step before locking matters so much. Photo: HenryWortel, CC BY-SA 4.0

Major section

Lock Bits and Password Protection on NTAG (continued)

Password protection uses a 32-bit PWD and a 16-bit PACK acknowledgement to gate writes, or sometimes reads, behind a shared secret.

An authorized writer can still update the tag, so this protects an update process rather than freezing content.
"Make this tag safe" therefore has two different answers.
Lock it if the content is final and must never change.
The security boundary is narrower than many product sketches imply.

Major section

Lock Bits and Password Protection on NTAG (continued)

Password-protect it if it must stay updatable by staff but not by the public.

NTAG21x also exposes a one-way NFC counter and a Capability Container that a reader checks first to learn the memory size and whether the tag is already read-only.
The Capability Container is why a careful writer inspects the tag before writing instead of blasting records at every UID it sees.
If a public poster tag is locked before read-back and the URL has a typo, the mistake becomes permanent.

Major section

Debugging Map

When a tag does not work, isolate the failure layer before changing code.

If RF coupling works, check the tag's NDEF support, capacity, and write state.
A formatting error and a read-back type mismatch are separate failures with different fixes.

NFC tag programming debugging map separating reader interface, RF coupling, tag capability, NDEF format, app validation, and deployment surface issues.

Major section

Checkpoint: Summary

Android, Python, and PN532-based readers can all support tag work, but each needs explicit capacity, write-state, and error handling.

NDEF records are useful for interoperability but should be treated as untrusted public input.
Tag selection depends on payload size, write lifecycle, environment, phone support, and security needs.
Production tags need field evidence from the final mounting surface and target reader devices.

Deck summary

Key takeaways

A writer's green tick is not enough.

Programming is not just writing bytes: A safe tag write includes record planning, capacity checks, write access checks, write, read-back verification, and a release record.
The same workflow applies whether the writer is an Android phone, a USB reader, a Raspberry Pi, or a microcontroller with a PN532 module.
Writing an NFC tag has two halves that are easy to blur.
Each tap should open one maintenance record, show a short human label, and let the app request authenticated service actions.

Retrieval practice

Recall check 1 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q1After a maintenance app writes a URL and label to an NFC tag, what is required before reporting the write as successful?

AImmediately lock the tag so that no one can ever change its contents again.

BRead back the tag and verify records, host, length, and asset ID.

CTrust the writer app's success flag and move straight on to the next tag.

DDelete the NDEF records afterward to save the tag's limited memory.

Show answer

Answer: B A safe NFC write reads the tag back and verifies the records before it is reported successful or locked.

Retrieval practice

Recall check 2 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q2A museum deploys NFC poster tags whose URL must never be altered by visitors, but staff must update a separate tag batch each week. Which memory controls fit the two cases?

APassword-protect poster tags and lock staff tags read-only.

BLock poster tags; use PWD/PACK protection for staff tags.

CLock both sets of tags because locking is the only real protection.

DRely on a URI record because NDEF records cannot be overwritten.

Show answer

Answer: B NTAG lock bits set pages permanently read-only, while PWD/PACK password protection gates writes reversibly; freeze final content with lock bits and keep updatable content behind a password.

Retrieval practice

Recall check 3 of 3

Radio Remi says: answer from memory, then check your reasoning.

Q3A maintenance app writes a URL and short text label to an NFC tag. Which step is required before the app shows the write as successful?

ARead back and verify record count, types, host, length, and asset ID

BAssume success after writeNdefMessage returns because NFC writes are atomic

CLock the tag first, then write the NDEF message so the payload cannot be changed

DStore the technician password in a Text record so the tag can prove authorization offline

Show answer

Answer: A A safe programming workflow does not stop at the write call.

Print reference

Answers

Answer key.

B · A safe NFC write reads the tag back and verifies the records before it is reported successful or locked.
B · NTAG lock bits set pages permanently read-only, while PWD/PACK password protection gates writes reversibly; freeze final content with lock bits and keep updatable content behind a password.
A · A safe programming workflow does not stop at the write call.