[LinuxPPS] Attaching PPS to the Kernel

Dave Hart hart at ntp.org
Fri Apr 1 10:55:26 CEST 2011


On Fri, Apr 1, 2011 at 07:49 AM,  <reg at dwf.com> wrote:
>
> Well, I no longer understand how this was supposed to work.
> Yes each of the WWVB/Parse/NMEA/mx4200 drivers have calls to
> time_pps_fetch, which is the PPSAPI call to get the time of the
> PPS signal.

Notice refclock_atom.c has no calls to time_pps_fetch()?  Same for
refclock_wwvb.c (despite what you said) -- like atom it solely uses
the common PPSAPI code.  Until recently, NMEA did not have any
time_pps_fetch() calls for the same reason.  It grew them to better
associate the PPS with the correct second than it could using solely
the shared PPSAPI code.

> But note that ATOM/Parse/NMEA/PARSE/WWVB also refer to the routine refclock_pps
> which also has a call to  tme_pps_fetch.

Right, that's part of the common PPSAPI code

> and that NMEA/PARSE/WWVB contain an #include refclock_atom.h which is
> filled in by the atom driver using refclock_pps and returned to the calling
> driver.

Wrong.  refclock_atom.h would be better named refclock_ppsapi.h or
common_ppsapi.h  Unlike in the past, no drivers call into
refclock_atom.c code.

> Confusing.
> But Dave Mills loves his ATOM driver.
>
> One would have to step thru this code more carefully to see what is really
> going on,
> but I truly believe that these drivers want to use the ATOM driver.

I won't argue what you should believe.  I believe they integrate
PPSAPI support so they can, at the operator's discretion, operate as
integrated drivers supporting a reflcock that provides a serial
timecode as well as a PPS signal.

Cheers,
Dave Hart



More information about the LinuxPPS mailing list