Re: [time-nuts] ADEV vs. OADEV

[Ulrich Bangert]

Magnus,

I am aware that you know a lot about these things. Nevertheless I
believe you are starting a most dangerous discussion in the sense that
you put some terms into question of which I believed that they have well
been established. For that reason let me test where we agree and where
not:

Mr. Allan decided that for his new statistical measure the summation
shall run over

square(y(i+1)-y(i))

for frequency data and over

square(x(i+2)-2*x(i+1)+(xi))

for phase data. Both in contrast to the standard deviation where the
summation runs over squares of distances from the mean. This new
variance was called "Allan variance" and its square root "Allan
deviation" to honor Mr. Allan for his work. This variance/deviation has
a certain "overlapping aspect" since a single y(i) or x(i) appears in
multiple terms of the summation. Agreed?

Both terms require that the elements with subsequent indices are spaced
apart at the "Tau" for wich the computation shall be done. Considered a
number of phase measurements spaced 1 s apart then the computation will
run over 

square(x(i+2)-2*x(i+1)+(xi))

for Tau = 1 s. If you are going to compute for Tau = 2 s from the SAME
data set you will have to use the "original" samples

square(x(5)-2*x(3)+x(1)) 

for the first summand and

square(x(7)-2*x(5)+x(3))

for the second summand and

square(x(9)-2*x(7)+x(5))

for the third summand and so on. All indices are incremented by two
between neighbour summands because the next summand is 2 s (or two
original samples) apart from the current summand. Agreed?

As we notice the summation leaves out a number of summands where the
elements are also spaced 2 s apart, for example

square(x(6)-2*x(4)+x(2))

or

square(x(8)-2*x(6)+x(4))

If we use these additional terms in the summation the number of summands
increases a lot and improves the confidence interval of the estimation,
even though the added summands are NOT completely statistical
independend from the original ones and therefore this measure shall be
clearly distincted from the original Allan variance/deviation. The
summation over the original terms plus the added terms delivers the
"Overlapping Allan variance/deviation" in conjunction with a suitable
normation factor. Agreed?

Best regards
Ulrich 

> -Ursprüngliche Nachricht-
> Von: time-nuts-boun...@febo.com 
> [mailto:time-nuts-boun...@febo.com] Im Auftrag von Magnus Danielson
> Gesendet: Mittwoch, 21. Januar 2009 09:33
> An: Discussion of precise time and frequency measurement
> Betreff: [time-nuts] ADEV vs. OADEV
> 
> 
> Hi!
> 
> I have been quite surprised to see the abbreviation OADEV appear. I 
> assume that this means Overlapped Allan Deviation, but this 
> is confusing 
> since the Allan Deviation estimates already is overlapping. 
> However, I 
> have seen that some use a non-overlapping estimator, but this type of 
> estimator has an unwanted filtering effect and should not be used.
> 
> If a distinction between these ADEV estimators should be 
> used, then the 
> standard (overlapping) estimator should continue to be called 
> ADEV and 
> the non-overlapping (back-to-back) could be called NOADEV ór 
> whatever...
> 
> I have done a fair amount of digging around many sources 
> around ADEV and 
> friends so I think I got it right.
> 
> Unless someone can give a meaningful explanation and I really 
> expect a 
> good article detailing the difference and benefits...
> 
> Cheers,
> Magnus
> 
> ___
> 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] ADEV vs. OADEV

[Magnus Danielson]

Ulrich,

Ulrich Bangert skrev:
> Magnus,
> 
> I am aware that you know a lot about these things. Nevertheless I
> believe you are starting a most dangerous discussion in the sense that
> you put some terms into question of which I believed that they have well
> been established.

I have only recently seen the OADEV being used where as I have seen 
countless articles on calculations of these without encountering them, 
so from my standpoint OADEV is not well established, which is why I 
raised the question in order to "shake the tree" to see what fruits that 
I have missed.

> For that reason let me test where we agree and where
> not:
> 
> Mr. Allan decided that for his new statistical measure the summation
> shall run over
> 
> square(y(i+1)-y(i))
> 
> for frequency data and over
> 
> square(x(i+2)-2*x(i+1)+(xi))
> 
> for phase data. Both in contrast to the standard deviation where the
> summation runs over squares of distances from the mean. This new
> variance was called "Allan variance" and its square root "Allan
> deviation" to honor Mr. Allan for his work. This variance/deviation has
> a certain "overlapping aspect" since a single y(i) or x(i) appears in
> multiple terms of the summation. Agreed?

Yes, yes

Actually, what you describe is the estimator formulas rather than 
definition. This is also targeting the fine point that I am trying to 
make. It's not about the basic definition, but accepted convention to 
denote the estimators.

> Both terms require that the elements with subsequent indices are spaced
> apart at the "Tau" for wich the computation shall be done. Considered a
> number of phase measurements spaced 1 s apart then the computation will
> run over 
> 
> square(x(i+2)-2*x(i+1)+(xi))
> 
> for Tau = 1 s. If you are going to compute for Tau = 2 s from the SAME
> data set you will have to use the "original" samples
> 
> square(x(5)-2*x(3)+x(1)) 
> 
> for the first summand and
> 
> square(x(7)-2*x(5)+x(3))
> 
> for the second summand and
> 
> square(x(9)-2*x(7)+x(5))
> 
> for the third summand and so on. All indices are incremented by two
> between neighbour summands because the next summand is 2 s (or two
> original samples) apart from the current summand. Agreed?

Yes, yes...

> As we notice the summation leaves out a number of summands where the
> elements are also spaced 2 s apart, for example
> 
> square(x(6)-2*x(4)+x(2))
> 
> or
> 
> square(x(8)-2*x(6)+x(4))
> 
> If we use these additional terms in the summation the number of summands
> increases a lot and improves the confidence interval of the estimation,
> even though the added summands are NOT completely statistical
> independend from the original ones and therefore this measure shall be
> clearly distincted from the original Allan variance/deviation. The
> summation over the original terms plus the added terms delivers the
> "Overlapping Allan variance/deviation" in conjunction with a suitable
> normation factor. Agreed?

Disagree. The estimator formulation that is classically used includes 
these "missed" tau0 steps that you claim that OAVAR/OADEV includes. This 
is my point. Somewhere along the line the established ADEV estimator 
became the OADEV estimator and another estimator took the ADEV place. 
This is what I oppose without a more detailed look at things.

I agree that it changes the statistical properties in terms of 
confidence interval, but it also change the frequency dependence. The 
analysis on frequency dependency needs to be redone as I suspect they do 
not always agree.

Cheers,
Magnus

___
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] Tbolt monitor software

[VK3FGJM]

Hi Ed,

Initially I felt that was the case, but after some brief RS-232
measurement and the ability to see the TX/RX LED radio buttons sync with
TX and RX data on the serial activity Monitor at the bottom left corner,
there is nothing wrong with the RS-232 lines.

Does anyone have a later version of the Trimble Thunderbolt monitor
program or any other thoughts?


Kind regards,

Gerald

VK3FGJM


-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Ed, k1ggi
Sent: Thursday, 22 January 2009 1:24 PM
To: 'Discussion of precise time and frequency measurement'
Subject: Re: [time-nuts] Tbolt monitor software

Sounds like the tbolt is not getting the queries from the pc and
therefore the responses are absent, but the pc is getting the
unsolicited info from the tbolt. A fault with pin 3 on the DE9 would do
it, or something deeper that kills the pc-to-tbolt comms.
Ed, k1ggi

-Original Message-
From: VK3FGJM [mailto:vk3f...@commtelns.com]
Sent: Wednesday, January 21, 2009 3:32 PM
To: time-nuts@febo.com
Subject: Re: [time-nuts] Tbolt monitor software

Hi,

Yes, I can see alarm status and changes when unplugging antenna etc.

As mentioned the unit actually works, just no data certain displayed.

Regards,

Gerald
VK3FGJM



-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of n3...@aol.com
Sent: Thursday, 22 January 2009 3:55 AM
To: time-nuts@febo.com
Subject: Re: [time-nuts] Tbolt monitor software

Did you select the right comm port? I power mine off a lot and it has
always come back.


-Original Message-
From: VK3FGJM 
To: time-nuts@febo.com
Sent: Wed, 21 Jan 2009 5:29 am
Subject: [time-nuts] Tbolt monitor software



Hi group,
 
A strange situation has led me to ask a question about the Tbolt GPSDO
and the Trimble Thunderbolt monitor s/w version 2.6.
 
While re-arrangement of the shack, it's been idle for 3 weeks, Tbolt
turned off. After turning the unit on and letting it settle some 2 hour,
I connected the monitor program and found the following that I can not
explain and correct:-

*   All SV and AMU have question marks
*   Product info has questions marks
*   the ability to see tracking status is blank.

When last used, some 2 months ago to show a friend, the relevant display
data came up, no issues. Further more, position, critical and minor
alarms are green, disciplining status section such as DAC voltage DAC
value mode and even it's 10MHz out etc etc is fine compared to my trusty
Rubidium standard.
 
Has any one seen this before and is there a setting that may have
inhibited this feature?
 
I have a screen shot, however it may be to large to attach, so let me
know if this will help, I will be glad to forward it to some one with
much more knowledge.
 
Thank you in advance.
 
Regards,
 
 
Gerald
 
VK3FGJM
 
 
 
 
 
 
 

 

___
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.
--
Message  protected by MailGuard: e-mail anti-virus, anti-spam and
content filtering.
http://www.mailguard.com.au/mg



___
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] ADEV vs. OADEV

[Ulrich Bangert]

Magnus,

> Actually, what you describe is the estimator formulas rather than 
> definition. This is also targeting the fine point that I am trying to 
> make. It's not about the basic definition, but accepted convention to 
> denote the estimators.

I still do not understand the fine point! A estimator might have this
property and that property and may perform this task good and another
task bad, but at the basics we have a formula and if the formula is new
or different from prior art then the thing needs an name of its own. In
this sense the summation over square(y(i+1)-y(i)) is called the base of
the "Allan variance/deviation" just for historical reasons. So the name
is "Allen deviation" and it is defined by its formula.  

> Disagree. The estimator formulation that is classically used includes 
> these "missed" tau0 steps that you claim that OAVAR/OADEV 
> includes. This is my point. Somewhere along the line the established
ADEV estimator 
> became the OADEV estimator and another estimator took the ADEV place. 
> This is what I oppose without a more detailed look at things.

The OAVAR/OADEV has this name of its own BECAUSE it includes the
summands that are missed by the original AVAR/ADEV so its needs an name
of its own.

