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:
http://leapsecond.com/tmp/dave1-phase.gif
http://leapsecond.com/tmp/dave1-freq.gif
http://leapsecond.com/tmp/dave1-adev.gif
http://leapsecond.com/tmp/dave1-tdev.gif
http://leapsecond.com/tmp/dave1-tdev10.gif
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).
/tvb
_______________________________________________
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.
