Speedway reader status light - orange

[Luca Fanicchi]

Hi.

Hoping someone can assist.

When I connect the Speedway reader (Impinj-R420) to the nework and system - both power and status lights are green. However, when I connect to the Read/Write program, the status light flashes green (two short flashes). Worse still when I connect to CrossMgrImpinj, the status light changes to flashing orange (single flash) and there is a long delay between the tag being presented to the antena and the tag being read by the program.

I have experienced some inconsistent tag read and tag losses during events and was wondering if this is the issue and how to resolve it.

Any suggestions?

Thanx

Luca

[Jonathan Rosen]

The slow flashing orange is OK, that means the reader is in inventory mode and waiting patiently for tags. The frequency of the orange LED will change as the reader sees more tags. The double blink green means LLRP active, which is fine. The only problems to look for are red lights for failures and missing green lights on antenna ports (failed antenna connection, typically due to a loose cable.) 

 I'm going to hope and assume that you are using the most recent version of TagReadWrite and CrossMgrImpinj,. Also, its worthwhile to update the Impinj reader firmware using the link posted in a different message, since it adds features and fixed bugs. 

Missing tags and tag losses are a separate problem. Make sure you have the shortest possible cable between the antenna and the reader. There are good tools online that will show how much signal loss is caused by long cables (3 meters or more) and thin cables should be avoided (LMR-100 is thin, LMR-400 is the lowest loss and thickest cable.) 

Check tag orientation, make sure your tags are facing the antenna and at the same height. 

For support purposes, you should report the following: 

1. cable length and thickness or type. 

2. antenna type, gain in db, height and position. 

3. chip type and location. 

4. CrossmgrImpinj version. 

5. Impinj reader software version. 

[Luca Fanicchi]

Hi Jonathan,

Many thanx for the reply - that sets my mind at rest. We are using the latest version of both TagReadWrite and CrossMgrImpin.  As to the firmware version of the reader - that I'll have to confirm. With regards the cables - we do go over the 3m, but are using the recommended thick cables for minimum loss.

I'll update the reader and runa  few tests again.

Thanx again

Luca

[Jonathan Rosen]

When using CrossMgrImpinj, its not unusual to see a delay of 3 seconds or more as it performs the analysis on the tag data. This is OK; since the tag data time is recorded with precision when it is seen by the antenna. 

--
You received this message because you are subscribed to the Google Groups "CrossMgrSoftware" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crossmgrsoftwa...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/crossmgrsoftware/639aa3f7-3387-4dd9-a5ea-082859805422%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Jonathan Rosen]

Here's the link to the Impinj reader documentation, it has a complete list of all of the LED status light codes in it. 

https://support.impinj.com/hc/article_attachments/360002484340/Impinj_SpeedwayR_installation_and_operations_guide.pdf

[Luca Fanicchi]

Hi Jonathan,

Thank you for the advice.  Had a race with no tag misses, but am experiencing a long delay between when the tag is read by the reader and when it is brought into/recognised by the timing system - sometimes up to a second or more.  So what I experience is that the rider is often way past the finish line before his number appears to be accepted by the timing system, even though the antenas are a good 5m before the finish line.

Is there a setting to reduce this lag?

Thanx

Luca

[Jonathan Rosen]

The delay in viewing the tag is OK, this is not a problem. 

The tag time is recorded by the receiver when the tag is read by the antenna, not when the tag is displayed in CrossMgr. If you watch very closely and compare times, it becomes apparent that the tag time precedes the current time by a few seconds, confirming that the tag is read by the receiver and then processed by CrossMgrImpinj.  Also, its unusual that the antenna is 5m before the finish line. When using CrossMgrImpinj and quadratic regression is enabled, the tag position will be within 20cm or less of the perpendicular line to the antenna. For a bike race, measure the distance from the front edge of the tire to the tag location (typically 1 meter) and position the antenna so that the front edge of the bike tire is on the finish line when the tag is read. 

Another method is to use CrossMgrVideo, since it will display the time of each picture. It will show where the tag was located when it was read. 

[Edward Sitarski]

Hi Luca,

Just to clarify that CrossMgr delay has nothing to do with the accuracy of the read times.  The times as based on the reader itself.  CrossMgr accepts times "in the past".  The delay is screen update only.

The delay may be due to processing.  Two ideas:

Are you using Quadratic Regression?  If so, CrossMgrImpinj waits for a "quiet period" of 0.5 seconds to delimit a sequence of reads to analyse.  

Changing this to "First Read" eliminates the delimit delay, but will also result in much less accuracy as only the first read time is used (not computed from multiple reads utilizing multiple strengths).

The chip is still being read after the rider crosses the finish line as the tag is still in range of the antennas.  The QR technique uses this to get a more accurate time for when the chip is closest to the antenna.  Of course, this means that the processing starts when the chip is out of range.

The second cause is the update delay built into CrossMgr.  When CrossMgr gets a read from CrossMgrImpnj, it does not update the display right away.

Rather, it waits an additional 0.1 seconds.  If it does not get another read during the 0.1 seconds, it does the update.

