[ntp:questions] false ticker after GPS coldreset
Gary E. Miller
gem at rellim.com
Tue Dec 19 22:52:10 UTC 2017
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:
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.
> 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.
> 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....
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
Size: 488 bytes
Desc: OpenPGP digital signature
More information about the questions