John,
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.
Cheers,
Magnus
_______________________________________________
time-nuts mailing list -- [email protected]
To unsubscribe, go to https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
and follow the instructions there.
