Found home made rubidium reference that seems to really work well

[notfaded1]

I recently acquired this rubidium standard that came from an estate sale.  I haven't opened the wood box inside yet to see what's inside.  It may have taken a few hours to slowly reach temp and then lock up (it didn't lock in half hour so I went to watch TV a while).  It looks like after running for 25 hours it's stabilized around 86.7°F on it's temperature gauge.  Attached are some pictures I was curious if anyone had an idea what's inside the wood box?  It has 5 MHz square, 10 MHz square, and 10 MHz sine wave outputs on the front.  From initial observation it's very stable once it locked.  Before it locked the frequency wandered up and down more.  I'm going to make some better measurements over time.

I was mainly wondering if seeing this rings any bells for anyone on what it might be.  Since it's working really well I'm more hesitant to tear the wood box apart with everything mounted to the wood on the outside.  My curiosity is going to get me soon anyhow because I can't not look inside the wood box to see how the rest is built and out of which parts.  I only have two good working rubidium references so you can see my dilemma.

It has a fan mounted inside and vents on both sides but it doesn't seem to be too warm to me and require turning the fan on.  There's a manual switch inside I think's for the fan.  A sticker on top lists a measurement Sept 7, 2004 5,000,000.004 Hz @ 66.5°C / 151.7°F.  the gauge on the front only is reading 85.8°F but after 20 hours is still rising slowly.  It may slowly reach a higher temp.  I would think since it's locked up now could there be a good reason to want it higher?  Wouldn't you usually prefer the lowest temp that achieves lock?

Perhaps until I know for sure the package inside it's hard to say for sure?

Bill

[notfaded1]

Locked pic the LED is red until locked

[notfaded1]

Running also my 53131A has the 010 HS oven.

[notfaded1]

More pics

[notfaded1]

Pic I'm also hoping this reference will make my 53131A much better as a good external reference.  Comparing to a new GNSS gpsdo I ordered from BG7TBL and also comparing to symmetricom syncserver gpsdo outputs I'm thinking my quest for timenuthood will be one step further along!

Last weekend I loaded up labview 2020 and it's licensed so between that and using the raspberry pi image I got from @branadic and my 82357B or GPIB-USB-HS hooked to a pi3 I'm hopefully on track to collecting and graphing better stats.  I'm finding out windows 10 and labview sometimes acts kinda funny.  Weird timing errors and stuff with GPIB that's hard to diagnose.  The pi seem to just work and seem maybe more stable... Maybe simple is sometimes best!

The ultimate goal is more stable digits and less uncertainty to get a standard that can calibrate everything else.

Bill

[edpalmer42]

I almost bought it just to find out what was in the wooden box!    I couldn't decide if the purpose of the box was electrical or thermal isolation, or both.  The fact that it takes hours to lock suggests that the box is a fix for something that's broken.  Most Rb standards lock in 20 minutes or less.  Also, the temperature of 86F makes no sense at all.  Nothing in an Rb standard runs near that temperature.  I see the label says 60C.  That could be the temperature of an OCXO.

In general, it's not a good idea to add thermal insulation to any oscillator.  The manufacturer designed it with a specific value for heat dissipation to the ambient.  If you upset that by adding insulation, you upset the design.  Worst case, the  oven temperature just keeps going up until it fries itself due to the oscillator's normal power dissipation.

Avoid drafts and sunbeams, but don't add insulation to an oscillator unless you're the manufacturer.

Ed

[testpoint1]

Pic I'm also hoping this reference will make my 53131A much better as a good external reference.  Comparing to a new GNSS gpsdo I ordered from BG7TBL and also comparing to symmetricom syncserver gpsdo outputs I'm thinking my quest for timenuthood will be one step further along!

Last weekend I loaded up labview 2020 and it's licensed so between that and using the raspberry pi image I got from @branadic and my 82357B or GPIB-USB-HS hooked to a pi3 I'm hopefully on track to collecting and graphing better stats.  I'm finding out windows 10 and labview sometimes acts kinda funny.  Weird timing errors and stuff with GPIB that's hard to diagnose.  The pi seem to just work and seem maybe more stable... Maybe simple is sometimes best!

The ultimate goal is more stable digits and less uncertainty to get a standard that can calibrate everything else.

Bill

the inside maybe is FE5680A, you can use it as reference to test your GPSDO, as my testing, the GPSDO's frequency offset may exceed your expection.

[notfaded1]

I'll have to take it apart... I don't see much reason to build a big wood box to insulate an FE5680A the way this was done.  It's a big box for that and I thought usually those are just mounted on a metal heatsink often so it doesn't get too hot when mounted in an enclosure.

I was hoping someone might recognize the style of build and have a really good idea what someone put inside.  I'm going to see how high the temp gets to see if it gets closer to the temp written on the old label.  There are a bunch of BIG screws holding the wood box closed and the wood looks to be 3/4 to an inch thick!  This things pretty heavy too.

[syau]

Looks like a native 5Mhz unit and a frequency doubler on top of the wooden box make a 10 Mhz output.

[james_s]

It looks like it shouldn't be difficult to open up the wood box without damaging anything, the screws are exposed.

Regarding adding insulation, I'm not an expert on oscillators but I do recall seeing a teardown of a double oven oscillator that had an off the shelf OCXO within an additional oven, had the normal labels on it and everything and I think the whole assembly was HP. The oven controllers are closed loop so if you add insulation it shouldn't cause the thing to get any hotter. I suppose it's possible that some may have issues, I don't know.

[edpalmer42]

It looks like it shouldn't be difficult to open up the wood box without damaging anything, the screws are exposed.

Regarding adding insulation, I'm not an expert on oscillators but I do recall seeing a teardown of a double oven oscillator that had an off the shelf OCXO within an additional oven, had the normal labels on it and everything and I think the whole assembly was HP. The oven controllers are closed loop so if you add insulation it shouldn't cause the thing to get any hotter. I suppose it's possible that some may have issues, I don't know.

That oscillator is somewhat (in)famous.  It's a slightly modified version of the HP 10811.  There are a few on the auction site right now.  There are two stories regarding why the outer oven was added.  Whatever.  The point is that it was the manufacturer who went through the effort to determine that the extra insulation and oven winding could be safely added.  That's totally different from one of us amateurs throwing on some extra insulation.  If the internal heat generated by the oscillator can't get out fast enough, the temperature will rise.  By adding insulation, you're reducing the rate that heat can escape. 

Ed

[notfaded1]

I almost bought it just to find out what was in the wooden box!    I couldn't decide if the purpose of the box was electrical or thermal isolation, or both.  The fact that it takes hours to lock suggests that the box is a fix for something that's broken.  Most Rb standards lock in 20 minutes or less.  Also, the temperature of 86F makes no sense at all.  Nothing in an Rb standard runs near that temperature.  I see the label says 60C.  That could be the temperature of an OCXO.

In general, it's not a good idea to add thermal insulation to any oscillator.  The manufacturer designed it with a specific value for heat dissipation to the ambient.  If you upset that by adding insulation, you upset the design.  Worst case, the  oven temperature just keeps going up until it fries itself due to the oscillator's normal power dissipation.

Avoid drafts and sunbeams, but don't add insulation to an oscillator unless you're the manufacturer.

Ed

I do notice that the wood box isn't sealed.  I'm going to open it once I figure out how high this temp gauge goes up to... also there is a fan in there for some reason???  It hasn't turned on by itself there's an extra switch inside by the power supply you can see where the power comes in.

I can say this... once it locked it's been very stable on the counter... you're right about my other rubidium standard Ed.  The Symmetricom Datum locks in 15 minutes or less.  On another note I got the seller to take less than he was asking and it was reasonable so it was worth a shot.  Since it did lock I'm pretty happy with it really so far!    I'm still working on the Datum Cesium.  I think I've got some bad caps in the power block on the back of the unit.  The next step is to check every one with the DE-5000 for ESR.  I'm not exactly sure how long it took to lock because it didn't in a half hour last night and went and watched TV for a while and when I came back a couple hours later it was locked.  I'll have to time it from cold to be sure.  I'm guessing that's why someone put the clock on the front with the temp gauge... maybe to watch how long it took to lock since it's starts at 12:00 when you turn it on and counts like a regular clock.  Or maybe that's just the temp gauge he had and just used it.  It does have a nice built in backlight!    The temp of the whole metal box is mildly warm... it's not hot by any standard so the now 86.8 degrees F on the front is probably close to correct.

[james_s]

Got any data to support this? I'm not saying it's not possible, but I'd like to know if it's backed by anything or just speculation because unless you've got such amazingly high performance insulation that the thermal loss is lower than the minimum power the oven controller is capable of going to (which I'd expect to be approaching zero) then I don't see how the temperature is going to continue to rise. Certainly the handful of milliwatts consumed by a typical oscillator itself is not going to do it. I just looked at a datasheet for a random Crystek OCXO and that lists a max ambient temperature of 80C, I would be absolutely shocked if you could insulate any similar oscillator to the point that the case temperature reaches 80C.

While anecdotal at best, I've never had any issues with oscillators in high ambient temperatures. I haven't specifically tried adding insulation to a standard OCXO but I have had them running inside gear that gets quite hot. Either way given surplus OCXOs can readily be found for <$30 it's not exactly a major risk to try. In fact I have an old Datum 10MHz OCXO here I might tape a thermocouple to and pack it in styrofoam to see what happens.

[notfaded1]

More pics from the original listing... also some of labels inside were labeled heater.  Also it's got an awful lot of trimmers on there with wires going into the box???

