Case study

Regularity rally pacing app, a prototype

Our own R&D for regularity rallies: one app tells the driver and co-driver whether the car is early or late, using distance measured at the wheels. A prototype, still in development.

Client: Own R&D
Sector: Historic regularity rallies
Role: Firmware, board, app
Status: Prototype, in development

0.07s
Timing error on a simulated test stage
3.2 km replay
1app
For driver and co-driver
Designed to replace separate apps

Pilot display in dark mode: ON PACE above a large green delta of plus 0.5 seconds, a tolerance bar from minus 2 to plus 2 seconds, the next speed change to 55 km/h in 3.00 km and the finish at 9.00 km. Synthetic test data. — FIG. 1Pilot display and the copilot's stage screen

Copilot screen during stage 2: on pace at minus 1.2 seconds, phone GPS as the position source with a low confidence flag, 349 m to the finish control, 36 km/h, and correction buttons for minus 50, minus 10, plus 10 and plus 50 metres. — FIG. 1Pilot display and the copilot's stage screen

The problem

A regularity rally scores every second early or late

Hidden controls time the crew to the second. The driver needs one steady number, and GPS on its own jumps around.

Pace deltaDemo data

+0.47sLate

What we built

Distance from the wheels, satellites only correct it

A small box in the car counts wheel turns, and the app follows that distance along the official route.

FIG. 2Hub, link and app

In use

Replay report map of a synthetic hairpin route: the route line, the estimator path, accepted GNSS fixes as blue dots and rejected fixes as crosses coloured by the gate that rejected them, with a 100 m scale bar. — FIG. 3Synthetic route replay

Dark replay screen in the app titled Tier B estimator replay: a synthetic replay at 49.8 of 100 seconds, speed options 1x, 4x and 16x, and a route map with the completed section in blue. — FIG. 4Replay in the app

Services

IoT, firmware and mobile as one system

How the rally system is built: firmware, board, estimator, app

Route-progress estimator: Wheel distance leads and satellite positions only correct it, so the number stays steady through hairpins and tunnels.
Firmware and hardware: An ESP32 hub counts wheel pulses, reads GNSS and motion sensors and logs every stage, then streams to the phone over Bluetooth Low Energy.
Carrier board written as code: The circuit is generated from code and passes the electrical and design rule checks. Fabrication has not started.
Offline maps, built for the car: Romania's road network from OpenStreetMap ships inside the app, and the pacing number stays on screen even if another view fails.

Stack