[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

> http://www.kirkbymicrowave.co.uk/time-stuff/ref-out-to-A-3.6m-cable-to-B-rev4.zip
> The format should be pretty self-explanatory. Note the counter sample

Well done, nicely self-documenting.

> I then used Tom's "adev1"
> http://www.leapsecond.com/tools/adev1.htm
> http://www.leapsecond.com/tools/adev1.c
> 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
> time.

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 mailing list