An advanced question - sampling an oscillator's signal for analysis

[dnessett]

Let's use a concrete example. The FEI FE-5650 spec gives an Allan Variance of 1.4*10^-11/sqrt(t) when the unit is new. Using that number (if you need other information, the URL to the spec is in my post to KE5FX), tell me how to determine that the frequency of the unit will not vary by more than x% (you choose x) over a two hour period with a probability of p (you choose p).

It can't be determined from their specifications, because they do not state the range over which 1.4*10^-11/sqrt(t) is valid.

Make an assumption and specify how to do the computation. Right now the process is more important than the answer.

[dnessett]

Those are very broad statements, especially when the time frame can be from ms to years. Also, there are some assumptions that might be irrelevant, or simply wrong, depending on the situation.

You mentioned surplus oscillators, synchronize multiple instruments, square to sin conversion of 10 MHz, rubidium clock, and so on.

What are you after? What exactly are you trying to do, or to achieve?

There are several messages in this thread that specify what I am trying to achieve. In summary I am trying to characterize the stability of several hobbyist oscillators in a way that is useful to an amateur.

What is your measuring setup? What exactly do you plan to measure with the given setup?

I am in the process of building the measuring setup at the moment. Right now I am waiting on some parts to arrive. I have a GPS disciplined 10 MHz oscillator that will serve as the reference clock coming to me from China, which will probably arrive at the end of the month or perhaps the beginning of next month.

Added Later: I plan to start with a zero crossing detector feeding one of the analog pins of an Arduino development board. The Arduino will be used for interrupt processing and data accumulation. It will be controlled by a Raspberry PI that will act as the archiving system. I plan to use Octave (an open source MatLab clone) as the analysis engine. I have the Arduino (actually a Vellman VMA100 clone), the Raspberry Pi and the USB cables to connect them, but haven't integrated them together yet (I got the Vellman yesterday). I will communicate with the Raspberry Pi over ethernet to access the archived data for analysis.

[tomato]

Let's use a concrete example. The FEI FE-5650 spec gives an Allan Variance of 1.4*10^-11/sqrt(t) when the unit is new. Using that number (if you need other information, the URL to the spec is in my post to KE5FX), tell me how to determine that the frequency of the unit will not vary by more than x% (you choose x) over a two hour period with a probability of p (you choose p).

It can't be determined from their specifications, because they do not state the range over which 1.4*10^-11/sqrt(t) is valid.

Make an assumption and specify how to do the computation. Right now the process is more important than the answer.

It's probably safe to assume that the Allan Variance is no worse than 1*10^-11 at 2 hours.

[KE5FX]

When you see a sqrt(tau) expression in a specification for a long-term reference like an Rb or Cs standard, you can usually assume that it's valid between t=1s and the flicker floor.  Essentially, they are giving you a limit mask in the form of a diagonal line with slope -0.5 on a log-log plot, suggesting that they expect the instability to be dominated by white-noise frequency variations. 

In that regard, the FE-56x0 models will resemble most other small telecom-grade rubidium standards:



That sort of spec leaves out a few details -- for one thing, where is the flicker floor?  In the blue trace above, the line bottoms out at what might be the flicker floor, but could also simply represent the onset of drift due to insufficient warmup time.  However, the rudimentary ADEV spec would have met customer requirements at the time, and it may also reflect the limitations of the measurement setup the manufacturer had available. 

The plot above actually came from an eBay'ed FE-5680 with a ton of hours on it, so you can probably expect yours to perform about the same.  As far as the error bars on "probably," that would be left as an exercise for the reader.

Edit: FEI's brochure is actually pretty informative, check it out if you haven't already.

[dnessett]

The plot above actually came from an eBay'ed FE-5680 with a ton of hours on it, so you can probably expect yours to perform about the same.  As far as the error bars on "probably," that would be left as an exercise for the reader.

Very informative post, but I am still trying to figure out how to go from ADEV to something practical; specifically how much the frequency will vary over a specified time period according to some statement of probability. "Exercise left for the reader" presumes the reader knows how to execute the exercise. So far, no one has provided an algorithm (or process, if "algorithm" is too restrictive) to convert ADEV to such a quantity.

