> For the complete documentation index, see [llms.txt](https://help.runonrufus.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.runonrufus.com/rufus-race-manager/timing-devices-integration/introduction-to-timing-devices.md).

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

<figure><img src="/files/ac1Qd2sjKF5UsUjpsxW8" alt=""><figcaption><p>Device Scope Diagram</p></figcaption></figure>

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

<figure><img src="/files/8g8Vy8h7MOlEUOFfDcI6" alt=""><figcaption><p>Device Bounce vs Checkpoint Bounce</p></figcaption></figure>

## 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**&#x20;
* **Mylaps**
* **Feibot**&#x20;
* **Ultra RFID**&#x20;
* **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.