magnus at rubidium.dyndns.org
Mon Oct 10 08:26:24 EDT 2016
On 10/09/2016 10:07 PM, Tom Van Baak wrote:
> Hi Magnus,
> 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.
Well, that is one option. However, as I care about where my zero line
is, it's annoying to operate in TimeLab.
The main problem I try to illustrate is the shift from tau = 1 s to
tau = 2 s, which can be a dominant case (say 50% of all samples) while
the through zero is annoying, but is more in the neighborhood of below 1
% of all samples.
> 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.
If all the counters we lay out hands on where capable of it, then no
question about it. I made the distinct case that we are not always
fortunate to have such counter available, and still want to make decent
enought measurements. I wanted to both explain the problem, show the
wiring setup and then propose minor software changes to make it much
easier to use.
If I where to use any counter in my private setup, then things would
quickly become much simpler. I intentionally stepped out of that case
and illustrated the hurdles of a fairly common clock.
> 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.
I intentionally steered clear from build another devise. Naturally, if a
sufficiently good and price-worthy one would be easily available, it
would remove much of the worries. Until then, lest than ideal hardware
and then try to use some additional signals and some software to make
things behave sufficiently good.
> 4) TimeLab already has support for some time stamping counters -- under Acquire click on Timestamp instead of Phase or Frequency.
I know, but it does not really help with the given conditions.
Think of the cases where a guy just got his first TIC like HP5335A or
HP53131A, or for that matter, one is laying around unused and can be put
into use. I found that the PM6654C to be quite accurate for some
measurements, even if I have better counters available.
What I try to achieve is more practical measures rather than more
ultimate measures. Where good enough has cleared of some issues, but
give good enough details and read-outs. I can then run my highly
specialized rig separately.
> 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.
Translating externally to TimeLab is certainly a possibility, but I
propose these improvements into TimeLab as I think they are not all that
complex and I think many will benefit from them. Giftwrapping of
commonly reoccurring problems.
More information about the time-nuts