Hi More or less:
ADEV takes the *difference* between phase samples and then does a standard deviation on them. RMS of the phase samples makes a lot of sense and it was used back in the late 50’s / early 60’s. The gotcha turns out to be that it is an ill behaved measure. The more data you take, the bigger the number you get. ( = it does not converge ). That problem is what lead NBS to dig into a better measure. The result was ADEV. The point about averaging vs decimation relates to what you do to the data *before* you ever compute the ADEV. If you have 0.1 second samples, you have to do something to get to a tau of 1 second or 10 seconds or … The process you use to get the data to the proper interval turns out to matter quite a bit. Bob > On May 10, 2018, at 12:17 PM, Dana Whitlow <k8yumdoo...@gmail.com> wrote: > > I'm a bit fuzzy, then, on the definition of ADEV. I was under the > impression that one measured a series of > "phase samples" at the desired spacing, then took the RMS value of that > series, not just a single sample, > as the ADEV value. > > Can anybody say which it is? The RMS approach seems to make better sense > as it provides some measure > of defense against taking a sample that happens to be an outlier, yet > avoids the flaw of tending to average > the reported ADEV towards zero. > > Dana (K8YUM) > > > On Thu, May 10, 2018 at 9:21 AM, Bob kb8tq <kb...@n1k.org> wrote: > >> Hi >> >> If you collect data over the entire second and average that down for a >> single point, then no, your ADEV will not be correct. >> There are a number of papers on this. What ADEV wants to see is a single >> phase “sample” at one second spacing. This is >> also at the root of how you get 10 second ADEV. You don’t average the ten >> 1 second data points. You throw nine data points >> away and use one of them ( = you decimate the data ). >> >> What happens if you ignore this? Your curve looks “to good”. The resultant >> curve is *below* the real curve when plotted. >> >> A quick way to demonstrate this is to do ADEV with averaged vs decimated >> data …. >> >> Bob >> >>> On May 10, 2018, at 4:46 AM, Oleg Skydan <olegsky...@gmail.com> wrote: >>> >>> Hi >>> >>> I have got a pair of not so bad OCXOs (Morion GK85). I did some >> measurements, the results may be interested to others (sorry if not), so I >> decided to post them. >>> >>> I ran a set of 5minutes long counter runs (two OCXOs were measured >> against each other), each point is 1sec gate frequency measurement with >> different number of timestamps used in LR calculation (from 10 till 5e6). >> The counter provides continuous counting. As you can see I reach the HW >> limitations at 5..6e-12 ADEV (1s tau) with only 1e5 timestamps. The results >> looks reasonable, the theory predicts 27ps equivalent resolution with 1e5 >> timestamps, also the sqrt(N) law is clearly seen on the plots. I do not >> know what is the limiting factor, if it is OCXOs or some counter HW. >>> >>> I know there are HW problems, some of them were identified during this >> experiment. They were expectable, cause HW is still just an ugly >> construction made from the boards left in the "radio junk box" from the >> other projects/experiments. I am going to move to the well designed PCB >> with some improvements in HW (and more or less "normal" analog frontend >> with good comparator, ADCMP604 or something similar, for the "low >> frequency" input). But I want to finish my initial tests, it should help >> with the HW design. >>> >>> Now I have some questions. As you know I am experimenting with the >> counter that uses LR calculations to improve its resolution. The LR data >> for each measurement is collected during the gate time only, also >> measurements are continuous. Will the ADEV be calculated correctly from >> such measurements? I understand that any averaging for the time window >> larger then single measurement time will spoil the ADEV plot. Also I >> understand that using LR can result in incorrect frequency estimate for the >> signal with large drift (should not be a problem for the discussed >> measurements, at least for the numbers we are talking about). >>> >>> Does the ADEV plots I got looks reasonable for the used "mid range" >> OCXOs (see the second plot for the long run test)? >>> >>> BTW, I see I can interface GPS module to my counter without additional >> HW (except the module itself, do not worry it will not be another DIY >> GPSDO, probably :-) ). I will try to do it. The initial idea is not try to >> lock the reference OCXO to GPS, instead I will just measure GPS against REF >> and will make corrections using pure math in SW. I see some advantages with >> such design - no hi resolution DAC, reference for DAC, no loop, no >> additional hardware at all - only the GPS module and software :) (it is in >> the spirit of this project)... Of cause I will not have reference signal >> that can be used outside the counter, I think I can live with it. It worth >> to do some experiments. >>> >>> Best! >>> Oleg UR3IQO >>> <Снимок экрана (1148).png><Снимок экрана (1150).png><Снимок экрана >> (1149).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. >> > _______________________________________________ > 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.