[JohnnyMalaria]

My understanding re. ADEV is that it calculates the standard deviation of the oscillator's signal over different time intervals and plots those deviations as a function of the time interval. Why not just digitize the signal in the time domain and calculate the standard deviation over different time intervals, of, say, the interval between cross-over points? It's a trivial exercise to do that. Then generate the log-log plot from which you can fit straight lines to the pertinent parts of the plot and find the break points, too. There's a very powerful statistical method for the latter - CUSUM.


Another option is cross-correlation, particularly multidecade. It basically achieves the same end result.

[tomato]

My understanding re. ADEV is that it calculates the standard deviation of the oscillator's signal over different time intervals and plots those deviations as a function of the time interval.

No, it's not calculating standard deviations.

[JohnnyMalaria]

My understanding re. ADEV is that it calculates the standard deviation of the oscillator's signal over different time intervals and plots those deviations as a function of the time interval.

No, it's not calculating standard deviations.

variance = standard deviation squared


Allan -> measuring it as a function of time intervals. This is also how correlation functions are constructed except instead of calculating the expectation value of the square difference, correlation calculates the expectation value of the product C(tau) = <y(t).y(t+tau)> (auto- or cross-correlation).

Even the man himself says it:

Brief Explanation

Allan variance equation:



where the variance is taken on the variable y. Each value of y in a set has been averaged over an interval J and the ys are taken in an adjacent series, i.e. no delay between the measurements of each. The brackets <> denote the expectation value. For a finite data set, it is taken as the average value of the quantity enclosed in the brackets. The )y denotes the first finite difference of the measures of y; i.e. if i denotes the ith measurement of y, then )y = yi+1 - yi. In total, each adjacent finite difference of y is squared and these then are averaged over the data set and divided by 2. The divide by two causes this variance to be equal to the classical variance if the ys are taken from a random and uncorrelated set; i.e. white noise.

[tomato]

Even the man himself says it:

Brief Explanation

Allan variance equation:



where the variance is taken on the variable y. Each value of y in a set has been averaged over an interval J and the ys are taken in an adjacent series, i.e. no delay between the measurements of each. The brackets <> denote the expectation value. For a finite data set, it is taken as the average value of the quantity enclosed in the brackets. The )y denotes the first finite difference of the measures of y; i.e. if i denotes the ith measurement of y, then )y = yi+1 - yi. In total, each adjacent finite difference of y is squared and these then are averaged over the data set and divided by 2. The divide by two causes this variance to be equal to the classical variance if the ys are taken from a random and uncorrelated set; i.e. white noise.

Read the sentence in bold.  The Allan Variance is not calculating standard deviations. 

[JohnnyMalaria]

Look at the equation. LHS is sigma squared.

The angle brackets are all important. You can't just do the 2-point difference once. It has to be done many times (hundreds or more) to reach the expectation value that Allan says. If you perform the calculation enough times then you'll get sigma² or sigma (which he calls the deviation). i.e., you are calculating variance/standard deviation. The only difference between the two is that there'll be a factor 2 difference in the gradient on the log-log plot.

