You asked for a change—and you’re right to ask. Farsens historically bridged to the sensor via read/write commands to User memory. Kliskatek now embeds sensor data inside the EPC and parses it appropriately on the application side. We design both ways, because each has clear pros and cons. Below I’ll lay out the two paths without favoring either, so you can pick what fits your deployment.
Quick refresher: the memory banks that matter
Gen2/RAIN tags organize non‑volatile memory into four banks:
- MB00 – Reserved: Access/Kill passwords
- MB01 – EPC (aka UII): Identifier + control fields (PC/XPC); can also carry additional data depending on your encoding scheme
- MB10 – TID: Tag chip identifier (read‑only)
- MB11 – User: Optional, variable‑size area for custom data
This layout is defined by EPC Gen2 / ISO/IEC 18000‑63 and widely documented across the ecosystem.
Path A — Embed sensor data in the EPC (inventory‑readable)
What it is: Encode the sensor payload inside EPC/UII memory so that a standard inventory (no Access/Read/Write step) retrieves both identity and the latest sensor value. Modern GS1 EPC Tag Data Standard (TDS 2.x) explicitly supports carrying AIDC data within EPC/UII as an alternative to storing it in User memory—so you can get that data via regular inventory backscatter.
Why teams like it:
- Lower power & faster capture: Inventory reads scale to hundreds–thousands of tags/s, while writes are orders of magnitude slower (typical write rates ≈ single‑digit tags/s). That gap exists across readers and modes.
- Shorter dwell, simpler workflows: No Access/Read/Write transaction; you inventory and parse. (Impinj documentation shows reader modes tuned for high inventory throughput; GS1 TDS 2.x adds EPC schemes that keep inventory processing efficient.)
- Standards‑friendly parsing: TDS 2.x introduces new EPC+ schemes and clarifies how supplemental AIDC data can be encoded after the EPC, keeping interoperability with GS1 keys and barcodes.
Trade‑offs you must manage:
- Identity stability: If the EPC changes with each measurement, systems expecting a stable EPC must adjust. (TDS explains PC/XPC length handling; tools like Zebra’s guidance show how PC bits must match EPC data length.)
- Parsing discipline: Your middleware needs robust decoders for EPC formats (TDS/TDT rules), especially if you append sensor fields.
- EPC size vs. performance: Longer EPCs slightly increase backscatter time; choose compact field encodings and only what’s essential per read window. Reader‑mode tuning still matters.
A compact EPC‑embedded pattern (example)
- EPC core: GS1 identifier (e.g., SGTIN or GRAI) for stable item/asset identity
- Appended fields (after EPC):
ver | flags | sensor_type | scaled_value(few bytes total) - PC/XPC: Adjust for EPC length; document endianness and versioning
TDS 2.x is the authoritative guide for how to legally place AIDC data after the EPC within the EPC/UII bank and still read it via inventory.
Path B — Bridge via User memory (write, then read)
What it is: Measure on the tag, WRITE the payload into MB11 (User), then READ it when asked. This is the approach we used at Farsens and we still support it at Kliskatek for deployments that benefit from richer, persistent data.
Why teams like it:
- Stable EPC identity: EPC remains constant; middleware can key on EPC while fetching User memory blocks for sensor data.
- More room for payloads & logs: User memory can be larger (hundreds of bits to kilobytes) and is designed for custom data; GS1 provides encoder/decoder tooling aligned with TDS.
- Gen2 keeps improving reads: GS1’s Gen2 updates (v3.0) even add commands that simplify capture of data encoded in User/TID, making reading user payloads easier for interrogators.
Trade‑offs you must manage:
- Energy & speed: Write transactions are slower and require more energy at the tag (non‑volatile programming), whereas inventory reads are much faster. Practical figures: >1,000 tags/s for reads vs. ≈7 tags/s for writes in common Gen2 implementations. Plan for reader dwell time.
- Access & locking: You’ll handle Access passwords, write locks, and idempotent write logic to avoid corruption under intermittent power; RAIN’s RCI covers inventory vs. access behaviors.
- Parser still needed: You must specify offsets, endian, CRC, scaling, and versioning for the user payload so any RAIN reader/middleware can parse deterministically. GS1 tools help, but consistency is on you.
When to pick which (neutral guidance)
Choose EPC‑embedded if…
- You need rapid, low‑power reads at scale (cycle counts, fly‑by audits).
- Your application can parse EPC variants (PC/XPC aware) and tolerate small, appended sensor fields in EPC/UII.
Choose User‑memory bridge if…
- You must keep EPC identity immutable while storing richer payloads/logs or multi‑channel data.
- You control reader dwell time and can afford write latency/energy to persist values or audit trails.
Both approaches are standards‑compliant, widely supported by RAIN readers, and future‑proofed by ongoing GS1 updates.
Practical design patterns we implement at Kliskatek
A) EPC‑embedded (inventory only)
- Identity: EPC core (e.g., SGTIN/GRAI)
- Sensor block:
ver | flags | type | value_scaledappended after EPC - Reader flow:
INVENTORY (read EPC/UII)→ parse → publish - Notes: Document PC/XPC rules and ensure the parser handles EPC length changes exactly per TDS/TDT.
B) User‑memory payload (write + read)
- Layout (example, 16 bytes):
ver | flags | type | scale | value | Vstart | Vend | seq | CRC16 - Reader flow:
INVENTORY → (ACCESS) → READ MB11two words minimum → parse - Notes: Use GS1 tools for encoding/decoding and keep writes idempotent; plan for slower throughput vs. inventory.
Deployment checklist (both paths)
- Standards mapping documented (TDS/TDT for EPC; fixed offsets for User)
- Reader mode tuning for inventory throughput (and minimal collisions)
- PC/XPC handling (if EPC‑embedded) and Access controls (if User‑memory bridge)
- Energy/dwell planning: inventory is faster; writes are slower—schedule accordingly
- Parser tests with mixed tag populations and variable payload lengths (per TDS/TDT)