[ntp:questions] false ticker after GPS coldreset
martin.burnicki at meinberg.de
Fri Dec 8 09:20:59 UTC 2017
again sorry for the late reply. I've been mostly offline for a few weeks
Gary E. Miller wrote:
> Yo Martin!
> On Mon, 6 Nov 2017 22:16:12 +0100
> Martin Burnicki <martin.burnicki at meinberg.de> wrote:
>> sorry for the late reply. I've been mostly offline for some days.
> Yeah, we both have real lives too.
>> 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.
>> On the other hand, with external GPS receivers connected via NMEA or
>> some binary serial messages you need PPS to compensate the serial
>> jitter. If you enable kernel PPS support then the kernel evaluates the
>> PPS time stamps by itself, but the kernel is unable to determine the
>> mean PPS latency.
> 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
>> So here we have to look at what happens to the PPS if the GPS goes
>> wacky. If you have a GPS with good, disciplined oscillator the it
>> makes sense to keep on evaluating the PPS even after GPS reception
>> has just failed.
> Scary, but if a GPS could tell gpsd that its PPS is good, but PTV is
> not good, some new code could handle that.
>>> Which is NOT what the OP was complaining about. His GPS was saying
>>> synced, but was off by the UTC/GPS offset which had not been
>>> downloaded yet.
>> That's exactly what I try to say. The GPS said "synced" but probably
>> only because a navigational fix could be achieved, which doesn't need
>> the UTC correction parameters. If there was a "time sync" status flag
>> that could be evaluated then the time from the GPS wouldn't be
>> accepted before the UTC correction parameters were available, even if
>> a position fix could have been achieved.
> Thecnically, a GPS should not output a 'valid' indication until it has the
> current ephemeris for the sats in the fix.
Again, that's what I also said.
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.
> 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.
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.
The UTC data set contains the current UTC/GPS time offset in seconds,
indicates when a leap second has been scheduled, but also some
polynomial coefficients that can be used to compute the basic offset
(modulo full seconds) and drift between GPS system time and UTC time.
The latter is usually in the range of a few nanoseconds, so indeed it is
below the noise level of IRQ latencies.
> 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.
Also the polynomial coefficients are important if you evaluate the PPS
slope with something different than a PC's IRQ line.
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.
The problem was that some satellites broadcast a faulty UTC parameter
set where the constant polynomial coefficient A0 was in the range of 13
microseconds instead of the true value which is only a few nanoseconds.
Here are some references:
A later statement of the US Coast Guard:
And a detailed analysis of the problem:
Senior Software Engineer
MEINBERG Funkuhren GmbH & Co. KG
Email: martin.burnicki at meinberg.de
Phone: +49 (0)5281 9309-14
Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de https://www.meinbergglobal.com
More information about the questions