Links

Predictive tracking with reads from timing system

Use sporadic detections from the timekeeping system for a smooth and realistic live visualization of your race.
Algorithm processes sporadic reads from the timekeeping into smoothly moving dots

Dashboard for predictive tracking

Dashboard to monitor reads from the timing system in Racemap to compose a live visualization of the race
The dashboard provides information to prepare predictive live tracking before the event, and to monitor the forwarded reads during the event.
Status: Checklist for data and settings required to conduct predictive tracking. There is an auto check of the forwarding settings in RACE|RESULT.
Readers: When Racemap receives reads the locations of corresponding readers are shown. There is a hint for readers which can't be mapped as placed too far from the shadowtrack and its reads are not considered for prediction (dropped reads). Additionally, the shadowtrack is shown as an elevation profile with the corresponding readers' locations. A reader can be mapped to several locations of the shadowtrack, automatically as a reader in laps is mapped to every lap.
Transponders: Shows the last received read for each transponder. Additional information: recorded- and received timestamp, location of the last read, and total number of reads for each transponder.
Reads: Raw data Racemap receives from your timing system account.
The prediction algorithm considers the timestamp when a read is recorded. The timestamp when Racemap receives the detection is not used for the prediction. Possible reasons for a difference between the recorded timestamp and the received timestamp of the same read (as Racemap receives reads with future timestamps):
  • There is a delay in forwarding the reads from the timing system to Racemap. Minimize the delay to improve the quality of the prediction.
  • Settings that impact the timestamps such as date, start time, and time offsets of your event in the timing system do not fit the NOW time.

Algorithm for predictive tracking

For predictive tracking our system needs to know:
  • transponder ID of each participant you want to display
  • exact race course as .gpx or .kml ("shadowtrack")
  • locations of the timing hardware
    • readers with a GPS module eg. track boxes send their locations to Racemap
    • readers without own locations: define the location of the reader in Racemap
With AI-based features, you flexibly apply predictive tracking.
  • Auto-Mapping to shadowtrack within 30 m distance:
    • If reader is placed in laps the reader will be mapped on each lap automatically.
    • If reader is located > 30 m from the shadowtrack the prediction ignores its reads.
  • Moving reader: Variable locations of reader 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.
Different visualization of live and replay
The replay is calculated with each finish detection for separate participants. The recalculation considers reads sent with a delay or even after the event.
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