Don't use time_offset as a leaky bucket variable in hardpps(), this

resulted in vastly optimistic offset values reported to userland
(typically a factor 40+ too small).  Apart from that, the code had
two sign-bugs.

Apply the hardpps() phase with the right sign with a simply
scaling by integration interval.  (This may be too stiff at
long integration intervals, see below).

Allow pps_shiftmax to be reduced again.

Before this, the phase lock in hardpps() were broken, but due to
two bugs mostly cancelling out, it would end up basically working
with a large stochastic component.  Now it behaves as one would
expect: smooth and quiet.

It seems that pps_shiftmax above 7..9 somewhere makes the phaselock
too weak to hold onto random walk phase errors from a HP-105 OCXO,
which basically means that it is too weak for real-life use with
such integration times.  This is yet to be resolved.

Submitted to:	Prof. Dave "NTP" Mills.
Tested by:	Terje Mathisen <Terje.Mathisen@hda.hydro.com>

0 files changed, 0 insertions, 0 deletions