On Sat, 30 May 2020 12:00:01 -0400, time-nuts-request@lists.febo.com wrote: Re: time-nuts Digest, Vol 190, Issue 40 [snip] > Message: 3 > Date: Sat, 30 May 2020 11:43:40 +0200 > From: Jan-Derk Bakker <jdbakker@gmail.com> > To: Discussion of precise time and frequency measurement > <time-nuts@lists.febo.com> > Subject: Re: [time-nuts] A simple sampling DMTD > Message-ID: > <CAEoGJMmsNEzL0eOJT25av0Pdkro9EuoRi=CEnbfg2QZe_S4uXw@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Dear Joe, > > Thank you for your mail; always happy with the dialogue. > > In a way we have come full circle; the Sherman/Jordens NIST paper was one > of my primary references for the design I made last summer. (It would have > been helpful had I linked to it upthread; I could have sworn I had done so, > but I cannot find the post.) I don't recall seeing it either. > The arctan-based approach in the NIST paper is computationally infeasible > on an 8-bit processor. Even so, back in November I have dumped raw samples > over USB to a PC to see how much improvement can be seen over a simple > least squares linear ZCD. As was discussed before, bandpass filtering and > more advanced phase estimation are complementary in their results: with > ideal band pass filtering, the phase detection becomes much less critical > (and vice versa). The best balance I could find at the time was a tracking > loop which runs a 501-point BPF FIR kernel on three points of the period of > both channels (expected on-time, ~1/6th period early, ~1/6th period late) > and then uses the arctangens to determine the phase. This produced ADEV > results about 1dB worse than running the FIR+arctan on all samples, and > about 1dB better than the simple ZCD with cascaded > differentiators/integrators as computationally inexpensive filters. This > gave me a workable baseline for the DMTD with reduced sampling rate and > reduced computational effort. What I don't understand is why everything must be done in that 8-bit processor. The traditional solution / architecture is to use the 8-bit processor only for data collection and forwarding, and do the big math in the commodity X86 computer which is controlling the data collection head. Then, ArcTan et al are easy. > (One of the limiting factors with the arctan-approach was that the quality > of the amplitude estimator plays a large role in the accuracy of the end > result. With arctan2 on I/Q data this is less of an issue; a FPGA can > efficiently do both in one go with a CORDIC) Yes, full I+Q is the way to go. I recall Sam Stein commenting an an article regarding the development of the 5120 instrument that a major cause of noise floor was the noise as the beatnote signals passed through zero. His solution was precisely I+Q, because the total power delivered is constant. Also, the Sherman/Jordens NIST paper specifically uses batch processing and curve-fitting, and not a FFT, for computational simplicity and to avoid the need for window taper functions. Nor are FFTs as precise and a batch fit. Joe Gwinn > Inspired by the NIST paper my sampling DMTD was designed to take an FPGA > daughterboard (the two rows of headers visible on > http://www.lartmaker.nl/time-nuts/dmtd-proto.jpg ). Last February I have > designed such a daughterboard (see attached image). Sadly, due to the > COVID-19 crisis my lab has closed for the foreseeable future; as I don't > have facilities to reliably populate 0402 parts and QFN packages at home, > this will have to wait for now. > > (@Luciano: Yes, having this available as a solution accessible to amateurs > has always been one of my goals) > > Sincerely, > > JDB. > [I've been working on other mildly time-nutty things that *can* be soldered > at home lately; hope to have a post in a week or two] > [snip] > > On Fri, May 29, 2020 at 6:07 PM Joseph Gwinn <joegwinn@comcast.net> wrote: > [snip] >> >> "Oscillator metrology with software defined radio, Jeff A. Sherman and >> Robert Jordens (of NIST), Review of Scientific Instruments 87, 054711 >> (2016); https://doi.org/10.1063/1.4950898. (Open version: >> <https://arxiv.org/pdf/1605.03505.pdf>)