[time-nuts] Phase measurement of my GPSDO

[Bob kb8tq]

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 <tpluess at ieee.org> 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 <kb8tq at n1k.org> 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 <tpluess at ieee.org> 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 <bobqhome at live.com> 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 -- time-nuts at lists.febo.com
>>>> 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 -- time-nuts at lists.febo.com
>>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>>> and follow the instructions there.
>> 
>> 
>> _______________________________________________
>> time-nuts mailing list -- time-nuts at lists.febo.com
>> 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 -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.