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

Mon Oct 24 00:38:42 UTC 2005

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 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
>
>  
>