From: Bob Camp <kb8tq@n1k.org>

 From: Bob Camp <kb8tq@n1k.org>

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 <magnus@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 <magnus@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 <kb8tq@n1k.org> >>>> To: Bob Stewart <bob@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 <bob@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@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 <magnus@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.

 From: Bob Camp <kb8tq@n1k.org>

 From: Bob Camp <kb8tq@n1k.org>

Hi, Agree. However, one need to make sure that the counter triggering never flukes a measurement. There is a few things missing to make it work much much better. Cheers, Magnus On 10/09/2016 08:35 PM, Bob Camp wrote: > 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 <magnus@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 <magnus@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 <kb8tq@n1k.org> >>>>> To: Bob Stewart <bob@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 <bob@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@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 <magnus@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. >

Hi Magnus, I run into this all the time. Some thoughts... 1) My *work-around* is to adjust the REF 1PPS by tens of microseconds, or even 500 ms. That avoids running into sign changes and skipped samples when a TIC gets near zero. This works really well for stable clocks where 500 ms drift is next to impossible. 2) My *solution* is to use time-stamping counters (TSC) instead of time interval counters (TIC). With time-stamping you avoid all the hassles of a TIC. There is no worry about CH1 vs. CH2, there are no sign changes, there are no missed samples, it doesn't matter if the sources are fast or slow, or ahead of behind. There is no concept of "start" or "stop", but only "when". For high-end TSC, I use a CNT-90 (or equiv) and for low-end I use my little picPET. It gets even more useful if you have multiple, synchronized time stamping counters. 3) The problems you are running into get far worse the less accurate and less stable the sources are (such as mains, mechanical, vintage quartz, and pendulum clocks). So that's why I developed the picPET time-stamping counter. It's 400 ns resolution is not good enough for you. Even the new 10 ns version isn't good enough for your needs. But a fellow time nut is working on a 100 ps version which will do both time stamping and time interval. That, finally, will solve the problems everyone has with TIC's. However, I still use hp 53131A/53132A a lot in my lab and simply avoid the TIC problem using #1 above. 4) TimeLab already has support for some time stamping counters -- under Acquire click on Timestamp instead of Phase or Frequency. Alternatively you can write simple tools that translate time stamp data to phase difference data or frequency data and then use TimeLab the way you usually do. The trick is to use the "Live ASCII file"input option. Also use fflush() in your C code (or equiv). That way you retain the real-time display feature that TimeLab provides. /tvb

> I didn't want to go into depth on counter design, a topic which I could > spew out much more text on, but this is not focused on the counters > themselves, but how we use them to get practical and useful data. I > would appreciate if we could stick to that topic, as I think it is a > relevant one. Practical obstacles and how we handle them. Here we have a > given counter, how do we utilize it best to get good measurements. > Also, I could dig up many counters that may solve this or that issue, > but for the given situation I'm stuck with this counter. Ok. Yes, the 53131A/53132A (and many other) counters get awkward when your signals get too near zero. There are issues of signs, of start / stop ambiguity, and missed samples due to cycle slipping. You want to avoid this. TimeLab cannot make up for random lost cycles, nor should hacks to that effect be in TimeLab, or Stable32, etc. So here's another trick when making long-term 1PPS measurements. Start with a clean 50% 1 Hz signal for your REF input instead of a typical short ~10 us 1PPS signal. As you monitor the data, when the TI numbers start to get close to zero -- you simply change the trigger edge of the REF input channel. Now you are triggering at the half-point of the REF/PPS instead of the zero-point of the REF/PPS. Later on, when the TI numbers once again drift toward zero, you flip the trigger edge again. This requires GPIB control of the counter, not its talk-only mode. You have a quarter to a half a second to send the GPIB command; very possible. When done right, your raw TI readings will always be in the range of, say, 0.25 s and 0.75 s. Your phase unwrap code will handle the 0.5 second "wraps", with no loss of precision, no loss of samples, no loss of phase. This effectively turns a 53131A/53132A into a TSC for ~1 Hz data. What you end up with is a clean set of data, with no missed samples. The occasional moments when the trigger edge is flipped are obvious within the data stream itself so your little tool that translates raw GPIB data from the TIC to clean phase or time-stamping data for TimeLab can handle the half second cycle slips with no external information. Just configure TimeLab to read Phase Difference, or Timestamp data, via live ASCII file, and you're all set. /tvb

On Sun, Oct 9, 2016 at 9:07 PM, Tom Van Baak <tvb@leapsecond.com> wrote: > 3) The problems you are running into get far worse the less accurate and > less stable the sources are (such as mains, mechanical, vintage quartz, and > pendulum clocks). So that's why I developed the picPET time-stamping > counter. It's 400 ns resolution is not good enough for you. Even the new 10 > ns version isn't good enough for your needs. > > 10ns ?