The reason you have to perform the calculation over many t (i.e., (y(t+tau)-y(t))² is because of the pseudo cyclostochastic nature of the signal (noise).

It terms of practical calculation, it is so simple especially with a matrix-based language like Matlab or Python with Numpy. I perform autocorrelation of pseudo cyclostochastic photodetector signals. The only difference is calculating the product y(t+tau).y(t) instead of the square of the difference. In Python/Numpy, it takes just 8 lines of code.

[dnessett]

My understanding re. ADEV is that it calculates the standard deviation of the oscillator's signal over different time intervals and plots those deviations as a function of the time interval.

No, it's not calculating standard deviations.

One reason Allan came up with the Allan Variation is the traditional standard deviation of real oscillators diverges as the sample size increases.

I began thinking about how to convert an Allan Variance/Deviation into a probabilistic bounds on frequency during a particular interval. However, it quickly became apparent that this is not a simple problem.

The Allan Variance uses the average frequency, f_i (measured in radians/sec), over an averaging interval tau. These are normalized by the nominal frequency to ensure the Allan Variances of oscillators with different frequencies, w₀, are comparable. This normalization produces what is called fractional frequency data ff_i = f_i/w₀. Suppose these samples are generated by a stationary process. Then the standard variance is simple to compute.

However, the Allan Variance is a function of the differenced fractional frequency data: a_i = ff_i+1-ff_i. It sums the square of these values and averages the sum (dividing by 2). The time series a_i is autocorrelated. Now, it is possible for a stationary process to produce an autocorrelated series, but this is generally not the case. So, it is possible (likely) that a_i represents samples from a non-stationary process. (Someone who is more knowledgable than I can correct me on this.) If so, the Allan Variance will not have the same properties as a standard variance. In particular, you can't use the Allan Deviation as you would a standard deviation from some pdf, defining probabilistic bounds based on it.

However, I am not an expert on Allan Variance/Deviation, so maybe there is some way to use it to compute the desired bounds. This is what I have been asking for someone to explain in recent posts.

[tomato]

Look at the equation. LHS is sigma squared.

The angle brackets are all important. You can't just do the 2-point difference once. It has to be done many times (hundreds or more) to reach the expectation value that Allan says. If you perform the calculation enough times then you'll get sigma² or sigma (which he calls the deviation). i.e., you are calculating variance/standard deviation. The only difference between the two is that there'll be a factor 2 difference in the gradient on the log-log plot.

The reason you have to perform the calculation over many t (i.e., (y(t+tau)-y(t))² is because of the pseudo cyclostochastic nature of the signal (noise).

There is no other way to say this -- you are wrong.  The Allan Variance is not standard deviations calculated at different times. In simple terms, the standard deviation is calculated from the differences between data points and the mean of the data, whereas the Allan Variance is calculated from differences between data points separated in time. Those calculations are very different.  Read one of the cited papers.

[tomato]

My understanding re. ADEV is that it calculates the standard deviation of the oscillator's signal over different time intervals and plots those deviations as a function of the time interval.

No, it's not calculating standard deviations.

One reason Allan came up with the Allan Variation is the traditional standard deviation of real oscillators diverges as the sample size increases.

I began thinking about how to convert an Allan Variance/Deviation into a probabilistic bounds on frequency during a particular interval. However, it quickly became apparent that this is not a simple problem.

The Allan Variance uses the average frequency, f_i (measured in radians/sec), over an averaging interval tau. These are normalized by the nominal frequency to ensure the Allan Variances of oscillators with different frequencies, w₀, are comparable. This normalization produces what is called fractional frequency data ff_i = f_i/w₀. Suppose these samples are generated by a stationary process. Then the standard variance is simple to compute.

However, the Allan Variance is a function of the differenced fractional frequency data: a_i = ff_i+1-ff_i. It sums the square of these values and averages the sum (dividing by 2). The time series a_i is autocorrelated. Now, it is possible for a stationary process to produce an autocorrelated series, but this is generally not the case. So, it is possible (likely) that a_i represents samples from a non-stationary process. (Someone who is more knowledgable than I can correct me on this.) If so, the Allan Variance will not have the same properties as a standard variance. In particular, you can't use the Allan Deviation as you would a standard deviation from some pdf, defining probabilistic bounds based on it.

However, I am not an expert on Allan Variance/Deviation, so maybe there is some way to use it to compute the desired bounds. This is what I have been asking for someone to explain in recent posts.

You're starting to get it.  You just need to abandon the idea of computing probabilistic bounds ...

[JohnnyMalaria]

Oddly enough, I was just thinking about autocorrelation in the context of Allan variance. I was going to suggest that measuring the variance function and the correlation function could be very useful especially given the trivial algorithm required (also another driver for Allan since computing power wasn't powerful enough for anything more complicated).


Specifically, the cyclic part of the process could be estimated by autocorrelation readily in the absence of noise but in the presence of noise it depends on the physical basis for the noise. If the noise is truly random (e.g., shot noise) then the calculated autocorrelation function will decay to zero within the first tau interval since there can be no temporal correlation for a truly random process. However, if the noise is due to a process akin to a random walk (e.g., Brownian motion) then useful information can be obtained by autocorrelation. The autocorrelation function will oscillate due to the periodic process and decay with a time constant related to the characteristic correlation time of the random process. e.g., large particles diffuse more slowly than for smaller ones and, hence, the characteristic correlation time (the decay constant) is longer for large particles. Indeed, autocorrelation is used extensively in light scattering techniques to measure the size of nanoparticles diffusing in liquids. Unlike the autocorrelation method, the Allan variance (or standard deviation) approach is appropriate for a truly random process.

[dnessett]

You're starting to get it.  You just need to abandon the idea of computing probabilistic bounds ...

So far all I get is that the Allan Variance/Deviation is for oscillator designers not oscillator users.

[JohnnyMalaria]

Look at the equation. LHS is sigma squared.

The angle brackets are all important. You can't just do the 2-point difference once. It has to be done many times (hundreds or more) to reach the expectation value that Allan says. If you perform the calculation enough times then you'll get sigma² or sigma (which he calls the deviation). i.e., you are calculating variance/standard deviation. The only difference between the two is that there'll be a factor 2 difference in the gradient on the log-log plot.

The reason you have to perform the calculation over many t (i.e., (y(t+tau)-y(t))² is because of the pseudo cyclostochastic nature of the signal (noise).

There is no other way to say this -- you are wrong.  The Allan Variance is not standard deviations calculated at different times. In simple terms, the standard deviation is calculated from the differences between data points and the mean of the data, whereas the Allan Variance is calculated from differences between data points separated in time. Those calculations are very different.  Read one of the cited papers.

That's EXACTLY the point I'm making and is born out in the equations I included and my emphasis about expectation values. I CLEARLY state that you calculate the difference between two points in time  (y(t+tau)-y(t))². Certainly not the standard deviation of the all the data points between t and t+tau. I also state that you have to do this many times. That's what the < > expressly mean.

The algorithm to achieve this is trivial and actually faster than having to calculate standard deviations across many data points. It's identical to autocorrelation except that the latter uses the product of two points instead of the difference.

What I am really struggling with is the OP says (I think - it's not clear) that they want to use whatever the standard way is to compare  the stability of two oscillators and understand why they are different. Allan variance is that way, isn't it? Well, I know how to construct the Allan variance function from raw data in an extremely efficient way (I've been doing it for a long time for autocorrelation which uses the same basic algorithm).

[tomato]

You're starting to get it.  You just need to abandon the idea of computing probabilistic bounds ...

So far all I get is that the Allan Variance/Deviation is for oscillator designers not oscillator users.

It's a general tool for characterizing oscillators. It's every bit as useful to users as it is to designers.

[tomato]

There is no other way to say this -- you are wrong.  The Allan Variance is not standard deviations calculated at different times. In simple terms, the standard deviation is calculated from the differences between data points and the mean of the data, whereas the Allan Variance is calculated from differences between data points separated in time. Those calculations are very different.  Read one of the cited papers.

That's EXACTLY the point I'm making and is born out in the equations I included and my emphasis about expectation values. I CLEARLY state that you calculate the difference between two points in time  (y(t+tau)-y(t))². Certainly not the standard deviation of the all the data points between t and t+tau. I also state that you have to do this many times. That's what the < > expressly mean.

You really need to read the cited papers. In particular, read section VI part D of the Rutman and Walls paper, and embrace Equation 10.

The algorithm to achieve this is trivial and actually faster than having to calculate standard deviations across many data points. It's identical to autocorrelation except that the latter uses the product of two points instead of the difference.

What I am really struggling with is the OP says (I think - it's not clear) that they want to use whatever the standard way is to compare  the stability of two oscillators and understand why they are different. Allan variance is that way, isn't it? Well, I know how to construct the Allan variance function from raw data in an extremely efficient way (I've been doing it for a long time for autocorrelation which uses the same basic algorithm).

The standard algorithm for computing Allan Variances is actually very efficient.

[JohnnyMalaria]

I fail to see how my description is inconsistent with the equation Allan presents:



How are these statements inconsistent with the equation?

I CLEARLY state that you calculate the difference between two points in time  (y(t+tau)-y(t))2. Certainly not the standard deviation of the all the data points between t and t+tau. I also state that you have to do this many times. That's what the < > expressly mean.

The angle brackets are all important. You can't just do the 2-point difference once. It has to be done many times (hundreds or more) to reach the expectation value that Allan says. If you perform the calculation enough times then you'll get sigma2 or sigma (which he calls the deviation). i.e., you are calculating variance/standard deviation. The only difference between the two is that there'll be a factor 2 difference in the gradient on the log-log plot.

The reason you have to perform the calculation over many t (i.e., (y(t+tau)-y(t))2 is because of the pseudo cyclostochastic nature of the signal (noise).

Either the equation he put in his own article is wrong or we are talking about two different things.

[rhb]

I'd like to suggest a data acquisition arrangement amenable to simple equipment.

On the 4 oscillators to be compared, attach 10 fast comparators (e.g ADCMP581),  four to the zero reference and 6 pair wise among all the pairings.  Multiply the GPSDO 10 MHz output to clock a fast ARM processor.  The pair wise comparators will need to have the gain adjusted so that the amplitudes are as closely matched as possible.  If matching  proves problematic use two comparators per pair referencing the average of the two signals.

At each sampling clock tick read the comparators and use those as the address of a counter in memory and increment that counter.  At the i PPS tick  increment the base address of the array of 64 counters.

A potentially useful embellishment would be to add a comparator tracking a noise source and collect a second set of counts when the sample clock tick value of the noise source comparator is positive.  That has the virtue that the random sampling precludes aliasing of harmonics produced by the oscillators but without requiring an antialias filter.

Bendat & Piersol and Octave will take care of things from there with ease.

After looking at the papers on cyclostationarity, I got the impression that's more a model for synthesizing noise in Spice than a model for analyzing clock data.

[dnessett]

I'd like to suggest a data acquisition arrangement amenable to simple equipment.

On the 4 oscillators to be compared, attach 10 fast comparators (e.g ADCMP581),  four to the zero reference and 6 pair wise among all the pairings.  Multiply the GPSDO 10 MHz output to clock a fast ARM processor.  The pair wise comparators will need to have the gain adjusted so that the amplitudes are as closely matched as possible.  If matching  proves problematic use two comparators per pair referencing the average of the two signals.

At each sampling clock tick read the comparators and use those as the address of a counter in memory and increment that counter.  At the i PPS tick  increment the base address of the array of 64 counters.

A potentially useful embellishment would be to add a comparator tracking a noise source and collect a second set of counts when the sample clock tick value of the noise source comparator is positive.  That has the virtue that the random sampling precludes aliasing of harmonics produced by the oscillators but without requiring an antialias filter.

Bendat & Piersol and Octave will take care of things from there with ease.

After looking at the papers on cyclostationarity, I got the impression that's more a model for synthesizing noise in Spice than a model for analyzing clock data.

I plan to do something simpler that what you propose. Use a zero-crossing detector on the oscillator output. Differentiate the zero-crossing detector output and clip the negative going pulse. That will give a pulse each time the oscillator has a positive going zero-crossing. Feed the output of the clipped differentiator into an analog port on the Arduino clone. Use code in the Arduino to count the positive zero-crossings. Set up that code to send the count to a Raspberry Pi when the averaging interval expires. Use the Raspberry Pi to store the data on flash memory. After the experiment is over, download the file of sample data to an analysis computer and process it using Octave (I could do the analysis on the Raspberry Pi, but using my main desktop machine is more convenient).

[In Vacuo Veritas]

This hypothetical hobbyist would have more stringent demands than the folks at CERN or ITER...

[dnessett]

It's a general tool for characterizing oscillators. It's every bit as useful to users as it is to designers.

You keep making generalized statements without any supporting evidence.

Here is a concrete example of oscillator use that illustrates why Allan Variance is probably not very interesting to, at least some, oscillator users. This example focuses on doppler radar.

An amateur use of dopplar radar might be to track model drones in a drone air race. Doppler radar sends out signals at a specific frequency and receives reflected signals in which that frequency is shifted. The frequency shifts are processed and turned into estimates of the drones' velocity. It is important that the frequency source is stable, otherwise the velocity estimates will be erroneous. More to the point, the designer of the dopplar radar system wants to know the bounds on the frequency jitter of the source oscillator. From those bounds (which are probabilistic in nature, e.g., 99.7% of the oscillator frequency variation is between w₀-b₀ and w₀+b₁), he can produce error bounds on the computed velocities.

The designer couldn't care less what is the Allan Varience of the oscillator or the power law exponents of the component noise sources. He wants to know the jitter bounds. If you can't get the jitter bounds from the Allan Variance, then it has no value in this particular application.

Some may criticize this example, pointing out that I know very little about doppler radar. That is absolutely correct. So, if there are any out there reading this thread who have experience in either professional or amateur doppler radar, I welcome their comments.

[tomato]

It's a general tool for characterizing oscillators. It's every bit as useful to users as it is to designers.

You keep making generalized statements without any supporting evidence.

What would you consider supporting evidence?  The fact that Allan Variance is used by every national standards lab in the world?

Here is a concrete example of oscillator use that illustrates why Allan Variance is probably not very interesting to, at least some, oscillator users. This example focuses on doppler radar.

An amateur use of dopplar radar might be to track model drones in a drone air race. Doppler radar sends out signals at a specific frequency and receives reflected signals in which that frequency is shifted. The frequency shifts are processed and turned into estimates of the drones' velocity. It is important that the frequency source is stable, otherwise the velocity estimates will be erroneous. More to the point, the designer of the dopplar radar system wants to know the bounds on the frequency jitter of the source oscillator. From those bounds (which are probabilistic in nature, e.g., 99.7% of the oscillator frequency variation is between w₀-b₀ and w₀+b₁), he can produce error bounds on the computed velocities.

The designer couldn't care less what is the Allan Varience of the oscillator or the power law exponents of the component noise sources. He wants to know the jitter bounds. If you can't get the jitter bounds from the Allan Variance, then it has no value in this particular application.

You can derive "jitter bounds" from the Allan Variance. As per your previous post:

I began thinking about how to convert an Allan Variance/Deviation into a probabilistic bounds on frequency during a particular interval. However, it quickly became apparent that this is not a simple problem.

The reason it is not a simple problem is because the behavior of an oscillator is (in general) not simple.  The non-simple behavior of oscillators is why the Allan Variance was developed.  Stating that Allan Variance has no value in the above application is ludicrous -- abandoning it will not simplify the behavior of the oscillator. You can use a different analysis technique that more easily produces "jitter bounds", but those jitter bounds will be of limited usefulness.  If you want meaningful results, you have to use the correct tools.

[tomato]

I fail to see how my description is inconsistent with the equation Allan presents:



How are these statements inconsistent with the equation?

I CLEARLY state that you calculate the difference between two points in time  (y(t+tau)-y(t))2. Certainly not the standard deviation of the all the data points between t and t+tau. I also state that you have to do this many times. That's what the < > expressly mean.

The angle brackets are all important. You can't just do the 2-point difference once. It has to be done many times (hundreds or more) to reach the expectation value that Allan says. If you perform the calculation enough times then you'll get sigma2 or sigma (which he calls the deviation). i.e., you are calculating variance/standard deviation. The only difference between the two is that there'll be a factor 2 difference in the gradient on the log-log plot.

The reason you have to perform the calculation over many t (i.e., (y(t+tau)-y(t))2 is because of the pseudo cyclostochastic nature of the signal (noise).

Either the equation he put in his own article is wrong or we are talking about two different things.

You haven't read section VI, part D of the and Rutman and Walls paper, have you?

I'm also guessing you have never worked with Allan Variances before?