gpsd-dev
[Top][All Lists]
Advanced

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

Re: [gpsd-dev] PPS over USB


From: Gary E. Miller
Subject: Re: [gpsd-dev] PPS over USB
Date: Mon, 23 May 2016 15:30:23 -0700

Yo Hal!

On Mon, 23 May 2016 01:16:16 -0700
Hal Murray <address@hidden> wrote:

> address@hidden said:
> >> PPS over USB will be more accurate with a fudge factor.  
> > Gack, no.  The USB delay is much less than the sample interval on
> > the USB 1.1 bus.   
> 
> I don't understand what you are trying to say.

I see we have a problem with terminology. 'accurate' and 'off by' really
do not have a place in NTP land.  We need to talk about delay, offset,
wander and jitter.  Which are separate, but related, parts of accuracy.

> PPS over USB will be off on average of 1/2 the polling interval.

Actually not.  Depending on your definition of 'off by'.

If we are looking at jitter specifically you will find it is often less
than 1/2 the polling interval (488 microSec).  That is because the USB
polling clock is tied to the system clock is tied to ntpd and thus PPS.
So the whole thing is in a PLL and the "gear lash" becomes a constant.

We can't actually say much about the delay as we have zero inforation
about the latency of the USB chips involved.  UNtil we compare it to a
better PPS.  My testing comparing USB/PPS against a local GPIO or serial
PPS leads me to believe this latency is around 1.4 milliSec.  That is
much more than 488 microSec that is 1/2 the polling interval.

So one definition of "off by" is more thean 1/2 the polling interval
and another one is less than the polling interval.

And if we look at wander the GPS makes us look real good, zero accumulation
of error over the long term.

> It's easy to see if you have a decent place to stand.

Yup.

> In some sense, it's not a big deal.

Well, it sort of is, thus my trying to get the words just right.
Different users have different time needs, we help the user when we can
tell him what sort of errors he can expect to get.  Then he can compare
them to his perceived time requirements.

>  On the other, it's a systematic error so it's
> silly not to document the fix, especially in a document that is
> mostly cut-n-paste.

Well, no real 'fix'.  Unless you can temporarily get a better time source
to adjust to.  About the best we can do is suggest a 001.4 fudge on
the PPS because we guess that is his USB 1.1 delay.

> Eric: Please plug your 701W into your Pi with HAT and collect some
> data.

I think we gotta send less grunt work to Eric when we can do it ourselves.

If we can get some better monitoring/graphing code then we can do that
ourselves.  For example, I already have GR-[67]601W hooked up to several
hosts with better PPS clocks to compare against.  If someone posts
some ntpd capable graphing code I'll make use of it.

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

Attachment: pgpsFxMF_BOLG.pgp
Description: OpenPGP digital signature


reply via email to

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