Re: [time-nuts] ADEV slopes and measurement mode

[Ole Petter Ronningen]

Thanks!

I think it will require more than one reading.. :)

Ole

On Thu, Apr 19, 2018 at 12:08 AM, Magnus Danielson <
mag...@rubidium.dyndns.org> wrote:

> Hi Ole Petter,
>
> On 04/16/2018 12:12 PM, Ole Petter Ronningen wrote:
> > Hi, All
> >
> > This will be a bit long, and I apologize for it. Perhaps someone else
> also
> > struggle with the same.
> >
> > One of the properties of the familiar ADEV-plots are the slopes - and how
> > the slope identify the dominant noise type for the various portions of
> the
> > plots. My understanding is that the slopes stem from "how the noise
> behaves
> > under averaging" - White FM follows the usual white noise slope of
> > 1/sqrt(N), or to put it another way; the standard deviation of a set of
> > many averages of length N will fall as sqrt(N) when N increases. If the
> > standard deviation of the whole non-averaged list is 1, the standard
> > deviation of a set of 100-point averages will be 1/10. Other noise types
> > does not follow the same 1/sqrt(N) law, hence will give rise to other
> > slopes as the number of points averaged increases as we look further to
> the
> > right of the plot.
> >
> > If I have already droppped the ball, I'd appreciate a correction..
>
> Hrhrm!
>
> It's not directly averaging but kind of. Ehm. Let me see how to explain
> this...
>
> When you measure frequency, one way or another, two time-stamps is
> formed. The distance between those two time-stamps will be the
> observation time tau. As you count how many cycles, often called events,
> that occurred over that time, you can calculate the frequency as
> events/time. This is the basis of all traditional counters, which we
> these days call Pi-counters, for reasons I will explain separately.
>
> Now, we could be doing this measurement as N sequential back-to-back
> measurements, where the stop event becomes the start event of the next
> measurmeent. As we sum these up the phase of the stop and the start of
> the next cancels and the full sum will become that of the first
> start-event and last stop-event. Regardless how we divide it up or not,
> it will end up being the same measurement. The averaging thus kind of
> cancels out and interestingly does not do anything.
>
> Now, as we attempt to establish the statistical stability of this value
> using the normal standard variance and standard deviation methods, also
> known as Root Mean Square (RMS) algorithm, we have a bit of a problem,
> because the noises of an oscillator is non-convergent. So, an
> alternative method to handle that was presented in the 1966 Feb article
> by that David Allan. It still provide variance and deviation measures,
> but without being caught by the convergence problems.
>
> The ADEV for a certain observation interval is thus an equivalent to
> standard deviation measure, to explain how good stability there is for
> the measure at that observation interval, regardless of how we divided
> the measurement up to form the frequency estimations, as long as they
> form a continuous measurement, thus without dead-time.
>
> The slopes stems from how the 1/f^n power distributions of noises gets
> inverse Fourier transformed into time-domain, which is the basis for
> David Allans article, he uses that out of the M.J.Lighthill "An
> introduction to Fourier analysis and generalised functions" and adapts
> to the power distributions noises. Because different 1/f^n noises is
> dominant in different parts of the spectrum, their slopes in the time
> domain will also show the same dominant features and thus be the limit
> of precision in our measurement.
>
> Now, if there happens to be gaps in the data as gathered, the dead-time
> would cause a bias in the estimated stability, but that bias can be
> predicted and thus compensated for, and was passed to a separate bias
> function that was also modeled in the same article. That way, the bias
> of the counters they had at the time could be overcome to result in
> comparable measures.
>
> The obsticle of the averaging over N samples that prohibited the use of
> the normal RMS function could be separated out into another bias
> function that also was modeled in the article. This way a 5-point
> stability measure and a 3-point stability measure could be compared, by
> converting it into the 2-point stability measure. The 2-point variance
> later became coined Allan's variance and later Allan variance. That
> article forged the ring to control the variances.
>
> I can explain more about how the averaging does not give you more help,
> but the bias function is good enough. I've done simulations to prove
> this to myself and it is really amazing to see it misbehave as soon as
> there is a slope there. Classical statistics is out the window.
>
> > Now onto where I confuse myself (assuming I havent already): measuring
> > phase vs measuring frequency, and white FM versus white PM. Specifically,
> > using a frequency counter to either measure the frequency directly, or
> > setting up a 

Re: [time-nuts] ADEV slopes and measurement mode

[Magnus Danielson]

Hi Ole Petter,

On 04/16/2018 12:12 PM, Ole Petter Ronningen wrote:
> Hi, All
> 
> This will be a bit long, and I apologize for it. Perhaps someone else also
> struggle with the same.
> 
> One of the properties of the familiar ADEV-plots are the slopes - and how
> the slope identify the dominant noise type for the various portions of the
> plots. My understanding is that the slopes stem from "how the noise behaves
> under averaging" - White FM follows the usual white noise slope of
> 1/sqrt(N), or to put it another way; the standard deviation of a set of
> many averages of length N will fall as sqrt(N) when N increases. If the
> standard deviation of the whole non-averaged list is 1, the standard
> deviation of a set of 100-point averages will be 1/10. Other noise types
> does not follow the same 1/sqrt(N) law, hence will give rise to other
> slopes as the number of points averaged increases as we look further to the
> right of the plot.
> 
> If I have already droppped the ball, I'd appreciate a correction..

Hrhrm!

It's not directly averaging but kind of. Ehm. Let me see how to explain
this...

When you measure frequency, one way or another, two time-stamps is
formed. The distance between those two time-stamps will be the
observation time tau. As you count how many cycles, often called events,
that occurred over that time, you can calculate the frequency as
events/time. This is the basis of all traditional counters, which we
these days call Pi-counters, for reasons I will explain separately.

Now, we could be doing this measurement as N sequential back-to-back
measurements, where the stop event becomes the start event of the next
measurmeent. As we sum these up the phase of the stop and the start of
the next cancels and the full sum will become that of the first
start-event and last stop-event. Regardless how we divide it up or not,
it will end up being the same measurement. The averaging thus kind of
cancels out and interestingly does not do anything.

Now, as we attempt to establish the statistical stability of this value
using the normal standard variance and standard deviation methods, also
known as Root Mean Square (RMS) algorithm, we have a bit of a problem,
because the noises of an oscillator is non-convergent. So, an
alternative method to handle that was presented in the 1966 Feb article
by that David Allan. It still provide variance and deviation measures,
but without being caught by the convergence problems.

The ADEV for a certain observation interval is thus an equivalent to
standard deviation measure, to explain how good stability there is for
the measure at that observation interval, regardless of how we divided
the measurement up to form the frequency estimations, as long as they
form a continuous measurement, thus without dead-time.

The slopes stems from how the 1/f^n power distributions of noises gets
inverse Fourier transformed into time-domain, which is the basis for
David Allans article, he uses that out of the M.J.Lighthill "An
introduction to Fourier analysis and generalised functions" and adapts
to the power distributions noises. Because different 1/f^n noises is
dominant in different parts of the spectrum, their slopes in the time
domain will also show the same dominant features and thus be the limit
of precision in our measurement.

Now, if there happens to be gaps in the data as gathered, the dead-time
would cause a bias in the estimated stability, but that bias can be
predicted and thus compensated for, and was passed to a separate bias
function that was also modeled in the same article. That way, the bias
of the counters they had at the time could be overcome to result in
comparable measures.

The obsticle of the averaging over N samples that prohibited the use of
the normal RMS function could be separated out into another bias
function that also was modeled in the article. This way a 5-point
stability measure and a 3-point stability measure could be compared, by
converting it into the 2-point stability measure. The 2-point variance
later became coined Allan's variance and later Allan variance. That
article forged the ring to control the variances.

I can explain more about how the averaging does not give you more help,
but the bias function is good enough. I've done simulations to prove
this to myself and it is really amazing to see it misbehave as soon as
there is a slope there. Classical statistics is out the window.

> Now onto where I confuse myself (assuming I havent already): measuring
> phase vs measuring frequency, and white FM versus white PM. Specifically,
> using a frequency counter to either measure the frequency directly, or
> setting up a time interval measurement to measure phase.

Actually, you tap the data from your counter in two different ways,
either just to get time-stamps one way or another, or get two
time-stamps that has been post-processed into a frequency estimate.

A good crash-coarse on how frequency counters do their dirty work can be
had by 

Re: [time-nuts] ADEV dead time w/ HP 53131A & TimeLab

[Magnus Danielson]

Hi David,

On 04/09/2018 03:29 AM, David Burnett wrote:
> Hi time-nuts,
> 
> I'm doing oscillator-related research for my PhD and found this list
> recently. It's been a great resource in trying to refine my freq
> measurement setup and in starting to understand what's really going on
> inside my lab equipment.

Really good! Welcome!

> I've been trawling the archives and have a question about measuring ADEV
> accurately with the Agilent 53131A frequency counter I have on hand. From
> the comments on this list and elsewhere, and the fact that TimeLab will
> talk to my 53131A directly, I have the impression one can use the 53131A
> for period measurements with which to calculate ADEV. But from GPIB command
> sniffing it looks like there's a lot of dead time between measurements:
> -- In period or freq mode* measurements take an extra ~130ms longer than
> gate time to return (but this seems to produce the correct measurements for
> TimeLab);
> -- in time interval mode they take about ~20ms;
> -- in totalize mode they take about 5ms, in keeping with "200 measurements
> per second" advertised in the brochure, but of course this is a simple
> counter and one loses the resolution of a reciprocal counter or anything
> smarter added in.
> 
> Is it just generally assumed everyone is making period measurements on time
> scales long enough that any instrument dead time is ignorable? Or is
> TimeLab and everyone else silently applying the correction factor as
> described by the Barnes & Allan NIST paper (NIST technical note 1318)? Or
> is there a configuration mode I'm missing that prints measurements with
> more regularly? TimeLab's GPIB commands seem to be limited to "get current
> measurement" so I might not have the box set up right to start with.

OK, first off, one hides the dead time of the counter by using the
time-interval mode and use a reference signal such as a PPS or other
suitable rate as start/Channel 1 signal where as the measured signals
goes into stop/Channel 2. That works up to the rate of the counter, and
you don't want to miss samples.

You should also consider what the time resolution you would need. A
HP5372A for instance can do 8000 samples as every 100 ns with 200 ps
resolution for instance. There is more modern counters that do much better.

> My research concerns oscillator drift on time scales of ~1ms to ~10s, so
> I'm guessing the 53131A with its 5-130ms of dead time isn't suitable for
> what I'm trying to measure. But I'd still like to know how folks are
> getting around this dead time issue with the 53131A for their measurements
> in hopes it'll shed light on how I can do the same without needing to pick
> up more gear and the inevitable shipping delay that will entail. I suspect
> someone will recommend that I get a time-stamping/continuous measurement
> box, which is probably the best solution. But I'm hoping there's a way
> around that in the short term so I can make these measurements sooner.

Well, start with what you have, learn what limits it and then you can
motivate better toys/tools.

That you mention dead-time is refreshing, so you get an extra point
right there, besides asking how to get started.

Now, how much drift do you expect that your oscillators would do? Do you
have a rough idea?

i have done lot's of measurements using a 53131A and hold-over, but
usually the first 10-100 s is relatively easy, but depending on the
details of the lock mechanism it can be more or less "interesting".

Cheers,
Magnus

> 
> 73,
> Dave
> 
> * Others on this list have warned about using this mode because the machine
> does a lot of averaging but it seems like TimeLab needs the box to be in
> this mode regardless. I'm still looking for the part in the manual where
> HP/Agilent/Keysight owns up to this and describe how it changes the
> measurement.
> ___
> 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 dead time w/ HP 53131A & TimeLab

[Tom Van Baak]

Dave,

> My research concerns oscillator drift on time scales of ~1ms to ~10s, so
> I'm guessing the 53131A with its 5-130ms of dead time isn't suitable for
> what I'm trying to measure.

True. Try a fancy TIA (time interval analyzer) or MDA (modulation domain 
analyzer) instead.

Or consider a high-res (tens of ps) timestamping counter capable of 1000 
samples per second. The Pendulum CNT-91 may work. Also look into the Agilent 
53230A which has a zero deadtime timestamping mode. The venerable SR620 is also 
capable of 1 kHz measurement rate, but I'm not sure if that's internal sampling 
or sustained data rate via GPIB. The TICC (designed by JohnA, distributed by 
TAPR) would also work to 1 kHz sampling if you rewrote the Arduino code.

What kind of oscillator is it that you're trying to measure? Pendulum? Tuning 
fork? TCXO? Some SiLabs thing? That may make a huge difference in the type of 
gear you need or the measurement model.

What timing resolution do you need at 1 ms sampling rates?


> But I'd still like to know how folks are
> getting around this dead time issue with the 53131A for their measurements
> in hopes it'll shed light on how I can do the same without needing to pick
> up more gear and the inevitable shipping delay that will entail.

If zero dead time is important then make single-shot time interval measurements 
instead of using frequency or period mode. I do almost all my GPS/1PPS logging 
that way, using a 53131A like yours. But, as you surmise, you don't get 
anywhere near a 1 kHz sampling rate.


> I'm still looking for the part in the manual where
> HP/Agilent/Keysight owns up to this and describe how it changes the
> measurement.

By now there's a lot of literature, both marketing and technical, that 
describes in detail how regression-based frequency counters work. The 53131A 
was designed in the 90's before that literature was written.

There's a key footnote in the manual from which you can infer all of this. For 
a summary see this posting, and the GIF:
https://www.febo.com/pipermail/time-nuts/2013-August/079647.html

Also if you look at the specifications pages (e.g., under RMS resoluion) you'll 
see a more explicit reference to the counter making 200,000 measurements per 
second. Putting all this together it's clear this counter does precise 
single-shot time measurements (compatible with ADEV) but it does 
regression-based frequency/period measurements, which may or may not be 
perfectly compatible with ADEV.

/tvb

- Original Message - 
From: "David Burnett" 
To: 
Sent: Sunday, April 08, 2018 6:29 PM
Subject: [time-nuts] ADEV dead time w/ HP 53131A & TimeLab


> Hi time-nuts,
> 
> I'm doing oscillator-related research for my PhD and found this list
> recently. It's been a great resource in trying to refine my freq
> measurement setup and in starting to understand what's really going on
> inside my lab equipment.
> 
> I've been trawling the archives and have a question about measuring ADEV
> accurately with the Agilent 53131A frequency counter I have on hand. From
> the comments on this list and elsewhere, and the fact that TimeLab will
> talk to my 53131A directly, I have the impression one can use the 53131A
> for period measurements with which to calculate ADEV. But from GPIB command
> sniffing it looks like there's a lot of dead time between measurements:
> -- In period or freq mode* measurements take an extra ~130ms longer than
> gate time to return (but this seems to produce the correct measurements for
> TimeLab);
> -- in time interval mode they take about ~20ms;
> -- in totalize mode they take about 5ms, in keeping with "200 measurements
> per second" advertised in the brochure, but of course this is a simple
> counter and one loses the resolution of a reciprocal counter or anything
> smarter added in.
> 
> Is it just generally assumed everyone is making period measurements on time
> scales long enough that any instrument dead time is ignorable? Or is
> TimeLab and everyone else silently applying the correction factor as
> described by the Barnes & Allan NIST paper (NIST technical note 1318)? Or
> is there a configuration mode I'm missing that prints measurements with
> more regularly? TimeLab's GPIB commands seem to be limited to "get current
> measurement" so I might not have the box set up right to start with.
> 
> My research concerns oscillator drift on time scales of ~1ms to ~10s, so
> I'm guessing the 53131A with its 5-130ms of dead time isn't suitable for
> what I'm trying to measure. But I'd still like to know how folks are
> getting around this dead time issue with the 53131A for their measurements
> in hopes it'll shed light on how I can do the same without needing to pick
> up more gear and the inevitable shipping delay that will entail. I suspect
> someone will recommend that I get a time-stamping/continuous measurement
> box, which is probably the best solution. But I'm hoping there's a way
> around that 

Re: [time-nuts] ADEV dead time w/ HP 53131A & TimeLab

[Bob kb8tq]

Hi

The basic fact is that oscillators drift on *all* time scales. How much they 
drift 
depends on the type of oscillator. A free running VCO based on a PCB resonator
will drift differently than a bare crystal oscillator. An OCXO will have 
different drift
characteristics than a bare oscillator. 

A 53131 by its self is not capable of measuring the ADEV of a crystal 
oscillator over
short time periods. The counter’s ability scales by the gate time so eventually 
if the
gate time is long enough, it will catch up. That might be beyond 1,000 seconds 
for a
good OCXO. By that point, your dead time concerns are not as significant. 

There are a number of methods out there to get higher resolution than a bare 
counter
will provide. The NIST Time and Frequency archives have quite a bit buried in 
them. 
That includes information that digs into your dead time concerns. 

One alternative to the 53131 is a TimePod from Symmetricom. A somewhat less 
expensive approach is a DMTD setup. Both require a “better than” device to 
compare
your oscillator under test to. Unfortunately that’s a drawback to pretty much 
all ways
to do this. If your reference is more noisy than your DUT, you will just see 
the reference. 

Bob

> On Apr 8, 2018, at 9:29 PM, David Burnett  wrote:
> 
> Hi time-nuts,
> 
> I'm doing oscillator-related research for my PhD and found this list
> recently. It's been a great resource in trying to refine my freq
> measurement setup and in starting to understand what's really going on
> inside my lab equipment.
> 
> I've been trawling the archives and have a question about measuring ADEV
> accurately with the Agilent 53131A frequency counter I have on hand. From
> the comments on this list and elsewhere, and the fact that TimeLab will
> talk to my 53131A directly, I have the impression one can use the 53131A
> for period measurements with which to calculate ADEV. But from GPIB command
> sniffing it looks like there's a lot of dead time between measurements:
> -- In period or freq mode* measurements take an extra ~130ms longer than
> gate time to return (but this seems to produce the correct measurements for
> TimeLab);
> -- in time interval mode they take about ~20ms;
> -- in totalize mode they take about 5ms, in keeping with "200 measurements
> per second" advertised in the brochure, but of course this is a simple
> counter and one loses the resolution of a reciprocal counter or anything
> smarter added in.
> 
> Is it just generally assumed everyone is making period measurements on time
> scales long enough that any instrument dead time is ignorable? Or is
> TimeLab and everyone else silently applying the correction factor as
> described by the Barnes & Allan NIST paper (NIST technical note 1318)? Or
> is there a configuration mode I'm missing that prints measurements with
> more regularly? TimeLab's GPIB commands seem to be limited to "get current
> measurement" so I might not have the box set up right to start with.
> 
> My research concerns oscillator drift on time scales of ~1ms to ~10s, so
> I'm guessing the 53131A with its 5-130ms of dead time isn't suitable for
> what I'm trying to measure. But I'd still like to know how folks are
> getting around this dead time issue with the 53131A for their measurements
> in hopes it'll shed light on how I can do the same without needing to pick
> up more gear and the inevitable shipping delay that will entail. I suspect
> someone will recommend that I get a time-stamping/continuous measurement
> box, which is probably the best solution. But I'm hoping there's a way
> around that in the short term so I can make these measurements sooner.
> 
> 73,
> Dave
> 
> * Others on this list have warned about using this mode because the machine
> does a lot of averaging but it seems like TimeLab needs the box to be in
> this mode regardless. I'm still looking for the part in the manual where
> HP/Agilent/Keysight owns up to this and describe how it changes the
> measurement.
> ___
> 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 data for mechanical clocks

[Tom Van Baak]

> Does anybody have any ADEV data for mechanical clocks?  (I didn't find any by 
> google, but there was a lot of noise so maybe I missed something.)

Hal,

It's often buried in out-of-print horological books or magazines / journals / 
articles that google may or may not index.

I have some ADEV examples here:

http://www.leapsecond.com/pages/m21/ -- the classic Navy chronometer
http://www.leapsecond.com/pend/shortt/  -- see Stable32 / Timelab plots
http://www.leapsecond.com/pend/clockb/  -- go to technical links
http://www.leapsecond.com/hsn2006/  -- see dream pendulum paper

> I'd expect a watch to slow down slightly as the spring unwinds.  That 
> probably doesn't apply to clocks driven by weights.

Clockmakers are clever and implement methods to keep constant power:

https://en.wikipedia.org/wiki/Fusee_(horology)
https://en.wikipedia.org/wiki/Maintaining_power

Photo:
https://www.wired.com/wp-content/uploads/archive/images/slideshow/2007/12/gallery_time_hackers/disk.jpg
via https://www.wired.com/2008/01/gallery-time-hackers/

Diagrams:
http://www.hamiltonparts.com/m21-6.jpg
http://www.hamiltonparts.com/m21-8.jpg
via  http://www.hamiltonparts.com/hamilton.htm

Additional photos:
https://chronometerbookdotcom.files.wordpress.com/2017/11/broken-chain-labelled1.jpg
via https://chronometerbook.com/2017/11/

https://chronometerbookdotcom.files.wordpress.com/2017/02/attach-to-fusee-1.jpg
via https://chronometerbook.com/2017/02/13/27-fusee-chain-substitute/

/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 data for mechanical clocks

[Attila Kinali]

On Tue, 06 Mar 2018 21:10:00 -0800
Hal Murray  wrote:

> Does anybody have any ADEV data for mechanical clocks?  (I didn't find any by 
> google, but there was a lot of noise so maybe I missed something.)

How about Tom's Powers of Ten?
http://www.leapsecond.com/ten/clock-powers-of-ten-tvb.pdf

Attila Kinali

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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 query Timelab and TICC

[bg]

Look at ICD-GPS-060.
10V into 50ohm, sub 50ns risetime and 20us pulse lenght is specified in figure 
3-2.
--     Björn


Sent from my smartphone.
 Original message From: Hal Murray <hmur...@megapathdsl.net> 
Date: 21/03/2017  19:18  (GMT+01:00) To: Tom Van Baak <t...@leapsecond.com>, 
Discussion of precise time and frequency measurement <time-nuts@febo.com> Cc: 
hmur...@megapathdsl.net Subject: Re: [time-nuts] ADEV query Timelab and TICC 

t...@leapsecond.com said:
> The TAPR dividers tend not to have "this problem" because they output at
> wimpy TTL/CMOS levels.

Modern CMOS drivers have fast rise times.  As long as the rise time is short 
relative to the cable length, it gets doubled if the end of the cable is an 
open circuit.

> Older equipment can have powerful outputs. 10V into 50R is, what, 1/5th of
> an amp? Logarithmically, that puts a 5061A 1PPS closer to an automobile
> starter motor or heart defibrillator compared to modern logic gates. 

There is a big difference across logic families.  Many can drive 50 ohms.

RS-232 drivers are explicitly limited to reduce EMI.


-- 
These are my opinions.  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.
___
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 query Timelab and TICC

[Hal Murray]

t...@leapsecond.com said:
> The TAPR dividers tend not to have "this problem" because they output at
> wimpy TTL/CMOS levels.

Modern CMOS drivers have fast rise times.  As long as the rise time is short 
relative to the cable length, it gets doubled if the end of the cable is an 
open circuit.

> Older equipment can have powerful outputs. 10V into 50R is, what, 1/5th of
> an amp? Logarithmically, that puts a 5061A 1PPS closer to an automobile
> starter motor or heart defibrillator compared to modern logic gates. 

There is a big difference across logic families.  Many can drive 50 ohms.

RS-232 drivers are explicitly limited to reduce EMI.


-- 
These are my opinions.  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 query Timelab and TICC

[timeok]

   I know the the open load output of some instrument is 10Vpp and I think this 
is right because if  we want to connect this output on a 50Ohm line is correct 
to close the cable with the proper load impedance.
   I have found this level also on some trak System equipment.
   All my test are done using a 50 Ohm load in parallel to the HP and Trak 
outputs. I have tested two HP5065A and one HP5061B with the 1PPS option 
installed with the same spikes problem. The Trak , instead, work correctly, so 
I suspect some design problems on the HP dividers. I remember the same problem 
on the HP, and only HP, appear using an HP53132A TIC.
   To avoid any TAPR TICC input problem I am working on a small interface board 
with a 1M and 50Ohm input selection and a protection circuit for negative or 
non TTL signals.
   Luciano
   www.timeok.it


   Da "time-nuts" time-nuts-boun...@febo.com
   A "Discussion of precise time and frequency measurement" time-nuts@febo.com
   Cc
   Data Mon, 20 Mar 2017 09:48:24 -0700
   Oggetto Re: [time-nuts] ADEV query Timelab and TICC
   Luciano,

   This should not happen with the hp 5065A or 5061B frequency standards. I'm 
glad you worked around it by using a TAPR divider, but let's see if we can 
figure out the actual problem.

   One thing to know is that the 1PPS output level from the 5061 and 5065 is 
*HUGE*, even up to 10 volts. If you send this to most counters it will blow the 
inputs or cause other undesirable side-effects, like the bouncing and spikes 
that you speak of. So always check your output and input signal levels and 
waveforms using a 'scope. Do this in-circuit, with all cables attached. Use 
attenuators and termination as appropriate for your counter's input specs. Set 
your DC trigger level to best match the actual waveform seen by the counter 
(not the waveform sent by the frequency standard).

   Yes, the usual way you find out about this is that your ADEV measurements 
don't look right. The good news is that you can often tell within seconds that 
something is wrong. It's almost always a signal conditioning or trigger level 
issue, not a flaw in the instrument itself.

   The TAPR dividers tend not to have "this problem" because they output at 
wimpy TTL/CMOS levels.

   Older equipment can have powerful outputs. 10V into 50R is, what, 1/5th of 
an amp? Logarithmically, that puts a 5061A 1PPS closer to an automobile starter 
motor or heart defibrillator compared to modern logic gates.

   /tvb


   - Original Message -
   From: "timeok" <tim...@timeok.it>
   To: <time-nuts@febo.com>
   Sent: Monday, March 20, 2017 12:56 AM
   Subject: Re: [time-nuts] ADEV query Timelab and TICC


   >
   > All,
   > the similar problem I have verified using the HP5065A and HP5061B 1PPS 
output, the dividers are pratically unusable for ADEV measurements. The 5/10MHz 
output of the same instruments using the TAPR divider are ok, so these dividers 
have some spike noise problems. It can be seen even using other TIC as The 
HP53132A.
   > Luciano
   > www.timeok.it
   >
   >
   > Da "time-nuts" time-nuts-boun...@febo.com
   > A "Discussion of precise time and frequency measurement" time-nuts@febo.com
   > Cc
   > Data Sun, 19 Mar 2017 20:03:29 -0700
   > Oggetto Re: [time-nuts] ADEV query Timelab and TICC
   > > I have sent a couple of files to Tom. They were taken simultaneously from
   > > an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz 
to
   > > 1Hz. The glitches were on the PPS trace, but not on the PicDiv trace, so
   > > I'm fairly confident the TICC was working correctly.
   > >
   > > Orin.
   >
   > Hi Orin,
   >
   > Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 
points). Everything looks fine with the exception of 8 glitches. These are 
sometimes obvious jumps in phase, which cause massive spikes in frequency. Two 
plots attached.
   >
   > Almost every data point is within a few ns of each other. This is good. 
The standard deviation is a fraction of 1 ns. But once in a while there is a 
relatively massive phase jump. This is bad. Interestingly these 8 phase jumps 
all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list 
is (ns units):
   >
   > 24.575
   > 24.724
   > 24.831
   > 25.047
   > 25.087
   > 25.549
   > 25.589
   > 49.623
   >
   > 25 * N ns is not random. So I think this is not a Windows problem, not a 
USB problem, not a TimeLab problem, not a TICC problem either.
   >
   > It makes me wonder if this is a LTE-Lite problem. If Said or Keith from 
Jackson Labs is around -- is there anything on the LTE-Lite board that's close 
to 20 or 40 or 80 MHz? At this point I kind of trust Orin's data and I kind of 
trust the TICC. So when I see monster 25 ns phase jumps it makes me thin

Re: [time-nuts] ADEV query Timelab and TICc

[ed briggs]

The 1 PPS signal is derived from an 81 MHz clock (12 ns) on the GPS chip 
according to the  Skytraq manual.  So that would mean n * 12ns.

From: time-nuts-requ...@febo.com<mailto:time-nuts-requ...@febo.com>
Sent: ‎3/‎20/‎2017 9:00 AM
To: time-nuts@febo.com<mailto:time-nuts@febo.com>
Subject: time-nuts Digest, Vol 152, Issue 32

Send time-nuts mailing list submissions to
time-nuts@febo.com

To subscribe or unsubscribe via the World Wide Web, visit
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
or, via email, send a message with subject or body 'help' to
time-nuts-requ...@febo.com

You can reach the person managing the list at
time-nuts-ow...@febo.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of time-nuts digest..."


Today's Topics:

   1. Re: ADEV query Timelab and TICC (Orin Eman)
   2. ADEV query Timelab and TICC (Mark Sims)
   3. Re: ADEV query Timelab and TICC (gandal...@aol.com)
   4. Re: ADEV query Timelab and TICC (Dave Martindale)


--

