Re: [time-nuts] HP5065A C-field mods and optical unit mods --> OFF LIST !!!

[Bob kb8tq]

Hi

So, when do they go up for sale? :)

( = If and when they do, I’m still shopping for one)

Bob

> On Nov 16, 2017, at 3:58 PM,   wrote:
> 
> HP5065A C-field mods and optical unit mods
> 
> In addition to the power supply mods:
> -removed AC components
> -power now supplied with an external DC lab grade low noise 
> highly regulated supply.
> -temperature coefficient of +20 Volt supply adjusted to be 
> below 1PPM/deg C
> See: https://www.febo.com/pipermail/time-nuts/2017-August/106634.html
> 
> 
> I've now installed the improved C-field circuit that has
> less than +- 1PPM variation per degree C.
> 
> The optical unit has been installed into a sealed enclosure
> that has been purged with dry Nitrogen. This eliminates
> any Barometric pressure effects and also eliminates
> drift caused by Helium permeation.
> 
> Tests at this point show a very nice long term stability.
> 
> Last mod will use a small PC closed loop liquid cooler to
> keep the outside of the sealed enclosure at a constant temperature 
> essentially making it a double oven.
> 
> 
> I'm also working on:
> 
> An active temp compensation scheme to add to the
> active barometric compensation I outlined earlier. 
> See: https://www.febo.com/pipermail/time-nuts/2016-May/097829.html
> 
> And a passive optical unit temperature compensation using a
> thermistor/resistor
> arrangement.
> 
> PIX shows the sealed optical unit installed into a slightly taller
> chassis. (The 5065C ?)
> 
> Cheers!
> 
> Corby<5065crs.jpg>___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

[time-nuts] HP5065A C-field mods and optical unit mods

[cdelect]

HP5065A C-field mods and optical unit mods

In addition to the power supply mods:
-removed AC components
-power now supplied with an external DC lab grade low noise 
 highly regulated supply.
-temperature coefficient of +20 Volt supply adjusted to be 
 below 1PPM/deg C
See: https://www.febo.com/pipermail/time-nuts/2017-August/106634.html


I've now installed the improved C-field circuit that has
less than +- 1PPM variation per degree C.

The optical unit has been installed into a sealed enclosure
that has been purged with dry Nitrogen. This eliminates
any Barometric pressure effects and also eliminates
drift caused by Helium permeation.

Tests at this point show a very nice long term stability.

Last mod will use a small PC closed loop liquid cooler to
keep the outside of the sealed enclosure at a constant temperature 
essentially making it a double oven.


I'm also working on:

An active temp compensation scheme to add to the
active barometric compensation I outlined earlier. 
See: https://www.febo.com/pipermail/time-nuts/2016-May/097829.html

And a passive optical unit temperature compensation using a
thermistor/resistor
arrangement.

PIX shows the sealed optical unit installed into a slightly taller
chassis. (The 5065C ?)

Cheers!

Corby___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Interpreting and Understanding Allen DeviationResults

[Tom Van Baak]

Jerry:
> For time interval as discussed below, the unaltered GPSDO output goes to A and
> how do you create the GPSDO delay for B without a physical coax delay?

You are correct. In Randal's hp 5335A frequency counter experiment he was 
splitting a single GPSDO 10 MHz output to both the REF input and the chA input. 
As such, as you thought, no amount of GPS h/w or s/w delay would affect the 
phase difference between those two ports.

Bob:
> One “cute” thing to do when looking at GPSDO’s or GPS modules is to use the 
> “cable delay”
> setting. It will allow you to move the pps of one unit relative to the pps of 
> the other one.

Note the plural. What Bob is saying here applies to the case where you have two 
or more GPS timing receivers, or one GPS timing receiver and a local atomic 
clock. In these cases adjusting the s/w antenna delay is an easy way to adjust 
the phase of one of the signals.

I use this method when I want to introduce large delays, many us or ms. Most 
timing receivers offer a way to shift the phase of the 1PPS. For small delays 
it may not work like you expect. If it's a plain GPS/1PPS board there will be 
plenty of 1PPS jitter so changing the antenna delay by a few ns or few tens of 
ns may not be immediately visible. For a GPSDO it depends on how the firmware 
handles the antenna delay parameter. If it's a FLL-based GPSDO the antenna 
delay has no effect. If it's a PLL-based GPSDO the unit may go into holdover, 
or jam sync the 1PPS, and/or begin the slow process of slewing the output 
frequency to get the oscillator output to match the now-shifted GPS/1PPS output.

Does anyone have experience with binary programmable video delay boxes like 
http://www.allenavionics.com/V_Delay/var.htm which are found on eBay all the 
time?

/tvb


- Original Message - 
From: "Jerry" 
To: "'Discussion of precise time and frequency measurement'" 

Sent: Thursday, November 16, 2017 9:05 AM
Subject: Re: [time-nuts] Interpreting and Understanding Allen DeviationResults


Bob,

I am also a time newbie... how do you adjust this in software?  For time 
interval as discussed below, the unaltered GPSDO output goes to A and how do 
you create the GPSDO delay for B without a physical coax delay?  Any change in 
GPSDO cable delay setting will affect A and B the same.  Sorry if this is a 
stupid question

Jerry, NY2KW

-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob kb8tq
Sent: Thursday, November 16, 2017 11:15 AM
To: Discussion of precise time and frequency measurement 
Subject: Re: [time-nuts] Interpreting and Understanding Allen Deviation Results

Hi

Yes, that’s exactly what I’m saying. You just use the software rather than 
dragging around a big hunk of coax. It makes it easy to get one pps into the 
“that’s way more than I need” range.
With the coax approach, is 50NS enough? Might 100NS be needed? Is there a 231NS 
case?.
I’ve spent a *lot* of time finding those cases in the middle of long data runs 
….

Bob

