Empathy List Archives

time-nuts@lists.febo.com

Discussion of precise time and frequency measurement

Re: [time-nuts] Z3805A cooling requirements?

Mark Spencer

Mon, Dec 24, 2012 2:58 PM

Volker et al..

I placed a small muffin fan near one of my Z3805's. The modest air flow seems to have some affect on the units operation.

I've collected some ADEV data as well but don't entirely trust it yet.

Amongst other issues I had a lengthy power failure at my residence four days ago so both my Z3805's have only been running for a few days and most of my other references and all my counters also lost power. My Z3805's seemed to take several weeks to settle down when they were first powered up.

My FTS 1050 has a separate backup battery system and has been running for a few years so I've used it as the reference for this test.

All that said I've included the Adev plots with this email. Removing the air flow seems to cause more issues than adding it. It took a number of hours for the unit to settle down after the air flow
was removed. I wouldn't place much emphasis on the Adev data for Tau's of less than 80 seconds.

While collecting the data used to generate these plots at times I also compared the reference I was using to two other references to give me some comfort that the reference wasn't drifting.

I'll be interested to see any additional data from Volker.

https://www.dropbox.com/s/s8v43cujv5y4wlp/FTS1050%20vs%20Z3805%232%20Dec%2022%202012%20Fan%20on%20at%20approx%20440%20seconds.png

https://www.dropbox.com/s/ong49tbg75ew0n2/Summary.png

https://www.dropbox.com/s/jn95o0h3cn4dh4n/Z3805%20with%20Fan.jpg

Regards
Mark Spencer

Volker et al.. I placed a small muffin fan near one of my Z3805's. The modest air flow seems to have some affect on the units operation. I've collected some ADEV data as well but don't entirely trust it yet. Amongst other issues I had a lengthy power failure at my residence four days ago so both my Z3805's have only been running for a few days and most of my other references and all my counters also lost power. My Z3805's seemed to take several weeks to settle down when they were first powered up. My FTS 1050 has a separate backup battery system and has been running for a few years so I've used it as the reference for this test. All that said I've included the Adev plots with this email. Removing the air flow seems to cause more issues than adding it. It took a number of hours for the unit to settle down after the air flow was removed. I wouldn't place much emphasis on the Adev data for Tau's of less than 80 seconds. While collecting the data used to generate these plots at times I also compared the reference I was using to two other references to give me some comfort that the reference wasn't drifting. I'll be interested to see any additional data from Volker. https://www.dropbox.com/s/s8v43cujv5y4wlp/FTS1050%20vs%20Z3805%232%20Dec%2022%202012%20Fan%20on%20at%20approx%20440%20seconds.png https://www.dropbox.com/s/ong49tbg75ew0n2/Summary.png https://www.dropbox.com/s/jn95o0h3cn4dh4n/Z3805%20with%20Fan.jpg Regards Mark Spencer

Tom Van Baak

Mon, Dec 24, 2012 5:47 PM

Hi Mark,

I wouldn't place much emphasis on the Adev data for Tau's of less than 80 seconds.

Actually, just the opposite; the ADEV at short tau is very close to correct.

I've collected some ADEV data as well but don't entirely trust it yet.

Right, it's the ADEV for longer tau that is completely misleading. Let me explain.

Realize that Allan deviation numbers are statistics; essentially they predict how constant the future frequency might be, based on a sampling of measured frequency in the past. For a statistic like this to be relevant you want to have at least 3, but more likely tens to hundreds of past measurements in order to have confidence in the prediction.

Plotting many Allan deviation statistics, each with a different sampling interval, on a log-log plot gives even more information; the slope of the line reveals noise types.

Now, there is no problem observing transient phenomenon like temperature changes (or phase jumps or frequency jumps or loose cables or pets jumping onto the bench). They show up dramatically in phase or frequency strip plots. You can see how quickly the effect occurs. You can measure the magnitude of the effect. You can measure how long it takes to recover. This is all useful: you get numbers like tempco or thermal Q. But using standard deviation or RMS or Allan deviation, or any other statistic on this data is not the right thing to do -- because you have only a sample of one.