>Somewhere along the line the established ADEV estimator became the
OADEV estimator

If you had said: "The currently established estimator for oscillator
stability is the OADEV estimator" I would have perfectly agreed.
However, ADEV does already point to a different thing, so to say "Today
we call ADEV what was formerly called OADEV and what was formerly called
ADEV now is also called different" is not excused with a certain
sloppiness in language but simply wrong use of terms. Exactly this is
the point why I said that the discussion is dangerous. This is not a
change in paradigm this is a case of inaccurate use of scientifical
terms.

Best regards
Ulrich



> -Ursprungliche Nachricht-
> Von: time-nuts-boun...@febo.com 
> [mailto:time-nuts-boun...@febo.com] Im Auftrag von Magnus Danielson
> Gesendet: Donnerstag, 22. Januar 2009 10:57
> An: Discussion of precise time and frequency measurement
> Betreff: Re: [time-nuts] ADEV vs. OADEV
> 
> 
> Ulrich,
> 
> Ulrich Bangert skrev:
> > Magnus,
> > 
> > I am aware that you know a lot about these things. Nevertheless I 
> > believe you are starting a most dangerous discussion in the 
> sense that 
> > you put some terms into question of which I believed that they have 
> > well been established.
> 
> I have only recently seen the OADEV being used where as I have seen 
> countless articles on calculations of these without 
> encountering them, 
> so from my standpoint OADEV is not well established, which is why I 
> raised the question in order to "shake the tree" to see what 
> fruits that 
> I have missed.
> 
> > For that reason let me test where we agree and where
> > not:
> > 
> > Mr. Allan decided that for his new statistical measure the 
> summation 
> > shall run over
> > 
> > square(y(i+1)-y(i))
> > 
> > for frequency data and over
> > 
> > square(x(i+2)-2*x(i+1)+(xi))
> > 
> > for phase data. Both in contrast to the standard deviation 
> where the 
> > summation runs over squares of distances from the mean. This new 
> > variance was called "Allan variance" and its square root "Allan 
> > deviation" to honor Mr. Allan for his work. This variance/deviation 
> > has a certain "overlapping aspect" since a single y(i) or 
> x(i) appears 
> > in multiple terms of the summation. Agreed?
> 
> Yes, yes
> 
> Actually, what you describe is the estimator formulas rather than 
> definition. This is also targeting the fine point that I am trying to 
> make. It's not about the basic definition, but accepted convention to 
> denote the estimators.
> 
> > Both terms require that the elements with subsequent indices are 
> > spaced apart at the "Tau" for wich the computation shall be done. 
> > Considered a number of phase measurements spaced 1 s apart then the 
> > computation will run over
> > 
> > square(x(i+2)-2*x(i+1)+(xi))
> > 
> > for Tau = 1 s. If you are going to compute for Tau = 2 s 
> from the SAME 
> > data set you will have to use the "original" samples
> > 
> > square(x(5)-2*x(3)+x(1))
> > 
> > for the first summand and
> > 
> > square(x(7)-2*x(5)+x(3))
> > 
> > for the second summand and
> > 
> > square(x(9)-2*x(7)+x(5))
> > 
> > for the third summand and so on. All indices are incremented by two 
> > between neighbour summands because the next summand is 2 s (or two 
> > original samples) apart from the current summand. Agreed?
> 
> Yes, yes...
> 
> > As we notice the summation leaves out a number of summands 
> where the 
> > elements are also spaced 2 s apart, for example
> > 
> > square(x(6)-2*x(4)+x(2))
> > 
> > or
> > 
> > square(x(8)-2*x(6)+x(4))
> > 
> > If we use these additional terms in the summation the number of 
> > summands increases a lot and improves the confidence 
> interval of the 
> > estimation, even tho

[time-nuts] Thunderbolt data issue

[VK3FGJM]

Hi All,
 
To the group, for your interest, a dry solder joint on IC U18 MAX 232 at
5 V logic side caused my issue. Although RS-232 data went in, it did not
reach CPU. My MAX 232 was badly soldered due to initial assembly had
some discoloured IC pins and solder did not free flow. Completely
removed IC, cleaned and reflowed.
 
Thanks to those providing comment.
 
Regards,
 
Gerald
 
VK3FGJM
 
 
 
 

 

 
___
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] ADEV vs. OADEV

[Magnus Danielson]

Ulrich,

Ulrich Bangert skrev:
> Magnus,
> 
>> Actually, what you describe is the estimator formulas rather than 
>> definition. This is also targeting the fine point that I am trying to 
>> make. It's not about the basic definition, but accepted convention to 
>> denote the estimators.
> 
> I still do not understand the fine point! A estimator might have this
> property and that property and may perform this task good and another
> task bad, but at the basics we have a formula and if the formula is new
> or different from prior art then the thing needs an name of its own.

This part we agree on, however, you fail to see that what I try to point 
out is that you seems to have the wrong reference to start with. What I 
am trying to say is that it seems that ADEV is being used to identify a 
different estimator than I have in my old material, including the 
articles collected in NIST TN1337, for instance "Time and Frequency 
(Time-Domain) Characterization, Estimation, and Prediction of Precision 
Clocks and Oscillators" by David W. Allan.
http://tf.nist.gov/timefreq/general/tn1337/Tn121.pdf
See page 4 and formulas 8 and 9. These are overlapping.

> In this sense the summation over square(y(i+1)-y(i)) is called the base of
> the "Allan variance/deviation" just for historical reasons. So the name
> is "Allen deviation" and it is defined by its formula.  

A further reference would be the IEEE standard found in

http://tf.nist.gov/timefreq/general/tn1337/Tn139.pdf

This is also overlapping (from page 2):

 N-2m
  ___
  2  1   \2
sigma  (tau) = ---   >   (x - 2x+ x )
  y   2  /___   i+2m i+mi
2(N-2m)tau   i = 1

a non-interleaved variant would have to be written as (assuming that m 
divides N):

   N
   - - 2
   m
___
  m\  2
   >   (x   - 2x   + x  )
   2   /___   (i+2)m (i+1)mim
2(N-2m)taui = 1

and these obviously isn't the same, the later form skips over samples 
not being a multiple of m.

Also, it is still overlapping in the sense that samples is being re-used.

>> Disagree. The estimator formulation that is classically used includes 
>> these "missed" tau0 steps that you claim that OAVAR/OADEV 
>> includes. This is my point. Somewhere along the line the established
> ADEV estimator 
>> became the OADEV estimator and another estimator took the ADEV place. 
>> This is what I oppose without a more detailed look at things.
> 
> The OAVAR/OADEV has this name of its own BECAUSE it includes the
> summands that are missed by the original AVAR/ADEV so its needs an name
> of its own.

I deeply disagree, see my reference to early papers (I agree not 
original). Also, the standardised form is overlapping.

This is the reason for me to react.

>> Somewhere along the line the established ADEV estimator became the
> OADEV estimator
> 
> If you had said: "The currently established estimator for oscillator
> stability is the OADEV estimator" I would have perfectly agreed.

Well, that part was never what we disagreed on IMHO.

> However, ADEV does already point to a different thing, so to say "Today
> we call ADEV what was formerly called OADEV and what was formerly called
> ADEV now is also called different" is not excused with a certain
> sloppiness in language but simply wrong use of terms. Exactly this is
> the point why I said that the discussion is dangerous. This is not a
> change in paradigm this is a case of inaccurate use of scientifical
> terms.

Well, if we were doing a shift in interpretation I fully agree with you, 
but what I reacted on was due to a shift in interpretation as I 
experienced it and when looking at the old reference material (altought 
I have not had the time for an extensive search that I would feel 
confident with). The issue was that I detected the dangerous shift and I 
wanted to bring it up to bring it back on tracks, or at least learn 
something useful.

I really kindly ask you or anyone else to bring forward articles 
describing the non-overlapping ADEV and help plotting out the issues. 
What has become standardised (and thus assumed accepted) as the ADEV 
estimator is overlappping unless you can point out that I have made a 
very deep misunderstanding of all those papers, in which case I would be 
happy to be corrected.

Cheers,
Magnus

___
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] ADEV vs. OADEV

[Magnus Danielson]

Bruce Griffiths skrev:

> Ulrich. Magnus
> 
> Perhaps the situation is best summarised in /NIST special Publication
> 1065/ (can be downloaded as 2220.pdf
>  from NIST) wherein it
> is stated that ADEV, AVAR are often taken to mean the overlapped form of
> the Allan deviation at least in the US.

This is an excellent contribution to the discussion as it details the 
"Original Allan variance" and "Overlapping Allan variance" and also has 
a special information box detailing that AVAR and ADEV used mainly 
(notice standards and much of the reference material) for the 
overlapping. It also shows the inability for the 2-sample variance 
(Original Allan variance) to create smooth and good curves.

That the 2-sample variance existed and was the basis for Allan variance 
was know, but the overlapping formulation of the established AVAR and 
ADEV terms estimators is motivated and accepted for its improved 
precission was also known to me indirectly, in the sense that I saw they 
where not directly equivalent but saying the same thing, then I forgot 
about it until this mysterious OADEV/OAVAR came up recently.

There is however a huge difference between the 2-sample variance being 
the original Allan variance and being AVAR. Here I tend to rely on 
standards set by IEEE and ITU-T as they establish a defined relationship 
and I suspect some wisedom was applied in the process. Which estimator 
is we best serviced by to get defined as AVAR? They chose the 
overlapping one and it has also been the most used in theoretical 
analysis to the best of my knowledge.

The plots given in the NIST SP 1065 figure 8 is very descriptive on the 
difference.

In the end, I think we must realize that there is a distinction between the
  2
sigma  (tau)
  y

and

AVAR(tau)

The former is the Original Allan Variance where as the later is the 
Overlapping Allan Variance. It is easy to confuse the two. Maybe this is 
the fundamental problem and not the definitions themselfs.

Cheers,
Magnus

___
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] ADEV vs. OADEV

[Ulrich Bangert]

Magnus,

the paper http://tf.nist.gov/timefreq/general/tn1337/Tn121.pdf is
thought-provoking. Not that I would simply say that you are right, but
because I dont't understand some things.

> 
>  N-2m
>   ___
>   2  1   \2
> sigma  (tau) = ---   >   (x - 2x+ x )
>   y   2  /___   i+2m i+mi
> 2(N-2m)tau   i = 1
> 
> a non-interleaved variant would have to be written as 
> (assuming that m 
> divides N):
> 
>N
>- - 2
>m
> ___
>   m\  2
>    >   (x   - 2x   + x  )
>2   /___   (i+2)m (i+1)mim
> 2(N-2m)taui = 1

