Standards Map

NFC is not one protocol; it is a family of layers. This is the practical map for POOM testing:

Family	Main Standard	Common Name	Typical Usage
Proximity A	ISO/IEC 14443-A	NFC-A	MIFARE / NTAG / many access cards
Proximity B	ISO/IEC 14443-B	NFC-B	Transport, secure ID cards
Proximity Transport	ISO/IEC 14443-4	ISO-DEP	APDU exchange (Type 4 style flows)
FeliCa	JIS X 6319-4 / NFC-F	NFC-F	Transit and wallet ecosystems
Vicinity	ISO/IEC 15693	NFC-V	Longer-range inventory tags
Peer-to-Peer	ISO/IEC 18092	NFC-DEP	Device-to-device modes
NFC Forum Tag Types	Type 1/2/3/4/5 mapping	Tag Type Model	Interoperability profile for apps

NFC Types Explained (Complete Catalog)

What Is ISO/IEC in NFC?

ISO/IEC standards define the low-level technical behavior of cards and readers (radio signaling, activation steps, transport rules). In short: ISO tells devices how to talk at protocol level.

Protocol Families You Will See in Labs

Standard / Name	Plain Explanation	Typical Cards/Tags	POOM Test Entry
ISO/IEC 14443-A (NFC-A)	Most common short-range contactless path at 13.56 MHz.	NTAG, MIFARE Ultralight, many MIFARE-family badges	nfc-a, nfc-scan, nfc-connect
ISO/IEC 14443-B (NFC-B)	Alternative modulation/activation path used by many secure ID ecosystems.	Some transit/government/enterprise secure cards	nfc-b, nfc-scan, nfc-connect
ISO/IEC 14443-4 (ISO-DEP)	Transport layer for APDU exchanges after activation on A or B.	Type 4 style cards, smartcard applets, secure elements	nfc-connect, nfc-send
JIS X 6319-4 (NFC-F / FeliCa)	FeliCa family, often used in high-speed transit/payment environments.	FeliCa cards and mobile wallets in those ecosystems	nfc-f, nfc-scan
ISO/IEC 15693 (NFC-V)	Vicinity cards with generally longer working distance than 14443 tags.	Inventory, asset, and industrial tags	nfc-v, nfc-scan
ISO/IEC 18092 (NFC-DEP)	Peer-to-peer device mode (device talks to device, not only reader to tag).	Device-to-device NFC workflows	Not enabled in this build (see capabilities below)

Complete Device Type Catalog (Scanner Labels)

This is the full practical list of tag/card labels you asked for, with what they mean and how POOM can test them today.

Device Type Label	What It Means	Underlying Family	POOM Lab Coverage
ISO14443-3A	Type A activation/anticollision/select layer.	ISO/IEC 14443-A (Part 3)	Full detect/connect validation with nfc-a, nfc-scan, nfc-connect.
ISO14443-3B	Type B activation and slot/attribution flow.	ISO/IEC 14443-B (Part 3)	Full detect/connect validation with nfc-b, nfc-scan, nfc-connect.
ISO14443-4A	ISO-DEP transport over Type A.	ISO/IEC 14443-4 on A	APDU path testing via nfc-connect + nfc-send.
ISO14443-4B	ISO-DEP transport over Type B.	ISO/IEC 14443-4 on B	APDU path testing via nfc-b + nfc-connect + nfc-send.
ISO15693-3	Vicinity command layer and inventory model.	ISO/IEC 15693 (NFC-V)	Discovery/reliability testing with nfc-v and repeated scans.
FeliCa	FeliCa ecosystem cards (fast transit/wallet style flows).	NFC-F / JIS X 6319-4	Discovery and session stability tests with nfc-f.
NTAG/Ultralight	NXP Type 2 style tags (stickers/cards, often NDEF payloads).	NFC-A + Type 2 model	Strongest current POOM flow: detect, read, dump, and MFUL-style emulator tests.
Mifare Classic	Legacy MIFARE family with proprietary security model.	NFC-A (non-ISO-DEP app model)	Detect/classify and classic-specific read workflows where keys/access permit.
Mifare DESFire	Smartcard-style MIFARE family with APDU application model.	Usually ISO-DEP (Type 4 style)	Best tested through ISO-DEP/APDU behavior using nfc-connect + nfc-send.
SLIX	NXP ICODE SLIX vicinity tags.	ISO/IEC 15693 (NFC-V)	Treat as NFC-V in POOM; validate inventory/read stability and UID consistency.
ST25TB	ST proprietary 13.56 MHz family (separate from normal Type 2/4/5 flows).	ST25TB family	Currently not enabled in this build (RFAL ST25TB stack is disabled).
EMV	Contactless payment profile (reader/card app protocol profile).	ISO14443 + ISO-DEP + EMV app rules	Only authorized APDU-level interoperability testing; never use on real payment systems without explicit authorization.

