ASQUARETE

Case study

Reading pallets at the dock door — Zebra FX9600 + LLRP middleware

A distribution center needed to know which pallets crossed a dock door, and in which direction, without a scanner in anyone's hand. A fixed Zebra FX9600 reader with LLRP middleware infers direction from read-order and antenna geometry.

Device · Zebra FX9600Role · Fixed-reader middleware + RF tuningStack · LLRP, C#, .NET, SQL Server

A distribution center wanted to know, automatically, which pallets moved through a specific dock door and whether they were headed inbound or outbound — without a forklift driver stopping to scan anything. The dock door was a natural chokepoint: everything physically had to pass through it, which made it a good candidate for a fixed-infrastructure read point instead of handheld scanning at every touch.

The ask was a fixed UHF reader mounted at the dock door, reliably capturing every tagged pallet that passed, with enough confidence in direction (in vs. out) to update inventory location automatically.

The problem

A fixed reader at a dock door faces two problems handhelds mostly avoid. First, anti-collision and read reliability at speed — a forklift moving a pallet through the doorway gives the reader a window of maybe one to two seconds per tag, and a busy shift can have multiple pallets close together, with tags on adjacent, unrelated pallets staged nearby also in range. Second, and this was the harder one: a single read event tells you a tag was present, not which way it was moving. Direction has to be inferred, and RFID reads alone don't carry a direction field.

Hardware used

ItemRole
Zebra FX9600Fixed UHF RFID reader, 4-port
2× antennas (inbound-side, outbound-side)Physical direction inference via read-order
LLRPReader control + tag report protocol
C# / .NET middlewareDirection logic, event publishing to WMS

Architecture

Two antennas were mounted on either side of the dock door's physical width, angled so each one's read zone is biased toward one side of the passage rather than overlapping evenly across the whole opening. The reader operates in an LLRP ROSpec that reports which antenna port produced each read, along with a timestamp — direction is inferred from the order antennas "see" the same tag, not from anything the tag itself communicates.

   Antenna A (inbound side)     Antenna B (outbound side)
        |                              |
        v                              v
   [dock door opening, pallet path]
                |
                v
        [FX9600, LLRP ROSpec]
                |
                | tag reports: EPC, antenna port, timestamp
                v
        [C# middleware: read-order state machine]
                |
   A-then-B, within window --> INBOUND
   B-then-A, within window --> OUTBOUND
   single-antenna only       --> ambiguous, logged not acted on
                |
                v
        [WMS event: pallet location update]

The middleware keeps a short-lived per-EPC state machine: the first antenna to report a tag starts a window (a couple of seconds, tuned to typical forklift speed through the door); if the second antenna reports the same EPC within that window, direction is resolved from the order. If only one antenna ever reports a tag — which happens when a pallet is staged near the door but doesn't actually pass through — the event is logged as ambiguous and explicitly not acted on, rather than guessing.

What was tricky

RF tuning at a dock door is a physical problem dressed as a software one, and it took longer than the LLRP integration itself. The first antenna placement had enough overlap between the two read zones that a pallet sitting still near the middle of the doorway would get read by both antennas within the same window and register as a false direction event with no actual movement. Fixing it meant physically narrowing each antenna's effective read zone — lower transmit power on each port, tighter physical angling — until stationary pallets near the door reliably triggered only one antenna or neither, and only a pallet that actually traversed the full width triggered the two-antenna sequence. This was mostly trial and error done on-site with a tag on a pallet jack, not something that could be fully solved from a spec sheet.

The other recurring issue was tag orientation on non-uniform pallets — a tag mounted flat against a stretch-wrapped pallet reads fine, but the occasional oddly-shaped or metal-adjacent load produced weak reads that only one antenna caught reliably, generating ambiguous events. These were logged rather than silently miscounted, and the client's ops team accepted a small ambiguous-event rate as a known limitation rather than something to chase to zero.

Result

The dock door now logs inbound/outbound pallet movement automatically for roughly 96% of tagged pallets crossing it, with the remainder logged as ambiguous rather than wrong. That freed the manual scan step that previously required a forklift driver to stop and scan at the door, which had been a recurring point of missed scans during busy shifts. The ambiguous-event rate is monitored, and RF tuning has been revisited once since go-live as pallet mix on that dock changed seasonally.


Role · Fixed-reader middleware + RF tuning

Stack · LLRP, C#, .NET, SQL Server

Updated Oct 30, 2025

Similar hardware on your desk?

Send the device model, the SDK, and what's failing. You get a written feasibility read within 24 hours.

Get a feasibility read

Another case study