[time-nuts] Help me make some sense of adev measurements of SR620'sown clock

[Magnus Danielson]

David,

Looking at the ADEV plot, I see the ripple that I expect from some 
oscillatory property.

Looking at the phase, I see some of it, and picking it up in fityk (to 
view the phase info) I see a sawtooth like pattern, seeing typ around 4 
cycles in 2000 s or so, which is typical of heating/AC type of 
behaviour. Hence, I may be looking at a temp-sensor.

Shielding from temperature-variations can be tricky, as the SR620 
produces a lot of heat. Putting thermal mass all around it 
(waterbottles) might be a fun experiment, but for most part, I think the 
performance you get is good and you should not be bothered with it.

The ADEV measure you got that was higher had only one degree of freedom, 
so the confidence interval was very wide, so you should just ignore 
that. You should look at the oadev list instead.

Cheers,
Magnus

On 01/25/2015 11:21 PM, Tom Van Baak wrote:
>> 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 -- time-nuts at febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>