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.
