When a second UHF RFID inventory shows fewer rows than the first, the missing rows can come from more than one layer. A tag may not participate in that inventory round, the reader or SDK may not report it in the expected way, or the application may suppress a value it already displayed. Changing power or waiting a guessed number of seconds before identifying the layer can hide the real cause.
This guide explains a verification method, not an AIDC GO device test. The RFID mobile-computer category, RFID sled category and Integration Support are commercial starting points. Availability of session, target, filter and report controls must be checked against the exact reader, firmware and SDK.
Treat a protocol session and a business inventory as different things
The GS1 EPC Gen2 standard defines four protocol sessions, S0, S1, S2 and S3. A conforming tag maintains an independent inventoried flag for each session, and each flag can be A or B. At the start of an inventory round, the interrogator chooses a session and whether A-flagged or B-flagged tags should participate. That radio state is not the warehouse's cycle-count ID, user session or application task number.
The standard's Release 3.0.1, section 6.3.2.2, says a tag participates in one session during an inventory round and that the interrogator may issue a command that causes the inventoried flag for that session to invert. The result depends on the commands and state transitions; it is too broad to say that every successful read always flips every relevant tag immediately.
Session and target choices can help interrogators manage a shared tag population, but they do not identify the business population that should be counted. The inventory-scope guide addresses Select criteria and business inclusion. The read-range guide addresses missed and stray reads caused by the physical RF observation. Keep those questions separate from the A/B state used for one protocol inventory round.
Do not replace persistence rules with a fixed wait
The Gen2 persistence values differ by session. In Release 3.0.1 Table 6-21, the S0 inventoried flag has no persistence after the tag is no longer energized. S1 has a bounded nominal-temperature persistence range of more than 500 milliseconds and less than 5 seconds whether energized or not. S2 and S3 can persist indefinitely while energized and, when not energized, have a required nominal-temperature persistence greater than 2 seconds without a universal upper time stated in that table.
For S1, S2 and S3, the table's persistence limits use a population-based conformance criterion (95% of persistence times, with a 90% confidence interval), rather than guaranteeing the same reset time for each individual tag.
This means that stopping the handheld's inventory API does not by itself prove that every tag immediately lost power. Another reader may still energize the population, the same reader may resume RF, and the selected tag implementation and environment still matter. A fixed delay such as “wait three seconds” is therefore not a universal reset method for every session and tag population.
Record the session, target/inventory state, antenna or reader path, Select filters, trigger behavior and relevant RF timing for the test. If the requirement is to read the same known population again, define how the chosen implementation establishes that starting condition rather than relying on an undocumented pause.
Separate tag response, SDK report and application display
A repeat-inventory diagnosis has at least three observation points. First, did the tag participate and backscatter under the interrogator's command and state? Second, did the reader or SDK expose a tag report to the client? Third, did the application create, update, suppress or hide a displayed row? “No new line in the list” answers only the third question unless the other evidence is available.
Zebra's RFID SDK for Android 2.0.5.292 singulation tutorial is a bounded implementation example. It exposes session and inventory-state settings through singulation control, requires those settings to agree with pre-filter behavior, and tells developers to check reader capabilities. The same page notes that AB_FLIP is not supported on listed devices. This is evidence for that SDK and its stated scope, not a promise that every reader exposes the same controls.
The matching inventory tutorial shows a simple inventory operation and retrieval of tag data from the SDK's internal queue. A project may additionally aggregate repeated reports, display one row per EPC, count unique values, or retain a list between operations. Those application choices must be inspected directly; they cannot be inferred from the protocol session.
Use one-condition-at-a-time repeat tests
Create a verification fixture with a documented set of known tags in fixed physical positions. Record tag identifiers, reader, firmware, antenna or handheld orientation, power, session, target/inventory state, Select filters, trigger, report configuration and application deduplication rule. Capture the reader or SDK output available to the integration and the application list as separate artifacts.
Run the first inventory without changing the fixture. Stop it through the documented API and save both outputs. Start the second inventory with the same recorded configuration. If the application adds no new rows but the SDK output contains the known tags, the display or application deduplication layer explains the visible difference. If the SDK output also lacks them, continue with protocol configuration, filters, RF conditions and other-reader involvement instead of clearing the application list and declaring the issue solved.
Repeat the comparison while changing only one relevant condition: for example the application's “clear list” behavior, the reader report rule, target A versus B, or the selected session. Do not change session, target, power, filter and tag placement together; a passing run would not identify which change mattered. Any expected A/B transition must be stated against the actual command flow and supported interface.
Check filters and other readers before blaming the tag
A Select or pre-filter can move or include tags according to its defined action, while singulation settings decide which resulting state participates. A report-level filter may suppress repeated EPCs even when the radio operation sees them. The application can then apply another unique-item rule. Record all three rather than using “filter” as one undifferentiated setting.
Another interrogator can influence the same tag population, and the Gen2 session design allows multiple interrogators to use independent session flags. That does not make the readers immune to RF interference, scheduling conflicts or overlapping coverage. During diagnosis, inventory nearby readers, portals and test tools; document whether they are transmitting and which session behavior they use.
If the observed population changes when another reader is disabled, the result identifies an interaction worth investigating, not proof that one session setting eliminates every interference mechanism. Physical placement, antennas, region settings, filters, report timing and application logic still require their own evidence.
Choose configuration from the required observation
A fast-moving population, repeated presence check, dense stationary inventory and two-reader workflow may favor different session and target strategies. The buyer should ask what the application must observe: every available tag report, one unique row per task, reappearance after a defined event, or independent rounds from more than one reader. Then confirm that the exact reader, tag population, SDK and application expose and preserve the necessary controls and evidence.
Acceptance should include a stable known-tag test, a controlled repeat, a changed physical condition, a filter mismatch, a retained application list and a nearby-reader case. Verify tag reports and final business records, not only the displayed count. The tag-locate versus inventory guide helps keep search and completion rules distinct from the protocol mechanics discussed here.
There is no universal instruction to set every project to S0, clear every list, increase power or wait a fixed interval. A technically useful configuration states the observation required, the exact supported controls, the test conditions and the layer that owns deduplication. To discuss an actual reader and workflow boundary, use Contact AIDC GO; no particular session-control capability or repeat-read result is implied for an AIDC GO model without its matching documentation.