[time-nuts] 5370B / TimeLab question

[Tom Van Baak]

Hi Skip,

You are exactly right. And, surprisingly, this is correct and normal for 
most TI counters.

The short answer is -- for your use case, a *zero deadtime* time 
interval counter (TIC) or a timestamping counter (TSC), is what you want.

----

The long answer is -- your problems is due to counter dead time. That 
is, in TI mode, the counter waits for chA, and then waits for chB, and 
then calculates and reports the chB-chA time interval measurement. The 
latter takes finite time and depending on the counter it may consume 
milliseconds or even tens of milliseconds. Part of it is CPU time, part 
of it is I/O time (GPIB, RS232/USB, even LAN takes time).

So as chB drifts far away from chA, the next chA may occur during the 
short busy measurement report window while the counter is "blind". The 
counter then has to wait for the *next* next chA and this results in a 
reduction in measurement rate from exactly 10 sps to exactly 5 sps. 
Annoying as it is, it's actually a nice way to measure the counter's 
deadtime ;-)

Note that this problem occurs with any TI measurement, but it is much 
worse with a DMTD, so that's why you ran into already! If you were to 
compare a OCXO/1PPS against a GPS/1PPS you might have to wait *years* 
before a 1 s phase wrap, a counter deadtime issue, occurred.

You see, a DMTD is a huge magnifier. The good news is that it magnifies 
phase difference and magnifies short-term instability by a factor of, 
say, 500,000. The bad news is that it also magnifies phase wrapping by 
500,000. So instead of having an annoying 1 s phase wrap every couple of 
years, or even once a lifetime, you're going to see it happen every 
couple of hours

----

Ok, that said, one solution to this mess is to use a timestamping 
counter (TSC) instead of a time interval counter (TIC). Yes, your 
TAPR/TICC will work perfectly for this. In fact, this is the main reason 
that the TICC was designed to be a flexible dual, independent, 
simultaneous, zero-deadtime, chA-*and*-chB timestamping counter instead 
of a traditional hardcoded chA-*to*-chB time interval counter.

Another solution is to use a microcontroller-based timer that can do 
multi-channel timestamp captures. I have used synchronized picPET's for 
this in the past. But more recently, for Corby's new DMTD, I created a 
six channel timer that can do timestamping or *zero deadtime* time 
interval measurements. Right now this solution works better than a 5370B 
or 53132A at 1/100th the price.

Still, if you have a TAPR/TICC use that instead of your 5370B.

/tvb


On 12/1/2020 12:04 PM, Skip Withrow wrote:
> Hello Time-Nuts,
> I have been having fun playing with the DMTD, but have a question
> regarding data collection.
>
> Obviously with a 10Hz offset oscillator I am feeding square waves with
> a 100ms period to the START and STOP of the 5370B.  The trigger lights
> are happily blinking away at 10Hz.  However, I seem to have two
> different operating modes depending on the difference between the
> START and STOP signals.
>
> If the difference is small, no problem.  I get 10 samples per second
> when TimeLab is run (TimeLab puts the 5370B in Talk Only mode, I
> believe).  When the difference between START and STOP approaches
> something larger than 50ms I start getting only 5 samples per second.
>   I believe this is because the re-arm time misses the next START edge,
> such that I get every other sample.
>
> This definitely gives bad data for TimeLab.  So, the question is, how
> do I straighten out this mess?  For long-term measurements with two
> oscillators that have any kind offset/aging difference you are toast.
> I have thought about maybe adding a 10Hz EXT ARM signal, but if it is
> not at exactly the 10Hz difference frequency that could create
> problems too (and it is a pain in the butt).
>
> I would like to use the 5370B, but maybe it's time to switch to the TICC.
>
> Any suggestions would be appreciated.
>
> Thanks,
> Skip Withrow
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com
> To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>