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

# Manual Timing

The **Manual Timing** view allows judges to record real-time participant passings at assigned checkpoint(s). It is designed for speed, reliability, and minimal friction during high-pressure race conditions.

Manual Timing sends timestamped bib passings directly to Race Control in **RUFUS Race Manager (RRM)**.

<figure><img src="/files/mqTRwC6oe4O8Zrvs0tq9" alt="" width="360"><figcaption><p>Manual Timing Screen</p></figcaption></figure>

## What Manual Timing Does

Manual Timing records a participant passing using the device’s current time and sends it to Race Control as a checkpoint event.

Each passing includes:

* Bib number
* Timestamp (device “now”)
* Source (manual keypad or QR)
* Passing number
* Optional GPS snapshot (latitude, longitude, accuracy — when available)

Passings appear in:

* Live Activity (inside the app)
* Race Manager (as checkpoint passings)

## Entering Bib Numbers

The Manual Timing screen is optimized for fast input.

### Numeric Keypad Entry

Judges can enter bib numbers using the on-screen keypad.

Features:

* Large numeric buttons for speed
* Fast correction (delete key)
* Optional double-zero shortcut (00)
* Immediate participant preview under the bib field

Best used for:

* High-throughput finish lines
* Situations where scanning is slower than typing

Always confirm the participant preview before pressing **Send**.

### QR Scanning

If QR codes are printed on bibs, judges can scan them to auto-fill the bib number.

Depending on configuration, scanning can:

* Fill the bib field only
* Automatically submit the passing (if enabled)

Best used for:

* Reducing typing errors
* Long or difficult bib numbers
* Low-visibility situations

QR scanning reduces input mistakes but may be slightly slower in dense finish traffic.

## Participant Preview

After entering a bib number, the app displays:

* Participant name
* Race distance
* Category

<figure><img src="/files/FEEl7RxxzwoEdC116v0m" alt="" width="336"><figcaption><p>Participant Information Preview</p></figcaption></figure>

This allows judges to confirm they are recording the correct athlete before sending the passing.

If no participant is found:

* The app will indicate it
* The passing can still be recorded (depending on event configuration)
* Race Control can review it later

## Sending a Passing

When **Send** is pressed:

1. The passing is created locally.
2. It appears immediately in **Live Activity**.
3. The app attempts to send it to the server.

The passing status will update as:

* Pending
* Sending
* Sent
* Failed (with retry)

All actions are append-only and traceable.

## Offline Behavior

Manual Timing is designed to work in unstable connectivity conditions.

If the device is offline:

* Passings are queued locally.
* They appear as Pending in Live Activity.
* Automatic synchronization occurs when connection returns.

Important:\
Keep the app open during race operations. Offline queueing works best when the app remains active.

## Processing Indicators

The app may show informative indicators about whether Race Control is currently processing passings for:

* The device
* The assigned checkpoint(s)

<div><figure><img src="/files/qvbxf76ALZqcxnSHzOPz" alt="" width="368"><figcaption><p>Process Passings Status</p></figcaption></figure> <figure><img src="/files/S2b068elf8YNEeCMuaPD" alt="" width="179"><figcaption><p>Topbar Checkpoints Status</p></figcaption></figure></div>

Even if processing is disabled:

* You can continue capturing passings.
* Race Control decides what is processed or applied.

This ensures judges never stop capturing data due to configuration changes.

## Duplicate Protection (If Enabled)

In some configurations, the system may include protection against duplicate timing events.

This helps prevent:

* Accidental double-taps
* Rapid duplicate submissions
* Unintended repeated entries

If a passing is rejected due to duplication, the app will indicate it in Live Activity.

## GPS Snapshot (When Available)

If the device allows location access:

* A GPS snapshot may be attached to the passing.
* Latitude, longitude, and accuracy are included.

This can help:

* Validate checkpoint location
* Provide additional audit context
* Support race analysis

GPS is optional and depends on device permissions.

## Live Activity Integration

Every Manual Timing action appears in **Live Activity**, showing:

* Timestamp
* Bib number
* Participant name
* Sending status

<figure><img src="/files/r4oSINSYUYtk6U9RT5nH" alt="" width="375"><figcaption><p>Live Activity Feed</p></figcaption></figure>

Live Activity acts as your operational confirmation panel.

If you see Failed:

* Keep the app open.
* The system will retry automatically once online.

## Operational Best Practices

Before race start:

* Confirm the correct checkpoint is assigned.
* Test one sample passing.
* Verify participant preview works correctly.

During the race:

* Use keypad for speed at high volume.
* Use QR scanning when accuracy is more important than speed.
* Always glance at participant preview before sending.
* Monitor Live Activity for failed submissions.

If kicked out:

* You will return to the login screen.
* This means another judge logged in with the same token.
* Log back in only if you are supposed to take control.

After the race:

* Review passings in Race Manager.
* Ensure all Pending entries are Sent before closing the app.

## Summary

Manual Timing is the fastest way to capture participant passings directly from a mobile device. It combines high-speed keypad entry, optional QR scanning, offline queueing, and real-time synchronization with Race Control.

It is designed so judges can focus on the athletes — while the system ensures traceability, reliability, and synchronization behind the scenes.