Rubidium Std Measurement using HP 5370B

[Jackson]

Hey all,

I acquired an HP 5370B about 11 months ago along with some other gear. Haven't done much with it up to this point, but a week ago I was talking to a colleague and the fact that their group had a rubidium standard (SRS SIM940/PRS10) came up. I was interested in characterizing the 5370B a bit since the last cal date on it is unknown to me. They were kind enough to let me set up the boat anchor in their lab and take some measurements of the rubidium standard over the weekend.

The SIM940 was marked as calibrated last in mid-2011, putting it within 3.5E-9 of 10 MHz (35 mHz) if I understand the datasheet correctly. From the conversation I had, it seems that the unit has not been used in a while if that makes a difference in stability.

I believe the 5370B came from the local branch of CTS Microelectronics that shut down sometime in the last ten years. The unit is marked with a company sticker stating it is a calibration standard from the metrology department and not to be used for direct measurements, so my guess is that it was kept in calibration until they closed. Aging for this is less than 0.5 ppm (5 mHz) per day of operation if the device was on continuously for at least 30 days and off for less than 24 hrs or less than 1E-7 per day for continuous operation (I assume this means until the conditions for the 5E-10 ageing are met). I doubt that it met the 30 day condition, as I often unplug the power strip to my test equipment when I am not using it to save $$ and protect it from thunderstorms/poor line regulation; The house we rent is old and has ungrounded outlets just about everywhere, except for the remodeled kitchen and bathroom. Haven't convinced the XYL to let me set up the lab in either of those locations yet.

For the test, both instruments were plugged in Friday morning in the lab. Ideally I would have staggered this to isolate the drift to one instrument or the other, but I wanted to maximize sampling time. I started sampling roughly 15 minutes after plugging the instruments in and turning them on. The rubidium source is speced to be within 10 mHz of its final value by this point, so I attribute the majority of the drift to the 5370B settling in. Frequency measurements were taken on the 10 MHz output with a 1s gate. With the measurement read and save delay, the time between samples was [usually] 2 seconds. This is what I used for my graphs, but the end time on the graph is a few hours before when I actually ended the measurement, so there were some points that obviously had more than a 2 second gap between them. Final frequency value by Monday afternoon was about 36 mHz above 10Mhz, around the expected maximum ageing of the rubidium source. Not sure how much of that is the counter and how much is the standard, but doesn't seem too bad for 7-10 years after last cal.

I have downloaded Stable32 to try to look at the stability in more detail, but I am still trying to figure out the program and how to get a sigma - tau plot. Haven't taken stability this seriously before, so I am learning as I go. Below is the python code snippet I used to collect data from the 5370B over GPIB. Only issue I had was that the instrument didn't know how to interpret a pyvisa close() command, so I had to power cycle it between runs  I was writing and testing this code late the night before I started collecting data, so I gave up on trying to fix that and went to bed instead.

Any feedback or suggestion for next steps in analysis are welcome. At the very least, if I get nothing else from this, I have a counting good to within a Hz that I can used to calibrate my other counter as well as my analog function/pulse generators.

Jackson

Code: [Select]

import sys
import visa

rm = visa.ResourceManager()

try:
  hp = rm.open_resource("GPIB0::20::INSTR", read_termination='\r\n')
except visa.VisaIOError as e:
  print(e.args)
  sys.exit()
 
hp.write("FN3 ST1 SS1 GT4 MD4")
#print(hp.query("MR"))


with open('RubidiumData.csv','a+') as f:
    try:   
        while True:           
            hp.wait_for_srq()
            data = hp.read()
            print(hp.read())
            f.write(data+'\n')
    except KeyboardInterrupt:
        print('Interrupted!')
        hp.write('MD1')
f.close()


[awallin]