Message: 1
Date: Sun, 19 Mar 2017 22:09:57 -0700
From: Orin Eman <orin.e...@gmail.com>
To: Tom Van Baak <t...@leapsecond.com>,  Discussion of precise time and
frequency measurement <time-nuts@febo.com>
Subject: Re: [time-nuts] ADEV query Timelab and TICC
Message-ID:

Re: [time-nuts] ADEV query Timelab and TICC

[Tom Van Baak]

Luciano,

This should not happen with the hp 5065A or 5061B frequency standards. I'm glad 
you worked around it by using a TAPR divider, but let's see if we can figure 
out the actual problem.

One thing to know is that the 1PPS output level from the 5061 and 5065 is 
*HUGE*, even up to 10 volts. If you send this to most counters it will blow the 
inputs or cause other undesirable side-effects, like the bouncing and spikes 
that you speak of. So always check your output and input signal levels and 
waveforms using a 'scope. Do this in-circuit, with all cables attached. Use 
attenuators and termination as appropriate for your counter's input specs. Set 
your DC trigger level to best match the actual waveform seen by the counter 
(not the waveform sent by the frequency standard).

Yes, the usual way you find out about this is that your ADEV measurements don't 
look right. The good news is that you can often tell within seconds that 
something is wrong. It's almost always a signal conditioning or trigger level 
issue, not a flaw in the instrument itself.

The TAPR dividers tend not to have "this problem" because they output at wimpy 
TTL/CMOS levels.

Older equipment can have powerful outputs. 10V into 50R is, what, 1/5th of an 
amp? Logarithmically, that puts a 5061A 1PPS closer to an automobile starter 
motor or heart defibrillator compared to modern logic gates.

/tvb


- Original Message - 
From: "timeok" <tim...@timeok.it>
To: <time-nuts@febo.com>
Sent: Monday, March 20, 2017 12:56 AM
Subject: Re: [time-nuts] ADEV query Timelab and TICC


> 
>   All,
>   the similar problem I have verified using the HP5065A and HP5061B 1PPS 
> output, the dividers are pratically unusable for ADEV measurements. The 
> 5/10MHz output of the same instruments using the TAPR divider are ok, so 
> these dividers have some spike noise problems. It can be seen even using 
> other TIC as The HP53132A.
>   Luciano
>   www.timeok.it
> 
> 
>   Da "time-nuts" time-nuts-boun...@febo.com
>   A "Discussion of precise time and frequency measurement" time-nuts@febo.com
>   Cc
>   Data Sun, 19 Mar 2017 20:03:29 -0700
>   Oggetto Re: [time-nuts] ADEV query Timelab and TICC
>   > I have sent a couple of files to Tom. They were taken simultaneously from
>   > an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to
>   > 1Hz. The glitches were on the PPS trace, but not on the PicDiv trace, so
>   > I'm fairly confident the TICC was working correctly.
>   >
>   > Orin.
> 
>   Hi Orin,
> 
>   Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). 
> Everything looks fine with the exception of 8 glitches. These are sometimes 
> obvious jumps in phase, which cause massive spikes in frequency. Two plots 
> attached.
> 
>   Almost every data point is within a few ns of each other. This is good. The 
> standard deviation is a fraction of 1 ns. But once in a while there is a 
> relatively massive phase jump. This is bad. Interestingly these 8 phase jumps 
> all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full 
> list is (ns units):
> 
>   24.575
>   24.724
>   24.831
>   25.047
>   25.087
>   25.549
>   25.589
>   49.623
> 
>   25 * N ns is not random. So I think this is not a Windows problem, not a 
> USB problem, not a TimeLab problem, not a TICC problem either.
> 
>   It makes me wonder if this is a LTE-Lite problem. If Said or Keith from 
> Jackson Labs is around -- is there anything on the LTE-Lite board that's 
> close to 20 or 40 or 80 MHz? At this point I kind of trust Orin's data and I 
> kind of trust the TICC. So when I see monster 25 ns phase jumps it makes me 
> think there's a problem with the GSPDO board itself.
> 
>   (Please realize that only on time-nuts may we can use the words "monster" 
> and "25 ns" in the same sentence; the rest of the world has larger problems)
> 
>   /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 query Timelab and TICC

[John Ackermann N8UR]

I noticed with the TICC that the very high peak voltage on the 5061, 5065, etc. 
PPS causes trigger errors.  Putting a 50 ohm load at the TICC channel input 
helped a lot, or an attenuator might even be better.

These HP units have a very short pulse width that peaks at something like 20v 
into a high impedance.  It doesn't​ seem to hurt the TICC input circuit, but 
causes ringing that results in perceived jitter.  Knocking that down to TTL 
level solves the problem.

On Mar 20, 2017, 12:01 PM, at 12:01 PM, timeok <tim...@timeok.it> wrote:
>
>   All,
>the similar problem I have verified using the HP5065A and HP5061B 1PPS
>output, the dividers are pratically unusable for ADEV measurements. The
>5/10MHz output of the same instruments using the TAPR divider are ok,
>so these dividers have some spike noise problems. It can be seen even
>using other TIC as The HP53132A.
>   Luciano
>   www.timeok.it
>
>
>   Da "time-nuts" time-nuts-boun...@febo.com
>A "Discussion of precise time and frequency measurement"
>time-nuts@febo.com
>   Cc
>   Data Sun, 19 Mar 2017 20:03:29 -0700
>   Oggetto Re: [time-nuts] ADEV query Timelab and TICC
>> I have sent a couple of files to Tom. They were taken simultaneously
>from
>> an LTE Lite - one from the PPS and one from a PicDiv dividing the
>10MHz to
>> 1Hz. The glitches were on the PPS trace, but not on the PicDiv trace,
>so
>   > I'm fairly confident the TICC was working correctly.
>   >
>   > Orin.
>
>   Hi Orin,
>
>Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219
>points). Everything looks fine with the exception of 8 glitches. These
>are sometimes obvious jumps in phase, which cause massive spikes in
>frequency. Two plots attached.
>
>Almost every data point is within a few ns of each other. This is good.
>The standard deviation is a fraction of 1 ns. But once in a while there
>is a relatively massive phase jump. This is bad. Interestingly these 8
>phase jumps all appear to be about 25 ns or a multiple of 25 ns in
>magnitude. The full list is (ns units):
>
>   24.575
>   24.724
>   24.831
>   25.047
>   25.087
>   25.549
>   25.589
>   49.623
>
>25 * N ns is not random. So I think this is not a Windows problem, not
>a USB problem, not a TimeLab problem, not a TICC problem either.
>
>It makes me wonder if this is a LTE-Lite problem. If Said or Keith from
>Jackson Labs is around -- is there anything on the LTE-Lite board
>that's close to 20 or 40 or 80 MHz? At this point I kind of trust
>Orin's data and I kind of trust the TICC. So when I see monster 25 ns
>phase jumps it makes me think there's a problem with the GSPDO board
>itself.
>
>(Please realize that only on time-nuts may we can use the words
>"monster" and "25 ns" in the same sentence; the rest of the world has
>larger problems)
>
>   /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.
___
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 query Timelab and TICC

[timeok]

   All,
   the similar problem I have verified using the HP5065A and HP5061B 1PPS 
output, the dividers are pratically unusable for ADEV measurements. The 5/10MHz 
output of the same instruments using the TAPR divider are ok, so these dividers 
have some spike noise problems. It can be seen even using other TIC as The 
HP53132A.
   Luciano
   www.timeok.it


   Da "time-nuts" time-nuts-boun...@febo.com
   A "Discussion of precise time and frequency measurement" time-nuts@febo.com
   Cc
   Data Sun, 19 Mar 2017 20:03:29 -0700
   Oggetto Re: [time-nuts] ADEV query Timelab and TICC
   > I have sent a couple of files to Tom. They were taken simultaneously from
   > an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to
   > 1Hz. The glitches were on the PPS trace, but not on the PicDiv trace, so
   > I'm fairly confident the TICC was working correctly.
   >
   > Orin.

   Hi Orin,

   Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). 
Everything looks fine with the exception of 8 glitches. These are sometimes 
obvious jumps in phase, which cause massive spikes in frequency. Two plots 
attached.

   Almost every data point is within a few ns of each other. This is good. The 
standard deviation is a fraction of 1 ns. But once in a while there is a 
relatively massive phase jump. This is bad. Interestingly these 8 phase jumps 
all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list 
is (ns units):

   24.575
   24.724
   24.831
   25.047
   25.087
   25.549
   25.589
   49.623

   25 * N ns is not random. So I think this is not a Windows problem, not a USB 
problem, not a TimeLab problem, not a TICC problem either.

   It makes me wonder if this is a LTE-Lite problem. If Said or Keith from 
Jackson Labs is around -- is there anything on the LTE-Lite board that's close 
to 20 or 40 or 80 MHz? At this point I kind of trust Orin's data and I kind of 
trust the TICC. So when I see monster 25 ns phase jumps it makes me think 
there's a problem with the GSPDO board itself.

   (Please realize that only on time-nuts may we can use the words "monster" 
and "25 ns" in the same sentence; the rest of the world has larger problems)

   /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 query Timelab and TICC

[Dave Martindale]

The LTE-Lite User Manual (version 1.3) says:

2.3.7 1 PPS Module outputs
The LTE-Lite SMT Module provides GPS raw 1 PPS CMOS pulse on pin 15 with
sawtooth present, and a clean TCXO-generated, sawtooth-removed, UTC(GPS)
phase-locked 1PPS output on pin 4.

It is the pin 4 output that connects to the 1PPS-OUT jack on the eval
board.  So it is supposed to be cleanly divided down from the TCXO.  (But I
don't think Jackson Labs has published any of the circuitry on the LTE-Lite
module itself).

- Dave

On Mon, Mar 20, 2017 at 2:07 AM, Mark Sims  wrote:

>
> It is also interesting that the LTE GPSDO 1PPS has such a wide range of
> TIE.   A Tbolt / Z38xx GPSDO typically has a TIE in the 1PPS signal of
> around 1 nsec.   The LTE TIE spans over 40 nanoseconds (not including the
> spikes).  It seems like the LTE 1PPS may be from the GPS and not derived
> from dividing down the disciplined oscillator output.
> ___
>
___
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 query Timelab and TICC

[GandalfG8--- via time-nuts]

Many thanks for the replies on this, what was initially intended as a quick 
 "Hello World" test seems to have become far more interesting:-)
 
I'll forward my results to Tom as requested and see where we go from  there.
 
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.

Re: [time-nuts] ADEV query Timelab and TICC

[Orin Eman]

On Sun, Mar 19, 2017 at 8:03 PM, Tom Van Baak  wrote:

>
> Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219
> points). Everything looks fine with the exception of 8 glitches. These are
> sometimes obvious jumps in phase, which cause massive spikes in frequency.
> Two plots attached.
>


First, thanks to Tom for taking a look at these files.



> Almost every data point is within a few ns of each other. This is good.
> The standard deviation is a fraction of 1 ns. But once in a while there is
> a relatively massive phase jump. This is bad. Interestingly these 8 phase
> jumps all appear to be about 25 ns or a multiple of 25 ns in magnitude. The
> full list is (ns units):
>
> 24.575
> 24.724
> 24.831
> 25.047
> 25.087
> 25.549
> 25.589
> 49.623
>
> 25 * N ns is not random. So I think this is not a Windows problem, not a
> USB problem, not a TimeLab problem, not a TICC problem either.
>


Personally, I didn't think it was any of the the above either.  The PicDiv
trace showed no such glitches, so I was fairly confident that the TICC was
working well.  But just to verify that, I connected the LTE-Lite PPS to the
5370A and let it run for a few hours.  The 5370A captures similar
glitches.  I have sent the file on to Tom.

For entertainment value, I have attached the current Lady Heather
screenshot for the LTE-Lite.  It has little relationship to the .tim files
I sent to Tom since I generated those a few weeks ago.  FWIW, it shows an
off by two error writing some text, for example: "PDTDT".  This seems to
happen if you go to some other screen (I think it was help in this case)
then returning.

Orin.

[image: Inline image 3]
___
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 query Timelab and TICC

[Tom Van Baak]

Hi Orin,

More info... If you try to manually remove the 25 ns glitches you get a data 
set that looks much better. Attached are the ADEV plots for (1) your raw data 
and (2) your data minus those 8 glitches. You can see the dramatic difference 
that just 8 points make. Blue is raw data, red is data without those 8 glitches.

Now, this is not likely your fault. Also, I'm not saying we know yet what 
causes the glitches. This posting is merely to show how 8 bad points out of 
8,000 points can totally mess up an ADEV plot.

And without preaching too much, this is why I recommend no one does statistical 
work (e.g., ADEV) without first looking at the raw phase and frequency data. A 
doubting Thomas attitude and the human eye are valuable tools in science. Both 
Stable32 and TimeLab make it easy to display phase and frequency, not just 
ADEV. This is not by accident.

Maybe we have hyped ADEV too much on this list. This rant is especially 
addressed at several LH and NTP authors who think analyzing clock data and 
making ADEV plots is just something you blindly code or script or automate, as 
if working with clock measurement data was as pure as mathematics.

/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 query Timelab and TICC

[Bob Stewart]

These look a lot like the 25ns pops I was getting when I first started 
generating the 1PPS output from the PIC.  In my case, the PIC uses a PLL to 
multiply the external clock from 10MHz to 80MHz, which is then  divided to 
40MHz and used as an instruction clock.  This gave an occasional early or late 
pulse, which was off by 25ns.  I wound up fixing my problem by arranging it so 
that the timer used to generate the 1PPS was offset by 2 instructions  (so that 
the timer fired between two successive 100ns pulses from the OCXO) and then 
gating the generated pulse with the OCXO so that the OCXO was the thing 
generating the actual 1PPS output.  Of course, this could be something entirely 
different:  For example, the quantization error on the 1PPS from the GPSDO as 
Tom mentions.  But, in that case, it seems like there should be a lot more of 
them.
Bob 

  From: Tom Van Baak <t...@leapsecond.com>
 To: Discussion of precise time and frequency measurement <time-nuts@febo.com> 
 Sent: Sunday, March 19, 2017 10:04 PM
 Subject: Re: [time-nuts] ADEV query Timelab and TICC
   
> I have sent a couple of files to Tom.  They were taken simultaneously from
> an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to
> 1Hz.  The glitches were on the PPS trace, but not on the PicDiv trace, so
> I'm fairly confident the TICC was working correctly.
> 
> Orin.

Hi Orin,

Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). 
Everything looks fine with the exception of 8 glitches. These are sometimes 
obvious jumps in phase, which cause massive spikes in frequency. Two plots 
attached.

Almost every data point is within a few ns of each other. This is good. The 
standard deviation is a fraction of 1 ns. But once in a while there is a 
relatively massive phase jump. This is bad. Interestingly these 8 phase jumps 
all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list 
is (ns units):

24.575
24.724
24.831
25.047
25.087
25.549
25.589
49.623

25 * N ns is not random. So I think this is not a Windows problem, not a USB 
problem, not a TimeLab problem, not a TICC problem either.

It makes me wonder if this is a LTE-Lite problem. If Said or Keith from Jackson 
Labs is around -- is there anything on the LTE-Lite board that's close to 20 or 
40 or 80 MHz? At this point I kind of trust Orin's data and I kind of trust the 
TICC. So when I see monster 25 ns phase jumps it makes me think there's a 
problem with the GSPDO board itself.

(Please realize that only on time-nuts may we can use the words "monster" and 
"25 ns" in the same sentence; the rest of the world has larger problems)

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

   
___
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 query Timelab and TICC

[Tom Van Baak]

> I have sent a couple of files to Tom.  They were taken simultaneously from
> an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to
> 1Hz.  The glitches were on the PPS trace, but not on the PicDiv trace, so
> I'm fairly confident the TICC was working correctly.
> 
> Orin.

Hi Orin,

Thanks for the raw data. It's very nice (2 hours 16 minutes = 8219 points). 
Everything looks fine with the exception of 8 glitches. These are sometimes 
obvious jumps in phase, which cause massive spikes in frequency. Two plots 
attached.

Almost every data point is within a few ns of each other. This is good. The 
standard deviation is a fraction of 1 ns. But once in a while there is a 
relatively massive phase jump. This is bad. Interestingly these 8 phase jumps 
all appear to be about 25 ns or a multiple of 25 ns in magnitude. The full list 
is (ns units):

24.575
24.724
24.831
25.047
25.087
25.549
25.589
49.623

25 * N ns is not random. So I think this is not a Windows problem, not a USB 
problem, not a TimeLab problem, not a TICC problem either.

It makes me wonder if this is a LTE-Lite problem. If Said or Keith from Jackson 
Labs is around -- is there anything on the LTE-Lite board that's close to 20 or 
40 or 80 MHz? At this point I kind of trust Orin's data and I kind of trust the 
TICC. So when I see monster 25 ns phase jumps it makes me think there's a 
problem with the GSPDO board itself.

(Please realize that only on time-nuts may we can use the words "monster" and 
"25 ns" in the same sentence; the rest of the world has larger problems)

/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 query Timelab and TICC

[DaveH]

USB is not tied to anything specific so that could well be the case.

Another interest of mine is CNC machining (mill conversion and looking at a
Chinese laser) using MACH3 software. People have tried everything to get the
motors to run from a USB connection as machines with parallel ports are
getting rare. No success at all. A couple of companies are using an Ethernet
connection from the host computer to their own CPU board
(https://www.poscope.com/) - this works great. USB no.

Dave

> -Original Message-
> From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf 
> Of Tom McDermott
> Sent: Sunday, March 19, 2017 15:00
> To: Discussion of precise time and frequency measurement
> Cc: gandal...@aol.com
> Subject: Re: [time-nuts] ADEV query Timelab and TICC
> 
> I had this happen this morning. (Running Windows 10). Had 7 
> hours of good
> data
> running overnight, (good ADEV, Freq Diff plots).
> 
> Then There was a big pop' in the frequency difference trace. 
> ADEV messed up
> suddenly.
> 
> It happened coincident with starting up Microsoft Edge (which 
> had not been
> run
> since the start of the data run).  My guess is that perhaps 
> Windows got too
> busy
> and USB samples were dropped.
> 
> -- Tom, N5EG
> ___
> 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 query Timelab and TICC

[John Ackermann N8UR]

I saw a similar higher-than-expected ADEV from another user who was measuring 
GPSDO PPS vs. 10 MHz from the same GPSDO.  Using a T2-Mini  from the 10 MHz 
yields the expected results.

I suspect that the GPSDO PPS in that unit is derived from GPS PPS rather than 
the OCXO, and thus is noisier in the short term than might otherwise be 
expected.

John

PS -- we just got into our new house and still don't have internet access, so 
I've not been on line as much as usual.  another few days and things should!D 
be getting back to normal.



On Mar 19, 2017, 8:01 PM, at 8:01 PM, Orin Eman  wrote:
>On Sun, Mar 19, 2017 at 3:00 PM, Tom Van Baak 
>wrote:
>
>> > I've seen similar with my TICC when observing a PPS - can't
>remember
>> > whether the PPS was from the Thunderbolt or LTE Lite.
>> >
>> > There was a distinct glitch on the frequency plot when it happened
>and it
>> > was pretty easy in timelab to expand the trace around the glitch to
>take
>> a
>> > better look.
>>
>> Orin -- Thanks for that report. If you still have the TIM file, can
>you
>> send it to me?
>>
>
>
>I have sent a couple of files to Tom.  They were taken simultaneously
>from
>an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz
>to
>1Hz.  The glitches were on the PPS trace, but not on the PicDiv trace,
>so
>I'm fairly confident the TICC was working correctly.
>
>Orin.
>___
>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 query Timelab and TICC

[Orin Eman]

On Sun, Mar 19, 2017 at 3:00 PM, Tom Van Baak  wrote:

> > I've seen similar with my TICC when observing a PPS - can't remember
> > whether the PPS was from the Thunderbolt or LTE Lite.
> >
> > There was a distinct glitch on the frequency plot when it happened and it
> > was pretty easy in timelab to expand the trace around the glitch to take
> a
> > better look.
>
> Orin -- Thanks for that report. If you still have the TIM file, can you
> send it to me?
>


I have sent a couple of files to Tom.  They were taken simultaneously from
an LTE Lite - one from the PPS and one from a PicDiv dividing the 10MHz to
1Hz.  The glitches were on the PPS trace, but not on the PicDiv trace, so
I'm fairly confident the TICC was working correctly.

Orin.
___
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 query Timelab and TICC

[Tom McDermott]

I had this happen this morning. (Running Windows 10). Had 7 hours of good
data
running overnight, (good ADEV, Freq Diff plots).

Then There was a big pop' in the frequency difference trace. ADEV messed up
suddenly.

It happened coincident with starting up Microsoft Edge (which had not been
run
since the start of the data run).  My guess is that perhaps Windows got too
busy
and USB samples were dropped.

-- Tom, N5EG
___
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 query Timelab and TICC

[Tom Van Baak]

> I've seen similar with my TICC when observing a PPS - can't remember
> whether the PPS was from the Thunderbolt or LTE Lite.
> 
> There was a distinct glitch on the frequency plot when it happened and it
> was pretty easy in timelab to expand the trace around the glitch to take a
> better look.

Orin -- Thanks for that report. If you still have the TIM file, can you send it 
to me?

Everyone -- If you do see any anomalies with the new TICC please let me know, 
on- or off-list. A copy of the TIM file (if you use TimeLab) would be useful to 
me. Or if you're just logging the raw ascii output that's fine too. Once we 
collect enough examples we can update the user manual, or FAQ or even the 
firmware.

Anytime you work with an instrument that can measure down to 60 ps 
(single-shot) or down to 1 ps (with sufficient over-sampling or averaging) you 
may see things you normally don't see. This includes walking, closing doors, 
sneezing, touching cables or connectors. HVAC, FedEx trucks, sunlight, kids, 
pets, wife are also known to affect measurements at the ps level.

I'm currently running a TICC in TI (Time Interval) mode, in parallel with a hp 
53132 counter in TI mode, in parallel with a TimePod. So it's really easy to 
see when one or the other or both have an issue. For use as a headless time 
interval counter, John's TICC is living up to its goal of an inexpensive 
alternative to a 53131A/53132A.

/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 query Timelab and TICC

[Bob kb8tq]

Hi

It’s a pretty good bet that the “upper” trace has a noise pop in it. One of the 
wonderful things about ADEV is that a single 
noise event can impact the whole curve. That is a bit non-intuitive. It is 
indeed how the math works and how the testing
comes out in the real world.

Bob



> On Mar 19, 2017, at 12:08 PM, GandalfG8--- via time-nuts  
> wrote:
> 
> Yesterday I used one of John's excellent TICC modules for the first  time 
> and initially set up a quick test using the 10MHz output from a  Thunderbolt 
> as the frequency reference to measure the 1PPS from an  Oscilloquartz Star4 
> GPSDO, with the TICC output feeding a USB3 port on a Windows  10 PC running 
> the 64 bit version of Timelab 1.29.
> 
> I'll attach a copy of the test plots I'm referring to but just in  case 
> this doesn't get through I've also uploaded it to
> 
> https://www.mediafire.com/?9bue90yp1e8ueu6
> 
> Using the basic settings as described in the TICC manual the first  run was 
> for 1 hour and seemed fine so I decided to extend the run time to 6  hours. 
> The first 6 hour test started to follow the 1 hour plot as expected and I  
> watched this on and off and can confirm it did so up to somewhere between  
> the 100s and 1000s points on the x-axis, but some time after that the 
> complete  plot shifted upwards and then continued to completion to produce 
> the 
> magenta  trace.
> 
> I wasn't watching when it shifted so don't know if it was a jump or a  
> gradual shift but did see it continue until completion. When I repeated the 6 
>  
> hour test, again without changing anything, and hoping to observe the  effect 
> as it happened, it produced the green trace which was what I'd been  
> expecting to start with. Since then I've made other test runs and again all  
> seems 
> to be as expected.
> 
> I'm probably missing something obvious but don't understand what's  
> happened here so any suggestions would be welcome.
> 
> Throughout the tests I have been simultaneously streaming data  from the 
> Star4 to Lady Heather via a "proper" serial port on the same PC so did  
> wonder 
> if there might be some form of data conflict but it doesn't seem to  have 
> shown up as any obvious form of corruption and hasn't repeated  itself.
> 
> Nigel,  GM8PZR  170318.png>___
> 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 query Timelab and TICC

[Orin Eman]

I've seen similar with my TICC when observing a PPS - can't remember
whether the PPS was from the Thunderbolt or LTE Lite.

There was a distinct glitch on the frequency plot when it happened and it
was pretty easy in timelab to expand the trace around the glitch to take a
better look.

I did not see any such problem when dividing the 10MHz to 1PPS with a
PICDIV so I figured it was due to the GPSDO steering the PPS signal as
satellites appear/disappear - my antenna location is far from optimal.

On Sun, Mar 19, 2017 at 12:57 PM, Tom Van Baak  wrote:

> > I'm probably missing something obvious but don't understand what's
> > happened here so any suggestions would be welcome.
>
> Hi Nigel,
>
> Your setup sounds fine. Off-list, send me the TIM files and I'll see what
> happened.
>
> I know we all love ADEV but in general always look at the phase, phase
> residual, and frequency plots first before you bother with ADEV. These
> strip chart plots better show your raw data and measurement. Even a single
> glitch will be visible. Only if these plots are "clean" should you go ahead
> and use ADEV. Another trick is using the TimeLab "Trace" feature which
> splits the data into N segments and computes ADEV for each one
> independently.
>
> But in this particular case where you are comparing two GPSDO a phase
> difference plot will likely be more informative than an ADEV plot anyway.
> You may also want to play around with the averaging value (command 'g').
>
> /tvb
>
> - Original Message -
> From: "GandalfG8--- via time-nuts" 
> To: 
> Sent: Sunday, March 19, 2017 9:08 AM
> Subject: [time-nuts] ADEV query Timelab and TICC
>
>
> > Yesterday I used one of John's excellent TICC modules for the first  time
> > and initially set up a quick test using the 10MHz output from a
> Thunderbolt
> > as the frequency reference to measure the 1PPS from an  Oscilloquartz
> Star4
> > GPSDO, with the TICC output feeding a USB3 port on a Windows  10 PC
> running
> > the 64 bit version of Timelab 1.29.
> >
> > I'll attach a copy of the test plots I'm referring to but just in  case
> > this doesn't get through I've also uploaded it to
> >
> > https://www.mediafire.com/?9bue90yp1e8ueu6
> >
> > Using the basic settings as described in the TICC manual the first  run
> was
> > for 1 hour and seemed fine so I decided to extend the run time to 6
> hours.
> > The first 6 hour test started to follow the 1 hour plot as expected and I
> > watched this on and off and can confirm it did so up to somewhere between
> > the 100s and 1000s points on the x-axis, but some time after that the
> > complete  plot shifted upwards and then continued to completion to
> produce the
> > magenta  trace.
> >
> > I wasn't watching when it shifted so don't know if it was a jump or a
> > gradual shift but did see it continue until completion. When I repeated
> the 6
> > hour test, again without changing anything, and hoping to observe the
> effect
> > as it happened, it produced the green trace which was what I'd been
> > expecting to start with. Since then I've made other test runs and again
> all  seems
> > to be as expected.
> >
> >
> > Throughout the tests I have been simultaneously streaming data  from the
> > Star4 to Lady Heather via a "proper" serial port on the same PC so did
> wonder
> > if there might be some form of data conflict but it doesn't seem to  have
> > shown up as any obvious form of corruption and hasn't repeated  itself.
> >
> > 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 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 query Timelab and TICC

[Tom Van Baak]

> I'm probably missing something obvious but don't understand what's  
> happened here so any suggestions would be welcome.

Hi Nigel,

Your setup sounds fine. Off-list, send me the TIM files and I'll see what 
happened.

I know we all love ADEV but in general always look at the phase, phase 
residual, and frequency plots first before you bother with ADEV. These strip 
chart plots better show your raw data and measurement. Even a single glitch 
will be visible. Only if these plots are "clean" should you go ahead and use 
ADEV. Another trick is using the TimeLab "Trace" feature which splits the data 
into N segments and computes ADEV for each one independently.

But in this particular case where you are comparing two GPSDO a phase 
difference plot will likely be more informative than an ADEV plot anyway. You 
may also want to play around with the averaging value (command 'g').

/tvb

- Original Message - 
From: "GandalfG8--- via time-nuts" 
To: 
Sent: Sunday, March 19, 2017 9:08 AM
Subject: [time-nuts] ADEV query Timelab and TICC


> Yesterday I used one of John's excellent TICC modules for the first  time 
> and initially set up a quick test using the 10MHz output from a  Thunderbolt 
> as the frequency reference to measure the 1PPS from an  Oscilloquartz Star4 
> GPSDO, with the TICC output feeding a USB3 port on a Windows  10 PC running 
> the 64 bit version of Timelab 1.29.
> 
> I'll attach a copy of the test plots I'm referring to but just in  case 
> this doesn't get through I've also uploaded it to
> 
> https://www.mediafire.com/?9bue90yp1e8ueu6
> 
> Using the basic settings as described in the TICC manual the first  run was 
> for 1 hour and seemed fine so I decided to extend the run time to 6  hours. 
> The first 6 hour test started to follow the 1 hour plot as expected and I  
> watched this on and off and can confirm it did so up to somewhere between  
> the 100s and 1000s points on the x-axis, but some time after that the 
> complete  plot shifted upwards and then continued to completion to produce 
> the 
> magenta  trace.
> 
> I wasn't watching when it shifted so don't know if it was a jump or a  
> gradual shift but did see it continue until completion. When I repeated the 6 
>  
> hour test, again without changing anything, and hoping to observe the  effect 
> as it happened, it produced the green trace which was what I'd been  
> expecting to start with. Since then I've made other test runs and again all  
> seems 
> to be as expected.
> 
> 
> Throughout the tests I have been simultaneously streaming data  from the 
> Star4 to Lady Heather via a "proper" serial port on the same PC so did  
> wonder 
> if there might be some form of data conflict but it doesn't seem to  have 
> shown up as any obvious form of corruption and hasn't repeated  itself.
> 
> 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.

Re: [time-nuts] ADEV and fractional frequency

[Attila Kinali]

On Thu, 14 Apr 2016 07:33:11 -0700
Jeremy Nichols  wrote:

> Correct, Attila. I've been trying to find two separate definitions when 
> it seems they are the same thing. It also shows my age that I don't 
> automatically check Wikipedia.

Well.. The formula there appears at a lot of other places as well.
Like NIST Tech Note 1337. What other formula did you see and why did
it confuse you?

I am trying to figure out what makes ADEV & Co hard to understand,
so we could come up with a better explanation.

Attila Kinali

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and technological sophistication in the world is of no 
use without that foundation.
 -- Miss Matheson, The Diamond Age, Neil Stephenson
___
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 and fractional frequency

[Magnus Danielson]

Hi,

Well, there is two different ways to evaluate ADEV, but the 5360 variant 
would be the non-overlapping Allan Deviation for sure.


Cheers,
Magnus

On 04/14/2016 04:33 PM, Jeremy Nichols wrote:

Correct, Attila. I've been trying to find two separate definitions when
it seems they are the same thing. It also shows my age that I don't
automatically check Wikipedia.

Jeremy

On 4/14/2016 3:18 AM, Attila Kinali wrote:

Hoi Jeremy,

On Wed, 13 Apr 2016 16:16:02 -0700
Jeremy Nichols  wrote:


It would appear that the Allen variance as defined at the bottom of page
4 in TVB's reference to the December 1970 HP Journal (thanks, Tom!) is
the same formula as that used for "fractional frequency deviation" in
other HP publications on the 5360A. This is helpful to me because I've
been tearing my hair out trying to find one reference that equates
the two.

Do you mean by "the two" ADEV and fractional frequency? If so,
could you enlighten me where the confusion comes from? Because
the formula you refere to in the HP journal is just a different
way of writing the standard two sample ADEV which you can also
find on wikipedia.

Attila Kinali



___
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 and fractional frequency

[Jeremy Nichols]

Correct, Attila. I've been trying to find two separate definitions when 
it seems they are the same thing. It also shows my age that I don't 
automatically check Wikipedia.


Jeremy

On 4/14/2016 3:18 AM, Attila Kinali wrote:

Hoi Jeremy,

On Wed, 13 Apr 2016 16:16:02 -0700
Jeremy Nichols  wrote:


It would appear that the Allen variance as defined at the bottom of page
4 in TVB's reference to the December 1970 HP Journal (thanks, Tom!) is
the same formula as that used for "fractional frequency deviation" in
other HP publications on the 5360A. This is helpful to me because I've
been tearing my hair out trying to find one reference that equates the two.

Do you mean by "the two" ADEV and fractional frequency? If so,
could you enlighten me where the confusion comes from? Because
the formula you refere to in the HP journal is just a different
way of writing the standard two sample ADEV which you can also
find on wikipedia.

Attila Kinali



___
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 measurement question

[Matthias Jelen]

Tom,

thanks for sharing this! This was exactly what I was looking for.

Regards,

Matthias

Am 23.08.2015 um 19:19 schrieb Tom Van Baak:

To learn more, I think the best way would be to put the
counter into its fast binary mode and acquire 1k time
interval samples per second. That would give me loads of
data to play with and it would be easy to try out how
different averaging schemes affect the result.

Matthias,

See: http://leapsecond.com/pages/adev-avg/ for the results of a similar ADEV 
averaging experiment. I can send you the raw data if you want.

What helped me understand the issue was to think in terms of frequency 
*in*stability instead of frequency stability. We often use the words 
interchangeably. But imagine that your goal is to measure oscillator noise, its 
instability, not its stability. With this new mental image the last thing you 
would do is average. By its very nature, averaging removes highs and lows and 
smoothes things out. If your goal is to measure instability, averaging removes 
the very thing you're trying to measure.

The plots in the above web page show this dramatically. You can make an 
oscillator as good as you want if you average enough.

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



___
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 measurement question

[Tom Van Baak]

 To learn more, I think the best way would be to put the 
 counter into its fast binary mode and acquire 1k time 
 interval samples per second. That would give me loads of 
 data to play with and it would be easy to try out how 
 different averaging schemes affect the result.

Matthias,

See: http://leapsecond.com/pages/adev-avg/ for the results of a similar ADEV 
averaging experiment. I can send you the raw data if you want.

What helped me understand the issue was to think in terms of frequency 
*in*stability instead of frequency stability. We often use the words 
interchangeably. But imagine that your goal is to measure oscillator noise, its 
instability, not its stability. With this new mental image the last thing you 
would do is average. By its very nature, averaging removes highs and lows and 
smoothes things out. If your goal is to measure instability, averaging removes 
the very thing you're trying to measure.

The plots in the above web page show this dramatically. You can make an 
oscillator as good as you want if you average enough.

/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 measurement question

[Magnus Danielson]

Matthias,

On 08/20/2015 09:55 PM, Matthias Jelen wrote:

Dear John  Magnus,

thank you very much for your detailed explanation. I realize that the
averaging topic is much more complex than I thought - it certainly gives
me something to think about :-) I never thought in terms of noise
bandwith in this application, thanks for putting me on this track.


