[time-nuts] First success with very simple, very low cost GPSDO, under $8
Chris Albertson
albertson.chris at gmail.com
Wed Apr 9 15:13:25 EDT 2014
On Wed, Apr 9, 2014 at 11:18 AM, Hal Murray <hmurray at megapathdsl.net> wrote:
>
> I think you can turn that into a feature. Suppose you start with the
> DAC/OCXO running at exactly 10 MHz, and the phasing such that you are right
> on. Due to noise, the last count will be early and get counted half the
> time. The other half of the time, it will be late and get counted in the
> next second. So if you don't see that sort of noise occasionally, you know
> you are drifting off from a phase that was "right on".
>
> Have you calibrated the DAC yet? If you bump it up by 1 count, how long does
> it take for the OCXO to drift by a cycle?
>
>
> Another low cost way to get better resolution would be to use 2 counters and
> a delay line. Pick the length of the delay to be well above the noise level.
I'm out of counters. The chip only has one 16-bit counter.
I think I can do all the averaging and dithering using only the PI
controller. The "I" term in effect handles dithering. When the error
toggles from plus to minus I goes to zero and the DAC is not changed
much. But if a few more pluses than minus happen the I term goes
positive and slowly pulls the DAC up. I don't have to use "if
statements" in the code.
The effect is I see a dither between 4999999 and 5000000 which cases
the DAC to move up then I see a long row of 5000000 samples which is
the perfect count. But then I see a 5000000 and 5000001 dither which
puss the DAC down and I get many more 5000000 samples. It mostly
hangs out at 5000000
So I have to disagree, differing is not what I want. I want to be
dead-on 5000000 cycles per second (that is 10MHZ after the divide by
two in the 74HC390) Then as soon as I see a few 5000001 samples I
need to very slowly go bcd down until a 4999999 is detected 10 or 15
seconds late. This is what is actually happening. It seems to work
with no "if" statements.
What I think I need is to fine tune the PID constants and likely have
a few sets of constants. For example I find a larger I causes the
system to very quickly get a lock but also the large I causes
overshoot. I may implement different modes, like "fast lock" and
"best short term" and "best long term" Maybe even have a PID auto
tune mode where I measure the system response. I am only using a
tiny fraction of the available space for code. There is room for
many thousands more lines of C code. The line count is only a couple
dozen at present.
--
Chris Albertson
Redondo Beach, California
More information about the time-nuts
mailing list