RFID tags are small chips stuck to cartons, pallets, tools, or products. Unlike a barcode, they don’t need to be scanned one at a time. Readers and antennas placed around a building pick them up automatically as items move past.
What a reader actually produces is a long stream of sightings: this tag was seen by this antenna at this moment, with this signal strength. On its own, that isn’t what the business wants. The business wants to know whether a pallet arrived, whether it left the building, whether it passed inspection, and whether it’s ready to ship. Turning sightings into those answers is where most of the real software work happens.
A sighting isn’t a decision
When a reader sees a tag, that’s a clue, not proof. It doesn’t necessarily mean the item went through the door. Tags get read many times in a row. They get picked up by an antenna at the next dock over. Metal shelving and damp cardboard bounce and block radio signals, so reads can be patchy.
So I keep the raw sightings separate from the conclusions the software draws from them. That way the rules can be adjusted, for example “it has to be seen at both doors within 10 seconds”, without losing the original evidence. It also means that when someone asks “why does the system think this pallet is in Bay 4?”, there’s a clear answer.
Expect repeats, gaps, and late arrivals
In the real world, the same reading may arrive twice, arrive late, or go missing for a while. The software needs a clear plan for each. It should spot duplicates, decide what to do with a reading that shows up five minutes late, and know what it missed during a network outage.
On busy sites I usually add a holding area that collects incoming readings so the rest of the system can work through them at a steady pace. That way a sudden rush, like a full truck going through a dock door, doesn’t freeze the screens staff are using.
“Where is it now?” and “where has it been?” are different questions
Some businesses mainly need to know what’s here right now. Others need a full history of every movement for traceability or audits. Many need both.
They call for different approaches. Keep every single reading forever and the data grows very quickly. Keep only the current location and you lose the evidence you might need to investigate a problem later. So I agree on the rules up front: how long to keep raw readings, how long an item can go unseen before it counts as gone, and how moves between areas are recorded.
Build screens people can actually use
A live view of tag activity only helps if it stays responsive when hundreds of readings arrive at once, and if it helps people understand what’s going on. I separate “what’s here now” from “what happened”, show clearly whether each reader is connected, and make sure the screen keeps up.
Staff on the floor need to see the exceptions, not a wall of data. A tag the system doesn’t recognize. An item that turned up somewhere unexpected. A reader that has gone quiet. A pallet that doesn’t match the order it’s meant to belong to. Those are the things worth putting front and centre.
Connect it to the rest of the business
RFID data becomes valuable when it feeds into inventory, production, shipping, or access control. That means every item needs a reliable ID, it’s clear which system has the final say on an item’s status, and there are rules for when what the readers saw doesn’t match the paperwork. A tag reading shouldn’t quietly overwrite a confirmed shipment unless someone has decided that’s okay.
I also plan for everyday realities: readers going offline, clocks on different devices drifting apart, a reader being swapped out, settings being changed. And before anyone relies on the system, I test it with realistic volumes and deliberately unplug things to see how it copes.
What makes it work
Reliable RFID isn’t really about reading more tags. It’s about turning imperfect sightings into information people can trust and explain, and being honest on screen about what the system knows and what it doesn’t.