DMTD Tutorial

[5065AGuru]

Here is some info on the "dead-time" problem experienced when using the HP 53131/132/181A or the SR620.

I did utilize the 131A and SR620 the first couple years of DMTD use, and was able to work around this problem.

Since then I have been using purpose built counters that do not have this problem.

The first phase plot using a 131A is a of a 5065A vs a 5061B and is over 8000 Seconds long.

If you follow the phase as it slowly increases on the plot you will see the slope change (it doubles) as it approaches the wrap.

This is caused when the counter cannot finish its RS232 transmission before the next start pulse arrives.
This results in starting on every other pulse.

I isolated one section for the 2nd plot shown so you can get a better look.

If you just delete the data to the right of the point where the slope changes (which includes the wrap) you end up with a clean plot that can be processed.

We are still working on the companion counter to the simple dual mixer and it does not have this problem!

Cheers,

Corby

[5065AGuru]

Made some checks at low and high offset on the Simple Dual Mixer board.
Main conclusion is that as long as you have a decent offset oscillator you don't need to worry
too much about the noise being lower in the lower counts! On my NBS106B with its better noise floor you do see that effect!
First is a phase plot between a good FTS 1200 and a very nice HP 10811 showing the AD at low and high count sections.
The next is an AD plot of the last 7500 Sec (after the 2nd wrap)
Not too shabby!
In the next couple weeks I'll be running some tests at a lower bandwidth to see if a lower noise floor can be reached. Will share the results.

[tkamiya]

Trying to do a base line noise test and getting some weird results.

Adev graph moves wildly in diminishing oscillation pattern.  In phase shift view, I can see phase is shifting very periodically.  Looking at raw data, I can confirm this is not an artifact.  By process of elimination, so far, I found coax between TIC and DMTD is picking up the same noise.  TICC itself isn't the problem because I see the same thing on HP53132A.  What I don't know is what it is that is causing this interference.  It could be AC mains and it could be other 10MHz signals that are near by. 

I plan to move necessary parts into a different room (living room?) away from lab and see if I can reproduce it.  Last resort will be run everything off battery and do it in middle of my back yard. 

Questions for those who are already working on one.  What kind of power supply do you use for DMTD?  Internal or external?  Switching or linear?  3 terminal regulators or something more complex?

[5065AGuru]

Hi,

Here is more data on how the quality of the offset oscillator affects the performance and also
another illustration of the importance of keeping close to coincidence.
I took a well performing oscillator and injected calibrated amounts of noise and measured
how much the STS was degraded by several fixed amounts.

AD at 1Sec for indicated noise levels
 
8.65X10-13th          Zero
3.10X10-12th          62.5
5.66X10-12th          125
9.72X10-12th          250
1.36X10-11th          375
2.26X10-11th          500

Then I setup to measure the simple dual mixer noise floor with this oscillator as the offset
oscillator.

I measured the noise floor at close to coincidence and also at close to full scale at the 6
levels of noise shown.

The plot shows all 12 300 Sec. measurements with the 6 close to coincidence on the left.
As you can see close to coincidence the noise floor stays fairly constant at all noise levels.
At the midpoint we transition to the 6 close to full scale measurements.
With no noise the first section is not too bad but as the noise is increased you can clearly
see the noise levels rise up.

This should help you select what oscillator to use as your offset oscillator.

I'm currently running some oscillator to oscillator plots with the 6 noise levels and will
post those results soon.

Cheers,

Corby

[5065AGuru]

OK, here is a plot that shows the AD degradation as the offset oscillator noise increases, all plots close to coincidence.

Cheers,

Corby

[5065AGuru]

Taka,

Removing wraps automatically even in PLOTTER is problematic. I find it best to use the single step function. Although for most Quartz plots I usually just use the data up to the first wrap and ignore the rest. In this example I'd delete all the wraps just leaving the parabola. Then I'd do my AD plot on that

Here is an example of removing wraps via the single step function. (Using PLOTTER)

1st is the raw phase plot with 3 wraps of a Quartz vs a 5065A.
As I noted before you see I adjusted to start the plot with the count slowly climbing.
As the oscillator ages you will see the plot make a parabola and then wrap.

2nd is after I deleted the 3rd step.

3rd is after positioning the single marker over the 1st step and clicking on single step. As you can see it did not remove it completely.

