[ntp:questions] false ticker after GPS coldreset

Gary E. Miller gem at rellim.com
Tue Dec 19 22:52:10 UTC 2017


Yo Martin!

On Fri, 8 Dec 2017 10:20:59 +0100
Martin Burnicki <martin.burnicki at meinberg.de> wrote:

> again sorry for the late reply. I've been mostly offline for a few
> weeks now.

Compounded by my being confined to bed for a bit, then taking forever
to get caught back up.  Nothing serious on my end, just the same
grunge going around my city.

> >> I'm mostly working with GPS PCI cards, where the kernel driver
> >> reads a high resolution, accurate time stamp from the PCI card,
> >> plus an associated system time stamp, plus some TSC counts. The
> >> calling application can check the TSC values to see if reading the
> >> time stamp pairs has taken longer than "usual", and repeat the
> >> call, or feed both time stamps into SHM.  
> > 
> > Coll?  Anyhting cheap I could afford?  
> 
> It's the Meinberg PCI GPS card. Not cheap, unfortunately.

Well, you're Meinberg, just send me one.  :-)

> > We assume it is zero.  Not valid, but what else can we do?  PPS is
> > already way down in the noise.  
> 
> I know there's nothing you can do to determine the IRQ latency on a
> standard PC.

Well, with a Meinberg budget, there are things you can do.

Get a PCIe GPIO card.  Tweak your kernel, or ntpd, to move a pin
on the GPIO on detecting the PPS.  I see the Gateworks gw16113 claims
12 nS output rise time, no idea of total latency...

Get one of these, measure time down to 100 pico second range:

    http://tapr.org/kits_ticc

Have it measure the time from the PPS in to the GPIO out.  That give you
an upper bound on PPS in latency.  Take a WAG how much overhead is in the
GPIO output and refine that upper bound a bit.


> However, we should be more specific here with the terms we use.

OK.

> The receiver needs to know the ephemeris data set (as well as the
> satellite's clock correction parameters) for each satellite to be able
> to compute the satellite's exact position in space at a given time,
> which is required for exact positioning and timing. Each satellite
> sends only its own ephemeris and clock correction parameters.

Yup.  Plus the entire almanac.

> > The almanac may take 12 to 24 mins to download, but the almanac is
> > just for predicting future GPS sat locations.  
> 
> Yes. The almanac can be used to predict which satellites should be
> visible at a given time and a given receiver position. However,
> almanac parameters yield only a limited accuracy when computing a
> satellite's position in space, so the ephemeris parameters are also
> required for a high accurate fix.

Yup.

> Basically the almanac would not even be required for high precision
> navigation if the ephemeris data is available. Navigation works
> perfectly fine based on GPS time only.

Yes, but.  Without an almanac, initial GPS sat selection, and then
ephemeris download, can take a while.

> If you are going to use the GPS receiver for exact UTC timing,
> however, you need to be sure that the GPS UTC correction parameters
> are also available in the receiver. The UTC correction parameter set
> is a single data set sent by every satellite, similar to the almanac
> data sets, some health data, etc. This is indeed sent only once every
> ~12 minutes.

A non-issue, except on startup.

> The latter is usually in the range of a few nanoseconds, so indeed it
> is below the noise level of IRQ latencies.

Yeah, but well in range of time-nuttery.  Like the TICC mentioned above.

> > I'm sure there a few small cases where my simplification is not
> > right, but I've not seen PPS shift from the almanac.  
> 
> The whole number of seconds of the UTC offset is currently 18, so if
> the *UTC parameter set* is not available in the receiver the GPS
> receiver is unable to convert UTC time to UTC. If the receiver anyway
> claims to be fully synchronized the we have the problem that
> gpsd/ntpd set the system time wrong by 18 seconds.

Yup, we do see that often on cheaper GPS on startup.

> Eventually you remember an incident on 2016-01-26 where the UTC time
> provided by most GPS receivers was off by about 13 microseconds, which
> could also be seen by PPS slopes handled via an IRQ.

Yeah, nothing we can do when the GPS operators mess up....
 
RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.ntp.org/pipermail/questions/attachments/20171219/9861a4b7/attachment.sig>


More information about the questions mailing list