On the other hand, if you encounter tens or hundreds of these transients over hours or days or months, then it is perfectly valid to use statistics like standard or Allan deviation to describe the probability of the transient occurring; the magnitude of the effect, etc. Now you have enough events to offer a future prediction based on many samples in the past.

Does this make sense? In your case "removing air flow" is only one event.

I know it's easy to make ADEV/MDEV plots using Plotter or Timelab but that doesn't mean it's appropriate in every case. When your data has an accidental data glitch or an intentional transient, it's best not to use statistics to describe that one event.

/tvb

----- Original Message -----
From: "Mark Spencer" mspencer12345@yahoo.ca
To: time-nuts@febo.com
Sent: Monday, December 24, 2012 6:58 AM
Subject: Re: [time-nuts] Z3805A cooling requirements?

Volker et al..

I placed a small muffin fan near one of my Z3805's. The modest air flow seems to have some affect on the units operation.

I've collected some ADEV data as well but don't entirely trust it yet.

My FTS 1050 has a separate backup battery system and has been running for a few years so I've used it as the reference for this test.

While collecting the data used to generate these plots at times I also compared the reference I was using to two other references to give me some comfort that the reference wasn't drifting.

I'll be interested to see any additional data from Volker.

https://www.dropbox.com/s/s8v43cujv5y4wlp/FTS1050%20vs%20Z3805%232%20Dec%2022%202012%20Fan%20on%20at%20approx%20440%20seconds.png

https://www.dropbox.com/s/ong49tbg75ew0n2/Summary.png

https://www.dropbox.com/s/jn95o0h3cn4dh4n/Z3805%20with%20Fan.jpg

Regards
Mark Spencer

Hi Mark, > I wouldn't place much emphasis on the Adev data for Tau's of less than 80 seconds. Actually, just the opposite; the ADEV at short tau is very close to correct. > I've collected some ADEV data as well but don't entirely trust it yet. Right, it's the ADEV for longer tau that is completely misleading. Let me explain. Realize that Allan deviation numbers are statistics; essentially they predict how constant the future frequency might be, based on a sampling of measured frequency in the past. For a statistic like this to be relevant you want to have at least 3, but more likely tens to hundreds of past measurements in order to have confidence in the prediction. Plotting many Allan deviation statistics, each with a different sampling interval, on a log-log plot gives even more information; the slope of the line reveals noise types. Now, there is no problem observing transient phenomenon like temperature changes (or phase jumps or frequency jumps or loose cables or pets jumping onto the bench). They show up dramatically in phase or frequency strip plots. You can see how quickly the effect occurs. You can measure the magnitude of the effect. You can measure how long it takes to recover. This is all useful: you get numbers like tempco or thermal Q. But using standard deviation or RMS or Allan deviation, or any other *statistic* on this data is not the right thing to do -- because you have only a sample of one. On the other hand, if you encounter tens or hundreds of these transients over hours or days or months, then it is perfectly valid to use statistics like standard or Allan deviation to describe the probability of the transient occurring; the magnitude of the effect, etc. Now you have enough events to offer a future prediction based on many samples in the past. Does this make sense? In your case "removing air flow" is only one event. I know it's easy to make ADEV/MDEV plots using Plotter or Timelab but that doesn't mean it's appropriate in every case. When your data has an accidental data glitch or an intentional transient, it's best not to use statistics to describe that one event. /tvb ----- Original Message ----- From: "Mark Spencer" <mspencer12345@yahoo.ca> To: <time-nuts@febo.com> Sent: Monday, December 24, 2012 6:58 AM Subject: Re: [time-nuts] Z3805A cooling requirements? Volker et al.. I placed a small muffin fan near one of my Z3805's. The modest air flow seems to have some affect on the units operation. I've collected some ADEV data as well but don't entirely trust it yet. Amongst other issues I had a lengthy power failure at my residence four days ago so both my Z3805's have only been running for a few days and most of my other references and all my counters also lost power. My Z3805's seemed to take several weeks to settle down when they were first powered up. My FTS 1050 has a separate backup battery system and has been running for a few years so I've used it as the reference for this test. All that said I've included the Adev plots with this email. Removing the air flow seems to cause more issues than adding it. It took a number of hours for the unit to settle down after the air flow was removed. I wouldn't place much emphasis on the Adev data for Tau's of less than 80 seconds. While collecting the data used to generate these plots at times I also compared the reference I was using to two other references to give me some comfort that the reference wasn't drifting. I'll be interested to see any additional data from Volker. https://www.dropbox.com/s/s8v43cujv5y4wlp/FTS1050%20vs%20Z3805%232%20Dec%2022%202012%20Fan%20on%20at%20approx%20440%20seconds.png https://www.dropbox.com/s/ong49tbg75ew0n2/Summary.png https://www.dropbox.com/s/jn95o0h3cn4dh4n/Z3805%20with%20Fan.jpg Regards Mark Spencer