Bill

[notfaded1]

If you look at that last pic I think maybe those few  screws on the side where the cables go in might be the place to try and open it up without interfering with all the other stuff mounted on the top and sides... a lot of the circuit boards overlap the box being screwed together with their own screws o.O!

[edpalmer42]

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.

[james_s]

Well let's do a little experiment, I don't really know what the result will be but it's easy enough to try. First I wired it up to power in free air and monitored the output while it warmed up, after about 10 minutes the case temperature seemed to have stabilized at around 97F, drifting around +/- a degree or two with drafts. I wasn't able to find any suitable foam that I could use to insulate it so I wrapped it up in an old towel and stuffed that into an insulated cooler. This is probably much better insulation than would be practical to include inside an instrument.

I'll check the temperature on my way to bed tonight and again in the morning before I head to work and see what it's gone up to. I suspect it will stabilize at about as hot as it's going to get within 30-40 minutes but we'll see.

[edpalmer42]

James,

The other thing that would be interesting to measure is the current drain.  The oscillator will have a constant drain and the oven will vary with ambient temperature.  Unfortunately, few oscillators have seperate power pins for oscillator vs. oven.  You'd expect that as you add external insulation, the oven should draw less current.  If the oven shuts off entirely, that means that the temperature is uncontrolled i.e. starting to rise.  If that happens, you might be able to see a shift in the frequency.

[james_s]

This one does actually have separate pins for power, although I tied them together for this experiment. I can try separating them and hook up meters to monitor the oven and oscillator current tomorrow.

[notfaded1]

Another thing I noticed since the temp went up a little more while locked... it looks like the last digit on my meter has now settled to varying between two digits instead of 4 or 5.  It's almost rock solid and that variation might even be just the drifting of my counters built in 010 option oscillator possibly.  I've only had this counter for a couple weeks so I'm still getting used to it.  I do like the features it has over my others.  I like that it does time interval and other stats vs. just counting like some counters do.

[edpalmer42]

James,

Somehow I missed a couple of messages in this thread.  Time to catch up.

You asked if I had any data to support the idea of burning up the oscillator by adding extra insulation.  No, I don't.  I think I read about this on Time-Nuts, but it was probably also listed there as a potential worst case.  It could even have been a discussion of putting an oscillator in a Dewar flask or in a vacuum!  Anyway, even if it happened, it wouldn't burst into flames.  But it might cook itself to death over a longer period of time.

Far more likely is the scenario I mentioned a couple of messages back where the temperature rises high enough that the oven either shuts off or becomes unstable.  Whether this happens or not will depend on the amount of extra insulation and the design of the oscillator or oven controller.  I would also suspect that older oscillators would be more susceptible to problems due to higher power drains and perhaps less sophisticated designs.

It also occurred to me that SC-cut crystals typically have a turnover temperature that are higher than an AT-cut crystal.  Does your Datum oscillator use an SC-cut crystal?  That might be why it can run in an 80C ambient.  That would also mean that oscillators equipped with AT-cut crystals might have more performance-related problems with overheating since the crystal could be running hotter than the turning point.

Ed

[notfaded1]

Some very positive initial observations comparing my we don't know what yet box to my Datum 8040 Rb
It says Datum on the front and has Symmetricom sticker on the top.
Calibrated by Rohde & Schwarz 2015-06-29

2/13/20
Measurement device: Agilent 53131A w/010 option

Unknown Rb standard
shows temp 87 degrees F on front today

05MHz sq. 4,999,999,808 Period .200,000,007,7
10MHz sq. 9,999,999,60   Period .100,000,003,9
10MHz sin.9,999,999,60   Period .100,000,003,8

Datum 8040 Locked in < 5 min.

10MHz ??  9,999,999,60  Period .100,000,003,9

That can't be all bad Ed?  I ordered 3 equal length quality BNC cables from Pamona Electronics for better comparison tests against each other.  I need to put the Datum 8040 on the scope to see if it's a square or sine wave... it doesn't say on the back.

The fact that they agree so closely is a good sign I think.    When the new cables come I'll do the port 1-2 comparisons with same exact cables and get some better data.  I've got the 53131A working in Labview 2020 but need to figure out how to take the output and with multiple samples and feed it to the analysis and graphing functions.  I may fall back on the pi3 if it takes too long.  I need good graphs now that I have the pieces all in the right places.

Thanks for all your help Ed... you've been a good asset! 

Bill

[notfaded1]

Some very positive initial observations comparing my we don't know what yet box to my Datum 8040 Rb
It says Datum on the front and has Symmetricom sticker on the top.
Calibrated by Rohde & Schwarz 2015-06-29

2/13/20
Measurement device: Agilent 53131A w/010 option

Unknown Rb standard
shows temp 87 degrees F on front today

05MHz sq. 4,999,999,808 Period .200,000,007,7
10MHz sq. 9,999,999,60   Period .100,000,003,9
10MHz sin.9,999,999,60   Period .100,000,003,8

Datum 8040 Locked in < 5 min.

10MHz ??  9,999,999,60  Period .100,000,003,9

That can't be all bad Ed?  I ordered 3 equal length quality BNC cables from Pamona Electronics for better comparison tests against each other.  I need to put the Datum 8040 on the scope to see if it's a square or sine wave... it doesn't say on the back.

The fact that they agree so closely is a good sign I think.    When the new cables come I'll do the port 1-2 comparisons with same exact cables and get some better data.  I've got the 53131A working in Labview 2020 but need to figure out how to take the output and with multiple samples and feed it to the analysis and graphing functions.  I may fall back on the pi3 if it takes too long.  I need good graphs now that I have the pieces all in the right places.  I want to get the good aDEV graphs going.  Once I get that down I'll try triple hat comparison method.  I got shipping notice on the GNSSDO from BG7TBL and it's coming DHL air mail because I don't want to wait much longer as it's already been a while due to their holiday delay and the virus!

Thanks for all your help Ed... you've been a good asset! 

I want to spend some more time on the 4040A Datum too... busy at work and busy at home o.O!  Oh my!    Too much cool stuff to figure out.

Bill

[edpalmer42]

Some very positive initial observations comparing my we don't know what yet box to my Datum 8040 Rb
It says Datum on the front and has Symmetricom sticker on the top.
Calibrated by Rohde & Schwarz 2015-06-29

2/13/20
Measurement device: Agilent 53131A w/010 option

Unknown Rb standard
shows temp 87 degrees F on front today

05MHz sq. 4,999,999,808 Period .200,000,007,7
10MHz sq. 9,999,999,60   Period .100,000,003,9
10MHz sin.9,999,999,60   Period .100,000,003,8

Datum 8040 Locked in < 5 min.

10MHz ??  9,999,999,60  Period .100,000,003,9

That can't be all bad Ed? 

Yes, those numbers seem quite reasonable.  It will be interesting to see what's inside the box.

I ordered 3 equal length quality BNC cables from Pamona Electronics for better comparison tests against each other.

I don't see the need for equal length cables.  Remember that the sources aren't synchronized, so their phases are random.  Also, a difference in cable length has no effect on frequency and just adds a constant offset to phase measurements.  There's no effect on typical timing calculations/graphs/analysis.

  I need to put the Datum 8040 on the scope to see if it's a square or sine wave... it doesn't say on the back.

When you're making these timing measurements, always use square waves.  If your source is a sine wave, you have to square it up before you measure it.  Sine waves are guaranteed to give you poor results due to inevitable noise riding on top of the signal.  This starts to get into the area of a 'black art'.  At these performance levels, it isn't just a matter of throwing in a Schmitt trigger inverter.

You should also consider whether you need to low pass filter the input to remove high frequency noise before the squaring stage.  I have a couple of 100 KW FM broadcast stations nearby that are always present - even with double-shielded coax cables.  I've sometimes seen my results improve by 2x just by adding filters to the inputs.

The fact that they agree so closely is a good sign I think.    When the new cables come I'll do the port 1-2 comparisons with same exact cables and get some better data.  I've got the 53131A working in Labview 2020 but need to figure out how to take the output and with multiple samples and feed it to the analysis and graphing functions.  I may fall back on the pi3 if it takes too long.  I need good graphs now that I have the pieces all in the right places.

There isn't a lot of benefit going to Labview when Timelab supports the 53131A natively and includes the most common timing calculations.  Labview will become useful when you need to collect data from other devices or multiple devices simultaneously.

Thanks for all your help Ed... you've been a good asset! 

Glad I can help!

Ed

[james_s]

Ok well an update on the Datum quartz OCXO experiment. Last night right before I went to bed I checked and it was 127F. This morning when I got up it was 134.4F and when I got home from work it was 136.2F so to my surprise it is still rising albeit quite slowly. I'm going to let the experiment go a bit longer than I had planned in order to see if it levels off.

I suspect what is happening is that the temperature of the housing is approaching the set temperature inside the oven, unfortunately I don't know what temperature these typically operate although I found mention online of 70-80C which is 158-176F, I suspect mine is not that hot inside though or the outside would be hotter by now than it is.

It's too early for a firm conclusion but at this point I'm going to say I strongly suspect that adding a modest amount of insulation to a quarz OCXO is *probably* fine and will not result in thermal runaway. Putting it inside a Dewar flask is another matter, that is going to be dramatically more effective insulation and losses will be limited to radiated heat and the small amount conducted through the leads. Whether or not it helps with stability I don't know, maybe someone who is set up to measure that can try a similar experiment. I would not suggest doing this on something safety critical, something you're sending up into orbit or your irreplaceable family heirloom oscillator but a cheap surplus OCXO? If you want to give it a shot why not? A few cm of foam may reduce the influence of drafts and room temperature swings without keeping in all the heat, it may work just as well though to simply put it in a closed box to keep it away from drafts although insulation may be of more benefit if the room temperature swings widely. As with anything the usual disclaimer applies, YMMV.

