On 25 Jan 2015 23:02, "Tom Van Baak" <t...@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 _______________________________________________ time-nuts mailing list -- time-nuts@febo.com To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts and follow the instructions there.