I have downloaded Stable32 to try to look at the stability in more detail, but I am still trying to figure out the program and how to get a sigma - tau plot. Haven't taken stability this seriously before, so I am learning as I go. Below is the python code snippet I used to collect data from the 5370B over GPIB. Only issue I had was that the instrument didn't know how to interpret a pyvisa close() command, so I had to power cycle it between runs  I was writing and testing this code late the night before I started collecting data, so I gave up on trying to fix that and went to bed instead.

Any feedback or suggestion for next steps in analysis are welcome. At the very least, if I get nothing else from this, I have a counting good to within a Hz that I can used to calibrate my other counter as well as my analog function/pulse generators.

If you are already using python you might look at allantools for the analysis part: https://github.com/aewallin/allantools

when Rb-clocks are measured against much better ones (Cs, H-maser) there's usually a clear dependence on ambient pressure. So if you get into comparison of several Rb-clocks then recording ambient pressure might be an interesting thing to do.

[Dr. Frank]

The 10811  OCXO inside the 5370B requires at least 48h to stabilize, so it makes no sense to start any stability measurements before that time.
That's also clearly indicated in your initial measurements.
If you let the 5370B permanently plugged into mains, the OCXO draws about 3W standby power only, and the instrument will be ready at any time.

As the 5370B and the OCXO are both very old, the OCXO is probably stable to < 1E-9, long-term.
Once calibrated, mine stays at that uncertainty for a period of over a year. (Same as my 2nd 10811A inside a 5335A)

It also recovers to that set point after a longer off line phase, after these prior 48h on-time.
Similar is the behavior of Rb standards, these are stable and precise to < 1E-10, if powered on for about a week.

As you have GPIB support, I propose to use TimeLab, an open source application of one of the time-nuts, ke5fx, John Miles.

http://www.ke5fx.com/timelab/readme.htm

Best is to use Allan deviation statistics, by using time-interval measurement on 1pps outputs, which measures phase changes between both references.

For this application, the frequency mode is more convenient, and also supported by TimeLab.
Either use 0.1 or 1 sec Gate Time in frequency mode and feed Rb to the counter input.
This measurement will give you numbers for stability, as well as for accuracy.

Frank

[Jackson]

Thanks for the suggestions.

I don't currently have environmental logging capability (beyond an arduino thermocouple board I use for BBQ/coffee roasting), but I'd like to get something up and running anyways, so this would be a good excuse. For the pressure dependence, I see in W. Riley's rubidium primer that it is typically around 1E-11 for a 10% change. A quick search for baro/thermo/hygrometers came up with the BME-280 chip on digikey/aliexpress, which would be easy to get up and running since I have several arduinos lying around unused. The temperature accuracy on the unit isn't that great (+-1C), but it looks to offer 0.01C resolution, which should be good enough to allow for relative comparisons?

I had seen TimeLab mentioned before, but hadn't downloaded it to check it out. It looks very well put together. I'll likely use this for my future 5370 datalogging. 

Best is to use Allan deviation statistics, by using time-interval measurement on 1pps outputs, which measures phase changes between both references.

For this application, the frequency mode is more convenient, and also supported by TimeLab.
Either use 0.1 or 1 sec Gate Time in frequency mode and feed Rb to the counter input.
This measurement will give you numbers for stability, as well as for accuracy.

Similar to the method used by John Ackermann, N8UR? 


Thanks again for the input.
Jackson

[Dr. Frank]

Well, John Ackermann actually IS Mr. time-nuts, as he has organized the mailing list.
And yes, he explains the oscillator / Allan stuff very well, that's exactly what's behind the TimeLab.
There's a whole community in the background, LeapSecond.com being the vastest time-nuttery place..
Btw.: The possession of an hp5370B already qualifies you to join the time-nuts club, afaik.

TimeLab contains the complete package, i.e. GPIB support for the most common T.I. counters, including the 5370A/B, data logging and also different data analysis.
Just install that package and start taking data, you're completely set in about 10 minutes..

I think, environmental data logging is not urgently needed for that digital stuff, but indeed, if you want to dig into analogue volt-nuttery, that's much more challenging 

Frank