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.
From: "Christopher Hoover" ch@murgatroid.com
Subject: [time-nuts] RE: phase locking Rb to GPS (was time-nuts Digest, Vol 14, Issue 30)
Date: Sun, 18 Sep 2005 11:40:36 -0700
Message-ID: 20050918184006.D6ACEA00031@mail.murgatroid.com
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?
In practice you usually see a voltage input on Rb standard. I have one on mine,
it is directly converted into current which drives the C-field coil.
Cheers,
Magnus
Magnus is correct that many Rb's have a voltage
input EFC control. But in case yours needs a
current source, the note below, which is an
excerpt from some notes on how the drive an
Efratom FRK-L from a gps controller, might be a
start.
The FRK-L has one end of the C-coil grounded and
the other fed by a resistor network. The resistor
Rc mentioned below is the piece of the network
that connects to the C-coil.
If you happen to have an FRK-L I can send you the
entire notes file. In the case of the FRK-L the
sensitivity was df/f = 2.2x10-9 per ma, so the
current change needed to swing the frequency over
a reasonable range was quite modest.
Modifications for locking to GPS
The DAC in my gps controller board (see QST, July
'98 or www.rt66.com/~shera) can operate in either
a voltage (+/- 3v) or a current mode (+/- 1ma),
however the PCB distributed by A&A is wired to use
it in a voltage mode. A voltage source can be used
as current source if it drives a low impedance
through a relatively larger series impedance. With
this in mind, and to conveniently match the FRK-L
to the sensitivity presently programmed into the
digital PLL in the controller, I have chosen to
control the C-coil current by attaching a resistor
at the Rc - C coil junction. The DAC is connected
directly to the other end of this resistor. The
value needed for the resistor turns out be 250
ohms (I used a 270). I wired the resistor inside
the unit so if I accidentally applied a large
voltage, like +5v, to the C-coil connector pin I
wouldn't burnout the C coil.
Regards, Brooks
----- Original Message -----
From: "Magnus Danielson" cfmd@bredband.net
To: time-nuts@febo.com; ch@murgatroid.com
Sent: Sunday, September 18, 2005 12:45
Subject: Re: [time-nuts] RE: phase locking Rb to
GPS
From: "Christopher Hoover" ch@murgatroid.com
Subject: [time-nuts] RE: phase locking Rb to GPS
(was time-nuts Digest, Vol 14, Issue 30)
Date: Sun, 18 Sep 2005 11:40:36 -0700
Message-ID:
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?
In practice you usually see a voltage input on
Rb standard. I have one on mine,
it is directly converted into current which
drives the C-field coil.
From: "Brooks Shera" ebs@starband.net
Subject: Re: [time-nuts] RE: phase locking Rb to GPS
Date: Sun, 18 Sep 2005 15:11:48 -0600
Message-ID: 004101c5bc95$a10167a0$0200a8c0@EBS8500
Magnus is correct that many Rb's have a voltage
input EFC control. But in case yours needs a
current source, the note below, which is an
excerpt from some notes on how the drive an
Efratom FRK-L from a gps controller, might be a
start.
The FRK-L has one end of the C-coil grounded and
the other fed by a resistor network. The resistor
Rc mentioned below is the piece of the network
that connects to the C-coil.
In the R&S XSRM Rb-standard (which I have), the 0 - 10V input goes straight
into the resistor network and coil setup as you described. The range is 1E-9.
Pretty much as your FRK-L modification, but this one is standard issue and
comes with a BNC in the back, as you would prefer.
PS. Anyone got the manuals for the frequency-converter XSRM-Z and the phase-
comparator XSRM-Z3? I would enjoy having them. Have the XSRM RB-standard and
XSRM-Z PSU manuals with schematics.
Cheers,
Magnus
PS. Anyone got the manuals for the frequency-converter XSRM-Z and
the phase-
comparator XSRM-Z3? I would enjoy having them. Have the XSRM
RB-standard and
XSRM-Z PSU manuals with schematics.
Try www.telford-electronics.com for R&S manuals. (Even if it's not listed
on their website, email them... they may be able to get it.)
-- john, KE5FX
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
Richard H McCorkle wrote:
[snip]
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 [snip]
Richard,
do you perhaps have any experience of using the Isotemp OCXO134-12 unit ?
I built a GPSDO using it, and it works rather well, were it not for a
residual oscillation of the frequency of about +- 2E-11. i.e. +- 0.0002Hz
at 10MHz, with an oscillation period of about 7 minutes, which is too fast
to be corrected by the PI software loop.
I attributed it, lacking other explanations, to an imperfect temperature
control of the oven. Translated in temperature terms, that frequency
oscillation amounts to a change of about 0.18 degrees Celsius.
What you think about this ? TNX
73 Alberto I2PHD
Speaking as a process control engineer, it sounds like
too much gain. You can verify that it is the oven by
warming up the device somehow. That should change the
period of oscillation. If it is still 7 minutes then
reduce the gain somehow.
You can elevate the temperature of the device by
putting it in a large cardboard box with a 60 or 100 watt
incandescent light. Monitor the temperature.
Regards
Bill Hawkins
-----Original Message-----
From: time-nuts-bounces@febo.com [mailto:time-nuts-bounces@febo.com]On
Behalf Of Alberto di Bene
Sent: Sunday, October 23, 2005 10:30 AM
To: Discussion of precise time and frequency measurement
Subject: [time-nuts] RE: phase locking Rb to GPS
Richard H McCorkle wrote:
[snip]
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 [snip]
Richard,
do you perhaps have any experience of using the Isotemp OCXO134-12 unit ?
I built a GPSDO using it, and it works rather well, were it not for a
residual oscillation of the frequency of about +- 2E-11. i.e. +- 0.0002Hz
at 10MHz, with an oscillation period of about 7 minutes, which is too fast
to be corrected by the PI software loop.
I attributed it, lacking other explanations, to an imperfect temperature
control of the oven. Translated in temperature terms, that frequency
oscillation amounts to a change of about 0.18 degrees Celsius.
What you think about this ? TNX
73 Alberto I2PHD
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Bill Hawkins wrote:
Speaking as a process control engineer, it sounds like
too much gain. You can verify that it is the oven by
warming up the device somehow. That should change the
period of oscillation. If it is still 7 minutes then
reduce the gain somehow.
I can't reduce the gain of the temperature controlling
circuitry, as it is sealed inside the oven. The only thing
I have control of, is the EFC voltage applied to the OCXO.
I made an experiment when testing the GPSDO, I blew on the
ovened oscillator assembly, and measured the EFC changes,
translated into frequency changes. The plot is in the attached
file. The long recovery time is caused by the long time
constant of the EFC controller.
73 Alberto I2PHD
While I have not used an Isotemp OCXO134-12 specifically, I am
currently running two different OCXO134-10 units in 2 different GPS
receivers. I am currently watching the performance of both units as they age
in because the two oscillators have very different characteristics. The spec
sheet for the 134-10 lists the short-term stability as < 1e-10 / sec, and
both units meet this spec, with long-term aging at <1e-9 after 30 days,
5e-10 after 1 year, with both units also meeting this spec after 30 days.
The first unit I built had a very steep (~5e-9 / day) initial aging
curve, which has settled to ~1.2e-10 / day after a couple of months of run
time. This unit has good short-term stability, with the EFC varying no more
than +/- 1e-11 over 100 minutes, similar to what you are seeing with a 7
minute period. The long-term aging on this unit while well within spec is
still double the aging of the second unit after months of operation.
The second OCXO134-10 unit had extremely low initial aging and has
remained at ~6e-11 / day over the last couple of months. While the aging is
excellent, the short-term stability of this unit is poor compared to the
first unit, with the EFC varying about +/- 1e-10 over 100 minutes. The
variations in EFC on both of my units appear to be cyclic with about a
100-minute period. 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.
Not knowing what the particular specs for the OCXO134-12 are, perhaps
they used a faster response time in that unit compared to my 2 OCXO134-10
units and what you are seeing at a 7 minute period is what I am seeing at a
100 minute period. I have 2 more OCXO134-10 units coming from an e-bay
auction to see how they compare with the two I have running. If testing the
two new ones against the two I have running reveals anything I will pass it
on.
----- Original Message -----
From: "Alberto di Bene" dibene@usa.net
To: "Discussion of precise time and frequency measurement"
time-nuts@febo.com
Sent: Sunday, October 23, 2005 7:30 AM
Subject: [time-nuts] RE: phase locking Rb to GPS
Richard H McCorkle wrote:
[snip]
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 [snip]
Richard,
do you perhaps have any experience of using the Isotemp OCXO134-12 unit
?
I built a GPSDO using it, and it works rather well, were it not for a
residual oscillation of the frequency of about +- 2E-11. i.e. +- 0.0002Hz
at 10MHz, with an oscillation period of about 7 minutes, which is too fast
to be corrected by the PI software loop.
I attributed it, lacking other explanations, to an imperfect temperature
control of the oven. Translated in temperature terms, that frequency
oscillation amounts to a change of about 0.18 degrees Celsius.
What you think about this ? TNX
73 Alberto I2PHD
time-nuts mailing list
time-nuts@febo.com
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts