[time-nuts] TimeLab

[Magnus Danielson]

Hi Adrian,

I know. I avoided discussing that detail in my initial postings.
For the purpose, the 500 ps resolution of the HP53131A is sufficient, or 
else I would have used another counter for the purpose.

I can shift the phase of the DUT intentionally, but if so I want to be 
able to compensate that shift in the software. Now, such a shift should 
be kept separate from the calibration factors which fills a different 
purpose.

Cheers,
Magnus

On 10/09/2016 06:34 PM, Adrian wrote:
> Hi Magnus,
>
> unfortunately, you can't measure 0 delay between two signals with a counter.
> With a 53131A, there is 500ps of LSB jitter and jitter from the measured
> signal as well as from the reference signal.
> When both signals are exactly in phase, the counter will randomly jump
> between 0 and 1 second (assuming you are measuring 1pps signals).
> In order to avoid this dead zone, you must add a sufficiently large
> phase offset between both signals.
> And, keep the acquisition time small enough to avoid phase wraps due to
> drift between both sources.
> The dead zone random jumps can not be unwrapped by any software.
>
> Cheers,
> Adrian
>
>
> Magnus Danielson schrieb:
>> Hi,
>>
>> Well, yes. You can do some fancy stuff with additional hardware, but I
>> think with already a handful of relatively simple software fixes and
>> some basic setup conditions, a sufficiently robust method emerges.
>>
>> I could not sign-swap the measurements in TimeLab when I tried.
>> I don't seem to be able to force the unwrapped phase to be +/- half
>> cycle.
>> I don't seem to be able to offset my readings. I have two sources of
>> offset, one is the additional delay of cables, and the other is the
>> offset due to wrong cycle (I hope this one can be baked into
>> alternative phase-unwrapping mode). I would prefer if I could hit
>> calibration to establish the zero-level. Typically I use a BNC barrel
>> and well, it does add smoe more delay
>>
>> What I propose should be doable with a simple counter like 5335A,
>> 53131/2A or similar. If you have a locked say 100 Hz or 1 kHz signal
>> (TADD-2 can be useful if the GPSDO does not output proper signal), you
>> can do the picket fence and resolve things, it is just that there is a
>> few things to aid in the post-processing to make values useful.
>>
>> I further hint about a few things which makes easier to analyze is the
>> improved support for zooming.
>>
>> Oh, I do care about phase variations and absolute phase measures. I do
>> such measures a lot. ADEV and TDEV is not all the things I measure,
>> especially when considering systematic effects.
>>
>> Cheers,
>> Magnus
>>
>> On 10/09/2016 03:42 PM, Bob Camp wrote:
>>> Hi
>>>
>>> Given that *some* of us have more than errr … one counter :)
>>>
>>> There are several setups that involve two or three counters to
>>> resolve some of these issues. Having
>>> multiple serial ports or multiple devices on a GPIB isn’t that big a
>>> problem. Addressing multiple devices
>>> (setting up the addresses in TimeLab) is an added step. Coming up
>>> with standard setups would be the
>>> first step. Getting them documented to the degree that they could be
>>> run without a lot of hassle would be
>>> the next step.
>>>
>>> Another fairly simple addition (rather than a full blown counter)
>>> would be some sort of MCU to time tag
>>> the input(s). It’s a function that is well within the capabilities of
>>> a multitude of cheap demo cards. Rather than
>>> defining a specific card, it is probably better to just define a
>>> standard message (115200 K baud, 8N1, starts
>>> with “$timenuts$,1,”, next is the channel number, after that the (32
>>> bit?) seconds count.The final data field is
>>> a time in nanoseconds within the second, *two byte check sum is last,
>>> cr/lf). If there is a next generation version that is
>>> incompatible, the 1 after timeouts changes to a 2.) Yes, even 10
>>> seconds after typing that definition I can see
>>> a few problems with it. Any structural similarity to NMEA is purely
>>> intentional. That’s why it needs a bit of
>>> thought and work before you standardize on it. It still would be a
>>> cheap solution and maybe easier to integrate
>>> into the software than multiple counters. You do indeed have all the
>>> same setup and documentation issues.
>>>
>>> In any of the above cases, the only intent of the added hardware is
>>> to get a number that is good to 10’s of ns.
>>> Anything past that is great. Once you know where all the edges really
>>> are, sorting out the phase data becomes
>>> much easier.
>>>
>>> Bob
>>>
>>>> On Oct 9, 2016, at 7:32 AM, 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.
>>>>
>>>> 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.
>>>
>>> _______________________________________________
>>> 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.
>>>
>> _______________________________________________
>> 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.
>>
>
> _______________________________________________
> 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.
>