Hi
> On Feb 10, 2022, at 4:44 PM, Joseph Gwinn <[email protected]> wrote: > > On Thu, 10 Feb 2022 03:30:33 -0500, [email protected] > wrote: >> time-nuts Digest, Vol 214, Issue 11 > >> ------------------------------------------------------------ > >> Message: 13 >> Date: Wed, 9 Feb 2022 15:18:36 -0800 >> From: "John Miles" <[email protected]> >> Subject: [time-nuts] Re: Phase Station 53100A Questions >> To: "'Discussion of precise time and frequency measurement'" >> <[email protected]> >> Message-ID: <[email protected]> >> >>> 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 -- [email protected] -- To unsubscribe send an > email to [email protected] > To unsubscribe, go to and follow the instructions there. _______________________________________________ time-nuts mailing list -- [email protected] -- To unsubscribe send an email to [email protected] To unsubscribe, go to and follow the instructions there.