You are welcome. Your question was a good opportunity to explain.


It seems that the simplest and safest way to get meaningfull results is
to hook up two mixers and a hand full of opamps and comparators.


Which isn't that easy. You will reduce the slew-rate of your signal in 
the mix-down process, and that converts white noise into white phase 
noise, which reduces the benefit of the lower frequency achieves. To 
overcome this you need to gain yourself out of the situation. That 
works, but it is a bit messy than just tossing in a mixer or two.



To learn more, I think the best way would be to put the counter into its
fast binary mode and acquire 1k time interval samples per second. That
would give me loads of data to play with and it would be easy to try out
how different averaging schemes affect the result.


This is actually a very good idea.
Won't do much for ADEV other than confidence intervals, but is good for 
MDEV in lowering the front-end noise to be able to measure things.



I´ll have to read and think some more :-)


Experiment, analyze, test theories etc. is how we all learn. :)

Cheers,
Magnus


Cheers,

Matthias


Am 19.08.2015 um 21:52 schrieb Magnus Danielson:

Dear Mathias,

On 08/19/2015 06:40 PM, Matthias Jelen wrote:

Hello,

I´ve got a question concerning ADEV-measurements.

I´m measuring the 15 MHz output of a KS-24361 with my SR-620 with it´s
internal (Wenzel) OCXO using Timelab. For the first shot I used the
counters frequency mode with 1s gatetime. ADEV at tau=1s turned out to
be arounf 2E-11, which fits the 20 ps single shot resolution of the
SR-620 nicely.

To overcome this limitation without setting up a DMTD system, I used the
counter as TIC, feeding 1 kHz (derived from the counter´s reference) to
the start channel, the 15 MHz to the stop channel and put the counter
into average mode / 1k samples. This gives me one averaged result per
second.

The idea was that this shouldn´t change the measurement itself, because
like in frequency mode with 1s gate time I get the averaged value over
one second, but I expected trigger noise etc. to be averaged out to a
certain amount. I have to watch out for phase wraps, but as the two
frequencys are quite equal, this is not a big issue here.

As expected, ADEV at tau=1s got much better, it is now in the 4E-12
area, which sound reasonable.

What makes me wonder is the fact that result are significantly better
now at longer taus (10..100s) also, despite of the fact that also in
frequency mode these result were well aboce the noise floor (2E-12 @ 10s
and so on...).

So, is it a good idea to use this kind of averaging, or am I overlooking
something which turns the numbers better than they really are? I´m
pretty sure I am not the first one to try this...

I´m looking forward to your comments.


OK, averaging or filtering of data before ADEV processing is tricky,
as it filters the data. Whenever you do that, you actually convert
your measurement from an ADEV measure to something else. If you do
proper post-processing, this something else can have known properties
and thus we can relate the amplitude of the curve to amplitude of
various noise sources, as it will cause biasing from the ADEV properties.

The reason you get better results is because the ADEV response on
white noise depends on the measurement system bandwidth (see Allan
deviation wikipedia page), and by averaging you do reduce the bandwidth.

Sometimes when you do this, you loose the gain as you increase the
tau, since the dominant frequency will lower and become more and more
into the pass-band of the fixed bandwidth filter you created. What you
see is that it flattens out to the length of the average before
lowering down, as if there was no filtering, so you have only achieved
a gain in skewed value for very short taus, but then no gain at all
for longer taus, so no real gain.

This was realized in 1980-1981 and in 1981 an article was published in
which they realized that they can change the bandwidth along-side the
change of tau, so that the gain remains. This became the modified
Allan deviation (MDEV), and was inspired by the methods for improving
frequency measures for lasers as presented by J.J. Snyder in 1980 and
1981. J.J. Snyder was doing what you proposes, averaging of blocks,
and then extended this in software, and this became a direct
inspiration for the MDEV development, which does a pre-averaging over
tau before processing through ADEV, and this combined is the MDEV.

Doing TIC averaging and then continue the processing with MDEV
processing should produce a proper MDEV curve, unless my tired brain
does not miss out on 

Re: [time-nuts] ADEV measurement question

[Bob Camp]

Hi

Next layer to this onion is that the low(er) frequency signals out of the mixer 
have slow(er) edges. There has been a lot of discussion on the list in the past 
about Dual Mixer Time Difference (DMTD) setups. The fast answer is in a paper 
by a gentleman by the name of Collins. on how to do the limiters in a fashion 
best optimized to get around the issue. There is some debate on how old the 
technique actually is, but his approach is pretty good. 

Bob

 On Aug 20, 2015, at 3:55 PM, Matthias Jelen matthias.je...@gmx.de wrote:
 
 Dear John  Magnus,
 
 thank you very much for your detailed explanation. I realize that the 
 averaging topic is much more complex than I thought - it certainly gives me 
 something to think about :-) I never thought in terms of noise bandwith in 
 this application, thanks for putting me on this track.
 
 It seems that the simplest and safest way to get meaningfull results is to 
 hook up two mixers and a hand full of opamps and comparators.
 
 To learn more, I think the best way would be to put the counter into its fast 
 binary mode and acquire 1k time interval samples per second. That would give 
 me loads of data to play with and it would be easy to try out how different 
 averaging schemes affect the result.
 
 I´ll have to read and think some more :-)
 
 Cheers,
 
 Matthias
 
 
 Am 19.08.2015 um 21:52 schrieb Magnus Danielson:
 Dear Mathias,
 
 On 08/19/2015 06:40 PM, Matthias Jelen wrote:
 Hello,
 
 I´ve got a question concerning ADEV-measurements.
 
 I´m measuring the 15 MHz output of a KS-24361 with my SR-620 with it´s
 internal (Wenzel) OCXO using Timelab. For the first shot I used the
 counters frequency mode with 1s gatetime. ADEV at tau=1s turned out to
 be arounf 2E-11, which fits the 20 ps single shot resolution of the
 SR-620 nicely.
 
 To overcome this limitation without setting up a DMTD system, I used the
 counter as TIC, feeding 1 kHz (derived from the counter´s reference) to
 the start channel, the 15 MHz to the stop channel and put the counter
 into average mode / 1k samples. This gives me one averaged result per
 second.
 
 The idea was that this shouldn´t change the measurement itself, because
 like in frequency mode with 1s gate time I get the averaged value over
 one second, but I expected trigger noise etc. to be averaged out to a
 certain amount. I have to watch out for phase wraps, but as the two
 frequencys are quite equal, this is not a big issue here.
 
 As expected, ADEV at tau=1s got much better, it is now in the 4E-12
 area, which sound reasonable.
 
 What makes me wonder is the fact that result are significantly better
 now at longer taus (10..100s) also, despite of the fact that also in
 frequency mode these result were well aboce the noise floor (2E-12 @ 10s
 and so on...).
 
 So, is it a good idea to use this kind of averaging, or am I overlooking
 something which turns the numbers better than they really are? I´m
 pretty sure I am not the first one to try this...
 
 I´m looking forward to your comments.
 
 OK, averaging or filtering of data before ADEV processing is tricky, as it 
 filters the data. Whenever you do that, you actually convert your 
 measurement from an ADEV measure to something else. If you do proper 
 post-processing, this something else can have known properties and thus we 
 can relate the amplitude of the curve to amplitude of various noise sources, 
 as it will cause biasing from the ADEV properties.
 
 The reason you get better results is because the ADEV response on white 
 noise depends on the measurement system bandwidth (see Allan deviation 
 wikipedia page), and by averaging you do reduce the bandwidth.
 
 Sometimes when you do this, you loose the gain as you increase the tau, 
 since the dominant frequency will lower and become more and more into the 
 pass-band of the fixed bandwidth filter you created. What you see is that it 
 flattens out to the length of the average before lowering down, as if there 
 was no filtering, so you have only achieved a gain in skewed value for very 
 short taus, but then no gain at all for longer taus, so no real gain.
 
 This was realized in 1980-1981 and in 1981 an article was published in which 
 they realized that they can change the bandwidth along-side the change of 
 tau, so that the gain remains. This became the modified Allan deviation 
 (MDEV), and was inspired by the methods for improving frequency measures for 
 lasers as presented by J.J. Snyder in 1980 and 1981. J.J. Snyder was doing 
 what you proposes, averaging of blocks, and then extended this in software, 
 and this became a direct inspiration for the MDEV development, which does a 
 pre-averaging over tau before processing through ADEV, and this combined is 
 the MDEV.
 
 Doing TIC averaging and then continue the processing with MDEV processing 
 should produce a proper MDEV curve, unless my tired brain does not miss out 
 on details. If you then analyze it as a MDEV (rather than ADEV) then you use 
 the 

Re: [time-nuts] ADEV measurement question

[Matthias Jelen]

Dear John  Magnus,

thank you very much for your detailed explanation. I realize 
that the averaging topic is much more complex than I thought 
- it certainly gives me something to think about :-) I never 
thought in terms of noise bandwith in this application, 
thanks for putting me on this track.


It seems that the simplest and safest way to get meaningfull 
results is to hook up two mixers and a hand full of opamps 
and comparators.


To learn more, I think the best way would be to put the 
counter into its fast binary mode and acquire 1k time 
interval samples per second. That would give me loads of 
data to play with and it would be easy to try out how 
different averaging schemes affect the result.


I´ll have to read and think some more :-)

Cheers,

Matthias


Am 19.08.2015 um 21:52 schrieb Magnus Danielson:

Dear Mathias,

On 08/19/2015 06:40 PM, Matthias Jelen wrote:

Hello,

I´ve got a question concerning ADEV-measurements.

I´m measuring the 15 MHz output of a KS-24361 with my 
SR-620 with it´s
internal (Wenzel) OCXO using Timelab. For the first shot 
I used the
counters frequency mode with 1s gatetime. ADEV at tau=1s 
turned out to
be arounf 2E-11, which fits the 20 ps single shot 
resolution of the

SR-620 nicely.

To overcome this limitation without setting up a DMTD 
system, I used the
counter as TIC, feeding 1 kHz (derived from the counter´s 
reference) to
the start channel, the 15 MHz to the stop channel and put 
the counter
into average mode / 1k samples. This gives me one 
averaged result per

second.

The idea was that this shouldn´t change the measurement 
itself, because
like in frequency mode with 1s gate time I get the 
averaged value over
one second, but I expected trigger noise etc. to be 
averaged out to a
certain amount. I have to watch out for phase wraps, but 
as the two

frequencys are quite equal, this is not a big issue here.

As expected, ADEV at tau=1s got much better, it is now in 
the 4E-12

area, which sound reasonable.

What makes me wonder is the fact that result are 
significantly better
now at longer taus (10..100s) also, despite of the fact 
that also in
frequency mode these result were well aboce the noise 
floor (2E-12 @ 10s

and so on...).

So, is it a good idea to use this kind of averaging, or 
am I overlooking
something which turns the numbers better than they really 
are? I´m

pretty sure I am not the first one to try this...

I´m looking forward to your comments.


OK, averaging or filtering of data before ADEV processing 
is tricky, as it filters the data. Whenever you do that, 
you actually convert your measurement from an ADEV measure 
to something else. If you do proper post-processing, this 
something else can have known properties and thus we can 
relate the amplitude of the curve to amplitude of various 
noise sources, as it will cause biasing from the ADEV 
properties.


The reason you get better results is because the ADEV 
response on white noise depends on the measurement system 
bandwidth (see Allan deviation wikipedia page), and by 
averaging you do reduce the bandwidth.


Sometimes when you do this, you loose the gain as you 
increase the tau, since the dominant frequency will lower 
and become more and more into the pass-band of the fixed 
bandwidth filter you created. What you see is that it 
flattens out to the length of the average before lowering 
down, as if there was no filtering, so you have only 
achieved a gain in skewed value for very short taus, but 
then no gain at all for longer taus, so no real gain.


This was realized in 1980-1981 and in 1981 an article was 
published in which they realized that they can change the 
bandwidth along-side the change of tau, so that the gain 
remains. This became the modified Allan deviation (MDEV), 
and was inspired by the methods for improving frequency 
measures for lasers as presented by J.J. Snyder in 1980 
and 1981. J.J. Snyder was doing what you proposes, 
averaging of blocks, and then extended this in software, 
and this became a direct inspiration for the MDEV 
development, which does a pre-averaging over tau before 
processing through ADEV, and this combined is the MDEV.


Doing TIC averaging and then continue the processing with 
MDEV processing should produce a proper MDEV curve, unless 
my tired brain does not miss out on details. If you then 
analyze it as a MDEV (rather than ADEV) then you use the 
values properly. MDEV have the benefit that white phase 
noise drops by tau^-1.5 rather than the ADEV tau^-1, and 
starting with the SR-620 means you for fairly low taus hit 
actual measurement noise. The averaging makes this trip 
from tau0 of 1 ms in your setup.


So, you can go down this route, but you need to be careful 
to ensure that you have done the processing correctly 
enough that you get the results that can be interpreted 
properly.


Oh, as you average, phase-unwrapping becomes 
interesting. :)


Cheers,
Magnus
___
time-nuts 

Re: [time-nuts] ADEV measurement question

[Magnus Danielson]

Dear Mathias,

On 08/19/2015 06:40 PM, Matthias Jelen wrote:

Hello,

I´ve got a question concerning ADEV-measurements.

I´m measuring the 15 MHz output of a KS-24361 with my SR-620 with it´s
internal (Wenzel) OCXO using Timelab. For the first shot I used the
counters frequency mode with 1s gatetime. ADEV at tau=1s turned out to
be arounf 2E-11, which fits the 20 ps single shot resolution of the
SR-620 nicely.

To overcome this limitation without setting up a DMTD system, I used the
counter as TIC, feeding 1 kHz (derived from the counter´s reference) to
the start channel, the 15 MHz to the stop channel and put the counter
into average mode / 1k samples. This gives me one averaged result per
second.

The idea was that this shouldn´t change the measurement itself, because
like in frequency mode with 1s gate time I get the averaged value over
one second, but I expected trigger noise etc. to be averaged out to a
certain amount. I have to watch out for phase wraps, but as the two
frequencys are quite equal, this is not a big issue here.

As expected, ADEV at tau=1s got much better, it is now in the 4E-12
area, which sound reasonable.

What makes me wonder is the fact that result are significantly better
now at longer taus (10..100s) also, despite of the fact that also in
frequency mode these result were well aboce the noise floor (2E-12 @ 10s
and so on...).

So, is it a good idea to use this kind of averaging, or am I overlooking
something which turns the numbers better than they really are? I´m
pretty sure I am not the first one to try this...

I´m looking forward to your comments.


OK, averaging or filtering of data before ADEV processing is tricky, as 
it filters the data. Whenever you do that, you actually convert your 
measurement from an ADEV measure to something else. If you do proper 
post-processing, this something else can have known properties and thus 
we can relate the amplitude of the curve to amplitude of various noise 
sources, as it will cause biasing from the ADEV properties.


The reason you get better results is because the ADEV response on white 
noise depends on the measurement system bandwidth (see Allan deviation 
wikipedia page), and by averaging you do reduce the bandwidth.


Sometimes when you do this, you loose the gain as you increase the tau, 
since the dominant frequency will lower and become more and more into 
the pass-band of the fixed bandwidth filter you created. What you see is 
that it flattens out to the length of the average before lowering down, 
as if there was no filtering, so you have only achieved a gain in skewed 
value for very short taus, but then no gain at all for longer taus, so 
no real gain.


This was realized in 1980-1981 and in 1981 an article was published in 
which they realized that they can change the bandwidth along-side the 
change of tau, so that the gain remains. This became the modified Allan 
deviation (MDEV), and was inspired by the methods for improving 
frequency measures for lasers as presented by J.J. Snyder in 1980 and 
1981. J.J. Snyder was doing what you proposes, averaging of blocks, and 
then extended this in software, and this became a direct inspiration for 
the MDEV development, which does a pre-averaging over tau before 
processing through ADEV, and this combined is the MDEV.


Doing TIC averaging and then continue the processing with MDEV 
processing should produce a proper MDEV curve, unless my tired brain 
does not miss out on details. If you then analyze it as a MDEV (rather 
than ADEV) then you use the values properly. MDEV have the benefit that 
white phase noise drops by tau^-1.5 rather than the ADEV tau^-1, and 
starting with the SR-620 means you for fairly low taus hit actual 
measurement noise. The averaging makes this trip from tau0 of 1 ms in 
your setup.


So, you can go down this route, but you need to be careful to ensure 
that you have done the processing correctly enough that you get the 
results that can be interpreted properly.


Oh, as you average, phase-unwrapping becomes interesting. :)

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 measurement question

[John Miles]

