Found home made rubidium reference that seems to really work well

[tkamiya]

I am trying to duplicate your setup.  Feeding 10MHz to Input 1 and 2 meter cable from Input 1 to Input 2.
Counter set to 1 to 2 mode.  Mine is HP53132A.

I get graph starting around 1.77E-10.

Are you sure incoming signal is actually 10MHz???

[tkamiya]

Will you take a pic of conter's front panel and post that?

[edpalmer42]

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

Bill, don't get confused between a normal measurement and the noise floor measurement with the BNC T adapter.  The noise floor test is a one-time thing that tells you that the counter is working properly.  It tells you nothing about the signal that you're feeding into the BNC T adapter.  You did that test, you got a good result showing a 1 sec. value of about 5e-10.  Now lets move on to normal measurements.

I dug out my 53131A, dropped it on the bench, powered it up, and connected it to GPIB.  I did a noise floor test as shown. Then  I did a quick data run with my 5065A to Ch. 1 and Tbolt to Ch. 2.  Measured Time Interval as shown.  I made no attempt to filter or optimize either of these tests.  I changed nothing in any of the boxes on the Timelab Acquisition screen.  I used the 'monitor' function to set the sampling interval.  Since both inputs were 10 MHz, the 'Input Frequency' was left at the default value of 10 MHz.

As expected, the noise floor came out slightly lower than the live measurement.  These are the kinds of results that you should see with either a Rb or GPSDO.  You should not see 1e-2 or 1e-16.  Neither is realistic.  The sampling interval would have only a small effect on the graph.

Then I looked at the Acquisition screen you posted.

Houston, we have a problem.

My Acquisition screen is the same as yours except that where you are showing numbers like 1.000000042E-07, I'm seeing things like 8.7E-09.  That makes me suspicious because you've got far too many digits.  There has to be averaging going on because the values shown in the Incoming Data window are only changing by 1e-15.  That's why your graph was so good.  My numbers are varying by ~5e-10.

Is the yellow LED beside the STATS button lit?

Ed

[notfaded1]

Sure here's what it looks like with the T.

[notfaded1]

No light besides the stats button Ed... I reran the T test with the auto sample box checked this time and here's the result with the T again.  I missed using the monitor function before and it had a 1 in the box instead of what was pulled from the meter... idk about that before.  This it the new noise floor test using monitor function.  I need to rerun the second pair of tests again I think... that looks bad but I used the monitor for them feeding directly in the two Rb's using the monitor function with box checked to use it.  That looks too bad now.  I think the noise floor measurement looks more possible now.  I have to crash for now but I'll pick it up tomorrow because I'm determined to figure this out! 

IDK if I said anything but on another note I modified one of my DE-5000 Kevin clips TL-21 plugs and added long leads with bigger nice Kelvin clips.  I'm going to use this on the 4040A for testing the caps.

Bill

[edpalmer42]

That looks perfect, Bill, but we've done that test.  Don't worry about the monitor function.  It has only a small effect on the results.

Save the data from one of the traces in your last graph (one of the 1e-2 graphs).  It uses a .TIM file extension.  Zip the file and attach it to a message.  Maybe if I look at the data I can see what's going on.  In the future, it's a good idea to attach the .TIM file to every message that includes a Timelab graph.

By the way, are you using version 1.4 of Timelab?  That's the current release version.

Ed

P.S.  Please don't edit your messages.  It's hard to respond to them properly when you change them.

[notfaded1]

I've been using the latest version listed under beta on the timelab website.  I'll post the .TIM starting tomorrow too.  I've saved the .TIM for everything I've sampled up to this point so can post any of them.

Bill

[notfaded1]

Ok I stopped this before waiting an hour so hopefully someone can tell me what setting I'm getting wrong.  Attached are the acquire settings, the initial few seconds and the .TIM file zipped up because .TIM files can't be attached.

Ed or someone can maybe help me out with this?

Thanks,

Bill

[notfaded1]

The sampling interval was selected by timelab because I selected the check box in monitor window.  I left the scale factor at the default of 1.  It's a 10MHz square wave coming from unknown Rb.  The counter is set time & interval input port 1 50Ω auto trigger.  None of the math functions are selected.  When timelab starts acquisition the light next to the Stop/Single button is lit.

Also I'm running timelab 1.402(beta) should I switch to version 1.4 instead?

Bill

[KE5FX]

The sampling interval was selected by timelab because I selected the check box in monitor window.  I left the scale factor at the default of 1.  It's a 10MHz square wave coming from unknown Rb.  The counter is set time & interval input port 1 50Ω auto trigger.  None of the math functions are selected.  When timelab starts acquisition the light next to the Stop/Single button is lit.

Also I'm running timelab 1.402(beta) should I switch to version 1.4 instead?

Bill

If you're taking frequency readings, you need to tell TimeLab that's what they are.  Right now it's set for time interval readings.  Change that pulldown to 'Frequency.'  If you're taking TI readings, something else must be going wrong, but I would focus on getting it working in frequency-count mode, personally.

Can you post a screencap of your acquisition dialog with a few incoming readings displayed in the 'Monitor' area?

[notfaded1]

I was using the time interval setting on the 53131... not the frequency setting.  I selected time interval in the software as well.  I was thinking of going back to frequency in both again and trying that.  That's what I did in the beginning.  I was under the assumption that the time interval was really a better way to measure in general?

Bill

[KE5FX]

Technically it is, but it's harder for beginners to set up properly.  With frequency readings, there's no need to worry about phase wrapping, for instance.

Let's see what your incoming readings actually look like, if possible?

[notfaded1]

Here's 3 minutes worth with 53131 set on frequency and TL on frequency.

