A dashboard for a car that never had one
Rune reads my 2026 Honda Accord in real time. A Raspberry Pi in the armrest pulls data off the engine and turns it into a health readout on a phone stuck to the dash. It runs on every drive.
A car that never showed its hand
A modern car already knows almost everything about itself. Coolant temperature, fuel trims, catalyst heat, battery voltage, every sensor the engine computer watches to keep itself alive. It just never shows you any of it. The dashboard gives you a speed, a fuel gauge, and a check-engine light that only turns on once something is already wrong.
Rune is my answer to that. A Raspberry Pi 4B sits in the armrest, taps the car's OBD-II port through the CAN bus, and reads the same signals the engine computer sees. A phone mounted on the dash shows them back to me as a single health score, updated live while I drive. Not a fault code after the fact. The actual state of the car, right now.
Turning readings into health
A raw number off a sensor does not tell you much. 440 degrees at the catalyst is fine on the highway and alarming at idle. So the readings pass through three layers before they become a health score, each catching a kind of problem the last one misses.
- 1layer 1
Threshold checks
The floor. Every reading is checked against the range Honda considers safe for that specific part. Fast, boring, and enough to catch anything already out of spec.
- 2layer 2
Streaming anomaly detection
A HalfSpaceTrees model learns what normal looks like for my car, on my drives, and flags readings that are strange even while still inside the safe range. I picked it over an isolation forest because it scores each reading as it arrives, without holding a window of history in memory on a Pi.
- 3layer 3
Trend forecasting
The slow one. It watches how a value drifts across weeks, so a battery giving out or a sensor going lazy shows up as a falling line long before it trips a threshold.
Catching the strange, not just the broken
Here is what layer two actually does. This is catalyst temperature over a ten-minute window. On the left is normal highway driving. In the highlighted stretch the temperature starts swinging as conversion efficiency drops, and the anomaly score climbs past the line. Drag the sensitivity to see where the model decides something is off.
The parts that took the most care
Two pieces took the most care.
Nothing goes back to the car unchecked
Reading from a car is safe. Writing to it is not. The CAN bus is the same wire that carries braking and throttle messages, and a malformed command does not politely fail. So every command the Pi is allowed to send passes a gate first that validates it against a hand-written allowlist. If a command is not on the list, it never reaches the wire. I would rather the feature not exist than ship a way to brick my own car.
The interesting data is not in the standard
The generic OBD-II standard exposes maybe a dozen values. Everything genuinely useful, the real fuel trims, the transmission and catalyst internals, lives in Honda-specific parameter IDs that are not documented anywhere official. Finding and decoding them was most of the work, and it is why the health score reflects this car specifically instead of a generic engine.
A Pi in a car gets hot
A sealed armrest in summer is a bad place for a computer. When the Pi heats up, Rune backs off on its own, slowing the analysis it can afford to slow so the parts that matter keep running instead of the whole thing throttling at once.
In the car
Rune runs on every drive. The health score is live, and the safety gate has stopped exactly the mistakes it was built to stop. The demo on the site plays recorded sample data so you can see the screens without my car present; the system behind them is the one in the car.
I keep adding sensors because the feedback is immediate and physical. I change something, I drive, and the car tells me whether I was right.