DMTD board

[tkamiya]

That worked as well as far as wrapping is concerned.

The Adev graph looks unreasonable though.  Dropping down to 5E-12 at 0.5 second.  Rising there after.  I expected somewhat flat response to 10 second or more.

Light blue trace is what I said before you that worked.
Brown trace is your latest response.

[tkamiya]

Thank you, John.  It's 2am now.  I'll try the same with TICC tomorrow.

Thank you for all of your help.  Great big THANKS!

[KE5FX]

No prob.  5E-12 @ t=0.1s is actually quite reasonable, because your measurement floor will likely get (much) worse at short-term taus below 1s. 

In general, nothing involving 1E8 or 1E-8 should be present, though.  Your heterodyne factor is 1E6 (10 MHz / 10 Hz), so that's what you would want to scale your phase data by in order for the data to make sense with the 10 MHz (1E7) nominal frequency.  (Be sure to enter 0.1 Hz as your sample interval, of course, rather than 1 Hz.)

[tkamiya]

I have scale factor at MINUS -6, such as 1E-6.  Is that what you meant? (you said 1E6)

Input frequency is 1E6 Hz
Sampling interval is 0.1second

[thinkfat]

I'm afraid the unwrapping code in TimeLab is too primitive. It heavily depends on "full_cycle_period_secs" being very, very accurate. If it isn't, you get a jump in phase at every wrap.

I don't know exactly what goes into the calculation of this variable, but I can import the original corby1.txt properly if I play with the "input frequency" in the import dialog. If I set it to 10.257e6, the file is imported properly. Resulting ADEV attached.

I'd be very suprised if there was such inconsistency in time intervals measured with the TAPR TICC. As I said, it's a timestamping counter and by design cannot be affected by start/stop ordering problems occuring near phase wrap. If there was an inconsistency, it'd have to be in the numeric library. Not likely for something as simple as a subtraction.

[KE5FX]

I have scale factor at MINUS -6, such as 1E-6.  Is that what you meant? (you said 1E6)

Input frequency is 1E6 Hz
Sampling interval is 0.1second

No, your input frequency would be 10E6 (10 MHz).  Since it's 10 Hz in reality, you would enter 1E-6 to scale the readings back by 1000000:1.

I'm afraid the unwrapping code in TimeLab is too primitive. It heavily depends on "full_cycle_period_secs" being very, very accurate. If it isn't, you get a jump in phase at every wrap.

Yes and no.  The unwrapping algorithm is meant to operate on the count, not the period.  If I'm doing a conventional STOP-START measurement between two 10 MHz sources, such that the TI readings can never exceed 100 ns, then a difference between successive readings that exceeds 50 ns indicates that a rollover occurred.  In that case, the reading is still correct modulo 100 ns.  The "phase unwrapper" is simply implementing a carry or borrow operation, adding more MSDs to the count.  It was intended to handle this case, and that's about it.  For the intended use case it's well below the noise floor of most counters. 

If I use a 5370B to compare two sources that are close to 10 MHz, for example, the unwrapper works well, or at least well enough.  I don't get a 2-ns error at the nominal 100-ns wrap points until I specify an input frequency that's 200 kHz off, i.e., 10.2 or 9.8 MHz.  That makes sense, considering that 1/10.2E6 or 1/9.8E6 is roughly 98 or 102 ns. 

So, thinking about it this way, it's not surprising that wrap errors that ordinarily don't show up in a straightforward TI measurement are suddenly a problem with a DMTD.  After all the whole idea is to magnify any phase-difference errors to measure them on a counter that normally doesn't have the required resolution.  What to do about it is a different question, of course.   An exercise for the proverbial student.

I'd be very suprised if there was such inconsistency in time intervals measured with the TAPR TICC. As I said, it's a timestamping counter and by design cannot be affected by start/stop ordering problems occuring near phase wrap. If there was an inconsistency, it'd have to be in the numeric library. Not likely for something as simple as a subtraction.

Yep, agreed.

[tkamiya]

It was late.  I meant 10E6 for input frequency.  Thanks again for staying up for me last night.

