My bike has a Garmin Edge 500 GPS and the standard Garmin GSC-10 cadence sensor for pedal cadence and wheel speed. The maximum sample frequency is every second. This is not, of course, enough to get properly accurate data (sampling frequency theory etc) but it'll have to do.

The Garmin produces a .FIT file which is binary and cannot be read directly, so you need to use something to convert it. Garmin have their desktop Garmin Training Center software which exports to both .TCX and .GPX, or you could use their connect.garmin.com web application. Both TCX and GPX are xml-a-like so a regular text editor can read them.

If you do use the Garmin software or their web site to convert the .FIT file, then one problem is that the xml like structure is not very human friendly so you need to convert to something like CSV.

The next problem is that for some reason the TCX / GPX and thus the CSV does not have speed data in it. After looking around, I found Ascent which runs OK on my OSX 10.8.5 laptop. It imports the .FIT directly, and exports nicely directly to CSV, with speed.

Next problem: Ascent outputs speed (yippee!) but to only one decimal point of accuracy, in either mph or kph, and thats not enough. I was pretty sure the Garmin records metres / second in the .FIT file, which would be a much better bet.

After some more looking around, I found the Garmin online fit repair tool web site. You upload a .FIT and get the raw data as .CSV. Speed is in metres per second to 3 decimal places, and no intermediate step - great, now I'm making progress! (Note yes I know GPS is not accurate enough to really use 3dp, but when the Garmin uses the GSC-10 it takes speed from the wheel / spoke sensor, which is a lot more accurate - more later).

Next step is to upload the CSV file into Google Drive and convert to native format.

After uploading, you scroll up and down and you notice some lines with what looks like bogus data on them. I presume that the converter web site is not interpreting the file completely correctly. Cleaning it up manually was OK, but a 4 or 5 hour ride which would have potentially 20,000 data lines in it, would be very tedious. Here however I was using a 50 minute commute file, so only 3000 or so lines.

Since I have speed in m/s, and cadence in rpm I'm nearly there.

Lets start some maths! Some definitions:

F (chainwheel) - teeth

R (cassette) - teeth

C (cadence) - rpm and Hz

S (road speed) - m/s and kph

W (wheel) circumference - metres

F = 52 for me, and I almost never come off the big ring :-)

R is what we want to calculate

C we have

S we have

W = 2.104m for my 700c with 25mm tyres (NB the book number is 2.105 however the Edge 500 had calibrated to 2.104 which is OK for me)

The basic formula we need is:

F/R * C * W = S in m/s

or

F * C * W / S = Rear teeth

since F and W are fixed we can turn them into a constant

ie 52 * 2.104 = 109.408

so to calculate teeth

109.408 * cadence (Hz) / speed (m/s)

So all you need to do is add a column in Google spreadsheet to do the calculation for you.

The first time I did this, I got two problems:

- When approaching a junction I often soft pedal to change gear, this means that when I'm doing this, the ratios don't work. To fix this I decided that if the cadence was less than 40 rpm then I would zero it. The formula I used is:

=IF(cadence<40,0,cadence/60)

this both zeroes for less than 40 rpm and converts into per second ie Hz

- If the speed is zero then you get divide by zero errors, so when calculating teeth I also used a conditional:

=IF(speed>0,102.408*cadence/speed,0)

so this means either I get the number of teeth or I get zero, which is when either I'm not pedalling and / or stationary.

So what do I get? Well here's the first chart: sprocket vs frequency of use.

If this commute ride is representative of my rides generally, it shows that I just don't use the 12, and hardly use the 13. My current presumption is that the very low values for 16, 18, 20, 22, 23 which the cassette doesn't have (its a 105 11-28 with 11-12-13-14-15-17-19-21-24-28) suggest that this method has statistical validity.

Above 24 we're into noise. My guess is that on the big end of the cassette I'm going so slowly that sampling frequency of speed on the wheel becomes an issue. Remember we only get 1 sample recorded per second, and at say 1 m/s which is 3.6 kph the wheel is only going round at 1/2 Hz or so. If you were to take a minimum speed of 2.2 times the sample frequency that would equal about 4.5 m/s or about 15 kph or 9 mph or so.

Then I can do speed vs cassette teeth. You can see how the results are clustered around what my cassette offers.

If I get chance I might try this with data from a longer ride.

## 1 comment:

you might have better results using some hall effect sensors on the front sprocket and rear wheels and counting the number of pulses.

here's how trigger wheels and hall sensors are used in a car engine:

http://people.physics.anu.edu.au/~amh110/Hall_sensor/hall_sensor_trigger.htm

here's a project with an arduino:

http://www.windandwet.com/software/datalogger/wind.php

Post a Comment