Re: GPSD Not Using /dev/pps0 But ppstest Shows /dev/pps0 is OK

[Gary E. Miller]

Yo Joshua!

On Thu, 3 Dec 2020 13:05:42 -0500
"Joshua Quesenberry" <engnfrc@gmail.com> wrote:

> Thanks that helps! A few more questions.

Good.

> Is the fix time modified at all when PPS present? Or does it remain
> what was in the NMEA string?

gpsd never modifies any data from the receiver.  It may scale
data, like meters to feet, but not modify.  It may also calculate
missing data, like ECEF and velocities, but only if the receiver
did not supply that data.

> Would (pps.clock + (gps fix time - pps.real) be an appropriate
> calculation to relate the current GPS data to the actual system time
> at the point the GPS sent out the NMEA string?

Almost.  Use gps fix time to select the proper second for the PPS pulse.
Then look at (clock - real) for the system clock offset.

> At this point toff.clock seems to always equal pps.clock,

I would hope so.  PPS is just a pulse, so the integer seconds has to
come from the fix time.

> does that
> imply there's minimal delay from the time the GPS sends the data till
> the time GPSd processes it?

It says nothing about any delays.  It just tells you when the
measurement was taken.  Measuring the delays is pretty hard and requires
kernel support and an external counter/timer.

You use a pin from a parallel port (or GPIO).  Have the kernel driver, or
gpsd, wiggle the pin when the PPS interrupt is processed.  Then use the
counter timer to measure the delay from the PPS pules to the output pulse.

That can jump all over the place, which is why ntpd uses smoothing
algorithms to discipline the system clock.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@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

pgpNaPNgVj06g.pgp
Description: OpenPGP digital signature