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
Appreciate the points you've made. I canceled my order and it was refunded by the sensor company. You're right, it doesn't make any sense with a single sensor. I just need to order the Raspberry Pi and start down that road.
Interesting post on IG from @Downamics . It’s a great visual diagram of how each part on the bike set up affects the other. It can also remind us how in the weeds we can get by making a change.
“This diagram is an overview of the scope for using DAQ as a holistic and specific analysis tool. It is not a comprehensive guide to the vehicle system or DAQ methodology.“
You can view and use the diagram here:
Downamics Framework
Anyone had any experiences with BYB using MacBook or Windows? Loading times etc
Yes, I have used BYB, with pretty fast loading times. What other info are you interested in?
So I sacrificed a string pot on the altar of science. TL;DR: So far, the results are encouraging.
I used a lathe to drive the pot via an offset crankpin, allowing me to calculate the theoretical string trajectory exactly, and the maximum velocities and accelerations at different lathe speeds. The downside of this arrangement is secondary vibration: because the string oscillates vertically, its inertia introduces an error that gets larger as the speed of rotation grows. The good news is that, because it isn’t something the pot will experience in real use and occurs at mid-stroke, I think it can be ignored: the ends of the stroke, where the accelerations are the highest, are where we expect any problems of the string overrunning the spool to occur.
RPM Peak velocity (m/s) Peak acceleration (m/s²)
530 3.78 247.6
750 5.35 495.8
1060 7.57 990.4
1500 10.71 1983.4
For reference, most of my ride files have max transient accelerations in the 200-300 m/s² range. I'm sure harder-hitting riders see higher accelerations but I think 1000 m/s² is a decent upper bound for design. That's 100g, folks.
The pot ran without any mechanical issues at the first three speeds. At 1500 RPM it failed after about 5 seconds (so even then, it got more than 100 cycles in). The mode of failure appears to have been loss of tracking of the string on the spool, possibly contributed to by wear in the grooves. I had a connecting piece of 40lb fishing line in the string which broke as intended. The string also chewed itself a new exit channel due to a minor alignment issue. In other respects the unit appears to have survived intact.
At 1000rpm the pot is tracking ideal movement pretty well - although not perfectly. The secondary vibration effects are visible in the mid stroke, along with the occasional minor bobble - cause unknown.
At 1500rpm I didn't manage to get the logger turned on before the string pot failed. But from what the string was doing, I would expect it to be ugly.
My conclusion is that this design comes pretty close to meeting the mechanical requirements. It tracks well - but not perfectly - under some very demanding test conditions - I'd expect the results to be perfectly acceptable for a fork in normal use, and better for a shock (where displacement, speed and acceleration are reduced by 2-3x). Having said that, there is scope for further reduction of both physical size and the inertia of the moving components. I have a revised version that I'll be testing shortly.
Durability is unproven at this point. The main issue I'm looking at is friction of the string at the exit point and resultant wear. I'm looking at fishing rod hardware to address this. Other longer-term issues will probably emerge.
Integration is another issue. Ideally the pot would work as a plug-in replacement for a traditional resistive linear pot. The AS5600 encoder I use does indeed have an analog output option, and can be used that way if the analog supply rail runs at a voltage that works for the AS5600, and if the logger's analog input doesn't load the AS5600 excessively. The AS5600 can also be read via a digital data bus, if your logger has one.
Because the pot is multi-turn, there is also the need to 'unwrap' the raw encoder results. Unless the analysis software happens to deal with that already (or the logger does it onboard), the results are going to look very strange. The requirement to unwrap also puts a theoretical lower limit on the sampling rate that can be used.
Various misfortunes have prevented me getting a successful side-by-side comparison to a linear pot, but that will be along soon.
There was a product called SussMyBike Flow that did something similar to this. The issue was the app sucked and eventually fell out of support, but it gave you some data ranges to work with using a similar mechanism IIRC. I have one laying around here somewhere...
You could try supporting the string near the lathe in both vertical directions to prevent these oscilations.
Yep, I'll try that for sure. There is a trade-off: as the support point gets closer, the magnitude of the secondary vibration gets larger (like short conrods in a car engine), but reduced oscillating mass ought to help. The main thing I will do is use lighter string. I have some high-tech fishing line that is 20% the weight of the stuff I'm using now so I expect that to help a lot.
few pics of the new string pot design. It ate up 1000rpm in testing and even ran at 1500 briefly. Unlike the last time however, this time the failure was friction at the string support (thanks @Primoz, worked great) causing the connecting string to break. The pot itself survived intact and tracked the theoretical path well until the failure.
That's it for bench testing. We'll see how it performs in the wild.
I was thinking about using two bearings for support to prevent friction over the in going edge. Or at least a very rounded hole entrance.
Yeah, my solution (hole in a piece of delrin) was pretty basic, it could definitely be better.
Post a reply to: Suspension Data Acquisition