[time-nuts] 5370B / TimeLab question

[djl]

or:
https://ntrs.nasa.gov/citations/19870019361
from Charlie Greenhall

On 2020-12-01 15:52, Tom Van Baak wrote:
> 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.
>> 
> 
> 
> _______________________________________________
> 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.

-- 
Dr. Don Latham  AJ7LL
PO Box 404, Frenchtown, MT, 59834
VOX: 406-626-4304