I would also not recommend doing this with a rubidium oscillator, they have parts that run quite a lot hotter and parts that need to be kept cooler, I recall a datasheet for one that said it should be mounted on a metal plate.

[edpalmer42]

James,

I couldn't resist - I had to try it myself.  But, unlike you, I threw caution and common sense out the window and stuffed my victim into a Dewar flask!   

I only have a few OCXOs with seperate oscillator and oven power.  I chose an Ovenaire OSC 59-52 oscillator from about 1982.  It's an old style 2x2x4 inch size.  I think it came from an HP 3330B synthesizer as the High Stability option.  1e-9/day aging, 0 - 55C.  Power drain for the oscillator was ~32ma @ 15V.  The oven draws ~75ma @ 29V in a 22C ambient.  I measured the internal temperature by taping a Type K thermocouple into the hole for adjusting the frequency.  It measured about 74C.

After a two hour sauna inside the Dewar flask, the frequency only rose by ~0.016 Hz (5 MHz nominal) and part of that would be normal drift.  When I took it out of the Dewar, the frequency rose by 0.032Hz over a period of minutes.

Over the two hour test, the internal temperature rose by ~5.4C and the oven current dropped from 74ma to 26ma.  Both surprised me.  I didn't think the temperature would change that quickly and I expected the temperature change to drive the oven current to zero.  I don't know if the design won't allow the current to go to zero or if it's just old and leaky.

The biggest surprise was the case temperature.  It started out at a nice cozy 36C.  After two hours it was 60C.   

Obviously, this wasn't a practical thing to do.  But it was interesting.  I doubt that a bit of extra insulation is helpful, but I agree that it's probably safe.

I also agree that you should never add extra insulation to a Rb standard.  A common parameter is to keep the base of the unit below 65C.  But don't go crazy.  A huge heatsink is not required or beneficial.

Ed

P.S.  It's been about 30 minutes since I removed the oscillator from the Dewar.  In that time, everything has returned to the same values as before except for the frequency.  It's now 0.03 Hz higher than the initial value.  It appears that the rise in temperature while in the Dewar partially counteracted the oscillator's attempt to drift up.  Once things cooled off, the drift was restored.  Previous tests have shown that this oscillator tends to drift up in frequency.  I don't think I can draw any conclusions regarding the effect of the temperature change on frequency.

[notfaded1]

How big is your Dewar flask?  I've wondered about putting electronics inside them.

Bill

[ArthurDent]

Any of the older style Rb oscillators that take over 10 minutes to lock or any of the newer ones that take over 5 minutes to lock I would be concerned about. Where yours takes over ½ hour to lock I would have reservations about using it unless you can find that there is some obvious problem you can correct.

I have an old FRK-HLN made in 1993 that takes 4 minutes 15 seconds to lock and has a distribution amp inside as well and I use this as my primary Rb standard. I also use a LPRO-101 that locks in 3 minutes that also has a distribution amp built in. Both units are very stable and I use a GPSDO to check them.

Here are some photos of those two units and the LPRO-101 unit’s frequency displayed on two different counters. They typically vary about .0005 max between readings and the graph shows the long-term stability of the LPRO-101 over a 12 hour period after it was adjusted to be as close as I could adjust it against my GPSDO.

[edpalmer42]

How big is your Dewar flask?  I've wondered about putting electronics inside them.

I have a couple of Pope 8600 Dewars (350 ml volume, 70 dia x 125 mm deep internal), but the ones that I experiment with are just Thermos bottles that I bought from the local second-hand store.  Look for wide-mouth bottles with plastic liners.  Keep the liner.  You can use it to fill up the space if necessary and to protect the glass from scratches.

Ed

[notfaded1]

Well it looks like maybe the 010 option in my 53131A isn't exactly rock solid.  When I get my new cables I'll feed the Datum 8040 in as the frequency standard for the counter and then measure the unknown box.  I'm glad that timelab works so easily.  Great suggestion Ed!  I'm definitely on the right track now.  When my new GNSSDO get's here I'll have a good GPSDO to check against the rubidium but the fact that both the Datum 8040 and unknown Rb are really close seems to be good.  Now I need to feed a better standard into the counter than it's upgraded oscillator option 010.  I still need to add the output connectors to my Symmetricom Syncserver as well.  That's going to require drilling out the back of one of them  to make room for the new 3 outputs and 3 inputs.  This is fun stuff.  With help from timenuts like @Ed and @AuthurDent I'm figuring a LOT more out.  I can also hook the two Rb standards to the 53131A... tell me this is it ok to use video 75Ω BNC video cables to connect these?  I have a bunch of nice 75Ω BNC cables.  I bought the Pomona cables for this reason thinking it's a no no to use 75Ω cables with test gear with 50Ω inputs because of the reflections it can cause.  I have some nice 50Ω terminators but this won't substitute for the actual cables will it?  I'm sorry for the questions I'm a CIS engineer not an EE or RF engineer but I'm learning fast.  Most of my world is crypto, networks, and digital compute, storage, and virtualization.

If it won't hurt anything I'll try with the 75Ω cables.  I understand the BNC connector may or may not be a little different with the 75Ω having smaller center pin possibly?  One thing I know... the 75Ω male BNC will fit on any 50Ω BNC female.

Bill

[edpalmer42]

Yes, the 75 ohm cables will be okay - at least for now.  For BNC connectors, 50 ohm and 75 ohm are mechanically compatible.  If you have true 75 ohm connectors (many video cables use 50 ohm connectors) there's no white insulator around the male pin or the female socket.  Once you get your 50 ohm cables, you can compare the results with both cables and see if there's any difference.

I think the 53131A has an option for 50 ohm or 1M ohm termination so you don't need the external termination.

So that ADEV graph is the frequency of the unknown Rb as measured by the 53131A?  There seems to be a slight problem here!    In the 'Acquire' screen, did you tell Timelab that the 'Data Type' is Frequency rather than Time Interval?

Ed

[ArthurDent]

Oops, in post #27 I forgot to add the photos of the two counters I mentioned in the post. The photos are now added if you're interested.

[notfaded1]

Thanks @ArthurDent... I also have a BG7TBL.  I just ran the Datum 8040 right after it locked over with the HP5313A and got this... something looks maybe not so good.  Do I need to feed the counter a better frequency standard than it's 010 option high stability oscillator to get better data?  Also does the BG7TBL work with timelab???  That would be nice but I don't think it does maybe... not sure.  So where in the picture it says ADJ you adjusted the frequency by adding some components next to the LPro-101?

Bill

[notfaded1]

Yes, the 75 ohm cables will be okay - at least for now.  For BNC connectors, 50 ohm and 75 ohm are mechanically compatible.  If you have true 75 ohm connectors (many video cables use 50 ohm connectors) there's no white insulator around the male pin or the female socket.  Once you get your 50 ohm cables, you can compare the results with both cables and see if there's any difference.

I think the 53131A has an option for 50 ohm or 1M ohm termination so you don't need the external termination.

So that ADEV graph is the frequency of the unknown Rb as measured by the 53131A?  There seems to be a slight problem here!    In the 'Acquire' screen, did you tell Timelab that the 'Data Type' is Frequency rather than Time Interval?

The 75Ω cables BNC have white insulator at the base of the PIN but NOT around it like my 50Ω cable has.

Ed

Yes that's the unknown measured by the 53131A Ed.  I used the defaults in the Acquire screen.  I'll try starting it again and check... still learning this software but it's really nice for free!  I'll check the Frequency vs. Time Interval.  I assumed since it supported the 53131 that it would configure it for the sampling?

[notfaded1]

Yes, the 75 ohm cables will be okay - at least for now.  For BNC connectors, 50 ohm and 75 ohm are mechanically compatible.  If you have true 75 ohm connectors (many video cables use 50 ohm connectors) there's no white insulator around the male pin or the female socket.  Once you get your 50 ohm cables, you can compare the results with both cables and see if there's any difference.

I think the 53131A has an option for 50 ohm or 1M ohm termination so you don't need the external termination.

So that ADEV graph is the frequency of the unknown Rb as measured by the 53131A?  There seems to be a slight problem here!    In the 'Acquire' screen, did you tell Timelab that the 'Data Type' is Frequency rather than Time Interval?

Ed

Ed-

The 75Ω cables BNC have white insulator at the base of the PIN but NOT around it like my 50Ω cable has.  I'll run the test again and check the frequency vs. time interval as I assumed the timelab would configure it.  I'm running the sample with the correct setting now... I'm an idiot and can't read apparently  Which is better way to measure frequency or time interval?  I suppose both give you information but they correlate correct?  Also yes the 53131 does have 50Ω or 1MΩ.

Bill

[notfaded1]

@ArthurDent

I really like your Rb standard... it's nice.  I've done a lot of research on the various Rb standards LPRO-101 is legit... I was hoping maybe the one in the wood box would be one actually!

Bill

[notfaded1]

Ok much better now  here's the comparison with both Rb measured by 53131.  I turned the unknown Rb off finally.  I'll let it cool down tonight and tomorrow can dig into it some more and also time the lock period better.  I'll probably open the wood box too... it's killing me not knowing what's in there.

Bill

[edpalmer42]

