[time-nuts] RE: phase locking Rb to GPS (was time-nuts Digest, Vol 14, Issue 30)

Richard H McCorkle mccorkle at ptialaska.net
Sun Oct 23 20:21:44 EDT 2005

----- Original Message ----- 
From: "Tom Van Baak" <tvb at leapsecond.com>
To: "Discussion of precise time and frequency measurement"
<time-nuts at febo.com>
Sent: Sunday, October 23, 2005 2:16 PM
Subject: Re: [time-nuts] RE: phase locking Rb to GPS (was time-nuts
Digest,Vol 14, Issue 30)

> Thanks for the detailed analysis. Maybe I didn't read it
> right, but could you explain a bit more about the words
> gain, span, and range?
> I ask because if I understand your description you
> seem to imply that one needs or wants the same
> controller range for Rb as for OCXO.
> Wide range is needed (say several Hz out of 10 MHz)
> for OCXO since over many years an OCXO will drift
> out of PLL tuning range. But you don't need (or can't
> even get) the same range for Rb.
> Instead of using Hz or volts or percent or ppm for
> span or range or whatever; use units of years. If you
> want unattended GPSDO operation for N years that
> tells you how much PLL range you need. It's the
> LO frequency aging rate that dictates this, not the
> DAC gain or the dF/dV EFC sensitivity.

In working with the Shera design, the stock controller expects that for min
to max DAC output the oscillator will change in frequency 4.5e-8, what I
refer to as controller span. To maintain the same damping factor in the
controller as the original design the gain (DAC count change vs. oscillator
frequency change) needs to be adjusted to produce a 4.5e-8 frequency change
from min to max DAC count. The available frequency control range of a
rubidium is so much smaller than the controller span of the standard Shera
controller that it is impossible to change a rubidium's frequency by that
amount, so only a small portion of the DAC count range can be used. What I
meant to imply is that a much smaller controller span is more suitable for
use with a rubidium oscillator.  Reducing the controller span from 4.5e-8 to
5.4e-9 or 2.7e-9 is still wider than the rubidium can use, but closer to the
desired range (min F to Max F for the oscillator) than the stock controller.
In trade for reducing the controller span, there is a smaller frequency
change per DAC step to increase the resolution, but the controller damping
is maintained at the original design point.

> The other question I had was about your suggestion
> to use a higher clock rate or shorter sampling time
> with Rb. This doesn't make sense to me. If anything
> I would think you'd want to use a longer sampling
> time with Rb since it has much better mid-term stability
> than an OCXO.

The standard system counts the number of 24MHz clocks gated into the counter
by the phase detector once per second. Once 30 seconds worth of samples have
accumulated, the count is read and this 30 second accumulation is a single
"sample" for the controller. Changing the clock rate to 50MHz and increasing
the speed of the divided 10MHz reference to 625KHz instead of the original
312KHz results in nearly the same count being returned after 30 seconds as
the original design, but each count represents half the phase change of an
original count. By doubling the number of samples collected to 60 instead of
30 and dividing the result by 2 to make a single "sample" for the controller
the actual "sample" time is twice as long as the original. The sample count
passed to the controller is still approximately the same count as the
original, so the limits set in the software will work without other changes,
but one count difference in the phase count now represents half the phase
change that one count of the original design does. Using a "sample"
collected over a longer time period with better resolution to calculate a
response using a longer filter time and smoothing the result using the Alpha
filter makes the short-term variations in EFC from the controller smaller
than the short-term stability of the oscillator, and a very gradual steering
of the rubidium results. The prototype LPRO uses a 23-bit DAC and the
controller reports a 23-bit EFC. From the deviation graphs developed on the
prototype, using a 12-hour filter plus the Alpha filter the max EFC
(converted to frequency) deviation rises slowly from 3e-14 at 60 sec to
2.5e-13 at 4000 sec, so it's not like the controller is moving the rubidium
very fast.