NFC Forum Tag Types (App Compatibility Model)

NFC Forum Tag Types are not new radios; they are compatibility profiles that tell apps how memory and NDEF are organized.

Tag Type	Usually Based On	Practical Meaning	POOM-Oriented Test
Type 1	NFC-A	Legacy simple tags with small memory.	Basic detect/read behavior if present in your environment.
Type 2	NFC-A	Very common tag profile for URLs, small records, and mass-market labels.	nfc-a + nfc-connect + read probe (for example nfc-send 30 04).
Type 3	NFC-F (FeliCa)	Transit-style high-performance profile in FeliCa ecosystems.	nfc-f scans and stability checks.
Type 4	ISO-DEP on NFC-A or NFC-B	File/application model with APDU exchange; common in secure apps.	nfc-connect + APDU tests with nfc-send.
Type 5	NFC-V (ISO/IEC 15693)	Longer-range NFC tag profile for vicinity scenarios.	nfc-v discovery and repeated read reliability tests.

What Is NTAG?

NTAG is an NXP chip family commonly used as NFC stickers/cards. Most NTAG21x tags are NFC Forum Type 2 and run on ISO/IEC 14443-A (NFC-A).

Lab expectation with POOM: NTAG tags are usually the easiest place to start for scan/connect/read tests and simple emulator interoperability checks.

What About MIFARE?

MIFARE is a product family name, not one single protocol. Different MIFARE lines map to different capabilities:

• MIFARE Ultralight: typically Type 2 style behavior on NFC-A (close to NTAG-like lab flows).
• MIFARE Classic: legacy NFC-A card family with proprietary security model (behavior may differ from pure NFC Forum flows).
• MIFARE DESFire: smartcard-style family that commonly uses ISO-DEP and APDU workflows.

NFC Protocol Deep Dive (Lab-Ready)

For POOM testing, break NFC into three phases: discovery, activation, and transport. If you validate those three phases, you validate most real-world NFC behavior.

Phase 1: Discovery and Selection (Type A)

• REQA/WUPA -> ATQA: the reader asks if any Type A card is in field, and the card answers with basic capability info.
• Anticollision (93 20): resolves collisions and reads UID bytes when multiple tags are present.
• Select (93 70 ...): confirms which card is selected and returns SAK, which signals what comes next.

Phase 2: Discovery and Selection (Type B)

• REQB -> ATQB: discovers Type B cards and receives PUPI plus protocol data.
• ATTRIB: chooses one PICC (using PUPI) and moves into active communication state.

Phase 3: ISO-DEP Transport

• RATS -> ATS: negotiates transport parameters (frame size, timing, optional features).
• PPS (optional): can request bitrate changes for faster exchange.
• I/R/S blocks: APDU traffic is encapsulated into block-level frames with chaining, retransmission, and wait-time control.

Protocol Signal	What You Should Interpret	POOM Command Touchpoint
ATQA / ATQB	Tag family and early compatibility clues.	nfc-scan, nfc-tech
SAK	Selection result and whether higher-layer exchange is expected.	nfc-connect
ATS	Frame sizing and timing behavior for data sessions.	nfc-connect, nfc-send
I/R/S Block behavior	Chaining, retries, and wait-time handling under real loads.	nfc-send, repeated transaction tests

How To Read POOM NFC Scan Output

A full NFC result usually has three layers: activation frames, parsed card identity, and optional dump-file content.

Layer 1: Activation Frames (What Happened on RF)

[TX] REQA (26)
[RX] ATQA: 04 00
[TX] 93 20
[RX] B9 17 D9 03 74
[TX] 93 70 B9 17 D9 03 74
[RX] 08
ISO/IEC 14443-A card detected

Line	Meaning	Why It Matters
[TX] REQA (26)	Reader requests any Type A tag in field.	Start of ISO14443-A discovery.
[RX] ATQA: ...	Tag answers with Type A capability bits.	Confirms tag family and early capability hints.
[TX] 93 20	Anticollision command (Cascade Level 1).	Requests UID bytes from one candidate tag.
[RX] B9 17 D9 03 74	UID fragment + BCC integrity byte.	Builds unique card identity.
[TX] 93 70 ...	Select command with UID/BCC.	Moves from discovery to selected target.
[RX] 08	SAK (Select Acknowledge).	Finalizes selection and helps type classification.

Layer 2: Parsed Card Identity (Human-Friendly)

