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 <[email protected]>
To: Bob Stewart <[email protected]>; Discussion of precise time and frequency
measurement <[email protected]>
Sent: Sunday, October 9, 2016 11:50 AM
Subject: Re: [time-nuts] TimeLab
Hi
> On Oct 9, 2016, at 12:27 PM, Bob Stewart <[email protected]> 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 <[email protected]>
> To: Discussion of precise time and frequency measurement <[email protected]>
> 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 <[email protected]>
>> wrote:
>>
>> Fellow time-nuts,
>>
>> I don't know if it is me who is lazy to not figure TimeLab out better or if
>> it is room for improvements. I was considering writing this directly to
>> John, but I gather that it might be of general concern for many, so I
>> thought it be a good topic for the list.
>>
>> In one setup I have, I need to measure the offset of the PPS as I upset the
>> system under test. The counter I'm using is a HP53131A, and I use the
>> time-interval measure. I have a reference GPS (several actually) which can
>> output PPS, 10 MHz, IRIG-B004 etc. In itself nothing strange.
>>
>> In the ideal world of things, I would hook the DUT PPS to the Start (Ch1)
>> and the reference PPS to the Stop (Ch2) channels. This would give me the
>> propper Time Error (DUT - Ref) so a positive number tells me the DUT is
>> ahead of the reference and a negative number tells me that the DUT is behind
>> the reference.
>>
>> Now, as I do that, depending on their relative timing I might skip samples,
>> since the counter expects trigger conditions. While TimeLab can correct for
>> the period offset, it can't reproduce missed samples.
>> I always get suspicious when the time in the program and the time in real
>> world does not match up.
>>
>> I could intentionally shift the PPS output of my DUT to any suitable number,
>> which would be one way to solve this, if I would tell TimeLab to withdraw
>> say 100 ms. I might want to do that easily afterhand rather than in the
>> setup window.
>>
>> To overcome this, I use the IRIG-B004 output, which is a 100 Hz signal with
>> a stable rising edge aligned to the PPS to within about 2 ns. Good enough
>> for my purpose. However, for the trigger to only produce meaningful results,
>> I will need to swap inputs, so that the PPS from DUT is on Start/Ch1 and the
>> IRIG-B is on Stop/Ch2. This way I get my triggers right. However, my
>> readings have opposite sign. I might have forgotten about the way to correct
>> for it.
>>
>> However, TimeLab seems unable to unwrap the phase properly, so if I have the
>> condition where I would get a negative value of say -100 ns then the counter
>> will measure 9,999,900 ns, so I have to force a positive value as I start
>> the measurement and then have it trace into the negative. I would very much
>> like to see that TimeLab would phase-unwrap into +/- period/2 from first
>> sample. That would be much more useful.
>>
>> I would also like to have the ability to set an offset from which the
>> current zoom window use as 0, really a form variant of the 0-base but
>> letting me either set the value or it be the first value of the zoom. I have
>> use for both of these. I often find myself fighting the offset issues. In a
>> similar fashion, I have been unable to change the vertical zoom, if I don't
>> care about clipping the signal then it forces me to zoom in further than I
>> like to. The autoscale fights me many times in a fashion I don't like.
>>
>> OK, so there is a brain-dump of the last couple of weeks on and off
>> measurement experiences. While a few things might be fixed in the usage, I
>> wonder if there is not room for improvements in the tool. I thought it
>> better to describe what I do and why, so that the context is given.
>>
>> Cheers,
>> Magnus
>> _______________________________________________
>> time-nuts mailing list -- [email protected]
>> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
>> and follow the instructions there.
>
> _______________________________________________
> time-nuts mailing list -- [email protected]
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
>
> _______________________________________________
> time-nuts mailing list -- [email protected]
> To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
