[time-nuts] Help me make some sense of adev measurements of SR620'sown clock
Tom Van Baak
tvb at LeapSecond.com
Sun Jan 25 17:21:34 EST 2015
> The format should be pretty self-explanatory. Note the counter sample
Well done, nicely self-documenting.
> I then used Tom's "adev1"
> to analyze the data.
That will work, but adev5 is a more recent version that I now use instead.
C:\tmp>skip 17 < ref-out-to-A-3.6m-cable-to-B.txt | fld 1 | adev5 /a 0 10 .5
** log(tau) from 0 to 10 step 0.5, that is, tau from 1 to 1e+010 with 2 steps/decade
0.0000 1 a -11.997131 1.006628e-012 56163
0.5000 3 a -12.432202 3.696563e-013 56159
1.0000 10 a -12.818504 1.518784e-013 56145
1.5000 32 a -13.123597 7.523206e-014 56101
2.0000 100 a -13.370151 4.264311e-014 55965
2.5000 316 a -13.787569 1.630914e-014 55533
3.0000 1000 a -14.280998 5.236028e-015 54165
3.5000 3162 a -14.694447 2.020940e-015 49841
4.0000 10000 a -15.061822 8.673176e-016 36165
Better yet, use John's TimeLab, import with 'L' and see nice phase, frequency, adev, tdev plots within seconds. Here are the plots you will get:
> I'm puzzled about, is how to interpret this, and if interpretation is
> correct, my counter might not be in spec.
Your interpretation is correct. You can also get TDEV numbers using adev5 /t
> The SR620 counter's display has resolution of 1 ps, and supposedly a
> 25 ps rms single short resolution. Would I be right in assuming that
> after 1 second (1000 samples), I would expect to see an adev of
> 25e-12/sqrt(1000) = 8e-13, suggesting my counter is not achieving the
> 25 ps rms resolution, but rather sqrt(1000)*1.0066e-12=31.8 ps?
You're getting 1e-12 at 1 second. Sounds fine to me. Don't sweat the 10 vs 9 vs 8e-13 thing; the counter is working fine. The TDEV gets down to 4e-13 at 4 seconds if you want nice numbers. You're partly limited by 1 ps LSDigit quantization as well.
> Also, why would the adev rise at 20000 tau, when this is only
> measuring the time between its own reference, and a version delayed by
> about 17.5 ns due to a few metres of cable? But maybe there's not
> really enough data at 20000 seconds.
There are many things hidden inside the word "measuring itself". Internal and external enviromental effects will start to play a role in this time frame.
Also, when you plot phase with TimeLab you'll notice a jump around T+23600 seconds. This is likely you breathing near the instrument, or touching a cable, or closing a door. We're talking ps here, so you can't even look at it while it's running.
> Do most people save time information as I have done there, or phase
> information? I'm guessing the two are easily related, but I'm
> wondering what will work with most peoples software. What I like about
> Tom's is it compiles easily on my Unix box, without me having to use
> Windows. But I note some of Tom's software wants phase, and the other
Always save phase. Not sure what you mean by time. Even better is to save both phase and elapsed time or real time; the latter can be used as a check that your sample rates are what you expect.
Personally, I prefix every ascii line received with a MJD timestamp. That way all my log files, everything from counters to temperature sensors to GPS NMEA lines can all be correlated against themselves and with other people.
> Data collection started at: 23:2:55 GMT on 24/01/2015 (day/month/year format)
Always use leading zeros for hours, minutes, and seconds. The preferred way to write this is simply 2015-01-24 23:02:55 (see ISO 8601).
More information about the time-nuts