12  RFID Lab Check

12.1 Start With the Story

In the lab, RFID becomes understandable when a learner can move a tag, change an antenna, watch the trace, and explain why the accepted event changed. A single good read is less useful than a repeatable evidence record.

Use this lab as a controlled version of a field review. Build the read zone, vary one condition at a time, capture missed and duplicate reads, then decide what the evidence does and does not prove about a real deployment.

12.2 In 60 Seconds

This chapter turns RFID application ideas into verifiable lab work. You will plan a read zone, collect tag inventory traces, test antenna placement, classify missed and duplicate reads, check middleware evidence, and prepare a release record that another team can retest.

The goal is not to prove that a reader can beep once on a bench. The goal is to show whether an RFID workflow can identify the intended items, ignore the wrong items, protect people and data, and keep enough evidence for operations to trust the result.

Phoebe’s Field Notes: What “Move The Antenna Down 10 cm” Is Actually Buying

Phoebe’s Why

An antenna’s gain in dBi is not extra power – it is the same power reshaped. An isotropic radiator spreads its watts evenly over the whole sphere; a real antenna squeezes that same total into a narrower cone, trading the solid angle it gives up for the power density it keeps in the direction it favours. That trade is the actual physics behind this lab’s boundary-tag problem: a wider-beam antenna floods more solid angle, catching the 4 tools that must stay excluded along with the 12 that should be read, while a narrower, higher-gain antenna can leave the boundary tags outside the illuminated cone entirely, at the same peak range. This is also why the lab’s own fix – “move the antenna down 10 cm” – works: a small position change tips the beam’s edge across a tag that was already sitting near the -3 dB rim of the pattern, without touching power or gain at all.

The Derivation

Directivity is total sphere divided by the beam’s own solid angle:

\[D = \frac{4\pi}{\Omega_A}\]

Approximating the main lobe as a rectangular patch of half-power beamwidths \(\theta_E,\theta_H\) (degrees) gives the standard antenna-engineering estimate:

\[D \approx \frac{41253}{\theta_E\,\theta_H}\ \Longrightarrow\ \theta \approx \sqrt{\frac{41253}{D}}\ \text{(square-beam case)}\]

Effective isotropic radiated power ties the transmitter setting to the antenna choice:

\[\mathrm{EIRP(dBm)} = P_{tx}\mathrm{(dBm)} + G\mathrm{(dBi)}\]

Worked Numbers: A Wide-Beam Gate vs. A Narrow-Beam Gate

• Catalog-typical wide-beam gate antenna: \(G=6.00\) dBi \(\to D_{lin}=10^{0.6}=3.98\), so \(\theta\approx\sqrt{41253/3.98}=101.8\,^\circ\approx102\,^\circ\) of half-power beamwidth – wide enough to sweep past a boundary tag standing just outside the intended zone.
• Catalog-typical narrow-beam gate antenna: \(G=9.00\) dBi \(\to D_{lin}=10^{0.9}=7.94\), so \(\theta\approx\sqrt{41253/7.94}=72.1\,^\circ\approx72\,^\circ\) – the illuminated solid angle shrinks to \(D_{6}/D_{9}=3.98/7.94=0.501\), essentially half.
• Same peak range, same regulatory ceiling: at a catalog-typical 36.0 dBm EIRP cap, the wide-beam antenna needs \(P_{tx}=36.0-6.00=30.0\) dBm; the narrow-beam antenna needs only \(P_{tx}=36.0-9.00=27.0\) dBm – both give identical \(\mathrm{EIRP}=36.0\) dBm and identical peak range, so the only thing the extra 3 dBi bought was a smaller footprint, exactly the coverage-for-range trade the derivation predicts.
• The lab’s own “move it down 10 cm” fix, quantified: at roughly 1 m from a shelf edge, a 10 cm vertical shift changes the look angle by \(\arctan(10/100)=5.71\,^\circ\) – small next to either beamwidth above, which is precisely why a modest placement change can walk a boundary tag across the pattern edge without any change to reader power, antenna gain, or firmware.

None of this replaces the lab’s own release criterion; it explains why antenna aim, not just antenna presence, belongs on the boundary-tag checklist next to reader power.