I think the simplest way to explain the evils of TI averaging is that white 
noise doesn't alias in a conventional sense.  If a value is perfectly random, 
then it doesn't matter how you sample it.  Your sampling bandwidth -- and 
nothing else -- determines how much energy you get.  You can legitimately 
change that bandwidth after the fact by resampling or averaging the data.  
(Another way to say this is that components of the white noise spectrum above 
the Nyquist frequency don't have a net effect on the observed spectrum.)  But 
this is only true for white noise; with any other variety of signal or noise 
energy, once it's sampled, it's there for good.  

So, postprocessing a sampled stream with averaging has the effect of reducing 
the white-noise component of the data to a greater extent than the rest.  This 
is why you see tend to see 'better' results from an MDEV plot than an ADEV 
plot.  MDEV has some built-in averaging properties, while ADEV does not.  
Energy in a given part of the spectrum will influence an ADEV plot to a greater 
extent than with MDEV.  

ADEV isn't particularly frequency-selective.  If you've ever seen 1-pps or 
50/60 Hz interference in an ADEV plot, you've noticed that its influence can 
corrupt the plot for the next decade or two.   So if you must use your 
counter's averaging feature to get good ADEV plots, it's important to carry out 
that averaging at a very small fraction of the tau-zero interval.  The more 
1/f^n noise is present in your measurement, the more important that becomes.  
Otherwise you end up with a transfer function that isn't really ADEV, even 
though that's what the label on the plot says it is.  

This gets more complicated with counters that dither their sampling clock, 
and/or apply other filter functions in their averaging process.  Some appear to 
be give better ADEV fidelity than others.  If nothing else, I would expect that 
averaging at sub-t0 intervals would introduce a dead-time effect in the portion 
of t0 over which the data is not contributing to the average.  It is always 
going to be better to avoid TI averaging whenever possible, and use great care 
in interpreting the data.

-- john, KE5FX
Miles Design LLC


 -Original Message-
 From: time-nuts [mailto:time-nuts-boun...@febo.com] On Behalf Of Matthias
 Jelen
 Sent: Wednesday, August 19, 2015 9:40 AM
 To: Discussion of precise time and frequency measurement
 Subject: [time-nuts] ADEV measurement question
 
 Hello,
 
 I´ve got a question concerning ADEV-measurements.
 
 I´m measuring the 15 MHz output of a KS-24361 with my SR-620
 with it´s internal (Wenzel) OCXO using Timelab. For the
 first shot I used the counters frequency mode with 1s
 gatetime. ADEV at tau=1s turned out to be arounf 2E-11,
 which fits the 20 ps single shot resolution of the SR-620
 nicely.
 
 To overcome this limitation without setting up a DMTD
 system, I used the counter as TIC, feeding 1 kHz (derived
 from the counter´s reference) to the start channel, the 15
 MHz to the stop channel and put the counter into average
 mode / 1k samples. This gives me one averaged result per second.
 
 The idea was that this shouldn´t change the measurement
 itself, because like in frequency mode with 1s gate time I
 get the averaged value over one second, but I expected
 trigger noise etc. to be averaged out to a certain amount. I
 have to watch out for phase wraps, but as the two frequencys
 are quite equal, this is not a big issue here.
 
 As expected, ADEV at tau=1s got much better, it is now in
 the 4E-12 area, which sound reasonable.
 
 What makes me wonder is the fact that result are
 significantly better now at longer taus (10..100s) also,
 despite of the fact that also in frequency mode these result
 were well aboce the noise floor (2E-12 @ 10s and so on...).
 
 So, is it a good idea to use this kind of averaging, or am I
 overlooking something which turns the numbers better than
 they really are? I´m pretty sure I am not the first one to
 try this...
 
 I´m looking forward to your comments.
 
 Best regards,
 
 Matthias
 ___
 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 with very short Tau

[claude . ff]

Thanks to you three for the answers.

I don't have the skills to make a frequency mixer yet, but if I think a good 
tutorial, I can try !

My goal is to estimate the stability of a rubidium at 0.1s,1s and 10s. I have a 
GPSDO, some picDiv and one Pulse Generator.
I believe the OCXO in the GPSDO (a HP 58530A) is better in stability than the 
Rubidium for shorts taus even if it has not a clear view of the sky (it doesn't 
see 6 satellites all the time) so I locked the 53131A counter to the GPSDO.

I made some tests with TI measurements, see attached picture.

In order to going to 0.1s, I generate 10 Hz on the pulse generator locked on 
the GPSDO (channel 1 of the counter) and feed the channel 2 with rubidium's 10 
MHz.
I get 
ADEV(0.1s) = 1.1 E-8 
ADEV(1s)   = 1.1 E-9
ADEV(10s)  = 1.1 E-10

It's not wonderful, but I will be happy if I can measure 1E-9 at 0.1s.

In fact, I think  I measure the noise floor of the Pulse Generator. So I need 
to improve the setup.

I manage to measure TI every 0.1s but when I want to measure frequency with 
Gate Time at 0.1s (with poor resolution I agree, but I will have access to a 
Frequency Difference Multiplier soon) it seems there is gaps in the records :

for example,TI record gives with 10 Hz on channel 1:
1430740210.00.0007515140
1430740210.10.0007515140
1430740210.50.0007515140
1430740210.60.0007515125
1430740210.70.0007515150
1430740210.80.0007515140
1430740210.90.0007515135

Frequency record with Gate Time 1 s gives:
1430741572.77   1000.000
1430741573.96   1000.001
1430741575.15   1000.001
1430741576.34   1000.000
1430741577.53   1000.001
1430741578.72   1000.001
1430741579.92   1000.001
1430741581.11   1000.000


Frequency record with Gate Time 0.1 s gives :
1430741673.61000.00
1430741673.89   1000.00
1430741674.18   1000.00
1430741674.47   1000.00
1430741674.77   1000.00
1430741675.06   1000.00
1430741675.35   1000.00


First colomn is timestamp of the computer, I disabled auto trigger on the 
counter. 
What are the gaps in the frequency records, are they Dead Time ? They look to 
be constant, about 0,2s even when the Gate Time is 10s. Are they a problem for 
ADEV calculation?

Thanks

Claude

- Mail original -
De: Charles Steinmetz csteinm...@yandex.com
À: Discussion of precise time and frequency measurement time-nuts@febo.com
Envoyé: Mercredi 29 Avril 2015 22:04:14
Objet: Re: [time-nuts] ADEV with very short Tau

Claude wrote:

I know how to measure ADEV with frequency method (using a 53131A 
counter) or time difference method (using 1 PPS of a GPSDO for 
example) but I would like to measure ADEV in the sub-second domain 
(from 0.1s to 1s for example). Do I need a Time Interval Analyzer, 
if so, an HP 5371A is ok for that ? Or there are simpliest method ?

You may do better with a Phase Noise measurement, depending on what 
instruments you have available.

Generally, we think of oscillator stability over times = 1 second in 
the time domain, as xDEV, and stability over times = 1 second (or 
so) (offsets = 1 Hz) in the frequency domain, as Phase 
Noise.  Partly, this is because of the different kinds of phenomena 
we are concerned about on the two different scales, and partly 
because different measurement techniques are better suited to each of 
the two time scales.

These limits are not absolute, particularly if you digitize signals 
at a high sample rate with high resolution and do the analysis in the 
digital domain.  Fancy xDEV/PN analyzers, such as the Microsemi 
5125A, can measure xDEV down to tau = 1 mS and PN below a 1mHz 
offset.  (But sit down before you ask the price.)

I usually measure xDEV down to 0.1 second, and PN at offsets = 1 
Hz.  Of course, to measure xDEV at 0.1 second, you need to take at 
least ten TI or frequency measurements per second with no dead time 
between measurements, and with good accuracy -- so you need an 
instrument with very high resolution at short gate times and fairly 
fast data throughput.  For that, I use a Wavecrest DTS2075.

Best regards,

Charles



___
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 with very short Tau

[Bob Camp]

Hi

The cheap / simple approach for ADEV is a single or dual mixer setup. Mix the 
signal(s) down to an audio frequency and measure those. Mix down
frequencies like 10 KHz will let you measure some pretty short Tau’s. 

If you want a purchased single box solution, then something like a TimePod will 
be needed. 

There are a multitude of options other than those ….

Bob


 On Apr 29, 2015, at 5:29 AM, claude...@aliceadsl.fr wrote:
 
 Hello
 
 I know how to measure ADEV with frequency method (using a 53131A counter) or 
 time difference method (using 1 PPS of a GPSDO for example) but I would like 
 to measure ADEV in the sub-second domain (from 0.1s to 1s for example). Do I 
 need a Time Interval Analyzer, if so, an HP 5371A is ok for that ? Or there 
 are simpliest method ?
 
 Thanks for your advices.
 
 
 Claude
 ___
 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 with very short Tau

[WarrenS via time-nuts]

Claude

what is the simplest method to measure sub second ADEV?

The answer depends on many unstated things.
Among them is your definition of simple, the Frequency of the DUT, the noise 
floor, your budget and your available time.. 

After budget and frequency, the next most important thing is the noise floor or 
resolution that you want.
Many of sub second ADEV plots you see end up showing the limitations of the 
tester and not the DUT.

One answer
If you want meaningful ADEV numbers at 0.1 sec, it is best to sample at = 20 
samples per second.
I find sampling at line freq or its multiple  has several advantages to allow 
good repeatable results for 0.1 sec ADEV.
For North American  that means a sample rate of 60 or 120Hz.

If you want to test Time-nut type oscillators with ADEV's below 1e-11 then you 
will need something with sub Pico second resolution.
Also measuring a  frequency of  5 or 10 MHz, instead of measuring say a 20 pps 
divided down signal has many advantages.

After defining the frequency and resolution you want, it comes down to what you 
mean by simple..

If you need to do it just once,  find a Time-nuts that already has the right 
capability and is willing to measure it for you.
If simples does not include budget get a TimePod.
If simple includes low cost and you need a low noise floor, then you're going 
to have to consider some custom built thing.
Who is doing the building, depends on how you value your time.

ws


**
Hello

I know how to measure ADEV with frequency method (using a 53131A counter) or 
time difference method (using 1 PPS of a GPSDO for example) but I would like to 
measure ADEV in the sub-second domain (from 0.1s to 1s for example). Do I need 
a Time Interval Analyzer, if so, an HP 5371A is ok for that ? Or there are 
simpliest method ?

Thanks for your advices.

Claude
___
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 with very short Tau

[Charles Steinmetz]

Claude wrote:

I know how to measure ADEV with frequency method (using a 53131A 
counter) or time difference method (using 1 PPS of a GPSDO for 
example) but I would like to measure ADEV in the sub-second domain 
(from 0.1s to 1s for example). Do I need a Time Interval Analyzer, 
if so, an HP 5371A is ok for that ? Or there are simpliest method ?


You may do better with a Phase Noise measurement, depending on what 
instruments you have available.


Generally, we think of oscillator stability over times = 1 second in 
the time domain, as xDEV, and stability over times = 1 second (or 
so) (offsets = 1 Hz) in the frequency domain, as Phase 
Noise.  Partly, this is because of the different kinds of phenomena 
we are concerned about on the two different scales, and partly 
because different measurement techniques are better suited to each of 
the two time scales.


These limits are not absolute, particularly if you digitize signals 
at a high sample rate with high resolution and do the analysis in the 
digital domain.  Fancy xDEV/PN analyzers, such as the Microsemi 
5125A, can measure xDEV down to tau = 1 mS and PN below a 1mHz 
offset.  (But sit down before you ask the price.)


I usually measure xDEV down to 0.1 second, and PN at offsets = 1 
Hz.  Of course, to measure xDEV at 0.1 second, you need to take at 
least ten TI or frequency measurements per second with no dead time 
between measurements, and with good accuracy -- so you need an 
instrument with very high resolution at short gate times and fairly 
fast data throughput.  For that, I use a Wavecrest DTS2075.


Best regards,

Charles



___
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 noise floor vs counter gate time

[James via time-nuts]

Hi Bill,

I'm travelling at the moment, but I had another go just now and it has stopped 
wiping my details when I press the save button so hopefully that means it is 
fixed.

I must just have been unlucky and picked a glitchy day (this was at the end of 
last week).

Though, now that I've downloaded NI-VISA and got that working I probably don't 
need to download tek-VISA.

Best Regards,

James


 

 

 

-Original Message-
From: Bill Byrom t...@radio.sent.com
To: time-nuts time-nuts@febo.com
Sent: Sun, 22 Mar 2015 20:28
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time


Was the website problem this past week? The main Tek US website was
acting up
for a while one day this week, but seems to be fine now. I
have no insights on
European access. 

-- 
Bill Byrom N5BB

On Sun, Mar 22, 2015, at 07:10 AM,
James via time-nuts wrote:
 Hi Bill,
 
 Thanks for the pointers.
 
 I
should say that my results reported so far have been with my older TTi
 TF930
reciprocal counter, not with my FCA3100 which I have only just got
 (it
arrived a few days ago) and I'm in the process of writing software to
 talk to
it via the USB.
 
 I did discover the website, in fact I'd downloaded the
manual before
 buying the counter, and it is fortunate I did because the
website for me
 didn't work - I'm currently talking to Tek support about
it.
 
 The problem is that to download software you must have your
details
 registered. Every time I register my details and press the save
button
 the site wipes all my details and returns to a blank form. When I try
to
 down load the software it then stops me and tells me to update my

details. I update my details and it blanks the form and so on... slightly

frustrating. I've tried both Firefox and IE.
 
 The other thing is that the
manuals don't show on the European site (I'm
 in the UK), you click on them
but the download screen just shows a blank
 line. I got round this by going to
the international site and just
 closing the screen asking me for my area
rather than responding to it - I
 had to do this several times.
 
 I have
now downloaded NI-VISA and have managed to do a bit of talking to
 the
instrument over USB though I've not yet had time to do this properly.
 
 So
in summary - I'm pleased with my counter but the Tek website for
 Europe at
least has some serious bugs which hopefully will be fixed soon.
 The Tek
support person I spoke to on the phone was helpful but she wasn't
 in a
position to fix the web site issues directly so has forwarded my
 case to Tek
IT.
 
 I intend repeating my TTi TF930 experiment with my FCA3100 when I've
got
 everything working ok and am looking forward to seeing the results.


 James
 
  
 
  
 
  
 
 -Original Message-
 From:
Bill Byrom t...@radio.sent.com
 To: time-nuts time-nuts@febo.com
 Sent:
Sun, 22 Mar 2015 2:27
 Subject: Re: [time-nuts] ADEV noise floor vs counter
gate time
 
 
 Hi, James. I'm a Tektronix RF Application Engineer in
Dallas and thought
 I
 would throw in a few points about your FCA3100 (if
you haven't read up
 on these
 already):
 
 All Tektronix manuals and
technical reference documents can
 be
 downloaded for no charge on our
website (http://www.tek.com), but
 some
 items may require you to register
and sign in. The detailed
 specification
 and performance verification
document (document number
 077-0495-01) has many
 details about the
specifications, and is
 at:

http://www.tek.com/frequency-counter-supplies/mca3027-manual/fca3000-and-fca3100-series-mca3000-series


 All
 downloadable files for this product can be found in the list

at:
 http://www.tek.com/search/apachesolr_search/fca3000 If you have a

used
 counter, be sure you check the firmware version and update it if

needed.
 
 If your exact model is FCA3000, you have a 300 MHz counter with
100
 ps
 single-shot resolution. This counter has reciprocal counter
features
 (based
 on a 10 ns main counter time resolution), but also uses
100 ps
 RMS jitter
 interpolation to determine edge location with an
additional
 X100 resolution.
 When the initial edge of the signal you are
measuring
 is detected, the
 interpolater resolves this edge with 100 ps
resolution
 relative to the internal
 10 ns clock. After the desired
measurement
 interval, the final edge is also
 resolved with 100 ps
resolution, and
 the number of signal edges and
 interpolated
intitial-to-final time are
 used to determine the frequency (for
 example).
The analog interpolation
 circuit uses a constant current charging a

capacitor with a sampler and
 A/D converter. Counting a 100 MHz signal,
this
 provides 12 digits of
 resolution per second of measurement

interval.
 
 --
 Bill Byrom N5BB
 
 
 
 On Wed, Mar 18, 2015, at
05:49 PM, James
 via time-nuts wrote:
  Hi Dave,
 
  Thanks for
another detailed
 response.
 
  I've now programmed a version of my code
that attempts to
 recover the
  raw data by trying different counts up and
down from the nominal
 and
  finding the one

Re: [time-nuts] ADEV noise floor vs counter gate time

[James via time-nuts]

Hi Bill,

Thanks for the pointers.

I should say that my results reported so far have been with my older TTi TF930 
reciprocal counter, not with my FCA3100 which I have only just got (it arrived 
a few days ago) and I'm in the process of writing software to talk to it via 
the USB.

I did discover the website, in fact I'd downloaded the manual before buying the 
counter, and it is fortunate I did because the website for me didn't work - I'm 
currently talking to Tek support about it.

The problem is that to download software you must have your details registered. 
Every time I register my details and press the save button the site wipes all 
my details and returns to a blank form. When I try to down load the software it 
then stops me and tells me to update my details. I update my details and it 
blanks the form and so on... slightly frustrating. I've tried both Firefox and 
IE.

The other thing is that the manuals don't show on the European site (I'm in the 
UK), you click on them but the download screen just shows a blank line. I got 
round this by going to the international site and just closing the screen 
asking me for my area rather than responding to it - I had to do this several 
times.

I have now downloaded NI-VISA and have managed to do a bit of talking to the 
instrument over USB though I've not yet had time to do this properly.

So in summary - I'm pleased with my counter but the Tek website for Europe at 
least has some serious bugs which hopefully will be fixed soon. The Tek support 
person I spoke to on the phone was helpful but she wasn't in a position to fix 
the web site issues directly so has forwarded my case to Tek IT.

I intend repeating my TTi TF930 experiment with my FCA3100 when I've got 
everything working ok and am looking forward to seeing the results.

James

 

 

 

-Original Message-
From: Bill Byrom t...@radio.sent.com
To: time-nuts time-nuts@febo.com
Sent: Sun, 22 Mar 2015 2:27
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time


Hi, James. I'm a Tektronix RF Application Engineer in Dallas and thought
I
would throw in a few points about your FCA3100 (if you haven't read up
on these
already):

