[GPS_Standard] GPSstd_PLL - today's plot of SM1/SM2 at about 53 hours in

[Dave Platt]

> As far as the rapid excursions, those seem closely related to when I turn the thermostat down at night and when the sun comes out in the morning.  I hadn't noticed the connection till now.  My program does not do a very good job of managing thermal drift.  Dave and I tried a number of different things, but none were reliably better.  Thanks for pointing it out.   One of the reasons for posting these is to get the input from a few more eyes.

A somewhat similar plot from my own system can be seen at

http://snulbug.mtview.ca.us/dave/rubidium-offset.png

This plot shows three sets of values, over about an 18-hour period.
The DAC value is shown in red (lefthand vertical axis).  A computed
"parts per billion of frequency error, over the last hour of operation"
is shown in green (righthand vertical axis).

And, a phase offset is shown in blue (arbitrary axis)... the height
of the blue stripe corresponds to one full 360-degree cycle).

The phase offset being show here is the offset between the GPSDO
output, and the output of a Datum 10 MHz rubidium frequency standard.
The rubidium standard is (I believe) quite stable once it's well warmed
up, but its long-term average frequency is probably not as good as the
GPSDO with the firmware I'm currently running.  The phase measurement
was taken using my Rigol digital storage scope, and the data merged
into the serial stream captured from the GPSDO controller.

My GPSDO shows quite a bit of temperature sensitivity.  A lot of the
work I've done with Bob has been aimed (in my head, that is) at enabling
the GPSDO to compensate for the temperature-related drift, by adding
an "integral" error control stage to Bob's state-machine system.

When things are at their best - when the temperature is either stable,
or is drifting at a steady rate - the GPSDO with my "integrator"
firmware matches the rubidium frequency quite well.  You can
see this between 11:30 and 13:00, for example.  When the "rate of
temperature change" isn't steady - e.g. when the sun first hits the
garage in the morning, or goes down at night - it takes a while for
the error integrator to "catch up".

[So... things are good when the second differential of temperature
 is near zero, and drifty when it is not.]

I'm currently experimenting with ways to stabilize the temperature
of the whole GPSDO system... in effect, adding a second "oven" in
addition to the ovenized VCO.  I've added a small thermostatically
controlled heater to the interior of the box, and built an insulating
outer shroud out of 1.5" poly foam (R5 or so).  This seems to
be helping matters quite a bit.  I might also add a bunch of thermal
mass to the assembly (a heavy metal plate or a sheet of marble or
something like that) to slow down the rate of temperature drift.