[notfaded1]

I left the 1 in sampling frequency in timelab and skipped the monitor and check box.  The front of the meter says 9,999,999,57Hz which obviously bounces around last digit just a little 1 or so plus minus.

[edpalmer42]

Bill,

To remove another confusion factor, I upgraded Timelab to 1.402.  I see your counter has Firmware Version 3944.  Mine is Version 4243.  I don't know if that's significant, but I wanted to document it.

The data in the .TIM file is being processed correctly by Timelab.  Here's a sample of the data:

   1.0000000430000000E-007
   1.0000000410000001E-007
   1.0000000410000001E-007
   1.0000000420000000E-007
   1.0000000420000000E-007
   1.0000000430000000E-007
   1.0000000430000000E-007
   1.0000000420000000E-007
   1.0000000410000001E-007
   1.0000000420000000E-007
   1.0000000430000000E-007

Here's what I see when I do the same test with my 53131A:

   6.8200000000000002E-008
   6.8200000000000002E-008
   6.7700000000000004E-008
   6.7700000000000004E-008
   6.7700000000000004E-008
   6.7700000000000004E-008
   6.7700000000000004E-008
   6.7200000000000006E-008
   6.7700000000000004E-008
   6.7700000000000004E-008

Your data is showing a lot less variability than mine.  At first, I thought there were too many digits in your data, but as you can see, mine is the same.  What *is* odd, is that in the Monitor window, my data is displayed with only 3 digits, e.g. 6.82E-008 while yours had all the digits.

The only other differences I saw in the .TIM file were:

Yours:

DBL 0x32200041 "Sample Interval" 0.69

DBL 0x3C001001 "Duration" 219420000
S32 0x00000000 "Duration Type" 5

Mine:

DBL 0x32200041 "Sample Interval" 0.95

DBL 0x3C001001 "Duration" 1
S32 0x00000000 "Duration Type" 3

I don't understand why one counter would automatically come up with 0.69 sec. while the other took 0.95 sec.

John, any significance to any of this from Timelab's point of view?

Ed

[notfaded1]

Does the GPIB have anything to do with the sample interval or just how fast the counter can sample?  I'm using a NI GPIB-USB-HS right now.  I also have a Keysight 82357B, Agilent 82357A, and Agilent 82357B I could try.  None are fakes and don't ask I got an opportunity to buy three in one day from someone and the price was right.

I'll do some reading and see if upgrading the firmware in these is doable too.  My GPSDO arrived from HK too... I just have to go pick it up.  I wonder if I should use gloves and wipe it off with Lysol wipes when I open the package lol. 

Bill

[notfaded1]

I'm finishing up an entire hour frequency measurement with frequency on the counter as you can see in picture hooked up and frequency set in timelab.  I'm attaching the pic of it running when it finishes I'll attach the .TIM and pic of the graph.

Bill

[notfaded1]

Here's the full hr freq measurement.

[edpalmer42]

Here's the full hr freq measurement.

Those numbers make no sense.  They start at -0.699... and gradually ramp down to -3600.  IOW, they're just counting the seconds.  By the way, if you haven't noticed, the .TIM file is just ASCII text.

At this point, the only thing I can come up with is to abandon GPIB and try to set up a serial port.  Use a dumb terminal program to see if you can get some raw data and see if it makes sense.  You could also write a program to pull the data from either GPIB or the serial port.

You know, you might have to consider upgrading the firmware.  I'm starting to wonder if it's corrupt - although there seems to be too much that's working right.

Ed

[edpalmer42]

Does the GPIB have anything to do with the sample interval or just how fast the counter can sample?  I'm using a NI GPIB-USB-HS right now.  I also have a Keysight 82357B, Agilent 82357A, and Agilent 82357B I could try.  None are fakes and don't ask I got an opportunity to buy three in one day from someone and the price was right.

I'll do some reading and see if upgrading the firmware in these is doable too.  My GPSDO arrived from HK too... I just have to go pick it up.  I wonder if I should use gloves and wipe it off with Lysol wipes when I open the package lol. 

Bill

Good point.  I'm using a National Instruments PCI-card in a Dual-Core Atom @ 1.66 GHz.  But I don't know if the computer would slow down the measurements when they're less than one reading a second.

It doesn't look like the counter's firmware can be updated easily.  I looked at a teardown on youtube and saw 4 socketed eprom chips.

Ed

[notfaded1]

That seems a little strange but I would try anything at this point.  I have the GPIB in a chain right now.  I'll try taking the 3458A out of the chain and maybe a different GPIB USB interface.  Couldn't hurt to try the serial but the counter seems to display everything right on the front of it frequency wise???  I was reading some about the firmware it's not old firmware per se.  Yours sounds much newer though.  Many of these can't be upgraded if they have firmware older than mine.  I'd like to think I didn't get a bad counter...  Thanks for all your help Ed... I'll look at the files some too.  I know when I hooked the counter up with labview 2020 it shows the exact same number I see in on the front when I read the GPIB with labview 2020.  I'll figure it out eventually I'm just not as experienced with this as you guys.

B

[notfaded1]

Wow I think I'm on to something removing the GPIB from the 3458.  I connected the counter directly now and pulled the plug on the counter for a few seconds then restarted it.  Now when I do the monitor it looks more like the front of the counter display.  I'm running a new sample now... fingers crossed Ed! 

[notfaded1]

Does this look better Ed?

[notfaded1]

That was too short I need to run more samples than that to see the text in the .TIM file what it's doing longer I think.  The Sigma(Tau) looks more like it should now.  Geesh I hope that was it.

[notfaded1]

Hopefully that was it Ed.  I think this looks more normal now.