Re: [time-nuts] More ES100 WWVB Measurements

[Bob kb8tq]

Hi

Go indoors in the basement inside an inner room. You can at some times of day 
get WWVB. 
With a normal building, GPS isn’t going to make it. Even if it does, the 
signals will be degraded
enough that you will have a tough time using in.

Bob

> On Dec 31, 2018, at 8:47 PM, Wayne Holder  wrote:
> 
>> If you are fairly deep inside a building, GPS isn’t going to get there.
> WWVB likely
>> will make it to an internal location.
> 
> Interesting thought. I wonder if anyone has tested WWVB reception in a
> deep underground location such as a sub sub level in a building or parking
> garage?
> 
> Wayne
> 
> On Mon, Dec 31, 2018 at 5:29 PM Bob kb8tq  wrote:
> 
>> Hi
>> 
>> If you are fairly deep inside a building, GPS isn’t going to get there.
>> WWVB likely
>> will make it to an internal location.
>> 
>> If you are convinced that WWVB is un-jamable and that GPS is easily
>> jammed, WWVB
>> would be more robust.
>> 
>> That’s about it.
>> 
>> Bob
>> 
>>> On Dec 31, 2018, at 7:56 PM, Wayne Holder 
>> wrote:
>>> 
>>> While reading this thread and pondering whether to buy and fool around
>> with
>>> an ES100-based module from Universal Solder, I suddenly found myself
>>> wondering if there was any advantage to using the time received from WWVB
>>> vs just using an inexpensive GPS receiver.  The ES100  module costs about
>>> $70, but I can get a GPS receiver, with antenna, for far less than that
>> and
>>> I've had no trouble receiving GPS signals indoors with most modern
>> receiver
>>> modules.
>>> 
>>> I suppose the low power requirements of the ES100 might be an advantage
>>> when building battery powered clocks to mount on the wall, but it seems
>>> like some of the newer, ultra low power GPS modules intended for use in
>>> smart watches could also work in a battery-powered wall clock, especially
>>> if the receiver was only powered on a few times a day to update the time.
>>> 
>>> And, finally, if GPS modules are (or will some become) a suitable
>>> replacement for WWVB receiver modules, do we really need WWVB in the
>> modern
>>> age?  Perhaps there's some critical advantage to using WWVB to get the
>> time
>>> but, offhand, I cannot think of it.  What am I missing?
>>> 
>>> Wayne
>>> 
>>> On Mon, Dec 31, 2018 at 4:30 PM Brooke Clarke 
>> wrote:
>>> 
 Hi Joseph:
 
 Thanks for the patent link.  I've added it to my WWVB phase modulation
 info at:
 https://prc68.com/I/Loop.shtml#La_Crosse_UltrAtomic
 
 --
 Have Fun,
 
 Brooke Clarke
 https://www.PRC68.com
 http://www.end2partygovernment.com/2012Issues.html
 axioms:
 1. The extent to which you can fix or improve something will be limited
>> by
 how well you understand how it works.
 2. Everybody, with no exceptions, holds false beliefs.
 
  Original Message 
> On Mon, 31 Dec 2018 12:00:02 -0500, time-nuts-requ...@lists.febo.com
> wrote:
> 
>> time-nuts Digest, Vol 173, Issue 44
>> Message: 7
>> Date: Mon, 31 Dec 2018 04:04:22 -0800
>> From: "Tom Van Baak" 
>> To: "Discussion of precise time and frequency measurement"
>>
>> Subject: Re: [time-nuts] More ES100 WWVB Measurements
>> Message-ID: <96BB388753294278A9CDE96C1EA7D9AE@pc52>
>> Content-Type: text/plain;charset="UTF-8"
>> 
>> Hi Graham,
>> 
>> That's very nice work. And you have uncovered several unusual effects
>> in the ES100. Bugs? Features? If we time nuts keep up the good work
>> to evaluate this chip, we are likely at some point to get an
>> informative response from the guys who designed it. They read
>> time-nuts.
> I didn't see this mentioned, but I think I have found the relevant US
> patent application: US20130051184A1, Real-time clock integrated circuit
> with time code receiver, method of operation thereof and devices
> incorporating the same, Oren Eliezer et al, Oren Eliezer et al, filed
> 2013-02-28.
> 
> .
> 
> Found this by chasing stuff from the EverSet website:
> .<
 
>> http://everset-tech.com/wp-content/uploads/2014/11/ReceiverRadioClocks.pdf
> .
> 
> Joe Gwinn
> 
> 
>> So now both you and Tim have observed the off-by-one-second (or
>> off-by-N-seconds) effect in the ES100. I wonder if this explains why
>> some of my ES100-based La Crosse 1235UA Ultratomic wall clocks are
>> off by a second sometimes.
>> 
>> My main question: in your "Time Plot.PNG" plot, what is the cause of
>> the sawtooth pattern? The points are almost all on a clear negative
>> slope, though bounded by roughly +/- 75ms. Looking on the far left, I
>> see a time drift of +50 ms to -25 ms over an hour, which is
>> equivalent to a -20 ppm frequency offset; about -2 seconds/day.
>> 
>> Do you think this is due to the 16 MHz onboard xtal? If so, how about
>> changing the temperature of 

Re: [time-nuts] More ES100 WWVB Measurements

[Wayne Holder]

> If you are fairly deep inside a building, GPS isn’t going to get there.
WWVB likely
> will make it to an internal location.

Interesting thought. I wonder if anyone has tested WWVB reception in a
deep underground location such as a sub sub level in a building or parking
garage?

Wayne

On Mon, Dec 31, 2018 at 5:29 PM Bob kb8tq  wrote:

> Hi
>
> If you are fairly deep inside a building, GPS isn’t going to get there.
> WWVB likely
> will make it to an internal location.
>
> If you are convinced that WWVB is un-jamable and that GPS is easily
> jammed, WWVB
> would be more robust.
>
> That’s about it.
>
> Bob
>
> > On Dec 31, 2018, at 7:56 PM, Wayne Holder 
> wrote:
> >
> > While reading this thread and pondering whether to buy and fool around
> with
> > an ES100-based module from Universal Solder, I suddenly found myself
> > wondering if there was any advantage to using the time received from WWVB
> > vs just using an inexpensive GPS receiver.  The ES100  module costs about
> > $70, but I can get a GPS receiver, with antenna, for far less than that
> and
> > I've had no trouble receiving GPS signals indoors with most modern
> receiver
> > modules.
> >
> > I suppose the low power requirements of the ES100 might be an advantage
> > when building battery powered clocks to mount on the wall, but it seems
> > like some of the newer, ultra low power GPS modules intended for use in
> > smart watches could also work in a battery-powered wall clock, especially
> > if the receiver was only powered on a few times a day to update the time.
> >
> > And, finally, if GPS modules are (or will some become) a suitable
> > replacement for WWVB receiver modules, do we really need WWVB in the
> modern
> > age?  Perhaps there's some critical advantage to using WWVB to get the
> time
> > but, offhand, I cannot think of it.  What am I missing?
> >
> > Wayne
> >
> > On Mon, Dec 31, 2018 at 4:30 PM Brooke Clarke 
> wrote:
> >
> >> Hi Joseph:
> >>
> >> Thanks for the patent link.  I've added it to my WWVB phase modulation
> >> info at:
> >> https://prc68.com/I/Loop.shtml#La_Crosse_UltrAtomic
> >>
> >> --
> >> Have Fun,
> >>
> >> Brooke Clarke
> >> https://www.PRC68.com
> >> http://www.end2partygovernment.com/2012Issues.html
> >> axioms:
> >> 1. The extent to which you can fix or improve something will be limited
> by
> >> how well you understand how it works.
> >> 2. Everybody, with no exceptions, holds false beliefs.
> >>
> >>  Original Message 
> >>> On Mon, 31 Dec 2018 12:00:02 -0500, time-nuts-requ...@lists.febo.com
> >>> wrote:
> >>>
>   time-nuts Digest, Vol 173, Issue 44
>  Message: 7
>  Date: Mon, 31 Dec 2018 04:04:22 -0800
>  From: "Tom Van Baak" 
>  To: "Discussion of precise time and frequency measurement"
>  
>  Subject: Re: [time-nuts] More ES100 WWVB Measurements
>  Message-ID: <96BB388753294278A9CDE96C1EA7D9AE@pc52>
>  Content-Type: text/plain;charset="UTF-8"
> 
>  Hi Graham,
> 
>  That's very nice work. And you have uncovered several unusual effects
>  in the ES100. Bugs? Features? If we time nuts keep up the good work
>  to evaluate this chip, we are likely at some point to get an
>  informative response from the guys who designed it. They read
>  time-nuts.
> >>> I didn't see this mentioned, but I think I have found the relevant US
> >>> patent application: US20130051184A1, Real-time clock integrated circuit
> >>> with time code receiver, method of operation thereof and devices
> >>> incorporating the same, Oren Eliezer et al, Oren Eliezer et al, filed
> >>> 2013-02-28.
> >>>
> >>> .
> >>>
> >>> Found this by chasing stuff from the EverSet website:
> >>> .<
> >>
> http://everset-tech.com/wp-content/uploads/2014/11/ReceiverRadioClocks.pdf
> >>> .
> >>>
> >>> Joe Gwinn
> >>>
> >>>
>  So now both you and Tim have observed the off-by-one-second (or
>  off-by-N-seconds) effect in the ES100. I wonder if this explains why
>  some of my ES100-based La Crosse 1235UA Ultratomic wall clocks are
>  off by a second sometimes.
> 
>  My main question: in your "Time Plot.PNG" plot, what is the cause of
>  the sawtooth pattern? The points are almost all on a clear negative
>  slope, though bounded by roughly +/- 75ms. Looking on the far left, I
>  see a time drift of +50 ms to -25 ms over an hour, which is
>  equivalent to a -20 ppm frequency offset; about -2 seconds/day.
> 
>  Do you think this is due to the 16 MHz onboard xtal? If so, how about
>  changing the temperature of the eval board by a lot (say, several
>  tens of degrees) for an extended time (say, 4 hours) and see if the
>  sawtooth slope changes convincingly.
> 
>  Also, just to be sure, can you put a known independent timing signal
>  (e.g., GPS/1PPS) into your complex BeagleBone Black / Debian 9.4 /
>  ntpd time server / Python 3 / Excel stack to 

Re: [time-nuts] More ES100 WWVB Measurements

[Bob kb8tq]

Hi

If you are fairly deep inside a building, GPS isn’t going to get there. WWVB 
likely 
will make it to an internal location. 

If you are convinced that WWVB is un-jamable and that GPS is easily jammed, WWVB
would be more robust. 

That’s about it.

Bob

> On Dec 31, 2018, at 7:56 PM, Wayne Holder  wrote:
> 
> While reading this thread and pondering whether to buy and fool around with
> an ES100-based module from Universal Solder, I suddenly found myself
> wondering if there was any advantage to using the time received from WWVB
> vs just using an inexpensive GPS receiver.  The ES100  module costs about
> $70, but I can get a GPS receiver, with antenna, for far less than that and
> I've had no trouble receiving GPS signals indoors with most modern receiver
> modules.
> 
> I suppose the low power requirements of the ES100 might be an advantage
> when building battery powered clocks to mount on the wall, but it seems
> like some of the newer, ultra low power GPS modules intended for use in
> smart watches could also work in a battery-powered wall clock, especially
> if the receiver was only powered on a few times a day to update the time.
> 
> And, finally, if GPS modules are (or will some become) a suitable
> replacement for WWVB receiver modules, do we really need WWVB in the modern
> age?  Perhaps there's some critical advantage to using WWVB to get the time
> but, offhand, I cannot think of it.  What am I missing?
> 
> Wayne
> 
> On Mon, Dec 31, 2018 at 4:30 PM Brooke Clarke  wrote:
> 
>> Hi Joseph:
>> 
>> Thanks for the patent link.  I've added it to my WWVB phase modulation
>> info at:
>> https://prc68.com/I/Loop.shtml#La_Crosse_UltrAtomic
>> 
>> --
>> Have Fun,
>> 
>> Brooke Clarke
>> https://www.PRC68.com
>> http://www.end2partygovernment.com/2012Issues.html
>> axioms:
>> 1. The extent to which you can fix or improve something will be limited by
>> how well you understand how it works.
>> 2. Everybody, with no exceptions, holds false beliefs.
>> 
>>  Original Message 
>>> On Mon, 31 Dec 2018 12:00:02 -0500, time-nuts-requ...@lists.febo.com
>>> wrote:
>>> 
  time-nuts Digest, Vol 173, Issue 44
 Message: 7
 Date: Mon, 31 Dec 2018 04:04:22 -0800
 From: "Tom Van Baak" 
 To: "Discussion of precise time and frequency measurement"
 
 Subject: Re: [time-nuts] More ES100 WWVB Measurements
 Message-ID: <96BB388753294278A9CDE96C1EA7D9AE@pc52>
 Content-Type: text/plain;charset="UTF-8"
 
 Hi Graham,
 
 That's very nice work. And you have uncovered several unusual effects
 in the ES100. Bugs? Features? If we time nuts keep up the good work
 to evaluate this chip, we are likely at some point to get an
 informative response from the guys who designed it. They read
 time-nuts.