Magnus Danielson

Tue, Dec 25, 2012 2:12 AM

Hi,

On 12/24/2012 06:47 PM, Tom Van Baak wrote:

Hi Mark,

I wouldn't place much emphasis on the Adev data for Tau's of less than 80 seconds.

Actually, just the opposite; the ADEV at short tau is very close to correct.

I've collected some ADEV data as well but don't entirely trust it yet.

Right, it's the ADEV for longer tau that is completely misleading. Let me explain.

Realize that Allan deviation numbers are statistics; essentially they predict
how constant the future frequency might be, based on a sampling of measured
frequency in the past. For a statistic like this to be relevant you want to
have at least 3, but more likely tens to hundreds of past measurements in
order to have confidence in the prediction.

Here I want to point out what this is the statistics off, and it is the
statistics noise, normalized to white frequency noise. It is however not
statistics of systematic effects.

Plotting many Allan deviation statistics, each with a different sampling
interval, on a log-log plot gives even more information; the slope of the
line reveals noise types.

Which is the original intent of the ADEV/MDEV curves. MDEV is being
preferred as it helps to distinguish two noise forms that ADEV failed to
handle. For far-out noises, ADEV does just was well with less processing
needed.

Now, there is no problem observing transient phenomenon like temperature
changes (or phase jumps or frequency jumps or loose cables or pets
jumping onto the bench). They show up dramatically in phase or frequency
strip plots. You can see how quickly the effect occurs. You can measure
the magnitude of the effect. You can measure how long it takes to recover.
This is all useful: you get numbers like tempco or thermal Q. But using
standard deviation or RMS or Allan deviation, or any other statistic
on this data is not the right thing to do -- because you have only a sample of one.

Consider if you wrap the time-sequence to re-occur at the same period.
If this is the signal you have, then it is valid. If you include more
"un-eventfull" time and wrap that, then this wrinkle has less part of
the overall time, and thus is averaged out. Assume you keep extending
with un-eventfull time to double each time you end up averaging the
particular wrinkle out of the plot, but still only approach an
approximation as a single wrinkle only occur once.

Those, the ADEV tool-set isn't going to give you very meaningful
interpretation of that wrinkle.

On the other hand, if you encounter tens or hundreds of these
transients over hours or days or months, then it is perfectly
valid to use statistics like standard or Allan deviation to
describe the probability of the transient occurring; the
magnitude of the effect, etc. Now you have enough events to
offer a future prediction based on many samples in the past.

Here I don't agree. Re-occuring "wrinkles" is systematic effects, and
the impact of systematic effects is different to those of noise forms.

A sine modulation of frequency and the way we can estimate it's impact
on future time is quite different from that of inherent noise sources.
Also, it doesn't scale to the white frequency noise.

Similarly, other systematic effects should be separated out of the data
before noise analysis.

Does this make sense? In your case "removing air flow" is only one event.

Indeed. In my experience, forced air as such does not need to be the
culprit, it just optimize the coupling between ambient temperature
changes and the oscillator. Varying forced air rate also counts as
inducing temperature gradients.

I know it's easy to make ADEV/MDEV plots using Plotter or Timelab
but that doesn't mean it's appropriate in every case. When your
data has an accidental data glitch or an intentional transient,
it's best not to use statistics to describe that one event.

In fact, looking at SP 1065 for instance, cleaning your data of such
events is assumed normal procedure.

Cheers,
Magnus