Field	Interpretation
Version: 4	Dump/header format version for a file schema (not the NFC radio protocol version).
Device type: NTAG/Ultralight	Detector classification based on UID/ATQA/SAK and extra reads.
UID: 04 A7 8B 62 C2 1B 90	7-byte unique identifier used across all later sections.
ATQA / SAK	Type A activation fingerprints used for card-family hints.
NTAG/Ultralight type: NTAG213	Specific product-family detection.
Signature	Tag originality signature bytes (chip-level authenticity data).
Mifare version: 00 04 04 02 01 00 0F 03	Chip version response used by detectors to refine product identification.
Counter / Tearing	Monotonic counters and anti-tearing status bytes when available.

Layer 3: Memory Pages (What Comes In The File)

For NTAG213, Pages total: 45 means page index 0..44, each page = 4 bytes.

Page Range	Typical Meaning
Page 0-2	Manufacturer block, UID/BCC, internal bytes, static lock bytes.
Page 3	Capability Container (for example E1 10 12 00 for Type 2 formatting cues).
Page 4-39	User/NDEF area (payload records, terminator FE, remaining free bytes).
Page 40-44	Dynamic lock/config/auth-related pages depending on tag setup.

POOM dump files keep this as readable lines like Page N: XX XX XX XX, so you can diff two captures and immediately see what changed.

POOM Native .nfc File Sections

• Header: filetype + dump schema version.
• Capture metadata: reader, read mode, read status.
• Tag identification: protocol, device type guess, UID, ATQA, SAK.
• Technology-specific info: manufacturer, subtype, signature, version bytes.
• Memory layout + security: page counts, user memory range, lock/config pages.
• Raw memory dump: full per-page hex lines.

Type A Activation Flow (What To Test)

Stage	Example Frame	Why It Matters
Presence Check	REQA (0x26) -> ATQA	Confirms a Type A PICC is in field and responding.
Anticollision CL1	93 20 -> UID0 UID1 UID2 UID3 BCC	Recovers UID bytes and avoids collision with multiple tags.
Select CL1	93 70 + UID/BCC -> SAK	Moves from UID discovery to selected card state.
ISO-DEP Request	E0 00 -> ATS	Starts Part 4 transport and negotiates frame parameters.
Bitrate Negotiation (Optional)	D0 ... (PPS)	Requests communication speed changes when supported.

Type B Activation Flow (What To Test)

Stage	Example Frame	Why It Matters
Presence / Slot Request	REQB (0x05) + AFI/PARAM -> ATQB	Finds Type B cards and returns PUPI + capability data.
Attribution	ATTRIB (0x1D) + PUPI ...	Selects the PICC and prepares it for ISO-DEP exchanges.
Transport Entry	I/R/S blocks (Part 4)	Runs APDU traffic over the negotiated Type B link.

ISO-DEP Block Model (Part 4)

After activation, traffic is carried in ISO-DEP blocks:

• I-Block: carries application payload (for example APDUs), supports chaining for long payloads.
• R-Block: ACK/NAK style flow control, used to request retransmission or next chained segment.
• S-Block: session control, including wait-time extension (WTX) and deselection.

POOM commands such as nfc-connect and nfc-send are where you validate this behavior at lab level.

POOM Capabilities (Current Build)

From the active RFAL/platform configuration in this repo:

• Enabled: NFC-A, NFC-B, NFC-F, NFC-V, Listen Mode, ISO-DEP (poll + listen), T4T flow.
• Disabled: NFC-DEP (P2P), ST25TB RFAL stack, Topaz/T1T, RFAL T2T module.
• Special app-layer behavior: MFUL mode is available in emulator (nfc-emul-set mode mful) and expects a 64-byte image file.

Lab Playbooks

Playbook 1: Multi-tech Discovery

nfc-start
nfc-all
nfc-tech
nfc-scan
nfc-stop

Goal: discover what card technologies are present in your environment before going deep on one target.

What to look for: stable detection output (for example NFC-A vs NFC-B) across repeated scans.

If it fails: check tag distance/orientation first, then verify RF is enabled with nfc-start and retry with fewer tags nearby.

Playbook 2: Focused NFC-A Session

nfc-start
nfc-a
nfc-scan
nfc-connect
nfc-send 30 04
nfc-stop

Goal: force an NFC-A-only test path and validate active communication after connect.

What to look for: successful nfc-connect and a non-empty response to nfc-send 30 04.

If it fails: confirm the tag is actually Type A and not locked/protected; then retry using a known-good NFC-A test card.

Playbook 3: Structured Tag Capture to SD

nfc-start
nfc-a
nfc-dump-sd 5000
nfc-stop

Goal: collect reproducible tag captures for later analysis and regression tests.

