magnus at rubidium.dyndns.org
Sun Oct 9 08:53:26 EDT 2016
Indeed. I know that. Some counters have +/- TI trigger, such that
regardless which of the channels which is first after arming, it
triggers and then the other, and it will resolve the time ambiguity.
No wonder a coax delay is often used to aid triggering.
I didn't want to go into depth on counter design, a topic which I could
spew out much more text on, but this is not focused on the counters
themselves, but how we use them to get practical and useful data. I
would appreciate if we could stick to that topic, as I think it is a
relevant one. Practical obstacles and how we handle them. Here we have a
given counter, how do we utilize it best to get good measurements.
Also, I could dig up many counters that may solve this or that issue,
but for the given situation I'm stuck with this counter.
On 10/09/2016 02:27 PM, Azelio Boriani wrote:
> In the real world of TICs is not possible to implement a stop pulse
> that occurs before its start pulse. When a regular start-stop (stop
> pulse after start, positive delay) is followed by a negative delay
> (stop pulse before the start) the sample is lost because the start has
> not yet occurred. The only way is to intentionally delay the stop so
> that it will never occur before the start. The delay must be known and
> very stable, of course.
> On Sun, Oct 9, 2016 at 1:32 PM, Magnus Danielson
> <magnus at rubidium.dyndns.org> wrote:
>> Fellow time-nuts,
>> I don't know if it is me who is lazy to not figure TimeLab out better or if
>> it is room for improvements. I was considering writing this directly to
>> John, but I gather that it might be of general concern for many, so I
>> thought it be a good topic for the list.
>> In one setup I have, I need to measure the offset of the PPS as I upset the
>> system under test. The counter I'm using is a HP53131A, and I use the
>> time-interval measure. I have a reference GPS (several actually) which can
>> output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.
>> In the ideal world of things, I would hook the DUT PPS to the Start (Ch1)
>> and the reference PPS to the Stop (Ch2) channels. This would give me the
>> propper Time Error (DUT - Ref) so a positive number tells me the DUT is
>> ahead of the reference and a negative number tells me that the DUT is behind
>> the reference.
>> Now, as I do that, depending on their relative timing I might skip samples,
>> since the counter expects trigger conditions. While TimeLab can correct for
>> the period offset, it can't reproduce missed samples.
>> I always get suspicious when the time in the program and the time in real
>> world does not match up.
>> I could intentionally shift the PPS output of my DUT to any suitable number,
>> which would be one way to solve this, if I would tell TimeLab to withdraw
>> say 100 ms. I might want to do that easily afterhand rather than in the
>> setup window.
>> To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal with
>> a stable rising edge aligned to the PPS to within about 2 ns. Good enough
>> for my purpose. However, for the trigger to only produce meaningful results,
>> I will need to swap inputs, so that the PPS from DUT is on Start/Ch1 and the
>> IRIG-B is on Stop/Ch2. This way I get my triggers right. However, my
>> readings have opposite sign. I might have forgotten about the way to correct
>> for it.
>> However, TimeLab seems unable to unwrap the phase properly, so if I have the
>> condition where I would get a negative value of say -100 ns then the counter
>> will measure 9,999,900 ns, so I have to force a positive value as I start
>> the measurement and then have it trace into the negative. I would very much
>> like to see that TimeLab would phase-unwrap into +/- period/2 from first
>> sample. That would be much more useful.
>> I would also like to have the ability to set an offset from which the
>> current zoom window use as 0, really a form variant of the 0-base but
>> letting me either set the value or it be the first value of the zoom. I have
>> use for both of these. I often find myself fighting the offset issues. In a
>> similar fashion, I have been unable to change the vertical zoom, if I don't
>> care about clipping the signal then it forces me to zoom in further than I
>> like to. The autoscale fights me many times in a fashion I don't like.
>> OK, so there is a brain-dump of the last couple of weeks on and off
>> measurement experiences. While a few things might be fixed in the usage, I
>> wonder if there is not room for improvements in the tool. I thought it
>> better to describe what I do and why, so that the context is given.
>> time-nuts mailing list -- time-nuts at febo.com
>> To unsubscribe, go to
>> and follow the instructions there.
> 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.
More information about the time-nuts