Introduction
This guide will:
- Explain and define Auxiliary (A) Transactions as a concept
- Outline the usefulness of A-Transactions
- Show you how to set the parameters that define an A-Transaction on your Controller
- Show you how to select A-Transactions using Fusion and SimpleClient
- Show how to verify that A-Transactions are being used (or being excluded) correctly
A-Transactions Defined
When a tag enters the "Read Zone" of a controller (e.g. the area in which the signal can read tags), the controller reads the tag over and over for five seconds, identifies the strongest read within that time frame, and records that time as a tag read. The signal strength and number of times the tag was read can be seen in the raw data file as shown below.
- The 3rd entry from the end is the signal strength. The lower the number, the stronger the signal. In general, a signal of -50 to -62 or less is considered a good signal, but that number may vary slightly depending on environmental and situational variables.
- The last entry indicates how many times the tag was ‘observed’ within the five second window.
Using this information, you can configure a Pro2 Controller to identify especially weak reads as A-Transactions.
A-Transactions in Practice
Simply put, setting a controller to record A-Transactions is useful for separating weak reads from strong reads. This can help compensate for situations where FlashPoints pick up unwanted, stray reads such as from non-participating athletes who picked up their bibs but are standing on the sidelines behind a flashpoint.
Reads designated as A-Transactions are NOT deleted or placed in a separate data session.
Below is an illustration of a possible scenario with some likely signal strength and observation data based on two athletes' positions relative to the FlashPoints.
Scenario: Bob Bystander showed up to the race late, picked up his shirt and bib, but decided not to run the race. He wanted to watch as people began coming in, so he sauntered over to the Finish line, and his bib got read. Elliot was the first place finisher, but since Bob came over and was read first, Bob is now displayed as the first place finisher! Now the live results are showing incorrect data, and the timer has to figure out what happened when Elliot comes forward to complain.
Using A-Transactions can help you avoid this type of situation by keeping Bob out of the data entirely so that Elliot can get his award without any hassle or confusion.
Configuring a Pro 2 Controller
This process only works on a Pro 2 Controller running ChronOS version 1.0.0.100 or higher.
- From any screen in ChronOS, tap the Settings cog on the left side of the screen, then select Reader.
- On the Reader screen, make sure you're on the "Internal" page of the Readers screen, then tap the A-Transaction toggle for the reader on which you'd like to configure A-Transactions. A-Transactions must be enabled and configured for each reader separately.
Be careful not to turn the reader power off on this screen!
- In the window that appears, tap the On/Off toggle next to the AUX field to turn A-Transactions on, then use the down and up arrows to adjust the read occurrence threshold (left side) and the RSSI signal strength (right) to the desired values.
There are no specific settings that work for every situation. ALWAYS test on location when possible and find a settings threshold that works for you. The Signal Strength setting is typically the most reliable method for identifying A-Transactions.
We currently recommend no more than -65 as the minimum allowed signal strength as a good starting point.
Tap Update when you're done adjusting the values.
- A confirmation message will appear reminding you of how A type reads are handled in the data file. Tap Update to confirm your changes or Cancel to go back.
- On the Reader screen, you'll notice that the values you set are noted below the reader on which you defined them. You should also see the AUX icon in the blue bar at the top of the screen.
The controller can now record tag reads as A-Transactions. Settings will NOT be stored on the Reader when the controller is powered off, so make sure to set the A-Transaction parameters after each boot up when you need to use them.
Processing A-Transactions with Fusion or SimpleClient
When a controller is configured to record reads as A-Transactions, the reads are still contained within the same file, but not all reads will be processed through Fusion or SimpleClient unless both Normal and Auxiliary Tag Modes are selected. Since A-Transactions are your weakest reads, you may never want to use them. If you DO need to use A-Transactions, follow this process:
Auxiliary Transactions can only be filtered using Fusion or SimpleClient 0.6.0 or higher.
- Access the controller data via your preferred method in Fusion or SimpleClient.
- Under the Filter > Type field in Fusion OR the Tag Mode section in SimpleClient, check the Auxiliary value. Make sure the other boxes are unchecked.
Fusion:
SimpleClient:
- Apply any other changes necessary and play the data as usual.
Processing tags in this way will include ONLY A-Transaction reads. Conversely, ONLY Normal tag reads will be processed if ‘Normal’ is checked, but the Auxiliary box remains unchecked. You can process Normal and A reads together by checking both the Normal and Auxiliary boxes at the same time. Ideally, Normal tag reads will go to a Priority 1 Timing Device in CTLive, and Auxiliary reads will go to a Priority 2 device as shown below.
A-Transactions in CT Live
As noted above, when streaming A-Transactions to CTLive, it is best to stream them to their own Priority 2+ Timing Device. This enables you to ensure that reads that fall within the accepted signal range are being used when available. It would also make sense to wait until you've verified the top finishers before you stream the Auxiliary reads.
You can use the Timing Point Inspector (TPI) Report to view any athletes that had times from the Auxiliary timing device. The ability to isolate these athletes in this way will enable you to much more quickly identify bystanders who got read who may mess up scoring data.
To do this, add the Standard/TimingPointInspector report to your event, and check the Priority 2 Timing Device for the point you streamed the data to.
Below is an example of a Timing Point Inspector report with times.
In an ideal scenario, the AUXFIN timing device field above would be empty, indicating that all the Athletes got their times from the Priority 1 device, but we can see that one Athlete did not have any reads above the A-Trans signal strength threshold, so his valid read came from the Priority 2 device.
Using this report, it’s easy to see if an athlete's time is suspect. This particular athlete’s time looks acceptable and normal relative to the others. It’s important to remember that a variety of environmental and situational factors may cause an athlete’s tag reads to be weak including sweat, clothing, poorly-located bib, and others, so not all A-Transactions may be suspect.
Disabling A-Transactions
To turn off A-Transactions on a Pro2, just go to Settings > Reader, tap the On/Off toggle, then tap the On/Off toggle in the pop-up window, then tap Update. A-Transaction settings also clear when you reboot the controller.