Motor logging · Part I and Part II
How a 64-record queue succeeds, then loses data
The board keeps producing records even when its browser reader is late. Compare normal batch reads, a temporary reader pause, and the new capture-first design. Playback time is slowed or accelerated for clarity; the rates and capacities shown are the experiment's values.
Board sampler250 records/sOne new record every 4 ms
→
Live queue · 64 slots0 / 64Unread records waiting for the browser
→
Browser reader24 per requestTries once every 80 ms while live
Simulation time0.000 s
Produced on board0
Read by browser0
Records discarded0
Normal reading
Every 80 ms, the browser can remove up to 24 records; the board creates about 20 in that time.
Stored, unreadIndexed read completedQueue full
Storage over simulated time
64 slots ÷ 250 records/s = 0.256 s of room if no records are read and the queue starts empty. If it is partly full, the remaining time is shorter.
Illustration only: the 680 ms scenario is a chosen period without reads. The real export showed a maximum 0.68 s gap between saved records; it did not measure the browser's actual pause duration. The frozen mode represents an 8 s transition with 128 retained records and 64 ms regular sampling, then indexed readback. No board or serial port is accessed.