> I switch counter to TIME MODE, because ADEV1 utility using times, not > frequency:
No. ADEV1 expects phase. Not time, not period, not frequency. > Here is from documentation: > > "Adev1 works on everything from pendulum clocks to hydrogen masers. The > only restrictions are that the data must be phase (time interval) rather > than frequency; the data must be sequential (no gaps); and the data > should be free from glitches or outliers." Busted! It looks like you broke all three rules: your data was period (not phase), your data has deadtime (gaps), and your data has glitches! Anyway, here is a more complete explanation. The word phase is confusing because it is used differently in time & frequency metrology than in other branches of science. The units are seconds (not degrees, not radians, not rotations, not angles). Think of phase as simply the difference between the time that two clocks display. If you call one clock the reference and assume it is the true time, then phase is simply the time error of the DUT clock. Think of a wall clock; maybe 2 seconds behind, or 15 seconds ahead. This is the phase. It tends to wander slowly and grow larger over time. If you were to write down the time error of your clock once a day for a month you'd have a nice set of phase numbers that you can feed to any tool that computes ADEV. Note also that phase is a cumulative measurement. That is, every successive data point reflects the net clock error since you started collecting data. Even if you lost 29 days of data in the middle, you'd still know how far off the clock had drifted in time between day 1 and day 30. If this all makes sense so far, I'll go on to explain how period or frequency measurements are related to this. /tvb _______________________________________________ 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.