> On Nov 16, 2017, at 10:37 AM, Jerry  wrote:
> 
> Bob,
> 
> Do you mean then you do not need to put a physical long length of cable for 
> the delay, just do it in software or do you do both?
> 
> Jerry, NY2KW
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob 
> kb8tq
> Sent: Thursday, November 16, 2017 9:58 AM
> To: Discussion of precise time and frequency measurement 
> 
> Subject: Re: [time-nuts] Interpreting and Understanding Allen 
> Deviation Results
> 
> Hi
> 
> One “cute” thing to do when looking at GPSDO’s or GPS modules is to use the 
> “cable delay” setting. It will allow you to move the pps of one unit relative 
> to the pps of the other one. You then can be sure of which pps happens first. 
> That makes the A to B measurement much easier to analyze. 
> 
> Short intervals also can lessen the impact of the time base accuracy in the 
> counter ( you always are measuring a microsecond or so to a nanosecond 
> resolution). Indeed there are other issues (like jitter) that still are an 
> issue. 
> 
> Bob
> 
>> On Nov 16, 2017, at 4:10 AM, Azelio Boriani  wrote:
>> 
>> As already stated here, the best measurement mode is the 
>> time-interval mode. The 5335A is a 2ns single-shot resolution 
>> counter. Use the PPS output from the GPSDO, route it to the A (start) 
>> input and to a coaxial cable used as a delay line (10m, 50ns, should 
>> be enough). The other end of the cable into the B input (stop), 
>> select the time interval mode TIME A -> B. Let the internal reference 
>> clock the counter. Set trigger levels and the various parameter to 
>> get stable readings and collect your data.
>> 
>> On Thu, Nov 16, 2017 at 3:59 AM, Mike Garvey  wrote:
>>> Could you post some phase plots?  The data you show is not 1/tau and very 
>>> likely not white 

Re: [time-nuts] Deaf Z3801

[Bob Bownes]

However, setting it to 23:59:59 Dec 12,2007 and leaving t alone for an hour
or two seems to have done the trick.

Thanks folks! Off to look at adev/pn of the $7 GPS boards I found with
10MHz out. Plots soon.

Bob


On Thu, Nov 16, 2017 at 12:26 PM, Bob Bownes  wrote:

> Yup. tried that too.
>
> The system won't let me set the date after 23:59:59 Dec 12,2007
>
>
>
> On Thu, Nov 16, 2017 at 11:42 AM, Bob kb8tq  wrote:
>
>> Hi
>>
>> One thing that has faked me out on SCPI - they cache error messages. You
>> have to dump them all before you try something.
>>
>> Bob
>>
>> > On Nov 16, 2017, at 11:24 AM, Bob Bownes  wrote:
>> >
>> > Thanks John.
>> >
>> > When I do this, I get the E-222 error indicating 'Data out of range'.
>> >
>> > Tried several formats, trailing';', etc.
>> >
>> > Here's what I get:
>> > scpi > :GPS:INIT:DATE 2017,11,16
>> > E-222> :GPS:INIT:DATE 17,11,16
>> > E-222> :GPS:INIT:DATE 17,01,01
>> > E-222> :GPS:INIT:DATE 2017,01,01
>> > E-222> :GPS:INIT:DATE 2017,01,01;
>> > E-222> :GPS:INIT:DATE 17,01,01;
>> > E-222>
>> >
>> > Even tried a :SYSTEM:PRESET, whic interestingly enough, does not reset
>> the
>> > location.
>> >
>> > Bob
>> >
>> > On Wed, Nov 15, 2017 at 8:49 AM, John Franke  wrote:
>> >
>> >> Try:
>> >>
>> >>
>> >> Shut off power to the GPS receiver
>> >>
>> >> Disconnect the GPS antenna downlead
>> >>
>> >> Reapply power to the GPS receiver
>> >>
>> >> Enter  *:GPS:INIT:DATE 2017,01,01* (The only space is between DATE and
>> >> 2017)
>> >>
>> >> Reconnect the GPS antenna downlead and wait
>> >>
>> >>
>> >> John
>> >>
>> >> On November 14, 2017 at 10:43 PM Bob Bownes  wrote:
>> >>
>> >> I put my 3801 back in service the day before yesterday, or tried to.
>> It’s
>> >> been on the shelf for about a year (off).
>> >>
>> >> I powered it up, and while it sees a few sats, it will not acquire any.
>> >> Changing to a known good antenna (off the NTP server) makes no
>> difference.
>> >>
>> >> Anyone seen the behavior before? The location data is good, but the
>> >> time/date are way out.
>> >>
>> >> Thanks!
>> >> Bob
>> >>
>> >> ___
>> >> time-nuts mailing list -- time-nuts@febo.com
>> >> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> >> mailman/listinfo/time-nuts
>> >> and follow the instructions there.
>> >>
>> >>
>> > ___
>> > time-nuts mailing list -- time-nuts@febo.com
>> > To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> ailman/listinfo/time-nuts
>> > and follow the instructions there.
>>
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/m
>> ailman/listinfo/time-nuts
>> and follow the instructions there.
>>
>
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Interpreting and Understanding Allen Deviation Results

[Azelio Boriani]

If you have only one GPSDO, a coaxial cable is your best friend to
test the performance of the counter in time-interval mode. If you have
two GPSDOs, the Segal's law apply:
, better go directly for
three.

