[time-nuts] Phase/frequency scaling with TIC measurements (long)
john at miles.io
Sun Jan 18 19:33:12 EST 2015
> If you only have your TIM file with you back home, all you have to do is
> to press (e) to Edit the trace, as I recall it. I might have edited the
> file directly also. When doing that, I helped another time-nut at one time.
> Uncheck the "Use Input Frequency" and then input 10 MHz (or whatever) to
> "DUT Frequency".
That works for phase noise scaling but unfortunately not for stability measurements. To change the basis for stability measurements after the fact, you need to use the "Rescale Phase" field. (E.g., scale the phase by 0.1 and the ADEV will drop by a factor of 10x since the time derivative of the phase data will also shrink by 10x.)
You may also want to rescale by -1 to flip the polarity of the data, if for instance your DUT and reference are connected to the counter's start and stop channel jacks in such a way that the phase trend goes the opposite way from what you expect. The main reason you might care about that is if you want the frequency count chart to be correct based on the DUT's relationship to the reference. It doesn't affect the xDEV traces.
(Longer explanation: I've never been 100% satisfied with the relationship between TimeLab's usage of "phase," "frequency," and "time interval" vis-a-vis the "start" and "stop" nomenclature used by TI counters and the "DUT" and "reference" terminology that goes with it. There's actually a convention that states that frequency differences -- and hence phase-difference slopes -- are minus dTI/dt, but I wasn't aware of it when I wrote the original code. As a result, the early versions waffled back and forth in several different places, and I also did a lot of hand-waving when I wrote the help text. None of this is an issue for TimePod or 3120A users, but I do regret that I never settled on a simple, idiot-proof explanation of how to make a stability measurement with a TIC and get valid results in all respects under all conditions.)
Stability measurements with heterodyne-based instruments like DMTDs are an area where the user really has to pay attention to make sure the numbers come out right. When making a TI measurement with a DMTD, you are measuring low-frequency signals at both the start and stop input jacks. As with any other TI measurement, you need to specify a value in the Input Frequency field that will allow the phase unwrapper to detect jumps of more than pi radians while disregarding the rest. If a phase wrap goes unrecognized, there is no easy way to clean up the data after the fact. So your first instinct may be to enter the beatnote frequency.
But now there's another problem: to take advantage of a DMTD's improved measurement resolution, you need to rescale the phase data by the ratio of the measured beatnote and original DUT frequencies. You might think that you could do this with the Scale Factor field in the counter's acquisition dialog, and you can, but you need to be aware that TimeLab applies the phase scaling factor before it checks for phase wraps. So when you enter a non-unity Scale Factor, you need to enter the expected DUT frequency in the Input Frequency field, not the beatnote frequency that the counter actually sees.
This *should* result in a correctly-scaled ADEV plot that also has correct handling of phase wraps at the beatnote frequency, and (if you got the polarity right or at least made an even number of mistakes) the phase slope and frequency count chart in the 'p' and 'f' views should be correct. But I don't know if anyone has ever tested TimeLab with a DMTD, so you need to sanity-check *everything* about your measurement before assuming that the software is telling you the truth. Please let me know via the list or otherwise if you find it's not behaving as expected. Don't assume it's pilot error! When I use TimeLab with counters I almost always use frequency mode, so the in-house test coverage isn't always what it should be.
TL,DR: It's always safe to rescale the phase data in the 'e'dit dialog after acquisition finishes, because it will ignore (and overwrite) the original wrapped phase data. But you cannot currently change the input frequency that's used to render the frequency count chart, so it's best to set up the phase-scaling and input frequency properties at acquisition time if you care about that.
-- john, KE5FX
Miles Design LLC
More information about the time-nuts