RFID AND WAREHOUSE TRACKING
The readers are the easy part. The hard part is turning a firehose of raw reads into something your existing software can use, and knowing which direction a pallet was going. Here is what usually goes wrong, what to buy rather than build, and where the middleware earns its money.
RFID is sold on the hardware, and the hardware is rarely the difficulty. Readers work. Tags work. What surprises people is the shape of what comes out.
A fixed reader at a gate does not produce tidy events. It produces a continuous stream of the same tag, seen hundreds of times, from several antennas, at varying signal strength, including tags that happened to be near the doorway and were never going through it at all. Your warehouse system wants one line: this pallet left, at this time. Nothing in the raw stream says that.
Everything between those two things is the work, and it is the part that is missing from most quotes.
The question that catches projects out. Not "can we read the tags", because you can. Ask who turns the reads into events, and who your existing software talks to. If the answer to either is nobody, the project has a gap in it.
None of these are exotic. They are the ordinary shape of an RFID deployment.
One pass through a gate is not one read. Without something to group them, your system records hundreds of movements for a pallet that moved once.
In or out is the question the business actually asked. A single read cannot answer it. Antenna order and timing can, and somebody has to work that out.
Stock stored near a doorway, a forklift passing by, a neighbouring bay. Reads with no business meaning, arriving alongside the ones that matter.
Readers speak their own protocols. Your ERP or warehouse system speaks HTTP and expects a sensible shape. Something has to sit between them.
If the only copy of an event is in flight when the connection goes, it is gone. Buffering is unglamorous and it is what makes the data trustworthy.
When a count disagrees with the system, you need to be able to go back to the raw reads and show what actually happened. That means keeping them.
Most projects should stop at the second one.
Major reader manufacturers ship management and middleware tooling with their hardware, and it handles the common cases. It is already paid for and already supported.
Verdict: try this before anything else. A surprising number of deployments need nothing more.
If you are buying or replacing a warehouse management system anyway, several support RFID natively and the integration is somebody else's problem.
Verdict: the right answer if you are already in the market for a WMS. The wrong reason to buy one.
A layer that takes the raw reads, turns them into events with meaning, holds on to them, and offers them to your existing systems in a shape they can consume.
Verdict: right when you already have software that needs the data and no way to get it.
Where there is no existing system to feed, and the screens, the reporting and the workflow have to be built as well as the plumbing.
Verdict: a bigger piece of work, and worth being sure the third option does not cover it first.
We write middleware for a living and we would still start here. If your reader vendor's own tooling produces the events you need, use it. It costs you nothing extra and somebody else maintains it.
Where it stops is specific and worth knowing: when you are mixing hardware from more than one manufacturer, when the events you need are particular to your process, or when your existing software needs the data in a shape the vendor tool does not offer. That third one is the common case, and it is what middleware is for.
Turning reads into events. Grouping hundreds of reads into one movement, with a time and a direction, and discarding the ones that meant nothing. This is the whole job, and everything else is plumbing around it.
Holding on to data when the network does not. Buffer locally, deliver when the link returns, never lose an event because a switch rebooted.
Giving your systems a sensible way in. A documented API your existing software can call, so your team or your software vendor can use the data without learning anything about RFID.
Keeping the raw reads. So that when a number is questioned, and it will be, you can show what the hardware actually saw rather than argue about it.
A good example of the case where the client already had software and needed the data to reach it.
Eltherington had their own software vendor, who needed RFID data and had no sensible way to get at it. We integrated with the Kathrein readers and built middleware that caches the reads and serves them on three API endpoints, so their team could take the data they needed without dealing with the hardware at all.
The middleware interprets the reads before serving them, which is the part that matters: it gives both the read itself and the direction of travel of stillages and pallets through the gates. Millions of raw reads become events a business can actually use.
Live in two weeks, at a fixed price, with ongoing maintenance since.
We price the job, not the day, and you see the price before anything starts. As a rough shape, using our current rate of £15 a token:
Hardware is bought from your supplier, not from us, and we have no interest in which you choose.
No, and we would rather you did not. We are not a reseller and we take nothing from your hardware choice. Buy from whoever supports you best and we will work with it.
We have worked with Kathrein directly. Beyond that the question is what a reader can talk to rather than whose badge is on it, and most industrial readers offer a way in that middleware can use.
That is usually the whole point. The middleware presents an API your system or your software vendor can call, so nothing else has to understand RFID. It is how the Eltherington one works.
Events are held locally and delivered when the connection returns. An integration that only works while the network is perfect is not one you can run a warehouse on.
Sometimes barcodes are, and they are much cheaper. RFID earns its place when things must be read without being handled or seen, in bulk, or at a gate nobody stops at. If your process has somebody picking each item up anyway, say so and we will tell you honestly.
Describe the movement you want recorded and what software you already run. You get a straight answer on whether your hardware supplier already covers it, and a real price if they do not.
Get a price