FWIW, I have only tried timelab reading a live ascii log file. On Sunday, 9 October 2016, Magnus Danielson <[email protected]> wrote:
> Which removes the real-time processing benefit of using TimeLab in the > first place. > > What I propose is not too complex to do. > > Cheers, > Magnus > > On 10/09/2016 06:19 PM, Bob Stewart wrote: > >> Don't forget the possibility of saving the data to a file and >> pre-processing the file before sending it to Timelab. >> Bob >> ----------------------------------------------------------------- >> AE6RV.com >> >> GFS GPSDO list: >> groups.yahoo.com/neo/groups/GFS-GPSDOs/info >> >> From: Magnus Danielson <[email protected]> >> To: [email protected] >> Cc: [email protected] >> Sent: Sunday, October 9, 2016 10:48 AM >> Subject: Re: [time-nuts] TimeLab >> >> Hi, >> >> Well, yes. You can do some fancy stuff with additional hardware, but I >> think with already a handful of relatively simple software fixes and >> some basic setup conditions, a sufficiently robust method emerges. >> >> I could not sign-swap the measurements in TimeLab when I tried. >> I don't seem to be able to force the unwrapped phase to be +/- half cycle. >> I don't seem to be able to offset my readings. I have two sources of >> offset, one is the additional delay of cables, and the other is the >> offset due to wrong cycle (I hope this one can be baked into alternative >> phase-unwrapping mode). I would prefer if I could hit calibration to >> establish the zero-level. Typically I use a BNC barrel and well, it does >> add smoe more delay >> >> What I propose should be doable with a simple counter like 5335A, >> 53131/2A or similar. If you have a locked say 100 Hz or 1 kHz signal >> (TADD-2 can be useful if the GPSDO does not output proper signal), you >> can do the picket fence and resolve things, it is just that there is a >> few things to aid in the post-processing to make values useful. >> >> I further hint about a few things which makes easier to analyze is the >> improved support for zooming. >> >> Oh, I do care about phase variations and absolute phase measures. I do >> such measures a lot. ADEV and TDEV is not all the things I measure, >> especially when considering systematic effects. >> >> Cheers, >> Magnus >> >> On 10/09/2016 03:42 PM, Bob Camp wrote: >> >>> 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/m >>>> ailman/listinfo/time-nuts >>>> and follow the instructions there. >>>> >>> >>> _______________________________________________ >>> time-nuts mailing list -- [email protected] >>> To unsubscribe, go to https://www.febo.com/cgi-bin/m >>> ailman/listinfo/time-nuts >>> and follow the instructions there. >>> >>> _______________________________________________ >> time-nuts mailing list -- [email protected] >> To unsubscribe, go to https://www.febo.com/cgi-bin/m >> ailman/listinfo/time-nuts >> and follow the instructions there. >> >> >> >> _______________________________________________ >> time-nuts mailing list -- [email protected] >> To unsubscribe, go to https://www.febo.com/cgi-bin/m >> ailman/listinfo/time-nuts >> and follow the instructions there. >> >> _______________________________________________ > time-nuts mailing list -- [email protected] > To unsubscribe, go to https://www.febo.com/cgi-bin/m > ailman/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.
