DZGarage Cockpit in the race: from the bench to the Spain Classic Raid

In the previous post I wrote about what I built for the XII Spain Classic Raid: three ESP32s, two GPS receivers, a touch screen and about 23,000 lines of C++, all of it shown with CAD renders. I promised photos of the thing mounted and a report after Palencia.

We ran the four stages, from Gijón to Palencia, with Andrés driving and me as co-driver. The cockpit logged 894 km at 10 Hz, almost 1.4 million GPS rows, and we finished 28th of 127 overall (the stage by stage chronicle of the race is in DZ Lab), but this post is about the device, from the garage to Palencia.

From the CAD to the dashboard

The mount and the boxes came out of OpenSCAD, but the dashboard measurements I took by hand. On October 12 I spent the afternoon in the garage with the tape measure, the caliper and a piece of cardboard cut to copy the curve over the glovebox, and every number went back into the .scad. That same afternoon I put everything together on the table for the first time, and on the 14th we mounted it in the car, with the neopod stuck to the top of the windscreen.

Gijón, Saturday at 11:17

At the start in Gijón the co-driver's side of the dashboard looked like this: the cockpit on the right, the tablet with Rabbit in the middle, the driver's phone on a suction mount, and up top the neopod and the organiser's receiver. Before the start the cockpit said 0.123 km and the tablet 0.122, and by the afternoon the tablet was already 24 m ahead.

Saturday's log

Saturday night, in León, I downloaded the cockpit logs and crossed them with the roadbook and with the official results from MiRally. I looked in the GPS track for the turns the roadbook draws and compared their km with the cockpit's. At the three junctions we could identify without doubt, the cockpit was 5 to 15 m off the roadbook.

The tablet counts too much, about 6 m per km. It adds up distances between GPS points, and in a 6 km TC it drifts 40 m, and at 27 km/h that's 5 seconds early that don't exist. From Sunday on, in the car, the tablet was always aligned to the cockpit with its buttons.

In TC1, 247 of the day's 289 points came from three batches of −10 m we pressed at km 2.8, where there wasn't any tulip: 470 m less of TRIP. The screen went to say we were 43 s late when we were really 20 s early, and Andrés sped up to recover a delay we invented. The log keeps every ±1 and ±10 press with the time, the TRIP and the position, so one night was enough to rebuild the mistake meter by meter. The review had the question of what we thought was at km 2.73 written down, to talk it over at breakfast.

In four days there were 2,080 TRIP corrections. About 1,000 went only to the tablet, to align it with the cockpit; the rest to both or only to the cockpit. After Saturday we kept the rule of correcting only at a turn you can't mistake or at a speed change.

The nights

Every night at the hotel we did the same. When we arrived, the cockpit's "copy of the day" (the web page, at /logs) went to the phone and from there by AirDrop to the Mac. I gave Claude Code the CSV, the GPX, the MiRally results link and what happened in the car, because that's in no log. Claude downloaded the results of every control for every crew, ran tc_review.py over the log and the roadbook, compared our track with the official controls and with the median of the top 20, and wrote in Spanish the review of the day and the plan for the next one. A script turns them into a phone-sized PDF, an A4 and a WhatsApp text.

On Sunday we started at 21:40 and on Monday at 19:40, and both nights we went past 23:00. The repo has 31 commits from Saturday, 19 from Sunday, 11 from Monday and 4 from Tuesday.

Claude got things wrong too, and we found almost all of it before printing. On Sunday it said that with TC2 and TC4 at the level of the top 20 we'd be on the podium; once it did the math with the medians, it was 4th or 5th. In the Stage 4 plan it wrote that the tablet would show "early" in the R! TCs when it would show "late", and it put the lunch stop 32 km into the liaison when it was 26. A card for Tuesday's TC3 used kilometers taken from the roadbook file that aren't printed, which the project forbids on crew sheets, and we had to cut it back.

On Sunday night Claude's first draft said "always arm the cockpit's TABLA". I answered no: "arming the TC in cockpit is problematic, is not easy to load the info in cockpit using the web; after a reboot the info is lost; we can't do that multiple times while we are driving". From that answer came the correction cards and the way we ran Stage 3.

There's been only one firmware change during the race. Saturday night, in León, I flashed the version that loads the day plan from the roadbook in the structure of the time card (Saturday's log says v0.1-238, the other three days v0.2-91). With that I broke the feature freeze, and after it nobody touched the firmware until Palencia.

The tables and the liaison screen

The previous post had a whole section about the TC by tables mode, the one that reduces a sheet of passing times to a few cadences. The cockpit writes a row in the log every time a table gets armed or starts, and in the logs of the four stages there isn't a single one.

Loading a TC into the cockpit on the road didn't work. You have to do it from the web, with the phone, in the minutes between getting the sheet and the start, and if the cockpit reboots the TC data's gone. So we ran the TCs with the tablet, a stopwatch and a printed sheet with the passing time at each tulip.

In the TCs with hidden speed changes (the organiser marks them R!) the tablet uses Rabbit's average for the whole section and doesn't know about the changes. On Sunday, in TC2 and TC4, the tablet said we were late, we pushed until it showed 0 and we were really 2 to 4 s early for kilometers: 50 of the day's 63 points. That night we made correction cards, one table per TC that says what the tablet has to show at each km to be really on time.

By Monday we had dropped the ENLACE (liaison) screen and printed a table with the clock time for every point of the day. From Stage 3 on we used the cockpit only as the reference odometer, all day on the TC face with the big TRIP.

Two GPS and a power cut

The Garmin GLO was the main source and measured between 89% and 100% of each day's kilometers. The neopod took over when the GLO dropped out: 7% of the distance on Sunday, 11% on Tuesday.

On Sunday, at 12:51:29, 90 seconds before the start of TC2, the cockpit went off. It came back by itself in 10 seconds with the TRIP where it was. The log marks it as a power-on reset, so something's moving in the power supply or there's a bad contact. That night we checked the cable and the plug, and on Tuesday it happened twice more, 3 or 4 minutes before the start of TC4. In the four days the cockpit booted 21 times between hotel, starts and power cuts, and every time it came back with the TRIP.

In that Tuesday TC4 Rabbit's odometer got about 290 m ahead. That night I wrote it to Claude like this: "In TC4, something happened with Rabbit app, and odometer went crazy but odometer in the cockpit was ok."

The numbers

Km is what the log recorded and corrections are the ±1 and ±10 presses. The log km include the drives to and from the hotel, that's why they don't match the official route. The maps, every TC and the standings are in the Spain Classic Raid 2026 chronicle in DZ Lab.

What I'd change

We didn't use the tables and the liaison screen because in the car there's no time to load anything, and the co-driver's already got both hands busy with the roadbook and the stopwatch.

For next year, the first thing I'd do is make a TC's data survive a reboot, and teach the cockpit the hidden changes from the day plan so it replaces the correction card. Then I've got to find which cable moves, Sunday at 12:51 and Tuesday before TC4. And I don't know if the tablet has to stay on the dashboard, or if the cockpit needs a roadbook screen so Rabbit isn't needed anymore.