[time-nuts] TimeLab

Magnus Danielson magnus at rubidium.dyndns.org
Sun Oct 9 07:32:56 EDT 2016

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.


More information about the time-nuts mailing list