Multi-Tag Polling and Collision Resolution

Reading Multiple Tags in the Field

How NFC readers handle multiple tags in the RF field: anticollision algorithms, polling loop configuration, and multi-tag applications.

| 6 min read

Multi-Tag Polling and Collision Resolution

Most NFC applications expect exactly one tag in the field at a time. But transit gates, retail checkouts, and industrial conveyor readers regularly encounter multiple tags simultaneously. Understanding how the anti-collision protocol works — and how to build applications that handle it correctly — prevents the silent data loss and missed reads that occur in multi-tag environments.

Why Multi-Tag Collisions Happen

When two or more NFC tags respond to a REQA simultaneously, their signals overlap in the RF field. The reader's analog front end sees the sum of two modulated signals, which generally produces an unintelligible waveform. Without an anti-collisionanti-collisionCommunicationProtocol for selecting individual tags from multiple in RF fieldClick to view → protocol, neither card would be read successfully.

The 13.56 MHz RF field for NFC has a spatial extent of approximately 10 cm from the reader antenna. Any tag within this volume responds to a REQA. In a wallet with two contactless cards, a conveyor with boxed product, or a stack of printed NFC labels, multiple tags will be in the field simultaneously.

ISO 14443-A: Bit-Frame Anti-Collision

Type A (NFC-A) resolves collisions with a bit-level tree-walking algorithm. The reader sends a SELECT command with a partial UID and an NVB (Number of Valid Bits) field specifying how many bits of the UID prefix are supplied. Only cards whose UID matches that prefix respond.

Algorithm steps:

1. REQA → all cards respond with ATQA
2. If collision detected in ATQA:
   a. Reader selects bit position of first collision
   b. Reader sends SELECT with prefix = bits before collision
   c. Cards not matching prefix remain silent
   d. Repeat until single card responds without collision
3. SELECT (full UID) → SAK received → card activated
4. Activated card goes into HALT state after transaction
5. Reader restarts with REQA (WUPA to also wake halted cards)

Cascade levels: A single-byte NVB specifies bits known; up to 96 bits of UID may be transmitted across up to 3 cascade levels. Each level resolves up to 32 bits of UID, and cascade tag 0x88 signals that more levels follow.

Collision bit detection: In NFC-A, the reader and card use modified Miller codingmodified Miller codingCommunicationBit encodingencodingManufacturingData writing to NFC tags during manufacturing productionClick to view → for NFC-A reader-to-tag communicationClick to view →. A collision at a specific bit position appears as a bit period where the reader detects energy but no valid edge transition — the two overlapping signals cancel or create an unrecognisable waveform. The reader hardware marks the bit position as "collision" and sets a 0 or 1 to select one branch of the binary tree.

ISO 14443-B: Time-Slot Anti-Collision

Type B (NFC-B) uses a different approach: probabilistic time-slot allocation. The reader sends an REQB with a parameter N, defining the number of slots (1, 2, 4, 8, or 16). Each card in the field picks a random slot number and responds only in that slot.

Reader: REQB(N=4)
Slot 1: [silence]
Slot 2: Card A responds with ATQB
Slot 3: [collision — Cards B and C responded simultaneously]
Slot 4: [silence]
Reader: REQB(N=2) [resolve slot 3 collision with smaller set]
...

With N=16, the probability of a collision between two cards is 1/16 per slot — meaning even in a 10-card field, 90%+ of cards are resolved in the first pass. Unresolved slots are retried with further REQB commands.

ISO 15693: Time-Slot with Address

ISO 15693 (NFC-V) uses 1-of-16 or 1-of-256 slot-based anti-collision with optional mask-length addressing. Up to 256 tags can be inventoried in a single transaction cycle using addressed slot selection.

This is why ISO 15693 tags are preferred for conveyor reading and bulk inventory: the wider slot space and larger read rangeread rangeHardwareMaximum communication distance between reader and tagClick to view → (up to 1 m) allow a fixed reader to inventory an entire pallet without individual positioning.

Software Multi-Tag Handling

Android

Android's NFC stack resolves anti-collision at the OS level — your application receives one NfcTag object per ACTION_TAG_DISCOVERED intent. You cannot enumerate all tags in the field from the Android public API without root access.

