RaceBox Telemetry Viewer

Inspiration

I have experience as an RC mechanic, business owner, and driver, but I am not a traditional software developer. Existing telemetry tools showed data without clearly explaining where time was gained or lost, whether an improvement was repeatable, or how the car behaved before a mistake or crash. I wanted to combine practical racing knowledge with accurate telemetry analysis. Codex helped turn my troubleshooting process and driving experience into a working native application.

What it does

RaceBox Telemetry Viewer combines RaceBox GPS, VBOX/VBO, and 100 Hz Sanwa radio data into one synchronized Windows application. It lets drivers compare a reference lap against two other laps, replay their position on a calibrated aerial map, and examine speed, G-force, altitude, throttle, brake, and steering. The application detects corner events such as braking, turn-in, apex, throttle pickup, full throttle, and steering corrections. It calculates corner timing, minimum speed, exit speed, line deviation, and time gained or lost. Drivers can also place the start/finish line, automatically detect and number corners, reorder graphs, create annotations anywhere in the interface, and save the complete workspace.

How we built it

We originally built RaceBox Telemetry Viewer as a JavaScript and React browser application. That prototype helped us quickly test the interface, telemetry graphs, lap comparison, and analysis workflow. As the project grew, we realized that running large telemetry sessions, synchronized graphs, maps, and playback inside Chromium required too much memory. The browser architecture was useful for proving the concept, but it was not the right foundation for the lightweight, responsive tool we wanted at the track. We rebuilt the application as a native Windows program using C++20, DirectX 11, Dear ImGui, and ImPlot. The native version runs locally without Chromium, Node.js, or an internet connection and handles large telemetry sessions more efficiently. RaceBox supplies lap timing and speed, VBO provides GPS and motion data, and Sanwa supplies the real throttle, brake, and steering inputs. Their different clocks and sample rates are aligned without changing the original recordings. Codex acted as the engineering collaborator throughout the transition. I supplied the racing knowledge, telemetry, troubleshooting observations, visual feedback, and acceptance criteria. Codex helped translate those requirements into the original prototype, the native C++ architecture, automated tests, documentation, and a portable release.

Challenges we ran into

The biggest challenge was aligning telemetry from twodifferent devices. Their clocks, sample rates, and data responsibilities are different. A graph can look correct while still being improperly synchronized, so we used correlations, golden values, and automated tests instead of visual guessing. GPS alignment was another challenge. One comparison lap contained a whole-lap position drift. Rather than moving or rewriting the displayed GPS trace, the application preserves the raw data and applies a disclosed correction only during line analysis. We also had to maintain exact map alignment when the interface was resized or redocked. The aerial image, GPS trace, grid, markers, and playback dots now share the same world-to-screen projection.

Accomplishments that we're proud of

We are proud that a non-programmer’s motorsport knowledge became a functioning native C++ application instead of remaining an idea or mock-up. The application now supports three-lap synchronized comparison, real Sanwa controls, calibrated mapping, deterministic driver insights, editable corners, sectors, theoretical-best timing, annotations, altitude, G-G analysis, and persistent workspaces. The project includes seven automated native test targets covering telemetry parsing, lap timing, map calibration, persistence, driver-analysis rules, graph ordering, DirectX fallback, and large-session memory behavior.

What we learned

We learned that trustworthy telemetry analysis depends more on synchronization and data provenance than on producing attractive graphs. A faster speed at one point does not automatically mean the driver found a useful improvement. It may be the consequence of missing a line, compromising another corner, or losing more time elsewhere. Recommendations need thresholds, confidence, repeatability, net time effect, and safety checks. We also learned how well hands-on domain expertise can work with AI-assisted development. Codex could implement and test the software, but the important questions—what drivers need, which data is trustworthy, and whether a result makes physical sense—came from real mechanical and racing experience.

What's next for RaceBox Telemetry Viewer

The next step is connecting the tested second-generation evidence layer. It is designed to distinguish reliable gains from one-off results, compensation, and improvements that cause a larger loss later in the lap. Future plans include repeatability scoring across multiple laps, clearer coaching language, a complete reports workspace, coherent theoretical-best telemetry, improved crash and airborne-event investigation, additional telemetry formats, and longer performance testing.

Built With

• c++20
• cmake
• ctest
• dear-imgui
• directx-11
• dxgi
• github
• github-cli
• gps-telemetry
• gpx
• implot
• miniz
• ninja
• nlohmann/json
• openai-codex
• racebox-csv
• sanwa-csv
• vbox/vbo
• visual-studio-2022
• vite
• win32-api
• windows-10/11
• windows-imaging-component