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

[Bob kb8tq]

Hi


> On Feb 10, 2022, at 4:44 PM, Joseph Gwinn <joegwinn at comcast.net> wrote:
> 
> 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.  

Folks do make modulation analyzers that are indeed targeted at giving
you all the I / Q data you would ever want to play with ….. not what I’d
call cheap. 

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

Both the 5330 and 53100 have a very “shallow” learning curve. We had 
a fleet of the 5330’s at work. I don’t think anybody really had trouble 
getting them to do what they wanted them to do. The 53100 I have 
here is very similar in that respect. 

Bob


> 
> 
> Joe Gwinn
> 
> 
> 
>> -- john (TimeLab support guy)
>> 
>> 
> 
>> End of time-nuts Digest, Vol 214, Issue 11
>> ******************************************
> _______________________________________________
> time-nuts mailing list -- time-nuts at lists.febo.com -- To unsubscribe send an email to time-nuts-leave at lists.febo.com
> To unsubscribe, go to and follow the instructions there.