> I use to joke that the best, simplest way to make a
> GPSDO with an Rb is to just change the EFC once
> a day. There is some truth to this.
> /tvb
> ----- Original Message -----
> From: "Richard H McCorkle" <mccorkle at ptialaska.net>
> To: "Discussion of precise time and frequency measurement"
> <time-nuts at febo.com>
> Sent: Saturday, October 22, 2005 19:53
> Subject: Re: [time-nuts] RE: phase locking Rb to GPS (was time-nuts
> Digest,Vol 14, Issue 30)
> > While the Brooks Shera (http://www.rt66.com/~shera/index_fs.htm) GPS
> > Controller design is excellent for use with an HP 10811, there are
> > challenges to using the standard design with low sensitivity
> > The Shera controller uses a 24MHz phase counter design with the gain set
> for
> > a 7.5e-9 / volt sensitivity over a +/- 3 volt span, or a 4.5e-8
> > span. To interface the controller to a typical HP 10811 the output is
> > through a divider to the bottom of a frequency trim pot. A precision
> > reference voltage is fed to the top of the pot, and the oscillator EFC
> input
> > is driven from the wiper. The frequency trim pot provides a fixed offset
> > voltage to set the frequency, and this voltage is "modulated" by the
> > controller output to maintain GPS lock. This design works well with
> > oscillators capable of frequency spans of 1e-7, and sensitivities of >
> > 1.5e-8/volt. Less sensitive oscillators require different methods to
> > the oscillator sensitivity to the controller span.
> >     In interfacing an Isotemp mil spec version of the HP 10811B with a
> > sensitivity of 9.7e-9/volt and a span of 4.85e-8 to the Shera controller
> > even with RA and RB removed and the DAC feeding the frequency trim pot
> > directly the pot acts as a divide by 2 to the controller output; and
> > additional gain would have been required to match the controller span.
> > Adding an additional gain stage after the DAC output results in
> > the DAC noise, which can adversely affect the short-term stability of
> > oscillator. By feeding an inverting summing amplifier and inverter with
> the
> > offset and controller outputs and driving the oscillator from the
> > output, an effective gain of 2 was realized by removing the frequency
> > pot from the controller path without adding additional gain to amplify
> > DAC noise. Using this arrangement allowed the lower sensitivity Isotemp
> > oscillator to be matched to the 4.5e-8 controller span without adding
> > additional gain.
> >      Rubidium oscillators can be used with the standard Shera design,
> > the low sensitivity (1e-9/volt for my LPRO, 4.5e-10/volt for my FRS-C)
> > requires the gain to be 9x - 20x normal to match the controller span.
> to
> > 40x for the FRS-C with the original frequency pot arrangement!)
> Multiplying
> > the DAC noise by a factor of 9x - 20x is not a good approach for
> maximizing
> > short-term stability in a precision oscillator. The available span for
> > LPRO is 5e-9, so it can only use 12% of the available 4.5e-8 controller
> span
> > if matched with an external gain stage. The FRS-C has a span of 2.25e-9,
> and
> > can use only 5% of the controller span. Brooks will share his source
> if
> > you ask him nicely, so modifications to the controller software are
> > possible. But just increasing the gain 2x in the controller software
> > requires changing the limiter and restricting the span in the lower
> > modes, and higher gains result in other design issues making an
> > gain of 2x the practical limit, and only with additional work on the
> > limiter.
> >      There are other options to achieve the required gain, and for
> rubidium
> > oscillator control they are  appropriate. One method to increase the
> is
> > to use a faster clock and a shorter sample time. Operation of a similar
> > design using 74F163 counters at speeds up to 125MHz is possible. Due to
> path
> > delays encountered in high-speed operation, layout becomes a major
> > for reliable operation at speeds above 50MHz. Standard perf-board
> techniques
> > work well up to 50MHz, so a design was tested using two 74F163 counters,
> > 74HC165 shift register, and a 50MHz oscillator in the phase detector.
> > counter is read and reset each second and the results accumulated in the
> > PIC. The result is scaled for the sample time chosen (divide by 2 for 60
> > sec) and fed to the process. The sample divider used was an ST 74HC393
> dual
> > binary counter, with one divider used to divide the 10MHz oscillator
> to
> > 625KHz to feed the phase detector and the second divider used to divide
> the
> > 50MHz clock by 4 to supply a 12.5MHz clock for the PIC. The faster clock
> > reduces the controller span from 4.5e-8 to 2.16e-8, still well beyond
> > span of a rubidium oscillator. It also increases the controller
> sensitivity
> > to 3.6e-9/volt giving an effective gain of 2.08 over the original 24 MHz
> > design.
> >      Another approach to increasing the effective gain is to increase
> > filter constant. This requires more stability in the oscillator to be
> > effective, which is just what a rubidium oscillator offers. Each
> of
> > the filter constant effectively increases the gain by 2. Increasing the
> > filter constant becomes the best way to get the gain required for a
> rubidium
> > oscillator controller without adding an additional gain stage.
> > the sample time to 60 sec results in a controller sensitivity of
> 9e-10/volt
> > with a 5.4e-9 span using a 50 MHz clock. This configuration will
> > drive an LPRO with 1e-9 / volt sensitivity using 93% of the available
> > controller span. For the lower sensitivity FRS-C, the F1 filter constant
> is
> > adjusted 1 step to scale the filter by an additional factor of 2. This
> > results in a controller sensitivity of 4.5e-10 / volt and a span of
> 2.7e-9.
> > This provides a proper match to the FRS-C sensitivity, using 83% of the
> > available controller span.
> >      Because a rubidium oscillator has poorer short-term stability when
> > compared to a good OCXO, short-term variations in EFC should be
> > when using a rubidium oscillator, and the Shera design has an Alpha
> > available to do just that. Once stable in your selected mode, the Alpha
> > filter should be employed to maximize short-term stability. Keep in mind
> > that the filter constant is now 2x or 4x longer than the stock
> so
> > you are effectively starting the IIR filter in mode 3 or 4 and going up
> from
> > there to effectively mode 8 or 9.  The filter settle time for the
> > modes become 1 to 2 days, and this can be too long to correct for daily
> > variations in the environment. Settle times of about 12 hours produced
> > best long-term stability, with typical 1 day stability of < 5e-13 being
> > achieved using a combination of these techniques on an LPRO.
> >
> > ----- Original Message -----
> > From: "Christopher Hoover" <ch at murgatroid.com>
> > To: <time-nuts at febo.com>
> > Sent: Sunday, September 18, 2005 10:40 AM
> > Subject: [time-nuts] RE: phase locking Rb to GPS (was time-nuts Digest,
> Vol
> > 14, Issue 30)
> >
> >
> > >
> > > On 9/18 "Tom Clark, W3IWI" <w3iwi at toad.net> wrote:
> > >
> > >    The frequency knob that you tweak to correct the Rb frequency
> > >    passes some tens of ma thru a coil surrounding the RF interaction
> > >    region. If you try to phase lock a Rb to GPS, you need to develop
> > >    a current source error signal.
> > >
> > > Hmmm ... can you say more about this current source error signal?
> > >
> > > I've been thinking of locking my Rb standard to GPS.  I was simply
> > to
> > > use the same circuit (1 pps, 10 MHz in; analog EFC voltage out) that I
> > have
> > > running with my OXCO but with different filter and EFC DAC
> > >
> > > So is this not sufficient to phase lock GPS to a Rb standard?
> > >
> > > Naively,
> > > -- Christopher.
> > >
> > >
> > > _______________________________________________
> > > time-nuts mailing list
> > > time-nuts at febo.com
> > > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> >
> >
> > _______________________________________________
> > time-nuts mailing list
> > time-nuts at febo.com
> > https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> _______________________________________________
> time-nuts mailing list
> time-nuts at febo.com
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts

More information about the time-nuts mailing list