OBD-II diagnostics on a car’s head unit
Live engine diagnostics for a 2006 car, running on its Android radio, deliberately read-only.
Context & problem
The car is a 2006 Seat Leon and the screen already in the dashboard is an aftermarket Android radio, so the diagnostics can live where the driver is already looking. It talks to an ELM327 adapter over Bluetooth for live readouts, fault codes and session logging. The hard part is not the protocol; it is that the connection is unreliable by nature. Dropouts, `NO DATA` replies and adapters that are cheap clones of the real thing are treated as normal flow, not as errors.
Role
Sole developer.
Constraints
- Read-only, permanently. The only write it will ever perform is clearing fault codes.
- It runs on a car radio, not a phone — landscape, and reachable while parked.
- The adapter may be a clone that answers incorrectly, and has to be detected as one.
Decisions & why
- Coding and adaptations are excluded by design, not postponed.
- Writing to a car’s modules can brick them. A diagnostics tool that cannot write cannot destroy the car it is diagnosing.
- Nothing above the transport interface knows which transport exists.
- A later phase swaps Bluetooth for an ESP32 and a CAN transceiver to reach the manufacturer-level measurements. Behind an interface, that phase adds a transport instead of rewriting the app.
- Built against a simulator and replayed logs; the car is only for validation.
- The alternative is developing in a car park. The fake transport was the first thing written, and it is what makes the rest testable.
Stack
- Flutter
- Dart
- Riverpod
- SQLite
- Bluetooth
- ELM327
- ESP32