If it gets a read during the 0.1 seconds, it resets the update timer to 0.25.  Then 0.5, then 1.0 second (the max).

The reason for this (and the way CrossMgr used to work) is that if you update the display on every read, and you have a large number of reads (say of crit with a peleton of 80 riders), the screen flashes and the computer appears to lock up as it processes all the updates individually.

Adding the 0.1, 0.25, 0.5, 1.0 update policy allow CrossMgr to do the updates "in batch": allowing it to keep up with "bursts".

We can estimate the shortest latency for a CrossMgr update.  Let say, one rider passes the finish line alone.

With QR, the tag has to go out of range before the processing can start.  Let's say this happens when the rider is 3m after the finish.

Then another 0.5 seconds must pass for QR to detect the end of the sequence.  It does the regression analysis and sends the chip value and the computed time to CrossMgr.

CrossMgr receives it, then waits an additional 0.1 seconds to see if there are any more reads.

With only one rider, it will update the display after the 0.1 second.

So, the screen update happens about 0.6 seconds after the tag goes out of range.

I am open to ideas to improve this.

The simplest idea would be to shorten the QR "delimit' time from 0.5 seconds to, say, 0.1 seconds.  Given that the reader frequency is about 200 reads/second, that should be plenty, and a savings of 0.4 seconds.

It is also possible to add another interval for the CrossMgr update time, say, starting at 0.05 instead of 0.1.  A savings of 0.05 seconds in the single-rider case.

Total  savings: 0.45 seconds.

With these changes, you would see the screen update in 0.15 seconds instead of 0.6 seconds for the single rider case after the tag went out of range.

Of course, the tag is still reading after the rider passes the line, there will always be that latency.  And, there has to be latency for "burst" RFID reads otherwise CrossMgr will appear to hang.

Tightening the delays cannot solve the problem entirely.  Tightening the QR delimit delay could be worthwhile.

--

You received this message because you are subscribed to the Google Groups "CrossMgrSoftware" group.
To unsubscribe from this group and stop receiving emails from it, send an email to crossmgrsoftwa...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/crossmgrsoftware/dbdb2a1b-c399-4451-9141-9b5b248c8e4d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Edward Sitarski

[stuart lynne]

Another possibility is for CrossMgr to extend the duplicate read detection another second or three. And then have CrossMgrImpinj provide the first read notice with the first read tag and then update later with a better time when Quadratic fitting has finished. 

To view this discussion on the web visit https://groups.google.com/d/msgid/crossmgrsoftware/CAAuZUphajcFdL%2B3aPatyKFBUSGwJg8BLr6YhdNhcneFNtMSu6w%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

__________O___________
_______-\<,____________
_____(_)/_(_)___________
_________________________
Stuart_Lynne____<stuart...@gmail.com>____604-518-1749(m)__604-461-7532(h)

[rkantos]

As others have previously written, the latency is not an issue and does not affect accuracy at all. It is good to understand that the time that is registered in the results comes from the RFID reader itself and not anything else. You can see the times and tags from the RFID backup txt file. Those times always match the time the reader recorded. Therefore it is also crucial for cross-refencing that the NTP servers of the RFID reader are set correctly. This ensures that the times are easy to work with should problems with the data appear. 

It does not matter at which point the times arrive to either CrossMgrImpinj or CrossMgr itself.. There could be a small point arguing that updating the results faster would make the announcer's job easier. However I think CrossMgr is already so good ad predictions, that decreasing the latency further would probably not yield any improvement to that either.

I would like to see the attention around this issue directed to somewhere else, for example the one thing I would like to see, which is the use of high speed (industrial) cameras, which can actually increase the accuracy of CrossMgr to the levels of actual Finish Line camera systems and beyond! With fast enough cameras, active timing becomes obsolete. With realtime machine vision rider recognition, all transpoder / rfid tag timing becomes pretty much obsolete.

[Luca Fanicchi]

Thank you Jonathan, this sets my mind at rest. Cheers

Luca

[Luca Fanicchi]

Hi Edward,  many thanx, the additional info is great and makes a lot more sense. Regards

Luca

To unsubscribe from this group and stop receiving emails from it, send an email to crossmgr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/crossmgrsoftware/dbdb2a1b-c399-4451-9141-9b5b248c8e4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Edward Sitarski

[Luca Fanicchi]

Thank you Stuart.

To unsubscribe from this group and stop receiving emails from it, send an email to crossmgr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/crossmgrsoftware/dbdb2a1b-c399-4451-9141-9b5b248c8e4d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Edward Sitarski

--
You received this message because you are subscribed to the Google Groups "CrossMgrSoftware" group.

To unsubscribe from this group and stop receiving emails from it, send an email to crossmgr...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/crossmgrsoftware/CAAuZUphajcFdL%2B3aPatyKFBUSGwJg8BLr6YhdNhcneFNtMSu6w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

__________O___________
_______-\<,____________
_____(_)/_(_)___________
_________________________

Stuart_Lynne____<stuar...@gmail.com>____604-518-1749(m)__604-461-7532(h)

[Luca Fanicchi]

Thanx for the info - I'll start playing with the camera and video apps. Cheers L