Technology 📅 September 5, 2026 ⏱ 12 min read

Gen2v3 and Gen2X: What to Ask a RAIN RFID Reader Manufacturer

A UHF RAIN RFID fixed reader on a bench beside a laptop showing firmware release notes and a protocol clause in a tender document

A datasheet lands on your desk with a line near the bottom: Gen2v3-ready. Or Gen2X-enabled. Both look like the same class of claim — a protocol box ticked — and both are turning up more often on RAIN RFID reader specifications. Each is a different class of claim entirely. One names an open air-interface standard published by GS1 alongside the RAIN Alliance. The other names an extension defined by a single silicon vendor and handed out royalty-free. One of them can be true on a datasheet while the other remains an open question you still need to ask.

The distinction has money attached to it. One of these is a compliance question that affects what you can write into a tender and what you can hold a supplier to. The other is an ecosystem question that affects which tags you buy and what performance you actually see on the floor. Tell them apart and you write a clause a supplier can meet, and you budget a tag line that matches the performance you were quoted.

This is what we tell procurement engineers who ask us to help draft the protocol section of a specification: what each term means, what it demands from the reader and from the tag, which parts are genuinely a firmware matter, and the four or five questions that separate a supplier who builds readers from one who resells them. We build the hardware and the software in-house, so these are the questions we expect to be asked.

Two names, two different things

Gen2v3 is a standard. It is an update to the UHF RAIN air interface introduced in January 2025 by the RAIN Alliance together with GS1, which led the update. RFID Journal describes it as the first protocol release in a decade, following Gen2v2 in 2013, and reports that the working groups behind it began planning the upgrade about five years before launch — this is a slow, consensus-built document, arrived at over years of working-group ballots. Updates to the corresponding ISO/IEC standard coincide with it, and at the time of reporting the working group had passed a first membership ballot.

Gen2X is a vendor extension. It was released by Impinj in December 2024 and is a standards-compatible enhancement to the radio and logical layers of the Gen2 protocol, which keeps the underlying standard intact and interoperable. Impinj’s CEO letter states plainly that the company has “already given Gen2X royalty-free to all leading reader manufacturers, including Zebra Technologies,” and that its Gen2X patents sit inside a cross-licence with its primary endpoint IC competitor. Impinj’s own summary of the programme names Zebra and EM Microelectronics among announced licensees.

The version history, briefly

Gen2v2 (2013) — the security and privacy command set most deployed estates run today, and the version RFID Journal measures the decade against.
Gen2v3 (January 2025) — filtering and memory-access commands aimed squarely at crowded read environments, with backward compatibility maintained so existing Gen2v2 deployments keep working.

Side by side

	Gen2v3	Gen2X
What it is	An update to the open UHF RAIN air-interface standard	An extension to the Gen2 radio and logical layers
Who defines it	GS1, in alignment with the RAIN Alliance	Impinj
Introduced	January 2025	December 2024
Licensing	Open standard, with an ISO/IEC counterpart in ballot	Given royalty-free to leading reader manufacturers; patents cross-licensed
What the reader needs	A software and firmware update	Firmware support on the reader or module
What the tag needs	New tag silicon	Endpoint ICs that carry the extension
Question it answers	Compliance — what can I specify?	Ecosystem — what will I actually see?

Read the table once more and notice the asymmetry in the bottom two rows. That asymmetry is the whole commercial story, and we come back to it below.

What Gen2v3 actually adds

The headline additions are filtering commands and a smarter way to get at memory. RFID Journal’s coverage of the launch names three.

QueryX and QueryY

These let a reader efficiently select only the tags of interest in a population before an inventory round begins — specific EPC schemes, or specific tag features. That sounds modest until you think about what an inventory round costs. In a dense population, the reader spends its time arbitrating collisions among tags the process never wanted: every slot given to a tag on the next pallet, the next aisle, or the next portal is a slot not given to the tag you are trying to read. Narrowing the population before arbitration starts attacks the problem at its source, upstream of any software filtering you apply afterwards.

ReadVar

ReadVar lets the reader select stored data to read in a more convenient and effective way, rather than pulling back everything encoded on the tag. Where a tag carries an identifier and little else, this is a refinement. For anything writing meaningful content into user memory — a batch code, a service record, the kind of payload a digital product passport implies — it is the difference between one efficient access and a sequence of reads that ties up air time.

