Tom Van Baak
tvb at LeapSecond.com
Sun Oct 9 16:07:26 EDT 2016
I run into this all the time. Some thoughts...
1) My *work-around* is to adjust the REF 1PPS by tens of microseconds, or even 500 ms. That avoids running into sign changes and skipped samples when a TIC gets near zero. This works really well for stable clocks where 500 ms drift is next to impossible.
2) My *solution* is to use time-stamping counters (TSC) instead of time interval counters (TIC). With time-stamping you avoid all the hassles of a TIC. There is no worry about CH1 vs. CH2, there are no sign changes, there are no missed samples, it doesn't matter if the sources are fast or slow, or ahead of behind. There is no concept of "start" or "stop", but only "when".
For high-end TSC, I use a CNT-90 (or equiv) and for low-end I use my little picPET. It gets even more useful if you have multiple, synchronized time stamping counters.
3) The problems you are running into get far worse the less accurate and less stable the sources are (such as mains, mechanical, vintage quartz, and pendulum clocks). So that's why I developed the picPET time-stamping counter. It's 400 ns resolution is not good enough for you. Even the new 10 ns version isn't good enough for your needs.
But a fellow time nut is working on a 100 ps version which will do both time stamping and time interval. That, finally, will solve the problems everyone has with TIC's. However, I still use hp 53131A/53132A a lot in my lab and simply avoid the TIC problem using #1 above.
4) TimeLab already has support for some time stamping counters -- under Acquire click on Timestamp instead of Phase or Frequency.
Alternatively you can write simple tools that translate time stamp data to phase difference data or frequency data and then use TimeLab the way you usually do. The trick is to use the "Live ASCII file"input option. Also use fflush() in your C code (or equiv). That way you retain the real-time display feature that TimeLab provides.
More information about the time-nuts