Found home made rubidium reference that seems to really work well

[FriedLogic]

Frequency and Time Interval (phase) are two sides of the same coin.  You can convert phase to frequency with no issues, but there are some problems going the other way.  When it comes to measuring ADEV, there are a few differences.  Most notable is the difference in slope of the resulting graph.  In your graph, it takes about two decades of frequency for the graph to drop one decade in ADEV, i.e. the slope is -0.5.  If you measure Time Interval, the slope is -1 which causes the graph to drop faster.  This gets you into the low values that we're really interested in sooner.  I've seen graphs of OCXOs that didn't look impressive because the measurements were frequency based and by the time the graph got down to the good stuff, the crystal aging was already causing the results to rise.

I'm not quite sure what you mean there - the way that frequency counters normally work is to measure time and then convert it to frequency anyway. Any difference is just down to how they do it.

The 53131A calculates the frequency from a large number of measurements taken across the gate time, which effectively filters the result, affects the apparent stability (and therefore the ADEV), and often results in an offset which will also change with the gate time.

Counters that use single start and stop measurements at each end of the gate time would give results much closer to time interval measurements.

Time interval measurement is used a lot for precision applications, but how much of a difference it makes all depends on the particular application.

I'm not quite sure what you don't understand.  If it's how there can be problems converting frequency into phase, it's because, as you state, frequency is an average over the gate time, ie. a filter, and so, destroys information that prevents a complete, precise conversion to phase.  Phase however, is a series of instantaneous measurements that, if you make enough of them, can be precisely converted into instantaneous frequency measurements.  When measuring frequency, if you measure every cycle, you have all the information necessary to do a precise conversion, but that's almost never done.  What this all means in practice is another matter.

Ed

What I meant was that the effects due to the filtering only apply to certain counters like the the 53131A, they're not a general issue with frequency modes. With some other counters frequency and TI modes would give the similar results to each other. Some counters like the FCA3100 give both options.

[edpalmer42]

Ed-
Here's the time interval of both Rb overlaid.  It looks pretty dang good I think!   

Uh .... no.   

Go back to the noise floor test you did yesterday.  What did I say?  "You also know that anytime you see a number at 1 sec. that's better than 5e-10, something's wrong."

Now look at the graphs.  What's wrong with this picture?

Ed

[edpalmer42]

What I meant was that the effects due to the filtering only apply to certain counters like the the 53131A, they're not a general issue with frequency modes. With some other counters frequency and TI modes would give the similar results to each other. Some counters like the FCA3100 give both options.

True.  Every counter puts its own particular spin on the situation.  Sometimes it's easy to find out exactly what a particular type of counter is doing, sometimes not.  It seems like this issue only exists for frequency measurement and not for time interval.

I think Rubiola did a paper on multiple different types of counters, but I don't have a link to it.

Ed

[ArthurDent]

Ed-
Here's the time interval of both Rb overlaid.  It looks pretty dang good I think!   

Uh .... no.   

Go back to the noise floor test you did yesterday.  What did I say?  "You also know that anytime you see a number at 1 sec. that's better than 5e-10, something's wrong."

Now look at the graphs.  What's wrong with this picture?

Ed

If my graphs looked like the one you show in post #44 and #48, I would have standards labs calling me to calibrate their equipment! As you can see in the adev tables on my Rb standard shown in post #29 and below, the numbers I got are pretty darn good but no where near 10E-16 !

I agree with Ed, go back and redo the graph and see if the numbers you get are far different this time. 

[james_s]

So have we opened this thing up yet? I'm itching to find out what's in the box. 

[notfaded1]

I started opening it up and the wood on top wouldn't come off with all the top screws taken out!  I'm thinking I may have to totally remove the wood box all together to get it out.  Also here's a pic of the actual Datum 8040 I have which the sticker says was calibrated by Rohde & Schwarz.  That's the sellers table btw... not mine.

Bill

[notfaded1]

