Predictive tracking with reads from race timing
Use sporadic detections from the timekeeping system for a smooth and realistic live visualization of the race. Real-time extrapolation of location and speed.
Processing sporadic passings from the timekeeping into smoothly moving dots
The dashboard supports users during all phases of predictive tracking and provides insights into data processing.
- Before the event: Checklist to quickly prepare and test predictive live tracking.
- During the race: Relevant information for monitoring and adjusting the prediction.
- After the race: With the purpose of analyzing the prediction all data for each athlete is prepared and linked in a map, in diagrams, and in a table.
Dashboard to monitor reads from the timing system in order to compose a live visualization of the race
Status: Checklist for settings required to conduct predictive tracking. The status tab also provides an auto-check of the forwarding settings in RACE RESULT.
Readers: When Racemap receives detections, the locations of corresponding readers are shown on a map. There is a hint for readers that are placed too far from the shadowtrack, and its reads are not considered for prediction (rejected reads). The track is also shown as an elevation profile with the corresponding readers' locations.
Transponders: Table showing various information of the last received read for each transponder: recorded- and received timestamp, location, reader id. Additionally, the start- and finish time is shown if imported to the participant data.
Reads: Continuously running list of all reads Racemap receives from your timing system.
Analysis: Select one participant and analyze all its aggregated information. Data is linked in a map, a table, and in diagrams.
The prediction considers the timestamp when a read is recorded. The timestamp when Racemap receives the detection is not used for the forecast. Possible reasons for a difference between the recorded timestamp and the received timestamp of the same read. (As Racemap receives reads with future timestamps):
- Delay in forwarding the reads from the timing system to Racemap. Minimize the delay to improve the quality of the prediction.
- Settings in the timing system that impact the timestamps such as date, start time, time zone, and time offsets of your event do not fit the NOW time.
For predictive live tracking our system needs to know:
- transponder id of each participant you want to display
- exact race course ("shadowtrack")
- locations of the timing hardware
- readers with a GPS module eg. track boxes send their locations to Racemap
- readers without own locations: set the location of the reader in Racemap
The prediction works differently than a timing system. The prediction does not know a reader's location ahead, and potentially upcoming reads are not taken into account. Each detection is processed stand-alone. This approach enables flexibility when applying predictive tracking for sports events.
- Auto-Mapping to a location of the shadowtrack within 50 m distance:
- A reader can be mapped to several locations of the same shadowtrack. If reader is placed in laps it is mapped on each lap automatically.
- If reader is placed too far (> 50 m) from the shadowtrack its reads are not considered for prediction (rejected reads).
- Moving reader: Variable locations of readers during the race, e.g. place track boxes on cars or boats. The prediction considers the current location of every detection for live and replay.
- Multiple contests detection: One reader can detect several contests (shadowtracks), simultaneously. Racemap assigns reads to the correct shadowtrack, corresponding to transponder id and contest.
- High performance: prediction calculates location & speed for > 50,000 participants simultaneously, e.g. München Marathon
predictive live tracking at München Marathon, decoder reads forwarded from RACE|RESULT
Strategically place readers along the race course.
- 1st & 2nd read approx 0.5 & 1 km behind the start.
- Place readers along the race course to detect each transponder every 20 min.
- Read 1 to 0.5 km before finish.
- Swimming events: place track boxes on buoys. eg. https://racemap.com/player/wa-open-water-swimming-series-race-8_2019-01-25/
- Transition area: t_in, t_out with decoders, track boxes too inaccurate.
Different visualization of live and replay
With every new input data, the prediction is recalculated automatically. Input data can be a detection, new speed filters for segments, adjustment of the shadowtrack, import of finish time.
| Live | Replay |
Appearance of markers | With 2nd read, eg. prediction receives detection from start without delay and markers will show from 1st reader behind | From start detection |
Movement of markers | Speed extrapolation until detection from next reader's location; speed correction depending on difference between marker in visualization from detection of real participant; As readers (especially track box) might miss detections, marker moves on over location of following reader. | Average speed between detections |
Speed filters to check the plausibility of reads: You can set splits with expected speed values eg. swimming, transition, and cycling for triathlon.
- filter_max: ignore reads with two times faster speed than expected speed
- filter_min: ignore reads with 0.1 x speed than expected speed
Last modified 1mo ago