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

Mark Martinec Mark.Martinec at ijs.si
Fri Dec 10 16:58:25 PST 2004


> 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).


More information about the hackers mailing list