There must be a word for that feeling the day after a great 400km DIY audax when you start uploading the log sections and find that one of the fit files won’t load off your garmin edge device. For the time being I’ll assume you understand the phrase knarked right off about covers it.
Once I’d tried all the available software options (Garmin Connect, Basecamp, Sporttracks, Golden Cheetah, etc) and still has no joy I decided it was time to take some drastic action. So I grabbed a copy of the FIT SDK from Ant+. This contains a tool (FitCSVTool.jar) that can break a FIT file down into a series of CSV files containg most of the information. It can also be used to recombine them into a FIT file once you’ve corrected any errors.
Once I’d got over the first problem with running the basic package (my Mac had it’s Java version in the wrong order) I started playing with the example files. The trick appears to be to carefully read the error messages when trying to recombine the file. Usually this tells you that X of Type Y is unknown at line Z. Correcting this is a case of find X of Y at Z and removing the Unknown field and then retrying the combine. This all seemed easy enough.
Except my file was so far gone it wouldn’t split down in CSV files properly so I got an error at that stage. Luckily it had created some intermediate CSV files that contained some information. Now all I had to do was convert and combine it into a workable format.
I’d told the splitter to create test.csv, and I found most of the useful information in test.csv.tmp. After about 17 rows of header information I had a row with the following fields (names in <> indicate a recorded value, those without are actual entries which appear to be identifiers:
So that all seems pretty straightforward as a list of type, value and units. So everything was looking good.
A quick bit of googling indicated that the semicircle units for latitude and longitude in the file could be converted into a decimal degree value by multiplying them by 180/(2^31).
The time was interesting. The number looked right to be an epoch value. But plugging a couple of test values into Unix’s date command returned a value 10 years out of date. So it appears that Garmin are using a different start to their epoch than everyone else (01/01/1960 00:00:00 as opposed to 01/01/1970 00:00:00). An epoch time is the number of seconds since a particular date, so to convert those values you need an app or function that can add seconds to a given date and return you another date. Unfortunately Excel on the Mac is missing VBA so doing the conversions was a bit tricky so I ended up having to do some playing around with shell scripts and the join command to build up a CSV of lat,lon,ele,date,time.
Once I’d got that I used the excellent site GPSVisualizer to convert it to a GPX and I was done.
Less impressed to find that I was still missing about 50km of route, and even worse it was just short of a control!! My local Organiser said it was worth submitting anyway, and it’s now been referred up the chain. So once again I’ve finished a cracking long ride and have no idea if I’ve completed it to AUK standards so I’ve no idea if it qualifies. On the plus side I had a great 20 hours out on the bike and managed to cope. Suprised i crawled all the way up Staxton Hill as well, 17% for a decent distance is good for me. Coming across the Humber bridge in the dark was great, and some very rural lanes across the top of Lincolnshire were great for spotting wildlife and feeling completely cut off from normality.
Enjoyed it so much that if it doesn’t validate I’ll do it again in a couple of weeks.