RFID Lab Check: Inventory and Trace Evidence

rfid-nfc-uwb

apps

This lab belongs to RFID Industry Applications

Start With the Decision

An RFID inventory trace can hide missed tags behind a good total count. The lab records each read before hardware is changed.

Route Overview

This is part 1 of 2. Continue with RFID Lab Check: Placement and Read Analysis.

Part Objectives

Capture and replay an RFID inventory trace.
Identify missed and repeated reads in raw evidence.

Chapter Roadmap

Start With the Story
In 60 Seconds
Phoebe’s Field Notes: What “Move The Antenna Down 10 cm” Is Actually Buying
Eddie’s Math Bridge: Screen the Read-Zone Beam
Quick Check: RFID Assessment
Prerequisites
Lab Scope
Folded Hands-On Evidence Route
A Lab Result Is a Controlled Evidence Set
Lab 1: Read-Zone Setup
Lab 2: Tag Inventory Trace
Replay the Trace Before Changing Hardware

Start With the Story

Prove the Read Zone Accepts the Right Items

Picture a tagged crate that is counted twice while a nearby crate is missed. A reader beep cannot show whether the workflow made the right inventory decision.

Radio frequency means the part of the radio spectrum used to carry a signal. RFID means radio frequency identification, a way to identify tagged items with radio signals. Define the intended items, excluded area, antenna position, event rule, and acceptance threshold before testing.

Move correct, wrong, close, distant, blocked, and repeated tags through the zone. Keep tag identity, position, antenna setting, raw reads, accepted event, duplicates, misses, and time so another person can repeat the trial.

This lab covers one zone and item set, not every material or crowd. The deeper sections add middleware, privacy, safety, release rules, and field transfer.

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.

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

Eddie’s Math Bridge: Screen the Read-Zone Beam

The mathematical gist. Treating gain as ideal directivity, 6 dBi gives a 101.8° square-beam screen and 9 dBi gives 72.1°; the ideal solid angle halves. At a fixed 36 dBm EIRP ceiling, the 9 dBi panel needs 27 dBm conducted power, while a 10 cm shift at 1 m changes the look angle by 5.71°.

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.

Quick Check: RFID Assessment

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.

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.

Before running a trial, use Figure to locate the four evidence layers in one scene. Start with the physical zone, then distinguish target and boundary tags, and finally follow the observations into logging and release evidence.

Inspect fixed and release record in Figure for lab scope. To challenge the claim in lab scope, locate fixed beside release record on it. The comparison reaches boundary tags stay absent.

RFID read-zone setup diagram showing reader and antenna, target tags inside the intended zone, boundary tags outside the zone, middleware logging, and release evidence capture — Read-zone setup showing reader position, antenna aim, target tags, boundary tags, middleware logging, and release evidence

Read fixed with release record in Figure for lab scope. Verify it from the fixed field to release record, then the boundary tags stay absent disposition. Combining fixed with release record hides accountability. Reopen lab scope whenever release record changes.

In Figure, inspect the reader and antenna aim first because they create the field under test. Next compare target tags inside the marked zone with boundary tags that must remain unaccepted. The logging path then preserves raw observations, and the release record captures the rule that turned those observations into outcomes. That order establishes the chapter’s running method: define both acceptance and exclusion space before measuring, then keep physical evidence tied to the software decision.

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:

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

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.

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.

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.

To turn that trace into diagnoses, inspect Figure from the expected population through each exception class. The point is to preserve how a raw observation was classified, not merely to count how many lines the reader emitted.

Inspect reader reads and asset-033 absent in Figure for lab 2: tag inventory trace. While tracing lab 2: tag inventory trace, separate reader reads from asset-033 absent using it. keep raw trace and decision trace together identifies the later check.

RFID inventory trace classification diagram showing expected reads, missed reads, duplicate reads, stray reads, and middleware outcomes — Inventory trace classification showing expected reads, missed reads, duplicate reads, stray reads, and middleware outcomes

Read reader reads with asset-033 absent in Figure for lab 2: tag inventory trace. Locate its roles by locating reader reads, assigning asset-033 absent, and ending at keep raw trace and decision trace together. Success at reader reads cannot prove the asset-033 absent boundary. Reopen lab 2: tag inventory trace whenever asset-033 absent changes.

Read Figure by establishing the expected identities first. A missing expected identity becomes a missed read; repeated observations of one identity become duplicate evidence to suppress or group; and an identity from outside the intended set becomes a stray read. Follow each branch to its middleware outcome and retained context. This classification prepares the replay step below, where rates and decisions are calculated against fixed target and boundary denominators.

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.

Continue to the Next Part

Carry this evidence into RFID Lab Check: Placement and Read Analysis, which begins with Lab 3: Antenna Placement Tests.