[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [External] Re: Time precision in gps_fix_t

From: Greg Troxel
Subject: Re: [External] Re: Time precision in gps_fix_t
Date: Wed, 22 Jan 2020 15:34:51 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (berkeley-unix)

"Gary E. Miller" <address@hidden> writes:

> Yo Greg!
> On Wed, 22 Jan 2020 12:54:12 -0500
> Greg Troxel <address@hidden> wrote:
>> "Gary E. Miller" <address@hidden> writes:
>> > Yo Greg!
>> >
>> > On Wed, 22 Jan 2020 12:16:02 -0500
>> > Greg Troxel <address@hidden> wrote:
>> >  
>> >> All true, but Marco asked a perfectly fair question about gpsd
>> >> losing the subsecond time-of-fix.  
>> >
>> > I see no evidence of that.  If that is true it is a serious bug.  
>> I don't have the logs handy, but I was doing captures of the json data
>> (gpspipe -w) from an M8030 set to 2 Hz.   Adjacent lines had the same
>> timesstamps, both with 0 subsecond fix times.
> Multiple TPV with the same time stamp is not unusual.  Care to share your
> raw dumps?

Sorry, I don't have raw dumps available to share.    I will if I can
generate some.

This was a clear pattern of two TPV lines with the same timestamp, for
every second.

> Regardless, getting time to 100 micro seconds from the serial data
> is unlikely by at least 2 orders of magnitude.

I am not talking about time sync.   If one has > 1 Hz positions, you
want to be able to have those time tagged correctly so you can
interpolate based on your (synchronized) system clock to get
within-second position estimates.   This is a very noticable issue with
lots of nav programs on android (probably more about not extrapolating
the pointer, vs multiple positions per s).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]