Hi Next layer to this onion is that the low(er) frequency signals out of the mixer have slow(er) edges. There has been a lot of discussion on the list in the past about Dual Mixer Time Difference (DMTD) setups. The fast answer is in a paper by a gentleman by the name of Collins. on how to do the limiters in a fashion best optimized to get around the issue. There is some debate on how old the technique actually is, but his approach is pretty good.
Bob > On Aug 20, 2015, at 3:55 PM, Matthias Jelen <[email protected]> wrote: > > Dear John & Magnus, > > thank you very much for your detailed explanation. I realize that the > averaging topic is much more complex than I thought - it certainly gives me > something to think about :-) I never thought in terms of noise bandwith in > this application, thanks for putting me on this track. > > It seems that the simplest and safest way to get meaningfull results is to > hook up two mixers and a hand full of opamps and comparators. > > To learn more, I think the best way would be to put the counter into its fast > binary mode and acquire 1k time interval samples per second. That would give > me loads of data to play with and it would be easy to try out how different > averaging schemes affect the result. > > I´ll have to read and think some more :-) > > Cheers, > > Matthias > > > Am 19.08.2015 um 21:52 schrieb Magnus Danielson: >> Dear Mathias, >> >> On 08/19/2015 06:40 PM, Matthias Jelen wrote: >>> Hello, >>> >>> I´ve got a question concerning ADEV-measurements. >>> >>> I´m measuring the 15 MHz output of a KS-24361 with my SR-620 with it´s >>> internal (Wenzel) OCXO using Timelab. For the first shot I used the >>> counters frequency mode with 1s gatetime. ADEV at tau=1s turned out to >>> be arounf 2E-11, which fits the 20 ps single shot resolution of the >>> SR-620 nicely. >>> >>> To overcome this limitation without setting up a DMTD system, I used the >>> counter as TIC, feeding 1 kHz (derived from the counter´s reference) to >>> the start channel, the 15 MHz to the stop channel and put the counter >>> into average mode / 1k samples. This gives me one averaged result per >>> second. >>> >>> The idea was that this shouldn´t change the measurement itself, because >>> like in frequency mode with 1s gate time I get the averaged value over >>> one second, but I expected trigger noise etc. to be averaged out to a >>> certain amount. I have to watch out for phase wraps, but as the two >>> frequencys are quite equal, this is not a big issue here. >>> >>> As expected, ADEV at tau=1s got much better, it is now in the 4E-12 >>> area, which sound reasonable. >>> >>> What makes me wonder is the fact that result are significantly better >>> now at longer taus (10..100s) also, despite of the fact that also in >>> frequency mode these result were well aboce the noise floor (2E-12 @ 10s >>> and so on...). >>> >>> So, is it a good idea to use this kind of averaging, or am I overlooking >>> something which turns the numbers better than they really are? I´m >>> pretty sure I am not the first one to try this... >>> >>> I´m looking forward to your comments. >> >> OK, averaging or filtering of data before ADEV processing is tricky, as it >> filters the data. Whenever you do that, you actually convert your >> measurement from an ADEV measure to something else. If you do proper >> post-processing, this something else can have known properties and thus we >> can relate the amplitude of the curve to amplitude of various noise sources, >> as it will cause biasing from the ADEV properties. >> >> The reason you get better results is because the ADEV response on white >> noise depends on the measurement system bandwidth (see Allan deviation >> wikipedia page), and by averaging you do reduce the bandwidth. >> >> Sometimes when you do this, you loose the gain as you increase the tau, >> since the dominant frequency will lower and become more and more into the >> pass-band of the fixed bandwidth filter you created. What you see is that it >> flattens out to the length of the average before lowering down, as if there >> was no filtering, so you have only achieved a gain in skewed value for very >> short taus, but then no gain at all for longer taus, so no real gain. >> >> This was realized in 1980-1981 and in 1981 an article was published in which >> they realized that they can change the bandwidth along-side the change of >> tau, so that the gain remains. This became the modified Allan deviation >> (MDEV), and was inspired by the methods for improving frequency measures for >> lasers as presented by J.J. Snyder in 1980 and 1981. J.J. Snyder was doing >> what you proposes, averaging of blocks, and then extended this in software, >> and this became a direct inspiration for the MDEV development, which does a >> pre-averaging over tau before processing through ADEV, and this combined is >> the MDEV. >> >> Doing TIC averaging and then continue the processing with MDEV processing >> should produce a proper MDEV curve, unless my tired brain does not miss out >> on details. If you then analyze it as a MDEV (rather than ADEV) then you use >> the values properly. MDEV have the benefit that white phase noise drops by >> tau^-1.5 rather than the ADEV tau^-1, and starting with the SR-620 means you >> for fairly low taus hit actual measurement noise. The averaging makes this >> trip from tau0 of 1 ms in your setup. >> >> So, you can go down this route, but you need to be careful to ensure that >> you have done the processing correctly enough that you get the results that >> can be interpreted properly. >> >> Oh, as you average, phase-unwrapping becomes "interesting". :) >> >> 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. _______________________________________________ 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.
