Dear Azelio,
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.
Cheers,
Magnus
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
<[email protected]> 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 -- [email protected]
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