12.3 Learning Objectives

By the end of this chapter, you will be able to:

• Define a read-zone test plan with controlled tag set, reader position, antenna orientation, reader settings, and pass or fail criteria.
• Capture inventory traces that preserve tag IDs, timestamps, antenna IDs, RSSI or equivalent signal indicators, event state, and middleware decisions.
• Diagnose missed reads, duplicate reads, stray reads, orientation sensitivity, and material effects without relying on unsupported range claims.
• Evaluate middleware behavior such as de-duplication, dwell time, direction inference, exception handling, and handoff to an IoT application.
• Record privacy, safety, fallback, and retest evidence before releasing an RFID workflow.
• Use an assessment rubric to distinguish a working demo from a deployable lab result.

12.4 Quick Check: RFID Assessment

12.5 Prerequisites

You should already know the RFID roles from RFID Hardware Integration, the application patterns from RFID Industry Applications, and the deployment risks from RFID Security and Privacy. This chapter focuses on lab execution and assessment evidence rather than new protocol theory.

12.6 Lab Scope

Use this chapter for any RFID application lab where tagged objects move through a known place: a shelf, bench reader, doorway, dock door, tool crib, library station, medicine cabinet, or maintenance cart. The equipment can be classroom hardware or production-style readers, but the evidence expectations are the same.

Read zone The intended physical space where a tag should be detected, plus the boundary where it should not be detected.

Inventory trace The raw or normalized event stream that shows each observed tag and the context of the observation.

Middleware decision The rule that turns repeated observations into a business event such as arrived, removed, checked in, or exception.

Release record The stored setup, test evidence, known limits, fallback plan, and retest trigger for the workflow.

Read-zone setup showing reader position, antenna aim, target tags, boundary tags, middleware logging, and release evidence

12.7 Folded Hands-On Evidence Route

A hands-on RFID lab should make the full system visible before the learner starts changing code. State the decision first, then separate the physical read zone, raw tag observations, filtering rule, application decision, exception behavior, and release evidence. This keeps a successful beep or single tag read from being mistaken for a verified workflow.

Use this route when adapting a short exercise into an assessable lab:

1. Define the object, credential, asset, or service event the tag is meant to identify.
2. Mark where the tag should be accepted and where nearby tags should be ignored.
3. Capture raw reader observations before filtering them into application events.
4. Test missing, unknown, duplicated, wrong-zone, restart, and network-loss cases.
5. Store the retest trigger when reader settings, tags, mounting, software, or workflow changes.

12.8 A Lab Result Is a Controlled Evidence Set

The useful question in an RFID application lab is not “did any tag read?” but “did the workflow produce the right application event under controlled conditions?” A small shelf lab can show the difference. Suppose the intended zone contains 12 tagged tools and the boundary zone contains 4 tagged tools that must not be accepted. The release criterion can be written before the run: all 12 expected tools must become present events within a 3 second dwell window, zero boundary tools may become present events, and one physical tag may create only one application event during that dwell.

That criterion turns the lab into measurable evidence. If the raw trace contains 54 reader observations, that is not automatically 54 inventory events. The assessment asks how many observations map to the 12 expected identities, whether any of the 4 boundary identities crossed the middleware acceptance rule, and which observations were suppressed as duplicates. A run with 11 accepted tools, 1 missed tool, 1 accepted boundary tag, and 31 duplicate raw observations is not a “mostly working” release. It is a precise failure record: the read zone is too wide for one edge and too weak for one target orientation.

The release note should preserve both the physical setup and the trace summary. It should name the reader profile, antenna count, reader power setting if exposed by the tool, target tag list, boundary tag list, dwell window, acceptance rule, and retest trigger. Another team should be able to put the same 12 target tags and 4 boundary tags back into the same geometry and see whether the same acceptance decision is reproduced.

That reproducibility is the difference between an activity and an assessment. Learners can still experiment with antenna aim or tag mounting, but the gradeable artifact is the before-and-after record: what changed, which denominator stayed fixed, which failure modes improved, and which new risks appeared. A release-ready lab says “pass” only when the trace supports the intended operational decision.

