[time-nuts] TimeLab

[Tom Van Baak]

> I didn't want to go into depth on counter design, a topic which I could 
> spew out much more text on, but this is not focused on the counters 
> themselves, but how we use them to get practical and useful data. I 
> would appreciate if we could stick to that topic, as I think it is a 
> relevant one. Practical obstacles and how we handle them. Here we have a 
> given counter, how do we utilize it best to get good measurements.
> Also, I could dig up many counters that may solve this or that issue, 
> but for the given situation I'm stuck with this counter.

Ok. Yes, the 53131A/53132A (and many other) counters get awkward when your signals get too near zero. There are issues of signs, of start / stop ambiguity, and missed samples due to cycle slipping. You want to avoid this. TimeLab cannot make up for random lost cycles, nor should hacks to that effect be in TimeLab, or Stable32, etc.

So here's another trick when making long-term 1PPS measurements. Start with a clean 50% 1 Hz signal for your REF input instead of a typical short ~10 us 1PPS signal. As you monitor the data, when the TI numbers start to get close to zero -- you simply change the trigger edge of the REF input channel. Now you are triggering at the half-point of the REF/PPS instead of the zero-point of the REF/PPS. Later on, when the TI numbers once again drift toward zero, you flip the trigger edge again.

This requires GPIB control of the counter, not its talk-only mode. You have a quarter to a half a second to send the GPIB command; very possible. When done right, your raw TI readings will always be in the range of, say, 0.25 s and 0.75 s. Your phase unwrap code will handle the 0.5 second "wraps", with no loss of precision, no loss of samples, no loss of phase.

This effectively turns a 53131A/53132A into a TSC for ~1 Hz data. What you end up with is a clean set of data, with no missed samples. The occasional moments when the trigger edge is flipped are obvious within the data stream itself so your little tool that translates raw GPIB data from the TIC to clean phase or time-stamping data for TimeLab can handle the half second cycle slips with no external information. Just configure TimeLab to read Phase Difference, or Timestamp data, via live ASCII file, and you're all set.

/tvb