Yes that's the unknown measured by the 53131A Ed.  I used the defaults in the [Timelab] Acquire screen.  I'll try starting it again and check... still learning this software but it's really nice for free!  I'll check the Frequency vs. Time Interval.  I assumed since it supported the 53131 that it would configure it for the sampling?

No, the author decided not to do any configuration.  Timelab just accepts data.  You have to tell it what the data is.  Considering Timelab's price (free!), I'm not complaining.

Which is better way to measure frequency or time interval?  I suppose both give you information but they correlate correct?

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.

The reason for the difference in slope is hidden in the fog of theory.  The value of the slopes suggests that it's related to different types of noise.  The slope of -1 suggest white or flicker phase noise while -0.5 suggests white frequency noise.  I don't know why the different measurements would exhibit different types of noise.  I'm more of an application guy. 

Ok much better now  here's the comparison with both Rb measured by 53131.

Yes, much better.  But you you might be able to do even better.  You should measure the noise floor of your 53131 to see if it's working up to spec and to see what results you can expect from it.  This measurement is for Time Interval.  I don't know if the noise floor in frequency mode is the same or not.  That's a question for the theory guys. 

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

[ArthurDent]

The problem with comparing the Rb oscillator you got against your HP53131A is that you don't know how close either one is to being correct. My HP53132A also has the 010 high stability timebase like yours but I almost always use the 10Mhz from one of my GPSDOs as the external timebase. You will notice that in the photo of my HP53132A there is a pushbutton switch under the channel 3 input connector that I installed to replace the switch on the back because I got tired of reaching around back to turn the counter off. Just using the standby switch leaves the OCXO and the power supply on which I don’t like. When I bought the counter I had to replace the filter caps in the power supply that were starting to bulge and the fan that had gotten noisy due to being left on for a long time.

The OCXO you have will age(drift) at the rate of 1.5x10E-8/month so the longer it has been since you last calibrated the timebase, the more inaccurate it will be. For checking an Rb oscillator you really need a standard that is more accurate and stable than the option 010 timebase in the counter and more accurate than the Rb you’re testing. The easiest solution is a GPSDO.  If you have a GPSDO you can easily calibrate the option 010 timebase following the directions in the service manual but using that calibrated internal timebase that still won’t give you the stability and accuracy you need to check an Rb oscillator.

Both Rb standards I posted photos of have been modified and the Quartzlock unit originally had an OCXO which I replaced with the LPRO-101. The adjustment is the standard external pot arrangement shown in the LPRO-101 manual which is much easier to use than the internal adjustment. That the Rb unit you bought doesn’t show any means of adjustment make me wonder what level of accuracy the builder was requiring from the unit as they should occasionally be recalibrated against a higher standard.  Here is a photo of another LPRO-101 Rb oscillator I built showing the adjustment locations.

[notfaded1]

@ArthurDent Did you look closely at my pictures... The unknown Rb has a bunch of pots for adjustments mounted on top of the wood box in a strip.  Since right now I have no idea what they do I'm not touching them since the unit does lock.  My new enhanced GNSS GPSDO is on its way from Hong Kong now from BG7TBL.  It should give me a good idea how close I am.  The two stand alone Rb are very close to each other.  I haven't done it yet but I'm planning to upgrade one of my symmetricom sync servers with the inputs and outputs.  I have two of them one has Rb osc and I  already received the stacked BNC females for the addition from digikey... They weren't cheap at all the double BNC.  I was surprised at the price.  See pic with red circled pots.  Two of the wires are labeled heater???

Bill

[notfaded1]

Yes, much better.  But you you might be able to do even better.  You should measure the noise floor of your 53131 to see if it's working up to spec and to see what results you can expect from it.  This measurement is for Time Interval.  I don't know if the noise floor in frequency mode is the same or not.  That's a question for the theory guys. 

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 here's the results from your suggested setup with the BNC T and time interval with 75Ω cables for now... my new cables came today I just have to pick them up.  That looks pretty good on internal 010 oscillator a little better than 5 right?

Another thing I have noticed... until the Rb locks it's frequency moves around a lot... I can see it being beneficial to watch the process with timelab on startup although ADEV wouldn't seem like the measurement for that???  Whatever the deal with Rb is... it seems it's a temperature related thing.  Considering there are wires labeled heater maybe it's getting up to temp slowly and that's why it takes longer to lock?  That makes me think something may not be adjusted the way it should be... since there are so many pots on top until I open the wood box I won't know anything.  I'm timing the lock right now.

[ArthurDent]

@ArthurDent Did you look closely at my pictures... The unknown Rb has a bunch of pots for adjustments mounted on top of the wood box in a strip. 
Bill

Those adjustments aren't part of the oscillator but are a filter on the output. They look like the 10.7Mhz i.f. transformers that they used in F.M. radios. There is just a string of them in series, adjusted to 10Mhz to filter the output. They have nothing to do with the actual oscillator.

https://www.minikits.com.au/image/cache/catalog/components/ift455-03-a-320x320.jpg

[notfaded1]

It looks like right around 2 hours and 15 minutes the Rb started going green lock and then back to red unlocked.  Now around 2.5 hours it's staying green.  It went back and forth for while between red/green until it's now just solid green.  Strange behavior but it seems like some temperature thing to me.  The frequency is now stable again and I can feel the outside of the metal case is just mildly warm like it was after running for two days.  That gauge says 84.4°F.  I think the highest it goes to is around 87 after being on for longer.

My 8040 on the other hand locks in less than 5 minutes so yeah... there's a difference but from what I've seen so far the big box once it locks is pretty stable.

Bill

[james_s]

So a final update on the insulating the OCXO experiment and then I'll stop polluting this thread with it.

I let it runs all day after my last update and it eventually settled at 136.2F and stopped increasing, actually it was slowly oscillating between 136.2 and 136.1 so I assume that's as high as it would go and terminated the experiment. I very much suspect that is the internal setpoint and what happened is the added insulation allowed the outside of the casing to gradually reach the temperature inside it as heat did what heat does and flowed from the hotter region to cooler regions. I've never taken one of these apart myself but I've seen a few teardowns of similar units and it doesn't seem they have anything exotic inside, there is only so much insulating you can do without making the can excessively large.

I think it would be interesting to compare the frequency stability between OCXOs run in various conditions. Free air in a still and climate controlled room, free air in an uncontrolled space like a garage or outside, inside a closed box, inside a well insulated box, inside a DIY second oven, etc. Of course I'm sure manufactures of these oscillators have already studied all this at length.

[notfaded1]

Here's the ADEV of the time interval on the unknown Rb... looks a little better.  I'm going to overlay the 8040 time interval next. 