Hi Adrian, > The dead zone random jumps can not be unwrapped by any software Correct, the dead zones are real. But it is *not* true that the jumps cannot be unwrapped by any software. Let me explain... When I collect data from an instrument, from thermometer to TIC, over RS-232 or GPIB or USB or LAN, I log the data to a file and prefix every line with a 9 decimal place MJD timestamp. This not only allows me to know when (historically) the data was collected, but by subtracting timestamp pairs, it also tells me how long each measurement took. For frequency measurements, this allows you to determine counter dead time. For time interval measurements, this allows you to immediately detect when the counter goes into the dreaded too-close-to-zero sample skip mode. That is, when start/stop acts more like stop/start resulting in one reading every 2 seconds instead of every 1 second. Right, it is impossible to retroactively re-measure the lost samples -- but by knowing when the sample rate is 1 sps vs. 2 sps you can reconstruct a valid phase data stream with constant tau, even with simple 2 sample interpolation. The result is that this repaired/fixed data is then perfectly usable for phase and frequency strip charts, as well as ADEV plots, and even FFT. Without this fix, all these plots can behave very badly because the universal assumption of some fixed tau0 has been violated. The PC MJD (or equiv) timestamp does not need to be absolutely accurate. That is, you don't need NTP or anything like that. Just 0.1 or 0.01 second resolution is all you need. So this works on any microcontroller, or computer running any operating system, with or without internet connection. If you don't like MJD, even something like the old unix clock() function is enough to disambiguate 2 sps from 1 sps. But the key point is never just blindly log plain serial data and then cry later. Always time-stamp or time-interval it as it is being read and written to a log file. /tvb ----- Original Message ----- From: "Adrian" <rfnuts@arcor.de> To: "Discussion of precise time and frequency measurement" <time-nuts@febo.com> Sent: Sunday, October 09, 2016 9:34 AM Subject: Re: [time-nuts] TimeLab Hi Magnus, unfortunately, you can't measure 0 delay between two signals with a counter. With a 53131A, there is 500ps of LSB jitter and jitter from the measured signal as well as from the reference signal. When both signals are exactly in phase, the counter will randomly jump between 0 and 1 second (assuming you are measuring 1pps signals). In order to avoid this dead zone, you must add a sufficiently large phase offset between both signals. And, keep the acquisition time small enough to avoid phase wraps due to drift between both sources. The dead zone random jumps can not be unwrapped by any software. Cheers, Adrian

{AB}* fine...

{AB}*B{AB}*  lost one from A

{AB}*A{AB}*  lost one from B