Ed-
Here's the time interval of both Rb overlaid.  It looks pretty dang good I think!   

Uh .... no.   

Go back to the noise floor test you did yesterday.  What did I say?  "You also know that anytime you see a number at 1 sec. that's better than 5e-10, something's wrong."

Now look at the graphs.  What's wrong with this picture?

Ed

I don't understand you said it looked pretty good and like the counter was working correctly???  I have my new cables and will try the test again when I get home from work.  So the hint hint was that a little over 5 on the noise floor was a problem?  Does this mean the counter has a problem then?  Until I get my GPSDO working I suppose the only thing I could do is feed one Rb into the counter as the reference and measure the other then and see what happens?  So I want the noise floor to be worse than 5E-10?

I can also try using the BG7TBL counter too but it doesn't work with time lab I don't think.

Bill

[notfaded1]

I would unscrew the two boards on the top, move them out of the way, and then remove the top of the wooden box.  That should give best visibility of whatever's inside.

I tried this yesterday and it wouldn't come off the top!  Then I put it all back together again lolol!  I need to find a short phillips one of the stubby ones to take side screws out or take the entire wood box out to get it apart I think.  It was disappointing taking all the top screws out and it not coming off!

[notfaded1]

Ed-
Here's the time interval of both Rb overlaid.  It looks pretty dang good I think!   

Uh .... no.   

Go back to the noise floor test you did yesterday.  What did I say?  "You also know that anytime you see a number at 1 sec. that's better than 5e-10, something's wrong."

Now look at the graphs.  What's wrong with this picture?

Ed

If my graphs looked like the one you show in post #44 and #48, I would have standards labs calling me to calibrate their equipment! As you can see in the adev tables on my Rb standard shown in post #29 and below, the numbers I got are pretty darn good but no where near 10E-16 !

I agree with Ed, go back and redo the graph and see if the numbers you get are far different this time.

If you're saying it's not possible I'll redo the numbers again tonight with the 50Ω Pomona cables I just got yesterday... I'll also redo the noise floor test with correct cables.  I set the counter on time interval and timelab to time interval and ran both Rb yesterday but of course repeatability is where it's at so I'll do again in case something was out of whack.  You guys are the experts...

[edpalmer42]

Ed-
Here's the time interval of both Rb overlaid.  It looks pretty dang good I think!   

Uh .... no.   

Go back to the noise floor test you did yesterday.  What did I say?  "You also know that anytime you see a number at 1 sec. that's better than 5e-10, something's wrong."

Now look at the graphs.  What's wrong with this picture?

Ed

I don't understand you said it looked pretty good and like the counter was working correctly???  I have my new cables and will try the test again when I get home from work.  So the hint hint was that a little over 5 on the noise floor was a problem?  Does this mean the counter has a problem then?  Until I get my GPSDO working I suppose the only thing I could do is feed one Rb into the counter as the reference and measure the other then and see what happens?  So I want the noise floor to be worse than 5E-10?

I can also try using the BG7TBL counter too but it doesn't work with time lab I don't think.

Bill

The noise floor test was perfect.  It showed a nice straight line at the proper slope and the 1 sec. value of approximately 5e-10 agreed with the public specification.  Then you posted two graphs that showed a 1 sec. value of 1e-16, over one hundred thousand times better than you could possibly measure.  As Arthur suggested, those numbers are beyond the reach of standards labs.  There might by a few research labs on the planet that can reach numbers like that, I'm not sure.

This has nothing to do with cabling.  This is most likely another data entry problem with Timelab.

It doesn't matter how many years you've been making these measurements.  It doesn't matter whether you're an amateur or a pro.  Dumb stuff happens.  Buttons that should be pushed, aren't.  Switches are in the wrong position.  You wanted the third item on the drop-down menu and instead chose the fourth.  You entered the wrong number in the fill-in box.  I blame the dog, even though I don't have a dog.  When you start a data run, look at *all* the Timelab screens as the data is coming in.  Do these numbers look right?  Do the trends make sense?  Can I explain why the numbers are as they are?  If not, abort the test and check everything over.  Think about what you're doing.  Do it at the start of the test when you've only invested a few minutes, not after you've wasted a few hours or days collecting data that you now have to throw away.