>>> I didn't see this mentioned, but I think I have found the relevant US
>>> patent application: US20130051184A1, Real-time clock integrated circuit
>>> with time code receiver, method of operation thereof and devices
>>> incorporating the same, Oren Eliezer et al, Oren Eliezer et al, filed
>>> 2013-02-28.
>>> 
>>> .
>>> 
>>> Found this by chasing stuff from the EverSet website:
>>> .<
>> http://everset-tech.com/wp-content/uploads/2014/11/ReceiverRadioClocks.pdf
>>> .
>>> 
>>> Joe Gwinn
>>> 
>>> 
 So now both you and Tim have observed the off-by-one-second (or
 off-by-N-seconds) effect in the ES100. I wonder if this explains why
 some of my ES100-based La Crosse 1235UA Ultratomic wall clocks are
 off by a second sometimes.
 
 My main question: in your "Time Plot.PNG" plot, what is the cause of
 the sawtooth pattern? The points are almost all on a clear negative
 slope, though bounded by roughly +/- 75ms. Looking on the far left, I
 see a time drift of +50 ms to -25 ms over an hour, which is
 equivalent to a -20 ppm frequency offset; about -2 seconds/day.
 
 Do you think this is due to the 16 MHz onboard xtal? If so, how about
 changing the temperature of the eval board by a lot (say, several
 tens of degrees) for an extended time (say, 4 hours) and see if the
 sawtooth slope changes convincingly.
 
 Also, just to be sure, can you put a known independent timing signal
 (e.g., GPS/1PPS) into your complex BeagleBone Black / Debian 9.4 /
 ntpd time server / Python 3 / Excel stack to establish the validity
 of your measurement methodology? Very likely you did it right, but I
 always cringe when I hear "Linux" or "NTP" and "precise time" in the
 same sentence. Yes, sorry, forgive me; I grew up in the "trust, but
 verify" generation [1]. It applies pretty well to metrology also ;-)
 
 /tvb
 
 [1] https://en.wikipedia.org/wiki/Trust,_but_verify
 
 
 End of time-nuts Digest, Vol 173, Issue 44
 **
>>> ___

Re: [time-nuts] More ES100 WWVB Measurements

[Wayne Holder]

While reading this thread and pondering whether to buy and fool around with
an ES100-based module from Universal Solder, I suddenly found myself
wondering if there was any advantage to using the time received from WWVB
vs just using an inexpensive GPS receiver.  The ES100  module costs about
$70, but I can get a GPS receiver, with antenna, for far less than that and
I've had no trouble receiving GPS signals indoors with most modern receiver
modules.

I suppose the low power requirements of the ES100 might be an advantage
when building battery powered clocks to mount on the wall, but it seems
like some of the newer, ultra low power GPS modules intended for use in
smart watches could also work in a battery-powered wall clock, especially
if the receiver was only powered on a few times a day to update the time.

And, finally, if GPS modules are (or will some become) a suitable
replacement for WWVB receiver modules, do we really need WWVB in the modern
age?  Perhaps there's some critical advantage to using WWVB to get the time
but, offhand, I cannot think of it.  What am I missing?

Wayne

On Mon, Dec 31, 2018 at 4:30 PM Brooke Clarke  wrote:

> Hi Joseph:
>
> Thanks for the patent link.  I've added it to my WWVB phase modulation
> info at:
> https://prc68.com/I/Loop.shtml#La_Crosse_UltrAtomic
>
> --
> Have Fun,
>
> Brooke Clarke
> https://www.PRC68.com
> http://www.end2partygovernment.com/2012Issues.html
> axioms:
> 1. The extent to which you can fix or improve something will be limited by
> how well you understand how it works.
> 2. Everybody, with no exceptions, holds false beliefs.
>
>  Original Message 
> > On Mon, 31 Dec 2018 12:00:02 -0500, time-nuts-requ...@lists.febo.com
> > wrote:
> >
> >>   time-nuts Digest, Vol 173, Issue 44
> >> Message: 7
> >> Date: Mon, 31 Dec 2018 04:04:22 -0800
> >> From: "Tom Van Baak" 
> >> To: "Discussion of precise time and frequency measurement"
> >>  
> >> Subject: Re: [time-nuts] More ES100 WWVB Measurements
> >> Message-ID: <96BB388753294278A9CDE96C1EA7D9AE@pc52>
> >> Content-Type: text/plain;charset="UTF-8"
> >>
> >> Hi Graham,
> >>
> >> That's very nice work. And you have uncovered several unusual effects
> >> in the ES100. Bugs? Features? If we time nuts keep up the good work
> >> to evaluate this chip, we are likely at some point to get an
> >> informative response from the guys who designed it. They read
> >> time-nuts.
> > I didn't see this mentioned, but I think I have found the relevant US
> > patent application: US20130051184A1, Real-time clock integrated circuit
> > with time code receiver, method of operation thereof and devices
> > incorporating the same, Oren Eliezer et al, Oren Eliezer et al, filed
> > 2013-02-28.
> >
> > .
> >
> > Found this by chasing stuff from the EverSet website:
> > .<
> http://everset-tech.com/wp-content/uploads/2014/11/ReceiverRadioClocks.pdf
> >.
> >
> > Joe Gwinn
> >
> >
> >> So now both you and Tim have observed the off-by-one-second (or
> >> off-by-N-seconds) effect in the ES100. I wonder if this explains why
> >> some of my ES100-based La Crosse 1235UA Ultratomic wall clocks are
> >> off by a second sometimes.
> >>
> >> My main question: in your "Time Plot.PNG" plot, what is the cause of
> >> the sawtooth pattern? The points are almost all on a clear negative
> >> slope, though bounded by roughly +/- 75ms. Looking on the far left, I
> >> see a time drift of +50 ms to -25 ms over an hour, which is
> >> equivalent to a -20 ppm frequency offset; about -2 seconds/day.
> >>
> >> Do you think this is due to the 16 MHz onboard xtal? If so, how about
> >> changing the temperature of the eval board by a lot (say, several
> >> tens of degrees) for an extended time (say, 4 hours) and see if the
> >> sawtooth slope changes convincingly.
> >>
> >> Also, just to be sure, can you put a known independent timing signal
> >> (e.g., GPS/1PPS) into your complex BeagleBone Black / Debian 9.4 /
> >> ntpd time server / Python 3 / Excel stack to establish the validity
> >> of your measurement methodology? Very likely you did it right, but I
> >> always cringe when I hear "Linux" or "NTP" and "precise time" in the
> >> same sentence. Yes, sorry, forgive me; I grew up in the "trust, but
> >> verify" generation [1]. It applies pretty well to metrology also ;-)
> >>
> >> /tvb
> >>
> >> [1] https://en.wikipedia.org/wiki/Trust,_but_verify
> >>
> >>
> >> End of time-nuts Digest, Vol 173, Issue 44
> >> **
> > ___
> > time-nuts mailing list -- time-nuts@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@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and 

Re: [time-nuts] More ES100 WWVB Measurements