-------- In message <0f6c1eb7-18cb-06e3-48dd-6cd618f19575@rubidium.dyndns.org>, Magnus D anielson writes: >This is why the two-counter setup is so messy, you have to have software >that will sync up and query them alternatively. It is not that bad messy. Counter A Start=DUT, Stop=REF Counter B Start=DUT, Stop=REF + half period [1] Now you know that at least one counter will always measure a DUT flank. The crucial detail is that you also know that the counters will not spit out their result at the same time, so timestamping the measurements on the computer will definitively sort them into order[2]. I always run separate programs/scripts for each counter outputting into separate files, but that's a matter of temperatment. You end up with a reliable sequence with three possible scenarios: {AB}* fine... {AB}*B{AB}* lost one from A {AB}*A{AB}* lost one from B And it is trivial to insert markers for the missing measurements. In addition you end up with two entirely separate series of measurements which you can compare for sanity, and if they look good, you combine them and reduce your noise by sqrt(2) Poul-Henning [1] PPSDIV gives nice symmetrical PPS, just trigger opposite flank. [2] Obviously: Do not use a computer running a weather model for this -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Poul-Henning, The key to your dual counter proposal is the half-period delay. Consider these variations: 1) Use the GPIB "change-flank-on-the-fly" trick I mentioned yesterday. Only one counter is necessary. The symmetrical (50.000000% duty cycle) output of the PPSDIV is useful here too. 2) Use one counter with 2PPS instead of 1PPS as the stop channel REF. That way the TI readings will always be a number ranging from 0 to 500 ms, or depending on the counter, something more like -20 ns to 500ms-20ns. Regardless, the software that is processing the raw TI data can resolve the 0.5 s wrapping. The main feature is that every 1PPS from DUT gets measured. That is, you eliminate the case that we're all trying to avoid where the sample rate jumps from one per second to one per 2 seconds as you enter the region where the TI is too close to 0. With a 10 MHz reference, anyone with a TADD-2 (board or mini) can set the input jumper from 10 MHz to 5 MHz. Then the "1PPS" output becomes 2PPS. 3) Looking at my various PICDIV I see there's a way to program a 5/10 MHz -> 1PPS divider so that the user can step the phase of the output by, say +/-500.000 000 ms. So the idea is that the PC program reading the TI data from the counter stays content as long as the TI readings are within a range of say 200 ms to 800 ms. If the TI values slowly drift outside that range it tells the PICDIV to advance or retard the divider once by exactly 0.500 000 000 s. The beauty of this approach is that: - you only need one counter, - the counter may run in talk-only mode (no need for GPIB), - the counter never operates anywhere near the TI = 0 point, - no DUT readings are ever lost, - your software (or TimeLab) can easily resolve the wrapping when it sees the 500 ms phase jumps, - the PICDIV advance/retard pins can be driven by a PC serial port DTR/RTS lines, - the output of the program that gets TI readings and issues the occasional step commands to the PIC can output wrapped phase, or unwrapped phase, or timestamps as the user wishes. TimeLab accepts all three. /tvb ----- Original Message ----- From: "Poul-Henning Kamp" <phk@phk.freebsd.dk> To: "Discussion of precise time and frequency measurement" <time-nuts@febo.com>; "Magnus Danielson" <magnus@rubidium.dyndns.org> Cc: <magnus@rubidium.se> Sent: Sunday, October 09, 2016 11:22 PM Subject: Re: [time-nuts] TimeLab > -------- > In message <0f6c1eb7-18cb-06e3-48dd-6cd618f19575@rubidium.dyndns.org>, Magnus D > anielson writes: > >>This is why the two-counter setup is so messy, you have to have software >>that will sync up and query them alternatively. > > It is not that bad messy. > > Counter A Start=DUT, Stop=REF > > Counter B Start=DUT, Stop=REF + half period [1] > > Now you know that at least one counter will always measure a DUT flank. > > The crucial detail is that you also know that the counters will not > spit out their result at the same time, so timestamping the > measurements on the computer will definitively sort them into > order[2]. > > I always run separate programs/scripts for each counter outputting > into separate files, but that's a matter of temperatment. > > You end up with a reliable sequence with three possible scenarios: > > {AB}* fine... > > {AB}*B{AB}* lost one from A > > {AB}*A{AB}* lost one from B > > And it is trivial to insert markers for the missing measurements. > > In addition you end up with two entirely separate series of > measurements which you can compare for sanity, and if they look > good, you combine them and reduce your noise by sqrt(2) > > Poul-Henning > > [1] PPSDIV gives nice symmetrical PPS, just trigger opposite flank. > > [2] Obviously: Do not use a computer running a weather model for this > > -- > Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 > phk@FreeBSD.ORG | TCP/IP since RFC 956 > FreeBSD committer | BSD since 4.3-tahoe > Never attribute to malice what can adequately be explained by incompetence. > _______________________________________________ > 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.

-------- In message <74DC70F096704AF8958028919BE7688A@pc52>, "Tom Van Baak" writes: >The key to your dual counter proposal is the half-period delay. >Consider these variations: Yes, running 2Hz STOP will also work, with the footnote that you still need to resolve the 2Hz ambiguity, which admittedly is easier. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.

Hi Magnus, two questions for you: > I can shift the phase of the DUT intentionally, but if so I want to be > able to compensate that shift in the software. Now, such a shift should > be kept separate from the calibration factors which fills a different > purpose. If you can shift the DUT phase, you're all set. No need for most of the most of the discussion going on, right? What is the frequency error or stability of the DUT? A 500 ms shift should provide days to years of time before you'd hit the TIC zero. > The trick that I then apply is to use a stop signal of higher frequency, > but who's rising edge matches that of the PPS on the PPS occurence, and > then let my DUT signal PPS be the start signal, as that will then > defined the tau-rate. With a 100 Hz signal I now have 10 ms period and > then from the last stop-time I have 990 ms for the counter to re-arm the > start-channel, and thus hide the dead-time. This is the picket fence > approach rather than having alternate counters to cover up each others > dead-time. I've tried this. In general the picket fence method has no effect on you hitting the awkward region near 0 ns where the TIC waffles between - and +. In fact, a 100 Hz picket fence just means you will run into the TIC dead zone 100 times more often, but the effect the dead zone will be 100x less. To me this suggests that 2 Hz is all that is necessary, as PHK and I have mentioned. I almost hesitate to call 2 Hz a picket fence. Or are we missing something? Is there some advantage to 10 Hz or 100 Hz over 2 Hz? It seems to me they all solve the problem where the counter start/stop accidentally gets turned into stop/start near the 0 ns region, which leads to sampling every 2 seconds instead of every 1 second for a while. /tvb