[Top][All Lists]

[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 12:02:57 -0700

Yo Eric!

Sorry, I've been reading this thread in reverse order.

What you see is a bug (or debouncer) in the USB driver.

This should be handled totally separately from generic PPS.

Except for the new PPS changes, which I have not had to review or test,
the PPS code has been hammered to death.  99.99% probability anything
you think is wrong in it is a failure of your assumptions, not a coding

On Tue, 26 Aug 2014 07:39:52 -0400 (EDT)
address@hidden (Eric S. Raymond) wrote:

> There is a comment in ppsthread.c that reads:
>              * FIXME! The GR-601W at 38,400 or faster can send the
>              * serial fix before PPS by about 10 mSec!
> And, indeed, when I run gosmon live at 9600 on a GR-601W I observe a 
> small negative offset. At the moment I write it is -0.003518431.
> This puzzles me.  It makes me fear we may have a design or
> implementation bug.

Nope.  USB driver implementation issue.

> The offset is the delta in fractional seconds between the clock time
> of the last PPS and the second part of the last GPS timestamp seen,
> minus one second.

I can't say about gpsmon, but not what we ship ntpd/chrony.  So this
assumption 0. is wrong.

> The assumption here is that the GPS reporting cycle looks like this:
> 1. GPS top of second occurs.  GPS asserts PPS.

> 2. gpsd fields the PPS interrupt and records the clock time it arrived
> to microsecond precision.

Nope.  Usually nanoseconds.

> 3. When doing 2, gpsd looks at the last timestamp received in the
> GPS datastream, assumes it went with the *previous* reporting cycle,
> and increments the second part by one second.  This is assumed to be
> the base clock second for the *current* reporting cycle.

> 3. GPS computes a fix. 

> 4. GPS ships the fix and a timestamp for this cycle.


> 5.  Return to step 1.

> What I don't understand is how, under these assumptions, the
> offset value can ever be negative.

Assumption 0. is wrong which easily leads to negative offset as 
given to ntpd/chrony.  Assumption 6 is that PPS and Serial data
proceed in sequence through the USB driver.  Assumption 7 is that the
new patches did not mess up anything.

> Can someone explain this, and what it means when it happens?  I
> want to document this in the Time Service HOWTO.

Explained?  I'd also like to see what you think you are seeing
to verify assumptions.

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

reply via email to

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