No discussion about that, simply correct.

However the note to figure 8 as well as the note to figure 9 cover the
non-overlapping case. Indeed formulas (8) and (10) are overlapping and
to me it is a bit kind of magic where they come from in regard to thise
two notes.

Do you agree to the fact that the ADEV for Tau = 2 s should be the same,
regardless if computed from 1 s spaced phase data or from 2 s spaced
phase data?  

Best regards
Ulrich


> -Ursprungliche Nachricht-
> Von: time-nuts-boun...@febo.com 
> [mailto:time-nuts-boun...@febo.com] Im Auftrag von Magnus Danielson
> Gesendet: Donnerstag, 22. Januar 2009 12:53
> An: Discussion of precise time and frequency measurement
> Betreff: Re: [time-nuts] ADEV vs. OADEV
> 
> 
> Ulrich,
> 
> Ulrich Bangert skrev:
> > Magnus,
> > 
> >> Actually, what you describe is the estimator formulas rather than
> >> definition. This is also targeting the fine point that I 
> am trying to 
> >> make. It's not about the basic definition, but accepted 
> convention to 
> >> denote the estimators.
> > 
> > I still do not understand the fine point! A estimator might 
> have this 
> > property and that property and may perform this task good 
> and another 
> > task bad, but at the basics we have a formula and if the formula is 
> > new or different from prior art then the thing needs an name of its 
> > own.
> 
> This part we agree on, however, you fail to see that what I 
> try to point 
> out is that you seems to have the wrong reference to start 
> with. What I 
> am trying to say is that it seems that ADEV is being used to 
> identify a 
> different estimator than I have in my old material, including the 
> articles collected in NIST TN1337, for instance "Time and Frequency 
> (Time-Domain) Characterization, Estimation, and Prediction of 
> Precision 
> Clocks and Oscillators" by David W. Allan. 
> http://tf.nist.gov/timefreq/general/tn1337/Tn121.pdf
> See page 4 and formulas 8 and 9. These are overlapping.
> 
> > In this sense the summation over square(y(i+1)-y(i)) is called the 
> > base of the "Allan variance/deviation" just for historical 
> reasons. So 
> > the name is "Allen deviation" and it is defined by its formula.
> 
> A further reference would be the IEEE standard found in
> 
> http://tf.nist.gov/timefreq/general/tn1337/Tn139.pdf
> 
> This is also overlapping (from page 2):
> 
>  N-2m
>   ___
>   2  1   \2
> sigma  (tau) = ---   >   (x - 2x+ x )
>   y   2  /___   i+2m i+mi
> 2(N-2m)tau   i = 1
> 
> a non-interleaved variant would have to be written as 
> (assuming that m 
> divides N):
> 
>N
>- - 2
>m
> ___
>   m\  2
>    >   (x   - 2x   + x  )
>2   /___   (i+2)m (i+1)mim
> 2(N-2m)taui = 1
> 
> and these obviously isn't the same, the later form skips over samples 
> not being a multiple of m.
> 
> Also, it is still overlapping in the sense that samples is 
> being re-used.
> 
> >> Disagree. The estimator formulation that is classically 
> used includes
> >> these "missed" tau0 steps that you claim that OAVAR/OADEV 
> >> includes. This is my point. Somewhere along the line the 
> established
> > ADEV estimator
> >> became the OADEV estimator and another estimator took the 
> ADEV place.
> >> This is what I oppose without a more detailed look at things.
> > 
> > The OAVAR/OADEV has this name of its own BECAUSE it includes the 
> > summands that are missed by the original AVAR/ADEV so its needs an 
> > name of its own.
> 
> I deeply disagree, see my reference to early papers (I agree not 
> original). Also, the standardised form is overlapping.
> 
> This is the reason for me to react.
> 
> >> Somewhere along the line the established ADEV estimator became the
> > OADEV estimator
> > 
> > If you had said: "The currently established estimator for 
> oscillator 
> > stability is the OADEV estimator" I would have perfectly agreed.
> 
> Well, that part was

Re: [time-nuts] ADEV vs. OADEV

[Tom Van Baak]

Hi Magnus,

I've never seen it in print either but I coined the name when I wrote
my ADEV tools. I've found a profound difference in the overlapping
form of ADEV in many cases and so I use it a lot now -- especially
when analyzing the effect of tides on precision pendulum clocks, or
other periodic effects, such as cycling A/C or diurnal effects.

However almost every technical paper in the past few decades uses
the plain old textbook non-overlapping back-to-back ADEV so my
software tools call the traditional calculation "ADEV" and I call the
overlapped version "OADEV".

An alternative was to use words "ADEV(normal)", ADEV(overlapped)"
and "ADEV(modified)" but I chose the shorter ADEV, OADEV, and
MDEV instead. "ADEV" and "MDEV" are already standard, and so
"OADEV" seemed to fit. So far no one has been confused, but I can
see your point.

See the tool page, which includes source code:
http://www.leapsecond.com/tools/adev1.htm

/tvb

- Original Message - 
From: "Magnus Danielson" 
To: "Discussion of precise time and frequency measurement" 
Sent: Wednesday, January 21, 2009 12:32 AM
Subject: [time-nuts] ADEV vs. OADEV


Hi!

I have been quite surprised to see the abbreviation OADEV appear. I
assume that this means Overlapped Allan Deviation, but this is confusing
since the Allan Deviation estimates already is overlapping. However, I
have seen that some use a non-overlapping estimator, but this type of
estimator has an unwanted filtering effect and should not be used.

If a distinction between these ADEV estimators should be used, then the
standard (overlapping) estimator should continue to be called ADEV and
the non-overlapping (back-to-back) could be called NOADEV ór whatever...

I have done a fair amount of digging around many sources around ADEV and
friends so I think I got it right.

Unless someone can give a meaningful explanation and I really expect a
good article detailing the difference and benefits...

Cheers,
Magnus

___
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] Tbolt monitor software

[Dave Ackrill]

VK3FGJM wrote:
> Hi Ed,
>
> Initially I felt that was the case, but after some brief RS-232
> measurement and the ability to see the TX/RX LED radio buttons sync with
> TX and RX data on the serial activity Monitor at the bottom left corner,
> there is nothing wrong with the RS-232 lines.
>
> Does anyone have a later version of the Trimble Thunderbolt monitor
> program or any other thoughts?
>
>
>
>   
Have you tried using portmon to see what data is beeing sent and 
received?  Of course, you would then need to either know what should be 
sent/received, or get a copy of someone elses results with a system that 
was working OK.

Dave (G0DJA)


___
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] Angus

[EWKehren]

Thanks for your offer on the AD1861. I think I found some. Tried to answer  
you direct. Address was rejected. Thanks again. Bert
**Inauguration '09:  Get complete coverage from the nation's 
capital. 
(http://news.aol.com/main/politics/inauguration?ncid=emlcntusnews0003)
___
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] Tbolt with Palisade

[Grant Hodgson]

The antenna will be mounted outside with a reasonably clear view to the 
horizon from east-south-west.  But there are times when there could be a 
lot of RF in the area - I design and build high power VHF and UHF PAs, 
amongst other things, and one of the attractions of the quality GPS 
antennas is the fact that they have a built in filter.

But I might try one of the cheap patch antennas as a start with a view 
to upgrading at some point in the future.

regards

Grant

Nigel Wrote :-
> 
> -
> Hi Grant
>  
> I think this really does depend on where you are, satellites in view etc,  
> and what level of performance you're actually looking for.
>  
> I have a few different timing antennas but have found these don't give  very 
> reliable reception indoors.
> Until I can get these mounted outdoors I have been having good results  on 
> various receivers using some small Trimble magnetic patch antennas,  
> specified 
> 26dB gain, attached to a steel plate and sitting on a shelf  inside a one 
> level 
> timber framed house on the west coast of Scotland.
> These came via a buy it now from the usual place at $21 for  10 about a year 
> ago.
>  
> Driving a pair of Thunderbolts with these and comparing them with an HP  
> 53132A counter, either one as reference and the other as input, once  locked 
> I see 
> variations of just a few places around zero in the 10th decimal  place.
> I have used this test on any two units selected from four with  consistent 
> results.
>  
> Not a very scientific test perhaps, and nothing else measured, but as  
> regards frequency at least I don't think they're suffering too much  from 
> their 
> "lesser" antennas:-)
>  
> regards
>  
> Nigel
> GM8PZR
>  
> --

___
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] GPS Time to Year?

[Brooke Clarke]

Hi:

It's my understanding that the slowest time data from GPS is the 10 bit week 
number.
How does a GPS receiver come up with the current Year?

-- 
Have Fun,

Brooke Clarke
http://www.prc68.com


___
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] GPS Time to Year?

[Tom Van Baak]

> Hi:
> 
> It's my understanding that the slowest time data from GPS is the 10 bit week 
> number.
> How does a GPS receiver come up with the current Year?
> 
> -- 
> Have Fun,
> 
> Brooke Clarke

Hi Brooke,

Good question. You are correct that this 10-bit week number
wraps once every 2^10=1024 weeks which is once about every
20 years. It's not the slowest GPS data, see below *.

Other GPS fields also wrap (more quickly) in a binary way.
Most wrist watches, for that matter, wrap 60 seconds, or 60
minutes, or 12 hours.

Note:
GPS week 0 started MJD 44244 = 1980-01-06
GPS week 0 (1024) started MJD 51412 = 1999-08-22
GPS week 0 (2048) starts MJD 58580 = 2019-04-07
GPS week 0 (3072) starts MJD 65748 = 2038-11-21

The ways GPS receivers come up with the current year are:

1) Since time moves forward only, the real year can't less than
what the year was yesterday. So when a GPS receiver on, say,
Sunday morning April 4, 2019 sees that the GPS week is now 0
while last night the week was 1023, the GPS receiver can be very
sure that the year is still 2019 and not 1980 or 1999 or 2019. As
long as a GPS receiver has NVRAM you're all set.

2) The real year can't be less than the year the GPS receiver was
manufactured. If the firmware sees GPS week 491, is has the
option to decide if that week means 0+491 (June 1989) or 1024+491
(January 2009) or 2048+491 (September 2028). With a +/- 10 year
margin the GPS receiver can pick the correct one.

On the other hand, those of us with boat anchor GPS receivers from
August 1999 know that firmware isn't always perfect.'

