RUFUS Help
RUFUS Race Manager
RUFUS Race Manager
  • Introduction to RUFUS Race Manager
  • GETTING STARTED
    • Introduction to Race Timing and Race Timing Software
    • Excel 101: Handling Participant Data
    • Networks 101: Understanding the Basics for Race Timing
    • System Requirements for RUFUS Race Manager
  • installation and setup
    • Installing RUFUS Race Manager
    • Initial Configuration
    • User Interface Overview
  • event management
    • Creating a New Event
    • Managing Events
    • Event Settings
    • Event Control View
  • Participant Management
    • Participants Menu
    • Manually Adding Participants
    • Import Participants from List
    • Editing Participant Details
    • Participant Statuses
    • Participant Passings
    • Organizing Participants
  • Checkpoints
    • Understanding Checkpoints
    • Checkpoints Menu
    • Creating Checkpoints
    • Checkpoint Dashboard
    • Checkpoint-Race View
  • Races
    • Races Menu
    • Creating Races
    • Race Dashboard
  • SEGMENTS
    • Understanding Segments
    • Segments Menu
    • Creating Segments
    • Time Visualization
    • Race-Segment View
  • GROUPS AND AGE GROUPS
    • Groups Menu
    • Groups
    • Age groups
  • Timing Devices Integration
    • Introduction to Timing Devices
    • Devices Menu
    • Connecting Local Devices
    • Connecting Cloud Devices
    • Analyzing Backup Files
    • Event-Devices View
    • Rewind Passings
  • Collecting and Managing Timing Data
    • Understanding the Data Collection Process
    • Timing on Race Day
    • Adding Manual Passings
    • Monitoring Live Timing Data
    • Editing Timing Data
    • Passing Statuses
    • Reprocess Passings
  • Classification and Results Processing
    • Understanding Classifications
    • Results Menu
    • Viewing Race Results
    • Generating Reports
  • PUBLISHING IN THE RUFUS EVENT APP
    • Publishing the Event
    • Publishing Participant Information
    • Publishing Race Results
  • Offline Mode and Data Synchronization
    • Working Offline with RRM
    • Data Synchronization
  • Troubleshooting and Support
    • Common Issues and Solutions
    • Frequently Asked Questions (FAQs)
  • Updates and New Features
    • Upcoming Features
    • Keeping RRM Updated
    • Changelog
  • Best Practices and Tips
    • Optimizing Race Timing Workflow
    • Data Management Best Practices
Powered by GitBook
On this page
  • The Process
  • Starting with a Passing
  • Device Assignment and Participant Identification
  • Checkpoint Association and Race Validation
  • Iterating through Checkpoints
  • Dynamic Lap and Segment Calculation
  • Ranking Dance
  • Key Statuses Explained
  • Summary
  1. Collecting and Managing Timing Data

Understanding the Data Collection Process

The timing data collection process in RUFUS Race Manager (RRM) involves a systematic flow to ensure accurate and consistent recording of participants' progress throughout a race. This article explains how passings (data points captured at checkpoints) are processed, validated, and managed by the software. The process follows a series of checks and decisions to assign the correct status to each passing, ensuring that every participant's progress is accurately tracked.

The Process

Starting with a Passing

A new passing starts with three key pieces of information:

  • Device ID: Identifies which timing device recorded the passing.

  • Chip/Bib Number: Identifies the participant.

  • Timestamp: The precise moment the passing was recorded.

Device Assignment and Participant Identification

  1. Device Verification: First, the system verifies if the passing is coming from a device assigned to the event. If the participant isn't recognized, the passing is marked with "ORPHAN" status.

  2. Participant Assignment: If the passing contains a valid chip or bib that is recognized, the system then checks if the participant is assigned to a race.

    • If the participant has no assigned race, the passing is given a "NO RACE" status.

Checkpoint Association and Race Validation

  1. Checkpoint Verification: The system checks whether the timing device has a valid checkpoint associated with the participant's race. If there is no valid checkpoint, the passing is marked as "WRONG RACE".

  2. Time Validity: If the device and checkpoint are verified, the system then validates whether the timestamp is within an appropriate time range for the race. If it's not, the passing is marked as "TIME INVALID".

Iterating through Checkpoints

  1. Checkpoint Iteration: If the race and time are both valid, the system iterates through the checkpoints defined for that device and race. If no more checkpoints are left to validate, the passing is marked as "EOTR (End Of The Road)", indicating a valid endpoint for that participant's race progress.

Dynamic Lap and Segment Calculation

  1. Lap Calculation: For checkpoints that are not the start or finish, the system determines if the passing completes a new lap by comparing it to the last valid passing. If a new lap is completed, the lap ID is updated accordingly.

  2. Bounce Time Analysis: The system then checks if the new passing complies with the bounce time settings (a dead time during which additional passings from the same participant are ignored to prevent duplicates). If the bounce time criteria aren't met, the passing is marked as "BOUNCED".

  3. Assign Valid Status: If all checks are passed, the passing is assigned a "VALID" status.

Ranking Dance

Once all passings are processed and validated, the "Ranking Dance" takes place—this is where all valid passings are ordered in time to generate rankings for the race. Valid passings are used to calculate participants' segment times, overall race times, and rankings.

For Cloud devices, this processing happens in the Cloud, utilizing cloud resources. For Local devices, the processing occurs locally on the timing PC running RRM, ensuring no cloud resources are consumed for local data.

Key Statuses Explained

  • ORPHAN: Passing is not recognized due to an unassigned or invalid device.

  • NO RACE: Participant is not assigned to any race.

  • WRONG RACE: Device checkpoint does not match the participant's assigned race.

  • TIME INVALID: Timestamp is not valid for the race.

  • EOTR (End Of The Road): Passing is valid but marks the end of that participant's race progress.

  • BOUNCED: Passing is ignored due to bounce time criteria.

  • VALID: Passing meets all criteria and is included in race timing and ranking calculations.

Summary

The timing data collection process in RRM is crucial for ensuring that every passing is accurately validated, assigned, and processed to generate fair and consistent race rankings. Each step of the process—from device verification, participant identification, checkpoint validation, to bounce time analysis—ensures that the data collected is reliable and accurate.

PreviousRewind PassingsNextTiming on Race Day

Last updated 7 months ago