Hi Tim,
I don't think the tag population has anything to do with the delay.
The tag is always recorded at its RFID reader time, which comes from the reader. Worst case, this is a UI update issue.
When CrossMgr processes a tag read, it does not update the display immediately.
Rather, it starts a timer for .1 seconds. If an additional read comes within .1 seconds, it resets the timer to .2 seconds.
This continues up to 1 second, when an update is forced.
The purpose of this logic is that large RFID bunch reads can occur faster than CrossMgr can keep up if it refreshes after every single ead.
CrossMgr would appear to "hang" after a large number of reads, and it could sometimes take 10 or more seconds for it to become response again.
Hence the need for the refresh delays. If multiple reads occur in quick succession, the update delays effectively "batch" them all together into one update.
This eliminates the "hang" at the expense of some delay in the update.
For 2 reads in quick succession, the delay should be max .2 seconds, and the max delay overall is capped at 1 second.
That doesn't sound like what you are seeing, or does it?
The other source of delay is when using CrossMgrImpinj and QuadReg.
Because QiadReg reads the tag multiple times and computes the time when it is closest, it wait for "silent" period after the last tag read before it assumes the tag is out of range of the antenna. Then it does the signal processing on all the reads it has.
This adds a further delay.
However, there is no logic around "updating after the second read". Everything is based on a timer.
Perhaps you could make a screen capture video and post it? That way, I would be able to see exactly what is happening.
Thanks.