[time-nuts] First success with very simple, very low cost GPSDO, under $8

Chris Albertson albertson.chris at gmail.com
Wed Apr 9 19:13:25 UTC 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_lists.febo.com mailing list