I too have repurposed a similar machine to try to help me solve a nagging problem.
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.
ps, if you haven't annihilated your syncros, you can 100% shift without the clutch, just "burp the throttle" when you want to shift, meaning, let off the gas, change gears, back on the gas.
shifting up anyway.
downshifting is another story, as is starting from a stop, though I've had good luck with a disabled neutral safety switch and stopping in neutral, turning the car off, pop into 1st, start when the light turns. Hell on the starter and battery, but sometimes it's the only option.
"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.
> 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
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
> 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)
> Motorway is an hour out from where I live. Each tweak meant hopping on the bike and carving out hours to test.
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.
Yeah, I'm very surprised they didn't record the data from a single ride, with some sort of manual entry for "brakes should light up now", and then test at home.
Fun signal processing project and all the sampling problems sound typical. Unless this is just for your bike, given that some of the pokey fours run up to 15k rpm ~ 250Hz primary, I think it would be a lot easier to use a significantly higher sample rate and then treat in the digital domain. If you can recognise the engine speed and signal as a reliable pattern (use a digital PLL?) you might be able to subtract it and get more of the chassis signal left. As another poster pointed out, if you could do a motorway run with a high sample rate you have a good dataset to experiment with, including seeing how far you could downsample and still get appropriate sensitivity and selectivity.
On a bike you have the front brake lever at the throttle on the right hand.
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.
From the original article, linked from this article:
> 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.
> 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.
This reminds me of a project I built in a class during my EE degree--I wanted a thing that would pick out the beat in a song and flash an LED accordingly. I thought it would be pretty easy to just look for spikes, but you can't have a constant threshold or else you will just run the LED for the entire duration of some high-energy portion of the song (or else you will hardly ever run it at all). It needed to be adaptive, but the adaptive threshold needed to be able to respond quickly to changes in the "average energy" of a song. It took quite a lot of calibrating to make it work properly, and I learned a lot in the process.
18 comments
[ 4.3 ms ] story [ 52.0 ms ] threadhttps://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.
I for sure approve this creative way to test things
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.
ps, if you haven't annihilated your syncros, you can 100% shift without the clutch, just "burp the throttle" when you want to shift, meaning, let off the gas, change gears, back on the gas.
shifting up anyway.
downshifting is another story, as is starting from a stop, though I've had good luck with a disabled neutral safety switch and stopping in neutral, turning the car off, pop into 1st, start when the light turns. Hell on the starter and battery, but sometimes it's the only option.
"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
Isn't this mandatory in the EU?
Edit. No. Only for passenger cars
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
...
> 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)
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.
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.