DMTD board

[tkamiya]

So, to get a good count, the following conditions must be met.

DUT and REF has to be very close to each other in frequency.
Start and Stop signal has to occur in shortest period possible.
Wrap should be avoided or minimized.

I have a lot of coax relays.  I could make something like a decade box for adjusting phase.  (I like overkill)

[thinkfat]

I'm really interested in the results you get with the other counters. In theory, the TICC should be ideal for the purpose and I was planning on using it myself. I'm curious what you will find.

[tkamiya]

Oh, me too!  In addition to good functionality, it's low power, quiet (silent) and inexpensive.  I'm really not discounting environmental factors.  It'll take some setup as I took down GPIB from others.  For some reasons, 53132a doesn't like to work with me, either.

I'll post back as soon I get something.

[5065AGuru]

Taka,

The ONLY time I use phase shifters to get to close coincidence is for noise floor tests.

For other tests I just adjust the DUT or REF to bring me down to close coincidence.

Then readjust for as slow as possible increments. Since you would need to do this even with phase shifters why make the setup more complex than needed?

Also on long plots you can run an AD on the whole plot (after unwrapping) this will give results that are good at the higher >10 Sec Taus. Then pick a spot where you are near the lower wrap and do an AD on just that section. This will give good results for the <10Sec Taus.

You can then plot them both on the same chart to get a combined result.

There are dead time issues with the 53131/132 as well I suspect on the 5335 and 5370.

I used a 53131 or SR620 for a few years before I went to a purpose built TIC.

I could work around the dead time easily enough but it's nice not to have to mess with it.

The companion counter (to be released soon) for work with Dual mixer systems has no dead time issue and is cheap/small/easy to work with.

When you take some data with your 53132 let it wrap a few times and send me the file.

I can show you the dead time.

Cheers,

Corby

[tkamiya]

At this time, I have no idea what is going on....

I changed the counter to HP5335A and started experimenting.  Oscillator and reference, and everything else is identical.  Frequency difference between DUT and ref has been brought very close to each other.  Wrapping still appears to be a problem.  In frequency difference screen, I see an abrupt change.  Phase difference does not show the same.  ADev showed somewhere between 1E-11 and 1E-12 until wrapping took place.  Then it went up by a factor of 10 (-11 and -10) once and by factor of 1000 next time.

I have not been able to talk to HP53132A.  (I did this before successfully)
Something is awfully wrong....

One odd thing....  On TimeLab, if I select HP5335A, "Scale Factor" column shows up.  If I select "Talk only" it does not.  I only mention this because my issue with live capture using TL is similar with 5335A but use of scale factor appears to fix this.  I've used input frequency of 10E6 and scale factor of 1E7.  (same thing...)

It's pretty conclusive wrapping is the source of problem.  I have no idea why.

One thing I've noticed.  In Phase Difference screen, unwrapped and original shows identical graph.  Why???  I don't recall it was like this before.

[5065AGuru]

John's (KE5FX) info was spot on.

The wraps can be unwrapped so you can use the longer files.

After unwrapping does your AD look OK? If so are your frequency difference abrupt changes gone?

The 53132 should work OK, RS232 talk only. You do need to turn print on.

There is another parameter (besides baud rate) that needs selecting but I can't remember it offhand.

I'll dig it up and let you know.

Cheers,

Corby

[tkamiya]

I did get the HP53132A to work.  It had to be power cycled.  (Yes, I know about enabling printing)

An odd thing is, unwrapping does not appear to do anything on my TimeLab installation.  The graph is exactly the same.  I remember seeing "saw tooth" like wrapping became straight at one point.  I cannot do it for some reason.

[KE5FX]

I did get the HP53132A to work.  It had to be power cycled.  (Yes, I know about enabling printing)

An odd thing is, unwrapping does not appear to do anything on my TimeLab installation.  The graph is exactly the same.  I remember seeing "saw tooth" like wrapping became straight at one point.  I cannot do it for some reason.

In the actual data, does it still look like the numbers are repeating every so often?  Previously they were cycling every 165 seconds or so. 

If not, you may not have had any phase wraps on that particular run.  In that case the 'p' and 'w' views will be identical.

One odd thing....  On TimeLab, if I select HP5335A, "Scale Factor" column shows up.  If I select "Talk only" it does not.  I only mention this because my issue with live capture using TL is similar with 5335A but use of scale factor appears to fix this.  I've used input frequency of 10E6 and scale factor of 1E7.  (same thing...)

'Scale Factor' in the 5335A dialog is the same as the 'x' part of the "Numeric Field # _____ x ______" fields.  Enter 1E-7 in those, not 1E7.

[tkamiya]

John, Corby, and everyone else

John,
You are right, of course.  There was nothing to unwrap! 

Today, I've managed to fine tune frequency of DUT within 1 mHz of reference, and took nearly 10 minutes of data without wrapping.  With TICC, I have a believable data.  This is still a problem though - as it means I cannot take long run session. 

