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

[Bob Stewart]

Chris says:
"I'm rather surprised at the amount of phase change."

Don't gloss over the fact that it is phase change and not frequency change.  A phase change of 360 degrees is only 1 cycle out of 10,000,000 cycles if it happens during a one second window.  If it happens over an hour, then it is 1 cycle out of 36,000,000,000 cycles.  That's 1 cycle out of 36 billion or .028ppb.  That's why it is so hard to accomplish actual phase lock.  

Another reason is the extremely large dead band we have away from phase zero.  Dave is trying the approach of integrating errors over time.  I am trying to get the data directly out of the area within 10ns of phase zero in my new efforts.  If Dave succeeds, his code is likely to be less noisy than mine due to how we're going at the problem.

Bob





>________________________________
> From: Chris Howard w0ep <w0ep at w0ep.us>
>To: Dave Platt <dplatt at radagast.org>; gps_standard at mailman.qth.net 
>Sent: Thursday, November 14, 2013 3:58 PM
>Subject: Re: [GPS_Standard] GPSstd_PLL - today's plot of SM1/SM2 at about 53 hours in
> 
>
>
>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
>> 
>> 
>______________________________________________________________
>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
>
>
>