On Thu, Nov 16, 2017 at 7:18 PM, Bob kb8tq  wrote:
> Hi
>
> The exact software command used depends on the GPSDO you have. How you send 
> the command to
> the GPSDO depends a bit on the driver software you are running. Not all 
> GPSDO’s or modules have
> cable delay. All the ones I run do have the feature. Normally it comes set to 
> some random default setting
> like 60 ns. I typically take one GPSDO and deliberately make it the odd one 
> out of the group. By making
> the offset large (say a microsecond or two) it’s easy to spot the “false 
> ticker” in the group if things get
> mixed up.
>
> Assuming you set the odd GPSDO to be early (which could be cable delay + or 
> cable delay -) it would
> go to input A on the counter. That would be the start channel. Input B would 
> come from any normal
> pps signal and it would be the stop channel. You can of course do this other 
> ways that work just as
> well.
>
> Again - this is for looking at a pps relative to a GPSDO using a 5335 or 
> similar counter.
>
> Bob
>
>> On Nov 16, 2017, at 12:05 PM, Jerry  wrote:
>>
>> Bob,
>>
>> I am also a time newbie... how do you adjust this in software?  For time 
>> interval as discussed below, the unaltered GPSDO output goes to A and how do 
>> you create the GPSDO delay for B without a physical coax delay?  Any change 
>> in GPSDO cable delay setting will affect A and B the same.  Sorry if this is 
>> a stupid question
>>
>> Jerry, NY2KW
>>
>> -Original Message-
>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob kb8tq
>> Sent: Thursday, November 16, 2017 11:15 AM
>> To: Discussion of precise time and frequency measurement 
>> Subject: Re: [time-nuts] Interpreting and Understanding Allen Deviation 
>> Results
>>
>> Hi
>>
>> Yes, that’s exactly what I’m saying. You just use the software rather than 
>> dragging around a big hunk of coax. It makes it easy to get one pps into the 
>> “that’s way more than I need” range.
>> With the coax approach, is 50NS enough? Might 100NS be needed? Is there a 
>> 231NS case?.
>> I’ve spent a *lot* of time finding those cases in the middle of long data 
>> runs ….
>>
>> Bob
>>
>>> On Nov 16, 2017, at 10:37 AM, Jerry  wrote:
>>>
>>> Bob,
>>>
>>> Do you mean then you do not need to put a physical long length of cable for 
>>> the delay, just do it in software or do you do both?
>>>
>>> Jerry, NY2KW
>>>
>>> -Original Message-
>>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob
>>> kb8tq
>>> Sent: Thursday, November 16, 2017 9:58 AM
>>> To: Discussion of precise time and frequency measurement
>>> 
>>> Subject: Re: [time-nuts] Interpreting and Understanding Allen
>>> Deviation Results
>>>
>>> Hi
>>>
>>> One “cute” thing to do when looking at GPSDO’s or GPS modules is to use the 
>>> “cable delay” setting. It will allow you to move the pps of one unit 
>>> relative to the pps of the other one. You then can be sure of which pps 
>>> happens first. That makes the A to B measurement much easier to analyze.
>>>
>>> Short intervals also can lessen the impact of the time base accuracy in the 
>>> counter ( you always are measuring a microsecond or so to a nanosecond 
>>> resolution). Indeed there are other issues (like jitter) that still are an 
>>> issue.
>>>
>>> Bob
>>>
 On Nov 16, 2017, at 4:10 AM, Azelio Boriani  
 wrote:

 As already stated here, the best measurement mode is the
 time-interval mode. The 5335A is a 2ns single-shot resolution
 counter. Use the PPS output from the GPSDO, route it to the A (start)
 input and to a coaxial cable used as a delay line (10m, 50ns, should
 be enough). The other end of the cable into the B input (stop),
 select the time interval mode TIME A -> B. Let the internal reference
 clock the counter. Set trigger levels and the various parameter to
 get stable readings and collect your data.

 On Thu, Nov 16, 2017 at 3:59 AM, Mike Garvey  wrote:
> Could you post some phase plots?  The data you show is not 1/tau and very 
> likely not white phase noise.
> Mike
>
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of
> CubeCentral
> Sent: Wednesday, November 15, 2017 11:12
> To: time-nuts@febo.com
> Subject: [time-nuts] Interpreting and Understanding Allen Deviation
> Results
>
> Greetings, time-nuts!
>
> After reading [ http://www.leapsecond.com/pages/adev/adev-why.htm ] I 
> felt that I better understood how an Allan Deviation is calculated and 
> endeavored to try 

Re: [time-nuts] Interpreting and Understanding Allen Deviation Results

[Bob kb8tq]

Hi

The exact software command used depends on the GPSDO you have. How you send the 
command to 
the GPSDO depends a bit on the driver software you are running. Not all GPSDO’s 
or modules have 
cable delay. All the ones I run do have the feature. Normally it comes set to 
some random default setting
like 60 ns. I typically take one GPSDO and deliberately make it the odd one out 
of the group. By making 
the offset large (say a microsecond or two) it’s easy to spot the “false 
ticker” in the group if things get 
mixed up. 

Assuming you set the odd GPSDO to be early (which could be cable delay + or 
cable delay -) it would 
go to input A on the counter. That would be the start channel. Input B would 
come from any normal 
pps signal and it would be the stop channel. You can of course do this other 
ways that work just as
well. 

Again - this is for looking at a pps relative to a GPSDO using a 5335 or 
similar counter. 

Bob

> On Nov 16, 2017, at 12:05 PM, Jerry  wrote:
> 
> Bob,
> 
> I am also a time newbie... how do you adjust this in software?  For time 
> interval as discussed below, the unaltered GPSDO output goes to A and how do 
> you create the GPSDO delay for B without a physical coax delay?  Any change 
> in GPSDO cable delay setting will affect A and B the same.  Sorry if this is 
> a stupid question
> 
> Jerry, NY2KW
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob kb8tq
> Sent: Thursday, November 16, 2017 11:15 AM
> To: Discussion of precise time and frequency measurement 
> Subject: Re: [time-nuts] Interpreting and Understanding Allen Deviation 
> Results
> 
> Hi
> 
> Yes, that’s exactly what I’m saying. You just use the software rather than 
> dragging around a big hunk of coax. It makes it easy to get one pps into the 
> “that’s way more than I need” range.
> With the coax approach, is 50NS enough? Might 100NS be needed? Is there a 
> 231NS case?.
> I’ve spent a *lot* of time finding those cases in the middle of long data 
> runs ….
> 
> Bob
> 
>> On Nov 16, 2017, at 10:37 AM, Jerry  wrote:
>> 
>> Bob,
>> 
>> Do you mean then you do not need to put a physical long length of cable for 
>> the delay, just do it in software or do you do both?
>> 
>> Jerry, NY2KW
>> 
>> -Original Message-
>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob 
>> kb8tq
>> Sent: Thursday, November 16, 2017 9:58 AM
>> To: Discussion of precise time and frequency measurement 
>> 
>> Subject: Re: [time-nuts] Interpreting and Understanding Allen 
>> Deviation Results
>> 
>> Hi
>> 
>> One “cute” thing to do when looking at GPSDO’s or GPS modules is to use the 
>> “cable delay” setting. It will allow you to move the pps of one unit 
>> relative to the pps of the other one. You then can be sure of which pps 
>> happens first. That makes the A to B measurement much easier to analyze. 
>> 
>> Short intervals also can lessen the impact of the time base accuracy in the 
>> counter ( you always are measuring a microsecond or so to a nanosecond 
>> resolution). Indeed there are other issues (like jitter) that still are an 
>> issue. 
>> 
>> Bob
>> 
>>> On Nov 16, 2017, at 4:10 AM, Azelio Boriani  
>>> wrote:
>>> 
>>> As already stated here, the best measurement mode is the 
>>> time-interval mode. The 5335A is a 2ns single-shot resolution 
>>> counter. Use the PPS output from the GPSDO, route it to the A (start) 
>>> input and to a coaxial cable used as a delay line (10m, 50ns, should 
>>> be enough). The other end of the cable into the B input (stop), 
>>> select the time interval mode TIME A -> B. Let the internal reference 
>>> clock the counter. Set trigger levels and the various parameter to 
>>> get stable readings and collect your data.
>>> 
>>> On Thu, Nov 16, 2017 at 3:59 AM, Mike Garvey  wrote:
 Could you post some phase plots?  The data you show is not 1/tau and very 
 likely not white phase noise.
 Mike
 
 -Original Message-
 From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of 
 CubeCentral
 Sent: Wednesday, November 15, 2017 11:12
 To: time-nuts@febo.com
 Subject: [time-nuts] Interpreting and Understanding Allen Deviation 
 Results
 
 Greetings, time-nuts!
 
 After reading [ http://www.leapsecond.com/pages/adev/adev-why.htm ] I felt 
 that I better understood how an Allan Deviation is calculated and 
 endeavored to try an experiment.  It should be noted that I have a 
 hobbyist-level understanding of the concepts described and tools used 
 below.  If my thinking or test methodology is incorrect, please let me 
 know so that I might learn something.
 
 A GPSDO with a 10MHz output was run into the EXT TIME BASE input on the 
 back of an HP5335A.
 Then, the TIME BASE OUT on the back was run to the A 

Re: [time-nuts] Interpreting and Understanding Allen Deviation Results

[Jerry]

Bob,

I am also a time newbie... how do you adjust this in software?  For time 
interval as discussed below, the unaltered GPSDO output goes to A and how do 
you create the GPSDO delay for B without a physical coax delay?  Any change in 
GPSDO cable delay setting will affect A and B the same.  Sorry if this is a 
stupid question

Jerry, NY2KW

-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob kb8tq
Sent: Thursday, November 16, 2017 11:15 AM
To: Discussion of precise time and frequency measurement 
Subject: Re: [time-nuts] Interpreting and Understanding Allen Deviation Results

Hi

Yes, that’s exactly what I’m saying. You just use the software rather than 
dragging around a big hunk of coax. It makes it easy to get one pps into the 
“that’s way more than I need” range.
With the coax approach, is 50NS enough? Might 100NS be needed? Is there a 231NS 
case?.
I’ve spent a *lot* of time finding those cases in the middle of long data runs 
….

Bob

> On Nov 16, 2017, at 10:37 AM, Jerry  wrote:
> 
> Bob,
> 
> Do you mean then you do not need to put a physical long length of cable for 
> the delay, just do it in software or do you do both?
> 
> Jerry, NY2KW
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob 
> kb8tq
> Sent: Thursday, November 16, 2017 9:58 AM
> To: Discussion of precise time and frequency measurement 
> 
> Subject: Re: [time-nuts] Interpreting and Understanding Allen 
> Deviation Results
> 
> Hi
> 
> One “cute” thing to do when looking at GPSDO’s or GPS modules is to use the 
> “cable delay” setting. It will allow you to move the pps of one unit relative 
> to the pps of the other one. You then can be sure of which pps happens first. 
> That makes the A to B measurement much easier to analyze. 
> 
> Short intervals also can lessen the impact of the time base accuracy in the 
> counter ( you always are measuring a microsecond or so to a nanosecond 
> resolution). Indeed there are other issues (like jitter) that still are an 
> issue. 
> 
> Bob
> 
>> On Nov 16, 2017, at 4:10 AM, Azelio Boriani  wrote:
>> 
>> As already stated here, the best measurement mode is the 
>> time-interval mode. The 5335A is a 2ns single-shot resolution 
>> counter. Use the PPS output from the GPSDO, route it to the A (start) 
>> input and to a coaxial cable used as a delay line (10m, 50ns, should 
>> be enough). The other end of the cable into the B input (stop), 
>> select the time interval mode TIME A -> B. Let the internal reference 
>> clock the counter. Set trigger levels and the various parameter to 
>> get stable readings and collect your data.
>> 
>> On Thu, Nov 16, 2017 at 3:59 AM, Mike Garvey  wrote:
>>> Could you post some phase plots?  The data you show is not 1/tau and very 
>>> likely not white phase noise.
>>> Mike
>>> 
>>> -Original Message-
>>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of 
>>> CubeCentral
>>> Sent: Wednesday, November 15, 2017 11:12
>>> To: time-nuts@febo.com
>>> Subject: [time-nuts] Interpreting and Understanding Allen Deviation 
>>> Results
>>> 
>>> Greetings, time-nuts!
>>> 
>>> After reading [ http://www.leapsecond.com/pages/adev/adev-why.htm ] I felt 
>>> that I better understood how an Allan Deviation is calculated and 
>>> endeavored to try an experiment.  It should be noted that I have a 
>>> hobbyist-level understanding of the concepts described and tools used 
>>> below.  If my thinking or test methodology is incorrect, please let me know 
>>> so that I might learn something.
>>> 
>>> A GPSDO with a 10MHz output was run into the EXT TIME BASE input on the 
>>> back of an HP5335A.
>>> Then, the TIME BASE OUT on the back was run to the A input on the front of 
>>> the HP5335A.
>>> My intention was to characterize the performance of the HP5335A counter 
>>> itself so that I might understand better future plots involving other GPSDO 
>>> and the counter's internal clock (which was bypassed for this test).
>>> 
>>> The settings of the HP5335A were as follows:
>>> Gate Mode: Normal
>>> Cycle: Normal
>>> 
>>> A Input -- Trigger Adjust: Full left to 
>>> 'Preset' detent
>>> Z select  =  in   =  50ohm
>>> x10 ATTN  =  in   =  x10 ATTN   (should have been out/off?)
>>> Slope =  out  =  up
>>> AC=  in   =  AC coupled
>>> COMA  =  out  =  Not ComA
>>> AutoTrig  =  out  =  Not Auto Tiggered (should have been in/on?)
>>> 
>>> (Tangentially, if someone has a good 'primer' or how-to resource 
>>> detailing Universal Counter operation, showing when/why/how to set 
>>> the knobs in certain situations it would be welcome!)
>>> 
>>> I then set the Time Lab V1.29 software to repeatedly acquire data 
>>> for
>>> 12 hours, starting the next test as soon as I could.  This means 
>>> that, normally, a test was run during the day for 12 

Re: [time-nuts] Deaf Z3801

[Bob Bownes]

Yup. tried that too.

The system won't let me set the date after 23:59:59 Dec 12,2007



On Thu, Nov 16, 2017 at 11:42 AM, Bob kb8tq  wrote:

> Hi
>
> One thing that has faked me out on SCPI - they cache error messages. You
> have to dump them all before you try something.
>
> Bob
>
> > On Nov 16, 2017, at 11:24 AM, Bob Bownes  wrote:
> >
> > Thanks John.
> >
> > When I do this, I get the E-222 error indicating 'Data out of range'.
> >
> > Tried several formats, trailing';', etc.
> >
> > Here's what I get:
> > scpi > :GPS:INIT:DATE 2017,11,16
> > E-222> :GPS:INIT:DATE 17,11,16
> > E-222> :GPS:INIT:DATE 17,01,01
> > E-222> :GPS:INIT:DATE 2017,01,01
> > E-222> :GPS:INIT:DATE 2017,01,01;
> > E-222> :GPS:INIT:DATE 17,01,01;
> > E-222>
> >
> > Even tried a :SYSTEM:PRESET, whic interestingly enough, does not reset
> the
> > location.
> >
> > Bob
> >
> > On Wed, Nov 15, 2017 at 8:49 AM, John Franke  wrote:
> >
> >> Try:
> >>
> >>
> >> Shut off power to the GPS receiver
> >>
> >> Disconnect the GPS antenna downlead
> >>
> >> Reapply power to the GPS receiver
> >>
> >> Enter  *:GPS:INIT:DATE 2017,01,01* (The only space is between DATE and
> >> 2017)
> >>
> >> Reconnect the GPS antenna downlead and wait
> >>
> >>
> >> John
> >>
> >> On November 14, 2017 at 10:43 PM Bob Bownes  wrote:
> >>
> >> I put my 3801 back in service the day before yesterday, or tried to.
> It’s
> >> been on the shelf for about a year (off).
> >>
> >> I powered it up, and while it sees a few sats, it will not acquire any.
> >> Changing to a known good antenna (off the NTP server) makes no
> difference.
> >>
> >> Anyone seen the behavior before? The location data is good, but the
> >> time/date are way out.
> >>
> >> Thanks!
> >> Bob
> >>
> >> ___
> >> time-nuts mailing list -- time-nuts@febo.com
> >> To unsubscribe, go to https://www.febo.com/cgi-bin/
> >> mailman/listinfo/time-nuts
> >> and follow the instructions there.
> >>
> >>
> > ___
> > time-nuts mailing list -- time-nuts@febo.com
> > To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> > and follow the instructions there.
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Deaf Z3801

[Bob kb8tq]

Hi

One thing that has faked me out on SCPI - they cache error messages. You 
have to dump them all before you try something. 

Bob

> On Nov 16, 2017, at 11:24 AM, Bob Bownes  wrote:
> 
> Thanks John.
> 
> When I do this, I get the E-222 error indicating 'Data out of range'.
> 
> Tried several formats, trailing';', etc.
> 
> Here's what I get:
> scpi > :GPS:INIT:DATE 2017,11,16
> E-222> :GPS:INIT:DATE 17,11,16
> E-222> :GPS:INIT:DATE 17,01,01
> E-222> :GPS:INIT:DATE 2017,01,01
> E-222> :GPS:INIT:DATE 2017,01,01;
> E-222> :GPS:INIT:DATE 17,01,01;
> E-222>
> 
> Even tried a :SYSTEM:PRESET, whic interestingly enough, does not reset the
> location.
> 
> Bob
> 
> On Wed, Nov 15, 2017 at 8:49 AM, John Franke  wrote:
> 
>> Try:
>> 
>> 
>> Shut off power to the GPS receiver
>> 
>> Disconnect the GPS antenna downlead
>> 
>> Reapply power to the GPS receiver
>> 
>> Enter  *:GPS:INIT:DATE 2017,01,01* (The only space is between DATE and
>> 2017)
>> 
>> Reconnect the GPS antenna downlead and wait
>> 
>> 
>> John
>> 
>> On November 14, 2017 at 10:43 PM Bob Bownes  wrote:
>> 
>> I put my 3801 back in service the day before yesterday, or tried to. It’s
>> been on the shelf for about a year (off).
>> 
>> I powered it up, and while it sees a few sats, it will not acquire any.
>> Changing to a known good antenna (off the NTP server) makes no difference.
>> 
>> Anyone seen the behavior before? The location data is good, but the
>> time/date are way out.
>> 
>> Thanks!
>> Bob
>> 
>> ___
>> time-nuts mailing list -- time-nuts@febo.com
>> To unsubscribe, go to https://www.febo.com/cgi-bin/
>> mailman/listinfo/time-nuts
>> and follow the instructions there.
>> 
>> 
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Deaf Z3801

[Bob Bownes]

Thanks John.

When I do this, I get the E-222 error indicating 'Data out of range'.

Tried several formats, trailing';', etc.

Here's what I get:
scpi > :GPS:INIT:DATE 2017,11,16
E-222> :GPS:INIT:DATE 17,11,16
E-222> :GPS:INIT:DATE 17,01,01
E-222> :GPS:INIT:DATE 2017,01,01
E-222> :GPS:INIT:DATE 2017,01,01;
E-222> :GPS:INIT:DATE 17,01,01;
E-222>

Even tried a :SYSTEM:PRESET, whic interestingly enough, does not reset the
location.

Bob

On Wed, Nov 15, 2017 at 8:49 AM, John Franke  wrote:

> Try:
>
>
> Shut off power to the GPS receiver
>
> Disconnect the GPS antenna downlead
>
> Reapply power to the GPS receiver
>
> Enter  *:GPS:INIT:DATE 2017,01,01* (The only space is between DATE and
> 2017)
>
> Reconnect the GPS antenna downlead and wait
>
>
> John
>
> On November 14, 2017 at 10:43 PM Bob Bownes  wrote:
>
> I put my 3801 back in service the day before yesterday, or tried to. It’s
> been on the shelf for about a year (off).
>
> I powered it up, and while it sees a few sats, it will not acquire any.
> Changing to a known good antenna (off the NTP server) makes no difference.
>
> Anyone seen the behavior before? The location data is good, but the
> time/date are way out.
>
> Thanks!
> Bob
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/
> mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.

Re: [time-nuts] Interpreting and Understanding Allen Deviation Results

[Bob kb8tq]

Hi

Yes, that’s exactly what I’m saying. You just use the software rather than 
dragging around a 
big hunk of coax. It makes it easy to get one pps into the “that’s way more 
than I need” range.
With the coax approach, is 50NS enough? Might 100NS be needed? Is there a 231NS 
case?.
I’ve spent a *lot* of time finding those cases in the middle of long data runs 
….

Bob

> On Nov 16, 2017, at 10:37 AM, Jerry  wrote:
> 
> Bob,
> 
> Do you mean then you do not need to put a physical long length of cable for 
> the delay, just do it in software or do you do both?
> 
> Jerry, NY2KW
> 
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob kb8tq
> Sent: Thursday, November 16, 2017 9:58 AM
> To: Discussion of precise time and frequency measurement 
> Subject: Re: [time-nuts] Interpreting and Understanding Allen Deviation 
> Results
> 
> Hi
> 
> One “cute” thing to do when looking at GPSDO’s or GPS modules is to use the 
> “cable delay” setting. It will allow you to move the pps of one unit relative 
> to the pps of the other one. You then can be sure of which pps happens first. 
> That makes the A to B measurement much easier to analyze. 
> 
> Short intervals also can lessen the impact of the time base accuracy in the 
> counter ( you always are measuring a microsecond or so to a nanosecond 
> resolution). Indeed there are other issues (like jitter) that still are an 
> issue. 
> 
> Bob
> 
>> On Nov 16, 2017, at 4:10 AM, Azelio Boriani  wrote:
>> 
>> As already stated here, the best measurement mode is the time-interval 
>> mode. The 5335A is a 2ns single-shot resolution counter. Use the PPS 
>> output from the GPSDO, route it to the A (start) input and to a 
>> coaxial cable used as a delay line (10m, 50ns, should be enough). The 
>> other end of the cable into the B input (stop), select the time 
>> interval mode TIME A -> B. Let the internal reference clock the 
>> counter. Set trigger levels and the various parameter to get stable 
>> readings and collect your data.
>> 
>> On Thu, Nov 16, 2017 at 3:59 AM, Mike Garvey  wrote:
>>> Could you post some phase plots?  The data you show is not 1/tau and very 
>>> likely not white phase noise.
>>> Mike
>>> 
>>> -Original Message-
>>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of 
>>> CubeCentral
>>> Sent: Wednesday, November 15, 2017 11:12
>>> To: time-nuts@febo.com
>>> Subject: [time-nuts] Interpreting and Understanding Allen Deviation 
>>> Results
>>> 
>>> Greetings, time-nuts!
>>> 
>>> After reading [ http://www.leapsecond.com/pages/adev/adev-why.htm ] I felt 
>>> that I better understood how an Allan Deviation is calculated and 
>>> endeavored to try an experiment.  It should be noted that I have a 
>>> hobbyist-level understanding of the concepts described and tools used 
>>> below.  If my thinking or test methodology is incorrect, please let me know 
>>> so that I might learn something.
>>> 
>>> A GPSDO with a 10MHz output was run into the EXT TIME BASE input on the 
>>> back of an HP5335A.
>>> Then, the TIME BASE OUT on the back was run to the A input on the front of 
>>> the HP5335A.
>>> My intention was to characterize the performance of the HP5335A counter 
>>> itself so that I might understand better future plots involving other GPSDO 
>>> and the counter's internal clock (which was bypassed for this test).
>>> 
>>> The settings of the HP5335A were as follows:
>>> Gate Mode: Normal
>>> Cycle: Normal
>>> 
>>> A Input -- Trigger Adjust: Full left to 
>>> 'Preset' detent
>>> Z select  =  in   =  50ohm
>>> x10 ATTN  =  in   =  x10 ATTN   (should have been out/off?)
>>> Slope =  out  =  up
>>> AC=  in   =  AC coupled
>>> COMA  =  out  =  Not ComA
>>> AutoTrig  =  out  =  Not Auto Tiggered (should have been in/on?)
>>> 
>>> (Tangentially, if someone has a good 'primer' or how-to resource 
>>> detailing Universal Counter operation, showing when/why/how to set 
>>> the knobs in certain situations it would be welcome!)
>>> 
>>> I then set the Time Lab V1.29 software to repeatedly acquire data for 
>>> 12 hours, starting the next test as soon as I could.  This means 
>>> that, normally, a test was run during the day for 12 hours, and then 
>>> overnight for
>>> 12 hours.
>>> 
>>> The results are shown here:  [ https://i.imgur.com/0sMVMfk.png ]  The 
>>> associated .TIM files are available upon request.
>>> 
>>> So, now we get to the heart of the matter and the questions this test and 
>>> results have raised.
>>> I am trying to understand what the data is telling me about the test, and 
>>> therefore the character of the counter.
>>> 
>>> 1)  Why are the plots a straight line from ~0.25s until ~100s?
>>> 2)  Why, after falling at the start, do the plots all seem to go back up 
>>> from ~100s to ~1000s?
>>> 3)  What do the "peaks" mean, after the plot has fallen and 

Re: [time-nuts] Interpreting and Understanding Allen Deviation Results

[Jerry]

Bob,

Do you mean then you do not need to put a physical long length of cable for the 
delay, just do it in software or do you do both?

Jerry, NY2KW

-Original Message-
From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Bob kb8tq
Sent: Thursday, November 16, 2017 9:58 AM
To: Discussion of precise time and frequency measurement 
Subject: Re: [time-nuts] Interpreting and Understanding Allen Deviation Results

Hi

One “cute” thing to do when looking at GPSDO’s or GPS modules is to use the 
“cable delay” setting. It will allow you to move the pps of one unit relative 
to the pps of the other one. You then can be sure of which pps happens first. 
That makes the A to B measurement much easier to analyze. 

Short intervals also can lessen the impact of the time base accuracy in the 
counter ( you always are measuring a microsecond or so to a nanosecond 
resolution). Indeed there are other issues (like jitter) that still are an 
issue. 

Bob

> On Nov 16, 2017, at 4:10 AM, Azelio Boriani  wrote:
> 
> As already stated here, the best measurement mode is the time-interval 
> mode. The 5335A is a 2ns single-shot resolution counter. Use the PPS 
> output from the GPSDO, route it to the A (start) input and to a 
> coaxial cable used as a delay line (10m, 50ns, should be enough). The 
> other end of the cable into the B input (stop), select the time 
> interval mode TIME A -> B. Let the internal reference clock the 
> counter. Set trigger levels and the various parameter to get stable 
> readings and collect your data.
> 
> On Thu, Nov 16, 2017 at 3:59 AM, Mike Garvey  wrote:
>> Could you post some phase plots?  The data you show is not 1/tau and very 
>> likely not white phase noise.
>> Mike
>> 
>> -Original Message-
>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of 
>> CubeCentral
>> Sent: Wednesday, November 15, 2017 11:12
>> To: time-nuts@febo.com
>> Subject: [time-nuts] Interpreting and Understanding Allen Deviation 
>> Results
>> 
>> Greetings, time-nuts!
>> 
>> After reading [ http://www.leapsecond.com/pages/adev/adev-why.htm ] I felt 
>> that I better understood how an Allan Deviation is calculated and endeavored 
>> to try an experiment.  It should be noted that I have a hobbyist-level 
>> understanding of the concepts described and tools used below.  If my 
>> thinking or test methodology is incorrect, please let me know so that I 
>> might learn something.
>> 
>> A GPSDO with a 10MHz output was run into the EXT TIME BASE input on the back 
>> of an HP5335A.
>> Then, the TIME BASE OUT on the back was run to the A input on the front of 
>> the HP5335A.
>> My intention was to characterize the performance of the HP5335A counter 
>> itself so that I might understand better future plots involving other GPSDO 
>> and the counter's internal clock (which was bypassed for this test).
>> 
>> The settings of the HP5335A were as follows:
>> Gate Mode: Normal
>> Cycle: Normal
>> 
>> A Input -- Trigger Adjust: Full left to 
>> 'Preset' detent
>> Z select  =  in   =  50ohm
>> x10 ATTN  =  in   =  x10 ATTN   (should have been out/off?)
>> Slope =  out  =  up
>> AC=  in   =  AC coupled
>> COMA  =  out  =  Not ComA
>> AutoTrig  =  out  =  Not Auto Tiggered (should have been in/on?)
>> 
>> (Tangentially, if someone has a good 'primer' or how-to resource 
>> detailing Universal Counter operation, showing when/why/how to set 
>> the knobs in certain situations it would be welcome!)
>> 
>> I then set the Time Lab V1.29 software to repeatedly acquire data for 
>> 12 hours, starting the next test as soon as I could.  This means 
>> that, normally, a test was run during the day for 12 hours, and then 
>> overnight for
>> 12 hours.
>> 
>> The results are shown here:  [ https://i.imgur.com/0sMVMfk.png ]  The 
>> associated .TIM files are available upon request.
>> 
>> So, now we get to the heart of the matter and the questions this test and 
>> results have raised.
>> I am trying to understand what the data is telling me about the test, and 
>> therefore the character of the counter.
>> 
>> 1)  Why are the plots a straight line from ~0.25s until ~100s?
>> 2)  Why, after falling at the start, do the plots all seem to go back up 
>> from ~100s to ~1000s?
>> 3)  What do the "peaks" mean, after the plot has fallen and begin to rise 
>> again?
>> 4)  Why is the period from ~1000s to ~1s so chaotic?
>> 5)  The pattern "Fall to a minimum point, then rise to a peak, then fall 
>> again" seems to be prevalent.  What does that indicate?
>> 6)  Why does that pattern in question (5) seem to repeat sometimes?  What is 
>> that showing me?
>> 
>> And finally, some general questions about looking at these plots.
>> a)  Would a "perfect" plot be a straight line falling from left to right?
>> (Meaning a hypothetical "ideal" source with perfect timing?)
>> b)  Is there some example showing 

