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
For others softwares this can be much more difficult cause they can ahve their own encoding of the file or a given strucutre to import it. Which software are you using?
If you could give some insight with how you formatted the file to play nice with Danas that would be incredibly helpful, still figuring things out for the first time as this is my first proper project and thought this was a cool idea to try implement on my own bike.
% INSERT CHANNELS PARAMETERS
simfile = 'data_20210712_16_30_47.dat';
an1_min = 0; an1_max = 1023;
an2_min = 0; an2_max = 1023;
an3_min = 0; an3_max = 1023;
an4_min = 0; an4_max = 1023;
an5_min = 0; an5_max = 1023;
an6_min = 0; an6_max = 1023;
an7_min = 0; an7_max = 1023;
an8_min = 0; an8_max = 1023;
fwh_circ = 1951; z_spkFF = 16; z_spkFR = 45; rwh_circ = 1980;
z_spkRF = 1; z_spkRR = 1;
gear1 = 26.6; gear2 = 32; gear3 = 40; gear4 = 53.3; gear5 = 80; gear6 = 160;
fid=fopen(simfile,'w');
fprintf(fid,'$NEW SESSION\n'); fprintf(fid,sprintf('$SETTINGS,xSuspR,%1.3f,%1.3f,xSuspF,%1.3f,%1.3f,vSuspF,%1.3f,%1.3f,vSuspR,%1.3f,%1.3f,... ANALOG4,%1.3f,%1.3f,ANALOG5,%1.3f,%1.3f,ANALOG6,%1.3f,%1.3f,ANALOG7,%1.3f,%1.3f,%1.0f,%1.0f,%1.0f, %1.0f,%1.0f,%1.0f,%1.3f,%1.3f,%1.3f,%1.3f,%1.3f,%1.3f,%1.0f\n' ,... an1_min,an1_max,an2_min,an2_max,an3_min,an3_max,an4_min,an4_max,an5_min,an5_max,an6_min,an6_max,an7_min,an7_max,an8_min,an8_max,fwh_circ,z_spkFF,z_spkFR,rwh_circ,z_spkRF,z_spkRR,gear1,gear2,gear3,gear4,gear5,gear6,22));
fprintf(fid,'$DATE,0708114\n');
fprintf(fid,'$SESSION_COLOR,142159034\n');
y_new1 = zeros(1,length(xSuspF)); y_new2 = zeros(1,length(xSuspF)); xSuspR = zeros(1,length(xSuspF));
%GPS WRITING
for j = 1:length(time_1hz) fprintf(fid,sprintf('$GPS,%1.0f,A,%1.4f,N,%1.4f,W,%1.2f,%1.2f,\n',time_1hz(j)*100+4752312,LatLon(j,2)*100,...
LatLon(j,1)*100,Velocity(j),counter(j)));
end
%SUSPENSION WRITING
for i=1:length(xSuspF); fprintf(fid,sprintf('$VALUE,%1.0f,%1.0f,%1.0f,%1.0f,%1.0f,%1.0f,%1.1f,%1.1f,%1.1f,%1.1f,%1.1f,%1.1f,%1.1f,%1.1f\n' ,... times(i)*100+4752312,xSuspF(i),xSuspR(i),xSuspR(i),xSuspR(i),xSuspR(i),xSuspF(i),... xSuspF(i),xSuspR(i),xSuspF(i),xSuspR(i),xSuspF(i),xSuspR(i),xSuspF(i))); end for y = 1:length(RI) fprintf(fid,sprintf('$IR,%1.0f,\n',Time(RI(y))*100+4752312));
end
fclose(fid);
All the challenges highlighted on this thread are the ones which have tripped me up on the way, achieving the data rate, synchronisation of the 3 clocks and then converting the acceleration data into velocity and displacement to a reasonable level of accuracy (I managed to achieve a maximum calculation error of 0.075% displacement for a unit). I have recently got to the point where I am ready to start logging real riding and analysing the data. I have also just had a baby, so the project has been on the back burner, but this thread has given me some ideas and a renewed desire to move it forward!
Alek - If there is anything in the above description which sounds like it could be useful for you, reach out and I can share some code or details of hardware.
Can you share some more information? At least which hardware it is based upon?
It's true that differentiation accumulates the errors (deriving the velocities and accelerations from travel will make the results even more wrong than integrating them from acceleration), but the main issue is, like I mentioned, that we are interested in the travel at the end of the day. So you are going from directly measuring it (with a linear pot or something similar) to integrating it from the acceleration. Besides the synchronisation issues you mentioned.
I think it's not a coincidence all the commercial systems use a linear travel sensor.
My 2 cents of course. Could your platform be adapted to read a linear sensor as well?
It could use a displacement sensor, and the wireless data acquisition/synchronisation parts of the code/hardware would be useful for that. But for the time being I will probably stick with accelerometers and maybe use a displacement sensor for verification.
Sorry to not answer for very long time, but i was not hecking this post anymore. I am using the device time to time with the bicycle and also with the motorbike, but unfortunately with the second one is much less reliable due to vibration problems.
I am very interested in you logging with the phone, in particular how you communicate / store the data from accelerometer to the phone, cause i had several problem with bluetooth communication (mainly cause i am not so good in writing the app for the phone).
Feel free to write me a private message so we can exchange some mails.
Hey Folks,
I too have begun working on a version of this project. I went with a Sparkfun Openlog Artemis as a brain. This has the benefit of coming with some open-source logging firmware out of the box. I'd like to move towards something like the nrf52840 eventually, to take advantage of Bluetooth functionality as alek-91 mentioned. So far, I'm using two ICM20948 IMUs and two VL53L1X Lidar sensors.
I haven't gotten a GPS wired in yet, but looking to do that next. I'm looking to add steering angle and bike pose to the mix, alongside suspension.
Here are a few of my datalogs:
So far I've just viewed and edited my logs in excel, but I'm very interested to try the Danas software.
@alek-91, do you happen to have any files in the format Danas needs? I'd like to take a look and see if I can convert my data.
Thanks!
Devin
Great job reviving the thread. Onwards!
Next one trying to revive this thread.
I still need to build holdes to attach the potentiometers to the bike but that should be done during the next couple of days.
Currently only reading the potentiometer data and GPS.
Everything is running on a RasPi Pico with uSD card adapter and ublox GPS module.
Currently working on downloading the data via wifi.
Hey Devin, in the post where there is the amtlab script you basically have all the info to convert to final file. You just need to save everyting in .dat file. If you want to have an example file you can download form i2m website.
I need to say that now there are a lot of user friendly webapp or customable dashboard to look at the data than a specific software is not needed anymore. Take a look at tableau or powerbi. You can use the free version for personal use.
I am working less on this project. My objective is to run everything wireless with bluetooth but require much more time (and money) than before, so everything is proceeding slowly
Nice to see someone that is working on the same stuff... Sharing information is always useful. If you arrange how to download data via Wifi it will eb awesome cause than you can customize a proper app on the phone.
Yeah, currently I am running into problems with Wifi. After the SDK update the initialization of the Wifi Chip on the RPi Pico seems to crash. Don't know why but I think there will be a fix for this.
Although the progess will slow down as I started a new job at the beginning of march and currently there are a lot of different things I need to get my head around.
Source Code and documentation can be found here if anybody is interested.
https://github.com/n0ll4k/bahama-mama-telemetry
Ideas/Critic/etc. is highly appreciated.
https://wiki.aalto.fi/display/MEX/DIY+suspension+wizard+-+mountain+bike…
I found out also this project on the web .
This guy has a working system, posting here for wider exposure: https://www.mtbr.com/threads/sufni-suspensiont-telemetry-an-open-source…
Yeah that is a pretty complete system.
Found that guys repo on Github while doing some research and starting my project.
Mine is unfortunately a bit delayed as I started a new job and have been quite busy. I tried measuring some data on the weekend but ran into issues with my front sensor.
Yeah that system is super tidy! I came across that last year sometime and hes made some nice progress since then. I really like the dashboard layout he's used - its nice and clean with stacks of info available at a glance without getting messy. The rotary encoders are a great idea - especially at the back end, but also a novel way to do the fork. Linear pots are at the wrong end of the price vs durability scale so its cool to see some alternatives being tested
Hi, i was inspired by your project and made my own (only fork) suspension analyzer. I think using a rotary encoder is the best way to make this a low-cost project.
So far I have only checked that the hardware I prototyped works and it does. In the future, the software part will have to be developed better.
Anyway, I leave here some photos and a link to a blog-like (no advertising) where I have documented the project.
It is: luigicennini.it/en/projects/fork-telemetry/ (sorry it does't me let post proper link)
There is also an italian version (as i see op of this thread is italian) : luigicennini.it/it/progetti/fork-telemetry/
Hi All!
For the past year or so, i have also been working on my own MTB telemetry system, very similar to alek-91's idea. I had incorporated the VL53L4CD sensor onto a PCB, which also contains a BLE module and PIC to act as the "master" microcontroller. The PCB design was pretty interesting, trying to fit as much (and minimal) components as possible onto the board. I've currently had some assistance with developing a mobile application to view, download and analyse the data, so feel i'm not quite there in terms of analysing the results, but its been interesting so far i have to say! The distance sensor can sample every 10ms (so 100Hz) however the bottle neck at the moment is the BLE transmission, where i can only achieve around 60ms transmission time, so may have to think of some inventive way of maximising throughput to the phone, but not compromising on sampling rate! Its powered from a single NiMH battery and fits inside the fork steerer tube using my own 3D printed housing. More updates to follow soon (hopefully)!
Just aside from my post, i think its great that so many people are doing a project like this. Anything that already exists seems to be unattainable in terms of cost or complexity, so its great that so many of us are looking at cheaper ways of getting that data!
Dan
Thats super cool, I like the idea of wireless sensors - how have you found the precision of the measurements from it? as for sample rate, have you looked at buffering the data in packets to cut down on transmit time?
re: accelerometers - these can be super powerful and useful on their own if you are looking at things like transmissiblity, vibration at the handlebar and contact patch load variation. That way you don't have to rely on infering the position accurately and gives you come really good insights that a linear sensor can't measure! The maths is a little more involved, and may not give perfect damper postion or speed but IMO if you don't also have a damper dyno then things like damper speed aren't going to be that meaningful. being able to measure the actual wheel movement & acceleration is technically more relevant to the goal of keeping them stuck to the ground properly. Measuring suspension position is useful for sure and 100% worthwhile but its really only a point in between the parts you actually care about - the contact points with the ground and the rider. Just don't discount accelerometers which are super cheap and easy to work with!
Hey TheSuspensionLabNZ,
The min resolution is 1mm, I haven't actually delved much into whether this can be improved or not. You've hit the nail on the head regarding throughput. I just need to package 6 or so measurements worth of distance data into a BLE frame and then I'll effectively clawback the 10ms sampling rate that the sensor can normally do.
It's interesting to hear your comments on the accelerometers, hadn't actually appreciated that using an accelerometer is probably a much more efficient/easier way of retrieving acceleration data as opposed to doing a double derivative of the displacement data. I guess there can be issues with taking derivatives of discrete data, and the results won't necessarily be a true representation of what's actually happening?
Dan
@happymeal Taking derivatives generally amplifies any noise in the signal. There are various methods to reduce this but they may not work well at high frequencies.
Numerical integrals on the other hand generally stabilise the signal BUT they accumulate errors over time (drift). This is why devices that need to do dead-reckoning rely on correlating different types of sensors over time to reduce overall error (generally GPS is used to correct larger drifts while the accelerometers/gyros are used for real-time positioning). For bike logging this means trying to determine axle position from accelerometers would be unreliable.
The other advantage of accelerometers or hybrid accelerometer/gyro units is that you get multi-axis results.
Hi Dan,
I was also using a wireless system for measuring suspension acceleration, if you change from BLE to Bluetooth classic then you should be able to increase your throughput. I was able to record data at 850Hz using this method to an Android Phone, I did need to mess around with data packets and the Bluetooth library buffer sizes, but it is doable.
As for converting between displacement to acceleration or vice versa, I was converting from acceleration to displacement. To do this I needed to use a mix of numerical integration and Omega arithmetic. A lot of the work needs to be done in the frequency domain so the strengths and weaknesses of each method could be leveraged. The final result was pretty good, I have written a paper on it, if I manage to get it published I will share it here.
The other challenge I had, which you might encounter, is synchronisation. I was using 2 off accelerometers on 2 separate micro controllers, and a phone and all clocks needed to be syced with each other to the millisecond. If you end up recording displacement and acceleration together, just make sure they run off the same clock.
Good luck with the project!
Cool, this would have been the natural step for my project as well. Unfortunately I face against similar problem with BLE transmission and smartphone logging.
I actually also realize that laser sensing is quite nice in terms of weight and easiness to work with, but not really usable in real mtb/motorcycle application due to the dirt that is accumulating on the sensor itself.
I am figuring out a different way to log the systems using magnetic sensors. A really nice application is the one from motloklik where they are using a linear encoder on the outer tube and a simple magnetic sensor on the moving part. In bicycle application is slightly more difficult cause you don't have upside down fork but still manageable.
I like the idea of embedded sensors - encoders would be super sweet, and the other thing I wondered about are softpots like this -
https://www.digikey.co.nz/en/product-highlight/s/spectra-symbol/softpot-potentiometers
These are what motion instruments use in their "expert" fork sensors and super rugged, low profile and cheap. Could be a way to tuck them inside a fork?
Hi everyone
I have found this thread as I am thinking about making a telemetry system for my downhill bike for my year 12 project and I have read through this thread and wanting to use a (Linear position travel sensor with eye rodT-PTS12) for my front and rear sensors I was just wondering what people recommend for like a circuit parts you guys are using. As I am new to circuits and not sure what parts would work be for this type of system.
Any opinions are appreciated, Thanks
Post a reply to: DIY mtb telemetry system