# [time-nuts] TEC party file format?

Tom Van Baak tvb at LeapSecond.com
Tue Jun 28 23:26:41 UTC 2011

```> If I have a day of good data, then a break, then more good data, how long can
> the break be so that I can correctly guess the number of cycles that were
> missed?  It depends upon how much the frequency changes.  If I extrapolate
> forward from before the break and back from after, the lines will intersect.
> If I can estimate the error in the slope of those lines I can see what
> happens if I use the high/low error cases.

Hal,

Your logic sounds correct. Note the question of how accurately
you can predict the future time or frequency of a clock, based
on a long record of its past behavior, is exactly what the ADEV
family of statistics give you. It's all about how much or little the
frequency changes over time.

I'll send you mains data from yesterday if you want to play with
simulating missing data algorithms. I think in this case TDEV or
MTIE is the statistic you want.

I had to deal with this issue of data breaks in my relativity clock
experiment on Mt Rainier (www.leapsecond.com/great2005, for
new people on the list). In this case you have stable clocks and
because of time dilation they "slip cycles" so to speak while you
are away from home. The question is: how stable a clock do you
need to have before you are sure you can see relativistic time
dilation and not just nanoseconds of normal clock drift.

> One thing that might help get back in cycle sync would be to use a PIC/AVR
> rather than a 555.  The idea is that it can do the first layer of data
> reduction, say divide by 100.  That would roughly multiply the
> get-back-in-sync time by 100.  (assuming not much noise)

Correct. Or divide to get 1 pulse per minute, or hour, etc. You may
laugh but even dividing by 5184000 (one pulse per day) would still
give you enough points to make a really nice plot of US mains power
timekeeping performance over a year. This illustrates the issue that
for some cases (such as this one) occasionally recording time
error (phase) is often easier and more reliable than making many
uninterrupted frequency measurements and integrating them all
to estimate net time error.

/tvb

```