I learned also, unwrapping is an actively researched subject.  I found two PhD thesis on this.  In areas like geo-spatal imaging, MRI, and radar, all involves unwrapping.  I was reading it's easy to do at first but when we consider all the corner cases and what-ifs of real implementation, it suddenly get complicated. 

One thing I've noted.  I may have a reflection problem somewhere between counter input and DMTD output.  Every now and then, LED on A input flickers one too many time as B does - which should not happen.  It is possible that signal is reflecting and higher instantaneous voltage may be triggering A port every now and then.

I really don't care what counter - as long as it works.  I'm pretty happy to have it working on HP5335.  Once I have a solid foundation, I can start to improve.

John,
TimeLab is not open sourced, correct?  I'd love to be able to look at the actual code.

[tkamiya]

Retried TICC again with the same setup.

Wrapping issue still exists.  It does not unwrap. 

[thinkfat]

Retried TICC again with the same setup.

Wrapping issue still exists.  It does not unwrap.

I'm afraid the unwrapping code in TimeLab is too primitive. It heavily depends on "full_cycle_period_secs" being very, very accurate. If it isn't, you get a jump in phase at every wrap.

I don't know exactly what goes into the calculation of this variable, but I can import the original corby1.txt properly if I play with the "input frequency" in the import dialog. If I set it to 10.257e6, the file is imported properly. Resulting ADEV attached.

I'd be very suprised if there was such inconsistency in time intervals measured with the TAPR TICC. As I said, it's a timestamping counter and by design cannot be affected by start/stop ordering problems occuring near phase wrap. If there was an inconsistency, it'd have to be in the numeric library. Not likely for something as simple as a subtraction.

Try it. It takes a while to figure out the correct value, but it can be done. Just modify "Input Frequency" on import, try a few times and watch the "frequency difference" display, eventually the spikes will disappear.

[tkamiya]

I'll have to manually perform unwrapping to understand this.  What is odd is, last night's experiment with HP5335 had few wraps.  It worked correctly.  Original and unwrapped screen showed respective versions.  Frequency display was devoid of peaks.  This morning, I noticed original and unwrapped graphs are identical showing UNWRAPPED graphs.   Since I wasn't paying attention to yesterday's work, I don't know when that changed.  Possibly when new acquisition was started this morning.

There is something going on that I am missing entirely.  It may not be the calculation.  I'll repeat the experiment and see if I can recreate it.

[notfaded1]

Question do these looks close enough to try?  I'm going to do it soon anyhow but I spent a LOT of time getting the Offset Oscillator stable at the right stability over decent amount of time 8 hours.  You can see my work in the last three plots working on getting stable Offset Osc.  I hope I'm close enough get some decent data.

Regards,

Bill

[tkamiya]

What are you doing?  Noise floor test?

[notfaded1]

No these are measurements of the three Oscillators directly against the 5061B over 8 hours each and the offset 3 times while tuning it.  I'm pretty excited to see them through the DMTD next.  I was trying to get them all stable over decent amount of time without drifting all over.  This took me many days and many 8 hour sessions to finally get it where setting the wheels and letting it stabilize then running it for 8 hours would be consistent and close to frequency I'm looking for.

Bill

[tkamiya]

They don't look right.  Adev curb is rarely straight like that.  You should have an initial value, go lower, keep at certain level for a while before going up.  Why are intervals 2.5 seconds?  If offset is 1Hz, you should be able to read every second. 

I'm doing 10Hz offset and reading every 1/10 second. 

You have HP5061?  You have lots of neat toys.  Best oscillator I have is an old and worn out Cesium.  It still locks but how well it's working, I have no ways to know.

[notfaded1]

They don't look right.  Adev curb is rarely straight like that.  You should have an initial value, go lower, keep at certain level for a while before going up.  Why are intervals 2.5 seconds?  If offset is 1Hz, you should be able to read every second. 

I'm doing 10Hz offset and reading every 1/10 second. 

You have HP5061?  You have lots of neat toys.  Best oscillator I have is an old and worn out Cesium.  It still locks but how well it's working, I have no ways to know.

