Hi Tom, On 10/10/2016 11:49 AM, Tom Van Baak wrote: > 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. Go back and read my original posting as well as fairly early follow-up posting. I have a locked system, I can move the phase in this case, but I need the assistance of the post-processing to get the zero offset values presented properly, and I heavily use the real-time display. Similarly, I propose improved processing through simple shift of sign and phase-unwrapping focused around zero. Notice that there can be different offsets of different origins, and one want to set them independently for ease of use. For the case at hand, any through zero sample skip is a rare case but the negative sample skip dominates. >> 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. As I said, the through-zero problems are much less of an issue. The 100 Hz was free and available, 2 Hz or 10 Hz would also do the trick, so don't hang up on the frequency as it is more to illustrate the setup I did. > 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. As long as you have an integer multiple, you're all fine. It's really what is handy which is important and preferably the period should be shorter than the dead-time, but as long as the software can compensate for multiple skipped periods we don't care about that either. Remember, I'm measuring phase and trying to measure deviation from "absolute phase". I want my view to be as unbiased as possible. This is different from just trying to make stability measures. I'm trying to illustrate the measurement challenges and then propose some enhancements to TimeLab that will help immensely to provide good values. Much of this thread ended up covering gazillions of other cases, including "use this counter instead". Cheers, Magnus

Hi Tom, On 10/09/2016 10:07 PM, Tom Van Baak wrote: > 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. Well, that is one option. However, as I care about where my zero line is, it's annoying to operate in TimeLab. The main problem I try to illustrate is the shift from tau = 1 s to tau = 2 s, which can be a dominant case (say 50% of all samples) while the through zero is annoying, but is more in the neighborhood of below 1 % of all samples. > 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. If all the counters we lay out hands on where capable of it, then no question about it. I made the distinct case that we are not always fortunate to have such counter available, and still want to make decent enought measurements. I wanted to both explain the problem, show the wiring setup and then propose minor software changes to make it much easier to use. If I where to use any counter in my private setup, then things would quickly become much simpler. I intentionally stepped out of that case and illustrated the hurdles of a fairly common clock. > 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. I intentionally steered clear from build another devise. Naturally, if a sufficiently good and price-worthy one would be easily available, it would remove much of the worries. Until then, lest than ideal hardware and then try to use some additional signals and some software to make things behave sufficiently good. > 4) TimeLab already has support for some time stamping counters -- under Acquire click on Timestamp instead of Phase or Frequency. I know, but it does not really help with the given conditions. Think of the cases where a guy just got his first TIC like HP5335A or HP53131A, or for that matter, one is laying around unused and can be put into use. I found that the PM6654C to be quite accurate for some measurements, even if I have better counters available. What I try to achieve is more practical measures rather than more ultimate measures. Where good enough has cleared of some issues, but give good enough details and read-outs. I can then run my highly specialized rig separately. > 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. Translating externally to TimeLab is certainly a possibility, but I propose these improvements into TimeLab as I think they are not all that complex and I think many will benefit from them. Giftwrapping of commonly reoccurring problems. Cheers, Magnus