The idea: a shift cue you can read without looking at it, driven by data the car already has, added without modifying the car at all. The car sees a standard diagnostic tool; everything interesting happens on my side of the port.
The problem
A tachometer is a bad shift cue. It is a small dial low in the instrument cluster, and reading it means taking your eyes off the road, finding the needle, and interpreting a number, all in the moment before the shift. What you actually want near redline is a signal that works in peripheral vision: position and color, not a gauge.
The harder problem is that a modern car is a closed box. The data to drive that signal already exists, the ECU tracks RPM, speed, and coolant temperature continuously, but there is no sanctioned way to add your own electronics to the dash. The one standardized opening is the OBD-II diagnostic port. This project lives entirely on that port: it asks the same questions a scan tool would, writes nothing, and unplugs without a trace.
What's working
The display is a 16-LED bar cut from an SK9822 addressable strip. I picked the SK9822 over the more common WS2812B for three reasons. It is driven over plain SPI with separate data and clock lines, so the microcontroller never has to generate a timing-critical one-wire waveform. Its PWM refresh sits near 5 kHz, where the WS2812B's much slower refresh shimmers visibly in peripheral vision, exactly where a shift light has to live. And it carries a separate 5-bit per-LED current setting, so the bar can dim for night driving without giving up color resolution. A 74AHCT125 buffer shifts the 3.3 V SPI lines up to the strip's 5 V logic.
The controller is an STM32 Nucleo-32 board with firmware built in PlatformIO. RPM comes from an off-the-shelf OBD-II adapter that speaks the diagnostic protocol on its own microcontroller and hands over the latest values, with age stamps, over I2C. The firmware polls it and maps RPM onto the bar as a green-to-yellow-to-red sweep, with a full-bar flash at the shift point.
The data source is an interface in the firmware, not a fixed device. On the bench, a simulated source plays back a synthetic drive loop, so the sweep colors, shift flash, and display logic can all be developed and tested at a desk. The OBD-II source swaps in for the car.
Version 1: off the breadboard
Current work is turning the breadboard into a version that can live in a car: the same circuit moved to perfboard, inside a 3D-printed enclosure sized for the top of the steering column. Two open items gate the install. The adapter's 5 V rail is rated for 2 A, which covers the strip's worst case on paper, but the bar stays brightness-capped until that holds up under a real load test. And the diagnostic port is powered even when the car is off, so the firmware has to drop into a low-power state whenever the engine isn't running, or the project becomes a slow battery drain.
Designed for version 2
Version 2 is already specced, and it replaces the off-the-shelf adapter with my own hardware: a custom PCB around an ESP32-S3, chosen because one chip brings a CAN controller, Bluetooth LE, and WiFi. Instead of requesting values through the diagnostic protocol, the board listens directly to the car's CAN bus, receive-only by design, and gets everything the modules on the bus already broadcast.
That opens up more than a faster shift light. The same data can drive indicators the dash doesn't offer: a low-battery-voltage alert, a warm-up mode that holds the shift point down until the coolant is warm, and gear detection computed from the ratio of RPM to speed. A phone app over Bluetooth LE handles configuration and live gauges, and drives get logged to onboard flash, with summaries syncing to my home server when the car is on home WiFi.