Lose the per-driver PPS code

Dave wants to lose the per-driver PPS code and let the ATOM driver handle it all.

What	Status
arbiter	(seems OK)
as2201	(seems OK)
hpgps	(seems OK)
jupiter	Bug #560
Master	Bug #557
msfees	Bug #561
mx4200	Bug #562
nmea	Bug #563
oncore	Bug #559
parse	Bug #558
ripencc	Bug #564
trak	Bug #565
true	Bug #566
zyfer	Bug #567

Let's use this topic to discuss issues about this set of bugs.

Harlan: Do the remarks "seems OK" mean - OK as they do not use any of the PPSAPI?

-- FrankKardel - 01 Feb 2006

Yes, it means that I did a grep PPS refclock*.c and the ones marked "seems OK" only discussed PPS in their comments.

-- HarlanStenn - 01 Feb 2006

The thing is that the refclock drivers know exactly whether the PPS of the device they are controlling is valid by the information from the device itself.

ATOM/PPS must use PPS derived time stamps only when the clock is doing well. ATOM/PPS has currently no way whatsoever to know about the health state of PPS (I currently see a 500ppm frequency check) - it assumes that PPS is always valid when it is there.

We have seen refclock/network scenarios where knowing whether PPS is healthy was absolutely crucial (effect: oscillating clock setting of several 100ms).

The scenario was invalid PPS information from a PPS source and valid time time information from the network.

For ATOM/PPS we would need an interface where the PPS health information is available to ATOM/PPS.

Currently this task is managed in the refclock drivers (some better, some worse).

-- FrankKardel - 01 Feb 2006