[time-nuts] TimeLab

Bob Stewart bob at evoria.net
Sun Oct 9 13:02:42 EDT 2016


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


   


More information about the time-nuts mailing list