2 How RFID Identifies Objects

rfid-nfc-uwb

2.1 Start With the Story

Imagine a tagged tool cabinet that says a wrench is present. The useful question is not whether RFID can read a tag on the bench. The useful question is whether the reader, antenna, tag, read zone, and middleware can turn messy radio observations into one trustworthy inventory event.

Use this chapter from that claim outward. Follow the energy path, the tag response, the anti-collision round, the filtering step, and the business event so the final record says what was observed and what could still fool the system.

Phoebe’s Field Notes: Two Regimes, One Word “Range”

Phoebe the physics guide

Phoebe’s Why

This chapter’s own system-architecture figure quotes two very different numbers – passive tags under 10 m, semi-passive (battery-assisted) tags around 30 m – and the gap is not a better antenna, it is a different limiting leg of the link. LF and HF tags live inside the reader’s reactive near field, coupled magnetically like a transformer, where “gain” and “EIRP” are not meaningful words. UHF tags sit in the ordinary radiating far field, where gain, aperture, and EIRP govern range the normal radio way – but a passive UHF tag has to harvest enough incident power to wake its chip before it can even attempt to answer, while a battery-assisted tag never has that requirement, so its range is set by the weaker leg instead: getting its faint backscattered reply back to the reader.

The Derivation

Near-field boundary, where far-field antenna concepts like gain and EIRP stop applying:

\[r_{nf} = \frac{\lambda}{2\pi}\]

Forward link (reader to passive tag), wake-power-limited – solve Friis for the range at which incident power falls to the tag chip’s wake threshold \(P_{wake}\):

\[P_{rx,tag} = \mathrm{EIRP} + G_{tag} - 20\log_{10}\!\left(\frac{4\pi d}{\lambda}\right)\]

Backscatter return link (tag to reader), a two-way trip that a battery-assisted tag’s range is actually limited by:

\[P_{rx,reader} = \mathrm{EIRP} + 2G_{tag} + G_{reader} - 40\log_{10}\!\left(\frac{4\pi d}{\lambda}\right)\]

Worked Numbers: This Chapter’s Own <10 m and 30 m

HF near field at 13.56 MHz: \(\lambda=22.1\) m, \(r_{nf}=22.1/2\pi=3.52\) m – an HF tag “a few centimetres” from the reader sits deep inside this boundary, which is why gain/EIRP reasoning does not apply to the LF/HF rows in this chapter’s frequency ledger.
UHF forward (wake-limited) range, catalog-typical values: EIRP \(=36\) dBm (4 W regulatory cap), tag antenna \(G_{tag}=1.8\) dBi, chip wake threshold \(P_{wake}=-18\) dBm. Solving Friis gives \(d_{max}=16.1\) m in idealized free space – polarization mismatch, packaging, and reader derating for reliable (not just barely-waking) reads bring real installed range down toward this chapter’s own quoted “under 10 m.”
UHF return-limited range for a battery-assisted tag (no wake constraint, catalog-typical reader gain \(G_{reader}=6.0\) dBi, reader sensitivity \(-80\) dBm): solving the two-way budget gives \(d=36.0\) m – consistent with this chapter’s own “~30 m” figure once the same real-world margin is subtracted.
The mechanism, not just the number, explains the chapter’s frequency-and-coupling ledger row directly: passive UHF range is capped by the forward wake link; battery-assisted range is capped by the return backscatter link – two different physics limits producing the two different figures this chapter already shows in one image.

2.2 Overview: What an RFID Claim Means

Radio Frequency Identification, or RFID, is a way to observe object identity with a tag, a reader, an antenna, and software that turns radio observations into events. The useful claim is not "RFID works." The useful claim is that a named object, credential, animal, tool, carton, or asset can be observed in a defined read zone with enough reliability for a specific workflow.

That boundary matters because RFID systems can produce both missing reads and extra reads. A tag may be present but unreadable because of orientation, material, distance, collision, shielding, or damaged attachment. A tag may also be read outside the intended business event if the reader zone is too broad or the middleware accepts every raw observation.