Where the gain is largest

The pattern is consistent: Gen2v3’s filtering is worth most wherever the reader can see more tags than the business process cares about.

Dock doors sitting close together, where a portal reading a neighbouring lane’s pallet produces a receiving error that costs an hour to unpick.
Adjacent portals in a corridor, the classic case where the physics of the read zone and the geometry of the building disagree.
High-density retail floors and stockrooms, where a handheld sweep is competing with thousands of tags for a fixed amount of air time.
Mixed populations, where cartons, items and returnable transport items share a zone and only one class matters for the transaction in progress.

If those descriptions match your site, this is a roadmap item worth tracking now. Where read points are isolated and tag populations are small, antenna placement and zone geometry are the levers that move your numbers first, and Gen2v3 filtering compounds on top of them as density rises. We scope it in that order — the same order that drives a warehouse management deployment: zone discipline first, protocol features second.

The dividing line that matters commercially

Here is the single most useful fact in this article, and it comes straight from RFID Journal’s launch coverage: tag chip makers must develop new RAIN RFID tag chips to comply with Gen2v3, while reader manufacturers need only update their software — the hardware already on the wall carries the capability. Backward compatibility is maintained, so existing Gen2v2 deployments keep working.

Unpack that into budget language and it splits cleanly in two.

Your reader estate is a roadmap item. The readers you buy this year are candidates for the capability, delivered as a firmware release, provided the supplier controls the firmware and the hardware architecture carries it. It stays an operating-expense item: a scheduled firmware release against readers already on the wall.
Your tag supply is a purchasing decision. The capability arrives with new silicon, which means new inlays, new part numbers, requalification against your substrate and your read distances, and a lead time that belongs to the chip industry’s calendar rather than yours.

Buyers routinely read this the other way round. They treat the reader as the expensive, immovable part and the tag as the cheap, fungible part, because that is true of the purchase price. For protocol capability the order is inverted, and planning it in the inverted order is what keeps a migration affordable.

How to phrase the question so the answer is checkable

Specific questions produce checkable answers. These four are answerable only with facts:

“Which Gen2v3 commands does your current firmware implement, and which are on your roadmap? Name them individually.”
“Is the capability delivered by a firmware update to the readers I am buying today, or does it arrive with a different hardware revision or module?”
“Give me the firmware version number that carries it and the release note that names it.”
“Who writes that firmware — your team, or your module supplier’s?”

The fourth question is the one that sorts the field. The update date belongs to whoever writes the firmware. Ask who that is and you learn whose release calendar your roadmap actually sits on. A supplier who writes the firmware can put a version and a release note in front of you. That is why we build hardware and software under one roof and answer as one point of accountability — one team owns the answer, and it comes with a version number attached.

Gen2X: what it is and what it demands from both ends

Gen2X is further along in the field than Gen2v3, simply because a single vendor can move faster than a standards body. Impinj reported in 2025 that partners had launched more than 85 production Gen2X-enabled inlays, and that more than 50 RAIN RFID readers, modules and printers had been upgraded to support it. A later Impinj post puts the inlay count above 100. Devices supporting it read both Gen2X-capable endpoint ICs and the rest of the estate — Gen2X and Gen2 interoperate seamlessly.

The reported field results

Dense shelf inventory. In an r-pac and Chainway demonstration on densely populated shelves, a Gen2X-enabled handheld read 98% of the items in 13 seconds, against 79% of the items in standard Gen2 mode over the same interval.
File and document handling. Impinj describes a customer cutting the time to inventory 500 files by 50 seconds — a 50% reduction in inventory time — using Gen2X-enabled devices with M830 endpoint ICs.
Read range. RFID Journal, reporting on Impinj’s upgraded reader platform, notes that increasing tag sensitivity by 2 dB equates to a 26% increase in read range. That is the mechanism worth understanding: sensitivity gains compound into range because of the inverse-square relationship, which is why a couple of decibels of tag sensitivity shows up as a measurable step in read distance.

Named capabilities in the set include Gen2X Fast Reinventory, Gen2X Tag Selection — which lets readers better specify which tags should respond during inventory and which should stay quiet — and Impinj Endpoint IC Verification for confirming an endpoint IC is genuine.

