10Mhz Frequency Standard

[alank2]

Are you guys aware of the NFT utility written by a KKP at the avr forum:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=82842&highlight=nft

http://n1.taur.dk/nft/nft.pdf manual with screenshots
http://n1.taur.dk/nft/nft.exe win32 exe

[Wim13]

maybe i dont understand, but if you write: At this point it takes 15.11s to move 1/5th of a div at 20ns.
i realy read here move, and not a steady difference...

I may not understand either.  I've got my rubidium on CH1 and it is triggering on it so it is stable.  Then I am feeding the OCXO into CH2 and looking at it alongside the rubidium.  If the OCXO were at the same exact frequency of the rubidium, then both waveforms will be stable and not move in relation to each other.  If however, the OCXO were actually at 9999999 Hz instead of 10 Mhz, then its waveform will be moving in relation to the rubidium waveform.

If my formula is right (and I'm not sure it is, I was hoping someone would come along with a formula for comparing two frequencies next to each other on a scope), it would move 5 divs per 1 second if it were 9999999 Hz...

 your calculation is correct, if the drift is constant, i was thinking it was speeding up 4 nSec per 15 sec. 

[alank2]

your calculation is correct, if the drift is constant, i was thinking it was speeding up 4 nSec per 15 sec.

Good; it doesn't seem to drift much.  I can adjust it so it is barely moving forward or barely moving backward in relation to the rubidium signal, and then it stays doing that.

[Wim13]

your calculation is correct, if the drift is constant, i was thinking it was speeding up 4 nSec per 15 sec.

Good; it doesn't seem to drift much.  I can adjust it so it is barely moving forward or barely moving backward in relation to the rubidium signal, and then it stays doing that.

An other way of calculating ,

10 Mhz has a period time of 100 nSec, the OCXO was 4/15 , 0,26 nSec off
That means it wil catch 1 cycle every  100 div by 0,26 is 384 seconds.

So if you look at the scoop for 384 seconds it will be shifted 1 cycle, so the difference is 1/384 HZ is 0,0026 Hz

[G0HZU]

It has no use to set a OCXO to the right frequency, you need to know what its drift is over long period.
Even HP OCXO ( 10E-10 a month), have to be recalibrated every three months. If you know the drift and the start calibration freq.
you can predict its drift over long period. And never turn it off. Becuse turning of OCXO, shift its freq. also.

All agreed, that's why I still keep using my old Droitwich locked offair std every few months to check all my various 10MHz ovens. Eg HP8568B, HP8566B, Marconi 2024 with HS oven, Quintenz 10MHz OCXO, plus the oven in my Anritsu counter. It has something like 5e-10 ageing per day but I find that because I turn them off when not in use, the drift becomes less predictable.

I did study the performance of some of the OCXOs and also a GPS reference on a fast updating 11 digit counter and all of them suffered short term step changes in stability if you simply tilted the OCXO in its axis. So even the GPS oven couldn't stay accurate eg it short term shifted the 10MHz by a few mHz if tilted. Obviously it locked again a short while later but it wasn't able to flag itself as being off frequency.

I need good 10MHz reference accuracy for the test gear that goes to >20GHz but I'm more than happy with the performance the ovens give and I can't see the need for a GPS reference because to justify it I'd have to leave all the ovens running and check/adjust them fairly constantly either manually or with ATE.
The Anritsu counter has the top option for the OCXO from Toyo that is the size of a small coffee mug and it takes >45Minutes to warm up (for even basic accuracy) so I usually use my Quintenz OCXO as an external reference. It takes less than 5 minutes to stabilise and offers very good performance. If I'm doing something critical I'll check the OCXO against the offair standard. Good enough for me

[dfmischler]

... I can't see the need for a GPS reference because to justify it I'd have to leave all the ovens running and check/adjust them fairly constantly either manually or with ATE.

I would think the best way to use the 10 MHz GPSDO is to use it as an external reference.  Then you can turn off the equipment you don't need to use.

Anybody else concerned about an uncalibrated 10MHz rubidium secondary standard being off by a few Hz and having no way to check it?  There are rumors of this happening.  Remember that 10 MHz is not the natural frequency of rubidium, so this is a synthesized or disciplined frequency.

[Wim13]

... I can't see the need for a GPS reference because to justify it I'd have to leave all the ovens running and check/adjust them fairly constantly either manually or with ATE.

I would think the best way to use the 10 MHz GPSDO is to use it as an external reference.  Then you can turn off the equipment you don't need to use.

My experience is that a GPS is not so reliable, to much jitter on short term. 10 - 100 nSec ( per Sec )
Better use a Rubidium, i check the rubidiums now and then, against a GPS and second source BBC4 ( only Europe )

The rubidiums i have are stable, better then 10E-11 a month, so they only need adjustment once a year.
No need to synchro direct with GPS or else.

[dfmischler]

My experience is that a GPS is not so reliable, to much jitter on short term.

I can buy that, but I would say your complaint is that some GPS frequency devices are not very stable on short scales.  Many of the manufacturers give you the option to have a TCXO, OCXO or rubidium stabilized oscillator as the disciplined oscillator.

The rubidiums i have are stable, better then 10E-11 a month, so they only need adjustment once a year.
No need to synchro direct with GPS or else.

Yes, but you apparently have something to compare them to.  My concern is for the people who buy a rubidium standard with no way to know if it is really accurate and stable when it claims it is locked in.  Almost all are probably fine, but how does Joe TimeNut know about the one he bought?

[G0HZU]

I would think the best way to use the 10 MHz GPSDO is to use it as an external reference.  Then you can turn off the equipment you don't need to use.

From a technical point of view that would be a neat solution but when I borrowed a Quartzlock E8-Y GPS reference I found I had to deploy the remote aerial outside and also run the Motorola software to make sure I was getting good reception from lots of satellites.  I also found that it took a long time to settle. The spec sheet said something like 30 minutes but I found it took less than this. But it was still a chore to use it so I'd have to leave it running all the time.

http://www.quartzlock.com/downloads/datasheets/E8-Y_4pp.pdf

I nearly bought one of the rubidium references on ebay a while back but I saw common sense and realised that I didn't need the extra performance and I'd still end up checking it against the offair std anyway

It's a really hot and humid night here in the UK so for a quick test  I fired up the Quintenz OCXO and gave it 5 minutes to settle and it was within 0.02Hz of the 10MHz from the offair standard if I averaged out any short term drift on the offair std. Not anywhere near as good as a rubidium std but still very impressive. It's temperature spec is something like -40 to +70degC and it was a 'special' high performance version of this oscillator here:

http://www.quintenz.de/pdf/xo/QO2736.pdf

[Wim13]

This is how i measure and calibrate GPS, BBC4 and the Rubidium

On the DSO, put the Rubiduim on the Ext trigger, BBC4 on channel1
and the GPS on channel 2. ( See picture )

Nice thing of Digital scoops, they can remember on screen

On this picture the measure time is 1 hour, the jitter on the GPS is about 40 nS average
during this hour, so al within 1.1 E-11

Second source is the BBC4 Quartzlock receiver, you can see jitter of it about 100 nS,
due to path changes of 100 * 0,3  is 30 meters.

On an other occasion i also discover night an day shift on GPS, of about 100-200 nSec,
If you synchro GPS on an OCXO  this is something to think about.

[G0HZU]

Looks good My homemade offair standard isn't as good as yours. I designed and built it in a hurry and it is a very simple design. It works best during the day where it can reliably deliver 1e-8 to 1e-9 in  the short term with some averages. At work we have been using the Quartzlock offair standards (198kHz)  for about 20 yrs and the newer models seem to work much better than the originals. I think we disposed of all the early ones as they were a chore to use because they were so fussy in finding a reliable lock and they weren't that stable either.

[Wim13]

Looks good My homemade offair standard isn't as good as yours. I designed and built it in a hurry and it is a very simple design. It works best during the day where it can reliably deliver 1e-8 to 1e-9 in  the short term with some averages. At work we have been using the Quartzlock offair standards (198kHz)  for about 20 yrs and the newer models seem to work much better than the originals. I think we disposed of all the early ones as they were a chore to use because they were so fussy in finding a reliable lock and they weren't that stable either.

i have model 2a of the Quartzlock 198 khz receiver, what is a design error i think is the antenne on the back of the unit,
i removed it fro the back, made a metal base for it and placed the antenna 4 meters away, that solved lots of problems

The antenna on the back sometimes oscilates if not proper tuned. When removing it, it has a much better tuning.

On day time it is very good, at night, the receiving path is shifting al the time

[Wim13]

This is how i measure and calibrate GPS, BBC4 and the Rubidium

Just to clarify you are using the 1PPS output of the rubidium standard as the trigger? In that case it seems like you would get all the jitter from the 1PPS divider, the oscilloscope trigger and the oscilloscope's trigger offset display.

What GPS receiver are you using? That edge doesn't look very good.

Divider jitter is so easy to measure, so that already wiped out...

And yes the output of the GPS, is a 10 Khz signal, which has a low rise.
You can also use sinus waves, so rise time is no issiue.

[jpb]

My OCXO only outputs 0.7Vrms so I had to wire up a small amplifier to get it up to 1.11Vrms for my counter's external ref in, which delayed my experiments a bit but I now have it setup on the bench.

I have a 5k pot to adjust the tuning voltage on the OCXO. Adjusting this by hand to give me 2.777V gives a average period reading over 100s of my GPS 1pps of 1.000 000 000 occasionally
changing by 1 in the last place.

Obviously this isn't very scientific - I need to put my amp in a box and do a lot of tidying up before I'm happy to leave things on for a long time but my conclusion is that it is reasonably easy to use a cheap OSXO off e-bay with a bit of adjustment with a gps module to get a standard to within around 10^-9. This is as close as I need with a 10digit counter.

Obviously a properly disciplined oscillator or a rubidium source will be rather better but 1 part in a billion doesn't seem bad. It is also in accord with what GOHZU reports.

Edit: I adjusted the Voltage up to 2.77871V and the period measurement is sitting at 1.000 000 000 with no changes in the last digit. The OCXO (which I have further insulated) is only drawing 184mA but seems to be stable so I am cautiously optimistic.

Edit again: I somehow had it on frequency instead of period. Switching to period and reducing V to 2.77825V gives a period reading oscillating between 999.999 9998 msecs and 1.000 000 000 secs which is a few parts in 10^-10. The counter uses a 50MHz clock so the difference is one count in the 100 second gate.

[Spark]

In a previous life I used to design these things. The main problem with using off air standards directly is they all suffer from short term jitter. The long wave BBC signal has a very low frequency data phase mod signal on it (used to control elect meters I believe). They claim this averages to 0 ( from memory over 1 sec.). However from practical experience it takes a lot longer (about 1min.) to get below 1^10-9 jitter. If you are using this as a calibration sig then no problem, but if being multiplied up to microwave freq. then not so good. The best option is to use a good ovened osc. either xtal or rubidium (the osc of which is xtal anyway). and cal this against an off air std. as often as needed for you application. Or you could just buy a GPS disciplined rubidium std. from eBay.

[Wim13]

In a previous life I used to design these things. The main problem with using off air standards directly is they all suffer from short term jitter. The long wave BBC signal has a very low frequency data phase mod signal on it (used to control elect meters I believe). They claim this averages to 0 ( from memory over 1 sec.). However from practical experience it takes a lot longer (about 1min.) to get below 1^10-9 jitter. If you are using this as a calibration sig then no problem, but if being multiplied up to microwave freq. then not so good. The best option is to use a good ovened osc. either xtal or rubidium (the osc of which is xtal anyway). and cal this against an off air std. as often as needed for you application. Or you could just buy a GPS disciplined rubidium std. from eBay.

Because you also mentioned, a GPS has also jitter, and even day and night shift, so thats why a dont like GPS connected Rubidiums,
because this jitter of GPS drifts the Rubidium very slowly. A rubidium who has been calibrated and not connected against off air standards acts much better,
and does not have this drift.

But is more work of course, you have to find out the trend of the rubidium.

I

[jpb]

From my brief experiments, it seems that the degree of hassle/expense is related to how accurate you want to be.

I can hand adjust my OCXO to within 1 nsec on a 1 second period and it stays that way for 12 hours or so. The jitter on the gps seems to even out to less than a nanosec when I use a gate of 100 secs so getting a solution to this sort of accuracy is cheap (£15 for OCXO from e-bay, £7 for good quality pot., £28 for GPS module and £5 for antenna I think - though I am relying on my counter to provide the measurement and I had to spend several quid  on building myself an amp as the OCXO signal was too low for my counter then I had to get a little power supply for the +-5V needed by the amp ......).

One problem I found with using my counter directly is that when the period is one count low i.e. 999.999 999 8 msecs (50MHz clock in counter) then the accuracy is 0.2 nanosecs but when it is one count high I lose the last place and it would only read 1.000 000 000 seconds so I don't know if it is one, two, three or four counts high.

A way around the asymmetry would perhaps to use a divide by 99 counter then it would read 98.9 999 999 8 or 99.0 000 000 2 seconds and the accuracy could be measured to the order of 2x10^-10.

Rubidium sources now seem expensive on e-bay. They start at £65 and at the cheap end you have the gamble that their lamp voltage is low and they are near end of life. Additionally, as I can't measure to  below 2x10^-10 accuracy having 10^-11 would be invisible to me. I only want this to provide an external 10MHz for my counter and a function generator (when I eventually get one) so even 10^-9 is 1000 times better than the built-in TCXO.

[Wim13]

@ jpb

Thats why i use a time interval counter for precise measurements,

on 1 channel the GPS and the other the Rubidium, and then plot a graph for some hours.
measure the difference in nano or pico over hours, and also the trend.
Or these days you can do it also with a DSO. See picture somewhere above.

So i discover the day and night shift on the GPS.

to discipline a rubidium with a GPS you need a very clever algorithm, that takes days.

[G0HZU]

This is a good thread

With my homemade offair standard I can see some of its short term jitter on my old Anritsu counter because the counter can display 10 digits per second or 11 digits in 10 seconds.

So during the day I typically see +/- 20mHz of jitter between counter refreshes but sometimes it jumps more than this for the odd count or two.

To overcome this I wrote a quick Windows app that reads the counter at every refresh and it builds up a long term average. For quick and dirty checks I average it over a minute or so but when checking it against a GPS reference I set it to 1mHz resolution and average over something like 30 minutes. It usually gives very good results over this time frame. I know the jitter is in the offair std because I get a very stable reading from the counter if I connect a decent OCXO to the counter input.

It is a very crude design and it doesn't use any kind of crystal filter. I designed it hoping I could get 10e-8 over a few seconds because that was the limit of my counters at the time.

It uses a hard limiter and some very high Q resonator sections and a very low loop bandwidth. At the time (early 1990s) it appeared to have similar performance to the Quartzlock 2A offair stds we had at work but the big bonus is that it always locks (during the day) whereas the QL models were a chore to use. Now I have the Anritsu counter I can see the short term jitter far more easily and I'm actually quite pleased with the offair std performance as long as I use a few averages.

[jpb]

@ jpb

Thats why i use a time interval counter for precise measurements,

on 1 channel the GPS and the other the Rubidium, and then plot a graph for some hours.
measure the difference in nano or pico over hours, and also the trend.
Or these days you can do it also with a DSO. See picture somewhere above.

So i discover the day and night shift on the GPS.

to discipline a rubidium with a GPS you need a very clever algorithm, that takes days.

My attempts at the DSO method have not been very successful. If I trigger on the 1pps from the GPS and look at the jitter on the OCXO output, from one second to the next it is around 5 to 10 nsecs which is what I'd expect. But if I leave persistence on at infinity it spreads over a wide range. I guess that the frequency is slightly out. If it is losing just 2 nsecs a second then over 50 seconds it will spread over an entire wavelength.

Unfortunately I don't have the remote control option on my scope (it is a WaveJet 300 series not the 300A series and LeCroy want £400 for the option). I'll have to manually look at 1024 saved waveforms I guess.

[jpb]

I did some DSO measurements by hand. It was very tedious so I only did about 125 out of 1024 possible points. The jitter shows quite well but there is probably too few points to get an accurate measurement of the slope. The slope as fitted is around -0.1nsecs per second so the period of the nominal 10MHz is around 10^-10 short (the frequency is slightly too high).

It is very annoying, but my scope doesn't allow an easy saving of the history of all 1024 waveforms at once, instead they need to be saved one at a time. If I get enthusiasm up I'll repeat the experiment with more points when I have more time.

Attached is the plot of the results - each point represents a 1pps and the relative offset of the 10MHz zero crossing following the 1pps transition (rising edge).

OK I know phase isn't measured in nanosecs - you need to divide by 100 nsecs and multiply by two-pi to get it in rads.

[Wim13]

Here a plot, off a GPS 1 sec against a Rubidium 10 mhz,
after 1 hour warmup of the Rubidium

measured over 4000 sec, it changes about 50 nSec, which is 1.2 E-11
and within specs.

Is you look over 2000 seconds, is it almost zero.

But measured over longer times, is also different, so using a GPS
as a reference is not easy.

[jpb]

Those results are interesting in the extent of GPS jitter. So GPS is good over long time periods but very noisy in the short term.

This is quite an interesting comparison between GPS disciplined OCXOs and Rubidium sources:

http://www.ptsyst.com/AppNote2.pdf

I'm still working on the analysis of 1024 seconds of data for my modern GPS with my OCXO. I also have a Trimble Resolution T which I want to compare it to.

A lot of GPS jitter seems to come down to the low clock frequency of the GPS receivers - I wonder if it is possible to overclock them.

I also wonder if there is some way of setting up multiple GPS antennas in a sort of phased array. Unfortunately GPS data and systems are rather complex.

[edpalmer42]

Here's some measurements that I've made on various GPS devices:

--------------------------------------------------------------
GPS Devices -- Performance of 1 PPS Output

Device ............... Std Dev (ns).... Range (max-min)(ns) ... Device Type

Navsync CW12 ......... 4 - 5 .......... 20 - 25 ............... GPS Rcvr (1) see below
Motorola UT+ ......... 40 - 55 ........ 95 - 110 .............. GPS Rcvr (2)
Rockwell Jupiter ..... 10 ............  50 ...................  GPS Rcvr (3)
Motorola M12M ........ 10 - 15 ........ 40 - 60 ............... GPS Rcvr

Trimble Thunderbolt .. 0.4 - 0.5 ...... 2 - 4 ................. GPSDO
HP Z3801A ............ 0.1 - 0.2 ...... < 1 ................... GPSDO   
HP Z3817A / CW12 ..... < 0.1 .......... < 1 ................... GPSDO    (4)
Jackson Labs GPSTCXO . 0.3 - 0.4 ...... 2 - 3 ................. GPSDO


Results are based on multiple runs of ~ 1000 measurements each.
Sawtooth correction has not been used for any of the GPS receivers.
GPS Rcvr measurements made with HP 5372A.  GPSDO measurements made with HP 5370B.
All units were connected to the same antenna system.

1.  Sawtooth correction not supported.
2.  Most 'range' results were in this group, but there were a few at 20 - 30.
3.  Only one test run.
4.  Requires external 1 PPS input.  Equipped with E1938 oscillator.
------------------------------------------------------------------------------

Note that sawtooth correction gives a big improvement to the performance of a GPS receiver.  If a unit supports it, you would normally use it.  These measurements only looked at the raw hardware.  Newer units tend to give better performance over short time intervals because higher clock speeds allow the 1 PPS pulse to be placed with better resolution.  Sawtooth correction helps compensate for the lower clock speed.

Ed

[G0HZU]

Hope nobody minds me digging up this thread again...

I calibrated my Anritsu counter yesterday and then used it to measure the short term stability of my homemade offair standard.

The counter can display to 10mHz on a 1 second gate time and this is able to capture some of the short term instability of the offair standard.
If I use a longer gate time and display to 1mHz then it tends to hide the worst of the jitter.

Obviously this level of performance is poor compared to GPS or a Rubidium standard but you can see why I'm generally pleased with the offair standard performance (for home use) as long as I use some averaging.




I gather the data using this simple Windows app that takes data from the counter via GPIB