I'll have to study what EXACTLY TimeLab does to find out why my dataset doesn't unwrap correctly.  I wonder if there is a dead-time when it wraps?  The variation in phase data isn't that much.  Seems when it wraps, phase data gets shortened by few parts in 10E-9.

I wonder if this is something like....  when register in TICC overflows code takes different path and reduces incremental count by just a little?  I mean the "error" is very small.  Execution of few extra steps will explain it.  Hum....

[tkamiya]

Here's a graph with 10Hz difference.  Reading is taken every 0.1 second.  Still having problem with wrapping, so this is just the data before that happens.

DUT 11801
REF  HP105B
LO 11801 at 10Hz offset

[tkamiya]

I am now trying HP5335A with 10Hz difference.

Long story short, it works well except for few problems.  Looking at Frequency Difference chart, where wrapping took place, there are deep "dips".  (see 500 second and 1000 second mark)  I've visually identified wrapping taking place through TIM file.  In addition to this, there was a strike of noise coming in at one point, and with it, Adev dropped by 3 orders of magnitude.  (see 363 second mark)  Before this noise strike, Adev was tracking 10^13 and immediately after, it dropped to 10^10.  Concerning wrapping, unwrapped and wrapped display look identical.  However, Adev appears unaffected.  What's unknown is if its impact is actually buried into poor Adev caused by the "strike".

I'm going to upload TIM and all graphs for reference.  I don't expect anyone to analyze this for me but it might help others identify their problems.  With my setup, taking screenshot is rather cumbersome.  So please excuse use of cellphone snapshots. 

This is rather confusing but an adev graph with two traces, please see red trace.  Blue trace is irrelevant.  After this, I deleted that trace, so blue one is the right one.

<edit>
I also noticed at 330 second mark, and 880 second mark, slope of the curb changes in phase.  They are exactly the same point from t=0 and again same distance from wrapping taking place.  On graph, I see this zoomed in.  (see IMG_4784.jpg)

[tkamiya]

John,

How do I find the exact spot in TIM file where these weird symptoms are appearing in graph?  Having a time stamp doesn't help.

[tkamiya]

Taka's monolog, stardate 20201229....

I am repeating the experiment just to make sure this wasn't a one-off issue.  In a word, it is repeatable.

Unwrapping still results in deep and narrow dip in frequency difference curb.  However, I am realizing the change in slope noted as above is not present in frequency difference curb.  Increase in dy/dt in phase should result in shift in frequency - which is not present.  I am wondering if this is a graphing artifact.  I am also noticing after the wrap, dy appears to be greater than one.  (meaning it takes more than one interval to start positive delta again)  That would mean, unwrapping will leave a hole in same depth as frequency.  Noting phase difference is unit of 2 measures in graph, and frequency difference is also unit of 2 measures.  At this point, I am not sure of transfer function between the two.  However, graphically, it seems to work that way.  If this is true, then the deep drop is an artifact in unwrapping.  Note, in zoomed in graph, increment in dT is 2 seconds.  Visibly, it appears to be taking at least 2/10 seconds to reset to zero before climbing back again.  Zooming further in did not help resolve exact fractional seconds.  What happens in t+1/10?

In other words.... someone who's better than I in math, HELP!

[tkamiya]

It appears to be a known issue according to Mr. Google in mathlab.

https://stackoverflow.com/questions/32442396/phase-unwrap-issue-the-unwrapping-of-the-phases-is-not-correcly

Basically, when data point is shifted in Y direction by 2pi, discontinuity in data will result in missing point remaining in the same location while the rest shifts UP.  That creates a deep null. 

So the issue is of sampling frequency and piloting interval.

[KE5FX]

For the record, this is the code used by TimeLab for phase unwrapping:

Code: [Select]

      //
      // Store wrapped and unwrapped copies of phase sample
      //
      // If data came from a TIC, the maximum supported phase is bounded by the cycle period,
      // and we need to detect wraparounds in both directions.  If it came from a frequency counter
      // or direct-digital test set, the phase is unbounded, so we can inhibit wrap testing
      //

      P[n_acq_points] = phase;                           // store original potentially-wrapped phase ('w' view)
      P_sum += phase;

      if (enable_wrapping && (last_wrap_phase != DBL_MAX) && (full_cycle_period_secs != 0.0))
         {
         DOUBLE d_secs = fabs(phase - last_wrap_phase);  // compare phase difference in seconds with nominal half-period in seconds

         if (d_secs > half_cycle_period_secs)
            {
            if (phase > last_wrap_phase)                 // underflow wrap (e.g., 1 ns to 99 ns)
               phase_wrap -= full_cycle_period_secs;
            else                                         // overflow wrap (e.g., 99 ns to 1 ns)
               phase_wrap += full_cycle_period_secs;
            }
         }

      last_wrap_phase = phase;
      phase += phase_wrap;

      U[n_acq_points] = phase;                           // store unwrapped phase ('p' view)

