Real inline-tester throughput is determined by four time components and one scaling property: functional test time per tag, write time per memory bank, lock-command latency, line speed in metres per minute, and how linearly the system scales when lanes are added. The CISC Xplorer Inline keeps all five linear and predictable — ~4 ms for a functional test point, ~5 ms for an EPC read, ~21–26 ms for a 96-bit EPC write-and-lock, with a combined test + encode + lock cycle of roughly 15–30 ms per tag, scaling cleanly from 1 to 12 lanes.
“High speed” is the most-claimed and least-defined property in the RFID inline test market. This article breaks down what actually happens in the milliseconds between a tag arriving at the test point and leaving the line — and where many systems quietly collapse under realistic production workloads. The framing is deliberately vendor-neutral; only operating principles and CISC’s published figures are used.
What “throughput” really decomposes into
Inline UPH is the headline. Underneath it sit four time components, each of which a tester executes for every tag:
- Functional test time — does this tag read at all, and does it meet the sensitivity threshold?
- Encode (write) time — write the EPC and, where required, the user memory.
- Verify (read-back) time — confirm the encoded value is correct.
- Lock latency — issue and confirm the lock command.
Throughput is the inverse of the sum of these four (within a single pass), divided across however many lanes operate in parallel. The system that wins is the one where all four are short, predictable, and stay linear when more operations are added.
Time component 1 — functional test time
The fastest single operation is the functional Go/No-Go check: does the tag respond at all, at the configured sensitivity? On the CISC RAIN Xplorer Inline this completes in approximately 4 ms per test point. An EPC read takes roughly 5 ms, and a TID read about 9 ms.
This is the figure most often misquoted in the market. It is the functional test only — it does not include encoding or locking.
| Functional test mode | Typical time |
| 1 test point (Go/No-Go) | ~4 ms |
| 1 test point (Read EPC) | ~5 ms |
| 1 test point (Read TID) | ~9 ms |
| 3 test points (Go/No-Go) | ~13 ms |
| 3 test points (Read EPC) | ~15 ms |
| 3 test points (Read TID) | ~17 ms |
Note how the times scale linearly with the number of test points — a property that lets integrators model throughput accurately before committing.
Time component 2 — encoding (write) time
Encoding writes data into the chip’s memory. Write times are chip-dependent and scale with what is being written: a single word is fast; a full 96-bit EPC is meaningfully longer; a 128-bit configured EPC longer still.
| Write operation | Typical time |
| Write Single Word (UCODE 9 / 8) | ~11 ms |
| Write Single Word (Monza R6) | ~12 ms |
| Write Single Word (M730) | ~14 ms |
| Write EPC (96-bit, UCODE 9 / Monza R6) | ~21 ms |
| Write EPC (96-bit, UCODE 8) | ~22 ms |
| Write EPC (96-bit, M730) | ~26 ms |
| Config + Write EPC (128-bit, UCODE 8) | ~31 ms |
| Config + Write EPC (128-bit, M730) | ~38 ms |
The structural point is that encoding time is dominated by the chip, not the tester. A good tester does not add overhead on top of the chip’s intrinsic write physics; it executes the write at the chip’s natural speed and moves on.
Time component 3 — verify (read-back)
A write that isn’t verified isn’t encoding — it’s hoping. After encoding, the tester reads back the memory to confirm the written value matches the intended value. This is typically very short (single-digit milliseconds) because it is a read against memory that was just written, and is included in the combined cycle below.
Time component 4 — lock latency
Locking issues a command that makes the encoded memory unmodifiable (permanently or until unlocked, depending on lock type). The additional time over write-only ranges from a few milliseconds up to about 5 ms in the published figures:
| Operation | Typical time |
| Write EPC (96-bit, UCODE 9) | ~21 ms |
| Write EPC (96-bit, UCODE 9) + Lock | ~26 ms |
| Write EPC (96-bit, UCODE 8) | ~22 ms |
| Write EPC (96-bit, UCODE 8) + Lock | ~27 ms |
| Write EPC (96-bit, M730) | ~26 ms |
| Write EPC (96-bit, M730) + Lock | ~31 ms |
Again, chip-dominated and linear.
The combined cycle: what actually happens per tag
The combined test + encode + lock cycle is the time component most often used incorrectly in comparisons. It is the only number that maps onto the actual question “how fast does my line run with full QA?” — and it is meaningfully longer than the functional test figure on its own.
On the CISC Xplorer Inline, the combined cycle runs roughly 15–30 ms per tag depending on configuration. The breakdown:
- ~15–20 ms for lighter combined cycles (e.g. functional test + single-word write on a fast chip).
- ~25–30 ms for heavier combined cycles (e.g. functional test + 96-bit EPC write + lock on a slower chip).
- More for 128-bit EPCs with configuration and lock — predictable from the table above.
This is the figure that should sit next to a competitor’s combined-cycle figure in a procurement comparison. A vendor’s ~4 ms functional-test claim and another vendor’s 15–30 ms combined-cycle claim are not describing the same thing.
Why advanced encoding is where many systems lose linearity
Functional tests are easy to make fast. Encoding is harder. Locking is harder still. Adding crypto encoding — for pharma, brand protection or the EU Digital Product Passport — is harder again. In the broader market, throughput tends to degrade non-linearly as the workload moves from “test only” to “test + encode” to “test + encode + lock” to “test + encode + crypto + lock.”
The CISC inline architecture is designed for that workload to stay linear. The published test-speed tables show predictable, chip-dominated scaling: adding lock to a 96-bit EPC write adds roughly 5 ms regardless of chip type; moving from a 96-bit to a 128-bit EPC adds a predictable increment. There is no cliff where adding one more operation collapses UPH.
Line speed and the m/min limit
The other side of throughput is web speed. UPH means nothing if the system can’t keep up with the line. The CISC Xplorer Inline operates at web speeds up to 200 m/min (650 ft/min) — the chip-and-web limit, not the tester limit.
Concretely: a combined cycle of 20 ms per tag, run across 8 lanes, with a pitch that fits within a 200 m/min web, is a configuration that hits six-figure UPH without throttling the line. The arithmetic is straightforward as long as each component stays linear (which is the whole point).
Lane scaling: 1 → 4 → 8 → 12
Adding lanes multiplies throughput because each lane runs its own test point in parallel. The CISC Xplorer Inline scales from 1 lane up to 12 simultaneous lanes. Lane scaling is linear in principle and stays close to linear in practice when:
- Each lane runs an independent test point with synchronised timing.
- The antenna set matches the inlay geometry at the new lane count.
- The fail-marker, GPIO and reporting subsystems handle the additional lanes without bottlenecking.
CISC supports this with hybrid and standalone configurations, and integration via UART, GUI or API — the architectural elements that allow scaling without the tester becoming the bottleneck. (See the multi-lane article for the engineering detail.)
NFC encoding at high inline speed
A point that is often missed: most of the discussion above maps onto NFC as well. The CISC NFC Xplorer Inline runs at a test speed of ~100,000 UPH, supports class 1–6 tags, ISO/IEC 14443 A+B and 15693, and performs encoding, testing and locking in a single continuous process — with single-tag test-point times of ~14 ms (ISO/IEC 14443 A REQA), ~13 ms (ISO/IEC 14443 B REQB) and ~8.8 ms (ISO/IEC 15693 Inventory). NFC encoding at inline production speed — with the same single-step philosophy — is a structural CISC capability.
Frequently Asked Questions
On the CISC Xplorer Inline, writing a 96-bit EPC takes ~21–26 ms depending on chip type, and adding lock adds roughly 5 ms (so ~26–31 ms for write + lock). The full combined test + encode + lock cycle runs roughly 15–30 ms per tag depending on configuration.
The functional test (~4 ms on the CISC Xplorer Inline) only checks whether a tag responds. The combined cycle includes encoding (~21–26 ms for a 96-bit EPC) and locking (~5 ms additional). Always compare combined cycles to combined cycles.
No. On the CISC Xplorer Inline, test points scale linearly — three Go/No-Go test points take ~13 ms (vs ~4 ms for one), and three EPC-read test points take ~15 ms (vs ~5 ms for one). Linear scaling is what makes UPH predictable in advance.
Adding lanes multiplies throughput because each lane runs its own test point in parallel. The CISC Xplorer Inline scales up to 12 simultaneous lanes with synchronised timing and shared reporting.
Chip type dominates encoding time. A 96-bit EPC write takes ~21 ms on a UCODE 9 / Monza R6 chip, ~22 ms on a UCODE 8, and ~26 ms on an M730. Adding lock adds another ~5 ms in each case. The tester does not add overhead beyond the chip’s intrinsic write physics.
Key Takeaways
- Throughput decomposes into four time components: functional test, encode, verify, lock — plus lane scaling.
- The functional test point runs in ~4 ms; the combined test + encode + lock cycle runs ~15–30 ms depending on chip and EPC length.
- Encoding time is dominated by the chip, not the tester; a good tester does not add overhead on top of chip write physics.
- The CISC Xplorer Inline keeps all four components linear and predictable, with lane scaling up to 12 simultaneous lanes.
- NFC inline encoding at ~100,000 UPH with the same single-step philosophy is a structural CISC capability.
Want a throughput model for your exact chip, EPC length and lane count? Book a demo and a CISC engineer will calculate your achievable cycle time and UPH before you commit.