All Tektronix manuals and technical reference documents can
be
downloaded for no charge on our website (http://www.tek.com), but
some
items may require you to register and sign in. The detailed
specification
and performance verification document (document number
077-0495-01) has many
details about the specifications, and is
at:
http://www.tek.com/frequency-counter-supplies/mca3027-manual/fca3000-and-fca3100-series-mca3000-series

All
downloadable files for this product can be found in the list
at:
http://www.tek.com/search/apachesolr_search/fca3000 If you have a
used
counter, be sure you check the firmware version and update it if
needed.

If your exact model is FCA3000, you have a 300 MHz counter with 100
ps
single-shot resolution. This counter has reciprocal counter features
(based
on a 10 ns main counter time resolution), but also uses 100 ps
RMS jitter
interpolation to determine edge location with an additional
X100 resolution.
When the initial edge of the signal you are measuring
is detected, the
interpolater resolves this edge with 100 ps resolution
relative to the internal
10 ns clock. After the desired measurement
interval, the final edge is also
resolved with 100 ps resolution, and
the number of signal edges and
interpolated intitial-to-final time are
used to determine the frequency (for
example). The analog interpolation
circuit uses a constant current charging a
capacitor with a sampler and
A/D converter. Counting a 100 MHz signal, this
provides 12 digits of
resolution per second of measurement
interval.

--
Bill Byrom N5BB



On Wed, Mar 18, 2015, at 05:49 PM, James
via time-nuts wrote:
 Hi Dave,

 Thanks for another detailed
response.

 I've now programmed a version of my code that attempts to
recover the
 raw data by trying different counts up and down from the nominal
and
 finding the one with the smallest rounding error.

 One problem is I
need to restrain the amount it goes up or down
 otherwise it finds erroneously
small or large numbers of cycles (+/- 2
 is believable, more than that
isn't).

 As an experiment I then changed the data to match the raw data.
This
 doesn't change the shape of the curve but it lowers it so it starts

below 10^-15! This is suspiciously good so I think I'm smoothing out
 changes
that are really there.

 Now that my new fca3100 has arrived I'm hoping to
find time to get
 measurements with it which should be proper time-stamped
ones and much
 more accurate - then I can compare the two.

 To answer
your question on ADEV aggregating values, and speaking as a
 total newbee
myself, the approach to different tau sizes is to
 aggregate all measurements
within a bin of size tau and average the
 frequencies (or average the time
differences and invert - for small
 variations it makes very little difference
as (1+delta)^-1 is 1

Re: [time-nuts] ADEV noise floor vs counter gate time

[Bill Byrom]

Was the website problem this past week? The main Tek US website was
acting up for a while one day this week, but seems to be fine now. I
have no insights on European access. 

-- 
Bill Byrom N5BB

On Sun, Mar 22, 2015, at 07:10 AM, James via time-nuts wrote:
 Hi Bill,
 
 Thanks for the pointers.
 
 I should say that my results reported so far have been with my older TTi
 TF930 reciprocal counter, not with my FCA3100 which I have only just got
 (it arrived a few days ago) and I'm in the process of writing software to
 talk to it via the USB.
 
 I did discover the website, in fact I'd downloaded the manual before
 buying the counter, and it is fortunate I did because the website for me
 didn't work - I'm currently talking to Tek support about it.
 
 The problem is that to download software you must have your details
 registered. Every time I register my details and press the save button
 the site wipes all my details and returns to a blank form. When I try to
 down load the software it then stops me and tells me to update my
 details. I update my details and it blanks the form and so on... slightly
 frustrating. I've tried both Firefox and IE.
 
 The other thing is that the manuals don't show on the European site (I'm
 in the UK), you click on them but the download screen just shows a blank
 line. I got round this by going to the international site and just
 closing the screen asking me for my area rather than responding to it - I
 had to do this several times.
 
 I have now downloaded NI-VISA and have managed to do a bit of talking to
 the instrument over USB though I've not yet had time to do this properly.
 
 So in summary - I'm pleased with my counter but the Tek website for
 Europe at least has some serious bugs which hopefully will be fixed soon.
 The Tek support person I spoke to on the phone was helpful but she wasn't
 in a position to fix the web site issues directly so has forwarded my
 case to Tek IT.
 
 I intend repeating my TTi TF930 experiment with my FCA3100 when I've got
 everything working ok and am looking forward to seeing the results.
 
 James
 
  
 
  
 
  
 
 -Original Message-
 From: Bill Byrom t...@radio.sent.com
 To: time-nuts time-nuts@febo.com
 Sent: Sun, 22 Mar 2015 2:27
 Subject: Re: [time-nuts] ADEV noise floor vs counter gate time
 
 
 Hi, James. I'm a Tektronix RF Application Engineer in Dallas and thought
 I
 would throw in a few points about your FCA3100 (if you haven't read up
 on these
 already):
 
 All Tektronix manuals and technical reference documents can
 be
 downloaded for no charge on our website (http://www.tek.com), but
 some
 items may require you to register and sign in. The detailed
 specification
 and performance verification document (document number
 077-0495-01) has many
 details about the specifications, and is
 at:
 http://www.tek.com/frequency-counter-supplies/mca3027-manual/fca3000-and-fca3100-series-mca3000-series
 
 All
 downloadable files for this product can be found in the list
 at:
 http://www.tek.com/search/apachesolr_search/fca3000 If you have a
 used
 counter, be sure you check the firmware version and update it if
 needed.
 
 If your exact model is FCA3000, you have a 300 MHz counter with 100
 ps
 single-shot resolution. This counter has reciprocal counter features
 (based
 on a 10 ns main counter time resolution), but also uses 100 ps
 RMS jitter
 interpolation to determine edge location with an additional
 X100 resolution.
 When the initial edge of the signal you are measuring
 is detected, the
 interpolater resolves this edge with 100 ps resolution
 relative to the internal
 10 ns clock. After the desired measurement
 interval, the final edge is also
 resolved with 100 ps resolution, and
 the number of signal edges and
 interpolated intitial-to-final time are
 used to determine the frequency (for
 example). The analog interpolation
 circuit uses a constant current charging a
 capacitor with a sampler and
 A/D converter. Counting a 100 MHz signal, this
 provides 12 digits of
 resolution per second of measurement
 interval.
 
 --
 Bill Byrom N5BB
 
 
 
 On Wed, Mar 18, 2015, at 05:49 PM, James
 via time-nuts wrote:
  Hi Dave,
 
  Thanks for another detailed
 response.
 
  I've now programmed a version of my code that attempts to
 recover the
  raw data by trying different counts up and down from the nominal
 and
  finding the one with the smallest rounding error.
 
  One problem is I
 need to restrain the amount it goes up or down
  otherwise it finds erroneously
 small or large numbers of cycles (+/- 2
  is believable, more than that
 isn't).
 
  As an experiment I then changed the data to match the raw data.
 This
  doesn't change the shape of the curve but it lowers it so it starts
 
 below 10^-15! This is suspiciously good so I think I'm smoothing out
  changes
 that are really there.
 
  Now that my new fca3100 has arrived I'm hoping to
 find time to get
  measurements with it which should be proper time-stamped
 ones and much

Re: [time-nuts] ADEV noise floor vs counter gate time

[Bill Byrom]

Hi, James. I'm a Tektronix RF Application Engineer in Dallas and thought
I would throw in a few points about your FCA3100 (if you haven't read up
on these already):

All Tektronix manuals and technical reference documents can be
downloaded for no charge on our website (http://www.tek.com), but some
items may require you to register and sign in. The detailed
specification and performance verification document (document number
077-0495-01) has many details about the specifications, and is at:
http://www.tek.com/frequency-counter-supplies/mca3027-manual/fca3000-and-fca3100-series-mca3000-series

All downloadable files for this product can be found in the list at:
http://www.tek.com/search/apachesolr_search/fca3000 If you have a used
counter, be sure you check the firmware version and update it if needed.

If your exact model is FCA3000, you have a 300 MHz counter with 100 ps
single-shot resolution. This counter has reciprocal counter features
(based on a 10 ns main counter time resolution), but also uses 100 ps
RMS jitter interpolation to determine edge location with an additional
X100 resolution. When the initial edge of the signal you are measuring
is detected, the interpolater resolves this edge with 100 ps resolution
relative to the internal 10 ns clock. After the desired measurement
interval, the final edge is also resolved with 100 ps resolution, and
the number of signal edges and interpolated intitial-to-final time are
used to determine the frequency (for example). The analog interpolation
circuit uses a constant current charging a capacitor with a sampler and
A/D converter. Counting a 100 MHz signal, this provides 12 digits of
resolution per second of measurement interval.

--
Bill Byrom N5BB



On Wed, Mar 18, 2015, at 05:49 PM, James via time-nuts wrote:
 Hi Dave,

 Thanks for another detailed response.

 I've now programmed a version of my code that attempts to recover the
 raw data by trying different counts up and down from the nominal and
 finding the one with the smallest rounding error.

 One problem is I need to restrain the amount it goes up or down
 otherwise it finds erroneously small or large numbers of cycles (+/- 2
 is believable, more than that isn't).

 As an experiment I then changed the data to match the raw data. This
 doesn't change the shape of the curve but it lowers it so it starts
 below 10^-15! This is suspiciously good so I think I'm smoothing out
 changes that are really there.

 Now that my new fca3100 has arrived I'm hoping to find time to get
 measurements with it which should be proper time-stamped ones and much
 more accurate - then I can compare the two.

 To answer your question on ADEV aggregating values, and speaking as a
 total newbee myself, the approach to different tau sizes is to
 aggregate all measurements within a bin of size tau and average the
 frequencies (or average the time differences and invert - for small
 variations it makes very little difference as (1+delta)^-1 is 1-delta
 ignoring delta*delta terms). Then each term in the Alan Variaton
 summation is the square of the difference between the average
 frequency in adjacent bins.

 So with 1 second values at a tau of 100 secs, 100 values in each cell
 are averaged whilst the 100 sec gate value results just have a single
 value for each bin. But given that the counter itself should be
 averaging there should be good agreement between the two - hence my
 puzzlement.

 The fca3100 calculates ADEV directly so I'll have a check on my code.

 James







 -Original Message- From: Dave Martindale
 dave.martind...@gmail.com To: jpbridge jpbri...@aol.com
 CC: Discussion of precise time and frequency measurement
 time-nuts@febo.com Sent: Wed, 18 Mar 2015 15:22 Subject: Re:
 [time-nuts] ADEV noise floor vs counter gate time



 The counter always has a 1 count uncertainty in the timebase
 measurement, which is a 2e-8 error with a 1 second gate time. If the
 value being displayed starts with the digit 9, and 8 digits are
 displayed, then that translates to +- 2 counts in the last place. But
 the measurements are synchronized to the input signal, so it always
 measures an integer number of input cycles, and there should be no
 comparable uncertainty in the input (other than some noise in deciding
 exactly when the edge crosses the input threshold, which should be
 tiny compared to the 20 ns timebase period).



 But that's comparing the counter reading to the real world. My table
 was comparing the displayed output to the likely raw measurements, and
 it seems to show that the counter's internal math is being performed
 to the full 10 digits of precision in the USB data, even when the gate
 time supports only 8 bits of accuracy. That's good news because it
 allows you to know when you have correctly guessed the input counts.




 When trying to calculate the raw data from the reading, you do need to
 try an input count of 91 in addition to 90 and 92. 91 did show up in
 the small sample of period

Re: [time-nuts] ADEV noise floor vs counter gate time

[James via time-nuts]

Hi Dave,

Interesting analysis. The accuracy stated in the manual is ...+ 2 counts and 
though this relates to the 50MHz clock, perhaps they use a similar algorithm 
for the input frequency.

I completed the 0.3 second measurements and the curve is similar to 1 second 
but higher up (i.e. as you'd expect by extrapolation from the behaviour of the 
other curves).

My ADEV calculation is based on the average frequency in each bin, the varying 
size of the bin should be insignificant as long as it is not affecting the 
average value within the bin. If the average frequency shifts by delta_F in one 
bin time step and the first bin is delta_T short (as a fraction of one bin time 
step) then the first frequency will be delta_T*delta_F low and the second bin 
perhaps that much high but the key point is that it is the product of the two 
deltas so it won't materially affect the accuracy of the calculation. At least 
I think that is correct.

Taking the worst possible case where the delta in bin size always went the 
wrong way so every term in the Alan Variance sum was multiplied by (1+2delta)^2 
then the final Alan deviation might be (1 + 2 delta) too big but as delta is of 
the order of 10E-8 or less this wouldn't even register on the graphs.

What I might try doing is programming your approach into the code to try and 
get at the raw data - I only need to try 88,90 and 92 as possible counts - 
though to be sure I'll try mean frequency +- 5 say and then try and get the 
50MHz clock values out as integers. What I might also do is then do a least 
squares fit (linear regression) to get the frequency over each bin and use the 
slope (this perhaps is what the counter does internally - I don't know).

I'd like to get to the bottom of this if only to understand my counter better.

James





 

 

 

-Original Message-
From: Dave Martindale dave.martind...@gmail.com
To: jpbridge jpbri...@aol.com; time-nuts time-nuts@febo.com
Sent: Wed, 18 Mar 2015 1:26
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time


 I believe I see the pattern.  As you figured out, you wouldn't expect a single 
period to be a multiple of 20 ns; you expect the length of (about) 90 periods 
to be an integer multiple of 50 ns, since that's what the counter actually 
measures.  Further, the measuring time isn't exactly 1 second, it is an integer 
number of periods of the input frequency that makes up at least 1 second.  If 
the counting logic was all hardware, you would expect to capture either 90 or 
91 cycles of the input, depending on whether the input frequency was slightly 
below or above 90 Hz respectively. 
  
 I built this table of your frequency data in Excel.  Math is 64-bit floating 
point, equivalent to about 16 decimal digits, so plenty accurate enough to 
simulate this counter: 
  
  ReadingInput Count TB Count  Rounded  Frequency   Interval 
  90.6359925074.998507590.63591.01500 
  90.7591925068.002506890.75911.01360 
  89.9640905002.000500289.96401.00040 
  89.8740905007.000500789.87401.00140 
  90.6007925076.997507790.60071.01540 
  89.6040905022.000502289.60401.00440 
  90.8648925061.999506290.86481.01240 
  90.8472925062.999506390.84721.01260 
  90.00011465925046.001504690.000114651.00920 
  90.00014459925028.998502990.000144591.00580 
  
 The first column is your data.  The second column is a guess about how many 
input cycles were captured.  The third column is the number of timebase cycles 
that have elapsed since the previous reading, based on the first two columns.  
I hand-tweaked the numbers in the second column until the number in the third 
column was within 0.003 of an integer.  The fact that I was always able to do 
this tells me that my guess is probably correct, and the small residual (which 
is a few parts in 1e-10) is due to the counter rounding the results to 10 
digits.  The 4th column is the result of rounding the previous column to the 
nearest integer.  This is what I believe is the actual number of counts the 
counter saw.  The 5th column is a fresh calculation of frequency, based on the 
integer number of input cycles in column 2 and the integer number of timebase 
cycles in column 4.  When the result is rounded to 10 digits, you can see it 
matches the 10 digits that the counter provided back in col
 umn 1. 
  
 Oddly, the counter never captured 91 input cycles.  If the input frequency was 
a little higher than 90 Hz, it always measured at 92 cycles, even though 91 
cycles was well more than 1 s since the previous reading.  I guess the 
microprocessor running the counter only checks periodically

Re: [time-nuts] ADEV noise floor vs counter gate time

[Dave Martindale]

 in the manual is ...+ 2 counts
 and though this relates to the 50MHz clock, perhaps they use a similar
 algorithm for the input frequency.

 I completed the 0.3 second measurements and the curve is similar to 1
 second but higher up (i.e. as you'd expect by extrapolation from the
 behaviour of the other curves).

 My ADEV calculation is based on the average frequency in each bin, the
 varying size of the bin should be insignificant as long as it is not
 affecting the average value within the bin. If the average frequency shifts
 by delta_F in one bin time step and the first bin is delta_T short (as a
 fraction of one bin time step) then the first frequency will be
 delta_T*delta_F low and the second bin perhaps that much high but the key
 point is that it is the product of the two deltas so it won't materially
 affect the accuracy of the calculation. At least I think that is correct.

 Taking the worst possible case where the delta in bin size always went the
 wrong way so every term in the Alan Variance sum was multiplied by
 (1+2delta)^2 then the final Alan deviation might be (1 + 2 delta) too big
 but as delta is of the order of 10E-8 or less this wouldn't even register
 on the graphs.

 What I might try doing is programming your approach into the code to try
 and get at the raw data - I only need to try 88,90 and 92 as possible
 counts - though to be sure I'll try mean frequency +- 5 say and then try
 and get the 50MHz clock values out as integers. What I might also do is
 then do a least squares fit (linear regression) to get the frequency over
 each bin and use the slope (this perhaps is what the counter does
 internally - I don't know).

 I'd like to get to the bottom of this if only to understand my counter
 better.

 James







  -Original Message-
 From: Dave Martindale dave.martind...@gmail.com
 To: jpbridge jpbri...@aol.com; time-nuts time-nuts@febo.com
 Sent: Wed, 18 Mar 2015 1:26
 Subject: Re: [time-nuts] ADEV noise floor vs counter gate time

  I believe I see the pattern.  As you figured out, you wouldn't expect a
 single period to be a multiple of 20 ns; you expect the length of (about)
 90 periods to be an integer multiple of 50 ns, since that's what the
 counter actually measures.  Further, the measuring time isn't exactly 1
 second, it is an integer number of periods of the input frequency that
 makes up at least 1 second.  If the counting logic was all hardware, you
 would expect to capture either 90 or 91 cycles of the input, depending on
 whether the input frequency was slightly below or above 90 Hz respectively.

 I built this table of your frequency data in Excel.  Math is 64-bit
 floating point, equivalent to about 16 decimal digits, so plenty accurate
 enough to simulate this counter:

 ReadingInput Count TB Count  Rounded  Frequency   Interval
  90.6359925074.998507590.6359
 1.01500
  90.7591925068.002506890.7591
 1.01360
  89.9640905002.000500289.9640
 1.00040
  89.8740905007.000500789.8740
 1.00140
  90.6007925076.997507790.6007
 1.01540
  89.6040905022.000502289.6040
 1.00440
  90.8648925061.999506290.8648
 1.01240
  90.8472925062.999506390.8472
 1.01260
  90.00011465925046.001504690.00011465
 1.00920
  90.00014459925028.998502990.00014459
 1.00580

 The first column is your data.  The second column is a guess about how
 many input cycles were captured.  The third column is the number of
 timebase cycles that have elapsed since the previous reading, based on the
 first two columns.  I hand-tweaked the numbers in the second column until
 the number in the third column was within 0.003 of an integer.  The fact
 that I was always able to do this tells me that my guess is probably
 correct, and the small residual (which is a few parts in 1e-10) is due to
 the counter rounding the results to 10 digits.  The 4th column is the
 result of rounding the previous column to the nearest integer.  This is
 what I believe is the actual number of counts the counter saw.  The 5th
 column is a fresh calculation of frequency, based on the integer number of
 input cycles in column 2 and the integer number of timebase cycles in
 column 4.  When the result is rounded to 10 digits, you can see it matches
 the 10 digits that the counter provided back in column 1.

 Oddly, the counter never captured 91 input cycles.  If the input frequency
 was a little higher than 90 Hz, it always measured at 92 cycles, even
 though 91 cycles was well more than 1 s since the previous reading.  I
 guess the microprocessor running the counter only checks periodically (e.g.
 every 20 ms) to see if the gate time has elapsed, and then latches the
 counts on the next

Re: [time-nuts] ADEV noise floor vs counter gate time

[Dave Martindale]

 and calculating a 10-digit period for display, the result 
always matched what the counter output.  Again, I think we know with high 
probability just how many input and timebase cycles were counted for each 
measurement.


I adjusted column 2 by eye, while looking at the results of column 3, but that 
process could be automated pretty easily (just not in Excel).  As I tried 90, 
91, and 92 in sequence, there was always just one of those which gave a small 
residual error.


So I think your TF930 is making measurements and accurately converting them to 
frequency or period, with a +- 20 ns uncertainty for each measurement.  Since 
it is a time-stamping counter, the uncertainty in a 10 s or 100 s or 1000 s 
measurement time (assembled by external software) is still only 20 ns.  That's 
great, but to actually get that accuracy over a long measurement time, you 
will need to determine and add up the actual number of input counts and 
timebase counts.  And you will have to understand that the counter does not 
make measurements at constant or near-constant intervals (e.g. every 90 cycles 
of input, without exception).  It gives you measurements whenever it gets 
around to measuring them.


Too bad there doesn't seem to be a way to get it to return the raw observed 
data (input cycle count, timebase cycle count) instead of the frequency or 
period derived from them.  That would make it trivial to string together a 
bunch of 1s measurements into arbitrarily long gate times.


- Dave

On 17/03/2015 05:57, jpbri...@aol.com wrote:

Hi Dave,

Thank you for your detailed response.

I use the E? command because it returns results at the gate time intervals 
rather than at the LCD update rate (as you point out). I think that this is 
working correctly because I get very different file sizes.


The numbers are returned as strings of 10 digits - here are some for 1 
second gate:


90.6359e+0Hz
90.7591e+0Hz
89.9640e+0Hz
89.8740e+0Hz
90.6007e+0Hz
89.6040e+0Hz
90.8648e+0Hz
90.8472e+0Hz
90.00011465e+0Hz
90.00014459e+0Hz

I generally use the frequency mode but I also tried time period and found I 
got the same curve in essence, which was comforting in a way but showed it 
wasn't rounding in converting to frequency.


The numbers above, on my calculator at least don't exactly match counts of 
20 nanosecs.


Here are some time period results:

11.11107736e-3s
11.0130e-3s
11.0769e-3s
11.0435e-3s
11.0593e-3s
11.0022e-3s
11.4000e-3s
11.e-3s
11.0370e-3s

Again they don't seem to be integer values of 20 nanosec exactly, though 
quite close. For example

11.11107736E-3/20E-9 = 555,553.868
555,554 x 20E-9 = 11.11108E-3

But I guess what it returns is the ratio of counts within the gate. So 
11.11107736E-3 period will occur

90 times in a second (as it is slightly short) and so I should take the ratio:

90 x 11.11107736E-3/20e-9 = 49,999,848.12

so still not quite an integer but if I assume the count (of 50MHz periods) 
was 49,999,848 and calculate one 90 th of it I get:


49,999,848 x 20E-9/90 = 1.07733

Still not exact agreement. I note that .12 is very close to .125 or 1/8 but 
I don't know if that is significant.
It is probable that it rounds the ratio in binary and then converts to 
decimal to print out.


I've tried assuming 89 periods and 91 periods but still don't get exact 
integer ratios.


Anyway, as I get good agreement between period and frequency measurements at 
1 sec, I don't think that it is a rounding issue.


I do think it is a quantization issue down to the +/- 20 nanosecs/gate time 
but I can't quite work it out.


I'm currently doing a run at 0.3 secs gate time and I'll see what sort of 
curve that produces.


Tomorrow I should receive my new Tek counter (I went for the fca3100 in the 
end as I got a very good discount on an ex demo unit) and that should give 
something to compare (once I've worked out how to program it).


James


-Original Message-
From: Dave Martindale dave.martind...@gmail.com
To: jpbridge jpbri...@aol.com; Discussion of precise time and frequency 
measurement time-nuts@febo.com

Sent: Tue, 17 Mar 2015 0:27
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time

How is the counter configured?  Are you reading period or frequency?  Are 
you in E? (Every Result) mode, or C? (Continuous Result) mode?  The 
former should give you continuous but independent measurements, while the 
latter gives heavily overlapped measurements.  (For example, with a 100 
second gate time, you get one E output every 100 seconds, which covers a 
different 100-second period than the previous measurement.  In C mode, you 
get one output every 2 seconds, each of which is an estimate from 100 
seconds of measurement, but 98 seconds of that data was also part of the 
previous output and only 2 seconds of new data is included).


What does the data returned by the counter actually look like?  The manual 
implies that you always get 10 digits

Re: [time-nuts] ADEV noise floor vs counter gate time

[James via time-nuts]

Hi Dave,

Thanks for another detailed response.

I've now programmed a version of my code that attempts to recover the raw data 
by trying different counts up and down from the nominal and finding the one 
with the smallest rounding error.

One problem is I need to restrain the amount it goes up or down otherwise it 
finds erroneously small or large numbers of cycles (+/- 2 is believable, more 
than that isn't).

As an experiment I then changed the data to match the raw data. This doesn't 
change the shape of the curve but it lowers it so it starts below 10^-15! This 
is suspiciously good so I think I'm smoothing out changes that are really there.

Now that my new fca3100 has arrived I'm hoping to find time to get measurements 
with it which should be proper time-stamped ones and much more accurate - then 
I can compare the two.

To answer your question on ADEV aggregating values, and speaking as a total 
newbee myself, the approach to different tau sizes is to aggregate all 
measurements within a bin of size tau and average the frequencies (or average 
the time differences and invert - for small variations it makes very little 
difference as (1+delta)^-1 is 1-delta ignoring delta*delta terms). Then each 
term in the Alan Variaton summation is the square of the difference between the 
average frequency in adjacent bins.

So with 1 second values at a tau of 100 secs, 100 values in each cell are 
averaged whilst the 100 sec gate value results just have a single value for 
each bin. But given that the counter itself should be averaging there should be 
good agreement between the two - hence my puzzlement.

The fca3100 calculates ADEV directly so I'll have a check on my code.

James

 

 

 

-Original Message-
From: Dave Martindale dave.martind...@gmail.com
To: jpbridge jpbri...@aol.com
CC: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Wed, 18 Mar 2015 15:22
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time


 
The counter always has a 1 count uncertainty in the timebase measurement, which 
is a 2e-8 error with a 1 second gate time.  If the value being displayed starts 
with the digit 9, and 8 digits are displayed, then that translates to +- 2 
counts in the last place.  But the measurements are synchronized to the input 
signal, so it always measures an integer number of input cycles, and there 
should be no comparable uncertainty in the input (other than some noise in 
deciding exactly when the edge crosses the input threshold, which should be 
tiny compared to the 20 ns timebase period).  
   
  
  
But that's comparing the counter reading to the real world.  My table was 
comparing the displayed output to the likely raw measurements, and it seems to 
show that the counter's internal math is being performed to the full 10 digits 
of precision in the USB data, even when the gate time supports only 8 bits of 
accuracy.  That's good news because it allows you to know when you have 
correctly guessed the input counts.  
  
   
  
  
When trying to calculate the raw data from the reading, you do need to try an 
input count of 91 in addition to 90 and 92.  91 did show up in the small sample 
of period-mode measurements, even if it did not appear in any of the 
frequency-mode measurements.  
  
   
  
  
I don't think the counter is doing averaging, in the sense of making multiple 
independent short-period measurements and then averaging them for higher 
precision.  Instead, it is just making one long continuous measurement, 
sampling the signal periodically, and then actually calculating frequency or 
period from two measurements separated by an appropriate time.  For a 
simplified example:  
  
   
  
  
Suppose the counter generates a time stamp approximately every 1 second (always 
aligned with the input signal active edge) and then stores the two pieces of 
raw data (the current input cycle counter and the current timebase counter) in 
a small memory buffer.  The counters are never reset; they just need to be 
large enough to never overflow twice within the longest input period allowed 
(1000 s for the TF930).  To display a frequency or period based on a 1 s gate 
time, the counter simply subtracts two successive data records to get 
delta-input and delta-timebase counts, then does its calculations based on 
those deltas.  To display a 10 second gate time measurement, the counter looks 
back through its memory to find a time stamp about 10 seconds earlier than the 
most recent measurement (with high input frequency, that will generally be 10 
measurements ago, but when measuring a signal with a 0.2 Hz frequency it's only 
2 measurements ago).  For a 100 second gate time measurement, the count
 er needs to find a saved time stamp that is about 100 seconds ago.  Once it 
has found the correct data record, it calculates the difference in input and 
timebase counts between that one previous data record and the most recent, and 
then calculates the displayed

Re: [time-nuts] ADEV noise floor vs counter gate time

[Dave Martindale]

How is the counter configured?  Are you reading period or frequency?  Are
you in E? (Every Result) mode, or C? (Continuous Result) mode?  The
former should give you continuous but independent measurements, while the
latter gives heavily overlapped measurements.  (For example, with a 100
second gate time, you get one E output every 100 seconds, which covers a
different 100-second period than the previous measurement.  In C mode, you
get one output every 2 seconds, each of which is an estimate from 100
seconds of measurement, but 98 seconds of that data was also part of the
previous output and only 2 seconds of new data is included).

What does the data returned by the counter actually look like?  The manual
implies that you always get 10 digits worth of result (not including the
exponent) regardless of gate time, but are the values rounded for display
in 7, 8, or 9 digits at the shorter gate times, or are they a full 10
digits always?  Given any particular value of frequency or period you get,
you should be able to reverse-calculate the number of whole cycles of the
input signal that the counter used as a gate time, and the number of cycles
of 50 MHz timebase that were counted in that period.  Since the counter
doesn't have interpolators, both of these values should be integers, and so
the possible output values are a small subset of all possible 10-digit
values for the shorter gate times.

For example, if the difference frequency is exactly 90 Hz, the period
between two 1 second measurements will be exactly 1 second, and the
counter will record 90 cycles of input and 5e7 cycles of timebase,
exactly.  In frequency mode, the output should be 90.0 Hz exactly, and in
period mode the output should be 11. ms.  Now suppose that the
difference frequency is just a hair slow, enough that 90 cycles of input
spans 50,000,001 counts of the timebase.  The reported frequency should be
89.9820 Hz and the reported period should be 11.1133 ms.  With a 1
s gate time, no values between those are possible unless the values are
being rounded (or there is an error in the calculation, which is always
possible).  Looked at another way, the smallest possible change in the
reported period is one timebase clock (20 ns) divided by the number of
input cycles in one gate time (90 for 1 s).

If the counter is rounding, you may be able to unambiguously figure out
what the actual inputs (cycles of input and cycles of timebase) to the
calculation were, and use that instead of the rounded value in your
calculations.  Rounding may round up or down, but if the two oscillators
are stable enough the direction can be predominantly up or down for
long periods of time, adding a bias to the actual frequency or period
you're measuring.  (I don't know what effect this bias would have on ADEV).

- Dave

On Mon, Mar 16, 2015 at 10:15 AM, James via time-nuts time-nuts@febo.com
wrote:

 Hi All,

 I'm in the process of getting a better counter, but at present I'm using
 my TTi TF930 counter.

 For those who don't know it, it is a reciprocal counter which should be
 continuous, it counts periods in terms of its internal 50MHz clock which
 I've locked to an external 10MHz reference.

 There are 4 gate times available, 0.3 secs, 1 sec, 10 secs and 100 secs.

 These correspond to 7, 8, 9 and 10 digits.

 I've been experimenting with using a single mixer (mini circuits ZAD+)
 along with a 1MHz low pass filter and appropriate attenuators to measure
 Alan Deviation (using my own software).

 My set up is a 10MHz reference source (MV89A which I've approximately set
 using a 10kHz GPS signal).

 The reference is used as the external reference for an Agilent 33522A
 arbitrary waveform generator.

 The 33522A generates an 9.10 MHz (10MHz - 90Hz) sine wave at 300mVpp
 to the mixer and the mixer is also fed by the 10MHz reference output of the
 33522A via an attenuator to get it to roughly the same level.

 The second output of the 33522A generates a 10MHz square wave as a
 reference for the counter (the counter requires quite a high reference
 signal and the reference out of the 33522A is too low a voltage to be used
 directly).

 I initially ran this with a gate of 1 second and the LOG10(ADEV) curve
 drops linearly vs LOG10(tau) but then curves back up again. (I tried many
 variants such as using period rather than frequency and so on.)

 But when I set the gate time to 10 seconds or 100 seconds then I get both
 lower curves and ones that no longer curve upwards.

 The attached pdf shows the three curves on the same graph.

 What puzzles me is that the counter at longer gates is only averaging to
 get more digits so the difference must come down to quantization in terms
 of the number of digits that are passed to the computer over the USB/RS232
 link.

 I find it rather puzzling.

 James






 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to
 

Re: [time-nuts] ADEV noise floor vs counter gate time

[James via time-nuts]

Hi Dave,

Thank you for your detailed response.

I use the E? command because it returns results at the gate time intervals 
rather than at the LCD update rate (as you point out). I think that this is 
working correctly because I get very different file sizes.

The numbers are returned as strings of 10 digits - here are some for 1 second 
gate:

 

 90.6359e+0Hz

90.7591e+0Hz

89.9640e+0Hz

89.8740e+0Hz

90.6007e+0Hz

89.6040e+0Hz

90.8648e+0Hz

90.8472e+0Hz

90.00011465e+0Hz

90.00014459e+0Hz

I generally use the frequency mode but I also tried time period and found I got 
the same curve in essence, which was comforting in a way but showed it wasn't 
rounding in converting to frequency.

The numbers above, on my calculator at least don't exactly match counts of 20 
nanosecs.

Here are some time period results:

11.11107736e-3s 

11.0130e-3s 

11.0769e-3s 

11.0435e-3s 

11.0593e-3s 

11.0022e-3s 

11.4000e-3s 

11.e-3s 

11.0370e-3s 

Again they don't seem to be integer values of 20 nanosec exactly, though quite 
close. For example
11.11107736E-3/20E-9 = 555,553.868
555,554 x 20E-9 = 11.11108E-3

But I guess what it returns is the ratio of counts within the gate. So 
11.11107736E-3 period will occur
90 times in a second (as it is slightly short) and so I should take the ratio:

90 x 11.11107736E-3/20e-9 = 49,999,848.12

so still not quite an integer but if I assume the count (of 50MHz periods) was 
49,999,848 and calculate one 90 th of it I get:

49,999,848 x 20E-9/90 = 1.07733

Still not exact agreement. I note that .12 is very close to .125 or 1/8 but I 
don't know if that is significant.
It is probable that it rounds the ratio in binary and then converts to decimal 
to print out.

I've tried assuming 89 periods and 91 periods but still don't get exact integer 
ratios.

Anyway, as I get good agreement between period and frequency measurements at 1 
sec, I don't think that it is a rounding issue.

I do think it is a quantization issue down to the +/- 20 nanosecs/gate time but 
I can't quite work it out. 

I'm currently doing a run at 0.3 secs gate time and I'll see what sort of curve 
that produces.

Tomorrow I should receive my new Tek counter (I went for the fca3100 in the end 
as I got a very good discount on an ex demo unit) and that should give 
something to compare (once I've worked out how to program it).

James


 

-Original Message-
From: Dave Martindale dave.martind...@gmail.com
To: jpbridge jpbri...@aol.com; Discussion of precise time and frequency 
measurement time-nuts@febo.com
Sent: Tue, 17 Mar 2015 0:27
Subject: Re: [time-nuts] ADEV noise floor vs counter gate time


 
  
How is the counter configured?  Are you reading period or frequency?  Are you 
in E? (Every Result) mode, or C? (Continuous Result) mode?  The former 
should give you continuous but independent measurements, while the latter gives 
heavily overlapped measurements.  (For example, with a 100 second gate time, 
you get one E output every 100 seconds, which covers a different 100-second 
period than the previous measurement.  In C mode, you get one output every 2 
seconds, each of which is an estimate from 100 seconds of measurement, but 98 
seconds of that data was also part of the previous output and only 2 seconds of 
new data is included).   
  
  
   
  
What does the data returned by the counter actually look like?  The manual 
implies that you always get 10 digits worth of result (not including the 
exponent) regardless of gate time, but are the values rounded for display in 7, 
8, or 9 digits at the shorter gate times, or are they a full 10 digits always?  
Given any particular value of frequency or period you get, you should be able 
to reverse-calculate the number of whole cycles of the input signal that the 
counter used as a gate time, and the number of cycles of 50 MHz timebase that 
were counted in that period.  Since the counter doesn't have interpolators, 
both of these values should be integers, and so the possible output values are 
a small subset of all possible 10-digit values for the shorter gate times.  
   
  
  
For example, if the difference frequency is exactly 90 Hz, the period between 
two 1 second measurements will be exactly 1 second, and the counter will 
record 90 cycles of input and 5e7 cycles of timebase, exactly.  In frequency 
mode, the output should be 90.0 Hz exactly, and in period mode the output 
should be 11. ms.  Now suppose that the difference frequency is just a 
hair slow, enough that 90 cycles of input spans 50,000,001 counts of the 
timebase.  The reported frequency should be 89.9820 Hz and the reported 
period should be 11.1133 ms.  With a 1 s gate time, no values between those 
are possible unless the values are being rounded (or there is an error in the 
calculation, which is always possible).  Looked at another way, the smallest 
possible change in the reported period is one

Re: [time-nuts] ADEV from phase or frequency measurement

[Volker Esper]

Even if the -3dB were an issue, I'd have much more faith in a clear, passive
resistor network than in a complex amplifier with all it's unknown non linear
characteristics, temperature dependent time delays, noise sources, etc., etc.
This simple home made network is a useful, manageable gadget.
Volker

 Bob Camp li...@rtty.us hat am 10. März 2014 um 01:47 geschrieben:


 Hi

 So far, I have not found the 3db lost in a a passive splitter to be a problem
 with anything I have played with. With proper termination , they seem to be a
 good thing to use.

 Bob

 On Mar 9, 2014, at 7:55 PM, Volker Esper ail...@t-online.de wrote:

  Bob,
 
  I sometimes indeed do arc welding, as well as forging... But that's
  another story.
 
  When waiting for an ADEV measurement I sit still, trying not to move a
  millimeter. Seriously, I try to avoid any rf noise, e.g. ham radio, any
  airflow, any temperature change. I log supply voltages and check, if
  there's anything odd. I avoid any switching supply. I regularely check,
  if any switching voltage regulator (TV, monitors, PC,...) disturbs my rf
  ether...
 
  As the legends of my plots tell, I do use a passive splitter to get two
  similar signals (start and stop) for phase measurement. But I haven't
  used it for splitting the 10MHz for frequency measurement (reference and
  input).
 
  Lower level is a concern, since it increases phase jitter.
 
  Volker
 
 
  Am 09.03.2014 23:32, schrieb Bob Camp:
  Hi
 
  Do you routinely do arc welding while waiting for an ADEV plot to finish
  :)… (I drink beer, but not everybody is into that …)
 
  You might consider trying a passive splitter on one of the outputs of the
  GPSDO. There aren’t many ways they will mess up a signal other than by
  dropping it’s level. If level is a concern then indeed they could be an
  issue.
 
  Bob
 
  On Mar 9, 2014, at 6:17 PM, Magnus Danielson mag...@rubidium.dyndns.org
  wrote:
 
  On 09/03/14 22:36, Volker Esper wrote:
  Am 09.03.2014 19:46, schrieb Magnus Danielson:
  On 04/03/14 01:05, Volker Esper wrote:
  Am 03.03.2014 23:04, schrieb Magnus Danielson:
  Volker,
 
  On 03/03/14 00:50, Volker Esper wrote:
  Sorry for the time delay...
 
  TIC: SR620 with Z3805 as external reference; signal source
  Nortel/Trimble GPSTM (GPSDO) 10MHz output
 
  Enclosed two plots (SW: Plotter):
  - one is sigma(tau) calculated from phase samples (SR620 TIME mode),
  - the other one is sigma(tau) from frequency data (SR620 FREQ mode)
 
  Whole equipment had a power up time of several days/weeks. Room
  temperature was stable over both measurements (within about 2 degrees
  C).
  The SR620 uses a bit different path through the logic when doing TI
  and FREQ measurements. The frequency measurement has a feature that
  means that the time error between start and stop signal needs to be
  calibrated out. This can be done using the calibration routines given
  in the manual. This should not affect the ADEV measure, but as a
  precaution.
 
  Try doing a pair of noise-floor measurements. That is, feed the
  reference 10 MHz to the A input for the frequency noise measurement.
  Then, for the TI noise-floor measurement, put a T on the A input, put
  it in high-Z mode and then use a 1 m cable to put the signal onto the
  B input which is terminating.
 
  You indeed have a higher level. Your initial shape makes me wonder. I
  would really like to get the TimeLab measurement files and eye-ball
  them closer.
 
  If you plot the phase or frequency, it may be easier to spot
  systematic wobbles. TDEV would also help, as it provides a general
  *tau scaling to the ADEV plot.
 
  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.
  I already did these measurements, I stick the plots at this posting.
 
  - The plot with the long file name shows frequency mode measurement:
  10MHz external reference put into channel A.
  - ...Plot2 shows a phase measurement, where I fed the reference
  signal
  via a home made 50 ohms splitter into both input channels. (I prefer
  feeding the channels symmetrically)
  Both plots show linear negative gradients, but the phase plot is
  steeper. The frequency plot transitions into a horizontal at about
  1000s.
  The 1/sqrt(tau) curve is higher than the background noise of the
  counter. That flicker phase noise is more typical of a buffer or
  source than of the counter.
 
  For shorter taus I would expect the white noise to dominate.
 
  I'm just surprised about the level of flicker phase noise. What is the
  source?
 
  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.
  Source in both cases is an HP Z3805 GPSDO. I didn't insert an 

Re: [time-nuts] ADEV from phase or frequency measurement

[Bob Camp]

Hi

I’ve played with both the 6 db loss resistive splitters and the transformer 
based 3 db loss splitters. They both seem to be fine for splitting precision 10 
MHz signals. For a while I avoided the transformer based parts, but not for any 
reason I could prove.

Bob

On Mar 10, 2014, at 7:41 AM, Volker Esper ail...@t-online.de wrote:

 Even if the -3dB were an issue, I'd have much more faith in a clear, passive
 resistor network than in a complex amplifier with all it's unknown non linear
 characteristics, temperature dependent time delays, noise sources, etc., etc.
 This simple home made network is a useful, manageable gadget.
 Volker
 
 Bob Camp li...@rtty.us hat am 10. März 2014 um 01:47 geschrieben:
 
 
 Hi
 
 So far, I have not found the 3db lost in a a passive splitter to be a problem
 with anything I have played with. With proper termination , they seem to be a
 good thing to use.
 
 Bob
 
 On Mar 9, 2014, at 7:55 PM, Volker Esper ail...@t-online.de wrote:
 
 Bob,
 
 I sometimes indeed do arc welding, as well as forging... But that's
 another story.
 
 When waiting for an ADEV measurement I sit still, trying not to move a
 millimeter. Seriously, I try to avoid any rf noise, e.g. ham radio, any
 airflow, any temperature change. I log supply voltages and check, if
 there's anything odd. I avoid any switching supply. I regularely check,
 if any switching voltage regulator (TV, monitors, PC,...) disturbs my rf
 ether...
 
 As the legends of my plots tell, I do use a passive splitter to get two
 similar signals (start and stop) for phase measurement. But I haven't
 used it for splitting the 10MHz for frequency measurement (reference and
 input).
 
 Lower level is a concern, since it increases phase jitter.
 
 Volker
 
 
 Am 09.03.2014 23:32, schrieb Bob Camp:
 Hi
 
 Do you routinely do arc welding while waiting for an ADEV plot to finish
 :)… (I drink beer, but not everybody is into that …)
 
 You might consider trying a passive splitter on one of the outputs of the
 GPSDO. There aren’t many ways they will mess up a signal other than by
 dropping it’s level. If level is a concern then indeed they could be an
 issue.
 
 Bob
 
 On Mar 9, 2014, at 6:17 PM, Magnus Danielson mag...@rubidium.dyndns.org
 wrote:
 
 On 09/03/14 22:36, Volker Esper wrote:
 Am 09.03.2014 19:46, schrieb Magnus Danielson:
 On 04/03/14 01:05, Volker Esper wrote:
 Am 03.03.2014 23:04, schrieb Magnus Danielson:
 Volker,
 
 On 03/03/14 00:50, Volker Esper wrote:
 Sorry for the time delay...
 
 TIC: SR620 with Z3805 as external reference; signal source
 Nortel/Trimble GPSTM (GPSDO) 10MHz output
 
 Enclosed two plots (SW: Plotter):
 - one is sigma(tau) calculated from phase samples (SR620 TIME mode),
 - the other one is sigma(tau) from frequency data (SR620 FREQ mode)
 
 Whole equipment had a power up time of several days/weeks. Room
 temperature was stable over both measurements (within about 2 degrees
 C).
 The SR620 uses a bit different path through the logic when doing TI
 and FREQ measurements. The frequency measurement has a feature that
 means that the time error between start and stop signal needs to be
 calibrated out. This can be done using the calibration routines given
 in the manual. This should not affect the ADEV measure, but as a
 precaution.
 
 Try doing a pair of noise-floor measurements. That is, feed the
 reference 10 MHz to the A input for the frequency noise measurement.
 Then, for the TI noise-floor measurement, put a T on the A input, put
 it in high-Z mode and then use a 1 m cable to put the signal onto the
 B input which is terminating.
 
 You indeed have a higher level. Your initial shape makes me wonder. I
 would really like to get the TimeLab measurement files and eye-ball
 them closer.
 
 If you plot the phase or frequency, it may be easier to spot
 systematic wobbles. TDEV would also help, as it provides a general
 *tau scaling to the ADEV plot.
 
 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.
 I already did these measurements, I stick the plots at this posting.
 
 - The plot with the long file name shows frequency mode measurement:
 10MHz external reference put into channel A.
 - ...Plot2 shows a phase measurement, where I fed the reference
 signal
 via a home made 50 ohms splitter into both input channels. (I prefer
 feeding the channels symmetrically)
 Both plots show linear negative gradients, but the phase plot is
 steeper. The frequency plot transitions into a horizontal at about
 1000s.
 The 1/sqrt(tau) curve is higher than the background noise of the
 counter. That flicker phase noise is more typical of a buffer or
 source than of the counter.
 
 For shorter taus I would expect the white noise to dominate.
 
 I'm just surprised about the level of flicker phase noise. What is the
 source?
 
 Cheers,
 Magnus
 

Re: [time-nuts] ADEV from phase or frequency measurement

[Magnus Danielson]

On 04/03/14 01:05, Volker Esper wrote:

Am 03.03.2014 23:04, schrieb Magnus Danielson:

Volker,

On 03/03/14 00:50, Volker Esper wrote:

Sorry for the time delay...

TIC: SR620 with Z3805 as external reference; signal source
Nortel/Trimble GPSTM (GPSDO) 10MHz output

Enclosed two plots (SW: Plotter):
- one is sigma(tau) calculated from phase samples (SR620 TIME mode),
- the other one is sigma(tau) from frequency data (SR620 FREQ mode)

Whole equipment had a power up time of several days/weeks. Room
temperature was stable over both measurements (within about 2 degrees
C).


The SR620 uses a bit different path through the logic when doing TI
and FREQ measurements. The frequency measurement has a feature that
means that the time error between start and stop signal needs to be
calibrated out. This can be done using the calibration routines given
in the manual. This should not affect the ADEV measure, but as a
precaution.

Try doing a pair of noise-floor measurements. That is, feed the
reference 10 MHz to the A input for the frequency noise measurement.
Then, for the TI noise-floor measurement, put a T on the A input, put
it in high-Z mode and then use a 1 m cable to put the signal onto the
B input which is terminating.

You indeed have a higher level. Your initial shape makes me wonder. I
would really like to get the TimeLab measurement files and eye-ball
them closer.

If you plot the phase or frequency, it may be easier to spot
systematic wobbles. TDEV would also help, as it provides a general
*tau scaling to the ADEV plot.

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.

I already did these measurements, I stick the plots at this posting.

- The plot with the long file name shows frequency mode measurement:
10MHz external reference put into channel A.
- ...Plot2 shows a phase measurement, where I fed the reference signal
via a home made 50 ohms splitter into both input channels. (I prefer
feeding the channels symmetrically)
Both plots show linear negative gradients, but the phase plot is
steeper. The frequency plot transitions into a horizontal at about 1000s.


The 1/sqrt(tau) curve is higher than the background noise of the 
counter. That flicker phase noise is more typical of a buffer or source 
than of the counter.


For shorter taus I would expect the white noise to dominate.

I'm just surprised about the level of flicker phase noise. What is the 
source?


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 from phase or frequency measurement

[Volker Esper]

Am 09.03.2014 19:46, schrieb Magnus Danielson:
 On 04/03/14 01:05, Volker Esper wrote:
 Am 03.03.2014 23:04, schrieb Magnus Danielson:
 Volker,

 On 03/03/14 00:50, Volker Esper wrote:
 Sorry for the time delay...

 TIC: SR620 with Z3805 as external reference; signal source
 Nortel/Trimble GPSTM (GPSDO) 10MHz output

 Enclosed two plots (SW: Plotter):
 - one is sigma(tau) calculated from phase samples (SR620 TIME mode),
 - the other one is sigma(tau) from frequency data (SR620 FREQ mode)

 Whole equipment had a power up time of several days/weeks. Room
 temperature was stable over both measurements (within about 2 degrees
 C).

 The SR620 uses a bit different path through the logic when doing TI
 and FREQ measurements. The frequency measurement has a feature that
 means that the time error between start and stop signal needs to be
 calibrated out. This can be done using the calibration routines given
 in the manual. This should not affect the ADEV measure, but as a
 precaution.

 Try doing a pair of noise-floor measurements. That is, feed the
 reference 10 MHz to the A input for the frequency noise measurement.
 Then, for the TI noise-floor measurement, put a T on the A input, put
 it in high-Z mode and then use a 1 m cable to put the signal onto the
 B input which is terminating.

 You indeed have a higher level. Your initial shape makes me wonder. I
 would really like to get the TimeLab measurement files and eye-ball
 them closer.

 If you plot the phase or frequency, it may be easier to spot
 systematic wobbles. TDEV would also help, as it provides a general
 *tau scaling to the ADEV plot.

 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.
 I already did these measurements, I stick the plots at this posting.

 - The plot with the long file name shows frequency mode measurement:
 10MHz external reference put into channel A.
 - ...Plot2 shows a phase measurement, where I fed the reference signal
 via a home made 50 ohms splitter into both input channels. (I prefer
 feeding the channels symmetrically)
 Both plots show linear negative gradients, but the phase plot is
 steeper. The frequency plot transitions into a horizontal at about
 1000s.

 The 1/sqrt(tau) curve is higher than the background noise of the
 counter. That flicker phase noise is more typical of a buffer or
 source than of the counter.

 For shorter taus I would expect the white noise to dominate.

 I'm just surprised about the level of flicker phase noise. What is the
 source?

 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.

Source in both cases is an HP Z3805 GPSDO. I didn't insert an additional
buffer, however, the Z3805 has two (buffered) outputs. I used one for
counter reference, the other one for counter input.

Volker

___
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 from phase or frequency measurement

[Magnus Danielson]

On 09/03/14 22:36, Volker Esper wrote:

Am 09.03.2014 19:46, schrieb Magnus Danielson:

On 04/03/14 01:05, Volker Esper wrote:

Am 03.03.2014 23:04, schrieb Magnus Danielson:

Volker,

On 03/03/14 00:50, Volker Esper wrote:

Sorry for the time delay...

TIC: SR620 with Z3805 as external reference; signal source
Nortel/Trimble GPSTM (GPSDO) 10MHz output

Enclosed two plots (SW: Plotter):
- one is sigma(tau) calculated from phase samples (SR620 TIME mode),
- the other one is sigma(tau) from frequency data (SR620 FREQ mode)

Whole equipment had a power up time of several days/weeks. Room
temperature was stable over both measurements (within about 2 degrees
C).


The SR620 uses a bit different path through the logic when doing TI
and FREQ measurements. The frequency measurement has a feature that
means that the time error between start and stop signal needs to be
calibrated out. This can be done using the calibration routines given
in the manual. This should not affect the ADEV measure, but as a
precaution.

Try doing a pair of noise-floor measurements. That is, feed the
reference 10 MHz to the A input for the frequency noise measurement.
Then, for the TI noise-floor measurement, put a T on the A input, put
it in high-Z mode and then use a 1 m cable to put the signal onto the
B input which is terminating.

You indeed have a higher level. Your initial shape makes me wonder. I
would really like to get the TimeLab measurement files and eye-ball
them closer.

If you plot the phase or frequency, it may be easier to spot
systematic wobbles. TDEV would also help, as it provides a general
*tau scaling to the ADEV plot.

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.

I already did these measurements, I stick the plots at this posting.

- The plot with the long file name shows frequency mode measurement:
10MHz external reference put into channel A.
- ...Plot2 shows a phase measurement, where I fed the reference signal
via a home made 50 ohms splitter into both input channels. (I prefer
feeding the channels symmetrically)
Both plots show linear negative gradients, but the phase plot is
steeper. The frequency plot transitions into a horizontal at about
1000s.


The 1/sqrt(tau) curve is higher than the background noise of the
counter. That flicker phase noise is more typical of a buffer or
source than of the counter.

For shorter taus I would expect the white noise to dominate.

I'm just surprised about the level of flicker phase noise. What is the
source?

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.


Source in both cases is an HP Z3805 GPSDO. I didn't insert an additional
buffer, however, the Z3805 has two (buffered) outputs. I used one for
counter reference, the other one for counter input.


Hmm... what is the noise when you measure it on the SR620 itself?

It seems a little high here.

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 from phase or frequency measurement

[Bob Camp]

Hi

Do you routinely do arc welding while waiting for an ADEV plot to finish :)… (I 
drink beer, but not everybody is into that …)

You might consider trying a passive splitter on one of the outputs of the 
GPSDO. There aren’t many ways they will mess up a signal other than by dropping 
it’s level. If level is a concern then indeed they could be an issue.

Bob

On Mar 9, 2014, at 6:17 PM, Magnus Danielson mag...@rubidium.dyndns.org wrote:

 On 09/03/14 22:36, Volker Esper wrote:
 Am 09.03.2014 19:46, schrieb Magnus Danielson:
 On 04/03/14 01:05, Volker Esper wrote:
 Am 03.03.2014 23:04, schrieb Magnus Danielson:
 Volker,
 
 On 03/03/14 00:50, Volker Esper wrote:
 Sorry for the time delay...
 
 TIC: SR620 with Z3805 as external reference; signal source
 Nortel/Trimble GPSTM (GPSDO) 10MHz output
 
 Enclosed two plots (SW: Plotter):
 - one is sigma(tau) calculated from phase samples (SR620 TIME mode),
 - the other one is sigma(tau) from frequency data (SR620 FREQ mode)
 
 Whole equipment had a power up time of several days/weeks. Room
 temperature was stable over both measurements (within about 2 degrees
 C).
 
 The SR620 uses a bit different path through the logic when doing TI
 and FREQ measurements. The frequency measurement has a feature that
 means that the time error between start and stop signal needs to be
 calibrated out. This can be done using the calibration routines given
 in the manual. This should not affect the ADEV measure, but as a
 precaution.
 
 Try doing a pair of noise-floor measurements. That is, feed the
 reference 10 MHz to the A input for the frequency noise measurement.
 Then, for the TI noise-floor measurement, put a T on the A input, put
 it in high-Z mode and then use a 1 m cable to put the signal onto the
 B input which is terminating.
 
 You indeed have a higher level. Your initial shape makes me wonder. I
 would really like to get the TimeLab measurement files and eye-ball
 them closer.
 
 If you plot the phase or frequency, it may be easier to spot
 systematic wobbles. TDEV would also help, as it provides a general
 *tau scaling to the ADEV plot.
 
 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.
 I already did these measurements, I stick the plots at this posting.
 
 - The plot with the long file name shows frequency mode measurement:
 10MHz external reference put into channel A.
 - ...Plot2 shows a phase measurement, where I fed the reference signal
 via a home made 50 ohms splitter into both input channels. (I prefer
 feeding the channels symmetrically)
 Both plots show linear negative gradients, but the phase plot is
 steeper. The frequency plot transitions into a horizontal at about
 1000s.
 
 The 1/sqrt(tau) curve is higher than the background noise of the
 counter. That flicker phase noise is more typical of a buffer or
 source than of the counter.
 
 For shorter taus I would expect the white noise to dominate.
 
 I'm just surprised about the level of flicker phase noise. What is the
 source?
 
 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.
 
 Source in both cases is an HP Z3805 GPSDO. I didn't insert an additional
 buffer, however, the Z3805 has two (buffered) outputs. I used one for
 counter reference, the other one for counter input.
 
 Hmm... what is the noise when you measure it on the SR620 itself?
 
 It seems a little high here.
 
 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 from phase or frequency measurement

[Volker Esper]

Bob,

I sometimes indeed do arc welding, as well as forging... But that's
another story.

When waiting for an ADEV measurement I sit still, trying not to move a
millimeter. Seriously, I try to avoid any rf noise, e.g. ham radio, any
airflow, any temperature change. I log supply voltages and check, if
there's anything odd. I avoid any switching supply. I regularely check,
if any switching voltage regulator (TV, monitors, PC,...) disturbs my rf
ether...

As the legends of my plots tell, I do use a passive splitter to get two
similar signals (start and stop) for phase measurement. But I haven't
used it for splitting the 10MHz for frequency measurement (reference and
input).

Lower level is a concern, since it increases phase jitter.

Volker


Am 09.03.2014 23:32, schrieb Bob Camp:
 Hi

 Do you routinely do arc welding while waiting for an ADEV plot to finish :)… 
 (I drink beer, but not everybody is into that …)

 You might consider trying a passive splitter on one of the outputs of the 
 GPSDO. There aren’t many ways they will mess up a signal other than by 
 dropping it’s level. If level is a concern then indeed they could be an issue.

 Bob

 On Mar 9, 2014, at 6:17 PM, Magnus Danielson mag...@rubidium.dyndns.org 
 wrote:

 On 09/03/14 22:36, Volker Esper wrote:
 Am 09.03.2014 19:46, schrieb Magnus Danielson:
 On 04/03/14 01:05, Volker Esper wrote:
 Am 03.03.2014 23:04, schrieb Magnus Danielson:
 Volker,

 On 03/03/14 00:50, Volker Esper wrote:
 Sorry for the time delay...

 TIC: SR620 with Z3805 as external reference; signal source
 Nortel/Trimble GPSTM (GPSDO) 10MHz output

 Enclosed two plots (SW: Plotter):
 - one is sigma(tau) calculated from phase samples (SR620 TIME mode),
 - the other one is sigma(tau) from frequency data (SR620 FREQ mode)

 Whole equipment had a power up time of several days/weeks. Room
 temperature was stable over both measurements (within about 2 degrees
 C).
 The SR620 uses a bit different path through the logic when doing TI
 and FREQ measurements. The frequency measurement has a feature that
 means that the time error between start and stop signal needs to be
 calibrated out. This can be done using the calibration routines given
 in the manual. This should not affect the ADEV measure, but as a
 precaution.

 Try doing a pair of noise-floor measurements. That is, feed the
 reference 10 MHz to the A input for the frequency noise measurement.
 Then, for the TI noise-floor measurement, put a T on the A input, put
 it in high-Z mode and then use a 1 m cable to put the signal onto the
 B input which is terminating.

 You indeed have a higher level. Your initial shape makes me wonder. I
 would really like to get the TimeLab measurement files and eye-ball
 them closer.

 If you plot the phase or frequency, it may be easier to spot
 systematic wobbles. TDEV would also help, as it provides a general
 *tau scaling to the ADEV plot.

 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.
 I already did these measurements, I stick the plots at this posting.

 - The plot with the long file name shows frequency mode measurement:
 10MHz external reference put into channel A.
 - ...Plot2 shows a phase measurement, where I fed the reference signal
 via a home made 50 ohms splitter into both input channels. (I prefer
 feeding the channels symmetrically)
 Both plots show linear negative gradients, but the phase plot is
 steeper. The frequency plot transitions into a horizontal at about
 1000s.
 The 1/sqrt(tau) curve is higher than the background noise of the
 counter. That flicker phase noise is more typical of a buffer or
 source than of the counter.

 For shorter taus I would expect the white noise to dominate.

 I'm just surprised about the level of flicker phase noise. What is the
 source?

 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.
 Source in both cases is an HP Z3805 GPSDO. I didn't insert an additional
 buffer, however, the Z3805 has two (buffered) outputs. I used one for
 counter reference, the other one for counter input.
 Hmm... what is the noise when you measure it on the SR620 itself?

 It seems a little high here.

 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.

___
time-nuts mailing list -- 

Re: [time-nuts] ADEV from phase or frequency measurement

[Bob Camp]

Hi

So far, I have not found the 3db lost in a a passive splitter to be a problem 
with anything I have played with. With proper termination , they seem to be a 
good thing to use.

Bob

On Mar 9, 2014, at 7:55 PM, Volker Esper ail...@t-online.de wrote:

 Bob,
 
 I sometimes indeed do arc welding, as well as forging... But that's
 another story.
 
 When waiting for an ADEV measurement I sit still, trying not to move a
 millimeter. Seriously, I try to avoid any rf noise, e.g. ham radio, any
 airflow, any temperature change. I log supply voltages and check, if
 there's anything odd. I avoid any switching supply. I regularely check,
 if any switching voltage regulator (TV, monitors, PC,...) disturbs my rf
 ether...
 
 As the legends of my plots tell, I do use a passive splitter to get two
 similar signals (start and stop) for phase measurement. But I haven't
 used it for splitting the 10MHz for frequency measurement (reference and
 input).
 
 Lower level is a concern, since it increases phase jitter.
 
 Volker
 
 
 Am 09.03.2014 23:32, schrieb Bob Camp:
 Hi
 
 Do you routinely do arc welding while waiting for an ADEV plot to finish :)… 
 (I drink beer, but not everybody is into that …)
 
 You might consider trying a passive splitter on one of the outputs of the 
 GPSDO. There aren’t many ways they will mess up a signal other than by 
 dropping it’s level. If level is a concern then indeed they could be an 
 issue.
 
 Bob
 
 On Mar 9, 2014, at 6:17 PM, Magnus Danielson mag...@rubidium.dyndns.org 
 wrote:
 
 On 09/03/14 22:36, Volker Esper wrote:
 Am 09.03.2014 19:46, schrieb Magnus Danielson:
 On 04/03/14 01:05, Volker Esper wrote:
 Am 03.03.2014 23:04, schrieb Magnus Danielson:
 Volker,
 
 On 03/03/14 00:50, Volker Esper wrote:
 Sorry for the time delay...
 
 TIC: SR620 with Z3805 as external reference; signal source
 Nortel/Trimble GPSTM (GPSDO) 10MHz output
 
 Enclosed two plots (SW: Plotter):
 - one is sigma(tau) calculated from phase samples (SR620 TIME mode),
 - the other one is sigma(tau) from frequency data (SR620 FREQ mode)
 
 Whole equipment had a power up time of several days/weeks. Room
 temperature was stable over both measurements (within about 2 degrees
 C).
 The SR620 uses a bit different path through the logic when doing TI
 and FREQ measurements. The frequency measurement has a feature that
 means that the time error between start and stop signal needs to be
 calibrated out. This can be done using the calibration routines given
 in the manual. This should not affect the ADEV measure, but as a
 precaution.
 
 Try doing a pair of noise-floor measurements. That is, feed the
 reference 10 MHz to the A input for the frequency noise measurement.
 Then, for the TI noise-floor measurement, put a T on the A input, put
 it in high-Z mode and then use a 1 m cable to put the signal onto the
 B input which is terminating.
 
 You indeed have a higher level. Your initial shape makes me wonder. I
 would really like to get the TimeLab measurement files and eye-ball
 them closer.
 
 If you plot the phase or frequency, it may be easier to spot
 systematic wobbles. TDEV would also help, as it provides a general
 *tau scaling to the ADEV plot.
 
 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.
 I already did these measurements, I stick the plots at this posting.
 
 - The plot with the long file name shows frequency mode measurement:
 10MHz external reference put into channel A.
 - ...Plot2 shows a phase measurement, where I fed the reference signal
 via a home made 50 ohms splitter into both input channels. (I prefer
 feeding the channels symmetrically)
 Both plots show linear negative gradients, but the phase plot is
 steeper. The frequency plot transitions into a horizontal at about
 1000s.
 The 1/sqrt(tau) curve is higher than the background noise of the
 counter. That flicker phase noise is more typical of a buffer or
 source than of the counter.
 
 For shorter taus I would expect the white noise to dominate.
 
 I'm just surprised about the level of flicker phase noise. What is the
 source?
 
 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.
 Source in both cases is an HP Z3805 GPSDO. I didn't insert an additional
 buffer, however, the Z3805 has two (buffered) outputs. I used one for
 counter reference, the other one for counter input.
 Hmm... what is the noise when you measure it on the SR620 itself?
 
 It seems a little high here.
 
 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 

Re: [time-nuts] ADEV from phase or frequency measurement

[Magnus Danielson]

Volker,

On 03/03/14 00:50, Volker Esper wrote:

Sorry for the time delay...

TIC: SR620 with Z3805 as external reference; signal source
Nortel/Trimble GPSTM (GPSDO) 10MHz output

Enclosed two plots (SW: Plotter):
- one is sigma(tau) calculated from phase samples (SR620 TIME mode),
- the other one is sigma(tau) from frequency data (SR620 FREQ mode)

Whole equipment had a power up time of several days/weeks. Room
temperature was stable over both measurements (within about 2 degrees C).


The SR620 uses a bit different path through the logic when doing TI and 
FREQ measurements. The frequency measurement has a feature that means 
that the time error between start and stop signal needs to be calibrated 
out. This can be done using the calibration routines given in the 
manual. This should not affect the ADEV measure, but as a precaution.


Try doing a pair of noise-floor measurements. That is, feed the 
reference 10 MHz to the A input for the frequency noise measurement.
Then, for the TI noise-floor measurement, put a T on the A input, put it 
in high-Z mode and then use a 1 m cable to put the signal onto the B 
input which is terminating.


You indeed have a higher level. Your initial shape makes me wonder. I 
would really like to get the TimeLab measurement files and eye-ball them 
closer.


If you plot the phase or frequency, it may be easier to spot systematic 
wobbles. TDEV would also help, as it provides a general *tau scaling to 
the ADEV plot.


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 from phase or frequency measurement

[Tom Van Baak]

Hi Volker,

Either phase or frequency raw data can be used to generate an ADEV plot, but 
you have to use different methods depending on the data type.

See the two formulas for Allan Variance in: http://www.wriley.com/paper2ht.htm

Usually we use the x form of the formula, where x is an array of phase 
samples. But if you have frequency samples then use the y form instead, where 
y is an array of frequency samples.

Note you can also convert phase data to frequency data (by differentiating) and 
use the y form. Or convert frequency data to phase data (by integrating) and 
use the x form.

/tvb

- Original Message - 
From: Volker Esper ail...@t-online.de
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Saturday, March 01, 2014 3:15 AM
Subject: [time-nuts] ADEV from phase or frequency measurement


 Hello dear fellow time-nuts,
 
 I stumbled over a question that may sound stupid to you:
 
 Is the usual ADEV plot the result of a phase or a frequency measurement?
 
 I get totally different results when comparing a phase and a frequency
 measurement of the same source. Or am I doing something totally wrong?
 
 Thanks a lot
 
 Volker


___
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 from phase or frequency measurement

[Volker Esper]

Thank you, Tom, so far. Yes, I know that I have to use different
formulas, but - of course - I didn't calculate the ADEV curves myself, I
let some software do the job, namely Ulrich's Plotter and TimeLab as
well. Plotter has a menu item, where you have to check if you deal with
phase or frequency data, so I assumed the software would do right.

I am confused. The ADEVs of the phase data are about 10 times better and
have a different shape...

Volker

Am 01.03.2014 12:37, schrieb Tom Van Baak:
 Hi Volker,

 Either phase or frequency raw data can be used to generate an ADEV plot, but 
 you have to use different methods depending on the data type.

 See the two formulas for Allan Variance in: http://www.wriley.com/paper2ht.htm

 Usually we use the x form of the formula, where x is an array of phase 
 samples. But if you have frequency samples then use the y form instead, 
 where y is an array of frequency samples.

 Note you can also convert phase data to frequency data (by differentiating) 
 and use the y form. Or convert frequency data to phase data (by 
 integrating) and use the x form.

 /tvb

 - Original Message - 
 From: Volker Esper ail...@t-online.de
 To: Discussion of precise time and frequency measurement 
 time-nuts@febo.com
 Sent: Saturday, March 01, 2014 3:15 AM
 Subject: [time-nuts] ADEV from phase or frequency measurement


 Hello dear fellow time-nuts,

 I stumbled over a question that may sound stupid to you:

 Is the usual ADEV plot the result of a phase or a frequency measurement?

 I get totally different results when comparing a phase and a frequency
 measurement of the same source. Or am I doing something totally wrong?

 Thanks a lot

 Volker

 ___
 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 from phase or frequency measurement

[Anders Wallin]

Here is python code for the most common deviations
https://github.com/aewallin/allantools/blob/master/allantools/allantools.py

each statistic (ADEV, MDEV, TDEV, and so on) has two functions. one takes
fractional frequency data, the other phase data. frequency2phase() and
phase2freqeuncy() show how the conversions are done.

Your patches are welcome!

Anders




On Sat, Mar 1, 2014 at 1:37 PM, Tom Van Baak t...@leapsecond.com wrote:

 Hi Volker,

 Either phase or frequency raw data can be used to generate an ADEV plot,
 but you have to use different methods depending on the data type.

 See the two formulas for Allan Variance in:
 http://www.wriley.com/paper2ht.htm

 Usually we use the x form of the formula, where x is an array of phase
 samples. But if you have frequency samples then use the y form instead,
 where y is an array of frequency samples.

 Note you can also convert phase data to frequency data (by
 differentiating) and use the y form. Or convert frequency data to phase
 data (by integrating) and use the x form.

 /tvb

 - Original Message -
 From: Volker Esper ail...@t-online.de
 To: Discussion of precise time and frequency measurement 
 time-nuts@febo.com
 Sent: Saturday, March 01, 2014 3:15 AM
 Subject: [time-nuts] ADEV from phase or frequency measurement


  Hello dear fellow time-nuts,
 
  I stumbled over a question that may sound stupid to you:
 
  Is the usual ADEV plot the result of a phase or a frequency measurement?
 
  I get totally different results when comparing a phase and a frequency
  measurement of the same source. Or am I doing something totally wrong?
 
  Thanks a lot
 
  Volker


 ___
 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 from phase or frequency measurement

[Magnus Danielson]

Volker,

On 01/03/14 12:15, Volker Esper wrote:

Hello dear fellow time-nuts,

I stumbled over a question that may sound stupid to you:

Is the usual ADEV plot the result of a phase or a frequency measurement?

I get totally different results when comparing a phase and a frequency
measurement of the same source. Or am I doing something totally wrong?


The core of the ADEV is the square of the second degree derivate of 
phase, where the phase measures are tau seconds away from each other.


You can use frequency measures, but it is likely that the start-point of 
the next measure is not the end point of the previous frequency measure. 
Then you have dead-time. Dead-time causes a bias in the ADEV measure and 
you need to use the dead-time bias function to compensate for this 
effect. This was explained by Dave Allan in his Feb 1966 article, as the 
2-point dead-time free variance was the unification of a large range of 
different measures, and he supplied the bias functions to unify them. 
Now that there was one variance to forge them all, they kept referring 
to it as Allan's variance and well, it's now history.


Another aspect is that your counter may do some smart filtering on the 
measures it makes. This reduces the bandwidth of the counter as the 
averaging removes noise. This also causes low-tau values that has 
white-phase noise to be lower than expected. This improvement is 
however not helping you to get better ADEV, it just fools you, as the 
ADEV of white phase noise will depend on the measurement bandwidth, 
known for a long time but ignored my many measurement setups.


I've tried to cover these topics on the Allan Variance Wikipedia article.

I would avoid using frequency measures from counters if phase measures 
can be made, as you can avoid both these issues rather than requiring to 
measure their effect and compensate for it. It is tricky to maintain 
valid numbers that way.


There are cases where ADEV is better calculated from frequency measures, 
so it is a valid tool, but care always needs to be taken to make sure 
the numbers remains scaled properly.


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 from phase or frequency measurement

[Magnus Danielson]

On 01/03/14 13:25, Volker Esper wrote:

Thank you, Tom, so far. Yes, I know that I have to use different
formulas, but - of course - I didn't calculate the ADEV curves myself, I
let some software do the job, namely Ulrich's Plotter and TimeLab as
well. Plotter has a menu item, where you have to check if you deal with
phase or frequency data, so I assumed the software would do right.

I am confused. The ADEVs of the phase data are about 10 times better and
have a different shape...


Can you supply the TimeLab plots or even measurement files?

What was your counter and setup?

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 from phase or frequency measurement

[Azelio Boriani]

This is because usually a counter that has the time interval feature
behaves better in time interval mode. As already pointed out here, use
always the time interval mode to take samples for the Allan deviation.
In frequency mode the counter uses average or various tricks to smooth
readings, so better to switch to time interval mode in order to take
clean samples for the post processing.

On Sat, Mar 1, 2014 at 1:25 PM, Volker Esper ail...@t-online.de wrote:
 Thank you, Tom, so far. Yes, I know that I have to use different
 formulas, but - of course - I didn't calculate the ADEV curves myself, I
 let some software do the job, namely Ulrich's Plotter and TimeLab as
 well. Plotter has a menu item, where you have to check if you deal with
 phase or frequency data, so I assumed the software would do right.

 I am confused. The ADEVs of the phase data are about 10 times better and
 have a different shape...

 Volker

 Am 01.03.2014 12:37, schrieb Tom Van Baak:
 Hi Volker,

 Either phase or frequency raw data can be used to generate an ADEV plot, but 
 you have to use different methods depending on the data type.

 See the two formulas for Allan Variance in: 
 http://www.wriley.com/paper2ht.htm

 Usually we use the x form of the formula, where x is an array of phase 
 samples. But if you have frequency samples then use the y form instead, 
 where y is an array of frequency samples.

 Note you can also convert phase data to frequency data (by differentiating) 
 and use the y form. Or convert frequency data to phase data (by 
 integrating) and use the x form.

 /tvb

 - Original Message -
 From: Volker Esper ail...@t-online.de
 To: Discussion of precise time and frequency measurement 
 time-nuts@febo.com
 Sent: Saturday, March 01, 2014 3:15 AM
 Subject: [time-nuts] ADEV from phase or frequency measurement


 Hello dear fellow time-nuts,

 I stumbled over a question that may sound stupid to you:

 Is the usual ADEV plot the result of a phase or a frequency measurement?

 I get totally different results when comparing a phase and a frequency
 measurement of the same source. Or am I doing something totally wrong?

 Thanks a lot

 Volker

 ___
 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 computed, now what?

[Charles Steinmetz]

Bob wrote:

here's the result for 1PPS vs 10MHz for my GPSDO, as measured by a 
5334B clocked by the same 10MHz.I don't know how to read these, 
but 6,3,1,6,3,1 etc. doesn't look normal.


The adev results you obtained look very much like the adev results 
reported by Lady Heather, very likely for the same reason -- you do 
not have any independent standard by which to measure.


From what you say above, it appears that you measured the time 
interval between one edge of the PPS pulse and the next zero-cross of 
the GPSDO 10 MHz, using a 5334B clocked by the GPSDO 10 MHz.  Is that 
correct?  I take it the GPSDO is disciplined by the PPS?


Bear in mind (i) that you are comparing one noisy source to another, 
and (ii) that the errors are correlated more and more strongly as tau 
increases beyond the point where the discipline loop begins 
controlling the 10 MHz oscillator.  At small tau, the GPS PPS is very 
noisy (much noisier than the 10 MHz oscillator), and it gets better 
and better as you average for longer and longer periods until at tau 
above 10k it's reasonably decent.  Your GPSDO should leave the 
oscillator more or less on its own at low tau (where the jitter in 
the oscillator is lower than the jitter in the PPS), and correct it 
beginning at some longer tau where the jitters are comparable 
(continuing to even longer tau where the jitter in the PPS is lower 
than the jitter in the oscillator).


So, measuring as you appear to be doing, at low tau you are 
essentially measuring the improvement of the PPS with averaging -- 
10x per decade -- using the essentially undisciplined 10 MHz 
oscillator as a standard.  At some point, you would expect to reach a 
floor where you would essentially be measuring the residual jitter in 
the disciplined oscillator and the PPS.  In fact, you can see this in 
your results starting around tau = 500, but your series does not go 
far enough to show the floor clearly.


Bob suggested that you are measuring the trigger error of the 5334B, 
and that may be contributing to your results as well.  With good 
measurement techniques, the outer bound of the 5334B trigger error 
should be less than 1nS, probably more like 200-300pS.  Your actual 
error is probably significantly lower than this outer bound unless 
something is wrong with your setup.  The trigger contribution to your 
computed adev should also fall 10x per decade with increasing tau.


Best regards,

Charles



___
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 computed, now what?

[Bob Stewart]

Hi Charles,

I've had a night to digest what I'm seeing, and this is what I've come up with:

There were only 2 updates to the DAC during the 24 hours tested.  So, long term 
doesn't system drift dominate?  That would include thermal drift and the 
stability of the OCXO.  Also, there was a phase crossing for both of those 
updates.  Short term there's the fact that this an Adafruit GPS Nav receiver 
(MTK-3339) with a spec of 10ns jitter.  Looking at the GPS track, it is 
moving in a diamond shaped area about 41 ft from point to opposite point.  
Sometimes it's not a smooth movement, with a jerk of perhaps 6 feet.  And 
there's the fact that the 1PPS has lots of ugly quantization errors, but I have 
no way of sensing them, much less correcting them.  (The 5335B is not part of 
the loop.  The phase error value is only an external measurement fed to my PC.)


So, short term, it seems to be a measurement of the 1PPS from the MTK-3339, and 
long term a measurement of the drift of the Tekelec DOC-1903 OCXO, including 
the impact of the phase crossings that my code can't prevent.  There is also 
the thermal drift in there somewhere, but it was very well behaved during this 
test run.

OK, I've just reread your post, and it seems that I've just reworded it.  Well, 
at least that means I'm beginning to understand what I have.  I don't have any 
more accurate standards than this, so I don't see any way of improving my 
measurements.  But, all in all, I'm satisfied that it's as accurate as I'll 
ever need.  But, I'll probably keep fiddling with the code to see if I can 
eliminate that dependency on phase crossings to update the DAC.


Bob





 From: Charles Steinmetz csteinm...@yandex.com
To: Discussion of precise time and frequency measurement time-nuts@febo.com 
Sent: Wednesday, February 5, 2014 5:47 AM
Subject: Re: [time-nuts] ADEV computed, now what?
 

Bob wrote:

 here's the result for 1PPS vs 10MHz for my GPSDO, as measured by a 5334B 
 clocked by the same 10MHz.    I don't know how to read these, but 
 6,3,1,6,3,1 etc. doesn't look normal.

The adev results you obtained look very much like the adev results reported 
by Lady Heather, very likely for the same reason -- you do not have any 
independent standard by which to measure.

From what you say above, it appears that you measured the time interval 
between one edge of the PPS pulse and the next zero-cross of the GPSDO 10 MHz, 
using a 5334B clocked by the GPSDO 10 MHz.  Is that correct?  I take it the 
GPSDO is disciplined by the PPS?

Bear in mind (i) that you are comparing one noisy source to another, and (ii) 
that the errors are correlated more and more strongly as tau increases beyond 
the point where the discipline loop begins controlling the 10 MHz oscillator.  
At small tau, the GPS PPS is very noisy (much noisier than the 10 MHz 
oscillator), and it gets better and better as you average for longer and 
longer periods until at tau above 10k it's reasonably decent.  Your GPSDO 
should leave the oscillator more or less on its own at low tau (where the 
jitter in the oscillator is lower than the jitter in the PPS), and correct it 
beginning at some longer tau where the jitters are comparable (continuing to 
even longer tau where the jitter in the PPS is lower than the jitter in the 
oscillator).

So, measuring as you appear to be doing, at low tau you are essentially 
measuring the improvement of the PPS with averaging -- 10x per decade -- using 
the essentially undisciplined 10 MHz oscillator as a standard.  At some point, 
you would expect to reach a floor where you would essentially be measuring the 
residual jitter in the disciplined oscillator and the PPS.  In fact, you can 
see this in your results starting around tau = 500, but your series does not 
go far enough to show the floor clearly.

Bob suggested that you are measuring the trigger error of the 5334B, and that 
may be contributing to your results as well.  With good measurement 
techniques, the outer bound of the 5334B trigger error should be less than 
1nS, probably more like 200-300pS.  Your actual error is probably 
significantly lower than this outer bound unless something is wrong with your 
setup.  The trigger contribution to your computed adev should also fall 10x 
per decade with increasing tau.

Best regards,

Charles



___
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 computed, now what?

[Bob Camp]

Hi

What you have measured is the trigger error of your 5334. Since the 10 MHz and 
the pps are from the same source, all that’s left is trigger.

Bob

On Feb 4, 2014, at 9:45 PM, Bob Stewart b...@evoria.net wrote:

 I think I have the unwrapping and scaling sorted out, so here's the result 
 for 1PPS vs 10MHz for my GPSDO, as measured by a 5334B clocked by the same 
 10MHz.I don't know how to read these, but 6,3,1,6,3,1 etc. doesn't look 
 normal.  I wonder if that merely reflects the consumer grade GPS receiver I'm 
 using (Adafruit Ultimate Breakout), rather than a reflection on the ultimate 
 result?  I can link to a plot of the 1PPS vs 10MHz if that's wanted.
 
 
 Any comments appreciated.
 
 
 ** Sampling period: 1 s
 ** Phase data scale factor: 1.000e-09
 ** Total phase samples: 86399
 ** Normal and Overlapping Allan deviation:
 
1 tau, 6.1669e-09 adev(n=86397), 6.1669e-09 oadev(n=86397)
2 tau, 3.2413e-09 adev(n=43198), 3.2349e-09 oadev(n=86395)
5 tau, 1.2603e-09 adev(n=17278), 1.2470e-09 oadev(n=86389)
   10 tau, 6.0606e-10 adev(n=8638),  5.9837e-10 oadev(n=86379)
   20 tau, 3.1173e-10 adev(n=4318),  3.0967e-10 oadev(n=86359)
   50 tau, 1.2778e-10 adev(n=1726),  1.2618e-10 oadev(n=86299)
  100 tau, 6.2970e-11 adev(n=862),   6.3607e-11 oadev(n=86199)
  200 tau, 3.6391e-11 adev(n=430),   3.2994e-11 oadev(n=85999)
  500 tau, 1.4055e-11 adev(n=171),   1.4008e-11 oadev(n=85399)
 1000 tau, 8.4596e-12 adev(n=85),7.8291e-12 oadev(n=84399)
 2000 tau, 4.8688e-12 adev(n=42),5.0306e-12 oadev(n=82399)
 5000 tau, 3.7358e-12 adev(n=16),4.1679e-12 oadev(n=76399)
1 tau, 3.7403e-12 adev(n=7), 3.5550e-12 oadev(n=66399)
2 tau, 1.9271e-12 adev(n=3), 2.6676e-12 oadev(n=46399)
 ___
 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 ScaleFactor correction

[Magnus Danielson]

On 16/01/14 07:54, WarrenS wrote:


ADEV is a great tool for measuring random noise but not so good for systematic 
errors like ageing drift.
I have seen on the better oscillator's that the typical ADEV rise with time is 
often the effect of changing temperature and/or ageing drift.

I did an experiment to determine what scale factor correction is needed for 
determining an oscillator's linear freq ageing drift rate over time using ADEV 
/ MDEV data.
I used a good HP10811 osc whose drift rate when left on continuously is well 
below 1e-10 / day with an ADEV / MDEV of around 1e-12 between 0.1 to 100 sec.
This osc has not been powered up for a few months, so it's initial turn on 
drift rate was very high at ~1.3 e-8 / day.
By plotting both its actual drift rate change and it's varying ADEV as the unit 
is restabilizing, I found that the oscillator's actual drift rate was equal to 
1.4 times the ADEV value.

That is with an ADEV value of 1e-10 at 1000 seconds, the oscillator's actual 
frequency ageing drift rate at that time was 1.4 e-10 per 1000 seconds.
The 1.4 scale factor correction worked in this case from below 100 seconds to 
greater than 10K seconds.
Of course this scale factor only applies when the oscillator's drift rate is 
constant and is the major error source for the given ADEV time period and data 
run.
The same scale factor also works using MDEV data, because in this case, the 
MDEV values are the same as the ADEV values at time periods when ageing drift 
is the major error source.

Attached are two TimeLab plots that I used to find the scale factor correction, 
showing the ageing drift rate and the changing ADEV values as this oscillator  
restabilizes.


The linear frequency drift causes an ADEV linear ramp of D*tau/sqrt(2) 
as found here:


http://en.wikipedia.org/wiki/Allan_variance#Linear_response

For raw measures being uncompensated of oscillator systematic drift, the 
drift will indeed overshadow the upper end of the ADEV/MDEV plot.
It turns out that below the linear frequency drift is higher terms, so 
just removing the linear drift does not completely remove the systematic 
components. ADEV was only means for the noise components, so systematic 
components should be separated and analysed separately. Their confidence 
bounds is way different.


I try to let oscillators sit powered up as long as possible to reduce 
the drift from my measurements.


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 ScaleFactor correction

[Tom Van Baak]

 The 1.4 scale factor correction worked

Nice confirmation.

The actual number is sqrt(2). Look at the definition of ADEV 
(http://tf.nist.gov/images/adevfreq.gif) to see why.

Note sqrt(2) = 1.414 and 1/sqrt(7) is 0.707. The rule-of-thumb is that ADEV(tau 
1 day) is 0.707 the daily drift rate; which is to say the daily drift rate is 
1.414 ADEV(tau 1 day).

/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 ScaleFactor correction

[Chuck Harris]

1/sqrt(7) = 0.37796...

sqrt(2)/2 = 0.707...

-Chuck Harris

Tom Van Baak wrote:

The 1.4 scale factor correction worked


Nice confirmation.

The actual number is sqrt(2). Look at the definition of ADEV
(http://tf.nist.gov/images/adevfreq.gif) to see why.

Note sqrt(2) = 1.414 and 1/sqrt(7) is 0.707. The rule-of-thumb is that ADEV(tau 
1
day) is 0.707 the daily drift rate; which is to say the daily drift rate is 
1.414
ADEV(tau 1 day).

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


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

[Magnus Danielson]

On 08/12/2012 05:02 AM, WarrenS wrote:


The basic problem is that one can not meet Allan's requirement
of the integral of the instantaneous frequencies over tau0 time
and Nyquist-Shannon sampling theorem requirement if taking just
one raw phase sample per displayed ADEV tau0.
The two requirements are then mutually exclusive.
This is especially true when that sample is coming from a
DTMD zero crossing detector.

The way I get ADEV tau answers that do not droop at all near tau0,
and that are independent of the displayed tau0, the oversample rate
and the NEQ.BW filter (if BW  2* tau0) without having to throw
away the low tau answers or save data files with more than tau0
number of samples, is by oversampling the raw data and then
reducing it in an appropriate way before saving it as tau0.
With high speed oversampling it is also very simple to avoid
any aliasing problems.

Using an external DC coupled sound card, oversampling at 48KHz
for any tau0, both the TPLL2.0 and the XOR-LPD give non-drooping
tau0 answers that are not a function of the oversample rate or the tau0
reduction rate.
That is, get the same ADEV tau 1sec answer if the tau0 is 1KHz, 1Hz or
anywhere in-between.


The problem with counters is that they often sample to infrequently. An 
audio rate sampling and proper conversion of the DM beat note will just 
as your TPLL2.0 provide sufficient sample rate. If you where trying to 
make ADEV plots all the way to your sample-rate, you would get droop 
too, but since you don't you don't experience it. That is because you do 
keep sufficient number of samples on the first displayed tau.


The same behaviour has been seen in the TimePod for instance.

So, it just illustrates how you need to handle your data, not that the 
method itself is 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 drop

[WarrenS]

The basic problem is that one can not meet Allan's requirement
of the integral of the instantaneous frequencies over tau0 time
and Nyquist-Shannon sampling theorem requirement if taking just
one raw phase sample per displayed ADEV tau0.
The two requirements are then mutually exclusive.
This is especially true when that sample is coming from a
DTMD zero crossing detector.

The way I get ADEV tau answers that do not droop at all near tau0,
and that are independent of the displayed tau0, the oversample rate
and the NEQ.BW filter (if BW  2* tau0) without having to throw
away the low tau answers or save data files with more than tau0
number of samples, is by oversampling the raw data and then
reducing it in an appropriate way before saving it as tau0.
With high speed oversampling it is also very simple to avoid
any aliasing problems.

Using an external  DC coupled sound card, oversampling at 48KHz
for any tau0, both the TPLL2.0 and the XOR-LPD give non-drooping
tau0 answers that are not a function of the oversample rate or the tau0
reduction rate.
That is, get the same ADEV tau 1sec answer if the tau0 is 1KHz, 1Hz or 
anywhere in-between.


ws



Fellow time-nuts,

As David insisted that I get and then read the ITU Handbook Selection
and Use of Precise Frequency and Time Systems (1997) and in particular
Chapter 3 I took the time to get it and start reading it. In there I
found clause 3.3.2.4.4 Truncation effects, which addresses this issue,
which also aligns up with my own writing on Allan Deviation, and the
Measurement bandwidth limit (I will have to update that one).

The key point is that the main lobe of the kernel function (the way that
the sin(pi*tau*f)^4/x^n look), will be affected by the system bandwidth
and values will be not matching up to the brick-wall analysis of the
traditional system. The result will be that the ADEV measure will be
lower than it should. This situation was analysed by Bernier in 1987 as
part of analysing the modified Allan deviation, which has a software
bandwidth filter in the form of the n*tau_0 average filter.

So, the first low n values is even expected to give systematic low
values, which is the reason for the ITU-T to put minimum requirements on
the tau_0 to lowest tau to ensure that repeatability is achieved.

This is also the same effect that Sam Steiner mentioned in his
presentation during this years NIST seminars. Sam also went on to
discuss the effect of aliasing, which helps to bring even more false
values in that region.

Conclusion: Just don't look all that hard on the lower tau values, as
they can be systematically off. Make sure that you have a tau_0 well
below the taus you are interested in to ensure that your values is
reasonably valid.

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 noise bandwidth (was LPRO Rubidium Performance)

[Magnus Danielson]

On 02/13/2012 02:19 AM, John Miles wrote:

The ADEV difference of about 6 db at 1ms tau can be explained by the fact
that if I apply a 500 Hz LP  filter to my 9600 sps raw data, the same

filter

used on the 5120A's  1K sps data, then even our 1ms ADEV answers
become very close.
I have found that using a 1/2 zero tau BW filter like the 5120A does can
falsely lower its tau zero ADEV answer by 3 to 6 dB.
The 5120A's use of a 1/2 tau zero LP cutoff filter is why the 5120A ADEV
answers are generally not the same at Tau zero when sampled at different
tau
zero rates.


At least some of that effect comes down to the improvement in the instrument
floor at lower filter bandwidths, but I agree that not all of it does.  An
example that bothers me is the BVA-vs-H-maser plot at
http://www.leapsecond.com/pages/adev-bw/ compared to the BVA J1 vs J2 plot
right below it.  The latter is mostly determined by the instrument floor,
since J1 and J2 are driven by the same source through two buffers that are
presumably very phase-stable.


Even if it is a bit hard to see, that white phase modulation does seem 
to follow the power-laws of


http://en.wikipedia.org/wiki/Allan_variance#Power-law_noise

Notice how the square root of bandwidth will scale the Allan deviation 
result.


PS. I just added the Allan deviation formulas to assist you.

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

[Mike Feher]

10 MHz locked LNBs do not use a separate connector. Everything goes down/up
the single main coax. The typical L-band down-converted frequency and the 10
MHz are easily separated, as is the DC. These are definitely not
inexpensive. Regards - Mike 

Mike B. Feher, EOZ Inc.
89 Arnold Blvd.
Howell, NJ, 07731
732-886-5960 office
908-901-9193 cell

-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of jimlux
Sent: Sunday, November 14, 2010 11:49 PM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] ADEV

David I. Emery wrote:

   3. External reference LNBs with 10 MHz (pretty universal) going
 up the cable that also carries power and brings the L band signal down.
 I'm not entirely sure how many of these designs simply bandpass filter
 and then limit the 10 MHz and use that directly as a PLL reference and
 how many phase lock a VCXO to the 10 MHz coming in.  Otherwise similar
 (and often  derived from designs for) the internal reference PLL types
 in 2 above.

And, I'll bet those are fairly pricey.. (after all, it needs another 
connector, and that's a price sensitive application..)



___
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

[David I. Emery]

On Sat, Nov 13, 2010 at 07:01:26AM -0800, jimlux wrote:
 
 To the Ku-band downconverters..  They're pretty crummy (but have a 
 decent SNR to work with).. however, I've seen that there are two kinds.. 
 a vanilla LNB and ones described as crystal locked... both are cheap 
 ($20-30 for the former, maybe twice that for the latter)... what's the 
 difference?  And, getting into time-nuts territory here, where's the 
 reference for the locked variety coming from? Up the coax? inside the 
 LNB?  And, can it be retrofitted from a much quieter oscillator?   I was 
 thinking that one could build a radio camera with a small array of 
 Ku-band dishes, if you could lock all the receivers together.  They 
 *are* pretty low noise (20-30K)

There are three kinds of LNBs in common use in the VSAT world...


1.  Open loop unlocked DROs, often with around a MHz or two or
more error due to temperature and calibration and drift over time.  More
expensive higher grade ones are tighter spec'd, but rarely much less
than 250-500 KHz over time and temp.   Most all DTH dishes use these,
often with rather loose frequency specs since the DTH carriers are wide,
fast signals.

2.  Closed loop DROs phase locked to a crystal or I believe
about as common, a UHF or higher frequency oscillator phase locked to a
crystal reference with some degree of multiplication to the final LO
frequency (maybe not much these days with fast prescaler/divider chips).
Crystal in this case is - depending on price - just a plain XO or either
a TXCO or in certain cases a OXCO.   More expensive ones have better
stability specs.Generally these sell for 5-10 times what a cheap DRO
LNB for the mass market might go for.  And can be as good as 1 PPM or
so.

PLL LNBs are mostly used for data or audio transmissions on
narrower, lower  bit rate carriers than TV but also used for many critical
professional TV broadcast and similar applications.

3. External reference LNBs with 10 MHz (pretty universal) going
up the cable that also carries power and brings the L band signal down.
I'm not entirely sure how many of these designs simply bandpass filter
and then limit the 10 MHz and use that directly as a PLL reference and
how many phase lock a VCXO to the 10 MHz coming in.  Otherwise similar
(and often  derived from designs for) the internal reference PLL types
in 2 above.

These ER types are more apt to be used for more exotic
specialized applications where very high frequency accuracy or some
degree of phase coherence  with other equipment or LNBs is useful.

Obviously with the high multiplication factor, one needs a quiet
reference inside the PLL bandwidth (and that is pretty wide to ensure 
reliable lock) - one suspects that issues with degradation due to
mechanically induced noise and phase shift in the cables can be a
problem.


-- 
  Dave Emery N1PRE/AE, d...@dieconsulting.com  DIE Consulting, Weston, Mass 
02493
An empty zombie mind with a forlorn barely readable weatherbeaten
'For Rent' sign still vainly flapping outside on the weed encrusted pole - in 
celebration of what could have been, but wasn't and is not to be now either.


___
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

[jimlux]

David I. Emery wrote:

On Sat, Nov 13, 2010 at 07:01:26AM -0800, jimlux wrote:
To the Ku-band downconverters..  They're pretty crummy (but have a 
decent SNR to work with).. however, I've seen that there are two kinds.. 
a vanilla LNB and ones described as crystal locked... both are cheap 
($20-30 for the former, maybe twice that for the latter)... what's the 
difference?  And, getting into time-nuts territory here, where's the 
reference for the locked variety coming from? Up the coax? inside the 
LNB?  And, can it be retrofitted from a much quieter oscillator?   I was 
thinking that one could build a radio camera with a small array of 
Ku-band dishes, if you could lock all the receivers together.  They 
*are* pretty low noise (20-30K)


There are three kinds of LNBs in common use in the VSAT world...


1.  Open loop unlocked DROs, often with around a MHz or two or
more error due to temperature and calibration and drift over time.  More
expensive higher grade ones are tighter spec'd, but rarely much less
than 250-500 KHz over time and temp.   Most all DTH dishes use these,
often with rather loose frequency specs since the DTH carriers are wide,
fast signals.

2.  Closed loop DROs phase locked to a crystal or I believe
about as common, a UHF or higher frequency oscillator phase locked to a
crystal reference with some degree of multiplication to the final LO
frequency (maybe not much these days with fast prescaler/divider chips).
Crystal in this case is - depending on price - just a plain XO or either
a TXCO or in certain cases a OXCO.   More expensive ones have better
stability specs.Generally these sell for 5-10 times what a cheap DRO
LNB for the mass market might go for.  And can be as good as 1 PPM or
so.



Bummer.. so much for making myself a radio camera with scavenged Ku-band 
 DBS dishes/feeds (when people around here subscribe, they just junk 
the existing, almost identical, assembly)..


I was willing to spend a few tens of dollars/element.. But $100/element 
is pushing it out of the hmm, interesting project for not much money, 
can I accumulate some more junk in the garage category.





PLL LNBs are mostly used for data or audio transmissions on
narrower, lower  bit rate carriers than TV but also used for many critical
professional TV broadcast and similar applications.

3. External reference LNBs with 10 MHz (pretty universal) going
up the cable that also carries power and brings the L band signal down.
I'm not entirely sure how many of these designs simply bandpass filter
and then limit the 10 MHz and use that directly as a PLL reference and
how many phase lock a VCXO to the 10 MHz coming in.  Otherwise similar
(and often  derived from designs for) the internal reference PLL types
in 2 above.


And, I'll bet those are fairly pricey.. (after all, it needs another 
connector, and that's a price sensitive application..)




Hmm.. I wonder if one could do the pilot tone technique.. I can radiate 
a weak Ku band signal, in band, and record what I see from the LNB, then 
post process to close the loop in software.  Have to think about that 
some more.. The Ku band beacon/pilot is easy (a comb), so what I'd need 
is a multichannel softrock type receiver (which has other uses) that 
can deal with the L-band IF from the cheap LNBs.  I wonder if the LO of 
the cheap LNBs are within, say, 50kHz of each other.. Then I could use a 
common L-band LO.. But based on the discussion above, probably not.




___
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

[Rex]

On 11/14/2010 7:24 PM, David I. Emery wrote:


3. External reference LNBs with 10 MHz (pretty universal) going
up the cable that also carries power and brings the L band signal down.
I'm not entirely sure how many of these designs simply bandpass filter
and then limit the 10 MHz and use that directly as a PLL reference and
how many phase lock a VCXO to the 10 MHz coming in.  Otherwise similar
(and often  derived from designs for) the internal reference PLL types
in 2 above.

These ER types are more apt to be used for more exotic
specialized applications where very high frequency accuracy or some
degree of phase coherence  with other equipment or LNBs is useful.

Obviously with the high multiplication factor, one needs a quiet
reference inside the PLL bandwidth (and that is pretty wide to ensure
reliable lock) - one suspects that issues with degradation due to
mechanically induced noise and phase shift in the cables can be a
problem.



I picked up an LNB a about 10 years back that used this external 
reference method.  The LO in the thing was a DRO that locked to a 10 MHz 
signal coming up the cable. The LO in this one locked to 10.750 GHz. 
Experimenting, I found that the DRO adjustment screw could be turned and 
it would lock every 10 MHz. I found it would lock as low as 10.690. I 
assume it would tune up about that far too.


I needed an LO in the 10 GHz area, so I hacked mine to use it just as a 
LO, not using any of the receive chain. Here's a page where I described 
the LNB and what I did with it.


http://www.xertech.net/Projects/sat_lo.html

Maybe the description there will help someone. If nothing else, it show 
pictures of what one external ref type LNB looks like.




___
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

[Magnus Danielson]

On 11/13/2010 02:20 PM, Mike Feher wrote:

I sure do agree, that with very low data rate systems it is significant. In
fact, when David Allan  Fred Walls came up with the proposal of using this
measurement as an FOM for oscillators over 30 years ago, digital
communication rates were slow, and, the measurement was a good one.


ADEV can be trace back to 1966, but even prior to that similar estimates 
was being used in the scientific research, but the Allan article of 1966 
provides part of the critical analysis which makes the M-sample analysis 
into the Allan-variance as we know it.


Their concerns where with oscillators and not data-communication which 
has its own set of problems and measures.



Due to the filtering process within ADEV by collecting and integrating a large
number of samples, has a filtering effect of its own. Therefore, it can, and
will, miss the fact that there may be instantaneous phase transitions that
could cause havoc with high data rates and higher order PSK modulation
schemes.  So, again, I apologize, as I should have mentioned higher data
rates.


Data-rates is actually not particularly interesting, it is the dynamic 
properties regardless of rate, which is only a scale-factor. The 
property of phase-jumps is well covered in the MTIE measurement which is 
used along-side the TDEV measurement for telecommunication systems.
MTIE provides the Maximum Time Interval Error... so for a window of 
length tau, what is the maximum difference between high and low? This is 
measured by taking the difference between max and min in a window, slide 
it over the data and take the maximum difference. This relates very well 
to buffer-size action and if converted over to a sine-tolerance curve 
(using f=1/(pi*tau) ) also can be made to match up with PLL responses.


Come to think of it, I have not seen any good Wikipedia article on it.

Anyway, one really has to understand what kind of measurement is 
adequate for the technical problem one is trying to address.


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

[Mike Feher]

I agree with all of the comments. My problem now is attempting to fight an
internal Gov't battle, where there is too much emphasis on ADEV, as an
indicator to overall system performance. Thanks for all the replies. Regards
- Mike

Mike B. Feher, EOZ Inc.
89 Arnold Blvd.
Howell, NJ, 07731
732-886-5960 office
908-901-9193 cell


-Original Message-
From: time-nuts-boun...@febo.com [mailto:time-nuts-boun...@febo.com] On
Behalf Of Bob Camp
Sent: Saturday, November 13, 2010 9:06 AM
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] ADEV

Hi

I see ADEV not as a solution to a system design problem, but an oscillator
measurement issue. If you look at the measures being used in the 60's, most
of them had serious statistical flaws. You could measure them several ways
and get multiple results. What ADEV gave us is a measure that could be done
repeatably. You still have to do it right, but if you do it repeats.  If
there is a systems rationale in the development of the measurement it's
awfully well hidden in the early papers.

Bob


On Nov 13, 2010, at 8:53 AM, Magnus Danielson wrote:

 On 11/13/2010 02:20 PM, Mike Feher wrote:
 I sure do agree, that with very low data rate systems it is significant.
In
 fact, when David Allan  Fred Walls came up with the proposal of using
this
 measurement as an FOM for oscillators over 30 years ago, digital
 communication rates were slow, and, the measurement was a good one.
 
 ADEV can be trace back to 1966, but even prior to that similar estimates
was being used in the scientific research, but the Allan article of 1966
provides part of the critical analysis which makes the M-sample analysis
into the Allan-variance as we know it.
 
 Their concerns where with oscillators and not data-communication which has
its own set of problems and measures.
 
 Due to the filtering process within ADEV by collecting and integrating a
large
 number of samples, has a filtering effect of its own. Therefore, it can,
and
 will, miss the fact that there may be instantaneous phase transitions
that
 could cause havoc with high data rates and higher order PSK modulation
 schemes.  So, again, I apologize, as I should have mentioned higher data
 rates.
 
 Data-rates is actually not particularly interesting, it is the dynamic
properties regardless of rate, which is only a scale-factor. The property of
phase-jumps is well covered in the MTIE measurement which is used along-side
the TDEV measurement for telecommunication systems.
 MTIE provides the Maximum Time Interval Error... so for a window of length
tau, what is the maximum difference between high and low? This is measured
by taking the difference between max and min in a window, slide it over the
data and take the maximum difference. This relates very well to buffer-size
action and if converted over to a sine-tolerance curve (using f=1/(pi*tau) )
also can be made to match up with PLL responses.
 
 Come to think of it, I have not seen any good Wikipedia article on it.
 
 Anyway, one really has to understand what kind of measurement is adequate
for the technical problem one is trying to address.
 
 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.


___
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

[Magnus Danielson]

Hi Bob,

On 11/13/2010 03:05 PM, Bob Camp wrote:

Hi

I see ADEV not as a solution to a system design problem, but an oscillator 
measurement issue.
If you look at the measures being used in the 60's, most of them had serious 
statistical flaws.
You could measure them several ways and get multiple results. What ADEV gave us 
is a measure
that could be done repeatably. You still have to do it right, but if you do it 
repeats.  If
there is a systems rationale in the development of the measurement it's awfully 
well hidden
in the early papers.


I completely agree, having spent quite some time in those early papers. 
They had problems to handle the noise of oscillators, and having those 
problems, how can you attack the system design problems? They had 
obvious needs for it in developing doppler radars for instance, but also 
for the space program. One of the big meetings on this topic was in the 
NASA Goddard space center, and the result of that is found in the NASA 
Special Publication 80 (SP-80):

http://hdl.handle.net/2060/19660001092

Un the part 1 User's viewpoint and requirements
First article in there is Short-term stability for a doppler radar: 
Requirements, Measurements and Techniques by D.B. Leeson and G.F. Johnsson.
Fifth article is Satellite Range and Tracking Accuracy as a function of 
Oscillator STability by J.J. Caldwell Jr.
Sixth article is Short-term Stability Requirements for Deep Space 
Tracking and Communications systems by R. L. Sydnor.


I think the system applications for short-term stability measurements 
was quite clear, and was brought out specifically.


ADEV addresses the oscillator noise issues, but isn't particularly well 
suited for the numerous of systematic effects that comes on top of the 
oscillator noise in the system.


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

[jimlux]

Mike Feher wrote:

I sure do agree, that with very low data rate systems it is significant. In
fact, when David Allan  Fred Walls came up with the proposal of using this
measurement as an FOM for oscillators over 30 years ago, digital
communication rates were slow, and, the measurement was a good one. Due to
the filtering process within ADEV by collecting and integrating a large
number of samples, has a filtering effect of its own. Therefore, it can, and
will, miss the fact that there may be instantaneous phase transitions that
could cause havoc with high data rates and higher order PSK modulation
schemes. So, again, I apologize, as I should have mentioned higher data
rates. However, you must admit that your application, while extremely
critical, is in the minority. I like to use the example of something like
DirecTV. Here, they use a down-converter that utilizes a free running DRO,
that is ridiculously noisy, and, varies all over in frequency, especially
over the temperature ranges it subjected to. In spite of all of that, one
gets a perfect pictures. Regards - Mike




no apologies necessary..  After all, I spend a small, but significant, 
amount of time explaining why we'd care about such things, since we are 
in the distinct minority of the radio comm world  (trying to write nice 
comments on failed SBIR proposal evaluations to explain why they missed 
the big picture)


And, on the one hand, it's frustrating being the orphan child of the RF 
user community: you can't get off the shelf test equipment.  On the 
other hand, it's cool, because then you have to *build* your test 
equipment.


To the Ku-band downconverters..  They're pretty crummy (but have a 
decent SNR to work with).. however, I've seen that there are two kinds.. 
a vanilla LNB and ones described as crystal locked... both are cheap 
($20-30 for the former, maybe twice that for the latter)... what's the 
difference?  And, getting into time-nuts territory here, where's the 
reference for the locked variety coming from? Up the coax? inside the 
LNB?  And, can it be retrofitted from a much quieter oscillator?   I was 
thinking that one could build a radio camera with a small array of 
Ku-band dishes, if you could lock all the receivers together.  They 
*are* pretty low noise (20-30K)


___
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

[jimlux]

Magnus Danielson wrote:

Hi Bob,


snip

I think the system applications for short-term stability measurements 
was quite clear, and was brought out specifically. 


Basically, these are all systems where there is some storage or 
delay and you are comparing a signal generated/recorded at some time t 
with that signal at some time t+delta, where delta is in the seconds to 
minutes range.  (well, milliseconds in the radar case)...


(the really slow speed comm application is slightly different.. there, 
it's more of a reciprocal mixing of close in noise and a frequency 
stability in the hours/days sense issue.. although for one-way doppler 
measurements ADEV is important)




ADEV addresses the oscillator noise issues, but isn't particularly well 
suited for the numerous of systematic effects that comes on top of the 
oscillator noise in the system.


yes. but some familiarity with how ADEV is measured/computed, and the 
fact that there are test sets out there that make a plot of ADEV means 
that you can look at a ADEV plot for the system, and if it deviates from 
that for the underlying oscillators, you can make some educated guesses 
about the system issues.  Not that it's best, by any means, but at least 
it exists.


When buying or building a complex system, one is often faced with the 
problem of how do we write a testable specification or requirement to 
show that the completed widget works.  And, further, you generally don't 
want to spend more developing the test than the thing you are buying. 
It does happen, though..probably part of the game for developing at the 
ragged edge of performance.  However, if you can sort of back your way 
into an analysis that shows that a performance of X on test Y (no matter 
how unsuited philosophicaly) means that you will get performance Z on 
important requirement Q, then all is good.


At work, we refer to the developing of a whole subproject to understand 
and test how the primary object is working as doing a science 
project.. but that's because I work in an engineering area as opposed 
to one of the science areas, where science projects are their lives. 
By the time we get it, we're on a schedule and budget that doesn't allow 
for much contemplation, reflection, and thinking about how to best do 
things: planetary motion waits for no man, and the launch period is a 
few weeks long, at best.








___
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

[Bob Camp]

Hi

I don't see anybody arguing that systems work better when there's a high ADEV 
than a low ADEV. Most of the papers are heading in the direction of it doesn't 
catch all of the problems I worry about. Based on what systems need and what 
ADEV measures, I don't find that a particularly surprising conclusion. The next 
step would be for people to come up with system related measures that do catch 
what they are after. Some have tried that, many have not. The next link in the 
chain would be getting (paying) vendors to run the tests on product. As far as 
I can tell - that's not happening at all. ADEV had the same issues early on. 
Until it became a mandatory specification, not a lot of people paid much 
attention to it. 

Bob

On Nov 13, 2010, at 10:18 AM, jimlux wrote:

 Magnus Danielson wrote:
 Hi Bob,
 snip
 
 I think the system applications for short-term stability measurements was 
 quite clear, and was brought out specifically. 
 
 Basically, these are all systems where there is some storage or delay and 
 you are comparing a signal generated/recorded at some time t with that signal 
 at some time t+delta, where delta is in the seconds to minutes range.  (well, 
 milliseconds in the radar case)...
 
 (the really slow speed comm application is slightly different.. there, it's 
 more of a reciprocal mixing of close in noise and a frequency stability in 
 the hours/days sense issue.. although for one-way doppler measurements ADEV 
 is important)
 
 ADEV addresses the oscillator noise issues, but isn't particularly well 
 suited for the numerous of systematic effects that comes on top of the 
 oscillator noise in the system.
 
 yes. but some familiarity with how ADEV is measured/computed, and the fact 
 that there are test sets out there that make a plot of ADEV means that you 
 can look at a ADEV plot for the system, and if it deviates from that for the 
 underlying oscillators, you can make some educated guesses about the system 
 issues.  Not that it's best, by any means, but at least it exists.
 
 When buying or building a complex system, one is often faced with the problem 
 of how do we write a testable specification or requirement to show that the 
 completed widget works.  And, further, you generally don't want to spend more 
 developing the test than the thing you are buying. It does happen, 
 though..probably part of the game for developing at the ragged edge of 
 performance.  However, if you can sort of back your way into an analysis that 
 shows that a performance of X on test Y (no matter how unsuited 
 philosophicaly) means that you will get performance Z on important 
 requirement Q, then all is good.
 
 At work, we refer to the developing of a whole subproject to understand and 
 test how the primary object is working as doing a science project.. but 
 that's because I work in an engineering area as opposed to one of the 
 science areas, where science projects are their lives. By the time we get 
 it, we're on a schedule and budget that doesn't allow for much contemplation, 
 reflection, and thinking about how to best do things: planetary motion waits 
 for no man, and the launch period is a few weeks long, at best.
 
 
 
 
 ___
 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

[Magnus Danielson]

On 11/13/2010 04:01 PM, jimlux wrote:

Mike Feher wrote:

I sure do agree, that with very low data rate systems it is
significant. In
fact, when David Allan  Fred Walls came up with the proposal of using
this
measurement as an FOM for oscillators over 30 years ago, digital
communication rates were slow, and, the measurement was a good one.
Due to
the filtering process within ADEV by collecting and integrating a large
number of samples, has a filtering effect of its own. Therefore, it
can, and
will, miss the fact that there may be instantaneous phase transitions
that
could cause havoc with high data rates and higher order PSK modulation
schemes. So, again, I apologize, as I should have mentioned higher data
rates. However, you must admit that your application, while extremely
critical, is in the minority. I like to use the example of something like
DirecTV. Here, they use a down-converter that utilizes a free running
DRO,
that is ridiculously noisy, and, varies all over in frequency, especially
over the temperature ranges it subjected to. In spite of all of that, one
gets a perfect pictures. Regards - Mike




no apologies necessary.. After all, I spend a small, but significant,
amount of time explaining why we'd care about such things, since we are
in the distinct minority of the radio comm world (trying to write nice
comments on failed SBIR proposal evaluations to explain why they missed
the big picture)

And, on the one hand, it's frustrating being the orphan child of the RF
user community: you can't get off the shelf test equipment. On the other
hand, it's cool, because then you have to *build* your test equipment.


Hmm. Should do more of that.


To the Ku-band downconverters.. They're pretty crummy (but have a decent
SNR to work with).. however, I've seen that there are two kinds.. a
vanilla LNB and ones described as crystal locked... both are cheap
($20-30 for the former, maybe twice that for the latter)... what's the
difference? And, getting into time-nuts territory here, where's the
reference for the locked variety coming from? Up the coax? inside the
LNB? And, can it be retrofitted from a much quieter oscillator? I was
thinking that one could build a radio camera with a small array of
Ku-band dishes, if you could lock all the receivers together. They *are*
pretty low noise (20-30K)


The key seek-term to add is external reference and it seems that 10 
MHz sine seems to be the standard external reference frequency for LNBs 
with external reference. I know it will be a tricky frequency for you to 
score, but the things you do for science.


Best of luck.

Interesting approach.

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

[jimlux]

Magnus Danielson wrote:
 One of the big meetings on this topic was in the
NASA Goddard space center, and the result of that is found in the NASA 
Special Publication 80 (SP-80):

http://hdl.handle.net/2060/19660001092

Un the part 1 User's viewpoint and requirements
First article in there is Short-term stability for a doppler radar: 
Requirements, Measurements and Techniques by D.B. Leeson and G.F. 
Johnsson.
Fifth article is Satellite Range and Tracking Accuracy as a function of 
Oscillator STability by J.J. Caldwell Jr.
Sixth article is Short-term Stability Requirements for Deep Space 
Tracking and Communications systems by R. L. Sydnor.





Thanks for this reference.. I had seen some of the papers before, but 
this collects them all handy in one place.


The paper by Sydnor is quite handy, because it's basically the same way 
we do things still  (well, we don't punch the Doppler estimate on paper 
tape, we've moved a tiny bit forward. And, most, but not all, of our 
equipment is calibrated in Hz as opposed to cps)..




___
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

[jimlux]

Bob Camp wrote:

Hi

I don't see anybody arguing that systems work better when there's a
high ADEV than a low ADEV. Most of the papers are heading in the
direction of it doesn't catch all of the problems I worry about.
Based on what systems need and what ADEV measures, I don't find that
a particularly surprising conclusion. The next step would be for
people to come up with system related measures that do catch what
they are after. Some have tried that, many have not. The next link in
the chain would be getting (paying) vendors to run the tests on
product. As far as I can tell - that's not happening at all. ADEV had
the same issues early on. Until it became a mandatory specification,
not a lot of people paid much attention to it.

Bob



Yes.. and if you read the discussion following that first batch of 
papers in the report Magnus linked, you can see the same sort of thing.. 
everyone had some measure they had developed that was important to their 
particular system, but none of them were the same, or even directly 
interconvertible.


The problem faced by them (and us at JPL now)is that we're a very, very 
low volume customer (a few units every few years)..  We *do* actually 
pay people to make the measurements, but sometimes, I think the 
measurements we ask for aren't necessarily appropriate.  It's expensive 
and time consuming to do the analysis for a new measurement, and 
particularly to validate that it's actually measuring something useful 
and relevant, so there's a very strong tendency to do what we did before..


Sometimes the previous measurement used something that happened to 
depend on an artifact of the system design so that you could test 
something you can measure to represent something that's difficult to 
measure (e.g. IP3 vs P1dB relationships presume a certain shape to the 
nonlinearity).  But if you've changed the underlying design, that 
artifact may not exist.


This shows up a lot with test procedures/specifications for systems 
based on all analog designs that are adopted unchanged for systems with 
digital conversions.  (look at all the various ways to specify 
performance of high speed ADCs).  For example, in my world, a common 
specification is for performance at best lock frequency (BLF, that is, 
the frequency at which you can acquire a carrier with the lowest SNR). 
In an analog system, this is often where the input corresponds to the 
rest frequency of the VCO with everything sort of in the middle of the 
range.   But a lot of modern systems have no BLF... their performance is 
essentially flat over some band, and any small variations are not 
indicative of, e.g. minimum loop stress, etc.  The time spent to 
determine BLF, and any assumptions about performance aren't necessarily 
valid.


On the other hand, we don't necessarily engage in a science project 
for each project to determine performance requirements (and 
corresponding test methods) unique to the performance in that system. 
There is a need for more generic performance numbers that have 
moderately universal understanding.. If I tell you the P1dB for an 
amplifier, and I tell you that my signals are 10dB below that, then, in 
a short statement, I've actually told you a fair amount about how my 
design works and the range over which it's likely to keep working. 
That's because you and I have a common understanding of what a P1dB spec 
means...


Over the past decades, I think a similar understanding has arisen with 
phase noise specs and to a lesser extent Allan deviation. That is, given 
a phase noise plot, a skilled practitioner can tell whether it's good or 
bad in the context of a particular system.


___
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

[Magnus Danielson]

On 11/13/2010 04:53 PM, jimlux wrote:

Magnus Danielson wrote:
One of the big meetings on this topic was in the

NASA Goddard space center, and the result of that is found in the NASA
Special Publication 80 (SP-80):
http://hdl.handle.net/2060/19660001092

Un the part 1 User's viewpoint and requirements
First article in there is Short-term stability for a doppler radar:
Requirements, Measurements and Techniques by D.B. Leeson and G.F.
Johnsson.
Fifth article is Satellite Range and Tracking Accuracy as a function
of Oscillator STability by J.J. Caldwell Jr.
Sixth article is Short-term Stability Requirements for Deep Space
Tracking and Communications systems by R. L. Sydnor.




Thanks for this reference.. I had seen some of the papers before, but
this collects them all handy in one place.

The paper by Sydnor is quite handy, because it's basically the same way
we do things still (well, we don't punch the Doppler estimate on paper
tape, we've moved a tiny bit forward. And, most, but not all, of our
equipment is calibrated in Hz as opposed to cps)..


When researching my contributions to the Allan variance Wikipedia 
article I found that many of the articles referred back to papers from 
that conference, so I dug around a little and came up with that 
reference. It is online from NASA if you just care to use their 
web-pages a little.


http://en.wikipedia.org/wiki/Allan_variance

I took some pride of providing significant contributions to the field as 
referenced articles, and also as far as possible provide linkage to them 
in online form, if possible to get for free. This was indeed one of the 
references I was quite happy to find. I have not read all the 300 pages, 
but there is a lot of good material in there. For instance, the DMTD 
technique has a precursor in the cross-correlation technique being 
presented on page 111 by R. F. C. Vessot, L. F. Mueller and J. Varnier 
in A cross-correlation technique for mesuring the short-term properties 
of stable oscillators. They measure the beat frequencies of two 
H-masers 1,420 GHz as being mixed down to first 30 MHz and then 600 Hz.


Oh, and I still have a number of things to properly cover on the Allan 
variance article for sake of completeness. Progress have just been slow. 
Doing exercises like these is however very rewarding as one needs to 
learn the things on a deeper level.


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

[jimlux]

And, on the one hand, it's frustrating being the orphan child of the RF
user community: you can't get off the shelf test equipment. On the other
hand, it's cool, because then you have to *build* your test equipment.


Hmm. Should do more of that.


Well, one *does* have to convince someone to pay you to do it..




To the Ku-band downconverters.. They're pretty crummy (but have a decent
SNR to work with).. however, I've seen that there are two kinds.. a
vanilla LNB and ones described as crystal locked... both are cheap
($20-30 for the former, maybe twice that for the latter)... what's the
difference? And, getting into time-nuts territory here, where's the
reference for the locked variety coming from? Up the coax? inside the
LNB? And, can it be retrofitted from a much quieter oscillator? I was
thinking that one could build a radio camera with a small array of
Ku-band dishes, if you could lock all the receivers together. They *are*
pretty low noise (20-30K)


