> So I needed a cheat code. Enter: a repurposed vibrator, No joke. I hooked it up to mimic the kind of high-frequency engine vibes you'd get ripping down a motorway. It wasn’t pretty, but it worked. I could test tweaks right from my test bench.
Those massage guns could be quite useful too. When finding a problem in the field, replicating it on the lab bench is always ideal.
> The current solution: The jitter helped, but it wasn’t bulletproof. Then I realized something deeper, the sensor has its own built-in sample rate, 400 times per second. If I read it too quickly, I might just be grabbing the same number twice. No new data. And if that repeat looks like a sustained deceleration, the light fires.
It should be a de-bounce based on time, not based on an arbitrary sampling rate. So you are looking for an average value threshold over a sliding window based in time.
Better yet:
1. On start-up it should be able to indicate an error via blink codes. You should for example be able to detect if an LED has burned out, there is moisture detected, that a brake signal was not detected over a X minute runtime, the temperature is outside safe limits, or the circuit draws current outside of the expected limits.
2. Use an IMU to detect de-acceleration events encase there is a break in the signal. It's obviously not ideal, but far better than nothing. Gravity is ~9.81m/s, and a braking force would be detected perpendicular to this. Again, you would use the error code on start-up to indicate that there is an issue.
3. Consider the use of an internal battery encase there is an issue with the supply voltage to the brake light. A bad power or ground could cause continuous resets, and failure to detect a signal.