[time-nuts] +/- TI button on 5370B
magnus at rubidium.dyndns.org
Sat Jul 6 10:02:22 EDT 2013
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
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
Counters like HP5335A, HP53131A and HP53132A only has TI mode to the
best of my understanding, and thus needs extra care in setup for
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