On the 53132A you can't get 12 digits of resolution without the longer sample interval... it'll cut off the digits of precision.  Believe me if I don't let them settle first after making voltage control changes they will curve a LOT more at first.  I've spent a lot of time and patience working on these.  You can see how the #2 unit after adjusting at first it wanted to curve back up right away.  It took me weeks to get them to this point.  The nice thing about the 1050A's are the wheels for adjusting the control voltage.  The wheels adjust like this:

Switch #
1   4 x 10^-12
2   4 x 10^-11
3   4 x 10^-10
4   4 x 10^ -9
5   4 x 10^ -8

Bill

[tkamiya]

Right.  But you don't need that many digits.  If you do 1 second gate time, you'll get as good as it'll ever do.  I don't know what the optimal value is, but this is DMTD, so 12th digit, if you have it, represents like 10E-18 or some ridiculous value. 

Are you reading frequency or are you reading time interval?  You should be setting it to have port 1 to start, and port 2 to stop. 

[notfaded1]

This isn't through the DMTD yet.  It's just the 3 LO's against the 5061B so I wanted the 12 digits to see how close I was getting.  The tweaking I was doing in the last two digits.  I'm hoping to then run these 3 through the DMTD next with the offset and two others here.

Bill

[tkamiya]

Oh, I misunderstood.  Apologies.

[edpalmer42]

I don't know exactly what goes into the calculation of this variable, but I can import the original corby1.txt properly if I play with the "input frequency" in the import dialog. If I set it to 10.257e6, the file is imported properly. Resulting ADEV attached.

And the tolerance on that value is quite tight.  10.250e6 is too little and 10.260e6 is too much.  Both result in spikes.

I've seen this issue in the past.  It tends to show up when the number of data points per wrap is low.  When the number of points is high, everything works.  I suspected it was caused by Timelab having difficulty determining exactly when the wrap points occurred.

I never considered it to be a 'bug' but rather a 'limitation'.  As the quality of my equipment and measurements increased the issue disappeared and I haven't seen it for years.

[thinkfat]

I don't know exactly what goes into the calculation of this variable, but I can import the original corby1.txt properly if I play with the "input frequency" in the import dialog. If I set it to 10.257e6, the file is imported properly. Resulting ADEV attached.

And the tolerance on that value is quite tight.  10.250e6 is too little and 10.260e6 is too much.  Both result in spikes.

I've seen this issue in the past.  It tends to show up when the number of data points per wrap is low.  When the number of points is high, everything works.  I suspected it was caused by Timelab having difficulty determining exactly when the wrap points occurred.

I never considered it to be a 'bug' but rather a 'limitation'.  As the quality of my equipment and measurements increased the issue disappeared and I haven't seen it for years.

Naturally, if you have few datapoints per cycle you have few samples around the wrapping point. This makes it more difficult to pinpoint it. But what I see when importing corby1.txt is a different issue, the wrap is detected quite well but the cycle period is waaay off. I guess TL doesn't even attempt to find the proper cycle period, it just uses the input frequency from the import dialog.

It could be done, though. One method could be to find the wrapping point, then differentiate over some 10 samples around it and adjust the cycle period by searching for minimum standard deviation. I've used this method for finding an optimal value for the ominous "time dilation" parameter in the TAPR TICC configuration.

[tkamiya]

That's what John said.  One thing about TICC data is that it takes two rows of data to complete the transition.  Appears unwarpping code gets confused about that.  It takes one point to unwrap it and leave the other one in place.  That becomes the deep null.  I can try to find the cycle but the problem is, this is not usable for measuring.  I'm going to use HP5335A that just works.  I may try to make DIY counter as well.  I want my whole setup in one package for ease of use. 

How's yours coming along?

[tkamiya]

I'm kind of wondering about DMTD.

