[time-nuts] TimeLab

Sun Oct 9 16:36:23 UTC 2016

Hi Alex,

It all comes down to arming of counters, and how that behaves in the 
time-interval case. I've done a long post on this before, so here is the 
quick explanation:

For a time-interval counter you measure the elapsed time from the start 
trigger to the stop trigger. This means that the stop trigger can only 
be armed for triggering after the start-trigger, and vice versa naturally.

Consider two PPS signals, let's say that the start trigger signal occurs 
and 100 ns later the stop trigger occurs. Great, so for each PPS event 
we get a single read-out. The start triggers, the stop is armed and then 
100 ns later triggers, arming the start trigger again. For each PPS 
event 100 ns elapses from the start to the stop.

Now, consider what happens when the start signal (our DUT) for some 
reason drifts so it occurs 100 ns after the stop signal (our reference). 
As the start signal occurs, it arms the stop channel, but it takes 
9999900 ns before the stop signal occurs, and then that arms the start 
signal, which happens 100 ns later. However, the trouble is if the time 
difference is smaller, then there is no time to arm the start channel 
again, and you miss the event, and now it takes 1000100 ns for the 
trigger. In that situation you miss out on the measurement and is only 
achieving 2 s tau measures rather than 1 s tau measures.

Why would the counter not be able to re-arm the start channel again?
Well, most counters have actually a third state in there, in which after 
the stop channel it actually triggers the processor to grab the 
measurement from the hardware, do the calculations update the display 
and output it over GPIB and only after that arm the start channel again. 
During that time it can't make another measurement and is hence called 
the dead-time. The dead-time can be several ms.

The trick that I then apply is to use a stop signal of higher frequency, 
but who's rising edge matches that of the PPS on the PPS occurence, and 
then let my DUT signal PPS be the start signal, as that will then 
defined the tau-rate. With a 100 Hz signal I now have 10 ms period and 
then from the last stop-time I have 990 ms for the counter to re-arm the 
start-channel, and thus hide the dead-time. This is the picket fence 
approach rather than having alternate counters to cover up each others 
dead-time.

As I move between positive and negative offset, I maintain the 1 sample 
per second readout rate that I want. However, I need my phase-wrapping 
to support me and I also need to reverse the values of my read-outs for 
them to have the same meaning.

Cheers,
Magnus

On 10/09/2016 06:01 PM, Alexander Pummer wrote:
> Hello Magnus,
>
> I am a totally unerducated time nut better, to say; not time nut, just
> an old RF ingenieur,  and so I have trouble to understand how could a
> counter stop to count before it started to count. I case you would have
> a circuit, which would tell you which pulse came at first and start the
> counter regardless of which of the two pulse came first and the same way
> stop the counter regardless pulse came last, you could count out the
> time difference with the interval counter independently from the
> sequence the pulses,
>
> Or you could use two counters and reverse the inputs at the second
> counter, thus one counter would show the positive error and the other
> the negative error.
>
> 73
> KJ6UHN
> Alex
>
>
>
> On 10/9/2016 4:32 AM, Magnus Danielson 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.
>>
>> 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.
>>
>>
>> -----
>> No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 2016.0.7797 / Virus Database: 4656/13173 - Release Date:
>> 10/08/16
>
> _______________________________________________
> 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.