To read multiple tags sequentially, your app must:

  1. Process the first tag (received via intent)
  2. Complete transaction and call close() on the tag
  3. Wait for the next ACTION_TAG_DISCOVERED intent (the OS will re-poll)

For bulk reading in an Android kiosk scenario, use a dedicated USB NFC readerNFC readerFundamentalsActive device generating RF field to initiate communication with tagsClick to view → with a PC host that has full control over the anti-collision loop.

iOS

iOS Core NFC similarly delivers one tag session at a time. Multi-tag sequential reading requires calling restartPolling() on the reader session after each tag is processed.

// iOS: sequential multi-tag
session.restartPolling()
// The next tag discovered fires didDetect again

Python nfcpy

nfcpy provides direct access to the anti-collision loop:

import nfc

def on_connect(tag):
    print(f"Tag: {tag.identifier.hex()}")
    return True  # Return True to keep reader active; False to stop

with nfc.ContactlessFrontend('usb') as clf:
    # Poll continuously; process each tag as it enters the field
    clf.connect(rdwr={'on-connect': on_connect, 'interval': 0.0})

With interval=0.0, the reader loops as fast as the hardware allows (~10–20 ms per poll cycle). Each tag is activated, processed, halted, and the loop continues to the next tag.

PN532 / ESP32 Direct Control

At the IC level, multi-tag enumeration uses the InListPassiveTarget command with MaxTg=2 to activate up to two tags simultaneously:

// PN532 InListPassiveTarget: activate up to 2 Type A tags
uint8_t cmd[] = {
    0xD4, 0x4A,  // TFI + InListPassiveTarget
    0x02,        // MaxTg = 2
    0x00,        // BrTy = 106 kbps Type A
};
// Response contains Tg (tag number), ATQA, SAK, NFCIDLength, NFCID for each card

With MaxTg=2, the PN532 runs the full anti-collision loop and activates the first two tags it resolves, assigning them Tg numbers 0x01 and 0x02. Subsequent APDU commands include the Tg number to route to the correct card.

Anti-Collision in Production Systems

System Typical Multi-Tag Scenario Approach
Transit gate Two taps simultaneously (family) Reject second tag; require re-tap
Retail POS Customer wallet with 3+ cards Present disambiguation UI
Conveyor reader Pallet of 50 labelled items ISO 15693ISO 15693Standards & ProtocolsStandard for vicinity-range smart cards, 1+ meter read rangeClick to view → bulk inventory loop
Access control Single badge expected Error on >1 tag: anti-passback violation
Event check-in Wristband only Field power limited to <4 cm to exclude wallet cards

Collision Avoidance in Tag Placement

For applications where only one specific tag should be read in a multi-tag environment, control the RF field geometry:

  • Field power reduction: Lower the reader's RF power to reduce the activation radius to <2 cm, ensuring only the intentionally presented tag is powered.
  • Shielding: A Faraday cage backing behind a presentation surface prevents tags in a wallet or bag from responding.
  • Tag orientation: The anti-collision loop resolves any tags in the field — but if two tags are oriented at 90° to each other, one receives significantly less field flux and may not power up reliably, providing a soft exclusion.

Use the Read Range Estimator to model field power vs activation radius for your antenna geometry.

See also: ISO 14443 Protocol Deep Dive | NFC Transit | NFC Reader Modules Compared | NFC Standards Reference

अक्सर पूछे जाने वाले प्रश्न

Our guides cover a range of experience levels. Getting Started guides are written for beginners with no prior NFC knowledge. Programming guides target developers integrating NFC into mobile apps or embedded systems. Security guides are for engineers designing secure NFC deployments for payments, access control, or authentication.

Most guides require only an NFC-enabled smartphone (iPhone 7+ or any modern Android device) and a few NFC tags (NTAG213 or NTAG215 recommended for beginners, available for under $1 each). Advanced guides may reference USB NFC readers like the ACR122U or Proxmark3 for development and testing.

Yes. Programming guides include code examples for Android (Kotlin/Java with the Android NFC API), iOS (Swift with Core NFC), and web-based tools (Web NFC API for Chrome on Android). All code samples are tested and include inline comments explaining each step.