Hi, On 12/24/2012 06:47 PM, Tom Van Baak wrote: > Hi Mark, > >> I wouldn't place much emphasis on the Adev data for Tau's of less than 80 seconds. > > Actually, just the opposite; the ADEV at short tau is very close to correct. > >> I've collected some ADEV data as well but don't entirely trust it yet. > > Right, it's the ADEV for longer tau that is completely misleading. Let me explain. > > Realize that Allan deviation numbers are statistics; essentially they predict > how constant the future frequency might be, based on a sampling of measured > frequency in the past. For a statistic like this to be relevant you want to > have at least 3, but more likely tens to hundreds of past measurements in > order to have confidence in the prediction. Here I want to point out what this is the statistics off, and it is the statistics noise, normalized to white frequency noise. It is however not statistics of systematic effects. > Plotting many Allan deviation statistics, each with a different sampling > interval, on a log-log plot gives even more information; the slope of the > line reveals noise types. Which is the original intent of the ADEV/MDEV curves. MDEV is being preferred as it helps to distinguish two noise forms that ADEV failed to handle. For far-out noises, ADEV does just was well with less processing needed. > Now, there is no problem observing transient phenomenon like temperature > changes (or phase jumps or frequency jumps or loose cables or pets > jumping onto the bench). They show up dramatically in phase or frequency > strip plots. You can see how quickly the effect occurs. You can measure > the magnitude of the effect. You can measure how long it takes to recover. > This is all useful: you get numbers like tempco or thermal Q. But using > standard deviation or RMS or Allan deviation, or any other *statistic* > on this data is not the right thing to do -- because you have only a sample of one. Consider if you wrap the time-sequence to re-occur at the same period. If this is the signal you have, then it is valid. If you include more "un-eventfull" time and wrap that, then this wrinkle has less part of the overall time, and thus is averaged out. Assume you keep extending with un-eventfull time to double each time you end up averaging the particular wrinkle out of the plot, but still only approach an approximation as a single wrinkle only occur once. Those, the ADEV tool-set isn't going to give you very meaningful interpretation of that wrinkle. > On the other hand, if you encounter tens or hundreds of these > transients over hours or days or months, then it is perfectly > valid to use statistics like standard or Allan deviation to > describe the probability of the transient occurring; the > magnitude of the effect, etc. Now you have enough events to > offer a future prediction based on many samples in the past. Here I don't agree. Re-occuring "wrinkles" is systematic effects, and the impact of systematic effects is different to those of noise forms. A sine modulation of frequency and the way we can estimate it's impact on future time is quite different from that of inherent noise sources. Also, it doesn't scale to the white frequency noise. Similarly, other systematic effects should be separated out of the data before noise analysis. > Does this make sense? In your case "removing air flow" is only one event. Indeed. In my experience, forced air as such does not need to be the culprit, it just optimize the coupling between ambient temperature changes and the oscillator. Varying forced air rate also counts as inducing temperature gradients. > I know it's easy to make ADEV/MDEV plots using Plotter or Timelab > but that doesn't mean it's appropriate in every case. When your > data has an accidental data glitch or an intentional transient, > it's best not to use statistics to describe that one event. In fact, looking at SP 1065 for instance, cleaning your data of such events is assumed normal procedure. Cheers, Magnus

Ulrich Bangert

Wed, Dec 26, 2012 10:16 AM

Gentlemen,

I know it's easy to make ADEV/MDEV plots using Plotter or
Timelab but that doesn't mean it's appropriate in every case.
When your data has an accidental data glitch or an
intentional transient, it's best not to use statistics to
describe that one event.

Correct! I would like to add that one of the reasons why I wrote Plotter at
all (other free ADEV software was available at that time and I have a
Stable32) was the fact that after recognizing a glitch or a transient you
may wish to remove it from the data so that ADEV plots are appropiate
thereafter.

My personal experience was that this can be very timeconsuming when done on
numerical data. The basic idea was: Remove the glich where you see it, in
the graphics itself. That has led to a set of handy tools and some
automatics based on robust statistics that you do not want to miss anymore
once you have used them.

Best regards
Ulrich Bangert

