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
Post a reply to: DIY mtb telemetry system