3) The real year can be obtained from external sources. Many GPS
receivers are now embedded into cell phone or internet-enabled
devices so obtaining a hint at the current date is easy. One may
even know the date&time well before the first GPS signal lock.

4) The real year can't have fewer leap seconds than the previous
year. So if you see that the GPS week number is 0 and the UTC
vs. TAI leap second count is around 20 seconds you know it's
GPS week 0 and year 1980. If the leap second count is closer to
32 seconds you know it's GPS week 0(1024) and so year 1999.
If the count is closer to, say, 44 seconds, then you can be safe
that it's GPS week 0(2048), or year 2019. Not perfect, but it will
work fine for our lifetimes and more.

/tvb

*) The 8-bit leap second number is slower, wrapping once every
couple of hundred years. Note also that the new GPS data format
allows for wider bit fields for this and other parameters. See also:
http://leapsecond.com/notes/gpswnro.htm






___
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] GPS Time to Year?

[M. Warner Losh]

In message: 
"Tom Van Baak"  writes:
: > Hi:
: > 
: > It's my understanding that the slowest time data from GPS is the 10 bit 
week 
: > number.
: > How does a GPS receiver come up with the current Year?
: > 
: > -- 
: > Have Fun,
: > 
: > Brooke Clarke
: 
: Hi Brooke,
: 
: Good question. You are correct that this 10-bit week number
: wraps once every 2^10=1024 weeks which is once about every
: 20 years. It's not the slowest GPS data, see below *.
: 
: Other GPS fields also wrap (more quickly) in a binary way.
: Most wrist watches, for that matter, wrap 60 seconds, or 60
: minutes, or 12 hours.
: 
: Note:
: GPS week 0 started MJD 44244 = 1980-01-06
: GPS week 0 (1024) started MJD 51412 = 1999-08-22
: GPS week 0 (2048) starts MJD 58580 = 2019-04-07
: GPS week 0 (3072) starts MJD 65748 = 2038-11-21
: 
: The ways GPS receivers come up with the current year are:
: 
: 1) Since time moves forward only, the real year can't less than
: what the year was yesterday. So when a GPS receiver on, say,
: Sunday morning April 4, 2019 sees that the GPS week is now 0
: while last night the week was 1023, the GPS receiver can be very
: sure that the year is still 2019 and not 1980 or 1999 or 2019. As
: long as a GPS receiver has NVRAM you're all set.

That works.  Even in the coldest of spares will have been on sometime
in the last 20 years, which is all that's needed to make this work...

: 2) The real year can't be less than the year the GPS receiver was
: manufactured. If the firmware sees GPS week 491, is has the
: option to decide if that week means 0+491 (June 1989) or 1024+491
: (January 2009) or 2048+491 (September 2028). With a +/- 10 year
: margin the GPS receiver can pick the correct one.
: 
: On the other hand, those of us with boat anchor GPS receivers from
: August 1999 know that firmware isn't always perfect.'

:)

: 3) The real year can be obtained from external sources. Many GPS
: receivers are now embedded into cell phone or internet-enabled
: devices so obtaining a hint at the current date is easy. One may
: even know the date&time well before the first GPS signal lock.

That's cheating...

: 4) The real year can't have fewer leap seconds than the previous
: year. So if you see that the GPS week number is 0 and the UTC
: vs. TAI leap second count is around 20 seconds you know it's
: GPS week 0 and year 1980. If the leap second count is closer to
: 32 seconds you know it's GPS week 0(1024) and so year 1999.
: If the count is closer to, say, 44 seconds, then you can be safe
: that it's GPS week 0(2048), or year 2019. Not perfect, but it will
: work fine for our lifetimes and more.

Yes.  Assuming there's no huge acceleration of the earth...  Possible,
but very unlikely...

And assuming that leap seconds continue...  If they stop, it will be
hard to know...  But if they stop, I can imagine that we could use
DUT1 that would have to be published...

: *) The 8-bit leap second number is slower, wrapping once every
: couple of hundred years. Note also that the new GPS data format
: allows for wider bit fields for this and other parameters. See also:
: http://leapsecond.com/notes/gpswnro.htm

True...

Warner

___
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] Tbolt monitor software

[Didier Juges]

I had the same problem here, and as it has been indicated, in my case it was
also the unidirectional connection (commands from the PC never made it to
the TB, so some data that is not automatically put out never got to the PC).
I had a bad pin on the serial port connector.

Check your wiring and signal levels, from the PC to the TB.

Didier KO4BB 

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of VK3FGJM
Sent: Wednesday, January 21, 2009 2:32 PM
To: time-nuts@febo.com
Subject: Re: [time-nuts] Tbolt monitor software

Hi,

Yes, I can see alarm status and changes when unplugging antenna etc.

As mentioned the unit actually works, just no data certain displayed.

Regards,

Gerald
VK3FGJM



-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of n3...@aol.com
Sent: Thursday, 22 January 2009 3:55 AM
To: time-nuts@febo.com
Subject: Re: [time-nuts] Tbolt monitor software

Did you select the right comm port? I power mine off a lot and it has always
come back.


-Original Message-
From: VK3FGJM 
To: time-nuts@febo.com
Sent: Wed, 21 Jan 2009 5:29 am
Subject: [time-nuts] Tbolt monitor software



Hi group,
 
A strange situation has led me to ask a question about the Tbolt GPSDO and
the Trimble Thunderbolt monitor s/w version 2.6.
 
While re-arrangement of the shack, it's been idle for 3 weeks, Tbolt turned
off. After turning the unit on and letting it settle some 2 hour, I
connected the monitor program and found the following that I can not explain
and correct:-

*   All SV and AMU have question marks
*   Product info has questions marks
*   the ability to see tracking status is blank.

When last used, some 2 months ago to show a friend, the relevant display
data came up, no issues. Further more, position, critical and minor alarms
are green, disciplining status section such as DAC voltage DAC value mode
and even it's 10MHz out etc etc is fine compared to my trusty Rubidium
standard.
 
Has any one seen this before and is there a setting that may have inhibited
this feature?
 
I have a screen shot, however it may be to large to attach, so let me know
if this will help, I will be glad to forward it to some one with much more
knowledge.
 
Thank you in advance.
 
Regards,
 
 
Gerald
 
VK3FGJM
 
 
 
 
 
 
 

 

___
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.
--
Message  protected by MailGuard: e-mail anti-virus, anti-spam and content
filtering.
http://www.mailguard.com.au/mg



___
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] ADEV vs. OADEV

[Magnus Danielson]

Hi Tom,

Tom Van Baak skrev:
> Hi Magnus,
> 
> I've never seen it in print either but I coined the name when I wrote
> my ADEV tools. I've found a profound difference in the overlapping
> form of ADEV in many cases and so I use it a lot now -- especially
> when analyzing the effect of tides on precision pendulum clocks, or
> other periodic effects, such as cycling A/C or diurnal effects.
> 
> However almost every technical paper in the past few decades uses
> the plain old textbook non-overlapping back-to-back ADEV so my
> software tools call the traditional calculation "ADEV" and I call the
> overlapped version "OADEV".
> 
> An alternative was to use words "ADEV(normal)", ADEV(overlapped)"
> and "ADEV(modified)" but I chose the shorter ADEV, OADEV, and
> MDEV instead. "ADEV" and "MDEV" are already standard, and so
> "OADEV" seemed to fit. So far no one has been confused, but I can
> see your point.

This at least explains the origin of the OADEV name. Many thanks.

If you look at the NIST paper that Bruce gave a link for, it makes very 
clear that the overlapping Allan deviation/variance should be used and 
that the original Allan deviation/variance should only be used "when 
necessary". The original form allows for some useful reductions in 
computation as a form of "quick" processing could be made with factor 2 
tau steps.

> See the tool page, which includes source code:
> http://www.leapsecond.com/tools/adev1.htm

I will look at it again, as I recall I have looked at it earlier.

Cheers,
Magnus

___
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] -hp- 10811 repair (Thermistor)

[Dan Rae]

The 10811-60111 that came in my 5370B counter turned out to have an open 
circuit Thermistor in it.  This is a "non-replaceable" part in theory.

However, nothing to lose, I have successfully substituted a Digikey Part 
number: 317-1371 100 kOhm 1% Thermistor ( from Cantherm, part number: 
MF51B104F3950 ).

I measured the resistance of it at the target oven temperature, working 
back from the selected value of R20 that was installed in mine, in this 
case 0 Ohms for 84C.  In fact this thermistor must be very similar to 
the one used originally, since I only needed to use a value of 110 Ohms 
for R20 to get bridge balance, instead of the short that was in there 
previously. 

Good enough for me...

Dan




___
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] -hp- 10811 repair (Thermistor)

[Bruce Griffiths]

Dan Rae wrote:
> The 10811-60111 that came in my 5370B counter turned out to have an open 
> circuit Thermistor in it.  This is a "non-replaceable" part in theory.
>
> However, nothing to lose, I have successfully substituted a Digikey Part 
> number: 317-1371 100 kOhm 1% Thermistor ( from Cantherm, part number: 
> MF51B104F3950 ).
>
> I measured the resistance of it at the target oven temperature, working 
> back from the selected value of R20 that was installed in mine, in this 
> case 0 Ohms for 84C.  In fact this thermistor must be very similar to 
> the one used originally, since I only needed to use a value of 110 Ohms 
> for R20 to get bridge balance, instead of the short that was in there 
> previously. 
>
> Good enough for me...
>
> Dan
>
>   
Dan

The real reasons that this part is labelled non replaceable are

1) its epoxied to the oven.

2) Setting R20 to the correct value actually requires plotting the OCXO
frequency vs R20 and selecting R20 so that the OCXO frequency is located
at the stationary point on the frequency vs R20 value plot. This
requires a high resolution frequency measurement setup with a highly
stable reference and takes considerable time as one has to allow the
oven temperature to settle between adjustments to R20. Drift due to
aging and ambient temperature changes limit the accuracy with which the
OCXO turnover temperature can be achieved.



Bruce




___
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] -hp- 10811 repair (Thermistor)

[Rick Karlquist]

Bruce Griffiths wrote:
>>
> Dan
>
> The real reasons that this part is labelled non replaceable are
>
> 1) its epoxied to the oven.
>
> 2) Setting R20 to the correct value actually requires plotting the OCXO
> frequency vs R20 and selecting R20 so that the OCXO frequency is located
> at the stationary point on the frequency vs R20 value plot. This
> requires a high resolution frequency measurement setup with a highly
> stable reference and takes considerable time as one has to allow the
> oven temperature to settle between adjustments to R20. Drift due to
> aging and ambient temperature changes limit the accuracy with which the
> OCXO turnover temperature can be achieved.
>
> Bruce

