On Oct 9, 2016, at 12:27 PM, Bob Stewart <b...@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?
Bob
-----------------------------------------------------------------
AE6RV.com
GFS GPSDO list:
groups.yahoo.com/neo/groups/GFS-GPSDOs/info
From: Bob Camp <kb...@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 <mag...@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.
