Coding a RaceCoach: From Telemetry to Driver Coaching

By peterm95018, 25 July, 2026

When I started RaceCoach, my goal was simple: make better use of the telemetry I was already collecting during autocross.

Like many drivers, I was recording every run with RaceChrono Pro, a RaceBox GPS, and OBD data. I had plenty of information, but only a few minutes between runs to decide what to change. Looking at graphs and numbers wasn’t helping me answer the most important question:

What should I do differently on my next run?

That question has gradually changed the entire direction of the project.

The Original Idea

RaceCoach began as a telemetry comparison tool. It imported RaceChrono CSV files, divided the course into segments, compared a run against a reference lap, and highlighted where time was gained or lost.

The reports were useful, but they suffered from the same problem as many data analysis tools: they described what happened without explaining why.

Knowing that I lost 0.32 seconds in a segment wasn’t enough. I still had to interpret the telemetry myself.

The Shift to Diagnosis

The biggest change over the past several months has been a shift away from reporting telemetry and toward diagnosing driving behavior.

Instead of treating every metric equally, RaceCoach now asks:

  • What driving behavior best explains this time loss?
  • How confident is that conclusion?
  • What is the single most useful adjustment for the next run?

That led to a much simpler mental model:

Telemetry → Metrics → Diagnosis → Coaching → Driver Improvement

Telemetry provides evidence.

Metrics quantify what happened.

Diagnosis explains the likely cause.

Coaching tells the driver what to change.

Building a Coaching Engine

Today, RaceCoach looks for recurring driving patterns instead of isolated numbers.

Examples include:

  • Late throttle commitment
  • Weak exit speed
  • Over-slowing
  • Momentum loss
  • Execution mistakes
  • Low-confidence situations where the telemetry does not support a reliable conclusion

One lesson learned during development is that software should sometimes admit uncertainty.

Early versions always tried to explain every time difference. That often produced convincing-looking advice that wasn’t actually supported by the data.

The current version includes confidence evaluation and is willing to say:

“No clear diagnosis.”

That turns out to be surprisingly valuable. Sometimes the best coaching advice is recognizing that the available evidence isn’t strong enough to justify a specific recommendation.

Event-Day Workflow

RaceCoach has also become part of my actual competition workflow.

After each run:

  • RaceChrono exports the run from my iPhone.
  • The file is uploaded automatically to an Ubuntu server.
  • RaceCoach analyzes the latest run against the current reference lap.
  • Updated reports are published to my website within minutes.

Between runs I typically read only the Grid Report, which is intentionally short.

Instead of presenting pages of telemetry, it answers:

  • What changed?
  • What caused it?
  • What should I focus on next?

The detailed report remains available later for deeper analysis.

Learning from Real Events

The project has benefited from real autocross weekends more than synthetic test data.

Recent PCA and Golden Gate Lotus Club events have provided opportunities to compare multiple clean runs on changing course layouts, evaluate how quickly I learn a course, and test whether the diagnoses actually match what happened behind the wheel.

Those weekends have also exposed weaknesses in the software.

For example, there were situations where I posted higher minimum speeds and better exit speeds yet still lost time overall. That highlighted an important limitation: speed alone cannot explain every performance difference. Future versions will incorporate path efficiency and line analysis to recognize when the driver simply covered more distance through a section.

Improving the Software

As RaceCoach has grown, I’ve spent almost as much time improving the software architecture as adding new features.

Recent work has included:

  • A documented diagnosis model
  • A coaching philosophy focused on actionable advice
  • Confidence-based filtering
  • Session summaries that identify recurring themes across an entire event
  • Cleaner separation between telemetry processing, diagnosis, coaching, and report generation
  • Validation cases that compare software output against known historical runs

This work may not produce flashy new screens, but it makes the coaching recommendations more consistent and much easier to extend.

Looking Ahead

The next phase is making RaceCoach even more like an experienced instructor.

Areas I’m exploring include:

  • Better path and line analysis using GPS projection
  • Detecting inefficient driving lines
  • Learning recurring driver habits across multiple events
  • Smarter diagnosis ranking
  • Automated regression testing to ensure new coaching logic improves the system rather than accidentally making it worse

Ultimately, I don’t want RaceCoach to become another telemetry viewer.

I want it to become a driver development tool that helps answer the same question after every run:

What’s the one thing I should do differently next time?

Every design decision now supports that goal.

Recent Results

At the past three events (GGLC, GGR, LPR), I’ve narrowed the gap down from a typical 3 seconds to .3 seconds. Whether or not RaceCoach is working, the focus on the development is helping my driving. At the GGLC 06/20/2026 event, I placed 4th overall PAX. At the 07/11/2026 GGR event I was 20th overall PAX. At the 07/12/2026 LPR event I was 5th overall PAX. 
 

Tags