That's news to me.  AFAIK, the individual crystal has a known oven
set point that is determined in the crystal fab.  R20 is selected
to achieve this set point.  What Dan did is exactly right, IMHO.
BTW, many 10811 crystals did not have a turnover temperature as
you imply.  They simply had a point of minimum (not zero) tempco
where there was an inflection point (2nd derivative is zero)
but 1st derivative is not zero.  This is well established SC
cut theory ("true" SC cuts, that is).  The stability of the oven
set point was quite adequate in terms of the overall 10811 error
budget.  Most the tempco is due to the electronics pulling the
crystal, as detailed in my paper on the E1938 oscillator.

When you install the new thermistor, try to duplicate the lead
dress of the old one.  That was supposed to mitigate against
heat running up the leads and corrupting the thermistor.

Rick Karlquist, N6RK
R&D engineer, HP Santa Clara Division 1979-1998


___
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] -hp- 10811 repair (Thermistor)

[Bruce Griffiths]

Rick Karlquist wrote:
> Bruce Griffiths wrote:
>   
>> Dan
>>
>> The real reasons that this part is labelled non replaceable are
>>
>> 1) its epoxied to the oven.
>>
>> 2) Setting R20 to the correct value actually requires plotting the OCXO
>> frequency vs R20 and selecting R20 so that the OCXO frequency is located
>> at the stationary point on the frequency vs R20 value plot. This
>> requires a high resolution frequency measurement setup with a highly
>> stable reference and takes considerable time as one has to allow the
>> oven temperature to settle between adjustments to R20. Drift due to
>> aging and ambient temperature changes limit the accuracy with which the
>> OCXO turnover temperature can be achieved.
>>
>> Bruce
>> 
>
> That's news to me.  AFAIK, the individual crystal has a known oven
> set point that is determined in the crystal fab.  R20 is selected
> to achieve this set point.  What Dan did is exactly right, IMHO.
> BTW, many 10811 crystals did not have a turnover temperature as
> you imply.  They simply had a point of minimum (not zero) tempco
> where there was an inflection point (2nd derivative is zero)
> but 1st derivative is not zero.  This is well established SC
> cut theory ("true" SC cuts, that is).  The stability of the oven
> set point was quite adequate in terms of the overall 10811 error
> budget.  Most the tempco is due to the electronics pulling the
> crystal, as detailed in my paper on the E1938 oscillator.
>
> When you install the new thermistor, try to duplicate the lead
> dress of the old one.  That was supposed to mitigate against
> heat running up the leads and corrupting the thermistor.
>
> Rick Karlquist, N6RK
> R&D engineer, HP Santa Clara Division 1979-1998
>
>
>
>   
Rick

Sorry, as soon as I posted the above, I realised I was actually
referring to the older 10544A/B, etc., OCXOs which did require such an
involved oven tuning procedure.
Meanwhile, before posting a correction I was trying to find data on the
oven setpoint temperature tolerance.

The relevant HP Journal with an article on the HP10811A is:
http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1981-03.pdf

One concern is:
How accurate does one' thermometer which one uses to calibrate the
thermistor bridge setpoint have to be?

Bruce


___
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] ADEV vs. OADEV

[Magnus Danielson]

Ulrich,

Ulrich Bangert skrev:
> Magnus,
> 
> the paper http://tf.nist.gov/timefreq/general/tn1337/Tn121.pdf is
> thought-provoking. Not that I would simply say that you are right, but
> because I dont't understand some things.

Well, I was taking on this thread in hope to spread some light and I was 
not sure who would learn what. I think I have learned a few things, but 
so far it seems my view on things have not changed significantly.

I think I can explain some things.

>>  N-2m
>>   ___
>>   2  1   \2
>> sigma  (tau) = ---   >   (x - 2x+ x )
>>   y   2  /___   i+2m i+mi
>> 2(N-2m)tau   i = 1
>>
>> a non-interleaved variant would have to be written as 
>> (assuming that m 
>> divides N):
>>
>>N
>>- - 2
>>m
>> ___
>>   m\  2
>>    >   (x   - 2x   + x  )
>>2   /___   (i+2)m (i+1)mim
>> 2(N-2m)taui = 1
> 
> No discussion about that, simply correct.

I thought we would agree on those things.

> However the note to figure 8 as well as the note to figure 9 cover the
> non-overlapping case. Indeed formulas (8) and (10) are overlapping and
> to me it is a bit kind of magic where they come from in regard to thise
> two notes.
> 
> Do you agree to the fact that the ADEV for Tau = 2 s should be the same,
> regardless if computed from 1 s spaced phase data or from 2 s spaced
> phase data?  

In the ideal world... yes... but in the real world limits hits us 
differently. The definition only says that it is an average, not how an 
average should be formed over samples where tau != tau0. A 
straightforward interpretation will skip samples, but require a much 
longer sequence and we must recall it is just one of several estimators.
Let's make this clear, there is no way to get the real Allan variation, 
we can only get estimates and choose among estimators. This becomes 
clear as one reads the Bregni book or look at the ITU-T G.810 standard 
(get it, it's available for free download as PDF from ITU).

Now, with this in mind, the "Overlapping Allan Variance" was chosen as 
the estimator of choice for the AVAR(n*tau0), and for good reasons.

One point of confusion is that AVAR(tau) should not be directly 
interpreted as Allan Variance in general, it is actually already defined 
and reserved to mean a chosen Allan Variance estimator. This is an 
important point when comparing oscillators and systems such as a 
standard for measuring oscillators or telecom standards. For other uses 
other estimators may be used, but for precision use the overlapped 
estimator has been chosen as it better uses the measurement series.

So, to sum things up. You can't get the "propper" Allan variance. You 
can only make estimates. The "Original Allan Variance" is a one of many 
estimators but to attain good quality it needs a long time-series. The 
"Overlapping Allan Variance" is another estimator which has improved 
quality for a limitied time series as compared to the "Original Allan 
Variance". The terms AVAR and ADEV as specified in several standards 
denotes an estimator which is the overlapping estimator, not just any 
Allan variance estimator. Notice also that telecom standards require 
tau0 to be less than lowest tau, so tau/tau0 is always > 1 as this 
ensures quality and allows for the specified highpass filter of 10 Hz, 
which is also being debated as being meaningfull or harmfull (see Bregni).

There is still a few lessons to learn on this, but thats about it I think.

So no, 1 s data and 2 s data does not necessarily give the same result, 
it depends on which estimator you are using, because you will be using 
an estimator regardless of what you think is "right". Thus, if you feel 
"Original Allan variance" is right for you, you are in your right to use 
it, but it is not the "propper" one to use, and do not confuse it with 
AVAR which is a dedicated name for the "Overlapping Allan Variance".

Cheers,
Magnus

___
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] -hp- 10811 repair (Thermistor)

[Dan Rae]

Bruce Griffiths wrote:
> Meanwhile, before posting a correction I was trying to find data on the
> oven setpoint temperature tolerance.
>
> The relevant HP Journal with an article on the HP10811A is:
> http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1981-03.pdf
>
> One concern is:
> How accurate does one' thermometer which one uses to calibrate the
> thermistor bridge setpoint have to be?
>
> Bruce
>
>
>   
Bruce, I'm guessing that since they quote values of R20 in the manual in 
intervals of 0.1 Degrees, that is how close they got.  Except oddly 
enough for 83.9 and 84.0 degrees, which are the same, but shouldn't be, 
IMHO.  I don't claim to have got that close in my thermistor tests, 
maybe 0.5 degrees using a lab type mercury thermometer.  But my original 
point is still valid: I now have a working oven.  In my case I will use 
an external reference for the 5370B so it is kind of not that important 
anyway...

Dan


___
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] GPS Time to Year?

[Magnus Danielson]

Tom Van Baak skrev:
>> Hi:
>>
>> It's my understanding that the slowest time data from GPS is the 10 bit week 
>> number.
>> How does a GPS receiver come up with the current Year?
>>
>> -- 
>> Have Fun,
>>
>> Brooke Clarke
> 
> Hi Brooke,
> 
> Good question. You are correct that this 10-bit week number
> wraps once every 2^10=1024 weeks which is once about every
> 20 years. It's not the slowest GPS data, see below *.
> 
> Other GPS fields also wrap (more quickly) in a binary way.
> Most wrist watches, for that matter, wrap 60 seconds, or 60
> minutes, or 12 hours.
> 
> Note:
> GPS week 0 started MJD 44244 = 1980-01-06
> GPS week 0 (1024) started MJD 51412 = 1999-08-22
> GPS week 0 (2048) starts MJD 58580 = 2019-04-07
> GPS week 0 (3072) starts MJD 65748 = 2038-11-21
> 
> The ways GPS receivers come up with the current year are:
> 
> 1) Since time moves forward only, the real year can't less than
> what the year was yesterday. So when a GPS receiver on, say,
> Sunday morning April 4, 2019 sees that the GPS week is now 0
> while last night the week was 1023, the GPS receiver can be very
> sure that the year is still 2019 and not 1980 or 1999 or 2019. As
> long as a GPS receiver has NVRAM you're all set.
> 
> 2) The real year can't be less than the year the GPS receiver was
> manufactured. If the firmware sees GPS week 491, is has the
> option to decide if that week means 0+491 (June 1989) or 1024+491
> (January 2009) or 2048+491 (September 2028). With a +/- 10 year
> margin the GPS receiver can pick the correct one.
> 
> On the other hand, those of us with boat anchor GPS receivers from
> August 1999 know that firmware isn't always perfect.'
> 
> 3) The real year can be obtained from external sources. Many GPS
> receivers are now embedded into cell phone or internet-enabled
> devices so obtaining a hint at the current date is easy. One may
> even know the date&time well before the first GPS signal lock.
> 
> 4) The real year can't have fewer leap seconds than the previous
> year. So if you see that the GPS week number is 0 and the UTC
> vs. TAI leap second count is around 20 seconds you know it's
> GPS week 0 and year 1980. If the leap second count is closer to
> 32 seconds you know it's GPS week 0(1024) and so year 1999.
> If the count is closer to, say, 44 seconds, then you can be safe
> that it's GPS week 0(2048), or year 2019. Not perfect, but it will
> work fine for our lifetimes and more.

You could use leap second counter as a rought estimate to get the right 
1024 week interval. Naturally, if leap seconds is no longer inserted 
that would break that algorithm. I wonder if this hint have been used by 
any receivers.. :)