Now we have Corby's DMTD and some of us have it working, what can we do to move this forward?  Improve noise floor?  Make low pass filter adjustable?  What determines DMTD's performance, anyway?  I personally have a plan to make this a "one box" solution.  Package DMTD, TICC, and an adjustable hetrodyne local source.  All I need in addition is reference source and a computer.  For the local source, I am going to use 11801-6011 and have a switchable EFC control that are preset to 1Hz, 5Hz, 10Hz, and external.  For switching, mercury wetted relays will be switch controlled.  I am also wondering if I can pack a small PC and CRT into discarded oscilloscope case and make it truly a one box solution.  I have a few TINY version of Lenovo PC, and small LCD displays.

Ideas anyone?

[jpb]

I'm kind of wondering about DMTD.

Now we have Corby's DMTD and some of us have it working, what can we do to move this forward?  Improve noise floor?  Make low pass filter adjustable?  What determines DMTD's performance, anyway?  I personally have a plan to make this a "one box" solution.  Package DMTD, TICC, and an adjustable hetrodyne local source.  All I need in addition is reference source and a computer.  For the local source, I am going to use 11801-6011 and have a switchable EFC control that are preset to 1Hz, 5Hz, 10Hz, and external.  For switching, mercury wetted relays will be switch controlled.  I am also wondering if I can pack a small PC and CRT into discarded oscilloscope case and make it truly a one box solution.  I have a few TINY version of Lenovo PC, and small LCD displays.

Ideas anyone?

Just a thought - but before you build it all into a one-box solution, think about whether you want to do three-cornered-hat measurements. You may want to build 3 DMT boards and a three way splitter for the offset oscillator into the same case - plus 3 TICCs. Obviously this puts the costs up considerably but it potentially allows you to get around the need for a very good reference oscillator or at least allows you to order oscillators in terms of ADEV.

[thinkfat]

That's what John said.  One thing about TICC data is that it takes two rows of data to complete the transition.  Appears unwarpping code gets confused about that.  It takes one point to unwrap it and leave the other one in place.  That becomes the deep null.  I can try to find the cycle but the problem is, this is not usable for measuring.  I'm going to use HP5335A that just works.  I may try to make DIY counter as well.  I want my whole setup in one package for ease of use. 

How's yours coming along?

Well I've received the PCBs and parts a while ago but I'm stuck with other stuff. I'm completing a LEA-M8T breakout board first, then populating and testing the DMTD board will come next. I've meanwhile bought a Bodnar GPS reference, hoping I'll be able to use it as the offset oscillator. I've also built a passive splitter, hoping that I'll be able to use that for testing the noise floor.

Unfortunately the Bodnar GPS is not flexible enough to provide offset as well as signal source for the noise floor test so I'll have to think about something else.

[tkamiya]

I'm not sure if GPSDO is a right choice for reference, as frequency gets yanked up and down periodically.  I'm using OCXO.  It will drift but at least it's a smooth transition.  In short term, it's more stable than GPSDO.  I am now using 11801 tuned 10Hz offset.  It easily moved that much and more.

Yes, I've considered 3 cornered hat version.  My problem is slightly different signals causing beat signal by leakage.  So I don't want to put 3 different DUT into one case until I solve that issue.

As to my data issue, I'm actually having two issues.  My DUT is 11801, REF is HP105B (both 10MHz) aligned pretty well to minimize wraps, and transfer oscillator is also 11801 tuned 10Hz higher.  This annomallies correlate precisely in timing.

Top graph is a frequency difference.  Notice the flat top mountain? 
Second graph is wrapped phase data.  If you look closely, there is an inflection point in negative slope, and of course the wrapping. 

I've drew a line through them to make it clear. 

Also, if you are to imagine those parts aren't there, rest of the data is pretty much contiguous.  Frequency stays steady, goes up, and comes back down to the same or similar point.  So phase wrap is causing some kind of annomaly and every wrapping resets it.  I'm sure this is a interference issue.  The shift is about 0.001Hz to 0.002Hz.  The exact location of this inflection point is consistent during a measurement but exact location changes when new oscillator is brought in. 

This change actually makes about 1 x 10^-11 worse in adev graph.  So it's fairly significant.
(0.001Hz is 1x10^10)  I need to solve this.