[time-nuts] Phase/frequency scaling with TIC measurements (long)

Magnus Danielson magnus at rubidium.dyndns.org
Sun Jan 18 21:26:26 EST 2015


On 01/19/2015 01:33 AM, John Miles wrote:
>> <snip>
>> 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.)

Thanks for correcting me there.
In this case, we have 5kHz / 10 MHz = 0.0005, right?

> 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.

Good trick.

> (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.)

I'll be the crash-head dummy as you attempt to re-work that. It would be 
good to nail it all down. It might even be that the convention does not 
align up to existing standards and definitions.

> 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.

Actually, I helped a fellow time-nut to edit his data so it did 
phase-unwrap properly. The benefit of not touching the data too much in 
the TIM file.

> 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.

I won't be able to rig up a test within the next couple of days, Friday 
at earliest, but it would indeed be nice to get it going. It's a fun lab. :)

I on the other hand always use phase data. Frequency data has a whole 
range of funky ways of biasing my measurements, and I regularly care 
about phase in ways which some consider me a nut-head, maybe even a 
time-nut. Ah well.

> 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.

Good to know.


More information about the time-nuts mailing list