Checkpoint Dashboard
The Checkpoint Dashboard in RUFUS Race Manager (RRM) provides full visibility and operational control over the passings captured at a specific checkpoint. From this view, organizers can monitor all passings flowing through the checkpoint, manage how the system processes them, and control race timing behavior as the event unfolds.
Each checkpoint displays a set of core elements:
Race Control widgets showing elapsed time, lap progress, or finish status depending on the checkpoint’s role.
Process Passings switch, allowing the checkpoint to actively process or temporarily ignore new detections.
Passings Grid, listing all passings recorded at the checkpoint across all races assigned to it.
This consolidated interface allows race officials to supervise checkpoint activity in real time and adjust operational status when necessary.
Passings Grid
The Passings Grid shows every passing detected at the checkpoint, regardless of the participant’s race, category, or status. This makes it possible to:
Audit all detections arriving from the hardware
Confirm that passings are being assigned correctly
Detect duplicates, invalid reads, or unexpected chip activity
Validate times, laps, or segment boundaries directly at the checkpoint level
What the Grid Displays
Columns typically include:
BIB
Name
Race
Lap (when applicable)
Race Time
Time of Day
Status (VALID, INVALIDATED, CHECKPOINT_CLOSED, etc.)
Type (LOCAL, CLOUD, MANUAL)
Row Actions
Each passing supports contextual operations such as:
Delete passing
Reprocess passing
Set passing as Invalidated by user
These actions provide precise control over how passings affect the participant’s record and final classification.
Adding Manual Passings
You can add passings directly from the Checkpoint View by entering the participant’s BIB number.
The timestamp recorded will be the exact moment the passing is entered.
The passing is then processed by the system using the full validation logic, ensuring it receives the appropriate status.
This feature is particularly useful when a participant is observed crossing but their chip was not detected.
For broader corrections, consider using Floating Passings, which are not tied to a specific checkpoint but use the entire race plan to infer the correct placement. See Floating Passings.
Activating or Deactivating Passing Analysis
At the center of checkpoint control is the Process Passings toggle:
Activated → The checkpoint actively processes passings. Valid detections are assigned to participants and integrated into timing calculations.
Deactivated → The checkpoint stops processing incoming passings. Detections are still captured but are not used for timing.
This toggle allows organizers to manage checkpoint behavior dynamically without interrupting hardware collection.
Status of Passings When Inactive
If a checkpoint is deactivated:
Passings recorded at that location are still captured and stored.
These passings are marked with the status CHECKPOINT_CLOSED.
This ensures a clear audit trail while preventing the passings from affecting official race timing and rankings.
When to Use This Control
Before the race starts → Keep checkpoints deactivated until just before the event begins to avoid noise from setup or early chip detections.
After all participants have passed → Deactivate a checkpoint once it has served its purpose to prevent unnecessary data (e.g., staff or spectators walking over mats).
Shared physical locations → If start and finish share the same mat but are set as separate checkpoints in RRM, you can close Start while keeping Finish active.
Best Practices
Always verify that Start checkpoints are activated at race start.
Close checkpoints that are no longer needed to keep data clean.
Use separate logical checkpoints for Start and Finish, even if they are physically in the same place, so you can control them independently.
Check the Event Control View for passings with the status CHECKPOINT_CLOSED when reviewing inactive periods.
Last updated