Hi Without a local reference that is *better* than your expected performance, there is no simple way to know what’s going on. Ideally you would like any measurement to be based on a reference that is 5X better than the expected result (tolerance wise). If you are looking for 1x10^-12, the ideal reference would be < 2x10^-13.
One way around this is to build several of a given design and then compare them to each other. You still have the issue of “common mode” noise. If they all drift exactly + 1 Hz per day, you will never be able to tell … A very normal way to test a GPSDO design is to use a Cs standard for the longer tau and a “known good” OCXO for the shorter tau. Bob > On Apr 3, 2020, at 11:20 AM, Tobias Pluess <[email protected]> wrote: > > Hi Bob > > knowing that my counter's noise floor is terrible (even though I still > don't understand why) I tried to measure the ADEV and MDEV of my GPSDO > against another GPSDO. > From the graphs, everything below tau=10s is, I would say, rubbish. But I > tend to mistrust these complete results, as I have no means of finding out > whether my reference is so bad or my own GPSDO. The reference is an eBay > GPSDO, and as we all know, these are sometimes of doubtful pedigree. > But still, below the 10s tau, the ADEV and MDEV are so close to the noise > floor that I would say this measurement is useless. > > But it still does not explain why my 5335A is so bad. > > > Tobias > HB9FSX > > > On Thu, Apr 2, 2020 at 10:17 PM Bob kb8tq <[email protected]> wrote: > >> Hi >> >> What you have measured *is* the noise floor of a 5335 when trying >> to use it to measure ADEV. Anything past the numbers on your plot >> will be “past” what the 5335 can “see”. Indeed, even when you get >> close to those numbers, things may get a bit weird due to the fact >> that you are measuring counter “noise” plus device noise. >> >> Bob >> >>> On Apr 2, 2020, at 3:13 PM, Tobias Pluess <[email protected]> wrote: >>> >>> Hello all >>> >>> in the meantime I figured out most of my problems and my GPSDO is working >>> now with some very ugly prototype code. Today, I wanted to do some ADEV >>> measurements. >>> My plan was to compare the 1PPS generated from my GPSDO to the 1PPS of my >>> Oscilloquartz STAR4; unfortunately I have nothing else (like Rb or so) >>> which is perhaps more stable. So I try with the STAR4 and see where I >> get. >>> However, before I did any meaningful measurements, I wanted to see what >> the >>> noise floor of my test equipment is. >>> Again, unfortunately I have nothing better than a HP 5335A with 1ns >>> resolution in TIC mode. I measured the noise floor of the TIC as follows: >>> the 1PPS output of my GPSDO was connected to a resistive power splitter, >>> and then, one output of the splitter went to channel A of the TIC (START >>> signal) while the other output from the splitter went first to a long >> cable >>> and then to channel B. With this, I achieved about 16ns of delay. >>> I then used the TIC together with Timelab and measured the ADEV of this >>> setup. >>> As far as I understand, if the delay of the cable stays constant (which >> it >>> does as long as it is not moved and the temperature stays the same), all >> I >>> see in the ADEV plot is the ADEV of my counter itself. Right? >>> >>> So I let this test run for one hour (collected 3600 samples), and the >>> result looks terrible. See the attached file. I did the test twice; once >> I >>> used the STAR4 GPSDO as external reference for the counter, and once I >> used >>> its internal reference, which is a HP 10544A oven. As one can see, the >> ADEV >>> at 1sec is between 7e-10 and 8e-10. I don't know yet what numbers I can >>> expect from my GPSDO, but from datasheets of commercial GPSDOs I saw that >>> the ADEV shortly after powerup should be in the 1e-11 region. So how does >>> one measure such low ADEVs? >>> >>> To me, it appears that the ADEV at 1sec is roughly the counter's >>> resolution; a bit less due to averaging. If I take averaging over 3600 >>> samples into account, I think I could expect maybe ~1ns/sqrt(3600) = >>> 16.7e-12 as ADEV at 1 second, but we can clearly see that this is not the >>> case. So there are two interesting questions arising: >>> >>> a) I think the ADEV is so high because of the quantization error of the >>> counter. Assume the time interval measured is right at the transition >> from, >>> say, 15ns to 16ns, even the smallest amount of noise will produce some >>> alternating readings of 15ns and 16ns, which, in turn, results in an ADEV >>> around 1e-9, right? Further, why is this effect not averaged out with >>> sqrt(# of samples)? >>> >>> b) if I want to measure 1e-11 or even 1e-12 at 1sec - what resolution >> does >>> my counter need? If the above was true, I would expect that a 1ps >>> resolution (and an even better stability!) was required to measure ADEV >> of >>> 1e-12, The fact that the (as far as I know) world's most recent, >>> rocket-science grade counter (some Keysight stuff) has "only" 20ps of >>> resolution, but people are still able to measure even 1e-14 shows that my >>> assumption is wrong. So how are the measurement resolution and the ADEV >>> related to each other? I plan to build my own TIC based on a TDC7200, >> which >>> would offer some 55ps of resolution, but how low could I go with that? >>> >>> >>> Best regards >>> Tobias >>> HB9FSX >>> >>> >>> >>> On Fri, Mar 20, 2020 at 5:34 PM Bob Q <[email protected]> wrote: >>> >>>> I have seen differences between both UCT and Oscilloquartz 8663 ocxo’s. >>>> The attached plot shows an example. Both boxes use Ublox LEA-6T >> receiver, >>>> surveyed in, AD5680 DAC 18 bit DAC, same level shift circuit and same >>>> control circuit. The reference is an LPRO-101. The Oscilloquartz ocxo >> was >>>> purchased used. Both UCT ocxo’s (only the better one is shown) were >>>> purchased new and have 100’s of operating hours. I have also seen >>>> differences with constant EFC control voltage. The differences limit >> what >>>> performance you can >> achieve._______________________________________________ >>>> time-nuts mailing list -- [email protected] >>>> To unsubscribe, go to >>>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>>> and follow the instructions there. >>>> >>> <figure-1.png>_______________________________________________ >>> time-nuts mailing list -- [email protected] >>> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >>> and follow the instructions there. >> >> >> _______________________________________________ >> time-nuts mailing list -- [email protected] >> To unsubscribe, go to >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com >> and follow the instructions there. >> > <adev_mdev.png>_______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com > and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
