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

Tom Van Baak tvb at leapsecond.com
Sun Oct 23 18:16:54 EDT 2005


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.

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.

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 OCXO
> Controller design is excellent for use with an HP 10811, there are
> challenges to using the standard design with low sensitivity oscillators.
> 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 controller
> span. To interface the controller to a typical HP 10811 the output is fed
> 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 match
> 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 amplifying
> the DAC noise, which can adversely affect the short-term stability of the
> oscillator. By feeding an inverting summing amplifier and inverter with
the
> offset and controller outputs and driving the oscillator from the inverter
> output, an effective gain of 2 was realized by removing the frequency trim
> pot from the controller path without adding additional gain to amplify the
> 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, but
> 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. (Up
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 the
> 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 code
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 filter
> modes, and higher gains result in other design issues making an additional
> 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 gain
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 factor
> 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, a
> 74HC165 shift register, and a 50MHz oscillator in the phase detector. The
> 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 down
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 the
> 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 the
> filter constant. This requires more stability in the oscillator to be
> effective, which is just what a rubidium oscillator offers. Each doubling
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. Increasing
> 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 properly
> 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 suppressed
> when using a rubidium oscillator, and the Shera design has an Alpha filter
> 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 controller
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 highest
> 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 the
> 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 going
> 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 coefficients.
> >
> > 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






More information about the time-nuts mailing list