The part worth stating plainly

Gen2X performance enhancements show up when a supporting reader is reading tags built on supporting endpoint ICs. Gen2X support now spans several endpoint IC series — Impinj has extended it to the M770, M775, M780 and M781 alongside the M800 family — so the uplift follows the link between a supporting reader and a supporting IC. It is a property of the chain rather than of the box.

Practically, that means a “Gen2X-enabled reader” line item on a quotation is half a sentence. The other half sits on the tag purchase order. A Gen2X performance number stands up when it is quoted against a named inlay — ask which inlay it was measured with, and the number becomes something you can hold to. This is a live consideration for apparel and fashion retail deployments, where inlay selection is already governed by a brand’s approved list, and for any inventory count that is graded on first-pass accuracy.

Reading a ‘Gen2v3-ready’ or ‘Gen2X-enabled’ claim on a datasheet

Protocol claims are quick to write and worth checking properly, because they carry real budget consequences downstream. Four checks turn a claim into something testable.

1. Commands implemented, or commands intended?

“Ready” is a word doing a great deal of work. Ask for the list, command by command. A supplier who has implemented QueryX will name it. Ask for the command list and the answer tells you where the implementation stands. A dated roadmap with named commands is a perfectly good answer, and often the honest one in 2026 — it should simply be labelled as a roadmap, with the date and the command names attached.

2. What does the claim attach to?

The reader, the radio module inside it, or a specific firmware build? These are three different scopes. A module vendor’s capability reaches your integration once the reader’s host application, the API and the SDK expose it. Ask which layer carries the new commands, and whether your SDK surfaces them. If your software talks to the reader through a vendor SDK, that question is the one that decides whether your developers can actually call the feature.

3. Get the version and the release note

Ask for the firmware version number that carries the capability and the release note that names it. This is a document a manufacturer can produce in an afternoon. It also pins the claim to something dated, which converts a marketing line into a contractual reference you can put in the specification.

4. Design an acceptance test for a behaviour, not a number

Protocol features are proven by comparison rather than by a single meter reading. The method that works is comparative and runs on one reader:

Build a fixed, documented population — a stated tag count, a stated inlay part number, a stated arrangement and orientation, at a stated distance.
Run the same population past the same reader with the feature enabled and disabled, several passes each, at the conveyor or forklift speed the site actually uses.
Measure first-pass read rate and time-to-complete, and record both. A feature that improves completion time as well as first-pass rate is telling you something real about your site.
Repeat with a deliberate interference population — a second tagged pallet parked where the neighbouring lane would be. Filtering features earn their money exactly here.

Write that method into the tender. It costs a supplier an hour and it tells you more than any datasheet line.

Where this sits alongside the reader-as-edge-computer shift

The reason “firmware, not silicon” holds for readers at all is architectural, and it is worth understanding because it tells you which readers can honestly make the promise.

Fixed readers have quietly become Linux computers with a radio attached. Impinj’s upgraded R700, as reported by RFID Journal, runs a dual-core 1 GHz 64-bit ARM A53 processor under 64-bit Linux 6.6, with three times the embedded application memory of its predecessor and twice the processor performance. The upgrade is form-, fit- and function-compatible with the previous generation, and both share a common firmware image, so an estate can hold both revisions under one management regime.

The load-bearing detail is the modem. RFID Journal notes that an FPGA-based modem inside the new reader gives it the flexibility to add future Gen2X innovations via software upgrades. That is the mechanism. A modem implemented in fixed-function silicon does what it was taped out to do; a modem implemented in reconfigurable logic can learn a new command set from a firmware image. When a supplier tells you a protocol update is a firmware matter, that architecture is what stands behind the promise, and it is a fair thing to ask about.

Protocol filtering and on-reader filtering are complements

Gen2v3’s QueryX and QueryY reduce what the reader interrogates. On-reader logic reduces what the reader reports. You want both, and they solve different halves of the same problem: air time upstream, network and application load downstream. Deduplicating hundreds of reads of the same tag in a single dwell into one arrival event, applying a dwell-time rule before anything is emitted, holding readings through a WAN outage and replaying them in order — that is work that belongs at the read point, on the application memory those newer readers ship with.

