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 <mag...@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 <mag...@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 <kb...@n1k.org> >>>> To: Bob Stewart <b...@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 <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? >>>> >>>> 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 <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. >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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. >> > _______________________________________________ > 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.
