Live telemetry for a racing ECU: a build log

The problem

PRS engineers electronic gear-shift systems used in real competition. Their control units are configured and monitored over a serial protocol whose lineage goes back decades — robust, proven, and entirely bench-bound. Watching engine parameters meant a cable, a laptop, and desktop software; there was no way for an engineer at the track, or a customer in their workshop, to simply glance at the live state of the unit.

The ask, in plain words: make the ECU visible on a phone and manageable from anywhere — without touching what already works.

The constraints that shaped everything

• The protocol was the spec. Serial protocols of this vintage are terse by design — single-character command families, tightly packed responses, behavior that lives partly in documentation and partly in the firmware's actual habits. Step one was protocol archaeology: mapping what the unit really says, not what the papers say it says.
• Cadence is a feature. Different engine parameters deserve different refresh rates. We designed the monitoring layer around distinct polling cadences — the fast set streaming at half-second refresh for the values you watch live, a second set at one-second refresh for the rest — so the link stays responsive instead of drowning in its own traffic.
• Zero firmware risk. The control unit ships to paying customers. The mobile and web layer had to be purely additive — speak the existing protocol, change nothing beneath it.

What we built

The native iOS app

A Swift app that connects to the unit wirelessly and renders live parameters in an interface designed for how it's actually used: glanceable between sessions, readable in sunlight, matched to the client's brand. Cadence-aware polling keeps the fast parameters genuinely live.

The web dashboard

A Next.js admin dashboard, deployed on Vercel with a Supabase backend, giving the manufacturer a single place to manage customers and their kits, define ECU parameters — including how each raw value is decoded and which are monitored — review logs, and see readings as live graphs. It's the operations side of the product: what the company sees, while the app is what their customers hold.

The design system

Both surfaces share one visual language, documented in Figma and aligned with the client's existing brand — because a tool used at a race weekend earns trust partly by looking like it belongs there.

What made it work

• Old protocols are documentation problems, not code problems. The engineering effort concentrated in understanding, not typing. Once the protocol's real behavior was mapped, the implementation followed quickly.
• Design the polling, not just the parser. The two-cadence structure — decided with the client, parameter by parameter — is what makes the app feel live without stressing the link.
• AI-native pace, senior review. One senior engineer, working with agentic tooling, shipped across firmware-adjacent protocol work, a native iOS app, and a full web platform — with every line reviewed. That breadth-in-one-head is the quiet superpower of the model: no hand-offs between an "embedded team" and an "app team," because it's one person who understands the whole chain.

Where it stands

The platform is in active use and growing — an ongoing engagement, with the dashboard and app evolving alongside the product line. Bench-only diagnostics became live monitoring on any device, and the manufacturer gained an operations console their product line never had.