Budget GPSDO - complete

[MIS42N]

It turns out the hunting behaviour seen in the previous posts was due to a design decision made quite a while back. The control algorithm has to deal with two things: (1) The difference between the frequencies of the local oscillator and the implied frequency from the 1PPS timing (2) the phase difference between the local oscillator and the implied frequency from the 1PPS timing.

When a deviation is noted, correcting fully for both generates larger changes of control voltage than correcting fully for one and partially for the other. Live testing seemed to give better figures if the phase difference was fully corrected and the frequency difference partially corrected. The full/partial strategy always gets the local oscillator headed in the right direction, it just takes longer to reach an equilibrium than full/full. When dealing with a GPS signal that varies in the short term, the calculation usually has some sort of residual error due to that variation. This is enough so the calculated equilibrium point is different after the next measurement period and the fact that full equilibrium was not reached is irrelevant because the target has moved.

But the LEA-M8T provides a more reliable 1PPS, and maybe the OCXO is the cause of most deviations. Those deviations seem to be jumps in frequency. So when the frequency is not fully compensated but the phase is compensated, the algorithm takes a while to get the phase right, but the partially compensated frequency is wrong so the algorithm overshoots, causing a decaying oscillation in the control voltage. The hunting behavior is explained.

Fully compensating for frequency and partially for phase eliminates the hunting behaviour. Without recourse to a higher precision local standard it is hard to tell if this results in a more stable frequency. So is it worth changing the published program? probably not. The limiting factor appears to be the quality of the oscillator, in this case a cheap second hand OSC5A2B02 which (from the plot below) is ageing markedly. The graph shows a significant jump change in control voltage presumably where something significant happened to the oscillator. Unlikely to be an external event as this setup was undisturbed for several days.

[PA0KTF]

I recently bought a FE-5680A (Rubidium 10MHz reference). In a message on time-nuts dated 11/17/2011 a method is described to connect an analog control voltage to the FE-5680A reference. This results in the following range: Input 1.0V with frequency deviation +0.02 Hz and input 4.0V with frequency deviation -0.02 Hz. You can see immediately the problem with the calibration using your software: The +/- 0.25 Hz points in the calibration is far more than the +/- 0.02 Hz. Is there a way to adjust your software for use with the FE-5680A ? Thanks in advance.

[MIS42N]

Input 1.0V with frequency deviation +0.02 Hz and input 4.0V with frequency deviation -0.02 Hz. You can see immediately the problem with the calibration using your software: The +/- 0.25 Hz points in the calibration is far more than the +/- 0.02 Hz. Is there a way to adjust your software for use with the FE-5680A ? Thanks in advance.

The 0.25Hz figure is a shift in the 1PPS of 25ns/second. The hardware only detects to the nearest 25ns so that provides an easy measurement - is the 1PPS arriving 1 period (25ns) earlier or later per second. It would be possible, but not really practical, to look for 1 period change per 32 seconds (as an example). That would be +/- less than 0.01Hz. However to get any precision in the value the test would need to run for longer periods. The limiting factor is the precision (or lack of it) in timing the 1PPS. For cheap GPS modules, cheap oscillators it's not a big deal. For a rubidium standard it is probably too sloppy.

Even if this was done, it may break the calculations. The calibration stores a number which is the change of control voltage (representing 5V as a 24 bit number) to get an 0.25Hz change of frequency. If the full range 0 to 5V is not enough to get a 0.25Hz change then that number is bigger than 24 bits and I'm not sure how the calculation would handle it. It might work, the math package is 32 bit, and for most calculations the number is turned into a peudo floating point with 13 bits precision and only converted back to integer when calculating a voltage change (which has to be within the pulling range).

Assuming the calculations don't break, it would be possible to cut out the calibration phase of the program and replace it with code that directly writes the calibration data to non volatile memory (after hand calculating that V/Hz figure). Just how it would behave is a matter of speculation. Good luck.