Re: [time-nuts] TimeLab
You guys never give up, happy Sunday
In a message dated 10/9/2016 2:46:02 P.M. Eastern Daylight Time,
magnus@rubidium.se writes:
Hi,
Agree. However, one need to make sure that the counter triggering never
flukes a measurement.
There is a few things missing to make it work much much better.
Cheers,
Magnus
On 10/09/2016 08:35 PM, Bob Camp wrote:
Hi
I understand the “keep it simple” concept, even if I rarely practice it
:)
I would indeed like to get time tagging of phase measurements better
integrated with some of these
tools. The whole “was that a dropout in the signal or a counter issue”
thing is rarely handled in a
very good fashion. It also just happens to be a pretty good addition to
a comb measurement system
as well.
Bob
On Oct 9, 2016, at 1:33 PM, Magnus Danielson
magnus@rubidium.dyndns.org wrote:
Hi Bob,
There is so many things that could be done differently if we started
with a clean sheet. I was intentionally not going down that road but more
thinking about practical setups with the stuff we have, or very small
additions.
Cheers,
Magnus
On 10/09/2016 07:26 PM, Bob Camp wrote:
Hi
On Oct 9, 2016, at 1:22 PM, Magnus Danielson
magnus@rubidium.dyndns.org wrote:
Hi Bob and Bob,
This is why the two-counter setup is so messy, you have to have
software that will sync up and query them alternatively. You also need to make
sure you get the counters to trigger. Besides, another issue is that
difference in the two counters read-outs will cause a false signal, so calibration
and compensation becomes important to remove that.
That’s why I believe the time tagger + counter is the better solution
rather than multiple counters. Let it give you the global information and
then use it to sort out what you see from the counter. Yes, a full blown
multi channel time tagger with picosecond resolution would be better still.
That’s going to cost more than $5….
Bob
Using a picket fence type of triggering approach is cheaper and
easier to maintain. Some mild software support for the processing and it will
work like a charm. Calibration for true zero offset is needed, but relatively
easy to implement, you want that anyway.
Cheers,
Magnus
On 10/09/2016 07:02 PM, Bob Stewart wrote:
Hi Bob,
I had actually thought about making a server for the Prologix
Ethernet adapters, but I gave up when I considered the issue of two processes
trying to claim the same device. I've experimented with using a C program to
capture multiple GPIB ports to a live file. But, I can't figure out how to
get the "live" part to work when running Timelab on a Windows client in a
Virtual Box under a Linux server that is collecting the data. I think
Santa may have to bring me another GPIB adapter this Christmas.
Bob
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Bob Camp kb8tq@n1k.org
To: Bob Stewart bob@evoria.net; Discussion of precise time and
frequency measurement time-nuts@febo.com
Sent: Sunday, October 9, 2016 11:50 AM
Subject: Re: [time-nuts] TimeLab
Hi
On Oct 9, 2016, at 12:27 PM, Bob Stewart bob@evoria.net wrote:
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?
That was my poorly stated point :) … you would have to add the
ability to identify and address multiple devices.
Bob
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
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.
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
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.
That's easy, Magnus. Do not use a Fluke counter :-)
Don
On 2016-10-09 13:02, KA2WEU--- via time-nuts wrote:
You guys never give up, happy Sunday
In a message dated 10/9/2016 2:46:02 P.M. Eastern Daylight Time,
magnus@rubidium.se writes:
Hi,
Agree. However, one need to make sure that the counter triggering
never
flukes a measurement.
There is a few things missing to make it work much much better.
Cheers,
Magnus
On 10/09/2016 08:35 PM, Bob Camp wrote:
Hi
I understand the “keep it simple” concept, even if I rarely practice
it
:)
I would indeed like to get time tagging of phase measurements better
integrated with some of these
tools. The whole “was that a dropout in the signal or a counter
issue”
thing is rarely handled in a
very good fashion. It also just happens to be a pretty good addition
to
a comb measurement system
as well.
Bob
On Oct 9, 2016, at 1:33 PM, Magnus Danielson
magnus@rubidium.dyndns.org wrote:
Hi Bob,
There is so many things that could be done differently if we started
with a clean sheet. I was intentionally not going down that road but
more
thinking about practical setups with the stuff we have, or very small
additions.
Cheers,
Magnus
On 10/09/2016 07:26 PM, Bob Camp wrote:
Hi
On Oct 9, 2016, at 1:22 PM, Magnus Danielson
magnus@rubidium.dyndns.org wrote:
Hi Bob and Bob,
This is why the two-counter setup is so messy, you have to have
software that will sync up and query them alternatively. You also need
to make
sure you get the counters to trigger. Besides, another issue is that
difference in the two counters read-outs will cause a false signal,
so calibration
and compensation becomes important to remove that.
That’s why I believe the time tagger + counter is the better
solution
rather than multiple counters. Let it give you the global information
and
then use it to sort out what you see from the counter. Yes, a full
blown
multi channel time tagger with picosecond resolution would be better
still.
That’s going to cost more than $5….
Bob
Using a picket fence type of triggering approach is cheaper and
easier to maintain. Some mild software support for the processing and
it will
work like a charm. Calibration for true zero offset is needed, but
relatively
easy to implement, you want that anyway.
Cheers,
Magnus
On 10/09/2016 07:02 PM, Bob Stewart wrote:
Hi Bob,
I had actually thought about making a server for the Prologix
Ethernet adapters, but I gave up when I considered the issue of two
processes
trying to claim the same device. I've experimented with using a C
program to
capture multiple GPIB ports to a live file. But, I can't figure out
how to
get the "live" part to work when running Timelab on a Windows client
in a
Virtual Box under a Linux server that is collecting the data. I think
Santa may have to bring me another GPIB adapter this Christmas.
Bob
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Bob Camp kb8tq@n1k.org
To: Bob Stewart bob@evoria.net; Discussion of precise time and
frequency measurement time-nuts@febo.com
Sent: Sunday, October 9, 2016 11:50 AM
Subject: Re: [time-nuts] TimeLab
Hi
On Oct 9, 2016, at 12:27 PM, Bob Stewart bob@evoria.net
wrote:
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?
That was my poorly stated point :) … you would have to add the
ability to identify and address multiple devices.
Bob
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
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.
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
and follow the instructions there.
time-nuts mailing list -- time-nuts@febo.com
To unsubscribe, go to
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.
--
Dr. Don Latham
PO Box 404, Frenchtown, MT, 59834
VOX: 406-626-4304