Re: [time-nuts] Interpreting and Understanding Allen Deviation Results

[Bob kb8tq]

Hi

One “cute” thing to do when looking at GPSDO’s or GPS modules is to use the
“cable delay” setting. It will allow you to move the pps of one unit relative 
to the 
pps of the other one. You then can be sure of which pps happens first. That 
makes
the A to B measurement much easier to analyze. 

Short intervals also can lessen the impact of the time base accuracy in the 
counter 
( you always are measuring a microsecond or so to a nanosecond resolution). 
Indeed 
there are other issues (like jitter) that still are an issue. 

Bob

> On Nov 16, 2017, at 4:10 AM, Azelio Boriani  wrote:
> 
> As already stated here, the best measurement mode is the time-interval
> mode. The 5335A is a 2ns single-shot resolution counter. Use the PPS
> output from the GPSDO, route it to the A (start) input and to a
> coaxial cable used as a delay line (10m, 50ns, should be enough). The
> other end of the cable into the B input (stop), select the time
> interval mode TIME A -> B. Let the internal reference clock the
> counter. Set trigger levels and the various parameter to get stable
> readings and collect your data.
> 
> On Thu, Nov 16, 2017 at 3:59 AM, Mike Garvey  wrote:
>> Could you post some phase plots?  The data you show is not 1/tau and very 
>> likely not white phase noise.
>> Mike
>> 
>> -Original Message-
>> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of CubeCentral
>> Sent: Wednesday, November 15, 2017 11:12
>> To: time-nuts@febo.com
>> Subject: [time-nuts] Interpreting and Understanding Allen Deviation Results
>> 
>> Greetings, time-nuts!
>> 
>> After reading [ http://www.leapsecond.com/pages/adev/adev-why.htm ] I felt 
>> that I better understood how an Allan Deviation is calculated and endeavored 
>> to try an experiment.  It should be noted that I have a hobbyist-level 
>> understanding of the concepts described and tools used below.  If my 
>> thinking or test methodology is incorrect, please let me know so that I 
>> might learn something.
>> 
>> A GPSDO with a 10MHz output was run into the EXT TIME BASE input on the back 
>> of an HP5335A.
>> Then, the TIME BASE OUT on the back was run to the A input on the front of 
>> the HP5335A.
>> My intention was to characterize the performance of the HP5335A counter 
>> itself so that I might understand better future plots involving other GPSDO 
>> and the counter's internal clock (which was bypassed for this test).
>> 
>> The settings of the HP5335A were as follows:
>> Gate Mode: Normal
>> Cycle: Normal
>> 
>> A Input --
>> Trigger Adjust: Full left to 'Preset' detent
>> Z select  =  in   =  50ohm
>> x10 ATTN  =  in   =  x10 ATTN   (should have been out/off?)
>> Slope =  out  =  up
>> AC=  in   =  AC coupled
>> COMA  =  out  =  Not ComA
>> AutoTrig  =  out  =  Not Auto Tiggered (should have been in/on?)
>> 
>> (Tangentially, if someone has a good 'primer' or how-to resource detailing 
>> Universal Counter operation, showing when/why/how to set the knobs in 
>> certain situations it would be welcome!)
>> 
>> I then set the Time Lab V1.29 software to repeatedly acquire data for 12 
>> hours, starting the next test as soon as I could.  This means that, 
>> normally, a test was run during the day for 12 hours, and then overnight for
>> 12 hours.
>> 
>> The results are shown here:  [ https://i.imgur.com/0sMVMfk.png ]  The 
>> associated .TIM files are available upon request.
>> 
>> So, now we get to the heart of the matter and the questions this test and 
>> results have raised.
>> I am trying to understand what the data is telling me about the test, and 
>> therefore the character of the counter.
>> 
>> 1)  Why are the plots a straight line from ~0.25s until ~100s?
>> 2)  Why, after falling at the start, do the plots all seem to go back up 
>> from ~100s to ~1000s?
>> 3)  What do the "peaks" mean, after the plot has fallen and begin to rise 
>> again?
>> 4)  Why is the period from ~1000s to ~1s so chaotic?
>> 5)  The pattern "Fall to a minimum point, then rise to a peak, then fall 
>> again" seems to be prevalent.  What does that indicate?
>> 6)  Why does that pattern in question (5) seem to repeat sometimes?  What is 
>> that showing me?
>> 
>> And finally, some general questions about looking at these plots.
>> a)  Would a "perfect" plot be a straight line falling from left to right?
>> (Meaning a hypothetical "ideal" source with perfect timing?)
>> b)  Is there some example showing plots from two different sources that then 
>> describes why one source is better than the other (based upon the ADEV plot)?
>> c)  I believe that if I understood the math better, these types of plots 
>> would be more telling.  Without having to dive back into my college Calculus 
>> or Statistics books, is there a good resource for me to be able to 
>> understand this better?
>> 
>> Lastly, thank you for your patience and for keeping this brain-trust alive.
>> I am 

