Re: [Gpsbabel-code] -x track,merge,split=1m looses msec resolution

[Robert L. <rob...@gp...>]

On Fri, Mar 26, 2010 at 6:36 AM, Klaus Rheinwald <krh...@we...> wrote:

> Dear Babelheads,
>
>
>
> when downloading a track logged with 5Hz with GPSBabel Version
> 1.3.7-beta20100215 from the new Qstarz 1000ex using the -x
> track,merge,split=1m  option, it looses msec resolution and trakcs are
> reduced from 1 point every 200 msecs to 1 point about every second.
> Strangely enough, the msecs are not simply cut off, but every other point
> has no msecs, every other800 and every other 200 msec.
>
>
>
> Although this was discoverd when downloading from the device, it can be
> reproduced by running the attached file raw.gpx though GpsBabel with that
> filter. merge.gpx shows the result
>

You're right.   Looking at the code, the track filter makes a mess out of
subsecond timestamps and it's going to be tedious to repair.

ISO C just doesn't have a concept of sub-second time.   When I initially
designed things, a time_t (32-bit value of seconds since 1/1/1970) was
fine.   Later I added an adjunct for microseconds and taught a few places
about treating these as a pair.

I suspect that most of the payoff in trackfilter.c will be from teaching the
sorter to order based on creation_time _and_ microseconds instead of just
the integer component, but there are a variety of other places in that code
that needs attention.

No individual piece of it is hard, it's just a matter of working through it.
  Any takers?

RJL




> Anything else I can do to help pinpointing the problem?
>
>
>