A Vibrator Helped Me Debug a Motorcycle Brake Light System

https://news.ycombinator.com/showhn.html

> Show HN is for something you've made that other people can play with. HN users can try it out, give you feedback, and ask questions in the thread.

One of my vehicles uses a hydraulic clutch. By design, air bubbles can be trapped in the master cylinder due to factory bends in the lines and the orientation of the master cylinder when it is properly installed. If this happens it will be impossible to shift the gears (manual transmission) until the air is bled from the lines.

I tried multiple air burping procedures without success. Part of the procedure involves tapping on the hydraulic lines to help dislodge air bubbles so they can flow up and out of the lines into the fluid reservoir. The area is tight and in order to do this efficiently you must remove the master cylinder from the vehicle.

I decided to avoid that removal step and employ a Sharper Image back massager as a tool to dislodge air bubbles with the system in place in the vehicle. Since that massager is huge it would not fit into tight places under the hood so I used a length of PVC pipe held tight to the lines to transfer the vibration to the lines. This allowed me to get large air bubbles out of the lines. In the end I was not able to remove enough air using this hack because an O-ring near the bottom of the system is missing or bad and that allows air to enter and flow up so i could vibrate that thing all day and never get anywhere. It was a shot in the dark anyway. If that O-ring were not missing or bad I know it would work.

"Evan and Katelyn" is the name of a youtube channel where (amongst other less mature things) they make a bunch of small things with concrete and epoxy, like a concrete keyboard. Both materials (especially concrete) need some assistance in flowing into small spaces and getting bubbles out. For the size of project they often work on... a personal vibrator seems to work damn well.

Concrete keyboard video as an example: https://www.youtube.com/watch?v=HUSG5ohV0nY

The author is configuring the sensor wrong i think. The usually way is you setup sampling rate of register, setup fifo inside register, wait for interrupt from sensor(through GPIO pin), then read from FIFO. Just blindly read data from sensor will get you in trouble, like reading duplicate value

It's easier said than done, but you might want to approach this like a data science project. Record the data from your test runs, annotate the behaviour you want, and build up a dataset. You should be able to experiment with any number of tweaks (admittedly except for the data sampling itself) without having to get back on the bike.

You always, always have to have at least two fingers on the brake lever and control the throttle with the thumb and palm.

It is completely irresponsible to ride not doing that because sudden obstacle will not give you enough time to put them back on it. Then you lose 60-80% of braking power for a second or two.

If you are doing it right then when you drop throttle you almost automatically slightly pull the brake lever. If the lever and brake light switch on it are adjusted properly like they should be, you have the brake lights on.

Nice project, but..

> Moreover, during intense braking scenarios, it flashes proportionately to the braking intensity.

Is it just me who finds this behaviour to be a regression? If I see a brake light on a motorbike, I know that the bike is slowing, and I respond accordingly. An urgent flashing brake light doesn't make me react faster, but it does serve to confuse and distract my brain.

...

> But when things are smooth for a while, the debounce comes back down

it sounds like he's just incrementing a variable in the first case and using timers to decrement it in the second case. that's a bad implementation. the correct implementation here is an envelope follower, or maybe-perhaps a kalman filter. OP's implementation will exhibit motorboating: https://en.wikipedia.org/wiki/Motorboating_(electronics)

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.

Isn't this mandatory in the EU?

Edit. No. Only for passenger cars

I for sure approve this creative way to test things