The strangest part of this build is the bug itself: during the flash cycle, while the LEDs shut off one by one, the four-digit RPM readout froze on values in the six thousands. Watching yellow-orange digits stick at 7389 or 8253 while bright blue-white flashes cycle through is the kind of fault that would send most people down a rabbit hole. The maker even wondered aloud whether it was a processor speed limit or a coding problem, and the answer turned out to be refreshingly mundane.
The hardware is a tachometer for a car, built on an Arduino Nano with a second Nano generating a dummy RPM pulse just for bench testing. The readout is a fourteen segment HT16K33 display hooked up over I2C through a backpack, and the shift light is a twenty-five LED strip of DotStar SK9822 modules. The LEDs and display get their own power supply, which seems sensible given the maker noted the strips draw a fair amount of current depending on color and brightness. The fourteen segment choice also opens up a full alphabet for the settings menu, and the bigger size fills the panel nicely.
The open source base code has been extended with sections that write RPM digits to the display, plus some thoughtful touches: the peak RPM of a run is stored, a dimmer pin reading sets display brightness, and at zero RPM the panel shows dashes instead of a number. Below the shift point the LEDs light up from an RPM table by color, and once the shift point hits they flash on a timed millis interval.
The fix was moving strip.show so it runs once after all pixel colors are set instead of after every single pixel. A quick edit later, the freeze was gone. The open question now is converting any remaining delay-based patterns to a millis style, and with more features planned the maker is weighing a move to a Teensy board.