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

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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://help.runonrufus.com/rufus-race-manager/timing-devices-integration/introduction-to-timing-devices.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.