UHF RFID Reader API Guide

LLRP — the EPCglobal low-level reader protocol and its role in portable integration

Every UHF integration starts the same way. A pallet of readers arrives, the project plan cheerfully says 'integrate the readers,' and you find that 'the readers' means several brands, a fistful of SDKs, and a protocol everyone claims to support but implements with its own accent. The reassuring part is that a genuine common substrate sits underneath the marketing — and reaching it is what saves you from rewriting the application every time procurement switches vendors. LLRP (Low Level Reader Protocol) is the EPCglobal-standardized, ISO-ratified protocol for controlling Gen2 UHF RFID readers over TCP/IP. It is the integration substrate for most enterprise fixed readers and gives application developers a single protocol they can target regardless of reader brand. Understanding LLRP's object model is the foundation of any portable UHF integration.

• Origins and standardization: LLRP was ratified by EPCglobal in 2007 and published as ISO/IEC 24791-5. It specifies a binary message format over TCP (default port 5084) for reader control, inventory operations, reader configuration and event subscription. LLRP abstracts the Gen2 air-interface protocol so application code doesn't have to generate raw Gen2 commands.
• Message categories: LLRP defines four major message categories: configuration (GET_READER_CAPABILITIES, GET_READER_CONFIG, SET_READER_CONFIG), ROSpec/AccessSpec lifecycle (ADD_ROSPEC, ENABLE_ROSPEC, START_ROSPEC, STOP_ROSPEC, DELETE_ROSPEC), reports (RO_ACCESS_REPORT with tag data), and events (READER_EVENT_NOTIFICATION for antenna, GPI and spec-timing events). Applications follow a state-machine pattern: configure reader, define ROSpec, enable spec, process reports, dispose of spec.
• ROSpec (Reader Operation Specification). Defines when and how the reader performs inventory: antenna selection, inventory duration, mode index (dense-reader vs. low-reader), session, search mode, Q-parameters, and whether to include TID/user memory in reads. Enterprise deployments use ROSpecs tuned to their environment (dense-reader mode for portal installations with many simultaneous readers; optimal-reader mode for standalone installations).
• AccessSpec: defines tag read/write operations (read EPC/TID/user memory, write, lock, kill, block-permalock). AccessSpec filters specify which tags the operation applies to (EPC mask + filter). Enterprise encoding programmes use AccessSpecs to commission, decommission or re-encode tags on conveyor lines or bench setups.
• LLRP client libraries: developers rarely write raw LLRP binary messages. Available libraries include llrpjs (JavaScript), llrp-toolkit (Java), sllurp (Python), Intermec LLRPToolkit (C#), and vendor-provided LLRP bindings. All produce the same wire format; choice is driven by application language and library maturity.
• LLRP over TLS and authentication. LLRP itself does not mandate TLS, but most enterprise readers support LLRP over TLS (port 5085 or configurable) with client-certificate authentication. Production deployments wrap LLRP in TLS, restrict network access to the reader, and manage reader-side credentials per the customer's security policy.

Impinj SDKs — Octane, ETK, ItemSense, R700 REST API

Impinj is the dominant RAIN RFID chip and reader vendor, and their SDK ecosystem spans multiple tiers. Understanding the Impinj SDK stack is essential for integrators working with Speedway and R-series readers (R420, R440, R510, R520, R700; the R720 has reached end-of-life per Impinj's published product change notification, with new and replacement deployments standardising on the R700 series) and xPortal, which together represent a large share of enterprise UHF RFID deployments.

• Impinj Octane SDK: the traditional high-level SDK for Speedway and R-series readers, available in Java, C#/.NET and Java-on-Android bindings. Wraps LLRP with semantic classes (ImpinjReader, Settings, Antennas, TagPopulation, TagReportListener, GpiEvent, GpoPinEvent). Useful for developers who want an opinionated API rather than raw LLRP.
• Impinj ETK (Embedded Development Kit). Enables on-reader application development for the R700 platform (the upgraded R700 ships with a dual-core 1 GHz 64-bit ARM Cortex-A53, 64-bit Linux 6.6 OS and roughly twice the processor performance plus 3x the application memory of the original R700; the R720 reached end-of-life). Applications written in Python, C++ or Go run directly on the reader, consuming tag data locally and publishing processed events to downstream systems via MQTT, Kafka, REST or custom protocols. Useful for edge-processing patterns where reducing upstream bandwidth is critical.
• Impinj ItemSense: Impinj's cloud-connected middleware for managing large reader networks. Handles job scheduling, reader configuration at scale, zone-based tag location tracking, and data stream publishing. Integrators choose ItemSense when the reader network exceeds 10-50 fixed readers and per-reader configuration becomes operationally expensive.
• Impinj R700 REST API and MQTT. Modern Impinj smart readers include native REST APIs for configuration plus MQTT event publishing. Integrators can bypass LLRP entirely and treat the reader as a REST/MQTT endpoint, which simplifies cloud-native architectures but is vendor-specific. R700 firmware 9.0.1 was required for ETSI customers to meet the EU Radio Equipment Directive (RED) cybersecurity baseline that took effect 2025-08-01; firmware 10.x has since added Gen2X performance and enterprise-security enhancements.
• Impinj chip features relevant to API integration. Monza 4/5/6/X-8K/X-2K and M700/M750/M800 chips support features (protected mode, encoded memory, short-range commissioning, optimized air protocol commands) that require AccessSpec / OpSpec commands to exercise. Integrators working with these features need to understand both the SDK abstraction and the underlying chip behaviour.
• Migration paths: legacy Octane SDK code migrates reasonably cleanly to the R700 REST+MQTT pattern when integrators adopt newer readers (the R720 line has reached end-of-life; Impinj's customer notification names the R700 as the upgrade path), with the ETK providing an alternative migration for edge-application patterns. Greenfield enterprise projects in 2025-2026 increasingly start with REST/MQTT rather than Octane.

Zebra, ThingMagic, Alien and the broader fixed-reader SDK ecosystem

Beyond Impinj, the enterprise fixed-reader market includes Zebra (FX7500, FX9600, ATR7000, FXR90), ThingMagic/JADAK (M6e, Nano, Sargas, Izar), Alien Technology (ALR-F800, ALR-9900, ALR-9680) and others. Each vendor offers an SDK ecosystem that wraps LLRP or provides proprietary alternatives. This section surveys the major vendor stacks integrators work with.

• Zebra Reader SDK and DataCapture DNA. Zebra's flagship SDK supports Java, C#/.NET, C++ and Android for FX- and ATR-series readers. Features include tag-location estimation (ATR7000 array-antenna readers), mode profiles optimized for specific use cases (retail DC, manufacturing, laundry), and native integration with Zebra's cloud services. DataCapture DNA is Zebra's broader toolkit for data-capture devices (scanners, mobile computers, RFID) unifying configuration, firmware management and analytics across device types.
• Zebra 123RFID Desktop / 123RFID Mobile. Configuration and diagnostic tools for integrators commissioning Zebra readers on-site. 123RFID Mobile enables handheld reader set-up and tag scanning from Android; 123RFID Desktop is the PC-side companion. Useful for pre-deployment testing and field diagnostics, although not a production integration API.
• ThingMagic Mercury API: JADAK/ThingMagic's SDK for M6e, Nano, Sargas, Izar and embedded modules. Available in Java, C, C# and Python (python-mercuryapi). Mercury API exposes readers as a single reader-like interface regardless of form factor (USB, embedded, fixed), which simplifies development for projects mixing embedded and fixed readers. Popular with OEMs embedding ThingMagic modules in custom hardware.
• Alien Gateway and Alien RFID Academy. Alien's configuration and SDK tools for ALR-F800, ALR-9900 and handheld H-series readers. Alien readers historically use a command-line-style protocol over Telnet/SSH or a JSON-based API on newer firmware. Alien is common in library, laundry, and access-control verticals where the readers have been deployed for years.
• Other enterprise vendors: Siemens, Turck, Fujitsu, Omron, Caen RFID, Nordic ID, Honeywell and Bluebird offer fixed and handheld UHF readers with their own SDKs. Most support LLRP as a fallback for portability, plus a proprietary SDK with vendor-specific features (Turck Vilant Engine integration, Honeywell IntelliTrack).
• Handheld reader SDKs: Chainway, Nordic ID, Zebra TC-series, Honeywell CN-series, Alien H-series, and Unitech RP-series provide Android-based handheld readers with Java/Kotlin SDKs for in-app RFID integration. Handheld SDKs typically expose the reader as an Android service with tag-event callbacks to the integrator's Android application.

Integration patterns — polling, event-driven, filtered, MQTT/Kafka, WebSocket bridges

Choosing the right integration pattern is often more important than the specific SDK — and the wrong one rarely shows itself in the demo. It waits until well after go-live, picks the busiest dock door of the quarter, and fails there. The pattern determines latency, reliability, operational overhead and how naturally the architecture scales. This section surveys the common patterns and when each fits.

• Polling inventory: application periodically calls the reader's inventory endpoint and retrieves the current tag population. Simple and easy to debug, fits cycle-count-style workflows, inventory-audit use cases and low-update-rate applications. Drawbacks: transient tag reads can be missed between polls, and high-frequency polling wastes bandwidth. Not recommended for dock-door portals or high-throughput dispatch.
• Event-driven (callback / subscription). Reader pushes tag events to the application as they are detected, via LLRP report callbacks, vendor-SDK event listeners or MQTT topic subscriptions. Lowest latency pattern, required for conveyor-integration, dock-door receive/ship, and real-time location tracking. Application must handle bursts (dock-door portals can emit 500-2000 tag events in 5-10 seconds).
• Filtered reads: reader-side filters (EPC mask, AccessSpec filter, session flags) constrain which tags are reported. Reduces event volume when many tags are present but only a subset is relevant (e.g., one tenant's EPCs in a 3PL environment). Critical for keeping event-driven pipelines tractable at scale; requires careful EPC-scheme planning so filters are efficient.
• MQTT event streaming: reader publishes tag events to an MQTT broker (Mosquitto, HiveMQ, AWS IoT Core, Azure IoT Hub). Downstream consumers subscribe to topic hierarchies (site/dock/antenna), enabling many-to-many event routing without tight coupling between reader and backend. Fits IoT and cloud-native patterns especially well; supports offline buffering and replay on reader-side.
• Kafka event streaming: for customers with a Kafka-based data platform, readers (via edge middleware or ETK applications) publish tag events directly to Kafka topics. Enables durable event logs, multi-consumer fan-out, stream-processing pipelines and integration with data-lakehouse architectures. Increasingly common in large consumer-goods and retail enterprises.
• WebSocket bridges: browser-based dashboards and shopfloor apps subscribe to live tag events via WebSocket. The WebSocket endpoint is typically served by an edge middleware component that bridges LLRP/SDK events to browser clients. Fits real-time UI patterns (live zone-tracking dashboards, pick-face visualization, yard-management screens).
• Hybrid architectures: enterprise deployments typically mix patterns. Real-time operational flows (receive, ship, put-away) run event-driven over MQTT or Kafka; audit and reconciliation flows run polling-style scheduled queries; dashboards subscribe via WebSocket. The orchestration layer (edge middleware, vendor platform, custom integration bus) coordinates these patterns against the operational requirements.

Reader I/O — GPIO, antennas, RSSI, direction detection, location estimation

Beyond pure tag-read events, UHF RFID reader APIs expose a rich control surface for I/O orchestration, antenna management and advanced features (RSSI, phase, Doppler) that enable location and direction detection. Integrators building automated material-handling systems exercise these APIs extensively.

• GPIO (General Purpose Input/Output) — most enterprise readers include 4-8 GPI lines (inputs from external sensors — light curtains, photo-eyes, proximity switches) and 4-8 GPO lines (outputs to external actuators — light stacks, conveyor gates, audible alarms, shipping-lane diverters). API control of GPIO enables RFID-triggered automation without separate PLCs for simple use cases.
• Antenna configuration: readers with 4-8-16 antenna ports support per-antenna configuration (transmit power, receive sensitivity, mode, polarization). APIs let applications adjust power per antenna for in-situ optimization (higher power on weaker antennas, lower power to avoid adjacent-portal cross-reads). Polarization control distinguishes linear and circular antennas.
• RSSI (Received Signal Strength Indication). Each tag-read event includes an RSSI value (dBm). Applications use RSSI trends to infer tag-to-antenna distance roughly (useful for zone detection) and to filter out weak, peripheral reads. Not a reliable precise distance metric but useful as a feature in a multi-signal decision.
• Phase angle and Doppler. Advanced readers (Impinj Speedway, R-series, R700; Zebra FX9600) report RF phase per read, enabling more sophisticated location algorithms (multipath analysis, direction-of-travel, tag-velocity estimation). Zebra ATR7000 uses an antenna array to compute Azimuth-Elevation angles directly, enabling meter-level tag localization without complex per-antenna tuning.
• Direction detection: retail exit portals and dock-door portals need to know whether a tag is entering or exiting. Direction detection combines multiple antennas (inside vs. outside the portal), RSSI trends, phase angle and timing heuristics. Vendor SDKs increasingly offer built-in direction detection (Impinj Direction, Zebra DirectionDetection) rather than requiring custom implementation.
• Zone detection and location tracking. For real-time location systems (RTLS), reader networks combine RSSI, phase and antenna-geometry data to assign tags to zones or compute continuous location estimates. Vendor platforms (Impinj ItemSense, Zebra MotionWorks) wrap this complexity; open-source alternatives (OpenRTLS) exist but require more integration work.

Security, network hardening and operational concerns for production API integrations

Enterprise UHF RFID deployments are network-connected, often exposed to warehouse-floor networks and sometimes to internet-facing cloud platforms. Security, observability and operational practices need to be planned as carefully as the functional integration.

• Network isolation and firewalls. Readers should be on a dedicated VLAN or subnet, with firewalls restricting inbound connections to the integration endpoints (application servers, MQTT broker, ItemSense cluster). Outbound connections from the reader should be similarly restricted. Production deployments audit reader network exposure as part of the security review.
• Authentication and TLS: LLRP-over-TLS, HTTPS for REST endpoints, MQTT-over-TLS with client certificates, SSH with key-based login for reader administration. Default reader credentials must be changed during commissioning. Enterprise deployments integrate reader authentication with the customer's directory service (LDAP/AD) where supported.
• Firmware management: reader firmware updates patch security vulnerabilities and introduce new API features. Managing firmware across hundreds of readers requires a firmware-management tool (Impinj Directory Services, Zebra Device Tracker, ItemSense Reader Configuration, customer-internal tooling) with staged rollouts and rollback capability.
• Observability and monitoring: production readers emit telemetry (CPU, memory, temperature, network, RF-environment RSSI distributions) and operational events (read-rate trends, antenna power drifts). Integration into the customer's monitoring platform (Grafana, Datadog, Splunk) enables proactive detection of failing readers and tuning-drift events.
• Rate limits and backpressure. High-throughput RFID flows (peak dock-door traffic) can burst event rates 10-100x above nominal. Integration layer must implement backpressure handling (per-reader queues, bounded buffers, event batching) so transient bursts don't overwhelm downstream systems. Kafka-based architectures handle this naturally; polling / direct-callback architectures need explicit buffering.
• Disaster recovery and store-and-forward. Readers should buffer events when upstream connectivity fails and replay them on recovery. LLRP supports report-buffering to a limited extent; modern MQTT/Kafka-on-reader patterns (via ETK or vendor edge runtimes) offer richer store-and-forward semantics. Integrators should test DR scenarios (network partition, broker outage) during commissioning.

Concrete code patterns for LLRP, Octane and MQTT integration

The copy-paste starting points below cover the integration paths integrators use 80% of the time: LLRP ROSpec creation with sllurp, Impinj Octane Java event listeners, MQTT subscription with paho-mqtt, a REST configuration call against the Impinj R700, and the GPI-triggered AccessSpec pattern used on conveyor-integration projects.

• LLRP ROSpec with sllurp (Python). Minimal inventory stream with tag reports: `from sllurp.llrp import LLRPReaderConfig, LLRPReaderClient, LLRP_DEFAULT_PORT; cfg = LLRPReaderConfig({'antennas':[1,2,3,4],'tx_power':[30,30,30,30],'mode_identifier':1002,'session':2,'report_every_n_tags':1,'tag_content_selector':{'EnableAntennaID':True,'EnablePeakRSSI':True,'EnableLastSeenTimestamp':True,'EnableTagSeenCount':True}}); client = LLRPReaderClient('10.0.1.50',LLRP_DEFAULT_PORT,cfg); client.add_tag_report_callback(lambda r,tags:[print(t['EPC-96'].hex(),t['PeakRSSI']) for t in tags]); client.connect(); client.join(None)`. The keys above are exactly what sllurp's tag_content_selector accepts (per the project README); to also capture TID or User memory, attach an AccessSpec with a C1G2Read OpSpec (bank 2 for TID, bank 3 for User), not a tag_content_selector flag.
• Impinj Octane SDK (Java). Event listener pattern: `ImpinjReader reader = new ImpinjReader(); reader.connect("speedway-01.local"); Settings settings = reader.queryDefaultSettings(); settings.getReport().setIncludeAntennaPortNumber(true); settings.getReport().setIncludePeakRssi(true); reader.applySettings(settings); reader.setTagReportListener((r, report) -> { for (Tag tag : report.getTags()) { System.out.println(tag.getEpc() + " " + tag.getPeakRssiInDbm()); } }); reader.start();`. The same pattern in C#/.NET replaces the lambda with a delegate.
• Impinj R700 REST configuration. Set TX power and inventory profile via HTTPS: `curl -u root:impinj -X PUT https://r700.local/api/v1/profiles/inventory -H 'Content-Type: application/json' -d '{"antennaConfigs":[{"antennaPort":1,"transmitPowerCdbm":3000,"rfMode":1002,"session":2}],"reportFilter":{"type":"none"}}'`. The matching Python call: `httpx.put('https://r700.local/api/v1/profiles/inventory', json=body, auth=('root','impinj'), verify=False)`. ETSI customers must run firmware 9.0.1 or later for EU RED compliance (effective 2025-08-01); FCC region readers can use 8.x or later.
• Impinj R700 MQTT subscription. `import paho.mqtt.client as mqtt; c = mqtt.Client(); c.username_pw_set('root','impinj'); c.tls_set(cert_reqs=ssl.CERT_NONE); c.connect('r700.local', 8883); c.subscribe('rfid/events'); def on_msg(c,u,m): evt = json.loads(m.payload); print(evt['epc'], evt['rssi'], evt['antennaPort']); c.on_message = on_msg; c.loop_forever()`. Each message is a single tag event with EPC, timestamp, antenna port and optional TID/user memory.
• Zebra Reader SDK (Java/Android). Tag read event: `IMPINJ_PC_CONFIG config = new IMPINJ_PC_CONFIG(); reader.Events.setTagReadEvent(true); reader.Events.addEventsListener(new RfidEventsListener() { public void eventReadNotify(RfidReadEvents e) { TagData[] tags = reader.Actions.getReadTags(100); for(TagData t: tags) Log.i("RFID", t.getTagID() + " RSSI=" + t.getPeakRSSI()); } }); reader.Actions.Inventory.perform();`. Handhelds use the same event callback against an Android service.
• LLRP AccessSpec: write EPC on trigger (GPIO 1 high) using sllurp: define `AccessSpec` with trigger on `GPI_PORT_STATE_CHANGE_EVENT`, an `OpSpec` of type `C1G2Write` targeting EPC memory bank 1, word offset 2, with the new EPC bytes. ROSpec and AccessSpec IDs must be unique across the reader. On trigger, tag in range gets re-encoded atomically; the reader emits an `AccessReport` with success/failure status (`WordPointerInvalid`, `InsufficientPower`, `NonSpecificTagError`).
• MQTT topic hierarchy convention. Use `rfid/{site}/{dock}/{antenna}/event` for tag events and `rfid/{site}/{dock}/{antenna}/status` for operational status. Downstream consumers subscribe with wildcards (`rfid/+/dock01/+/event` captures everything at dock 01). Use QoS 1 (at-least-once) for tag events where duplicates are acceptable; QoS 2 for commissioning/decommissioning events where exactly-once matters.
• Backpressure pattern in Python — wrap sllurp callback in a bounded `asyncio.Queue` or `queue.Queue(maxsize=10000)`, and on `queue.Full` exception either drop oldest events (retail inventory — some loss acceptable) or slow reader via `client.pause_inventory()` (conveyor-critical — no loss allowed but reader pauses).

Tag encoding compatibility, Proud Tek SDK support and integrator engagement

Reader API integration is only half of the system picture. The tag data structures the application parses must be consistent with the encoding approach deployed on tags. Proud Tek's tag supply and encoding services are designed to fit cleanly into integrator workflows across the SDK ecosystem described above.

• Gen2-compliant encoding across all reader APIs. All Proud Tek UHF tags are encoded to GS1 EPC Gen2v2 standards (SGTIN-96, SSCC-96, GRAI-96, GIAI-96) readable by any LLRP, Octane, Zebra Reader SDK, Mercury API, Alien Gateway, or handheld-vendor SDK. Standard compliance means your integration doesn't need per-tag-batch adjustments when you switch reader hardware or add new SDKs.
• TID-to-EPC mapping files. Proud Tek's pre-encoding service returns a TID-to-EPC mapping CSV with each production lot. This file imports directly into Impinj Octane tag-database lookups, Zebra Reader SDK inventory callbacks, sllurp tag-dictionary initialization, or custom application tag-resolution caches. Eliminates the need for customers to run their own encoding verification pass.
• Encoding specifications reviewed with SDK in mind. For complex integration patterns (per-zone filters, per-antenna reads, advanced direction detection), Proud Tek's encoding specifications can be tuned for filter-value consistency (uniform GS1 filter value for fast antenna-level filtering), serial-number locality (sequential serials for efficient AccessSpec ranges), or company-prefix segmentation (per-product-line prefixes for clean MQTT topic routing).
• Chip-family selection aligned with reader features. Impinj M700/M750/M800 chips work optimally with Impinj readers leveraging Autopilot and Power Management features; NXP UCODE 9/UCODE 9xe chips work well with Zebra and other multi-vendor deployments. Proud Tek's application engineering team advises on chip selection when customers are standardizing reader hardware across a multi-site rollout.
• Developer sample kits: for evaluation and SDK development, Proud Tek ships sample kits containing assorted EPC encodings, filter values and form factors (labels, hang tags, on-metal tags, flag tags). Developers can exercise filter-mask logic, direction detection and location-estimation algorithms against realistic tag populations before committing to production encoding.
• Integration support during go-live (during the first 2-4 weeks of a new reader-API integration, Proud Tek's application engineering team is available for read-rate troubleshooting, filter-mask optimization, and antenna-placement advisory) coordinating with the customer's reader vendor (Impinj, Zebra, Chainway) and integration partner as needed. Most integrations reach steady-state operation within 1-2 weeks of commissioning; tuning adjustments continue for 4-6 weeks as real-world tag mixes and operational patterns shake out.

Vendor SDK reference table — Impinj Octane classes, Zebra Reader SDK callbacks, sllurp lifecycle

Connect to a reader, configure it, listen for tags — conceptually it is the same short dance everywhere. The only thing that genuinely changes between vendors is how many ways there are to spell the steps. When integrators jump between SDK ecosystems, the same conceptual operation has different class names, method signatures and event-listener patterns. This reference table compresses the most-used SDK entry points so a team migrating between Impinj Octane, Zebra Reader SDK and sllurp can locate the equivalent operation quickly. Names are taken from the vendor developer portals and the sllurp project README accessed in May 2026.

• Impinj Octane (Java / .NET). Connect: `ImpinjReader reader = new ImpinjReader(); reader.connect(hostname);`. Configure: `Settings settings = reader.queryDefaultSettings(); settings.getReport().setIncludeAntennaPortNumber(true);`. Apply: `reader.applySettings(settings);`. Tag events: `reader.setTagReportListener((r, report) -> { for (Tag t : report.getTags()) { ... } });`. Start/stop: `reader.start(); ... reader.stop();`. GPI events: `reader.setGpiEventListener(...)`. Octane wraps LLRP underneath; raw LLRP error codes still surface via OctaneSdkException.
• Zebra Reader SDK (Java / Android, the same class names work for FX9600 fixed and MC3390R handheld). Connect: `RFIDReader reader = readers.GetAvailableRFIDReaderList().get(0); reader.connect();`. Configure: `reader.Config.setTriggerInfo(triggerInfo); reader.Events.setTagReadEvent(true);`. Tag events: `reader.Events.addEventsListener(new RfidEventsListener() { public void eventReadNotify(RfidReadEvents e) { TagData[] tags = reader.Actions.getReadTags(100); } });`. Perform inventory: `reader.Actions.Inventory.perform();`. Pre-filter: `reader.Actions.PreFilters.add(...)`.
• sllurp (Python). Connect: `client = LLRPReaderClient(host, LLRP_DEFAULT_PORT, config); client.connect()`. Configure via the `LLRPReaderConfig` dict argument (antennas, tx_power, mode_identifier, session, tag_content_selector). Tag events: `client.add_tag_report_callback(lambda reader, tags: ...)`. Block: `client.join(None)`. Stop: `client.disconnect()`. Reset a hung reader from the CLI: `sllurp reset <host>`. CLI helpers: `sllurp inventory <host>` and `sllurp --debug inventory --impinj-search-mode N <host>` to set Impinj search modes.
• Impinj R700 REST + MQTT (replaces Octane for cloud-native architectures). Configure via REST: `PUT https://<reader>/api/v1/profiles/inventory` with JSON body containing `antennaConfigs[]`, `transmitPowerCdbm`, `rfMode`, `session`. Stream tag events via MQTT on default topic `rfid/events` (TLS port 8883, auth `root/<password>`). Trigger commands via REST: `PUT https://<reader>/api/v1/profiles/start` and `/stop`. Pin firmware: R700 ETSI customers need 9.0.1+ for EU RED compliance (effective 2025-08-01); FCC region can run 8.x or later.
• LLRP (vendor-neutral). Message types: GET_READER_CAPABILITIES, GET_READER_CONFIG, SET_READER_CONFIG, ADD_ROSPEC, ENABLE_ROSPEC, START_ROSPEC, STOP_ROSPEC, DELETE_ROSPEC, ADD_ACCESSSPEC, ENABLE_ACCESSSPEC, RO_ACCESS_REPORT, READER_EVENT_NOTIFICATION, KEEPALIVE / KEEPALIVE_ACK. Default TCP port 5084 plain, 5085 TLS where supported. Use Wireshark with the `llrp.lua` dissector for binary debugging.

Debugging and performance tuning for UHF reader integrations

UHF RFID reader integrations share a recognizable set of failure modes. Unexpectedly low read rates, phantom reads, backpressure failures, multi-reader interference, and edge cases in direction detection. This section walks through the debugging techniques and operational observations that teams develop during the first few production weeks.

• Low read rate in expected-good conditions. First check transmit power (defaults vary from 25 dBm to 32.5 dBm per FCC ERP limit; setting max power doesn't always help and can increase multipath interference). Then check session setting. Session 2 or session 3 behave differently than session 0/1 and are the right choice for portal applications where you want tags to stay 'asleep' after first read. Finally check mode: DRM (Dense Reader Mode) reduces channel usage at the cost of raw read rate; DRM is mandatory in some deployments but hurts throughput.
• Phantom reads (tags appearing that shouldn't be there). Caused by RF leakage past the expected read zone, multipath reflections, or antenna cross-coupling. Mitigate with physical RF shielding (RF-absorber panels around portal edges), lower transmit power on outer antennas, EPC-mask filtering to reject out-of-scope tag populations, and RSSI thresholds (reject reads below -70 dBm as peripheral).
• Multi-reader interference in dense deployments. ETSI 302 208 restricts 4 channels in Europe so multiple readers share spectrum; FCC Part 15.247 gives 50 channels but still has frequency-hopping collision risk. Use dense-reader mode (Miller-4 or Miller-8 encoding), synchronized transmit windows (LBT. Listen Before Talk for ETSI), and reader-to-reader communication via the vendor platform (ItemSense) or coordinated scheduling.
• Direction detection false positives. Portals see tags on forklifts driving parallel (not through) the portal; deliver false 'shipped' events. Mitigate with multi-antenna voting (require read from both inbound and outbound antenna before declaring direction), minimum dwell time (tag must be in zone for N seconds), RSSI trend monitoring (increasing then decreasing RSSI indicates pass-through), and business-rule sanity checks (don't ship tags with known 'stock' status).
• Tuning DRM/mode for your tag population. More modes (Miller-4, Miller-8) improve dense-reader performance but reduce raw throughput. Measure the actual read-rate-vs-mode curve on a sample of your tags at your intended transmit power. Impinj's R_Mode tool and Zebra's 123RFID Desktop both provide this measurement. For high-dense deployments with 500+ readers at a DC, you often accept 500 tag/s per reader in Miller-8 to avoid interference, rather than 1500 tag/s per reader at Miller-2 which causes cascading failures.
• RSSI distribution as a health indicator. Track per-antenna RSSI distributions over time. Sudden shifts (mean dropping by 5+ dBm week-over-week) indicate antenna cabling degradation, connector corrosion or environmental change. Use this as a predictive maintenance signal rather than waiting for read-rate to visibly fail.
• Capturing LLRP traffic for deep debugging. Wireshark has an LLRP dissector (llrp.lua) that decodes the binary protocol. Capture with `tcpdump -i eth0 -w llrp.pcap port 5084`, open in Wireshark, filter `llrp.message_type`. Useful when reader behavior doesn't match SDK expectations. The raw LLRP messages reveal whether the reader accepted the ROSpec, what errors it returned, and whether expected reports actually arrived.
• Load testing with synthetic tag populations. Before commissioning a portal for a 2000-case/hour dock, load-test the integration with a tag-event generator (sllurp includes a mock reader mode; Impinj SpeedwayR can be scripted to replay recorded streams; custom scripts using paho-mqtt can publish simulated events at target rates). Verify that downstream processing (ERP API calls, Kafka producer throughput, database writes) sustains the peak rate with acceptable latency. Many integrations fail in production because the reader works fine but the backend can't keep up with bursts.

FAQ