Event timing: run a timed race day

Run this checklist independently for every timed ticket and distance. Each timed distance moves through its own lifecycle: Setup → Ready → Live → Closed → Finalised.

Two things to hold onto throughout:

• Two distinct records. Gate attendance and finish timing are separate. Scanning someone into the venue does not record a finish, and recording a finish does not check them in.
• Independent distances. Each timed ticket has its own roster, start batches, lifecycle, evidence review and published results.

Important — provisional timing. Smartphone timing is an operational timing tool, not a certified photo-finish or UHF timing-mat system. Use finish-line video or a manual order sheet as backup evidence for competitive events.

Before race day

1. Build the registration structure

1. Create the event and enter its date, venue, registration window and sales settings.
2. Create a clear ticket type for every timed distance or division. Include the distance in the ticket name — for example 10 km, 21.1 km and 50 km MTB.
3. In Timing, create one timing race for each timed ticket type. Give each race an unambiguous name, sport and distance.
4. JollyBee binds that ticket to its timing race. Only registrations for that exact ticket enter the race roster. Do not create timing races for spectator, meal or other non-racing tickets.
5. Recheck the mapping before sales open. The ticket chosen during registration determines which distance roster receives that entrant. Never use one ticket type for entrants who may choose different distances later.

The structure is: Event (one event-day container) → Ticket (exact distance or division) → Timing race (independent roster and results) → Start batch (its own official gun time) → Entrant (timed from the assigned batch).

Within each distance, create one or more start batches / waves. For example, a 21.1 km ticket can have Elite, Batch A and Batch B, each with its own official gun time. Entrants remain on one distance roster and are timed from the batch to which they were seeded.

2. Configure race numbers

Open Race numbers from the event and choose an assignment mode:

• Assign at the door — sequential bib hand-out as entrants arrive for ordinary event operations. If you prepare this event for JollyBee live timing, Prepare entries still pre-assigns a number to every confirmed entrant before building the timing roster.
• Pre-assign at registration — packed race packs and numbers included on entry cards.
• No numbers — use only when the event will not use JollyBee race timing.

Create enough non-overlapping number pools for all expected entries. A ticket-specific pool is recommended for each distance or category because it makes packing and visual checks easier; an event-wide pool can serve remaining ticket types. Leave spare numbers for replacements and late entries. Number pools do not recycle numbers automatically. Clearing or replacing an assignment can make that number available for a later deliberate manual assignment.

Before race day, compare active registrations with the pool capacity and use Assign now if older registrations need pre-assigned numbers.

3. Assign staff and responsibilities

Assign event-scoped access in Timing. Keep duties explicit:

• Community owner/admin — event, tickets, ticket-to-race mapping, number pools and staff assignments.
• Registration — scan entry cards and record arrivals.
• Numbering — issue or correct race numbers.
• Timing capture — open a mobile timing session and record finishers.
• Timing control — prepare rosters, start and close each race, and recover abandoned devices.
• Results — review evidence, correct results and finalise each race.

Nominate one controller. Brief finish operators on the distance assigned to their station; each phone must open the correct race. If distances share a finish chute, use clear signage and a verbal distance call as the entrant crosses the line.

4. Prepare devices and the roster

Complete a rehearsal with the same phones and network plan you will use on race day.

1. Fully charge each phone, take a power bank, enable automatic date and time, and disable aggressive battery saving for JollyBee.
2. Sign each operator into their own account. Grant camera permission and, when required, NFC permission.
3. In the web Timing page, choose Prepare entries for each race. Confirm that its prepared count matches registrations with status registered or attended for its mapped ticket type. Waitlisted, pending, cancelled and other statuses are not prepared.
4. Process late registrations, number assignments and chip bindings at the arrival desk. If a desk worked offline, reconnect it and wait for those operations to be confirmed by the database.
5. Choose Refresh entries after the last registration or identifier change. Confirm the prepared count again. A refresh preserves existing batch and seed assignments; a newly added entrant must still be reviewed.
6. Open Batches & seeding for the distance: add the ordered start batches and their capacities, enter each planned gun time, paste bib,expected finish time rows or enter expected times manually, choose Auto-seed fastest first, then review individual assignments. Save only when every entrant belongs to exactly one batch.
7. Only now, while online, open the mobile Admin → Race Timing list and tap Open for the correct race on every finish phone. JollyBee downloads that race's manifest, calibrates the device clock and opens an audited session.
8. Check that every phone shows the intended race name, batches, entrant count and an acceptable clock connection. Use a separate test event for an end-to-end rehearsal; never add a test finisher to the live event.

Connectivity is required once. Opening and calibrating a timing session requires connectivity. Once its manifest and clock anchor are cached, that open session can capture finishes without connectivity. Open finish devices as late as practical: a changed roster or chip binding requires a new manifest before the start.

Race day

5. Run the arrival desk

From the mobile Admin tab, open the assigned arrival desk and use Scan Tickets.

1. Scan the entrant's entry-card QR or supported barcode.
2. Confirm the displayed name and ticket/distance before handing over a pack.
3. Issue the shown number, or enter/assign the correct number if authorised.
4. If the event uses phone-readable NFC entry cards or chips, use Link NFC timing chip while the entrant's registration is open.
5. Watch the offline-operation status. A locally saved action is provisional until the database confirms it; use Sync now when connectivity returns.

