Re: [time-nuts] RE: phase locking Rb to GPS
From: Tom Van Baak [EMAIL PROTECTED] Subject: Re: [time-nuts] RE: phase locking Rb to GPS Date: Sun, 23 Oct 2005 14:42:39 -0700 Message-ID: [EMAIL PROTECTED] 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 ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
[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
RE: [time-nuts] RE: phase locking Rb to GPS
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] 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 ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] RE: phase locking Rb to GPS
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 [EMAIL PROTECTED] 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 ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
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
[time-nuts] RE: phase locking Rb to GPS
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] ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] RE: phase locking Rb to GPS
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 [EMAIL PROTECTED] (Business) (978) 927-4099 FAX [EMAIL PROTECTED] (Personal) (339) 927-7896 Mobile - Original Message - From: Brooke Clarke [EMAIL PROTECTED] To: Richard H McCorkle [EMAIL PROTECTED]; 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 ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] RE: phase locking Rb to GPS
From: Robert Lutwak [EMAIL PROTECTED] Subject: Re: [time-nuts] RE: phase locking Rb to GPS Date: Sun, 23 Oct 2005 16:43:34 -0400 Message-ID: [EMAIL PROTECTED] 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 ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] RE: phase locking Rb to GPS
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. /tvb http://www.LeapSecond.com ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
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. 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 [EMAIL PROTECTED] 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
Re: [time-nuts] RE: phase locking Rb to GPS (was time-nuts Digest, Vol 14, Issue 30)
- Original Message - From: Tom Van Baak [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [time-nuts] RE: phase locking Rb to GPS (was time-nuts Digest, Vol 14, Issue 30)
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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
Re: [time-nuts] RE: phase locking Rb to GPS (was time-nuts Digest, Vol 14, Issue 30)
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 ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] RE: phase locking Rb to GPS
From: Christopher Hoover [EMAIL PROTECTED] 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: [EMAIL PROTECTED] On 9/18 Tom Clark, W3IWI [EMAIL PROTECTED] 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 ___ time-nuts mailing list time-nuts@febo.com https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
Re: [time-nuts] RE: phase locking Rb to GPS
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 AA 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 [EMAIL PROTECTED] To: time-nuts@febo.com; [EMAIL PROTECTED] Sent: Sunday, September 18, 2005 12:45 Subject: Re: [time-nuts] RE: phase locking Rb to GPS From: Christopher Hoover [EMAIL PROTECTED] 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: [EMAIL PROTECTED] On 9/18 Tom Clark, W3IWI [EMAIL PROTECTED] 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 ___ 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
