Plan A
The plan was to use a 20Mhz cyrstal on the PIC, which gets divided by four internally to provide the clock for one of the internal counters. The drawback is I would be using 5Mhz to measure the phase rather the 24Mhz in the original design. I set out to determine how this might affect accuracy.

A look at accuracy
In the original design, a 24Mhz clock was used to measure the phase difference between the 1 Hz pulse from the GPS and the 5Mhz VXCO frequency divided by 16. This means that there are 76.8 cycles of the 24Mhz clock for every 5Mhz/16 cycle.

Looking at this another way, the orginal design averaged the phase measurements over a 30 second period. This means that the VXCO must drift one period of the 24Mhz clock in 30 seconds in order to be measurable. Putting into math form, the minimum detectable VXCO frequency change would be:

5Mhz - (30 sec - 1/24Mhz)/30 sec * 5Mhz = .00694Hz

Not bad, a fraction of a hertz or 1 part in 0.7e9. How much accurracy is enough? Assuming, we would multiply the 5Mhz up to say 1Ghz, yields a 1.38Hz accuracy. Accurate enough for anything I would need.

So, back to my orignal idea of using 5Mhz instead of 24Mhz. Running that through the same formula, we get:

5Mhz - (30 sec - 1/5Mhz)/30 sec * 5Mhz = .03334Hz

Not as good, still a fraction of a hertz, but only 1 part in 150e6. Multiply this up to 1Gz and accuracy is only about 7Hz. Probably still usable.

Required DAC resolution
The 18 bit DAC seemed a little overkill, so I calculated what would be needed to achieve 1 part in 1e9 resolution for controlling the VXCO. A typical integrated VXCO has +/-100ppm pull for 5 volts of control. The math would be:

5 volts * 0.0069Hz / (200ppm * 5Mhz) = 69uV

Thus 34.5uV is required to pull the vxco .0069Hz. The 18 bit DAC provides 5 volts / 2^18 resolution or 19uV. A 16 bit DAC would provide 76uV, Not quite enough. so using the 18 bit DAC was justified.

Measuring phase with an rubber ruler
As I looked at the math behind the orignal design, I became skeptical of using a undisciplined oscillator to discipline the VXCO. My major concern was the how temperature drift might affect phase measurement accuracy. I wrote a small simulation program where I could vary temperature over a reasonable range. This confirmed my suspicions that indeed temperature would cause the measured value to dither +/- a bit depending on the temperature. To negate this effect, the measured value should be divided by two. This makes my redesign look even worse.

Locking on the wrong frequency
My second concern was that the VXCO is only divided by 16 and phase is being measured at widely different frequencies. I convinced myself that the phase measurements would unaffected though. I looked at another possible problem, locking up at the wrong frequency. At small variations in VXCO frequency, the system seems to work. However, a second simulation confirmed that it would be possible to lock up perfectly at 5.001Mhz or 5.002Mhz. Okay, its unlikely you would pull a 5Mhz VXCO 1000Hz, but it is technically possible.

Measurable error or measurement error?
Another interesting point, the author mentioned observing noise in the phase with a standard deviation of 35ns. I find this interesting since the 24Mhz only allows phase resolution of only 42ns. The author make the claim on the web page the the measurement accurracy is about 3ns when averaged over 30 seconds. I see where this comes from:

1/(24Mhz * 30secs) * 2 or about 3ns.

However, this is a fallacy. Basicly phase is being measured as the difference in time which is analogous to measuring distance with a ruler. Using the assumption the author makes, if we measure a board 30 times with a carpenter's rule that has 32nds and then take the average, we can measure to an accuracy of a thousandth of an inch. Wrong! We might be able to split the 32nd in half to get 64ths, but that is it.

Now take that same ruler that has the hook on the end that slides back and forth a 32nd and push it one way for one set of measurements and the other for the next. What would we measure? This is exactly what happens with the 24Mhz clock phase slipping relative to the GPS clock. Now take that rule and heat it up so the metal expands or throw it in the freezer for a while so it contracts. How accurate are measurements now?"

This all reminds me of the first Physics lab they used to teach at the university. Students often are confused by accuracy, resolution, precision and repeatability. Terms which are often misused interchangebly.