The key seek-term to add is external reference and it seems that 10 
MHz sine seems to be the standard external reference frequency for LNBs 
with external reference. I know it will be a tricky frequency for you to 
score, but the things you do for science.



Browsing the aisles of the local electronics mega-mart... I don't think 
I've ever seen external reference in the commodity units.  I figure 
that the crystal locked units have a crystal in the LNB (as opposed to 
just running the DRO open loop)..


But, presumably, one could modify the LNB to drive the reference with 
something external (and somehow, I doubt it will be 10 MHz.. but anyone 
able to modify LNBs will be able to make whatever is needed)


___
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

[Magnus Danielson]

On 11/13/2010 05:32 PM, jimlux wrote:




And, on the one hand, it's frustrating being the orphan child of the RF
user community: you can't get off the shelf test equipment. On the other
hand, it's cool, because then you have to *build* your test equipment.


Hmm. Should do more of that.


Well, one *does* have to convince someone to pay you to do it..


Once in a while, I end up being paid to do it. :)

But I do not play in Ku-band. Haven't had to... yet.


The key seek-term to add is external reference and it seems that 10
MHz sine seems to be the standard external reference frequency for
LNBs with external reference. I know it will be a tricky frequency for
you to score, but the things you do for science.



Browsing the aisles of the local electronics mega-mart... I don't think
I've ever seen external reference in the commodity units. I figure
that the crystal locked units have a crystal in the LNB (as opposed to
just running the DRO open loop)..