Never trust the dummy running the test!  The dog is smarter than him! 

Ed

[notfaded1]

All you need for this test are two pieces of BNC cable and a BNC T adapter.  Connect the T adapter to Channel 1.  Set the impedance of Channel 1 to 1M ohm.  Connect a BNC cable from one side of the T adapter to Channel 2.  Make sure the cable can't flop around and make sure that the temperature won't change during the test.  The length doesn't matter.  A meter or two is fine.  Set the impedance of Channel 2 to 50 ohm.  Feed a square wave from your 8040 to the open connector on the T adapter.  I think the 8040 has a 1 PPS output.  That would be perfect.  Set the triggering on both channels appropriately for the input signal.  Now measure Time Interval and collect the data with Timelab.  Since there's nothing between Channel 1 and 2 but a piece of cable, the delay should be very stable.  Any variation will be due to noise or limitations inside the counter.  The resulting ADEV graph will show you the best results you'll ever see from that counter.

A good rule of thumb is that the ADEV @ 1 sec. should be about the same as the minimum time interval resolution of the counter.  For the 53131A, that would be about 5e-10 @ 1 sec.  Since most good quality counters exceed their specs, you might do a bit better.

If your results are much better than spec, it means your counter is making multiple measurements and averaging them.  You have to disable that 'feature' before any of your measurements will make sense.  If your results are much worse than spec, you may have a setting wrong on your counter or a fault in your counter or your 8040.

This isn't a long test.  If you watch the ADEV graph as the data is being collected, you'll see that the 1 sec. value flops around to begin with, but stabilizes within a few minutes.  You can stop the test there.  Sometime when it's convenient, you can let the test run longer to see how far down you can go.  Eventually, the graph will become a flat, horizontal line, but that's usually so far down that there isn't any point in measuring it.

Ed

Ed-

When you said time interval for this test doesn't it meant the time interval port 1 to port 2?  I assumed that's what you mean since I have both ports hooked up with the cabled between them and T on port 1 with the Datum 8040 feeding it.  Have port 1 and 2 set to auto trigger.  My 8040 doesn't have a 1 PPS output only the 10MHz output so that's what I used.  I don't see any averaging settings.  It looks like hooked up this way the live display shows time interval bouncing around between .0001 µs and .001 µs.  I'm running the time interval again with the 50Ω Pomona cables I have now.  I'm afraid it's going to be better than when I ran the test with the video BNC cable 

Bill

[notfaded1]

Another test I want to try is measuring the time interval off the BG7TBL 10MHz out with 53131.  I wouldn't expect it to be a good as the Rb's are.

Also does the 53131 take multiple measurements and average them and if so how do you change the setting?  I'll do some reading because I don't see anything obvious that sticks out.  I haven't had this meter very long.

[notfaded1]

Good news Ed!  I think I figured out what the problem was for other people too that aren't experts with timelab.  The sampling interval has to be set.  By default it's set at 1.  From reading the descriptions of every box in timelab I read that you can click the monitor button and there's a check box that says allow timelab to sample configure the sampling interval automatically.  It's setting it lower than I had set with the defaults before at 1.  This is going to make the reading much different I think.  I'm rerunning the 8040 right now and it looks better... well worse actually but probably more correct now.  I bet if I run the T test with cable length and both ports 1 and 2 it will also read differently if I let timelab configure the sampling interval?  This is a hypothesis at this point but I'm pretty sure this is it.  A setting of 1 assumes a 1 PPS input... I'm feeding a 10MHz signal into it.  The counter is set correctly but it's the timelab defaults that don't apply to feeding it a 10MHz signal you have to change the sampling interval to match the input frequency and by God timelab can do it automatically with the 53131.  FWIW it looks like it set it to .71

