# Welcome to RUFUS Help Center

Explore everything you need to get the most out of RUFUS products suite, all in one place. Whether you are timing events with the RUFUS CloudBox, managing race operations with RUFUS Race Manager, or integrating your own solutions using the RUFUS Public API, our help guides are designed to support you every step of the way.

Choose a category to get started:

<table data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th><th data-hidden data-card-cover data-type="image">Cover image</th></tr></thead><tbody><tr><td><strong>RUFUS Cloud Help</strong> </td><td>Learn to set up and use the RUFUS Cloud Platform—the ultimate hub for managing your timing devices, events, and real-time race data! </td><td><a href="https://help.runonrufus.com/rufus-cloud">https://help.runonrufus.com/rufus-cloud</a></td><td data-object-fit="contain"><a href="/files/8TgFFPFAWTbIIP2Dbi0U">/files/8TgFFPFAWTbIIP2Dbi0U</a></td></tr><tr><td><strong>RUFUS Race Manager Help</strong></td><td>Master the RUFUS Race Manager, including participant management, checkpoint configuration, and results processing.</td><td><a href="https://help.runonrufus.com/rufus-race-manager">https://help.runonrufus.com/rufus-race-manager</a></td><td data-object-fit="contain"><a href="/files/QbbjVg7DMhBIBDrvGjde">/files/QbbjVg7DMhBIBDrvGjde</a></td></tr><tr><td><strong>RUFUS Race App  Help</strong>             </td><td>Learn how to set up and use the RUFUS Race App for race timing. From manual timing and race alerts to bonus &#x26; penalizations and team chat.</td><td><a href="/spaces/1sZIrkMlXm95ujcqAqfj/pages/Dte7FMO4R2fdzK0LYTvb">/spaces/1sZIrkMlXm95ujcqAqfj/pages/Dte7FMO4R2fdzK0LYTvb</a></td><td data-object-fit="contain"><a href="/files/w29KE64crjVTaEWhjHJA">/files/w29KE64crjVTaEWhjHJA</a></td></tr><tr><td><strong>RUFUS Events App Help</strong></td><td>Learn how to navigate and utilize the <strong>RUFUS Events App</strong> to access live race results, participant information, and event details. </td><td><a href="/spaces/I4WtN9BWShT7BWdHS9mo/pages/FzOLcci6Hk6UT5boOK4Q">/spaces/I4WtN9BWShT7BWdHS9mo/pages/FzOLcci6Hk6UT5boOK4Q</a></td><td data-object-fit="contain"><a href="/files/j6xHk4LiTCTIKP3zCHby">/files/j6xHk4LiTCTIKP3zCHby</a></td></tr><tr><td><strong>RUFUS CloudBox Help</strong>            </td><td>Learn how to set up and use the CloudBox for accurate race timing, from network connections to data syncing.</td><td><a href="https://help.runonrufus.com/rufus-cloudbox">https://help.runonrufus.com/rufus-cloudbox</a></td><td><a href="/files/8WJhP0LdrMej3gisJ9XB">/files/8WJhP0LdrMej3gisJ9XB</a></td></tr><tr><td><strong>RUFUS Public API Help</strong></td><td>Get in-depth information on integrating your custom applications and timing devices with RUFUS services via our Public API.</td><td><a href="/spaces/TCSseHEwnCQelzZOq6GX">/spaces/TCSseHEwnCQelzZOq6GX</a></td><td><a href="/files/wbcO1i4muZd4777ELfdv">/files/wbcO1i4muZd4777ELfdv</a></td></tr></tbody></table>

For the fastest way to find what you need, use the help search bar to look for information throughout all the documentation.

If you need further assistance, feel free to reach out to us at <help@runonrufus.com>.&#x20;


# Introduction to RUFUS CloudBox

Step into the future of race timing with the CloudBox, a cutting-edge device engineered to revolutionize the way you time and monitor race events.

The CloudBox is compatible with virtually any UHF RFID reader making it ideal for both low-density checkpoints and high-traffic finish lines. Remotely manage your devices, monitor battery life, GPS position, and more with ease. Integrated with RUFUS software, including RUFUS Cloud, the CloudBox is more than just a timing device—it's a complete, cloud-focused solution that will elevate your race events to the next level, offering unparalleled flexibility, reliability, and value.

Designed for both novice and professional race timers, CloudBox offers unparalleled ease of setup and operation, making it ideal for events of all sizes. From small local races to large-scale international marathons, CloudBox ensures timing is efficient and results are delivered with precision.

<figure><img src="/files/3dHEuV2MCbMusVNIfU60" alt=""><figcaption></figcaption></figure>

## Key Features of CloudBox

* **Seamless Cloud integration:** Finally, a cloud solution that's easy to use! Simply bind your device and you're ready to go.
* **Built-in 4G & GPS:** Ensure your devices stay online and accurately located at all times.
* **Fast and Easy Smartphone Control:** Connect to the access point and manage your device effortlessly by navigating to cloudbox.local.
* **Integrated WiFi Modem & Access Point:** Connect to local networks to gain Internet access and share it with connected clients.
* **USB and Ethernet Ports for Data Extraction:** Access your CloudBox via web, WiFi, or Ethernet. For quick file backups, simply plug in a USB drive.
* **Built-in Real-Time Clock:** Keep your devices synchronized with NTP or GPS time-syncing.
* **Configurable Network Parameters:** Easily configure network settings to integrate with your local area network.
* **Firmware Updates via Internet:** Automatically receive and install new firmware releases as soon as they become available.

## **How CloudBox Works**

CloudBox employs **RFID technology** to track athletes by assigning each participant a unique RFID tag, typically attached to their race bib or on an ankle band. As athletes pass through designated timing points (start line, checkpoints, finish line), CloudBox’s RFID readers and antennas detect the tags and record the exact time of crossing. This data is then transmitted to the central software, where it is processed and displayed as race results.

The core components include:

* **RFID Tags**: Passive UHF tags assigned to each athlete, which transmit a unique identifier to the CloudBox system when within range of an antenna.
* **RFID Reader and Antennas**: Strategically placed at critical points along the racecourse to capture tag data.
* **Timing Software**: The software processes the raw data collected by the CloudBox readers, matching it with the athletes' information and producing accurate race classifications and results.

## **Why Choose CloudBox for Race Timing?**

**1. Reliability and Accuracy**\
CloudBox’s UHF RFID technology ensures highly accurate reads, even in races with high-speed athletes such as cyclists. With features designed to reduce interference and handle large numbers of simultaneous reads, CloudBox consistently delivers dependable results, reducing the risk of missed or erroneous timing captures.

**2. Scalability and Flexibility**\
No matter the size of the event, CloudBox can be easily scaled. From a single race with a few hundred participants to large international events with thousands, the system adapts effortlessly. Additional units and antennas can be deployed as needed without complicated configurations.

**3. Easy Setup and Operation**\
Even without extensive technical knowledge, race timers can set up and operate CloudBox with ease. The system’s intuitive design reduces the learning curve, allowing users to focus more on race day operations rather than complex technical management.

**4. Real-Time Monitoring and Results**\
With real-time data capture, CloudBox allows event organizers to monitor the race as it happens, offering insights into athlete performance, split times, and rankings. Real-time tracking keeps the audience and support teams informed, contributing to a more engaging race experience.

**5. Support for Multi-Sport Events**\
CloudBox is versatile enough to handle the timing needs of multi-sport events like triathlons, where athletes transition between swimming, cycling, and running. With CloudBox, you can set up multiple timing points across different sections of the course and manage split times effortlessly.

## **Conclusion**

The **RUFUS CloudBox** is a comprehensive, reliable, and user-friendly race timing solution that caters to the diverse needs of both small and large race events. With its combination of UHF RFID technology, real-time data processing, and flexible deployment options, CloudBox is designed to meet the high standards of modern race timing.

Whether you're a professional timer managing a major event or a local organizer running a community race, CloudBox empowers you to deliver seamless, accurate, and efficient timing for athletes and event organizers alike.

Welcome to the future of race timing—welcome to **CloudBox**.


# Getting Started with RFID Technology

## **What is RFID?**

RFID (Radio Frequency Identification) is a wireless technology used to identify and track objects using radio waves. It involves the use of an RFID reader, antennas, and RFID tags, which communicate via radio frequency. RFID is widely used in various applications, including inventory management, security systems, and, notably, race timing.

## **Components of an RFID System**

* **RFID Reader**: The core device that emits radio waves to communicate with RFID tags. It processes the signals from the tags and sends the data to the timing software.
* **Antennas**: These are connected to the RFID reader and transmit radio waves to create a field. The antennas receive signals from the tags when they enter the field. Antennas come in various shapes and sizes depending on the specific use case, such as wide or narrow beam patterns for different tracking needs.
* **RFID Tags**: Each tag has a unique ID and contains a small chip and antenna. These tags are attached to the object (or person, in the case of race timing). Tags can be either active (with their own power source) or passive (powered by the reader's signal). In race timing, passive RFID tags are commonly used, as they are lightweight and disposable.

## RFID Frequencies

RFID operates in different frequency bands, including:

* **Low Frequency (LF)**: 125–134 kHz, commonly used for access control and animal identification.
* **High Frequency (HF)**: 13.56 MHz, often used for short-range applications like payment systems.
* **Ultra High Frequency (UHF)**: 300 MHz–3 GHz. UHF is preferred for race timing due to its longer read range (up to several meters) and fast tag detection rates.

The CloudBox timing system utilizes **UHF RFID** technology, which is ideal for accurately reading tags at a distance and handling large volumes of participants.


# Introduction to Race Timing

Race timing is a critical element of any competitive event. Accurately recording and managing participants' times not only determines the winners but also ensures fair play and a smooth overall experience for athletes and organizers. Whether it’s a marathon, triathlon, or cycling race, the process of timing a race involves various components, technologies, and preparations to ensure everything runs seamlessly.

## **Importance of a Well-Prepared Database**

A **well-prepared and accurate database** is the foundation of successful race timing. Before the race day:

* Ensure all participant data is collected accurately, including name, bib number, age, gender, category (if applicable), and RFID tag assignments.
* The database should be thoroughly checked for duplicates or missing information. Any errors in the database can lead to incorrect race results or even disqualification due to inaccurate classifications.
* Participant data is used for **correct classification** in the results, such as age group categories, overall ranking, or team results.

A polished database ensures the timing system accurately matches finish times with the correct participant, preventing confusion or disputes post-race.

## **Essential Equipment for Race Timing**

Race timing requires a mix of hardware and software, all working together to record participants' performance seamlessly. The following is a checklist of the essential components needed for a successful race timing setup:

* **CloudBox RFID Timing System**: This includes the RFID reader, antennas, and RFID tags (usually provided to participants in the form of bib tags or ankle chips).
* **Laptop/PC**: The central device where the timing software is installed and operated. It handles data processing, database management, and communicates with the CloudBox system.
* **Timing Software**: The software is crucial for capturing RFID tag data, managing the participant database, and generating results in real time.
* **Printer**: For printing results on-site, such as athlete ranking, certificates, or category classifications.
* **Notebook and Pen**: For manually noting any issues or unexpected incidents, like participants missing RFID reads, for later reconciliation.
* **Backup Power Source**: Having an **uninterruptible power supply (UPS)** or external batteries ensures your timing equipment keeps running smoothly even during power outages.
* **Backup Cameras**: These can be set up at the start/finish line or key checkpoints. They serve as a failsafe in case of RFID read failures, enabling manual cross-checking of times if necessary.
* **Mobile Devices**: For staying in touch with event organizers and potentially capturing any on-the-go adjustments to the setup.
* **Spare Equipment**: Spare RFID tags, connectors, or even additional readers and antennas in case of technical issues or breakdowns.

## **A Typical Race Day for a Timer**

Being a race timer requires thorough preparation and an early start to ensure everything goes according to plan. Here’s a rundown of a typical race day:

1. **Early Morning Start**: Race timing usually starts hours before the participants arrive. Depending on the event, timers might need to be on-site as early as 4 to 6 AM to begin the setup.
2. **Arrival at the Event**: On arrival, the first priority is to assess the race venue layout and confirm the locations of the start/finish lines and checkpoints. Collaborate with the event organizers to finalize details and access.
3. **Setup of Timing Equipment**:
   * Position **RFID readers** and **antennas** at critical points like the start line, finish line, and intermediate checkpoints if necessary.
   * Ensure **cables** are laid out safely, power is available, and backup power sources are ready.
   * Test the **timing software** by simulating tag reads, checking if the system records and displays times correctly.
4. **Pre-race Checks**: Conduct a **thorough test** of all RFID readers and antennas to ensure no dead zones or areas where tags might not be read.
   * Verify the **athlete database** by confirming bib numbers and tag IDs are correctly linked.
   * Coordinate with race organizers for any last-minute changes, like participant additions or withdrawals.
5. **During the Race**:
   * As participants cross the start line, the RFID system begins recording their times.
   * Continue to monitor the system throughout the race to ensure it is functioning correctly. If any tags fail to read, make manual notes of any discrepancies for later resolution.
   * If the race is multi-lap or has checkpoints, ensure those locations are functioning correctly and all data is being logged.
6. **Post-race**:
   * As participants cross the finish line, the timing system logs their completion times, and you begin generating **real-time results** for event organizers.
   * Address any **missed reads** or discrepancies, cross-referencing with **backup cameras** or manual notes.
   * Print and distribute **provisional results**, ensuring they are accurate before finalizing.
7. **Wrap Up**:
   * After the race, dismantle the equipment carefully, ensuring nothing is left behind or damaged.
   * Save and back up all race data, providing it to the event organizers for official publishing.
   * Conduct a **debrief** with the event team to discuss any issues and learnings for future events.

## **Conclusion**

Race timing is a high-stakes, detail-oriented process that requires preparation, the right tools, and careful management. From building a solid database to ensuring your timing equipment is reliable, these elements come together to deliver a smooth, efficient, and accurate race experience for all. With the right planning and attention to detail, your CloudBox system will help ensure a professional timing experience every time.


# RFID for Race Timing

In modern endurance events like marathons, triathlons, cycling, and obstacle races, **RFID (Radio Frequency Identification)** has become the standard for automated race timing. It enables accurate, contactless detection of athletes as they cross specific points — start, checkpoints, and finish lines — without requiring manual input.

This technology offers high efficiency, scalability, and reliability, but it also comes with a few considerations that every timer should understand to get the best possible performance.

## How RFID Timing Works

### 1. Tag Assignment

Each participant receives a small RFID tag — often integrated into the **bib**, **ankle strap**, or **bike frame**.\
Each tag contains a unique ID that the timing system associates with a participant in the timing software.

### 2. Reader and Antenna Setup

At the start, checkpoints, and finish lines, **RFID readers** are installed.\
Each reader is connected to one or more **antennas**, which create the **RF field** (the “read zone”) that detects tags as athletes pass through.

### 3. Detection and Timestamping

When a participant’s tag enters an antenna’s field, it reflects back a signal that the reader captures. The system records:

* The **tag ID**
* The **reader/antenna** that captured it
* The **exact timestamp**

This data is sent to the race timing software — such as the **RUFUS Race Manager** — where it is processed into passings, lap times, and final results.

## Understanding UHF RFID Technology

**UHF (Ultra High Frequency)** RFID is the most commonly used technology in race timing because it offers:

* **Long read range** (typically 3–8 meters)
* **Fast read rates** (hundreds of tags per second)
* **Passive operation** (no battery in the tag)
* **Low-cost** (cents per tag)

However, UHF RFID also behaves like any other radio signal — it can be influenced by **orientation, materials, and environment**. Let’s break down how to manage these factors effectively.

## Antenna Orientation and Field Coverage

Each antenna creates a **read field** shaped somewhat like a flattened bubble or fan.\
The exact size and strength depend on:

* Antenna model and gain
* Reader power setting
* Mounting height and angle

### Tips for Proper Orientation

* **Aim antennas at tag level.** For bib tags, **floor antennas** are often used, **or side antennas slightly tilted facing** the tag .
* **Avoid perpendicular angles.** A tag facing directly away from an antenna might not reflect enough energy to be read.
* **Overlap read fields.** If using multiple antennas, make sure their fields overlap slightly to avoid “dead zones.”

## Antenna Redundancy

Using more than one antenna at a timing point is not overkill — it’s **a key design principle**.

### Why Redundancy Matters

* A single antenna might miss a tag due to **orientation**, **body shielding**, or **momentary interference**.
* Multiple antennas from different angles ensure that **at least one antenna captures each tag**.

### Example:

At a finish line, a common setup is:

* Two lines of floor antennas.
* Overhead antennas (for backup)
* or side antennas  (for backup)

This redundancy drastically reduces missed reads and ensures consistent detection even if a runner passes at the edge of the mat or with their bib slightly folded.

## Chip (Tag) Redundancy

For large events, many timers use **dual-tag setups** — for example, two tags on the back of the bib or two an ankle straps.

### Benefits:

* Compensates for orientation issues — if one tag is facing away, the other likely isn’t.
* Increases read reliability for **dense packs** of runners or **cyclists grouped closely together**.

Some tag vendors even sell **twin-chip tags** specifically designed for endurance sports, pre-calibrated for this redundancy.

## The Importance of Orientation

The RFID tag has an internal **antenna strip** (often invisible under the label).\
The way this antenna faces relative to the field drastically affects performance.

### Best Practices:

* Ensure bibs are flat and facing forward.
* Avoid folding or wrinkling the tag area.
* On bikes, place tags **parallel to the frame** or **under the seat post**, away from metal surfaces.
* Avoid placing tags directly on **metal** or **wet skin**, as these absorb or reflect RF energy.

## The Role of Speed and Dwell Time

A tag must stay inside the antenna’s field long enough for the reader to “see” it — this is called **dwell time**.

### Example:

* A runner at 15 km/h spends \~0.4 seconds over a 1.5 m wide mat.
* A cyclist at 40 km/h crosses the same mat in just 0.13 seconds.

Because of this, high-speed events (like cycling or motocross) require:

* **Wider detection zones** (multiple antennas)
* **Higher reader sensitivity**
* **Optimal tag placement** to maximize visibility during that short window.

## Dealing with Environmental Factors

RFID systems can be affected by:

* **Water** (sweat, rain) — absorbs signal energy
* **Metal** (bike frames, timing gantries) — reflects or distorts the field
* **Crowded conditions** — cause tag collisions or signal reflection

### Mitigation Tips:

* Use **RFID mats** or side antennas with proper separation from metal structures.
* In wet conditions, ensure **tags are not directly soaked**.
* Adjust reader power to avoid “oversaturation,” which can cause reflections and duplicate reads.

## Summary: Pros and Cons of UHF RFID in Active Sports

### ✅ Pros

* **Contactless and automatic**: no need to stop or scan manually.
* **Scalable** for thousands of participants.
* **Low-cost tags**, easy to distribute and replace.
* **Accurate and reliable**, when properly configured.

### ⚠️ Considerations

* **Orientation-sensitive**: tags must be attached correctly.
* **Environmental influence**: water and metal can interfere.
* **Requires setup expertise**: antenna layout, redundancy, and power tuning are key.

## Practical Workarounds and Tips for Beginners

| Challenge                        | Practical Solution                                             |
| -------------------------------- | -------------------------------------------------------------- |
| Missed reads due to orientation  | Use dual tags (bib + shoe, or two bib chips)                   |
| Fast cyclists not detected       | Extend antenna zone or add side antennas                       |
| Metal interference (bike frames) | Keep tag 2–3 cm away from metal                                |
| Heavy rain                       | Use laminated bibs or waterproof tag covers                    |
| Dense finish lines               | Increase antenna redundancy and use side or overhead detection |

***

## Conclusion

RFID timing is a **powerful and proven technology** for endurance events — but **it’s not magic**.\
Its success depends on thoughtful setup, testing, and redundancy.

By understanding how antennas, tags, and environmental factors interact, even first-time timers can achieve **near-perfect read rates** and deliver **professional-level results** at their events.


# Networks 101: Understanding the Basics for Race Timing

In race timing, your timing systems, such as the CloudBox, are essentially computers that communicate with each other over a network. A clear understanding of networking basics can help ensure your timing system is set up correctly, operates smoothly, and communicates reliably with the software. Let’s dive into some key concepts that are essential for understanding how networks work in race timing environments.

## **What is a Network?**

A **network** is a group of interconnected devices (computers, servers, timing systems) that share data and resources. In the context of race timing, your CloudBox timing system, laptops, and potentially other devices are all connected over a network to exchange information, such as timing data and results.

The most common type of network used in timing systems is a **local area network (LAN)**, which connects devices within a specific location, such as the race venue or timing tent.

### **Key Networking Concepts**

Here are some of the fundamental elements of networks that you’ll encounter when setting up and managing timing systems:

#### **1. IP Address**

An **IP address** (Internet Protocol address) is a unique identifier for each device on a network, kind of like a postal address for a house. It ensures that data sent across the network arrives at the correct destination.

IP addresses come in two formats:

* **IPv4**: The most common type, made up of four sets of numbers separated by periods (e.g., `192.168.1.10`).
* **IPv6**: A newer format designed to offer more unique addresses, using longer alphanumeric strings (e.g., `2001:0db8:85a3:0000:0000:8a2e:0370:7334`).

In race timing systems, each CloudBox, laptop, and other network device will be assigned a unique IP address. The IP address helps these devices communicate and transfer data, such as timing results, back to the main computer or server.

#### **2. Subnet Mask**

A **subnet mask** is used in conjunction with an IP address to define which portion of the address refers to the network and which part identifies the individual device. It essentially divides the network into smaller sections, or "subnets," allowing efficient routing of data between devices.

A typical subnet mask for a small local network might look like this: `255.255.255.0`. In this example, the `255` portions indicate the network part, and the last `0` indicates the part used to identify individual devices on that network.

* For example, in a network with the IP range `192.168.1.0`, the subnet mask `255.255.255.0` means that all devices within that network can have addresses like `192.168.1.1`, `192.168.1.2`, and so on.

#### **3. Ports**

A **port** is a virtual endpoint that allows a computer to communicate with other devices over the network. Different services on a networked device communicate using specific port numbers. Think of ports as different doors to a house: each door (port) opens to a specific function or service running on the device.

For instance:

* **Port 80** is commonly used for web traffic (HTTP).
* **Port 8080** or **443** may be used for secure web services (HTTPS).
* In race timing, the CloudBox system may use specific ports to communicate with the timing software.

Ensuring the correct ports are open and available on your network is critical for data to flow between your timing system and the race management software.

#### **4. DHCP vs. Static IPs**

* **DHCP (Dynamic Host Configuration Protocol)**: In a network, a DHCP server automatically assigns IP addresses to devices when they connect to the network. This is convenient because it simplifies setup, especially when there are many devices.
* **Static IP Address**: A static IP is manually assigned to a device and remains constant. In race timing setups, you may assign static IP addresses to timing devices to ensure consistent communication. For example, assigning a static IP to your CloudBox means you always know where it is on the network.

#### **5. Router and Switch**

* **Router**: A router is a device that connects multiple networks and directs traffic between them. In a race timing context, the router may manage the traffic between the timing system’s local network and an external network (e.g., the internet or the race organizer’s network).
* **Switch**: A switch connects multiple devices within a single network, allowing them to communicate with each other. For example, if you have multiple CloudBox systems, a switch can connect them all to your timing network.

## **How It All Works Together in Race Timing**

On race day, your timing systems (e.g., CloudBox), laptop, and possibly other devices are networked together. Here’s how the concepts we've covered come into play:

1. **Setting Up the Network**:
   * You'll connect your CloudBox system to your local network, either via Ethernet cables or Wi-Fi, depending on the setup.
   * Assign each device a unique IP address, either dynamically using DHCP or statically for more control.
2. **Communication Between Devices**:
   * Your CloudBox sends timing data (e.g., when an athlete crosses a checkpoint) over the network. It uses IP addresses to ensure the data is delivered to the correct computer, and ports to handle the data transmission.
3. **Ensuring Reliable Communication**:
   * Subnet masks ensure that all devices on your race timing network can communicate properly.
   * The router or switch manages the flow of data between devices, ensuring everything runs smoothly without interruptions.
4. **Troubleshooting Network Issues**:
   * If a timing system fails to communicate with the laptop, check whether IP addresses are correctly assigned, whether the right ports are open, or if there are any network device malfunctions (e.g., a faulty router or switch).

## **Conclusion**

A solid understanding of basic network concepts like IP addresses, ports, and subnet masks will help you set up and troubleshoot your race timing systems more effectively. The CloudBox and other timing devices rely heavily on networks to function correctly, so ensuring your network is configured and optimized is a key part of a successful race timing operation.

By learning the fundamentals of networking, you’ll be better prepared to handle any challenges that arise on race day and keep your timing system running smoothly.


# Excel 101: Handling Participant Data

Excel is a powerful tool for managing participant data in race timing events. Knowing the basic functions and formulas in Excel is essential for efficiently preparing and organizing participant lists, which will later be uploaded to the timing software for race classification. In this article, we’ll cover some of the key formulas and tips that are most useful for handling race data in Excel.

## Key Excel Formulas

### **1. CONCAT**&#x20;

* **Purpose**: Used to combine text from two or more cells into one cell.
* **Usage**: Often useful when you need to create full names or merge different pieces of data (like name and bib number).

**Syntax**:

```excel-formula
=CONCAT(text1, text2, ...)
```

**Example**:

```excel-formula
=CONCAT(A2, " ", B2)
```

If cell A2 contains the **First Name** and B2 contains the **Last Name**, this formula will combine the two into one cell with a space between them, producing something like **John Doe**.

***

### **2. VLOOKUP**

* **Purpose**: Looks for a value in the first column of a table and returns a value in the same row from a specified column. Useful for **finding bib numbers**, classification results, or participant information.
* **Usage**: This is helpful when matching participant bib numbers with names or other relevant data.

**Syntax**:

```excel-formula
=VLOOKUP(lookup_value, table_array, col_index_num, [range_lookup])
```

**Example**:

```excel-formula
=VLOOKUP(C2, $A$2:$B$100, 2, FALSE)
```

In this example, if **C2** contains a **bib number**, the formula will search for it in the first column of the range **A2**

and return the corresponding name from the second column.

* **Key Tip**: Use **FALSE** as the last argument to get an **exact match**.

***

### **3. MID**

* **Purpose**: Extracts a specific portion of text from a cell, based on the starting point and the number of characters you want to extract.
* **Usage**: This is handy when you need to extract specific parts of information, like a middle name or a specific digit from an ID or bib number.

**Syntax**:

```excel-formula
=MID(text, start_num, num_chars)
```

**Example**:

```excel-formula
=MID(A2, 1, 5)
```

This formula extracts the first **5 characters** from the text in cell **A2**. If A2 contains a bib number or a name, it will extract the first part (e.g., if A2 is "12345John", it will extract "12345").

***

### **4. IF**

* **Purpose**: Creates conditional statements, allowing you to make decisions within your data.
* **Usage**: Often used to apply different labels or classifications based on certain criteria (e.g., male/female or age group divisions).

**Syntax**:

```excel-formula
=IF(logical_test, value_if_true, value_if_false)
```

**Example**:

```excel-formula
=IF(B2="M", "Male", "Female")
```

If **B2** contains "M", this formula will return **Male**; otherwise, it will return **Female**.

***

### **5. SUMIF**

* **Purpose**: Adds the values in a range that meet specific criteria. Useful for summing times or points only for certain participants (e.g., those from a particular age group).
* **Usage**: Calculate total values based on a specific condition (e.g., only for participants from a particular city or team).

**Syntax**:

```excel-formula
=SUMIF(range, criteria, [sum_range])
```

**Example**:

```excel-formula
=SUMIF(B2:B100, "18-24", C2:C100)
```

This will sum all the values in **C2**

where the value in **B2**is equal to "18-24" (age group).

***

### **6. COUNTIF**

* **Purpose**: Counts the number of cells that meet a certain condition. Useful for counting participants in a specific category or group.
* **Usage**: This can help you see how many participants are in a certain category (e.g., males, females, a specific team).

**Syntax**:

```excel-formula
=COUNTIF(range, criteria)
```

**Example**:

```excel-formula
=COUNTIF(C2:C100, "Team A")e
```

This will count how many times **Team A** appears in the range **C2:C100**

***

### **7. TEXT**

* **Purpose**: Formats numbers as text, particularly useful for formatting dates, times, or bib numbers with leading zeros.
* **Usage**: If you need to standardize your data for uploading into the timing software, this is a key formula to use.

**Syntax**:

```excel-formula
=TEXT(value, format_text)
```

**Example**:

```excel-formula
=TEXT(A2, "00000")
```

If A2 contains the number **123**, this formula will return **00123**, preserving the 5-digit format.

***

### **8. LEFT, RIGHT**

* **Purpose**: Extracts a certain number of characters from the left or right side of a text string.
* **Usage**: Extract key parts of data from a larger string (e.g., initials, the last digits of bib numbers).

**Syntax**:

```excel-formula
=LEFT(text, num_chars)
=RIGHT(text, num_chars)
```

**Example**:

```excel-formula
=LEFT(A2, 3)
```

This will return the **first 3 characters** of the text in A2.

***

### **9. TRIM**

* **Purpose**: Removes extra spaces from text.
* **Usage**: This is crucial for cleaning up messy participant lists where extra spaces might have been entered, affecting the data upload process.

**Syntax**:

```excel-formula
=TRIM(text)
```

**Example**:

```excel-formula
=TRIM(A2)
```

This will remove all extra spaces from the text in cell **A2**.

***

## Organizing Data for Race Classification

When preparing Excel files for uploading to the timing software, ensure that:

1. **All necessary columns** (e.g., Name, Bib Number, Age, Gender, Team) are filled in and formatted correctly.
2. Use **consistent formatting** for all fields to prevent errors during the upload process.
3. **Remove any extra spaces** or irrelevant data using the **TRIM** function before finalizing the file.
4. Double-check formulas like **VLOOKUP** or **SUMIF** to ensure participant data is properly matched and summarized.

## Summary

Excel is a powerful tool for preparing race participant data, and knowing how to use its key formulas will make managing and organizing data easier. With formulas like **CONCAT**, **VLOOKUP**, **EXTRAE**, and others, you can efficiently format and prepare participant lists for smooth uploading into timing software, ensuring accurate race classification and results.


# CloudBox Ports & Characteristics

The **CloudBox** is a powerful and versatile timing device equipped with multiple ports and features designed to optimize its performance in race timing environments. In this article, we’ll break down the key ports and their characteristics, as well as the system components that make the CloudBox an essential tool for race organizers.

<figure><img src="/files/9EFsjPdLf78JLjIsItYq" alt=""><figcaption></figcaption></figure>

## Key Ports and Connectivity

1. **Ethernet Port**
   * **Connector**: RJ45 Neutrik NE8FDP IP65
   * **Purpose**: This port is used for establishing a **TCP socket connection** for controlling the CloudBox, managing status updates, and retrieving timing data. It provides reliable communication over wired networks, making it ideal for setups where stability and speed are critical.
   * **Use Cases**: Data extraction, status monitoring, and session control via Ethernet.
2. **USB Port**
   * **Connector**: USB 2.0 Neutrik NAUSB-W
   * **Purpose**: The USB port is designed for **quick extraction of backup files**. By inserting a USB drive, you can swiftly download saved passings for post-race analysis.
   * **Use Cases**: Backup passings data downloads.
3. **Charging Port**
   * **Connector**: Standard IEC-320 C-14
   * **Purpose**: This port allows for safe and efficient charging of the CloudBox’s internal batteries.
   * **Use Cases**: Powering the CloudBox, battery recharging.
4. **SIM Card Slot**
   * **Type**: 2FF - Mini SIM (25 x 15 x 0.76 mm)
   * **Purpose**: The CloudBox supports 4G connectivity via a **Mini SIM card**, allowing for remote operation and real-time data transmission even when WiFi or Ethernet is unavailable.
   * **Use Cases**: Cellular data for live timing, cloud communication, and GPS tracking.
5. **WiFi Access Point**
   * **Specification**: 802.11b/g/n - Internal antenna
   * **Purpose**: The CloudBox can function as a **WiFi access point**, enabling easy access and control via smartphones or other devices. It can also connect to external WiFi networks to gain internet access.
   * **Use Cases**: Connecting to local WiFi networks for data transmission, serving as an access point for device control.
6. **UHF Reader Compartment**
   * **Reader Power Output Cable**: Supplies power to the RFID reader.
   * **Reader Data Input Ethernet Cable**: Used to connect the reader to the system for data transmission.
   * **Purpose**: This compartment is specifically designed to house and connect compatible RFID readers.

***

## System Components

1. **CPU and Memory**
   * **CPU**: Quad Core 1.2GHz Broadcom BCM2837 64bit CPU
   * **RAM**: 1GB
   * **Flash Memory**: 32GB
2. **Real-Time Clock (RTC)**
   * **Accuracy**: ±20 parts per million (ppm), approximately ±1.73 seconds per day.
   * **Synchronization**: Frequent synchronization with an NTP server reduces the impact of clock drift, making the device highly accurate.
   * **Purpose**: Ensures accurate timekeeping during events.
3. **Integrated WiFi Modem**
   * **WiFi**: 802.11b/g/n
   * **Purpose**: For connecting to external WiFi networks or creating a **local access point** to share internet access with connected devices.
   * **Use Cases**: Remote control, real-time timing data sharing, and system monitoring via WiFi.

***

## Environmental and Physical Specifications

#### Protection Rating

**IP52**: Protected against limited dust ingress and dripping water when tilted up to 15 degrees.

The CloudBox is designed for controlled outdoor event environments, but it is **not waterproof** and must always be protected from extreme weather conditions.

The system can handle minor exposure to outdoor elements, but it must not be left unprotected under heavy rain or exposed to water spray. During wet weather, always use an appropriate protective cover or place the CloudBox in a sheltered location where water cannot reach the unit directly.

#### Weather Protection Guidelines

When using the CloudBox outdoors, always protect it from **direct sunlight, excessive heat, heavy rain, and water spray**.

Place the CloudBox in a **shaded area** with proper air ventilation. Never place the system under direct sunlight, especially during hot weather or long events.

Avoid placing the CloudBox directly on hot surfaces such as **asphalt, concrete, or other heat-retaining floors**, as these surfaces can increase the internal temperature of the system. When needed, raise the CloudBox from the ground or place it on a cooler, stable surface.

During rain, never leave the CloudBox unprotected. The system must be kept away from heavy rain and must not be exposed to shower spray, hose spray, or water being blown toward the unit by wind.

#### Operating Internal Temperature

**Range:** -20°C to +60°C

The CloudBox can operate in a wide range of outdoor temperatures. However, in hot weather, the system must be kept in the shade and properly ventilated to prevent overheating.

**Use Cases:** Suitable for outdoor races in cold and warm conditions, provided that the system is protected from direct sunlight, extreme heat, and water exposure.

#### Dimensions and Weight

**Dimensions:** 36 x 26 x 20 cm

**Weight:** 5.5 kg without the reader

**Use Cases:** Portable and durable enough for event handling, while still requiring proper placement and protection during outdoor use.

***

## Alarms and Notifications

1. **Buzzer**
   * **Frequency**: 2.9kHz
   * **Acoustic Level**: 95dB
   * **Purpose**: Provides audible feedback for system events, such as passing notifications during timing sessions.
   * **Use Cases**: Real-time passing notifications, error alerts.
2. **LEDs**
   * **Power and Start/Stop LEDs**: These indicators provide real-time feedback on the CloudBox’s operational status, signaling power on/off, timing session states, and errors.
   * **Use Cases**: Monitoring system status during races.

***

## UHF Reader and Antenna Compatibility

1. **Reader Compatibility**
   * **Models**: Zebra FX9600, Motorola FX9500, Impinj R420, Impinj R220, Chainway UR4.
   * **Purpose**: The CloudBox is **reader agnostic**, allowing it to be used with a wide variety of UHF readers from the most trusted industry brands.
   * **Use Cases**: Adaptable for low and high-density timing points, making it versatile for different race event types.
2. **Antenna Compatibility**
   * **Frequencies**: 902MHz – 928MHz, 865MHz – 868MHz
   * **Purpose**: The CloudBox is compatible with a wide range of UHF antennas, ensuring seamless integration with existing timing setups.
   * **Use Cases**: Various race timing scenarios, including road races, trail running, cycling, and triathlons.


# Quick Start Video Tutorials

Welcome to your **CloudBox**! 🚀\
\
Before diving into your first race, we’ve prepared a short **First Steps** video playlist to walk you through everything you need to know to get up and running.

These videos cover the essentials—from powering up your CloudBox and checking the battery, to navigating the Dashboard and linking your device to the **RUFUS Cloud**.

## Video 1 — Meet your CloudBox

Before your first event, here’s what you need to know:

* Battery checks
* Antenna setup
* LED signals
* How to connect via Ethernet or Wi-Fi

🎥 [*First Steps Ep 1 / CloudBOX & RUFUS Cloud*](https://www.youtube.com/watch?v=12BZ4bH27uI)

<figure><img src="/files/SLPtDPuJJyrGQyKjyRqg" alt="" width="563"><figcaption></figcaption></figure>

## Video 2 — Explore the Dashboard

The CloudBox Dashboard is your control center. In this video you’ll learn:

* How to navigate the tabs (Timing, Status, GPS, Backup, Config, Cloud)
* How to connect your device to the internet
* How to configure your RFID reader

🎥 [*First Steps Ep 2 / CloudBOX & RUFUS Cloud*](https://www.youtube.com/watch?v=s2X8hAg5ViY)

<figure><img src="/files/dHeInLMjdcuHlHCq03hx" alt="" width="563"><figcaption></figcaption></figure>

## Video 3 — Link to RUFUS Cloud & Start Timing

Bring it all together by pairing your CloudBox with your RUFUS Cloud account. This video shows you how to:

* Set up your Cloud account
* Link your CloudBox device
* View dashboards
* Start and stop a test reading

🎥 [*First Steps Ep 3 / CloudBOX & RUFUS Cloud*](https://www.youtube.com/watch?v=xwPnc40jREY)

<figure><img src="/files/OM0tfTvphYSSfMtDqxVZ" alt="" width="563"><figcaption></figcaption></figure>

***

With these three short videos, you’ll have your CloudBox ready for action in no time.\
Once you’ve completed these steps, you’re ready to move on to more advanced features—or straight to your first event


# How to Connect to the CloudBox

To interact with the **RUFUS CloudBox** and send commands, you'll need to establish a **TCP socket connection**. This allows you to send protocol commands to control and configure the CloudBox, retrieve its status, and manage race timing operations.&#x20;

The CloudBox can handle the connection of multiple clients at the same time.

Here’s a step-by-step guide on how to connect to the CloudBox, for example, at **IP address 192.168.1.10** and **port 8080**.

### **Step 1: Check Your Network Setup**

Before connecting to the CloudBox, ensure the following:

1. **Network Connectivity**:
   * The computer or device you are using to connect to the CloudBox must be on the **same network** as the CloudBox. This is usually a **local area network (LAN)**, or you may connect via Wi-Fi if the CloudBox is connected wirelessly.
   * Verify the CloudBox’s **IP address** and **port number** (in this case, IP: `192.168.1.10`, Port: `8080`). You can retrieve this information from the system configuration (via `GETSYSTEMCONFIG` or by referencing the system setup information).
2. **Firewall and Port Access**:
   * Ensure that port `8080` is **open** and not blocked by any firewall on your local machine or network.
   * The CloudBox must be reachable at the specified IP and port. If any network restrictions are in place, these may need to be adjusted.

### **Step 2: Open a TCP Socket Connection**

To connect to the CloudBox, you will need a terminal or software that supports **TCP socket connections**. Depending on your operating system and tools available, you can use various methods to establish this connection.

#### **Using a Command Line (Linux/macOS/Windows)**

For example, you can use **netcat (nc)**, a common command-line tool for network debugging, to open a TCP connection.

* **Linux/macOS**: Open a terminal and run the following command:

  <pre class="language-bash" data-full-width="false"><code class="lang-bash">nc 192.168.1.10 8080
  </code></pre>
* **Windows**: You can also use PowerShell or CMD to run the same command (if `nc` is installed), or you can use other tools like **PuTTY** to establish a TCP socket connection.

#### Using a Programming Language (Python, C#, and Node.js)

You can also connect to the CloudBox using programming languages like Python, C#, and Node.js. Below are examples for each of these languages, showing how to establish a TCP connection, send a command, and receive a response from the CloudBox.

#### **Python Example**

In Python, you can use the `socket` module to establish a TCP connection to the CloudBox.

```python
# CloudBox IP and port
HOST = '192.168.1.10'  # CloudBox IP address
PORT = 8080            # CloudBox TCP port

# Create a TCP socket
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    # Connect to CloudBox
    s.connect((HOST, PORT))
    print(f"Connected to CloudBox at {HOST}:{PORT}")

    # Example of sending a command (e.g., GETSYSTEMSTATUS)
    command = "GETSYSTEMSTATUS\r\n"
    s.sendall(command.encode('utf-8'))

    # Receive response from CloudBox
    data = s.recv(1024)
    print(f"Received: {data.decode('utf-8')}")

# The connection will automatically close when the block ends
```

**C# Example**

In C#, you can use the `TcpClient` class to establish a TCP connection to the CloudBox and interact with the system.

```csharp
using System.Net.Sockets;
using System.Text;

class Program
{
    static void Main(string[] args)
    {
        // CloudBox IP and port
        string host = "192.168.1.10";
        int port = 8080;

        try
        {
            // Create a TCP client and connect to the CloudBox
            TcpClient client = new TcpClient(host, port);
            Console.WriteLine($"Connected to CloudBox at {host}:{port}");

            // Get the network stream
            NetworkStream stream = client.GetStream();

            // Example of sending a command (e.g., GETSYSTEMSTATUS)
            string command = "GETSYSTEMSTATUS\r\n";
            byte[] dataToSend = Encoding.ASCII.GetBytes(command);

            // Send the command to CloudBox
            stream.Write(dataToSend, 0, dataToSend.Length);
            Console.WriteLine("Command sent");

            // Buffer for receiving data
            byte[] dataReceived = new byte[1024];
            int bytes = stream.Read(dataReceived, 0, dataReceived.Length);

            // Display the response
            string response = Encoding.ASCII.GetString(dataReceived, 0, bytes);
            Console.WriteLine($"Received: {response}");

            // Close the stream and client connection
            stream.Close();
            client.Close();
        }
        catch (Exception e)
        {
            Console.WriteLine($"Error: {e.Message}");
        }
    }
}
```

**Node.js Example**

In Node.js, you can use the built-in `net` module to create a TCP connection to the CloudBox and interact with it.

```javascript
javascriptCopy codeconst net = require('net');

// CloudBox IP and port
const HOST = '192.168.1.10';
const PORT = 8080;

// Create a socket connection to CloudBox
const client = new net.Socket();

client.connect(PORT, HOST, () => {
    console.log(`Connected to CloudBox at ${HOST}:${PORT}`);
    
    // Example of sending a command (e.g., GETSYSTEMSTATUS)
    const command = "GETSYSTEMSTATUS\r\n";
    client.write(command);  // Send the command to the CloudBox
});

// Receive response from CloudBox
client.on('data', (data) => {
    console.log(`Received: ${data}`);
});

// Handle connection close
client.on('close', () => {
    console.log('Connection closed');
});

// Handle errors
client.on('error', (err) => {
    console.error(`Error: ${err.message}`);
});
```

### **Step 3: Send Protocol Commands**

Once the connection is established, you can begin sending protocol commands to the CloudBox as needed. For example, you could send:

* `START` to initiate the timing session.
* `GETSYSTEMSTATUS` to check the current system status.
* `SETSYSTEMTIME` to set the system’s time.

Make sure to follow the correct command syntax as defined in the protocol (e.g., sending commands followed by `\r\n` to denote the end of the message).

### **Step 4: Receive Responses**

After sending each command, the CloudBox will respond with the relevant information, such as a status message or the result of the command. The responses are typically in plain text or JSON format, depending on the command you sent.

### **Step 5: Closing the Connection**

Once you have finished interacting with the CloudBox, it’s important to close the TCP socket connection to free up resources. If you're using a manual connection via a tool like netcat, you can close it by typing `CTRL + C` or using the `exit` command.

In programming environments (e.g., Python), the connection will automatically close when you exit the code block or can be manually closed using `socket.close()` if you're managing the connection manually

### Conclusion

Connecting to the **RUFUS CloudBox** via TCP socket is a straightforward process, and it allows you to interact with the system in real time to manage timing operations, retrieve system statuses, and configure settings. Just ensure that you are on the same network, the IP address and port are correct, and your firewall is configured to allow the connection. Once connected, you can control the system and retrieve essential data for race timing operations.


# Protocol Commands and Responses

The **CloudBox Protocol** is a set of commands and responses designed to control, configure, and monitor the CloudBox timing system. These commands allow you to manage timing sessions, configure system settings, check system statuses, and perform various network functions. Below is a detailed explanation of all the commands, including their possible responses and error codes.

## Protocol Command Format

When sending commands to the CloudBox via TCP socket, the commands must always be sent as **plain text** in a specific format. The general structure of the command follows these rules:

1. **Command Name**: The first part of the command is the name of the action you want to perform (e.g., `CHANGESYSTEMIPADDRESS`).
2. **Arguments**: Any required or optional arguments must be passed **in order**, separated by **semicolons (`;`)**.
3. **Termination**: Each command must be terminated with the characters `\r` (carriage return and newline) to signal the end of the command.

**Command Format Example**

For example, when sending the `CHANGESYSTEMIPADDRESS` command with the required arguments for IP address, port, and subnet, the format would be:

```plaintext
CHANGESYSTEMIPADDRESS;192.168.1.100;8080;/24\r\n
```

In this example:

* `CHANGESYSTEMIPADDRESS`: The name of the command.
* `192.168.1.100`: The new IP address to assign to the system.
* `8080`: The new port to assign.
* `/24`: The subnet mask.
* `\r`: Marks the end of the command.

## Protocol Response Format

In the CloudBox protocol, the responses to commands are always structured in a **JSON format**, following a consistent pattern. Each response contains two main keys:

1. **command**: This key specifies the command that was sent to the CloudBox. It confirms what action or query was requested.
2. **result**: This key contains the actual result or data returned by the system based on the command executed.

Here is an example of a typical response for the `GETSYSTEMTIME` command:

```json
{
    "command": "GETSYSTEMTIME",
    "result": {
        "dateTimeSync": "NTP",
        "timezone": "Europe/Madrid (CEST, +0200)",
        "timestamp": "2024-09-17;18:44:11.649"
    }
}
```

## Key Commands and Responses

### **1. START**

Initiates the start of the timing session.

**Responses**:

* `START_MODE`: The system is already in timing mode.
* `READERNOTOK`: The RFID reader is not present or functioning correctly.
* `DEVICE_INTEGRITY_FAILED`: The integrity check of the device has failed.
* `INVALIDREADERMODEL`: The configured reader model is not valid.
* `ERRREADER`: General reader error.
* `OK`: The timing session has started successfully.

### **2. STOP**

Stops the current timing session.

**Responses**:

* `READERNOTOK`: The RFID reader is not present or functioning correctly.
* `INVALIDREADERMODEL`: The configured reader model is not valid.
* `ERRREADER`: General reader error.
* `OK`: The session has stopped successfully.

### **3. GETSYSTEMSTATUS**

Returns the current status of the system, including battery level, 4G network connection status, GPS status, and more.

**Response Example**:

```json
{
  "batteryVolts": "25.33",
  "batteryPercentage": "88.27",
  "cpuTemperature": "53.75",
  "hasPower": false,
  "hasInternet": true,
  "startMode": false,
  "sessionPassingCount": 0,
  "lastPassingTimestamp": null,
  "operator4G": null,
  "signal4G": null,
  "networkService4G": null,
  "status4G": {"status": "CME_ERROR", "message": "SIM not inserted"},
  "statusGps": {"status": "SEARCHING", "message": "No GPS data found. Searching..."},
  "statusIoT": {"status": true, "message": "Connected to IoT server"},
  "backupDownloadLink": "http://192.168.0.3:2999/download",
  "sessionToken": null,
  "cloudPassingCount": 0,
  "deviceIntegrity": "Device integrity check passed",
  "readerStatus": "RFID Reader not found",
  "updateInfo": null,
  "currentBackendVersion": "1.0.4",
  "currentFrontVersion": "1.0.4"
}
```

### **4. GETSYSTEMCONFIG**

Fetches the current system configuration, including network settings, reader configuration, and system parameters.

**Response Example**:

```json
{
  "bounceTime": 1,
  "buzzerPassings": false,
  "readerModel": "R420",
  "readerHost": "10.0.0.2",
  "readerPort": "5084",
  "tcpHost": "192.168.0.3",
  "tcpSubnet": "/8",
  "tcpPort": "8080",
  "apName": "CLBX_192_168_0_3",
  "wifiSsid": "MOVISTAR_91DA",
  "disableStartButton": false,
  "dateTimeSync": "NTP",
  "timezone": "America/Argentina/Buenos_Aires",
  "simPin": "4509",
  "modemImei": "862636053313696",
  "deviceSerialNumber": "CLBX10001"
}
```

### **5. SETSYSTEMTIME;timestamp**

Sets the system time. The format is `YYYY-MM-DD HH:mm:ss`.

**Responses**:

* `BAD_FORMAT`: The date or time format is incorrect.
* `START_MODE`: The system is in timing mode and the command cannot be executed.
* `NTPACTIVE`: NTP synchronization is active, and manual time changes are disabled.
* `CMDERROR`: General command error.
* `OK`: The system time has been set successfully.

### **6. GETSYSTEMTIME**

Returns the current system time, time zone, and synchronization settings.

**Response Example**:

```json
{
  "dateTimeSync": "NTP",
  "timezone": "Europe/Madrid (CEST, +0200)",
  "timestamp": "2024-09-17;18:44:11.649"   
}
```

### **7. SETDATETIMESYNC;syncMode**

Sets the date and time synchronization mode. Available options are: `"DISABLED"`, `"GPS"`, `"NTP"`.

**Responses**:

* `START_MODE`: The system is in timing mode and the command cannot be executed.
* `SYNCNOTAVAILABLE`: The selected synchronization mode is not available.
* `OK`: The synchronization mode has been successfully set.

### **8. CHANGESYSTEMIPADDRESS;ip;port;subnet**

Changes the system's IP address, port, and subnet mask.

**Responses**:

* `START_MODE`: The system is in timing mode and the command cannot be executed.
* `INVALIDNETWORKCONFIGURATION`: The provided network configuration is invalid.
* `INVALIDNETWORKSUBNET`: The subnet mask is invalid.
* `RESERVEDIPADDRESS`: The IP address is reserved.
* `STDERROR`: General application error.
* `OK`: Success. The system will restart to apply the new configuration.

### **9. SETBUZZERPASSINGS;value**

Enables or disables the buzzer for passing detections (true/false).

**Response**:

* `OK`: The buzzer setting has been successfully updated.

### **10. SETBOUNCETIME;seconds**

Sets the bounce time between RFID reads. If seconds is `null` or <= 0, the default value is 5 seconds.

**Response**:

* `OK`: The bounce time has been successfully set.

### **11. SHUTDOWN**

Shuts down the system after 10-15 seconds.

**Responses**:

* `START_MODE`: The system is in timing mode and the command cannot be executed.
* `OK`: The system will shut down.

### **12. LISTBACKUPFILES**

Returns a list of available backup files. Example: `["20240712-135902.txt"]`

**Responses**:

* `ERROR`: Failed to retrieve the backup files.
* `OK`: Successfully retrieved the list of files.

### **13. DELETEBACKUPFILES**

Deletes all backup files from the system.

**Responses**:

* `START_MODE`: The system is in timing mode and the command cannot be executed.
* `ERROR`: Failed to delete the files.
* `OK`: The backup files have been successfully deleted.

### **14. REWIND;startTimestamp;endTimestamp**

Rewinds the passing data between the specified start and end timestamps (`YYYY-MM-DD HH:mm:ss`) and streams it to connected TCP clients.

**Response**:

* `OK`: The passing data is being streamed.

### **15. GETGPSINFO**

Returns the GPS information, including latitude, longitude, altitude, and last synchronization time.

**Response Example**:

```json
{
  "latitudeDecimal": 41.28425,
  "longitudeDecimal": 1.98251,
  "googleMapsLink": "https://www.google.com/maps/place/41.28425,1.98251",
  "gpsTimezone": "Europe/Madrid",
  "altitude": 38.7,
  "speed": 0,
  "lastSync": "2024-07-24 20:27:02"
}
```


# Receiving Timing Data Passings During a Session

Once a **timing session** is started by sending the `START` command to the CloudBox, the TCP connection must remain open to continuously receive real-time streams of timing data, known as **passings**. Each passing represents an instance of an RFID tag being detected by the system, and contains important information about the athlete or object that triggered the RFID read.

The **passing data** is sent to the connected client in JSON format, with the following structure:

```json
{
  "epc": "EPC_CODE_HERE",
  "timestamp": "2024-09-17;14:34:23.123Z",
  "seenCount": 3,
  "antenna": 1,
  "rssi": -65,
  "passingNumber": 145,
  "tagStr": "TAG_STRING",
  "latitude": 41.28425,
  "longitude": 1.98251,
  "chksum": "CHECKSUM_HERE"
}
```

## **Key Elements of a Passing**

1. **epc** (Electronic Product Code)(\*):

   This is the unique identifier of the RFID tag that was detected. The EPC helps identify which specific tag was read during the session.
2. **timestamp**:

   The exact time the passing was recorded, provided in ISO 8601 format (`YYYY-MM-DDTHH:mm:ss.sssZ`). This allows precise tracking of the moment the tag was detected.
3. **seenCount** (\*):

   The number of times this tag has been detected within the same reading cycle. This value can help with determining the proximity or quality of the tag read.
4. **antenna** (\*):

   Identifies which antenna detected the tag. In systems with multiple antennas, this helps to determine which part of the course or checkpoint the passing occurred at.
5. **rssi** (\*):

   The **Received Signal Strength Indicator (RSSI)** measures the strength of the signal received from the RFID tag. This value can help with determining the proximity or quality of the tag read.
6. **passingNumber**:

   A sequential number that increments with each passing, providing a unique identifier for each passing event during the timing session.
7. **tagStr** (\*):

   A string representation of the tag extracted from the `epc` code. Data available when reading RUFUS encoded tags.
8. **latitude** (\*):

   The latitude coordinates from the GPS device (if available). This value can help track the exact location of the passing on a global map.
9. **longitude** (\*):

   The longitude coordinates from the GPS device (if available). This value, along with latitude, provides the geographic location of the passing.
10. **chksum**:\
    The checksum is used for verifying data integrity, ensuring the passing data was transmitted correctly without errors.

*(\*) Information may not be available depending on RFID reader installed or CloudBox configuration. Keys will always be present and if no data is available, the value will be null.*

## Handling the Passing Data

Once the `START` command is issued and the session is active, passings are sent over the **same open TCP connection** to the connected clients. Each passing is transmitted as a separate JSON object, similar to the example provided above. The passings continue to stream in real-time as athletes or objects with RFID tags pass through the detection antennas.

The format of each passing is consistent, allowing the receiving system to parse and process the data for timing, classification, and tracking purposes.

The client application needs to handle the continuous stream of passings by parsing the incoming data, processing it, and storing it as needed. Below are examples in Python, C#, and Node.js to handle incoming passings.

#### **Python Example**

```python
import json

HOST = '192.168.1.10'
PORT = 8080

with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as s:
    s.connect((HOST, PORT))
    s.sendall("START\r\n".encode('utf-8'))  # Start the timing session
    
    while True:
        data = s.recv(1024)
        if data:
            passing = json.loads(data.decode('utf-8'))
            print(f"Passing received: {passing}")
            # Process the passing data here (e.g., save to database, analyze, etc.)
```

#### **C# Example**

```csharp
using System;
using System.Net.Sockets;
using System.Text;
using Newtonsoft.Json.Linq; // Install via NuGet

class Program
{
    static void Main(string[] args)
    {
        string host = "192.168.1.10";
        int port = 8080;

        try
        {
            TcpClient client = new TcpClient(host, port);
            NetworkStream stream = client.GetStream();

            byte[] startCommand = Encoding.ASCII.GetBytes("START\r\n");
            stream.Write(startCommand, 0, startCommand.Length);

            byte[] buffer = new byte[1024];
            while (true)
            {
                int bytesRead = stream.Read(buffer, 0, buffer.Length);
                if (bytesRead > 0)
                {
                    string passingData = Encoding.ASCII.GetString(buffer, 0, bytesRead);
                    JObject passing = JObject.Parse(passingData);
                    Console.WriteLine($"Passing received: {passing}");
                    // Process the passing data (e.g., save to database, analyze, etc.)
                }
            }

            stream.Close();
            client.Close();
        }
        catch (Exception e)
        {
            Console.WriteLine($"Error: {e.Message}");
        }
    }
}
```

**Node.js Example**

```javascript
const net = require('net');

// CloudBox IP and port
const HOST = '192.168.1.10';
const PORT = 8080;

// Create a socket connection to CloudBox
const client = new net.Socket();

client.connect(PORT, HOST, () => {
    console.log(`Connected to CloudBox at ${HOST}:${PORT}`);
    
    // Send the START command to initiate timing session
    client.write("START\r\n");
});

// Receive and process passings
client.on('data', (data) => {
    const passing = JSON.parse(data.toString());
    console.log(`Passing received: ${JSON.stringify(passing)}`);
    // Process the passing data (e.g., save to database, analyze, etc.)
});

// Handle connection close
client.on('close', () => {
    console.log('Connection closed');
});

// Handle errors
client.on('error', (err) => {
    console.error(`Error: ${err.message}`);
});
```

## Conclusion

Once a timing session is started, the CloudBox sends streams of passings over the open TCP connection in real-time, each containing vital RFID detection data. You can handle these passings in Python, C#, or Node.js, depending on your application’s needs. The passings can then be processed for storage, analysis, and race timing operations.


# Connecting to the CloudBox: LAN, WiFi, and 4G Overview

The **CloudBox** offers three primary ways to connect—**LAN (Ethernet)**, **WiFi Access Point**, and **4G**—to suit various race timing needs and event environments. Each method provides different benefits and considerations for setup. This article will explain the pros and cons of each connection type, and what considerations to have.

## 1. Connecting via LAN (Ethernet)

**LAN (Ethernet)** provides a reliable, wired connection to the CloudBox. The CloudBox always has a **fixed IP address** in the Ethernet port, which can be configured by the user to fit the local network.

### **Pros:**

* **High Stability and Reliability**: Ethernet connections are highly stable, offering dependable data transfer without interference.
* **Fast and Secure**: Provides fast data transfer speeds and is more secure than wireless connections.
* **Fixed IP**: The CloudBox uses a configurable fixed IP address, ensuring consistency in network setup.

### **Cons:**

* **Limited Mobility**: The need for a physical connection limits placement flexibility, especially in outdoor events.
* **Cable Management**: Ethernet requires careful cable placement and management.

### **Considerations for Ethernet Connection:**

* **Fixed IP Address**: The CloudBox comes with a fixed IP address in the Ethernet port, which can be customized by the user. Ensure that devices on the same network have IP addresses within the same subnet.
* **Subnet Mask**: Configure the correct subnet mask (e.g., `255.255.255.0`) to allow communication within the network.

### **Configuring IPv4 for Ethernet in Windows:**

1. **Open Network Settings**:
   * Press `Windows + X` and select **Network Connections**.
   * Right-click on your **Ethernet** adapter and select **Properties**.
2. **Configure IPv4**:
   * Select **Internet Protocol Version 4 (TCP/IPv4)** and click **Properties**.
   * To use DHCP, choose **Obtain an IP address automatically**.
   * To set a static IP, choose **Use the following IP address** and input:
     * **IP Address**: E.g., `192.168.1.100` (in the same range as the CloudBox’s IP).
     * **Subnet Mask**: E.g., `255.255.255.0`.
     * **Default Gateway**: Usually your router’s IP (e.g., `192.168.1.1`).
   * Click **OK** to save the settings.

## 2. Connecting via WiFi Access Point

The CloudBox creates a **WiFi Access Point**, allowing devices to connect wirelessly without the need for an external network. The CloudBox’s SSID follows the format `CLBX_{IP_ADDRESS}` (e.g., `CLBX_192_168_1_10`), where the IP address reflects the CloudBox’s current Ethernet/TCP socket address. This access point name changes dynamically when the CloudBox’s IP address is updated, effectively acting as a beacon indicating its current IP.

When connected with the Access Point, the CloudBox has the fixed IP **192.168.4.2**, and devices connecting to the WiFi access point receive IP addresses in the **192.168.4.x** range. Additionally, the **WiFi Access Point and Ethernet port are bridged**, meaning users connected to the WiFi can still access the CloudBox via its Ethernet IP address for TCP connections.

### **Pros:**

* **Wireless Convenience**: No need for physical cables, allowing flexible setup in a range of environments.
* **Quick Setup**: No need for external routers or network infrastructure, just connect directly to the CloudBox’s WiFi network.

### **Cons:**

* **Limited Range**: The range of the WiFi Access Point is limited compared to external routers, meaning devices need to be close to the CloudBox.
* **Interference**: WiFi can be affected by other wireless devices or environmental factors.

### **Considerations for WiFi Access Point Connection:**

* **Fixed IP Address (192.168.4.2)**: Devices connecting to the WiFi Access Point are assigned IPs in the **192.168.4.x** range, while still being able to access the Ethernet IP address.
* **Bridged Connection**: The Ethernet port and WiFi access point are bridged, allowing seamless access to the CloudBox’s TCP services regardless of the connection method.

### **Configuring IPv4 for WiFi in Windows:**

1. **Open Network Settings**:
   * Press `Windows + X` and select **Network Connections**.
   * Right-click on your **WiFi** adapter and select **Properties**.
2. **Configure IPv4**:
   * Select **Internet Protocol Version 4 (TCP/IPv4)** and click **Properties**.
   * For dynamic IP addressing (DHCP), choose **Obtain an IP address automatically**.
   * For a static IP, choose **Use the following IP address** and input:
     * **IP Address**: E.g., `192.168.4.100` (within the same range as the CloudBox).
     * **Subnet Mask**: `255.255.255.0`.
     * **Default Gateway**: Typically set to `192.168.4.2` (the CloudBox’s fixed IP).
   * Click **OK** to apply the changes.

## 3. Connecting via 4G

The CloudBox supports **4G connectivity**, allowing it to connect to the internet over cellular networks. When connected via 4G, the CloudBox shares its internet connection with devices connected to its **WiFi Access Point**.

### **Pros:**

* **No Local Network Needed**: Ideal for remote or outdoor locations where Ethernet or WiFi infrastructure isn’t available.
* **Mobile Connectivity**: Works anywhere there’s 2G/3G/4G coverage, making it highly versatile.
* **Internet Sharing**: Devices connected to the CloudBox’s WiFi Access Point can access the internet through the CloudBox’s 4G connection.

### **Cons:**

* **Signal Dependency**: The connection depends on 4G signal strength, which can vary by location.
* **Data Costs**: Cellular data usage can be expensive, especially with large volumes of data.
* **Lower Bandwidth**: 4G networks may offer lower bandwidth compared to Ethernet or WiFi, especially in congested areas.

### **Considerations for 4G Connection:**

* **SIM Card**: Insert a compatible 4G SIM card with an active data plan.
* **Internet Sharing**: When connected via 4G, devices connected to the WiFi Access Point will have internet access through the CloudBox.

## Summary

The CloudBox offers flexible connection options, including **Ethernet**, **WiFi Access Point**, and **4G**, to meet different event needs:

* **Ethernet** provides a stable and fast connection with a configurable fixed IP.
* **WiFi Access Point** allows wireless connections, with the SSID dynamically reflecting the CloudBox’s current IP address and the ability to access the Ethernet IP through a bridged connection.
* **4G** is ideal for remote locations, providing mobile internet connectivity that can be shared with devices connected to the CloudBox’s WiFi.

Ensure proper configuration of **IP addresses**, **subnet masks**, and **gateways** for each method.&#x20;


# Connecting the CloudBox via Ethernet Cable

Connecting the **RUFUS CloudBox** via **Ethernet** provides the most stable and secure method for managing timing data, especially in large events where reliability and speed are essential. This article walks you through the key considerations, steps to establish a connection, and how to troubleshoot connectivity issues. We’ll assume the CloudBox’s **fixed IP address** is set to **192.168.1.10**.

## Key Considerations Before Connecting

1. **Network Configuration**:
   * Ensure that your computer or device is on the same network as the CloudBox. This means the IP address of your device should be within the same range (e.g., `192.168.1.x`).
   * Check that your device’s **subnet mask** is configured correctly (e.g., `255.255.255.0`) to ensure communication within the same network.
2. **Firewall and Antivirus Software**:
   * Firewalls and antivirus software may block the TCP socket connection to the CloudBox. Ensure that the **firewall** allows traffic on the **CloudBox’s IP address** (`192.168.1.10`) and that no antivirus program is preventing communication.
   * For testing, you may want to temporarily disable firewalls or antivirus software to confirm whether they are causing any connection issues.
3. **Ethernet Cable and Port**:
   * Use a high-quality **Ethernet cable** to physically connect the CloudBox to your network router or switch. Check that the Ethernet port on both the CloudBox and the connecting device is functioning correctly.

## Steps to Connect the CloudBox via Ethernet

### **1. Connect the CloudBox to Your Network**

* **Step 1**: Plug one end of the Ethernet cable into the **Ethernet port** on the CloudBox.
* **Step 2**: Connect the other end of the cable to your **network router,** **switch** or **PC**.

The CloudBox will now be part of your network, using the **fixed IP address** you’ve configured (in this case, `192.168.1.10`).

### **2. Configure Your Computer’s Network Settings**

To ensure that your computer can communicate with the CloudBox, you need to configure its network settings to be on the same subnet.

* **Step 1**: Open **Network Settings** in Windows.
  * Press `Windows + X`, and select **Network Connections**.
  * Right-click on your **Ethernet** adapter, and select **Properties**.
* **Step 2**: Select **Internet Protocol Version 4 (TCP/IPv4)**, and click **Properties**.
* **Step 3**: Configure your IPv4 settings:
  * Choose **Use the following IP address**, and input:
    * **IP Address**: Set an address in the same range as the CloudBox, e.g., `192.168.1.50`.
    * **Subnet Mask**: `255.255.255.0`.
    * **Default Gateway**: Set this to the IP address of your router or leave it blank if you're not routing traffic beyond your local network.
* **Step 4**: Click **OK** to save the settings.

## Testing the Connection

Once connected, it’s important to test that your computer can communicate with the CloudBox. The easiest way to verify the connection is by using the **ping** command.

### **Step-by-Step Ping Test**

1. **Open the Command Prompt**:
   * Press `Windows + R`, type **cmd**, and press **Enter**.
2. **Ping the CloudBox**:

   * In the command prompt, type:

     ```bash
     ping 192.168.1.10
     ```
   * Press **Enter**. If the CloudBox is properly connected, you should see replies from `192.168.1.10`, confirming that the connection is working.

   Example output:

   ```bash
   Pinging 192.168.1.10 with 32 bytes of data:
   Reply from 192.168.1.10: bytes=32 time<1ms TTL=64
   Reply from 192.168.1.10: bytes=32 time<1ms TTL=64
   ```

   If you receive replies like the above, your CloudBox is successfully connected and communicating over Ethernet.

**Troubleshooting Ping Failures**

If the ping fails (e.g., you receive **Request Timed Out** errors):

* **Check Cables**: Ensure the Ethernet cable is properly connected to both the CloudBox and your router or switch.
* **Verify IP Configuration**: Confirm that your computer’s IP address is on the same subnet as the CloudBox (e.g., `192.168.1.x`).
* **Disable Firewall/Antivirus**: Temporarily disable any firewalls or antivirus programs that may be blocking the connection.

## Summary

Connecting the CloudBox via **Ethernet** offers a stable, secure connection ideal for high-performance timing events. By following the steps above, you can easily connect and verify communication between your computer and the CloudBox. Be sure to configure your IP settings correctly, ensure there are no firewalls blocking the connection, and perform a simple **ping test** to confirm successful communication.

If you experience connection issues, check your network configuration and cables, and ensure no security software is preventing access.


# Connecting the CloudBox via WiFi Access Point

The **RUFUS CloudBox** can create a **WiFi Access Point**, allowing you to connect wirelessly without needing any external network infrastructure like routers or switches. This method is ideal for quick setups and flexible environments. The access point’s SSID follows the format `CLBX_{IP_ADDRESS}` (e.g., `CLBX_192_168_1_10`), where the IP address reflects the CloudBox’s current TCP socket address. When in WiFi Access Point mode, the CloudBox has a fixed IP address of **192.168.4.2** and dynamically assigns IP addresses to devices through **DHCP**.

The default password for the **WiFi Access Point** is: **changeme**

In this article, we’ll go over key considerations, connection steps, and troubleshooting methods, as well as how to test the connection between your device and the CloudBox.

## Key Considerations Before Connecting

1. **WiFi Range and Interference**:
   * Ensure that the device you’re connecting is within the **WiFi range** of the CloudBox. Physical obstacles (walls, metal objects) or interference from other wireless devices can reduce the signal quality.
2. **Bridged Access Point and Ethernet**:
   * In Access Point mode, the WiFi access point and Ethernet port on the CloudBox are **bridged**. Even if your device is connected to the WiFi network and assigned an IP in the range of `192.168.4.x`, you will still be able to access the CloudBox’s Ethernet IP address for **TCP socket connections**.
3. **Firewall and Antivirus**:
   * Ensure that any **firewall** or **antivirus software** on your computer or device does not block connections to the CloudBox’s IP address (`192.168.4.2`). You may need to temporarily disable such software for testing purposes.

## Steps to Connect to the CloudBox via WiFi Access Point

### **1. Locate and Connect to the CloudBox’s Access Point**

* **Step 1**: Power on the CloudBox and allow it to generate the WiFi access point. The SSID of the network will follow the format `CLBX_{IP_ADDRESS}` (e.g., `CLBX_192_168_1_10`), where the IP address reflects the CloudBox’s current configuration.
* **Step 2**: Open your computer or device’s WiFi settings and look for the CloudBox’s SSID (e.g., `CLBX_192_168_1_10`).
* **Step 3**: Connect to the WiFi network. You may be prompted to enter a password, depending on your CloudBox’s security configuration.

### **2. Ensure Your Device is Set to DHCP (Automatic IP Assignment)**

The CloudBox’s WiFi Access Point automatically assigns IP addresses to connected devices using **DHCP**. To avoid connection issues, ensure your device is set to obtain an IP address automatically.

* **Step 1**: Open **Network Settings** in Windows.
  * Press `Windows + X`, and select **Network Connections**.
  * Right-click on your **WiFi** adapter, and select **Properties**.
* **Step 2**: Select **Internet Protocol Version 4 (TCP/IPv4)**, and click **Properties**.
* **Step 3**: Ensure **Obtain an IP address automatically** is selected. This will allow the CloudBox to automatically assign an IP address to your device within the **192.168.4.x** range.
* **Step 4**: Click **OK** to save the settings.

## Testing the Connection

After connecting, it’s important to test the connection to verify communication between your device and the CloudBox. The easiest way to do this is by using the **ping** command.

### **Step-by-Step Ping Test**

1. **Open the Command Prompt**:
   * Press `Windows + R`, type **cmd**, and press **Enter**.
2. **Ping the CloudBox**:

   * In the command prompt, type:

     ```bash
     ping 192.168.4.2
     ```
   * Press **Enter**. If the CloudBox is properly connected, you should see replies from `192.168.4.2`, confirming the connection.

   Example output:

   ```bash
   bPinging 192.168.4.2 with 32 bytes of data:
   Reply from 192.168.4.2: bytes=32 time<1ms TTL=64
   Reply from 192.168.4.2: bytes=32 time<1ms TTL=64
   ```

   If the ping is successful, your connection is established and working.

**Troubleshooting Ping Failures**

If the ping test fails (e.g., you receive **Request Timed Out** messages):

* **Check WiFi Connection**: Ensure you’re connected to the correct WiFi network (`CLBX_{IP_ADDRESS}`) and have an IP address in the **192.168.4.x** range.
* **Verify DHCP Settings**: Ensure that your device is set to **Obtain an IP address automatically**.
* **Disable Firewall/Antivirus**: Temporarily disable any firewalls or antivirus programs that may be blocking the connection.

## Summary

Connecting the CloudBox via **WiFi Access Point** is a simple and flexible way to set up communication between your device and the CloudBox. The CloudBox generates a WiFi network with an SSID that reflects its current IP address, making it easy to identify and connect to. Once connected, your device will automatically be assigned an IP address in the **192.168.4.x** range through DHCP, and the CloudBox will have a fixed IP of **192.168.4.2**.

The bridged connection between the WiFi access point and the Ethernet port allows seamless access to the CloudBox’s services, whether you're connected via WiFi or Ethernet. Make sure to check for firewalls or antivirus software that might block the connection, and perform a simple **ping test** to verify communication.


# Connecting the CloudBox to an External WiFi Network

The **RUFUS CloudBox** can connect to an external WiFi network, allowing it to access the internet through a router or hotspot. This connection method enables the CloudBox to integrate with other devices connected to the same WiFi network, provided they are within the same IP range. When connected, the CloudBox can communicate with devices on the network, send timing data, and access internet-based services if needed.

This article outlines the key considerations, steps for connecting to an external WiFi network, and how to verify the connection.

## Key Considerations Before Connecting

1. **WiFi Signal and Range**:
   * Ensure that the CloudBox is within range of the external WiFi network you are connecting to. Signal strength can be affected by distance, walls, or other obstacles.
2. **Same IP Range**:
   * The CloudBox and any device wishing to communicate with it must be on the **same IP range** (i.e., same subnet). For example, if your router assigns IP addresses in the range of `192.168.1.x`, the CloudBox should also be assigned an IP in that range.
3. **Network Security**:
   * Ensure that the WiFi network credentials (SSID and password) are available, and the network security (e.g., WPA2) is compatible with the CloudBox.
4. **Firewall and Antivirus**:
   * Ensure that firewalls or antivirus software on your computer or other devices are not blocking communication with the CloudBox. You may need to temporarily disable them for testing purposes.

## Steps to Connect the CloudBox to an External WiFi Network

### **1. Configure the CloudBox to Connect to the WiFi Network**

To connect the CloudBox to an external WiFi network, you'll need to provide the network’s SSID (network name) and password.

* **Step 1**: Access the CloudBox’s configuration interface (this can typically be done through the Ethernet connection or WiFi Access Point).
* **Step 2**: Enter the WiFi network details:
  * **SSID**: The name of the external WiFi network.
  * **Password**: The password for the WiFi network.

Once entered, the CloudBox will attempt to connect to the WiFi network.

**2. Ensure the CloudBox and Devices are on the Same IP Range**

Once the CloudBox is connected to the external WiFi network, it will receive an IP address from the router’s DHCP server. For your devices to communicate with the CloudBox, ensure that:

* The CloudBox and your devices are in the **same IP range**.
  * Example: If the router assigns an IP to the CloudBox in the range `192.168.1.x`, your devices must also have IP addresses in the same range (e.g., `192.168.1.50` and `192.168.1.100`).

## Testing the Connection

After connecting the CloudBox to the external WiFi network, it’s essential to test the connection to ensure proper communication.

### **Step-by-Step Ping Test**

1. **Determine the CloudBox’s IP Address**:
   * Find your CloudBox assigned IP address in the status interface.
2. **Ping the CloudBox**:
   * On a device connected to the same WiFi network, open the command prompt by pressing `Windows + R`, typing **cmd**, and pressing **Enter**.
   * Ping the CloudBox using its assigned IP address (e.g., `192.168.1.10`):

     ```bash
     ping 192.168.1.10
     ```
3. **Check the Ping Results**:
   * If the CloudBox is connected properly, you should see successful replies:

     ```bash
     Pinging 192.168.1.10 with 32 bytes of data:
     Reply from 192.168.1.10: bytes=32 time<1ms TTL=64
     Reply from 192.168.1.10: bytes=32 time<1ms TTL=64
     ```

**Troubleshooting Ping Failures**

If the ping fails:

* **Check Network Configuration**: Ensure that the CloudBox and your device are on the same IP range.
* **Check Router Settings**: Ensure the router isn’t blocking communication between devices on the network (some routers may have guest networks or isolation modes that prevent device-to-device communication).
* **Disable Firewall/Antivirus**: Temporarily disable any firewall or antivirus software that could be blocking the connection.

## Additional Benefits of Connecting to an External WiFi Network

When the CloudBox is connected to an external WiFi network, several advantages come into play:

* **Internet Access**: The CloudBox gains internet access through the WiFi network, which can be used for cloud-based timing data uploads or software updates.
* **LAN Communication**: Devices connected to the same WiFi network (such as timing laptops, tablets, or other monitoring systems) can communicate directly with the CloudBox, facilitating real-time data sharing.
* **Extended Range**: Using an external WiFi network with a powerful router or access points can significantly extend the communication range, compared to the CloudBox’s internal WiFi Access Point.

## Summary

Connecting the CloudBox to an **external WiFi network** provides internet connectivity and allows the CloudBox to integrate with other devices on the same network. The most critical aspect is ensuring that the CloudBox and all devices are on the same **IP range**, allowing them to communicate seamlessly.

Make sure to have the network credentials ready, verify the IP range, and perform a **ping test** to ensure connectivity. With this setup, you can take advantage of internet access, real-time communication, and extended range for more complex event configurations.


# Connecting Two or More CloudBox in the Same Network via a Hub or Router

When connecting two or more **CloudBox** in the same network using a hub, switch, or router, several important considerations must be taken into account to ensure seamless communication and avoid network conflicts. This setup is often used for large events where multiple timing points or separate CloudBox are needed to cover different areas of the event.

## Key Considerations for Connecting Multiple CloudBox

1. **Unique IP Addresses**:
   * Each CloudBox must have a **unique IP address** on the network to avoid conflicts. Ensure that each CloudBox has a different IP (e.g., `192.168.1.10` for the first CloudBox, `192.168.1.11` for the second, and so on).
2. **Same Subnet**:
   * All CloudBox devices and the timing computers or other devices on the network must be in the same **IP range** and **subnet**. For example, if your router assigns IPs in the `192.168.1.x` range, all devices should follow this format.
   * The **subnet mask** (usually `255.255.255.0`) must be the same across devices to ensure proper communication.
3. **Router or Switch Capacity**:
   * Ensure that the router, switch, or hub has enough ports and bandwidth to handle all connected CloudBox units and any other connected devices (e.g., timing computers, backup systems). The switch or router should support simultaneous data transmission to avoid slowdowns.
4. **Firewall and Security Settings**:
   * Verify that firewall settings on your network do not block communication between devices. Some routers isolate devices by default, so you may need to adjust these settings.
   * Temporarily disable antivirus or firewall programs on timing computers while troubleshooting, to ensure they are not blocking connections between CloudBox devices.

## Testing the Network

After connecting multiple CloudBox units to a hub or router, it is important to test the network to ensure everything is working correctly:

### **1. Ping Each CloudBox:**

* Determine the IP addresses of each CloudBox by checking your router’s device list or accessing each CloudBox’s configuration.
* Open the **Command Prompt** on a device connected to the same network and ping each CloudBox:

  ```bash
  ping 192.168.1.10  # First CloudBox
  ping 192.168.1.11  # Second CloudBox
  ```

You should see replies from each IP if the connections are successful.

### **2. Check Router Settings:**

* Access your router’s management interface and ensure that all CloudBox devices are listed with unique IP addresses. Confirm that there are no IP conflicts or issues with the devices dropping from the network.

## Benefits of Connecting Multiple CloudBox in the Same Network

* **Expanded Coverage**: Multiple CloudBox units can cover different areas of an event, such as the start line, intermediate checkpoints, and the finish line, enhancing event coverage.
* **Centralized Management**: Connecting all CloudBox units to the same network allows for centralized monitoring and management of timing data.
* **Real-Time Data**: With all CloudBox devices in the same network, data can be synchronized and accessed in real-time across the event.

## Summary

Connecting multiple CloudBox devices in the same network via a hub or router requires careful attention to **IP address uniqueness** and **subnet configuration**. Ensure that your network infrastructure can handle the bandwidth and that security settings do not block device communication. Testing the setup through ping commands and monitoring router logs will help ensure a smooth and reliable network connection.

This setup allows for efficient management of large events, with multiple CloudBox units working together to provide comprehensive timing and tracking coverage.


# Connecting the CloudBox to a 4G Network

The **RUFUS CloudBox** supports **4G connectivity** via a built-in **SIM7600G-H 4G HAT**, which enables internet and **Cloud** access using a cellular network. This is ideal for events where traditional Ethernet or WiFi infrastructure is unavailable or impractical. The CloudBox has a **SIM card slot** and allows users to configure the **SIM PIN** if required. Once connected to the 4G network, the CloudBox can share the internet connection with devices connected to its **WiFi Access Point** or through its **Ethernet port**.

This article explains the key considerations, steps for connecting to a 4G network, and how to verify the connection.

## Key Considerations Before Connecting

1. **SIM Card and Cellular Network**:
   * Insert a **2FF Mini SIM card** (25 x 15 x 0.76 mm) with an active data plan into the SIM slot.
   * The CloudBox supports multiple **LTE bands** for global compatibility, as well as **3G** and **2G** fallback.
   * Ensure that the location has adequate **4G signal strength** from the network provider.
2. **SIM PIN Configuration**:
   * If your SIM card has a **PIN code** enabled, you can configure this on the CloudBox by entering the required SIM PIN in the configuration interface. This ensures that the CloudBox can access the cellular network securely.
3. **GPS and Antenna Setup**:
   * The CloudBox also includes a **GNSS receiver** that supports **GPS, Beidou, GLONASS, Galileo**, and **QZSS**, enhancing location accuracy for mobile use cases.
   * Ensure that both the **LTE main antenna** and **GNSS antenna** are properly connected for optimal connectivity and signal strength.

## Steps to Connect the CloudBox to a 4G Network

### **1. Insert the SIM Card**

* **Step 1**: Power off the CloudBox before inserting the SIM card.
* **Step 2**: Insert the **2FF Mini SIM** card into the SIM slot, ensuring proper orientation.
* **Step 3**: Power on the CloudBox. Once powered up, the CloudBox will attempt to connect to the 4G network.

### **2. Configure the SIM PIN (if required)**

* If your SIM card requires a **PIN**, access the CloudBox configuration interface via **Ethernet** or **WiFi Access Point**.
* Navigate to the **SIM settings** and enter the required PIN for the SIM card to unlock it and enable 4G connectivity. Once the PIN is entered, the CloudBox will reboot.

### **3. Ensure Adequate Signal Strength**

The CloudBox supports a range of LTE and 3G bands (as outlined in the table below), which ensures global compatibility:

| **Cellular & GPS Details** | **Specifications**                                                |
| -------------------------- | ----------------------------------------------------------------- |
| **GNSS Receiver**          | GPS, Beidou, GLONASS, Galileo, QZSS                               |
| **Cellular Protocols**     | LTE CAT-4 4G / 3G / 2G Support, Global Bands                      |
| **LTE Bands**              | LTE-FDD: B1/B2/B3/B4/B5/B7/B8/B12/B13/B18/B19/B20/B25/B26/B28/B66 |
| **Data Rate**              | LTE Cat-4: Up to 150Mbps (Downlink) / 50Mbps (Uplink)             |
| **SIM Card Slot**          | 2FF Mini SIM (25 x 15 x 0.76 mm), Supports 1.8V/3V SIM card       |
| **Antenna Connectors**     | LTE main antenna + GNSS antenna                                   |

Ensure that the LTE antennas are correctly connected to achieve optimal signal reception.

## Internet Sharing and Configuration

Once the CloudBox is connected to the 4G network, it can share the internet connection with devices connected via **WiFi Access Point** or **Ethernet**.

### **WiFi Access Point:**

* Devices connected to the CloudBox’s **WiFi Access Point** will automatically have internet access through the CloudBox’s 4G connection.
* The **CloudBox AP** is available with the fixed IP address **192.168.4.2** and will dynamically assign IP addresses to devices using DHCP.

### **Ethernet:**

* Devices connected to the **Ethernet port** can access the internet through the 4G connection as long as the CloudBox is properly configured to share its 4G connection.

## **Step-by-Step Ping Test**

1. **Determine the CloudBox’s IP Address**:
   * For devices connected to the CloudBox’s WiFi Access Point, the CloudBox has a fixed IP of `192.168.4.2`.
   * For devices connected via Ethernet, check the IP address configuration of the CloudBox.
2. **Ping the CloudBox**:
   * Open the **Command Prompt** and use the ping command:

     ```bash
     ping 192.168.4.2
     ```
3. **Check Ping Results**:
   * If the CloudBox is properly connected to the 4G network, you should receive replies, confirming connectivity.

## **Testing Internet Connectivity:**

Open a web browser on a device connected via WiFi or Ethernet and attempt to load a webpage to confirm that the CloudBox is properly sharing its 4G internet connection.

## Summary

Connecting the CloudBox to a **4G network** provides internet access in areas where traditional wired or WiFi networks are unavailable. By inserting a compatible **2FF Mini SIM card**, configuring the **SIM PIN** (if needed), and ensuring the **LTE antennas** are properly connected, you can leverage 4G connectivity for your timing operations.

Once connected, the CloudBox shares the internet via its **WiFi Access Point** or **Ethernet port**, making it accessible to any device connected to the CloudBox network. Perform connection tests and ensure optimal signal strength to guarantee stable internet access throughout your event.


# Accessing the CloudBox Interface: General Guide

The **CloudBox interface** is a web-based dashboard that allows you to manage and monitor your timing system. This interface is accessible via a web browser, whether you’re connected to the CloudBox over **Ethernet** or **WiFi**. From the dashboard, you can view and control various aspects of the system, including timing data, network settings, and more.

In this article, we’ll walk you through how to access the CloudBox interface and what to consider when using multiple CloudBox devices on the same network.

## Connecting to the CloudBox Interface

To access the CloudBox interface, you can connect either via **Ethernet** or **WiFi**:

**1. Connecting via Ethernet**

* Connect your computer directly to the CloudBox using an Ethernet cable.
* Once connected, open a web browser and navigate to one of the following:
  * **cloudbox.local** (if only one CloudBox is on the network).
  * The **IP address** of the CloudBox (e.g., `http://192.168.1.10`).

**2. Connecting via WiFi Access Point**

* Connect your computer or device to the **WiFi Access Point** generated by the CloudBox (e.g., `CLBX_192_168_1_10`).
* Once connected, open a web browser and navigate to:
  * **cloudbox.local** (for single CloudBox setups).
  * The **IP address** of the CloudBox (e.g., `http://192.168.4.2` if connected to the WiFi Access Point or `http://192.168.1.10`).

## Accessing the Interface When Multiple CloudBox Devices Are in the Same Network

If you are working with multiple CloudBox devices on the same network, accessing the interface becomes more specific. Here’s what you need to consider:

1. **cloudbox.local Conflict**:
   * When multiple CloudBox devices are connected to the same network, the **cloudbox.local** address will no longer uniquely identify a single device. The same hostname will be shared among all connected CloudBox units, causing conflicts in accessing the dashboard.
2. **Mandatory Access via IP Address**:
   * To avoid this conflict, you will need to access each CloudBox by its **IP address** rather than using `cloudbox.local`. Each CloudBox should be configured with a unique IP address, allowing you to distinguish between devices.
   * For example:
     * **CloudBox 1**: `http://192.168.1.10`
     * **CloudBox 2**: `http://192.168.1.11`
     * **CloudBox 3**: `http://192.168.1.12`

## Important Considerations

1. **Unique IP Addresses**:
   * When working with multiple CloudBox devices, ensure each device is configured with a **unique IP address** on the network. This is necessary to avoid IP conflicts and ensure smooth communication across the network.
2. **Firewall/Antivirus Settings**:
   * Make sure that any **firewall** or **antivirus** software on your computer is not blocking access to the CloudBox. Temporarily disabling such software can help in troubleshooting connection issues.
3. **Browser Compatibility**:
   * The CloudBox interface works best with modern web browsers like **Google Chrome**, **Mozilla Firefox**, or **Microsoft Edge**. Ensure your browser is up-to-date for the best performance.

## Summary

To access the **CloudBox interface**, connect via **Ethernet** or **WiFi** and navigate to `cloudbox.local` or the CloudBox’s **IP address** through a web browser. When working with multiple CloudBox devices on the same network, always access the devices through their **unique IP addresses**, as `cloudbox.local` will not differentiate between multiple units.

This interface allows you to configure settings, monitor timing data, and manage network configurations, ensuring you can efficiently control your timing system from a single location.


# Timing Interface

The **Timing Interface** is the heart of the CloudBox system, giving you real-time visibility and control over race timing sessions. Accessible directly from the CloudBox dashboard, it allows you to start, pause, and stop sessions while monitoring the latest tag detections as they happen. The interface is designed to keep you in control of the event with clear indicators, session counters, and detailed passing data.

<figure><img src="/files/Ic2tdPI2LKHCh8Z30aiA" alt=""><figcaption><p>Timing interface</p></figcaption></figure>

## Key Features

### Session Controls

* **Start**: Initiates a new timing session. The CloudBox begins detecting RFID tags and recording passings.
* **Pause**: Temporarily suspends the recording of passings without ending the session. This is useful if you want to stop recording momentarily without creating a new session or backup file.
* **Stop**: Ends the current session. No further passings are recorded until a new session is started.

At the top-right of the interface, the session state is always visible (e.g., *STOPPED*), along with the total number of passings collected.

### Latest Passings Table

The table displays up to the last **1000 passings** detected during the active session, with the most recent at the top. Each row corresponds to a single passing and contains the following data:

* **#**: Sequential number of the passing in the session.
* **tagStr / EPC**: The unique RFID tag identifier (Electronic Product Code or string representation).
* **Timestamp**: Exact time of detection, displayed in `DD/MM/YYYY, HH:mm:ss` format.
* **Seen**: Number of times this tag has been detected in the read cycle.
* **RSSI** *(if provided)*: The signal strength at which the tag was read, expressed in dBm. A stronger signal (closer to 0, e.g., -25 dBm) usually means the tag was close to the antenna, while weaker values (e.g., -90 dBm) suggest greater distance or obstacles. Not all passings will include this field, depending on the reader model and configuration.
* **Ant.**: The antenna ID that detected the tag (especially useful when using multiple antennas).
* **Lat. / Long.**: GPS coordinates of the CloudBox at the time of detection (if GPS is enabled).

This live-updating table allows you to confirm that tags are being captured correctly during the event.

### Real-Time Updates

* Passings appear instantly in the table as they are read.
* All connected clients viewing the interface receive real-time updates, ensuring timers and operators stay synchronized.

## How to Use the Timing Interface

1. **Start a Session**\
   Click **Start** to begin capturing RFID tag detections. Passings will appear immediately in the table as they are detected.
2. **Pause a Session**\
   Use the **Pause** button to temporarily halt recording without closing the session. No new passings will be logged until you resume.
3. **Stop a Session**\
   Click **Stop** to end the session. A new session will be created the next time you press **Start**.

## Understanding the Data

* **EPC/tagStr**: Unique identifier that links to a participant in your race timing software.
* **Timestamp**: Essential for precision in results—each passing is logged to the millisecond.
* **Seen**: Helps identify how long a tag have been on the field during a read cycle.
* **RSSI**: Indicates how strong the tag’s signal was at the time of reading. This helps evaluate antenna coverage and tag proximity.
* **Antenna ID**: Indicates which antenna read the tag, useful for multi-point setups.
* **GPS Coordinates**: Provides location data, particularly valuable for mobile setups or races spanning wide areas.


# Status Interface

The **Status Interface** of the CloudBox provides a complete overview of the system’s operational state. It is divided into multiple sections, each representing a different aspect of the CloudBox, from hardware integrity to network connectivity. This interface allows timing personnel to quickly confirm that the device is healthy, connected, and ready to operate.

<figure><img src="/files/1HMCwLxgJFHlI34CtoGw" alt=""><figcaption><p>Status interface</p></figcaption></figure>

## Device

This section provides general information about the CloudBox hardware and software.

<figure><img src="/files/ajFunpkRpbvUSPxqeNJQ" alt=""><figcaption></figcaption></figure>

**Fields**

* **Serial**: The unique identifier for the CloudBox hardware.
* **Pi Serial**: Internal Raspberry Pi hardware serial number.
* **Backend / Front**: The versions of the backend software and the user interface running on the device.
* **Integrity**: Confirms whether the device passed the integrity check.
* **System Status**: Indicates if the CloudBox system is open to read any tag EPC.
* **RUFUS Cloud**: Displays whether the device is bound to the RUFUS Cloud service.

## Power & Battery

This section monitors the power system and thermal health of the CloudBox.

<figure><img src="/files/K0Qz4C1dCVc3exGPQTzc" alt=""><figcaption></figcaption></figure>

**Fields**

* **Charging**: Shows whether the CloudBox is currently charging.
* **Battery**: Current battery percentage.
* **Voltage**: Battery voltage level in volts.
* **CPU Temp**: Real-time CPU temperature of the device.

## Date & Time

This section ensures accurate timekeeping, crucial for race timing.

<figure><img src="/files/ksfGHbhYYNYHx1mazAxG" alt=""><figcaption></figcaption></figure>

**Fields**

* **Current**: The system’s current date and time.
* **Timezone**: Configured timezone of the device.
* **Sync**: Indicates the synchronization method (e.g., **NTP** for Network Time Protocol, GPS when available, or Disabled).

## Network

This section shows all network interfaces and internet status.

<figure><img src="/files/Jnb6ICK4PKXPySy14Z4k" alt=""><figcaption></figcaption></figure>

**Fields**

* **wlan1**: IP address of the CloudBox when connected to an external WiFi network.
* **wlan0**: Internal WiFi Access Point status (typically fixed at `192.168.4.2`).
* **Internet**: Connection status of the CloudBox to the internet.

### 4G

This section displays the status of the 4G modem and mobile network connection.

**Fields**

* **Status**: Current modem state (e.g., `CME_ERROR` if no SIM card is present).
* **Operator**: Displays the mobile operator when a SIM is inserted.
* **Signal**: Shows the mobile network signal strength.
* **Network**: Service type and connection details (LTE, 3G, etc.).
* **Modem IMEI**: Unique hardware identifier of the 4G modem.

## IoT & Cloud

This section manages communication with the Cloud services.

<figure><img src="/files/pGcfwQmB7HX7VjyJI8I4" alt=""><figcaption></figcaption></figure>

**Fields**

* **IoT**: Connection status to the IoT server. Required for transmitting device health and configuration and for remote management.
* **Cloud Binding**: Shows whether the device is bound to a Cloud account.&#x20;
* **GPS**: Displays the current GPS status (e.g., SEARCHING, SYSTEM\_LOCATED, ERROR).

## Reader & Modes

This section provides the current state of the RFID reader and operational modes.

<figure><img src="/files/5k87yIrabMqg8nuPURdm" alt=""><figcaption></figcaption></figure>

**Fields**

* **Reader**: Shows whether the reader is configured and operational.
* **Start Mode**: Indicates if the CloudBox is currently timing.
* **Last Passing**: Timestamp of the most recent detected tag.
* **Total Tag Count**: Total number of tag detections since system inception.

## Updates

This section indicates whether new software updates are available for the CloudBox.

<figure><img src="/files/L06PbPFipQLd72P9wzp1" alt=""><figcaption></figcaption></figure>

**Fields**

* **Updates**: Displays the availability of updates. If none are available, the section confirms the system is up to date.

## Summary

The **Status Interface** provides a real-time overview of the CloudBox’s health, connectivity, and readiness. By checking each section—**Device, Power, Date & Time, Network, 4G, IoT & Cloud, Reader & Modes, and Updates**—operators can ensure the system is properly configured, connected, and stable before starting any timing session.


# Configuration Interface

The **Configuration Interface** of the CloudBox allows users to customize and manage all essential system settings. From here, you can adjust general parameters, set date and time, configure the RFID reader, manage network connectivity, and safely shut down the device.

This interface is divided into clear sections, each represented by a card in the UI.

<figure><img src="/files/HjQTKa1RPdGiFYyPllad" alt=""><figcaption><p>Configuration interface</p></figcaption></figure>

## General

This section lets you set basic operational parameters.

<figure><img src="/files/cBA6MPxjWhMoVghiriHy" alt=""><figcaption></figcaption></figure>

**Fields**

* **Bounce Time (seconds)**: Defines the minimum interval between two reads of the same tag to avoid duplicates. Typical values are 5–10 seconds for running events, higher in dense read environments.
* **Disable Buzzer**: Mutes the beeper sound when a passing is detected.
* **Disable Start Button**: Disables the physical start button to prevent accidental session starts.

## Date & Time

This section ensures the CloudBox maintains accurate timing.

<figure><img src="/files/lfS7XpLZUETvekjzcUjR" alt=""><figcaption></figcaption></figure>

**Fields**

* **Sync Source**: Select how the system clock is maintained (e.g., **NTP,** GPS or Disabled).
* **Set System Date/Time**: If NTP or GPS is not used, you can manually set the date and time.
* **Timezone**: Configure the timezone. Changing the timezone will reboot the device.

## Reader

The **Reader configuration** section is one of the most critical parts of the CloudBox setup. This is where you define how the system connects to and controls your RFID reader — directly impacting read performance, system stability, and overall timing reliability.

With the latest firmware, CloudBox introduces **native LLRP integration**, giving operators significantly more control over reader behavior, especially in professional and multi-antenna race timing environments.

#### Native LLRP Integration

CloudBox now supports **Native LLRP mode**, which provides a more direct and reliable communication layer with compatible readers (such as Zebra and Impinj devices).

Compared to legacy approaches, Native LLRP offers:

* **Improved connection stability**
* **Better control over reader behavior**
* **More predictable performance in high-density environments**
* **Enhanced compatibility with multi-antenna setups**

For most modern deployments, **Native LLRP is the recommended option**.

<figure><img src="/files/UzAltzMTh5okpk997n8U" alt=""><figcaption></figcaption></figure>

**Fields**

* **Reader Model**: Select the reader model connected to the CloudBox.
* **Reader Port**: Specify the communication port (default: **5084** for LLRP).
* **LLRP Implementation Mode**
  * **Native (recommended)**\
    Direct integration with the reader for improved performance and reliability.
  * **Legacy (if available)**\
    Maintained for compatibility with older setups.
* **Antenna Ports**\
  Choose which physical ports are active, or allow the reader to manage them automatically.
* **Antenna Mux Time (ms)**\
  Controls how long the reader spends on each antenna before switching.\
  This is especially important in multi-antenna environments where timing precision and coverage must be balanced.
  * Lower values → faster switching, broader coverage
  * Higher values → more stable reads per antenna

## Ethernet (Fixed IP)

This section manages the Ethernet configuration. Ethernet always uses a fixed IP.

<figure><img src="/files/eS4RM5fvAOJvh2W1TA1l" alt=""><figcaption></figcaption></figure>

**Fields**

* **IP Address**: The fixed IP for accessing the CloudBox over LAN.
* **Port**: Default is **8080**, but this can be customized.
* **Subnet**: Default is `/24`, standard for most networks.
* **Gateway**: Needed only when connecting through a router for internet access.

Changing any of these values reboots the device.

## WiFi

This section covers both Access Point (AP) and client WiFi modes.

<figure><img src="/files/nGo2UqSm5gO7WCQ8fKFL" alt=""><figcaption></figcaption></figure>

**WiFi Access Point (AP)**

* **AP Password**: Password for connecting client devices to the CloudBox AP.

**WiFi Client**

* **SSID / Password**: Enter credentials to join the CloudBox to an external WiFi network.
* **Connect / Disconnect WiFi**: Control the connection to the external WiFi.\
  When connected as a client, the CloudBox receives its IP from the external router (DHCP).

## SIM & 4G

This section configures the SIM card used by the 4G modem.

<figure><img src="/files/kcZjr1zRUCAl1i8ZCw6t" alt=""><figcaption></figcaption></figure>

**Fields**

* **SIM PIN**: Enter or remove the SIM PIN if required. Changing this setting reboots the device.

## Quick Reference

A summary of key network and system behaviors:

* Ethernet uses a fixed IP.
* AP clients connect directly to the UI and TCP socket.
* WiFi client mode gets IP via DHCP.
* Gateway is only needed for internet access.
* Some changes (timezone, reader config, IP) trigger a reboot.

## Danger Zone

This section provides the safe shutdown option.

**Shutdown CLBX**: Performs a controlled shutdown of the device to prevent filesystem corruption and protect stored data. Always use this option before powering off the CloudBox manually.

## Summary

The **Configuration Interface** centralizes all system setup for CloudBox. From adjusting Bounce Time and reader settings to configuring network access and powering down safely, this interface ensures that operators have complete control over the device. Proper configuration guarantees stable performance and accurate results during race timing.


# Backup Interface

The **Backup Interface** in the CloudBox system allows users to manage, download, and replay backup files. Backup files contain important timing data, ensuring event integrity and enabling post-event analysis. Proper management of these files helps maintain smooth operations and fast retrieval when needed.

<figure><img src="/files/tR2aTduhysVvTyYRP0dh" alt=""><figcaption><p>Backup interface</p></figcaption></figure>

## Backups

This section shows all backup files stored locally on the CloudBox. Each file is timestamped (`YYYYMMDD-HHmmss.txt`) for easy identification.

**Functions**

* **List Files**: Displays the available backup files.
* **Download Backups**: Downloads all backup files as a single ZIP archive.
* **Delete All**: Permanently removes all stored backup files.

Keeping this section clean is important to prevent the system from becoming slow during rewind operations.

## Rewind Passings

The **Rewind** function allows replaying of past passings stored in backup files.

**Fields**

* **Start Timestamp**: Defines the beginning of the time range to rewind.
* **End Timestamp**: Defines the end of the time range to rewind.

**Buttons**

* **Rewind**: Starts the process of replaying passings from backup files.
* **Clear**: Resets the timestamp fields.

**Behavior**

* If no timestamps are set, all passings from the backup folder are replayed.
* Replayed passings are sent to connected TCP clients and, if the CloudBox is bound, also to the Cloud Passing Ingestion Service.
* Rewinding large amounts of data can take longer if many backup files are present.

## Important Considerations

* **Regular Cleanup**: Delete old backups after downloading them externally to keep the CloudBox efficient. Large volumes of files can slow down rewind operations.
* **Backup Download**: Always archive backups outside of the CloudBox. Files can be downloaded directly via the interface or by navigating to:

  ```
  http://{clbx_ip_address}:2999/download
  ```

  Example:

  ```
  http://192.168.1.11:2999/download
  ```

## Summary

The **Backup Interface** provides essential tools to handle race data securely and efficiently. By listing, downloading, deleting, and rewinding backup files, operators ensure that no critical information is lost and that event timing data can be retrieved whenever necessary.

Regularly cleaning up backups and archiving them externally guarantees both system performance and long-term data safety.


# GPS Interface

The **GPS Interface** in the CloudBox provides real-time location and movement information, as well as details of the last known GPS fix. This interface is especially important for mobile or geographically distributed events such as marathons, triathlons, or cycling races.

The interface is divided into several sections: **GPS Status, Last Known Position, Movement, and Timing**.

<figure><img src="/files/xcBmn68Y6dnhDRGyjW7U" alt=""><figcaption><p>GPS Interface</p></figcaption></figure>

## GPS Status

This section shows the current status of the GPS module.

**Fields**

* **Current Status**: Displays whether the GPS has acquired a position. Possible values include:
  * **SEARCHING**: No GPS fix yet; the system is scanning for satellites.
  * **SYSTEM\_LOCATED**: A valid GPS fix has been obtained; accuracy is typically best.
  * **TIMEOUT**: GPS search exceeded the retry limit.
  * **GPS\_ERROR**: Invalid or corrupted GPS data.
* **Message**: Provides additional context, such as “No GPS data found. Searching...”
* **Last Sync**: Timestamp of the most recent GPS update.
* **GPS Timezone**: Timezone reported by the GPS module.

## Last Known Position

This section provides the geographic details of the last successful GPS fix.

**Fields**

* **Latitude / Longitude**: Exact coordinates of the CloudBox.
* **Altitude**: Elevation above sea level, in meters.
* **Speed**: Movement speed in km/h. Will show **0 km/h** if stationary.
* **View on Google Maps**: A direct link to visualize the CloudBox’s position in Google Maps.

## Movement

This section highlights the current motion data from the GPS module.

**Fields**

* **Current Speed**: Current speed of the CloudBox, in km/h.
* **Altitude**: Current elevation in meters.

Useful for mobile deployments where the CloudBox is moving along with the race.

## Timing

This section focuses on time synchronization through GPS.

**Fields**

* **Last Sync**: Timestamp of the most recent GPS sync.
* **GPS Timezone**: Timezone based on GPS data.
* **Notes**: If the GPS status shows **SEARCHING** or **TIMEOUT**, move the CloudBox outdoors with clear sky visibility to improve satellite acquisition.

## How the GPS Interface Works

* **Real-Time Status**: The GPS module constantly attempts to acquire satellites. When located, the interface updates live with coordinates, speed, and altitude.
* **Historical Data**: Even if GPS temporarily loses connection, the “Last Known Position” remains available.
* **Google Maps Integration**: Clicking the Google Maps link opens the CloudBox’s coordinates for easy visualization and verification.

## Summary

The **GPS Interface** ensures accurate geographic and timing data for CloudBox operations. With real-time GPS status, last known position details, motion metrics, and direct Google Maps integration, it allows race organizers to confidently monitor the CloudBox’s position and synchronization during events.


# Filters Interface

The **Filters Interface** in the CloudBox allows you to control which tag passings are processed during a timing session. By applying filters, you can ensure that only relevant bib numbers or chip mappings are included, making your timing data cleaner and easier to manage.

The interface is divided into two main sections:

* **Bib Filters**: Lets you define ranges or specific bib numbers to include.
* **Cross-Reference Table**: Allows you to map raw chip EPCs directly to bib numbers, creating a structured link between chip IDs and participants.

These tools help race organizers tailor the data flow to match the event’s requirements, whether by filtering out irrelevant tags or linking EPCs to known bib numbers.

<figure><img src="/files/r8Yljrk2iybHUT3oxscx" alt=""><figcaption><p>Filters Interface</p></figcaption></figure>

## Where to Learn More

This article introduces the Filters Interface, but the details of how to use **Bib Filters** and the **Cross-Reference Table** are covered in the **ADVANCED OPERATIONS** section. There, you’ll find step-by-step explanations and examples on how to:

* Configure and manage bib ranges.
* Load and enable cross-reference tables.
* Optimize your filters for real-world race conditions.


# Test Interface

The **Test Interface** in the CloudBox allows you to quickly verify that your RFID reader and its connected antennas are working correctly. This is especially useful during setup or troubleshooting, ensuring that each antenna is detecting tags as expected before starting a live timing session.

The interface represents each available antenna (1–8) as a circle on the screen. When a tag is detected, the circle becomes active and displays key information such as the tag’s code or EPC, the time since it was last seen, and the signal strength (RSSI, if available).

Operators can start or stop the test directly from this interface, making it a convenient tool to validate system readiness.

<figure><img src="/files/wNTovj6c8APTu1aVkaNa" alt=""><figcaption></figcaption></figure>

## Where to Learn More

This article provides a general introduction to the Test Interface. For detailed instructions on how to:

* Run an antenna test,
* Interpret the displayed results,
* Use RSSI values for antenna placement,

please refer to the **ADVANCED OPERATIONS** section of the documentation.


# Cloud Interface

The **Cloud Interface** allows you to link (bind) your CloudBox to your Cloud account, enabling seamless cloud-based timing, storage, and remote management. When bound, the CloudBox automatically sends timing passings to the **Passing Ingestion Service** and can be monitored through the Race Manager Software and you Cloud dashboard.

This interface is divided into two sections: **RUFUS Cloud** and **Cloud Binding**.

<figure><img src="/files/0g2olabNqCYfXs5TvkXo" alt=""><figcaption><p>Cloud interface</p></figcaption></figure>

## RUFUS Cloud

This section shows the current binding status and IoT connectivity of the device.

**Fields**

* **Binding Status**: Indicates whether the CloudBox is bound to a Cloud account.
  * **Not bound** (red) → Device is not linked to a Cloud account.
  * **Bound** (green) → Device is linked and will actively send passings.
* **Device Token**: The token generated in your Cloud account for the device.
* **IoT Connection**: Displays the status of the IoT service (Connected / Disconnected). IoT transmits system health and configuration data to the Cloud every 60 seconds.
* **Passings Sent to Cloud (last session)**: Number of passings successfully uploaded to the Passing Ingestion Service during the last timing session.
* **Binding Token Field**: Paste the token obtained from cloud.runonrufus.com to bind your device.
* **Bind Device Button**: Completes the binding process.

Additional actions:

* **Open RUFUS Cloud**: Opens your Cloud account in a new window.
* **Refresh**: Updates the current binding and IoT status.

## Cloud Binding

This section explains what binding does and provides important notes.

**What binding does**

* Links this CloudBox to your Cloud account.
* Sends passings to the Cloud Timing Service whenever internet connectivity is available (Ethernet, WiFi AP-shared, or 4G).
* Allows remote monitoring and status checks from your Cloud account via IoT.

**Good to know**

* Binding/unbinding is disabled while in **Start Mode** or **Test Mode** to avoid data loss.
* Passings collected offline are forwarded to the Cloud as soon as connectivity returns (within the same session).
* Unbinding only prevents future uploads — previously sent data remains stored in your Cloud account.

## Binding Your CloudBox

1. Log into your Cloud account at cloud.runonrufus.com.
2. Generate a **binding token** from the **Devices** section.
3. Paste the token into the **Binding Token** field in the Cloud interface.
4. Click **Bind Device**.

Once bound, the CloudBox will automatically send passings to the Cloud whenever an internet connection is available.

## Unbinding Your CloudBox

1. Access the Cloud Interface in the CloudBox dashboard.
2. Click **Unbind Device**.

The device will be disconnected from your Cloud account, disabling cloud-based race management.

## Summary

The **Cloud Interface** links the CloudBox to the Cloud ecosystem, unlocking powerful remote management and secure data storage features. By binding your device, you ensure:

* **Automatic upload** of all passings to the Passing Ingestion Service.
* **Remote monitoring** through IoT integration.
* **Centralized race management** in the Race Manager Software.

Binding and unbinding is straightforward, but should be managed carefully to guarantee uninterrupted synchronization and reliable event timing.


# RFID Reader Configuration

The **CloudBox** supports several compatible RFID readers, allowing for flexible deployment across a variety of timing scenarios. Whether you're timing dense race starts with hundreds of participants or monitoring sparse checkpoints, selecting the right RFID reader is crucial for ensuring accurate and reliable performance.

In this article, we'll dive deeper into the differences between the compatible RFID readers and their ideal applications. We’ll also discuss configuration requirements, status notifications, and best practices for ensuring proper connectivity and performance.

## Reader Configuration Requirements

For the CloudBox to communicate properly with a connected RFID reader, the following settings must be in place:

* **IP Address**: The RFID reader must be set to a **fixed IP address of 10.0.0.2**. This is necessary to maintain reliable communication between the CloudBox and the reader.
* **Port**: The port used for communication can vary depending on the reader model. This setting is configurable within the CloudBox **Configuration Interface**.
* **Apps**: The RFID reader must have no applications running that may interfere with the operations of the CloudBox firmware

## Compatible RFID Readers (Firmware Version 1.0.19)

As of firmware version **1.0.16**, the following RFID readers are compatible with the CloudBox:

1. **Zebra FX9600 w/APP (via One4All app)**
   * This model works with a dedicated application (One4All app) and offers high performance for dense timing points. It is ideal for events with high participant volumes, such as marathons and triathlons.
2. **Zebra FX9600 (via LLRP)**
   * This version operates via **LLRP (Low-Level Reader Protocol)** and is also highly recommended for high-density race events. Its robust design and high read rate make it ideal for start and finish lines with large groups of participants.
3. **Zebra FX9500 (via LLRP)**
   1. The **FX9500** is an older model but still reliable for medium-density timing points. It is suitable for checkpoint readings where there is moderate tag density.
4. **Sirit INFINITY 610 (via LLRP)**
   * The **INFINITY 610** is an older model with similar characteristics as the FX9500.
5. **Impinj R220 (via LLRP)**
   * The **Impinj R220** is recommended for low-density applications, such as individual checkpoints or smaller events. This reader is efficient but limited in terms of the number of tags it can handle simultaneously as it only has 2 antenna ports.
6. **Impinj R420 (via LLRP)**
   * The **R420** is a more powerful version of the **R220**, suited for medium to high-density applications. It provides a balance between performance and cost and can handle larger numbers of participants than the R220 because it has 4 antenna ports.
7. **Chainway UR4**
   * The **Chainway UR4** is a versatile and budget-friendly option for low- to medium-density race checkpoints. It offers reliable performance for events that do not require ultra-high tag read rates.

## Reader Status Notifications

The CloudBox continuously monitors the status of the connected RFID reader and will provide real-time feedback through the user interface and notifications sent to connected clients.

1. **RFID Reader Not Found**:
   * This status indicates that the reader is either not configured or not present. The CloudBox will attempt to connect to the reader every 10 seconds.
   * The **Start LED** on the CloudBox will blink every 250 ms continuously, and a notification will be sent to all connected web clients.
2. **RFID Reader Present**:
   * Once the reader is correctly configured and detected, the CloudBox will enter **standby mode**, checking the reader's status every 60 seconds to ensure it remains connected.
   * The system will notify connected clients that the reader is present and ready for use.
3. **RFID Reader Connection Lost**:
   * If the reader was previously connected but loses connection, the CloudBox will display this status. It will attempt to reconnect every 10 seconds.
   * The **Start LED** will blink every 250 ms continuously, and a notification will be sent to connected clients informing them of the connection loss.

## Choosing the Right RFID Reader for Your CloudBox

Depending on the specific needs of your event, different RFID readers will be more or less suitable. Here are some recommendations based on **timing point density**:

1. **High-Density Timing Points** (Start and Finish Lines for Large Events):
   * Recommended readers:
     * **Zebra FX9600** (w/APP or LLRP)
     * **Impinj R420**
   * These readers offer high read rates and can handle large numbers of tags in quick succession, ensuring accurate detection at busy start or finish lines.
2. **Medium-Density Timing Points** (Checkpoint Events or Mid-Sized Races):
   * Recommended readers:
     * **Zebra FX9500**
     * **Impinj R420**
     * **Chainway UR4**
   * These readers offer a balance of performance and affordability for events with moderate participant volumes.
3. **Low-Density Timing Points** (Individual Checkpoints or Smaller Races):
   * Recommended readers:
     * **Impinj R220**
     * **Chainway UR4**
   * For less dense timing points, these readers are effective and cost-efficient, handling fewer tags without sacrificing accuracy.

## Power and Connectivity Considerations

1. **Power Requirements**:
   * Ensure that the RFID reader is receiving the correct power supply, as provided by the CloudBox. The CloudBox’s built-in power connectors are designed to work seamlessly with the RFID readers listed above.
2. **Ethernet and Power Connections**:
   * The CloudBox is equipped with two connection cables for the reader:
     * **Ethernet Cable**: Used for transmitting data between the CloudBox and the reader.
     * **Power Cable**: Used for powering the RFID reader. Ensure that both connections are properly secured for reliable operation.

## Default Readers Configurations

Here are the default configurations for each kind of reader compatible with the CloudBox:

* **FX9600\_APP:**&#x20;
  * IP: 10.0.0.2&#x20;
  * Subnet: 255.0.0.0
  * Port: 5555
* **FX9600\_LLRP, FX9500, R420, R220, INFINITY 610**
  * IP: 10.0.0.2&#x20;
  * Subnet: 255.0.0.0
  * Port: 5084
* **UR4,**
  * IP: 10.0.0.2&#x20;
  * Subnet: 255.0.0.0
  * Port: 8888

## Summary

Configuring an RFID reader with the CloudBox requires setting a **fixed IP address** and selecting the appropriate reader model based on the event's timing requirements. Whether you're managing a high-volume race start or a low-density checkpoint, the right RFID reader will ensure that your timing data is accurate and reliable.

Always monitor the **Reader Status** through the CloudBox interface and ensure that both the **Ethernet** and **power connections** are properly configured. By following these guidelines, you can ensure a smooth and efficient race timing experience.


# RFID Reader Installation

This article provides detailed instructions on how to physically install a compatible RFID reader into your CloudBox. Proper installation is key to ensuring smooth and reliable race timing performance.

**Required Tools and Components:**

* Screwdriver (compatible with the screws provided)
* Hole punch (if additional holes are needed for securing the reader)
* Provided screws and nuts

<figure><img src="/files/3zpyCLd2zkrnhlGJL8Ro" alt="" width="563"><figcaption><p>Required tools</p></figcaption></figure>

## **Step-by-Step Installation:**

### **1. Detach the Reader Cabinet Top Cover**

The first step is to **detach the top cover of the CloudBox reader cabinet**:

* Use a screwdriver to remove the screws securing the cover.
* Once all screws are removed, lift off the top cover to expose the interior of the reader cabinet.

<figure><img src="/files/5YaXrwzAd2vPphLY4VS4" alt="" width="563"><figcaption><p>Top cover detached</p></figcaption></figure>

### **2. Remove the Double Bottom Base**

Inside the reader cabinet, there is a **double bottom base** that serves as the mounting platform for the reader:

* Unscrew and remove this base.
* You will notice that the base already has several **pre-drilled holes**. These holes are compatible with the fixing holes on the readers. Position the reader on this base so that you can **secure it using at least three fixing points**.
* If the pre-drilled holes do not align perfectly, use a **hole punch** to create the necessary holes.

<div><figure><img src="/files/ajz4fsqMG33l784MRWay" alt=""><figcaption><p>View of the double bottom removed</p></figcaption></figure> <figure><img src="/files/duhvwzpE3zOpgkMwEvq1" alt=""><figcaption><p>View of the double bottom removed</p></figcaption></figure></div>

### **3. Attach the Reader to the Base**

Once the reader is positioned:

* **Attach the reader** to the base using the provided screws and nuts.
* Ensure the reader is securely fastened, minimizing movement that could impact performance.

<div><figure><img src="/files/fbL3P24z7uo4TkMTZ277" alt=""><figcaption><p>Impinj reader attached to the double bottom base</p></figcaption></figure> <figure><img src="/files/zIOdis0npfUDSM0D242I" alt=""><figcaption><p>Zebra reader attached to the double bottom base</p></figcaption></figure> <figure><img src="/files/HLl3c23pyWeb7B6a91Sl" alt=""><figcaption><p>Chainway reader attached to the double bottom base</p></figcaption></figure></div>

### **4. Connect the Ethernet Cable**

With the reader properly installed, it's time to make the necessary connections:

* Locate the **red Ethernet data cable** and connect it to the **Ethernet port** of the reader.
* This cable is essential for data transmission between the reader and the CloudBox.

### **5. Connect the Power Connector**

The next step is to **connect the power** to the reader:

* The CloudBox can provide multiple power outputs (24V, 12V, and 9V). Ensure you choose the correct **power version** for your specific reader.
* Plug the power connector into the **power input** of the RFID reader.

<figure><img src="/files/zGxV0frqADnrh5hptjMG" alt="" width="563"><figcaption><p>Ethernet cable and power cable connected to the reader</p></figcaption></figure>

### **6. Turn On the CloudBox and Configure the Reader**

Now that the reader is physically installed and connected:

* **Turn on the CloudBox**.
* Access the CloudBox interface via your browser (navigate to `cloudbox.local` or the specific IP address of your CloudBox).
* Follow the steps in the **"**[**Configuration Interface**](https://help.runonrufus.com/rufus-cloudbox/general-operations/pages/tQG939Q6Ov0w4UKTQpuO#id-3.-reader-configuration)**"** article to complete the software setup for the reader.
* Make sure the reader is recognized and that there are no error messages.

### **7. Reattach the Reader Base and Cabinet Top Cover**

Once you have confirmed that everything is functioning correctly:

* **Reattach the reader double base** to the cabinet.
* **Reattach the top cover** of the reader cabinet.
* Secure everything in place using the screws removed in the firsts steps.

<figure><img src="/files/DhTzm1zFRyRBwPfoZhIL" alt="" width="563"><figcaption></figcaption></figure>

<div><figure><img src="/files/k9N2mQ4WwbGccmq6XrWt" alt=""><figcaption></figcaption></figure> <figure><img src="/files/kWOC32jAEm3jbbsdEj6r" alt=""><figcaption></figcaption></figure></div>

## **Final Notes:**

* It is crucial to properly secure both the reader and the cabinet to prevent damage during transportation or operation.
* Double-check all connections, ensuring that both data and power cables are firmly in place before using the system.

By following these steps, you ensure that your RFID reader is installed correctly and ready to perform efficiently during race events. Proper installation reduces potential issues and enhances the reliability of your CloudBox timing system.


# Knowing your CloudBox IP Address

When working with the **CloudBox**, knowing its **Ethernet IP address** is essential for accessing the web interface, configuring settings, and ensuring smooth communication, especially for **TCP socket communication**. This **Ethernet IP address** remains fixed and is the one you’ll use to interact with the CloudBox for timing data and system commands, regardless of whether the device is connected via **WiFi** or **Ethernet**.

In this article, we will explore the different ways to determine the **Ethernet IP address** of your CloudBox in various scenarios.

## 1. **Checking the WiFi Access Point Name**

When the CloudBox is operating in **WiFi Access Point mode**, it generates its own access point with an SSID (network name) that directly includes its IP address. This makes it one of the easiest methods to identify the CloudBox IP.

The format of the SSID is:

```bash
CLBX_{IP_ADDRESS}
```

For example, if the CloudBox IP address is `192.168.1.10`, the WiFi access point name will be `CLBX_192_168_1_10`. Simply by looking at the network name, you can immediately know the current IP address of the CloudBox.

**Steps:**

1. Open your device’s **WiFi settings**.
2. Look for the WiFi network named `CLBX_{IP_ADDRESS}`.
3. The IP address will be embedded in the SSID (e.g., `CLBX_192_168_1_10`).

This is particularly useful when using the CloudBox in standalone mode, where it is generating its own WiFi access point.

## 2. **Checking the Router’s Device List (For External WiFi Networks)**

When the CloudBox is connected to an **external WiFi network**, the device will receive an IP address for the **WiFi interface** dynamically via **DHCP** from the router. However, this WiFi IP is not the one used for TCP socket communication. The IP address you need for communication is the **fixed Ethernet IP address**, which stays constant and is always used for TCP socket connections.

To find the **Ethernet IP address** in this case, you’ll still use the router’s device list, but you need to identify the **fixed Ethernet IP** rather than the dynamically assigned WiFi IP.

**Steps:**

1. Log into your router’s admin interface (typically accessed via `192.168.1.1` or a similar IP address).
2. Navigate to the **Connected Devices** or **Clients** section.
3. Find the CloudBox in the device list. The router will show multiple IP addresses for the CloudBox:
   * One IP for the **WiFi** interface (assigned dynamically via DHCP).
   * One **fixed IP address** for the **Ethernet port**.
4. Identify the **fixed Ethernet IP address**, which is the one you’ll use for TCP socket communication (e.g., `192.168.1.10`).

This method is useful when the CloudBox is connected to a larger network via WiFi but still uses the **Ethernet IP** for TCP communication.

## **3. Using the CloudBox Interface Directly**

If you’re already connected to the CloudBox via **Ethernet** or the **WiFi Access Point**, you can directly access the **Network Configuration** section of the CloudBox interface to view the current IP addresses.

**Steps:**

1. Open a web browser and go to the CloudBox’s interface using`cloudbox.local`
2. In the **Network Configuration** section, the **Ethernet IP** **address** will be displayed.&#x20;
3. You can also modify the Ethernet IP here if needed.

This method is useful for verifying or changing network settings when you already have access to the interface.

## 4. **Using the Ping Command**

If you are on the same network as the CloudBox, you can use the **ping** command to locate the device.

**Steps:**

1. Open the **Command Prompt** (Windows) or **Terminal** (Mac/Linux).
2. Type the following command:

   ```bash
   ping cloudbox.local
   ```
3. The system will return the CloudBox’s IP address if it’s reachable on the network, but this may return the **WiFi IP** instead of the **Ethernet IP**.

This method works best when there is only one CloudBox on the network and you want to verify connectivity.

## Important Considerations

* **Ethernet IP Address for TCP Communication**: The **Ethernet IP address** is the fixed IP address you should always use for **TCP socket communication**, regardless of whether the CloudBox is connected via **WiFi** or **Ethernet**.
* **WiFi IP Address (For External Networks)**: When the CloudBox is connected to an external WiFi network, the **WiFi IP address** is dynamically assigned via **DHCP**, but this is not the IP you need for direct communication. Always look for the **fixed Ethernet IP** for TCP communication.
* **Multiple CloudBox Devices on the Same Network**: If you are working with multiple CloudBox devices on the same network, ensure that each device has a **unique Ethernet IP address** to avoid conflicts. In such cases, accessing by IP is more reliable than using `cloudbox.local`.

## Summary

When working with the CloudBox, the most critical IP address to know is the **Ethernet IP address**, as this is the one used for **TCP socket communication**. Whether you’re connected via **Ethernet** or **WiFi**, the Ethernet IP remains constant, ensuring reliable connectivity for timing data and commands. Use the **WiFi Access Point name**, **router’s device list**, or directly check the **Network Configuration** in the CloudBox interface to find this address.


# Boot Sequence

Understanding the boot sequence of your **CloudBox** is important for ensuring that the system is starting up correctly and that all components are functioning as expected. During the boot process, the status of the **LED indicators** and the **cooler** provide valuable feedback about the current state of the device.

Here’s a breakdown of the typical boot sequence and the meaning behind each LED status:

## Initial Boot Sequence (First 10 Seconds)

1. **LED Status**:
   * **Power LED**: Solid blue.
   * **Start LED**: Solid red.
2. **Cooler Status**:
   * The **cooler** is active during the initial boot phase, ensuring the system maintains optimal temperature while components initialize.

This state lasts for approximately **10 seconds** as the CloudBox initializes its systems.

## After 10 Seconds

After the initial 10 seconds, the system transitions into its operational checks:

1. **LED Status**:
   * **Start LED**: Begins to blink **every 1000 ms** (once per second).
2. **Cooler Status**:
   * The **cooler** turns off as the system completes its boot process.

This indicates that the CloudBox is finishing its startup routine and checking for any potential issues.

## System Status After Boot

Once the boot sequence is completed, the **Start LED** will indicate the status of the CloudBox:

1. **Normal Operation (System OK)**:
   * **Start LED**: Solid red.
   * This indicates that the system has successfully booted, and the CloudBox is ready for use.
2. **RFID Reader Not Detected (READERNOTOK)**:
   * **Start LED**: Blinks rapidly **every 250 ms**.
   * This status indicates that the RFID reader is either not connected or not configured correctly. The CloudBox will continue to attempt to detect the reader.
3. **System Updating (UPDATING)**:
   * **Start LED**: Blinks slowly **every 3000 ms** (once every 3 seconds).
   * This status shows that the CloudBox is in the process of updating its firmware or software. Wait for the update to complete before interacting with the system.

## Summary

The **CloudBox boot sequence** provides a clear indication of the system's status through its **LED indicators** and **cooler operation**. In the first 10 seconds, both the **Power** and **Start LEDs** are solid, and the cooler is active. After this, the system checks its components and gives feedback through the **Start LED**. A solid red Start LED indicates that the CloudBox is ready, while different blinking patterns signal issues or updates in progress.

Understanding these indicators ensures that you can quickly diagnose and respond to any potential issues during startup.


# Starting, Pausing, and Stopping a Timing Session

The CloudBox provides multiple ways to manage a timing session, offering flexibility in how events are timed. Whether through the CloudBox Interface, hardware buttons, TCP socket commands, or the IoT service, the system ensures accurate and efficient session management.

The CloudBox also introduces a **Pause** option, which temporarily suspends recording without creating a new session. This allows operators to halt passings momentarily without generating extra backup files or splitting sessions.

In this article, we’ll explore the different ways to start, pause, and stop a timing session, the internal processes triggered during these actions, and the commands affected while a session is active.

## Ways to Start a Timing Session

1. **Via the CloudBox Interface**:
   * The most common way to start a timing session is by pressing the **START READS** button in the CloudBox web interface. This action begins the session, enabling the CloudBox to start reading and transmitting RFID tag data.
2. **Using the Start Button on the CloudBox**:
   * Pressing the **Start Button** on the physical CloudBox also initiates a timing session. This is useful in scenarios where access to the web interface is not immediately available.
3. **Via TCP Socket Command**:
   * You can also start a session through a **TCP socket connection** by sending the `START` command. This method allows for integration with external systems or custom applications that control the CloudBox remotely.
4. **Through the IoT Service**:
   * If the CloudBox is connected to the **Cloud Service**, a session can also be initiated remotely from the cloud. This allows race managers to start sessions from anywhere with internet access, without physically interacting with the device.

### Internal Processes During Session Start

When a timing session starts, several key operations are triggered within the CloudBox to ensure data accuracy and reliability:

1. **Session Creation in the Cloud**:
   * The CloudBox connects to the **Passing Ingestion service**, creating a new session that logs all incoming timing data. This ensures real-time tracking and cloud-based storage for post-event analysis.
2. **Backup File Creation**:
   * A local **backup file** is created on the CloudBox, ensuring all passings are saved even if internet connectivity is lost. This file is essential for data integrity and recovery.
3. **Data Transmission to TCP Clients**:
   * Any **connected TCP clients** will start receiving real-time timing data (passings). The CloudBox transmits the tag reads to all clients connected via TCP.
4. **Counter Reset**:
   * All session-related counters (e.g., passings count) are reset to zero to ensure accurate data collection for the new session.
5. **Buzzer Activation**:
   * The CloudBox will emit a **start signal** via the buzzer to notify race officials or timing personnel that the session has begun.
6. **LED Indicator Changes**:
   * The **Start LED** on the CloudBox changes to **blue** to visually indicate that a timing session is in progress.

### **Possible Responses After Starting a Session:**

* `START_MODE`: Indicates that a session has already started.
* `READERNOTOK`: The RFID reader is not detected.
* `DEVICE_INTEGRITY_FAILED`: The CloudBox integrity check failed.
* `INVALIDREADERMODEL`: The connected reader model is unsupported.
* `ERRREADER`: There’s an issue with the reader.
* `ERRCONNECT`: Error connecting to the reader or network.
* `OK`: The session started successfully.

### Commands Affected During a Timing Session

Once a timing session is active, the majority of configuration commands are **ignored** to avoid disruptions during the session. Commands that cannot be executed during a session include:

* **Reader configuration commands** (`SETREADERPORT`, `SETREADERMODEL`): You cannot change the reader’s port or model during a session.
* **IP address changes** (`CHANGESYSTEMIPADDRESS`): Network changes are blocked to ensure continuous connectivity.
* **Date/time sync changes** (`SETSYSTEMTIME`, `SETDATETIMESYNC`, `CHANGETIMEZONE`): Any changes to time-related settings are ignored.
* **System shutdown and restart commands** (`SHUTDOWN`): The system cannot be shut down or restarted during a session.

These commands will return a `START_MODE` response, indicating that they cannot be executed while a session is active.

## Pausing a Timing Session

The **Pause** feature allows operators to suspend passings without ending the session.

* **Via the CloudBox Interface**: Click **Pause** to temporarily stop recording passings.

While paused:

* No new passings are logged or transmitted.
* The session remains open, preventing creation of new backup files or sessions when resumed.
* Resuming is done by pressing **Start** again, continuing from the same session.

**Use case**: Pausing is ideal if you need to temporarily block passings (e.g., for setup, maintenance, or a break in the race) without fragmenting event data.

## Ways to Stop a Timing Session

1. **Via the CloudBox Interface**:
   * To stop a timing session, press the **STOP** button in the CloudBox interface. This ends the session and initiates the data-saving processes.
2. **Using the Stop Button on the CloudBox**:
   * Pressing the **Start Button** again on the CloudBox will stop the session, making it a quick way to end a session without accessing the web interface.
3. **Via TCP Socket Command**:
   * Send the `STOP` command through the **TCP socket connection** to remotely stop the session.
4. **Through the IoT Service**:
   * The session can also be stopped remotely through the **Cloud Service**, giving race managers control over the session from anywhere with internet access.

### Internal Processes During Session Stop

Stopping a timing session triggers several operations to ensure the safe storage and transmission of the session’s data:

1. **Cloud Session Closure**:
   * The active session on the **Passing Ingestion service** is closed, finalizing the race data for cloud storage.
2. **Queue Cleanup**:
   * Any remaining passings in the **data queue** are processed and sent to connected clients before the system stops reading tags.
3. **Buzzer Activation**:
   * The **stop signal** is emitted via the buzzer to alert personnel that the session has ended.
4. **Global Counter Update**:
   * The **global passings counter** is incremented, ensuring that cumulative data for all sessions is maintained.
5. **LED Indicator Changes**:
   * The **Start LED** returns to **red**, indicating that the session has ended and the CloudBox is no longer reading tags.

### **Possible Responses After Stopping a Session:**

* `READERNOTOK`: The RFID reader is not detected or disconnected.
* `INVALIDREADERMODEL`: The connected reader model is unsupported.
* `ERRREADER`: There’s an issue with the reader.
* `ERRCONNECT`: Error in network connection.
* `OK`: The session stopped successfully.

## Summary

The CloudBox now supports **starting, pausing, and stopping sessions** with flexibility across the interface, hardware, TCP commands, and IoT.

* **Start**: Creates a new session and begins logging passings.
* **Pause**: Suspends logging without ending the session, avoiding fragmentation of backup files.
* **Stop**: Closes the session, finalizes data, and ensures safe storage.

By understanding these functions, operators can manage timing sessions efficiently while preserving data integrity and adapting to event needs.


# Accessing Backup Files on the CloudBox

The **CloudBox** offers multiple methods for users to access and manage backup files, ensuring data integrity during race events. Backup files are essential for storing passings data, especially in cases where network connections might be lost or when post-event analysis is required. You can retrieve backup data through methods like **USB Pen Drive**, **browser download link**, or by using the **Rewind feature**. Additionally, each backup file is saved in **.txt format** and named using a **timestamp** to help identify when the backup was created.

This article will cover the different ways to access backup files and provide a code example for analyzing the **.txt backup files**.

## Backup File Format

All backup files on the CloudBox are saved in **.txt format**, with the file name consisting of a **timestamp** that reflects the creation time. The format of the file name is:

```
YYYYMMDD-HHMMSS.txt
```

For example, a backup file created on **September 18, 2024, at 09:36:34** would be named:

```
20240918-093634.txt
```

### **Backup File Content**

Each file contains JSON-formatted entries, similar to the data transmitted during a TCP socket connection. These entries represent individual **passings**, with information such as the RFID tag read, timestamp, antenna used, RSSI value, and more.

Example JSON entry from a backup file:

```json
{
  "epc": "3D2E372D39293A313C313734",
  "timestamp": "2024-09-18;09:36:34.098",
  "seenCount": 1,
  "antenna": 1,
  "rssi": -58,
  "passingNumber": 1,
  "tagStr": "MC00169",
  "latitude": null,
  "longitude": null,
  "chksum": "6a0f5"
}
```

Each passing is stored sequentially, with all relevant timing data captured.

## 1. **Accessing Backups via USB Pen Drive**

One of the easiest ways to retrieve your CloudBox backups is by connecting a **USB Pen Drive** to the device. The CloudBox automatically detects the USB drive and transfers backup files to it. The system will notify you of the connection status and whether the download was successful or encountered an error.

### **How It Works:**

* When a **USB drive** is connected to the CloudBox, the system detects the device and begins the backup download process.
* The user is notified of the drive detection, download progress, and any errors that may occur.
* During this process, the CloudBox will emit a **light sequence**—flashing every 500ms for 2 seconds—to indicate that the USB drive has been detected.

### **Important Considerations:**

* **USB Drive Format**: The USB drive must be formatted in **MS-DOS (FAT32)**. Drives with other formats may not be detected by the CloudBox.
* **Drive Name**: The drive's name should use **standard characters** (e.g., `PEN_BACKUPS`) to ensure compatibility.
* **Notifications**: If you're connected to the CloudBox interface, you will receive notifications indicating whether the connection and download were successful or if any errors occurred.

## 2. **Downloading Backups via Browser Link**

Another convenient way to access backups is by using a **direct download link** in a web browser. You can download all backup files in a **zipped format** by accessing the following link:

```
http://{clbx_ip_address}:2999/download
```

For example, if the CloudBox's IP address is `192.168.1.11`, the link to download backups would be:

```
http://192.168.1.11:2999/download
```

### **How It Works:**

* Open a browser and navigate to the download link using the CloudBox's **Ethernet IP address**.
* You can download all backup files stored on the CloudBox in a **zipped format**, making it easy to transfer and archive the data.

### **Important Considerations:**

* The CloudBox must be connected to the same network as your computer (either via **Ethernet**, **WiFi on the same subnet**, or **WiFi Access Point**).
* Make sure to keep the backup storage clean by periodically downloading and deleting old files to avoid storage issues.

## 3. **Rewind Feature for Retrieving Passings**

The **Rewind feature** allows you to retrieve specific passings data between a given time range. This feature is especially useful for analyzing race data after the event, as it provides a stream of past passings to connected TCP clients.

### **How It Works:**

* The **Rewind** feature returns a stream of **passings** data to connected TCP clients.
* You can specify a **startTimestamp** and **endTimestamp** to limit the data to a specific time range. If both are set to `null`, the CloudBox will return all passings available in the backup files.

### **Command Format:**

* **Rewind Command**:

  ```
  REWIND;startTimestamp;endTimestamp
  ```

  Example format for timestamps:

  ```
  REWIND;2024-09-18 09:30:00;2024-09-18 10:30:00
  ```
* **startTimestamp** and **endTimestamp** must be in the format `YYYY-MM-DD HH:mm:ss`. If no timestamp is provided, the system will return all available data from the backup.

### **Important Considerations:**

* The **Rewind feature** can be used during an active timing session (`START_MODE`). This allows you to access past data while still recording new passings in real time.
* Keep in mind that if no specific time range is provided, retrieving a large amount of data could take time, especially if the backup storage is not regularly cleaned.

## Notifications and LED Indications

The CloudBox provides various feedback mechanisms when interacting with backups:

* **USB Detection**: The CloudBox will flash its LED every **500 ms for 2 seconds** when a USB drive is detected, indicating that the backup download process is starting.
* **User Notifications**: If you are connected to the CloudBox via the web interface, you will receive **notifications** when:
  * The USB drive is connected.
  * The backup download completes successfully.
  * Any errors occur during the download process.

These notifications ensure that users are aware of the backup status and can respond if needed.

## Analyzing Backup Files

Here’s an example of how you can read and analyze the backup files using **Python**, **C#**, and **Node.js**.

**Python Example:**

```python
import json

# Path to the backup file
backup_file = "20240918-093634.txt"

# Open the backup file and parse each line as a JSON object
with open(backup_file, "r") as file:
    for line in file:
        passing_data = json.loads(line)
        print(f"Tag: {passing_data['epc']}, Timestamp: {passing_data['timestamp']}, Antenna: {passing_data['antenna']}")
```

**C# Example:**

```csharp
using System;
using System.IO;
using Newtonsoft.Json.Linq;

class BackupAnalysis
{
    static void Main()
    {
        string backupFilePath = "20240918-093634.txt";
        
        foreach (string line in File.ReadLines(backupFilePath))
        {
            JObject passingData = JObject.Parse(line);
            Console.WriteLine($"Tag: {passingData["epc"]}, Timestamp: {passingData["timestamp"]}, Antenna: {passingData["antenna"]}");
        }
    }
}
```

**Node.js Example:**

```javascript
const fs = require('fs');

// Path to the backup file
const backupFile = '20240918-093634.txt';

// Read and parse each line of the backup file
fs.readFile(backupFile, 'utf8', (err, data) => {
    if (err) throw err;
    
    data.split('\n').forEach(line => {
        if (line) {
            const passingData = JSON.parse(line);
            console.log(`Tag: ${passingData.epc}, Timestamp: ${passingData.timestamp}, Antenna: ${passingData.antenna}`);
        }
    });
});
```

These examples show how you can parse the JSON entries in the backup files and extract key information like **epc** (RFID tag), **timestamp**, and **antenna**.

## Summary

The CloudBox provides multiple ways to access and manage backup files, including using a **USB Pen Drive**, downloading via a **browser link**, or using the **Rewind feature** for targeted passings retrieval. Each backup file is saved in a **.txt format** with a **timestamped name**, and the entries inside the file are stored in **JSON format**, representing each passing. Regularly downloading and analyzing these backups ensures that race data is securely stored and easily accessible for post-event analysis.


# Time Synchronization Methods

Accurate time synchronization is critical for race timing systems, as it ensures that all data collected is consistent and reliable. The **CloudBox** offers three methods for time synchronization: **NTP (Network Time Protocol)**, **GPS**, and **Manual**. Each method has its own advantages and trade-offs, depending on your network environment, event setup, and connectivity.

In this article, we will explore the pros and cons of each method and provide guidelines for when to use each option.

## 1. **NTP (Network Time Protocol) Synchronization**

**NTP** is a widely used protocol for synchronizing the time of devices over a network. The CloudBox can connect to an external NTP server to keep its time accurate.

### **How It Works:**

* The CloudBox connects to an NTP server on the internet to synchronize its system time.
* NTP continuously adjusts the time, ensuring it remains accurate as long as there is network connectivity.

### **Pros:**

* **Automatic synchronization**: Once set up, NTP keeps the CloudBox’s time in sync without manual intervention.
* **Accurate**: NTP servers provide highly accurate time, ideal for timing critical events.
* **Ideal for connected environments**: Works well when the CloudBox has consistent access to the internet.

### **Cons:**

* **Requires network connectivity**: If the CloudBox loses internet access or if the NTP server becomes unavailable, the CloudBox will no longer synchronize its time.
* **Dependent on external sources**: NTP relies on a third-party server, which means there could be a slight delay or error based on network conditions.

### **When to Use:**

* NTP is best used when the CloudBox is connected to a reliable **external network** (e.g., Ethernet or WiFi) with access to the internet. It is ideal for venues or races where continuous internet access is available.

## 2. **GPS Synchronization**

**GPS synchronization** allows the CloudBox to set its time based on satellite signals. This method is useful for outdoor events where the CloudBox can receive a GPS signal.

### **How It Works:**

* The CloudBox’s built-in GPS module receives signals from satellites and synchronizes its internal clock with the highly accurate time from the Global Positioning System (GPS).

### **Pros:**

* **Highly accurate**: GPS provides extremely accurate time synchronization, down to the millisecond, which is critical for events with precise timing needs.
* **No internet required**: GPS works anywhere there’s a clear view of the sky, making it perfect for outdoor events without reliable internet access.
* **Ideal for mobile or remote races**: GPS is well-suited for geographically dispersed events like marathons, cycling races, or triathlons where the CloudBox might not be connected to a stable network.

### **Cons:**

* **Requires GPS signal**: GPS synchronization only works when the CloudBox has a clear view of the sky. In indoor or obstructed environments, GPS may not be available.
* **Initial delay**: There may be a slight delay when acquiring the GPS signal, especially when starting up the system or after moving to a new location.

### **When to Use:**

* **GPS synchronization** is ideal for outdoor races or remote locations where the CloudBox cannot rely on internet connectivity for NTP synchronization. It is also a great backup option if your event setup is mobile or lacks fixed network infrastructure.

## 3. **Manual Synchronization**

**Manual synchronization** allows users to manually set the date and time on the CloudBox through both the **interface** and via a **protocol command**. This method is useful in environments where network or GPS signals are unavailable or unreliable.

### **How It Works:**

* The user can manually input the current date and time in the **DateTime Configuration** section of the CloudBox interface, ensuring that the system reflects the correct time.
* Alternatively, manual time synchronization can be performed using the **SETSYSTEMTIME** protocol command, which allows you to set the date and time programmatically via a TCP connection.

#### **Protocol Command for Manual Sync**:

```bash
SETSYSTEMTIME(YYYY-MM-DD HH:mm:ss)
```

Example:

```bash
SETSYSTEMTIME(2024-09-18 10:30:00)
```

This command allows flexibility for remote management and can be particularly useful for automated setups or when you need to adjust the time from a connected system.

### **Pros:**

* **No external dependencies**: Manual synchronization works without needing an internet connection, network access, or GPS signals.
* **Flexible options**: You can either use the **web interface** or the **SETSYSTEMTIME** command to adjust the time.
* **Useful for isolated or backup scenarios**: This method is helpful when both NTP and GPS synchronization are unavailable or impractical.

### **Cons:**

* **Prone to human error**: Entering the time manually can lead to small discrepancies if the time is set incorrectly. This could affect the accuracy of timing data.
* **No automatic updates**: Unlike NTP or GPS, manual time settings won't adjust automatically, meaning the system’s time may drift over longer periods.

### **When to Use:**

* **Manual synchronization** is best used as a **backup option** when neither NTP nor GPS synchronization is available. It's also valuable in smaller or controlled events where minute-by-minute precision isn't as critical.

## Comparison of Time Synchronization Methods

<table><thead><tr><th width="115">Method</th><th>Pros</th><th>Cons</th><th>Best Use Case</th></tr></thead><tbody><tr><td><strong>NTP</strong></td><td>- Automatic and accurate<br>- Ideal for connected environments</td><td>- Requires internet access<br>- Dependent on external servers</td><td>Events with stable internet or local network connectivity</td></tr><tr><td><strong>GPS</strong></td><td>- Highly accurate<br>- Works without internet access</td><td>- Requires clear view of sky<br>- Not ideal for indoor events</td><td>Outdoor events or mobile race setups</td></tr><tr><td><strong>Manual</strong></td><td>- No external dependencies<br>- Easy to configure</td><td>- Prone to human error<br>- No automatic adjustments</td><td>Backup or isolated scenarios</td></tr></tbody></table>

## How to Configure Time Synchronization on the CloudBox

You can configure time synchronization through the **DateTime Configuration** section of the CloudBox interface. Here are the steps for each method:

1. **NTP Synchronization**:
   * Go to the **DateTime Configuration** section.
   * Select **NTP** as the synchronization method.
   * Ensure the CloudBox is connected to the internet.
2. **GPS Synchronization**:
   * Select **GPS** as the synchronization method in the **DateTime Configuration** section.
   * Ensure the CloudBox has access to the sky for a GPS signal.
3. **Manual Synchronization**:
   * Choose **DISABLED** in the **DateTime Configuration** section.
   * Manually enter the correct date and time.
   * Set the appropriate **timezone** to ensure the timing data reflects the local time.

## Summary

The CloudBox offers three methods for time synchronization—**NTP**, **GPS**, and **Manual**—each suited to different environments and scenarios. For most events with stable internet, **NTP** is a reliable and automatic method. **GPS** is ideal for outdoor or mobile events where internet access may not be available, and **Manual** synchronization serves as a useful backup option for isolated or controlled situations. Ensuring the correct time synchronization method is used guarantees accurate timing data for any event.


# LED Signals and Alarm Notifications

The **CloudBox** provides clear visual and auditory signals to notify users about system status, battery levels, and temperature conditions. These signals, through the system’s **LEDs** and **alarm sounds**, help users quickly identify issues like low battery or high temperature, ensuring smooth and uninterrupted race timing.

This article will detail the meaning behind the CloudBox's **LED indicators**, as well as the sound alarms triggered for **low battery** and **high temperature** situations.

## LED Signals

The CloudBox uses a combination of two main LEDs—**Power LED** and **Start LED**—to indicate its operational status during boot, normal operation, and error conditions.

### **1. Power LED (Blue)**

* **Solid Blue**: This indicates that the CloudBox is powered on and operational.

### **2. Start LED (Red/Blue)**

* **Solid Red during Boot**: The **Start LED** remains solid red during the first 10 seconds of boot, along with the **Power LED** being blue and the cooler being on.
* **Blinking Red every 1000 ms**: After the first 10 seconds of boot, if the system is OK, the **Start LED** will blink red once every second (1000 ms) to indicate that the CloudBox has completed booting and is functioning normally. The cooler will turn off at this stage.
* **Solid Red**: When the system is in standby and ready for operation after boot, the **Start LED** remains solid red.
* **Blue during Timing Session**: During a timing session, the **Start LED** turns blue to indicate that a session is active.
* **Blinking Red every 250 ms (Reader Issue)**: If the CloudBox cannot detect the RFID reader (or if there’s an issue with the reader), the **Start LED** will blink rapidly (every 250 ms). This indicates the system is searching for the reader or encountering a reader-related issue.
* **Blinking Red every 3000 ms (System Updating)**: If the CloudBox is undergoing a system update, the **Start LED** will blink red every 3000 ms, indicating that the system is updating its firmware or software.

### **3. Other LED Indications**

* **USB Detection**: When a USB Pen Drive is connected for backups, the CloudBox will emit a **light sequence** with the LED flashing every 500 ms for 2 seconds to indicate the drive is recognized and backup processing has started.

## Alarm Sounds and Notifications

The CloudBox is equipped with audible alarms to notify users of critical battery and temperature conditions. These alarms are essential to avoid system failures due to power loss or overheating.

### **1. Low Battery Alarm**

The CloudBox monitors its internal power levels to ensure optimal performance. When the battery voltage drops below specific thresholds, the system triggers alerts and alarms.

* **Optimal Voltage Range**: The optimal voltage range for the CloudBox is **25V to 29V**.
* **Warning Threshold**: When the battery voltage drops to **24V**, a **warning notification** is sent to connected users to alert them of the low power level.
* **Critical Threshold**: If the voltage drops further to **23V**, a **sound alarm** is triggered, warning users that immediate action is required to prevent shutdown. The sound alarm pattern is:
  * **1000 ms ON / 500 ms OFF** (repeating).

This ensures that users have time charge the device before it runs out of battery.

### **2. High Temperature Alarm**

The CloudBox also monitors its internal temperature to avoid overheating. If the temperature exceeds safe limits, the system triggers alarms and turns on its cooling mechanism.

* **Optimal Temperature Range**: The optimal operating temperature for the CloudBox is between **0°C and 60°C**.
* **Warning Threshold**: When the internal temperature reaches **70°C**, a **warning notification** is sent to connected users, and the system's **cooling fan** is activated to prevent further temperature increases.
* **Critical Threshold**: If the temperature reaches **78°C**, a **sound alarm** is triggered to notify users of the critical temperature. This alarm pattern is:
  * **500 ms ON / 500 ms OFF** (repeating).

At this point, the system will either throttle performance to reduce heat or prepare for an emergency shutdown to prevent hardware damage.

## Summary of LED and Alarm Signals

| Condition                       | LED Signal                                      | Alarm Signal                        | Action                                |
| ------------------------------- | ----------------------------------------------- | ----------------------------------- | ------------------------------------- |
| **Power On**                    | Power LED: Solid Blue                           | None                                | System ready                          |
| **Boot Sequence (First 10s)**   | Start LED: Solid Red                            | None                                | Initializing                          |
| **Boot Completed (OK)**         | Start LED: Blinks Red every 1000 ms             | None                                | System ready                          |
| **Timing Session Active**       | Start LED: Solid Blue                           | None                                | Session in progress                   |
| **Reader Not Detected**         | Start LED: Blinks Red every 250 ms              | None                                | Searching for RFID reader             |
| **System Updating**             | Start LED: Blinks Red every 3000 ms             | None                                | Firmware/software update              |
| **USB Detection**               | Start LED: Flashes every 500 ms (for 2 seconds) | None                                | USB drive detected                    |
| **Low Battery Warning (24V)**   | Start LED: No change                            | Warning notification sent           | Replace or charge battery             |
| **Critical Battery (23V)**      | Start LED: No change                            | 1000 ms ON / 500 ms OFF sound alarm | Replace or charge battery immediately |
| **High Temp Warning (70°C)**    | Start LED: No change                            | Warning notification sent           | Cooling fan activated                 |
| **Critical Temperature (78°C)** | Start LED: No change                            | 500 ms ON / 500 ms OFF sound alarm  | Cool down or shut down the device     |

## Conclusion

The **CloudBox** uses a combination of **LED signals** and **alarm sounds** to notify users of system status, battery levels, and temperature conditions. Understanding these indicators ensures that users can respond quickly to prevent downtime or system failures, whether due to power loss or overheating. By paying attention to the **LED patterns** and **alarm signals**, you can ensure that your CloudBox operates smoothly during critical race timing events.


# Connecting your CloudBox with RUFUS Race Manager (locally)

To connect your CloudBox to **RUFUS Race Manager (RRM)** locally, you'll need to set up the local network connection between the CloudBox and the RRM software. This allows for direct communication, enabling seamless timing operations and device control during an event.

To understand how to effectively use the CloudBox as a Local Device in RRM, please refer to the following articles from the **RRM documentation**:

* [Devices Menu](https://help.runonrufus.com/rufus-race-manager/timing-devices-integration/devices-menu): Learn how to access and manage devices connected to your RRM account.
* [Connecting Local Devices](https://help.runonrufus.com/rufus-race-manager/timing-devices-integration/connecting-local-devices): Follow these instructions to connect your CloudBox as a Local Device within RRM.
* [Event-Devices View](https://help.runonrufus.com/rufus-race-manager/timing-devices-integration/event-devices-view): Understand how to view and manage devices during an event, ensuring they are properly configured and sending accurate timing data.

These articles cover everything from adding your CloudBox in RRM to managing devices during events.

## Key **Benefits of Using the CloudBox as a Local Device in RRM:**

1. **Low Latency**: A direct connection ensures minimal data transmission delays.
2. **Offline Operation**: Timing can proceed even if there is no internet connection.
3. **Simplified Setup**: Local connection reduces dependency on external factors, offering greater control.


# Connecting your CloudBox with Wiclax (locally)

As of Wiclax software version **10.1.1151**, the RUFUS CloudBox timing system is fully compatible with Wiclax classification software. This guide explains how to connect your CloudBox locally to the Wiclax software quickly and effortlessly.

## Step-by-Step Guide

### Step 1: Open the Acquisition Window

Launch your Wiclax software and navigate to the **Acquisition** window. This is the main interface used to manage timing data.

<figure><img src="/files/IDfmeazRaDYMVnhlLUfF" alt="" width="293"><figcaption><p>RUFUS Adquisition Menu</p></figcaption></figure>

### Step 2: Add a CloudBox Acquisition

Within the Acquisition window, follow these steps:

* Locate the acquisition toolbar at the top of your interface.
* Click on the **Rufus** option.
* Select **CloudBox** from the dropdown menu.

This action will create a new CloudBox acquisition in your acquisition list.

<figure><img src="/files/gb3K1oWaPdWDglCA77dq" alt=""><figcaption><p>CloudBox Adquisition</p></figcaption></figure>

### Step 3: Configure CloudBox Acquisition Properties

After adding the CloudBox acquisition:

* Select your newly created CloudBox acquisition from the list.
* On the properties panel that appears, enter the connection details.
  * **IP Address**: Typically set to `192.168.1.10`
  * **Port**: Typically set to `8080`

<figure><img src="/files/Jg8e0mvNlRjW0Upr3Dab" alt=""><figcaption><p>Cloudbox Adquisition Properties</p></figcaption></figure>

### Step 4: Connect to CloudBox

* Click on the **Connect** button to establish communication between the Wiclax software and the CloudBox.
* Confirm the status changes to indicate a successful connection.

### Step 5: Start Timing Acquisition

Once connected:

* Click on the **Start Reading** button to begin acquiring timing data from your CloudBox.

Your CloudBox is now actively connected and capturing timing data.

## Helpful Tips:

* Ensure your PC and CloudBox are on the same local network.
* The default IP and port provided (`192.168.1.10`, `8080`) typically work out-of-the-box, but these may vary if you've customized your CloudBox settings.
* You can adjust connection settings anytime in the Acquisition properties panel.

That's it! Your RUFUS CloudBox is successfully connected to Wiclax and ready for your next event.


# Firmware Update

The **CloudBox** is designed to keep its system software up to date automatically. When connected to the internet, the CloudBox checks for available firmware updates. These updates are essential for ensuring optimal performance, security, and access to new features. However, updates are only applied when the user manually selects the option to reboot and install the new firmware. This article will guide you through the firmware update process and what to expect during the update.

**IMPORTANT**: The update **requires a stable internet connection** (4G connectivity is not supported for firmware updates) and the system in **sync with the current date time**. Make sure the CloudBox is connected via **Ethernet** or a reliable **WiFi** network and has the **NTP sync enabled**.

<figure><img src="/files/EhecmUNu9KOD0lO9t5sM" alt=""><figcaption></figcaption></figure>

## Firmware Update Notification

When the CloudBox detects a new firmware version, the update will be shown in the **Status Interface** under the **Updates** section.&#x20;

<figure><img src="/files/nKd2J0pkAz1zJVsFMdrx" alt=""><figcaption></figcaption></figure>

The following information is displayed:

* **New backend version**: The version number of the backend software that is available for update.
* **New front version**: The version number of the frontend software available for update.

The user is notified of the availability of the update but must initiate the update process manually by selecting the **Reboot and Install** option.

## How to Install a Firmware Update

1. **Check for Update Availability**:
   * Go to the **Status Interface** on the CloudBox web dashboard.
   * If a new firmware version is available, it will be displayed in the **System Update Available** section at the bottom of the interface.
2. **Select "Reboot and Install"**:

   * To proceed with the update, toggle the **Reboot and Install** option.
   * The CloudBox will reboot to start the installation of the new firmware. Ensure the device is connected to a stable internet connection during this process.

   **IMPORTANT**: The update **requires a stable internet connection** (4G connectivity is not supported for firmware updates) and the system in **sync with the current date time**. Make sure the CloudBox is connected via **Ethernet** or a reliable **WiFi** network and has the **NTP sync enabled**.
3. **Monitor the Installation Progress**:
   * During the installation, the system will reboot.
   * After rebooting, you can reconnect to the CloudBox by navigating to `http://cloudbox.local:3000` or using the **Ethernet IP address**, for example: `http://192.168.1.10:3000`. The CloudBox interface will display the progress of the update.
4. **Post-Installation**:
   * Once the update is complete, the CloudBox will automatically restart.
   * The system will return to normal operation, and the new firmware versions will be active.

## Automatic Rollback Protection

The CloudBox provides **rollback protection** during the update process. When a new firmware version is installed, the previous version is **backed up and stored** in case of an issue with the new firmware. This allows the user to roll back to the previous version if necessary, ensuring that the device remains operational even in the rare case of a failed update.

## LED Signal During Update

During the firmware update, the **Start LED** will blink **every 3000 ms** to indicate that the system is updating. The CloudBox will not be operational for timing sessions during the update. Once the update is completed and the system reboots, the LED will return to its normal state depending on the system status (solid red for standby or blue during a session).

## Considerations for a Successful Update

* **Stable Internet Connection**: Ensure that the CloudBox has a stable internet connection throughout the update process. **4G connectivity and Wifi are not supported** for firmware updates, so make sure the device is connected via Ethernet to a reliable network.
* **NTP service enabled**: Ensure that the system date and time are current, otherwise the firmware download will fail.
* **Accessing the CloudBox After Reboot**: Once the update process starts and the system reboots, reconnect to the CloudBox via `cloudbox.local` or its fixed IP address.
* **Backup of the Previous Firmware Version**: The CloudBox automatically backs up the current firmware before installing a new one. This ensures that if anything goes wrong during the update, the system can revert to the previous working version.
* **No Timing Sessions During Update**: The CloudBox will not be able to start or stop timing sessions during the update process. Make sure no critical timing tasks are running before initiating the update.

## Summary

The **CloudBox firmware update process** is designed to be simple and secure. When a new update is detected, the user can choose when to install it by selecting the **Reboot and Install** option. The system will then reboot and install the new firmware while backing up the previous version to safeguard against any issues. During the update, the **Start LED** will blink to show that the system is updating, and users can follow the installation progress by reconnecting to the CloudBox web interface. Always ensure the CloudBox has a stable internet connection during the update process for a smooth and successful installation.


# Network Configuration

The **CloudBox** offers flexible network configuration options, allowing users to connect to the system through **Ethernet**, **WiFi**, or **4G**. The most common and reliable method for communication with the CloudBox is through its **Ethernet IP address**, especially for **TCP socket connections**. In this article, we’ll dive deeper into the details of configuring and understanding the CloudBox network setup, reserved IP ranges, subnets, and available ports.

## Ethernet IP Configuration

The **Ethernet IP address** on the CloudBox is a **fixed IP address** that users can configure in the **Network Configuration** section of the CloudBox interface. This fixed IP address ensures that the CloudBox can be accessed consistently, without the IP changing as it might with a DHCP-assigned address.

By default, the CloudBox uses port **8080** for **TCP socket communication**. Users can open a TCP client to communicate with the CloudBox at its Ethernet IP and port **8080**, or a custom port if configured.

**How to Configure the Ethernet IP Address:**

1. Navigate to the **Network Configuration** section in the CloudBox interface.
2. Enter the desired **Ethernet IP address**, **port**, and **subnet**.
3. Save the changes, and the CloudBox will restart to apply the new configuration.

## Gateway Configuration

The **Gateway** setting in the Network Configuration determines how the CloudBox accesses the wider internet when connected via Ethernet.

* If your CloudBox is connected **directly to a local device** (such as a laptop) or is only being used for **local LAN communication**, you can leave the Gateway field empty. The CloudBox will still be fully accessible at its fixed IP address for timing operations.
* If your CloudBox is connected to a **router or switch with internet access**, configuring the Gateway allows the CloudBox to reach external services such as:
  * The **Cloud Timing Service** (for transmitting passings).
  * **NTP servers** (for precise date/time synchronization).
  * **Firmware update servers**.

**Example**\
If your router has the IP address `192.168.1.1`, set this as the Gateway in the CloudBox configuration. The CloudBox will then use this router to access the internet while keeping its fixed IP (e.g., `192.168.1.10`).

**Important Notes**

* Configuring the Gateway requires a reboot of the CloudBox.
* The Gateway is only needed for internet connectivity. For local-only setups (e.g., timing with no cloud or internet dependency), it can remain unset.
* If multiple CloudBox units are connected in the same network, each one should share the same Gateway (router address) but must have **unique fixed IP addresses**.

## Reserved IP Ranges

When configuring your CloudBox, it’s essential to avoid assigning an IP address that falls within reserved ranges. These ranges are used for special purposes (such as internal network use, multicast, or reserved addresses) and should not be assigned to your CloudBox.

* **Loopback**:
  * `127.0.0.0` to `127.255.255.255`
  * Used for internal device communication (loopback).
* **Reader IP Address Range**:
  * `10.0.0.0` to `10.255.255.255`
  * Reserved for connecting to RFID readers. Make sure the RFID reader is on the **10.0.0.2** address.
* **Link-Local**:
  * `169.254.0.0` to `169.254.255.255`
  * Used for self-assigned addresses (automatic IP address assignment when no DHCP server is available).
* **Multicast**:
  * `224.0.0.0` to `239.255.255.255`
  * Used for multicast groups, typically for media or data streaming applications.
* **Reserved for Future Use**:
  * `240.0.0.0` to `255.255.255.254`
  * Reserved for future applications.
* **Broadcast**:
  * `255.255.255.255`
  * Used for network-wide broadcasting.

Be sure to configure the CloudBox with an IP address that doesn’t conflict with these ranges to ensure smooth network operations.

## Available Subnets

When configuring your CloudBox, you can choose from different subnet masks depending on the size of your network. The subnet defines the size of the network by specifying how many devices can be connected within that network.

* **255.0.0.0 (/8)**: Large networks with many devices.
* **255.255.0.0 (/16)**: Medium-sized networks.
* **255.255.255.0 (/24)**: Small networks with up to 254 devices.

**Example:**

If you are setting the CloudBox on an IP range of `192.168.1.x` and you want to limit the network to 254 devices, you would use the **255.255.255.0** subnet.

## Available Ports

The CloudBox offers flexibility when choosing the port number for TCP communication. However, there are a few reserved ports that should not be used.

* The CloudBox supports port numbers between **1024** and **65535**.
* **Reserved Ports**:
  * **Port 2999**: Reserved for backup file downloads.
  * **Port 6379**: Reserved for internal system use.
  * **Port 5000**: Reserved for internal system use.

When setting up TCP connections or any other network services, make sure to avoid these reserved ports.

## Summary

The CloudBox provides robust network configuration options, allowing users to connect via **Ethernet**, **WiFi**, or **4G**. With its **fixed Ethernet IP address**, the CloudBox ensures consistent access for **TCP socket communication**. By understanding reserved IP ranges, available subnets, and port numbers, users can effectively configure their CloudBox for seamless network integration.

To ensure your CloudBox operates smoothly:

* Configure the **Ethernet IP address** appropriately using available subnets.
* Avoid using **reserved IP addresses** and **reserved ports** for system integrity.
* Use the correct **port (8080)** for TCP communication or customize as needed.

By following these guidelines, you’ll ensure your CloudBox is ready for network operations, providing reliable communication for race timing and other system tasks.


# GPS Service

The **CloudBox** is equipped with a built-in **GPS receiver** that allows it to obtain precise geographical coordinates. The GPS functionality is crucial for events where location tracking is necessary, such as marathons, cycling races, or triathlons. This article will dive deep into how the GPS system works on the CloudBox, the different GPS statuses, general information about GPS positioning, and tips for ensuring strong signal quality.

## How GPS Works in the CloudBox

The GPS service on the CloudBox provides real-time location data, which can be viewed through the **GPS Status Interface**. The CloudBox regularly attempts to obtain a valid GPS signal and presents the user with the system’s coordinates when available.

### **GPS Statuses:**

1. **STARTING**:
   * The system is initializing the GPS positioning. At this stage, the CloudBox begins searching for GPS satellites to obtain a signal.
2. **SEARCHING**:
   * No GPS information has been obtained yet. The CloudBox continues to search for a valid signal and waits until it can lock onto enough satellites to provide accurate positioning.
3. **GPS\_ERROR**:
   * The system has received incorrect or incomplete GPS information. It continues searching for a proper signal and will attempt to correct the error by retrying the positioning process.
4. **TIMEOUT**:
   * If a SIM PIN is required, the system will attempt to obtain coordinates up to 10 times with a 10-second delay between each attempt. If it exceeds this retry limit without success, the system will stop searching for GPS coordinates to free up the modem for internet connection purposes (in the statuses **READY** or **READY\_PIN**).
5. **SYSTEM\_LOCATED**:
   * The system has successfully obtained GPS coordinates. A **Google Maps link** is generated and displayed in the GPS interface, allowing users to pinpoint the device’s exact location.

### **GPS and SIM PIN Handling:**

* **With SIM PIN**: The CloudBox will attempt to obtain GPS coordinates 10 times, with a 10-second delay between attempts. If it cannot acquire a valid position after these retries, it stops searching to allow the modem to focus on maintaining the internet connection.
* **Without SIM or SIM PIN**: If no SIM or SIM PIN is present, the system continues searching for GPS coordinates every minute without stopping.

## General Information About GPS Positioning

**GPS (Global Positioning System)** is a satellite-based navigation system that provides accurate location data by triangulating signals from multiple satellites. Devices equipped with GPS receivers, such as the CloudBox, calculate their position based on the time it takes for satellite signals to reach the receiver.

### **Key Factors Affecting GPS Accuracy:**

1. **Number of Satellites**: For optimal accuracy, the GPS receiver needs to connect to at least 4 satellites. The more satellites it can lock onto, the better the accuracy of the positioning.
2. **Signal Interference**: GPS signals can be obstructed by buildings, trees, and even weather conditions. Ensure that the **CloudBox antenna** has a clear view of the sky to minimize interference.
3. **Time to First Fix (TTFF)**: This is the time it takes for the GPS receiver to lock onto satellites and provide a valid position after powering on. TTFF can vary depending on the environment and the receiver’s initial state.

## Ensuring Strong GPS Signal Quality

To ensure that the CloudBox receives the best possible GPS signal, follow these guidelines:

1. **Place the Antenna Outdoors**:
   * For optimal performance, ensure that the **GPS antenna** is placed outside, in an open area with a clear view of the sky. This helps the receiver lock onto satellites faster and more accurately.
2. **Avoid Obstructions**:
   * Buildings, trees, and other large structures can block or reflect GPS signals, reducing accuracy. Position the CloudBox and its antenna in an unobstructed area, away from tall buildings or dense forests.
3. **Weather Conditions**:
   * Heavy cloud cover, storms, or other extreme weather can interfere with GPS signal strength. While the CloudBox will continue searching for satellites, bad weather can result in slower acquisition times or reduced accuracy.
4. **Check GPS Status Regularly**:
   * Monitor the **GPS Status Interface** on the CloudBox to ensure that the system is obtaining valid coordinates. If the system remains in the **SEARCHING** or **GPS\_ERROR** state for an extended period, consider adjusting the placement of the antenna or verifying the system’s configuration.

## Practical Applications of GPS in CloudBox

The GPS functionality of the CloudBox can be applied in a variety of scenarios, including:

1. **Event Tracking**:
   * During events like marathons or cycling races, the GPS data can be used to monitor the position of the timing stations. This ensures that all data is captured from the correct locations and can help provide real-time updates for race officials.
2. **Geolocation-Enhanced Timing**:
   * For remote events or large-scale races, knowing the precise location of the CloudBox devices ensures that the data collected corresponds accurately to specific checkpoints, providing seamless geolocation-based timing.

## Summary of CloudBox GPS Service

<table data-header-hidden><thead><tr><th width="204"></th><th></th><th></th></tr></thead><tbody><tr><td><strong>GPS Status</strong></td><td><strong>Meaning</strong></td><td><strong>Action</strong></td></tr><tr><td><strong>STARTING</strong></td><td>The system is initializing GPS positioning</td><td>Wait for the system to start acquiring a signal.</td></tr><tr><td><strong>SEARCHING</strong></td><td>The system is searching for GPS satellites</td><td>Ensure antenna placement is optimal and in clear view of the sky.</td></tr><tr><td><strong>GPS_ERROR</strong></td><td>Incorrect or incomplete GPS information obtained</td><td>System continues to retry; check for possible obstructions.</td></tr><tr><td><strong>TIMEOUT</strong></td><td>GPS retries exceeded, modem resumes internet connection</td><td>System stops searching after 10 retries if a SIM PIN is present.</td></tr><tr><td><strong>SYSTEM_LOCATED</strong></td><td>GPS coordinates successfully obtained</td><td>Google Maps link is generated for precise location tracking.</td></tr></tbody></table>

To get the most out of the CloudBox’s GPS functionality, ensure the GPS antenna is positioned for the best signal reception and regularly monitor the **GPS Status Interface**. With reliable GPS data, you can provide accurate, location-based timing and event management.


# Backup Rewind Function

The **Backup Rewind function** on the CloudBox allows users to retrieve past **passings** data stored in backup files. This feature is essential for recovering or replaying timing data to connected **TCP clients** and, if the CloudBox is bound to the Cloud, the data is also sent to the **Cloud’s Passing Ingestion service**. This ensures that any retrieved passings are available both locally and in the Cloud for further analysis or reporting.

In this article, we will explain how to use the **Backup Rewind** function through both the **CloudBox user interface** and via a **TCP-connected client**.

## Overview of the Rewind Function

The **Rewind function** enables users to replay historical passings data stored in backup files by specifying a time range. These passings are sent to connected TCP clients as if they were received in real-time. Additionally, if the CloudBox is connected to the **Cloud Service**, all passings retrieved through the rewind process are forwarded to the **Passing Ingestion service** in the Cloud.

## Using the Rewind Function from the CloudBox Interface

1. **Access the Backup Interface**:
   * Navigate to the **Backup Interface** from the CloudBox dashboard.
   * You will see a section dedicated to managing backups, including the **Rewind** function.
2. **Specify the Time Range**:
   * In the **Start Timestamp** and **End Timestamp** fields, enter the time range for the data you want to retrieve.
   * The timestamp format is:

     ```bash
     YYYY-MM-DD HH:mm:ss
     ```
3. **Initiating the Rewind**:
   * Once you’ve set the time range, click **Rewind** to start the process.
   * If no timestamps are provided, the CloudBox will retrieve **all available data** from the backup files.
4. **Rewind Results**:
   * The system will stream the passings data from the specified time range to all connected **TCP clients**. If the CloudBox is bound to the Cloud, the retrieved passings will also be sent to the **Cloud Passing Ingestion service** for synchronization.

## Using the Rewind Function via a TCP-Connected Client

You can also initiate the **Rewind function** programmatically through a **TCP socket connection**, allowing for remote data retrieval and automated operations.

1. **TCP Command for Rewind**:
   * The command to initiate a rewind is as follows:

     ```bash
     REWIND(startTimestamp, endTimestamp)
     ```
   * As with the interface, the **startTimestamp** and **endTimestamp** fields define the time range of the data you want to retrieve, and the format is:

     ```bash
     YYYY-MM-DD HH:mm:ss
     ```
   * If both values are set to `null`, the CloudBox will return **all available data** from the backup files.
2. **Example TCP Command**: To retrieve passings data from **2024-09-18 09:00:00** to **2024-09-18 10:00:00**, the TCP command would be:

   ```bash
   REWIND(2024-09-18 09:00:00, 2024-09-18 10:00:00)
   ```
3. **Receiving the Data**:
   * The passings data is streamed to the **TCP client** as if it were happening in real-time.
   * If the CloudBox is connected to the Cloud, these passings will also be sent to the **Cloud Passing Ingestion service**.
4. **Handling Large Data Requests**:
   * If no time range is specified, the system will attempt to retrieve **all data** stored in backups. This could be a large volume of information, depending on the backup file size. To avoid potential delays, it’s recommended to specify a time range when using the rewind function.

## Rewind and the Cloud Passing Ingestion Service

When the CloudBox is **bound to the Cloud Service**, all passings retrieved through the rewind process are automatically transmitted to the **Passing Ingestion Service**. This ensures that any replayed or retrieved data is synchronized with the Cloud, even if it was not originally transmitted during the live timing session.

This feature provides an additional layer of data reliability, allowing for post-event synchronization with the Cloud and ensuring that all passings, whether captured in real time or retrieved from backups, are available in the Cloud for analysis and reporting.

## Considerations for Using the Rewind Function

* **TCP Clients**: The rewind function only sends data to **connected TCP clients**. Ensure that clients are actively connected before initiating the rewind process.
* **Cloud Synchronization**: If the CloudBox is connected to the **Cloud Service**, all retrieved passings are forwarded to the Cloud’s **Passing Ingestion service**.
* **Time Range Specification**: Specifying a time range can help limit the amount of data retrieved and improve performance. Retrieving all available data may take longer if backups have not been cleaned regularly.
* **Backup Cleanup**: Periodically deleting old backup files can improve the efficiency of the rewind function, especially when retrieving large amounts of data.

## Example Code: Using Rewind via TCP Client in Python, C#, and Node.js

Here’s how to use the **Rewind** function programmatically via a **TCP-connected client** in **Python**, **C#**, and **Node.js**.

***

**Python Example:**

```python
import socket

# Define CloudBox IP and port
cloudbox_ip = '192.168.1.10'
port = 8080

# Create TCP socket
client = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# Connect to CloudBox
client.connect((cloudbox_ip, port))

# Send REWIND command for a specific time range
rewind_command = 'REWIND;2024-09-18 09:00:00;2024-09-18 10:00:00\n'
client.sendall(rewind_command.encode())

# Receive data
while True:
    data = client.recv(1024)
    if not data:
        break
    print(data.decode('utf-8'))

# Close connection
client.close()
```

***

**C# Example:**

```csharp
using System;
using System.Net.Sockets;
using System.Text;

class Program
{
    static void Main(string[] args)
    {
        // Define CloudBox IP and port
        string cloudboxIp = "192.168.1.10";
        int port = 8080;

        // Create TCP client
        TcpClient client = new TcpClient(cloudboxIp, port);

        // Send REWIND command
        string rewindCommand = "REWIND;2024-09-18 09:00:00;2024-09-18 10:00:00\n";
        byte[] data = Encoding.ASCII.GetBytes(rewindCommand);
        NetworkStream stream = client.GetStream();
        stream.Write(data, 0, data.Length);

        // Receive data
        byte[] buffer = new byte[1024];
        int bytesRead;

        while ((bytesRead = stream.Read(buffer, 0, buffer.Length)) != 0)
        {
            Console.WriteLine(Encoding.ASCII.GetString(buffer, 0, bytesRead));
        }

        // Close connection
        stream.Close();
        client.Close();
    }
}
```

***

**Node.js Example:**

```javascript
const net = require('net');

// Define CloudBox IP and port
const cloudboxIp = '192.168.1.10';
const port = 8080;

// Create TCP client
const client = new net.Socket();

client.connect(port, cloudboxIp, () => {
    console.log('Connected to CloudBox');

    // Send REWIND command
    const rewindCommand = 'REWIND;2024-09-18 09:00:00;2024-09-18 10:00:00\n';
    client.write(rewindCommand);
});

// Receive data
client.on('data', (data) => {
    console.log('Received: ' + data);
});

// Close connection when done
client.on('close', () => {
    console.log('Connection closed');
});
```

In this example, the script connects to the CloudBox at IP `192.168.1.10` and requests passings data between **2024-09-18 09:00:00** and **2024-09-18 10:00:00**. If the CloudBox is connected to the Cloud, all retrieved passings will also be sent to the Cloud.

## Summary

The **Backup Rewind function** on the CloudBox is a powerful tool for replaying and retrieving passings data from a specified time range. This function can be used both via the **CloudBox web interface** and through a **TCP-connected client**. When the CloudBox is bound to the Cloud, all passings retrieved during the rewind process are also sent to the **Passing Ingestion service**, ensuring full synchronization between local and cloud data. Regular backup cleaning and careful use of the rewind function will ensure that data is retrieved efficiently and reliably.


# IoT Service

The **IoT service** (Internet of Things) on the CloudBox plays a key role in remotely monitoring and managing the system. This service allows the CloudBox to continuously send its **status** and **configuration parameters** to the Cloud, providing real-time visibility into the system's health and operation. Additionally, the IoT service enables users to perform remote operations such as **START**, **STOP**, and **SHUTDOWN** via the **RUFUS** **Race Manager (RRM)** software or their Cloud account. However, it’s important to note that **passing information** is not transmitted via the IoT service but is instead sent via **HTTP** to the **Passing Ingestion service**.

In this article, we’ll explore how the IoT service works, what data is transmitted, and the various remote commands that can be executed.

## How the IoT Service Works

The CloudBox uses the IoT service to continually communicate with the Cloud. The main function of the IoT service is to keep the CloudBox’s **status** and **configuration** up to date in the Cloud, ensuring that administrators can always view the current state of the device.

### **Key Features of the IoT Service:**

* **Status Transmission**: Every **60 seconds**, the CloudBox sends its full status to the Cloud, including details about the system’s battery level, CPU temperature, GPS information, and other important configuration parameters.
* **Remote Control**: Through the **RRM** or the user’s Cloud account, the IoT service allows the remote execution of critical commands like **START**, **STOP**, and **SHUTDOWN**.
* **IoT Client Status**: The IoT client on the CloudBox manages the connection to the Cloud. The current connection status can be one of the following:
  * **Connected to IoT server**: The CloudBox is successfully connected to the IoT server, and status updates are being transmitted regularly.
  * **Disconnected from IoT server**: The CloudBox has lost connection to the IoT server and is no longer transmitting status updates.
  * **IoT server connection error**: The CloudBox encountered an error while trying to connect to the IoT server. This could be due to internet connectivity issues.
* **Passing Information**: It’s important to note that **passings are not sent via IoT**. Passings data is transmitted to the Cloud via **HTTP** to the **Passing Ingestion Service**.

## Remote Commands via IoT

Through the **RRM** or the user’s Cloud account, the IoT service allows remote control over key operational commands. This is particularly useful for managing the CloudBox from a distance, ensuring flexibility and control during race events or when working in distributed environments.

The following commands can be executed remotely via the IoT service:

1. **START**: This command remotely initiates a timing session on the CloudBox, equivalent to pressing the **START** button on the interface or issuing the **START** TCP command. Once the session starts, the system begins tracking and transmitting passings data.
2. **STOP**: This command remotely stops an active timing session, allowing you to terminate the session from anywhere, provided the CloudBox is connected to the internet. This command ensures a smooth finish to race timing sessions without needing to be physically present at the device.
3. **SHUTDOWN**: This command safely powers down the CloudBox system. It is particularly useful for conserving battery or securing the device at the end of an event. The **SHUTDOWN** process ensures all data is properly saved before powering off.

## IoT Service Status and Troubleshooting

To ensure proper communication between the CloudBox and the IoT server, the system regularly checks the connection status. If there are any issues, the system will notify the user through the **Status Interface**.

**IoT Client Status Messages:**

* **Connected to IoT server**: This status confirms that the CloudBox is actively connected to the IoT server, and data transmission is occurring every 60 seconds.
* **Disconnected from IoT server**: This status indicates that the CloudBox has lost connection with the IoT server, possibly due to a network issue. Status updates will not be transmitted until the connection is restored.
* **IoT server connection error**: The CloudBox encountered a problem while attempting to connect to the IoT server, typically due to internet connectivity issues. In this case, ensure that the device has a stable connection and troubleshoot network settings if needed.

**Troubleshooting IoT Connection Issues:**

* **Internet Connectivity**: The most common reason for IoT server connection errors is a lack of internet access. Ensure that the CloudBox is connected to a reliable WiFi network, Ethernet connection, or 4G (where applicable).
* **Reboot the CloudBox**: If the IoT connection cannot be restored, try rebooting the CloudBox, which will refresh the system and attempt to reconnect to the IoT server.

## IoT and Cloud Synchronization

The IoT service plays a crucial role in ensuring the CloudBox’s status and configuration are always synchronized with the Cloud. This is especially helpful for large-scale events or multiple timing points spread across different locations, as it allows race officials to monitor and manage all timing systems remotely.

* **Real-time Monitoring**: The IoT service allows real-time monitoring of the CloudBox's health and operational status. Through the Cloud or RRM interface, users can view key metrics such as battery levels, CPU temperature, and GPS location.
* **Control via Cloud**: All status updates transmitted via IoT can be viewed in the user’s **Cloud account** or through the **RRM interface**, enabling seamless coordination across multiple devices during race events.

## Summary

The **IoT service** on the CloudBox provides continuous communication with the Cloud, ensuring that users can remotely monitor and control their device. By sending full system status updates every 60 seconds, the IoT service keeps the CloudBox’s operational data synchronized with the Cloud, making it possible to monitor device health and execute remote commands such as **START**, **STOP**, and **SHUTDOWN**.

However, it is important to remember that **passing data is not transmitted via IoT** but rather through HTTP to the **Passing Ingestion service**. If the CloudBox encounters any connection issues, users will be notified through the **IoT client status**, allowing for prompt troubleshooting. By leveraging the IoT service, event organizers and race officials can maintain control over their timing systems from anywhere, ensuring smooth and successful race timing operations.


# 4G Modem

The **4G modem** on the CloudBox provides reliable connectivity for data transmission, ensuring that the system can operate even in remote locations without Ethernet or WiFi networks. In this article, we’ll explore the technical details of the CloudBox's 4G modem, its possible statuses, cellular protocols, and how to configure the SIM PIN.

## 4G Modem Overview

The CloudBox uses a **SIM7600G-H 4G MODEM** to provide 4G connectivity. This modem allows the CloudBox to connect to the internet via a **SIM card**, enabling remote communication and the ability to send race timing data to the Cloud.

### **Key Features:**

* **GNSS Receiver**: Supports GPS/Beidou/GLONASS/GALILEO/QZSS for precise positioning.
* **Cellular Protocols**: LTE CAT-4 4G / 3G / 2G support.
* **LTE Bands**:
  * LTE-FDD: B1/B2/B3/B4/B5/B7/B8/B12/B13/B18/B19/B20/B25/B26/B28/B66
  * LTE-TDD: B34/B38/B39/B40/B41
* **Data Rate**:
  * LTE Cat-4: Up to 50Mbps (Uplink) / Up to 150Mbps (Downlink)
  * 3G (HSPA+): Up to 5.76Mbps (Uplink) / Up to 42Mbps (Downlink)
* **SIM Card Slot**: 2FF (Mini SIM: 25 x 15 x 0.76 mm) supporting 1.8V/3V SIM cards.
* **Antenna Connectors**: LTE main antenna + GNSS antenna for cellular and GPS communication.

## 4G Modem Statuses

The 4G modem operates through a series of statuses that indicate its connection state and operational health. These statuses can help diagnose issues and ensure the modem is functioning properly.

1. **STARTING**: The modem is initializing and preparing for operation.
2. **AT\_OK**: The modem has been detected and is functioning correctly.
3. **RESET\_OK**: The modem has successfully reset and is searching for a SIM card.
4. **IMEI\_OK**: The modem's IMEI (International Mobile Equipment Identity) has been verified.
5. **READY**: The SIM card is ready, and the modem is prepared to connect to the cellular network.
6. **SIM\_PIN**: The SIM card requires a PIN to unlock.
7. **SIM\_PUK**: The SIM card requires a PUK (Personal Unblocking Key) to unlock.
8. **PH\_NET\_PIN**: A custom network PIN is required to connect.
9. **UNKNOWN**: The modem is in an unknown state.
10. **READY\_PIN**: The correct SIM PIN has been entered, and the modem is ready.
11. **NETWORK\_STATUS**: The network status has been successfully obtained.
12. **SIGNAL\_STRENGTH**: The modem has measured the signal strength.
13. **CONNECTING**: The modem is connecting to the network operator.
14. **CONNECTED**: The modem is connected to the network and is operational.
15. **DISCONNECTED**: The connection has ended, and there is no service.
16. **CME\_ERROR**: A modem error has occurred; check the error description for more details.
17. **SIM not inserted**: The SIM card is missing or not inserted correctly.
18. **SIM failure**: There is an issue with the SIM card.
19. **SIM busy**: The SIM card is busy with another operation.
20. **SWIM wrong**: The wrong SIM card has been inserted.
21. **Incorrect password**: An incorrect password or PIN has been entered.

## Network Status and Signal Strength

The **Network Status** provides real-time feedback on the cellular connection. Depending on your environment or SIM card, the CloudBox may report one of the following statuses:

* **0**: No service (only emergency calls are possible).
* **1**: Full service (normal operation).
* **2**: Reserved for future use.
* **3**: Registration denied (the network rejected the connection attempt).
* **4**: Unknown status (the device is out of coverage).
* **5**: Registered, roaming (the device is connected to a network but is in roaming mode).

Signal strength is expressed in **RSSI** (Received Signal Strength Indicator). A higher RSSI value indicates a stronger signal, which is important for maintaining a stable 4G connection, especially in remote locations.

## Configuring the SIM PIN

The CloudBox allows users to configure the SIM PIN via the **Network Configuration** section in the interface. Once the SIM PIN is set, the CloudBox will **restart** to initialize the modem with the correct SIM information.

### **Steps to Set the SIM PIN:**

1. **Access the Network Configuration Interface**: Navigate to the **Network Configuration** section of the CloudBox dashboard.
2. **Enter the SIM PIN**: In the **SIM PIN** field, input the correct PIN for your SIM card.
3. **Save the Configuration**: Once the PIN is entered, click **Set SIM PIN** to save the configuration.
4. **Reboot**: The CloudBox will automatically reboot to apply the SIM PIN and restart the modem.

### **Important Considerations:**

* After setting the SIM PIN, the modem will restart to ensure it initializes with the correct settings.
* If the incorrect SIM PIN is entered multiple times, the SIM may require a **PUK** to unlock it. Contact your cellular provider if this occurs.

## 4G Troubleshooting

If you encounter issues with the 4G connection, the following steps can help troubleshoot the problem:

1. **Check SIM Card Insertion**: Ensure the SIM card is inserted correctly in the **2FF Mini SIM slot**.
2. **Verify SIM PIN**: Make sure the correct SIM PIN is entered. If the wrong PIN is entered too many times, the SIM will be locked and require a **PUK** to unlock it.
3. **Check Signal Strength**: Poor signal strength (low RSSI) can prevent the modem from maintaining a stable connection. Ensure the LTE antenna is properly installed and positioned for optimal signal.
4. **Monitor Status Messages**: Use the modem status indicators to identify issues, such as **CME\_ERROR** or **SIM not inserted**, and take appropriate action based on the status.
5. #### Summary

   The **4G modem** on the CloudBox provides reliable cellular connectivity, ensuring the device can operate and transmit data in remote locations without WiFi or Ethernet. Understanding the various modem statuses, network conditions, and how to configure the **SIM PIN** is essential for maintaining a stable connection. By following the steps outlined in this article, you can ensure that the CloudBox remains connected and fully operational in any location with cellular coverage.

## Summary

The **4G modem** on the CloudBox provides reliable cellular connectivity, ensuring the device can operate and transmit data in remote locations without WiFi or Ethernet. Understanding the various modem statuses, network conditions, and how to configure the **SIM PIN** is essential for maintaining a stable connection. By following the steps outlined in this article, you can ensure that the CloudBox remains connected and fully operational in any location with cellular coverage.


# Bib Filters

Bib Filters allow you to control which participant passings are processed by your CloudBox. By limiting reads to specific bib numbers or ranges, you can focus on the athletes you want to time and reduce noise from unwanted chip reads. This feature is especially useful in multi-event setups or when several races are happening simultaneously.

<figure><img src="/files/UqBkG5z9iWrrJv7PiwwT" alt="Bib filters section"><figcaption><p>Bib filters</p></figcaption></figure>

## How It Works

When enabled, a Bib Filter ensures that **only passings belonging to the specified bib numbers** are accepted and processed. Any chip not linked to a bib in your filter is ignored.

There are two main ways to define your filters:

1. **Quick Paste**\
   You can paste ranges or lists directly into the input field.

   * Use a dash (`-`) for ranges (e.g. `100-120`).
   * Use commas (`,`) for lists (e.g. `10, 25, 33`).
   * Combine them as needed (e.g. `1-10, 50, 100-1100`).

   After clicking **Parse**, the system automatically normalizes the list and adds the ranges.
2. **Add Range**\
   You can manually add a range by specifying a **From** and **To** value.\
   Example: Adding `100` to `120` creates a range that covers all bibs from 100 through 120.

   The order does not matter—CloudBox will normalize the range on save.

<figure><img src="/files/dM3CrxmHJnKueOKe5pN8" alt="" width="374"><figcaption><p>Bib filters add range modal</p></figcaption></figure>

## Managing Filters

* **Enable / Disable**: Each range can be toggled on or off without deleting it.
* **Remove**: Delete ranges completely if they are no longer needed.
* **Clear All**: Instantly remove all filters with one click.
* **Active Bibs Counter**: The system automatically calculates and displays the total number of active bibs covered by your current filters.

## Example Scenario

If you set up the following filters:

* Range `100-120`
* Range `1000-1100`

Your CloudBox will only process passings from bibs within those ranges (total: 122 bibs). Any other bib detected will be ignored.

## Why Use Bib Filters?

* **Focus on relevant participants**: Exclude test chips or athletes from different races.
* **Reduce data noise**: Avoid clutter in your passings list and reports.
* **Improve performance**: Process only the bibs that matter for your event.

## Closing Thoughts

Bib Filters are a powerful way to fine-tune your timing setup. Whether you are running a local 5K or a multi-wave triathlon, filters help ensure that only the right athletes are included in your timing data. By combining them with Cross-Reference Tables, you gain full control over how chips map to bib numbers and which passings are valid.


# Cross-Reference Table

The Cross-Reference Table is a feature designed for **Open systems**—setups where your CloudBox reads not only RUFUS chips but any EPC (Electronic Product Code). With this tool, you can directly map raw EPC codes to bib numbers, giving you precise control over how passings are recognized and classified.

<figure><img src="/files/PVXaNZ64yMIbk3iZUWMJ" alt=""><figcaption><p>Cross-reference tables</p></figcaption></figure>

## How It Works

Every RFID tag has a unique EPC, which may not be tied to your event’s bib numbering by default. The Cross-Reference Table acts as a dictionary: whenever the CloudBox reads a chip, it looks up the EPC in the table and translates it into the correct bib number.

This ensures that regardless of the raw EPC format, the resulting timing data always aligns with the bib numbers in your event.

## Creating a Table

<figure><img src="/files/1Yns8c9pgpnUnmuMqvns" alt="" width="563"><figcaption><p>Add cross-reference table modal</p></figcaption></figure>

1. **Prepare a CSV file**\
   Your file must contain exactly two columns with no header row:

   * Column 1: **EPC**
   * Column 2: **Bib**

   Example (EPCs are automatically normalized: uppercase, no spaces):

   ```
   11100B8C,1
   11100B93,2
   11100B8E,3
   ```
2. **Upload and name your table**
   * Click **Load CSV & Create Table**.
   * Select your CSV file.
   * Provide a descriptive table name (e.g. *RR chips*).
3. **Inspect and Save**
   * The system will preview your data so you can confirm correctness.
   * Save the table to make it available for use.

## Managing Tables

* **Enable**: Only one Cross-Reference Table can be active at a time. When enabled, it overrides all other EPC-to-bib mappings.
* **Inspect**: Review the contents of the table at any time.
* **Delete**: Remove a table when it’s no longer needed.

Each entry in the table must be unique—duplicate EPCs or duplicate bibs are not allowed.

## Example Scenario

Imagine you are timing a race with rental chips from different suppliers. Each tag has an unfamiliar EPC like `11100B91`, `11100B92`, and so on. By loading a Cross-Reference Table that maps these EPCs to bibs `4`, `5`, `6`, the CloudBox ensures that every detection automatically translates into the correct athlete bib number.

## Why Use a Cross-Reference Table?

* **Flexibility**: Integrate third-party chips and rental stock seamlessly.
* **Accuracy**: Guarantee that EPC reads always match your official bib list.
* **Compatibility**: Expand your system to support events beyond RUFUS native chips.

## Closing Thoughts

The Cross-Reference Table is the bridge between raw RFID data and meaningful race results. In Open systems, where EPCs come from a variety of tags, this feature ensures that every athlete is properly recognized. Combined with Bib Filters, you gain full command of which athletes are tracked and how their chip data is processed, no matter the source.


# Antenna Test

The Antenna Test feature allows you to quickly verify that your RFID reader and its connected antennas are working correctly. By running a simple live test, you can ensure that all antennas are detecting tags as expected before starting a race.

<figure><img src="/files/NDtACeqPrXcYDnBIALmC" alt=""><figcaption><p>Antenna test</p></figcaption></figure>

## How It Works

When you start the test, the CloudBox begins reading tags in a dedicated **test mode**. Each connected antenna (up to 8) is represented on screen by a numbered circle. The interface gives you instant visual confirmation of which antennas are active and what they are detecting.

* **Start Test**\
  Begins the antenna check. As soon as tags are read, the corresponding antenna circle turns green.
* **Live Feedback**\
  Inside each green circle you’ll see:
  * The last detected EPC (chip ID).
  * The time since the tag was last seen.
  * The RSSI value (signal strength), when available.
* **Stop Test**\
  Ends the test and clears the results.

## Limitations

* Antenna testing is **disabled while Start Mode is active**. This ensures the test does not interfere with live timing sessions.
* The test is intended for quick validation and troubleshooting. It does not record or save passings into the timing system.

## Example Use Cases

* **Pre-race setup**: Confirm all antennas are correctly wired and positioned before the start.
* **Troubleshooting**: Quickly identify if one antenna is underperforming or disconnected.
* **Signal verification**: Check the approximate strength of reads at different positions using the RSSI value.

## Why Use Antenna Test?

Reliable antenna performance is the foundation of accurate timing. With Antenna Test, you can:

* Eliminate guesswork when installing antennas on the race course.
* Save time during setup with instant visual confirmation.
* Ensure your system is race-ready before the clock starts.

## Closing Thoughts

The Antenna Test is a simple but powerful tool for building confidence in your RFID setup. By verifying every antenna ahead of time, you reduce the chance of missed reads and ensure smooth timing operations on race day.&#x20;


# Introduction to CloudBox Cloud Service

Connecting the **CloudBox** to the **Cloud Service** offers a powerful and flexible way to manage race timing data, monitor system performance, and ensure data reliability across events. By leveraging the Cloud, users can unlock advanced features that improve efficiency, security, and real-time access to data.

The Cloud Service ensures that the CloudBox remains in sync with other timing systems, provides remote control capabilities, and safeguards race timing information even in challenging environments. Here’s a detailed look at the benefits and features of connecting the CloudBox to the Cloud.

## Key Benefits of Connecting the CloudBox to the Cloud

1. **Real-Time Data Synchronization**:
   * When connected to the Cloud, the CloudBox continuously sends race timing data to the **Passing Ingestion service**, ensuring that all passings are securely stored and accessible in real-time. This guarantees that race officials and organizers have immediate access to timing information, no matter the event's location or size.
2. **Remote Monitoring and Management**:
   * Through the Cloud Service, users can remotely monitor the CloudBox’s status, including battery levels, GPS location, and overall system health. This provides race officials the flexibility to manage timing systems across multiple locations without being physically present.
   * The CloudBox also sends its full status and configuration parameters to the Cloud every **60 seconds**, allowing for up-to-date monitoring via the **RUFUS Race Manager (RRM)** or the user's Cloud account.
3. **Remote Control Capabilities**:
   * One of the standout features of the Cloud integration is the ability to remotely issue commands to the CloudBox. Using the **RRM** or a Cloud account, users can send essential commands such as **START**, **STOP**, and **SHUTDOWN** to the CloudBox, enabling full remote control of the timing system.
4. **Data Reliability and Backup**:
   * With the Cloud Service, even if local data transmission fails, the CloudBox continues to store backup files on the device, which can later be uploaded to the Cloud. This ensures data integrity even in cases of connectivity issues or hardware malfunctions. The **Backup Rewind** feature allows users to retrieve missing data and send it to the Cloud for post-race analysis and reporting.
5. **Enhanced Collaboration**:
   * The Cloud Service allows multiple race officials, event organizers, and staff to access the same real-time data. With the ability to monitor multiple timing systems from different locations, teams can collaborate more effectively and make decisions based on accurate, up-to-the-minute information.
6. **Firmware Updates and Maintenance**:
   * The CloudBox can receive automatic **firmware updates** when connected to the Cloud. These updates ensure that the system is always running the latest features and security patches. Updates are only applied when the user manually selects the "Reboot and install" option, providing control over when the device is updated.

## Cloud-Enabled Features

1. **Passing Ingestion service**:
   * As the CloudBox collects timing data, it sends passings directly to the **Passing Ingestion service** over HTTP, ensuring that data is immediately available in the Cloud. This feature provides a real-time stream of passings to the Cloud for quick access and analysis.
2. **IoT Service**:
   * The CloudBox’s **IoT service** continuously sends system status and configuration details to the Cloud, allowing remote users to monitor and control the device. Through the IoT service, users can remotely initiate or stop timing sessions, ensuring complete control over the system from any location.
3. **Cloud Synchronization and Status Reporting**:
   * The CloudBox sends status reports to the Cloud every **60 seconds**. These reports include key performance indicators such as CPU temperature, battery voltage, GPS location, and network connectivity. Users can view this information from their Cloud account or the **RUFUS Race Manager** (RRM) platform.
4. **Automatic Backups**:
   * The CloudBox automatically stores local backups of all passings, ensuring no data is lost even during network interruptions. Once the device reconnects to the Cloud, any missing data can be synced via the rewind function, offering post-event data recovery capabilities.

## Why Use the Cloud Service?

Using the **Cloud Service** transforms the CloudBox from a standalone timing device into a fully connected and integrated system. For race organizers, this means:

* **Improved scalability**: Easily monitor and manage multiple CloudBox devices across large-scale events.
* **Enhanced security**: Keep race data safe with automatic Cloud backups and secure remote control capabilities.
* **Increased efficiency**: Make real-time decisions with the confidence that you have access to the latest timing and system status data.

By leveraging the Cloud, race organizers gain real-time insights into their timing systems and can ensure that race data is always available, backed up, and accurate.


# Binding the CloudBox with the RUFUS Cloud Service

Binding the **CloudBox** to the **RUFUS Cloud Service** is a critical step to unlock the full potential of the Cloud features, including real-time monitoring, remote control, and automatic data synchronization with the Cloud. Once the CloudBox is bound, it can send passings data, system status, and configuration information to the Cloud for seamless management and analysis.

In this article, we will guide you through the steps required to bind your CloudBox with the Cloud Service.

## Why Bind the CloudBox?

Binding the CloudBox allows you to:

* **Synchronize passings data** with the Cloud in real-time.
* **Remotely monitor** system health, including battery levels, GPS location, and connectivity.
* **Control the CloudBox** remotely using commands like **START**, **STOP**, and **SHUTDOWN**.
* **Receive firmware updates** and ensure your device is running the latest software.
* **Automatically back up data** and retrieve it if necessary using the **Rewind** feature.

## Steps to Bind the CloudBox

1. **Obtain the Bind Token**:
   * Log into your **Cloud account** on the Cloud Service platform.
   * Navigate to the  **Devices** section and generate a **bind token**. This token is a unique identifier that securely links your CloudBox to your Cloud account.
2. **Access the Cloud Interface on the CloudBox**:
   * Connect to your CloudBox through the **Ethernet** or **WiFi**.
   * In your browser, navigate to the CloudBox interface by entering `http://cloudbox.local` or the CloudBox’s **fixed IP address**.
   * Once inside the CloudBox interface, go to the **Cloud** section.
3. **Enter the Bind Token**:
   * In the **Cloud Operations** section, you will see a field labeled **Bind Device**.
   * Enter the **bind token** generated from your Cloud account.
4. **Bind the Device**:
   * Click on the **Bind Device** button.
   * The CloudBox will now attempt to connect to the Cloud and bind with your account. If successful, the CloudBox will start transmitting status updates and passing data to the Cloud.
5. **Confirmation**:
   * After binding, the **Device Token** will be displayed on the CloudBox interface, along with the number of passings sent to the Cloud.
   * Your CloudBox is now successfully bound to the Cloud Service, and you can manage it remotely from your Cloud account.

## Unbinding the CloudBox

If you ever need to unbind the CloudBox from the Cloud Service (for example, if you're transferring ownership or reconfiguring your system), you can do so easily:

1. **Access the Cloud Interface**:
   * Navigate to the **Cloud Operations** section within the CloudBox interface.
2. **Click Unbind Device**:
   * Simply click the **Unbind Device** button.
   * The CloudBox will be disconnected from your Cloud account, and it will no longer send data to the Cloud.

## Summary

Binding the **CloudBox** to the **Cloud Service** is essential for enabling real-time data synchronization, remote control, and monitoring features. The process is straightforward: generate a **bind token** from your Cloud account, enter it into the **Cloud Operations** section on the CloudBox, and bind the device. Once connected, you’ll have access to all the powerful features of the Cloud, ensuring your timing system is fully operational and secure.


# Accessing Stored Cloud Timing Sessions

Once your **CloudBox** is connected and synchronized with the **Cloud Service**, all timing sessions are automatically stored and available for review in your **Cloud Account**. This allows you to easily access, analyze, and download timing data from any event your CloudBox has recorded.

## Steps to Access Cloud Timing Sessions

1. **Log in to Your Cloud Account**:
   * Start by visiting the **Cloud** platform and logging in with your credentials.
2. **Navigate to Your CloudBox**:
   * Once logged in, go to the **Devices** section where your **CloudBox** devices are listed.
   * Select the **online representation** of the CloudBox device you want to access.
3. **View Timing Sessions**:
   * Inside the selected CloudBox page, you will see a list of all the **timing sessions** that have been stored in the Cloud.
   * Each timing session is recorded with its specific start and end times, and you can click on any session to view more detailed information.
4. **View Passings**:
   * Within each timing session, you can see all the **passings** stored, including the EPC, timestamp, antenna, and other relevant data for each passing.
5. **Download Timing Data**:
   * Each timing session can be **downloaded in CSV format**. Simply click the **Download CSV** option next to the session you wish to export.
   * The CSV file will contain all the passings for that specific session, allowing you to perform further analysis or integrate the data into race management software.

## Summary

Accessing your stored Cloud timing sessions is easy through your **Cloud Account**. Simply select your CloudBox device, review the list of timing sessions, and download each session in **CSV format** for further use. This ensures that your race timing data is securely stored, easily accessible, and ready for post-event analysis.


# Connecting your CloudBox with RUFUS Race Manager (remote)

The RUFUS CloudBox can be used as a Cloud Device within the RUFUS Race Manager (RRM) system, allowing you to seamlessly integrate RFID-based timing into your race management workflows.

To understand how to effectively use the CloudBox as a Cloud Device in RRM, please refer to the following articles from the RRM documentation:

* [Devices Menu](https://help.runonrufus.com/rufus-race-manager/timing-devices-integration/devices-menu): Learn how to access and manage devices connected to your RRM account.
* [Connecting Cloud Devices](https://help.runonrufus.com/rufus-race-manager/timing-devices-integration/connecting-cloud-devices): Follow these instructions to connect your CloudBox as a Cloud Device within RRM.
* [Event Devices View](https://help.runonrufus.com/rufus-race-manager/timing-devices-integration/event-devices-view): Understand how to view and manage devices during an event, ensuring they are properly configured and sending accurate timing data.

## Key Benefits of Using the Timing App in RRM <a href="#key-benefits-of-using-the-timing-app-in-rrm" id="key-benefits-of-using-the-timing-app-in-rrm"></a>

* **Real-Time Data Synchronization**: All passings collected via the CloudBox are automatically synchronized to your RRM account, ensuring that timing data is accessible and accurate across all devices.
* **Seamless Integration**: Using the CloudBox as a Cloud Device in RRM simplifies the workflow by integrating all timing devices in one management platform.

By following the documentation provided and connecting your CloudBox as a Cloud Device, you can make your race operations more efficient, reliable, and easy to manage.

[<br>](https://help.runonrufus.com/rufus-timing-app/settings-and-configuration/setting-up-tag-types-for-rfid-readers)


# Warning!

## Warning

Before operating the CloudBox and its associated components, it is essential to understand the critical warnings and guidelines to ensure safe and proper use of the system. Following these warnings will help prevent damage to your equipment and ensure accurate, high-quality race timing services.

### Read the Documentation Carefully

Before using the CloudBox system, thoroughly read all the documentation provided. This includes setup guides, operational instructions, and maintenance recommendations.

Operating the system without sufficient knowledge may result in errors, misconfiguration, or potential damage.

### Protect the CloudBox from Extreme Weather Conditions

The CloudBox is designed for outdoor race timing environments, but it must always be protected from extreme weather conditions such as **direct sunlight, excessive heat, heavy rain, and water spray**.

Never place the CloudBox under direct sunlight. Always place the system in a **shaded area** with proper air ventilation.

Be especially careful when placing the CloudBox on hot surfaces such as **asphalt, concrete, or other heat-retaining floors**, as these surfaces can increase the internal temperature of the system. When operating in hot weather, place the CloudBox on a cooler, stable surface or raise it from the ground when necessary.

The CloudBox must also be protected from water exposure. Never leave the system unprotected under heavy rain. Prevent the CloudBox from being hit by shower spray, hose spray, or wind-driven rain.

Use an appropriate protective cover or sheltered location whenever weather conditions may expose the system to water or excessive heat.

### Do Not Manipulate the RFID Reader While Powered

Avoid handling or manipulating the RFID reader while the system is powered on.

Always connect or disconnect the reader from its power source with the system turned off to prevent electrical damage or communication failures.

### Test the System Before Every Event

Never attend a race or timing event without fully testing all system components. Ensure that both hardware components, including the CloudBox, RFID readers, antennas, and tags, and software are functioning correctly.

Familiarize yourself with both the hardware and software aspects of the CloudBox to provide an error-free, high-quality timing service. Lack of system knowledge could lead to serious problems during an event.

### Inform Competitors on Proper Tag Usage

Always educate competitors on the correct placement and use of the tags for their particular event. The success of timing heavily relies on proper tag placement, whether on the body, bicycle, or vehicle.

Incorrectly placed tags can lead to missed readings and increase the system's error margin. Properly installed tags result in a failure rate of less than 0.5%.

### Avoid Improper Tag Placement

Never place tags in untested areas or on surfaces that could interfere with RFID signals, such as:

* Metal surfaces
* Human bodies or water-heavy areas

Improper tag placement can significantly reduce the reader’s ability to detect tags. Always conduct thorough testing before installation and receive approval from the manufacturer if necessary.

### Use Only Approved Accessories and Components

Only use accessories, replacement parts, and tags that are provided or approved by RUFUS.

Do not connect unauthorized accessories or use unapproved RFID tags, as this may cause system malfunctions or inaccurate results.

For any additional components or third-party accessories, obtain express approval from RUFUS before integrating them into your setup.

### Summary

By adhering to these important warnings, you ensure the safe and effective operation of your CloudBox timing system.

Taking the time to properly test the system, protect it from extreme weather conditions, inform competitors, and only use authorized components will help avoid errors and guarantee a successful timing experience.

Always follow the provided documentation and seek assistance from the manufacturer when needed to maintain optimal performance.


# Battery Care

The **CloudBox** uses high-quality **lithium batteries** to ensure reliable performance during race timing events. Proper care and maintenance of these batteries are essential to extend their lifespan and ensure optimal performance. This article will cover key points about the first use, charging, discharging, storage and monitoring, of the CloudBox battery.

## First Use

When you receive a new CloudBox, the lithium battery will have some charge remaining. You can start using the system immediately and recharge the battery after using up the remaining power. After **2-3 full charge and discharge cycles**, the lithium battery will be fully activated, and you’ll achieve the battery’s full capacity and performance.

## Charging the Battery

**Proper charging habits** are essential for maintaining the long-term health of the CloudBox battery. Follow these tips to charge your device correctly:

1. **Unplug When Fully Charged**:
   * When the battery reaches full charge, **unplug the charger** as soon as possible to avoid slow trickle charging. Leaving the battery connected at full charge for extended periods can increase the battery's stress level, which may lead to degradation over time.
2. **Avoid Recharging When Already at 80% or Higher**:
   * If the battery level is already at **80% or higher**, it’s best not to recharge it immediately before use. Instead, wait until the battery is lower to recharge for better long-term performance.
3. **Charge the Battery Above 30%**:
   * If the battery level is low, make sure to recharge it to at least **30% or higher** before using the CloudBox again. Avoid charging the battery only partially (e.g., 20%) and then using it, as this can impact performance.
4. **Post-Charge Wait Time**:
   * After fully charging the CloudBox, let it rest for about **30 seconds** before putting it back into use. This allows the battery to stabilize, ensuring better performance during operation.
5. **Temperature Considerations**:
   * The charging temperature for lithium batteries should be between **0°C and 45°C**, and the discharge temperature should be between **-20°C and 60°C**. Always be mindful of these temperature limits to prevent damage.

## Discharging the Battery

**Avoid over-discharging** the CloudBox battery, as this can cause permanent damage and reduce the battery's overall capacity.

1. **Charge Immediately When Low**:
   * When the CloudBox indicates that the battery level is low, start charging it immediately. Continuous usage on a low battery can lead to an irreversible loss of capacity.
2. **Impact of Environment**:
   * **High temperature and humidity** can accelerate the self-discharge rate of lithium batteries. Make sure to store and operate the CloudBox in a controlled environment to prevent this from happening. The ideal operating temperature is **0°C to 20°C**.

## Storing the Battery

If you need to store the CloudBox for an extended period, follow these guidelines to maintain battery health:

1. **Storage Charge Level**:
   * Store the CloudBox battery at **50-80% charge** if you plan to store it for a long time. This ensures the battery remains in good condition while minimizing stress on the cells.
2. **Recharge Every Three Months**:
   * Lithium batteries naturally self-discharge over time. To avoid excessive capacity loss, **recharge the battery every three months** during long-term storage. This helps prevent irreversible capacity loss caused by self-discharge.
3. **Optimal Storage Environment**:
   * Store the CloudBox in a dry environment with temperatures between **0°C and 20°C**. Avoid storing the CloudBox in extremely hot or humid conditions, as this can accelerate battery degradation.

## Monitoring the CloudBox Battery and Charging Status

### **When the System is On:**

To check if your CloudBox is charging while powered on:

* Go to the **STATUS** interface in the CloudBox dashboard.
* Look for the **hasPower** indicator. If it shows **true**, your CloudBox is charging.

### **When the System is Off:**

To check the charging status while the system is off:

* Press and hold the **START** button.
* If the **START LED** flashes **every 1 second**, this indicates the system is actively charging.

By following these steps, you can ensure your CloudBox is properly charging both when it’s on or off.

## Summary

By following these simple guidelines for **charging**, **discharging**, and **storing** the CloudBox battery, you’ll extend its lifespan and maintain peak performance. Proper battery care ensures that your CloudBox will be ready for action whenever you need it, whether it’s at the start of a major race or during long-term storage between events.


# Taking Care of your CloudBox

Proper care and maintenance of your CloudBox are essential to ensure optimal performance and long-term durability.

The CloudBox is built for race timing environments, but it still requires careful protection from environmental conditions, improper handling, and accidental damage during events. In this article, we’ll cover best practices for protecting the system from water, heat, dust, and other potential hazards, as well as tips for taking care of the system during races.

## Environmental Considerations

### Water Exposure

While the CloudBox includes protection for its internal components, the system is **not waterproof**.

To prevent damage, always protect the CloudBox from rain, splashes, and water spray during outdoor races. We recommend using a waterproof cover that fits over the system or placing it in a sheltered location where water cannot directly reach the unit.

Never leave the CloudBox unprotected under heavy rain. Also prevent the system from being hit by shower spray, hose spray, or wind-driven rain.

If the system gets wet, immediately dry any visible water with a cloth. If the CloudBox powers off due to significant water exposure, do not attempt to power it on until you have contacted RUFUS Support for further assistance.

### Heat and Direct Sunlight

Prolonged exposure to high temperatures can reduce the lifespan of the internal lithium batteries and affect overall system performance.

Never place the CloudBox under direct sunlight. During races, always place the system in a **shaded area** with proper air ventilation.

Be especially careful when placing the CloudBox on hot surfaces such as **asphalt, concrete, or other heat-retaining floors**. These surfaces can significantly increase the temperature around the system, especially during warm weather. When needed, raise the CloudBox from the ground or place it on a cooler, stable surface.

**Storage recommendations:**

* Do not store the CloudBox in areas where temperatures exceed 80°F / 26°C, especially for extended periods.
* Avoid leaving the CloudBox inside hot vehicles, warehouses, or storage rooms exposed to high temperatures.
* Store the system in a dry, ventilated place away from direct sunlight.

### Dust and Dirt

Allowing dust and dirt to accumulate on the CloudBox can lead to issues and may affect internal components through the ventilation slots.

After each event, use a slightly damp cloth to clean off any visible dirt or dust that has accumulated on the CloudBox.

Regular cleaning prevents buildup and helps the system continue to function smoothly.

## Battery Care

As the CloudBox ages, the internal lithium batteries will naturally experience a decrease in capacity. To maximize the lifespan of the battery, follow these guidelines:

* Avoid charging the system while using the RFID reader, as this increases strain on the battery and can reduce its life over time.
* Disconnect the charger once the battery is fully charged to prevent unnecessary charging cycles.
* Avoid complete discharges. Keeping the battery charged, especially during storage, is key to preserving battery life.
* Store the system with a charged battery to prevent power-related issues during the next race.

For more detailed battery care instructions, refer to the article on **Battery Care**.

## Care During a Race

On race day, your CloudBox may be exposed to various environmental and operational challenges. Follow these best practices to protect the system during the event.

#### Place the CloudBox in a Safe and Protected Area

Choose the CloudBox location carefully before starting the event.

The system should be placed in a shaded, ventilated, and stable area. Avoid direct sunlight, heavy rain exposure, water spray, and hot floors such as asphalt or concrete.

Make sure the selected location protects the CloudBox from weather conditions while still allowing proper cable routing and safe access to the antennas and reader.

#### Delimiting the Space

Athletes and spectators, especially children, tend to move freely around the race area and may interfere with sensitive equipment. It’s important to set up clear boundaries around your CloudBox and antennas to keep the area safe.

Use traffic cones, barriers, or caution tape to establish a perimeter around the timing equipment, ensuring that athletes and the public do not unintentionally damage the system.

#### Keep the Lid Closed

When the CloudBox is actively in use during a race, keep the reader lid closed.

This helps prevent dirt, water, or accidental contact from damaging internal components. It also reduces the risk of curious passersby interfering with the system.

#### Protecting the Antennas

The RFID antennas play a crucial role in detecting athlete passings. To ensure optimal performance:

* Keep athletes and the public away from the antennas.
* Make sure no one stands on or in front of the antennas, as this can compromise timing accuracy.
* Remember that bodies, especially the human body, absorb radio waves, which reduces the RFID reading range.

## Summary

Taking care of your CloudBox ensures that the system will last for many race events, providing accurate and reliable timing services.

Keep the system dry, cool, shaded, ventilated, and clean. Always protect it from heavy rain, water spray, direct sunlight, excessive heat, and hot surfaces such as asphalt or concrete.

During races, take precautions to protect the CloudBox, RFID reader, antennas, and cables from accidental damage. Following these guidelines will help you get the most out of your CloudBox and avoid unnecessary downtime or repairs.


# General Recommendations

Proper handling and maintenance of the CloudBox and its associated components are crucial for ensuring reliable and long-lasting performance.

The following general recommendations cover key aspects such as electrostatic protection, temperature and humidity considerations, weather protection, handling and connecting cables, and synchronization of devices.

Follow these guidelines to keep your CloudBox in optimal condition and avoid potential issues during race events.

## Protection and Handling

### Electrostatic Sensitivity

The reader components are sensitive to electrostatic discharges.

Handle the reader and antennas with care and avoid exposing them to sudden shocks or vibrations, as this can damage sensitive internal components.

### Avoid High Humidity Environments

Prolonged exposure to high humidity can affect the performance and sensitivity of the reader and antennas.

Always use and store the CloudBox in a dry environment. Avoid storing or operating the system in areas with high moisture levels.

### Temperature, Sunlight, and Heat

Do not expose the CloudBox to direct sunlight or high temperatures for extended periods, as this can damage the system.

Never place the CloudBox under direct sunlight during an event. Always place the system in a **shaded area** with proper air ventilation.

Be especially careful when placing the CloudBox on hot surfaces such as **asphalt, concrete, or other heat-retaining floors**. These surfaces can increase the temperature around the system and may contribute to overheating or reduced battery lifespan.

Avoid leaving the CloudBox or its components in hot environments, such as inside vehicles, warehouses, or storage areas, as this can lead to partial or complete failure of the reader or other internal components.

Very low temperatures may affect battery performance and reduce the overall sensitivity of the reader. Keep the system at moderate temperatures whenever possible for optimal performance.

### Rain and Water Protection

The CloudBox must always be protected from water exposure.

Never leave the system unprotected under heavy rain. Prevent the CloudBox from being hit by shower spray, hose spray, or wind-driven rain.

When using the CloudBox outdoors, place it in a sheltered location or use an appropriate protective cover that prevents water from reaching the unit directly, while still allowing proper air ventilation.

If the CloudBox gets wet, dry any visible water immediately with a cloth. If the system powers off after significant water exposure, do not attempt to power it on again until you have contacted RUFUS Support.

## Cable Management and Connections

### Antenna Terminals

There is high voltage on the antenna terminals. Avoid handling these terminals while the reader is powered on, as it can be harmful to your health.

Do not connect or disconnect antennas while the reader is in Start Mode. Always ensure that the reader is powered off before attaching or detaching antennas.

### Secure and Properly Connect Cables

Always ensure that cables are securely connected to their respective ports, but do not force or overtighten them.

For most ports, such as USB, it is safe to connect and disconnect while the CloudBox is powered on. However, never disconnect any cable from its port while the reader is on, except for USB cables.

Keep the antenna terminals clean, and avoid excessive pressure when connecting or disconnecting the antennas.

### Handling Antennas and Cables

Antennas are water-resistant and can be used under rainy conditions. However, never submerge antennas in water, as this can damage both the antennas and the reader.

When storing antennas, avoid bending or sharply folding the cables. Always keep them in smooth curves, store them in a dry, protected area, and cover connectors with the provided caps to protect them when not in use.

Ensure that cables do not get pressed or damaged by the weight of the antennas or any other object. Always route cables securely to avoid wear and tear.

## Operation and Synchronization

### Reader Synchronization

Ensure the CloudBox’s time is always synchronized with the local event time and the PC or system processing the timing data, whether offline or through backups.

Before any timing event, verify that all readers are correctly synchronized to avoid timing discrepancies.

### Proper Power Cycling

Always perform the shutdown process via the **Shutdown** option in the CloudBox interface before powering off the system.

Do not use the physical power button for abrupt shutdowns, as this can cause errors during the next boot-up sequence.

Allow at least 15 seconds between powering off and restarting the reader to ensure proper boot procedures.

## Network and Device Management

### Avoid IP Conflicts

If using more than one CloudBox or reader in the same network, ensure that each device has a unique ID to avoid network conflicts caused by duplicate IP addresses.

Reserved IP addresses should not be assigned to any other devices on the network. Conflicting IP addresses between devices can disrupt communication and lead to data loss.

### Pendrive Usage

You can safely connect or disconnect a USB pendrive while in the main menu.

Never connect or disconnect a pendrive during a download process, as this could cause data corruption.

## Recommendations for Race Day

### Protect Your Equipment

During events, use cones, caution tape, barriers, or other methods to create a clear boundary around the CloudBox and antennas. This helps prevent athletes, spectators, or children from tampering with or damaging the system.

Keep the reader lid closed on the CloudBox when it is actively being used to protect it from dirt, water, or accidental contact.

### Protect the CloudBox from Weather Conditions

Before starting the event, choose a safe and protected location for the CloudBox.

Place the system in a **shaded, ventilated, and stable area**. Avoid direct sunlight, heavy rain exposure, water spray, and hot floors such as asphalt or concrete.

If the race area is exposed to rain, wind, or intense heat, use a protective setup that shields the CloudBox from water and direct sun while allowing air to circulate around the system.

Do not cover the CloudBox in a way that blocks ventilation or traps heat inside the unit.

### Antenna Setup

Ensure athletes do not stand or park in front of or over the antennas.

The human body absorbs radio signals, which can reduce the effective reading range and negatively impact the system’s performance.

## Summary

By following these general recommendations, you will ensure that your CloudBox remains in optimal working condition.

Proper handling of cables, avoiding extreme environmental conditions, protecting the system from direct sunlight, heat, heavy rain, and water spray, ensuring synchronization, and carefully managing network settings are essential for a successful and error-free race timing experience.


# Special Note on UHF Cables

In any RFID-based timing system like the **CloudBox**, the **UHF cables** are vital components that ensure the smooth transmission of power and data between the reader and antennas. Proper handling, maintenance, and storage of these cables are critical for the overall success and reliability of your timing operation.

## Why UHF Cables Are Important

UHF cables are responsible for transmitting the **power generated by the reader** to the antennas. They play a key role in ensuring that the RFID system operates at its full potential. Any damage to the cables can result in **loss of signal strength** and **poor performance** of the antennas, which may lead to missed athlete passings during races.

## Key Recommendations for UHF Cable Care

1. **Avoid Sharp Bends or Forceful Handling**
   * **Never bend UHF cables sharply** or apply excessive force when handling them. Cables contain delicate internal wiring that can become damaged if bent or twisted in the wrong way.
   * When rolling or unrolling cables, always do so gently to prevent internal breakages that can cause **power transmission loss**.
2. **Keep Connectors and Cables Clean and Dry**
   * **Moisture** can be highly damaging to both the cables and connectors, leading to corrosion and performance degradation.
   * Always keep the cables in **dry environments**, and ensure connectors are free from dust, dirt, and humidity. Use protective covers when the cables are not in use.
3. **Check for Internal Cable Damage**
   * Over time, repeated improper handling or poor storage can cause **internal damage** to cables, which may not be immediately visible. Damaged cables can result in a significant loss of transmission power, reducing the overall performance of the RFID system.
   * Regularly **inspect** cables for signs of wear or damage, and if you notice any drop in antenna performance, consider testing or replacing the cables.
4. **Avoid Cable Pressure**
   * **Never press or crush the cables** under the weight of the antenna or other heavy objects. Ensure that cables are laid in a **safe, unobstructed path** underneath or around the antennas during setup.
   * Protect the cables by placing them in the designated space below **floor antennas** or securing them away from foot traffic.
5. **Store Cables Properly**
   * After each event, **store cables correctly** by coiling them in loose, smooth loops. Ensure the cables are kept in a **dry, protected area**, away from sharp objects that might puncture or damage them.
   * Using the **provided protective covers** for connectors is highly recommended to prevent dust and moisture buildup.

## Why Cable Maintenance is Critical

The **cables are an integral part** of the entire CloudBox system. Even though they may seem like minor components, they are just as important as the reader and antennas themselves. **Damaged or neglected cables can result in reduced signal strength**, inaccurate race timing, and potentially missed athlete passings.

To ensure a successful timing operation, make UHF cable care and maintenance a priority. Properly cared for cables will last longer, transmit power more efficiently, and deliver consistent performance in even the most challenging environments.

## Summary

**Take care of your UHF cables** to maintain the accuracy and reliability of your race timing system. Avoid sharp bends, keep them clean and dry, check for internal damage, and store them properly to protect the integrity of your timing setup. Always remember: **the cables are a fundamental part of the system—take care of them!**


# FAQ

Here’s a collection of common questions that race timers might have after reading through the CloudBox help documentation. These questions cover a wide range of topics related to setup, operation, maintenance, and troubleshooting.

## **1. How do I know the current IP address of my CloudBox?**

The CloudBox uses a **fixed IP address** for Ethernet connections, which is displayed on the CloudBox’s **interface**. If connected via an external WiFi network, the IP address will be assigned via **DHCP**. To determine the Ethernet IP address, check the **SSID** of the WiFi Access Point, or access it via the **Status** interface.

***

## **2. Can I change the IP address of my CloudBox?**

Yes, the Ethernet IP address is configurable. Navigate to the **Network Configuration** section of the CloudBox interface to change the IP address, subnet, and port. The system will restart for the changes to take effect.

***

## **3. How can I access the CloudBox interface if there are multiple CloudBoxes on the same network?**

When multiple CloudBoxes are on the same network, you should access each CloudBox via its **unique IP address** rather than `cloudbox.local`, as the domain `cloudbox.local` is shared between all CloudBoxes. Always use the specific IP address for each device.

***

## **4. What happens if I start a timing session with the reader not properly connected?**

If the reader is not detected or incorrectly connected when you try to start a session, you will receive a **READERNOTOK** response. Check the connection between the reader and the CloudBox and ensure it is properly configured before restarting the session.

***

## **5. How do I bind my CloudBox to the Cloud Service?**

To bind your CloudBox, obtain a **bind token** from your Cloud account and enter it in the **Cloud Operations** section of the CloudBox interface. Once bound, the CloudBox will start sending timing data and system status to the Cloud for remote monitoring and management.

***

## **6. Can I use the CloudBox in a location without Ethernet or WiFi?**

Yes, the CloudBox is equipped with a **4G modem** that can provide internet connectivity in areas where Ethernet or WiFi are not available. Ensure you have a compatible SIM card inserted and configured correctly, and check the modem status for a **CONNECTED** indication.

***

## **7. How do I update the firmware of my CloudBox?**

The CloudBox automatically detects firmware updates when connected to the internet. If an update is available, you will see a notification on the **Status** interface. You can choose to **Reboot and install** the update, which will apply the new firmware and restart the system.

***

## **8. Can I retrieve old race data from the CloudBox?**

Yes, you can use the **Rewind function** to retrieve passings stored in the CloudBox’s backup files. You can initiate this either via the **Backup interface** or through a TCP-connected client. If the CloudBox is bound to the Cloud, all retrieved passings will also be sent to the **Passing Ingestion service**.

***

## **9. What is the best way to care for the CloudBox battery?**

To maximize the life of your CloudBox battery, avoid charging it while using the reader, disconnect it once fully charged, and always store the system with a partially charged battery (between **50-80%**). Never leave the battery fully discharged for long periods, and recharge it every three months during storage.

***

## **10. How do I protect the CloudBox and antennas during a race?**

To protect the CloudBox during a race, use **barriers or cones** to create a boundary around the system and antennas. Keep the **lid closed** when the system is in active use to prevent dirt, water, or accidental interference. Ensure that athletes do not stand or walk near the antennas, as this can affect the reading range.

***

## **11. What should I do if my CloudBox gets wet?**

If the CloudBox is exposed to water, immediately dry any visible moisture. If the system powers off due to water exposure, **do not attempt to power it back on**. Contact **RUFUS Support** for further assistance to avoid damaging the internal components.

***

## **12. Can I operate the CloudBox in extreme temperatures?**

The CloudBox should not be exposed to extreme temperatures for prolonged periods. The ideal operating temperature is between **0°C and 45°C**. Extremely high or low temperatures can affect battery performance and reduce the system’s reliability.

***

## **13. How do I properly handle and store UHF cables?**

UHF cables should be handled with care. **Avoid sharp bends** and pressure on the cables, and never disconnect them while the reader is powered on. Store cables in a dry area, coiled gently, and always use protective caps on connectors when not in use to prevent moisture or dirt from entering the cable ends.

***

## **14. Can I use more than one CloudBox on the same network?**

Yes, but you must ensure that each CloudBox has a **unique ID** and a non-conflicting IP address. Duplicate IP addresses on the same network can cause communication errors and potential loss of data.

***

## **15. What happens if the GPS signal is weak or unavailable?**

If the CloudBox is unable to obtain GPS data, it will continue to search for a signal. If a **SIM PIN** is required, the system will attempt to locate GPS coordinates **10 times** with a delay between attempts. If no SIM is inserted, the system will continue searching every minute.

***

## **16. Can I control the CloudBox remotely?**

Yes, once the CloudBox is bound to the Cloud, you can use the **IoT service** to remotely issue commands such as **START**, **STOP**, and **SHUTDOWN**. This allows for full control of the timing session from your Cloud account or through the **RUFUS Race Manager (RRM)**.

***

## **17. Can I connect and disconnect a USB pendrive at any time?**

You can safely connect and disconnect a USB pendrive. However, **do not** connect or disconnect the pendrive during a download process, as this can corrupt the data or cause the system to crash.

***

## **18. What should I do if I receive a READERNOTOK error?**

A **READERNOTOK** error indicates that the reader is either not configured correctly or not connected. Check the connections and configuration in the **Reader Configuration** section of the CloudBox interface, and ensure that the reader is properly powered.

***

## **19. How do I know if my CloudBox is overheating?**

The CloudBox will trigger a **high temperature alarm** if the internal temperature exceeds **70°C**. If the temperature reaches **78°C**, an audible alarm will sound, and the system will automatically activate the fan to cool down.

***

## **20. What does the "No service" network status mean?**

If the network status displays **No service** (status code 0), it means the 4G modem cannot connect to a network, and only emergency calls are possible. Check the **SIM card**, antenna placement, and signal strength to troubleshoot the issue.


# Common Problems and Troubleshooting

Even with proper care and maintenance, occasional issues may arise when using the CloudBox system. Here’s a list of common problems that timers might encounter during setup or operation, along with troubleshooting steps to help resolve them.

## **1. Problem: Reader Not Detected (READERNOTOK Error)**

**Symptoms**:

* The system shows a **READERNOTOK** error during startup or when attempting to start a timing session.

**Possible Causes**:

* The reader is not properly connected to the CloudBox.
* The reader model is not correctly configured in the CloudBox settings.
* The reader may be powered off or malfunctioning.

**Troubleshooting**:

* Check the **cable connections** between the reader and the CloudBox.
* Ensure the reader is powered on and receiving the correct voltage.
* Verify that the **reader model** is correctly set in the **Reader Configuration** section of the CloudBox interface.
* If using multiple antennas, ensure they are connected to the correct ports (e.g., start with port 1 for single antenna setups).
* Restart the CloudBox and attempt to reconnect the reader.

***

## **2. Problem: CloudBox is Not Accessible via cloudbox.local**

**Symptoms**:

* Unable to access the CloudBox interface through `http://cloudbox.local`.

**Possible Causes**:

* Multiple CloudBox devices are connected to the same network, causing a conflict.
* The DNS service on your computer may not resolve the address properly.

**Troubleshooting**:

* If multiple CloudBoxes are on the same network, access each one via its **IP address** instead of `cloudbox.local`.
* Use the **fixed Ethernet IP address** to connect directly to the CloudBox (e.g., `http://192.168.1.10`).
* Ensure your device is connected to the same network as the CloudBox (Ethernet or WiFi).
* Clear your browser cache or try a different browser.

***

## **3. Problem: Cannot Connect to the Cloud**

**Symptoms**:

* The CloudBox fails to connect to the Cloud and shows an **IoT server connection error** or **No internet connection**.

**Possible Causes**:

* The CloudBox does not have an active internet connection (via Ethernet, WiFi, or 4G).
* Network settings may be incorrect.
* The 4G SIM card is not properly inserted or configured.

**Troubleshooting**:

* Verify that the CloudBox is connected to a network (Ethernet, WiFi, or 4G).
* If using WiFi, check that the correct **SSID and password** are entered in the **Network Configuration** section.
* If using 4G, check the **SIM card status** in the **System Status** section. Ensure the SIM PIN is entered if required.
* Test the internet connection by pinging a known website or IP address from a device on the same network.
* Restart the CloudBox to reinitialize the network connection.

***

## **4. Problem: GPS Not Acquiring Location**

**Symptoms**:

* The GPS status shows **SEARCHING** or **GPS\_ERROR** and does not locate the device’s position.

**Possible Causes**:

* The GPS antenna is not correctly connected or placed in a poor location.
* Obstructions (e.g., buildings or trees) may be interfering with GPS signals.
* The SIM PIN may not have been entered (if required).

**Troubleshooting**:

* Ensure the **GPS antenna** is connected and placed in an open area, ideally outside, where it has a clear view of the sky.
* Check the **GPS status** in the **System Status** interface. If a SIM PIN is required, ensure it is entered correctly.
* Wait a few minutes, as the GPS may take time to acquire a signal, especially in a new location.
* If the GPS does not resolve, restart the CloudBox and try again.

***

## **5. Problem: Battery Drains Quickly**

**Symptoms**:

* The CloudBox’s battery discharges faster than expected, or the system powers off unexpectedly.

**Possible Causes**:

* The battery may have degraded over time.
* The system is being operated in extreme temperatures.
* The battery is not properly charged, or the charging method is incorrect.

**Troubleshooting**:

* Avoid using the CloudBox in **extreme heat or cold**, as these conditions can reduce battery performance.
* Ensure the battery is fully charged before use, and unplug the charger once the battery is fully charged.
* Check the **Battery Care** article for proper maintenance practices to extend battery life.
* If the battery shows signs of severe degradation, consider replacing it.

***

## **6. Problem: Antennas Not Reading Tags Correctly**

**Symptoms**:

* Missed passings or inconsistent tag readings during a race.

**Possible Causes**:

* The antennas are not properly positioned or connected.
* The athletes’ TAGs are improperly placed.
* Obstructions are blocking the signal, such as people or objects standing near the antennas.

**Troubleshooting**:

* Ensure the antennas are **properly connected** and positioned. Antennas should be clear of obstructions and facing the correct direction.
* Check that the TAGs are **correctly placed** on the athletes. Misplaced tags (e.g., on metal surfaces) can reduce reading accuracy.
* Keep **spectators and athletes** from standing too close to the antennas, as the human body can absorb radio signals and reduce the effective reading range.

***

## **7. Problem: Unable to Rewind Backup Data**

**Symptoms**:

* The CloudBox fails to rewind backup data or the rewind function takes too long.

**Possible Causes**:

* The backup folder is too large, causing the rewind operation to take longer than expected.
* There are no backup files available.

**Troubleshooting**:

* Clear unnecessary backups regularly to reduce the size of the backup folder.
* Perform the rewind operation through the **CloudBox interface** or using the **TCP socket** commands, specifying a **start** and **end timestamp** if necessary.

***

## **8. Problem: Firmware Update Fails**

**Symptoms**:

* The CloudBox fails to update its firmware, or the system becomes unresponsive during an update.

**Possible Causes**:

* The CloudBox does not have a stable internet connection during the update.
* The system was powered off or lost connection during the update process.

**Troubleshooting**:

* Ensure the CloudBox has a **stable internet connection** before starting the update.
* Allow the update process to finish without interruption. The system will reboot automatically when the update is complete.
* If the update fails, try again after restarting the CloudBox and ensuring the network connection is stable.

***

## **9. Problem: USB Pendrive Not Detected**

**Symptoms**:

* The CloudBox does not recognize a USB pendrive when inserted, or fails to save backup files to the pendrive.

**Possible Causes**:

* The USB pendrive is not formatted correctly.

**Troubleshooting**:

* Ensure the pendrive is **formatted to FAT32** and has a simple name (e.g., "PEN\_BACKUPS").
* If the issue persists, try a different USB drive or restart the CloudBox.

***

## **10. Problem: High Temperature Warning**

**Symptoms**:

* The CloudBox triggers a high-temperature warning and powers down unexpectedly.

**Possible Causes**:

* The system is operating in a hot environment or lacks proper ventilation.
* The fan is not functioning, or the ventilation slots are blocked.

**Troubleshooting**:

* Ensure the CloudBox is placed in a **well-ventilated area**, away from direct sunlight and heat sources.
* Check that the **cooling fan** is functioning correctly and that the ventilation slots are free of obstructions.
* If the system overheats frequently, consider lowering the ambient temperature or using additional cooling methods.

***

## 11. Problem: Unable to Connect to IoT Service

**Symptoms**:&#x20;

*IoT Status: false*\
*Message: Error connecting with IoT server: Failed to connect: aws-c-io: AWS\_IO\_TLS\_ERROR\_NEGOTIATION\_FAILURE, TLS (SSL) negotiation failed*

**Possible Causes**:

* The system’s **date and time** are incorrect, causing a failure during TLS negotiation for secure connections to the IoT server.

**Troubleshooting**:

1. **Check the CloudBox Time**:
   * Access the **STATUS** interface to verify the date and time settings.
2. **Set Correct Time**:
   * Use the **NTP**, **GPS**, or **Manual** time synchronization options in the **CONFIG** interface to correct the time.
3. **Restart the CloudBox**:
   * After updating the time, restart the system to attempt reconnecting to the IoT service.

## Summary

This list of common problems and troubleshooting tips should help resolve most issues that may arise during the operation of your CloudBox. By following these guidelines, you can ensure smooth, reliable performance for all your race timing needs. For persistent problems, contact **RUFUS Support** for further assistance.


# RUFUS Tag Writer

The **RUFUS Tag Writer** is a desktop UHF RFID reader/writer designed to help you code UHF chips for your events. It works with **RUFUS wet chips** and other compatible UHF tags, giving you a simple way to prepare participant tags before race day.

With the Tag Writer software you can:

* Encode EPC values into UHF chips.
* Prepare tags for use with **RUFUS CloudBox** and the RUFUS Timing ecosystem.
* Verify chips before deployment.

## Credentials

To use the Tag Writer software you will need a **username and password**.

* These credentials are **different from your RUFUS Cloud account**.
* To request access, please contact us at: **<help@runonrufus.com>**

## Download Software & Drivers

* **Tag Writer Software (Windows)**\
  [Download here](https://rufus-web-downloads.s3.us-east-1.amazonaws.com/Macsha+Tag+Writer+V3.1.6.rar)
* **Windows Drivers**\
  [Download here](https://rufus-web-downloads.s3.us-east-1.amazonaws.com/CP210x_VCP_Windows.zip)

## Video Tutorial

Watch this short video to see how to install the software, connect the device, and start writing chips:

[How to Use the RUFUS Tag Writer](https://www.youtube.com/watch?v=kpEb-eq3Apw)

## FAQ

**Does the Tag Writer work only with RUFUS tags, or with any other?**\
The Tag Writer works with any UHF chip, as long as the chip’s read or write memory is not blocked.

**When are credits consumed?**\
You need to purchase coding credits only if you want to write blank chips into **RUFUS 2.5 encryption** (for closed systems). Re-coding those chips will not consume credits. Any coding into **RUFUS Free** or **CUSTOM EPC** will not consume credits.

***

## Notes

* The Tag Writer is **Windows-only**.
* Install the drivers **before** connecting the device to your PC.
* Once installed, open the Tag Writer software, log in with your credentials, place your chip on the reader, and follow the on-screen steps to encode.


# Introduction to RUFUS Cloud API

RUFUS is a modern platform for sports timing and race operations. The RUFUS Cloud Public API opens this ecosystem to external developers, timers, and organizations who want to integrate with it.

The API has evolved from a simple ingestion layer into a production-ready platform. It maintains full backward compatibility with existing v0 integrations—ensuring current devices and workflows continue to operate unchanged—while introducing stronger validation, improved security, and better protection against duplicate data, stale telemetry, and abusive traffic.

At its core, the API still revolves around three fundamental resources: **devices**, **sessions**, and **passings**. Devices connect to the cloud and create timing sessions, which act as containers for race passings. These passings can be consumed in real time or accessed later, enabling flexible workflows across timing operations.

On top of this foundation, the API now expands into two key areas:

* **Device Telemetry & Health**\
  Devices can report operational status (battery, temperature, GPS, connectivity, and more), enabling real-time monitoring and better field control.
* **Event & Participant Integration**\
  A new public layer allows authenticated clients to access event data and manage participants, enabling deeper integrations with registration systems, apps, and external platforms.

With improved reliability, stricter data integrity, and expanded capabilities, the RUFUS Cloud API is designed to support scalable, real-world race operations—while remaining simple and flexible to integrate.


# Overview

The RUFUS Cloud API is built around a set of core resources that represent both timing operations and event data.

At the heart of the timing layer are **devices**, **sessions**, and **passings**:

* A **device** is any hardware or software capable of detecting a competitor at a specific point—typically by reading a bib number or chip and assigning it a timestamp.
* A **session** is created by a device to group a set of passings during a specific timing operation.
* A **passing** represents a single recorded event: a competitor identifier and a timestamp generated by a device.

The typical flow is simple:\
a device authenticates using an API key → creates a session → sends passings to that session.

On top of this ingestion layer, the API now exposes an **event and participant data model**, enabling deeper integrations:

* An **event** represents a race or competition managed within the RUFUS ecosystem.
* **Participants** are the competitors registered in an event, including their identifiers (bib, chip, etc.) and associated data.

This allows external systems not only to send timing data, but also to **consume and manage event-related information**, such as listing events, retrieving participants, or creating new participant records (depending on API key permissions).

Before interacting with any of these resources, access must be granted through an **API key**, which defines the level of permissions (read, write, or both) available to your integration.

Together, these components provide a complete workflow—from capturing raw timing data in the field to integrating structured event information in the cloud.


# Get your api keys

To get started you must first get your api keys.

Inside your RUFUS Cloud account go to your profile section. You'll find this section in the upper-right corner of the navigation bar. Click to access personal and organisation settings.

<figure><img src="/files/PeT3HTNiP8GrQLCicYKM" alt=""><figcaption><p><em>Profile page</em></p></figcaption></figure>

Click in the Api keys tab and scroll down until the Create a new api key section.&#x20;

<figure><img src="/files/9qIHPDjXCdSQiFIKjcKx" alt=""><figcaption><p><em>Create new api key section</em></p></figcaption></figure>

Select an alias for the api key and an access type, and click the Create api key button. That's it!. You can create up to 10 different api keys for your account. You can then manage your api keys in the section below.

<figure><img src="/files/HZTxp9Rv8s9Po3QIFQsc" alt=""><figcaption><p><em>Company active api keys</em></p></figcaption></figure>


# Api permissions

You api keys can have different access types.

API keys define how your applications interact with the RUFUS Cloud API. Each key can be assigned a specific **access type**, allowing you to control exactly what actions an integration can perform.

This ensures better security, clearer separation of responsibilities, and safer integrations across devices, apps, and services.

**Access Types**

| Access type       | Permissions                                                                                                                                              |
| ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **READ**          | Can call all **GET** endpoints. Allows reading data such as devices, sessions, passings, events, and participants.                                       |
| **WRITE**         | Can call **POST** and **PATCH** endpoints. Allows sending data (sessions, passings, device status/telemetry) and creating participants.                  |
| **READ\_WRITE**   | Full access to all **GET**, **POST**, and **PATCH** endpoints.                                                                                           |
| **Unbind device** | Optional property available for **WRITE** and **READ\_WRITE** keys. Enables access to **DELETE** operations, such as unbinding a device from an account. |

**Notes on Permissions**

* **Telemetry reporting** (device status updates) requires **WRITE** or higher access.
* **Participant creation** is restricted to keys with **WRITE** permissions and is subject to plan limits and ownership validation.
* **Participant updates and corrections** are intentionally **not available via the Public API** and must be managed through RUFUS Race Manager (RRM).
* **DELETE operations** are limited and protected, and must be explicitly enabled via the *Unbind device* property.

**Typical Use Cases**

| API key alias          | Access type          | Application                                                                                          |
| ---------------------- | -------------------- | ---------------------------------------------------------------------------------------------------- |
| **Devices**            | WRITE                | Used in RFID devices or edge systems to send sessions, passings, and telemetry data.                 |
| **Timing app**         | READ\_WRITE          | Used in timing software or mobile apps that both send and consume timing data.                       |
| **Classification app** | READ                 | Used in results or classification systems that only need to read events, participants, and passings. |
| **Admin**              | READ\_WRITE + Unbind | Used in internal dashboards or admin tools with full control, including device management.           |

***

This model allows you to design integrations that are **secure by default**, while still being flexible enough to cover everything from low-level device ingestion to full event management workflows.


# Devices

## List devices

> Requires \`READ\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Devices"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"parameters":{"Page":{"name":"page","in":"query","required":false,"schema":{"type":"integer","minimum":1,"default":1},"description":"1-based page."},"LimitDevices":{"name":"limit","in":"query","required":false,"schema":{"type":"integer","minimum":1,"maximum":5000,"default":5000},"description":"Max items per page (devices)."}},"schemas":{"DevicesListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/DeviceSummary"}},"pagination":{"$ref":"#/components/schemas/Pagination"}},"required":["description","pagination"]}},"required":["body"]},"DeviceSummary":{"type":"object","additionalProperties":false,"properties":{"deviceid":{"type":"string"},"type":{"type":"string"},"model":{"type":"string"},"alias":{"type":"string"},"firmware":{"type":"string","nullable":true},"serial_number":{"type":"string"},"last_login":{"type":"string","format":"date-time","nullable":true},"creation_date":{"type":"string","format":"date-time","nullable":true},"sessions":{"type":"integer","minimum":0},"device_status":{"type":"string","nullable":true},"battery_percentage":{"type":"integer","minimum":0,"maximum":100,"nullable":true},"charging":{"type":"boolean","nullable":true},"last_telemetry_at":{"type":"string","format":"date-time","nullable":true},"last_reported_latitude":{"type":"number","nullable":true},"last_reported_longitude":{"type":"number","nullable":true}},"required":["deviceid","type","model","alias","serial_number"]},"Pagination":{"type":"object","additionalProperties":false,"properties":{"page":{"type":"integer","minimum":1},"limit":{"type":"integer","minimum":1},"total":{"type":"integer","minimum":0},"has_more":{"type":"boolean"}},"required":["page","limit","total","has_more"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/devices":{"get":{"tags":["Devices"],"summary":"List devices","description":"Requires `READ` or `READ_WRITE` api key access type.","parameters":[{"$ref":"#/components/parameters/Page"},{"$ref":"#/components/parameters/LimitDevices"}],"responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"$ref":"#/components/schemas/DevicesListResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Bind (create) device

> Requires \`WRITE\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Devices"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"BindDeviceRequest":{"type":"object","additionalProperties":false,"properties":{"type":{"type":"string"},"model":{"type":"string"},"serial_number":{"type":"string"},"alias":{"type":"string"},"firmware":{"type":"string"}},"required":["type","model","serial_number"]},"BindDeviceResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"deviceid":{"type":"string"},"already_binded":{"type":"boolean","nullable":true}},"required":["description","deviceid"]}},"required":["body"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"BadRequest":{"description":"Bad request","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/devices":{"post":{"tags":["Devices"],"summary":"Bind (create) device","description":"Requires `WRITE` or `READ_WRITE` api key access type.","requestBody":{"required":true,"content":{"application/json":{"schema":{"$ref":"#/components/schemas/BindDeviceRequest"}}}},"responses":{"201":{"description":"Device binded succesfully","content":{"application/json":{"schema":{"$ref":"#/components/schemas/BindDeviceResponse"}}}},"400":{"$ref":"#/components/responses/BadRequest"},"403":{"$ref":"#/components/responses/Forbidden"},"409":{"description":"Conflict","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Get device by id

> Requires \`READ\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Devices"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"DeviceGetResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"$ref":"#/components/schemas/DeviceDetails"}},"required":["description"]}},"required":["body"]},"DeviceDetails":{"allOf":[{"$ref":"#/components/schemas/DeviceSummary"},{"type":"object","additionalProperties":false,"properties":{"passings":{"type":"integer","minimum":0},"last_seen":{"type":"string","format":"date-time","nullable":true},"battery_volts":{"type":"number","nullable":true},"temperature_celsius":{"type":"integer","nullable":true},"gps_accuracy_m":{"type":"number","nullable":true},"network_type":{"type":"string","nullable":true},"signal_strength":{"type":"integer","nullable":true}}}]},"DeviceSummary":{"type":"object","additionalProperties":false,"properties":{"deviceid":{"type":"string"},"type":{"type":"string"},"model":{"type":"string"},"alias":{"type":"string"},"firmware":{"type":"string","nullable":true},"serial_number":{"type":"string"},"last_login":{"type":"string","format":"date-time","nullable":true},"creation_date":{"type":"string","format":"date-time","nullable":true},"sessions":{"type":"integer","minimum":0},"device_status":{"type":"string","nullable":true},"battery_percentage":{"type":"integer","minimum":0,"maximum":100,"nullable":true},"charging":{"type":"boolean","nullable":true},"last_telemetry_at":{"type":"string","format":"date-time","nullable":true},"last_reported_latitude":{"type":"number","nullable":true},"last_reported_longitude":{"type":"number","nullable":true}},"required":["deviceid","type","model","alias","serial_number"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/devices/{deviceid}":{"get":{"tags":["Devices"],"summary":"Get device by id","description":"Requires `READ` or `READ_WRITE` api key access type.","responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"$ref":"#/components/schemas/DeviceGetResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Unbind (delete) device

> Requires an api key with \`allow\_unbind=true\`.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Devices"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"UnbindDeviceResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"deviceid":{"type":"string"}},"required":["description","deviceid"]}},"required":["body"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/devices/{deviceid}":{"delete":{"tags":["Devices"],"summary":"Unbind (delete) device","description":"Requires an api key with `allow_unbind=true`.","responses":{"200":{"description":"Device unbinded succesfully","content":{"application/json":{"schema":{"$ref":"#/components/schemas/UnbindDeviceResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Report device telemetry/status

> Requires \`WRITE\` or \`READ\_WRITE\` api key access type.\
> \
> Stale updates are ignored if \`reported\_at\` is older than the current \`last\_telemetry\_at\`.<br>

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Devices"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"DeviceTelemetryRequest":{"type":"object","additionalProperties":false,"description":"At least one telemetry field is required.","properties":{"reported_at":{"type":"string","format":"date-time"},"device_status":{"type":"string"},"battery_percentage":{"type":"integer","minimum":0,"maximum":100},"battery_volts":{"type":"number","minimum":0},"charging":{"type":"boolean"},"temperature_celsius":{"type":"integer","minimum":-100,"maximum":200},"latitude":{"type":"number","minimum":-90,"maximum":90},"longitude":{"type":"number","minimum":-180,"maximum":180},"gps_accuracy_m":{"type":"number","minimum":0},"network_type":{"type":"string"},"signal_strength":{"type":"integer","minimum":-200,"maximum":200}}},"DeviceTelemetryResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"deviceid":{"type":"string"},"result":{"type":"object","additionalProperties":false,"properties":{"deviceid":{"type":"string"},"last_telemetry_at":{"type":"string","format":"date-time"},"device_status":{"type":"string","nullable":true},"battery_percentage":{"type":"integer","nullable":true},"battery_volts":{"type":"number","nullable":true},"charging":{"type":"boolean","nullable":true},"temperature_celsius":{"type":"integer","nullable":true},"last_reported_latitude":{"type":"number","nullable":true},"last_reported_longitude":{"type":"number","nullable":true},"gps_accuracy_m":{"type":"number","nullable":true},"network_type":{"type":"string","nullable":true},"signal_strength":{"type":"integer","nullable":true}}}},"required":["description","deviceid"]}},"required":["body"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"BadRequest":{"description":"Bad request","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"PayloadTooLarge":{"description":"Payload too large","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/devices/{deviceid}/status":{"patch":{"tags":["Devices"],"summary":"Report device telemetry/status","description":"Requires `WRITE` or `READ_WRITE` api key access type.\n\nStale updates are ignored if `reported_at` is older than the current `last_telemetry_at`.\n","requestBody":{"required":true,"content":{"application/json":{"schema":{"$ref":"#/components/schemas/DeviceTelemetryRequest"}}}},"responses":{"200":{"description":"Updated (or ignored if stale)","content":{"application/json":{"schema":{"$ref":"#/components/schemas/DeviceTelemetryResponse"}}}},"400":{"$ref":"#/components/responses/BadRequest"},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"413":{"$ref":"#/components/responses/PayloadTooLarge"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```


# Sessions

## Create session

> Requires \`WRITE\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Sessions"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"CreateSessionRequest":{"type":"object","additionalProperties":false,"properties":{"deviceid":{"type":"string"},"alias":{"type":"string"}},"required":["deviceid"]},"CreateSessionResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"token_session":{"type":"string"}},"required":["description","token_session"]}},"required":["body"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"BadRequest":{"description":"Bad request","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/sessions":{"post":{"tags":["Sessions"],"summary":"Create session","description":"Requires `WRITE` or `READ_WRITE` api key access type.","requestBody":{"required":true,"content":{"application/json":{"schema":{"$ref":"#/components/schemas/CreateSessionRequest"}}}},"responses":{"201":{"description":"Session inserted succesfully","content":{"application/json":{"schema":{"$ref":"#/components/schemas/CreateSessionResponse"}}}},"400":{"$ref":"#/components/responses/BadRequest"},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"409":{"description":"Conflict","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Get session by token

> Requires \`READ\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Sessions"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"SessionGetResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/SessionDetails"}}},"required":["description"]}},"required":["body"]},"SessionDetails":{"type":"object","additionalProperties":false,"properties":{"token_session":{"type":"string"},"alias":{"type":"string"},"creation_date":{"type":"string","format":"date-time"},"duration":{"type":"number","nullable":true},"active":{"type":"boolean"},"passings":{"type":"integer","minimum":0},"first":{"type":"string","format":"date-time","nullable":true},"last":{"type":"string","format":"date-time","nullable":true}},"required":["token_session","alias","active"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/sessions/{token_session}":{"get":{"tags":["Sessions"],"summary":"Get session by token","description":"Requires `READ` or `READ_WRITE` api key access type.","responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"$ref":"#/components/schemas/SessionGetResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## List sessions by device

> Requires \`READ\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Sessions"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"SessionsListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/SessionSummary"}}},"required":["description"]}},"required":["body"]},"SessionSummary":{"type":"object","additionalProperties":false,"properties":{"token_session":{"type":"string"},"alias":{"type":"string"},"creation_date":{"type":"string","format":"date-time"},"duration":{"type":"number","nullable":true},"active":{"type":"boolean"},"passings":{"type":"integer","minimum":0}},"required":["token_session","alias","active"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/sessions/device/{deviceid}":{"get":{"tags":["Sessions"],"summary":"List sessions by device","description":"Requires `READ` or `READ_WRITE` api key access type.","responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"$ref":"#/components/schemas/SessionsListResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Get active session for device

> Requires \`READ\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Sessions"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"SessionsListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/SessionSummary"}}},"required":["description"]}},"required":["body"]},"SessionSummary":{"type":"object","additionalProperties":false,"properties":{"token_session":{"type":"string"},"alias":{"type":"string"},"creation_date":{"type":"string","format":"date-time"},"duration":{"type":"number","nullable":true},"active":{"type":"boolean"},"passings":{"type":"integer","minimum":0}},"required":["token_session","alias","active"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/sessions/device/{deviceid}/active":{"get":{"tags":["Sessions"],"summary":"Get active session for device","description":"Requires `READ` or `READ_WRITE` api key access type.","responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"$ref":"#/components/schemas/SessionsListResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Close session

> Requires \`WRITE\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Sessions"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"CloseSessionResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"token_session":{"type":"string"}},"required":["description","token_session"]}},"required":["body"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/sessions/close/{token_session}":{"patch":{"tags":["Sessions"],"summary":"Close session","description":"Requires `WRITE` or `READ_WRITE` api key access type.","responses":{"200":{"description":"Session closed succesfully","content":{"application/json":{"schema":{"$ref":"#/components/schemas/CloseSessionResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```


# Passings

## Insert passings

> Requires \`WRITE\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Passings"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"InsertPassingsRequest":{"type":"object","additionalProperties":false,"properties":{"token_session":{"type":"string"},"passings_list":{"type":"array","minItems":1,"items":{"$ref":"#/components/schemas/Passing"}}},"required":["token_session","passings_list"]},"Passing":{"type":"object","additionalProperties":false,"properties":{"timestamp":{"type":"string","format":"date-time"},"num_passing":{"type":"integer","minimum":0},"bib":{"type":"string"},"participant_id":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"latitude":{"type":"number","nullable":true},"longitude":{"type":"number","nullable":true},"status":{"type":"string","nullable":true},"timezone":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true}},"required":["timestamp","num_passing","bib"]},"InsertPassingsResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"token_session":{"type":"string"},"inserted_count":{"type":"integer","minimum":0},"duplicate_count":{"type":"integer","minimum":0}},"required":["description","token_session"]}},"required":["body"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"BadRequest":{"description":"Bad request","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"PayloadTooLarge":{"description":"Payload too large","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/passings":{"post":{"tags":["Passings"],"summary":"Insert passings","description":"Requires `WRITE` or `READ_WRITE` api key access type.","requestBody":{"required":true,"content":{"application/json":{"schema":{"$ref":"#/components/schemas/InsertPassingsRequest"}}}},"responses":{"201":{"description":"Passings inserted succesfully","content":{"application/json":{"schema":{"$ref":"#/components/schemas/InsertPassingsResponse"}}}},"400":{"$ref":"#/components/responses/BadRequest"},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"413":{"$ref":"#/components/responses/PayloadTooLarge"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Get session passings

> Requires \`READ\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Passings"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"parameters":{"First":{"name":"first","in":"query","required":false,"schema":{"type":"integer","minimum":0,"default":-1},"description":"First num_passing to include (inclusive). Use -1 to ignore."},"Last":{"name":"last","in":"query","required":false,"schema":{"type":"integer","minimum":0,"default":-1},"description":"Last num_passing to include (inclusive). Use -1 to ignore."},"PageZeroBased":{"name":"page","in":"query","required":false,"schema":{"type":"integer","minimum":0,"default":0},"description":"0 disables paging. When > 0, behaves like 1-based page."}},"schemas":{"PassingsListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/Passing"}}},"required":["description"]}},"required":["body"]},"Passing":{"type":"object","additionalProperties":false,"properties":{"timestamp":{"type":"string","format":"date-time"},"num_passing":{"type":"integer","minimum":0},"bib":{"type":"string"},"participant_id":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"latitude":{"type":"number","nullable":true},"longitude":{"type":"number","nullable":true},"status":{"type":"string","nullable":true},"timezone":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true}},"required":["timestamp","num_passing","bib"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/passings/session/{token_session}":{"get":{"tags":["Passings"],"summary":"Get session passings","description":"Requires `READ` or `READ_WRITE` api key access type.","parameters":[{"$ref":"#/components/parameters/First"},{"$ref":"#/components/parameters/Last"},{"$ref":"#/components/parameters/PageZeroBased"}],"responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PassingsListResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Get device passings

> Requires \`READ\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Passings"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"parameters":{"From":{"name":"from","in":"query","required":false,"schema":{"type":"string","format":"date-time"},"description":"Filter passings with timestamp >= from."},"To":{"name":"to","in":"query","required":false,"schema":{"type":"string","format":"date-time"},"description":"Filter passings with timestamp <= to."},"PageZeroBased":{"name":"page","in":"query","required":false,"schema":{"type":"integer","minimum":0,"default":0},"description":"0 disables paging. When > 0, behaves like 1-based page."}},"schemas":{"PassingsListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/Passing"}}},"required":["description"]}},"required":["body"]},"Passing":{"type":"object","additionalProperties":false,"properties":{"timestamp":{"type":"string","format":"date-time"},"num_passing":{"type":"integer","minimum":0},"bib":{"type":"string"},"participant_id":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"latitude":{"type":"number","nullable":true},"longitude":{"type":"number","nullable":true},"status":{"type":"string","nullable":true},"timezone":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true}},"required":["timestamp","num_passing","bib"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/passings/device/{deviceid}":{"get":{"tags":["Passings"],"summary":"Get device passings","description":"Requires `READ` or `READ_WRITE` api key access type.","parameters":[{"$ref":"#/components/parameters/From"},{"$ref":"#/components/parameters/To"},{"$ref":"#/components/parameters/PageZeroBased"}],"responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"$ref":"#/components/schemas/PassingsListResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```


# Events

## List events

> Requires \`READ\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Events"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"parameters":{"Page":{"name":"page","in":"query","required":false,"schema":{"type":"integer","minimum":1,"default":1},"description":"1-based page."},"LimitEvents":{"name":"limit","in":"query","required":false,"schema":{"type":"integer","minimum":1,"maximum":1000,"default":1000},"description":"Max items per page (events)."}},"schemas":{"EventsListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/EventSummary"}},"pagination":{"$ref":"#/components/schemas/Pagination"}},"required":["description","result","pagination"]}},"required":["body"]},"EventSummary":{"type":"object","additionalProperties":false,"properties":{"event_token":{"type":"string"},"name":{"type":"string","nullable":true},"edition":{"type":"string","nullable":true},"location":{"type":"string","nullable":true},"start_date":{"type":"string","format":"date-time","nullable":true},"end_date":{"type":"string","format":"date-time","nullable":true},"status":{"type":"string","nullable":true}},"required":["event_token"]},"Pagination":{"type":"object","additionalProperties":false,"properties":{"page":{"type":"integer","minimum":1},"limit":{"type":"integer","minimum":1},"total":{"type":"integer","minimum":0},"has_more":{"type":"boolean"}},"required":["page","limit","total","has_more"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/events":{"get":{"tags":["Events"],"summary":"List events","description":"Requires `READ` or `READ_WRITE` api key access type.","parameters":[{"$ref":"#/components/parameters/Page"},{"$ref":"#/components/parameters/LimitEvents"}],"responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EventsListResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Get event by token

> Requires \`READ\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Events"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"EventGetResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","properties":{"description":{"type":"string"},"result":{"type":"object","description":"Event details (fields follow RRM schema; large object).","additionalProperties":true}},"required":["description"]}},"required":["body"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/events/{event_token}":{"get":{"tags":["Events"],"summary":"Get event by token","description":"Requires `READ` or `READ_WRITE` api key access type.","responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EventGetResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## List participants by event

> Requires \`READ\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Events"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"parameters":{"Page":{"name":"page","in":"query","required":false,"schema":{"type":"integer","minimum":1,"default":1},"description":"1-based page."},"LimitParticipants":{"name":"limit","in":"query","required":false,"schema":{"type":"integer","minimum":1,"maximum":1000,"default":1000},"description":"Max items per page (participants)."},"ParticipantBib":{"name":"bib","in":"query","required":false,"schema":{"type":"string"},"description":"Filter participants by bib."},"ParticipantChip":{"name":"chip","in":"query","required":false,"schema":{"type":"string"},"description":"Filter participants by chip."},"ParticipantRaceToken":{"name":"race_token","in":"query","required":false,"schema":{"type":"string"},"description":"Filter participants by race_token."},"ParticipantStatus":{"name":"status","in":"query","required":false,"schema":{"type":"string"},"description":"Filter participants by status."}},"schemas":{"ParticipantsListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/ParticipantSummary"}},"pagination":{"$ref":"#/components/schemas/Pagination"}},"required":["description","result","pagination"]}},"required":["body"]},"ParticipantSummary":{"type":"object","additionalProperties":false,"properties":{"event_token":{"type":"string"},"participant_token":{"type":"string"},"name":{"type":"string"},"lastname":{"type":"string","nullable":true},"bib":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"status":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true},"dob":{"type":"string","format":"date-time","nullable":true},"yob":{"type":"integer","nullable":true},"country":{"type":"string","nullable":true},"city":{"type":"string","nullable":true},"age_group":{"type":"string","nullable":true},"team":{"type":"string","nullable":true},"club":{"type":"string","nullable":true},"email":{"type":"string","format":"email","nullable":true},"telephone":{"type":"string","nullable":true},"group_id":{"type":"string","nullable":true},"race_token":{"type":"string","nullable":true},"custom_fields":{"type":"array","nullable":true,"items":{"$ref":"#/components/schemas/CustomField"}},"individual_start_time":{"type":"string","nullable":true}},"required":["event_token","participant_token","name"]},"CustomField":{"type":"object","additionalProperties":false,"properties":{"field_name":{"type":"string"},"value":{"type":"string","nullable":true}},"required":["field_name","value"]},"Pagination":{"type":"object","additionalProperties":false,"properties":{"page":{"type":"integer","minimum":1},"limit":{"type":"integer","minimum":1},"total":{"type":"integer","minimum":0},"has_more":{"type":"boolean"}},"required":["page","limit","total","has_more"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/events/{event_token}/participants":{"get":{"tags":["Events"],"summary":"List participants by event","description":"Requires `READ` or `READ_WRITE` api key access type.","parameters":[{"$ref":"#/components/parameters/Page"},{"$ref":"#/components/parameters/LimitParticipants"},{"$ref":"#/components/parameters/ParticipantBib"},{"$ref":"#/components/parameters/ParticipantChip"},{"$ref":"#/components/parameters/ParticipantRaceToken"},{"$ref":"#/components/parameters/ParticipantStatus"}],"responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"$ref":"#/components/schemas/ParticipantsListResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Create participant

> Requires \`WRITE\` or \`READ\_WRITE\` api key access type.\
> \
> Participant corrections (PATCH/DELETE) are intentionally not exposed in the public API.<br>

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Events"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"CreateParticipantRequest":{"allOf":[{"$ref":"#/components/schemas/Participant"}]},"Participant":{"type":"object","additionalProperties":false,"properties":{"name":{"type":"string"},"lastname":{"type":"string","nullable":true},"bib":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true},"dob":{"type":"string","format":"date-time","nullable":true},"yob":{"type":"integer","nullable":true},"country":{"type":"string","nullable":true},"city":{"type":"string","nullable":true},"age_group":{"type":"string","nullable":true},"team":{"type":"string","nullable":true},"club":{"type":"string","nullable":true},"email":{"type":"string","format":"email","nullable":true},"telephone":{"type":"string","nullable":true},"group_id":{"type":"string","nullable":true},"race_token":{"type":"string","nullable":true},"custom_fields":{"type":"array","nullable":true,"items":{"$ref":"#/components/schemas/CustomField"}},"individual_start_time":{"type":"string","nullable":true,"description":"HH:mm:ss"}},"required":["name","bib"]},"CustomField":{"type":"object","additionalProperties":false,"properties":{"field_name":{"type":"string"},"value":{"type":"string","nullable":true}},"required":["field_name","value"]},"CreateParticipantResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"event_token":{"type":"string"},"participant_token":{"type":"string"},"result":{"type":"object","additionalProperties":true}},"required":["description","event_token","participant_token"]}},"required":["body"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"BadRequest":{"description":"Bad request","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"PayloadTooLarge":{"description":"Payload too large","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/events/{event_token}/participants":{"post":{"tags":["Events"],"summary":"Create participant","description":"Requires `WRITE` or `READ_WRITE` api key access type.\n\nParticipant corrections (PATCH/DELETE) are intentionally not exposed in the public API.\n","requestBody":{"required":true,"content":{"application/json":{"schema":{"$ref":"#/components/schemas/CreateParticipantRequest"}}}},"responses":{"201":{"description":"Participant inserted succesfully","content":{"application/json":{"schema":{"$ref":"#/components/schemas/CreateParticipantResponse"}}}},"400":{"$ref":"#/components/responses/BadRequest"},"403":{"description":"Forbidden (includes plan enforcement)","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"404":{"$ref":"#/components/responses/NotFound"},"409":{"description":"Conflict (duplicate bib/chip/participant)","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"413":{"$ref":"#/components/responses/PayloadTooLarge"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```

## Get participant by token

> Requires \`READ\` or \`READ\_WRITE\` api key access type.

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"tags":[{"name":"Events"}],"servers":[{"url":"https://api.runonrufus.com/v0","description":"Production (v0)"}],"security":[{"ApiKeyHeader":[]},{"XApiKeyHeader":[]}],"components":{"securitySchemes":{"ApiKeyHeader":{"type":"apiKey","in":"header","name":"api_key","description":"API key for authentication."},"XApiKeyHeader":{"type":"apiKey","in":"header","name":"x-api-key","description":"API key for authentication (alternate header)."}},"schemas":{"ParticipantGetResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"$ref":"#/components/schemas/ParticipantSummary"}},"required":["description","result"]}},"required":["body"]},"ParticipantSummary":{"type":"object","additionalProperties":false,"properties":{"event_token":{"type":"string"},"participant_token":{"type":"string"},"name":{"type":"string"},"lastname":{"type":"string","nullable":true},"bib":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"status":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true},"dob":{"type":"string","format":"date-time","nullable":true},"yob":{"type":"integer","nullable":true},"country":{"type":"string","nullable":true},"city":{"type":"string","nullable":true},"age_group":{"type":"string","nullable":true},"team":{"type":"string","nullable":true},"club":{"type":"string","nullable":true},"email":{"type":"string","format":"email","nullable":true},"telephone":{"type":"string","nullable":true},"group_id":{"type":"string","nullable":true},"race_token":{"type":"string","nullable":true},"custom_fields":{"type":"array","nullable":true,"items":{"$ref":"#/components/schemas/CustomField"}},"individual_start_time":{"type":"string","nullable":true}},"required":["event_token","participant_token","name"]},"CustomField":{"type":"object","additionalProperties":false,"properties":{"field_name":{"type":"string"},"value":{"type":"string","nullable":true}},"required":["field_name","value"]},"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}},"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}},"responses":{"Forbidden":{"description":"Forbidden","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"NotFound":{"description":"Not found","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeAny"}}}},"InternalError":{"description":"Internal server error","content":{"application/json":{"schema":{"$ref":"#/components/schemas/EnvelopeNull"}}}}}},"paths":{"/events/{event_token}/participants/{participant_token}":{"get":{"tags":["Events"],"summary":"Get participant by token","description":"Requires `READ` or `READ_WRITE` api key access type.","responses":{"200":{"description":"Success","content":{"application/json":{"schema":{"$ref":"#/components/schemas/ParticipantGetResponse"}}}},"403":{"$ref":"#/components/responses/Forbidden"},"404":{"$ref":"#/components/responses/NotFound"},"500":{"$ref":"#/components/responses/InternalError"}}}}}}
```


# Models

## The EnvelopeAny object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"EnvelopeAny":{"type":"object","additionalProperties":false,"properties":{"body":{"description":"Operation result body."}}}}}}
```

## The EnvelopeNull object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"EnvelopeNull":{"type":"object","additionalProperties":false,"properties":{"body":{"nullable":true}},"required":["body"]}}}}
```

## The Pagination object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"Pagination":{"type":"object","additionalProperties":false,"properties":{"page":{"type":"integer","minimum":1},"limit":{"type":"integer","minimum":1},"total":{"type":"integer","minimum":0},"has_more":{"type":"boolean"}},"required":["page","limit","total","has_more"]}}}}
```

## The DeviceSummary object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"DeviceSummary":{"type":"object","additionalProperties":false,"properties":{"deviceid":{"type":"string"},"type":{"type":"string"},"model":{"type":"string"},"alias":{"type":"string"},"firmware":{"type":"string","nullable":true},"serial_number":{"type":"string"},"last_login":{"type":"string","format":"date-time","nullable":true},"creation_date":{"type":"string","format":"date-time","nullable":true},"sessions":{"type":"integer","minimum":0},"device_status":{"type":"string","nullable":true},"battery_percentage":{"type":"integer","minimum":0,"maximum":100,"nullable":true},"charging":{"type":"boolean","nullable":true},"last_telemetry_at":{"type":"string","format":"date-time","nullable":true},"last_reported_latitude":{"type":"number","nullable":true},"last_reported_longitude":{"type":"number","nullable":true}},"required":["deviceid","type","model","alias","serial_number"]}}}}
```

## The DeviceDetails object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"DeviceDetails":{"allOf":[{"$ref":"#/components/schemas/DeviceSummary"},{"type":"object","additionalProperties":false,"properties":{"passings":{"type":"integer","minimum":0},"last_seen":{"type":"string","format":"date-time","nullable":true},"battery_volts":{"type":"number","nullable":true},"temperature_celsius":{"type":"integer","nullable":true},"gps_accuracy_m":{"type":"number","nullable":true},"network_type":{"type":"string","nullable":true},"signal_strength":{"type":"integer","nullable":true}}}]},"DeviceSummary":{"type":"object","additionalProperties":false,"properties":{"deviceid":{"type":"string"},"type":{"type":"string"},"model":{"type":"string"},"alias":{"type":"string"},"firmware":{"type":"string","nullable":true},"serial_number":{"type":"string"},"last_login":{"type":"string","format":"date-time","nullable":true},"creation_date":{"type":"string","format":"date-time","nullable":true},"sessions":{"type":"integer","minimum":0},"device_status":{"type":"string","nullable":true},"battery_percentage":{"type":"integer","minimum":0,"maximum":100,"nullable":true},"charging":{"type":"boolean","nullable":true},"last_telemetry_at":{"type":"string","format":"date-time","nullable":true},"last_reported_latitude":{"type":"number","nullable":true},"last_reported_longitude":{"type":"number","nullable":true}},"required":["deviceid","type","model","alias","serial_number"]}}}}
```

## The BindDeviceRequest object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"BindDeviceRequest":{"type":"object","additionalProperties":false,"properties":{"type":{"type":"string"},"model":{"type":"string"},"serial_number":{"type":"string"},"alias":{"type":"string"},"firmware":{"type":"string"}},"required":["type","model","serial_number"]}}}}
```

## The BindDeviceResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"BindDeviceResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"deviceid":{"type":"string"},"already_binded":{"type":"boolean","nullable":true}},"required":["description","deviceid"]}},"required":["body"]}}}}
```

## The UnbindDeviceResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"UnbindDeviceResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"deviceid":{"type":"string"}},"required":["description","deviceid"]}},"required":["body"]}}}}
```

## The DevicesListResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"DevicesListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/DeviceSummary"}},"pagination":{"$ref":"#/components/schemas/Pagination"}},"required":["description","pagination"]}},"required":["body"]},"DeviceSummary":{"type":"object","additionalProperties":false,"properties":{"deviceid":{"type":"string"},"type":{"type":"string"},"model":{"type":"string"},"alias":{"type":"string"},"firmware":{"type":"string","nullable":true},"serial_number":{"type":"string"},"last_login":{"type":"string","format":"date-time","nullable":true},"creation_date":{"type":"string","format":"date-time","nullable":true},"sessions":{"type":"integer","minimum":0},"device_status":{"type":"string","nullable":true},"battery_percentage":{"type":"integer","minimum":0,"maximum":100,"nullable":true},"charging":{"type":"boolean","nullable":true},"last_telemetry_at":{"type":"string","format":"date-time","nullable":true},"last_reported_latitude":{"type":"number","nullable":true},"last_reported_longitude":{"type":"number","nullable":true}},"required":["deviceid","type","model","alias","serial_number"]},"Pagination":{"type":"object","additionalProperties":false,"properties":{"page":{"type":"integer","minimum":1},"limit":{"type":"integer","minimum":1},"total":{"type":"integer","minimum":0},"has_more":{"type":"boolean"}},"required":["page","limit","total","has_more"]}}}}
```

## The DeviceGetResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"DeviceGetResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"$ref":"#/components/schemas/DeviceDetails"}},"required":["description"]}},"required":["body"]},"DeviceDetails":{"allOf":[{"$ref":"#/components/schemas/DeviceSummary"},{"type":"object","additionalProperties":false,"properties":{"passings":{"type":"integer","minimum":0},"last_seen":{"type":"string","format":"date-time","nullable":true},"battery_volts":{"type":"number","nullable":true},"temperature_celsius":{"type":"integer","nullable":true},"gps_accuracy_m":{"type":"number","nullable":true},"network_type":{"type":"string","nullable":true},"signal_strength":{"type":"integer","nullable":true}}}]},"DeviceSummary":{"type":"object","additionalProperties":false,"properties":{"deviceid":{"type":"string"},"type":{"type":"string"},"model":{"type":"string"},"alias":{"type":"string"},"firmware":{"type":"string","nullable":true},"serial_number":{"type":"string"},"last_login":{"type":"string","format":"date-time","nullable":true},"creation_date":{"type":"string","format":"date-time","nullable":true},"sessions":{"type":"integer","minimum":0},"device_status":{"type":"string","nullable":true},"battery_percentage":{"type":"integer","minimum":0,"maximum":100,"nullable":true},"charging":{"type":"boolean","nullable":true},"last_telemetry_at":{"type":"string","format":"date-time","nullable":true},"last_reported_latitude":{"type":"number","nullable":true},"last_reported_longitude":{"type":"number","nullable":true}},"required":["deviceid","type","model","alias","serial_number"]}}}}
```

## The DeviceTelemetryRequest object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"DeviceTelemetryRequest":{"type":"object","additionalProperties":false,"description":"At least one telemetry field is required.","properties":{"reported_at":{"type":"string","format":"date-time"},"device_status":{"type":"string"},"battery_percentage":{"type":"integer","minimum":0,"maximum":100},"battery_volts":{"type":"number","minimum":0},"charging":{"type":"boolean"},"temperature_celsius":{"type":"integer","minimum":-100,"maximum":200},"latitude":{"type":"number","minimum":-90,"maximum":90},"longitude":{"type":"number","minimum":-180,"maximum":180},"gps_accuracy_m":{"type":"number","minimum":0},"network_type":{"type":"string"},"signal_strength":{"type":"integer","minimum":-200,"maximum":200}}}}}}
```

## The DeviceTelemetryResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"DeviceTelemetryResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"deviceid":{"type":"string"},"result":{"type":"object","additionalProperties":false,"properties":{"deviceid":{"type":"string"},"last_telemetry_at":{"type":"string","format":"date-time"},"device_status":{"type":"string","nullable":true},"battery_percentage":{"type":"integer","nullable":true},"battery_volts":{"type":"number","nullable":true},"charging":{"type":"boolean","nullable":true},"temperature_celsius":{"type":"integer","nullable":true},"last_reported_latitude":{"type":"number","nullable":true},"last_reported_longitude":{"type":"number","nullable":true},"gps_accuracy_m":{"type":"number","nullable":true},"network_type":{"type":"string","nullable":true},"signal_strength":{"type":"integer","nullable":true}}}},"required":["description","deviceid"]}},"required":["body"]}}}}
```

## The CreateSessionRequest object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"CreateSessionRequest":{"type":"object","additionalProperties":false,"properties":{"deviceid":{"type":"string"},"alias":{"type":"string"}},"required":["deviceid"]}}}}
```

## The CreateSessionResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"CreateSessionResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"token_session":{"type":"string"}},"required":["description","token_session"]}},"required":["body"]}}}}
```

## The CloseSessionResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"CloseSessionResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"token_session":{"type":"string"}},"required":["description","token_session"]}},"required":["body"]}}}}
```

## The SessionDetails object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"SessionDetails":{"type":"object","additionalProperties":false,"properties":{"token_session":{"type":"string"},"alias":{"type":"string"},"creation_date":{"type":"string","format":"date-time"},"duration":{"type":"number","nullable":true},"active":{"type":"boolean"},"passings":{"type":"integer","minimum":0},"first":{"type":"string","format":"date-time","nullable":true},"last":{"type":"string","format":"date-time","nullable":true}},"required":["token_session","alias","active"]}}}}
```

## The SessionSummary object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"SessionSummary":{"type":"object","additionalProperties":false,"properties":{"token_session":{"type":"string"},"alias":{"type":"string"},"creation_date":{"type":"string","format":"date-time"},"duration":{"type":"number","nullable":true},"active":{"type":"boolean"},"passings":{"type":"integer","minimum":0}},"required":["token_session","alias","active"]}}}}
```

## The SessionGetResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"SessionGetResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/SessionDetails"}}},"required":["description"]}},"required":["body"]},"SessionDetails":{"type":"object","additionalProperties":false,"properties":{"token_session":{"type":"string"},"alias":{"type":"string"},"creation_date":{"type":"string","format":"date-time"},"duration":{"type":"number","nullable":true},"active":{"type":"boolean"},"passings":{"type":"integer","minimum":0},"first":{"type":"string","format":"date-time","nullable":true},"last":{"type":"string","format":"date-time","nullable":true}},"required":["token_session","alias","active"]}}}}
```

## The SessionsListResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"SessionsListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/SessionSummary"}}},"required":["description"]}},"required":["body"]},"SessionSummary":{"type":"object","additionalProperties":false,"properties":{"token_session":{"type":"string"},"alias":{"type":"string"},"creation_date":{"type":"string","format":"date-time"},"duration":{"type":"number","nullable":true},"active":{"type":"boolean"},"passings":{"type":"integer","minimum":0}},"required":["token_session","alias","active"]}}}}
```

## The Passing object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"Passing":{"type":"object","additionalProperties":false,"properties":{"timestamp":{"type":"string","format":"date-time"},"num_passing":{"type":"integer","minimum":0},"bib":{"type":"string"},"participant_id":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"latitude":{"type":"number","nullable":true},"longitude":{"type":"number","nullable":true},"status":{"type":"string","nullable":true},"timezone":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true}},"required":["timestamp","num_passing","bib"]}}}}
```

## The InsertPassingsRequest object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"InsertPassingsRequest":{"type":"object","additionalProperties":false,"properties":{"token_session":{"type":"string"},"passings_list":{"type":"array","minItems":1,"items":{"$ref":"#/components/schemas/Passing"}}},"required":["token_session","passings_list"]},"Passing":{"type":"object","additionalProperties":false,"properties":{"timestamp":{"type":"string","format":"date-time"},"num_passing":{"type":"integer","minimum":0},"bib":{"type":"string"},"participant_id":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"latitude":{"type":"number","nullable":true},"longitude":{"type":"number","nullable":true},"status":{"type":"string","nullable":true},"timezone":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true}},"required":["timestamp","num_passing","bib"]}}}}
```

## The InsertPassingsResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"InsertPassingsResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"token_session":{"type":"string"},"inserted_count":{"type":"integer","minimum":0},"duplicate_count":{"type":"integer","minimum":0}},"required":["description","token_session"]}},"required":["body"]}}}}
```

## The PassingsListResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"PassingsListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/Passing"}}},"required":["description"]}},"required":["body"]},"Passing":{"type":"object","additionalProperties":false,"properties":{"timestamp":{"type":"string","format":"date-time"},"num_passing":{"type":"integer","minimum":0},"bib":{"type":"string"},"participant_id":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"latitude":{"type":"number","nullable":true},"longitude":{"type":"number","nullable":true},"status":{"type":"string","nullable":true},"timezone":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true}},"required":["timestamp","num_passing","bib"]}}}}
```

## The EventSummary object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"EventSummary":{"type":"object","additionalProperties":false,"properties":{"event_token":{"type":"string"},"name":{"type":"string","nullable":true},"edition":{"type":"string","nullable":true},"location":{"type":"string","nullable":true},"start_date":{"type":"string","format":"date-time","nullable":true},"end_date":{"type":"string","format":"date-time","nullable":true},"status":{"type":"string","nullable":true}},"required":["event_token"]}}}}
```

## The EventsListResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"EventsListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/EventSummary"}},"pagination":{"$ref":"#/components/schemas/Pagination"}},"required":["description","result","pagination"]}},"required":["body"]},"EventSummary":{"type":"object","additionalProperties":false,"properties":{"event_token":{"type":"string"},"name":{"type":"string","nullable":true},"edition":{"type":"string","nullable":true},"location":{"type":"string","nullable":true},"start_date":{"type":"string","format":"date-time","nullable":true},"end_date":{"type":"string","format":"date-time","nullable":true},"status":{"type":"string","nullable":true}},"required":["event_token"]},"Pagination":{"type":"object","additionalProperties":false,"properties":{"page":{"type":"integer","minimum":1},"limit":{"type":"integer","minimum":1},"total":{"type":"integer","minimum":0},"has_more":{"type":"boolean"}},"required":["page","limit","total","has_more"]}}}}
```

## The EventGetResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"EventGetResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","properties":{"description":{"type":"string"},"result":{"type":"object","description":"Event details (fields follow RRM schema; large object).","additionalProperties":true}},"required":["description"]}},"required":["body"]}}}}
```

## The CustomField object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"CustomField":{"type":"object","additionalProperties":false,"properties":{"field_name":{"type":"string"},"value":{"type":"string","nullable":true}},"required":["field_name","value"]}}}}
```

## The Participant object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"Participant":{"type":"object","additionalProperties":false,"properties":{"name":{"type":"string"},"lastname":{"type":"string","nullable":true},"bib":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true},"dob":{"type":"string","format":"date-time","nullable":true},"yob":{"type":"integer","nullable":true},"country":{"type":"string","nullable":true},"city":{"type":"string","nullable":true},"age_group":{"type":"string","nullable":true},"team":{"type":"string","nullable":true},"club":{"type":"string","nullable":true},"email":{"type":"string","format":"email","nullable":true},"telephone":{"type":"string","nullable":true},"group_id":{"type":"string","nullable":true},"race_token":{"type":"string","nullable":true},"custom_fields":{"type":"array","nullable":true,"items":{"$ref":"#/components/schemas/CustomField"}},"individual_start_time":{"type":"string","nullable":true,"description":"HH:mm:ss"}},"required":["name","bib"]},"CustomField":{"type":"object","additionalProperties":false,"properties":{"field_name":{"type":"string"},"value":{"type":"string","nullable":true}},"required":["field_name","value"]}}}}
```

## The CreateParticipantRequest object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"CreateParticipantRequest":{"allOf":[{"$ref":"#/components/schemas/Participant"}]},"Participant":{"type":"object","additionalProperties":false,"properties":{"name":{"type":"string"},"lastname":{"type":"string","nullable":true},"bib":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true},"dob":{"type":"string","format":"date-time","nullable":true},"yob":{"type":"integer","nullable":true},"country":{"type":"string","nullable":true},"city":{"type":"string","nullable":true},"age_group":{"type":"string","nullable":true},"team":{"type":"string","nullable":true},"club":{"type":"string","nullable":true},"email":{"type":"string","format":"email","nullable":true},"telephone":{"type":"string","nullable":true},"group_id":{"type":"string","nullable":true},"race_token":{"type":"string","nullable":true},"custom_fields":{"type":"array","nullable":true,"items":{"$ref":"#/components/schemas/CustomField"}},"individual_start_time":{"type":"string","nullable":true,"description":"HH:mm:ss"}},"required":["name","bib"]},"CustomField":{"type":"object","additionalProperties":false,"properties":{"field_name":{"type":"string"},"value":{"type":"string","nullable":true}},"required":["field_name","value"]}}}}
```

## The ParticipantSummary object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"ParticipantSummary":{"type":"object","additionalProperties":false,"properties":{"event_token":{"type":"string"},"participant_token":{"type":"string"},"name":{"type":"string"},"lastname":{"type":"string","nullable":true},"bib":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"status":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true},"dob":{"type":"string","format":"date-time","nullable":true},"yob":{"type":"integer","nullable":true},"country":{"type":"string","nullable":true},"city":{"type":"string","nullable":true},"age_group":{"type":"string","nullable":true},"team":{"type":"string","nullable":true},"club":{"type":"string","nullable":true},"email":{"type":"string","format":"email","nullable":true},"telephone":{"type":"string","nullable":true},"group_id":{"type":"string","nullable":true},"race_token":{"type":"string","nullable":true},"custom_fields":{"type":"array","nullable":true,"items":{"$ref":"#/components/schemas/CustomField"}},"individual_start_time":{"type":"string","nullable":true}},"required":["event_token","participant_token","name"]},"CustomField":{"type":"object","additionalProperties":false,"properties":{"field_name":{"type":"string"},"value":{"type":"string","nullable":true}},"required":["field_name","value"]}}}}
```

## The ParticipantsListResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"ParticipantsListResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"type":"array","items":{"$ref":"#/components/schemas/ParticipantSummary"}},"pagination":{"$ref":"#/components/schemas/Pagination"}},"required":["description","result","pagination"]}},"required":["body"]},"ParticipantSummary":{"type":"object","additionalProperties":false,"properties":{"event_token":{"type":"string"},"participant_token":{"type":"string"},"name":{"type":"string"},"lastname":{"type":"string","nullable":true},"bib":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"status":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true},"dob":{"type":"string","format":"date-time","nullable":true},"yob":{"type":"integer","nullable":true},"country":{"type":"string","nullable":true},"city":{"type":"string","nullable":true},"age_group":{"type":"string","nullable":true},"team":{"type":"string","nullable":true},"club":{"type":"string","nullable":true},"email":{"type":"string","format":"email","nullable":true},"telephone":{"type":"string","nullable":true},"group_id":{"type":"string","nullable":true},"race_token":{"type":"string","nullable":true},"custom_fields":{"type":"array","nullable":true,"items":{"$ref":"#/components/schemas/CustomField"}},"individual_start_time":{"type":"string","nullable":true}},"required":["event_token","participant_token","name"]},"CustomField":{"type":"object","additionalProperties":false,"properties":{"field_name":{"type":"string"},"value":{"type":"string","nullable":true}},"required":["field_name","value"]},"Pagination":{"type":"object","additionalProperties":false,"properties":{"page":{"type":"integer","minimum":1},"limit":{"type":"integer","minimum":1},"total":{"type":"integer","minimum":0},"has_more":{"type":"boolean"}},"required":["page","limit","total","has_more"]}}}}
```

## The ParticipantGetResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"ParticipantGetResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"result":{"$ref":"#/components/schemas/ParticipantSummary"}},"required":["description","result"]}},"required":["body"]},"ParticipantSummary":{"type":"object","additionalProperties":false,"properties":{"event_token":{"type":"string"},"participant_token":{"type":"string"},"name":{"type":"string"},"lastname":{"type":"string","nullable":true},"bib":{"type":"string","nullable":true},"chip":{"type":"string","nullable":true},"status":{"type":"string","nullable":true},"gender":{"type":"string","nullable":true},"dob":{"type":"string","format":"date-time","nullable":true},"yob":{"type":"integer","nullable":true},"country":{"type":"string","nullable":true},"city":{"type":"string","nullable":true},"age_group":{"type":"string","nullable":true},"team":{"type":"string","nullable":true},"club":{"type":"string","nullable":true},"email":{"type":"string","format":"email","nullable":true},"telephone":{"type":"string","nullable":true},"group_id":{"type":"string","nullable":true},"race_token":{"type":"string","nullable":true},"custom_fields":{"type":"array","nullable":true,"items":{"$ref":"#/components/schemas/CustomField"}},"individual_start_time":{"type":"string","nullable":true}},"required":["event_token","participant_token","name"]},"CustomField":{"type":"object","additionalProperties":false,"properties":{"field_name":{"type":"string"},"value":{"type":"string","nullable":true}},"required":["field_name","value"]}}}}
```

## The CreateParticipantResponse object

```json
{"openapi":"3.0.3","info":{"title":"RUFUS Public REST API","version":"0.1.0"},"components":{"schemas":{"CreateParticipantResponse":{"type":"object","additionalProperties":false,"properties":{"body":{"type":"object","additionalProperties":false,"properties":{"description":{"type":"string"},"event_token":{"type":"string"},"participant_token":{"type":"string"},"result":{"type":"object","additionalProperties":true}},"required":["description","event_token","participant_token"]}},"required":["body"]}}}}
```


# Introduction to RUFUS Race Manager

Welcome to **RUFUS Race Manager**—your comprehensive, cloud-based solution for race timing and event management. Designed for both professional timers and event organizers, RUFUS Race Manager (RRM) streamlines every aspect of your race events, from registration to results, ensuring a seamless experience for you and your participants.

<figure><img src="/files/7nrAJHX8YsnUmw9ZFIIK" alt=""><figcaption><p>Race Dashboard in Map View in RUFUS Race Manager</p></figcaption></figure>

## What is RUFUS Race Manager?

RUFUS Race Manager is a cutting-edge software application that revolutionizes how race events are managed. Whether you're organizing a local fun run, a cycling race, or an international marathon, RRM provides all the tools you need to execute your event flawlessly. Its intuitive interface and robust features make race management efficient and stress-free.

## Key Benefits

### **Cloud-Based Flexibility**

* **Access Anywhere, Anytime**: Being cloud-based, RRM allows you to access your event data from any location with internet connectivity. This ensures that you can manage your race details on the go, without being tied to a specific device or location.
* **Real-Time Updates**: Collaborate with your team in real-time. Any changes made are instantly updated across all devices, keeping everyone on the same page.

### **Cross-Platform Compatibility**

* **Windows and Mac Support**: RRM is available on both Windows and macOS platforms, providing flexibility and convenience regardless of your preferred operating system.
* **Seamless Experience**: Enjoy a consistent user experience across different devices, making it easier for your team to adopt and utilize the software effectively.

<figure><img src="/files/PPxVObiVUmBptxRAYrJp" alt=""><figcaption><p>Race Podiums Report in RUFUS Race Manager</p></figcaption></figure>

### **Offline Working Mode**

* **Uninterrupted Management**: Don't let unreliable internet connections halt your progress. RRM supports offline working modes, allowing you to continue managing your event without interruption.
* **Automatic Data Syncing**: Once you're back online, RRM automatically syncs your data to the cloud, ensuring that all information is up-to-date and no work is lost.

### **High Performance and Scalability**

* **Efficient Processing**: Built with advanced technologies, RRM delivers high-speed performance, handling large volumes of data without lag or slowdown.
* **Scalable Solutions**: Whether you're managing a small local race or a large-scale international event, RRM scales effortlessly to meet your needs.

### **User-Friendly Interface**

* **Intuitive Design**: Navigate through the software with ease thanks to its user-friendly interface, designed to simplify complex tasks.
* **Customizable Features**: Tailor the software to suit your specific event requirements, enhancing productivity and efficiency.

<figure><img src="/files/wabxfw2Dnq3sijNkTHoc" alt=""><figcaption><p>Results View</p></figcaption></figure>

### **Secure and Reliable**

* **Robust Security**: Protect your data with advanced security features that safeguard against unauthorized access and data breaches.
* **Reliable Infrastructure**: Benefit from a dependable platform with minimal downtime, ensuring that your event management processes run smoothly.

## Why Choose RUFUS Race Manager?

Choosing RUFUS Race Manager means investing in a solution that combines innovation with practicality. Its cloud-based nature and offline capabilities ensure that you're always equipped to manage your event, regardless of external circumstances. The cross-platform support enhances collaboration among team members using different operating systems.

By leveraging modern technological advancements, RRM offers a powerful yet accessible tool that adapts to the evolving needs of race event management. From simplifying administrative tasks to providing real-time data access, RRM empowers you to deliver exceptional race experiences.

***

Embrace the future of race management with RUFUS Race Manager, and take your events to the next level of excellence.


# Introduction to Race Timing and Race Timing Software

Race timing is a critical component of organizing successful sporting events, whether it's a local 5K run, a cycling race, or an international marathon. Accurate timing not only determines winners but also enhances the overall experience for participants and spectators alike. In the digital age, race timing software has become an indispensable tool for event organizers, streamlining processes from registration to result dissemination.

This guide provides a comprehensive introduction to race timing from a software perspective, highlighting the importance of a well-prepared database, effective participant classification, and the collection of essential data to ensure accurate and meaningful results.

## The Role of Race Timing Software

Race timing software automates and simplifies many aspects of event management:

* **Data Management**: Handles participant registration details and stores critical information securely.
* **Timing and Scoring**: Interfaces with timing devices to record finish times accurately.
* **Results Processing**: Calculates rankings based on various classifications and criteria.
* **Communication**: Distributes results to participants and media efficiently.
* **Event Reporting**: Generates comprehensive reports for organizers and stakeholders.

By leveraging technology, race timing software enhances accuracy, saves time, and reduces the likelihood of human error.

## Importance of a Well-Prepared Database

A well-structured database is the backbone of any race event. It ensures that all participant information is accurate, accessible, and ready for use during the event. Key benefits include:

* **Accurate Timing and Results**: Precise participant data leads to correct timing assignments and results calculations.
* **Efficient Event Management**: Streamlines administrative tasks, allowing organizers to focus on other critical aspects of the event.
* **Enhanced Participant Experience**: Participants receive accurate information, fostering trust and satisfaction.

## Understanding Participant Classifications

Classifications are used to group participants for ranking and awards. Common classifications include:

* **Age Groups**: Participants are divided into age brackets (e.g., 18-29, 30-39).
* **Gender Categories**: Separate rankings for male, female, and non-binary participants.
* **Skill Levels**: Categories such as amateur, professional, or elite.
* **Team or Club Affiliations**: Grouping participants who are part of the same organization.
* **Special Categories**: Such as wheelchair divisions or local residents.

### **Why Classifications Matter:**

* **Fair Competition**: Ensures participants compete against peers of similar age or skill.
* **Recognition and Awards**: Provides opportunities to acknowledge more participants.
* **Customized Results**: Allows for tailored reporting based on specific groups.

## Collecting Essential Participant Information

To facilitate accurate timing and meaningful classifications, collect the following information during registration:

### Mandatory Data:

* **Full Name**: For identification and results listing.
* **Date of Birth or Birth Year**: Essential for age group classifications.
* **Gender**: Necessary for gender-specific categories.
* **Contact Information**: Email and phone number for communication and emergencies.
* **Race Category Selection**: If multiple races or distances are offered.

### Optional Data:

* **Nationality or Residence**: For events with international participants or local awards.
* **Team or Club Name**: If team rankings or affiliations are recognized.
* **Emergency Contact Details**: For participant safety during the event.
* **T-Shirt Size or Preferences**: For merchandise distribution.
* **Medical Information**: Allergies or conditions organizers should be aware of.
* **Custom Questions**: Any additional information pertinent to the specific event.

### **Best Practices for Data Collection:**

* **Clear Instructions**: Guide participants on how to fill out forms correctly.
* **Mandatory Fields**: Mark essential fields as required to prevent incomplete registrations.
* **Privacy Compliance**: Ensure data collection complies with relevant privacy laws and regulations.
* **Data Verification**: Implement checks to confirm the accuracy of the information provided.

## Timing and Scoring

Accurate timing is achieved through a combination of reliable hardware and effective software integration.

### Timing Hardware

* **Transponder Systems**: Use RFID chips attached to bibs or shoes.
* **Manual Timing**: For smaller events, manual entry with stopwatches may suffice.
* **Photofinish Cameras**: For events where finish order is critical.

### Software Integration

* **Real-Time Data Transfer**: Ensure the timing hardware communicates effectively with the software.
* **Redundancy Measures**: Implement backup systems in case of hardware failure.
* **Testing**: Conduct thorough tests before the event to verify system functionality.

## Processing and Publishing Results

After the race, timely and accurate results processing is crucial.

### Data Verification

* **Cross-Check Times**: Validate recorded times against backup systems if available.
* **Resolve Discrepancies**: Investigate and correct any anomalies.

### Classification Application

* **Apply Classifications**: Use the software to sort participants into their respective categories.
* **Adjustments**: Account for penalties, disqualifications, or adjustments as needed.

### Results Dissemination

* **Immediate Posting**: Publish preliminary results promptly.
* **Official Results**: Release final results after verification.
* **Multiple Channels**: Share results via websites, social media, email, and onsite displays.

## Enhancing Participant Experience

Race timing software can contribute significantly to participant satisfaction.

### Personalized Communication

* **Confirmation Emails**: Send immediate confirmations upon registration.
* **Event Updates**: Keep participants informed about event details.
* **Post-Race Follow-Up**: Share results and thank participants.

### Live Tracking and Updates

* **Real-Time Results**: Provide live updates during the event for spectators and participants.
* **Mobile Apps**: Offer apps for participants to track their performance and receive notifications.

## Best Practices and Tips

* **Start Early**: Begin data collection and system setup well in advance.
* **Training**: Ensure your team is proficient with the software and hardware.
* **Dry Runs**: Conduct test events to identify and resolve issues.
* **Feedback Loops**: After the event, gather feedback to improve future races.

## Conclusion

Effective race timing is a blend of precise data management, reliable technology, and thoughtful planning. By focusing on building a comprehensive database and utilizing race timing software, organizers can deliver accurate results, enhance participant satisfaction, and streamline event operations. Embracing these best practices sets the foundation for successful events and positive experiences for all involved.


# Excel 101: Handling Participant Data

Excel is a powerful tool for managing participant data in race timing events. Knowing the basic functions and formulas in Excel is essential for efficiently preparing and organizing participant lists, which will later be uploaded to the timing software for race classification. In this article, we’ll cover some of the key formulas and tips that are most useful for handling race data in Excel.

## Key Excel Formulas

### **1. CONCAT**&#x20;

* **Purpose**: Used to combine text from two or more cells into one cell.
* **Usage**: Often useful when you need to create full names or merge different pieces of data (like name and bib number).

**Syntax**:

```excel-formula
=CONCAT(text1, text2, ...)
```

**Example**:

```excel-formula
=CONCAT(A2, " ", B2)
```

If cell A2 contains the **First Name** and B2 contains the **Last Name**, this formula will combine the two into one cell with a space between them, producing something like **John Doe**.

***

### **2. VLOOKUP**

* **Purpose**: Looks for a value in the first column of a table and returns a value in the same row from a specified column. Useful for **finding bib numbers**, classification results, or participant information.
* **Usage**: This is helpful when matching participant bib numbers with names or other relevant data.

**Syntax**:

```excel-formula
=VLOOKUP(lookup_value, table_array, col_index_num, [range_lookup])
```

**Example**:

```excel-formula
=VLOOKUP(C2, $A$2:$B$100, 2, FALSE)
```

In this example, if **C2** contains a **bib number**, the formula will search for it in the first column of the range **A2**

and return the corresponding name from the second column.

* **Key Tip**: Use **FALSE** as the last argument to get an **exact match**.

***

### **3. MID**

* **Purpose**: Extracts a specific portion of text from a cell, based on the starting point and the number of characters you want to extract.
* **Usage**: This is handy when you need to extract specific parts of information, like a middle name or a specific digit from an ID or bib number.

**Syntax**:

```excel-formula
=MID(text, start_num, num_chars)
```

**Example**:

```excel-formula
=MID(A2, 1, 5)
```

This formula extracts the first **5 characters** from the text in cell **A2**. If A2 contains a bib number or a name, it will extract the first part (e.g., if A2 is "12345John", it will extract "12345").

***

### **4. IF**

* **Purpose**: Creates conditional statements, allowing you to make decisions within your data.
* **Usage**: Often used to apply different labels or classifications based on certain criteria (e.g., male/female or age group divisions).

**Syntax**:

```excel-formula
=IF(logical_test, value_if_true, value_if_false)
```

**Example**:

```excel-formula
=IF(B2="M", "Male", "Female")
```

If **B2** contains "M", this formula will return **Male**; otherwise, it will return **Female**.

***

### **5. SUMIF**

* **Purpose**: Adds the values in a range that meet specific criteria. Useful for summing times or points only for certain participants (e.g., those from a particular age group).
* **Usage**: Calculate total values based on a specific condition (e.g., only for participants from a particular city or team).

**Syntax**:

```excel-formula
=SUMIF(range, criteria, [sum_range])
```

**Example**:

```excel-formula
=SUMIF(B2:B100, "18-24", C2:C100)
```

This will sum all the values in **C2**

where the value in **B2**is equal to "18-24" (age group).

***

### **6. COUNTIF**

* **Purpose**: Counts the number of cells that meet a certain condition. Useful for counting participants in a specific category or group.
* **Usage**: This can help you see how many participants are in a certain category (e.g., males, females, a specific team).

**Syntax**:

```excel-formula
=COUNTIF(range, criteria)
```

**Example**:

```excel-formula
=COUNTIF(C2:C100, "Team A")e
```

This will count how many times **Team A** appears in the range **C2:C100**

***

### **7. TEXT**

* **Purpose**: Formats numbers as text, particularly useful for formatting dates, times, or bib numbers with leading zeros.
* **Usage**: If you need to standardize your data for uploading into the timing software, this is a key formula to use.

**Syntax**:

```excel-formula
=TEXT(value, format_text)
```

**Example**:

```excel-formula
=TEXT(A2, "00000")
```

If A2 contains the number **123**, this formula will return **00123**, preserving the 5-digit format.

***

### **8. LEFT, RIGHT**

* **Purpose**: Extracts a certain number of characters from the left or right side of a text string.
* **Usage**: Extract key parts of data from a larger string (e.g., initials, the last digits of bib numbers).

**Syntax**:

```excel-formula
=LEFT(text, num_chars)
=RIGHT(text, num_chars)
```

**Example**:

```excel-formula
=LEFT(A2, 3)
```

This will return the **first 3 characters** of the text in A2.

***

### **9. TRIM**

* **Purpose**: Removes extra spaces from text.
* **Usage**: This is crucial for cleaning up messy participant lists where extra spaces might have been entered, affecting the data upload process.

**Syntax**:

```excel-formula
=TRIM(text)
```

**Example**:

```excel-formula
=TRIM(A2)
```

This will remove all extra spaces from the text in cell **A2**.

***

## Organizing Data for Race Classification

When preparing Excel files for uploading to the timing software, ensure that:

1. **All necessary columns** (e.g., Name, Bib Number, Age, Gender, Team) are filled in and formatted correctly.
2. Use **consistent formatting** for all fields to prevent errors during the upload process.
3. **Remove any extra spaces** or irrelevant data using the **TRIM** function before finalizing the file.
4. Double-check formulas like **VLOOKUP** or **SUMIF** to ensure participant data is properly matched and summarized.

## Summary

Excel is a powerful tool for preparing race participant data, and knowing how to use its key formulas will make managing and organizing data easier. With formulas like **CONCAT**, **VLOOKUP**, **EXTRAE**, and others, you can efficiently format and prepare participant lists for smooth uploading into timing software, ensuring accurate race classification and results.


# Networks 101: Understanding the Basics for Race Timing

Efficient race timing relies not only on accurate software and hardware but also on a well-configured network infrastructure. **RUFUS Race Manager (RRM)** interacts with local LAN timing devices to collect and process timing data in real-time. Understanding the basics of networking is essential to ensure smooth communication between your timing devices and RRM.

This guide introduces fundamental networking concepts relevant to race timing, provides insights into setting up your network for optimal performance, and offers troubleshooting tips for common network issues.

## Introduction to Networking in Race Timing

In race events, timing devices capture the precise moments participants cross certain points (e.g., start, checkpoints, finish line). These devices need to communicate with RUFUS Race Manager to transmit this data for processing and result generation. A reliable network ensures that this communication is seamless, timely, and accurate.

Understanding the basics of networking enables you to:

* Set up your network correctly for race timing needs.
* Quickly identify and resolve connectivity issues.
* Optimize network performance to handle high data volumes.

## Basic Networking Concepts

Before diving into the specifics of network setup for race timing, let's review some fundamental networking concepts.

### IP Addresses

An **IP address** is a unique identifier assigned to each device on a network. It allows devices to locate and communicate with each other.

* **IPv4 Addresses**: Consist of four numbers separated by dots (e.g., 192.168.1.1).
* **Static IP**: Manually assigned and doesn't change.
* **Dynamic IP**: Automatically assigned by a DHCP server and may change over time.

### Routers and Switches

* **Router**: Connects multiple networks together and routes data between them. In a race timing setup, a router connects your local network to the internet.
* **Switch**: Connects devices within the same network, allowing them to communicate. It's essential for connecting multiple timing devices and computers within a LAN.

### Local Area Network (LAN) vs. Wide Area Network (WAN)

* **LAN**: A network that covers a small geographic area, like a race site. Devices within a LAN can communicate directly.
* **WAN**: A broader network that covers larger areas. The internet is the largest WAN.

## How RRM Interacts with Timing Devices

RUFUS Race Manager communicates with timing devices over the local network to receive timing data. Here's how they interact:

* **Data Transmission**: Timing devices send data packets containing participant IDs and timestamps to RRM.
* **Communication Protocols**: Typically uses TCP/IP protocols, which require proper network configuration.
* **Device Discovery**: RRM may need to discover devices on the network, which requires devices to be on the same subnet.

## Setting Up Your Network

Proper network setup is crucial for ensuring reliable communication between RRM and your timing devices.

### Network Requirements for RRM

* **Same Network Segment**: RRM and timing devices should be on the same LAN to facilitate direct communication.
* **Sufficient Bandwidth**: Ensure your network can handle the data load, especially for large events.
* **Low Latency**: Minimizes delays in data transmission, which is critical for accurate timing.

### Configuring IP Addresses

#### **Static vs. Dynamic IP Addresses**

* **Static IP Addresses**: Assign static IPs to timing devices to ensure consistent communication paths.
* **Dynamic IP Addresses**: Suitable for devices where static IPs are not critical, like staff laptops.

#### **Assigning Static IP Addresses**

1. **Access Device Settings**: Connect to your timing device's configuration interface.
2. **Set IP Address**: Assign an IP address within your network's range but outside the DHCP pool to prevent conflicts.
3. **Configure Subnet Mask**: Typically 255.255.255.0 for small networks.
4. **Set Default Gateway**: Usually the IP address of your router.

### Wired vs. Wireless Connections

#### **Wired Connections**

* **Advantages**:
  * More stable and reliable.
  * Less susceptible to interference.
* **Disadvantages**:
  * Limited mobility.
  * Requires physical cabling.

#### **Wireless Connections**

* **Advantages**:
  * Greater flexibility and mobility.
  * Easier setup in temporary locations.
* **Disadvantages**:
  * Potential for signal interference.
  * May have higher latency.

**Recommendation**: Use wired connections for timing devices whenever possible to ensure reliability.

## Troubleshooting Common Network Issues

Despite careful planning, network issues can occur. Here are common problems and solutions.

### Connectivity Problems

#### **Symptoms**:

* RRM cannot detect timing devices.
* Data from timing devices is not received.

#### **Solutions**:

1. **Check Physical Connections**: Ensure all cables are securely connected.
2. **Verify Device Status**: Confirm timing devices are powered on and functioning.
3. **Ping Devices**: Use the `ping` command to test connectivity.

   ```bash
   ping [device IP address]
   ```
4. **Network Configuration**: Ensure RRM and devices are on the same subnet.

### IP Address Conflicts

#### **Symptoms**:

* Intermittent connectivity issues.
* Devices disconnect unexpectedly.

#### **Solutions**:

1. **Check for Duplicate IPs**: Ensure no two devices share the same IP address.
2. **Adjust DHCP Range**: Modify the DHCP server settings to prevent overlap with static IP addresses.
3. **Assign New IPs**: Reassign IP addresses to conflicting devices.

### Firewall and Security Settings

#### **Symptoms**:

* Unable to establish communication despite correct settings.
* Data transmission is blocked.

#### **Solutions**:

1. **Disable Firewalls Temporarily**: Test if the firewall is causing the issue.
2. **Configure Firewall Rules**: Allow RRM and timing device communication through specific ports.
3. **Check Antivirus Software**: Ensure it's not blocking network communication.

   \
   **Example Firewall Rule**:

   * Allow inbound and outbound traffic on the ports used by timing devices (e.g., TCP/UDP port 8080).

### Network Interference (Wireless Networks)

#### **Symptoms**:

* Unstable connections.
* Slow data transmission.

#### **Solutions**:

1. **Reduce Interference**: Keep wireless devices away from sources of interference like microwaves or other wireless networks.
2. **Change Wi-Fi Channel**: Select a less congested channel in your router settings.
3. **Strengthen Signal**: Use Wi-Fi extenders or move closer to the access point.

## Best Practices for Network Setup

Implementing best practices helps prevent issues and ensures smooth operation.

* **Plan Ahead**: Assess network needs based on event size and device count.
* **Use Quality Equipment**: Invest in reliable routers, switches, and cabling.
* **Segment Your Network**: Separate timing devices from general internet traffic to reduce congestion.
* **Regular Testing**: Conduct network tests before the event day.
* **Documentation**: Keep records of IP addresses, network configurations, and device settings.

## Security Considerations

Protecting your network is essential to prevent unauthorized access and data breaches.

* **Secure Passwords**: Use strong passwords for all network devices.
* **Update Firmware**: Keep routers and devices updated with the latest firmware.
* **Disable Unused Services**: Turn off unnecessary services on devices to reduce vulnerabilities.
* **Network Encryption**: Use WPA3 or WPA2 encryption for wireless networks.
* **Access Control Lists (ACLs)**: Restrict access to network resources based on IP addresses.

## Conclusion

Understanding the basics of networking is crucial for effective race timing operations. By properly setting up your network, configuring devices, and being prepared to troubleshoot issues, you ensure that RUFUS Race Manager can communicate seamlessly with your timing devices. This results in accurate data collection, timely results processing, and a successful event.

Remember to:

* Stay proactive with network planning and testing.
* Keep security at the forefront of your network setup.
* Utilize wired connections for critical devices when possible.


# System Requirements for RUFUS Race Manager

Before you begin using **RUFUS Race Manager (RRM)**, it's important to ensure that your hardware and network infrastructure meet the necessary requirements. This guide outlines the minimum and recommended system specifications for both the web version and the local Windows application. Additionally, it provides suggestions for network equipment to optimize performance and reliability during your race events.

## Minimum and Recommended PC Requirements

RUFUS Race Manager is built on advanced technologies such as React, Node.js, Electron, and utilizes MongoDB Atlas along with AWS services. These technologies provide a robust and scalable platform but also have specific hardware requirements to function optimally.

### Hardware Specifications

#### **Minimum Requirements**

* **Processor**: Dual-core CPU (Intel Core i3 or equivalent)
* **Memory (RAM)**: 8 GB
* **Storage**: 2 GB of available disk space
* **Graphics**: Integrated graphics capable of 1024x768 resolution
* **Network Interface**: Ethernet port or Wi-Fi adapter
* **USB Ports**: At least one available USB port&#x20;

#### **Recommended Requirements**

* **Processor**: Quad-core CPU (Intel Core i5 or equivalent)
* **Memory (RAM)**: 16 GB or more
* **Storage**: 5 GB of available disk space (SSD preferred for faster performance)
* **Graphics**: Dedicated graphics card supporting higher resolutions
* **Network Interface**: Gigabit Ethernet port and dual-band Wi-Fi adapter
* **USB Ports**: Multiple USB 3.0 ports for peripherals

### Operating Systems

#### **Windows Application**

* **Minimum OS**: Windows 10 (64-bit)
* **Recommended OS**: Windows 11 (64-bit)

*Note: While RRM may run on Windows 7 or 8, these operating systems are outdated and no longer supported by Microsoft, which may pose security risks and compatibility issues.*

#### **Web Version**

* **Supported Browsers**: Latest versions of Google Chrome, Mozilla Firefox, Microsoft Edge
* **Operating Systems**: Windows 10/11, macOS Catalina or later,.

## Network Equipment Recommendations

A reliable network is crucial for seamless communication between RRM and your timing devices. The right routers and switches can significantly enhance data transmission speed and reliability.

### Routers

#### **Minimum Requirements**

* **Standards**: Supports IEEE 802.11n (Wi-Fi 4)
* **Frequency Bands**: 2.4 GHz
* **Ethernet Ports**: 10/100 Mbps ports
* **Features**: Basic firewall and security settings

#### **Recommended Routers**

* **Standards**: Supports IEEE 802.11ac or 802.11ax (Wi-Fi 5 or Wi-Fi 6)
* **Frequency Bands**: Dual-band (2.4 GHz and 5 GHz)
* **Ethernet Ports**: Gigabit Ethernet ports (10/100/1000 Mbps)
* **Features**:
  * Advanced Quality of Service (QoS) settings
  * Multiple SSIDs and guest network support
  * Robust security features (WPA3 encryption)
  * MU-MIMO and beamforming technologies for better wireless performance

#### **Suggested Models**:

* **Mid-Range**:
  * TP-Link Archer AX20
  * Netgear Nighthawk R7000
* **High-End**:
  * ASUS RT-AX88U
  * Linksys MX5 Velop AX Whole Home Wi-Fi 6 System

### Switches

#### **Minimum Requirements**

* **Type**: Unmanaged switch
* **Ports**: At least 8 x 10/100 Mbps Ethernet ports
* **Features**: Plug-and-play functionality

#### **Recommended Switches**

* **Type**: Managed Gigabit switch
* **Ports**: 16 or more Gigabit Ethernet ports
* **Features**:
  * VLAN support for network segmentation
  * QoS prioritization
  * Link aggregation for increased bandwidth
  * Energy-efficient design

#### **Suggested Models**:

* **Mid-Range**:
  * Netgear GS316 (Unmanaged)
  * TP-Link TL-SG1016DE (Easy Smart Switch)
* **High-End**:
  * Cisco SG350-28 (Managed)
  * Ubiquiti UniFi Switch US-24 (Managed)

## Additional Considerations

### Internet Connectivity

While RRM supports offline working modes, an internet connection is required for:

* Initial software installation and updates
* Synchronizing data with the cloud
* Accessing online features and support

#### **Recommendations**:

* **Bandwidth**: Minimum 5 Mbps download/upload speed; 10 Mbps or higher is recommended for smoother operation
* **Connection Type**: Wired connections are preferred for stability, especially during events

### Peripheral Devices

Consider the following peripherals to enhance your race management setup:

* **Printers**: For printing start lists, results, and certificates
  * **Recommendation**: Laser printers for faster printing and better quality
* **Backup Storage**: External hard drives or USB flash drives for data backup
  * **Recommendation**: Devices with at least 16 GB capacity and USB 3.0 support
* **Uninterruptible Power Supply (UPS)**: To protect against power outages
  * **Recommendation**: UPS units with surge protection and enough capacity to keep your system running for at least 15 minutes
* **Monitors**: Dual-monitor setups can improve workflow efficiency
  * **Recommendation**: Monitors with Full HD (1920x1080) resolution or higher

## Conclusion

Ensuring that your hardware and network infrastructure meet the minimum and recommended requirements is essential for the optimal performance of RUFUS Race Manager. Adequate preparation helps prevent technical issues during critical moments of your race events.

### **Key Takeaways**:

* **Hardware**: Invest in a modern computer with sufficient processing power and memory to handle the demands of RRM
* **Network Equipment**: Use reliable routers and switches that offer the necessary features to maintain a stable and secure network
* **Additional Equipment**: Consider peripherals and backup solutions to enhance functionality and protect against data loss

By meeting these requirements and recommendations, you'll be well-equipped to leverage the full capabilities of RUFUS Race Manager, ensuring a seamless and successful race event experience.


# Installing RUFUS Race Manager

RUFUS Race Manager is available for Windows and macOS. For macOS, make sure you download the correct version for your processor type:

* **macOS x64**: for Intel-based Macs
* **macOS arm64**: for Apple Silicon Macs, such as M1, M2, M3, or later
* **Windows**: for Windows computers

## Download RUFUS Race Manager

Download the installer from the official RUFUS Race Manager download page:

**rm.runonrufus.com**

Use the download button for your operating system and processor type.

## Before Installing

If you already have a previous version of RUFUS Race Manager installed, uninstall or remove it before installing the latest version.

This is especially recommended when replacing an older beta version or moving between different installer types.

## Installing on Windows

1. Download the Windows installer.
2. Open the downloaded `.exe` file.
3. Follow the installation steps.
4. Once the installation is complete, launch RUFUS Race Manager from the desktop shortcut or the Start Menu.

RUFUS Race Manager may not launch automatically after installation.

## Installing on macOS

1. Download the correct macOS version:
   * `x64` for Intel Macs
   * `arm64` for Apple Silicon Macs
2. Open the downloaded `.dmg` file.
3. Drag **RUFUS Race Manager** into the **Applications** folder.
4. Open RUFUS Race Manager from the Applications folder.

### macOS Security Message: “Damaged” or “Dangerous” App

In some cases, macOS may show a message saying that RUFUS Race Manager is **“damaged”** or **“dangerous”**.

This is usually caused by a quarantine flag added by macOS during the download process, especially when the app is downloaded using Chrome. It does not necessarily mean that the application is damaged.

To resolve this:

1. Delete the current RUFUS Race Manager app by moving it to the Bin.
2. Download RUFUS Race Manager again, preferably using **Safari**.
3. Move the app to the **Applications** folder.
4. Open **Terminal**.
5. Run the following command:

```
xattr -cr /Applications/RUFUS\ Race\ Manager.app
```

After running the command, open RUFUS Race Manager again from the Applications folder.

## First Launch

When RUFUS Race Manager opens for the first time:

1. Log in with your RUFUS account.
2. Complete any required on-screen setup.
3. Check that the application is updated before using it at an event.

## Installation Troubleshooting

If the installer does not open or the application does not start:

* Confirm that you downloaded the correct version for your operating system.
* On Windows, make sure your user has permission to install applications.
* On macOS, confirm that the app is inside the Applications folder before running the Terminal command.
* If security software blocks the installation, review the warning and allow RUFUS Race Manager only if it was downloaded from the official RUFUS source.

Keep the installer available until you confirm that RUFUS Race Manager opens correctly.


# Initial Configuration

After installing **RUFUS Race Manager (RRM)**, the next step is to set up your account and configure the software for the first use. This guide will walk you through creating a cloud account, logging in, and setting up your first event.

## Creating a RUFUS Race Manager Account

To use RRM, you need a cloud account that synchronizes your data and allows access across devices. Follow these steps to create your account:

### Step 1: Visit the RUFUS Cloud Portal

* Open your web browser and navigate to the cloud portal at `cloud.runonrufus.com`.

### Step 2: Start the Registration Process

* Click on the **"Register"** button to begin the registration.

### Step 3: Enter Your Details

* **Email Address**: Provide a valid email address that you have access to.
* **Password**: Create a strong password for your account.
  * Password requirements may include a minimum number of characters, and the inclusion of uppercase letters, numbers, or special characters.

### Step 4: Accept Terms and Conditions

* Review the terms of service and privacy policy.

### Step 5: Complete Registration

* Click on the **"Create new account"** button to submit your information.

### Step 6: Verify Your Email Address

* Check your email inbox for a verification message and code.
* The email will contain a verification code to confirm your account.

### Step 7: Enter the Verification Code (If Applicable)

* Return to the cloud portal.
* Enter the verification code from the email.
* Click **"Verify"** to complete the process.

*Your RUFUS Race Manager account is now created and verified.*

## **Changing the Default Language**

To change the language displayed in RRM, simply go to your **Cloud Profile** at [cloud.runonrufus.com/profile](https://cloud.runonrufus.com/profile) and select your preferred language. This change will automatically be applied in RRM as well.

## Logging In for the First Time

With your account set up, you're ready to log in to RUFUS Race Manager and begin exploring its features.

### Step 1: Launch RUFUS Race Manager

* Open the RRM application on your computer.
  * **Windows and Users**: Use the desktop shortcut or find RRM in the Start menu.
  * **Web Version**: If using the web version, navigate to `rm.runonrufus.com` in your browser.

### Step 2: Access the Login Screen

* Click the **"Sign in"** button to display the Login modal.

### Step 3: Enter Your Credentials

* **Email Address**: Input the email address you used during registration.
* **Password**: Enter your password.

### Step 4: Log In

* Click the **"Login"** button to access your account.

*You are now logged in to RUFUS Race Manager.*

## Synchronization Process on Desktop Applications

When you log in from the Windows (or Mac) application for the first time, RUFUS Race Manager will:

* **Check for Existing Data**: The software connects to the cloud to retrieve any existing events, participants, and settings associated with your account.
* **Sync Data Locally**: All available information is downloaded and stored locally on your device.
* **Enable Offline Access**: Once synchronization is complete, you can use RRM without an internet connection.

**Important Note**: The initial login and synchronization are essential for offline functionality. Without completing this step, the application won't have the necessary data to operate offline.

### Benefits of Local Synchronization

* **Work Offline**: Manage your events and data without needing an active internet connection.
* **Faster Access**: Local data access can improve performance and reduce loading times.
* **Data Backup**: Local copies of your data provide an additional layer of security.

## Working Offline with RUFUS Race Manager

After the initial synchronization, you can use RRM without an internet connection. Here's what you need to know:

### Offline Capabilities

* **Full Functionality**: Most features of RRM are available offline, including event management, participant handling, and timing data processing.
* **Data Entry**: You can continue to add or modify events, participants, and timing data.
* **Local Storage**: All changes are saved locally on your device.

### Synchronization upon Reconnecting

* **Automatic Sync**: When you reconnect to the internet, RRM will automatically sync your local changes with the cloud.
* **Data Consistency**: This ensures that your data is up-to-date across all devices associated with your account.
* **Conflict Resolution**: In case of conflicts (e.g., the same data modified on different devices), RRM will resolve them automatically.

### Best Practices for Offline Use

* **Regular Syncing**: Connect to the internet periodically to sync your data and prevent large data discrepancies.
* **Device Management**: Be cautious when working offline on multiple devices simultaneously to avoid sync conflicts.

## Tips for First-Time Users

* **Complete Your Profile**: Add any missing information to your cloud user profile for a personalized experience.
* **Explore the Settings**: Adjust application settings to suit your preferences, such as language or notification preferences.
* **Check for Tutorials**: Look for any in-app tutorials or help sections that provide additional guidance.
* **Stay Updated**: Keep an eye out for software updates to access new features and improvements.

## Troubleshooting Login and Sync Issues

If you encounter any problems while logging in or during synchronization:

* **Forgot Password**: Use the **"Forgot Password"** link to reset your password via email.
* **Email Verification**: Ensure that your email address is verified. Check for the verification email and follow the instructions.
* **Internet Connection**: Verify that you have a stable internet connection during initial login and synchronization.
* **Firewall Settings**: Ensure that your firewall or antivirus software is not blocking RRM from accessing the internet.
* **Contact Support**: If issues persist, consider reaching out to the support team for assistance.

## Conclusion

Setting up your RUFUS Race Manager account and configuring your first event are crucial steps to leveraging the full potential of the software. By understanding the synchronization process, you can effectively use RRM both online and offline, ensuring flexibility and reliability during your race events.

Happy racing!


# User Interface Overview

The **RUFUS Race Manager (RRM)** user interface is designed to be intuitive and efficient, providing you with the necessary tools to manage participants, create races, and monitor race events seamlessly. This overview will introduce you to the main components of the RRM interface and guide you through its workflow, focusing on the tab-based navigation system that facilitates multitasking.

<figure><img src="/files/sqCoHzFDSIPbOMyVZAmZ" alt=""><figcaption><p>Main Workspace Area</p></figcaption></figure>

## Main Parts of the Screen

### 1. Sidebar Menu

The **Sidebar Menu** is located on the left-hand side of the screen and is your main navigation tool for accessing different sections of the software. The key sections accessible from the Sidebar Menu include:

* **Event Control**: Manage general settings and monitor the event's overall progress.
* **Participants**: View, add, and manage participants for each event.
* **Results**: Access race results and classifications.
* **Checkpoints**: Set up and manage checkpoints for each race.
* **Races**: Create and configure different races within your event.
* **Segments**: Define segments between checkpoints for timing analysis.
* **Team Cups:** Create team results that are calculated across one or more races.
* **Groups**: Define participants groups and age groups.&#x20;
* **Devices**: Connect and manage timing devices.
* **Settings**: Located at the bottom of the sidebar, this section allows you to adjust application settings and preferences.

### 2. Tab-Based Workspace

The **Tab-Based Workspace** is central to the RRM interface and provides a flexible way to manage multiple aspects of your event simultaneously. Each time you open a section (such as participant details, race results, or event control), it is displayed in a new tab at the top of the workspace.

* **Multiple Tabs**: You can open several tabs at once to work on different aspects of your event without losing track of your progress.
* **Tab Management**: Tabs can be closed individually by clicking the **"X"** on each tab, allowing you to keep only relevant sections open.
* **Quick Switching**: Switching between tabs allows you to quickly move from participant management to viewing results, ensuring an efficient workflow.

### 3. Main Workspace Area

The **Main Workspace Area** is where you perform the bulk of your tasks. This section changes based on the selected tab and displays the relevant tools and information.

### 4. Quick Actions Menu

At the top-right corner of the interface, you will find the **Quick Actions Menu**, which provides fast access to commonly used tools and system controls:

* **Simulator**: Allows you to simulate selected races for testing timing configurations and race behavior.
* **Screens**: Opens the **Screen Manager**, where you can launch and manage spectator-facing live screens.
* **Event Selector**: Lets you quickly switch between different events that you have created or are managing.
* **Help**: Opens the help documentation for RUFUS Race Manager.
* **Account Controls**: Options to **Sign Out** of the application.
* **Cloud Sync Status**: Displays the current synchronization status with the RUFUS Cloud, including connection state, last sync time, and queue activity.

### 5. Grids for Data Display

**RUFUS Race Manager** utilizes grids to display information, such as participant details, results, and other event-related data. These grids are highly flexible and provide various features to make data management easy:

* **Sorting**: Click on column headers to sort data (e.g., by name, bib number, or status).
* **Grouping**: Group participants or results based on specific criteria for easier management.
* **Searching**: Use the search bar to quickly locate specific records.
* **Action menu**: With a right click you can display the grids' actions menu, with options like delete, reprocess passings, etc.

The grid system ensures that you have full control over how information is displayed, helping you manage events efficiently.

### 6. Race Notifications Widget

The **Race Notifications widget** provides real-time alerts generated by race judges using the **RUFUS Race App**. These notifications allow race operators to stay informed about important race events and decisions without leaving the Race Manager interface. Alerts may include events such as lead runners passing a checkpoint, the first participant of a category arriving, participants running without a bib, applied penalties or bonuses, and team communications between race officials.&#x20;

Notifications are displayed chronologically and include contextual information such as the reporting judge, checkpoint location, and timestamp. This widget acts as a live communication bridge between the field judges using the Race App and the race control team managing the event in RRM.

### 7. Version Indicator

At the bottom right of the screen, the **version number** of the application is always displayed. This helps you verify which version of RRM is currently running, ensuring you are up to date with the latest features and fixes.

## Workflow with Tabs

The **tab-based approach** in RUFUS Race Manager is designed to improve productivity by allowing you to multitask effectively. Here is how you can make the most out of it:

1. **Manage Multiple Aspects Simultaneously**: Open tabs for different aspects of your event, such as participants, checkpoints, and event control. This allows you to easily switch between tasks without losing your place.
2. **Focus on What's Important**: Keep only the tabs that are currently relevant to you. For example, while preparing for an event, you might have tabs open for adding participants, configuring checkpoints, and setting up timing devices.
3. **Monitor Event Progress**: During the race, keep tabs open for participant lists and live results to get an overview of ongoing activities. The flexibility to switch between tabs helps you monitor various aspects of the event concurrently.

## Tips for Using the Interface Efficiently

* **Use the Search Function**: When managing many participants, use the search bar to quickly find specific individuals.
* **Organize Tabs**: Close tabs that are no longer needed to keep your workspace organized and reduce clutter.
* **Regular Saving**: Although RRM saves data automatically, it's a good practice to ensure changes are saved before switching focus, especially when editing participant information or event settings.

## Conclusion

The **RUFUS Race Manager** user interface is designed to streamline race management through a combination of intuitive navigation and a flexible tab-based workspace. Understanding the different components of the interface and how to use the tab system effectively will help you manage your events with greater efficiency and ease.

Feel free to explore the interface and familiarize yourself with the various features, ensuring you get the most out of RUFUS Race Manager.


# Event Structure

In **RUFUS Race Manager (RRM)**, every event is built on a clear and flexible structure that defines how timing data is collected, organized, and used to calculate results. Understanding this hierarchy is essential for setting up and managing races effectively.

<figure><img src="/files/ZGgw2AfUZjVDyCV029lw" alt=""><figcaption><p>Event Structure Diagram</p></figcaption></figure>

## Event

The **Event** is the top-level container. It represents the entire competition and may include one or multiple races.

* Example: An event called *Run to the Hills 2025* may contain a *21k race* and a *3k fun run*.

## Races

Each **Race** defines a competitive unit within the event. Races have their own:

* Start time
* Checkpoints
* Segments
* Participants

This allows multiple races to coexist within a single event while keeping timing data separate.

## Checkpoints

A **Checkpoint** is a physical or logical location where passings are captured.

* **Start** → Marks the beginning of the race (lap 0).
* **Finish** → Marks the end of the race (lap 9999).
* **Intermediate checkpoints** → Provide splits, pacing information, and course validation.

Checkpoints can be **shared** (e.g., Start and Finish on the same mat) or **separate** for finer control (e.g., Start closed independently, Finish kept open).

## Segments

A **Segment** represents the section of the course between two checkpoints. Segments are used for splits, rankings, and analysis.

Types of segments include:

* **Standard Segments** → Defined between consecutive checkpoints (e.g., *Start → 10k*, *10k → Finish*).
* **Full-Course Segments** → Defined across the entire race (e.g., *Start → Finish*).
* **Race Order Segment** → A special segment (e.g., *Gunshot → Finish*) used to determine the official order of finishers for the race.

Every race must have at least one **Race Order Segment** to establish rankings.

## Summary

The event structure in RRM follows a logical hierarchy:

* **Event** → contains multiple **Races**
* **Races** → built from **Checkpoints**
* **Checkpoints** → connected by **Segments**

This structure ensures that timing data is always consistent, flexible, and ready for classification. By carefully setting up checkpoints and segments, timers can manage everything from simple fun runs to complex multi-split races with confidence.


# Creating a New Event

Creating a new event in **RUFUS Race Manager (RRM)** is the first step to managing and organizing races effectively. This guide will walk you through the process of creating a new event, understanding the different event statuses, and navigating the Event Select welcome screen.

<figure><img src="/files/8ng8dRL7Q6YCBj4OV9Wh" alt=""><figcaption><p>Event Select</p></figcaption></figure>

## Accessing the Event Select Screen

When you first log in to RRM, you will be presented with the **Event Select** screen. This screen allows you to create new events or access existing ones. The Event Select screen is divided into three main tabs:

1. **Upcoming Events**: Displays all upcoming events that have been scheduled.
2. **Past Events**: Lists all events that have already occurred.
3. **Draft Events**: Contains all events currently in draft mode.

New events are created with **Draft** status. Being in Draft status does not prevent you from timing the race or generating classifications; it only restricts public publication of participants and results via the RUFUS Event App. Once the feature for publishing events via the RUFUS Event App is available, users will be able to change the status from draft to published, making the event publicly accessible and engaging with participants and audiences.

## Creating a New Event

To create a new event from the Event Select screen, follow these steps:

<figure><img src="/files/OLbmlCP7ytxCiOD0Wxen" alt="" width="563"><figcaption><p>New Event Modal</p></figcaption></figure>

### Step 1: Click "New Event"

* On the Event Select screen, you will see a **"New Event"** button on the right-hand side.
* Click this button to open the event creation modal.

### Step 2: Fill in Event Details

A modal window titled **"Create a New Event from Scratch"** will appear, prompting you to enter basic event information:

* **Name**: Enter the name of your event.
* **Edition**: Add the edition of the event (e.g., 1st, 2nd, etc.). This helps distinguish between different iterations of the same event.
* **Start Date**: Specify the start date of the event.

These details are essential for identifying and organizing your event.

### Step 3: Save Your Event

* Once you have entered all the necessary details, click **"Save"** to create the event.
* If you decide not to create the event, click **"Cancel"** to exit the modal.

After saving, your new event will be added to the **Draft Events** list, allowing you to further configure and prepare it before making it publicly available.

## Tips for Creating Events

* **Be Descriptive**: When naming your event, use a descriptive title that will make it easy to identify among other events.
* **Draft Mode for Preparation**: Use the **Draft** status to thoroughly prepare your event before publishing it. This includes setting up all races, adding participants, and testing timing devices.
* **Future Publishing**: Keep an eye out for the event publishing feature to take full advantage of audience engagement via the RUFUS Event App.


# Managing Events

## Managing Existing Events

<figure><img src="/files/9sB5lUGLkTb4zzmnjxQw" alt=""><figcaption><p>Events List</p></figcaption></figure>

From the Event Select screen, you can manage existing events by clicking on them in the appropriate tab (Draft, Upcoming, or Past). This will open the event dashboard, where you can:

* **Edit Event Details**: Modify event information such as name, date, or edition.
* **Add Races and Participants**: Set up races and add participants to the event.
* **Monitor Event Progress**: Use the event control tools to monitor the event as it progresses.

## Event Statuses

### Draft Events

* **Draft** status is assigned to all newly created events. Events in this status are still being prepared and are not yet ready for public access.
* You can configure all aspects of the event while it is in draft mode, including adding participants, setting up races, and integrating timing devices.

### Upcoming and Past Events

* Once the event is **PUBLISHED**, they are moved from **Draft** to **Upcoming** or **Past** tabs correspondingly.


# Event Settings

The **Event Settings** screen in RUFUS Race Manager allows you to configure the main properties and operational behavior of the selected event.

To access it, select the **Settings** icon from the sidebar menu.

<figure><img src="/files/P8mcKfHBWeS3e279uOoB" alt=""><figcaption><p>Event Settings</p></figcaption></figure>

## General Settings

Use this section to edit the basic event information:

* **Name**: event name.
* **Edition**: event edition or version.
* **Start Date**: official event start date.
* **Event Location**: location associated with the event.

## Gender Mapping

Gender Mapping defines how RRM identifies and displays participant gender values in the event data grids.

For example, you can map values such as `M` and `F` so participants are visually categorized in a consistent way across the interface. You can introduce two or more values sepparated by comma.

## Timekeeping

The Timekeeping section defines the timing precision used by the event.

Available precision options may include:

* Seconds
* Tenths of a second
* Milliseconds

Select the precision that matches the timing requirements of the race.

## Event Reference Date

The Event Reference Date is used to calculate participant age.

This is especially important when age groups or categories depend on the participant’s age on a specific date.

## Participant Data Style

Participant Data Style controls how participant text fields are normalized when importing or editing participant records.

You can configure formatting rules for fields such as:

* Name
* Lastname
* City
* Team
* Club

For example, you can apply capitalization rules to keep participant data consistent and easier to read.

Use **Apply to Current Participants** to normalize the existing participant records using the selected formatting rules.

## Reference Table

The Reference Table allows you to manage the relation between **Chip / EPC values** and **bib numbers** for the event.

It is used to resolve passings, match chip reads with participants, and control chip visibility across the event interface.

From this section, you can:

* Review the current reference table status.
* Upload a CSV reference table.
* Add or edit individual rows.
* Search by chip or bib.
* Hide chip columns across the event UI.

For more details, see the [**Reference Table**](/rufus-race-manager/collecting-and-managing-timing-data/chip-to-bib-reference-table) help article.

## Automatic Publication Updates

Automatic Publication Updates define how a published event should refresh information in the RUFUS Events App.

When enabled, RRM can automatically update selected publication areas, such as:

* Participants
* Results
* Race progress

This setting is useful when the event is published and the public-facing information must remain synchronized during the race.

For more details, see the [**Automatic Publication Updates**](/rufus-race-manager/publishing-in-the-rufus-event-app/automatic-publication) help article.

## Notifications

The Notifications section controls which passing-related alerts are shown during event operation.

You can enable or disable notifications for:

* **VALID passings**: passings correctly matched and accepted.
* **EOTR & CLOSED passings**: passings outside the expected lap or received while a checkpoint, race, or device is closed.
* **ORPHAN, NO\_RACE & WRONG\_RACE passings**: passings not matched to a participant, linked to a participant without a race, or linked to the wrong race.
* **BOUNCED & TIME\_INVALID passings**: passings rejected due to bounce rules or invalid timing data.

Adjust these options according to the type of information you need to monitor during the race.

## Custom Fields

Custom Fields allow you to store additional participant information, such as:

* Address
* T-shirt size
* Company
* Any event-specific data field

Custom fields can be displayed, filtered, and grouped in participant, segment, and result views.

## Event Status

Event Status controls the visibility of the event in RUFUS Cloud and RUFUS Events App.

Published events can appear in the Cloud Events Dashboard and can be made available in the RUFUS Events App.

## Danger Zone

The Danger Zone contains operations that affect the entire event. Use these actions carefully.

### Export Event to File

Creates a full event backup file containing the event configuration and data.

This can be used for:

* Backups
* Moving events between systems
* Archiving event data

### Clone Event

Creates a copy of the current event configuration.

This is useful when preparing another edition of the same race using a similar structure.

### Reset Event

Clears operational event data, such as timing sessions and results, while preserving the event structure.

### Delete Event

Permanently removes the event from the system.

This action cannot be undone.

## Saving Changes

After modifying the event settings, click **Save** to apply the changes.


# Event Dashboard View

The **Event Control View** in **RUFUS Race Manager (RRM)** provides a complete and centralized workspace for monitoring, validating, and managing all passings of an event. It consolidates every captured passing—regardless of device, file, or source—into a single operational dashboard focused purely on raw timing data. This makes it the primary environment for real-time supervision during a race.

<figure><img src="/files/gHlIDdD6O6bNUT84NuFY" alt=""><figcaption><p>Event Control View</p></figcaption></figure>

## Main Features

#### Centralized passings management

All passings generated during the event—whether from CloudBox devices, backup files, manual inputs, or floating passings—are displayed and managed in one place.

#### Real-time visibility

Passings appear instantly as they are received from any source. The grid updates live without needing to refresh.

#### Flexible and powerful data grid

The data grid supports:

* Searching and instant filtering
* Sorting and grouping
* Column arrangement and customization
* Fast scrolling for large-scale events
* Exporting data to CSV

#### Floating passings

Floating passings let operators manually insert a passing anywhere in the race timeline. They are ideal for:

* Correcting missed reads
* Handling uncommon race situations
* Reconciling handwritten notes or manual observations

Floating passings are clearly marked to differentiate them from device-generated passings.

## Race Control Widgets

#### Race-level control

Each race includes a dedicated control widget showing:

* **Elapsed time** since the race start
* A **Process passings** toggle
* Visual indicators of the race’s processing state

These widgets allow operators to pause or resume passing processing per race, and to quickly understand the timing state of each race.

## Checkpoint Control Widgets

#### Checkpoint-level management

Each checkpoint appears with its own widget containing:

* A processing toggle
* Status and activity indicators

These controls allow operators to enable or disable the processing of individual checkpoints and to focus on specific segments of the course when needed.

## Global Start Time Widget

#### Multi-race start synchronization

When an event contains two or more races, the Global Start Time widget allows setting or adjusting the start time for multiple races simultaneously. This is especially useful for:

* Mass-start events
* Synchronizing multiple races sharing the same start line

## Grid Columns

| Column              | Description                                                        |
| ------------------- | ------------------------------------------------------------------ |
| **BIB**             | Participant’s bib number                                           |
| **Chip**            | RFID chip code assigned to the participant                         |
| **Name**            | Participant’s name                                                 |
| **Age Group**       | Participant’s age group, if defined                                |
| **Lap**             | Lap number associated with the passing                             |
| **Race**            | Race in which the participant competes                             |
| **Checkpoint**      | Checkpoint where the passing was recorded                          |
| **Virtual**         | Indicates if the passing belongs to a virtual lap, when applicable |
| **Sector**          | Sector number, when applicable                                     |
| **Racetime**        | Time elapsed since the race start                                  |
| **Time of the Day** | Exact timestamp of the passing                                     |
| **Status**          | Passing status (VALID, ORPHAN, INVALIDATED, EOTR, etc.)            |
| **Type**            | Type of passing (Local, Manual, Floating, Backup File, Cloud)      |
| **Device**          | Device or file source that generated the passing                   |

## **Context Actions**

Right-clicking a passing opens a contextual menu allowing you to:

* **Delete passing**
* **Reprocess passing**
* **Set passing as invalidated by user**

These tools are essential when resolving timing conflicts or adjusting data integrity.

## **Tips**

* Use the **search bar** to quickly isolate passings by bib, chip, or name.
* Combine **status filtering** with checkpoint widgets to resolve timing issues faster.
* Utilize **floating passings** for edge cases or manual corrections.


# Race Notifications

The **Race Notifications widget** provides real-time communication between race judges using the **RUFUS Race App** and race operators working in **RUFUS Race Manager (RRM)**.

<figure><img src="/files/CSnXuEMxUajY5ntBUbMi" alt=""><figcaption><p>Race Notification Widget</p></figcaption></figure>

It allows race control teams to receive important alerts, decisions, and field updates directly inside the timing interface without interrupting race operations.

Notifications are displayed in chronological order and include contextual information such as:

* The **judge who created the alert**
* The **checkpoint location**
* The **timestamp of the notification**
* Additional **descriptive notes when available**

This system helps race operators maintain awareness of events happening across the course.

## Widget Placement

The Race Notifications widget can appear in two different layouts depending on user preference.

### Attached Mode

<div><figure><img src="/files/bCWhlcVvwxxHQCf8XzBW" alt=""><figcaption><p>Attached Full-Collapsed Widget</p></figcaption></figure> <figure><img src="/files/LyFZaI7L2WRrJkAdEuTr" alt=""><figcaption><p>Attached Expanded Widget</p></figcaption></figure> <figure><img src="/files/1KKymk58f8K49SeZPZ6I" alt=""><figcaption><p>Attached Collapsed Widget</p></figcaption></figure></div>

In **attached mode**, the widget is docked to the **bottom of the interface**.

This layout keeps notifications visible while minimizing interference with other parts of the user interface. It is ideal when operators want to monitor alerts continuously during race operations.

### Floating Mode

<div><figure><img src="/files/nABfH4tIkkkm8mJH1p17" alt=""><figcaption><p>Floating Collapsed Widget</p></figcaption></figure> <figure><img src="/files/LkQbqG4SqDWFXPjgbFMS" alt=""><figcaption><p>Floating Expanded Widget</p></figcaption></figure></div>

In **floating mode**, the widget appears as a **movable panel** above the interface.

This allows race operators to reposition the widget anywhere on the screen while working with other race management views.

Floating mode is useful when notifications need to remain visible while interacting with other panels such as:

* Event Control
* Participant Editor
* Results
* Device Monitoring

## Expanded and Collapsed Views

The widget can be displayed in two states.

### Expanded View

In **expanded mode**, the widget shows the full list of notifications.

Each alert card includes:

* Notification title
* Judge name
* Checkpoint location
* Time of creation
* Optional description

This view is typically used when race operators want to review multiple alerts or monitor notifications in real time.

### Collapsed View

In **collapsed mode**, the widget shows only the **most recent alert**.

This compact view minimizes screen usage while still keeping the race team informed of the latest notification.

Users can expand the widget at any time to see the full alert list.

## Notification Categories

Race Notifications are grouped into categories to help organize communication between race officials.

### Race Alerts

These notifications report events observed by race judges on the course.

Examples include:

* Lead runner passing a checkpoint
* First female or male participant passing
* Suspicious race situations
* Participants running without a bib
* General race observations

Race alerts help race control monitor race dynamics and detect potential issues quickly.

### Penalty & Bonus

This category shows notifications related to **penalties or bonuses applied to participants**.

Examples include:

* Time penalties for rule violations
* Time bonuses granted by race officials
* Adjustments made during race review

These notifications provide transparency when race decisions affect participant results.

### Team Chat

The **Team Chat** section allows race officials to communicate directly with the race control team.

Messages may include:

* Operational updates
* Course status reports
* Equipment issues
* Coordination between checkpoints

This communication channel keeps race operations synchronized across the event.

## Notification Information

Each notification contains contextual information that helps race operators understand the situation quickly.

Typical notification data includes:

| Field              | Description                                  |
| ------------------ | -------------------------------------------- |
| Notification Title | Short description of the alert               |
| Judge Name         | Race official who generated the notification |
| Checkpoint         | Location where the event occurred            |
| Timestamp          | Time when the alert was created              |
| Description        | Additional details provided by the judge     |

## How Notifications Are Generated

Race Notifications are generated directly from the **RUFUS Race App** used by judges on the course.

Judges can:

* Send alerts
* Report race situations
* Apply penalties or bonuses
* Communicate with race control

Once submitted, notifications appear immediately in **RRM**, allowing the race control team to react quickly.

## Summary

The **Race Notifications widget** acts as a real-time communication bridge between the course and race control.

It allows race operators to:

* Monitor race events live
* Receive alerts from judges
* Track penalties and bonuses
* Communicate with the race team

With flexible layout options and real-time updates, Race Notifications help ensure race operations remain coordinated, informed, and responsive throughout the event.

For more information visit the related article about the [RUFUS Race App](/rufus-cloud/race-app/rufus-race-app-overview).


# Participants Menu

The **Participants Menu** in **RUFUS Race Manager (RRM)** is your primary tool for managing all participant-related tasks for your events.

## Accessing the Participants Menu

The **Participants Menu** is located on the left-hand side of the interface, represented by the **person icon** in the Sidebar Menu. Clicking on this icon will open the Participants section, where you can view and manage all participants within your event.

<figure><img src="/files/614097Zat77wDqBn1k1B" alt=""><figcaption><p>Participants Menu</p></figcaption></figure>

## Components of the Participants Menu

### 1. Participant Lists

The Participants Menu is divided into multiple categories to help you organize participants according to their respective races, which are previously created within the event. These categories include:

* **All**: Displays a complete list of participants across all races within the event.
* **21K**: Shows only participants registered for the **10K** race.
* **3k fun run**: Shows only participants registered for the **3k fun run** race.

### 2. Add Participants

Below the participant lists, you will find the **Add Participants** section. This section provides two options for adding participants to your event:

* **Add New**: Click the **"Add New"** button to manually add a participant. This allows you to enter all relevant participant details individually, such as bib number, name, gender, and age group.
* **Import from List**: Click the **"Import from List"** button to import participants in bulk from an external file (CSV is available for the moment). This feature is particularly useful when dealing with a large number of participants, saving time and effort.


# Manually Adding Participants

Adding participants manually in **RUFUS Race Manager (RRM)** is a simple and efficient way to ensure that all relevant details are accurately captured. This guide will walk you through the steps to manually add participants to your event, using the **Add Participant** modal.

## Accessing the Add Participant Dialog

To add a new participant manually, navigate to the **Participants Menu** located on the left-hand side of the RRM interface. In the **Add Participants** section, click the **"Add New"** button. This will open the **Add Participant** modal, where you can input all the necessary participant information.

<figure><img src="/files/AOGsSPJM3CwZR245Mgdc" alt=""><figcaption><p>Add Participant Dialog</p></figcaption></figure>

## Fields in the Add Participant Modal

> **Note**: The only mandatory field when adding a participant is **Name** and **Bib**. All other fields are optional, but providing more information can help with better participant management.

The **Add Participant** modal is divided into several sections to help you systematically enter all the details about a participant:

### 1. Personal Information

* **Name**: Enter the participant's first name.
* **Lastname**: Enter the participant's last name.
* **Gender**: Specify the participant's gender (e.g., **M** or **F**). Ideally, this value should match the gender values defined in the **Gender Mapping** section of the Settings to ensure consistency and to visually distinguish male and female participants in the grids throughout the software.
* **Date of Birth**: Enter the participant's date of birth, which helps determine their age group.
* **Country**: Select the participant's country from the dropdown list.
* **City**: Enter the city where the participant resides.

### 2. Registration Details

* **Bib Number**: Assign a unique bib number to the participant, which will be used for identification during the race. Note that bib numbers must be unique across the entire event, meaning they cannot be shared between different races.
* **Chip Code**: Enter the chip code that the participant will use for timing purposes. Similar to bib numbers, chip codes must be unique across the entire event and cannot be shared between different races.
* **Race**: Select the race in which the participant will compete (e.g., **10K**, **5K**). These races must be previously created within the event.
* **Individual Start Time**: Set the individual start times for your competitors. Perfect for events where racers set off separately—like downhill, irox, or time-trial competitions.
* **Age Group Code**: Specify the age group code that corresponds to the participant's age.
* **Group**: Enter any specific group that the participant belongs to, if applicable.
* **Team**: If the participant is part of a team, enter the team name here.
* **Club**: Enter the name of the club, if the participant belongs to one.

### 3. Contact Details

* **Email**: Enter the participant's email address for communication purposes.
* **Phone Number**: Enter the participant's phone number.

## Saving Participant Information

After filling in all the necessary fields, click the **"Save"** button at the bottom right of the screen to add the participant to the event. You can save a participant without assigning a race and assign the race later. Once saved, the participant will appear in the **Participants Menu**, and the form will reset to allow you to enter the information for a new participant. Close the tab when finished.

## Tips for Manually Adding Participants

* **Accuracy is Key**: Ensure that all the information entered is correct, especially bib numbers and chip codes, as these are essential for race timing and participant identification.
* **Complete All Relevant Fields**: While not all fields are mandatory, providing as much information as possible will help in effective participant management and communication.
* **Use Consistent Formats**: When entering information such as **Age Group, Club** or **Team**, use a consistent format to maintain data integrity and make searching, sorting, and grouping easier.


# Import Participants from List

**RUFUS Race Manager (RRM)** provides the ability to import participants in bulk using a CSV file, making it convenient for managing large-scale events. This guide will walk you through the process of importing participants from a list using the **Import Participants** modal.

## Accessing the Import Participants Dialog

To begin importing participants, navigate to the **Participants Menu** located on the left-hand side of the RRM interface. In the **Add Participants** section, click the **"Import from List"** button. This will open the **Import Participants** modal, where you can upload your CSV file and configure importation parameters.

## Steps to Import Participants

The importation process is divided into three main steps:

### Step 1: Upload Data

<figure><img src="/files/PI4k6sBXt4HUGLBbSIN4" alt=""><figcaption><p>Import Participants Step 1</p></figcaption></figure>

* **Upload CSV File**: In the **Import Participants** modal, click the upload area labeled **"Upload CSV Files"** to select your CSV file from your computer. The uploaded file should contain all relevant participant information such as names, bib numbers, chip codes, and any other required details.
* **Select Race to Import**: Before proceeding, use the dropdown menu to select which race the participants should be added to, or select **Get from file**.

> **Tip**: Ensure your CSV file is formatted correctly before uploading. Include column headers for better organization and easier parameter configuration.

### Step 2: Configure Importation Parameters

<figure><img src="/files/thcEGGCDMuehzQ4Wdsme" alt=""><figcaption><p>Import Participants Step 2</p></figcaption></figure>

Once the CSV or TXT file is uploaded, RRM displays the participant data in a preview grid and attempts to **automatically match the columns** from your file to the corresponding participant fields.

The system analyzes the **column headers** and compares them against a list of recognized aliases. When a match is detected, the column is automatically mapped to the correct participant field.

You can still manually adjust any column mapping before proceeding.

### Are Column Headers Available?

Enable this option if your file contains **column headers in the first row**.

When enabled, RRM will analyze those headers and attempt to automatically match them to participant fields.

### Automatic Column Matching

RRM attempts to automatically match CSV column headers with participant fields using a list of recognized aliases.

If a column header matches one of the following values (case-insensitive), the column will be mapped automatically.

<table><thead><tr><th width="244.82421875">Participant Field</th><th>Recognized Column Headers</th></tr></thead><tbody><tr><td><strong>Bib Number</strong></td><td>bib, race number, bibnumber, dorsal, number</td></tr><tr><td><strong>Chip Code</strong></td><td>chip, tag, rfid, transponder</td></tr><tr><td><strong>Name</strong></td><td>name, firstname, first name</td></tr><tr><td><strong>Lastname</strong></td><td>lastname, last name, surname, family name</td></tr><tr><td><strong>Gender</strong></td><td>gender, sex</td></tr><tr><td><strong>Date of Birth (DOB)</strong></td><td>dob, dateofbirth, date of birth, birthdate, birth date, fechadenacimiento, bdate</td></tr><tr><td><strong>Year of Birth (YOB)</strong></td><td>yob, yearofbirth, year of birth, birthyear, birth year</td></tr><tr><td><strong>Age Group</strong></td><td>agegroup, age group, categoria, category</td></tr><tr><td><strong>Group</strong></td><td>group, group id</td></tr><tr><td><strong>Individual Start Time</strong></td><td>start, start time, individualstarttime, starttime</td></tr><tr><td><strong>Country</strong></td><td>country, nation, nationality, nat, countrycode, country code</td></tr><tr><td><strong>City</strong></td><td>city, town, ciudad</td></tr><tr><td><strong>Team</strong></td><td>team, equipo</td></tr><tr><td><strong>Club</strong></td><td>club</td></tr><tr><td><strong>Email</strong></td><td>email, mail</td></tr><tr><td><strong>Telephone</strong></td><td>telephone, phone, phone number</td></tr><tr><td><strong>Race</strong></td><td>race, race name, course, carrera, evento, event</td></tr></tbody></table>

If a column header does not match any of these aliases, you can manually select the appropriate field using the dropdown selector above each column.

### Date Format

If your file includes **Date of Birth (DOB)** values, select the correct format used in the file (for example **dd/MM/yyyy**). This ensures participant birthdates are interpreted correctly during import.

### Step 3: Review & Import

<figure><img src="/files/xpCZcnDv7RuwKeRT01dN" alt=""><figcaption><p>Import Participants Step 3</p></figcaption></figure>

In the final step, RRM provides a **preview of the import results** before committing the changes.

This allows you to verify that the participant data has been correctly interpreted.

The preview shows the following information.

### Participants Ready to Import

Displays the total number of participant records detected in the uploaded file.

### New vs Updating Participants

RRM determines whether each row represents:

* **A new participant**, or
* **An update to an existing participant**

This detection is based on the **Bib number**, which is used as the primary identifier when importing.

For example:

* **New participants:** records not previously registered in the event.
* **Updating existing BIBs:** records that will update participant information for an existing bib.

### Race Detection

If your file contains a **Race column**, RRM will detect the races referenced in the file and match them with the races configured in the event.

The preview indicates:

* Races successfully matched
* Participants assigned to each race
* Any races that could not be matched automatically

### Unmapped Fields

If your file contains columns that were **not mapped to a participant field**, they will be listed here.

For example:

* Start Time
* Year of Birth (YOB)
* Email
* Telephone
* DNI

These fields will **not be imported unless they are mapped** in Step 2.

### Import Preview Table

The preview grid displays the participant data exactly as it will be imported.

You can quickly verify that fields such as:

* Bib
* Chip
* Name
* Lastname
* Race

are correctly interpreted.

### Import Participants

Once everything looks correct, click **Import** to finalize the process.

RRM will then create or update the participant records in the event.

## Tips for Importing Participants

* **Consistent Formatting**: Use consistent formatting across all columns in your CSV file to ensure a smooth import process. For example, ensure gender values (e.g., **M**, **F**) match the **Gender Mapping** settings in RRM for consistency.
* **Country Format**: If the country information for participants is in **ISO 3166-1 alpha-2** format (e.g., **US**, **ES**), RRM will automatically detect it and display the corresponding flag in the grids, making it visually easier to identify participant locations.
* **Backup Existing Data**: If you plan to use the **Make a Fresh Import** option, consider backing up your existing participant data to avoid accidental data loss.
* **Avoid Duplicates**: Make sure bib numbers and chip codes are unique across the event. Duplicates can cause issues with race timing and participant identification.

## Conclusion

The **Import Participants** feature in **RUFUS Race Manager** streamlines the process of adding multiple participants to your event, saving time and effort, especially for large-scale races. By following the steps outlined in this guide and configuring import settings correctly, you can ensure accurate and organized participant data for a successful event.


# Editing Participant Details

Editing participant details in **RUFUS Race Manager (RRM)** allows you to update information, manage race status, and keep track of passings accurately. This guide will help you understand how to edit a participant and use the available tools effectively.

## Accessing the Edit Participant Tab

To edit a participant, simply **double-click** on the participant you want to select. You can do this from any screen across the software, not just within a **Participants Grid**. This flexibility ensures you can quickly access and edit participant information wherever you are in the system.

When you open the editing tab, the participant's name will be displayed at the top of the tab, making it easy to differentiate between participants when managing multiple tabs.

<figure><img src="/files/TBaaFtLh4N5BUNQqqCXN" alt=""><figcaption><p>Edit Participant View</p></figcaption></figure>

## Editable Fields and Actions

The **Edit Participant** tab is divided into several sections where you can modify participant information and manage their race status and passings.

### 1. Personal Information

* **Name**: Modify the participant's first name if needed.
* **Lastname**: Update the participant's last name.
* **Gender**: Change the participant's gender, ensuring consistency with the **Gender Mapping** settings for accurate categorization.
* **Date of Birth**: Adjust the date of birth to correct or update participant records.
* **Country**: Select or change the country of the participant.
* **City**: Update the city where the participant resides.

### 2. Registration Details

* **Bib Number**: Update the participant's bib number if necessary. Remember that bib numbers must remain unique across the entire event.
* **Chip Code**: Modify the chip code used for timing purposes.
* **Race**: If the participant is registered in a race, you can change the race they are participating in.
* **Age Group Code**: Update the participant's age group code if applicable.
* **Group**: Modify the participant's group if needed.
* **Team**: Update the team name if the participant is part of a team.
* **Club**: Enter or modify the club name if applicable.

### 3. Contact Details

* **Email**: Update the participant's email address.
* **Phone Number**: Modify the participant's phone number.

### 4. Status, Laps, Segments, Passings and Rankings

If the participant is registered in a race, you will also be able to manage their **Status** and **Passings**:

* **Status**: Use the dropdown at the top of the tab to change the participant's current race status (e.g., **DNS**, **DNF**, etc.). See [Participant Statuses](/rufus-race-manager/participant-management/participant-statuses-notes-penalties-and-bonuses) article for more information.
* **Passings**: Manage the participant's passings by adding, deleting, or marking passings as **VALIDATED** or **INVALIDATED**. See [Participant P](/rufus-race-manager/participant-management/participant-statuses-notes-penalties-and-bonuses)[assings ](/rufus-race-manager/participant-management/participant-passings)article for more information.
* **Laps/Segments**: Instantly see all participant laps or segments.
* **Rankings**: Instantly see participant position across all rankings: *Global, gender, age group, group, club, team, city, country*. Updates live as you edit participant info

### 5. Predictive Tracking Location

Operators can see a focused mini-map snippet for the selected athlete with useful race-time context such as:

* **pace**
* **distance to go**
* **predictive finish**
* **last checkpoint**
* **next checkpoint**

## Deleting a Participant

You can also delete a participant directly from the **Edit Participant** tab. To do this, click on the **Trash icon** located in the lower-left corner of the tab. Please note that deleting a participant will not remove the associated passings.

## Tips for Editing Participants

* **Double-Check Changes**: Always double-check any changes before saving to ensure participant data is accurate and up-to-date.
* **Consistency Across Fields**: Ensure consistency with gender values, country information, and age group codes to maintain accurate categorization and avoid issues during classification.
* **Manage Passings Carefully**: Adding or deleting passings can impact the participant's final results, so make sure to make these changes only when necessary.


# Participant Statuses, Notes, Penalties and Bonuses

The **Participant Status** in RUFUS Race Manager (RRM) represents the current state of a participant within a race. Status management, along with notes and penalties, allows race operators to correctly reflect race outcomes and provide additional context for participants when needed.

This article explains:

* Participant status types
* Automatic and manual status management
* Participant notes
* Penalties and bonuses applied to participants

These tools help race organizers maintain **accurate classifications and transparent race records**.

## Participant Status Types

<figure><img src="/files/nSiRxCcBb0yFLPQobzSf" alt=""><figcaption><p>Participant Status Selector</p></figcaption></figure>

Participants can have one of the following statuses.

<table><thead><tr><th width="226.76171875">Status</th><th>Description</th></tr></thead><tbody><tr><td><strong>NOT_STARTED</strong></td><td>The participant has not yet started the race.</td></tr><tr><td><strong>IN_RACE</strong></td><td>The participant has started the race but has not yet finished.</td></tr><tr><td><strong>FINISH</strong></td><td>The participant has completed the race.</td></tr><tr><td><strong>DNS</strong></td><td>Did Not Start – the participant did not start the race.</td></tr><tr><td><strong>DNF</strong></td><td>Did Not Finish – the participant started but did not finish.</td></tr><tr><td><strong>DSQ</strong></td><td>Disqualified – the participant has been disqualified.</td></tr><tr><td><strong>DNQ</strong></td><td>Did Not Qualify – the participant did not qualify for the race.</td></tr></tbody></table>

The current participant status can be seen and edited in the **Edit Participant view**.

## System-Managed Statuses

The following statuses are automatically determined by the system based on the participant’s recorded passings.

<table><thead><tr><th width="194.92578125">Status</th><th>Condition</th></tr></thead><tbody><tr><td><strong>NOT_STARTED</strong></td><td>No passings have been recorded for the participant.</td></tr><tr><td><strong>IN_RACE</strong></td><td>One or more passings exist but the final finish passing has not yet occurred.</td></tr><tr><td><strong>FINISH</strong></td><td>A valid finish passing has been recorded (lap ID 9999).</td></tr></tbody></table>

These statuses update automatically during the race to reflect the participant’s progress.

## Manually Assignable Statuses

Race operators can manually assign the following statuses when needed.

<table><thead><tr><th width="372.359375">Status</th><th>Usage</th></tr></thead><tbody><tr><td><strong>DNS</strong></td><td>Participant did not start the race.</td></tr><tr><td><strong>DNF</strong></td><td>Participant started but did not finish.</td></tr><tr><td><strong>DSQ</strong></td><td>Participant was disqualified.</td></tr><tr><td><strong>DNQ</strong></td><td>Participant did not qualify for the race.</td></tr></tbody></table>

Manual status changes override the system-determined status until it is restored.

## Restoring the Participant Status

If a participant status has been manually modified, it can be restored to the **system-determined status**.

Use the **Restore Participant Status** button next to the status selector.

This will recalculate the participant status based on the recorded passings.

Example:

If a participant was marked **DNF** but valid passings indicate they finished the race, restoring the status will change it back to **FINISH**.

## Participant Notes

A **Participant Note** allows race operators to add contextual information to a participant.

This field can be used to record:

* The reason for a disqualification
* Manual decisions from race officials
* Observations about race incidents
* Any other race control notes

Examples:

* *Cut course at km 18*
* *Manual finish verification*
* *Incorrect bib number reported*

When a note is present, a **note indicator icon** appears next to the participant in the participant list.

This helps race operators quickly identify participants with special notes or race decisions.

## Penalties and Bonuses

<figure><img src="/files/hTrDL4z9A4UQ4gLf6xEO" alt=""><figcaption><p>Participant note/reason &#x26; Penalty &#x26; Bonus box</p></figcaption></figure>

RRM allows race operators to apply **time penalties or bonuses** to participants.

This feature is used when race rules require time adjustments due to infractions or official decisions.

Examples include:

* **Penalty** for cutting the course
* **Penalty** for missing a checkpoint
* **Bonus** time adjustment granted by race officials

When a penalty or bonus is applied:

* The adjustment is reflected in the participant’s result
* A description of the adjustment can be recorded
* The information appears in the participant editor

Typical examples:

| Adjustment  | Example                           |
| ----------- | --------------------------------- |
| **Penalty** | +120 seconds – Cut course         |
| **Bonus**   | −30 seconds – Official correction |

## Status Reasons and Race Control Context

Participant notes and penalty descriptions act as **status reasons**, allowing race operators to document why a decision was made.

This ensures that race classifications remain **transparent and auditable**.

Reasons may include:

* Disqualification justification
* Penalty explanations
* Official race control notes

These notes provide valuable context for organizers reviewing results after the event.

## Race App Integration

Participant notes and penalties can also be generated automatically by **Race App actions** during race operations.

For example, race judges using the Race App may:

* Apply penalties
* Flag participants
* Send race control notes

When these actions occur, the corresponding notes and adjustments appear automatically in the **participant editor in RRM**.

## Initial Participant Status

When participants are first added to an event, their initial status is:

**NOT\_STARTED**

As passings are recorded during the race, the system automatically updates the status to **IN\_RACE** or **FINISH**.

## Summary

Participant status management in RRM combines automated race tracking with manual race control tools.

Race organizers can:

* Monitor system-generated statuses
* Assign manual race statuses
* Add notes explaining race decisions
* Apply penalties or bonuses when required

These tools ensure race results remain **accurate, transparent, and fully documented**.


# Participant Passings

From the **Edit Participant** tab in **RUFUS Race Manager (RRM)**, users can view and manage participant passings during the race. Passings represent the recorded instances of a participant passing a checkpoint, providing essential data for race analysis and classification. This article will cover how to manage passings, including adding new passings, deleting, and changing their status.

<figure><img src="/files/WyAH2VdNx1Qv74sk5ZSo" alt=""><figcaption><p>Participant Passings</p></figcaption></figure>

## Viewing Passings

In the **Edit Participant** tab, the **Passings** section displays all recorded passings for the selected participant. Each passing includes the following details:

* **Checkpoint**: The checkpoint where the passing was recorded.
* **Lap**: The lap number associated with the passing.
* **Racetime**: The elapsed race time when the passing occurred.
* **Time of the Day**: The exact timestamp when the passing was recorded.
* **Status**: The current status of the passing (e.g., **VALID**, **EOTR**).
* **Device**: The device that recorded the passing.

## Managing Passings

### 1. Deleting a Passing

Passings cannot be edited in terms of their recorded date, time, or checkpoint; this data is immutable once captured by the system to maintain integrity. However, users can **delete** a passing if necessary.

To delete a passing:

* **Select the Passing**: Click the checkbox next to the passing you wish to delete.
* **Delete**: From the grid menu, select **Delete** to remove the selected passing.

### 2. Changing Passing Status

The status of a passing can also be modified. There are two main statuses that a user can assign:

* **VALIDATED\_BY\_USER**: If a previously invalid passing is deemed correct, the user can mark it as valid, and it will be included in the classification analysis.
* **INVALIDATED\_BY\_USER**: If a passing is considered incorrect or irrelevant, the user can mark it as invalid, excluding it from the classification analysis.

To change the status of a passing:

* **Select the Passing**: Click the checkbox next to the passing whose status you wish to change.
* **Change Status**: From the grid menu, select **Change Status** and choose either **VALIDATED\_BY\_USER** or **INVALIDATED\_BY\_USER**.

## Adding a New Passing

Users can manually add a new passing if required, such as when a timing issue occurs, and additional data needs to be captured for accuracy.

<div><figure><img src="/files/e0U6hq3L9em0bL8KTcVG" alt=""><figcaption><p>Add New Passing Modal for Laps races</p></figcaption></figure> <figure><img src="/files/aY8b8tmKu6kpKdeLd2oX" alt=""><figcaption><p>Add New Passing Modal for Classical races</p></figcaption></figure></div>

To add a new passing:

* **Click Add Passing**: In the **Passings** section, click the **Plus icon** to open the **Add New Passing** modal. Or within the context menu in any Participants Grid.
* **Enter Details**:
  * **Date**: Specify the date of the new passing.
  * **Time or Race time**: Specify the time of the day or the race time of the new passing. Press the NOW button to input the current date/time in the fields.
  * **Lap number:** Specify the lap number of the new passing (for Laps races only)
  * **Checkpoint & Lap**: Select the corresponding checkpoint and lap for the passing.
* **Save**: Click **Save** to add the new passing. All manually added passings are assigned the **VALIDATED\_BY\_USER** status by default.

## Important Notes on Passings

* **Immutable Data**: The date, time, and checkpoint of a passing are immutable once captured. This ensures that the recorded data maintains its integrity for race classification purposes.
* **Deleting vs. Invalidating**: Deleting a passing removes it entirely, while invalidating a passing allows the data to be retained but ignored for classification.

## Conclusion

The **Passings** section in the **Edit Participant** tab provides a comprehensive toolset for managing the recorded checkpoints of participants in **RUFUS Race Manager**. Whether you need to delete, invalidate, or manually add passings, understanding how to manage these records ensures accurate race tracking and classification. Properly handling passings allows for a seamless race experience and reliable results.


# Participant Rankings

From the **Edit Participant** tab in RUFUS Race Manager (RRM), users can view a participant’s performance relative to other competitors through the Rankings widget. This section provides a quick overview of how the participant stands across different categories, helping organizers and officials verify results and classifications.

<figure><img src="/files/3GbMk6VPMVURQjXARNjk" alt=""><figcaption><p>Participant Rankings</p></figcaption></figure>

## Viewing Rankings

The Rankings widget displays the participant’s position in several categories:

* **Global**: The participant’s overall position among all finishers.
* **Age Group**: The participant’s ranking within their registered age group.
* **Gender**: The participant’s position within their gender category.
* **Group**: The participant’s result within the assigned group (if groups are configured for the event).
* **Club**: The participant’s ranking within their registered club (if applicable).
* **Team**: The participant’s ranking within their registered team (if applicable).
* **City**: The participant’s ranking within their registered city (if applicable).
* **Country**: The participant’s ranking within their registered country (if applicable).

Each entry shows the participant’s position followed by the total number of competitors in that category (e.g., *1 / 51*).

## Understanding the Rankings

* **Automatic Updates**: Rankings are updated automatically as new passings are validated and processed by the system.
* **Consistency Across Categories**: Rankings provide a layered perspective of performance, allowing participants to be compared both globally and within their peer groups.
* **Linked to Passings**: Any modification in passings (validation, deletion, or adding new ones) can influence the participant’s position in these rankings.

## Conclusion

The Rankings widget in the Edit Participant tab provides a clear snapshot of where a participant stands in the race across multiple categories. By combining global, demographic, and group-based results, it ensures accurate classification and an easy-to-understand overview of performance.


# Participants Laps/Segments

From the **Edit Participant** tab in RUFUS Race Manager (RRM), users can access two detailed performance views depending on the event type: **Laps** (for Time-Trial/Laps-based races) and **Segments** (for Classical races). These grids provide an immediate breakdown of the participant’s progress throughout the course, allowing organizers to verify times, pacing, and intermediate performance with precision.

<div><figure><img src="/files/bRPu2NBvtdXSFBALcqNt" alt=""><figcaption><p>Participant Laps Grid</p></figcaption></figure> <figure><img src="/files/k14JBYYvMqayUnElaEF6" alt=""><figcaption><p>Participant Segments Grid</p></figcaption></figure></div>

## Laps View

The **Laps** grid displays a lap-by-lap summary for events structured around repeated circuits or timed laps. This view helps officials confirm that each passing has been correctly detected and properly associated with the corresponding lap.

#### What the Laps Grid Shows

* **Lap Number**\
  Indicates the lap index and total laps (e.g., *1/3*).
* **Lap Time**\
  The time taken to complete the lap. If the participant has a fastest lap, it is highlighted visually.
* **Accumulated Time**\
  Total race time up to that lap.
* **Gap**\
  Difference between this lap and the leading participant in the race up to that segment.
* **Interval**\
  Time difference compared to the previous lap.
* **Lap Rank**\
  The participant’s ranking for that specific lap compared to all competitors.
* **Pos. Δ (Position Change)**\
  Shows if the participant’s overall position improved, remained the same, or dropped after the lap.
* **Lap Pace**\
  Calculated pace for the lap, expressed in Km/h for cycling/TT formats.

#### How Organizers Use the Laps Grid

* Validate lap detection and ensure all expected laps were recorded.
* Identify performance trends, such as improving or declining lap times.
* Spot irregularities (missing laps, unexpected speed changes, etc.).
* Support protests or result inquiries by providing transparent lap-by-lap data.

## Segments View

For Classical races (running, triathlon splits, cycling point-to-point, etc.), the **Segments** grid shows performance across predefined course segments. This allows organizers to audit intermediate times and compare the participant’s pacing across the route.

#### What the Segments Grid Shows

* **Name**\
  The segment label (e.g., *km0–km5*, *km10–km15*, *chip-time*, etc.).
* **Start Time**\
  Timestamp of the participant’s first passing that marks the beginning of the segment.
* **End Time**\
  Timestamp of the passing that marks the completion of the segment.
* **Segment Time**\
  Total duration required to complete that segment.
* **Pace**\
  Running pace or cycling speed adapted to the race type (e.g., *5:30 min/Km*).
* **Segment Rank**\
  Participant’s ranking within that segment compared to all other participants who completed it.

#### How Organizers Use the Segments Grid

* Verify that all split points were registered correctly.
* Compare the participant’s speed/pacing evolution across the course.
* Detect unusual slowdowns or surges that may require further validation.
* Provide accurate split-based reporting to athletes and stakeholders.

## Understanding Laps and Segments Together

Both grids are directly driven by the validated passings of the participant. Any modification—adding, removing, or validating a passing—will immediately update these tables. This ensures that the participant’s intermediate data remains consistent with the final classification.

These views give officials a comprehensive understanding of the participant’s progress and allow for quick troubleshooting when discrepancies arise.


# Organizing Participants

The Participants Grid in RUFUS Race Manager (RRM) is a powerful tool designed to help users efficiently view, organize, and manage participant information. With filtering, grouping, search, and bulk actions built directly into the interface, organizers can navigate large participant lists quickly and maintain accurate race records.

<figure><img src="/files/lZJHyOYK0g4ZYFZfzomw" alt=""><figcaption><p>Participants View</p></figcaption></figure>

## Participants Grid Overview

The Participants Grid provides a complete view of all participants registered in an event. Each row represents a participant, and the grid includes columns such as:

* **BIB**
* **Chip**
* **Name**
* **Gender**
* **Age Group**
* **Group**
* **City**
* **Country**
* **Club**
* **Team**
* **Status**
* **Race**

Columns can be customized, reordered, and filtered, allowing users to tailor the display to their workflow.

## Participant Status Filters

At the top of the Participants View, RRM provides **quick-access status filters**, allowing users to instantly narrow the list based on the participant’s race status.

Available filters include:

* **Not Started**\
  Participants who have not yet recorded passings or whose status is manually set to NOT\_STARTED.
* **In Race**\
  Participants currently detected on course based on validated passings.
* **Finish**\
  Participants who have completed the race.
* **Excluded**\
  Participants marked with exclusion statuses such as DNS, DNF, DSQ, or DNQ.

Clicking any status badge filters the grid automatically, streamlining race control and verification.

Status filters work in combination with search, column filters, and grouping, offering both quick overviews and granular control.

## Color Coding by Gender

The Gender column uses color coding based on the Gender Mapping configured in the event’s Settings. This visual distinction helps quickly identify participant categories and improves readability when working with large datasets.

## Available Grid Actions

### 1. Exporting Data

Users can export participant data to CSV or PDF. The export contains exactly what is currently displayed—meaning filters, groupings, and visible columns all affect the exported file. This is particularly useful for generating reports or preparing external lists.

### 2. Searching Participants

The search bar allows instant filtering by:

* Name
* BIB
* Chip code
* Any other searchable text shown in the grid

This makes it easy to locate individual participants without adjusting column filters.

### 3. Column Actions

Each column offers a set of actions to help organize information:

* **Sort ASC/DESC**\
  Order the column values.
* **Pin to Left/Right**\
  Keep important fields visible while scrolling.
* **Filter**\
  Display only rows matching specific criteria.
* **Group By**\
  Organize participants by categories such as Status, Country, Age Group, Race, etc.
* **Hide Column**\
  Temporarily remove unnecessary fields from view.
* **Manage Columns**\
  Customize which columns are visible and adjust the layout to suit your workflow.

### 4. Bulk Actions

Users can select multiple participants and apply actions to all of them at once. After selecting rows, the bulk menu provides:

* **Delete**\
  Permanently remove participants from the event.
* **Reset Status**\
  Set the selected participants back to NOT\_STARTED. This does not delete passings but resets their race progress.
* **Assign Status**\
  Mark participants as DNS, DNF, DSQ, or DNQ.

Bulk operations make large-scale adjustments fast and consistent, especially during race preparation or corrections.

## Publish Participants List in the RUFUS Event App

When an event is in **PUBLISHED** status, organizers can publish the participant list to make it available in the RUFUS Event App. This allows athletes to check and verify their personal details such as name, club, age group, and team.

To publish, go to **All Participants** and click the cloud icon next to the page title.

<figure><img src="/files/rGAuqT653t8BU1cMrKLs" alt=""><figcaption><p>Publish Participants List to Cloud Button</p></figcaption></figure>

## Tips for Organizing Participants

* **Pin Key Columns**\
  Keep BIB, Name, or Status visible while scrolling.
* **Use Status Filters**\
  Quickly identify who has started, who is still on course, who has finished, and who is excluded.
* **Group Participants**\
  Grouping by Status, Country, Age Group, or Race helps analyze large datasets effortlessly.
* **Apply Column Filters**\
  View targeted segments of participants, such as all runners from a country or all participants in a specific age division.

## Conclusion

The Participants Grid in RRM provides a comprehensive set of tools for managing and organizing participants efficiently. With status filters, column controls, search, exporting, and bulk actions, organizers can maintain clean, accurate participant data while keeping race operations smooth and responsive.


# Swap and Race Change

The **Swap** and **Race Change** tool allows race operators to correct participant assignment issues after timing data has already been recorded.

It can be used to perform three types of corrections:

* **Bib/chip swap**: exchanges bib and chip assignments between two participants.
* **Time swap**: exchanges the recorded race times between two participants.
* **Race Change** – move a participant to another race.

These options include a preview step so the operator can verify the impact before applying the change.

<figure><img src="/files/uvj5KnkVuUMjU3DHAw5I" alt=""><figcaption><p>Edit Participant View</p></figcaption></figure>

## Accessing Swap

The Swap tool can be accessed from:

* The **Edit Participant** view.
* The **Bib** field in the participant registration details.
* The context menu on supported **Participant Grids**.

The context menu is useful when reviewing participant lists, rankings, or operational grids and a correction must be made directly from the current view.

## Bib/Chip Swap

<figure><img src="/files/zCXIbFGpIEkzpCFuGp6A" alt=""><figcaption><p>Bib Chip Swap</p></figcaption></figure>

Bib/chip swap exchanges the bib and chip assignment between the current participant and another participant.

This is useful when bibs or chips were assigned incorrectly before or during the race.

For example, if participant A raced with participant B’s bib or chip, the swap allows the operator to correct the registration data without manually editing both participants.

### Performing a Bib/Chip Swap

1. Open the **Swap** dialog.
2. Select **Bib/chip swap**.
3. Enter the **target bib** of the participant to swap with.
4. Click **Preview**.
5. Review the **Before swap** and **After swap** panels.
6. Click **Swap** to apply the correction.

The preview shows:

* Participant names
* Bib numbers
* Chip codes
* Assigned race

After confirmation, RRM updates the affected participants and reprocesses the relevant data.

### Time Swap

<figure><img src="/files/zNbQGzph3QJeFENihVJ3" alt=""><figcaption><p>Time Swap</p></figcaption></figure>

Time swap exchanges the race times between two participants without swapping their bib or chip registration data.

This is useful when the participants are correctly registered, but their recorded timing data must be exchanged.

Common cases include:

* Two participants crossed with exchanged bibs, but registration data should remain unchanged.
* A manual correction requires the finish or race time to be assigned to the other participant.
* Ranking positions must be corrected based on confirmed timing review.

### Performing a Time Swap

1. Open the **Swap** dialog.
2. Select **Time swap**.
3. Enter the **target bib** of the participant to swap times with.
4. Click **Preview**.
5. Review the ranking preview.
6. Click **Swap** to apply the correction.

The ranking preview shows how the swap affects each participant, including:

* Global rank
* Gender rank
* Age-group rank

This allows the operator to confirm the ranking impact before applying the change.

### Compatibility Analysis

When previewing a swap, RRM analyzes how the correction affects existing timing data and rankings.

If the participants belong to different races or have incompatible timing data, RRM may display warnings or ranking changes that require review.

Before confirming the swap, check that:

* The target bib is correct.
* The participants shown in the preview are the expected ones.
* The resulting bib, chip, time, and ranking changes are consistent with the race situation.

### Operational Notes

Use Swap only when the correction reflects what actually happened during the race.

After applying a swap, review the affected participant records, passings, and results to confirm that the classification is correct.

For published events, update or republish the affected results after the correction so the Events App reflects the corrected race data.

## Race Change

Participants can also be reassigned to another race from the **Race selector** in the **Registration Details** section.

This may be necessary when:

* A participant registered for the wrong race
* A participant switches distance
* Race staff corrects a registration mistake

### Race Change Warning

If the participant already has recorded passings, RRM displays a **warning indicator** next to the race selector.

This warning indicates that changing the race may affect existing timing data.

When saving the participant after a race change, a **confirmation dialog** will appear explaining:

* The race being changed
* The number of **compatible passings**
* The number of **incompatible passings**

<figure><img src="/files/DjjyVjWhEbOEkGvaFJXI" alt=""><figcaption></figcaption></figure>

You can then choose:

* **Cancel** – keep the current race assignment.
* **Continue Anyway** – apply the race change.

## When to Use These Features

These tools are commonly used during race operations to correct participant information.

Typical scenarios include:

* Two participants accidentally **wearing each other's bibs**
* A participant **changing distance before the race**
* Correcting **registration mistakes**
* Adjusting participants based on **race control decisions**

Because RRM automatically reprocesses passings, these changes are applied safely without losing recorded timing data.

## Summary

The **Bib Swap** and **Race Change** features allow race operators to correct participant registration data while preserving timing integrity.

RRM helps maintain accurate results by:

* Previewing swap results before applying them
* Analyzing passings compatibility
* Warning when race changes may affect timing data
* Automatically reprocessing affected passings

These safeguards ensure that participant corrections can be made confidently, even during live race operations.


# Understanding Checkpoints

Checkpoints are a fundamental element of race timing in **RUFUS Race Manager (RRM)**. They represent specific locations on the racecourse where participants’ times are recorded, enabling accurate tracking of progress, splits, laps, and results.

Checkpoints work within a race’s **plan** — the ordered list of checkpoints a participant must pass. Each checkpoint has a **lap ID**, a type (start, intermediate, or finish), and may have additional properties such as whether it closes a lap.

## What Are Checkpoints

A checkpoint is a designated location on the racecourse where participants’ passings are logged. Timing devices (e.g., RFID readers, manual entries, floating passings) capture these passings as participants cross.

* **Start checkpoint** → Marks the official beginning of a race (lap 0). If missing, RRM may create a **synthetic start** at race time + 1 ms to guarantee continuity.
* **Intermediate checkpoints** → Record splits and help validate course completion. Each increments the lap ID according to the race plan.
* **Finish checkpoint** → Marks the end of the race (lap 9999). After a valid finish, all subsequent passings for the same participant on that device are marked **EOTR (End of the Road)**.

## Race Plan vs Device Plan

<figure><img src="/files/BN1tf5T07GsHtrHA8g7e" alt=""><figcaption><p>Checkpoint Plans</p></figcaption></figure>

* **Race Plan** → The full ordered sequence of checkpoints for a participant’s race. This defines the expected course from start to finish.
* **Device Plan** → A filtered subset of checkpoints that a specific device records (e.g., a 10k mat only has the 10k checkpoint).

When a passing is recorded:

* The race plan determines what checkpoint comes next.
* The device plan determines whether the passing matches the device’s assigned scope.

**Floating passings** are special because they are not tied to a device plan. Instead, they use the **full race plan** as scope, letting the system infer the correct next checkpoint.

## Importance of Checkpoints

Checkpoints provide several critical functions:

* **Start and finish tracking** → Calculate total race times.
* **Intermediate splits** → Track pacing and performance at multiple stages.
* **Validation of completion** → Ensure participants follow the full course.
* **Lap and segment creation** → Define race structure, including repeated laps and sector splits.

## Flexibility of Checkpoints

Checkpoints in RRM are highly configurable:

* **Shared checkpoints** → A single checkpoint may serve as both start and finish (common in loop or out-and-back races).
* **Separate checkpoints** → Distinct start and finish points, with intermediates in between.
* **Multi-lap checkpoints** → Configured to repeat across multiple laps (e.g., triathlon bike loops or circuit races).
* **Lap-closer checkpoints** → Define when a lap is complete, ensuring laps are validated correctly.

## Tips for Setting Up Checkpoints

* **Plan placement carefully** → Place checkpoints at the start, finish, and key points along the course.
* **Use consistent naming** → Descriptive names like *Start*, *Finish*, or *10k Split* help during setup and race control.
* **Test in advance** → Run devices and check test passings to confirm configuration before race day.

## Summary

Checkpoints form the backbone of race timing in RRM. They define the race plan, structure lap progression, and ensure fair and accurate results. Whether shared, separate, or repeated across laps, checkpoints give race organizers flexibility to adapt to any race format.

By understanding how checkpoints interact with devices, participants, and passings, timers can confidently manage both simple and complex race scenarios.


# Checkpoint Promotion and Granularity

Checkpoints in **RUFUS Race Manager (RRM)** are designed to be flexible and intelligent. They not only record passings at specific points on the course but also adapt dynamically when conditions change, giving race organizers maximum control and reliability.

## Promotion of Passings

If a checkpoint in the race plan is **closed**, RRM does not simply discard passings that occur at that point. Instead, it automatically **moves them forward** to the next available checkpoint in the participant’s race plan.

<figure><img src="/files/jqBu7cBIBLXIUNXmQcYf" alt=""><figcaption><p>Checkpoint Promotion Diagram</p></figcaption></figure>

* Example: A passing is recorded at the *Start* checkpoint after it has been closed. The system assigns it to the next open checkpoint (e.g., *Finish*).
* This ensures that participants’ race continuity is preserved, even if certain checkpoints are no longer active.
* The internal service may mark this step as **PROMOTED**, but what timers see in the UI is the resulting **VALID** passing at the new checkpoint.

This behavior maintains fairness and accuracy while reducing the chance of lost data.

## Logical vs Physical Checkpoints

In real-world races, the **Start** and **Finish** lines are often at the same physical location. In RRM, however, it is best practice to configure them as **separate checkpoints**.

This approach gives timers more granularity and control:

* **Close Start independently** → Once all participants have started, you can close the *Start* checkpoint while keeping the *Finish* checkpoint open.
* **Manage notifications separately** → You can silence notifications for *Start* (to avoid overload during a mass start) while still allowing *Finish* notifications.
* **Handle race plan progression correctly** → With separate checkpoints, RRM can shift passings through the plan without ambiguity.

Even though the two checkpoints may share the same physical mat, treating them separately in the software provides significant operational benefits.

## Best Practices

* Always configure **Start** and **Finish** as distinct checkpoints, even if they share the same location.
* Use checkpoint **closing** to reduce noise once a phase of the race is complete.
* Adjust **notifications** per checkpoint to match operational needs.
* Monitor the **Event Control View** to confirm how passings are applied.

## Summary

By combining **promotion through the race plan** with the ability to define **logical checkpoints**, RRM ensures that passings are always handled consistently and that race organizers have full control over timing operations.

This flexibility is especially valuable when the same physical location acts as both the start and finish line.


# Checkpoints Menu

The **Checkpoints Menu** in **RUFUS Race Manager (RRM)** allows users to manage all checkpoints for an event, providing a central place to create, edit, and review checkpoint information. This article will explain how to navigate the **Checkpoints Menu**, what information is available, and how to manage checkpoints effectively.

<figure><img src="/files/XuulaCGVyI9r0J0yXRIM" alt=""><figcaption><p>Checkpoints Menu</p></figcaption></figure>

## Navigating the Checkpoints Menu

The **Checkpoints Menu** is accessible from the left-hand navigation bar in RRM. Here, users can view all checkpoints that have been defined for the event. Each checkpoint listed will show the name of the checkpoint, as well as the races it is assigned to.

## Viewing Defined Checkpoints

In the **Checkpoints Menu**, you will see a list of all the checkpoints that have been created. For each checkpoint, the following information is displayed:

* **Checkpoint Name**: The name assigned to the checkpoint.
* **Muted:** Checkpoints with muted notifications show the crossed bell icon.
* **Assigned Races**: The races that the checkpoint is associated with.

This overview makes it easy for race organizers to see which checkpoints are used in which races.

## Editing a Checkpoint

To edit a checkpoint, simply **click on the pen icon** that appears when you hover over the checkpoint name. This will open the **Edit Checkpoint** modal, where you can modify details such as the checkpoint name and location. Editing a checkpoint ensures that any updates or changes needed before or during the event can be made quickly and easily.

## Accessing the Checkpoint Dashboard

Clicking on a **checkpoint name** will open the **Checkpoint Dashboard**. Currently, the **Checkpoint Dashboard** only shows the toggle command to activate the passing analysis for the checkpoint. More widgets are yet to come that will provide detailed and relevant information for the checkpoint.

## Accessing the Checkpoint-Race View

If you click on the **race name** under a checkpoint, you will be directed to the **Checkpoint-Race View**. This view provides a detailed view of participant passings and other race-specific data for the selected checkpoint. It allows you to easily monitor checkpoint performance for a particular race and see which participants have crossed that checkpoint.

## Creating a New Checkpoint

To add a new checkpoint, click on the **"Add New"** button located within the **Checkpoints Menu**. This will open a form where you can enter details such as the **Checkpoint Name** and location. Setting up checkpoints accurately is crucial for effective race timing and classification.


# Creating Checkpoints

Checkpoints are a vital part of race management in **RUFUS Race Manager (RRM)**. Creating checkpoints accurately ensures participants are tracked correctly and the race flow is managed effectively.

### Accessing the New Checkpoint Dialog

To create a new checkpoint:

1. Navigate to the **Checkpoints Menu** using the left-hand navigation bar.
2. Click the **New Checkpoint** button.
3. The **New Checkpoint modal** will open, allowing you to configure all the details.

<figure><img src="/files/opErV0cAKR6onNBXJ6k3" alt=""><figcaption><p>Checkpoint Dialog</p></figcaption></figure>

### Adding a New Checkpoint

In the New Checkpoint modal, the following fields are available:

* **Name** → A descriptive name to identify the checkpoint, such as *Start Line*, *Checkpoint 1*, or *Finish Line*.
* **Bounce time** → The minimum time interval (in seconds) required between valid reads at this checkpoint.
  * Any passing that occurs within the bounce window after a valid passing receives the status **BOUNCED\_BY\_CHECKPOINT**.
  * This prevents duplicate detections when a participant lingers or steps multiple times on the mat.

<figure><img src="/files/wPNSYXOCOeVusmELJTXf" alt=""><figcaption><p>Bounce Time Diagram</p></figcaption></figure>

* **Latitude / Longitude (optional)** → Coordinates for precise mapping of the checkpoint. Useful for GPS-based planning and route visualization.
* **Show passings notifications** → Toggle notifications for this checkpoint.
  * When enabled, every passing generates a notification.
  * When disabled, passings are still recorded and processed, but without real-time pop-up notifications.

Once configured, click **Save** to create the checkpoint. If you decide not to proceed, click **Cancel** to close the modal without saving changes.

### Tips for Creating Checkpoints

* **Use descriptive names** → Clear labels (e.g., *Start Line*, *Finish*, *10k Split*) simplify event control, especially when managing multiple checkpoints.
* **Set bounce times carefully** → Adjust based on checkpoint type. For example:
  * Start/Finish mats may need a larger bounce window to avoid congestion duplicates.
  * Intermediate splits can often use shorter bounce windows.
* **Silence notifications when needed** → For very busy checkpoints (e.g., mass starts), disabling notifications helps operators focus without being overwhelmed.
* **Add location data if relevant** → GPS coordinates are optional but recommended for precise planning, mapping, and post-race review.


# Checkpoint Dashboard

The Checkpoint Dashboard in **RUFUS Race Manager** (RRM) provides full visibility and operational control over the passings captured at a specific checkpoint. From this view, organizers can monitor all passings flowing through the checkpoint, manage how the system processes them, and control race timing behavior as the event unfolds.

<figure><img src="/files/YMhciUdF5llhKLYMCjKw" alt=""><figcaption><p>Checkpoint Dashboard View</p></figcaption></figure>

Each checkpoint displays a set of core elements:

* **Race Control widgets** showing elapsed time, lap progress, or finish status depending on the checkpoint’s role.
* **Process Passings switch**, allowing the checkpoint to actively process or temporarily ignore new detections.
* **Passings Grid**, listing all passings recorded at the checkpoint across all races assigned to it.

This consolidated interface allows race officials to supervise checkpoint activity in real time and adjust operational status when necessary.

## Passings Grid

The Passings Grid shows **every passing detected at the checkpoint**, regardless of the participant’s race, category, or status. This makes it possible to:

* Audit all detections arriving from the hardware
* Confirm that passings are being assigned correctly
* Detect duplicates, invalid reads, or unexpected chip activity
* Validate times, laps, or segment boundaries directly at the checkpoint level

#### What the Grid Displays

Columns typically include:

* **BIB**
* **Name**
* **Race**
* **Lap** (when applicable)
* **Race Time**
* **Time of Day**
* **Status** (VALID, INVALIDATED, CHECKPOINT\_CLOSED, etc.)
* **Type** (LOCAL, CLOUD, MANUAL)

#### Row Actions

Each passing supports contextual operations such as:

* **Delete passing**
* **Reprocess passing**
* **Set passing as Invalidated by user**

These actions provide precise control over how passings affect the participant’s record and final classification.

## Adding Manual Passings

You can add passings directly from the Checkpoint View by entering the participant’s **BIB number**.

* The timestamp recorded will be the **exact moment the passing is entered**.
* The passing is then processed by the system using the full validation logic, ensuring it receives the appropriate status.
* This feature is particularly useful when a participant is observed crossing but their chip was not detected.

For broader corrections, consider using **Floating Passings**, which are not tied to a specific checkpoint but use the entire race plan to infer the correct placement. See [Floating Passings](/rufus-race-manager/collecting-and-managing-timing-data/floating-passings).

## Activating or Deactivating Passing Analysis

At the center of checkpoint control is the **Process Passings** toggle:

* **Activated** → The checkpoint actively processes passings. Valid detections are assigned to participants and integrated into timing calculations.
* **Deactivated** → The checkpoint stops processing incoming passings. Detections are still captured but are not used for timing.

This toggle allows organizers to manage checkpoint behavior dynamically without interrupting hardware collection.

<figure><img src="/files/5GrWj8imeZR8HFZX7KQJ" alt=""><figcaption><p>Checkpoint Active Diagram</p></figcaption></figure>

## Status of Passings When Inactive

If a checkpoint is deactivated:

* Passings recorded at that location are still captured and stored.
* These passings are marked with the status **CHECKPOINT\_CLOSED**.
* This ensures a clear audit trail while preventing the passings from affecting official race timing and rankings.

## When to Use This Control

* **Before the race starts** → Keep checkpoints deactivated until just before the event begins to avoid noise from setup or early chip detections.
* **After all participants have passed** → Deactivate a checkpoint once it has served its purpose to prevent unnecessary data (e.g., staff or spectators walking over mats).
* **Shared physical locations** → If start and finish share the same mat but are set as separate checkpoints in RRM, you can close *Start* while keeping *Finish* active.

## Best Practices

* Always verify that **Start checkpoints** are activated at race start.
* Close checkpoints that are no longer needed to keep data clean.
* Use separate logical checkpoints for Start and Finish, even if they are physically in the same place, so you can control them independently.
* Check the **Event Control View** for passings with the status **CHECKPOINT\_CLOSED** when reviewing inactive periods.


# Checkpoint-Race View

The **Checkpoint-Race View** in **RUFUS Race Manager (RRM)** provides detailed visibility into all passings captured for a specific **checkpoint and race**. It is designed to help race organizers monitor activity at that checkpoint in real time, ensuring accuracy and control during the event.

<figure><img src="/files/zpi4j2XnN0vhZpuGaUVe" alt=""><figcaption><p>Checkpoint-Race View</p></figcaption></figure>

## Overview

* The grid displays **all assigned passings** for the selected checkpoint and race.
* **ORPHAN passings** do not appear in this view because they are not linked to a participant or race.
* This view does **not** show rankings or classifications. It is purely a **passing-level view**, focused on what was captured at the checkpoint.

<figure><img src="/files/lZgu4oPN14DdpeQHclCm" alt=""><figcaption><p>Checkpoint-Race View Passings Diagram</p></figcaption></figure>

The grid includes key information for each passing:

* **BIB** → Participant’s bib number
* **Name, Gender, Age Group** → Participant details
* **Chip** → The chip ID used in timing
* **Lap** → The lap number associated with the passing
* **Racetime** → Time elapsed since race start
* **Time of the Day** → Exact clock timestamp
* **Status** → Passing status (VALID, BOUNCED, etc.)
* **Type** → Origin of the passing (e.g., AUTOMATIC, MANUAL, BACKUP FILE)
* **Device** → The device that captured or created the passing

As with other grids in RRM, you can **filter, sort, group, and search** the data to find exactly what you need.

## Adding Manual Passings

You can add passings directly from the Checkpoint-Race View by entering the participant’s **BIB number**.

* The timestamp recorded will be the **exact moment the passing is entered**.
* The passing is then processed by the system using the full validation logic, ensuring it receives the appropriate status.
* This feature is particularly useful when a participant is observed crossing but their chip was not detected.

For broader corrections, consider using **Floating Passings**, which are not tied to a specific checkpoint but use the entire race plan to infer the correct placement. See [Floating Passings](/rufus-race-manager/collecting-and-managing-timing-data/floating-passings).

## Viewing Race Time

At the top of the Checkpoint-Race View, the **current race time** is displayed. This acts as a reference clock for the ongoing race and helps contextualize the passings you are reviewing.

## When to Use the Checkpoint-Race View

* **During the race** → Monitor live passings at a critical checkpoint.
* **After the race** → Review checkpoint activity for accuracy, identify missed or duplicated passings, and correct them with manual or floating entries.
* **Operational monitoring** → Focus on a specific race and checkpoint without being distracted by global event data.

## Summary

The Checkpoint-Race View is an essential operational tool in RRM. It provides:

* Detailed grids of all checkpoint passings for a race
* Manual addition of missing passings
* Real-time race time display
* Full grid management (filtering, sorting, grouping)

By using this view effectively, race organizers can maintain precise oversight of critical checkpoints and ensure reliable timing data throughout the event.


# Races Menu

The **Races Menu** in **RUFUS Race Manager (RRM)** is where you view and manage all races defined for an event. From here, you can open race dashboards, edit race settings, and create new races.

<figure><img src="/files/ZrCHYqfGhUFkjiWz2BgD" alt=""><figcaption><p>Races Menu List</p></figcaption></figure>

## Viewing Defined Races

* All races already created for the event are listed in this menu.
* Each race is shown by **name**, making it easy to identify.
* Next to the race name, you can also see the number of checkpoints associated with that race.

#### Opening a Race

Clicking on a race name opens the **Race Dashboard**, where you can find detailed information and tools to manage that race.

#### Editing a Race

Hover over a race name and click the **pen icon** to open the **Edit Race modal**, where you can adjust race details such as name, distance, and other configurations.

## Creating a New Race

At the bottom of the Races Menu, you’ll find the **Add races** section.

* **Classical (V2)** → Create a traditional mass-start race. This is the standard format for most running, cycling, and triathlon events.
* **Laps/Time-Trial** → Create lap based races. This is the standard format for most motor sports events.

## Creating a Race Course

Operators can design a race course directly on an interactive map with the **Course Designer**, either by drawing it manually or importing it from **GPX/KML**. Event checkpoints can be placed as shared physical locations and reused across multiple races, making setup cleaner and faster.


# Creating a Classical Race

Creating races in **RUFUS Race Manager (RRM)** is a key step in configuring an event. A race defines the checkpoints, rules, and timing policies used to calculate results and track participants.

### Race Types

RRM currently supports two race formats:

<table><thead><tr><th width="237.04296875">Race Type</th><th>Description</th></tr></thead><tbody><tr><td><strong>CLASSICAL</strong></td><td>Traditional race format with an optional <strong>START</strong> checkpoint and a required <strong>FINISH</strong> checkpoint. Intermediate checkpoints can be added along the course.</td></tr><tr><td><strong>LAPS</strong></td><td>Lap-based races such as circuits or multi-loop formats.</td></tr></tbody></table>

This article focuses on creating a **CLASSICAL race**.

## Accessing the New CLASSICAL Race Dialog

To create a new race:

1. Open the **Races** section from the left navigation bar.
2. Click **Add races**.
3. Select **CLASSICAL**.

The **Add Race dialog** will open, where you can configure the race structure and timing policies.

<figure><img src="/files/dZfrqzEuYyFLMZVvLtb1" alt=""><figcaption><p>Classical Race Dialog</p></figcaption></figure>

## Filling Out Race Details

In the **New Race modal**, complete the following fields:

* **Race name** → Enter a descriptive name (e.g., *5K Run*, *Mountain Bike Challenge*).
* **Sport** → Select the sport type (e.g., RUN, BIKE, TRIATHLON, TRAIL\_RUN, OBSTACLE\_COURSE, etc.). This helps with classification and participant management.

## Assigning Checkpoints

A race is built from **checkpoints**, which represent timing points along the course.

To add checkpoints:

1. Select a checkpoint from the list.
2. Choose its **type**.
3. Click **Add to Race**.

Checkpoint types include:

| Type             | Description                                   |
| ---------------- | --------------------------------------------- |
| **START**        | The race start checkpoint.                    |
| **INTERMEDIATE** | A checkpoint placed between start and finish. |
| **FINISH**       | The race finish checkpoint.                   |

<figure><img src="/files/QMaAU7ouXeeFBR3jsMef" alt=""><figcaption><p>Race Structure Diagram</p></figcaption></figure>

### Lap IDs

Each checkpoint receives an automatic **Lap ID**.

| Checkpoint   | Lap ID            |
| ------------ | ----------------- |
| Start        | 0                 |
| Intermediate | Sequential values |
| Finish       | 9999              |

#### Rules

* Each race must contain **at least one FINISH checkpoint**.
* A race can only contain **one START** checkpoint.
* Intermediate checkpoints can be added freely.

## Start Policies

Start policies define how the system behaves when start passings are missing or ambiguous.

### Auto-create lap 0

If no valid start passing is detected, the system automatically generates a **synthetic start passing** at:

```
Race start time + 1 millisecond
```

This is useful when participants stand on the start mat before the gun and the system does not record a clean start passing.

### Allow finish without start

If enabled, participants who cross the **Finish checkpoint without a recorded Start** will still receive a valid finish time.

If disabled, finish passings without a valid start will be ignored.

### Auto-select last start time

When multiple start passings are detected for a participant, this policy determines which start time will be used.

If enabled:

* The system will use the **last detected start passing** as the official start.

This helps handle situations where participants cross the start mat multiple times before leaving the start area.

## Auto-Generate Race Segments

RRM can automatically generate all possible timing segments for the race based on the configured checkpoints.

When this option is enabled, RRM creates a proposed segment set before saving the race. This may include:

* Gun-time segments
* Chip-time segments
* Intermediate checkpoint splits
* Checkpoint-to-checkpoint segments

Before the race is created, RRM opens a **Review generated segments** screen where you can check and adjust the proposed segments.

<figure><img src="/files/d5nkG21seQlxDF4BbyaQ" alt=""><figcaption><p>Review Generated Segments Dialog</p></figcaption></figure>

In this review step, you can:

* Rename segments.
* Remove segments that are not needed.
* Select the race order segment.
* Set the discipline for each segment.
* Set the length of each segment to enable pace calculations.

These segments are used for participant results, rankings, race order, and pace calculations.

This option helps build a complete segment structure from the race checkpoints while still allowing operator review before the race is saved.

## Race Aliases

Race aliases allow RRM to recognize race names from **imported participant files**.

This is useful when importing data from **registration platforms or CSV files** that may use slightly different race names.

Example:

Race name:

```
21k
```

Aliases:

```
21 K
21
21 km
```

When importing participants, if the CSV file contains any of these values in the **Race column**, RRM will automatically assign the participant to the correct race.

This improves compatibility with external registration systems.

## Saving the Race

Once the details, checkpoints, and policies are configured:

* Click **Save** to create the race.
* The race will appear in the **Races Menu**, ready for dashboard access and live timing.


# Course Designer

The **Course Designer** lets you build the race route directly on an interactive map inside **RUFUS Race Manager**. It is the starting point for the new **Predictive Tracking** experience in classical races, and it gives operators a visual way to define how the race flows through the course.

With Course Designer, you can draw the route manually, import it from a file, and connect the race to real mapped checkpoints that can later be reused across races.

<figure><img src="/files/qKXV8MCCtaK2MWOJW32x" alt=""><figcaption><p>Course Designer View</p></figcaption></figure>

## What is Course Designer for?

Course Designer is used to create the mapped route of a race.

This route is what Race Manager uses to:

* show the course on the map
* connect race checkpoints to real physical locations
* prepare the race for **Predictive Tracking**
* give operators a clearer visual reference during setup and live operations

A race becomes **predictive-tracking ready** when it has:

* a valid mapped route
* at least one mapped intermediate checkpoint

## Where to find it

You can open **Course Designer** from the race setup flow in classical races.

Once opened, the screen shows:

* the interactive map
* the current race selector
* route editing tools
* route statistics and mapping status
* the **Event checkpoints** panel

## What you can do in Course Designer

### Draw the route manually

You can create the route directly on the map by placing points along the course.

This is useful when:

* you want to build the course from scratch
* you need to adjust a route manually
* you want full control over the exact path

As you build the route, Race Manager samples the path into route handles so the course can be tracked and interpreted correctly.

### Import a route

You can also import an existing route file instead of drawing it manually.

Supported route import formats include:

* **GPX**
* **KML**

This is the fastest option when the race route has already been prepared in another mapping tool.

### Edit the route

Once a route exists, you can refine it using the route editing tools.

Depending on the current state of the route, you can:

* add or move route points
* adjust the path
* re-center the map
* clear or replace the route
* save the updated course

The top bar also shows useful route information, such as:

* mapped location
* number of race checkpoints
* mapped checkpoints count
* total route distance

## Event checkpoints

The **Event checkpoints** panel is where you map the race checkpoints onto the route.

Checkpoints are treated as shared physical event locations, which means they can be reused across multiple races in the same event.

This helps keep course setup more consistent, especially when several races pass through the same real-world point.

For each checkpoint, the panel shows its mapping status, including whether it is already mapped or still pending placement.

Typical checkpoint types include:

* **Start**
* **Intermediate checkpoints**
* **Finish**

### Mapping a checkpoint

To map a checkpoint:

1. Open **Course Designer** for the race.
2. Locate the checkpoint in the **Event checkpoints** panel.
3. Choose the option to place or edit it on the map.
4. Set its position on the route.
5. Save the changes.

Once mapped, the checkpoint becomes part of the course logic used by Predictive Tracking.

### Reusing checkpoints

Because checkpoints represent event-level physical locations, the same checkpoint can be used across more than one race when appropriate.

This is especially useful in events where:

* multiple races share the same start or finish area
* different races pass through the same intermediate point
* course setup should stay aligned between distances

## When is a race ready?

A race is considered ready for Predictive Tracking when:

* the route is valid
* the race includes at least one mapped intermediate checkpoint

If the route is incomplete or checkpoints are missing, the race will not be considered ready for predictive tracking yet.

## Best practices

For the best results when building a course:

* map the route as accurately as possible
* make sure checkpoints are placed on the correct point of the route
* verify that the route passes through the intended checkpoints in order
* review the total distance after editing or importing
* use shared checkpoints consistently across races in the same event

## Why it matters

Course Designer adds a more visual and structured setup flow to race configuration.

Instead of working only with splits and checkpoint logic, operators can now build the race on a real map and prepare it for a more modern live-race experience.

It is the foundation for **Predictive Tracking**, helping Race Manager understand where participants are, where they are headed, and how the race is evolving between checkpoints.




---

[Next Page](/llms-full.txt/1)

