Re: [Gpsbabel-code] Run Trainer 2.0 .FIT File

[Tom P. <tom...@gm...>]

That sounds somewhat similar to the issue I reported recently with some
.FIT files from my Garmin Forerunner 210.


On Tue, Mar 26, 2013 at 3:08 AM, Robert Lipe <rob...@gp...>wrote:

>
> On Mon, Mar 25, 2013 at 7:12 AM, Brigg Thorp <bw...@gm...> wrote:
>
>> Timex released their new Run Trainer 2.0 watch that I happened to get a
>> hold of. Unfortunately, their .FIT file is a little different from Garmin,
>> so it works with some sites but not with others. It doesn't work with GPS
>> Babel.
>>
>> I have contacted their customer support and they said that they are 100%
>> compatible with the Dynastream ANT FIT format.
>>
>
> 100% compatible...that works with some sites and not with others.   Sigh.
>  Does this not set off alarms for anyone?
>
>
>
>> Can someone look at the attached .FIT file and see what the problem is
>> and why this is not working?
>>
>
> The Garmin fit file is reverse engineered and relatively complicated.
>  (They have an SDK, but the licensing terms on it are incompatible with
> open source projects.)  I can see what's going on at a microscopic level,
> but I've looped in the original author of that module in the hopes he can
> offer a better fix.
>
> It looks like the format has two entries in each record that describe that
> field.  One is the type and the other is  the size in bytes.  (This seems
> to match the understanding of, say,
> https://github.com/ptarcher/FIT-decode/blob/master/src/garmin/fit.c)  An
> "INT8" would be one byte.  An INT16 is two bytes.  A String has a variable
> number of bytes and so on.  We're crashing on a safety check.  We're seeing
> a type of "unsigned int32" and a size of eight bytes - clearly, that makes
> no sense so we stop processing at that point.
>
> As the actual data is 64 bits of all ones, the record doesn't make any
> sense to us anyway.
>
> It's easy enough to modify our reader to detect this, but it's probably
> fundamentally wrong.
>
> If you just change garmin_fit.cc, your file seems to basically read.
> Modify starting around line 249.  Add one line and then comment out the
> is_fatal()
>
>   case 0x85: // sint32
>   case 0x86: // uint32
> if (f->size == 8) fit_getuint32(); // read and throw away the first
> 0xffffffff
> //    is_fatal(f->size != 4,
> //             MYNAME ": Bad field size in data message %02x
> %02x\n",f->type, f->size);
>     return fit_getuint32();
>
> Someone needs to really understand what's going on.   Our decoding of
> these field definitions and sizes match other programs, such as the one I
> mentioned.  It seems unlikely they're actually intending to put a 64bit
> thing in an 32 bit field, but it's not like our reader has fallen out of
> sync and we're just reading nonsense and trying to fit it in based on
> numerology or such.   My guess is that we have a fundamental
> misunderstanding or their writer is slightly broken...which would help
> explain the "works with some sites but not with others".
>
> I'm uncomfortable enough with that change that I won't commit it, but that
> should give you (and hopefully Timex) an idea where to start.
>
> Good luck.  Keep us posted.
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Gpsbabel-code mailing list  http://www.gpsbabel.org
> Gps...@li...
> https://lists.sourceforge.net/lists/listinfo/gpsbabel-code
>
>