magnus at rubidium.dyndns.org
Sun Oct 9 07:32:56 EDT 2016
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