Make the claim measurable before approving the system. For a tool cabinet, the bounded claim might be: "when the cabinet closes, the reader should identify the 18 tagged tools inside this cabinet, ignore tools on the bench beside it, and create one inventory event per physical tool." If the raw trace contains 63 observations, that is not 63 tools. The evidence should reduce those observations to the expected identities, such as 18 / 18 tools accepted, 0 / 3 nearby bench tools accepted, and duplicate observations suppressed by the cabinet-close event rule.

A moving portal has a different denominator. If 32 tagged cartons pass through a 2.4 m read zone at 1.6 m/s, the reader has about 2.4 / 1.6 = 1.5 s of dwell time. With an observed inventory round time of 200 ms, that is about 1.5 / 0.2 = 7.5 rounds before the cartons leave the zone. A pilot that reads 29 of 32 expected cartons is an evidence record, not a full release: the review still needs to explain whether the three misses came from tag orientation, material shielding, anti-collision timing, antenna aim, or middleware timeout. This is why RFID fundamentals are really about the whole identification chain, not only the tag chip.

RFID System Architecture

If you only need the intuition, this layer is enough: approve RFID from observed read-zone evidence, not from the technology label. Name the object identity, tag type, frequency family, reader zone, filtering rule, application event, privacy boundary, owner, and retest trigger.

The Five Evidence Boundaries

Identity

The tag identifier must map to the right object, credential, animal, container, or process state, with a rule for unknown, duplicate, damaged, or retired tags.

Physics

Tag power model, frequency family, coupling, antenna pattern, object material, orientation, and read distance define whether a radio observation is plausible.

Read-zone behavior

Reader placement, power, shielding, anti-collision, dwell time, movement, and neighboring tags define what the reader can and cannot prove.

Event meaning

Middleware, filtering, application rules, security, privacy, exception handling, ownership, and retest triggers decide whether a read becomes an approved event.

Beginner Examples

A successful bench read proves that this tag and reader can communicate under that condition. It does not prove the installed read zone.
A portal read proves an observation near the portal only when placement, antenna settings, object flow, and filtering rules are part of the evidence.
A tag identifier is not the business event. The application still has to decide whether the observation means received, returned, released, counted, or rejected.
Longer read range is not automatically better. A wider zone can create false events when nearby tags are observed unintentionally.

Overview Knowledge Check

2.3 Practitioner: Build the RFID Review Record

A practical RFID review record should let another engineer repeat the decision. It names the business event, the physical read zone, the tag and reader choices, the observed evidence, the filter that turns raw reads into events, and the operational change that reopens the decision.

Early design may record assumptions and required tests. A release review should replace assumptions with observations from representative tags, objects, mounting positions, reader placements, motion patterns, neighboring tags, privacy boundaries, and exception workflows.

Evidence Area

Review Question

Evidence to Record

Failure If Missing

Business event

What decision should a read support?

Received, issued, returned, counted, released, denied, inspected, located, or exception event, with the object population in scope.

The system records observations without knowing what workflow state they are allowed to change.

Tag and object fit

Can the tag survive and read on the real object?

Tag power model, form factor, encoding rule, attachment method, material, orientation, lifecycle, and unknown-tag handling.

A tag that works before attachment fails after it meets metal, liquid, stacking, cleaning, heat, or handling.

Frequency and coupling

Which physical RFID family is being approved?

LF, HF, NFC, UHF, battery-assisted, or active behavior, with coupling model, region, reader settings, and material evidence.

The team transfers evidence from one frequency family or power model to another without proof.

Read zone

Where should the read be accepted?

Antenna placement, power, shielding, field shape, motion, dwell time, anti-collision, tag population, misses, and extra reads.

The system accepts nearby, duplicate, or accidental reads as if they were the intended event.

Event filtering

How does software convert reads into events?

Duplicate window, confidence rule, reader identity, timestamp rule, application mapping, retry, manual override, and audit evidence.

Every raw read becomes an application action, or valid reads are discarded without a diagnosable reason.

Security and operations

Who owns tags, readers, data, and retest?

Privacy boundary, access rule, cloning or replacement risk, owner, monitoring signal, calibration, maintenance, and retest trigger.

