Here's how the data from corby1.txt looks in TimeLab:
![](http://www.ke5fx.com/tl1.png)
This is the original wrapped phase data ('w') view of corby1.txt, which I imported as follows:
![](http://www.ke5fx.com/tl5.png)
With those import settings, TimeLab will unwrap the phase automatically. Pressing 'p' shows this view of the data:
![](http://www.ke5fx.com/tl2.png)
As you (Corby) note, this is a frequency error of 6E-10, which should be OK. There is normally no need to avoid phase wrap, as long as it happens slowly enough to obey the usual Nyquist limit. (If you want to eliminate all relative drift between the reference and DUT, you should use a tight PLL rather than a DMTD!) It's necessary to look at the residual ('r') to see the fine details:
![](http://www.ke5fx.com/tl4.png)
Or differentiate it, by looking at the effect in the frequency ('f') difference view:
![](http://www.ke5fx.com/tl6.png)
The question I have is, where is the 2ns sawtooth coming from? The 2ns resolution of the counter should be swamped by a factor of 1E7, taking it out of the picture entirely, but for some reason we still see this 2 ns glitch every couple of minutes when the phase wrap occurs. If I zoom in on each of those spikes in the frequency-difference view and remove it with F4, I get a more believable result:
![](http://www.ke5fx.com/tl8.png)
Hitting 'z' to position the trace for viewing at a zero baseline:
![](http://www.ke5fx.com/tl9.png)
The phase drift now looks like
this, compared to the
original data:
![](http://www.ke5fx.com/tlc2.png)
Again, a perfectly-reasonable display of two decent 10 MHz oscillators being compared to each other. ADEV now looks like this:
![](http://www.ke5fx.com/tlb.png)
Once again, very believable. But what's up with those spikes at the wrap point? They shouldn't be there, unless the counter has a bug or calibration issue, or I'm overlooking something about how the DMTD works.