CrossMgr Impinj "splitter": One reader for timing and racedb

[mbuckaway]

Is your feature request related to a problem? Please describe. Alot of the Impinj readers are four port readers, and generally, only one or two ports are actually used for race timing antennas. The remaining ports are unused. It would be useful to be able, somehow, to assign ports in CrossMgrImpinj to use for race timing (crossmgr) and race registration (racedb).

Describe the solution you'd like The typically situation for a small race is to have two ports for timing and two ports for registration. This, of course, assumes reg is close enough to the start/finish that this would work. For small races, it is easy enough to make that happen. In this way, only one reader would be required. CrossMgrImpinj would then a client and a server. It would connect to CrossMgr for timing and allow RaceDB to connect to it for reg. Some mapping might be required to fake an X port reader that Racedb can talk to. Alternatively, CrossMgrImpinj could just forward whatever chips appear on the port to RaceDB and only records the chip when the user presses the "read" button.

Describe alternatives you've considered Spend more money on a second reader (which are expensive to buy new).

[Belcarra]

I would have to review the LLRP specifications, but if I remember correctly, there can only be one active ROSPEC.

For timing the ROSPEC does continuous polling via the active antenna(s).

To achieve your goal, the process would be:

• stop the timing ROSPEC
• initiate the read or write to a specific antenna
• restart the timing ROSPEC

For the several seconds that the timing ROSPEC was not active, there would be no reads if a race participant went past the finish line.

In terms of implementation, it would probably require that CrossMgrImpinj take over the RaceDB read/write's. RaceDB would need to make the request via CrossMgrImpinj.

[mbuckaway]

@Belcarra That is too much work. For example, if antenna 1 and 2 were for race timing, and 3 was for reg, one would config 1, 2, and 3 antennas to detect chips. CrossMgrImpinj would direct any chips detected on Ant 1 and 2 to CrossMgr, and "direct" chips on Ant 3 to RaceDB. In reality, reads on Ant 3 would probably be caches, and when RaceDB requests a chip, would just send it along. The thought is any chip placed on the reg antenna would read 100 times before the user clicks the read button.

Of course, now that I think of it, chip writes would not be possible in this situation. Chips would have to be pre-encoded with whatever number set is required or just use whatever number is encoded in them. It would, however, ensure the correct chip is assigned to the correct rider and the chip is functional. Chip writes really aren't necessary during reg.

[Belcarra]

Effectively at that point you have your registration antenna taking up 25% of the impinj reader duty cycle and it becomes a problem to write tags.

I don't even like using one reader for two or more antennas at the finish line. One reader for each antenna. 100% duty cycle for each antenna.

On Fri, Mar 6, 2020 at 6:21 AM Mark Buckaway notifications@github.com wrote:

@Belcarra https://github.com/Belcarra That is too much work. For example, if antenna 1 and 2 were for race timing, and 3 was for reg, one would config 1, 2, and 3 antennas to detect chips. CrossMgrImpinj would direct any chips detected on Ant 1 and 2 to CrossMgr, and "direct" chips on Ant 3 to RaceDB. In reality, reads on Ant 3 would probably be caches, and when RaceDB requests a chip, would just send it along. The thought is any chip placed on the reg antenna would read 100 times before the user clicks the read button.

Of course, now that I think of it, chip writes would not be possible in this situation. Chips would have to be pre-encoded with whatever number set is required or just use whatever number is encoded in them. It would, however, ensure the correct chip is assigned to the correct rider and the chip is functional. Chip writes really aren't necessary during reg.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/esitarski/CrossMgr/issues/58?email_source=notifications&email_token=AALJH5DRFEWB3C64V2ZC7DTRGEBFNA5CNFSM4LCKDD5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEOBQHQI#issuecomment-595788737, or unsubscribe https://github.com/notifications/unsubscribe-auth/AALJH5DN3YJRWASPCFAV6BTRGEBFNANCNFSM4LCKDD5A .

-- Belcarra Embedded USB Software Stuart_Lynne sl@belcarra.com 604-461-7532 Alternates: 604-283-7475 and 604-518-1749(cell) http://usblan.belcarra.com http://www.belcarra.com

[esitarski]

This is a common request. Sadly, RFID readers are simple devices and this is not possible . There is a fundamental limitation of LLRP (low level reader protocol). Details:

LLRP (specifically the ROSPEC) supports only one "mode" for the reader at a time. There is a lot more to it, but basically, the reader can do one of the following at a time:

1. Continuous read: report timestamped tags as soon as they are detected by the specified antenna(s).
2. Inventory read: read tags within range of the specified antenna(s) and stop.
3. Inventory write: write to the specified antenna(s) and stop.

For each mode, you can specify which antenna(s) to use. To read a tag at the registration table, you have to disable mode (1) and enable mode (2), changing antennas in the process. Riders crossing the finish would be missed. Not good.

Managing one reader to do multiple-antenna read/writes in the current RaceDB is also harder than it would seem to be. Behind the scenes, a single-threaded "socket-server" processes all the read/write requests. Each request is queued. For each request, the RFID reader is reconfigured to access the specified antenna and perform the action, then the result is returned to the client socket.

RaceDB considers it an error if it reads more than one antenna in range, and this would be lost if the reader was always in mode 1.

I also researched this issue with non-LLRP readers and did not find any with this capability. It is unlikely that these readers will ever do this as they all seem to have the same chipset. There are other problems too, for example, most non-LLRP readers timestamp to seconds of accuracy - not milliseconds. These reflects their designed for security/parking.