12.9 Lab 1: Read-Zone Setup

Start with a written read-zone plan before collecting data. The plan prevents the common mistake of moving the reader, tag set, and acceptance criteria during the same test.

Record these setup fields:

• Workflow name and location.
• Reader model or reader class, antenna count, antenna placement, reader settings, and firmware or configuration version.
• Tag type, mounting method, object material, tag orientation, and tag population.
• Intended zone boundary and exclusion zone boundary.
• Test scenarios: empty zone, expected tags present, nearby non-target tags, obstructed tags, moving tags, and removal or return events.
• Pass or fail criteria written as measurable evidence, not as optimism about expected range.

The first setup should be conservative. Lower power, reduce antenna spillover, and add shielding or physical separation before increasing coverage. A lab that reads everything everywhere is not controlled; it is only noisy.

12.10 Lab 2: Tag Inventory Trace

Collect a trace for each scenario. Keep both raw observations and the middleware event output when your tooling allows it. Raw reads explain RF behavior; middleware output explains what the application actually sees.

Minimum trace fields:

• run_id: unique identifier for the test run.
• tag_id: EPC, UID, or other tag identifier used by the reader.
• timestamp: reader-side or gateway-side event time.
• antenna_id: antenna or port that observed the tag.
• signal: RSSI, phase, read count, or the closest signal indicator your reader exposes.
• scenario: controlled test condition such as baseline, rotated tag, metal backing, dense group, or boundary tag.
• middleware_event: state such as first_seen, still_present, departed, duplicate_suppressed, missed_expected, or stray_read.

run_id: shelf-A-baseline-003
scenario: expected tags present
reader_config: reader_profile_shelf_A_v2
tag_id: asset-014
antenna_id: left-shelf
timestamp: 2026-06-18T09:14:22Z
signal: recorded by reader as reported
middleware_event: first_seen
operator_note: tag flat on plastic tray, no boundary tag detected

Do not edit the trace to make it look cleaner. If the reader produces duplicate observations, keep them and let the analysis show whether middleware suppressed them correctly.

Inventory trace classification showing expected reads, missed reads, duplicate reads, stray reads, and middleware outcomes

12.11 Replay the Trace Before Changing Hardware

Start assessment by replaying the trace against the intended rule. In the shelf example, a defensible replay table has one row per expected item and one row per boundary item. For each identity, record first-seen time, last-seen time, antenna IDs, signal indicator range if available, raw read count, middleware state, and operator note. The important comparison is not highest signal; it is whether the middleware decision matches the scenario label.

Use simple arithmetic so the result cannot hide in prose. If 12 target tags were expected and 11 became present, the target acceptance rate is 11 / 12 = 91.7%. If 4 boundary tags were present outside the intended zone and 1 became accepted, the boundary false-accept rate is 1 / 4 = 25%. If those 11 accepted tags produced 42 raw reads inside the dwell window but only 11 present events, then 31 raw observations were duplicate evidence that the suppression rule handled. None of those numbers is a universal pass threshold; the pass threshold is the one the lab wrote before testing.

Evidence field	Why it matters	Release implication
Expected target count	Defines the denominator for missed-read analysis	A missing target is a failed inventory event until retested or accepted as a known limit.
Boundary tag count	Proves whether the zone excludes nearby objects	An accepted boundary tag means antenna aim, power, shielding, or workflow geometry needs review.
Dwell window	Prevents repeated raw reads from becoming repeated business events	The release record must document the window because changing it changes behavior.

Change one variable after replay, then repeat the same scenarios. If moving the antenna down 10 cm produces 12 of 12 accepted target tags and 0 of 4 accepted boundary tags, the improvement is credible only because the tag set, dwell rule, and scenario sequence stayed fixed. If the same change also increases duplicate raw observations from 42 to 93, that is not automatically bad, but the release record must show that duplicates still collapse to one application event and that gateway load remains acceptable for the exercise or pilot.

12.12 Lab 3: Antenna Placement Tests

Antenna placement is a test variable, not a decoration. Change one placement factor at a time and keep the tag set fixed while you compare outcomes.