You can always add more decimals places (zeros) after a number to make it more precise. This does not mean it is more accurate or has higher resolution. In the case of the ruler, accuracy is limited by how the lines are printed on on rule when compared to a distance standard. Resolution is limited my the number of divisions per inch. In our case, accuracy is provided by the GPS clock, the resolution is provided by the 24Mhz clock. Precision is determined by the software math.

My guess is that there is some cancelation of errors going on. There is another fallacy in using the system itself to measure it's own accuracy and precision. In fact, the circuit appears to work more by chance of nature than by mathematical design. Yes the VCXO is being disciplined, but is it to the GPS or to the 24Mhz clock?"

Not convinced yet? Here is another situation. Assume the 24Mhz clock is in phase with the GPS clock, but is slightly off in frequency. Over a period of time the two will phase slip and there will be a point where they are 180 degrees apart. This is half a bit, does it get counted or not. This gets compounded by the fact that the 5Mhz/16 frequency and the 24Mhz are not harmonically related. Therefore, we are always measuring with fractional bit errors. Following this logic it is possible that the counter will undercount one bit for the entire 30 seconds. This would create a huge error to the PI loop. So I still ask, is the GPS or the 24Mhz clock disciplining the VCXO? The answer is both.

My conclusion is the accuracy of the frequency of VCXO is severely in question. Between the temperature drift and phase slip of the 24Mhz clock, there could be an inaccuracy in measurement of 2 bits. A count of 76 represents 360 degrees so the phase angle could be off almost 10 degrees. Huge error!

An alternate approach
I looked at alternatives. The simplest concept would be to simply measure the 5 Mhz frequency using the 1Hz as the timebase. Problem is, only 1Hz can be resolved. However, if I measure over 30 seconds instead of averaging, I could get 1/30 or .033hz. Same lousy number as my redesign idea. If the measurement period were increased to say 64 seconds (nice binary number) the resolution halves to .016hz. By increasing the VXCO to 20Mhz (increasing the millions) brings me up to 1 part in 1.28e9. At 1Gz this would provide 0.78Hz accuracy. Almost twice as good as the original design.

The nice part about this approach is that measurement accuracy depends entirely on the GPS signal. Frequency measurement is easy on a PiC microcontroller. Several designs for frequncy counters are already in use. The tricky part is that the VXCO needs to be syncronized to the microcontroller's internal clock. This leads to timing constraintes. Simple solution is to use the internal prescalers, but that thows away the part of the counter we are most interested in.

Solution is to use external divide by eight counter with a latch. The GPS 1Hz signal is used to trigger the latch to freeze the count. At the same time, the GPS signal drives the PIC ccp1 input to capture the internal counter. The counter runs continuously and is never stopped. Snapshots of the count are grabbed every second and accumulated for 64 seconds. Feeding the GPS to the t0clki pin makes for easy counting of the 64 seconds.

Part II - Roll my own temperature controller for a VXCO
Having done temperature controlled chambers on a larger scale before, I also considered making a small chamber to house the VXCO. Some experimentation with a crude mock-up showed that a 1 watt heater will raise the temperature to 100+ degrees F in less than an hour.

Frequency measurement is done mostly in the hardware of the microcontroller. Hence, the CPU time is barely utilized except when the PI control algorithim runs once every 30 seconds. Thserefore, the temperature controller could quite easily be done on the same microcontroller.

Heater control is simple to implement using the microcontroller's timer 2 and CCP2 module in PWM mode. The CCP2 output drives a transistor (2N4401 since current is only 70 ma). Using the same PI control algorithim with differnt coefficients makes a tightly controlled temperature loop. A LM75 temperature to digital sensor (via SPI), the tempurature can be sensed with 0.0625 degree Centigrade resolution.

Frequency drift vs temperature
In theory, the termperature of the VXCO could be held to +/-0.0625 degrees C. If the VXCO has +/-50ppm change over a -40 to +85 degree C range the drift would be:

20Mhz * (100ppm / 125 degC) * 0.0625 degC = 1Hz

Not acceptable. Okay, what temperature resolution would be needed to get better that the .033Hz resolution of the frequency control?

.016Hz / [20Mhz * (100ppm / 125 degC)] = 0.001 deg C

Ja right that wouldn't be possible.

Bells and whistles
Another nice feature would be using 13.8VDC instead of the 24VDC often required for commercial TCVCXO's. This would alllow prortable/mobile operation or battery backup in case of power outages. A consideration since it takes considerable time to become stable.