Bob wrote:

You are using a resistor to charge the integrating capacitance, so it
charges with the classic exponential curve and you get a nonlinear
time-to-voltage conversion.  You need to charge the integrating
capacitance with a constant current if you want a linear
time-to-voltage function.  The current source will probably need to
be connected to a supply that is higher than 5v, because it needs
some headroom.

There may be secondary errors, as well, due to the leakage of the
tri-state buffers in their hi-Z state and/or nonlinearity in the
ADC's internal capacitors.  Often you can improve things by using
sufficient external capacitance to swamp the ADC's internal
capacitance and increasing the charging current.

Best regards,

Charles

Thanks Charles.  That makes sense, but at the expense of adding unwanted complexity.  As I've been moving the setpoint around this morning, I think I see a way to characterize what it's doing.  Maybe I can come up with a small correction table or formula that's good enough for my purposes.

Bob

One method would be to calibrate with a series of  buckets that you fill by
sampling a random source, the more samples in a bucket the more range in
phase for that bucket. For example 1 1 1 2 2 2 3 2 2 1 0 samples sum equal
17 so each unit equal 17/(total range of  TIC) and the bucket with 3 samples
would be 3 * 17/(total range of TIC).

Stanley

On Wed, Mar 26, 2014 at 8:41 AM, Bob Stewart bob@evoria.net wrote:

Yes a lookup table would be easy.  But how to create the table?  I've been
thinking about a way to do self calibration.  The controller purposely
runs the DAC and of course the OCXO through some range and watches the
phase.  This gives you a rough DAC vs. Phase function.  Re-running the
calibration could make up for some component aging.  It would take some
time (hours) to wait for everything to warm up and then you'd have to move
the EFV voltage slowly

--

Chris Albertson
Redondo Beach, California

If I were to try to do this automatically, I think I'd move the PLL set point in "n" steps from near the bottom to near the top and look at the width of the PPS signal at each step; perhaps using the bucket scheme that Stanley mentioned and using some count per bucket to decide "how wide is wide".  I don't have any sort of phase wrapping code, though, so I have to be careful how close to a phase point I get.

Bob

A random source will need a lot more samples in each bucket to reduce
the noise to an acceptable level.
To determine the relative bucket width with a 10% error requires at
least 100 samples per bucket.
For 1% error at least 10,000 samples per bucket.

All thats really required is a sufficiently noisy oscillator that isn't
phase locked to your clock.

Bruce

Stanley wrote:

Hi

Having done this - it gets really boring to sit there for 10,000 seconds and collect data. Best to automate the process.

In reality you want to run three groups of 10,000 samples and see how they relate to each other. With some approaches you can find some disturbing things going on.

Bob

On Mar 26, 2014, at 1:22 PM, Bruce Griffiths bruce.griffiths@xtra.co.nz wrote:

I finally got my PLL running today, and I think I can manage with just a small table of 10 values to be used as the width of my PPS jitter corrector.  That takes care of it for this project, but obviously not for the general case.

Bob