This is the design philosophy behind running rules on the reader itself: the read point decides what constitutes an event, and the server receives business facts instead of a firehose. A site that filters well at both layers gains compounding value from each protocol version it adopts.

RFID moving onto the application processor

There is a second shift running in parallel, and OEM/ODM buyers should have it on their radar because it changes handheld bills of materials.

Qualcomm’s Dragonwing Q-6690 product brief describes it as the world’s first enterprise mobile processor with a fully integrated UHF (RAIN) RFID reader, stating that the integration “eliminates the need for bulky, external RFID reader modules” and lets enterprise and industrial mobile devices read UHF RFID tags natively. The brief lists the RFID reader functionality as Gen2X-capable, alongside an octa-core Kryo CPU running to 2.9 GHz on a 4 nm process, a Hexagon 7xx AI engine rated at 6 TOPS, Wi-Fi 7, 5G and UWB, with UHF RFID appearing as a block in the processor diagram next to the modem and the GPU.

Where it lands

For a handheld or a rugged tablet, this takes a discrete module, its interface, its power tree, its thermal budget and its separate firmware lifecycle out of the design. It also puts an on-device AI engine adjacent to the read stream, which is a genuinely different proposition for things like reconciling a read against an image of the shelf.

For fixed infrastructure the engineering stays where it has always been. A dock-door portal is defined by transmit power, antenna count and placement, cable loss, duty cycle, enclosure rating and the regulatory band it ships configured for — gates and portals remain a hardware engineering problem, which is the discipline we build in. Holding that boundary in mind keeps the handheld conversation and the portal conversation each on its own engineering footing.

The question for an OEM/ODM buyer

If you are having a device built to your specification, ask how your supplier tracks silicon roadmaps — both the reader-side chips and the application processors — and what happens to your product when a module you depend on reaches end-of-life. The answer tells you how much of the design lifecycle your supplier owns. We build to both models and export under both, and we open that conversation at the quotation stage rather than at the second production run.

A protocol section for your tender specification

Here is a skeleton you can lift into a document. It is deliberately short. Each clause is written so the answer is a fact a supplier can put in writing.

Clause	What a good answer looks like
Air-interface standard and version	The GS1 UHF Gen2 version number and the matching ISO/IEC part, stated explicitly — the UHF RAIN air interface is ISO/IEC 18000-63, and Gen2v3 arrives with an update to it. Be precise with part numbers: ISO/IEC 18000-65:2026, published on 13 February 2026, is a different part, covering air-interface parameters for streaming sensors based on ISO/IEC 18000-63. Naming the right part number is what keeps the clause enforceable.
Vendor extensions relied upon	Named, not implied. If Gen2X is required, the clause should also name the tag-side dependency, because the benefit lives in the link between reader and endpoint IC.
Regulatory band configuration	The band the units ship configured for, and the approvals held for the destination market. Protocol version and radio approval are separate axes and both belong in the specification.
Firmware update mechanism	How an update is delivered and applied across a fleet, whether it can be staged and rolled back, and whether it can be done remotely without a site visit.
Support term for protocol updates	A stated number of years during which protocol-level firmware updates are provided, and what follows that term. The answer tells you how long the protocol roadmap is contracted for.
Acceptance test	First-pass read rate at a stated speed, orientation, distance and population size, with the named inlay part number, measured with the feature on and off on the same unit.
Escalation path	Named owner for a read-performance defect. Where tags, reader and software come from three suppliers, the clause should say who leads and who is obliged to participate.

That last row deserves a sentence of its own. Name a single owner for read performance. Where the reader firmware, the middleware and the application come from one house, that owner is obvious and the acceptance test is something to pass together. Where they come from three, write the lead and the obliged participants into the contract at the outset, while everyone is still keen to win the work.

The short version

Gen2v3 is the standard, arriving with new silicon on the tag side and a firmware update on the reader side. Gen2X is a vendor extension, already broadly available, royalty-free to reader manufacturers, and dependent on matching endpoint ICs to deliver its numbers. Ask which commands, ask for the firmware version and the release note, ask who writes the firmware, and design an acceptance test that compares the same population on the same reader with the feature on and off. Any supplier who can answer those four is worth talking to about the rest of your project.

Frequently asked questions