But, presumably, one could modify the LNB to drive the reference with
something external (and somehow, I doubt it will be 10 MHz.. but anyone
able to modify LNBs will be able to make whatever is needed)


There is really three types available from my quick search:

1) Open Loop L.O. LNBs

2) Crystal locked L.O. LNBs

3) External referenced locked L.O. LNBs

Searching the web using say Google should get you the part numbers you 
would need for your short-hand.


Crystal locked would require modification, but modifying them for a 10 
MHz reference would probably be a good choice.


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 MDEV

[Magnus Danielson]

Bob Camp wrote:

Hi

I believe the statement:

Both systems are equally limited by the reference oscillator  


was part of the same paragraph as the comment on 10811 short term stability.

Neither system, no matter how well set up will get below the stability of the 
reference oscillator.


For DMTD systems the transfer oscillator noise can be partially 
cancelled. You do have two inputs, but you then play three-cornered hat 
tricks. However, for a DMTD system to be able to cancel noise, good 
time-correlation between channels is needed to make the 
noise-integration time-periods of both channels to match up. The more 
they are apart, the bigger difference in noise it is between the 
channels and thus it will fail to cancel. Thus, phase-alignment prior to 
ZCDs could be a treatment. Using the audio channel approach avoids the 
issue as the full-wave signal is being used and time correlation between 
samples is high, an approach not available when DMTD was developed.


