Skip to content

Configure Races, Runs, and Tracks

Key Concepts

Before configuring races and tracks, it is important to understand several core concepts used throughout the platform:

Race vs. Run

  • Race: A Race is a competition distance or discipline within an Event (e.g., Marathon, Half-Marathon, 10K). Every Race always has at least one Run. In the most common case, there is only one Run per Race, and the user interface is simplified so that all configuration appears directly under the Race. However, there are scenarios where multiple Runs are needed for a single Race. For example, there may be a morning and an evening run, or qualification heats and a final, possibly on the same or different tracks. Each Run has its own results. If a Race contains multiple Runs, combined results across Runs may also be supported in the future (feature not yet implemented).

  • Run: A Run is a specific instance or configuration of a Race, used to define how a particular group of participants will complete the Race (e.g., different start times, waves, or heats). Each Run has its own track, its own start rules, time limits, and configuration that determines how results will be calculated.

Track

  • Track: Each Run has its own Track, representing the specific physical course that participants follow. A Track is made up of a sequence of trackpoints, each of which is a specific instance of a checkpoint, ordered and placed at a defined distance from the start or previous trackpoint. The Track defines the structure required for result calculation, including the order and distance of timing locations, and is used for mapping, timing, and result calculation. While multiple Tracks can share the same checkpoints, each Track has its own unique sequence and context for those checkpoints (for example, a checkpoint may appear at different distances or multiple times in different Tracks). The Track configuration is essential for accurate timing and results for each Run.

Checkpoint (CP) vs. Trackpoint (TP)

  • Checkpoint (CP): A Checkpoint is a physical timing location — such as a start, finish, or intermediate timing point — defined globally at the Event level. It is not inherently part of any specific Track and can have geographic coordinates, though these are not always provided. Multiple Tracks can pass through the same Checkpoint, and a single Track can use the same Checkpoint multiple times, each time with its own context (such as distance from the start), which is determined by the Trackpoint. The Checkpoint itself is simply a timing location, independent of any track context.

  • Trackpoint (TP): A Trackpoint is an instance of a Checkpoint (or a simple route point) within a specific Track. When a Checkpoint is used in a Track, it becomes a Trackpoint with additional context — such as its order and distance from the start or previous Trackpoint. This means that the same Checkpoint can appear as multiple Trackpoints in a single Track (for example, a lap course where CP1 is passed several times), each time at a different distance. Trackpoints define the route's geometry and timing structure for that Track, while Checkpoints remain global and context-free.

Moving Limits

Moving limits are an optional feature that can be configured to help detect and filter out timing reads that indicate improbable or invalid movement—such as excessive speed, unrealistic pace, or unrealistically short times. These issues most often occur when a participant does not complete the course correctly (for example, by taking unauthorized shortcuts or reversing over timing points).

  • Moving limit options:
    • None: No limit is applied; moving-limit checks are disabled for the segment.
    • Max Speed: Sets the maximum allowed speed (in km/h) for the segment. Requires distances between trackpoints to be entered.
    • Max Pace: Sets the maximum allowed pace (time per km, e.g., mm:ss/km) for the segment. Also requires segment distances.
    • Min Time: Sets the minimum time allowed for the segment (e.g., mm:ss). While distances are not strictly required, providing them is recommended so the system can compute and display derived speed/pace in the results.

Note: To apply moving limits, you must specify the segment distances.

Limits can be applied globally to a Track or to individual splits (the segment between two trackpoints). If both a global track limit and a split-specific limit exist, the split-specific limit overrides the global limit for that segment.

Reads that violate a configured limit are ignored by the system and excluded from result calculations; they are not included in final results.

Example: In an MTB event where leaders average around 30 km/h, you might set a global track Max Speed of 40 km/h. For a long downhill split leading to TP3, you could set a higher per-split Max Speed (e.g., 70 km/h) so participants are not excluded by the global limit.

In most cases, a single global track limit is sufficient. Per-split limits are only needed for exceptional segments that require different tolerances.

Use moving limits carefully. They are a useful safeguard but must be tuned to the course and expected participant behavior to avoid filtering out legitimate results.

Pay special attention to situations where the same checkpoint is visited multiple times (for example, when the course includes a loop where both entry and exit are through the same checkpoint, or when the course goes from A to B and back to A along the same path). If a participant's first crossing of a checkpoint is not read but a later crossing is, that later read may be treated as the participant's first crossing for that checkpoint. This can cause missing or shifted split information and have downstream effects on results and rankings. Tune limits conservatively for segments with repeated visits.

In pure lap races, moving limits are usually not the root cause of issues. If a read is missed, the remaining distance for that competitor is typically unchanged, and the main problem is a missed lap count rather than a limit-based exclusion. Tune limits with this distinction in mind.

Run Configuration

Configuring a Run involves two main areas:

