[ntp:hackers] PPS, PPSAPI and pps_sample()
Mark.Martinec at ijs.si
Sat Dec 11 16:36:13 PST 2004
> I diddled the atom driver to use the mode keyord value as PPSAPI mode
> (decimal), which overrides flag2. Mark, have fun.
Thanks, will try it out as soon as I can lay my hands on a scope
close to our clocks.
> We still need to be able to choose which edge (rising or falling).
I believe this is covered by mode keyword value specifying the
full PPSAPI mode, which includes the edge specification
(but I haven't yet taken a look at the changed code).
It may be prudent not to let a user fully specify the ppsapi mode,
but do some sanity check / preprocessing on it. Namely:
- masking the requested bits with the offered capabilities as in the
previous code may be a good thing - it makes life a little easier for user;
- using only a couple of bits from the mode keyword leaves room
for future use;
Actually, only 4 bits are useful at the moment (asert/clear and two for echo).
> If I understand your explanation correctly, you have a correction for
> every PPS edge, right?
No, one edge only, the timing for the other edge is not calibrated/specified
(talking about the Trimble GPS receiver, probably for M12+T as well).
(incidentally, the PHK's driver pps.c in FreeBSD only allows for a parallel
port to capture the rising edge on the nACK, which is still a puzzle to me,
as so far I lived under the impression that for the printer handshaking
the falling edge on nACK would be the one that is important to be able
to cause an interrupt).
> Is this correction before or after the edge?
I'll have to re-check the docs to make sure.
I believe the anticipated correction is available before the edge.
> The PPSAPI does have provision to shim the edge, although
> I don't know if the current timepps.h uses it.
The capability is optional, but at least on FreeBSD it is supported
(thanks to Paul H.K.!). I have no idea how it is on Linux.
> This would seem the appropriate way to
> introduce corrections if known before the edge.
I agree, but the clock driver would need to lay hands on the ppsapi handle
from the atom driver.
I don't know if there are actual implementations of PPSAPI that do not
support it. If yes, some covert channel to the atom driver would be
a more general solution.
> 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.
I hope such magic won't be needed.
More information about the hackers