[ntp:questions] PPS from an external OCXO source. Correcting drift is it possible?
mills at udel.edu
Sat May 2 02:53:30 UTC 2009
You should think about my suggestions. Here is the engineering
justification for my approach some years ago and justified by experiment.
The real enemy when disciplining a cold rock is random-walk frequency
noise, often called flicker noise. A PPS signal from a good hot rock
very nearly eliminates this source, even if the intrinsic frequency is
not precise. At 20 ms per day your rock is within 0.23 PPM, which is not
bad at all and results in a 0.23 microsecond sawtooth error. The secret
to keeping the residual errors, both phase and frequeny, low is long
integration times in the order of 1000s. This can be achieved with a
poll interval/time constant of about the same value..
Our expectations with a PPS signal and even without a OCXO discipline
show jitter in the 1-5 microsecond range, but with occasional flutter
somewhat more than that due flicker noise of the computer oscillator,
which you can't get away from unless your OCXO drives the timer interupt
directly. So, even with your OCXO frequency error, you should be able to
do as well.
>>How far are you willing to go? You might be able to build a clock
>>based on the PPS that is amenable to disciplining through NTP, but
>>if it's only for holdover during Internet outages, perhaps you'd
>>be more helped with a way to keep the offset down (or at least
>>known) between Internet outages.
>Probably I would be well served with a way to keep the offset down at
>least as a starting point. This would take care of one of the two
>issues, but ideally for long term accuracy some kind of drift
>compensation would be nice.
>For drift compensation, logically I would be expecting NTP to handle
>pulses that are not exactly 1 second long, perhaps this is easy to
>program, however I'm not a C programmer or a unix guru so there will
>be a very steep learning curve for me to get into modifying the PPS
>code. (Unfortunately I have a tendency to want to make things work
>correctly rather than just fix the problem but I will resist this
>temptation for now).
>I have conflicting and confusing info on the fudge commands so I have
>tried using the fudge time1 setting to eliminate the offset at start
>up. I didn't get it to work, so I tried fudge time2 and this also
>didn't work. The documentation that I have isn't clear on how to use
>these settings and what units are used, I tried both milliseconds and
>microseconds and neither worked. What units are used, and can they be
>dynamically adjusted through ntpdc?
>A hint at why the offset may not be working may come from this
>fragment from - External Clock Discipline and Local Clock Driver.
>"The external clock driver controls the system time and clock
>selection in the following way. Normally, the driver adjusts the
>kernel time using the ntp_adjtime() system call in the same way as the
>daemon. In the case where the kernel discipline is to be used intact,
>the clock offset is provided in this call and the loop operates as
>specified. In the case where the driver steers only the frequency, the
>offset is specified as zero".
>Please indulge me if I am way off here - I am finding the mountains of
>NTP documentation exceptionally confusing and the more I wade through
>it the more confusing I find it.
>Does anyone know of an authoritative source of instructions for using
>PPSAPI with a PPS only source?
>I thought that if I could get the fudge to work then perhaps I could
>script something to use ntpdc to keep the offset under control.
>I'm also not to clear on how to get the authentication for ntpdc
>working. Can anyone point me to clear instructions or a tutorial for
>current NTP versions?
>questions mailing list
>questions at lists.ntp.org
More information about the questions