Use this sequence:

Baseline Capture the current placement with photos, antenna aim, reader configuration, and a trace from the standard tag set.

Boundary check Place known non-target tags outside the desired zone and confirm whether they remain absent from the middleware event stream.

Orientation check Rotate representative tags and objects through the expected real-world positions. Keep the same reader configuration.

Material check Test representative objects near metal, liquid, dense packaging, or human handling if those conditions are realistic for the workflow.

Change record Move or aim one antenna, update the setup record, and repeat the same scenarios before comparing results.

When a placement improves one scenario but creates stray reads in another, record both effects. The correct result may be a narrower read zone, a second antenna, a different tag mount, or a workflow change that prevents ambiguous reads.

Antenna placement testing workflow with baseline, boundary, orientation, material, and change-record checks

12.13 Lab 4: Missed and Duplicate Read Analysis

Treat missed and duplicate reads as evidence, not as random noise. A deployable lab result explains how the workflow handles both.

Missed reads usually require checking:

• Tag orientation or placement on the object.
• Material near the tag or between tag and antenna.
• Reader configuration changes between runs.
• Antenna blind spots or destructive overlap between antennas.
• Middleware timeout values that mark tags as departed too quickly.

Duplicate reads usually require checking:

• Whether the same physical tag is counted multiple times inside one dwell period.
• Whether two antennas report the same tag and the middleware lacks a zone ownership rule.
• Whether a moving tag crosses a boundary slowly enough to create multiple arrival events.
• Whether the tag identity is reused across sample tags or fixtures.

Stray reads require a separate decision: either shrink the read zone or mark that boundary as a known operational risk. Do not hide stray reads by filtering tag IDs unless the filter is part of the actual release design and is documented.

12.14 Dense Inventories and Q Scaling

Dense UHF RFID inventories take time because tags do not get fixed private time slots. In EPC Gen2-style inventory, the reader opens a frame of 2^Q slots, tags choose slots, and each slot becomes one of three outcomes: a singleton that can be read, a collision where multiple tags answered together, or an empty slot. The reader adjusts Q as it observes those outcomes:

• Too many collisions means the frame is too small for the tag population, so the reader increases Q.
• Too many empty slots means the frame is too large, so the reader decreases Q.
• The goal is roughly one tag per slot, not a guarantee that every slot succeeds.

EPC Gen2 inventory round showing reader Q value, tags choosing slots, successful single-tag slots, empty slots, collision slots, and Q adjustment before retry.

The arithmetic explains a common lab surprise. With 64 nearby tags and Q=4, the reader has only 2^4 = 16 slots, so the average load is 64 / 16 = 4 tags per slot. Under a simple slotted ALOHA model, the expected useful singletons are roughly N * e^-G, where G is the average tags per slot. That gives about 64 * e^-4 = 1.2 successful tag replies per frame, so the trace will be dominated by collisions. With Q=6, the frame has 64 slots and G = 1, giving about 64 / e = 23.5 useful singletons per frame. It still takes multiple rounds to see every tag, but the trace is no longer thrashing.

Q too small	Q well-matched	Q too large
Slots collide constantly; few reads per round; long total time.	Mostly singletons; near-peak read rate.	Most slots empty; the reader wastes time listening to silence.

The consequence for assessment is concrete: a release record must separate RF inventory performance from application logic. If a dense box takes three rounds before every expected tag appears, the middleware must either wait long enough before declaring a miss or mark the result as provisional. If a Select command narrows the population to one product family or location, the lab should capture that filter because it changes the inventory denominator.

This is also why a lab should avoid unsupported range promises. A bench reader may see all tags quickly when they are spread flat, then miss several when the same count is stacked, rotated, near liquid, or close to metal. The under-the-hood evidence does not need to identify every RF cause perfectly; it must show the trace signature, the controlled change, the repeated scenario, and the release decision.

12.15 Check Q Scaling Evidence

12.16 Middleware Evidence

Middleware is where raw RFID observations become IoT events. Assessment should review the decision logic, not just the reader output.

Collect evidence for:

