[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