On Wed, Apr 9, 2014 at 11:18 AM, Hal Murray <[email protected]> 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 _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