1. General Run Settings

  • Run name (for multi-run mode only):

  • Run type:

    • Fixed length: The distance to be completed is a set, fixed length; enter the total distance (in kilometers) in the Length field. This is the most common scenario.
    • Fixed time: The run lasts for a fixed amount of time; enter the duration (in minutes) in the Duration field. The winner is determined by who completes the most laps within the time limit; if lap counts are equal, the winner is the one who completed those laps first.

  • Result mode:

    • Any trackpoint reached: Final result and position are assigned as soon as a participant reaches any trackpoint. In the ranking, participants who reached the finish are listed first, followed by others ordered by the last trackpoint they reached and the corresponding time. This mode is commonly used in mass-participation events where there is no official overall ranking; participants who completed only part of the course may still be assigned a position.
    • Last trackpoint reached: Final result and position are awarded only if the participant reached the finish trackpoint. This mode is typically chosen when positions or overall points are calculated from official results — it ensures that participants who only partially completed the course are excluded from the final standings.

  • Automatic assignment of participants to this run.

  • Apply time limit: Enable a time cutoff for the run; participants who do not finish within the specified limit are marked as DNF (Did Not Finish).

    • Time from start: A duration measured in minutes from the run start (for example, 120:00 meaning two hours from the start).
    • End time: An absolute clock cutoff (for example, 19:00:00), after which participants are considered DNF.

  • Count the finish at the next crossing after the leader finishes: This option is intended for lap-based formats where a participant finishes at their next crossing of the finish line after the leader has completed the race. It prevents late or duplicate chip reads from being counted as additional laps.

  • Accept times only in a specific range: Optionally restrict which timing reads are considered for results by specifying a clock-time window.

    • From: Ignore any incoming times earlier than this clock time. If left empty, there is no lower bound.
    • To: Ignore any incoming times later than this clock time. If left empty, there is no upper bound.

2. Track Configuration

Tracks, as described above, consist of checkpoints arranged in a specific order. The first trackpoint is always the start, followed by other checkpoints in the required sequence. These checkpoints can also be placed inside loops if needed.

Configuring the Start Trackpoint

The first trackpoint in every track is always the start. There are three possible start types:

  • Standard: The participant's start time is taken from the Start rules. This is the classic mass start or wave start scenario, where all participants in a group start together at a scheduled time.

  • With chip start: Like Standard, the participant's start time is initially taken from the Start rules, but there is also a checkpoint placed at the start line to record when each participant actually crosses the line. This is especially useful in large events with thousands of participants, where it may take several minutes for everyone to cross the start line. Chip start ensures that each participant's time reflects when they physically started the course.

    • Additional configuration is required for chip start:
      • Chipstart checkpoint: The checkpoint used to record chip start times.
      • Allow before gun start: The time window before the official gun start during which a chip read will be accepted and treated as if the participant started exactly at the gun start. This prevents situations where participants standing on the start line are not credited with a chip start because their last read was just before the gun start.
      • Allow after gun start: The time window after the gun start during which the checkpoint is interpreted as a valid chip start. In practice, this is usually the same checkpoint that also collects finish times. This window should be long enough for all participants (including those who are slightly late) to cross the chip start, but must be shorter than the time it takes for the leader to return to this checkpoint as part of the course.

  • From checkpoint: Start times are taken from a specially defined checkpoint, rather than from the Start rules. In practice, starts are rarely triggered automatically by timing equipment, as accidental or stray chip reads could cause unintended starts. Instead, start times are usually either pre-defined and imported into the checkpoint data, or entered manually by an official using the Racetribe Timing app's manual timing adjustment feature (currently in development). This is most often used for individual starts, where the official records the participant's number and the exact moment they start—typically in fixed intervals, such as every 30 seconds.

    There are also two additional configurable fields: Opened from and Opened to. These define the time window during which chip reads at the start checkpoint will be accepted as valid starts. These fields are mainly intended for the rare cases when timing equipment is used to collect start times from the checkpoint. It is important to specify the correct time window and ensure that only the intended participants are present in the timing zone during this period, to avoid recording unintended starts.

Select the appropriate start type when configuring the start trackpoint to match the event's requirements.

Configuring the Rest of the Track Structure

After the start, define the rest of the track using the drag-and-drop interface:

  • On the right side of the screen, you will see a list of available checkpoints and track structure elements (such as loops).
  • Drag checkpoints from the right panel into the track structure area on the left to build your track in the desired order.
  • If you need a checkpoint that does not yet exist, create a new one by assigning it a name. Newly created checkpoints will appear in the right panel and can then be added to the track.
  • You can add the same checkpoint to the track structure multiple times if the course requires passing through it more than once (for example, in lap races or courses with repeated sections).
  • In addition to checkpoints, you can also drag a Loop element into the track structure. A loop is a special track structure element that allows you to specify how many times the enclosed sequence of checkpoints should be repeated. You can drag and drop checkpoints (or even other loops) inside a loop, just as you would in the main track structure.

This flexible drag-and-drop approach allows you to visually construct even complex track layouts, including repeated sections and nested loops, by arranging checkpoints and loops as needed.

Note: Every loop (including Infinite loop) must contain at least one checkpoint inside it.

Fixed-Time Runs and Infinite Loop

For fixed-time runs, you configure the track in exactly the same way as for a regular (fixed-length) run, except that you cannot know in advance how many laps the winner will complete. To support this scenario, there is a special track structure element called Infinite loop. This element must be placed as the last element in the track structure.

The Infinite loop works as follows: whenever a participant completes a lap that has not yet been accounted for in the calculations, the system automatically adds that lap to the structure. This process continues until the time allocated for the run has expired. The Infinite loop ensures that lap-based results are calculated correctly for all participants, regardless of how many laps are completed within the time limit.

Track Configuration: Final Thoughts

Although track configuration may seem complicated at first, once you understand how each part works, creating a new track becomes quite straightforward. All you need to do is drag and drop the correct elements into the right order, and the system will know how to calculate results for the given run.

If you also enter the segment distances, the system will be able to display pace or speed in the results.

For larger events, where it is impossible to manually check every result, it is recommended to define moving limits. This will help filter out unnatural or improbable timing reads and improve the reliability of your results.