gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] Meaning of negative PPS offset?


From: Gary E. Miller
Subject: Re: [gpsd-dev] Meaning of negative PPS offset?
Date: Tue, 26 Aug 2014 11:36:21 -0700

Yo Greg!

Sorry to jump in late, I've been off net much of the summmer until
yesterday. I've not looked at the recent changes and missed that start
of this discussion.

On Tue, 26 Aug 2014 14:12:52 -0400
Greg Troxel <address@hidden> wrote:

> Well, you are assuming that the phase of the PPS relative to the NMEA
> arrival is >=0.0s and < 1.0s.   That seems not really true.

Never seen or heard of a case otherwise.

> So one
> could look at
>    p = system timestamp of pps edge

Yes, we do.
 
>    n = system timestamp of most recent nmea sentence with time (or
> first in a cycle, if we can separate those?)

Yes, we do.

>    N = nmea timestamp (always .0000000s?)

Nope.  There are common 5Hz and 10Hz GPS.  Plus some that try to
output the time of the start of the serial accounting for processing
delays.

> So presumably we expect, when things are ok
> 
>    n - N = a about 300 ms

We see 100mSec to 800mSec in the wild.
 
>    p - n = about 700 ms

That would be 200mSec to 900mSec.

>    associate p as being the time for edge (N+1)

Given.

> which is I think what you are saying.   So the bug is that in cases we
> are saying.
> 
>    n - N = -40ms

Which makes no sense.  The NMEA at time X never preceeds the PPS for time X.

> in which case we should associate p as being the time for edge N.

Or ignore it.

> So two thoughts:
> 
>   We really need to know how each device behaves, unless they are all
>   close enough.

They are pretty close.  Some just a lot slower to emit the first 
NMEA time.
 
>   Instead of assuming that p > n, we can assume
>     n + 0.1 > p > n - 0.9
>   so that we find the right edge for p.   Hence we say that if p-n is
> <= 100ms, we just take N for the PPS.  And if p-n > 900 ms, we add 1.

100mSec is way too large.  Except for really old and slow GPS the 0.9 is
also way too large.

> The real rub is that we have to know if it's more likely that the NMEA
> sentence is 100 ms early or 900 ms late.  Which is necessarily device
> specific.   An alternative view is that any device outside those
> bounds is broken.

The NMEA is NEVER early.

> A totally alternate approach is to assume that the system clock is
> within 500 ms, and to disamiguate the PPS edge by finding the nearest
> second.

Which fails for older and slower GPS.

>  Or perhaps even to only capture PPS when it's within 200 ms
> of the system clock.

Which fails for older and slower GPS.

>  Basically this ignores PPS until the clock is
> close, which sort of makes sense.

Which is what we used to do.  The 3.11 PPS patches, which I have not
tested or inspected, were intended to speed up time lock.  In theory
they should work.

In practice testing this would be very time consuming.

I assume this discussion is because someone has seen bad results from 
this patch?  Can someone recap the data that started the discussion?

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97701
        address@hidden  Tel:+1(541)382-8588

Attachment: signature.asc
Description: PGP signature


reply via email to

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