RE: phase locking Rb to GPS (was time-nuts Digest, Vol 14, Issue 30)
Hi Richard:
It's my understanding that this optimization can be done by changing the
oscillator power level at the crystal.
In the case of the 32768 Hz watch crystal, it must be run a very low
power and it has a very low aging rate when compared to higher frequency
crystals that are typically run at higher power levels. I think this is
related to the crystal throwing off atoms, so more power means more
acceleration and more atoms thrown off.
Have Fun,
Brooke Clarke, N6GCE
--
w/Java http://www.PRC68.com
w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com
Richard H McCorkle wrote:
. . . snip . .
Since both units are the same model, but with different
P/N and both meet the OCXO134-10 spec but have different characteristics I
believe they were each optimized for a different characteristic when
originally ordered, one for low aging, and one for high stability.
Richard,
thanks for your answer. I got my OCXO134-12 from eBay (NOS), and so far I
have been unable to find its exact specs, as it is not reported on the
Isotemp Web site (only the -10 is there). An email to them remained without
answer, of course... probably it was a special build for some telecom
companies (the guy I bought it from, was in Korea...)
73 Alberto I2PHD
Richard H McCorkle wrote:
While I have not used an Isotemp OCXO134-12 specifically, I am
currently running two different OCXO134-10 units in 2 different GPS
receivers.
[snip]
Careful, there's no such thing as a free lunch. Reducing the power to the
oscillator improves the long-term stability (drift) at the expense of
short-term stability.
-RL
Robert Lutwak, Senior Scientist
Symmetricom - Technology Realization Center
34 Tozer Rd.
Beverly, MA 01915
(978) 232-1461 Voice RLutwak@Symmetricom.com (Business)
(978) 927-4099 FAX Lutwak@Alum.MIT.edu (Personal)
(339) 927-7896 Mobile
----- Original Message -----
From: "Brooke Clarke" brooke@pacific.net
To: "Richard H McCorkle" mccorkle@ptialaska.net; "Discussion of precise
time and frequency measurement" time-nuts@febo.com
Sent: Sunday, October 23, 2005 2:29 PM
Subject: Re: [time-nuts] RE: phase locking Rb to GPS
Hi Richard:
It's my understanding that this optimization can be done by changing the
oscillator power level at the crystal.
In the case of the 32768 Hz watch crystal, it must be run a very low power
and it has a very low aging rate when compared to higher frequency
crystals that are typically run at higher power levels. I think this is
related to the crystal throwing off atoms, so more power means more
acceleration and more atoms thrown off.
Have Fun,
Brooke Clarke, N6GCE
--
w/Java http://www.PRC68.com
w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com
Richard H McCorkle wrote:
. . . snip . .
Since both units are the same model, but with different
P/N and both meet the OCXO134-10 spec but have different characteristics I
believe they were each optimized for a different characteristic when
originally ordered, one for low aging, and one for high stability.
--
w/Java http://www.PRC68.com
w/o Java http://www.pacificsites.com/~brooke/PRC68COM.shtml
http://www.precisionclock.com
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
From: "Robert Lutwak" Lutwak@Alum.mit.edu
Subject: Re: [time-nuts] RE: phase locking Rb to GPS
Date: Sun, 23 Oct 2005 16:43:34 -0400
Message-ID: 000701c5d812$708718c0$cc1b10ac@lutwakhome
Careful, there's no such thing as a free lunch. Reducing the power to the
oscillator improves the long-term stability (drift) at the expense of
short-term stability.
Indeed, but you can also handle that by using two oscillators, one for long-
term stability and one for short-term and lock the short-term to the long-term
oscillator with a suitable PLL bandwidth. Comes at some additional cost, but
then you can optimize each end better rather than compromizing on one crystal
oscillator. That ain't a free lunch either. In the end, you should not stare at
the numbers, one must recall the intended application and make that work.
Cheers,
Magnus
Indeed, but you can also handle that by using two oscillators, one for
long-
term stability and one for short-term and lock the short-term to the
long-term
oscillator with a suitable PLL bandwidth. Comes at some additional cost,
but
then you can optimize each end better rather than compromizing on one
crystal
oscillator. That ain't a free lunch either. In the end, you should not
stare at
the numbers, one must recall the intended application and make that work.
You've hinted at the scenario that I often use here
in my lab. I do use two oscillators. For short-term
I use a nice quartz OCXO -- free running. And for
long-term I use daily averages of 1PPS pulses from
a GPS receiver.
But they are not disciplined; it's just two completely
separate references. Neither helps the other but also
neither pollutes the other.
This works because, in most cases, for me at least,
absolute accuracy is not critical during short-term,
low-noise measurements. And similarly, undisciplined
averaged sawtooth corrected raw GPS 1 PPS timing
provides a slightly better long-term reference than a
GPSDO provides. So you get the best of both worlds.
Granted a GPSDO sort of gives you both in the same
box but do you lose a bit of performance on either end
as a result.
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@ptialaska.net
To: "Discussion of precise time and frequency measurement"
time-nuts@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@murgatroid.com
To: time-nuts@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@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@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
----- Original Message -----
From: "Tom Van Baak" tvb@leapsecond.com
To: "Discussion of precise time and frequency measurement"
time-nuts@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@ptialaska.net
To: "Discussion of precise time and frequency measurement"
time-nuts@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@murgatroid.com
To: time-nuts@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@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@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Be aware that Brooks can modify the sensitivity of his PIC for a
rubidium. Brooks has made me several custom PICS for my FRS-C.
I used his controller without any of its offsets circuits. I built a
summing amp and summed the output of the controller, with a precision
variable voltage reference circuit based on the LM199. I set the
precision reference to the voltage it needs to put the rubidium on UTC,
and then let the controller step around to control it.
I had Brooks to modify the PIC for an different update rate. The stock
units are 30 seconds. We have tested a unit at 120 seconds, and I am
testing a unit at 60 second update rates. Some of the data is pointing
to optimized design around 81 seconds.
I plan to publish the results in the future - but the long term test
take about 5 days for each test - and the unit is being tested against
several reference oscillators. Doing all combinations of timebases,
results in 20 some test that have to be performed.
Brian - N4FMN
Richard H McCorkle wrote:
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@murgatroid.com
To: time-nuts@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@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@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Be aware that Brooks can modify the sensitivity of his PIC for a
rubidium. Brooks has made me several custom PICS for my FRS-C.
See, this makes much more sense to me. His architecture
is fine and when you swap an OCXO for an Rb things like
EFC gain, range, and span are just part of the problem. I
would guess TIC and PLL time constants are a bigger part
of the equation. You need to match the Rb ADEV. This is
simple with modified source code; way harder (impossible?)
with external hardware hacks.
I used his controller without any of its offsets circuits. I built a
summing amp and summed the output of the controller, with a precision
variable voltage reference circuit based on the LM199. I set the
precision reference to the voltage it needs to put the rubidium on UTC,
and then let the controller step around to control it.
Yup, this makes sense.
I had Brooks to modify the PIC for an different update rate. The stock
units are 30 seconds. We have tested a unit at 120 seconds, and I am
testing a unit at 60 second update rates. Some of the data is pointing
to optimized design around 81 seconds.
Can't wait to see that data. Given Shera's TIC resolution
and GPS noise, I would have guessed much longer than
that. See the PRS10 plot, for example:
http://www.thinksrs.com/assets/instr/PRS10/PRS10diag2LG.gif
The other thing I'm wondering is what you're trying to
optimize. A high update rate or short time constant
may be good for a GPS time standard but bad for a
GPS frequency standard. I don't think you can have
it both ways.
I plan to publish the results in the future - but the long term test
take about 5 days for each test - and the unit is being tested against
several reference oscillators. Doing all combinations of timebases,
results in 20 some test that have to be performed.
Brian - N4FMN
Have you considered doing all of this with some sort of
software simulation? If you take 5 days of real GPS data
and 5 days of real Rb data (or OCXO data, etc.) my gut
tells me it shouldn't be that hard to then wrote code to
simulate the entire thing and get answers in a matter of
minutes. Then change the parameters and run it again.
As a by-product you'll get ADEV plots of GPS, the LO,
and the virtual GPSDO.
/tvb
From: "Tom Van Baak" tvb@leapsecond.com
Subject: Re: [time-nuts] RE: phase locking Rb to GPS
Date: Sun, 23 Oct 2005 14:42:39 -0700
Message-ID: 001201c5d81a$b1b1dc60$c621f304@computer
Tom,
Indeed, but you can also handle that by using two oscillators, one for
long-
term stability and one for short-term and lock the short-term to the
long-term
oscillator with a suitable PLL bandwidth. Comes at some additional cost,
but
then you can optimize each end better rather than compromizing on one
crystal
oscillator. That ain't a free lunch either. In the end, you should not
stare at
the numbers, one must recall the intended application and make that work.
You've hinted at the scenario that I often use here
in my lab. I do use two oscillators. For short-term
I use a nice quartz OCXO -- free running. And for
long-term I use daily averages of 1PPS pulses from
a GPS receiver.
But they are not disciplined; it's just two completely
separate references. Neither helps the other but also
neither pollutes the other.
This works because, in most cases, for me at least,
absolute accuracy is not critical during short-term,
low-noise measurements. And similarly, undisciplined
averaged sawtooth corrected raw GPS 1 PPS timing
provides a slightly better long-term reference than a
GPSDO provides. So you get the best of both worlds.
Granted a GPSDO sort of gives you both in the same
box but do you lose a bit of performance on either end
as a result.
Indeed. In what I described the short-term oscillator cleans up the short-term
noise of the long-term oscillator while the long-term oscillator takes over the
long-term part from the short-term oscillator and you get pieces of the best
in one signal. The type of PLL loop does makes a difference at the cross-point
between the oscillator responces. Also, a Kalman filtered version would be able
to stabilize at a point which is optimum (for some measure of optimum that is)
for those two oscillators at that point in time.
If you want GPSDO, you can build a line of oscillators, each cleaning up their
region of the phase-noise spectrum / tau-region.
Doing it the way you do in your lab will work for some work, but for other
things you do want synchronous clocks and performance, so you have to lock them
up one way or another.
Cheers,
Magnus