[paul swed]

Good detective work. Oren is who I used to talk with at everset.
Regards
Paul
WB8TSL

On Mon, Dec 31, 2018 at 4:32 PM Joseph Gwinn  wrote:

> On Mon, 31 Dec 2018 12:00:02 -0500, time-nuts-requ...@lists.febo.com
> wrote:
>
> >  time-nuts Digest, Vol 173, Issue 44
>
> > Message: 7
> > Date: Mon, 31 Dec 2018 04:04:22 -0800
> > From: "Tom Van Baak" 
> > To: "Discussion of precise time and frequency measurement"
> >   
> > Subject: Re: [time-nuts] More ES100 WWVB Measurements
> > Message-ID: <96BB388753294278A9CDE96C1EA7D9AE@pc52>
> > Content-Type: text/plain; charset="UTF-8"
> >
> > Hi Graham,
> >
> > That's very nice work. And you have uncovered several unusual effects
> > in the ES100. Bugs? Features? If we time nuts keep up the good work
> > to evaluate this chip, we are likely at some point to get an
> > informative response from the guys who designed it. They read
> > time-nuts.
>
> I didn't see this mentioned, but I think I have found the relevant US
> patent application: US20130051184A1, Real-time clock integrated circuit
> with time code receiver, method of operation thereof and devices
> incorporating the same, Oren Eliezer et al, Oren Eliezer et al, filed
> 2013-02-28.
>
> .
>
> Found this by chasing stuff from the EverSet website:
> .<
> http://everset-tech.com/wp-content/uploads/2014/11/ReceiverRadioClocks.pdf
> >.
>
> Joe Gwinn
>
>
> > So now both you and Tim have observed the off-by-one-second (or
> > off-by-N-seconds) effect in the ES100. I wonder if this explains why
> > some of my ES100-based La Crosse 1235UA Ultratomic wall clocks are
> > off by a second sometimes.
> >
> > My main question: in your "Time Plot.PNG" plot, what is the cause of
> > the sawtooth pattern? The points are almost all on a clear negative
> > slope, though bounded by roughly +/- 75ms. Looking on the far left, I
> > see a time drift of +50 ms to -25 ms over an hour, which is
> > equivalent to a -20 ppm frequency offset; about -2 seconds/day.
> >
> > Do you think this is due to the 16 MHz onboard xtal? If so, how about
> > changing the temperature of the eval board by a lot (say, several
> > tens of degrees) for an extended time (say, 4 hours) and see if the
> > sawtooth slope changes convincingly.
> >
> > Also, just to be sure, can you put a known independent timing signal
> > (e.g., GPS/1PPS) into your complex BeagleBone Black / Debian 9.4 /
> > ntpd time server / Python 3 / Excel stack to establish the validity
> > of your measurement methodology? Very likely you did it right, but I
> > always cringe when I hear "Linux" or "NTP" and "precise time" in the
> > same sentence. Yes, sorry, forgive me; I grew up in the "trust, but
> > verify" generation [1]. It applies pretty well to metrology also ;-)
> >
> > /tvb
> >
> > [1] https://en.wikipedia.org/wiki/Trust,_but_verify
> >
> >
> > End of time-nuts Digest, Vol 173, Issue 44
> > **
>
> ___
> time-nuts mailing list -- time-nuts@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@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] More ES100 WWVB Measurements

[Joseph Gwinn]

On Mon, 31 Dec 2018 12:00:02 -0500, time-nuts-requ...@lists.febo.com 
wrote:

>  time-nuts Digest, Vol 173, Issue 44

> Message: 7
> Date: Mon, 31 Dec 2018 04:04:22 -0800
> From: "Tom Van Baak" 
> To: "Discussion of precise time and frequency measurement"
>   
> Subject: Re: [time-nuts] More ES100 WWVB Measurements
> Message-ID: <96BB388753294278A9CDE96C1EA7D9AE@pc52>
> Content-Type: text/plain; charset="UTF-8"
> 
> Hi Graham,
> 
> That's very nice work. And you have uncovered several unusual effects 
> in the ES100. Bugs? Features? If we time nuts keep up the good work 
> to evaluate this chip, we are likely at some point to get an 
> informative response from the guys who designed it. They read 
> time-nuts.

I didn't see this mentioned, but I think I have found the relevant US 
patent application: US20130051184A1, Real-time clock integrated circuit 
with time code receiver, method of operation thereof and devices 
incorporating the same, Oren Eliezer et al, Oren Eliezer et al, filed 
2013-02-28.  

.

Found this by chasing stuff from the EverSet website: 
..

Joe Gwinn

 
> So now both you and Tim have observed the off-by-one-second (or 
> off-by-N-seconds) effect in the ES100. I wonder if this explains why 
> some of my ES100-based La Crosse 1235UA Ultratomic wall clocks are 
> off by a second sometimes.
> 
> My main question: in your "Time Plot.PNG" plot, what is the cause of 
> the sawtooth pattern? The points are almost all on a clear negative 
> slope, though bounded by roughly +/- 75ms. Looking on the far left, I 
> see a time drift of +50 ms to -25 ms over an hour, which is 
> equivalent to a -20 ppm frequency offset; about -2 seconds/day.
> 
> Do you think this is due to the 16 MHz onboard xtal? If so, how about 
> changing the temperature of the eval board by a lot (say, several 
> tens of degrees) for an extended time (say, 4 hours) and see if the 
> sawtooth slope changes convincingly.
> 
> Also, just to be sure, can you put a known independent timing signal 
> (e.g., GPS/1PPS) into your complex BeagleBone Black / Debian 9.4 / 
> ntpd time server / Python 3 / Excel stack to establish the validity 
> of your measurement methodology? Very likely you did it right, but I 
> always cringe when I hear "Linux" or "NTP" and "precise time" in the 
> same sentence. Yes, sorry, forgive me; I grew up in the "trust, but 
> verify" generation [1]. It applies pretty well to metrology also ;-)
> 
> /tvb
> 
> [1] https://en.wikipedia.org/wiki/Trust,_but_verify
> 
> 
> End of time-nuts Digest, Vol 173, Issue 44
> **

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] More ES100 WWVB Measurements

[paul swed]

This is good work and I have been following.
What caught my attention was the 2 X very fast codes. I remember talking to
the everset folks early on and the high speed code could be turned on. It
had not been. The ES100 will not track that code as mentioned. Did not
think they actually ever turned it on.
More likely a power cycle left the system turned on. A bit of humor. If
John Lowe is still around send him a email he could turn it off.
Regards
Paul
WB8TSL

On Mon, Dec 31, 2018 at 7:05 AM Tom Van Baak  wrote:

