This guide will:
- Explain and define Auxiliary (A) Transactions as a concept
- Outline the usefulness of A-Transactions
- Walk you through the process of setting the parameters necessary to define a read as an A-Transaction
- Guide you through filtering A-Transactions using SimpleClient and Fusion.
- Show how to verify that A-Transactions are being used (or being excluded) correctly.
When a tag enters the Read Zone put out by a controller, the controller reads the tag over and over for five second and records the time it saw the tag based on the strongest read within that five second window. 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 depending on factors such as weather and the width of the timing line. Testing is always encouraged when variables are present.
The last entry indicates how many times the tag was ‘observed’ within the five second window.
Using one or both of these fields, you can enter a command on a Pro Series Controller or MiniTrack Controller that tells the Reader which reads should be noted as A-Transactions.
A-Transactions in Practice
Simply put, A-Transactions are 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 still picked up their bibs and are standing on the sidelines behind a flashpoint.
Reads designated as A-Transactions are NOT deleted and are fully recoverable, should you need to use the reads.
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.
Before a controller can determine whether or not a tag read is an A-Transaction, you must define the parameters for an A-Transaction.
Scenario: Bob 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 you’ve printed out an Awards Report with the wrong data, and you have to figure out what happened when Elliot comes forward to complain.
Using the A-Transaction filtering options available through ChronOS, BoxScore 3, and the MiniTrack interface, combined with SimpleClient and Fusion can help you avoid this situation entirely by easily setting parameters that will keep Bob out of the data so 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 126.96.36.199 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 screen 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. The values depicted in the image below are an example of a good A-Transaction threshold, though with testing and experience, you my find values that work better for you.
Tap Update when you're one 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.
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-Transactions parameters after each boot up when you need to use it.
Processing A-Transactions with SimpleClient or Fusion
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.
Auxiliary Transactions can only be filtered using Fusion or SimpleClient 0.6.0 or higher.
To process ONLY A-Transactions:
- Access the controller data via your preferred method in SimpleClient or Fusion.
- Under the Type field in Fusion OR the Tag Mode section in SimpleClient, check the Auxiliary value. Make sure the other boxes are unchecked.
- 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. 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 to the right.
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 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 from the Priority 1 device, but did from the Priority 2 device.
Since this athlete with a weak read is isolated, it’s easy to see if his time is suspect. This particular athlete’s time look 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. Not all A-Transactions may be suspect.
For more information about A-Transactions, see the “Auxiliary Transactions – Getting Started” Forum Post on the Timer Portal under Forum > ChronoTrack Hardware.
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.