On 05/12/2018 09:41 PM, Bob kb8tq wrote: > Hi > > >> On May 12, 2018, at 1:20 PM, Oleg Skydan <olegsky...@gmail.com> wrote: >> >> Hi! >> >> From: "Bob kb8tq" <kb...@n1k.org> >>> There is still the problem that the first post on the graph is different >>> depending >>> on the technique. >> >> The leftmost tau values are skipped and they "stay" inside the counter. If I >> setup counter to generate lets say 1s stamps (ADEV starts at 1s) it will >> generate internally 1/8sec averaged measurements, but export combined data >> for 1s stamps. The result will be strictly speaking different, but the >> difference should be insignificant. > > Except here are a *lot* of papers where they demonstrate that the difference > may be *very* significant. I would > suggest that the “is significant’ group is actually larger than the “is not” > group.
There is no reason to treat it light-handed as about the same, as they become different measures, where there is a measurement bias. Depending on what you do, there might be a bias function to compensate the bias with... or not. Even when there is, most people forget to apply it. Stay clear of it and do it properly. Averaging prior to ADEV does nothing really useful unless it is well-founded, and then we call it MDEV and PDEV, and then you have to be careful about the details to do it proper. Otherwise you just waste your time to get "improved numbers" which does not actually help you to give proper measures. >> >>> The other side of all this is that ADEV is really not a very good way to >>> test a counter. >> >> Counter testing was not a main reason to dig into statistics details last >> days. Initially I used ADEV when tried to test the idea of making the >> counter with very simple HW and good resolution (BTW, it appeared later it >> was not ADEV in reality :). Then I saw it worked, so I decided to make a >> "normal" useful counter (I liked the HW/SW concept). The HW has enough power >> to compute various statistics onboard in real time, and while it is not >> requisite feature of the project now, I think it will be good if the counter >> will be able to do it (or at least if it will export data suitable to do it >> in post process). The rest of the story you know :) > > Again, ADEV is tricky and sensitive to various odd things. This whole debate > about it being sensitive goes > back to the original papers in the late 1960’s and 1970’s. At every paper I > attended the issue of averaging > and bandwidth came up in the questions after the paper. The conversation has > been going on for a *long* > time. If you go back to Dr. David Allan's Feb 1966 paper, you clearly see how white and flicker phase modulation noise depend on the bandwidth, and then assumed to be brick-wall filter. Your ability to reflect the amplitude of those noises properly thus depends on the bandwidth. Any filtering reduces the bandwidth, and hence artificially reduces the ADEV value for the same amount of actual noise, then it is not representing the underlying noise properly. However, if you use this for improving your frequency measurements, it's fine and the processed ADEV will represent the counters performance with that filter. Thus, the aim will govern if you should or should not do the pre-filtering. >>> If you are trying specifically just to measure ADEV, then there are a lot >>> of ways to do that by it’s self. >> >> Yes, but if it can be done with only some additional code - why not to have >> such ability? Even if it has some known limitations it is still a useful >> addition. Of cause it should be done as good as it can be with the HW >> limitations. Also it was/is a good educational moment. > > It’s only useful if it is accurate. Since you can “do code” that gives you > results that are better than reality, > simply coming up with a number is not the full answer. To be useful as ADEV, > it needs to be correct. Exactly. >> >> Now it is period of tests/experiments to see the used technology >> features/limitations(of cause if those experiments can be done with the >> current "ugly style HW"). I have already got a lot of useful information, it >> should help me in the following HW/FW development. The next steps are analog >> front end and GPS frequency correction (I should get the GPS module next >> week). I have already tested the 6GHz prescaler and now wait for some parts >> to finish it. Hope this project will have the "happy end" :). > > I’m sure it will come out to be a very cool counter. My *only* concern here > is creating inaccurate results > by stretching to far with what you are trying to do. Keep it to the stuff > that is accurate. Bob and I are picky, and for a reasoon. When we want our ADEV plots, we want them done properly, or else we can improve the specs of the oscillators by changing how fancy post-processing we do on the counter-data. Yes, we see this in professional conferences too. Mumble... BAD SCIENCE! Metrology correct measures takes care for details. Measurements needs to be repeatable and of correct value. 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.