[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.

The relative effect of time interval errors goes down with time. An error of 1 nanosecond over 1 second is equivalent to 1E-9, but only 1.157E-14 over 1 day.
With a frequency error the time accumulates. An error 1E-12 is only 1 picosecond over 1 second, but 86.4 nanoseconds over a day.

[edpalmer42]

Ed here's the results from your suggested setup with the BNC T and time interval with 75Ω cables for now... my new cables came today I just have to pick them up.  That looks pretty good on internal 010 oscillator a little better than 5 right?

Yes, that looks good.  The result isn't due to the Option 010 oscillator, it's inherent to the counting mechanism of the counter - specifically the resolution of the timing circuit - 500 ps in this case.  So since that matches up with the counter's specs, you now have confidence that the counter is working properly.  It's also interesting to note that when you were measuring frequency, the ADEV at 1 sec. was about the same.  Looks like the noise floor is the same whether measuring frequency or phase.  The only difference is the slope.  You also know that anytime you see a number at 1 sec. that's better than 5e-10, something's wrong.  (Hint, hint) 

Another thing I have noticed... until the Rb locks it's frequency moves around a lot... I can see it being beneficial to watch the process with timelab on startup although ADEV wouldn't seem like the measurement for that???  Whatever the deal with Rb is... it seems it's a temperature related thing.  Considering there are wires labeled heater maybe it's getting up to temp slowly and that's why it takes longer to lock?  That makes me think something may not be adjusted the way it should be... since there are so many pots on top until I open the wood box I won't know anything.  I'm timing the lock right now.

What you should see is the frequency sweeping up and down over a few hundred Hertz.  As the unit heats up, the sweeps will get closer to the nominal output frequency.  Once the sweep reaches the right frequency, lock becomes possible if everything else lines up.  Until it locks, ADEV doesn't make sense, but watching the frequency graph during the warmup will show the sweeping behaviour.

It looks like right around 2 hours and 15 minutes the Rb started going green lock and then back to red unlocked.  Now around 2.5 hours it's staying green.  It went back and forth for while between red/green until it's now just solid green.  Strange behavior but it seems like some temperature thing to me.

Yeah, something's not right.  Once it locks, it should stay locked.  It's almost like one of the heaters is dead and it's just absorbing heat from around it until it kind of gets warm enough.  I predict that Rb is either headed for the repair bench or the scrap heap.  But the rest of the unit should be okay.  Just drop another Rb into the case and you'll have a nice bench standard.

Ed

[edpalmer42]

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

[notfaded1]

Ed-
Here's the time interval of both Rb overlaid.  It looks pretty dang good I think!    It's also nice to know the counter is working correctly.  When my GNSSDO comes I'll have more to compare to.  I need to decide which of the two syncservers I want to upgrade too.  The one without the Rb actually works better.  I'm tempted to try and move the Rb from the one to the other too or maybe better swap the good working one's motherboard into the Rb model and move the Rb onto it.  This way it'll have a label on the back that shows the -Rb in the model number.  Then I'll have two GPSDO's to compare to.  I like the idea of feeding the GPSDO 10MHz into the counter replacing it's internal osc to better measure the Rb's.  Then I'll better know how exact the Rb's are.  I'm thinking they're pretty close because they agree with each other.  Thanks for your help.

I turned the unknown Rb off again to cool down.  Next I should open it up since something must not be right for it to take 2.5 hours to lock solidly.  It would be nice if it would lock in under 5 minutes like the Datum 8040 does.  I'm picking up my new cables too so I can ditch the 75Ω BNC cables for this.

Bill

[FriedLogic]

Another thing I have noticed... until the Rb locks it's frequency moves around a lot... I can see it being beneficial to watch the process with timelab on startup although ADEV wouldn't seem like the measurement for that???  Whatever the deal with Rb is... it seems it's a temperature related thing.  Considering there are wires labeled heater maybe it's getting up to temp slowly and that's why it takes longer to lock?

No, ADEV is not the tool for that, but I think that Timelab can also show a normal frequency plot which is more suitable. ADEV is better for showing some things, and standard linear plots of frequency, temperature, etc., against time are better for showing others. You need both to get the best idea of what's going on - it's not a case of one or the other.

Some of the manuals for rubidium oscillators give a good explanation of what's going on. There are some Efratom ones here:
http://ftb.ko4bb.com/getsimple/index.php?id=manuals&dir=02_GPS_Timing/Efratom
Basically, the frequency is swept back and forth looking for the resonance frequency to lock on to. This won't happen until it's all got to temperature.

[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.

[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.

[edpalmer42]

That looks good, Bill.  I'd run through the noise floor test and a time interval test between the 8040 and the weird Rb just to make sure everything gives consistent results.

My bad, I never thought to ask about the cabling.  Let's cover that off now.  Are you using regular big, fat, heavy, stiff GPIB cables or something less robust and possibly more noise prone?  Regarding the 3458, the only way it should interfere is if it was set to talk only, or had the address set the same as the 53131 (i.e. set to 3) or if it's defective.  You should be able to have multiple devices on a GPIB bus.  After all, that's what it's for.  Unless you've got a defective or substandard controller.  Does the documentation for your controller say anything about 'only one device'?  I've never used one of those USB controllers.

I think I've heard of a few instruments that just don't play nice with others, but I'd be surprised to find an HP unit acting like that.

Ed

[notfaded1]

They're real big fat HP GPIB cables... I wonder if they were on the same channel or something... I know one was channel 3 on the counter.  I'll check the 3458 when I get home.  Well that's an easy fix... I'm sorry it took this long but it's a relief my counter isn't totally bogus!    Now I need to pick up the new GPSDO and test it's time too along with the 8040 again and a new noise floor test.  Wow what a crazy session o.O!  It'll be interesting to test the time interval now again as well.  Thanks for hanging in there with me on this Ed.  I appreciate @KE5FX trying to help too... it almost seems a little ridiculous on my part but oh well... stuff like this happens sometimes.  You guys are great.

Bill

[notfaded1]

Things are looking edit:  I spoke too soon those numbers are way too low. 

[notfaded1]

I ran the other Rb 8040 on top of the previous graph and they seem to line up but the numbers look low to me?

Bill

[notfaded1]

These are time interval not frequency now.  Perhaps I should go back to just frequency for troubleshooting?

[notfaded1]

It looks like the numbers that come up in the monitor window match the front of the counter now I thought that was a better sign?

[notfaded1]

Datum 8040 10 min frequency measurement.

[notfaded1]

Switched to other Rb and hit monitor for a few seconds then started capture for the second graph of unknown Rb.  The monitor window showed 9.99999957E+006 (Edit that's a plus not minus).  It sorta looks like display bug possibly because I don't have that many digits for the second graph for the input frequency and the monitor window didn't show that many digits.  That's minor though.

B

[notfaded1]

For comparison I ran the FA-2 TG7TBL LO through frequency ADEV for 10 minutes.  One things for sure... it ain't any challenge for the Rb's.

B

[notfaded1]

Unknown Rb 5MHz Sq output 10 min frequency ADEV:

B

[notfaded1]

I fed the unknown Rb into the 53131 ext reference input then plug the 8040 into channel 1 input.

This can't be all bad???
I'm running the frequency ADEV right now with TL.

B

[notfaded1]

Here's the 10 min of one Rb as ext Ref for 53131 and 8040 on channel 1.

B

[notfaded1]

Picture of the unknown Rb feeding 53131A ext reference input with Datum 8040 output feeding counter channel 1.  It just sits there stuck at 0.100,000,000,0 micro seconds in time internal setting on counter.

B

[notfaded1]

Time Interval with uk Rb feeding ext ref and measuring 8040 Rb.  Maybe I do need to try the non beta...?

B

[notfaded1]

I uninstalled the beta and installed 1.4 for the heck of it.  For the time interval I'm using the Time & Period button on the 53131 and  period 1 capture.  My monitor screen looks like attached and this is still what I'm getting.  At work they use these boxes called PXE I've heard them call them Pixie before for phase noise measurements... I looked a little but I'm not thinking I'll be able to buy a used phase station ne time soon for timelab so maybe this is going to be it for a little while.     I am looking forward to hooking up the BG7TBL GNSSDO that came.  I still have the FA-2 too and can feed it the Rb as an external reference.  This was a loooong week at work thank God it's almost Friday!

Bill

[ArthurDent]

I think your main problem is that you have too many unknowns and that you somewhat randomly choose one of your oscillators to be considered your ‘standard’ without actually knowing how accurate it really is. Cables will only contribute infinitesimally small errors and as others have said, they aren’t part of the problem here. 

I use a Trimble Thunderbolt or EBSCTM(NTPB15AA) running Lady Heather displaying all the information on a laptop in both numeric and graphic formats and the information is reliable, easy to understand, and basically self-checking. I then know I have a very stable known 10Mhz signal that I can use to compare any 10Mhz unknown to. I can then use the Thunderbolt’s known 10Mhz output to trigger my scope with the unknown 10Mhz on a vertical channel and watch for drift.

Introducing the BG7TBL FA-2 frequency counter into this mix just add another level of confusion. The internal timebase in that counter isn’t that great and I saw one owner say that his was only within 0.1Hz as received. When using the internal oscillator I can put a pencil under the front edge of the FA-2 to tip it up slightly and it will drift one way; then put the pencil under the back edge and it will drift in the other direction. That counter is great for the money but I always use an external known 10Mhz timebase with the BG7TBL FA-2 if I want to get the most accurate measurements.

The BG7TBL GNSSDO wouldn’t be my first choice to use with Lady Heather because I believe that the Trimble Thunderbolt, EBSCTM(NTPB15AA), or NTGS55AA with Lady Heather give the best information of the surplus GPSDOs available. The BG7TBL GNSSDO could be used as the external 10Mhz with your HP53131A and that would work just fine and I use the 10Mhz from my GPSDOs with my HP 53132A. I modified the EBSCTM I have so it has an internal supply and readout as shown in the photo below. That GPSDO is one of the best I have and is running 24/7.  The modified Thunderbolt I have with the EFC and OXCO leads brought out to test other oscillators allows me to use the same Lady Heather software and graphic display on all test oscillators to make it easier to compare unknowns.

[notfaded1]

Got some good news today... the GPSSDO is here!  It locked up in seconds after hooking it up.  By the time I had the USB to serial hooked up it was on 12 satellites too!  This is the newest BG7TBL I've seen advertised as "enhanced" and I ordered it with US GPS and Galileo Sats. configured.

Should be good for some better 10MHz and 1PPS.

Bill

[notfaded1]

It went down to 8 when i took that picture I'll have to watch how it moves around.  This isn't even on my +43db symmetricom antenna it's the little cheap one it came with sitting on my lab window sill.  It locked faster and onto more SATs than any GPS I've ever had before.  It sees 11 right now.

Bill

[notfaded1]

I'm not very experienced with LH i wanna see if there are other good flags to try...

[james_s]

Some of those modern GPS receivers are truly remarkable. I have a few of the little $5 Ublox modules and they will lock within a few minutes sitting in the middle of the room in my ground floor. It's astonishing that they can manage that when you look at how small of a signal they are actually grabbing.

[notfaded1]

I've never seen anything like it before o.O it was less than 5 minutes after I plugged it in it said 12 SAT's... that's a record for me.  My other devices take much longer.  I'm impressed.  I wonder if there's an easy way to see if any are Galileo SATs?  I'm figuring out how to arrange stuff in my lab so it's organized.  I had a dual one of these but just picked up a 4 way unit and the right pre-built cables to match my current hardware so I don't have to use RF adapters I have to make the connections.

I figure put the symmetricom syncserver on port 1 because it can put out up to 12V to the antenna... it'll fry little antenna like the one that came with this GNSSDO.  I also got the Type-N to TNC because my symmetricom antenna is TNC.

Bill

[notfaded1]

I took down the LH pics to edit them... prob shouldn't post that unedited... edit much better  IMA CISSP and my gut tells me that's not a good idea for some reason.

[notfaded1]

Now I can take Ed and AuthurDent's suggestion and check against the GNSSDO.  If I have to I'll hook the 53131 up with a serial cable although I think it's putting out the correct information because when I test one sample at time with Labview it says exactly what's on the front of the meter... I don't think I'm losing any data now like I was.  I think the 3458 and 53131 were both on channel 3...    How that could make my timelab ADEV look better than it should is beyond me?

[notfaded1]

When I hook the GPSSDO to port 1 on 53131 and unknown Rb to port 2 and do frequency ratio 1 -> 2 it's reading 1.000,000.  That has to be a good sign?

[notfaded1]

When I straight measure frequency of either of them it looks exactly the same they both read 9.999.999.60 or .61 back and forth.  That's the instability of the HS oscillator and it pretty much tells me my HS option 010 oscillator is set .4Hz low.

Bill

[notfaded1]

I couldn't resist... had to feed the BG7TBL GNSSDO 10MHz output into the 53131 extref input and test the unknown Rb.  Now if I could just figure out good Time Interval readings I'll be doing ok.

B

[notfaded1]

Overlaid the Datum 8040 on the other Rb graph.  The GNSSDO makes a huge difference in the counters ability to measure.  I'm convinced the 53131 has it's HS OCXO set around .4 Hz low.

B

[ArthurDent]

Your 010 option timebase in the HP 53131A should give far better accuracy than .4Hz and it can be recalibrated easily if you connect the GPSDO to channel 1 and carefully follow the steps below. Even calibrated properly the 010 option timebase isn't adequate to calibrate an Rb oscillator and the GPSDO used as an external timebase for the counter must be used. The scope method I described earlier gives good quick results, better than the counter unless you log the data over a long time as you have done previously.

Allow the Counter to warm up for approximately 24 hours before
performing this calibration. This calibration is unlikely to fail, unless
the Counter is not warmed up.

1 Connect the output of a 10 MHz house standard to Channel 1 of
the Counter as shown in Figure 2-5.

2 Press any one of the arrow keys until CAL: TIMEBAS? is displayed.
Note that the timebase choice (CAL: TIMEBAS?) only appears when the
Timebase Option is installed.

3 Press Enter key and follow the instructions in the scrolling
message that appears in the Counter display.

4 Press Enter key after each instruction.
The Counter displays CALIBRATING, and then it should display
TB CAL PASS.

If the fail message is displayed (even after the Counter has been warmed
up for 24 hours), refer to the troubleshooting section in this chapter.
This completes the High Stability Timebase Option Calibration procedure.
If all tests passed, the Counter is now calibrated.

[thinkfat]

I'd take it easy on the number of GNSS constellations enabled. In my experience, more is worse. It degrades the stability of the 1PPS signal. I disabled everything but GPS.

[notfaded1]

How does this look?  I'm reading more of the details about LH.  I'm really impressed with it and TL.  Big props for the guys that made them both and offer it up for everyone.  I need to take this GNSSDO apart and see what it's made of.  It would be neat if there's more I can get from LH than just the basic NMEA information with this version of BG7TBL device.  IDK what most people do but I edited out the coordinates on the GIF LH produced?

Bill

[notfaded1]

When I bought my 3458A a couple weeks ago I got the seller to throw in an HP 33120A since I knew I was in search of time as well as the volt.  It totally passed all it's built in extended self tests but didn't output anything.  I tested the resistance between the center of the BNC and case and it read like it wasn't connected... I started down this road because I wasn't getting any output from it.  At first I thought maybe I just didn't know how to operate the frequency generator.  I pulled up the service manual and it said the internal output fuse F801 might be open.  I opened up the case... put my Fluke 289 on continuity and checked the fuse... yep it was open as could be... NO BEEP!  I ordered replacement Littlefuse part 251.500T1 and replaced the fuse today.  Hooked it back up and it's all working now again.

I put it on channel two of 53131A while my GNSSDO was feeding as extref and when I set the 33120A on 10MHz it reads 9,999,990.82 Hz.  It looks like as with my counters own internal HS reference it too needs some adjustment.  Thanks AurthurDent for sending me in the calibration direction for the 53131... I had almost forgotten it can be adjusted without turning screws! 

I'm not as worried about 33120A as the counter and it's got a more involved verification/calibration procedure.  I'm glad I got it to put out output though.  The internal fuse was an easy fix!

Bill

[notfaded1]

Here's the pic of the fuse I replaced circled in red to fix the frequency generator.

[ArthurDent]

"IDK what most people do but I edited out the coordinates on the GIF LH produced?"

Removing that info from the top left doesn't help if you're plotting that same data on the graph at the bottom. There is no reason to plot that info because your coordinates/elevation don't change and you generally don't want others to see it. Look at what data is plotted on the graph I posted.

[notfaded1]

What setting do you use to get it like yours?  Is it possible for me to get same info?

Bill

[ArthurDent]

Different makes and models of GPSDOs display different data with Lady Heather. The graph I showed was from my NTPB15AA made by Trimble which displays the same basic info as a Trimble Thunderbolt. Your GPSDO is apparently displaying NEMA data and I'm not sure if you could make the graph look exactly like mine but you may be able to get rid of the coordinate/altitude info which isn't necessary. If you're stuck with displaying that data I would use a photo editing program and wipe out the location information so if you post a graph no one can see that your antenna is on the south side of your duplex near the window.

[thinkfat]

If this GPSDO only outputs positioning data, there is nothing worth showing anyway.

[notfaded1]

This is kinda fun... I'm a cold cathode display tube person and have a bunch of nixie tube counters.  I hooked the 5MHz Unknown Rb output to my Systron Donner Model 114 that has big nice tubes.  I have a decent distribution amp with over 10 outputs on it... it would be cool to hook up all my nixie counters at the same time and take a picture.

Bill

[notfaded1]

If this GPSDO only outputs positioning data, there is nothing worth showing anyway.

I'm hoping it actually outputs more than just that data... it's heather that defaults to NMEA correct?

[notfaded1]

Eldorado Model 225 it's nice and small and has very few controls on it.

[notfaded1]

Monsanto Counter-Timer Model 101B

[notfaded1]

Yaesu YC-355D - I don't know a lot about these but they were apparently popular with HAMs.

Bill

[notfaded1]

On another note I just bought this for a little over 100 British pounds... it's supposed to have the power supply with it. 

[notfaded1]

This is kinda an affliction I think. 

[notfaded1]

I figured out how to get slightly better screen from lady heather buy using the ublox flag.    All the great code pulled together to make this is awesome! 

Bill

[notfaded1]

The change in the graph at the bottom is pretty helpful I'd say... it's nice to know the nanosecond span 100%.

[thinkfat]

Yes, but it's still only the GPS part. The "DO" part shows up nowhere. No TFOM and FFOM and the 1PPS nanoseconds is just the output of the receiver, no relation to the output of the GPSDO. Also - this doesn't seem to be a timing receiver. Lady Heather would identify it if it was. So, no position hold mode, which is definitely bad for the 1PPS stability.

[notfaded1]

Yes, but it's still only the GPS part. The "DO" part shows up nowhere. No TFOM and FFOM and the 1PPS nanoseconds is just the output of the receiver, no relation to the output of the GPSDO. Also - this doesn't seem to be a timing receiver. Lady Heather would identify it if it was. So, no position hold mode, which is definitely bad for the 1PPS stability.

You're right about that.  The 10MHz is about as good as you can get but the 1PPS will be adjusted all over the place because it's monitoring the UBlox not the LO.  I think the perfect addition for this is a LO that can be monitored by ladyheather too.  Which do you recommend @thinkfat?

Thanks,

Bill

[thinkfat]

Well, if the serial interface output is the only port you can access, the only chance is to see if the GPS module is one of the "Frequency and Time Sync" modules from UBLOX. Those are able to discipline a LO by themselves and if you enable the correct messages, you have enough information for Lady Heather. So, the job is then to modify LH to understand this data.

If the GPS module cannot supply the disciplining data and no other interface is available, your journey ends there, if you don't want to use extra hardware.

What you could do is order a TAPR TICC (it's about $250), which LH supports, and feed it the 1PPS signal from the GPS module and the 10MHz from the LO and see what you get there. No idea if LH can work both with a GPS and the TAPR TICC but it's worth a shot.

[notfaded1]

Well, if the serial interface output is the only port you can access, the only chance is to see if the GPS module is one of the "Frequency and Time Sync" modules from UBLOX. Those are able to discipline a LO by themselves and if you enable the correct messages, you have enough information for Lady Heather. So, the job is then to modify LH to understand this data.

If the GPS module cannot supply the disciplining data and no other interface is available, your journey ends there, if you don't want to use extra hardware.

What you could do is order a TAPR TICC (it's about $250), which LH supports, and feed it the 1PPS signal from the GPS module and the 10MHz from the LO and see what you get there. No idea if LH can work both with a GPS and the TAPR TICC but it's worth a shot.

What's an alternative GNSSDO that has LO which can be monitored by LH in addition to it's monitoring of the birds?  I'm checking out the TAPR TICC.

Thanks,

Bill

[thinkfat]

Well, if the serial interface output is the only port you can access, the only chance is to see if the GPS module is one of the "Frequency and Time Sync" modules from UBLOX. Those are able to discipline a LO by themselves and if you enable the correct messages, you have enough information for Lady Heather. So, the job is then to modify LH to understand this data.

If the GPS module cannot supply the disciplining data and no other interface is available, your journey ends there, if you don't want to use extra hardware.

What you could do is order a TAPR TICC (it's about $250), which LH supports, and feed it the 1PPS signal from the GPS module and the 10MHz from the LO and see what you get there. No idea if LH can work both with a GPS and the TAPR TICC but it's worth a shot.

What's an alternative GNSSDO that has LO which can be monitored by LH in addition to it's monitoring of the birds?  I'm checking out the TAPR TICC.

Thanks,

Bill

Lady Heather should have list of GPSDOs it supports somewhere in the documentation.

Regarding the TAPR TICC, I see you have a 53131A. That should be fine, I just don't know if you'd want to dedicate it permanently towards monitoring a GPSDO

Maybe LH supports it already.

[notfaded1]

Regarding the TAPR TICC, I see you have a 53131A. That should be fine, I just don't know if you'd want to dedicate it permanently towards monitoring a GPSDO

Maybe LH supports it already.

I concur.  It might be nice to not have to dedicate the 53131A to this for sure.  I like the idea of having something that can run 24x7 and monitor the status of the GNSSDO and it would great to in addition to having a rock solid 10MHz to also having a monitored accurate 1PPS signal.  I have a nice distribution amplifier that has it's own internal 10MHz oscillator but also can pass an inputted signal.

And hey it goes to 11!!! How can that not be good???

B

[ArthurDent]

The linear modulation technology unit isn't that bad for general use but you have to remember which BNC outputs are connected together to avoid possible crosstalk.

[notfaded1]

The linear modulation technology unit isn't that bad for general use but you have to remember which BNC outputs are connected together to avoid possible crosstalk.

Any idea why they would add the one lone 11th output?  I thought that was kinda neat but also kinda strange?  That was all the room they had in a 1U space?  Do you have one too?

B

[notfaded1]

What you could do is order a TAPR TICC (it's about $250), which LH supports, and feed it the 1PPS signal from the GPS module and the 10MHz from the LO and see what you get there. No idea if LH can work both with a GPS and the TAPR TICC but it's worth a shot.

I'm looking at a different GPSDO now.  A later model Trimble Thunderbolt.  It seems to offer up more data including the LO.  It would be interesting to compare the two GPSDO to each other.  I have enough antenna connections on my splitter for them both to run together along with my sync server.

B

[ArthurDent]

The linear modulation technology unit isn't that bad for general use but you have to remember which BNC outputs are connected together to avoid possible crosstalk.

Any idea why they would add the one lone 11th output?  I thought that was kinda neat but also kinda strange?  That was all the room they had in a 1U space?  Do you have one too?

B

The photo I posted is of the unit I own.

[notfaded1]

A little clean up on the TI measurement of the unknown Rb.  After following the directions I seem to be getting better readings than I did before. 

To do Time Interval measurements with one interface on the 53131A I followed this procedure:

Example Procedure for Using Common 1 to Make Time Interval (TI)
Measurements on a Single Signal
1 Connect a signal to channel 1 of the Counter.
2 Press Time & Period key until TI 1 TO 2 is momentarily displayed. (Note that the
Time, Ch1, and Ch2 annunciators light.)
3 Press Trigger/Sensitivity key until COMMON 1: OFF is displayed.
4 Press any one of the arrow keys until COMMON 1: ON is displayed.
When the Counter is operating in Common 1 mode, the signal applied to CHANNEL
1 is used for both start and stop event. The trigger level, slope, and sensitivity for the
start signal can be modified by using the CHANNEL 1 input conditioning keys.
Whereas, the trigger level, slope, and sensitivity of the stop signal can be modified by
using CHANNEL 2 input conditioning keys. (See the figure located at the end of the
sub-section of this section titled “Overview of Trigger/Sensitivity Menu.”)

B

[Johnny B Good]

 Hi, notfaded1

 I've been reading this topic thread to while away the time whilst I await delivery of an Efratom LPRO-101 I'd ordered from a stateside dealer just over ten days ago now in the hope that you would finally break open the wooden box to reveal what I strongly suspect will be an undervolted FE-5680A.

 For some reason I thought I'd seen a later posting dated May, hence this contribution. I guess it must have been a "Last Edit:" date/time stamp I'd seen attached to an earlier posting. Anyway, if anything, the absence of any report on what you found (if you ever did get round to cracking it open  ) after more than four months since your last posting, makes the delay worse. Lucky for me that I've been reading 'ancient history' rather than following along in real time.

 So, the unanswered question remains - did you finally discover what your "unknown Rb" frequency standard was? Before you dignify that question with a reply, let me first offer the reasons for my own prediction that it's most likely going to be an "undervolted FE-5680A" before you reply.

 I could see from your photos that it was using a 12v laptop charging brick rather than the expected 19v one typically used to meet the minimum (single rail) supply voltage requirements of an LPRO-101 (19 to 32vdc, 24v recommended). That, along with what looked like a 5v smpsu board, initially suggested an FE-5680A until I checked actual voltage requirements for the FE Rb units when I discovered that they require 15 to 18vdc for the physics package as well as a separate 5v 200mA dc supply for the supporting logic, hence my referring to it as an "undervolted FE-5680A" which would neatly explain the much protracted warm up delay and the unsteady lock lamp indication.

 I suppose it's just possible that the previous owner may have modified that 12v laptop charging brick to output 15 volts but that seems rather unlikely, judging from the use of a wooden box to house a Rb oscillator that needs to be mounted on a solid heat spreader thermally coupled to ambient air (fan assisted or not).

 If I ever felt the need to modify a 12v laptop charging brick for use as an integrated 15vdc PSU, I'd be rather inclined to remove its guts and scrap the plastic housing to improve its reliability by allowing it to run some 15 to 20 deg C cooler.

 Luckily for myself, I can just use a bog standard 19v laptop charging brick as an external psu without any need to increase its output voltage ( a ripple free 19vdc supply is just about the optimum for an LPRO-101 to minimise excess heat from its internal 17v analogue voltage regulator). I've no shortage of 65W and 90W rated 19v charging bricks to choose from

 One final thought has just occurred to me regarding an outside chance of it being an LPRO-101 and that is: the 12v charging brick's output could have been placed in series aiding with the output from the 5vdc smpsu board to create a 17 volt supply, resulting in a similar undervolt condition unless the 17v analogue regulator had been strapped out of circuit inside the LPRO-101 module.

 However, otoh, a 17 volt supply is nicely within the 15 to 18 volt range for the FE-5680A' physics package and the 5v smpsu, if it's being used to lift the zero volt rail of the 12v supply, can still provide the required 5v to the support logic rail.

 It can be fun to speculate but could you please report whether or not you finally took the plunge and cracked open the box and, if so, what did you find inside?   

JBG (still awaiting delivery of an LPRO-101 that's been stuck in a global air freight terminal in Erlanger, KY since last Thursday afternnoon )

[EDIT 2020-08-25] It arrived yesterday afternoon, just before 12am. I've now got it trimmed to within 60ppt (2 cycles drift over a 9 hour overnight  run) compared to my MK II GPSDO. I'm looking to improve on that calibration attempt once I've got it housed in a thermally regulated case.

[thinkfat]

A little clean up on the TI measurement of the unknown Rb.  After following the directions I seem to be getting better readings than I did before. 

To do Time Interval measurements with one interface on the 53131A I followed this procedure:

Example Procedure for Using Common 1 to Make Time Interval (TI)
Measurements on a Single Signal
1 Connect a signal to channel 1 of the Counter.
2 Press Time & Period key until TI 1 TO 2 is momentarily displayed. (Note that the
Time, Ch1, and Ch2 annunciators light.)
3 Press Trigger/Sensitivity key until COMMON 1: OFF is displayed.
4 Press any one of the arrow keys until COMMON 1: ON is displayed.
When the Counter is operating in Common 1 mode, the signal applied to CHANNEL
1 is used for both start and stop event. The trigger level, slope, and sensitivity for the
start signal can be modified by using the CHANNEL 1 input conditioning keys.
Whereas, the trigger level, slope, and sensitivity of the stop signal can be modified by
using CHANNEL 2 input conditioning keys. (See the figure located at the end of the
sub-section of this section titled “Overview of Trigger/Sensitivity Menu.”)

B

I still don't think this is the Rb you're seeing... I'd try something different:
* Measure "Frequency 1"
* In "Gate&ExtArm", set Gate Time to 2 seconds, this yields an additional digit.

Capture the absolute frequency data with TimeLab, remember to set the interval to 2 seconds when importing.
Remember to set the scaling correctly in TimeLab. Sometimes the 53131A prints MHz, sometimes just Hz.

[tkamiya]

Do you think HP53131A has enough resolution for this purpose?  As I understand it, it's LSD resolution is 500ps.  Even if you go up to HP53132A, it's 150ps.  On top of it, reference oscillator's stability comes into play. 

500ps is 500 x 10^-12, which is 0.5 x 10^9, which isn't much.  This is regardless of how many digits you have displayed.  Typical Rb is orders of magnitude better than this.

I'm struggling with this kind of limitations myself. 

[thinkfat]

500ps is the single shot resolution, if I'm not mistaken. Measuring frequency, with a 2 second gate time he should at least be able to see something of the bg7tbl he's using as external reference.

 I'm using this setup for measuring my DIY GPSDO and while the small tau < 10s is down in the noise, I can clearly see it for larger tau. I cannot see any of my Rb though. But I can measure another commercial GPSDO just fine.

[notfaded1]

Thanks @thinkfat for this comment.  I've recently figured out that you have to set it to 2 seconds to get meaningful data from 53132A.  If you leave it at the shortest time period it's just too short.  I have a couple Cs now and a bunch of Rb so I've figured a lot of this out with trial and error.  I have a Pendulum CNT-90 as well now.  I will say if you set it to 2 seconds the 53132A gets much much better data you can use in timelab.  No one ever really told me this I had to figure it out on my own... for too long I left it at sub second and couldn't understand why it was so hard to reach -13's.  I'm using an Agilent 5071A now as my reference for the counters in some measurements which has helped.  New to me soon will be a 5065 Rb I've always wanted but I was never was around when they were really available.  I'm hoping after letting it run for a while (weeks most likely) I'll be able to test short and medium term stability with much better precision which for a reference the Cesium isn't as ideal I don't think.

Now if we could just get a timepod or phasestation that's less than 5k we'd by stylin'      Wouldn't hurt if BVA's grew on trees either!

[notfaded1]

Also now that I have other better references I'll maybe tear into the wood box this weeknd and find out what's inside since it's not really working anyhow.

Bill

[5065AGuru]

Bill, I did not read through this whole post but wondered if you had considered using a DMTD system along with your 53132A.
I used a DMTD system for a couple years with either an SR620 or an HP 53131A and had good results. The DMTD system I use now has a built in counter that eliminates a minor dead time problem that occurs with the SR620 or the 53131/132A. It works so well I sold my SR620!
I managed to work around that problem until the new counter went operational.
A DMTD would give you a AD floor at 1 Sec. of less that 2 to 4 X10-13th.
You would have to build it yourself but there are schematics and info on the web to help.

https://nvlpubs.nist.gov/nistpubs/Legacy/IR/nbsir75-827.pdf

http://www.stable32.com/A%20Small%20DMTD%20System.pdf

Also I've thought of replicating the input stages of the EFRATOM TS-105 Atomic test set. (another DMTD unit) This would allow one a much easier build for those wanting to try a DMTD system!

Cheers,

Corby

[notfaded1]

I really want a good DTMD system Corby.  I was watching this and dreaming:  https://www.ebay.com/itm/Symmetricom-TSC-5120A-Single-Box-Phase-Noise-Analyzer-Allan-Deviation-Test-Set-/164356367460

DANG even used look it sold for 15.5k!

I have an SR620 myself and both 53131 and 53132 both with 3G third interface and the 010 LO built in.  Recently I bought a nice Pendulum CNT-90 too which I like.  I bought one of the Chinese DTMD from TURN Dynamic Systems but it doesn't seem to get great numbers at all.  Lately I've been just using my 53132 with the 5071A feeding it as an external reference and it's working ok but you don't get any real phase data like you do with a DTMD.  I've been reading a bunch of papers about different devices including "Comparison of high-precision frequency-stability measurement systems"  I wish I could post the full document but it's IEEE that licensed to me at work and it stamps the PDF with my company name.  Here's the Abstract:

The performance of two commercial high-precision frequency-stability measurement systems, timing solutions 5110A time-interval analyzer and Quartz lock A7 frequency and phase comparator, has been compared with two laboratory dual-mixer time-difference (DMTD) systems developed at the institute of radio engineering and electronics (IREE), Prague, and istituto elettrotecnico nazionale "Galileo Ferraris" (IEN), Turin, respectively. Two BVA oscilloquartz 5 MHz oscillators with Allan deviation (ADEV) around 1/spl times/10/sup -13/ at averaging intervals 1 s to 30 s were used as test-signal sources. In terms of the best-measurement-capability (BMC), the compared systems have shown the background noise at 5 MHz of ADEV=4.2/spl times/10/sup -14/ at 1 s in IREE-DMTD, 4.4/spl times/10/sup -14/ in IEN-DMTD, 7.4/spl times/10/sup -14/ in A7, and 8.8/spl times/10/sup -14/ in 5110 A, respectively. The 5110 A analyzer behaved the best concerning the dependence on departures from the BMC conditions.

Great paper!  Here's the noise floor samples from the devices:

I'm learning fast but I'm a Computer Scientist and not really an EE so it takes me a little longer to figure some things out but I learn fast.  I want to do exactly what you're talking about Corby.  Even with many of these DTMD they still use an SR620 as the TIC for the experiment.  See second picture.

Bill

[FriedLogic]

There was this 'DIY' version from a decade ago:
http://www.wriley.com/A%20Small%20DMTD%20System.pdf
I did hear something about there being an update for it, but I don't know the details.

A variation on the theme:
http://www.ke5fx.com/tpll.htm

Quite a few people have made their own, but other than the Small DMTD above I've not come across any that have been documented to allow others to easily play along, which is a pity. Many people have little enough time for their hobby without having to design and build the test gear from scratch, so I'm sure it would be appreciated. Maybe even with money, although that can bring more problems than it's worth.

[5065AGuru]

FriedLogic,

There have been a couple nice systems offered in the past on TimeNuts at VERY inexpensive costs.
Unfortunately not enough takers, and as is sadly the case a lot of the time, people nit picked it and it went away.
It and a later version are my main and backup DMTD.
Like I mentioned before I will look over my notes on using the EFRATOM TS-105 mixer scheme and make a board to test. If it has promising results I will share the performance/parts list/schematic/and ExpressPCB file.
The SR620 and 53131/2A are major overkill with a DMTD
With a 1Hz offset oscillator you would count the time interval between the DUT and REF 1PPS outputs.
If operating at 10Mhz and the counter has 9 digits the resolution of the LSB is 1X10-15th.
So using 12 digits from a fancy counter will give you and LSB of 1X10-18th! Even with 9 digits the last couple digits are "noise"!

Cheers,

Corby

[notfaded1]

Good Morning Corby-

I'm totally game if you put together a formula for a working DTMD.  I can assemble just about anything if we have a good PCB and known parts.  I've been studying all the diagrams and papers but it's just a bridge too far for me to just whip one together at this point (and build the pcb layout).  At its foundation it's really a few different parts that work together.  But then what parts really will work together.  What mixers, what splitter, how to offset the reference, zero crossing detector and it is RF after all too which is a kind of black magic.

Best Regards,

Bill

[5065AGuru]

Bill,

I've just about finished the board layout. Hope to have it double checked this weekend!
I'll order the Standard mini board which will give me 3 boards.
Once they arrive  I'll assemble one and make sure it does what we want.
Will let you know!

Cheers,

Corby

[thinkfat]

Bill,

I've just about finished the board layout. Hope to have it double checked this weekend!
I'll order the Standard mini board which will give me 3 boards.
Once they arrive  I'll assemble one and make sure it does what we want.
Will let you know!

Cheers,

Corby

I'm in the same board. I'll happily assemble something, provided I have a PCB and BOM. Gerber files and Schematic would be even more awesome!

[notfaded1]

Bill,

I've just about finished the board layout. Hope to have it double checked this weekend!
I'll order the Standard mini board which will give me 3 boards.
Once they arrive  I'll assemble one and make sure it does what we want.
Will let you know!

Cheers,

Corby

I'm totally psyched Corby!  I really appreciate your experience with this.  I've made some strides in my measurement this year for sure.  A working DMTD that I could interface to timelab or load data into Stable32 would be ideal.

Bill

[notfaded1]

I'll be firing up the 5065 this weekend as well... lot's of fun!  Can't wait to let it burn in a little while.    I like the timenuts email forum but there's something really nice about having a true HTML5 web board like we have here on eevblog.  I have some other Rb that would be perfect to test against the 5065 once it settles in... couple AccuBeat AR40A, Datum 8040, Efratom FRK-S, Efratom M-100, a few Efratom LPRO-101, LEA-6T disciplined SRS PRS-10, GNSS disciplined Latlon-Rb-102, and some other GPS OCXO including FEI PicoSync, Thunderbolt (gold type), Thunderbolt E, BG7TBL GNSS OCXO, Datum Exactime 6010, HP Z3805A, Symmetricom Mark V (this one is neat it has Trimble Force 22 GPS in it and Rb LO).  I've been saving all my data from TimeLab as I progress... I've learned so much by trial and error and experimentation.  I think I'd like to do an Rb study and a separate GPS disciplined Rb/OCXO one.  I love seeing the graphs overlaid on top of each other comparing the results.

Bill

[FriedLogic]

There have been a couple nice systems offered in the past on TimeNuts at VERY inexpensive costs.
Unfortunately not enough takers, and as is sadly the case a lot of the time, people nit picked it and it went away.
It and a later version are my main and backup DMTD.

I cringe when I see someone asking for features that others would like to have in some project. The resulting daft wish list can delay or derail the whole thing.
What I more had in mind was just making the design files and maybe some basic notes available on a 'you might find this useful/interesting' basis, like a lot of the stuff that finds its way onto GitHub.

Like I mentioned before I will look over my notes on using the EFRATOM TS-105 mixer scheme and make a board to test. If it has promising results I will share the performance/parts list/schematic/and ExpressPCB file.

Thanks, I'd be very interested in seeing that.

The SR620 and 53131/2A are major overkill with a DMTD
With a 1Hz offset oscillator you would count the time interval between the DUT and REF 1PPS outputs.
If operating at 10Mhz and the counter has 9 digits the resolution of the LSB is 1X10-15th.
So using 12 digits from a fancy counter will give you and LSB of 1X10-18th! Even with 9 digits the last couple digits are "noise"!

With the increasing price of electricity, another issue these days is energy consumption. A relatively simple TDC based timer might work here.

[notfaded1]

With the increasing price of electricity, another issue these days is energy consumption. A relatively simple TDC based timer might work here.

The electricity is the least of my issues... I live in the southwest desert of Arizona to begin with and the AC runs basically 8 months out of the year.  Very little humidity though!!!

I also have a TURN Dynamic Systems DMTD but didn't have great results at first with it... I should probably try it some more now that I have better references.  Can't wait to see what Corby comes up with.

Bill

[Johnny B Good]

@notfaded1

 Just a quick question. Did you ever discover what was actually inside that wooden box? 

[EDIT 2022-01-08]

 Well, did you?