I run into this every once in a while, and wondering if anyone else has seen it. When doing the software cal on an HP 53131A with 010 or 012 time base, every once in a while I get one that has an offset. I am using my Rubidium, and I have two identical units that have both been warming up at least 72 hours (last time I ran into this I had about 6 units all with OPT 010 or 012). I unsecure the cal mode, input the 10 MHz, and when it is done, I have a little offset. Like with resolution of 0.1 mHz (milli Hertz), I get an offset of about 25.5 mHz (not MHz). I have two counters. One cals fine, and with the same resolution, I get a predictable one or two counts of offset just due to instability/noise, etc. But the second unit, I get the above offset. I re-ran the software cal and get about the same results on both counters. Same thing happened on the last one (a few m onths ago). I recall on the other one, I repeated the SW cal a few times, and it did the same thing each time. So I don't believe I am doing anything wrong. I tried adding a feedthrough term, and no effect. I think there is something wrong with the counter. Maybe a noisy A/D circuit or something (maybe a leaky capacitor somewhere??). Just wondering if anyone else has had that problem.
What if you took a sig gen, tied it to your rubidium and then input a 10 MHz signal that is offset by the offset you are seeing, does that solve the problem, basically lie to the UUT.
I actually thought of trying that. One thought I have is that the offset may be a multiple of power line frequency (possibly indicating a leaky capacitor somewhere). Problem is, the incoming shelves are full. So I have to set it aside. One other experimental thought I have is try reducing the resolution and seeing if I get the same approximate three digits of offset, but pushed over by what ever resolution I set to (for example, if I change resolution to 10 Hz, if the offset changes to 2550 Hz (still corresponding to the bottom three digits), which would still lean toward a leaky cap or equivalent, but associated with A/D circuitry..... this, once I have actual time to work on it.
Yes - I've seen this ( I have a 53131A and 53181A ).
It looks like the auto calibrate function is a little buggy.
It has also been noticed here http://gerrysweeney.com/diy-hpagilent-53131a-010-high-stability-timebase-option/ (http://gerrysweeney.com/diy-hpagilent-53131a-010-high-stability-timebase-option/)
The video has a section which shows the auto calibration procedure performing the magic
( a binary search - and a dac to control the OCXO )
The calibration will even fail sometimes when it should not.
Also - be aware that some rubidium oscillators 'sweep' around the 10.000000Mhz
As far as I recall the 10Mhz is locked to a microwave source which is swept in frequency around the absorption line for rubidium plasma. A light cell detects a dip in the absorption - which indicates the correct frequency - so you're always going to get 10Mhz +/- some very small amount swept at some rate (416.6Hz has been mentioned)
I've had better results manually adjusting a very good ocxo to match the rubidium , and then using the ocxo to calibrate the 53131A.
Standard rubidium oscillators are not very good over the short term - and I think the 53131A calibration method is too short.
This has been a while now. But I feel like the Rubidium is not the culprit. We use it all the time on many counters. It's short and long term stability is quite a bit better. If I recall that day, I had a stack of 53131A's and 53132A's. They all cal'd perfectly except that one. Seemed like it was something weird in the 53131A/2A. I don't think that particular unit is around. Just a strange mystery.
If it was repeatable then definitely a fault with the counter - the issues I've seen usually clear after a couple of recal attempts.
A nice page comparing the short/medium/longterm stability of certain rubidium standards
is at http://www.ke5fx.com/rb.htm (http://www.ke5fx.com/rb.htm)