# 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.

![](https://rufus-serverless-v1-shopmediabucket-yqa11v58uwom.s3.us-east-1.amazonaws.com/knowledge/assets/knowledge_asset_4f422d2c6d74422fa1b0f5a0afde2b7e/imported.png)
_Device Scope Diagram_

## 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.

![](https://rufus-serverless-v1-shopmediabucket-yqa11v58uwom.s3.us-east-1.amazonaws.com/knowledge/assets/knowledge_asset_d7074095f86d427d88caa23cbafb524d/imported.png)
_Device Bounce vs 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).

## Compatible Local Timing Devices

You can connect locally the current compatible timing devices:

* **Macsha One4All 5 Base and PRO systems**
* **RUFUS CloudBox**
* **RaceResult**
* **LLRP RFID Readers**
* **Mylaps**
* **Feibot**
* **Ultra RFID**
* **Westhold**

## 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.