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

Mark Martinec Mark.Martinec at ijs.si
Sat Dec 11 16:36:13 PST 2004


Dave,

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

>From Harlan:
> 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.

  Mark



More information about the hackers mailing list