> For the complete documentation index, see [llms.txt](https://docs.racemap.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.racemap.com/prediction/algorithm.md).

# Algorithm for predictive tracking

Processing of timing data for a smooth race visualization.

The prediction considers the timestamp when a read is recorded. The timestamp when RACEMAP receives the detection is not used for the forecast.

Check in the reads tab of the prediction dashboard: The smaller the difference between *READ AT* and *RECEIVED AT* timestamps, the better the data for live tracking.

* Positive difference: Delay in forwarding the reads from the timing system to RACEMAP. Minimize the delay for a good prediction.
* Negative differences - reads appearing to come from the future: This indicates an incorrect time / date setting at your hardware or in the timing system.

<figure><img src="https://1672210197-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-LSRNxaH2Ju9Flr7JhJD%2Fuploads%2F14C3UZElB93jxNcwrUZ6%2Fimage.png?alt=media&amp;token=75dd11db-c950-4d29-b7fe-f569ac74f8ec" alt=""><figcaption><p>Green - very good: Small difference, Red - not usable data: Huge difference</p></figcaption></figure>

For predictive live tracking RACEMAP 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 from 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](/glossary.md#rejected-read)). Reader distance is only one of several rejection causes. A read is also dropped for falling outside the event's time window. Otherwise each of its [mappings](/glossary.md#mapping) is judged on its own — rejected for leaving the speed corridor or for sitting too close to the previous accepted read — and the read is accepted as soon as one mapping passes. The Analyse tab lists every read with all its mappings and the reason for each rejection.
* **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](https://racemap.com/player/muenchen-marathon-staffel-marathon-racemap_2019-10-13#follow=5da571f0fb1cf413081cb0c4\&selected=5da571f0fb1cf48a431cb10f,5da571f0fb1cf413081cb0c4)

{% hint style="info" %}
Strategically place readers along the race course.

* 1st & 2nd read within the first 1 km, e.g. at the start and approx 0.5 km behind it. Racemap finds each participant's start from the 1st read and confirms it with the 2nd; imported start times are not used. In live mode the marker appears once the start is confirmed. The Status tab checks this placement.
* 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.
  {% endhint %}

#### **Parameters to adjust the prediction**

Predictive live tracking involves the below parameters. Set these parameters carefully, as they impact the quality of your prediction.

**Max distance from shadow track** in meters: Maximum distance between the shadowtrack and the reader in which detections can be considered for the prediction. Readers with a greater distance from the shadowtrack are not considered for prediction and are shown as "Out of range". If the distance is 40 m the width of the whole corridor is 80 m.

**Jumping dot threshold** in seconds: With a new read, there is a new speed calculated for a predicted virtual participant (represented by the location of the dot in the tracking map). The "Jumping dot threshold" is the maximum time difference between the latest read and the virtual participant. If this difference is greater, the dot jumps to the location of the latest read. If this difference is smaller, the dot will either move faster or slower to smoothly reduce the difference during the ongoing event.

**RSSI threshold** in dBm; With Track Boxes the reads have a Received Signal Strength Indicator (RSSI). The RSSI threshold is the minimal value to be considered for prediction. Reads with a smaller RSSI are not considered for prediction. Small values indicate a significant distance between the Track Box and the transponder. Allowing small RSSI values increases possible errors as the transponder could be detected by multiple Track Boxes over a long distance at nearly the same time.

**Future track scale value:** The relative distance in which the predicted virtual participant "meets" the real participant moving along with the measured average speed. The greater the track scale value the longer takes the correction.

**Look back distance** in meters: The look back distance makes prediction less susceptible to measurement errors. With a new read, there is a new speed calculated for a predicted virtual participant. The prediction might receive many reads from a short section of the track. These reads can have location errors and therefore cause malicious velocities. The look back distance is the length for calculating an average speed for the prediction.

**Look forward time** in seconds: The look forward time compensates for the delay in data transmission and processing throughout our systems.

**Speed corridor:** every [transition](/glossary.md) carries a minimum and a maximum speed for the leg that starts there. From those the prediction derives two curves over the course — the fastest and the slowest progression the configuration allows — and accepts a mapping only if the time since the previous accepted read falls between them.

Because the bounds are summed over the legs a stretch actually crosses, a swim → transition → bike stretch is judged against all three, not against whichever leg the read happened to land in. This is what makes the check meaningful for multi-sport events, where no single speed limit describes the course.

The corridor is re-anchored on every accepted read: each one opens a fresh funnel that a mapping of the next read has to land in. Both curves, and the ideal pace between them, are drawn in the Analyse tab so a rejected mapping can be seen leaving the funnel.

#### **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   | <p>Speed extrapolation until detection from next reader's location;</p><p>speed correction depending on difference between marker in visualization from detection of real participant;</p><p>As readers (especially track box) might miss detections, marker moves on over location of following reader.</p> | Average speed between detections |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.racemap.com/prediction/algorithm.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.