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

[Azelio Boriani]

Not only: consider that most time interval counters have a minimum
measurable interval (Racal 2351 is 2ns) and slowly crossing PPSes can
be a problem to measure when they are about to cross. In my opinion it
is always better to displace the PPSes, easily done when using GPSDOs
and by using stable delay lines in other cases. The Racal 2351 has
+/-TI measurement function.

On Sat, Jul 6, 2013 at 4:02 PM, Magnus Danielson
<magnus at rubidium.dyndns.org> wrote:
> 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 channels.
>
> 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.
>
> Cheers,
> Magnus
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.