> Hi Graham,
>
> That's very nice work. And you have uncovered several unusual effects in
> the ES100. Bugs? Features? If we time nuts keep up the good work to
> evaluate this chip, we are likely at some point to get an informative
> response from the guys who designed it. They read time-nuts.
>
> So now both you and Tim have observed the off-by-one-second (or
> off-by-N-seconds) effect in the ES100. I wonder if this explains why some
> of my ES100-based La Crosse 1235UA Ultratomic wall clocks are off by a
> second sometimes.
>
> My main question: in your "Time Plot.PNG" plot, what is the cause of the
> sawtooth pattern? The points are almost all on a clear negative slope,
> though bounded by roughly +/- 75ms. Looking on the far left, I see a time
> drift of +50 ms to -25 ms over an hour, which is equivalent to a -20 ppm
> frequency offset; about -2 seconds/day.
>
> Do you think this is due to the 16 MHz onboard xtal? If so, how about
> changing the temperature of the eval board by a lot (say, several tens of
> degrees) for an extended time (say, 4 hours) and see if the sawtooth slope
> changes convincingly.
>
> Also, just to be sure, can you put a known independent timing signal
> (e.g., GPS/1PPS) into your complex BeagleBone Black / Debian 9.4 / ntpd
> time server / Python 3 / Excel stack to establish the validity of your
> measurement methodology? Very likely you did it right, but I always cringe
> when I hear "Linux" or "NTP" and "precise time" in the same sentence. Yes,
> sorry, forgive me; I grew up in the "trust, but verify" generation [1]. It
> applies pretty well to metrology also ;-)
>
> /tvb
>
> [1] https://en.wikipedia.org/wiki/Trust,_but_verify
>
>
> - Original Message -
> From: "Graham / KE9H" 
> To: "Discussion of precise time and frequency measurement" <
> time-nuts@lists.febo.com>
> Sent: Sunday, December 30, 2018 6:03 PM
> Subject: [time-nuts] More ES100 WWVB Measurements
>
>
> > Attached are three graphs, plotting the results of two 24 hour runs of
> the
> > ES100 board.
> >
> > The ES100 can run in two modes. One for time acquisition, which takes 134
> > seconds, and a second mode for "tracking" which only takes 24 seconds to
> > execute, and returns only the "seconds" value.
> >
> > The tracking mode is intended for time sync of a receiver that already
> > knows
> > the time, and may need to compensate for oscillator drift. It can only
> sync
> > over a +/- 4 second correction interval, and must be started just before
> > the
> > top of the minute.
> >
> > The first plot, entitled Time Plot, is a plot of sequential time
> > acquisition
> > commands, which shows the time returned by the ES100, versus nptd time,
> on
> > a Linux (Debian 9.4) computer connected to the network. Due to
> asymmetrical
> > latency in a cable modem system, there might be some bias in the
> > Network time, but the bias should be constant for the 24 hour run.
> >
> > If the ES100 returned a "No Decode" for any single command, the value was
> > forced to -100 ms in the plot, and plotted on the line labeled "NO
> DECODE".
> >
> > The WWVB signal sends a 6 minute long highly encoded time signal at 10
> > Minutes
> > and 40 Minutes after the hour, which this chip can not decode, which are
> > the
> > clearly occurring repetitive "NO DECODE" bursts, twice per hour. To the
> > best of
> > my knowledge, there is no commercially available receiver or that can
> > decode this
> > 6 minute signal.
> >
> > The first time acquisition was within a few seconds of 0300 UTC, and ran
> > for
> > 24 hours. After each acquisition, whether successful or unsuccessful
> > decode,
> > the logging computer waited one second then requested another time
> > acquisition.
> > A total of 495 samples were captured and plotted.
> >
> > --
> >
> > The second test exercised the "tracking" mode.
> >
> > In this case, the logging computer requested a tracking update at 4
> seconds
> > before the top of the minute, every minute for 24 hours.
> >
> > The same results are plotted twice, once labeled "Track Plot ALL" which
> is
> > scaled to show all data, which includes some seconds returned as "valid"
> > but
> > are in error up to three seconds in time. It should be noted that there
> > were
> > only 13 of these events, and they all occurred during one of the six
> minute
> > highly encoded time signals, which this chip can not decode.  I let the
> > tracking sync requests run during these 6 minute signals.  If a real
> > 

Re: [time-nuts] ES100 Back in Stock

[Artek Manuals]

The "Two High Gain Antennas" feature is laughable :-)

On 12/31/2018 8:57 AM, Patrick Murphy wrote:

Just a heads-up. Universal Solder has two different ES100 devices back in
stock.

https://universal-solder.ca/product/everset-es100-cob-wwvb-60khz-bpsk-receiver-kit-with-2-antennas/
https://universal-solder.ca/product/everset-es100-adk-v2-wwvb-bpsk-phase-modulation-receiver/

-Pat (KG5YPQ)
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.



--
Dave
manu...@artekmanuals.com
www.ArtekManuals.com


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Long life products, obsolete components, and code 4 parts. RE: HP Cesium Standards in the International Atomic Time Scale, the legend of Felix Lazarus, and the "top cover

[Adrian Godwin]

Time-standard based stories are probably on-topic, but for those wanting a
wider range of subjects without posting to the list,
http://hpmemoryproject.org/ has good stuff. And, of course, the
http://www.hpl.hp.com/hpjournal/journal.html

Tek produced a book :
https://www.radiomuseum.org/lf/b/winning-with-people-the-first-40-years-of-tektronix/


On Mon, Dec 31, 2018 at 3:40 PM paul swed  wrote:

