An RFID inventory result is meaningful only when the project can explain which tag population was eligible to participate. A reader can report tags in its field of view, while an application may intend to count only a defined class, location or asset group. Before choosing a handheld workflow, document whether the job uses an unfiltered inventory, a preselected population or an application-side filter, and show how that scope is verified.
This guide is for RFID integrators, asset teams and procurement managers. It does not prescribe an AIDC GO filtering feature. It explains the evidence needed to compare a proposed reader configuration and the application that turns reads into a business count.
Define the population before interpreting the number
Begin with a plain-language statement: “Count all tagged returnable containers in staging zone A,” not “run RFID inventory.” Identify the asset class, expected identifier pattern, physical boundary, time window and exclusions. If pallets, tools and employee badges can all be present, the team must decide which of them are eligible before treating the displayed total as an accepted count.
GS1’s current EPC UHF Gen2 air-interface standard distinguishes Select from Inventory. Select defines a tag population for subsequent inventory; Inventory is the process by which an interrogator identifies participating tags. That protocol distinction supports the planning model here. It does not show that a particular AIDC GO reader, SDK or application exposes a given filtering control.
The physical read zone remains a separate problem. Antenna position, tag orientation, material and neighbouring zones can change which tags respond. Use UHF RFID Read Range: Missed Tags and Stray Reads to evaluate that boundary. Population logic does not make an uncontrolled read zone controlled, and a good read zone does not define which identifiers the application should accept.
Distinguish reader selection from application filtering
A reader-side pre-filter can influence which matching tags participate in inventory. An application-side filter may instead receive a broader set of reads and decide which records belong in the task. These approaches produce different evidence and failure modes.
Zebra’s versioned RFID SDK inventory tutorial describes a simple continuous inventory with no pre- or post-filters that reads tags in the field of view. Its readable RFID SDK for Android 2.0.5.292 pre-filter tutorial describes pre-filters as corresponding to the Gen2 Select command and links filter criteria with singulation state. Those are concrete vendor examples for the named Zebra SDK and devices, not AIDC GO capability statements. The older 2-15 URL was not independently readable during this review and is not treated as a verified 404.
If the proposed workflow says “filtered inventory,” ask where the filter executes, which memory bank and bit range it uses, how the pattern is encoded, and which SDK/firmware version defines that behavior. If filtering happens in the application, ask whether excluded reads are retained for diagnostics and whether the accepted count is based on unique identifiers, events or a separate asset record.
Trace one mixed-zone count from requirement to result
Consider an editorial example in which a staging area contains blue reusable containers, red maintenance tools and tagged pallets. The task is to count only containers assigned to dispatch batch B17. The physical sweep may expose all three groups. Two containers can share the same tag class or prefix while only one belongs to B17 in the business database. A reader-side class filter may therefore retain both; the application still has to consult the authoritative mapping to decide batch membership.
The project first defines the authoritative container records and the identifier pattern or mapping for batch B17. If batch membership is not encoded in the tag memory, “B17” is not a memory-bit condition that the reader can match. An application may convert the authoritative B17 membership into an explicit set of EPC values, but the team must then verify the set, the device and API support, and the applicable limit on the number of filter entries. The RFID owner states whether the reader should preselect that population or return a broader read stream. The application owner records how duplicates, unexpected identifiers and assets missing from master data are handled. The operator sees both the provisional read total and a final accepted count only after those rules run.
A pre-filtered reader cannot report a tag it was configured to exclude as an expected missing member. Retain a known control tag or an authoritative expected-membership list and reconcile that list against the accepted result. That comparison is what exposes an expected B17 asset that never entered the returned read set; the absence cannot be inferred from the filtered read stream alone.
If a tag is readable but mapped to the wrong asset, population filtering cannot repair the mapping. Use Replacing a Damaged RFID Tag for old/new tag relationships and identity verification. If the same configuration will move between countries, keep regional hardware and documentation checks with UHF RFID Deployment Countries.
Record what each population test actually proves
| Test condition | Evidence to retain | Limit of the result |
|---|---|---|
| Unfiltered inventory in a bounded test area | Reader/configuration identity, antenna, time window and complete unique-tag report | Does not prove that every reported tag belongs to the business task |
| Reader-side filter for a documented pattern | Memory bank, offset, mask/pattern, SDK and firmware version, plus matching/non-matching controls | Does not prove the application mapped each accepted identifier to the correct asset |
| Application-side inclusion rule | Raw read set, rule version, authoritative asset list and accepted/rejected records | Does not prove excluded tags were physically absent or unreadable |
| Expected container deliberately outside the pattern | Recorded exclusion and operator message | Does not prove all future exceptions will be recognised |
| Unexpected but readable tag inside the zone | Raw identifier and the system’s hold/reject result | Does not establish that physical read-zone leakage is acceptable |
Use a known matching tag, a known non-matching tag and an unexpected tag as controls. Change one condition at a time. A final count should be reproducible from the retained raw observations, the filter definition and the application’s acceptance record rather than from a single number on a reader screen.
Keep uniqueness, mapping and count acceptance separate
Reader software may report unique tag identifiers during an inventory, but “unique read” is not automatically “one valid asset.” Duplicate suppression, read-event aggregation and asset mapping can occur in different layers. Document which identifier is used for uniqueness, when the list is cleared, and whether an identifier without a valid asset record is counted, rejected or held.
Do not infer that EPC, TID or User memory is available for every planned operation. The exact tag construction, memory state, access rights and reader interface matter. If the filter depends on a specific memory bank, require documentation for the tag and proposed reader/software build. A successful EPC inventory does not prove that another bank can be read, filtered or written.
The UHF RFID Inventory & Asset Tracking solution can frame task evidence and application responsibility. The customer’s application remains responsible for the authoritative asset list, inclusion rules, reconciliation and accepted business result.
Bring the scope contract to the device discussion
Provide the deployment country, tag samples and exact tag identifiers or data scheme, the asset groups to include and exclude, a marked read-zone layout, the intended application and the desired raw/accepted reports. Add the proposed filter layer, memory bank and pattern if they are already defined.
Review RFID Mobile Computers for the integrated handheld direction or RFID Sleds when the project keeps an existing host. Ask for the exact regional model, firmware, SDK/API documentation, filter support and applicable tag-memory conditions. Do not assume the vendor example above is present on the proposed AIDC GO configuration.
Use Integration & Support to submit the versioned reader and application question, then contact AIDC GO with the population definition and sample evidence. Approve the workflow only when the physical zone, eligible tag population and application acceptance result are recorded as three connected but distinct controls.