4th is after drawing a rectangle around the area of the step. (position cursor, left click and hold while you draw the rectangle.) You now have a zoomed area around the step.

5th shows after you position the marker in the middle of the step as shown. Click on delete +- points until the step is clean and then click on single step again.

6th Shows another remaining residual step. Zoom as required and keep clicking on single step until you get no change.

7th show the final step that does not respond to the single step click. Make sure you position the marker in the middle of this final step.

8th shows the result after clicking once on the delete +- points and then clicking UnZoom.

The first wrap is now gone.

Repeat for the next wrap.

The last plot shows the unwrapped phase plot and can now be used to perform the AD plot.

At this point you can also save the unwrapped file to allow you to import it into TimeLab if desired.

Cheers,

Corby

[tkamiya]

When you say "coincident" and "coincidence" what do you mean, please?

[edpalmer42]

Another trick you can use with Plotter is to use the 'Drag Y' function to distort the data to improve the unwrapping and then remove the distortion to get a perfect unwrap.

Let's say you're looking at Corby's seventh picture above.  You've removed the step but there's still a bit of a glitch.  Instead of deleting points, click on the 'Drag Y' button.  Now, all the points are replaced by big squares.  You want the graph on the right side of the blue line to shift down so click and drag a point on the right higher.  Now do a 'Single step'.  The distortion forces the graph to drop.  Too much or too little movement?  Just adjust and repeat the 'Single step'.  Once you're satisfied, click and drag your distorted point back where it should be.

Yes, it's tedious, but sometimes it's necessary.  I've found that sometimes removing points doesn't give a perfect result.  This gives you another option.  Also, if your datafile is timestamped, Plotter won't close up the graph when you remove points.  It just jumps over the gap.  This trick retains all your data points so there are no gaps.

[tkamiya]

I will have to try PLOTTER.  I have been using TimeLab pretty much exclusively.  It's ability to graph as it records is a big plus.  Perhaps my expectation was wrong.  I wasn't aware this much data editing is necessary to get clean graphs.  I haven't heard anyone talk about it extensively like this before either.

[edpalmer42]

As the quality of your measurements and, therefore, of your data improves, your need to edit data drops, but never disappears.  I haven't used Plotter for a few years because Timelab is just too convenient.  If you've got hundreds of points per wrap, Timelab unwraps perfectly.  The only data editing needed is to remove an occasional noise glitch.  Timelab easily handles this.

But it would be really nice if Timelab included Total Deviation.  Just saying..... 

[5065AGuru]

Ed,

When you are at seventh plot and performing a single step results in no change then PLOTTER has calculated that a single delete +- points will remove the exact amount to result in no remaining "bit of a glitch" I have never seen any remaining glitch after following this procedure.

I can't remark on TimeLab unwrapping as I'm only an occasional user.

Cheers,

Corby

[tkamiya]

I've been wondering about this.

Some SMA connectors are rated for 200 to 500 screw/unscrew cycles only, if rated at all.  500 is for Amphenol's $60/piece type.  (wow....  expensive!)  I've seen 200 for common ones.  I personally have damaged threads few times with far, far, less.  As I understand it, it was originally designed for internal component connection, not an external interface.  Yet, I've seen images of NIST lab using them for latter.  I wonder about this from time to time.  I do not like BNC as I can see readings change just pushing on the connector lightly.

Has anyone in DMTD world or really anyone had their measurement error because of this?  I used N connector for this reason.  I can see myself doing 10 ocxo tests at a time and easily exceeding this rather low rating. 

Corby:
I've just aligned my second best 11801 for 10MHz + 10Hz duty.  I can't wait to get the new TIC!  I've suspended my effort to use my other counters for now.  I feel like chasing an ever moving target.

Ed:
It is odd that I'm always having wrapping problems and you don't have it or rarely.  As I understand it, most counters around year 2000 and before has this dead-time issue.   What kind of counters do you have?  I used TICC, 53132A and 5335A.

[edpalmer42]

To clarify:

The glitch remains after the *first* step removal.  Further step removals are unnecessary with my trick.  It also doesn't delete any data points - if that's important for that particular measurement.

[edpalmer42]

Taka:

I usually use a Fluke PM6681 counter.  I don't know if it has a deadtime or not - the specs are a little obscure on that point.  One thing I always do is make sure that I'm not using any averaging.  One time interval - one measurement.  Now that I think about it, I seem to remember that averaging does confuse Timelab because the averaging smears the wrap over many samples.

