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
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 MiniTrack 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 MiniTrack
This process only works using MiniTrack firmware 5.3.8 or higher.
- Press Menu > 3 > 3 > 5 and use the arrow keys to select FLSHPT to set the antenna type to FlashPoint.
- Press Enter and then Yes to confirm the change.
- Now press Menu > 3 > 3 > 6 and use the arrow keys to select BIB as the tag type.
- Press Enter and then Yes to confirm the change. Return to the main screen.
- Press the CMD button on the keypad above the Enter key.
Warning: For MiniTracks running firmware version 5.3.8, the screen WILL NOT CHANGE when you press the CMD key. Simply press CMD and enter the complete code. When you press the last number in the code, the MiniTrack should beep to acknowledge the change.
- Enter 287267XXYYY where XX is the minimum accepted read strength (RSSI) and YYY is the total number of times the tag was read within the 5 second window. 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.
- Press Enter and then Yes to confirm the change. If the setting was successful, the controller will beep once.
The controller can now record tag reads as A-Transactions. Settings will be stored on the Reader even when the controller is powered off and will remain in place until changed.
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.
- 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.
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 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. 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.
For a MiniTrack, press CMD and enter 9999.