> hello to the group.
> I really am enjoying the stories and in reality history about a great
> company that I am very proud to actually own a lot of its technology.
> Though purchased for $/lbs at hamfests and such. All needing TLC and all of
> it teaching me more then a few lessons on how to do things.
> So though the stories center around real world trade offs. The fact is the
> guts were still very good. Says the guy with home brew crystal references.
> Chuckle.
>
> My one and only story was circa 1994-98 and video. Was at HP to see demos
> of their video server. Always thought it would be a great place to work.
> But going through the sea of cubes and seeing what it would actually be
> like settled that forever.
> Keep up the stories please.
> Regards
> Paul
> WB8TSL
>
> On Mon, Dec 31, 2018 at 12:37 AM Rice, Hugh (IPH Writing Systems) <
> hugh.r...@hp.com> wrote:
>
> > I’ll add a bit to Rick’s story, from my manufacturing engineering
> > perspective.
> > I was hired into PFS manufacturing engineering in 1984, specifically to
> > work with Roberto (Robert) Montesi on the 5061B product.   Roberto was
> the
> > production engineer on the 5061A, and acting “project manager” of our
> > little two man development team.  We were funded by manufacturing, as
> Rick
> > noted, but sat in the R lab for about 18 months as we redesigned
> > (updated) a bunch of stuff on the 5061A.
> >
> > As I mentioned a few weeks ago, Roberto was a very good engineer
> (compared
> > to me at least), and a great mentor.  One story he told me about himself
> > that I recall:  He was originally from Nicaragua, and somehow wound up in
> > the US Army during Vietnam, spending some time in combat there as a GI.
> >  At one point the Army wanted to send him to officers candidate school,
> > since he scored so well on all the tests.   He was a smart guy, with
> > perfect English.   Well into the process, they finally realized that he
> > wasn’t a US citizen, and thus couldn’t be an officer.He seemed to
> make
> > it through the whole Vietnam experience with minimal PTSD (as far as I
> > could tell), and would tell an interesting (and likely cynical) war story
> > now an then.   Like Rick said, Roberto kept his head down, and we sat in
> a
> > shared work area and did our 5061B thing, surrounded by the team working
> on
> > the new 5350,51,52 microwave counters, led by their very energetic
> project
> > manager Bob Renner.   The real R guys treated us well, even though we
> > were 2nd class production guys.   (Not too many years before this, R
> > engineers and production engineers were not on the same pay scale, and
> > really were second class in HP eyes.   The feeling of not being a “full”
> > engineer still lingered in 1984.)
> >
> > As Rick said, PFS products like the cesium standards were cash cow
> > products, and didn’t have a R staff at all.   All the “upgrades” were
> > funded by manufacturing, to keep this product line viable.The whole
> > development effort was about extending the production life of the 5061A.
> >  We were selling about 15/month, with an average price of about $35K.
> The
> > gross margins were very high (sales price – material costs), and the
> > product line delivered 4 or 5 million in gross profits to the division a
> > year.It was well worth having a couple of manufacturing engineers
> > freshen things up to keep this cow healthy.And Roberto was still the
> > production engineer for the 5061A during this time, so kinda doing double
> > duty.
> >
> > My job on the 5061B was to redesign the clock display and the battery
> > charger.  These were both part of the popular time-keeping option 003,
> > which was primarily the 1pps output circuit.  The battery backup was to
> > prevent the 1PPS signal from losing syc. If there was a power
> > interruption.   I recall the battery charger had a huge mica capacitor
> that
> > couldn’t be purchased any more, and a crazy design with obscure TTL
> > counters.   The clock display was even crazier.  Not nixie tubes,  but
> two
> > or three circular PC boards driving LED displays, and again obscure ICs
> > that were hard to procure.   Hard to build, and really expensive.   (More
> > on these in another story on another day.)
> >
> > Roberto redesigned the frequency divider module (5MHz in; 10MHz, 1MHz,
> > 100kHz out – another odd design rooted in 5060 history), the A3 power
> > regulator board, and some stuff internal to one (both?) of the high
> voltage
> > power supplies, used for the Ion Pump and Electron Multiplier.   Maybe
> some
> > other things too.  For 

[time-nuts] ES100 Back in Stock

[Patrick Murphy]

Just a heads-up. Universal Solder has two different ES100 devices back in
stock.

https://universal-solder.ca/product/everset-es100-cob-wwvb-60khz-bpsk-receiver-kit-with-2-antennas/
https://universal-solder.ca/product/everset-es100-adk-v2-wwvb-bpsk-phase-modulation-receiver/

-Pat (KG5YPQ)
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] Long life products, obsolete components, and code 4 parts. RE: HP Cesium Standards in the International Atomic Time Scale, the legend of Felix Lazarus, and the "top cover

[paul swed]

hello to the group.
I really am enjoying the stories and in reality history about a great
company that I am very proud to actually own a lot of its technology.
Though purchased for $/lbs at hamfests and such. All needing TLC and all of
it teaching me more then a few lessons on how to do things.
So though the stories center around real world trade offs. The fact is the
guts were still very good. Says the guy with home brew crystal references.
Chuckle.

My one and only story was circa 1994-98 and video. Was at HP to see demos
of their video server. Always thought it would be a great place to work.
But going through the sea of cubes and seeing what it would actually be
like settled that forever.
Keep up the stories please.
Regards
Paul
WB8TSL

On Mon, Dec 31, 2018 at 12:37 AM Rice, Hugh (IPH Writing Systems) <
hugh.r...@hp.com> wrote:

> I’ll add a bit to Rick’s story, from my manufacturing engineering
> perspective.
> I was hired into PFS manufacturing engineering in 1984, specifically to
> work with Roberto (Robert) Montesi on the 5061B product.   Roberto was the
> production engineer on the 5061A, and acting “project manager” of our
> little two man development team.  We were funded by manufacturing, as Rick
> noted, but sat in the R lab for about 18 months as we redesigned
> (updated) a bunch of stuff on the 5061A.
>
> As I mentioned a few weeks ago, Roberto was a very good engineer (compared
> to me at least), and a great mentor.  One story he told me about himself
> that I recall:  He was originally from Nicaragua, and somehow wound up in
> the US Army during Vietnam, spending some time in combat there as a GI.
>  At one point the Army wanted to send him to officers candidate school,
> since he scored so well on all the tests.   He was a smart guy, with
> perfect English.   Well into the process, they finally realized that he
> wasn’t a US citizen, and thus couldn’t be an officer.He seemed to make
> it through the whole Vietnam experience with minimal PTSD (as far as I
> could tell), and would tell an interesting (and likely cynical) war story
> now an then.   Like Rick said, Roberto kept his head down, and we sat in a
> shared work area and did our 5061B thing, surrounded by the team working on
> the new 5350,51,52 microwave counters, led by their very energetic project
> manager Bob Renner.   The real R guys treated us well, even though we
> were 2nd class production guys.   (Not too many years before this, R
> engineers and production engineers were not on the same pay scale, and
> really were second class in HP eyes.   The feeling of not being a “full”
> engineer still lingered in 1984.)
>
> As Rick said, PFS products like the cesium standards were cash cow
> products, and didn’t have a R staff at all.   All the “upgrades” were
> funded by manufacturing, to keep this product line viable.The whole
> development effort was about extending the production life of the 5061A.
>  We were selling about 15/month, with an average price of about $35K.  The
> gross margins were very high (sales price – material costs), and the
> product line delivered 4 or 5 million in gross profits to the division a
> year.It was well worth having a couple of manufacturing engineers
> freshen things up to keep this cow healthy.And Roberto was still the
> production engineer for the 5061A during this time, so kinda doing double
> duty.
>
> My job on the 5061B was to redesign the clock display and the battery
> charger.  These were both part of the popular time-keeping option 003,
> which was primarily the 1pps output circuit.  The battery backup was to
> prevent the 1PPS signal from losing syc. If there was a power
> interruption.   I recall the battery charger had a huge mica capacitor that
> couldn’t be purchased any more, and a crazy design with obscure TTL
> counters.   The clock display was even crazier.  Not nixie tubes,  but two
> or three circular PC boards driving LED displays, and again obscure ICs
> that were hard to procure.   Hard to build, and really expensive.   (More
> on these in another story on another day.)
>
> Roberto redesigned the frequency divider module (5MHz in; 10MHz, 1MHz,
> 100kHz out – another odd design rooted in 5060 history), the A3 power
> regulator board, and some stuff internal to one (both?) of the high voltage
> power supplies, used for the Ion Pump and Electron Multiplier.   Maybe some
> other things too.  For all of these, obsolete components was the driving
> force.
>
> By 1984 standards, there were some really crazy circuits still in the
> instrument (still another story for another day), but as Rick said, in low
> volume manufacturing, if it isn’t broken, don’t fix it.  In the case of the
> 5061, don’t even think about touching it.
>
> Rick’s memory of the management dynamics are similar to mine.   A 5061A to
> 5061B “upgrade”, particularly if funded by manufacturing, was easy to get
> approved.Entire new developments were hard to justify.The division
> was 

