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

[Dr. David Kirkby (Kirkby Microwave Ltd)]

On 25 Jan 2015 23:02, "Tom Van Baak" <tvb at leapsecond.com> wrote:

> You're getting 1e-12 at 1 second. Sounds fine to me.

Obviously you have the experience to know that 1e-12 at 1 second is fine.

But if it's possible,  I would like to understand the relationship between
the counters specification and the adev (or one of the modifications of it)
one would expect to see.

Obviously it is nice to know that the counter is working ok, but I would
like to understand how one can ascertain that from the data I recorded,
based on the SR620's specifications.

> 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.

That's interesting.  It is about 4:30 am local time here, so when I was
asleep. I would have expected data then to be better than during the day
when I move around. The biggest disturbance occurred at a time I would have
least expected it.

> > Do most people save time information as I have done there, or phase
> > information?

> Always save phase. Not sure what you mean by time.
The counter can measure the time between the start and stop inputs, which
is what I done. The numbers are around 17.5 ns due to the cable length.

But instead of saving those time values, I could have configured the
counter to save the phase in the range -180 to +180 degrees. Your adev1
programe expected time in seconds rather than phase in degrees, which is
why I saved time rather than phase.  But I will use adev5 as you
suggested.  I used adev1 primarily since you had a web page on it.

I am not talking about elapsed time, time of the day etc. That's something
quite different.

> 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.

I did save elapsed time as you can see. I was in fact a bit surprised that
the data points are spaced very slightly *less* than a second apart. I
would have expected the data to take 1 second to collect, then some time
processing time, especially since I introduced a delay of about 200 us to
stop the GPIB reads randomly failing.   That's a bit of a mystery.

> 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.

I had never heard of the MJD, but I will do what you suggest.

> > 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.

That was not intensional. I would have intended to put the leading zero.

> The preferred way to write this is simply 2015-01-24 23:02:55 (see ISO
8601).

OK, I'll do that, despite it seems quite unnatural to us brits!

John's software looks impressive. In fact is TimePod hardware too, but far
out of my budget. I will have to make do with the SR620.

I just wish I didn't have to load the data into a Windows program. Maybe at
some point I will try to get gnuplot to do similar.

> /tvb

Thank you Tom. Also to Bob. I will do as Bob suggested and repeat using an
external 10 MHz source, rather than use the counters own timebase.

Dave