-----Ursprungliche Nachricht-----
Von: time-nuts-bounces@febo.com
[mailto:time-nuts-bounces@febo.com] Im Auftrag von Tom Van Baak
Gesendet: Montag, 24. Dezember 2012 18:48
An: Discussion of precise time and frequency measurement
Betreff: Re: [time-nuts] Z3805A cooling requirements?

Hi Mark,

I wouldn't place much emphasis on the Adev data for Tau's

of less than

80 seconds.

Actually, just the opposite; the ADEV at short tau is very
close to correct.

I've collected some ADEV data as well but don't entirely

trust it yet.

Right, it's the ADEV for longer tau that is completely
misleading. Let me explain.

Realize that Allan deviation numbers are statistics;
essentially they predict how constant the future frequency
might be, based on a sampling of measured frequency in the
past. For a statistic like this to be relevant you want to
have at least 3, but more likely tens to hundreds of past
measurements in order to have confidence in the prediction.

Plotting many Allan deviation statistics, each with a
different sampling interval, on a log-log plot gives even
more information; the slope of the line reveals noise types.

Now, there is no problem observing transient phenomenon like
temperature changes (or phase jumps or frequency jumps or
loose cables or pets jumping onto the bench). They show up
dramatically in phase or frequency strip plots. You can see
how quickly the effect occurs. You can measure the magnitude
of the effect. You can measure how long it takes to recover.
This is all useful: you get numbers like tempco or thermal Q.
But using standard deviation or RMS or Allan deviation, or
any other statistic on this data is not the right thing to
do -- because you have only a sample of one.

On the other hand, if you encounter tens or hundreds of these
transients over hours or days or months, then it is perfectly
valid to use statistics like standard or Allan deviation to
describe the probability of the transient occurring; the
magnitude of the effect, etc. Now you have enough events to
offer a future prediction based on many samples in the past.

Does this make sense? In your case "removing air flow" is
only one event.

I know it's easy to make ADEV/MDEV plots using Plotter or
Timelab but that doesn't mean it's appropriate in every case.
When your data has an accidental data glitch or an
intentional transient, it's best not to use statistics to
describe that one event.

/tvb

----- Original Message -----
From: "Mark Spencer" mspencer12345@yahoo.ca
To: time-nuts@febo.com
Sent: Monday, December 24, 2012 6:58 AM
Subject: Re: [time-nuts] Z3805A cooling requirements?

Volker et al..

I placed a small muffin fan near one of my Z3805's. The
modest air flow seems to have some affect on the units operation.

I've collected some ADEV data as well but don't entirely
trust it yet.

Amongst other issues I had a lengthy power failure at my
residence four days ago so both my Z3805's have only been
running for a few days and most of my other references and
all my counters also lost power. My Z3805's seemed to take
several weeks to settle down when they were first powered up.

My FTS 1050 has a separate backup battery system and has been
running for a few years so I've used it as the reference for
this test.

All that said I've included the Adev plots with this email.
Removing the air flow seems to cause more issues than adding
it. It took a number of hours for the unit to settle down
after the air flow
was removed. I wouldn't place much emphasis on the Adev data
for Tau's of less than 80 seconds.

While collecting the data used to generate these plots at
times I also compared the reference I was using to two other
references to give me some comfort that the reference wasn't drifting.

I'll be interested to see any additional data from Volker.

https://www.dropbox.com/s/s8v43cujv5y4wlp/FTS1050%20vs%20Z3805

%232%20Dec%2022%202012%20Fan%20on%20at%20approx%20440%20seconds.png

https://www.dropbox.com/s/ong49tbg75ew0n2/Summary.png

https://www.dropbox.com/s/jn95o0h3cn4dh4n/Z3805%20with%20Fan.jpg

Regards
Mark Spencer

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.