... i.e., it does nothing except look for successive differences that exceed a half-cycle at the user-specified frequency, and accumulate an additional whole cycle every time that happens. 

Barring any strange bugs that have gone unreported for almost ten years, any artifacts that occur at wrap points are likely to be an issue with the counter or test setup.  Counter support will always be a 'best effort' sort of thing in TimeLab since its main purpose is to support direct-digital hardware, but if anyone can show that TimeLab is introducing any wrapping artifacts on its own, I'm all ears.

John,

How do I find the exact spot in TIM file where these weird symptoms are appearing in graph?  Having a time stamp doesn't help.

That's a bit of an open-ended question; what do you mean?  Just hit 'p' and/or 'f' and look for behavior you don't expect.

[tkamiya]

Thank you!

No, I don't think I've discovered a bug in your code.  I do think there must be an odd combination of corner cases happening.  Either that or my error in defining the acquisition screen.  I was thinking of manually unwrapping or writing a simple code to do the same.

About my question, say I'm looking at a graph and find a spot of interest.  Graph is doing "something funny".  Since the graph is a representation of time variant data, in order for "funny" to show up on a graph, there must be a corresponding data that is responsible for the behavior.  Let's say I save the data into a TIM file.  I want to find a row/data that correspond to that spot on the graph.  How do I do that?  p(phase difference), and f(frequency difference) will take me to the graph.  I can zoom in and see the data I find "funny".  How do I know which row in TIM file that caused/represents it?

Additionally, I see there is a half_cycle_period_secs.  You said it comes from "user specified" period.  Which field in acquisition screen exactly in HP5335 and stream device support?  Where does the following variables come from?  full_cycle_period_secs

How is it they declared? 
The DEFINE DBL_MAX, in the compiler in use for this, what is sizeof(DBL_MAX)?  What is double in this case?  8 bytes?

*something* is causing if(phase > last_wrap_phase) to return false I think.
Thank you very much.

[tkamiya]

Never mind on "how do I find" question.  I just found out I can export it with time stamp.

[KE5FX]

Never mind on "how do I find" question.  I just found out I can export it with time stamp.

Yep, that works.  At some point I'm going to add the ability to create annotations at desired spots in the data set, which will also make it easy to narrow down individual points.

The period_secs variables are based on the reciprocal of whatever you enter in the 'Input Frequency' fields, which are present in both the HP5335 and talk-only/import dialogs. 

Everything in TimeLab uses 64-bit doubles, and DBL_MAX is just used as a flag value that will never show up in real data.  It's either a #define or a const double declaration in float.h or someplace like that. 

[tkamiya]

Excel dump of frequency data shows all rows are unwrapped. 

I took this dump then subtracted n+1 from n in frequency data.  I see 343.4 and 343.5 being 6 to 7 orders of magnitude larger.  This is where wrapping happened.  I don't have what my counter sent.  But these two rows where it represents point of wrapping is unusual. 

Starting from 343.1 and incrementing by 0.1 second per row:

Here's the frequency data:
1.00000000002397E-05
1.00000000002523E-05
1.00000000002439E-05
9.99999900009689E-06
1.00000000001218E-05
1.00000000001228E-05
1.00000000001253E-05

Here's n+1 - n:
6.01901612318906E-18
-1.25699689372538E-17
8.36021518939994E-18
1.00014705108824E-12
-1.00002494281856E-12
-9.97804811865566E-19
-2.50044126029469E-18
-2.5410988417629E-18

Something happened at 343.4 to 343.5 second.  Could very well be my counter reporting something funny.  Wouldn't surprise me....  It's an old counter.  Somehow, I need to ascii capture what HPIB is reading.

Wait a second!  I exported frequency data.  Why am I seeing data in range of 1E-5?  Counter is showing nn.xxxx E-03.

Posting for sake of record keeping...

[tkamiya]

I think there is a major error (on my part) in acquisition screen.

The setting is DMTD 10MHz + 10Hz, 10 readings per second.
Data type is time interval.
Input frequency is 10E-6
Scale factor is 10E-7

This can't be right, right??  What should they be?  I'm always confused with these two.

[KE5FX]

That should be fine (see the image of the acquisition fields I posted above.)

[tkamiya]

What about INPUT FREQUENCY?  I was putting in 10E-6.  You have 10E6.

[tkamiya]

That didn't make any difference in graphs.  Hum.... 

[KE5FX]

Sorry, didn't see the minus sign -- yes, you should give it the frequency at the "DUT" mixer input there.  10E6 or 1E7, take your pick.  Then, with the 1E-6 scale factor, the phase is scaled to account for the heterodyne factor between your 10 Hz beat frequency and the 10 MHz input.

[tkamiya]

UNwrapping worked when I set input frequency to 1E8, and scale factor 1e-7.  I took verbatim of what help says.  Phase swings between 0 and 1E-8.  Recipical of largest phase difference, which is 1E8.

Now trying your suggestion.