[tkamiya]

Does averaging even a concern in time interval measurements like we are doing?  The pulse/signal we are giving to the counter is "start" and "stop", so that there isn't anything to take average of....  As I understand it, in frequency measurements, modern reciprocal counters make hundreds of period measurements and give you the best guess answer.

I have to remind myself...  do not buy any more counters...  except for ProTic.  I already have enough counters to completely fill a full height rack.

[edpalmer42]

Does averaging even a concern in time interval measurements like we are doing?  The pulse/signal we are giving to the counter is "start" and "stop", so that there isn't anything to take average of....  As I understand it, in frequency measurements, modern reciprocal counters make hundreds of period measurements and give you the best guess answer.

If your measurement reporting interval is long enough that you could make multiple measurements your counter might do that.  If there's a wrap during a measurement interval, the counter will average the results and report a value somewhere between 0 and the maximum.  But, when I look at Corby1.txt, I don't see those intermediate values around the wraps so it doesn't look like averaging is part of your problem.

However, I do see a very significant problem in that file!

Code: [Select]

-0.957360687806 TI(A->B)
-0.963215360909 TI(A->B)
-0.969065112713 TI(A->B)
-0.000101747664 TI(A->B)
-0.005955872314 TI(A->B)
-0.011832818799 TI(A->B)
What happened to -0.975, -0.981, -0.987, and -0.993?  The data points are spaced ~ 0.006 sec. apart except for a 30 ms. gap around the wrap.  I looked at a few of the other wraps and found the same anomaly.  Care to guess what happens when I add the missing values to the file?  Spoiler - the first glitch at 238 sec. almost disappears.  If I added another digit or two I expect the glitch would completely disappear.  See the attached Frequency Difference graph.

Are you still using the HP 5335A?

[thinkfat]

That is interesting. That series was recorded with the TICC.

[tkamiya]

Thanks for finding that.  I actually tried to find the missing data, but I couldn't.

So far, I have tried TICC, HP53132A, and HP5335.  The last I tried was HP5335.  They all had similar issues except the last one being less periodic than former.  Earlier recordings were also problematic as DUT and REF frequencies were way off.  What's interesting is, in log series of data, there were only few missing.  I would've expect it'd be all over the place.  Currently, I'm not doing anything pending Corby's counter's arrival.

[5065AGuru]

Taka,

I use a stainless male to female SMA "connector saver" adaptor on the mixer inputs.
That way the wear and tear is on the sacrificial adaptor.

Cheers,

Corby

[tkamiya]

I changed the offset oscillator after noticing the original one (11801-6011) taking few cycles to cross the wrapping point.  My guess is, instability?/phase noise? in oscillator caused it to fluctuate around the wrapping that it took few cycles to complete the transition.  This may have caused algorithm in TL to become confused.  New one is from a discarded HP5071A.  (11801-60219)  Still using HP5335 with 10Hz offset.

I observed frequency difference graph looks a lot cleaner.  Original phase graph shows 15 wrappings in 20 minutes and unwrapped shows a straight line.  So far, I have observed 10 wrappingd and they all unwrapped correctly using TimeLab.  WIth the original offset oscillator, it never did.  Adev looks reasonable and as the data accumulates, there are less "whipping" effect of the graph.  There is this odd jump that looks like pulse in frequency difference graph.  I don't know what this is about.

Still watching...

[thinkfat]

Still the same issue, still not properly unwrapped. You need to switch the phase measurement to display the "linear residual" to see the jumps there. "Frequency difference" does show them.

PS: @tkamiya which firmware version are you running on the TAPR TICC? I can imagine a lot of things, but the TICC loosing measurements is not among those.

[tkamiya]

Where is Linear Residual?  I don't see such option.

[thinkfat]

Where is Linear Residual?  I don't see such option.

In the "Trace" menu, the option is called "Show linear phase/frequency residual".

[tkamiya]

This is interesting....

[thinkfat]

This is interesting....

Not unexpected, this is why you see the jumps in the frequency difference graph. They must come from somewhere and a frequency jump must have a corresponding phase change.

PS: While we're at it, "Ctrl-c" in TL will create a screenshot of the currently displayed graph and store it in the clipboard. You can "paste" it into Explorer to save it and attach it to a posting. Must be way easier than taking actual "screenshots" with a camera and downloading the photos to post them.