Support cannot tell whether a later miss, false read, privacy issue, or tag replacement invalidates the approval.

Worked Review: Dock-Door Inventory

A dock-door workflow reads tagged cartons as they pass through a portal. The review should approve only the observed flow: the carton population, tag placement, reader antennas, power settings, movement speed, nearby tags, duplicate filter, missed-read rule, manual exception path, and retest trigger for new packaging, reader relocation, firmware, or operating procedure changes.

The safe approval statement is narrow: under the reviewed conditions, this portal can turn observed tag reads into this inventory event. It does not prove every product material, stacking pattern, doorway, antenna, or future warehouse layout.

Worked Review: Tool Checkout Cabinet

A cabinet reads tagged tools when a technician opens and closes the door. The evidence boundary is different from a portal. Review shielding, reader timing, tool overlap, tag attachment durability, unknown tools, duplicate reads, access identity, privacy, audit trail, and the exception process when a tool is missing or unreadable.

The approval should not say that RFID generally solves tool custody. It should say which cabinet, tag set, timing rule, and application mapping were observed.

Practitioner Knowledge Check

2.4 Under the Hood: Layer Handoffs and Failure Boundaries

RFID systems fail when radio observations are treated as complete application proof. A tag can harvest enough energy and still collide with other tags. A reader can decode a tag and still observe the wrong zone. Middleware can filter duplicates and still map the event to the wrong object state. A privacy or cloning issue can exist even when reads are technically reliable.

The review should preserve enough handoff evidence to diagnose where the claim stopped being proven: tag physics, air-interface behavior, read-zone control, event filtering, application state, or operations. That separation makes later troubleshooting faster and keeps approvals from expanding beyond the evidence.

Handoff

What It Proves

What It Does Not Prove

Retest Trigger

Object to tag

The identifier is attached, encoded, and associated with the intended object or credential.

Read reliability, zone control, privacy safety, or application event correctness.

Attachment, material, cleaning, repair, replacement, reuse, encoding, or ownership change.

Tag to reader

The tag and reader can communicate under the tested power, frequency, orientation, distance, and material conditions.

Correct event filtering, application decision, or behavior across all tag populations and environments.

Reader power, antenna, firmware, region, object material, tag vendor, orientation, population, or site-layout change.

Reader to middleware

Raw observations can be decoded, timestamped, associated with a reader, and sent to software.

That a read is unique, intentional, in-zone, or meaningful to the business workflow.

Duplicate window, reader identity, network path, timing, filtering, batching, or exception-rule change.

Middleware to application

A filtered observation is mapped to a workflow event such as count, receive, return, release, or deny.

That every future workflow, user, privacy boundary, replacement tag, or support process remains valid.

Catalog, access rule, workflow, privacy policy, audit rule, integration, or support-ownership change.

Diagnosis Pattern

Name the failing boundary. Separate missed read, extra read, collision, duplicate event, object mapping, privacy issue, and application-state error.
Check the closest lower proof. If an application event is wrong, inspect filtering and mapping before changing antenna placement. If the tag is unreadable, inspect object material and orientation before rewriting middleware.
Change one variable at a time. Reader power, antenna position, tag model, attachment, firmware, object flow, and duplicate window can each change the evidence trail.
Write the unsupported claim. If the pilot covered one doorway, one object type, or one tag population, keep the approval limited to that boundary.

Under-the-Hood Knowledge Check

2.5 Summary

RFID approval starts with a bounded identification claim, not with a successful read in isolation.
Tags, readers, antennas, coupling, anti-collision, reader zones, filtering, and applications each prove different parts of the workflow.
Passive, battery-assisted passive, and active tags support different power and evidence models.
LF and HF systems use magnetic coupling; UHF passive systems use backscatter and are more sensitive to placement, materials, reflections, and region rules.
A reliable RFID event requires a controlled read zone plus middleware that filters duplicates, misses, extra reads, and exception cases.
Operations evidence names the owner, privacy boundary, replacement rule, monitoring signal, and retest trigger.

2.6 Key Takeaway

Approve RFID only when the reviewed behavior is tied to object identity, tag physics, read-zone evidence, event filtering, application meaning, owner, and retest boundary.