Re: [time-nuts] Interpreting and Understanding Allen Deviation Results

[Azelio Boriani]

As already stated here, the best measurement mode is the time-interval
mode. The 5335A is a 2ns single-shot resolution counter. Use the PPS
output from the GPSDO, route it to the A (start) input and to a
coaxial cable used as a delay line (10m, 50ns, should be enough). The
other end of the cable into the B input (stop), select the time
interval mode TIME A -> B. Let the internal reference clock the
counter. Set trigger levels and the various parameter to get stable
readings and collect your data.

On Thu, Nov 16, 2017 at 3:59 AM, Mike Garvey  wrote:
> Could you post some phase plots?  The data you show is not 1/tau and very 
> likely not white phase noise.
> Mike
>
> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of CubeCentral
> Sent: Wednesday, November 15, 2017 11:12
> To: time-nuts@febo.com
> Subject: [time-nuts] Interpreting and Understanding Allen Deviation Results
>
> Greetings, time-nuts!
>
> After reading [ http://www.leapsecond.com/pages/adev/adev-why.htm ] I felt 
> that I better understood how an Allan Deviation is calculated and endeavored 
> to try an experiment.  It should be noted that I have a hobbyist-level 
> understanding of the concepts described and tools used below.  If my thinking 
> or test methodology is incorrect, please let me know so that I might learn 
> something.
>
> A GPSDO with a 10MHz output was run into the EXT TIME BASE input on the back 
> of an HP5335A.
> Then, the TIME BASE OUT on the back was run to the A input on the front of 
> the HP5335A.
> My intention was to characterize the performance of the HP5335A counter 
> itself so that I might understand better future plots involving other GPSDO 
> and the counter's internal clock (which was bypassed for this test).
>
> The settings of the HP5335A were as follows:
> Gate Mode: Normal
> Cycle: Normal
>
> A Input --
> Trigger Adjust: Full left to 'Preset' detent
> Z select  =  in   =  50ohm
> x10 ATTN  =  in   =  x10 ATTN   (should have been out/off?)
> Slope =  out  =  up
> AC=  in   =  AC coupled
> COMA  =  out  =  Not ComA
> AutoTrig  =  out  =  Not Auto Tiggered (should have been in/on?)
>
> (Tangentially, if someone has a good 'primer' or how-to resource detailing 
> Universal Counter operation, showing when/why/how to set the knobs in certain 
> situations it would be welcome!)
>
> I then set the Time Lab V1.29 software to repeatedly acquire data for 12 
> hours, starting the next test as soon as I could.  This means that, normally, 
> a test was run during the day for 12 hours, and then overnight for
> 12 hours.
>
> The results are shown here:  [ https://i.imgur.com/0sMVMfk.png ]  The 
> associated .TIM files are available upon request.
>
> So, now we get to the heart of the matter and the questions this test and 
> results have raised.
> I am trying to understand what the data is telling me about the test, and 
> therefore the character of the counter.
>
> 1)  Why are the plots a straight line from ~0.25s until ~100s?
> 2)  Why, after falling at the start, do the plots all seem to go back up from 
> ~100s to ~1000s?
> 3)  What do the "peaks" mean, after the plot has fallen and begin to rise 
> again?
> 4)  Why is the period from ~1000s to ~1s so chaotic?
> 5)  The pattern "Fall to a minimum point, then rise to a peak, then fall 
> again" seems to be prevalent.  What does that indicate?
> 6)  Why does that pattern in question (5) seem to repeat sometimes?  What is 
> that showing me?
>
> And finally, some general questions about looking at these plots.
> a)  Would a "perfect" plot be a straight line falling from left to right?
> (Meaning a hypothetical "ideal" source with perfect timing?)
> b)  Is there some example showing plots from two different sources that then 
> describes why one source is better than the other (based upon the ADEV plot)?
> c)  I believe that if I understood the math better, these types of plots 
> would be more telling.  Without having to dive back into my college Calculus 
> or Statistics books, is there a good resource for me to be able to understand 
> this better?
>
> Lastly, thank you for your patience and for keeping this brain-trust alive.
> I am quite grateful for all the time and energy members pour into this list.
> The archives have been a good source of learning material.
>
> -Randal (at CubeCentral Labs...)
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ___
> time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to 
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
> ___
> time-nuts mailing list -- time-nuts@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
___
time-nuts mailing list -- time-nuts@febo.com
To 

Re: [time-nuts] Lucent RFTG-u REF0-REF1 cable

[Jerry Hancock]

Just to close this one out, I was able to get the Ref-0 and Ref-1 working 
standalone with 10Mhz on both using my spare Motorola UT+ GPS.  Lots of help 
from lots of people and especially Peter Garde who stuck with me to the end.

It would be nice if all this was in one place or maybe one combined document.

Anyway, now I have two, so I’ll be guessing which one is right half the time.

Thanks,

Jerry
___
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.