MyLaps and Orbits

Orbits is the timing software at the track. Race Control reads its exports, and it can hand Orbits a run configuration built from your own event.

Upload timing files

There is nothing to connect. Export from Orbits and upload the file against its session, on Event → Schedule.

Load timing covers both file shapes and what happens to them.

Use the original passing log for a crossing import. Orbits also exports lap times grouped under each rider's name. That file omits finish flags and transponders. Race Control does not accept that grouped file as a passing log.

Check the stored best laps against the accepted Orbits results before generating grids. Orbits can invalidate a lap without deleting its crossing. A passing CSV can omit that distinction. If the best times differ, review the Orbits correction and record a qualifying override where needed.

Race numbers that differ

A number in a timing file does not always match the number a rider registered with. Race Control resolves a passing log by transponder first, then by an event number alias, then by name, then by registered number.

When you confirm a number difference, that decision is kept and replayed. It also confirms the matching Speedhive standings row for that season, so one review answers two questions.

A matched transponder is a claim with a record behind it. It never merges two riders on its own.

What a race file needs

A practice or qualifying log needs only crossings, and it collapses to each rider best lap.

A race log needs lap counts, elapsed times, and a finish marker. Race Control then assigns finishing positions within each class by laps and then elapsed time. A starter who never crossed after the flag is a DNF. A rider on the race roster with no passing at all is a DNS.

The uploaded finish marker is authoritative. Race Control does not apply its own lap or distance rule to decide whether a race counted.

Export a run configuration to Orbits

When your event was built from a schedule template, you can download an Orbits run configuration built entirely from Race Control data.

This replaces maintaining the same schedule twice. Nothing is read from or written to a spreadsheet.

The event needs a copied schedule template with Orbits runs and a current MotorsportReg registration snapshot. On Event → Setup, review each run's exact source products and competitor count. Reviewed race and qualifying product bindings select the riders. For practice and warmup, choose an Audience Source Qualifying Run when those runs use a qualifying product's riders, then save the event-owned link. A link in the reusable template is copied into future events; an event link corrects that event only. Race Control blocks the XML download while a run lacks a reviewed product audience or an assignment lacks a valid current eligibility claim or timing identity.

After Save Product Review or Apply Reviewed Products, run counts update without a page reload.

Older registration captures made before eligibility claims use their stored inclusion decisions; Event Setup identifies this policy. New captures require matching claims for every selected assignment. A run with no eligible riders remains visible for review; an entirely empty file cannot be downloaded.

An Admin can preview saved Group selections and apply them to the source schedule template. Later events copied from that template start with those Group names. Earlier event copies keep their own settings.

Groups can span several products and runs. You can save Group names as XML class labels without changing the rider rows. The optional promotion action shows the exact labels it would put into future template copies. For CVMA, keep the reference template's product-specific labels unless staff explicitly choose new ones. Broad provider Group labels lose that detail.