When the Read Window Is Shorter Than the Conversation

A battery-free tag can have all the energy it needs and still fail to report. The read window closed before the conversation finished. That failure looks like a power problem. Teams debug it like a power problem. It is not one.

We wrote last year about where sensor data can live inside the protocol, and in September about what decides whether a moving asset gets read at all. This post is the layer between them.

The read window is time, and the conversation spends it

The window a passive tag gets is how long the asset stays inside the field. For something moving, that is the length of the field divided by its speed.

Inside that window the tag has to do four things: harvest enough energy, charge, measure, and talk. The first three get all the attention, because they are the ones that feel like physics. The fourth is the one that runs out.

Talking costs exchanges. Every exchange is a command from the reader, a reply from the tag, and the silence in between. A reading is not an instant; it is a short conversation with a fixed number of turns.

There is a second subtlety, and it makes the read window smaller than the arithmetic suggests. The window does not open when the tag enters the field. It opens when the tag has stored enough charge to answer, which happens somewhere inside the pass, and it closes when the tag leaves. The usable read window is always shorter than the physical one, and how much shorter depends on how hungry the tag is and how strong the field is at that point.

Two paths, and they do not cost the same number of turns

There are two standards-compliant places to put a sensor reading, and we have written about choosing between them before. Here is what they cost in time.

Sensor data inside the inventory reply. The reader runs an inventory, and the tag answers with its identifier and the measurement in the same message. One turn, and the reading is done. Inside that turn the air interface already trades a few short commands. Both paths pay for them, so we count them once.

Sensor data in user memory. The reader runs an inventory and gets an identifier. Then it issues a read command for the memory where the measurement lives, and waits for that reply. Two turns at least, sometimes more if the data spans more than one read.

On a bench, the difference is milliseconds and nobody cares. Inside a short read window, the difference is whether you get a reading at all.

When the read window is the thing that decides

The case is specific, and it is more common than it sounds: assets that pass in and out of the field rather than sitting in it. A carrier that keeps coming back on a loop. A part that travels past an antenna on its way somewhere else. Anything whose job is something other than passing a reader.

Here energy often is not the constraint. A tag that passes the same antenna every few seconds can accumulate charge across passes, because storage holds what the last pass delivered. Given enough passes, it will have the energy.

What does not accumulate is the conversation. Each pass is an independent attempt to complete the protocol, and a pass that ends halfway leaves nothing behind for the next one. Energy integrates. Time does not. That asymmetry is the whole story, and it is why a system can look perfectly powered and still report nothing.

Why we could not show it on a table

We built a demonstration of exactly this for IEEE IWSA 2026, the research workshop we co-hosted in San Sebastián last month. It was harder than it should have been.

The demonstration needs two things at once. The tag has to have enough energy to communicate, because if it does not, both paths fail and you prove nothing. And the window has to be short enough that the longer conversation does not finish while the shorter one does.

Both of those are governed by the same lever: how long the tag spends inside the field. Shorten it and you take away the time, but you take away the energy too, and you can end up breaking both paths. Lengthen it and the longer conversation finishes comfortably. The band where one path wins and the other loses is narrower than we expected, and it moves with transmit power and distance.

That is worth saying out loud, because it cuts both ways. If the effect matters in your application, you are not going to see it on a demonstration table. You are going to see it on your machine, at your speed, with your geometry. And a vendor demonstration that shows it cleanly has been tuned until it did.

How to work out your own read window

Three numbers, and none of them needs a laboratory.

1. How long the tag is inside the field on each pass. Field length along the direction of travel, divided by the speed at the worst moment, not the average one.
2. How many turns your reading needs. One if the measurement rides in the inventory reply, two or more if it lives in memory.
3. How many passes you get. This is the one people forget, and it decides whether energy is a constraint at all.

If the asset passes often and the window is short, the design question is not power. It is how much conversation you are asking for.

What to do when the window is too short

• Ask for fewer turns. Putting the measurement where the inventory already looks is the cheapest fix, and it is a decision taken at design time, not afterwards.
• Make the window longer. A longer field along the direction of travel, or a slower pass. Halving the speed doubles the time in the field.
• Accept misses and read more often. If the asset passes every few seconds, a reading every tenth pass may be plenty. Reliability per pass and reliability per hour are different specifications, and projects routinely buy the expensive one by accident.
• Move the read point. The best read point is often not where somebody first put the antenna, which is a subject of its own.
• Check what else is in the field. A read window is shared. If twenty tags answer the same inventory, each one waits its turn, and the window each of them gets is a fraction of the one you calculated. Population size belongs in this arithmetic as much as speed does.

Where none of this matters

Some assets stop in front of the reader, and some live in the field permanently. There the read window is not your constraint at all, and you should choose the path on completely different grounds. How much data you need. Whether any standard reader has to understand it. How you handle writes.

Most installations are in that comfortable category. The point of this post is to help you work out, early and cheaply, whether yours is one of them.

Where to start

If you have an application where things pass by rather than stop, the useful thing to do before buying anything is the arithmetic above. Field length, worst-case speed, turns required, passes available.

If that arithmetic says your window is tight, that is a good subject for a paid scoping study, and the answer usually changes a design decision rather than a purchase. If one turn is what you need, our SenseID evaluation kits carry the measurement in the inventory reply, so you can try it on your own bench. You can also read how we work across hardware, firmware, software and radio, or the physics of what a battery-free tag does with the energy it gets.

Next week: what it takes to pick up a development somebody else started, and why the state of the hardware is the least of it.