Read Completeness Is a Timing Budget

Ada re-derives this chapter’s own numbers step by step, at full precision

ADA · CALCULATION AUDIT

Read Completeness Is a Timing Budget

A dock-door portal must confirm when a tagged pallet crosses from staging into a truck, and its release test logs both raw observations and the accepted event: 47 raw reads from antenna A, 39 from antenna B, resolving to exactly 1 accepted crossing. The chapter times a forklift moving at 1.2 m/s through the 2 m read zone against a reader that completes one inventory cycle every 120 ms. This audit asks the question that timing budget invites: how many inventory chances does that pallet get before it leaves the field, and how far does that number fall if the forklift speeds up?

Companion to the chapter RFID Hardware Integration — every number here comes from that chapter.

Ada: The chapter’s timing budget decides whether a portal is usable, so let me re-run it and then push the one variable that matters most.

• Dwell time: a forklift at 1.2 m/s crossing a 2 m read zone keeps a pallet in the field for 2 / 1.2 = 1.667 s.
• Inventory chances: at one useful cycle every 120 ms, that is 1.667 / 0.12 = 13.9, about 13 chances to see each tag — enough for a sparse pallet.
• Now double the forklift speed to 2.4 m/s: dwell halves to 2 / 2.4 = 0.833 s, and chances fall to 0.833 / 0.12 = 6.9, about 6 to 7. One operational change quietly cut the read budget nearly in half.

The audit conclusion is that read completeness is not a hardware property but a timing budget, and item speed is its dominant lever — which is exactly why the release record must store the raw read count beside the accepted event (for example 47 and 39 raw observations resolving to 1 crossing), and why a speed change is a hardware-integration retest trigger, not a middleware tweak.

Every number above is taken from the chapter’s own material and re-derived step by step.