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

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 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.
The conclusion depends on payload/test/owner.

Major section

Programming Is Records Plus Lifecycle (continued)

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

Work through it with: Writing is a release workflow as one fact, decode records as another, and payload/test/owner as the closeout.
Combining: Writing is a release workflow with decode records hides accountability.
The most common design error is treating the write command's success flag as the release event.

Major section

NDEF Record Planning

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

When reviewing ndef record planning, locate: NDEF Message Container beside bit 5 on it.: Any type makes the purpose concrete.
Both: NDEF Message Container and bit 5 need evidence.
Include a version field and reject unknown schemas.

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 pictured: PN532 RFID/NFC Shield marking makes setup reproducible.

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

Both one stable tag and decode records need evidence.

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.

To make debugging map reviewable, find the boundary between: USB/I2C/SPI/UART driver and type/capacity/write state on it.: Fix earliest failing layer first identifies the later check.
Both: USB/I2C/SPI/UART driver and type/capacity/write state need evidence.

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

Major section

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.
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.
During writing, reject tags that are read-only, already protected, too small, or not NDEF formatted.

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?

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

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

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: A 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?

AAssume success after writeNdefMessage returns because NFC writes are atomic

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

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: B 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.
A · 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.
B · A safe programming workflow does not stop at the write call.