On Tue, Jul 30, 2013 at 12:09 AM, Conrad Meyer <cse.cem@...> wrote:
> Hi all,
> Today my Garmin Forerunner 110 produced a .fit file that GPSBabel does not
> want to convert. I'll attach the (small) file, and I've posted it to Google
> Drive in case the list strips attachments.
Thanx for the good description. The file you provided (in both forms)
doesn't seem to actually trigger the problem you describe. Still, I've
applied a patch that should cure this.
I'm running the latest (1.4.4) gpsbabel; here's the usage and output at
> $ gpsbabel -D6 -i garmin_fit -f <attached_file.fit> -o gpx -F xxx.gpx
> GPSBabel Version: 1.4.4
> fit: header len=14
> fit: protocol version=16
> fit: profile version=135
> fit: fit_data.len=8928
> fit: starting to read data with fit_data.len=8928
> .....fit: got data message at fit_data.len=8927 ...local message type 0x2
> .....fit: got definition message at fit_data.len=8926 ...local message
> type 0xB
> fit: Definition message reserved bits not zero
That's not what I see on the file you provided:
fit: starting to read data with fit_data.len=8928
.....fit: got definition message at fit_data.len=8927 ...local message type
.......fit: definition message contains 6 records
.......fit: record 0 ID: 3 SIZE: 4 TYPE: 140 fit_data.len=8919
.......fit: record 1 ID: 4 SIZE: 4 TYPE: 134 fit_data.len=8916
.......fit: record 2 ID: 1 SIZE: 2 TYPE: 132 fit_data.len=8913
.......fit: record 3 ID: 2 SIZE: 2 TYPE: 132 fit_data.len=8910
.......fit: record 4 ID: 5 SIZE: 2 TYPE: 132 fit_data.len=8907
.......fit: record 5 ID: 0 SIZE: 1 TYPE: 0 fit_data.len=8904
.....fit: got data message at fit_data.len=8903 ...local message type 0x0
......fit: parsing fit data ID 0 with num_fields=6
Did you perhaps binary edit that file or something?
I was going to add your file as a test case, but the change is so
self-evident that I'm not going to worry much about it.
In my attached example file, this byte happens to be 0x40. To me, this
> looks like probably some kind of flag. However, I don't know what it means.
> Maybe the right thing to do in this case is print a warning that a reserved
> bit is set, and then proceed as usual? My proposed patch (attached) does
This is always the curse of reverse engineered formats - when you have
something you can't identify do you ignore it or do you acknowledge that
there's something about it that you haven't tested? There's no clear
answer and we do different things in different places.
There's really no reason to warn a human; it's not like there is anything
they can do about it, so I've just tossed the warning completely.
P.S., I've filed a bug with Fedora; I couldn't find a bugtracker for
> gpsbabel so I hope this mailing list is the appropriate place. The Fedora
> bug is here: https://bugzilla.redhat.com/show_bug.cgi?id=989851
This list is the correct place. I can't recall ever getting a patch from
Fedora for anything - even when they break or hobble our product - so if
you ever actually need something fixed in GPSBabel, this is the place to