Re: [time-nuts] TIC Characterization

[Poul-Henning Kamp]

In message , Magnus D
anielson writes:

>> measure (start=house_std, stop=siggen) and (start=siggen, stop=house_std) for
>> as many siggen phase settings as you have patience for.
>
>Well, this was the second setup I was talking about. To disclose the
>full non-linearity you want to tweak it to 9.999 MHz rather than 10 MHz.

Yes, that is a fall-back if your siggen cannot control the phase.

Of course if you both set 9.999 MHz *and* sweep the phase, you will
be able to separte the effects of the siggen and counter even better.

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] More ES100 WWVB Measurements

[Tom Van Baak]

Hi Graham,

That's very nice work. And you have uncovered several unusual effects in the 
ES100. Bugs? Features? If we time nuts keep up the good work to evaluate this 
chip, we are likely at some point to get an informative response from the guys 
who designed it. They read time-nuts.

So now both you and Tim have observed the off-by-one-second (or 
off-by-N-seconds) effect in the ES100. I wonder if this explains why some of my 
ES100-based La Crosse 1235UA Ultratomic wall clocks are off by a second 
sometimes.

My main question: in your "Time Plot.PNG" plot, what is the cause of the 
sawtooth pattern? The points are almost all on a clear negative slope, though 
bounded by roughly +/- 75ms. Looking on the far left, I see a time drift of +50 
ms to -25 ms over an hour, which is equivalent to a -20 ppm frequency offset; 
about -2 seconds/day.

Do you think this is due to the 16 MHz onboard xtal? If so, how about changing 
the temperature of the eval board by a lot (say, several tens of degrees) for 
an extended time (say, 4 hours) and see if the sawtooth slope changes 
convincingly.

Also, just to be sure, can you put a known independent timing signal (e.g., 
GPS/1PPS) into your complex BeagleBone Black / Debian 9.4 / ntpd time server / 
Python 3 / Excel stack to establish the validity of your measurement 
methodology? Very likely you did it right, but I always cringe when I hear 
"Linux" or "NTP" and "precise time" in the same sentence. Yes, sorry, forgive 
me; I grew up in the "trust, but verify" generation [1]. It applies pretty well 
to metrology also ;-)

/tvb

[1] https://en.wikipedia.org/wiki/Trust,_but_verify


- Original Message - 
From: "Graham / KE9H" 
To: "Discussion of precise time and frequency measurement" 

Sent: Sunday, December 30, 2018 6:03 PM
Subject: [time-nuts] More ES100 WWVB Measurements


> Attached are three graphs, plotting the results of two 24 hour runs of the
> ES100 board.
> 
> The ES100 can run in two modes. One for time acquisition, which takes 134
> seconds, and a second mode for "tracking" which only takes 24 seconds to
> execute, and returns only the "seconds" value.
> 
> The tracking mode is intended for time sync of a receiver that already
> knows
> the time, and may need to compensate for oscillator drift. It can only sync
> over a +/- 4 second correction interval, and must be started just before
> the
> top of the minute.
> 
> The first plot, entitled Time Plot, is a plot of sequential time
> acquisition
> commands, which shows the time returned by the ES100, versus nptd time, on
> a Linux (Debian 9.4) computer connected to the network. Due to asymmetrical
> latency in a cable modem system, there might be some bias in the
> Network time, but the bias should be constant for the 24 hour run.
> 
> If the ES100 returned a "No Decode" for any single command, the value was
> forced to -100 ms in the plot, and plotted on the line labeled "NO DECODE".
> 
> The WWVB signal sends a 6 minute long highly encoded time signal at 10
> Minutes
> and 40 Minutes after the hour, which this chip can not decode, which are
> the
> clearly occurring repetitive "NO DECODE" bursts, twice per hour. To the
> best of
> my knowledge, there is no commercially available receiver or that can
> decode this
> 6 minute signal.
> 
> The first time acquisition was within a few seconds of 0300 UTC, and ran
> for
> 24 hours. After each acquisition, whether successful or unsuccessful
> decode,
> the logging computer waited one second then requested another time
> acquisition.
> A total of 495 samples were captured and plotted.
> 
> --
> 
> The second test exercised the "tracking" mode.
> 
> In this case, the logging computer requested a tracking update at 4 seconds
> before the top of the minute, every minute for 24 hours.
> 
> The same results are plotted twice, once labeled "Track Plot ALL" which is
> scaled to show all data, which includes some seconds returned as "valid"
> but
> are in error up to three seconds in time. It should be noted that there
> were
> only 13 of these events, and they all occurred during one of the six minute
> highly encoded time signals, which this chip can not decode.  I let the
> tracking sync requests run during these 6 minute signals.  If a real
> application
> knew not to ask for tracking sync during this time, the false "valid" would
> not
> occur. But it does suggest a problem within the error detection/correction
> processes within the ES100 chip.
> 
> To give a better view of the time "tracking" performance of the chip, I
> plotted
> the same data on a scale of +150, -100 milliseconds. This plot is labeled
> "Track Plot Close-In Detail."  On this plot, "NO DECODES" are forced to a
> value
> of -150 milliseconds and thereby plotted on the line labeled "No Decode".
> The 13 invalid decodes marked valid, all one second or greater in error are
> off-scale on this plot, so not visible.
> A total of 1440 samples were captured.
> 
> --
> 
> The logging computer is a 

Re: [time-nuts] Long life products, obsolete components, and code 4 parts.

[Magnus Danielson]

Hi,

On 12/31/18 7:31 AM, Tom Van Baak wrote:
>> This email chain has unleashed a flood of memories from 30 years ago.
>> Hopefully a few of you find this walk down memory lane interesting.
>> I have a few more stories in the que if any of you are still interested.
>>
>> Hugh Rice
> 
> Somewhere in my library I have an internal hp document describing all the 
> changes between the 5061 A and B. I remember a number of the changes were 
> influenced by feedback from the repair group. So the design was driven not 
> only by manufacturability, but also serviceability.
> 
> By the time the 5061B came out there was a decade or two of field experience 
> with portable cesium clocks and this was put to good use. If you have this 
> document it would be worth scanning. If not, I'll try to find the box where 
> my copy is hiding.