• De-duplication window and how it is chosen.
• State transitions such as unknown, present, departed, exception, and reconciled.
• Multi-antenna ownership rules when two antennas see the same tag.
• Offline behavior when the gateway, network, or application endpoint is unavailable.
• Audit log fields that explain why the system accepted, ignored, or flagged a tag event.
• Manual correction workflow for expected tags that were missed or unexpected tags that were observed.

For a classroom lab, a CSV trace and a short script summary can be enough. For an operational pilot, preserve the actual gateway configuration export, middleware rule version, and sample application event payloads.

12.17 Privacy, Safety, and Fallback Checks

RFID labs often collect identifiers tied to people, assets, medicine, tools, or locations. Keep the review practical and bounded:

• Do tag IDs reveal a person, patient, employee, or sensitive asset without an authorized lookup?
• Can tags be read from a place outside the intended workflow?
• Is there signage, policy, or operator instruction where people need notice?
• Are emergency, manual, or offline procedures documented?
• Can a failed reader leave the process in a safe state?
• Are logs retained only for the operational need defined by the course or project?

These checks are not a substitute for organizational policy review, but they keep the lab from treating identifiers and movement traces as harmless by default.

12.18 Assessment Rubric

Use the rubric to score the lab result. A strong submission can be reproduced by another team member using the record alone.

Setup control The reader, antenna, tag set, object materials, mounting method, and scenarios are recorded before testing. Changes are tracked between runs.

Trace quality The submission includes raw or reader-normalized observations with timestamps, tag IDs, antenna context, scenario labels, and signal indicators when available.

Failure analysis Missed, duplicate, and stray reads are classified with plausible causes and retest evidence after changes.

Middleware review The event logic is visible enough to explain de-duplication, zone ownership, exception handling, offline behavior, and application handoff.

Privacy and safety Identifier exposure, unintended reads, operator notice, fallback behavior, and safe failure states are reviewed.

Release readiness The final record includes known limits, accepted risks, owner, retest trigger, and links to evidence artifacts.

12.19 Release and Retest Record

The release record closes the lab. It should be short enough to maintain and precise enough to retest.

Workflow: Location: Reader and antenna configuration: Tag type and mounting: Scenario set: Evidence artifacts: Known limits: Accepted risks: Fallback procedure: Owner: Retest trigger: Release decision:

Retest after a reader firmware change, antenna move, tag type change, packaging change, middleware rule change, layout change, or incident report. If the workflow depends on a physical read zone, physical changes are software changes for assessment purposes.

RFID release evidence loop: setup, trace capture, analysis, controlled change, retest, and release decision, which any layout, tag, firmware, or rule change restarts.

12.20 Check Your Understanding

12.21 Match the Evidence

12.22 Order the Lab Workflow

12.23 Common Pitfalls

• Changing too many variables at once: If antenna aim, reader power, and tag placement change together, the trace cannot explain which change mattered.
• Testing only happy paths: Expected tags alone do not prove a read zone. Boundary tags, absent tags, moving tags, and obstructed tags reveal the system limits.
• Counting raw reads as inventory events: A raw read is an observation. Inventory state needs middleware rules for dwell time, de-duplication, and departure.
• Ignoring object material: A tag that works on a plastic badge may fail on a metal tool, a liquid container, or a dense package.
• Hiding failures in the final report: Misses, duplicates, and strays are the material for improvement. Preserve them and explain the retest.

12.24 Summary

RFID lab assessment is evidence work. A useful result names the read zone, controls the scenarios, captures trace data, explains middleware decisions, and records what changed between runs. The release decision should state the known limits and the retest trigger so the workflow can survive layout, tag, reader, or middleware changes.

12.25 Key Takeaway

RFID labs and assessments should measure read behavior, missed reads, duplicates, materials, orientation, and middleware filtering rather than only proving one successful scan.

12.26 What’s Next

• RFID Design and Deployment: turn lab findings into site surveys, placement decisions, and deployment records.
• RFID Troubleshooting: diagnose read failures, interference, and antenna issues in more depth.
• RFID Security and Privacy: review tag identity, access control, tracking risk, and privacy controls.
• RFID Comprehensive Review: consolidate RFID concepts before module assessment.