Français

P.06Internal prototype

Systèmes embarqués

Low-level work in C and C++: multi-channel OBD-II reading, network timing on microcontrollers, real-time graphical instrumentation.

Period
2025 – 2026
Role
Acquisition, protocols, display, build tooling.
Stack
  • C
  • C++
  • Python
  • OBD-II
  • TCP sockets
  • ESP32
  • Make

Reference points

  • 8

    vehicle channels read in parallel

    CSV outputs declared in the acquisition module

  • 1 ms

    polling period

    poll_interval parameter of the acquisition module

  • 0,1 s

    reconnection delay

    reconnect_delay parameter of the acquisition module

The problem

Between a car's ECU and a readable screen lies a long series of things that do not exist on their own: a serial or network link that drops, channels answering at different rates, and a display that must never wait on data.

What was built

  • 01

    OBD-II reading across eight channels — engine speed, road speed, fuel, coolant temperature, tyre pressure, brake pressure, pedal position, engaged gear — each written to its own file.

  • 02

    Automatic reconnection: a link drop interrupts neither the other channels' reading nor the writing to disk.

  • 03

    A display in C: speedometer and tachometer drawn from scratch, fed by the Python stream over a local link.

  • 04

    Timing in C++ that polls a networked microcontroller and timestamps passes, one thread per car.

  • 05

    A launcher that starts both processes, propagates stop signals to children and leaves no orphan process.

Architecture

timestampECUOBD-IIESP32TCP, passAcquisitionPython, 1 msTimingC++, one thread / car8 filesflush + fsyncInstrumentsC, speedo / tacho
Two processes, one local link, one launcher stopping both together.

Technical decisions

One file per channel

OBD-II channels do not answer at the same rate and some do not answer at all depending on the vehicle. A single file would have meant waiting on the slowest channel, or writing gaps. One file per channel lets each advance at its own cadence, and a missing sensor is immediately visible: the file stays empty.

Forced write to disk

Each reading is flushed then synced to the medium. On an in-car acquisition, the session rarely ends cleanly: the ignition is cut, something is unplugged, the laptop battery dies. Data left in a system buffer is data lost.

Explicit propagation of stop signals

The launcher traps the interrupt and terminates its children before exiting. Without that, a Ctrl-C leaves a Python process holding the serial port, and the next launch fails on a busy device — trackside, with a laptop and five minutes to spare, that detail decides whether the session happens.

What it demonstrates

Systems programming, vehicle protocols, robustness to disconnections, process and signal handling.