Hello Vital MTB Visitor,
We’re conducting a survey and would appreciate your input. Your answers will help Vital and the MTB industry better understand what riders like you want. Survey results will be used to recognize top brands. Make your voice heard!
Five lucky people will be selected at random to win a Vital MTB t-shirt.
Thanks in advance,
The Vital MTB Crew
I just started dabbling with Arduino last year and already well aware of the limitations on logging a high sample rate so well done for getting to where you are!
Or you could be a mondraker and make something just for marketing (that system can't actually work).
The issue is with the fork where a coworker of mine (magnetics expert) said you'd be picking up shovels and rakes from fields when riding by due to the strength of the magnet, which would be required for the sensor to work over 200 mm that is between the magnet and the Hall sensor.
A time of flight sensor makes much more sense, the only issue with it, for MTB, is that it could get dirty, either the sensor lens (this can easily be solved) or the target (dirt on the target gives you a step change in distance, giving you an offset in travel at a point in time).
Looking at this video very intersting is the switch on the handlebar to put a trigger on the data whenever you want. i think i will copy it.
So, what is the status with the BOM for the hardware and the code? Are you prepared to publish it, do you want to sell kits? I'm still very happy to test things out if possible 🙂
I decided to buy this and use at the handlebar to start and stop the logging, and to put the trigger whenever i want during riding.
Do whatever works for you and makes you feel comfortable, so take your time if you feel it makes sense.
great implementation! I think the use of a LiDar sensor is brilliant, I didn't think of that in my bachelor thesis where I designed a similar system some years ago, also using an Arduino. My design uses a pressure sensor connected to the fork or shock, like the Shockwiz does, but connecting the sensor to the air chamber and precisely converting the pressure changes into movement of the suspension element was quite a pain at first.
Like you, I also store the data on an SD card. After managing to achieve a maximum of about 50 Hz in my first attempts, I was able to reach over 500 Hz with some improvements to the code. If you want, I would be more than happy to help you with this. Just send me a message if you want
This is the "final" version mounted to the bike:
I also did some frequency comparison:
The first prototype was a lot bigger and used a bottle cage mount:
I also developed a tool to automatically analyze the data on a pc (and even made a logo: It's called SusAn
Thanks for motivating me to revisit the project.
I really like the handlebar button since is very confortable to start and stop the log during riding... gps antenna results slitghtly too long 😂😂
Edit: I ask because I think people working the problem from y'all's side may ultimately help out riders with their setup more than the traditional bracketing and timed runs approach, even if a rider never uses DA but gets to piggyback off of some similar riders' evidence-based setup
It's up to the user to read what the suspension is doing and what it should do. Data acquisition is easy. Doing something useful with that data is the hard part. I'd be happy to see some thoughts on this topic from people in the know, but it's usually the competitive advantage. Not having enough people or enough money to pay people like that is the reason so few riders in the world cup (any world cup) use data acquisition while it's the norm in motorsports, where the budgets are much higher.
The short answer is there isn't really any consensus on what the "target" is...yet at least. DAQ has taken off over the last couple of years so hopefully most of the people using it are learning as they go rather than thinking they already know what to look for. I definitely see some guys get hung up on looking at certain things in the data which may or may not be relevant, and thats a trap we all have to be mindful of
Knowing which data to gather is a super interesting question, you can get very carried away attaching sensors to everything but then what do you do with that? I currently have or am working on position sensors, accelerometers, temperature, gyro, gps, wheel speed and strain gauges but to be honest a simple suspension position (not even velocities) logger will be hugely insightful. Even a humble speed sensor (not gps) is a powerful tool from a rider perspective and getting faster as you can see exactly what sections you gain or lose speed on very easily.
One key thing we should never lose sight on is how the rider feels - good or bad, simple as that. If I was to decide on certain factors but rider feedback said they weren't comfortable then I need to change those factors. And realistically thats where most of us are at with Data Acquisition, very few have nailed down some good metrics on what a great set up looks like, so the process still involves a bit of trial and error and conversations with the rider. Don't get me wrong though having the data makes the process soooo much more streamlined as you can normally identify which direction a certain variable needs to go (eg spring rate) because suspension set up can be so counterintuitive that literally any adjustment can go in either direction so removing that doubt speeds things up immensely.
For a simple example of how I use it, with suspension data I mostly look at a position histogram that shows how much time you spend in each part of the travel. These are very straightforward to look at - if the graph is quite "flat" and shifted towards the end of the travel then things are too soft and unstable because the bike is wallowing around a range of travel instead of maintaining a particular height. If its a tall, sharp peak close to the top of the stroke then its too stiff. I regularly see people who think the suspension is too harsh but the histogram shows they are spending a lot of time deep in the travel. The instinctive response without data would have been to soften the bike but bump up the pressure and it not only feels better but they actually have more travel available and are still reaching the end when they need it!
And yes a big reason for me using it is so I can get very precise benchmarks of different types of riders, so those settings can be taken to a similar rider and they get to start off on a much more refined baseline than what they would have otherwise.
Another great example of an alternative DAQ to the typical suspension-based design is brakeace - https://www.brakeace.com/ which is very much focused on improving technique. Matt's software uses brake torque sensors to measure how effectively you are using the brakes on track and pinpoints the location so you can alter your technique. It's really cool and the riders who have tried it got a lot of benefit out of it!
And alex-91 - cool to see the new upgrades! Love following this progress
I come from motorcycle motorsport were we are plenty of data and sensor but everything is not 100% understandable just from data yet, cause 2 wheels vehicles are unstable for theri own nature and rider is affecting a lot the dynamic behavior of the bike .
So coming from what i saw, one of the most important thing on a 2 wheels is Center of gravity position, and i am not completely sure that the static sag is always representative of the dynamic behavior on the trail with suspension with such an high travel. This was my first doubt when I move to 170 mm fork and everything starts from there.
Also damping is not just a matter of dampening the bumps (even if on an off road vehicle is one of the most important factor) but also how fast/slow the bike behave to your inputs.
A lot of people just plays with clicks and pressure, but i do not find this method scientific, whitout check how much this will affect the dynamic behavior of the bike on the trail, that's why i think we neeed logging systems even if are not the bible to adjust the setting of a bike. Off road mtb suspension is basically an unknow world, but until you don't start to get some number is impossible to get a direction.
I've got a few different arduino boards to try including an Adafruit Feather with CAN capability, but it also has a small amount of built in flash and is supposed to be good for logging at quite high sample rates. Looking forward to testing it out!
Also,
"For a simple example of how I use it, with suspension data I mostly look at a position histogram that shows how much time you spend in each part of the travel. These are very straightforward to look at - if the graph is quite "flat" and shifted towards the end of the travel then things are too soft and unstable because the bike is wallowing around a range of travel instead of maintaining a particular height. If its a tall, sharp peak close to the top of the stroke then its too stiff. I regularly see people who think the suspension is too harsh but the histogram shows they are spending a lot of time deep in the travel. The instinctive response without data would have been to soften the bike but bump up the pressure and it not only feels better but they actually have more travel available and are still reaching the end when they need it!"
I think it was Darren from Push that said in the Inside Line podcast that the go-to solution to a too harsh suspension setup is to make it stiffer. People often spend a lot of time in deeper in the travel, where the (modern, progressive) systems and (air) springs are effectively much stiffer, so that's why a too soft setting gives a harsh feeling. Making it actually stiffer throws you up higher into the travel, where the stiffness is actually lower.
As for the histogram, what are you looking for? Sort of a histogram centered roughly around the sag point or something similar to that?
This is a quick example from the last ride I did - run #3 was on a 550 spring and run #4 a 600
The peaks are at roughly 28% and 30% wheel travel but the firmer spring cuts off more suddenly with almost no samples after 110mm stroke but the softer spring reaches 130mm.
Stiffer spring is also at full extension more, which can indicate less grip (but also more air time) but would need further inspection to decide that
150mm travel bike, same trail at relatively cruisy pace
Alamor 22Mm 7/8Inch A 2 Pulsanti Array for 6,95€
I end up with binary file (to speed up he logging) then i just convert the file in a formatted dat file for i2m software.
About CAN capability depend on which sensor you run, or if you have analog to can converter that is another step. For "cheap" application like this i think it starts to be too complicated. Worth then to buy a compelte kit from Aim that is really reliable.
I updgrade the connectors to waterproof (jst jpwf) that a real pain to crimp, but i was able to manage a nice work. Now the wiring loom can be used with both linear potentiometer and lidar sensor. Long linear potentiometer is coming from china for 45$... let’s see how long it survive. My idea is to check measurement with both sensor (analog and digital) to have a double check.
I also buy a lipo rachargable battery and clean a little bit the overall harness. Almost ready for the summer, hopefully i will do a proper case soon.
Post a reply to: DIY mtb telemetry system