Bill

[notfaded1]

In other good news the enhanced BG7TBL GNSS GPSDO just arrived from Hong Kong... I'm sure glad I paid for DHL express instead of waiting for the slow boat after all that holiday and then virus delay I already had 

Edit:  I just thought of something... I may be really careful opening the box and wipe down the GPSDO with some disinfecting wipes just to satisfy my fears 

I get anywhere from 3 to 7 SATs sitting in a window with this.  I'd like to mount in on the roof if I can find a safe way to not make my house leak.

[notfaded1]

Ed-

I'm guessing this looks better... or worse actually lolol.  Oh well, it's a learning experience.  I'll overlay the unknown box again now with the auto sampling interval turned on.

Bill

[FriedLogic]

The 53131A has a nasty habit of changing the scale of the output data for no particularly obvious reason. I normally notice it jumping between uHz and Hz since I usually remove the 10MHz, but it presumably does it between Hz and MHz too. TimeLab probably handles it if it happens during the run, but if it's different when you start the run it it might knock it out by 10^6.
See: https://www.eevblog.com/forum/metrology/adev-and-standard-used-in-measurements-of-it/msg2878578/#msg2878578

You can also log the output from the 53131A with serial terminal software, then load it into TimeLab with various settings until you're happy that it's correct. That way you also have have the original counter readings to compare to what TimeLab shows. (It's a long time since I've used TimeLab so I can't remember the details of using it)

[notfaded1]

The 53131A has a nasty habit of changing the scale of the output data for no particularly obvious reason. I normally notice it jumping between uHz and Hz since I usually remove the 10MHz, but it presumably does it between Hz and MHz too. TimeLab probably handles it if it happens during the run, but if it's different when you start the run it it might knock it out by 10^6.
See: https://www.eevblog.com/forum/metrology/adev-and-standard-used-in-measurements-of-it/msg2878578/#msg2878578

You can also log the output from the 53131A with serial terminal software, then load it into TimeLab with various settings until you're happy that it's correct. That way you also have have the original counter readings to compare to what TimeLab shows. (It's a long time since I've used TimeLab so I can't remember the details of using it)

I've seen it do this and usually restart the counter because I'm not 100% sure why it does it and was afraid restarting it was the only way to be sure it's at the defaults everywhere again.  I'm sure I'll figure out what's going on and power cycling it isn't required but for now this worked.  Once timelab starts  it's session it's pretty locked in though... but as I've found out you have to set the sampling rate first in timelab because it doesn't do much for you at all.  The defaults may not be what you need at all.  When you hover over any setting in timelab it explains exactly what the setting is for and how it works.  I just had to study and read it more.  Of course it's a let down to find out I didn't discover the bestest amazing out of this world Rb standard too in combination with the most accurate 53131 ever produced lolololol    @ArthurDent's comments really cracked me up... he was like wth is that lol.  His comment "If my graphs looked like the one you show in post #44 and #48, I would have standards labs calling me to calibrate their equipment!"

Bill

[KE5FX]

In frequency count mode, you can achieve a 'noise floor' near 1E-12 at 1 second on a 53132A.  This is really more like MDEV than ADEV, since it relies on averaging to achieve much better numbers than the counter's true single-shot resolution is capable of delivering.  But it works reasonably well for informal tests.  I've probably been a little too critical of these counters in the past, having looked over some PRS10 plots from another user recently that look pretty accurate near 1E-11 @ t=1s.

1E-16, however, is right out, as is 1E-2. 

TimeLab intentionally does as little as possible to configure the counter, because otherwise it would be a pain to support various counter models that I don't have around here.  The program's main purpose is to support instruments like TimePods and PhaseStations, so counter support is a "best effort" sort of feature.  That means the user needs to be familiar with what's actually being measured, and pay somewhat closer-than-expected attention to the measurement as it runs. 

Check the frequency count chart in the 'f' view, for instance -- does it agree with what's on the counter display?  If not, then you're getting bad data.

[tkamiya]

Why does this sound SO familiar.....   

[notfaded1]

In frequency count mode, you can achieve a 'noise floor' near 1E-12 at 1 second on a 53132A.  This is really more like MDEV than ADEV, since it relies on averaging to achieve much better numbers than the counter's true single-shot resolution is capable of delivering.  But it works reasonably well for informal tests.  I've probably been a little too critical of these counters in the past, having looked over some PRS10 plots from another user recently that look pretty accurate near 1E-11 @ t=1s.

1E-16, however, is right out, as is 1E-2. 

TimeLab intentionally does as little as possible to configure the counter, because otherwise it would be a pain to support various counter models that I don't have around here.  The program's main purpose is to support instruments like TimePods and PhaseStations, so counter support is a "best effort" sort of feature.  That means the user needs to be familiar with what's actually being measured, and pay somewhat closer-than-expected attention to the measurement as it runs. 

Check the frequency count chart in the 'f' view, for instance -- does it agree with what's on the counter display?  If not, then you're getting bad data.

I love this timelab software @KE5FX!  It works great once you figure it out some.  I'm interested in the timepods and phasestations too... I've been looking at the SR620's as well.  It's like buying an HP3458A kinda... you gotta look around to find a good one and hopefully can find a decent price with some time.  I like the idea of new technology though... some things don't change but technology doesn't usually stand still.  Usually this means you can get more for a lot less and it shrinks but not always I'm finding out with some things.  Some things stand the test of time like the 3458A.

Bill

[notfaded1]

Here's the updated overlay with the unknown Rb overlaid.  Now I need to try the T again and see what happens with the auto sampling box checked.  Then it's feeding the new GNSS GPSDO into the counter as a time reference and retesting the Rb's and testing the FA-2 10 MHz output.  Seems like a good plan.  I'm tempted to take the OCXO out of my Datum 4040A and test it too then!

Bill

[tkamiya]

Please post go to an acquisition screen.  Hit monitor, then take a screen shot.

There is a field called "numeric field".  I bet that's set wrong.

If your Rubidium is 10MHz, your counter is likely displaying 10.xxxxxx or 9.xxxxxxx.  Notice numeric field's unit is Hz.  You need to enter a multipication factor to make 10 or 9 to mean 10000000 or 9000000.  In my case, it has 1 and 1e6.  I went through this as you already know.

[notfaded1]

Please post go to an acquisition screen.  Hit monitor, then take a screen shot.

There is a field called "numeric field".  I bet that's set wrong.

If your Rubidium is 10MHz, your counter is likely displaying 10.xxxxxx or 9.xxxxxxx.  Notice numeric field's unit is Hz.  You need to enter a multipication factor to make 10 or 9 to mean 10000000 or 9000000.  In my case, it has 1 and 1e6.  I went through this as you already know.

You mean the input frequency?  Mine says 10E6 Hz that's the time interval setting on counter sampling the 10MHz Unknown Rb right now.  It's the sampling interval I got all wrong before.  I had it set at the default of 1 which is all wrong if it's not a 1PPS input... at least I think that's right?

I'm feeding it 10MHz directly from the Rb's and doing a time interval setting on timelab and on the counter.  I'm NOT feeding it 1PPS.

[tkamiya]

Please disregard what I said.  I'm using frequency method.  You are using interval method.  I apologize for the confusion.

[notfaded1]

That's ok... I can do either and like to do both eventually.  You are right though I don't want that input Hz setting set wrong... that's for sure!

I'm trying the T again now with the unknown Rb fed into the T with cable between port 1 and port 2 counter set to TI 1 -> 2.  1MΩ on port 1 and 50Ω on port 2, Auto input setting in timelab.