Roster freeze. Do not start a distance until late registrations, bib assignments and chip bindings have synced and its roster has been refreshed. After the race is live, the official roster is frozen.

6. Start every batch and capture the distance

In the mobile Admin → Race Timing list, each distance shows its nested start batches. At the starter's signal, the owner or a Timing control operator taps Start now for that exact batch and confirms its distance, batch name and entrant count. The first batch makes the distance LIVE; later batches receive their own independent gun timestamps without resetting the distance.

Batch starts are online-only. A start is deliberately fail-closed and is never placed in the offline replay queue — a delayed replay would create a false gun time. If the response is interrupted, refresh the batch list. JollyBee uses the same action identity to reconcile a start without creating a second timestamp. Never start a batch early merely to test the button.

Finish phones record the entrant identity and immutable finish observation. JollyBee looks up that entrant's assigned batch on sync and calculates elapsed time from that batch's official start. A capture for an unstarted batch is kept for review rather than silently timed from another batch.

Finish capture methods:

• Manual bib — enter the race number for the quickest controlled fallback.
• QR / barcode — scan the entry-card QR or supported barcode with the camera.
• Phone-readable NFC — tap a previously linked NFC card or compatible tag.
• Operator confirmation — confirm the app's feedback before moving to the next entrant.

Local queue first. Every finish observation is written to the phone's durable local queue first. It remains available through a network interruption and syncs when connectivity returns. Multiple phones may capture the same race; duplicate reads are kept as evidence and resolved during review.

Protect the offline session. While offline, do not sign out, change operator, clear app storage, uninstall the app or replace the open timing session. Keep the app awake and periodically check the pending count. When online, use Sync now and wait for database acknowledgement.

7. Close devices and the race

1. Stop accepting new reads and compare each phone's local total with the finish-line manual/video record.
2. Reconnect every phone, choose Sync now, and wait until no captures remain pending.
3. On each phone choose Sync & end. Do not simply close the app.
4. Confirm that every populated start batch has been started. When all devices have ended, the controller chooses Close finish capture for that distance.

If event control closes the race before an offline phone reconnects, captures saved before the close cutoff may still sync. Keep the phone and its session intact until JollyBee acknowledges them.

Recover an abandoned device only as a last resort. First establish that its local queue cannot be recovered. Recovery closes the session with an audit reason, but any evidence that exists only on that phone is excluded. If the app offers a recovery export, save the JSON with the event records before archiving the stranded queue.

After the race

8. Review, finalise and publish

Finalisation gate. Finalisation is blocked while a device session remains open or a result issue is unresolved.

1. Review quarantined reads and either use the capture or dismiss it with a reason.
2. Inspect duplicate evidence. Duplicates do not block publication, but a results operator may select a better read with a reason.
3. Resolve every missing entrant with a verified elapsed time or an explicit DNS, DNF or DSQ status.
4. Check the finish order and elapsed times against the backup record.
5. Choose Finalise results only after the race director signs off.

Finalise and publish each distance separately. Retain with the event records: timing exports and recovery evidence, manual finish sheets, finish-line video, and the race director's results sign-off.

Troubleshooting

• Entrant missing from a race — confirm their active registration uses a ticket mapped to that race; sync the arrival desk, assign a bib, then refresh entries before opening timing sessions.
• Wrong distance appears on a phone — end the empty session and reopen the correct race. Never capture one distance against another race's manifest.
• Entrant is in the wrong batch — before the first batch starts, correct their seed time or batch in Batches & seeding and save. Batch assignments lock when timing starts.
• A batch start response times out — stay online and refresh the batch list. If it shows Started, do not press again. Otherwise make a fresh deliberate start after confirming with the starter.
• Race is absent from mobile — confirm the staff assignment, that the race is prepared (READY or LIVE), and that the phone is online; refresh the Race Timing list.
• Clock calibration is rejected — enable automatic time, move to a stable connection and open the race again. Do not bypass an uncertainty warning.
• QR/barcode is not recognised — confirm the correct race, clean the camera lens and increase light; use the printed bib as the fallback.
• NFC tag is not linked — bind it at the arrival desk, sync the binding and refresh the race manifest before opening finish sessions; otherwise use bib or QR.
• Captures remain pending — keep the original operator signed in, reconnect, use Sync now, and do not end/reset the session until every item is acknowledged.
• A lost phone leaves an open session — try to recover the device and sync first. If impossible, use audited recovery with a specific reason and record the evidence gap.
• Quarantined or duplicate reads appear — preserve them; they are evidence. Resolve quarantined reads and compare duplicates during post-race review.

Current limitations

• Each timing race represents one ticket/distance and supports several seeded start batches. Relay legs, rolling individual starts and start-mat/net-time timing are not yet modelled.
• Offline finish capture works only after the phone has connected once to download the current manifest, calibrate its clock and open a session.
• Phone NFC is short-range HF. JollyBee can read NDEF identifiers and the UID from compatible NfcA, IsoDep or NfcV tags. It does not read common long-range UHF race RFID bib chips, timing mats or many chips supplied by commercial race-timing vendors.
• External UHF/RFID reader and timing-mat ingestion is future hardware work.
• Smartphone timestamps still include operator, scan and device uncertainty. Treat results as provisional until evidence review and finalisation.