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

[Chris Howard w0ep]

Thanks to both of you for the explanation.

I'm rather surprised at the amount of phase change.
When the ZAZ controller comes up as a subject on the time-nuts
list, there seems to be some mild disdain for the design
because it tracks frequency and not phase.

So I was surprised to see these vertical motions in your phase
plots.

I can't say I really know what I'm talking about.

In Dave's plot I see some correlation between the
DAC direction and the phase direction.  I say that
because the direction changes (peaks) in the phase
seem to precede similar peaks in the red.  That's
kind of cool.

Wait a minute... that would be because you
are reading the phase and steering the DAC... duh.





On 11/14/2013 3:11 PM, Dave Platt wrote:
> 
>> 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.
> 
> 
> 
> ______________________________________________________________
> GPS_Standard mailing list
> Home: http://mailman.qth.net/mailman/listinfo/gps_standard
> Help: http://mailman.qth.net/mmfaq.htm
> Post: mailto:GPS_Standard at mailman.qth.net
> 
> This list hosted by: http://www.qsl.net
> Please help support this email list: http://www.qsl.net/donate.html
> 
>