EEVblog Electronics Community Forum
Products => Test Equipment => Topic started by: linux-works on March 12, 2014, 04:22:29 pm
-
after watching gerry sweeney's video, I decided to try to replicate his idea with the video distribution amp and the Rb ebay box.
I'm still gathering info about this whole process and have some questions.
- to get the best accuracy for the 10mhz signal, do I need to adjust anything or does it automatically lock to 10mhz by itself, thus being a self-calibrating standard of sorts? I know it has a PLL or servo in there and that the center freq is shifted back and forth during lock, but is this an absolute thing or does it need to be calibrated, somehow?
- I plan to make this GPSDO based but I am not finding much open source code to get me started. from what I can tell, you can shift the center point of the oscillator via a pure hardware sense (some kind of internal trimmer or voltage controlled offset) OR you can nudge the freq a bit up or down via rs232 serial commands.
- what I'm thinking of doing is having an arduino do the servo work to keep the Rb output locked to the gps output. it seems you are supposed to use the 1pps output from both the gps receiver and the Rb box and phase-compare them (somehow?) and nudge the Rb oscillator up or down just based on a tiny tiny phase diff?
- it looks like all the Rb boxes output sine waves. I've heard you can modify these to output native square waves. if you do that, it may not be smart to use an analog video dist amp; the square waves may not be passed very well thru something that expects sines and not tons of harmonics, such that a square would use. maybe the right way to do this is to distribute sines to the test gear and, AT the test gear (one by one) convert from sine to square? can you just use fast schmitt triggers for this? I want to keep the accuracy and low jitter of the 10mhz signal so I'm looking for clean ways to convert the sine to square, assuming that typical freq counters and funct gens that take a 10mhz external input need squares.
TIA
/bryan
-
It is a physical property of the rubidium that is the "calibration". Over time rubidium will condense or pool in the heated bulb which will bring the standard out of "calibration", but there is a process to re-evaporate that lost rubidium and "recalibrate" it. I wouldn't worry about it, though, as long as it locks you're REALLY close to 10MHz.
GPS is a very good long-term source of time accuracy, and not so good at small-term time accuracy. Rubidium is very good at short-term time accuracy, and not so good at long-term accuracy.
For Rubidium, counting 10M cycles and being close to one second is highly accurate. Counting 10M cycles * 60 * 60 * 24 will put you farther away from an exact 1 day time frame than GPS will, if my understanding is correct.
Combining the long-term stability of GPS and the short-term stability of Rubidium means that the GPS accuracy at long-term measurements can be used to tune the Rubidium for even greater short-term accuracy. Basically, you know how many Rubidium 10M cycles are supposed to happen in a day, and you know what a day is because of GPS. You calculate the offset between the measurement and the expectation and you adjust the rubidium to compensate. You will never get it to be exact, and because of things like relativity there is no "exact" but you can get very, very close.
Maybe I'm wrong on all that. The time-nuts mailing list archives probably have the proper explanation for all of this in as much detail as you can fathom. I haven't looked.
-
There is a tuning word you can input over RS232 to adjust the frequency, you can also choose to save it in non-volatile memory if you just want a one-time calibration.
The simplest way is probably to count the exact number of 10MHz cycles during N PPS pulses from a GPS with a steady signal lock, where N is something large like 604800 (one week of PPS pulses). The number should be exactly 10e6 * N, take the value you get and calculate a correction factor, modify the tuning word accordingly and store into the Rb oscillator non-volatile memory.
To do this using an arduino (or any microcontroller) you probably need to use the 10MHz as the clock for the micro, and use some hardware timer to count the cycles.
I did almost exactly this using a PIC, but I don't think I have the source code anymore.
Of course, except for some exotic applications and time-nuttery the Rb oscillator is likely more than close enough without any adjustment.
-
Maybe you will find following page useful http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
-
- to get the best accuracy for the 10mhz signal, do I need to adjust anything or does it automatically lock to 10mhz by itself, thus being a self-calibrating standard of sorts? I know it has a PLL or servo in there and that the center freq is shifted back and forth during lock, but is this an absolute thing or does it need to be calibrated, somehow?
Rb atomic clocks are secondary standards only. Initial uncertainty may be around 1e-10, and they drift about 5e-11/month. Therefore they have to be calibrated frequently, 5e-12 initially is possible.
You need a GPS receiver as the Thunderbolt as a reference for calibration.
As GPSDOs have bad short term stability, a single shot comparison, e.g. over 1sec, is not sufficient, even if you have a highly resolving counter (12 digits/sec).
Additionally, varying satellite constellation and variance on the transmitting path will lead to mid term unstabilities.
Therefore you need to compare the phase of the Rb vs. the GPS signal over hours or over one day to achieve 1e-12 uncertainty.
This comparison is done best by using 1 pps outputs from the GPSDO and from the Rb.
For the Rb you need a sine to square ware converter, and then a precision divider.
Both circuits can be found on the sites of some time-nuts.
http://www.tapr.org/kits_tadd-2.html (http://www.tapr.org/kits_tadd-2.html)
The 1pps signals will have to be compared by a T.I. counter, having at least 1ns resolution.
A monitor and evaluation program is freely accessible. http://www.ke5fx.com/timelab/readme.htm (http://www.ke5fx.com/timelab/readme.htm)
- I plan to make this GPSDO based but I am not finding much open source code to get me started. from what I can tell, you can shift the center point of the oscillator via a pure hardware sense (some kind of internal trimmer or voltage controlled offset) OR you can nudge the freq a bit up or down via rs232 serial commands.
Rb clocks have very good short and mid term stability, which will be harmed if using it in a GPSDO.
Better calibrate the Rb frequently and let if free running.
There are proposals to use a Rb as the oscillator in the Thunderbolt, instead of the original OCXO.
The Thunderbolt lets you chose the correct loop parameters, to find a compromise between short term and long term stability.
For some Allan distributions, see here:
http://www.ke5fx.com/rb.htm (http://www.ke5fx.com/rb.htm)
- what I'm thinking of doing is having an arduino do the servo work to keep the Rb output locked to the gps output. it seems you are supposed to use the 1pps output from both the gps receiver and the Rb box and phase-compare them (somehow?) and nudge the Rb oscillator up or down just based on a tiny tiny phase diff?
You can program it on yóur own, or use the Thunderbolt.
- it looks like all the Rb boxes output sine waves. I've heard you can modify these to output native square waves. if you do that, it may not be smart to use an analog video dist amp; the square waves may not be passed very well thru something that expects sines and not tons of harmonics, such that a square would use. maybe the right way to do this is to distribute sines to the test gear and, AT the test gear (one by one) convert from sine to square? can you just use fast schmitt triggers for this? I want to keep the accuracy and low jitter of the 10mhz signal so I'm looking for clean ways to convert the sine to square, assuming that typical freq counters and funct gens that take a 10mhz external input need squares.
TIA
/bryan
Clock distribution amplifiers normally operate on square wave signals only.
Video distributors are suitable for that at low cost.
Several TTL inverters in parallel will also serve well as clock distributors.
For such comparisons, very stable and fast sine => TTL converters are needed, otherwise, you will get additional short term jitters. Better use the above mentioned circuits.
And work yourself through the time-nuts site.
Frank
-
Rb atomic clocks are secondary standards only. Initial uncertainty may be around 1e-10, and they drift about 5e-11/month.
For most uses people have, that's plenty good enough, no need for the GPS discipline. 4 orders better than a regular crystal, and a couple of orders better than an oven.
-
The SRS PRS10 is one of the best Rb clocks available AFAIK. This plot from SRS shows its allan deviation vs. that of a 1PPS GPS signal:
http://www.thinksrs.com/assets/instr/PRS10/PRS10diag2LG.gif (http://www.thinksrs.com/assets/instr/PRS10/PRS10diag2LG.gif)
for this Rb clock the "handover" to GPS-disciplined operation should happen somewhere around 100k seconds, or 1-2 days of averaging.
Other cheaper Rb's might be worse, and the free-running Rb curve crosses the GPS 1PPS curve sooner.
The suggestion above to leave it free-running is also good, since the aging over many years is quite predictable. In fact if you calibrate it regularly (~once per year) you can predict its aging quite well. This approach would work well if you use it as a frequency-standard, but probably less well for timekeeping.
-
There are all sorts of GPS-signal distributing phenomena that are present in the atmosphere -- space weather stuff mainly. These disturbances cause variations in the transmission time from satellite to ground station throughout the day. Its been one of the main challenges GPS has had to face before being adopted as an aviation navigation standard.
http://www.raimprediction.net/ (http://www.raimprediction.net/)
http://en.wikipedia.org/wiki/Receiver_autonomous_integrity_monitoring (http://en.wikipedia.org/wiki/Receiver_autonomous_integrity_monitoring)
There are all sorts of cleaver ways people have thought up to "calibrate out" these problems (like WAAS: http://en.wikipedia.org/wiki/Wide_Area_Augmentation_System (http://en.wikipedia.org/wiki/Wide_Area_Augmentation_System)). But I've never been too clear on how 'smart' the GPS disciplined section of a frequency standard is...? If it blindly accepts the arival of two signals spaced over X time, I'm thinking space weather effects would add more uncertainty to the Rb per cycle frequency -- even though it would have the advantage of keeping up with the offical standard time.
-
Maybe you will find following page useful http://www.leapsecond.com/pic/picdiv.htm (http://www.leapsecond.com/pic/picdiv.htm)
that picdiv looks very interesting!
can anyone confirm which chip it uses? are there many choices for PIC's for this? I am more an atmel/arduino guy and know very little about the PIC chips. I think this chip will work:
PIC12F675
are there other equivs that I can also use with his .hex files?
-
PIC12F675
That's the one that is pictured, I think you're safe with that one.
-
I saw the pic-div and pic-pet on that guy's page. really neat ideas. love the fact that you can burn purpose-built chips and just use them with next to no components other than a bypass cap.
since they are so easy and cheap, I might make concurrent outputs at 1, 10, 100, 1k, 10k, 100k, 1M and digitally buffer them each. does not seem to be all that much extra work and you get lots of easy standards driven by using that divider chip (or a bunch of them).
my project is stalled, though; UPS is farking with me with some kind of 'hold' or delay. they must have thought I was importing flux capacitors or something.
-
I saw the pic-div and pic-pet on that guy's page. really neat ideas. love the fact that you can burn purpose-built chips and just use them with next to no components other than a bypass cap.
since they are so easy and cheap, I might make concurrent outputs at 1, 10, 100, 1k, 10k, 100k, 1M and digitally buffer them each. does not seem to be all that much extra work and you get lots of easy standards driven by using that divider chip (or a bunch of them).
my project is stalled, though; UPS is farking with me with some kind of 'hold' or delay. they must have thought I was importing flux capacitors or something.
What are you importing?
-
rubidium ;)
(inside a physics package. maybe that's what scared them. or, this is all pure BS and UPS is slowing things down on their own).
-
rubidium ;)
(inside a physics package. maybe that's what scared them. or, this is all pure BS and UPS is slowing things down on their own).
Oh. US customs are just stupid like that.
-
- it looks like all the Rb boxes output sine waves. I've heard you can modify these to output native square waves.
The 10Mhz output from many of the 5680A's are actually square on one of the CPLD pins , and the modified to sine via an analog flter. Thats prob. why the LPRO-has a much nicer sine.
If you lift/bridge that filter you get a nice square.
This is prob a page to look at of getting a 5680A
http://ko4bb.com/dokuwiki/doku.php?id=precision_timing:fe5680a_faq (http://ko4bb.com/dokuwiki/doku.php?id=precision_timing:fe5680a_faq)
/Bingo
-
- it looks like all the Rb boxes output sine waves. I've heard you can modify these to output native square waves.
The 10Mhz output from many of the 5680A's are actually square on one of the CPLD pins , and the modified to sine via an analog flter. Thats prob. why the LPRO-has a much nicer sine.
If you lift/bridge that filter you get a nice square.
This is prob a page to look at of getting a 5680A
http://ko4bb.com/dokuwiki/doku.php?id=precision_timing:fe5680a_faq (http://ko4bb.com/dokuwiki/doku.php?id=precision_timing:fe5680a_faq)
/Bingo
I would think a high-speed comparator would work as well.