What to look for: successful dump completion and a new file written under /sdcard/nfc_dumps.

If it fails: verify SD mount/space and ensure the read window (5000 ms here) is long enough for stable capture.

Output path format: /nfc_dumps/nfc_<uid>_<timestamp>_<n>.nfc, stored on SD under /sdcard.

Playbook 4: Emulation From Last Scan Snapshot

nfc-start
nfc-a
nfc-connect
nfc-emul-set-from-last-scan
nfc-emul-start
nfc-emul-stop
nfc-stop

Goal: quickly pivot from read mode to emulation using the most recently observed tag profile.

What to look for: emulator starts without config errors and external reader detects the emulated target.

If it fails: ensure a valid scan/connect happened right before nfc-emul-set-from-last-scan.

Playbook 5: Type 4 URI Emulation

nfc-emul-reset
nfc-emul-set mode t4t
nfc-emul-set uri https://example.org/lab
nfc-start
nfc-emul-start
nfc-emul-stop
nfc-stop

Goal: emulate a Type 4 tag that delivers a URI payload to reader devices.

What to look for: phones or reader apps should resolve exactly the configured URI.

If it fails: test with a second reader app/device to rule out app-side parsing issues before changing POOM config.

Playbook 6: MFUL Image Emulation

nfc-emul-reset
nfc-emul-set mode mful
nfc-emul-set image /sdcard/path/to/mful_64b.bin
nfc-start
nfc-emul-start
nfc-emul-stop
nfc-stop

Goal: emulate a fixed MFUL memory image for deterministic QA and compatibility checks.

What to look for: consistent page reads from the external reader across repeated sessions.

If it fails: re-check file path and exact 64-byte image size; this mode expects a raw binary image, not a text dump.

Practical Test Examples With POOM

Example 1: Unknown Badge Profiling

nfc-start
nfc-all
nfc-tech
nfc-scan-loop 1000 10
nfc-stop

Use this to classify field behavior over repeated scans. You can detect unstable reads, changing UIDs, or inconsistent technology detection.

Example 2: Type A Session + Read Probe

nfc-start
nfc-a
nfc-connect
nfc-send 30 04
nfc-stop

This verifies that discovery and selection completed correctly and that the active data path responds to a basic read-style command.

Example 3: Type 4/NDEF Path Validation

nfc-start
nfc-a
nfc-connect
nfc-send 00 A4 04 00 07 D2 76 00 00 85 01 01
nfc-stop

If the target supports Type 4/NDEF application selection, this confirms APDU transport is working end-to-end over ISO-DEP.

Example 4: Emulation Acceptance Test (Phone Reader)

nfc-emul-reset
nfc-emul-set mode t4t
nfc-emul-set uri https://example.org/lab
nfc-start
nfc-emul-start
nfc-emul-stop
nfc-stop

Present POOM to a phone reader app and confirm the URI appears exactly as configured. This validates listen mode, emulation config, and reader interoperability together.

Example 5: MFUL Regression Test

nfc-emul-reset
nfc-emul-set mode mful
nfc-emul-set image /sdcard/path/to/mful_64b.bin
nfc-start
nfc-emul-start
nfc-emul-stop
nfc-stop

Use your own 64-byte MFUL image and verify expected page reads from a known-good reader workflow. This is useful for repeatable emulator QA.

Command Reference (High-Value)

Goal	Command
Initialize core	nfc-start
Select tech filter	nfc-all, nfc-a, nfc-b, nfc-f, nfc-v
Scan tags	nfc-scan, nfc-scan-loop <period_ms> <count> [timeout_ms]
Activate session	nfc-connect
Raw send (active tag)	nfc-send <hex...>
Dump to SD	nfc-dump-sd [timeout_ms]
Emulation config	nfc-emul-show, nfc-emul-reset, nfc-emul-set ...
Start/stop emulation	nfc-emul-start [stored_index], nfc-emul-stop
RF tuning	nfc-tune-auto, nfc-tune-get, nfc-tune-set <aat_a> <aat_b>
Debug RF	nfc-reqa, nfc-wupa, nfc-raw, nfc-regdump

NFC Validation Checklist

• Verify REQA/ATQA and select flow for Type A tags.
• Verify REQB/ATQB/ATTRIB flow for Type B cards.
• Capture ATS data and check expected frame-size negotiation behavior.
• Send short and long payloads to confirm ISO-DEP chaining and block handling.
• Test emulation modes (t4t and mful) with real reader apps in a controlled environment.

Next Step in POOM LABS

After validating these NFC playbooks end-to-end, continue with the Technologies Matrix to map and prioritize the next POOM LABS tracks (BLE, Wi-Fi, capture, web, storage, and device modules).