[time-nuts] Question about frequency counter testing
magnus at rubidium.dyndns.org
Sat May 12 17:44:13 EDT 2018
On 05/12/2018 09:41 PM, Bob kb8tq wrote:
>> On May 12, 2018, at 1:20 PM, Oleg Skydan <olegskydan at gmail.com> wrote:
>> From: "Bob kb8tq" <kb8tq at 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
>>> 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*
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.
>> 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.
More information about the time-nuts