Posts
45
Joined
3/12/2021
Location
IT
Edited Date/Time
8/5/2022 3:42am
Hi guys,
Covid lockdown period in Europe was tough so I started my own project for a supension diy data logger, and after some fails i got an acceptable result
I am using micro LiDar sensor for both front and rear suspension. Front sensor is integrated into the stem
and it weigth much less than a proper potentiometer
Rear sensor attached directly to the shock and pointing to the frame
I am running with very raw case and cabling by now to test on the bike behavior but i am quite happy with the results:
Here some example of logged data and analysis
Damping analysis closing rebound of rear shock
Balance analysis front and rear
Covid lockdown period in Europe was tough so I started my own project for a supension diy data logger, and after some fails i got an acceptable result
I am using micro LiDar sensor for both front and rear suspension. Front sensor is integrated into the stem
and it weigth much less than a proper potentiometer
Rear sensor attached directly to the shock and pointing to the frame
I am running with very raw case and cabling by now to test on the bike behavior but i am quite happy with the results:
Here some example of logged data and analysis
Damping analysis closing rebound of rear shock
Balance analysis front and rear
I can do DIY if needed given a specsheet too.
I use a SD shield with clock time that you can buy from eBay.
The cost of programming, assembling and designing support and also all the fails is difficult to say 😂
My idea is to try to standardize as much as possible everything and make an open source board already programmed for doing basic stuff, but customizable by everyone who is buying like many other boards for other application (speeduino, fuelino etc), but still long way to go.
About software and analysis I am using an open source from i2m (motorsports company) so everyone can use it to check the data.
I tried to make an app too, but it's far away from my IT capacity by now.
I'd be more interested in a BoM and a github link to the code with a setup guide.
Do you have a link the sensor?
The lidar just needs a reliable target I guess? It could probably be mounted to the reservoir with the target mounted around the shaft eyelet area for the lidar to point to? And some changes could probably be also made to the fork part to avoid routing the wires through the steerer tube?
https://github.com/greiman/SdFat
I used those sensors from st electronics
https://www.st.com/resource/en/datasheet/vl53l0x.pdf
Max frequency depends also in how to assemble the sensor on you board and you use it. I am running at 100hz but probably with some expedient you can run slightly faster.
Routing the cable in another way is for sure something possible, i need to modify sligthly the support.
Just in case any of you don't know my reference to the rubber chicken, it's a must-see:
https://www.youtube.com/watch?v=K4N-1x0_-n0
I've been curious about using non-contact sensors for suspension movement so I'm interested in the Lidar sensors. Will have to give them a try myself!
“ We have 1000 Hz sampling working as a debug feature. We thought we needed higher sampling rate early on but it turns out our sampling algorithm was not great. A crapload of dyno testing later, we got 200 Hz working the way it should and it was very accurate. We even had a well respected bike company do some extended dyno testing for a 1 hour run to see how far our signals would drift apart between 2 sensors measuring the same up.down movement. We were only off 40 uSec (micro seconds) in an hour. Our accuracy was as accurate as the position sensors we use. I've seen DH rear wheel speeds up to 8 m/s, but that is measuring the shock which is ~1/3 the speed of the axle. Forks on DH are between 5500 - 7500 mm/s. 200 Hz is fine. To get a nice 200 Hz signal, we sample over 6K Hz. For the 1000, >30K samples/sec. ”
In any case, still nice to see the numbers. It is a bit weird though that the fork rates and shock rates are similar on the damper side, making them differ on the wheel rate by a factor of 3!
About comment to log at 6khz to have a 200hz signal sound strange to me... i really don’t like buttering and filtering when i cannot see what they are really doing. 100 Hz I think are more than enough, i will not optimize 800 mm/s damping area with the shock i have so even if i miss that spot 🤷
Maybe it would be difficult to 'see' exactly what path the tire is taking, but wouldn't it be sweet to have data of the ground as well as the suspension movement? Every telemetry systems seems to track just suspension movement, which obviously is way more measurable, and challenging on its own! But feels like performance would be more objective with data of the terrain. Maybe, I dunno - just a crazy question.
Do you want to run a computer and a spinning LIDAR unit on your bike?
It's much easier, strap a gopro to your head, chest or bike, calibrate it (start recording and do two or three pumps on your bike on flat or something similar), so you know where in the suspension traces and in the video time you are, then just ride. If there's a weird phenomenon in your data, check the video.
Motion IQ write the data at 200Hz to save on storage space and less computing power needed from the phone to process results. A 1000Hz signal balloons too huge file size pretty quickly! There might be other factors but that is the main one
100Hz will give a general representation of whats going on but recommendations for sampling rates say to use a rate at least 10x the frequency of your input signal in time domain analysis. Extreme cases on mtb's reach at least 20Hz so the minimum for an accurate representation is 200Hz.
I like the approach with the lidar sensors. I was always thinking about doing something similar with a combination of gyrosscopes and accelerometers.
But I am way to lazy when it comes to such projects as the firmware programming is my day job
I think this application the 100Hz should be enough as you don't want to measure how the fork/shock is working in detail only see how far they are moving.
Out of interest are you saving the data directly to SD card and then use that on a laptop or are you using any RF chips for transmission?
The project could be interesting with a nrf52 based chip and encapsulate it for both front and rear. Synchronization could get an issue but it would result in two small and sleek units.
You can hit me up if you want any information on the nrf52 stuff. I have worked with those for several years now.
With more time and more coding expertize probably you can reach 200 Hz ... I will try to improve my code and the board itself.
Yesterday I had couple of running on my local trails, the system did not had big issue. Still room to improve cabling and vibration sensitivity. I will show you results as soon I process it.
Unfortunately I am firmware only developer so I got no expertise in getting those off the phone.
Starting point for me would be the nrf BLE UART for sending data to the phone and then somehow log those on the phone directly and get them via some cloud service to a computer. Should be possible with the nrf app for smartphones.
Otherwise how good is your C Programming? Perhaps this is worth porting to real C/C++ and using the Nordic dev environtment. I think there are also some small footprint boards available from china which could be used as a base, perhaps with just a small LiPo as power source.
This would at least be a pretty interesting project. Personally I would also add some kind of acceleration sensor as this could be interesting data wise in combination with the travel.
You can hit me up via a message if you have any further questions. Perhaps I can help you out or contribute something.
https://observablehq.com/@chnn/running-ramer-douglas-peucker-on-typed-a…
https://karthaus.nl/rdp/
Which gives unevenly spaced data but with minimal lost of curve shape (information). On the app side they are likely interpolating back up to a slightly higher frequency and evenly spaced data to get nice numerical derivatives for velocity.
This is not necessarily a bad strategy though for what they are trying to do particularly with the convenience of having no separate logger device or wires. If you were developing dampers and wanted a bit more information in the higher frequencies it may not be the machine for you.
In your case to boost over 100Hz you could consider creating a buffer array with a few hundred samples, then run the algorithm on it before batch writing to the SD card (which is probably the bottleneck in your setup). I am not sure how fast the algorithm will run on an Arduino though it may be too slow. You could also look at a Teensy 3.6 or 4.1 which has an onboard SD card and can handle rates as high as 20kHz (each sample is just two analog reads). They are also in the sub $30 range.
With regards to sampling frequency one way to look at it is a 5000mm/s shaft speed with a 5000samples/second logger would maintain resolution down to 1mm in the worst case. A 1000Hz algorithm however would only get 5mm increments at the peak speeds which is enough you could miss a bottom out event and high frequency data. You can see quickly why MI landed in the 6kHz range. On the other hand 1000Hz is adequate for basic setup information. 100Hz raw sampling is probably a bit low for fork data.
@nollak Adafruit makes a nRF52 Feather module that is an Arduino clone. I don't think it would have the juice to write to an SD card at much over 500-1000Hz though while managing logging and BLE.
Questions are the data rates and I think with Bluetooth 5.x which is accessible via the newer Nordic chips there should be some possibilities.
I found those boards and I agree those with the Arduino could be a bit week for those sampling rates. Think one of those newer nrf53 chips should do the trick. One of those Teensy boards is a bit of an overkill in my opinion.
The lidar sensor itself is the limiting factor here as you can't sample that one with 1000Hz. I think even 100Hz is a bit to much for the sensor from what I saw in the datasheet (only scrolled through it in the morning).
Potentionmeters as used by Motion Instruments and others can be sampled a lot higher.
Nevertheless I think it's a really nice project and has a lot of potential as I think all those poteniometers and mounting those is not really feasible for the everday rider. Things like the Shockwiz or this one are more Plug'n'Play. For me the question is always what you want to achieve. Motion Instruments is a pretty data driven instrument which shows a lot of data. If you just want to see if you use your fork travel and see if there are optimizations possible regarding rebound and compression it should be doable with lower sampled data.
A 1000 Hz signal would mean a 5 times the file size, I'd say that is not horrible.
20 Hz means that the shortest end-to-end movements of the damper are in a 50 ms time frame (at much lower than peak shaft speeds of course)? If that is the case, probably even 100 Hz of sampling is enough (the bare minimum is double the frequency of the phenomenon you're recording). 200 Hz would probably be plenty.
As for the frequency debate and shaft speeds, if you wanted to map 1 mm movements at 8 m/s of wheel rate, you'd need 8 kHz of sampling. BUT! You don't really need to know the peak speed of the movement. The shaft speed will slow down before turning around and your stroke resolution will improve quite a lot in that range. Sure the shaft speeds would be a nice thing to know, but mostly if you're developing suspension products. But you could probably extrapolate the peak speeds from the stroke vs. time data anyways. And for the end user analysis the depth of stroke at certain events and the subsequent oscillations are what matter.
Motion instruments product is already an high end product for a sunday rider like me, that's why i decided to take a simpler and cheaper approach for my project.
I bought a brand new Lyrik ultimate and i was almost lost without any data to fit it to my riding, and i thought was a waste of money for an high end fork just to optimize by feeling
I am agree with the frequency topic, i would like to increase my sample rate but by now lidar and arduino constraints (probably not only physical but also from my code) bring to me accepts 100 Hz.
Yesterday i designed a more clean case to improve packaging. It is becoming quite small and i am really happy about it. I would like to add some control led, but i am a little bit worried about energy consumption.
and also had time on the weekend to take some more data on the trails.
Post a reply to: DIY mtb telemetry system