Thanks! I think it will require more than one reading.. :)
Ole On Thu, Apr 19, 2018 at 12:08 AM, Magnus Danielson < [email protected]> 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 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 reading the HP5372A programmers manual. It actually shows how to > use the raw data digital format and do all the calculations yourself. > > A more gentle approach can be had by reading the HP Application Note 200 > series. > > > Thinking about where the quantization noise/trigger noise/whatever is > added > > to the measurements, my initial reasoning was as follows: > > * When measuring frequency, the quantization noise is added to the > > frequency estimate. This, when converted to phase in the adev > calculations, > > will result in random walk in the phase plot - and hence a slope of -0.5. > > "Two over, one down". > > * When measuring the phase directly in a time interval measurement, the > > noise is added to the phase record, and will not result in random walk in > > phase - and hence a slope of -1. "One over, one down" > > The way that classical counters do their business, and here I mean any > counters doing Pi-counters, for many purposes the time and frequency > measurements is essentially the same things. The only real difference is > if you time-stamp phase as a you do in a frequency measurement, and thus > compare the reference clock and the measurement channel, or if you > measure the time-difference between two channels using the reference > channel as a "transfer-clock". > > > This is in fact not what happens - or kinda, it depends, see below. As > > someone on the list helpfully pointed out; as the gate time of your > > frequency measurements increase, the noise stays the same. So the slope > is > > -1. This makes perfect sense when measuring phase, and is consistent with > > my reasoning above - the way to "average" a phase record is simply to > drop > > the intermediate datapoints. > > > > My confusion concerns measuring frequency. I can not see why the slope is > > -1, and I am confused for two reasons: > > > > 1. The gate time as such is not increasing - we are averaging multiple > > frequency readings, all of them has noise in them which, in my mind, when > > converted into phase should result in random walk in phase and follow the > > -.5 slope.[1] > > See my explanation above. The averaging you do fools you to believe you > got more data in then you did. > > phase[3] - phase[2] + phase[2] - phase[1] + phase[1] - phase[0] > = phase[3] - phase[0]. > > That's all there is to it. What you gain by the longer measurement is > that you get a longer time for the single-shot resolution of phase[3] > and phase[0] to affect the precision, this is a systematic effect which > is trivial to understand. We also get in the more subtle point of > stability slope and we get a reading from where there is less effective > noise because the length of the reading got longer. It can get so long > that we start to loose again. > > ADEV and friends is greatly misunderstood, it's a way to get stability > measures for the type of readout you do with your counters. This was at > the time when for this span there was no other useful method than > counters. Much of the ADEV limits and motivation comes from the limited > instruments of the times. Once the tool was there and the strength of > various noises could be determined, it became handy tool. > > > 2. Trying to get to grips with this, I also did a quick experiment - > which > > only increased my confusion: > > > > I set up my 53230a to measure a BVA-8600 against my AHM, in three modes, > > tau 1 second, each measurement lasting one hour: > > 1. Blue trace: Time interval mode, the slope on the left falls with a > slope > > of -1, as expected. > > 2. Pink trace: Frequency mode, "gap free"; the slope on the left also > falls > > with a slope of -1, somewhat confusing given my reasoning about random > walk > > in phase, but could maybe make sense somehow. > > Notice how these two have the same shape up to about 200 s, at which > time they start to deviate somewhat from each other. What you should > know that the confidence interval for the ADEV starts to open up really > much at 200 s, and as you sit down and see TimeLab collect the data in > real time, you can see that the upper end flaps around up and down, just > illustrating that the noise process is yanking it around and you don't > know where it will end up. Do the same measurement again and they could > look differently, that's the meaning of confidence interval, it just > gives you a rough indication that the noise process makes the true value > to be with a certain certainty within those limits, but not where. As it > opens up, the true value can be in an increasingly wide range. This is > due to lack of degrees of freedom, and was DF increases, the confidence > interval becomes tighter. ADEV is thus following a chi-square statistics. > > There is a small offset between the blue and pink trace. It would be > interesting to find out where that offset comes from, but they should > trace the same until confidence inverval blows up. > > > 3. Green trace: Frequency mode, "RECiprocal" - *not* gap free. The slope > on > > the left falls with a slope of -0.5. Very confusing, given the result in > > step 2. Random walk is evident in the phase plot. > > Hmm, strange. > > > Since the 53230A has some "peculiarities", I am not ruling out the > counter > > as the source of the difference in slopes for gap free vs not gap free > > frequency measurement - although I can see how gaps in frequency leads to > > random walk in the phase record and a slope of -0.5 - I just cant see > how a > > gap free frequency record (where every frequency estimate contains an > > error) does *not* result in RW in phase.. :) > > Yeah. It should not do that. > > > So my questions are: > > 1. Does gaps in the frequency record always lead to random walk in phase > > and a slope of -0.5, is this a "known truth" that I missed? Or is this > > likely another artifact of the 53230A? > > Gaps would give a bias, and that bias function is known. > Check if that could be what you seek for. > > > 2. Is my understanding of how the slopes arise, they show how the noise > > types "behave under averaging", correct? > > No, not really. > > > 3. Depending on the answer to 1; What am I missing in my understanding of > > white PM vs white FM - why does gap free frequency measurement not lead > to > > a slope of -0.5? > > Because the underlying power distribution slopes does not inverse > fourier convert to time like that. However, other mecanisms of gapped > data interacts. I would recommend a careful reading of David Allan's > paper from Feb 1966. It takes a few readings to figure out what's going on. > > > Thanks for any and all insight! > > Ole > > I hope I have contributed some to the understanding. > > > --------- > > [1] Thinking about how frequency measurements are made, it kinda maybe > > makes sense that the slope is -1; the zerocrossings actually *counted* by > > the frequency counter is not subject to noise, it is a nice integer. It > is > > only the start and stop interpolated cycles that are subject to > > quantization noise, and as more and more frequency estimates are > averaged, > > the "portion" of the frequency estimate that is subject to the noise > > decreases linearly. I suppose. > > Well, turns out that the 1/tau slope is not well researched at all. I > have however done research on it, and well, the way that noise and > quantization interacts is... uhm... interesting. :) > The non-linearity it represents does interesting things. I have promised > to expand that article to a more readable one. > > You can however understand how the time quantization part of it works, > and the single-shot resolution of the start and stop methods is really > the key there. > > Now, I did talk about Pi-counters. A Pi-counter is a counter which > provides equal weighing to frequency over the measurement period, that > which is about tau long. The shape of the weighing function looks like a > greek Pi-sign. As you integrate this, you take the phase at stop minus > the phase of start, that just how the math works and is fully > equivalent, and very practical as the frequency is not directly > observable but the relative phase is, so we work with that. > > Now, what J.J.Snyder presented in a paper 1980 and then 1981 was an > improved measurement method used in laser technology that improved the > precision. It does this by averaging over the observation interval. This > then inspired the modified Allan deviation MDEV which solved the problem > of separating white and flicker phase noise. For white noise, the slope > now becomes tau^-1.5 rather than tau^-1. This thus pushes the noise down > and reveals the other noises more quickly, which is an improved > frequency measure. The separation of noise-types is helpful for > analysis. This was also used in the HP53131/132A counters, but also K+K > counters etc. and has been know as Delta-counters, because of the shape > of the frequency weighing looks like the greek Delta-sign. Frequency > measures done with such a counter will have a deviation of the MDEV and > not the ADEV. As you measure with such a frequency estimator, you need > to treat the data correct to extend it properly to ADEV or MDEV. Also, > many counters output measurements that is interleaved, and if you do not > treat it as interleaved you get the hockey-puck response at low tau, > which wears of at higher taus at which time you have the ADEV as if you > used raw time-samples and all you got was a bit of useless data at the > low-tau end. > > Some counters, including the Philips Industrier/Fluke/Pendulum > PM-6681/CNT-81 and PM-6690/CNT-90 uses a linear regression type of > processing to get even better data. This was presented in papers and > app-notes by Staffan Johnsson of Philips/Fluke/Pendulum. He also showed > that you could do ADEV using that. Now, Enrico Rubiola got curious about > that, and looked into it and realized that the linear regression would > form a parabolic weighing of the frequency samples, and that the > deviation measure of such pre-filtering to ADEV would not become ADEV > but a parabolic deviation PDEV. The trouble with the linear regression > scheme is that compared to the others, you cannot decimate data, where > as for the others you can. This meant that for proper PDEV calculations > you could not use the output of a Omega-counter, again to reflect the > shape of the weighing of frequency, but you needed to access the data > directly. However, I later showed that the equivalent least-square > problem could be decimated in efficient form and do multi-tau processing > memory and CPU efficient in arbitrary hierarchial form. > > The filtering mechanisms of Pi, Delta and Omega shapes is really > filtering mechanisms that surpresses noise, which makes frequency > measures more precise as you follow the development chain, and their > deviations is the ADEV, MDEV and PDEV respectively. As you then want to > estimate the underlying noise-powers of the various 1/f^n power > distributions, you need to use the right form to correctly judge it. If > you intend to present it as ADEV, you can use MDEV/ADEV or PDEV/ADEV > biases functions to correct the data to understand it in ADEV equivalent > plots, but that would not be valid of the Delta or Omega prediciton of > frequency. > > Similarly can phase be estimated, but again the weighing of frequency, > or for that matter phase, over the observation time will render > different precision values. The time deviation TDEV is based on a > rescaled MDEV, so that is valid only for measures using a Delta-shaped > frequency weighing. The lack of time deviation of Pi and Omega shapes > remains an annoying detail, but TDEV was not meant for that purpose. > > OK, so this is the first lesson of "ADEV greatly missunderstood". :) > > Most people that say they understand ADEV and friends actually don't > understand it. > > Cheers, > Magnus > _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/ > mailman/listinfo/time-nuts > and follow the instructions there. > _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.