What is Gen2v3 in RFID?

Gen2v3 is the latest version of the UHF RAIN RFID air-interface protocol — the rules that govern how readers and tags talk to each other. It was introduced in January 2025 by the RAIN Alliance together with GS1, which led the update, and RFID Journal describes it as the first protocol release in a decade, following Gen2v2 in 2013. Its headline additions are the QueryX and QueryY commands, which let a reader efficiently select only the tags of interest in a population before an inventory round begins by selecting specific EPC schemes or tag features, and ReadVar, which allows more selective access to stored data rather than returning everything encoded on the tag. Backward compatibility is maintained, so existing Gen2v2 deployments continue to operate.

What is the difference between Gen2v3 and Gen2X?

Gen2v3 is an open standard published through GS1 in alignment with the RAIN Alliance, with a matching ISO/IEC update. Gen2X is an extension to the Gen2 radio and logical layers defined by Impinj, released in December 2024 and licensed out to the industry. The practical difference is what a claim commits a supplier to: Gen2v3 is a compliance question you can write into a tender against a published specification, while Gen2X is an ecosystem question whose benefits depend on the tags you buy as well as the reader. A datasheet line claiming one leaves the other as a separate question to ask.

Can an existing RFID reader be upgraded to Gen2v3 with firmware?

For readers, Gen2v3 is a software and firmware matter rather than a hardware one. RFID Journal’s launch coverage states that reader manufacturers will only need to update their software, while tag chip makers must develop new silicon. Whether any specific reader in your estate can take that update depends on its architecture — readers whose modem is implemented in reconfigurable logic can learn new protocol behaviour from a firmware image, which is why Impinj describes the FPGA-based modem in its upgraded R700 as enabling future capabilities via software upgrade — and on who writes your supplier’s firmware. Ask for the firmware version number and the release note that names the capability.

Do Gen2v3 tags work with Gen2v2 readers?

Yes. The Gen2 family maintains backward compatibility, and RFID Journal reports that existing Gen2v2 deployments will continue functioning with the arrival of Gen2v3. A Gen2v3-capable tag presented to a Gen2v2 reader is inventoried using the command set both ends share, and the new filtering and memory-access commands wait for a reader that speaks them. That is what makes a phased migration realistic: you can phase readers and tags on separate schedules and separate budgets.

Is Gen2X royalty free?

Impinj’s CEO letter states that the company has given Gen2X royalty-free to all leading reader manufacturers, naming Zebra Technologies, and that its Gen2X patents are included in a cross-licence with its primary endpoint IC competitor. Impinj’s own summary of the programme names Zebra and EM Microelectronics among the announced licensees. For a buyer, the useful consequence is that a Gen2X claim on a reader datasheet arrives licence-free at the reader end, so the cost sits in the tag choice rather than in the radio. Adoption has been broad — more than 50 readers, modules and printers and over 85 production inlays as of Impinj’s 2025 availability update, with a later post putting the inlay count above 100.

Does Gen2X improve RFID read range?

Range gains come through tag sensitivity. Reporting on Impinj’s upgraded reader platform, RFID Journal notes that increasing tag sensitivity by 2 dB equates to a 26% increase in read range. Speed gains have also been demonstrated: in an r-pac and Chainway demonstration on densely populated shelves, a Gen2X-enabled handheld read 98% of items in 13 seconds against 79% in standard Gen2 mode over the same interval, and Impinj describes a file-management customer cutting the time to inventory 500 files by 50 seconds, a 50% reduction. All of these depend on the reader talking to tags built on supporting endpoint ICs — the improvement is a property of the link, so quote it against a named inlay.

Which ISO standard covers the RAIN RFID air interface?

ISO/IEC 18000-63 is the part covering air-interface communications for passive UHF RFID, and it is the ISO/IEC counterpart to the GS1 UHF Gen2 protocol. RFID Journal reports that 18000-63 was updated alongside Gen2v3 and that the working group had passed a first membership ballot. Be careful with adjacent part numbers when writing a specification: ISO/IEC 18000-65:2026, published on 13 February 2026, covers air-interface parameters for streaming sensors operating in the 860 MHz to 930 MHz range, based on ISO/IEC 18000-63, and is a different document. Cite the part number you actually mean.