[time-nuts] +/- TI button on 5370B

Magnus Danielson magnus at rubidium.dyndns.org
Sat Jul 6 10:02:22 EDT 2013

Hi Charles,

This triggered some thoughts. :)

On 07/06/2013 06:28 AM, Charles P. Steinmetz wrote:
> So, for proper operation in +/- TI mode, use external arming to remove
> the ambiguity when the trigger events cross from + to - and back, and
> make sure you have adjusted the triggering properly for a robust
> response to the input signals.

I've found it annoying that some counters miss the +/- TI mode (where 
either A or B triggers start). Using only TI mode (where A triggers 
start) one ends up with a situation where I measure either every PPS 
(PPE on A is early compared to B) or every other PPS (PPS on A is late 
compared to B). If they alter position, you end up altering the report 
speed. It can be even tricker, since if the PPS on A is very much later 
than B, then it can trigger the measurement directly anyway.

This is all due to the logic and timing of the triggering logic. The 
details of counters differs in subtle details. After the stop trigger, 
there is a dead-time at which the counter does not arm another measurement.

A direct trigger sequence is START, STOP, DONE.
An arm trigger sequence is ARM, START, STOP, DONE.
(Assuming repetive measurment mode, single measurments won't arm another 
triggering round the way DONE does it here.)

For TI mode, channel A triggers START and channel B triggers STOP.
For +/- TI mode, either channel A and B triggers first, and whoever is 
later triggers later.

The TI mode can produce unfortunate results when the B channel PPS 
occurs just before the A channel PPS, such that the measurement is not 
gathered by the processing and the hardware triggered for another 
measurmenet before the A channel PPS occurs, so it skip to the next PPS 
pulse instead. That is, the dead time caused by the CPU causes a time 
after the B channel PPS where the A channel PPS trigger will be missed.
If the A channel PPS is about the dead-time after B channel PPS, and 
altering to be somewhat before and after the critical time (which is not 
necessarily static) then the A channel PPS will be "swallowed" or not. 
That is, the time between the measurements will alter. The same thing 
occurs if the A and B channels PPS occurs at about the same time, so 
sometimes the A is in the lead and a small delay will be measured every 
second and sometimes B will be in lead and a large delay will measured 
every other second.

That makes it very dodgy measurements for a time-nut. The only thing 
that really works is to set the PPSes up on channel A and B such that B 
always occurs after A. ARMing does not really help to resolve the issue.

Either you can induce delays in the equipment, or use the falling edge 
of either, if the PWM factor allows for sufficient delay. For long term 
measurements this can still fail, as large deviations will phase-wrap 
and you end up in the dead-band regardless.

For TI mode (A->B), using a separate ARM thus does not help, as you can 
just as well use the A event as arming, because you will have to resolve 
tha A/B relationship regardless.

For +/- TI mode, using a separate ARM does not help either, since either 
of the channels suffice as trigger, and the relative timing is resolve 
dynamically by the counter. For most time, the dead-time will be hidden, 
but for longer runs where A/B timing diverge, it can create the same 
issues as the remaining time from the STOP to the START (as the sequence 
now has been assigned and maintained) can become to short to cover up 
the dead-time.

ARMing does help the TI measurement if you run the ARM at a lower rate. 
Running at 1/2 rate resolves some of the issues, but not if the ARM 
signal occurs close to the A/B event and B is early, but 1/3 rate or 1/4 
rate will resolve it properly.

ARMing does help the +/- TI measurement if you run the ARM at a lower 
rate. Running at 1/2 rate is needed for long term measurements to always 
make room for the dead-time regardless of the diversions between the 

ARMing with a PPS is a great tool when measure clock rates.

In comparison, I'm sloppy as hell in the typical setup, and the only 
reason for my sloppiness is that I don't sit down and think it through, 
but the actual logic isn't that hard if you have the components clear 
for you.

Counters like HP5335A, HP53131A and HP53132A only has TI mode to the 
best of my understanding, and thus needs extra care in setup for 
reliable result.

Counters like HP5370a/B has both +TI mode and +/- TI mode.

The software receiving the time-stamps, can detect the altering times 
and duplicate measurements to achieve a time-series which at least has 
linear time, even if the values are not always unique. This form of 
cover up works if the software is aware of elapsed time and can figure 
out when samples has gone missing due to triggering errors. Looking at 
raw values also helps. It's part of un-wrapping the phase.

I hope this triggers a little deeper debate about how triggering/arming 
should be done to get quality results.


More information about the time-nuts mailing list