do not bail out on unknown message types. This violates the design of the
Fit format of being extensible.
As this was the last thing using the global_msg_names QMap, I've nuked
this, aswell.
1. Allow FIT reader to recognise the file comes from a Garmin Edge 800
This is Garmin product ID 1169 in the decodeFileId routine.
2. Ignore global_msg_type = 72
This message appeared with the introduction of the Garmin Edge 800.
There is no FIT SDK that tells us what this message is.
It appears only once and has timestamp/device serial number.
Code now recognises the msg_type as valid but we don't process it.
3. Add all decodeEvent types and work only with "timer" events
Not all event_types were present. They are now all in the function.
Previously the decodeEvent would look at all "events"
We now only decode event_types if the event is of type "timer".
Fixes: #250
The FIT parser will attempt to interpolate data when filling in for smart
recording or if a record is missed. A problem occurs if one of the lat/long
points is missing or 0,0.
This patch will record a 0,0 lat,long if the record is missing in the FIT
file and when interpolating, will set any interpolated data points to 0,0
if the start or end record is also 0,0.
A 0,0 record is not plotted on the MAP tab.
Fixes#111
New idea: only linearly interpolate between two consecutive "record"
messages. I don't know what else to do. My FIT files have all sorts
of weirdness I can't explain. One, for example, has two consecutive
start events with the same timestamp. What does that mean?
This is all proof that just having the file "format" isn't really
enough. What you need is the file *semantics*, and we don't have that
for FIT yet.
I'm not really sure what these are doing in the FIT file Jamie sent
to the list, but there's only one of them, and it's at the end of a
long rest period, so it seems safe to ignore it for now.
