Why the Same UHF Reader Reads Some Cards Once — and Others Nonstop
A customer asked why Zebra cards read once while generic UHF cards read continuously on the same reader. The answer: EPC Gen2 sessions, inventoried flags, and chip persistence time — plus two clean fixes.
A question landed in our inbox recently from an overseas integrator, and it is one of the best "same hardware, different behavior" puzzles in UHF RFID:
"On the same Chinese UHF reader, with the same S0/S1 inventory settings — your UHF cards get read continuously, but Zebra's cards get read exactly once. We want the read-once behavior to cut the load on the reader and the host. Why the difference?"
On paper, one reader plus one set of parameters should treat two standards-compliant cards identically. In practice, the chip inside the card quietly decides how chatty it is. The answer lives in the EPC Class 1 Gen 2 (ISO/IEC 18000-63) protocol — specifically in sessions, inventoried flags, and a very unglamorous storage capacitor.
First, a mental reset: is "read once" a tag feature or a reader feature?
Neither — it is a negotiation between the two. Two basics set the stage:
- Passive UHF tags have no battery. A tag wakes up only when the reader antenna's RF field powers it, and it replies by backscattering its EPC.
- The default behavior is chatter. As long as a powered tag hears inventory Queries, it will keep answering them. Continuous reads are not a defect — they are the protocol's default state.
So the real question is inverted: not "why does the generic card read continuously?" but "what makes the Zebra card shut up after one read?"
The mechanism: sessions and inventoried flags
Every Gen2 tag maintains an inventoried flag per session, with two states — A and B. The choreography is simple:
- Read once: when the reader successfully inventories the tag, the tag flips its flag from A to B.
- Stay quiet: while the flag stays in B, the tag ignores further Queries targeting state A in that session. One read, then silence.
If every tag played this perfectly, every card would read once. The plot twist is what happens to that flag between reader cycles.
Persistence time: where premium chips quietly win
In session S1, the B flag is not stored in permanent memory. It is held by a tiny on-die storage capacitor, and it survives only for the chip's persistence time — how long the flag outlives a dip or gap in RF power.
- Impinj Monza-family chips (what Zebra cards typically carry) — the monk. Excellent energy management keeps the B flag stable through microsecond-scale scan gaps and field-strength wobble. The flag holds, the tag stays silent, and the host sees exactly one read.
- Generic chips — the goldfish. The capacitor bleeds off during the same tiny gaps, the flag snaps back from B to A, and the reader greets the tag as a brand-new arrival. Again. And again. That is your "continuous read" stream.
Same reader, same air protocol, same commands — but one chip forgets it was already counted, and one does not.
How to get read-once behavior on purpose
Two clean engineering routes, depending on what you are allowed to touch:
Route 1 — hardware alignment (touch nothing but the card)
If the reader configuration and host software must stay frozen, specify cards built on the same silicon: Impinj Monza R6 / R6-P. The flag-persistence behavior then matches the Zebra reference card, and the same S0/S1 setup produces the same single read — no firmware, reader, or middleware changes. We build custom UHF cards on Monza and other chips from our chip catalog, and free samples let you verify the behavior on your own reader before committing.
Route 2 — system-side filtering (the sturdier habit)
Betting production stability on an analog capacitor's discharge curve is elegant until a forklift, a metal shelf, or a neighboring reader adds interference. The robust pattern:
- Switch the inventory to session S3, which holds its inventoried state far longer; in our bench tests every card — premium or generic — read once under S3.
- Enable de-duplication in the reader software or middleware: report each EPC once per window, for example "same EPC reported at most once every 3 seconds." This ends the serial-port and CPU flood regardless of which tags show up.
Route 1 fixes the symptom at the silicon level; Route 2 makes the system indifferent to which silicon arrives. Mature deployments usually do both.
Session cheat sheet: what S0–S3 actually promise
The Gen2 specification defines four sessions, and the differences are entirely about how long the inventoried flag survives. The nominal persistence values from the spec:
| Session | Flag persistence (tag energized) | Flag persistence (power lost) | Typical use |
|---|---|---|---|
| S0 | Indefinite while powered | Resets immediately | Fast repeated counting, tag-present detection |
| S1 | Nominal 500 ms – 5 s, decays even while powered | Same 500 ms – 5 s window | Short de-duplication windows; the session in this article’s puzzle |
| S2 | Indefinite while powered | > 2 s after power loss | Read-once inventory, per-reader state |
| S3 | Indefinite while powered | > 2 s after power loss | Read-once inventory across long dwell times |
Two details worth underlining. First, S1 is the only session whose flag decays while the tag is still powered — which is exactly why chip-to-chip capacitor quality shows up there and nowhere else. Second, the spec values are minimums and nominals: a chip is free to hold its S1 flag toward the long end of 500 ms–5 s, and premium silicon does. That freedom is the entire Zebra-vs-generic difference.
Multi-reader sites: sessions decide who sees what
Sessions were invented for a second job besides de-duplication: letting multiple readers inventory the same tag population without trampling each other’s state. Each of the four sessions carries its own independent inventoried flag, so a handheld sweeping the aisle in S2 does not reset the state a fixed portal is tracking in S3. If your site mixes fixed portals and handheld readers, assign them different sessions on purpose — "both on S1 by accident" is a classic source of tags that mysteriously reappear mid-count.
How to bench-test persistence before you commit to a card
Ten minutes with a desktop reader/writer settles the question for any candidate card:
- Fix one card at a constant distance and orientation from the antenna — tape it down; wobble invalidates the test.
- Run a continuous inventory in the session your production readers will use, and count reports per second for the same EPC.
- Repeat in S1, then S2/S3. A chip with strong persistence collapses to a single report in every session; a weak one floods S1 but behaves in S3.
- Now make it hard: add distance or angle until reads become marginal. Weak-persistence chips get chattier as the field gets patchy — exactly the condition a busy dock door produces.
Run the same protocol on the free samples before a production order, using your own reader and settings rather than anyone’s datasheet — persistence is the kind of analog behavior that only your RF environment can certify. Background on the protocol stack lives in our RFID technology guide.
The takeaway
"Mystery" RFID field behavior is almost always a protocol detail wearing a trench coat. Zebra's read-once behavior is not magic — it is a well-engineered chip's flag persistence cooperating with S1 inventory rules. You can buy the same behavior (Monza-based cards), or you can design for it (S3 plus de-duplication) and stop caring which chip shows up. Understanding the layer underneath is what turns a support ticket into a spec decision — and a spec decision made once beats a support ticket answered every deployment.
FAQ
Why does my UHF card keep being read continuously under S0/S1?
Because that is Gen2's default: a powered tag answers every Query. Read-once behavior only appears when the tag's inventoried flag stays in state B between inventory rounds — which depends on the session used and the chip's flag persistence time.
What is the practical difference between sessions S0/S1 and S3?
S0 resets the inventoried flag as soon as power is lost, S1 holds it only for a short capacitor-backed persistence window, and S2/S3 hold it substantially longer while the tag remains energized. For "count each tag once" workflows, S2/S3 plus a host-side de-duplication window is the dependable combination.
Can RFIDAK supply cards that behave like Zebra's read-once cards?
Yes — we supply UHF cards built on Impinj Monza R6 / R6-P with the same flag-persistence behavior, MOQ from 500 pieces. Request free samples and test them on your own reader and session settings before ordering.
Sources
- GS1 — EPC UHF Gen2 Air Interface Protocol (the session and inventoried-flag definitions). gs1.org
- ISO/IEC 18000-63 — Parameters for air interface communications at 860–960 MHz (Type C). iso.org
- Impinj — Monza R6 tag chip family. impinj.com
- Impinj Support — session and persistence guidance for inventory tuning. support.impinj.com
- NXP — UCODE UHF tag chip family. nxp.com
Need help turning this guidance into a product shortlist?
Use this next step when the article has narrowed the direction and you now need help choosing chips, formats, samples or the closest product family.
Quick FAQ
Questions buyers often ask after reading this guide
Why does my UHF card keep being read continuously under S0/S1?
Because that is EPC Gen2's default: a powered tag answers every inventory Query. Read-once behavior only appears when the tag's inventoried flag stays in state B between inventory rounds - which depends on the session in use and the chip's flag persistence time. In S1 the flag is held by an on-die capacitor for a nominal 500 ms - 5 s, so a chip with weak persistence snaps back to state A during scan gaps and re-reports as new.
What is the difference between EPC Gen2 sessions S0, S1, S2 and S3?
S0 holds the inventoried flag only while the tag is powered and resets it the instant power is lost. S1 holds it for a nominal 500 ms - 5 s window that decays even while the tag stays powered - the only session where chip capacitor quality matters. S2 and S3 hold the flag indefinitely while energized and for more than 2 seconds after power loss. For count-each-tag-once workflows, S2/S3 plus a host-side de-duplication window is the dependable combination.
What is tag persistence time in RFID?
Persistence time is how long a Gen2 tag's session inventoried flag survives after RF power dips or disappears. In S1 the flag lives on a small on-die storage capacitor, so persistence varies chip to chip: premium silicon such as Impinj Monza holds the flag through microsecond scan gaps, while weaker chips let it decay and re-answer as if never read. The Gen2 spec sets minimums; how far past them a chip goes is a silicon-quality question.
How do I make any UHF card read only once?
Two routes that also combine well. Hardware: specify cards on chips with strong S1 flag persistence (e.g., Impinj Monza R6/R6-P) so the existing S0/S1 reader setup produces one read. System: switch the inventory to session S2/S3, whose flags hold far longer, and enable de-duplication in the reader software or middleware (report each EPC at most once per time window). The system route is sturdier because it works regardless of which chip arrives.
Do sessions matter when multiple readers cover the same area?
Yes - that is their second job. Each of the four sessions carries an independent inventoried flag on the tag, so a handheld sweeping in S2 does not reset the state a fixed portal tracks in S3. Deliberately assigning different sessions to different reader roles prevents readers from trampling each other's inventory state; two readers accidentally sharing S1 is a classic cause of tags reappearing mid-count.
Does read-once behavior depend on the reader brand?
Only indirectly. Any Gen2-compliant reader can select the session and target flag, so the reader determines which persistence regime applies - but within S1, whether the flag actually survives between inventory rounds is decided by the chip inside the card, not the reader brand. That is why identical reader settings can produce single reads from one vendor's cards and a continuous stream from another's.
How can I test flag persistence before ordering UHF cards?
Fix one sample card at constant distance and orientation from the antenna, run continuous inventory in your production session, and count reports per second for the same EPC. Repeat across S1 and S2/S3, then degrade the link with distance or angle - weak-persistence chips grow chattier as the field gets patchy. Run this on free samples with your own reader rather than trusting a datasheet; persistence is analog behavior your RF environment has to certify.
Do HF or NFC cards have sessions like UHF Gen2?
No. Sessions and inventoried flags are specific to the EPC Gen2 / ISO 18000-63 UHF air protocol. HF 13.56 MHz cards (ISO 14443 MIFARE/NTAG families) use a different anti-collision scheme, and read-once behavior there is handled by the reader application layer, not by tag-side session flags. If your project mixes HF credentials and UHF tracking, the two stacks are tuned independently.
Author
RFIDAK RFID Editorial Team
Manufacturer editorial team
RFIDAK publishes practical RFID guides to help buyers compare chips, product formats, sampling plans and sourcing options before production.
