Introduction to Timing Devices
In RUFUS Race Manager (RRM), timing devices are the bridge between the racecourse and the software. They capture passings (chip reads, bib taps, or manual inputs) and send them to RRM, where the data is validated and transformed into race results.
What is a Timing Device?
A timing device is any hardware or system that generates passings, each containing:
Participant identification (chip code, bib number, or manual entry).
Timestamp (the exact moment the passing occurred).
Devices can work automatically (RFID readers, CloudBox) or manually (RUFUS Timing App). In RRM, every device must be assigned to checkpoints so the system knows which part of the race each passing belongs to.
Device Scope
Each device in RRM has a scope, meaning it only covers a subset of the race’s checkpoints.
Example:
Device A at the Start/Finish mat → scope includes Start (Lap 0) and Finish (Lap 9999).
Device B at the 10k mat → scope includes only the 10k checkpoint.
Device C at 15k and 30k mats → scope includes both checkpoints.
Passings from a device are validated only against the checkpoints within that device’s scope.
Bounce Time in Devices
Duplicate passings can occur if a chip is read multiple times in quick succession. RRM manages this through bounce logic, but it’s important to distinguish two layers:
Device internal bounce → Some RFID readers filter repeated reads before sending them.
RRM device bounce → Configured when adding the device in RRM. Ensures passings from the same participant are ignored within a defined time window.
⚠️ Note: Manual passings (added in-app or via floating/manual tools) are immune to device bounce but still respect checkpoint bounce.
Device Bounce vs Checkpoint Bounce
Order matters, RRM checks Checkpoint Bounce first, then Device Bounce.
BOUNCED_BY_CHECKPOINT: triggers when a read arrives within the per-checkpoint window.
BOUNCED_BY_DEVICE: triggers when a read arrives within the device’s own window.
Manual/Floating passings skip device bounce but still respect checkpoint bounce.
Passing Statuses Related to Devices
When processing passings, device conditions directly affect statuses:
DEVICE_CLOSED → The device is inactive (not set to process passings).
BOUNCED_BY_DEVICE → A passing was ignored because it fell inside the device’s bounce time window.
VALID → Passing is accepted by the device and assigned correctly.
These statuses make it clear how each passing was handled during validation.
Types of Devices in RRM
Cloud Devices
Connected via the RUFUS Cloud.
Require internet access.
Examples: Custom integrations via the Open API, RUFUS CloudBox with IoT features.
Local Devices
Connected directly to the timing PC (Ethernet, WiFi, etc.).
Communication via TCP sockets.
Examples: RUFUS CloudBox, Macsha One4All 5.
Provide extended monitoring (battery, temperature, sync).
Assigning Devices to Checkpoints
Every device must be assigned to one or more checkpoints in the Device Settings.
This ensures passings are only validated against the correct parts of the race.
Devices without checkpoint assignments cannot contribute to timing.
Summary
In RRM:
Devices generate passings that are scoped to specific checkpoints.
Bounce logic ensures duplicate reads are filtered, either at device level or in RRM.
Device-related statuses make data handling transparent.
Cloud and local devices are both supported, with CloudBox bridging both worlds.
Understanding how devices operate inside RRM is essential for accurate, efficient, and reliable race timing.
Last updated