Accessibility Widget: On | Off

DIY mtb telemetry system

Create New Tag

3/12/2021 5:45 AM

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

Photo

and it weigth much less than a proper potentiometer

Photo
Photo

Rear sensor attached directly to the shock and pointing to the frame

Photo

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:

Photo
Here some example of logged data and analysis
Photo

Damping analysis closing rebound of rear shock
Photo
Balance analysis front and rear
Photo

|

3/12/2021 7:23 AM

that's awesome! homepaging.

|

3/12/2021 8:23 AM

How much does it cost and where do I signup for a test unit? smile

I can do DIY if needed given a specsheet too.

|

3/12/2021 8:35 AM

So freaking cool!!

|

3/12/2021 9:20 AM

Primoz wrote:

How much does it cost and where do I signup for a test unit? smile

I can do DIY if needed given a specsheet too.

+1 i'd love to build something like this.

|

3/12/2021 10:29 AM

Primoz wrote:

How much does it cost and where do I signup for a test unit? smile

I can do DIY if needed given a specsheet too.

groghunter wrote:

+1 i'd love to build something like this.

Cost is difficult to quantify. Single components are quite cheap. It is based on Arduino board that's around 20 $, sensors and additional boards for logging around 40-50 dollars.
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.

|

3/12/2021 10:36 AM
Edited Date/Time: 3/12/2021 10:39 AM

alek-91 wrote:

Cost is difficult to quantify. Single components are quite cheap. It is based on Arduino board that's around 20 $, sensors and additional boards for logging around 40-50 dollars.
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.

interesting, i'd suspected it was a raspi.


I'd be more interested in a BoM and a github link to the code with a setup guide.

|

3/12/2021 11:08 AM

Nice little project 👍 did you look into break sensors to see when your pulling the breaks too?

|

3/12/2021 11:22 AM

Looks slick! What is the sampling rate of the lidar?
Do you have a link the sensor?

|

3/12/2021 11:47 AM

groghunter wrote:

+1 i'd love to build something like this.

alek-91 wrote:

Cost is difficult to quantify. Single components are quite cheap. It is based on Arduino board that's around 20 $, sensors and additional boards for logging around 40-50 dollars.
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.

groghunter wrote:

interesting, i'd suspected it was a raspi.


I'd be more interested in a BoM and a github link to the code with a setup guide.

Yeah, if that was available to DIY it, I'm game too. And I'd be happy to test things out and stuff if you need it. If you'd want to be reimbursed for any parts of it it would also be more than fair.

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?

|

3/12/2021 12:12 PM
Edited Date/Time: 3/12/2021 12:14 PM

groghunter wrote:

+1 i'd love to build something like this.

alek-91 wrote:

Cost is difficult to quantify. Single components are quite cheap. It is based on Arduino board that's around 20 $, sensors and additional boards for logging around 40-50 dollars.
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.

groghunter wrote:

interesting, i'd suspected it was a raspi.


I'd be more interested in a BoM and a github link to the code with a setup guide.

I did not put the code on github yet cause basically i modified the example low latency logger from this library:
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.

|

3/12/2021 12:18 PM

alek-91 wrote:

Cost is difficult to quantify. Single components are quite cheap. It is based on Arduino board that's around 20 $, sensors and additional boards for logging around 40-50 dollars.
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.

groghunter wrote:

interesting, i'd suspected it was a raspi.


I'd be more interested in a BoM and a github link to the code with a setup guide.

Primoz wrote:

Yeah, if that was available to DIY it, I'm game too. And I'd be happy to test things out and stuff if you need it. If you'd want to be reimbursed for any parts of it it would also be more than fair.

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?

You’re right the lidar need a target. I tested with std linear potentiometer against the sensor i used and for the precision i need i think is more than enough, pointing directly on front fender and on the frame for the rear. Obviously if you want 0.1 mm precision this is not the case but the cost increase exponentially.

Routing the cable in another way is for sure something possible, i need to modify sligthly the support.

|

3/12/2021 1:09 PM

Very cool. Great work!

|

3/12/2021 1:24 PM

Man, when I think DIY, I think "bike rack made of ABS plastic," or "rubber chicken trail bell," not "homemade electronic suspension analysis tool."



Just in case any of you don't know my reference to the rubber chicken, it's a must-see:

|

3/12/2021 2:52 PM

alek-91 wrote:

You’re right the lidar need a target. I tested with std linear potentiometer against the sensor i used and for the precision i need i think is more than enough, pointing directly on front fender and on the frame for the rear. Obviously if you want 0.1 mm precision this is not the case but the cost increase exponentially.

Routing the cable in another way is for sure something possible, i need to modify sligthly the support.

Even 1 mm of accuracy is probably enough, it's ~0,75 % of an average fork travel and ~2 % of the shock travel. I'm not sure about the sampling rate, don't really know what the shaft speeds are, so it might make sense to raise the sampling rate just to be sure?

|

3/12/2021 3:16 PM

Very cool, you've done a nice job of making a tidy system there! Bravo

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!

|

3/12/2021 3:33 PM

Primoz wrote:

Even 1 mm of accuracy is probably enough, it's ~0,75 % of an average fork travel and ~2 % of the shock travel. I'm not sure about the sampling rate, don't really know what the shaft speeds are, so it might make sense to raise the sampling rate just to be sure?

I think Jordi actually mentioned what typical shaft speeds are for MTB in one of the dialed vids, i know i've heard some figures somewhere. From what a remember, they are surprisingly different from moto or trucks.

|

3/12/2021 6:37 PM
Edited Date/Time: 3/12/2021 6:38 PM

Speeds and sampling rate info from motion instruments pb comment
“ 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. ”

|

3/13/2021 12:42 AM

So wait, they poll the sensor at 6 kHz to write the data at 100 Hz? Is some kind of smoothing going on before writing the data then or something similar?

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!

|

3/13/2021 3:38 AM

Scales are missing in the damping plot, i realize now that png shot delete white scales. Anyway they are different between front and rear, speed ratio is affecting a lot the speed you see on the shock. I will take the shot with scales

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 🤷

|

3/13/2021 3:58 PM

Super cool idea! That's so awesome! Would it ever be possible to sense the shape of the ground ahead with LIDAR?

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.

|

3/14/2021 3:02 AM
Edited Date/Time: 3/14/2021 3:02 AM

It is a bit crazy. I mean of course you have a point here. But this is something that is happening in autonomous cars and we have only in the past few years gotten hardware that is small enough to compute the data and do something with it. Granted, in this case you don't need to compute the data, just save it, but still, it's tons of data.

Do you want to run a computer and a spinning LIDAR unit on your bike? smile

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.

|

3/14/2021 1:12 PM

Primoz wrote:

So wait, they poll the sensor at 6 kHz to write the data at 100 Hz? Is some kind of smoothing going on before writing the data then or something similar?

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!

He means that they are measuring at the shock but it is converted to 8m/s at the wheel, so the sensor isn't actually measuring 8m/s. Wheel rates are typically a little faster in compression at the rear wheel and slower on rebound

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.

|

3/15/2021 12:20 AM

Great job!

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 wink

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.

|

3/15/2021 1:32 AM

nollak wrote:

Great job!

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 wink

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.

Right now i am getting the data directly from SD, dismounting it physically. I am actually tryng to use the new arduino base on nrf52 processor, i am able to connect and dump data to the phone, but then I stuck there. Would be nice to get some advice from someone more expert!

|

3/15/2021 1:37 AM

Primoz wrote:

So wait, they poll the sensor at 6 kHz to write the data at 100 Hz? Is some kind of smoothing going on before writing the data then or something similar?

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!

TheSuspensionLabNZ wrote:

He means that they are measuring at the shock but it is converted to 8m/s at the wheel, so the sensor isn't actually measuring 8m/s. Wheel rates are typically a little faster in compression at the rear wheel and slower on rebound

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.

Main problem for me is on the memory side of the arduino. More i increase the frequency more memory to store data coming from sensor and then write to sd I need.
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.

|

3/15/2021 2:22 AM

alek-91 wrote:

Right now i am getting the data directly from SD, dismounting it physically. I am actually tryng to use the new arduino base on nrf52 processor, i am able to connect and dump data to the phone, but then I stuck there. Would be nice to get some advice from someone more expert!

Ah there is an arduino with nrf52 processor? Need to have a look into those. Although I am not a big fan of the Arduino platform, but thats mainly due to the fact that I am used to working with other development environment with debuggers and deep insight into the processor so Arduino sometimes seems like a toy to me.

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.

|

3/15/2021 8:44 AM

alek-91 wrote:

Scales are missing in the damping plot, i realize now that png shot delete white scales. Anyway they are different between front and rear, speed ratio is affecting a lot the speed you see on the shock. I will take the shot with scales

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 🤷

Motion Instruments is heavily constrained by their use of BLE. Transfer rates for BLE are actually quite low and would require them to heavily drop the average sample rate. I suspect they are probably using an algorithm like this:

https://observablehq.com/@chnn/running-ramer-douglas-peucker-on-typed-arrays
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.


|

3/15/2021 11:53 AM

synDev wrote:

Motion Instruments is heavily constrained by their use of BLE. Transfer rates for BLE are actually quite low and would require them to heavily drop the average sample rate. I suspect they are probably using an algorithm like this:

https://observablehq.com/@chnn/running-ramer-douglas-peucker-on-typed-arrays
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.


Is Motion Instruments really feeding the live data to the phone while riding? I mean a small SD card or something isn't too expensive and could be easily integrated to a setup. Offloading the data after a ride should be ok. One could even use some smoothing algorithms or drop unnecessary data while the transfer to the phone is starting. There are several options for stuff like that.
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.

|

3/15/2021 1:44 PM

TheSuspensionLabNZ wrote:

He means that they are measuring at the shock but it is converted to 8m/s at the wheel, so the sensor isn't actually measuring 8m/s. Wheel rates are typically a little faster in compression at the rear wheel and slower on rebound

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.

That makes much more sense, that the 8 m/s is for the wheel rate.

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.

|