In usual HP style, minor fixes was surely introduced stepwise to reduce
returns or fix common enough issues.

> Yes, keep the stories coming. They are very much appreciated.

Indeed, very nice reading from both Hugh and Rick here.

Cheers,
Magnus

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] TIC Characterization

[Tom Van Baak]

> Thanks Tom for your quick and extensive reply. 
> Indeed I confused Time Interval with Phase Difference… 
...
> By the way, it also seems that HDEV at Tau=1 is  2/sqrt(3) * Sigma = 1.15 
> SigmaTIC
>

I don't believe that HDEV result. For many large runs of simulated normalized 
white phase noise input I get:
adev(1) = 1.732, mdev(1) = 1.732, tdev(1) = 1.000, hdev(1) = 1.825


See: https://en.wikipedia.org/wiki/Sum_of_normally_distributed_random_variables
or google for topics like:
sums of independent random variables
normal sum distribution
linear combinations of normal random variables

Then look at both calc_adev() and calc_hdev() in 
http://leapsecond.com/tools/adev_lib.c
Assuming you have white phase noise input with mean=0, stdev=1 and using tau=1, 
then,

1) The key lines for ADEV are:
v = data[i + 2*tau] - 2 * data[i + tau] + data[i];
sum /= 2.0;
So you would expect sqrt( (1 + 4 + 1) / 2 ) = sqrt(6/2) = 1.7321

2) The key lines for HDEV are:
v = data[i + 3*tau] - 3 * data[i + 2*tau] + 3 * data[i + tau] - data[i];
sum /= 6.0;
So you would expect sqrt( (1 + 9 + 9 + 1) / 6 ) = sqrt(20/6) = 1.8257

3) MDEV is the same as ADEV for tau = 1 so that's why it is also 1.7321.

4) TDEV is MDEV / sqrt(3) so that why it gives 1..


For testing counter resolution TDEV is often more instructive than ADEV:

a) TDEV doesn't have that misleading, distracting, prolonged -1 slope that ADEV 
plots often show.
b) TDEV has the nice property of reporting 1 when given 1 RMS data.
c) The units for TDEV are seconds, which is appropriate for a TIC (time 
interval counter).
d) The units for ADEV are fractional frequency, which is natural for frequency 
standards.
e) Unless there are design flaws, instrument drift, or environmental issues, 
TDEV should be flat from tau 1 to forever.
f) Subtle, unwanted variations are much easier to observe in a flat line (TDEV) 
than a -1 line (ADEV).

/tvb


- Original Message - 
From: "Club-Internet Clemgill" 
To: "Tom Van Baak" ; "Discussion of precise time and 
frequency measurement" 
Sent: Sunday, December 30, 2018 1:07 AM
Subject: Re: [time-nuts] TIC Characterization


Thanks Tom for your quick and extensive reply. 
Indeed I confused Time Interval with Phase Difference… 

Corrected calc: 
4/ [(Xi+2 - Xi+1) - (Xi+1 - Xi)]^2 = [(To + Ti+2) - 2(To + Ti+1) + (To + Ti)]^2 
= [Ti+2 - 2Ti+1 + Ti]^2 
=  (Ti+2)^2 + 4(Ti+1)^2 + (Ti)^2 + 2(-2Ti+2*Ti+1 + Ti+2*Ti - 2Ti+1*Ti)

5/ <(Ti+1)^2> # <(Ti+1)^2> #  < (Ti)^2> for large samples and  
<(Ti+a * Ti+b)> = 0 as Ti+1 and Ti are independent
Then AVAR =  (1/2Tau^2) * 6 < (Ti)^2>  = (1/Tau^2) * 6  * SigmaTIC^2

6/ Hence ADEV = sqrt(3) * SigmaTIC / Tau

So ADEV(Tau=1)  = 1.73 * SigmaTIC (indeed…)

By the way, it also seems that HDEV at Tau=1 is  2/sqrt(3) * Sigma = 1.15 
SigmaTIC

Best, 
Gilles.

 


> Le 30 déc. 2018 à 07:14, Tom Van Baak  a écrit :
> 
> Hi Gilles,
> 
> Correct, the log-log slope will be -1.
> 
> But I'm not sure about your ADEV and SigmaTIC claim.
> 
> Assume the 53132A has 150 ps RMS resolution. The standard deviation is also 
> 150 ps. The Allan deviation at tau=1 would be 1.73 * 150 ps/s or 2.60e-10.
> 
> Look at calc_adev() in http://leapsecond.com/tools/adev_lib.c and note the 
> three data[] terms. With multiple uncorrelated terms you simply sum the 
> variances. There are three terms so that's 3 * stdev. When you convert AVAR 
> to ADEV the 3 becomes sqrt(3), or 1.73. Make sense?
> 
> For extra credit, note that MDEV at tau=1 is the same as ADEV. However, TDEV 
> at tau=1 is 1.50e-10, the same as stdev. In the same file, see that the 
> sqrt(3) factor is removed in calc_tdev().
> 
> 
> 
> The best and largest pile of ADEV documentation is:
> 
> "information about frequency stability analysis"
> http://www.wriley.com/Freq%20Stab%20Analy%20Links.htm
> 
> There is also a wikipedia page:
> 
> https://en.wikipedia.org/wiki/Allan_variance
> 
> For simpler introductions see:
> 
> "Analysis of Time Domain Data"
> https://tf.nist.gov/phase/Properties/four.htm
> 
> "Clock Performance and Performance Measures"
> https://tycho.usno.navy.mil/mclocks2.html
> 
> "Fundamentals of Time and Frequency"
> https://tf.nist.gov/general/pdf/1498.pdf
> 
> 
> 
> If you want to play with ADEV check out Stable32 [1] or TimeLab [2]. Both are 
> highly recommended and are also free. For questions like yours the Stable32 
> noise generator feature is very useful to explore the shape(s) of ADEV for 
> given noise types. It was used to create:
> 
> "Exploring Allan Deviation"
> http://leapsecond.com/pages/allan/Exploring_Allan_Deviation_v2.pdf
> 
> /tvb
> 
> [1] http://www.stable32.com/
> [2] http://www.ke5fx.com/timelab/readme.htm
> 
> 
> - Original Message - 
> From: "Club-Internet Clemgill" 
> To: "Discussion of precise time and frequency measurement" 
> 
> Sent: Saturday, December 29, 2018 2:28 PM
> Subject: [time-nuts] TIC Characterization
> 
> 
>> Hi, 
>> Looking to testing my HP53132A