A field-note style breakdown of the problem that will eat more engineering time than almost anything else in industrial IoT deployments.
If you've ever deployed RFID anywhere near production machinery, you've probably run into this: a single tag gets read two times in less than a second, or even "read" while it is nowhere in the range. Teams that are new to an industrial context often assume it is a hardware failure. In the vast majority of cases, that is anything but simple, and understanding why is very important if you are building something that makes the assumption that those reads are true and fact.
The issue is not the reader, but the environment
One of the primary causes of this issue is the environment, specifically metal. Stamping presses, assembly lines, and metallic racks cause radio frequency signals to bounce. This reflection means a single tag can be read several times, as a transmission reaches the antenna at slightly different intervals. So, the reader assumes it is reading the same tag a dozen or so times rather than one; add the dozen or so tags which are being read every day on the factory floor and you will start developing some serious problems in count-based logic, without even realizing it.
Another, less obvious issue is antenna overlapping; when a facility is using more than one reader, they overlap at the edges. A tag in the overlap would be read at the same time by two or more readers, looking exactly like two separate reads unless the user is already storing or logging which specific tag, antenna or reader ID it was.
What makes it mess up more than you can imagine
The common response is that this issue can be considered a minor data-corruption nuisance. This statement is only true until that data finds its way to anything that uses a count-based logic, such as a WIP or workforce/zone occupancy tracker, which will both become miscalculated as each additional read will appear as additional activity. Traceability systems, if they use each read as a separate genealogy event, will eventually generate an extremely cluttered log, full of non-original entries under a great many valid reads.
This is where a significant percentage of early-phase industrial IoT projects go undetected. The hardware is perfectly fine, the network is good, and all connections are active. But because a deduplication layer wasn't built into the system, the application that used the read data was not designed for that specific problem.
What it actually resolves
Dedup at the edge, not in the cloud – The most effective solution for dedup would be to eliminate the reads when the signal is nearest the tag antenna. Either set it in the reader's hardware (there usually is a "read window setting" where it simply doesn't read the same tag a second time for a specified amount of time) or use lightweight edge processes. This will dramatically remove the additional data overhead and eliminate the need for the upstream system to try to deal with something it wasn’t built for.
Consider tagid+timestamp bucket instead of just tagid – If a tag is genuinely reappearing after five or ten minutes, it is a legitimate re-entry and not a duplicated reading. A time bucket in the range of 2-3 seconds ensures valid reads are not caught for this.
Log reader/antenna ID when recording the read - The simplest method to correct overlapping zones is to log the reader or antenna ID for each read. If two readings for the same tag arrive within microseconds and there are two antennas on either side, both reading the same tag, you know it is a read zone overflow. This should eliminate the problem using whichever method you prefer: proximity to the antenna, strength of the read signal, or business-relevant factors.
Check a state machine rather than just a simple count - Instead of using a simple count for WIP/workforce systems, make it state-aware. Any read triggering a change that should not be allowed (i.e., an entry into a zone the employee is already signed into) indicates an overflowed read which needs to be filtered out.
The take-away message
There is nothing exotic here, and it mostly comes down to disciplined data hygiene at the right layer of your stack. The problem is that none of this is obvious until it is too late to easily fix, which in this case typically means a critical system that is not producing accurate results. If you are just starting out with a new project involving RFID on a factory floor, you must account for this issue before your data pipeline takes centre stage.
If you need further information on RFID, BLE and UWB data structuring for industrial tracking or workforce applications, check out the general overview at Compentra AI
Top comments (0)