Gentlemen, > I know it's easy to make ADEV/MDEV plots using Plotter or > Timelab but that doesn't mean it's appropriate in every case. > When your data has an accidental data glitch or an > intentional transient, it's best not to use statistics to > describe that one event. Correct! I would like to add that one of the reasons why I wrote Plotter at all (other free ADEV software was available at that time and I have a Stable32) was the fact that after recognizing a glitch or a transient you may wish to remove it from the data so that ADEV plots are appropiate thereafter. My personal experience was that this can be very timeconsuming when done on numerical data. The basic idea was: Remove the glich where you see it, in the graphics itself. That has led to a set of handy tools and some automatics based on robust statistics that you do not want to miss anymore once you have used them. Best regards Ulrich Bangert > -----Ursprungliche Nachricht----- > Von: time-nuts-bounces@febo.com > [mailto:time-nuts-bounces@febo.com] Im Auftrag von Tom Van Baak > Gesendet: Montag, 24. Dezember 2012 18:48 > An: Discussion of precise time and frequency measurement > Betreff: Re: [time-nuts] Z3805A cooling requirements? > > > Hi Mark, > > > I wouldn't place much emphasis on the Adev data for Tau's > of less than > > 80 seconds. > > Actually, just the opposite; the ADEV at short tau is very > close to correct. > > > I've collected some ADEV data as well but don't entirely > trust it yet. > > Right, it's the ADEV for longer tau that is completely > misleading. Let me explain. > > Realize that Allan deviation numbers are statistics; > essentially they predict how constant the future frequency > might be, based on a sampling of measured frequency in the > past. For a statistic like this to be relevant you want to > have at least 3, but more likely tens to hundreds of past > measurements in order to have confidence in the prediction. > > Plotting many Allan deviation statistics, each with a > different sampling interval, on a log-log plot gives even > more information; the slope of the line reveals noise types. > > Now, there is no problem observing transient phenomenon like > temperature changes (or phase jumps or frequency jumps or > loose cables or pets jumping onto the bench). They show up > dramatically in phase or frequency strip plots. You can see > how quickly the effect occurs. You can measure the magnitude > of the effect. You can measure how long it takes to recover. > This is all useful: you get numbers like tempco or thermal Q. > But using standard deviation or RMS or Allan deviation, or > any other *statistic* on this data is not the right thing to > do -- because you have only a sample of one. > > On the other hand, if you encounter tens or hundreds of these > transients over hours or days or months, then it is perfectly > valid to use statistics like standard or Allan deviation to > describe the probability of the transient occurring; the > magnitude of the effect, etc. Now you have enough events to > offer a future prediction based on many samples in the past. > > Does this make sense? In your case "removing air flow" is > only one event. > > I know it's easy to make ADEV/MDEV plots using Plotter or > Timelab but that doesn't mean it's appropriate in every case. > When your data has an accidental data glitch or an > intentional transient, it's best not to use statistics to > describe that one event. > > /tvb > > ----- Original Message ----- > From: "Mark Spencer" <mspencer12345@yahoo.ca> > To: <time-nuts@febo.com> > Sent: Monday, December 24, 2012 6:58 AM > Subject: Re: [time-nuts] Z3805A cooling requirements? > > > Volker et al.. > > I placed a small muffin fan near one of my Z3805's. The > modest air flow seems to have some affect on the units operation. > > I've collected some ADEV data as well but don't entirely > trust it yet. > > Amongst other issues I had a lengthy power failure at my > residence four days ago so both my Z3805's have only been > running for a few days and most of my other references and > all my counters also lost power. My Z3805's seemed to take > several weeks to settle down when they were first powered up. > > My FTS 1050 has a separate backup battery system and has been > running for a few years so I've used it as the reference for > this test. > > All that said I've included the Adev plots with this email. > Removing the air flow seems to cause more issues than adding > it. It took a number of hours for the unit to settle down > after the air flow > was removed. I wouldn't place much emphasis on the Adev data > for Tau's of less than 80 seconds. > > While collecting the data used to generate these plots at > times I also compared the reference I was using to two other > references to give me some comfort that the reference wasn't drifting. > > I'll be interested to see any additional data from Volker. > > https://www.dropbox.com/s/s8v43cujv5y4wlp/FTS1050%20vs%20Z3805 %232%20Dec%2022%202012%20Fan%20on%20at%20approx%20440%20seconds.png https://www.dropbox.com/s/ong49tbg75ew0n2/Summary.png https://www.dropbox.com/s/jn95o0h3cn4dh4n/Z3805%20with%20Fan.jpg Regards Mark Spencer _______________________________________________ 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.