MD
Magnus Danielson
Sun, Oct 9, 2016 11:32 AM
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
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
AB
Azelio Boriani
Sun, Oct 9, 2016 12:27 PM
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
magnus@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@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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
<magnus@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@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
MD
Magnus Danielson
Sun, Oct 9, 2016 12:53 PM
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
magnus@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@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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
> <magnus@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@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@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
BC
Bob Camp
Sun, Oct 9, 2016 1:42 PM
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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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@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@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
MD
Magnus Danielson
Sun, Oct 9, 2016 3:48 PM
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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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@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@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@febo.com
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
AP
Alexander Pummer
Sun, Oct 9, 2016 4:01 PM
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@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
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@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
BS
Bob Stewart
Sun, Oct 9, 2016 4:19 PM
Don't forget the possibility of saving the data to a file and pre-processing the file before sending it to Timelab.
Bob
-----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Magnus Danielson <magnus@rubidium.dyndns.org>
To: time-nuts@febo.com
Cc: magnus@rubidium.se
Sent: Sunday, October 9, 2016 10:48 AM
Subject: Re: [time-nuts] TimeLab
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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Don't forget the possibility of saving the data to a file and pre-processing the file before sending it to Timelab.
Bob
-----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Magnus Danielson <magnus@rubidium.dyndns.org>
To: time-nuts@febo.com
Cc: magnus@rubidium.se
Sent: Sunday, October 9, 2016 10:48 AM
Subject: Re: [time-nuts] TimeLab
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@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@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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
BS
Bob Stewart
Sun, Oct 9, 2016 4:21 PM
The problem with two counters is that they will never read exactly the same. What would be better is if the TICs were able to steer the first incoming signal to start and the next to stop, and then apply a sign based on where the first pulse came from. Of course, then you have the problem of deciding whether you started the counter at the right point in time, or merely have things backward as a result of being too crafty with your hardware.
Bob
-----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Alexander Pummer <alexpcs@ieee.org>
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Sunday, October 9, 2016 11:01 AM
Subject: Re: [time-nuts] TimeLab
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@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
The problem with two counters is that they will never read exactly the same. What would be better is if the TICs were able to steer the first incoming signal to start and the next to stop, and then apply a sign based on where the first pulse came from. Of course, then you have the problem of deciding whether you started the counter at the right point in time, or merely have things backward as a result of being too crafty with your hardware.
Bob
-----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Alexander Pummer <alexpcs@ieee.org>
To: Discussion of precise time and frequency measurement <time-nuts@febo.com>
Sent: Sunday, October 9, 2016 11:01 AM
Subject: Re: [time-nuts] TimeLab
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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
BS
Bob Stewart
Sun, Oct 9, 2016 4:27 PM
Hi Bob,
Is it actually possible to address two devices on one GPIB adapter with Timelab? I admit to not reading the documentation carefully, but I've not been able to do this directly. The only way I could think of doing it was to use some software to send the data to a file and then use Timelab to pull the data from the file. Maybe NI software allows you to configure this?
Bob
-----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Bob Camp <kb8tq@n1k.org>
To: Discussion of precise time and frequency measurement time-nuts@febo.com
Sent: Sunday, October 9, 2016 8:42 AM
Subject: Re: [time-nuts] TimeLab
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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
Hi Bob,
Is it actually possible to address two devices on one GPIB adapter with Timelab? I admit to not reading the documentation carefully, but I've not been able to do this directly. The only way I could think of doing it was to use some software to send the data to a file and then use Timelab to pull the data from the file. Maybe NI software allows you to configure this?
Bob
-----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Bob Camp <kb8tq@n1k.org>
To: Discussion of precise time and frequency measurement <time-nuts@febo.com>
Sent: Sunday, October 9, 2016 8:42 AM
Subject: Re: [time-nuts] TimeLab
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@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@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@febo.com
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
A
Adrian
Sun, Oct 9, 2016 4:34 PM
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@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@febo.com
To unsubscribe, go to
https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
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@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@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@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@febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