You can also use a CMOS backed clock, which many receivers have or there 
is an external option for a backup battery. That hint is usually valid 
enought. Also, the CMOS clock can be maintained when running. Storing 
last seen leap second and week number along with date at time of storage 
in the CMOS backup memory could also be usefull.

Cheers,
Magnus

___
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] ADEV vs. OADEV

[Tom Van Baak]

> One point of confusion is that AVAR(tau) should not be directly 
> interpreted as Allan Variance in general, it is actually already defined 
> and reserved to mean a chosen Allan Variance estimator. This is an 

Sorry if I'm jumping into this thread late, but this statement
confuses me. Since when is "AVAR" not simply short-hand
for "Allan Variance"?

Next you'll tell me SDEV isn't Standard Deviation because some
self-important standards organization decided otherwise.

/tvb


___
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] -hp- 10811 repair (Thermistor)

[Bruce Griffiths]

Dan Rae wrote:
> Bruce Griffiths wrote:
>   
>> Meanwhile, before posting a correction I was trying to find data on the
>> oven setpoint temperature tolerance.
>>
>> The relevant HP Journal with an article on the HP10811A is:
>> http://www.hpl.hp.com/hpjournal/pdfs/IssuePDFs/1981-03.pdf
>>
>> One concern is:
>> How accurate does one' thermometer which one uses to calibrate the
>> thermistor bridge setpoint have to be?
>>
>> Bruce
>>
>>
>>   
>> 
> Bruce, I'm guessing that since they quote values of R20 in the manual in 
> intervals of 0.1 Degrees, that is how close they got.  Except oddly 
> enough for 83.9 and 84.0 degrees, which are the same, but shouldn't be, 
> IMHO.  I don't claim to have got that close in my thermistor tests, 
> maybe 0.5 degrees using a lab type mercury thermometer.  But my original 
> point is still valid: I now have a working oven.  In my case I will use 
> an external reference for the 5370B so it is kind of not that important 
> anyway...
>
> Dan
>
>
>   
Dan

Achieving 0.1C accuracy with a mercury in glass thermometer can be
tricky even with a calibrated one reading to 0.1C.

Some of the problems are:

1) Thermometer calibration accuracy

2) Immersion length correction - the indicated temperature depends on
the temperature distribution over the entire length of the glass column.
The thermometer may or may not have been calibrated fully immersed

3) Glass column hystereisis - correction depends on thermal history and
is smaller for some glass types than others.

4) Ensuring that the thermistor and the thermometer are at the same
temperature - perhaps the most important as internal dissipation in the
thermistor will raise its temperature above its ambient. Using a metal
block immersed in a liquid with both the thermometer and the thermistor
installed in wells within the metal block is one of the better ways.

In many ways its easier to use a themometer with an electrical output
such as a calibrated RTD, PRT or SPRT.
Commonly available RTD s are capable of maintaining calibration to much
better than 0.1C for very long periods if they aren't thermally abused.

Another possibility is t use a noise thermometer as all one needs to do
is measure the resistance and the resultant Johnson noise.
No calibration is required other than determining the equivalent noise
bandwidth of the measurement system.

Bruce

___
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] ADEV vs. OADEV

[Bruce Griffiths]

Tom Van Baak wrote:
>> One point of confusion is that AVAR(tau) should not be directly 
>> interpreted as Allan Variance in general, it is actually already defined 
>> and reserved to mean a chosen Allan Variance estimator. This is an 
>> 
>
> Sorry if I'm jumping into this thread late, but this statement
> confuses me. Since when is "AVAR" not simply short-hand
> for "Allan Variance"?
>
> Next you'll tell me SDEV isn't Standard Deviation because some
> self-important standards organization decided otherwise.
>
> /tvb
>
>
>   
Tom

Perhaps the real confusion is between the actual definition of the Allan
variance etc, and the various estimators of the Allan variance etc.

For example:
The so called classical Allan variance is nothing more than an estimator
of the Allan variance.
The so called overlapped Allan variance is a better (more accurate)
estimator of the Allan variance.

Bruce

___
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] ADEV vs. OADEV

[Magnus Danielson]

Tom Van Baak skrev:
>> One point of confusion is that AVAR(tau) should not be directly 
>> interpreted as Allan Variance in general, it is actually already defined 
>> and reserved to mean a chosen Allan Variance estimator. This is an 
> 
> Sorry if I'm jumping into this thread late, but this statement
> confuses me.

Feel free to join in...

> Since when is "AVAR" not simply short-hand
> for "Allan Variance"?

Good question. My point being that yes... AVAR is a handy short-hand for 
Allan Deviation, but it is also actually a standardised quantity and 
several standards actually define it consistently as a particular 
estimator. It's a good estimator for being of the Allan Variance family 
and CPU-cycles should not prohibit us from using it.

Recall that they are all estimators. I think this is a crutial point to 
learn really. Once one has accepted that fact, then taking a look at 
which estimator serves me the best becomes the issue of interest, not 
"which is the right one?" which is actually an incorrect question in 
this context.

So, feel free to short-hand Allan Variance as AVAR, but there are 
context in which this is going to be interpreted as being the 
overlapping Allan variance estimator and not any other estimator, and 
hence using that short-hand can be ambiguous. If we want an unambiguous 
use of AVAR, do not use AVAR as short-hand for Allan Variance when using 
other estimators than the overlapping one. Do as you please, but now you 
are aware of the issue.

Also, look at the NIST SP 1065 for instance, where it is clearly 
indicated that the "original" is being superseded in most practical use 
for the benefit of the overlapping, giving improved confidence 
intervals. Also, Modified Allan Variance and Theo should be considered 
as better alternatives.

The SP 1065 should be a good read for many, as it gives a modern 
overview and also addresses several practical implementational issues 
such as software test-sequences etc. The TN 1337 is a more classic view 
and collection of articles.

So... we could argue all we want about "which is the correct Allan 
Variance" but it doesn't really help. The original estimator is flawed. 
the overlapping estimator improves confidence and the Theo family should 
provide even better results.

> Next you'll tell me SDEV isn't Standard Deviation because some
> self-important standards organization decided otherwise.

I could probably find a standard defining it to something completely 
different and totally out of context which would not help.

But the reaction is natural, but one must realize that there is not real 
"right" here, so sometimes putting down the foot and say "this is what 
we define it to be" is needed so that everyone at least do it according 
to the same procedures and with known errors... until you realize that 
you need something better and move over to some other measurement which 
you define in a similar fashion. It's like say the meter standard. "This 
is the meter... until we say something different".

Cheers,
Magnus

___
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] -hp- 10811 repair (Thermistor)

[Rick Karlquist]

Bruce Griffiths wrote:
>> One concern is:
> How accurate does one' thermometer which one uses to calibrate the
> thermistor bridge setpoint have to be?
>
> Bruce

The thermistors HP used were quite accurate, so you didn't
need a thermometer.  You just calculated the correct resistor
value for the temperature you wanted.  The characterization of
the crystals themselves was done in an oil bath with fairly
precise thermometers, however, the accuracy only needed to
be on the order of a degree C or so.  This is because of the
very broad peak, or plateau.  It was easy to get the crystal
temperature set correctly so that the electronics dominated.
The fact that the electronics were not so great helped.

Rick


___
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] Tbolt monitor software

[VK3FGJM]

Hi Didier and others,

Thanks for the feedback.

Others Thunderbolt owners may want to check there soldering also. Prior
to this error I has not opened the unit, did not see a need, although my
symptom did not pop it's head up at first, to took some 4-5 months to
manifest.

As previously mentioned, it's now running perfect, but it required me to
completely remove the MAX232, clean all pins and reflow.

Regards

Gerald

VK3FGJM 



 

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Didier Juges
Sent: Friday, 23 January 2009 8:45 AM
To: 'Discussion of precise time and frequency measurement'
Subject: Re: [time-nuts] Tbolt monitor software

I had the same problem here, and as it has been indicated, in my case it
was also the unidirectional connection (commands from the PC never made
it to the TB, so some data that is not automatically put out never got
to the PC).
I had a bad pin on the serial port connector.

Check your wiring and signal levels, from the PC to the TB.

Didier KO4BB 

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of VK3FGJM
Sent: Wednesday, January 21, 2009 2:32 PM
To: time-nuts@febo.com
Subject: Re: [time-nuts] Tbolt monitor software

Hi,

Yes, I can see alarm status and changes when unplugging antenna etc.

As mentioned the unit actually works, just no data certain displayed.

Regards,

Gerald
VK3FGJM



-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of n3...@aol.com
Sent: Thursday, 22 January 2009 3:55 AM
To: time-nuts@febo.com
Subject: Re: [time-nuts] Tbolt monitor software

Did you select the right comm port? I power mine off a lot and it has
always come back.


-Original Message-
From: VK3FGJM 
To: time-nuts@febo.com
Sent: Wed, 21 Jan 2009 5:29 am
Subject: [time-nuts] Tbolt monitor software



Hi group,
 
A strange situation has led me to ask a question about the Tbolt GPSDO
and the Trimble Thunderbolt monitor s/w version 2.6.
 
While re-arrangement of the shack, it's been idle for 3 weeks, Tbolt
turned off. After turning the unit on and letting it settle some 2 hour,
I connected the monitor program and found the following that I can not
explain and correct:-

*   All SV and AMU have question marks
*   Product info has questions marks
*   the ability to see tracking status is blank.

When last used, some 2 months ago to show a friend, the relevant display
data came up, no issues. Further more, position, critical and minor
alarms are green, disciplining status section such as DAC voltage DAC
value mode and even it's 10MHz out etc etc is fine compared to my trusty
Rubidium standard.
 
Has any one seen this before and is there a setting that may have
inhibited this feature?
 
I have a screen shot, however it may be to large to attach, so let me
know if this will help, I will be glad to forward it to some one with
much more knowledge.
 
Thank you in advance.
 
Regards,
 
 
Gerald
 
VK3FGJM
 
 
 
 
 
 
 

 

___
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.
--
Message  protected by MailGuard: e-mail anti-virus, anti-spam and
content filtering.
http://www.mailguard.com.au/mg



___
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] GPS Time to Year?

[Hal Murray]

A nice list.  Thanks.

> One may even know the date&time well before the first GPS signal lock.

Be careful with that one.

Time is used for all sorts of things, some critical and some mostly a 
convenience.

Time is often central in network security.  That often turns into an 
interesting tangle.  How do you securely set the time when your security 
stuff doesn't work yet because you don't know the time?

