This guide will:
- Explain and define Auxiliary (A) Transactions as a concept
- Outline the usefulness of A-Transactions
- Walk you through the process of defining the parameters necessary to define a read as an A-Transaction
- Guide you through filtering A-Transactions using SimpleClient.
- Show how to verify that A-Transactions are being used (or being excluded) correctly.
When a tag enters the RFID field put out by a controller, the controller reads the tag over and over for five seconds 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. Any reads that fall below the defined threshold are labeled as Auxiliary Transactions.
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 BoxScore 3, the MiniTrack interface, and SimpleClient 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 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 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 SimpleClient unless both Normal and Auxiliary Tag Modes are selected.
Auxiliary Transactions can only be filtered using SimpleClient 0.6.0 or higher or in StreamManager when you select the Tag Mode for your stream.
To process ONLY A-Transactions:
- Open a controller file in SimpleClient.
- Under the Tag Mode section, check the Auxiliary box. Make sure the other Tag Mode boxes are unchecked.
- Apply any other changes necessary and play the data file 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.
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.