[ntp:hackers] PPS, PPSAPI and pps_sample()

David L. Mills mills at udel.edu
Sat Dec 11 11:49:39 PST 2004


Dennis Fergusson's original 1991 code is anal retentive to the max. The 
flags are bits, just bits. The configuration stuff really needs to be 
weeded and a more general fudge options put in. The mode option is a 
better place to put this stuff. I'll take a look at it.

Yes, I'm trying real hard to get rid of all PPS stuff anywhere except 
the atom driver. As long as the PS is clean, the way I suggested last 
week is the preferred scheme, but nobody has spoken up.

If I understand your explanation correctly, you have a correction for 
every PPS edge, right? Is this correction before or after the edge? The 
PPSAPI does have provision to shim the edge, although I don't know if 
the current timepps.h uses it. This would seem the appropriate way to 
introduce corrections if known before the edge. If known only after the 
edge, say on the message following the edge, the only way I can think of 
is latch the PPS, wait for the message, calculate the correction and 
call pps_sample(). The link to pps%d would not be installed, so the atom 
driver would not open the device or field interrupts. The driver would 
open the PPSAPI and feed via pps_sample(). Probably some wrinkles, but 
it would work.


Mark Martinec wrote:

>>I looked further in the pps_sample() plaint reported earlier and found
>>no joy at all. The pps_sample() routine is designed to work with the
>>atom driver only and will fault if the atom driver is not configured. ...
>Not directly related, but since you are touching the atom driver,
>I have two requests/questions for it.
>>(atom driver):
>>flag2 0 | 1 
>> Specifies the PPS signal on-time edge: 0 for assert (default), 1 for clear.
>I would like to be able to enable the PPS_ECHO<whatever> from
>the config file on the atom driver. This would make it easier to calibrate
>the interface without having to hack with pps-api.c utility or some such.
>Perhaps recognizing the second bit of flag2 to turn on the pps echo
>matching the assert or clear as determined by the lsb.
>(background: I'm playing with the FreeBSD implementation of
>pps api and the parallel port driver seems to be able to capture
>the edge 15 microseconds earlier that DCD capture on the serial line;
>seems like a way to go)
>The second item is rather a question on a proper way of feeding PPS
>dynamic corrections from a clock driver to the atom driver. Namely,
>both the Motorola M12+T and a Trimble Acutime2000 GPS receivers
>use an internal clock to fire their PPS output on the nearest clock 
>transition, which means it produces a bit of jagginess on PPS offset
>due to internal clock granularity. But both receivers are able to report
>the current PPS offset in their protocol, so this offset should best be 
>subtracted from PPS timestamps as acquired by the pps capture.
>Now, considering that the use of atom refclock seems to be the
>recommended way to go (instead of each driver feeding samples via
>pps_sample), how should a clock driver feed the pps offset corrections
>to the atom driver? A possible solution would be to use the pps api
>to feed the offset to assert_offset(), but this capability is optional in the 
>api, and the atom file descriptor is probably not available in the clock 
>driver. Is using the pps_sample the only option? Perhaps an additional
>routine to declare offset, made available to the clock driver?
>And last but not least, thanks for the:
>>There is a new driver call once per second from the timer module. It 
>>uses the FLAGS entry in the transfer vector, which hasn't been used in 
>>twenty years, to call a driver dependent routine once per second. ...
>Last time I was playing with the Palisade driver I missed some routine
>like that (the Palisade GPS can capture time of events on its event
>input, which seems faster and more predictable that the handling of
>interrupts in the computer).
>  Mark

More information about the hackers mailing list