[time-nuts] Re: Phase Station 53100A Questions

[Joseph Gwinn]

On Thu, 10 Feb 2022 03:30:33 -0500, time-nuts-request at lists.febo.com 
wrote:
> time-nuts Digest, Vol 214, Issue 11

>------------------------------------------------------------

> Message: 13
> Date: Wed, 9 Feb 2022 15:18:36 -0800
> From: "John Miles" <john at miles.io>
> Subject: [time-nuts] Re: Phase Station 53100A Questions
> To: "'Discussion of precise time and frequency measurement'"
> 	<time-nuts at lists.febo.com>
> Message-ID: <02b001d81e0b$5d950370$18bf0a50$@miles.io>
> 
>> I think you may be heading a bit off track digging into the 5120. The
>> 53100a has a very different “heritage” than the TSC gear. 

OK.  I didn't realize this.  But the patents were all I had found.


>     The 5330
>> “TimePod” would be a better thing to dig into to see its history. I’m
>> guessing 52100A is a typo.

I'll look into 5330 TimePod documentation.  Yes, 52100A is a typo; 
53100A was meant.


>> The .TIM files are generated by TimeLab so that’s a good place to look
>> for grubby details of this or that. They are “just” text files 
>> with a lot of
>> embedded comments that document what’s what on each line.  Maybe
>> not *quite* a “just read it and it all makes sense”, but there is a lot of
>> information in the file itself. I would suggest starting by reading through
>> the file that TimeLab puts out.

I recall looking into a .TIM file some time ago, and being able to 
read it (or at least fool myself).

I can also read the TimeLab source code.  The usual problem with this 
approach is that it can be hard to picture the shape of the forest 
from details of the bark on the trees.

 
> What Bob says. :)   It's true that the .TIM file format is meant to 
> be self-descriptive to some extent, but it's also true that we 
> really ought to document it formally at some point.  I've been 
> holding off for the next major revision of the file format, which 
> is intended to support multichannel measurements and per-sample 
> metadata in a single file.  That will probably be an 
> extensive-enough overhaul to render existing documentation 
> obsolete.  

Yes, this documentation will be quite welcome.  The problem of 
reverse engineering what amounts to an Interface Design Document from 
a few example files is that anything that does not happen to occur in 
the examples will be missed, giving no clue that anything is 
missing.  Until we later trip over it.


>    That said, feel free to email me -- or post here -- if 
> you have questions.

Thanks.  For now, I'll ask on the group so all can see the questions 
and answers, and chime in.

 
>> 2.  There will be some debugging required in my test setup, and it
>> would be very useful if I could independently demodulate the
>> Amplitude Modulation (AM) and Phase Modulation (PM) components of the
>> phase noise, and present the low-passed waveforms in voltage versus
>> time form.  Signals leaking in for other places may well be
>> recognizable by resemblance of the demodulated AM or PM baseband
>> waveform to other signals known to exist in the system under test.  I
>> was thinking that the TIM file may be a start.
> 
> This would really need to be addressed with direct access to the 
> I/Q data stream from the hardware, which isn't on the road map 
> right now.  If the goal is to track down signal leakage, though, it 
> is very effective to look at the AM and/or PM spurs, and also the 
> frequency-difference view.  As long as you select a measurement 
> bandwidth that's wide enough to include the source(s) of concern, 
> they will show up as periodic artifacts in frequency difference 
> measurements as well as ripple in the ADEV trace.

As I suspected, the TIM file will not help here, so for now it will 
be spectra and spurs.  Unless one can get the raw I&Q data in a file 
for external processing.

A lot of the possible interference is audio-band pink to red noise 
waveforms that are not spurs, and so spur displays will not be all 
that helpful.  Frequency spectra can be helpful, but can be ambiguous 
(because of the ignored phase data).

In any event, I guess demodulation of the AM and PM components of PN 
is really a product-improvement suggestion.  I envision the signal 
I&Q processing as being something like low pass filtration followed 
by decimation of I&Q followed by demodulation followed by low-pass 
baseband filtration.  

What is sought in my present effort would be happy with a modulation 
baseband bandwidth of 10 KHz, although I can envision wanting enough 
bandwidth to see things like the actual waveforms of switching power 
supply ripple.  This would get one up to a few MHz switching frequency

 
> As far as the fundamental principles of operation go, they are 
> covered reasonably well in the manual.  Again, any specific 
> questions, just say the word.  The TSC patents are mostly aimed at 
> working around deficiencies in the early RF ADC chips and DDS IP 
> cores that were available when Sam Stein's team did the original 
> groundwork.  I wouldn't say they're a waste of time to study, but 
> they are of historical rather than operational interest.  As a 
> source for further reading, the 5120A/5125A manuals are likely to 
> be more helpful than the patents.

I read the 5120 and 5125 manuals around the time that I came upon the 
TSC patents, and the manuals had the same figures and text as the 
patents.  At the time, I was encouraging TSC to obtain patents, 
because it is difficult to use such a capable but complicated 
instrument without a clear idea how it works, complete with the 
underlying math.

But I have not looked at later versions of these manuals, so I'll 
revisit them.

Most of my coworkers will struggle to use a 53100A correctly or at 
all without such documentation.


Joe Gwinn


 
> -- john (TimeLab support guy)
> 
> 

> End of time-nuts Digest, Vol 214, Issue 11
> ******************************************