Cheers,
Magnus - while visiting fellow time-nut

___
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 MDEV - using sound card

[Magnus Danielson]

Bob Camp wrote:

Hi

My main concern with the low frequency pole in the sound card is the quality of the R/C 
used. You can certainly model what ever you have. If they used an aluminum electrolytic 
for the C it may not be the same next time you check it 


Do consider to bypass it. This is routinely done both by audio folks and 
various other. The cap is there to remove DC offsets which can be 
problematic in audio editing. I am quite sure you feel at home with the 
soldering iron to do that upgrade.


On a 10 Hz system, a 1 Hz pole is probably not an issue. It might get in the way with a 1 Hz beat note. 


Another thing I have only seen in passing: Sigma Delta's have poor low frequency 
noise characteristics. I haven't dug into it to see if that's really true or not. 
If you buy your own ADC's, you certainly would not be restricted to a Sigma Delta.


Strange, most Sigma Delta's I have seen would have the opposite said 
about them. It's the upper end that is problematic.


Even with a cheap pre-built FPGA board, you could look into higher sample rates than a conventional sound card. You would drop back to 16 bits, but it might be worth it. 


In fact, one of my FPGA demo-board does 3 MS at 14 bit. Crappy for 
audio, but maybe good enough for this application.


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 MDEV - using sound card

[Bruce Griffiths]

Magnus Danielson wrote:

Bob Camp wrote:

Hi

My main concern with the low frequency pole in the sound card is the 
quality of the R/C used. You can certainly model what ever you have. 
If they used an aluminum electrolytic for the C it may not be the 
same next time you check it 


Do consider to bypass it. This is routinely done both by audio folks 
and various other. The cap is there to remove DC offsets which can be 
problematic in audio editing. I am quite sure you feel at home with 
the soldering iron to do that upgrade.


On a 10 Hz system, a 1 Hz pole is probably not an issue. It might get 
in the way with a 1 Hz beat note.
Another thing I have only seen in passing: Sigma Delta's have poor 
low frequency noise characteristics. I haven't dug into it to see if 
that's really true or not. If you buy your own ADC's, you certainly 
would not be restricted to a Sigma Delta.


Strange, most Sigma Delta's I have seen would have the opposite said 
about them. It's the upper end that is problematic.


Even with a cheap pre-built FPGA board, you could look into higher 
sample rates than a conventional sound card. You would drop back to 
16 bits, but it might be worth it. 


In fact, one of my FPGA demo-board does 3 MS at 14 bit. Crappy for 
audio, but maybe good enough for this application.


Cheers,
Magnus

_
A pity that there is a relatively low bandwidth PGA used to drive the 
inputs of that dual channel simultaneous sampling ADC.


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 MDEV - DMTD sound card

[Bob Camp]

Hi

That was actually talking about a heterodyne system.

Indeed a good digitizer could be used with a DMTD. One thing I have not looked 
into is the DC accuracy required if you go that way. Some of these approaches 
have odd little gotcha's. By analogy with a heterodyne setup it might not. 
That's not always the best way to analyze things 

Bob

On Feb 7, 2010, at 3:50 AM, Magnus Danielson wrote:

 Bob Camp wrote:
 Hi
 I believe the statement:
 Both systems are equally limited by the reference oscillator  was part of 
 the same paragraph as the comment on 10811 short term stability.
 Neither system, no matter how well set up will get below the stability of 
 the reference oscillator.
 
 For DMTD systems the transfer oscillator noise can be partially cancelled. 
 You do have two inputs, but you then play three-cornered hat tricks. However, 
 for a DMTD system to be able to cancel noise, good time-correlation between 
 channels is needed to make the noise-integration time-periods of both 
 channels to match up. The more they are apart, the bigger difference in noise 
 it is between the channels and thus it will fail to cancel. Thus, 
 phase-alignment prior to ZCDs could be a treatment. Using the audio channel 
 approach avoids the issue as the full-wave signal is being used and time 
 correlation between samples is high, an approach not available when DMTD was 
 developed.
 
 Cheers,
 Magnus - while visiting fellow time-nut
 
 ___
 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 MDEV

[bg]

Hi Pete,

 typical for theHP5370A/B, the SR620 or the CNT81/91. I have data
 from my CNT81showing MDEV  1E-13 in 10s. and I believe the
 other counters behave similarly.

 Pete Rawson

I have a CNT81 and a TI GPIB-card, that are not yet close friends. Could
you tell me a bit about your measurement setup? (type of GPIB-card,
computer OS, GPIB-software, ...)

thanks,

Björn


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

[Bob Camp]

Hi

The counter is not the big issue in DMTD. We seem  The problems lies elsewhere. 
I think we've gone into that pretty deeply in various recent threads.

As a practical bench instrument, the Pendulums are a very good choice. That's 
independent of anything having to do with DMTD. 

Bob


On Feb 5, 2010, at 11:53 PM, Bruce Griffiths wrote:

 Read the data sheet and the various application notes/white papers on the 
 Pendulum site.
 The intrinsic resolution of the Pendulum counter (50ps) is slightly inferior 
 to that of the SR620 and HP5370A/B.
 What they do is statistically process the results of a series of measurements 
 of the input phase taken at short intervals.
 They actually fit a regression line to the resultant series of phase 
 measurements.
 This process inherently filters out some of the noise of the counter.
 If it were possible to do the same thing using an SR620 or HP5370 the noise 
 in the output resolution would be even lower.
 
 If one is building a conventional DMTD one doesn't actually need resolution 
 for the timestamping device/counter much better than 10ns or so to achieve a 
 resolution of around 1E-13/Tau with say a 100Hz beat frequency and 10MHz 
 inputs to the mixer/phase detector.
 
 Bruce
 
 Bob Camp wrote:
 Hi
 
 At least from what I've seen, the Pendulum's seem to work a bit better than 
 the other counters you mention. That may simply be a function of their being 
 designed much more recently.  It could also be the issue of comparing beat 
 up stuff on the bench to brand new stuff on the bench. The CNT-81 is rated 
 to have a much better single shot time resolution than the others.
 
 Yes I realize that in no way addresses the question you asked.
 
 MDEV and ADEV measure slightly different things. Depending on what you are 
 looking for MDEV may give you better insight.
 
 Bob
 
 
 On Feb 5, 2010, at 10:59 PM, Pete Rawson wrote:
 
   
 Efforts are underway to develop a low cost DMTD apparatus with
 demonstrated stability measurements of 1E-13 in 1s. It seems that
 existing TI counters can reach this goal in 10s. (using MDEV estimate
 or 100+s. using ADEV estimate). The question is; does the MDEV tool
 provide an appropriate measure of stability in this time range, or is
 the ADEV estimate a more correct answer?
 
 The TI performance I'm referring to is the 20-25 ps, single shot TI,
 typical for theHP5370A/B, the SR620 or the CNT81/91. I have data
 from my CNT81showing MDEV  1E-13 in 10s. and I believe the
 other counters behave similarly.
 
 I would appreciate any comments or observations on this topic.
 My motivation is to discover the simplest scheme for making
 stability measurements at this performance level; this is NOT
 even close to the state-of-the-art, but can still be useful.
 
 Pete Rawson
 
 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to 
 https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
 
 
 
 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
 
   
 
 
 
 ___
 time-nuts mailing list -- time-nuts@febo.com
 To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
 and follow the instructions there.
 


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

Re: [time-nuts] ADEV vs MDEV

[Magnus Danielson]

Bruce Griffiths wrote:

_Correction_

Oops, Its the CNT91 not the CNT81 that actually does the regression fit.

How did you achieve MDEV ~1E-13 @10s with a counter rated at 50ps single 
shot resolution?


I think the actual resolution and trigger jitter was combined to a 
single number. For some reason they do that. You need to look more into 
the details of the counters.


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 MDEV

[Magnus Danielson]

Pete Rawson wrote:

Efforts are underway to develop a low cost DMTD apparatus with
demonstrated stability measurements of 1E-13 in 1s. It seems that
existing TI counters can reach this goal in 10s. (using MDEV estimate
or 100+s. using ADEV estimate). The question is; does the MDEV tool
provide an appropriate measure of stability in this time range, or is
the ADEV estimate a more correct answer? 


Your question is incorrect. ADEV and MDEV is two different animals of 
measurements. They are kind of similar, but MDEV can distinguish f² and 
f³ from each other. The trivial non-overlapping ADEV estimator is not 
using the samples even nearly as efficient as MDEV, so you need to use 
the overlapping ADEV estimator to compare numbers, but you must look at 
the details of how they react to different noise-types to understand 
what happens. So which gives the more correct answer depends on which 
question you are asking.



The TI performance I'm referring to is the 20-25 ps, single shot TI,
typical for theHP5370A/B, the SR620 or the CNT81/91. I have data
from my CNT81showing MDEV  1E-13 in 10s. and I believe the
other counters behave similarly.


Care should be taken when comparing numbers, in fact those single-number 
values can be confusing as they combined a systematic error with that of 
a noise which depends among other things on the slew-rate of the input 
signal.


The CNT90/91 have different modes of measurements, and the predictor 
data is only relevant when the frequency/period measures is taken, not 
when the time-stamp data-record is being used. The HP53131/53132 has 
similar issues, but again type of data-record used is important to recall.



I would appreciate any comments or observations on this topic.
My motivation is to discover the simplest scheme for making 
stability measurements at this performance level; this is NOT

even close to the state-of-the-art, but can still be useful.


The post-processing can use various variants of estimators, which is 
relative cheap form of upgrade. The total variance and Theo variance 
will provide you very good measures for the same sequence of data. The 
filter approach provides another interesting approach. I have not 
implemented the filter-approach variants just yet, but intend to do so.


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.