Anyway, setting the time depending on the time that you already "know" has 
similar problems.  It's probably a good approach, but may not be good enough. 
 Where did you get that time from?  Somebody has to think about the big 
picture and the costs/risks of getting it wrong.


Another place where you can get a sanity check on the time is from the file 
system.

If you are running an embedded application out of ROM/Flash or off a CD, 
that's the time of manufacturer.  If you are running on an OS, it's probably 
the time some file was recently written, but that assumes the system time was 
correct.



-- 
These are my opinions, not necessarily my employer's.  I hate spam.




___
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] ADEV vs. OADEV

[Bruce Griffiths]

Magnus Danielson wrote:
> Tom Van Baak skrev:
>   
>>> One point of confusion is that AVAR(tau) should not be directly 
>>> interpreted as Allan Variance in general, it is actually already defined 
>>> and reserved to mean a chosen Allan Variance estimator. This is an 
>>>   
>> Sorry if I'm jumping into this thread late, but this statement
>> confuses me.
>> 
>
> Feel free to join in...
>
>   
>> Since when is "AVAR" not simply short-hand
>> for "Allan Variance"?
>> 
>
> Good question. My point being that yes... AVAR is a handy short-hand for 
> Allan Deviation, but it is also actually a standardised quantity and 
> several standards actually define it consistently as a particular 
> estimator. It's a good estimator for being of the Allan Variance family 
> and CPU-cycles should not prohibit us from using it.
>
> Recall that they are all estimators. I think this is a crutial point to 
> learn really. Once one has accepted that fact, then taking a look at 
> which estimator serves me the best becomes the issue of interest, not 
> "which is the right one?" which is actually an incorrect question in 
> this context.
>
> So, feel free to short-hand Allan Variance as AVAR, but there are 
> context in which this is going to be interpreted as being the 
> overlapping Allan variance estimator and not any other estimator, and 
> hence using that short-hand can be ambiguous. If we want an unambiguous 
> use of AVAR, do not use AVAR as short-hand for Allan Variance when using 
> other estimators than the overlapping one. Do as you please, but now you 
> are aware of the issue.
>
> Also, look at the NIST SP 1065 for instance, where it is clearly 
> indicated that the "original" is being superseded in most practical use 
> for the benefit of the overlapping, giving improved confidence 
> intervals. Also, Modified Allan Variance and Theo should be considered 
> as better alternatives.
>
> The SP 1065 should be a good read for many, as it gives a modern 
> overview and also addresses several practical implementational issues 
> such as software test-sequences etc. The TN 1337 is a more classic view 
> and collection of articles.
>
> So... we could argue all we want about "which is the correct Allan 
> Variance" but it doesn't really help. The original estimator is flawed. 
> the overlapping estimator improves confidence and the Theo family should 
> provide even better results.
>
>   
>> Next you'll tell me SDEV isn't Standard Deviation because some
>> self-important standards organization decided otherwise.
>> 
>
> I could probably find a standard defining it to something completely 
> different and totally out of context which would not help.
>
> But the reaction is natural, but one must realize that there is not real 
> "right" here, so sometimes putting down the foot and say "this is what 
> we define it to be" is needed so that everyone at least do it according 
> to the same procedures and with known errors... until you realize that 
> you need something better and move over to some other measurement which 
> you define in a similar fashion. It's like say the meter standard. "This 
> is the meter... until we say something different".
>
> Cheers,
> Magnus
>
>   
Hej Magnus

The major failing of SP1065 is that it doesn't explicitly make it clear
that all the quantities for which its gives formulae are merely
estimators of an underlying statistical property of the frequency source.

For example using the terminology of SP1065:

Classical AVAR
Overlapped AVAR
TOTVAR
MTOT

are all estimators of the Allan variance.
They all have the same Expectation value but the confidence limits for
each of these estimators are different.

MVAR
MTOT

are both estimators of the Modified Allan variance.
They both have the same Expectation value but the confidence limits for
each of these estimators are different.

Bruce

___
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] ADEV vs. OADEV

[Magnus Danielson]

Hej Bruce,

> Hej Magnus
> 
> The major failing of SP1065 is that it doesn't explicitly make it clear
> that all the quantities for which its gives formulae are merely
> estimators of an underlying statistical property of the frequency source.

I agree. Other sources is much more careful on this point. SP1065 gives 
a great overview, but should not be mistaken as a definite reference in 
all aspects.

Bregni for instance presents the definitions in one place (Chapter 5) 
and estimators in another (Chapter 7). G.810 does the same for instance.

It should be clear that the definition of Allan variance is actually not 
on two samples of frequency, they are measures of two average frequency 
measures, which implies an tau-long integral over v(t) for two 
end-to-end ranges. Using samples of frequency or samples of time is 
doing an estimation or approximation to the actual definition. I don't 
recall which paper wrote it, but it was pointed out that the average 
line over the y is often missed, but it you look in early papers these 
are found and uses, such as the tn121 paper i TN1337.

It takes the reading of alot of papers and books to really make the 
picture stand out as subtle points is pointed out here and there. I just 
learned that J. J. Snyder is to take credit for the improved overlapped 
Allan variance estimator and that this became an inspiration for the 
modified Allan variation.

> For example using the terminology of SP1065:
> 
> Classical AVAR
> Overlapped AVAR
> TOTVAR
> MTOT
> 
> are all estimators of the Allan variance.

You missed Theo1, just read the beginning of 5.2.15 and the info-box 
there. Then the followup is TheoH in 5.2.16.

> They all have the same Expectation value but the confidence limits for
> each of these estimators are different.
> 
> MVAR
> MTOT
> 
> are both estimators of the Modified Allan variance.
> They both have the same Expectation value but the confidence limits for
> each of these estimators are different.

Agree.

In the end, while I have only very quickly browsed through the material 
and picked up some new, I feel it is time to read it through properly 
again. I think I have learned a few finer points in the last days and 
when seeing it with fresh eyes I think I will appreciate many of the 
comments better.

Cheers,
Magnus

___
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] ADEV vs. OADEV

[Tom Van Baak]

Yes, it is interesting that SP1065 uses words like:
  "original Allan" (page 2, 3, 14)
  "classic Allan variance" (page 11)
  "normal Allan variance" (page 16)
as a way to distinguish the non- from the overlapping version.
We could throw in "traditional", "simple", "back-to-back", "plain".

I agree with the author (W.Riley) that these days ADEV is
moving towards being interpreted, and more frequently
implemented, as the overlapping variety, but that might take
a generation to sink in.

I mean, even his own Stable32 program calls the default
2-sample variance "Allan" and if you want the overlapped
version you have to click on "Overlapping Allan".

So you see why that Allan tool of mine labels the columns
adev and oadev? At least there's no ambiguity that way.

I should also point out that not all systems can calculate
overlapping Allan statistics. Some realtime analyzers, even
the fancy TSC boxes for example, cannot do full overlapping
(because you need access to the entire data set for that).
So plain adev is not dead yet.

/tvb


___
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] ADEV vs. OADEV

[Bruce Griffiths]

Bruce Griffiths wrote:
> Magnus Danielson wrote:
>   
>> Tom Van Baak skrev:
>>   
>> 
 One point of confusion is that AVAR(tau) should not be directly 
 interpreted as Allan Variance in general, it is actually already defined 
 and reserved to mean a chosen Allan Variance estimator. This is an 
   
 
>>> Sorry if I'm jumping into this thread late, but this statement
>>> confuses me.
>>> 
>>>   
>> Feel free to join in...
>>
>>   
>> 
>>> Since when is "AVAR" not simply short-hand
>>> for "Allan Variance"?
>>> 
>>>   
>> Good question. My point being that yes... AVAR is a handy short-hand for 
>> Allan Deviation, but it is also actually a standardised quantity and 
>> several standards actually define it consistently as a particular 
>> estimator. It's a good estimator for being of the Allan Variance family 
>> and CPU-cycles should not prohibit us from using it.
>>
>> Recall that they are all estimators. I think this is a crutial point to 
>> learn really. Once one has accepted that fact, then taking a look at 
>> which estimator serves me the best becomes the issue of interest, not 
>> "which is the right one?" which is actually an incorrect question in 
>> this context.
>>
>> So, feel free to short-hand Allan Variance as AVAR, but there are 
>> context in which this is going to be interpreted as being the 
>> overlapping Allan variance estimator and not any other estimator, and 
>> hence using that short-hand can be ambiguous. If we want an unambiguous 
>> use of AVAR, do not use AVAR as short-hand for Allan Variance when using 
>> other estimators than the overlapping one. Do as you please, but now you 
>> are aware of the issue.
>>
>> Also, look at the NIST SP 1065 for instance, where it is clearly 
>> indicated that the "original" is being superseded in most practical use 
>> for the benefit of the overlapping, giving improved confidence 
>> intervals. Also, Modified Allan Variance and Theo should be considered 
>> as better alternatives.
>>
>> The SP 1065 should be a good read for many, as it gives a modern 
>> overview and also addresses several practical implementational issues 
>> such as software test-sequences etc. The TN 1337 is a more classic view 
>> and collection of articles.
>>
>> So... we could argue all we want about "which is the correct Allan 
>> Variance" but it doesn't really help. The original estimator is flawed. 
>> the overlapping estimator improves confidence and the Theo family should 
>> provide even better results.
>>
>>   
>> 
>>> Next you'll tell me SDEV isn't Standard Deviation because some
>>> self-important standards organization decided otherwise.
>>> 
>>>   
>> I could probably find a standard defining it to something completely 
>> different and totally out of context which would not help.
>>
>> But the reaction is natural, but one must realize that there is not real 
>> "right" here, so sometimes putting down the foot and say "this is what 
>> we define it to be" is needed so that everyone at least do it according 
>> to the same procedures and with known errors... until you realize that 
>> you need something better and move over to some other measurement which 
>> you define in a similar fashion. It's like say the meter standard. "This 
>> is the meter... until we say something different".
>>
>> Cheers,
>> Magnus
>>
>>   
>> 
> Hej Magnus
>
> The major failing of SP1065 is that it doesn't explicitly make it clear
> that all the quantities for which its gives formulae are merely
> estimators of an underlying statistical property of the frequency source.
>
> For example using the terminology of SP1065:
>
> Classical AVAR
> Overlapped AVAR
> TOTVAR
> MTOT
>
> are all estimators of the Allan variance.
> They all have the same Expectation value but the confidence limits for
> each of these estimators are different.
>
> MVAR
> MTOT
>
> are both estimators of the Modified Allan variance.
> They both have the same Expectation value but the confidence limits for
> each of these estimators are different.
>
> Bruce
>
>   
Addendum:

There would appear to be only 3 underlying frequency stability
statistics of interest in this paper:

1) Allan variance

2) Modified Allan variance

3) Hadamard variance

Each of which has a different phase transfer function.

All other statistical quantities related to frequency stability in this
paper are actually estimators of one of the above underlying statistics
Each estimator has different confidence limits and a different bias
function which may depend on phase noise type.
Correction for the underlying bias of each estimator is desirable before
plotting the results.
Confidence limits are also useful.

Bruce

___
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] ADEV vs. OADEV

[Bruce Griffiths]

Tom Van Baak wrote:
> Yes, it is interesting that SP1065 uses words like:
>   "original Allan" (page 2, 3, 14)
>   "classic Allan variance" (page 11)
>   "normal Allan variance" (page 16)
> as a way to distinguish the non- from the overlapping version.
> We could throw in "traditional", "simple", "back-to-back", "plain".
>
> I agree with the author (W.Riley) that these days ADEV is
> moving towards being interpreted, and more frequently
> implemented, as the overlapping variety, but that might take
> a generation to sink in.
>
> I mean, even his own Stable32 program calls the default
> 2-sample variance "Allan" and if you want the overlapped
> version you have to click on "Overlapping Allan".
>
> So you see why that Allan tool of mine labels the columns
> adev and oadev? At least there's no ambiguity that way.
>
> I should also point out that not all systems can calculate
> overlapping Allan statistics. Some realtime analyzers, even
> the fancy TSC boxes for example, cannot do full overlapping
> (because you need access to the entire data set for that).
> So plain adev is not dead yet.
>
> /tvb
>
>
>   
Tom

Its important to realise these calculated statistics are all estimators
of the underlying Allan variance.
Thus it is important to assign unique unambiguous names  to each of them
so that some idea of their region of reasonable accuracy and perhaps
their confidence limits can be estimated.

Thus for example:
AVAR doesn't actually denote the underlying Allan variance but rather a
particular algorithm used to estimate it from the data.

OAVAR denotes another algorithm for estimating the underlying Allan
variance from the data

TOTVAR, THEO1 and THEOH denote other algorithms that can be used to
estimate the underlying Allan variance from the data.

Some of these algorithms produce biased estimates of the underlying
Allan variance so correction for such bias is usually necessary.

Bruce

___
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] ADEV vs. OADEV

[Magnus Danielson]

Tom Van Baak skrev:
> Yes, it is interesting that SP1065 uses words like:
>   "original Allan" (page 2, 3, 14)
>   "classic Allan variance" (page 11)
>   "normal Allan variance" (page 16)
> as a way to distinguish the non- from the overlapping version.
> We could throw in "traditional", "simple", "back-to-back", "plain".

Depending on the context of course.

> I agree with the author (W.Riley) that these days ADEV is
> moving towards being interpreted, and more frequently
> implemented, as the overlapping variety, but that might take
> a generation to sink in.

Maybe. The J.J. Snyder article is from 1980 where as the Allan deviation 
is from 1966. It's only about half-a-generation. Maybe about the age 
difference of us two...

> I mean, even his own Stable32 program calls the default
> 2-sample variance "Allan" and if you want the overlapped
> version you have to click on "Overlapping Allan".

This could indicate where he is on the issue, but does not really 
resolve the question.

> So you see why that Allan tool of mine labels the columns
> adev and oadev? At least there's no ambiguity that way.

That I agree with, in your context you certainly avoided ambiguity.

> I should also point out that not all systems can calculate
> overlapping Allan statistics. Some realtime analyzers, even
> the fancy TSC boxes for example, cannot do full overlapping
> (because you need access to the entire data set for that).
> So plain adev is not dead yet.

Actually... no. I have looked at this problem and you can calculate the 
overlapping Allan variance in real time with only the 2m tau of historic 
x values in memory. It is fairly trivial to implement out of the 
definition. You don't need the full data-set. However, you would need 
multiple accumulators for different choices of m. I can see how this 
might not is imminently apparent, but given the clues given I think it 
will become visible.

The trickier part is to do drift rate compensation without having access 
to the full dataset. For Allan variance this is possible with a few 
tricks out of the statistics book.

Using such an approach, you could see your AVAR/ADEV develop as the time 
series is consumed and be able to see how it stabilizes as you measure 
more and more. I think it is a rather pleasing approach.

What I really need to learn is to calculate the confidence intervals. It 
keep nagging me all the time.

Cheers,
Magnus

___
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] ADEV vs. OADEV

[Magnus Danielson]

Bruce,

> Tom
> 
> Its important to realise these calculated statistics are all estimators
> of the underlying Allan variance.
> Thus it is important to assign unique unambiguous names  to each of them
> so that some idea of their region of reasonable accuracy and perhaps
> their confidence limits can be estimated.

It should be recalled that AVAR is actually not necessarilly a name as 
such but short-hand. To help making the issue complex, AVAR has been 
given as a name to denote a particular algorithm, just as MADEV, TDEV 
etc. Even if one can argue that they have these meanings within a 
specific context, the ambiguity problem is there as it makes it harder 
to compare results.

> Thus for example:
> AVAR doesn't actually denote the underlying Allan variance but rather a
> particular algorithm used to estimate it from the data.
> 
> OAVAR denotes another algorithm for estimating the underlying Allan
> variance from the data

Trouble is, the algorithm Tom and Ulrich wants to denote OAVAR others 
have already denoted AVAR, thus causing ambiguity.

> TOTVAR, THEO1 and THEOH denote other algorithms that can be used to
> estimate the underlying Allan variance from the data.
> 
> Some of these algorithms produce biased estimates of the underlying
> Allan variance so correction for such bias is usually necessary.

The way the confidence interval closes on the estimate should be of a 
concern. We can calculate whatever we want, but as we try to judge the 
results of such estimates we should also view the indicators of its 
precision if available.

Cheers,
Magnus

___
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] ADEV vs. OADEV

[Magnus Danielson]

Bruce,

Bruce Griffiths skrev:
> Addendum:
> 
> There would appear to be only 3 underlying frequency stability
> statistics of interest in this paper:
> 
> 1) Allan variance
> 
> 2) Modified Allan variance
> 
> 3) Hadamard variance
> 
> Each of which has a different phase transfer function.
> 
> All other statistical quantities related to frequency stability in this
> paper are actually estimators of one of the above underlying statistics
> Each estimator has different confidence limits and a different bias
> function which may depend on phase noise type.
> Correction for the underlying bias of each estimator is desirable before
> plotting the results.
> Confidence limits are also useful.

I agree... very good points.

Cheers,
Magnus

___
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] Agilent 53132A Needs Help

[tomknox]

Hi Yuri;
I am late to this thread, but if you have not tried this, reseating  
the 4 or 2 eproms which are socketed near the rear may solve the  
problem. I am currently having the same problem with one of mine and  
in the past this have solved the problem on other units.
Good Luck;
Thomas Knox
NIST
4475 Whitney Place
Boulder Colorado 80305
1-303-554-0307
tomk...@nist.gov



Quoting "Yuri Ostry" :

> Hello,
>
> Tuesday, January 20, 2009, 17:26:00, Richard M. Hambly wrote:
>
> R> One of my 53132As, an Agilent unit, s/n KR01202209 fail the power-on self
> R> test with a FAIL:ROM error message.
>
> Cannot say anything about your particular counter, but very often such
> error is due to 'leaked' EPROM chip, that change value of some memory
> cells over time. Last years I seen such problems 5 or 6 times with 15+
> years old equipment, and in most times original EPROM image still can
> be read out if you have a EPROM programmer that allow to set arbitrary
> Vcc for a chip in programming socket.
>
> Some background: Erased EPROM cell (actually small piece of
> metallization between two layers of silicon oxide, acting both as a
> capacitor and as a gate of MOSFET transistor on underlying layers)
> reads as logical "one". When it is charged during programming, it
> start read as "zero".
>
> If some cell have small defects in insulating oxide, or just got a hit
> of some high energy particle, part of charge can be lost and
> "programmed" bit that should read as "zero" starting to read as "one"
> under normal conditions (nominal Vcc).
>
> There is a chance (very good chance, according to my own experience)
> that you can find such "partially discharged" bits by lowering
> (gradually) Vcc and saving read images to disk for further comparsion.
>
> Usually I start from 5.0V, make 10-20 reads, saving each one to
> separate file in a 5V0 directory, then switch to 4.9V, and do the
> same, saving to 4V9 directory, and so on... Usually it is enough to go
> below to 4V0...
>
> When you analyze saved images later, first compare all files in each
> directory to each other, you can find some bits that reads unstable at
> given voltage. Then compare images between nearby voltages and if
> there is any changes, it may be your "lost" zero bits.
>
> If you go too low, some EPROMS that was written before and then erased
> to program current image may show you some of former programmed bits
> as zeros - you need to be careful. There was some "erased" EPROM chips
> that read as blank under 5V but read out their previous content (and
> CRC perfectly match) when read out at Vcc little below 3.8V (not all
> brands of EPROM operational at that voltage, though)...
>
> If there is a CRC on a EPROM label, it may be very useful in
> determining that your recovered image is really good. Some devices do
> CRC check on startup and you can feel yourself safe enough if checksum
> error is gone.
>
> Always keep your original EPROM chip intact and do not expose it to a
> UV or sunlight (if there is no label that cover their window) until
> you are completely sure that you have correct image on hand. Use spare
> EPROM of same type for experiments.
>
>
> BTW: Looks like it is a good idea to have images of EPROMS and
> calibration EEPROMs (if any) for all equipment in a safe place.
>
> --
> Best regards,
>  Yuri, UA3ATQ/KI7XJmailto:y...@ostry.ru
>
>
> ___
> 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] ADEV vs. OADEV

[Tom Van Baak]

> Trouble is, the algorithm Tom and Ulrich wants to denote OAVAR others 
> have already denoted AVAR, thus causing ambiguity.

One can equally say the algorithm you now want to call simply
"AVAR" others long before you chose to call "overlapping AVAR"
in order to clearly distinguish it from the pre-existing label that
you no longer even want to call "AVAR".

Personally I prefer to call it AVAR/ADEV when the implementation
isn't relevant; and in those cases when it is, I specifically qualify
the name with something like "normal" vs. "overlapping". That
removes the ambiguity regardless of historical interpretation.

We've beat this to death now and all understand the issues, yes?

/tvb


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