Re: [time-nuts] A simple sampling DMTD

[Joseph Gwinn]

On Sat, 30 May 2020 12:00:01 -0400, time-nuts-requ...@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 
> To: Discussion of precise time and frequency measurement
>   
> Subject: Re: [time-nuts] A simple sampling DMTD
> Message-ID:
>   
> 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  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>)

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Bob Martin]

Timing Solutions Corp had several products that might be of interest.

Designed around 20 years ago. The TSC5110 was mixer based.
The TSC5120 and successors were A/D based.

The block diagram in the TSC52120A datasheet may be of interest:

https://www.axiomtest.com/documents/models/MicroSemi%205120A%20DataSheet.pdf


In the TSC5120A manual, Appendix B has some theory:

https://deki.mpifr-bonn.mpg.de/@api/deki/files/4701/=TSC-5120A-MAN-Rev-G.pdf

For you history buffs, Timing Solutions was bought by Symmetricom, 
which was bought by Microsemi which was bought by Microchip. The
location and many of the key employees at TSC have remained  despite 
all the ownership changes.


Cheers,

Bob

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Dear Joe,

Thank you for your mail; always happy with the dialogue.

In a way we have come full circle; the Sherman/Jördens 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.)

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.

(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)

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]

[image: timenuts-dmtd-fpga.png]

On Fri, May 29, 2020 at 6:07 PM Joseph Gwinn  wrote:

> On Sun, 01 Dec 2019 01:01:34 -0500, time-nuts-requ...@lists.febo.com
> wrote:
> Re: time-nuts Digest, Vol 185, Issue 1
>
> -
> >
> > Message: 1
> > Date: Sat, 30 Nov 2019 12:23:07 -0500
> > From: Joseph Gwinn 
> > To: time-nuts@lists.febo.com
> > Subject: Re: [time-nuts] A simple sampling DMTD
> > Message-ID: <20191130122307326859.fc045...@comcast.net>
> > Content-Type: text/plain; charset=us-ascii
> >
> > Re: time-nuts Digest, Vol 184, Issue 40
> > On Fri, 29 Nov 2019 20:37:02 -0500, time-nuts-requ...@lists.febo.com
> > wrote:
> >
> > [snip]
> >> Message: 6
> >> Date: Fri, 29 Nov 2019 20:37:16 +0100
> >> From: Gerhard Hoffmann 
> >> To: time-nuts@lists.febo.com
> >> Subject: Re: [time-nuts] A simple sampling DMTD
> >> Message-ID: 
> >> Content-Type: text/plain; charset=utf-8; format=flowed
> >>
> [snip]
> > The fundamental problem to be solved is to estimate the phases of two
> > beatnotes, one per channel (ref, signal under test), the phase
> > difference being converted into a relative time delay.  So, we are
> > estimating phase twice, against an unknown but common internal
> > reference, and the key question here is how best to measure those two
> > phases.  Detection of zero crossings is one way, but there are others.
>
> FYI, while looking for something unrelated, I recently ran across a
> relevant article from the NIST of Japan, published in 2007:
>
> "Frequency-Stability Measurement System Using High-Speed ADCs and
> Digital Signal Processing", Ken Mochizuki, Masaharu Uchino, and Takao
> Morikawa, IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL.
> 56, NO. 5, OCTOBER 2007, pages 1887-1893, Digital Object Identifier
> 10.1109/TIM.2007.895588.
>
> This can be implemented using a modern Software Defined Radio system.
>
> No zero-crossing detecter is used.  Computation of the time difference
> is detailed in reference [16] therein:
>
> [16] M. Uchino and K. Mochizuki, "Frequency stability measuring
> technique using digital signal processing," Electron. Commun. Jpn.,
> vol. 87, no. 1, pp. 21–33, 2004.   IEEE Xplore has it.
>
> Searching for Uchino et al led me to the following:
>
> "Oscillator metrology with software defined radio, Jeff A. Sherman and
> Robert Jördens (of NIST),

Re: [time-nuts] A simple sampling DMTD

[timeok]

   It looks very interesting.

   The TICC which has similar performance to the HP53132A, has a residual of 6 
e-11 @ 1s while the two-channel version described in the document is around 5 e 
-14.

   It would be extremely interesting if someone turned this into a solution 
accessible to amateurs.

   Luciano

   Luciano P. S. Paramithiotti
   tim...@timeok.it
   www.timeok.it

   Da "time-nuts" time-nuts-boun...@lists.febo.com
   A time-nuts@lists.febo.com
   Cc
   Data Fri, 29 May 2020 12:06:41 -0400
   Oggetto Re: [time-nuts] A simple sampling DMTD
   On Sun, 01 Dec 2019 01:01:34 -0500, time-nuts-requ...@lists.febo.com
   wrote:
   Re: time-nuts Digest, Vol 185, Issue 1

   -
   >
   > Message: 1
   > Date: Sat, 30 Nov 2019 12:23:07 -0500
   > From: Joseph Gwinn 
   > To: time-nuts@lists.febo.com
   > Subject: Re: [time-nuts] A simple sampling DMTD
   > Message-ID: <20191130122307326859.fc045...@comcast.net>
   > Content-Type: text/plain; charset=us-ascii
   >
   > Re: time-nuts Digest, Vol 184, Issue 40
   > On Fri, 29 Nov 2019 20:37:02 -0500, time-nuts-requ...@lists.febo.com
   > wrote:
   >
   > [snip]
   >> Message: 6
   >> Date: Fri, 29 Nov 2019 20:37:16 +0100
   >> From: Gerhard Hoffmann 
   >> To: time-nuts@lists.febo.com
   >> Subject: Re: [time-nuts] A simple sampling DMTD
   >> Message-ID: 
   >> Content-Type: text/plain; charset=utf-8; format=flowed
   >>
   [snip]
   > The fundamental problem to be solved is to estimate the phases of two
   > beatnotes, one per channel (ref, signal under test), the phase
   > difference being converted into a relative time delay. So, we are
   > estimating phase twice, against an unknown but common internal
   > reference, and the key question here is how best to measure those two
   > phases. Detection of zero crossings is one way, but there are others.

   FYI, while looking for something unrelated, I recently ran across a
   relevant article from the NIST of Japan, published in 2007:

   "Frequency-Stability Measurement System Using High-Speed ADCs and
   Digital Signal Processing", Ken Mochizuki, Masaharu Uchino, and Takao
   Morikawa, IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL.
   56, NO. 5, OCTOBER 2007, pages 1887-1893, Digital Object Identifier
   10.1109/TIM.2007.895588.

   This can be implemented using a modern Software Defined Radio system.

   No zero-crossing detecter is used. Computation of the time difference
   is detailed in reference [16] therein:

   [16] M. Uchino and K. Mochizuki, "Frequency stability measuring
   technique using digital signal processing," Electron. Commun. Jpn.,
   vol. 87, no. 1, pp. 21–33, 2004. IEEE Xplore has it.

   Searching for Uchino et al led me to the following:

   "Oscillator metrology with software defined radio, Jeff A. Sherman and
   Robert Jördens (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>)

   Joe Gwinn


   > We know the frequencies of the beatnotes quite accurately, and that the
   > waveforms are sine waves (which we will have band-pass filtered in
   > hardware before conversion to digital data). Here, I will assume that
   > the frequencies are the same. The only free variables are thus
   > amplitude and phase; these can be estimated using least squares applied
   > to successive batches of I samples. Windowing is still useful to
   > reduce end splice effects, as previously discussed. Given that we are
   > working in the numerical domain, it's probably adequate to apply the
   > window function to the product of the proposed match and the actual
   > data, and then sum the windowed products.
   >
   > As a quality check, if the estimated amplitude is too small (or too
   > large), reject the phase estimate and try again. If this condition
   > persists too long or becomes too common, something is broken.
   >
   > I doubt that anything of the 8-bit class is practical for this, and
   > certainly not for a small-volume product, because programming effort
   > increases sharply if the chosen processor is too limited. Ardinuo and
   > maybe StrawberryPi seem more like it.
   >
   > As for emulation of floating point, the least-squares algorithm defined
   > above can certainly be implemented in fixed-point arithmetic, called
   > fractional integers above.
   > <https://en.wikipedia.org/wiki/Fixed-point_arithmetic>
   >
   > In the extreme, this kind of algorithm will work with data clipped to a
   > few bits per sample. The underwater sonar folk are masters of this,
   > especially back in the days when signal processors were necessarily
   > bespoke hardware. The search term is "one-

Re: [time-nuts] A simple sampling DMTD

[Joseph Gwinn]

On Sun, 01 Dec 2019 01:01:34 -0500, time-nuts-requ...@lists.febo.com 
wrote:
Re: time-nuts Digest, Vol 185, Issue 1

-
> 
> Message: 1
> Date: Sat, 30 Nov 2019 12:23:07 -0500
> From: Joseph Gwinn 
> To: time-nuts@lists.febo.com
> Subject: Re: [time-nuts] A simple sampling DMTD
> Message-ID: <20191130122307326859.fc045...@comcast.net>
> Content-Type: text/plain; charset=us-ascii
> 
> Re: time-nuts Digest, Vol 184, Issue 40
> On Fri, 29 Nov 2019 20:37:02 -0500, time-nuts-requ...@lists.febo.com 
> wrote:
> 
> [snip]
>> Message: 6
>> Date: Fri, 29 Nov 2019 20:37:16 +0100
>> From: Gerhard Hoffmann 
>> To: time-nuts@lists.febo.com
>> Subject: Re: [time-nuts] A simple sampling DMTD
>> Message-ID: 
>> Content-Type: text/plain; charset=utf-8; format=flowed
>> 
[snip]
> The fundamental problem to be solved is to estimate the phases of two 
> beatnotes, one per channel (ref, signal under test), the phase 
> difference being converted into a relative time delay.  So, we are 
> estimating phase twice, against an unknown but common internal 
> reference, and the key question here is how best to measure those two 
> phases.  Detection of zero crossings is one way, but there are others. 

FYI, while looking for something unrelated, I recently ran across a 
relevant article from the NIST of Japan, published in 2007:

"Frequency-Stability Measurement System Using High-Speed ADCs and 
Digital Signal Processing", Ken Mochizuki, Masaharu Uchino, and Takao 
Morikawa, IEEE TRANSACTIONS ON INSTRUMENTATION AND MEASUREMENT, VOL. 
56, NO. 5, OCTOBER 2007, pages 1887-1893, Digital Object Identifier 
10.1109/TIM.2007.895588.

This can be implemented using a modern Software Defined Radio system.

No zero-crossing detecter is used.  Computation of the time difference 
is detailed in reference [16] therein:

[16] M. Uchino and K. Mochizuki, "Frequency stability measuring 
technique using digital signal processing," Electron. Commun. Jpn., 
vol. 87, no. 1, pp. 21–33, 2004.   IEEE Xplore has it.

Searching for Uchino et al led me to the following:

"Oscillator metrology with software defined radio, Jeff A. Sherman and 
Robert Jördens (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>)

Joe Gwinn


> We know the frequencies of the beatnotes quite accurately, and that the 
> waveforms are sine waves (which we will have band-pass filtered in 
> hardware before conversion to digital data).  Here, I will assume that 
> the frequencies are the same.  The only free variables are thus 
> amplitude and phase; these can be estimated using least squares applied 
> to successive batches of I samples.  Windowing is still useful to 
> reduce end splice effects, as previously discussed.  Given that we are 
> working in the numerical domain, it's probably adequate to apply the 
> window function to the product of the proposed match and the actual 
> data, and then sum the windowed products.
> 
> As a quality check, if the estimated amplitude is too small (or too 
> large), reject the phase estimate and try again.  If this condition 
> persists too long or becomes too common, something is broken.
> 
> I doubt that anything of the 8-bit class is practical for this, and 
> certainly not for a small-volume product, because programming effort 
> increases sharply if the chosen processor is too limited.  Ardinuo and 
> maybe StrawberryPi seem more like it.
> 
> As for emulation of floating point, the least-squares algorithm defined 
> above can certainly be implemented in fixed-point arithmetic, called 
> fractional integers above.  
> <https://en.wikipedia.org/wiki/Fixed-point_arithmetic>
> 
> In the extreme, this kind of algorithm will work with data clipped to a 
> few bits per sample.  The underwater sonar folk are masters of this, 
> especially back in the days when signal processors were necessarily 
> bespoke hardware.  The search term is "one-bit correlator" (without the 
> quotes).
> 
> --
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[paul swed via time-nuts]

It turns out Bobs dumpster was my dumpster by a long path.
I still have the sampling HP54100 1 Ghz scope and it works.
Many other lucky bits to get.
Best regards
Paul
WB8TSL

On Mon, Feb 24, 2020 at 1:43 PM Bob kb8tq via time-nuts <
time-nuts@lists.febo.com> wrote:

> Hi
>
> Yup, welcome to the online auction lottery ….. As you may have noted, I’m
> struggling a bit with the Phase Station and random (likely my fault)
> issues.
>
> At the same time, I’m going around in circles about the R FPC-COM2. It’s
> a pile of money, but it would replace a lot of questionable gear I have
> sitting
> here. Most of what I have was quite literally pulled from / saved from the
> dumpster at various points over the last few decades …..
>
> Bob
>
> > On Feb 24, 2020, at 12:33 PM, Taka Kamiya via time-nuts <
> time-nuts@lists.febo.com> wrote:
> >
> > I woke up this morning, check my HP105B, it's absolutely going nuts.
> Heater temp down, frequency ALL OVER the place.  No output in any of the
> ports.  Sigh.  eBay strikes again!
> >
> > ---
> > (Mr.) Taka Kamiya
> > KB4EMF / ex JF2DKG
> >
> >
> >On Sunday, February 23, 2020, 7:52:02 PM EST, Bob kb8tq via time-nuts
>  wrote:
> >
> > Hi
> >
> > Ok, but thats “high pass in the RF section”. You really do not have an
> audio high pass
> > filter the way you would in a more typical DMTD.
> >
> > If it’s any comfort, I’m sitting here looking at a very different box.
> It also has “wobbles”
> > as you get into parts in 10^-16. That might change a bit if the draft
> coming through the
> > window was a bit less.
> >
> > Bob
> >
> >> On Feb 23, 2020, at 6:12 PM, Jan-Derk Bakker 
> wrote:
> >>
> >> Dear Bob,
> >>
> >> The capacitors are 47n NP0/C0G types (Kemet C0805C473K3GAC7800), picked
> for low tempco (and low DF and other non-ideal behavior). I've not spotted
> any hysteresis artefacts in these in previous designs, but I haven't
> measured their performance in this circuit.
> >>
> >> Forgot to mention in the previous message: the baluns are transformers
> (M/A-COM MABAES0060), so the only DC the ADC should see is its own input
> offset (plus offset current across the 25R input filter resistors). Full
> schematic is here ( http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf <
> http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf> ; needs cleanup, but
> all connections are there).
> >>
> >> JDB.
> >>
> >> On Sun, Feb 23, 2020 at 10:13 PM Bob kb8tq  kb...@n1k.org>> wrote:
> >> Hi
> >>
> >> What does the temperature coefficient of your “hardware HPF” filter
> caps look like?
> >> Are they a type that has significant hysteresis?
> >>
> >> Bob
> >>
> >>> On Feb 23, 2020, at 3:05 PM, Jan-Derk Bakker via time-nuts <
> time-nuts@lists.febo.com > wrote:
> >>>
> >>> Dear Attila,
> >>>
> >>> Thanks for the heads up.
> >>>
> >>> I am currently using a HPF both in hardware (capacitive coupling into
> the
> >>> balun driving the ADC inputs) and in software before the ZCD. This
> should
> >>> counteract the first-order effects of this offset, although
> second-order
> >>> effects (converter nonlinearity et al) will of course still be an
> issue.
> >>> The plots you've quoted include (different kinds of) DC offset
> correction
> >>> for all but the "unfiltered" data; getting an efficient DC offset
> >>> correction working in real time on this 8-bit platform was indeed one
> of
> >>> the main challenges of the software-only approach.
> >>>
> >>> The FPGA daughterboard is currently in production at Eurocircuits; I
> hope
> >>> to have time to work on those the coming month. I'll also try to book
> some
> >>> time in our climate chamber. (I've had one of our GPSDO-designs
> running in
> >>> our general labs since before Christmas; surrounding it with bottles of
> >>> water works well enough to low pass filter temperature swings, but I
> still
> >>> see 6 degrees C swings overnight as out HVAC only runs during business
> >>> hours.)
> >>>
> >>> To be continued,
> >>>
> >>> JDB.
> >>>
> >>> On Sun, Feb 23, 2020 at 8:11 PM Attila Kinali via time-nuts <
> >>> time-nuts@lists.febo.com > wrote:
> >>>
>  Good evening!
> 
>  I'm going through some old stuff...
> 
> 
>  On Wed, 27 Nov 2019 00:29:19 +0100
>  Jan-Derk Bakker mailto:jdbak...@gmail.com>>
> wrote:
> 
> > This has yielded a combined "simple" signal
> > processing path of a differentiator, a double comb filter and the
> offset
> > estimator, which is getting very close in performance to the "ideal"
> band
> > pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the
>  BPF;
> > full plot:
> >
> 
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
> <
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
> >
> > for this 60-second recording:
> >
> 
> 

Re: [time-nuts] A simple sampling DMTD

[Bob kb8tq via time-nuts]

Hi

Yup, welcome to the online auction lottery ….. As you may have noted, I’m
struggling a bit with the Phase Station and random (likely my fault) issues.

At the same time, I’m going around in circles about the R FPC-COM2. It’s
a pile of money, but it would replace a lot of questionable gear I have sitting 
here. Most of what I have was quite literally pulled from / saved from the 
dumpster at various points over the last few decades …..

Bob

> On Feb 24, 2020, at 12:33 PM, Taka Kamiya via time-nuts 
>  wrote:
> 
> I woke up this morning, check my HP105B, it's absolutely going nuts.  Heater 
> temp down, frequency ALL OVER the place.  No output in any of the ports.  
> Sigh.  eBay strikes again!
> 
> --- 
> (Mr.) Taka Kamiya
> KB4EMF / ex JF2DKG
> 
> 
>On Sunday, February 23, 2020, 7:52:02 PM EST, Bob kb8tq via time-nuts 
>  wrote:  
> 
> Hi
> 
> Ok, but thats “high pass in the RF section”. You really do not have an audio 
> high pass 
> filter the way you would in a more typical DMTD. 
> 
> If it’s any comfort, I’m sitting here looking at a very different box. It 
> also has “wobbles”
> as you get into parts in 10^-16. That might change a bit if the draft coming 
> through the
> window was a bit less.
> 
> Bob
> 
>> On Feb 23, 2020, at 6:12 PM, Jan-Derk Bakker  wrote:
>> 
>> Dear Bob,
>> 
>> The capacitors are 47n NP0/C0G types (Kemet C0805C473K3GAC7800), picked for 
>> low tempco (and low DF and other non-ideal behavior). I've not spotted any 
>> hysteresis artefacts in these in previous designs, but I haven't measured 
>> their performance in this circuit.
>> 
>> Forgot to mention in the previous message: the baluns are transformers 
>> (M/A-COM MABAES0060), so the only DC the ADC should see is its own input 
>> offset (plus offset current across the 25R input filter resistors). Full 
>> schematic is here ( http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf 
>>  ; needs cleanup, but 
>> all connections are there).
>> 
>> JDB.
>> 
>> On Sun, Feb 23, 2020 at 10:13 PM Bob kb8tq > > wrote:
>> Hi
>> 
>> What does the temperature coefficient of your “hardware HPF” filter caps 
>> look like?
>> Are they a type that has significant hysteresis?
>> 
>> Bob
>> 
>>> On Feb 23, 2020, at 3:05 PM, Jan-Derk Bakker via time-nuts 
>>> mailto:time-nuts@lists.febo.com>> wrote:
>>> 
>>> Dear Attila,
>>> 
>>> Thanks for the heads up.
>>> 
>>> I am currently using a HPF both in hardware (capacitive coupling into the
>>> balun driving the ADC inputs) and in software before the ZCD. This should
>>> counteract the first-order effects of this offset, although second-order
>>> effects (converter nonlinearity et al) will of course still be an issue.
>>> The plots you've quoted include (different kinds of) DC offset correction
>>> for all but the "unfiltered" data; getting an efficient DC offset
>>> correction working in real time on this 8-bit platform was indeed one of
>>> the main challenges of the software-only approach.
>>> 
>>> The FPGA daughterboard is currently in production at Eurocircuits; I hope
>>> to have time to work on those the coming month. I'll also try to book some
>>> time in our climate chamber. (I've had one of our GPSDO-designs running in
>>> our general labs since before Christmas; surrounding it with bottles of
>>> water works well enough to low pass filter temperature swings, but I still
>>> see 6 degrees C swings overnight as out HVAC only runs during business
>>> hours.)
>>> 
>>> To be continued,
>>> 
>>> JDB.
>>> 
>>> On Sun, Feb 23, 2020 at 8:11 PM Attila Kinali via time-nuts <
>>> time-nuts@lists.febo.com > wrote:
>>> 
 Good evening!
 
 I'm going through some old stuff...
 
 
 On Wed, 27 Nov 2019 00:29:19 +0100
 Jan-Derk Bakker mailto:jdbak...@gmail.com>> wrote:
 
> This has yielded a combined "simple" signal
> processing path of a differentiator, a double comb filter and the offset
> estimator, which is getting very close in performance to the "ideal" band
> pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the
 BPF;
> full plot:
> 
 http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
  
 
> for this 60-second recording:
> 
 http://www.lartmaker.nl/time-nuts/600ksec%20run%20with%20PLL,%2010811%20through%20splitter.png
  
 
> . OADEV past ~1000sec is severely compromised by the fact that the
> measurement setup is in my home lab which sees temperature swings of up
 to
> 20 degrees C and which does get bumped from time to time. Longer runs in
 a
> more controlled setting 

Re: [time-nuts] A simple sampling DMTD

[Taka Kamiya via time-nuts]

I woke up this morning, check my HP105B, it's absolutely going nuts.  Heater 
temp down, frequency ALL OVER the place.  No output in any of the ports.  
Sigh.  eBay strikes again!

--- 
(Mr.) Taka Kamiya
KB4EMF / ex JF2DKG
 

On Sunday, February 23, 2020, 7:52:02 PM EST, Bob kb8tq via time-nuts 
 wrote:  
 
 Hi

Ok, but thats “high pass in the RF section”. You really do not have an audio 
high pass 
filter the way you would in a more typical DMTD. 

If it’s any comfort, I’m sitting here looking at a very different box. It also 
has “wobbles”
as you get into parts in 10^-16. That might change a bit if the draft coming 
through the
window was a bit less.

Bob

> On Feb 23, 2020, at 6:12 PM, Jan-Derk Bakker  wrote:
> 
> Dear Bob,
> 
> The capacitors are 47n NP0/C0G types (Kemet C0805C473K3GAC7800), picked for 
> low tempco (and low DF and other non-ideal behavior). I've not spotted any 
> hysteresis artefacts in these in previous designs, but I haven't measured 
> their performance in this circuit.
> 
> Forgot to mention in the previous message: the baluns are transformers 
> (M/A-COM MABAES0060), so the only DC the ADC should see is its own input 
> offset (plus offset current across the 25R input filter resistors). Full 
> schematic is here ( http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf 
>  ; needs cleanup, but all 
> connections are there).
> 
> JDB.
> 
> On Sun, Feb 23, 2020 at 10:13 PM Bob kb8tq  > wrote:
> Hi
> 
> What does the temperature coefficient of your “hardware HPF” filter caps look 
> like?
> Are they a type that has significant hysteresis?
> 
> Bob
> 
> > On Feb 23, 2020, at 3:05 PM, Jan-Derk Bakker via time-nuts 
> > mailto:time-nuts@lists.febo.com>> wrote:
> > 
> > Dear Attila,
> > 
> > Thanks for the heads up.
> > 
> > I am currently using a HPF both in hardware (capacitive coupling into the
> > balun driving the ADC inputs) and in software before the ZCD. This should
> > counteract the first-order effects of this offset, although second-order
> > effects (converter nonlinearity et al) will of course still be an issue.
> > The plots you've quoted include (different kinds of) DC offset correction
> > for all but the "unfiltered" data; getting an efficient DC offset
> > correction working in real time on this 8-bit platform was indeed one of
> > the main challenges of the software-only approach.
> > 
> > The FPGA daughterboard is currently in production at Eurocircuits; I hope
> > to have time to work on those the coming month. I'll also try to book some
> > time in our climate chamber. (I've had one of our GPSDO-designs running in
> > our general labs since before Christmas; surrounding it with bottles of
> > water works well enough to low pass filter temperature swings, but I still
> > see 6 degrees C swings overnight as out HVAC only runs during business
> > hours.)
> > 
> > To be continued,
> > 
> > JDB.
> > 
> > On Sun, Feb 23, 2020 at 8:11 PM Attila Kinali via time-nuts <
> > time-nuts@lists.febo.com > wrote:
> > 
> >> Good evening!
> >> 
> >> I'm going through some old stuff...
> >> 
> >> 
> >> On Wed, 27 Nov 2019 00:29:19 +0100
> >> Jan-Derk Bakker mailto:jdbak...@gmail.com>> wrote:
> >> 
> >>> This has yielded a combined "simple" signal
> >>> processing path of a differentiator, a double comb filter and the offset
> >>> estimator, which is getting very close in performance to the "ideal" band
> >>> pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the
> >> BPF;
> >>> full plot:
> >>> 
> >> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
> >>  
> >> 
> >>> for this 60-second recording:
> >>> 
> >> http://www.lartmaker.nl/time-nuts/600ksec%20run%20with%20PLL,%2010811%20through%20splitter.png
> >>  
> >> 
> >>> . OADEV past ~1000sec is severely compromised by the fact that the
> >>> measurement setup is in my home lab which sees temperature swings of up
> >> to
> >>> 20 degrees C and which does get bumped from time to time. Longer runs in
> >> a
> >>> more controlled setting forthcoming).
> >> 
> >> 
> >> I can offer an explanation for the large effect of the zero correction seen
> >> here. The LTC2140 is specified to have a +/-10µV/°C drift (at 1Vpp
> >> setting).
> >> Converted into phase error due to zero crossing shift, this turns into
> >> a phase shift of +/-1ps/°C @ 10MHz. Note, the shift is given as +/- and
> >> per channel, which means, it could very well be that the channels are
> >> not matched in their temperature characteristics and thus the total phase
> >> shift could be +/-2ps/°C ... though total shift being closer to 0.5ps/°C is
> >> more likely.

Re: [time-nuts] A simple sampling DMTD

[Taka Kamiya via time-nuts]

I took over master bedroom for my lab, and I have a gate for dog entry 
prevention.  All cables are over-head.  I need protection from 2 legged and 4 
legged variety.

--- 
(Mr.) Taka Kamiya
KB4EMF / ex JF2DKG
 

On Monday, February 24, 2020, 10:47:20 AM EST, Bob kb8tq via time-nuts 
 wrote:  
 
 Hi

…… looking at the data this morning. It appears that in my case *somebody* 
(I’m blaming the dog) must have bumped the setup. There is a very obvious 
set of steps in the phase data. The overnight run has no similar steps. 
Sometimes
getting everything away from the test is a good thing …..

Bob

> On Feb 23, 2020, at 7:51 PM, Bob kb8tq  wrote:
> 
> Hi
> 
> Ok, but thats “high pass in the RF section”. You really do not have an audio 
> high pass 
> filter the way you would in a more typical DMTD. 
> 
> If it’s any comfort, I’m sitting here looking at a very different box. It 
> also has “wobbles”
> as you get into parts in 10^-16. That might change a bit if the draft coming 
> through the
> window was a bit less.
> 
> Bob
> 
>> On Feb 23, 2020, at 6:12 PM, Jan-Derk Bakker > > wrote:
>> 
>> Dear Bob,
>> 
>> The capacitors are 47n NP0/C0G types (Kemet C0805C473K3GAC7800), picked for 
>> low tempco (and low DF and other non-ideal behavior). I've not spotted any 
>> hysteresis artefacts in these in previous designs, but I haven't measured 
>> their performance in this circuit.
>> 
>> Forgot to mention in the previous message: the baluns are transformers 
>> (M/A-COM MABAES0060), so the only DC the ADC should see is its own input 
>> offset (plus offset current across the 25R input filter resistors). Full 
>> schematic is here ( http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf 
>>  ; needs cleanup, but 
>> all connections are there).
>> 
>> JDB.
>> 
>> On Sun, Feb 23, 2020 at 10:13 PM Bob kb8tq > > wrote:
>> Hi
>> 
>> What does the temperature coefficient of your “hardware HPF” filter caps 
>> look like?
>> Are they a type that has significant hysteresis?
>> 
>> Bob
>> 
>> > On Feb 23, 2020, at 3:05 PM, Jan-Derk Bakker via time-nuts 
>> > mailto:time-nuts@lists.febo.com>> wrote:
>> > 
>> > Dear Attila,
>> > 
>> > Thanks for the heads up.
>> > 
>> > I am currently using a HPF both in hardware (capacitive coupling into the
>> > balun driving the ADC inputs) and in software before the ZCD. This should
>> > counteract the first-order effects of this offset, although second-order
>> > effects (converter nonlinearity et al) will of course still be an issue.
>> > The plots you've quoted include (different kinds of) DC offset correction
>> > for all but the "unfiltered" data; getting an efficient DC offset
>> > correction working in real time on this 8-bit platform was indeed one of
>> > the main challenges of the software-only approach.
>> > 
>> > The FPGA daughterboard is currently in production at Eurocircuits; I hope
>> > to have time to work on those the coming month. I'll also try to book some
>> > time in our climate chamber. (I've had one of our GPSDO-designs running in
>> > our general labs since before Christmas; surrounding it with bottles of
>> > water works well enough to low pass filter temperature swings, but I still
>> > see 6 degrees C swings overnight as out HVAC only runs during business
>> > hours.)
>> > 
>> > To be continued,
>> > 
>> > JDB.
>> > 
>> > On Sun, Feb 23, 2020 at 8:11 PM Attila Kinali via time-nuts <
>> > time-nuts@lists.febo.com > wrote:
>> > 
>> >> Good evening!
>> >> 
>> >> I'm going through some old stuff...
>> >> 
>> >> 
>> >> On Wed, 27 Nov 2019 00:29:19 +0100
>> >> Jan-Derk Bakker mailto:jdbak...@gmail.com>> wrote:
>> >> 
>> >>> This has yielded a combined "simple" signal
>> >>> processing path of a differentiator, a double comb filter and the offset
>> >>> estimator, which is getting very close in performance to the "ideal" band
>> >>> pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the
>> >> BPF;
>> >>> full plot:
>> >>> 
>> >> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
>> >>  
>> >> 
>> >>> for this 60-second recording:
>> >>> 
>> >> http://www.lartmaker.nl/time-nuts/600ksec%20run%20with%20PLL,%2010811%20through%20splitter.png
>> >>  
>> >> 
>> >>> . OADEV past ~1000sec is severely compromised by the fact that the
>> >>> measurement setup is in my home lab which sees temperature swings of up
>> >> to
>> >>> 20 degrees C and which does get bumped from time to time. Longer runs in
>> >> a
>> >>> more controlled setting forthcoming).
>> >> 
>> >> 
>> >> I can offer an explanation for the large effect of the zero correction 
>> >> 

Re: [time-nuts] A simple sampling DMTD

[Bob kb8tq via time-nuts]

Hi

…… looking at the data this morning. It appears that in my case *somebody* 
(I’m blaming the dog) must have bumped the setup. There is a very obvious 
set of steps in the phase data. The overnight run has no similar steps. 
Sometimes
getting everything away from the test is a good thing …..

Bob

> On Feb 23, 2020, at 7:51 PM, Bob kb8tq  wrote:
> 
> Hi
> 
> Ok, but thats “high pass in the RF section”. You really do not have an audio 
> high pass 
> filter the way you would in a more typical DMTD. 
> 
> If it’s any comfort, I’m sitting here looking at a very different box. It 
> also has “wobbles”
> as you get into parts in 10^-16. That might change a bit if the draft coming 
> through the
> window was a bit less.
> 
> Bob
> 
>> On Feb 23, 2020, at 6:12 PM, Jan-Derk Bakker > > wrote:
>> 
>> Dear Bob,
>> 
>> The capacitors are 47n NP0/C0G types (Kemet C0805C473K3GAC7800), picked for 
>> low tempco (and low DF and other non-ideal behavior). I've not spotted any 
>> hysteresis artefacts in these in previous designs, but I haven't measured 
>> their performance in this circuit.
>> 
>> Forgot to mention in the previous message: the baluns are transformers 
>> (M/A-COM MABAES0060), so the only DC the ADC should see is its own input 
>> offset (plus offset current across the 25R input filter resistors). Full 
>> schematic is here ( http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf 
>>  ; needs cleanup, but 
>> all connections are there).
>> 
>> JDB.
>> 
>> On Sun, Feb 23, 2020 at 10:13 PM Bob kb8tq > > wrote:
>> Hi
>> 
>> What does the temperature coefficient of your “hardware HPF” filter caps 
>> look like?
>> Are they a type that has significant hysteresis?
>> 
>> Bob
>> 
>> > On Feb 23, 2020, at 3:05 PM, Jan-Derk Bakker via time-nuts 
>> > mailto:time-nuts@lists.febo.com>> wrote:
>> > 
>> > Dear Attila,
>> > 
>> > Thanks for the heads up.
>> > 
>> > I am currently using a HPF both in hardware (capacitive coupling into the
>> > balun driving the ADC inputs) and in software before the ZCD. This should
>> > counteract the first-order effects of this offset, although second-order
>> > effects (converter nonlinearity et al) will of course still be an issue.
>> > The plots you've quoted include (different kinds of) DC offset correction
>> > for all but the "unfiltered" data; getting an efficient DC offset
>> > correction working in real time on this 8-bit platform was indeed one of
>> > the main challenges of the software-only approach.
>> > 
>> > The FPGA daughterboard is currently in production at Eurocircuits; I hope
>> > to have time to work on those the coming month. I'll also try to book some
>> > time in our climate chamber. (I've had one of our GPSDO-designs running in
>> > our general labs since before Christmas; surrounding it with bottles of
>> > water works well enough to low pass filter temperature swings, but I still
>> > see 6 degrees C swings overnight as out HVAC only runs during business
>> > hours.)
>> > 
>> > To be continued,
>> > 
>> > JDB.
>> > 
>> > On Sun, Feb 23, 2020 at 8:11 PM Attila Kinali via time-nuts <
>> > time-nuts@lists.febo.com > wrote:
>> > 
>> >> Good evening!
>> >> 
>> >> I'm going through some old stuff...
>> >> 
>> >> 
>> >> On Wed, 27 Nov 2019 00:29:19 +0100
>> >> Jan-Derk Bakker mailto:jdbak...@gmail.com>> wrote:
>> >> 
>> >>> This has yielded a combined "simple" signal
>> >>> processing path of a differentiator, a double comb filter and the offset
>> >>> estimator, which is getting very close in performance to the "ideal" band
>> >>> pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the
>> >> BPF;
>> >>> full plot:
>> >>> 
>> >> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
>> >>  
>> >> 
>> >>> for this 60-second recording:
>> >>> 
>> >> http://www.lartmaker.nl/time-nuts/600ksec%20run%20with%20PLL,%2010811%20through%20splitter.png
>> >>  
>> >> 
>> >>> . OADEV past ~1000sec is severely compromised by the fact that the
>> >>> measurement setup is in my home lab which sees temperature swings of up
>> >> to
>> >>> 20 degrees C and which does get bumped from time to time. Longer runs in
>> >> a
>> >>> more controlled setting forthcoming).
>> >> 
>> >> 
>> >> I can offer an explanation for the large effect of the zero correction 
>> >> seen
>> >> here. The LTC2140 is specified to have a +/-10µV/°C drift (at 1Vpp
>> >> setting).
>> >> Converted into phase error due to zero crossing shift, this turns into
>> >> a phase shift of +/-1ps/°C @ 10MHz. Note, the shift is given as +/- and
>> >> per channel, which means, it could very well be that the channels are
>> >> not 

Re: [time-nuts] A simple sampling DMTD

[Bob kb8tq via time-nuts]

Hi

Ok, but thats “high pass in the RF section”. You really do not have an audio 
high pass 
filter the way you would in a more typical DMTD. 

If it’s any comfort, I’m sitting here looking at a very different box. It also 
has “wobbles”
as you get into parts in 10^-16. That might change a bit if the draft coming 
through the
window was a bit less.

Bob

> On Feb 23, 2020, at 6:12 PM, Jan-Derk Bakker  wrote:
> 
> Dear Bob,
> 
> The capacitors are 47n NP0/C0G types (Kemet C0805C473K3GAC7800), picked for 
> low tempco (and low DF and other non-ideal behavior). I've not spotted any 
> hysteresis artefacts in these in previous designs, but I haven't measured 
> their performance in this circuit.
> 
> Forgot to mention in the previous message: the baluns are transformers 
> (M/A-COM MABAES0060), so the only DC the ADC should see is its own input 
> offset (plus offset current across the 25R input filter resistors). Full 
> schematic is here ( http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf 
>  ; needs cleanup, but all 
> connections are there).
> 
> JDB.
> 
> On Sun, Feb 23, 2020 at 10:13 PM Bob kb8tq  > wrote:
> Hi
> 
> What does the temperature coefficient of your “hardware HPF” filter caps look 
> like?
> Are they a type that has significant hysteresis?
> 
> Bob
> 
> > On Feb 23, 2020, at 3:05 PM, Jan-Derk Bakker via time-nuts 
> > mailto:time-nuts@lists.febo.com>> wrote:
> > 
> > Dear Attila,
> > 
> > Thanks for the heads up.
> > 
> > I am currently using a HPF both in hardware (capacitive coupling into the
> > balun driving the ADC inputs) and in software before the ZCD. This should
> > counteract the first-order effects of this offset, although second-order
> > effects (converter nonlinearity et al) will of course still be an issue.
> > The plots you've quoted include (different kinds of) DC offset correction
> > for all but the "unfiltered" data; getting an efficient DC offset
> > correction working in real time on this 8-bit platform was indeed one of
> > the main challenges of the software-only approach.
> > 
> > The FPGA daughterboard is currently in production at Eurocircuits; I hope
> > to have time to work on those the coming month. I'll also try to book some
> > time in our climate chamber. (I've had one of our GPSDO-designs running in
> > our general labs since before Christmas; surrounding it with bottles of
> > water works well enough to low pass filter temperature swings, but I still
> > see 6 degrees C swings overnight as out HVAC only runs during business
> > hours.)
> > 
> > To be continued,
> > 
> > JDB.
> > 
> > On Sun, Feb 23, 2020 at 8:11 PM Attila Kinali via time-nuts <
> > time-nuts@lists.febo.com > wrote:
> > 
> >> Good evening!
> >> 
> >> I'm going through some old stuff...
> >> 
> >> 
> >> On Wed, 27 Nov 2019 00:29:19 +0100
> >> Jan-Derk Bakker mailto:jdbak...@gmail.com>> wrote:
> >> 
> >>> This has yielded a combined "simple" signal
> >>> processing path of a differentiator, a double comb filter and the offset
> >>> estimator, which is getting very close in performance to the "ideal" band
> >>> pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the
> >> BPF;
> >>> full plot:
> >>> 
> >> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
> >>  
> >> 
> >>> for this 60-second recording:
> >>> 
> >> http://www.lartmaker.nl/time-nuts/600ksec%20run%20with%20PLL,%2010811%20through%20splitter.png
> >>  
> >> 
> >>> . OADEV past ~1000sec is severely compromised by the fact that the
> >>> measurement setup is in my home lab which sees temperature swings of up
> >> to
> >>> 20 degrees C and which does get bumped from time to time. Longer runs in
> >> a
> >>> more controlled setting forthcoming).
> >> 
> >> 
> >> I can offer an explanation for the large effect of the zero correction seen
> >> here. The LTC2140 is specified to have a +/-10µV/°C drift (at 1Vpp
> >> setting).
> >> Converted into phase error due to zero crossing shift, this turns into
> >> a phase shift of +/-1ps/°C @ 10MHz. Note, the shift is given as +/- and
> >> per channel, which means, it could very well be that the channels are
> >> not matched in their temperature characteristics and thus the total phase
> >> shift could be +/-2ps/°C ... though total shift being closer to 0.5ps/°C is
> >> more likely.
> >> 
> >> Summa sumarum: DC offset correction is important if a zero crossing
> >> detector is used.
> >> 
> >>Attila Kinali
> >> 
> >> --
> >> The bad part of Zurich is where the degenerates
> >>throw DARK chocolate at you.
> >> 
> >> ___
> >> time-nuts 

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker via time-nuts]

Dear Bob,

The capacitors are 47n NP0/C0G types (Kemet C0805C473K3GAC7800), picked for
low tempco (and low DF and other non-ideal behavior). I've not spotted any
hysteresis artefacts in these in previous designs, but I haven't measured
their performance in this circuit.

Forgot to mention in the previous message: the baluns are transformers
(M/A-COM MABAES0060), so the only DC the ADC should see is its own input
offset (plus offset current across the 25R input filter resistors). Full
schematic is here ( http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf ;
needs cleanup, but all connections are there).

JDB.

On Sun, Feb 23, 2020 at 10:13 PM Bob kb8tq  wrote:

> Hi
>
> What does the temperature coefficient of your “hardware HPF” filter caps
> look like?
> Are they a type that has significant hysteresis?
>
> Bob
>
> > On Feb 23, 2020, at 3:05 PM, Jan-Derk Bakker via time-nuts <
> time-nuts@lists.febo.com> wrote:
> >
> > Dear Attila,
> >
> > Thanks for the heads up.
> >
> > I am currently using a HPF both in hardware (capacitive coupling into the
> > balun driving the ADC inputs) and in software before the ZCD. This should
> > counteract the first-order effects of this offset, although second-order
> > effects (converter nonlinearity et al) will of course still be an issue.
> > The plots you've quoted include (different kinds of) DC offset correction
> > for all but the "unfiltered" data; getting an efficient DC offset
> > correction working in real time on this 8-bit platform was indeed one of
> > the main challenges of the software-only approach.
> >
> > The FPGA daughterboard is currently in production at Eurocircuits; I hope
> > to have time to work on those the coming month. I'll also try to book
> some
> > time in our climate chamber. (I've had one of our GPSDO-designs running
> in
> > our general labs since before Christmas; surrounding it with bottles of
> > water works well enough to low pass filter temperature swings, but I
> still
> > see 6 degrees C swings overnight as out HVAC only runs during business
> > hours.)
> >
> > To be continued,
> >
> > JDB.
> >
> > On Sun, Feb 23, 2020 at 8:11 PM Attila Kinali via time-nuts <
> > time-nuts@lists.febo.com> wrote:
> >
> >> Good evening!
> >>
> >> I'm going through some old stuff...
> >>
> >>
> >> On Wed, 27 Nov 2019 00:29:19 +0100
> >> Jan-Derk Bakker  wrote:
> >>
> >>> This has yielded a combined "simple" signal
> >>> processing path of a differentiator, a double comb filter and the
> offset
> >>> estimator, which is getting very close in performance to the "ideal"
> band
> >>> pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the
> >> BPF;
> >>> full plot:
> >>>
> >>
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
> >>> for this 60-second recording:
> >>>
> >>
> http://www.lartmaker.nl/time-nuts/600ksec%20run%20with%20PLL,%2010811%20through%20splitter.png
> >>> . OADEV past ~1000sec is severely compromised by the fact that the
> >>> measurement setup is in my home lab which sees temperature swings of up
> >> to
> >>> 20 degrees C and which does get bumped from time to time. Longer runs
> in
> >> a
> >>> more controlled setting forthcoming).
> >>
> >>
> >> I can offer an explanation for the large effect of the zero correction
> seen
> >> here. The LTC2140 is specified to have a +/-10µV/°C drift (at 1Vpp
> >> setting).
> >> Converted into phase error due to zero crossing shift, this turns into
> >> a phase shift of +/-1ps/°C @ 10MHz. Note, the shift is given as +/- and
> >> per channel, which means, it could very well be that the channels are
> >> not matched in their temperature characteristics and thus the total
> phase
> >> shift could be +/-2ps/°C ... though total shift being closer to
> 0.5ps/°C is
> >> more likely.
> >>
> >> Summa sumarum: DC offset correction is important if a zero crossing
> >> detector is used.
> >>
> >>Attila Kinali
> >>
> >> --
> >> The bad part of Zurich is where the degenerates
> >>throw DARK chocolate at you.
> >>
> >> ___
> >> time-nuts mailing list -- time-nuts@lists.febo.com
> >> To unsubscribe, go to
> >> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> >> and follow the instructions there.
> >>
> > ___
> > time-nuts mailing list -- time-nuts@lists.febo.com
> > To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
>
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Bob kb8tq via time-nuts]

Hi

What does the temperature coefficient of your “hardware HPF” filter caps look 
like?
Are they a type that has significant hysteresis?

Bob

> On Feb 23, 2020, at 3:05 PM, Jan-Derk Bakker via time-nuts 
>  wrote:
> 
> Dear Attila,
> 
> Thanks for the heads up.
> 
> I am currently using a HPF both in hardware (capacitive coupling into the
> balun driving the ADC inputs) and in software before the ZCD. This should
> counteract the first-order effects of this offset, although second-order
> effects (converter nonlinearity et al) will of course still be an issue.
> The plots you've quoted include (different kinds of) DC offset correction
> for all but the "unfiltered" data; getting an efficient DC offset
> correction working in real time on this 8-bit platform was indeed one of
> the main challenges of the software-only approach.
> 
> The FPGA daughterboard is currently in production at Eurocircuits; I hope
> to have time to work on those the coming month. I'll also try to book some
> time in our climate chamber. (I've had one of our GPSDO-designs running in
> our general labs since before Christmas; surrounding it with bottles of
> water works well enough to low pass filter temperature swings, but I still
> see 6 degrees C swings overnight as out HVAC only runs during business
> hours.)
> 
> To be continued,
> 
> JDB.
> 
> On Sun, Feb 23, 2020 at 8:11 PM Attila Kinali via time-nuts <
> time-nuts@lists.febo.com> wrote:
> 
>> Good evening!
>> 
>> I'm going through some old stuff...
>> 
>> 
>> On Wed, 27 Nov 2019 00:29:19 +0100
>> Jan-Derk Bakker  wrote:
>> 
>>> This has yielded a combined "simple" signal
>>> processing path of a differentiator, a double comb filter and the offset
>>> estimator, which is getting very close in performance to the "ideal" band
>>> pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the
>> BPF;
>>> full plot:
>>> 
>> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
>>> for this 60-second recording:
>>> 
>> http://www.lartmaker.nl/time-nuts/600ksec%20run%20with%20PLL,%2010811%20through%20splitter.png
>>> . OADEV past ~1000sec is severely compromised by the fact that the
>>> measurement setup is in my home lab which sees temperature swings of up
>> to
>>> 20 degrees C and which does get bumped from time to time. Longer runs in
>> a
>>> more controlled setting forthcoming).
>> 
>> 
>> I can offer an explanation for the large effect of the zero correction seen
>> here. The LTC2140 is specified to have a +/-10µV/°C drift (at 1Vpp
>> setting).
>> Converted into phase error due to zero crossing shift, this turns into
>> a phase shift of +/-1ps/°C @ 10MHz. Note, the shift is given as +/- and
>> per channel, which means, it could very well be that the channels are
>> not matched in their temperature characteristics and thus the total phase
>> shift could be +/-2ps/°C ... though total shift being closer to 0.5ps/°C is
>> more likely.
>> 
>> Summa sumarum: DC offset correction is important if a zero crossing
>> detector is used.
>> 
>>Attila Kinali
>> 
>> --
>> The bad part of Zurich is where the degenerates
>>throw DARK chocolate at you.
>> 
>> ___
>> time-nuts mailing list -- time-nuts@lists.febo.com
>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
>> 
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker via time-nuts]

Dear Attila,

Thanks for the heads up.

I am currently using a HPF both in hardware (capacitive coupling into the
balun driving the ADC inputs) and in software before the ZCD. This should
counteract the first-order effects of this offset, although second-order
effects (converter nonlinearity et al) will of course still be an issue.
The plots you've quoted include (different kinds of) DC offset correction
for all but the "unfiltered" data; getting an efficient DC offset
correction working in real time on this 8-bit platform was indeed one of
the main challenges of the software-only approach.

The FPGA daughterboard is currently in production at Eurocircuits; I hope
to have time to work on those the coming month. I'll also try to book some
time in our climate chamber. (I've had one of our GPSDO-designs running in
our general labs since before Christmas; surrounding it with bottles of
water works well enough to low pass filter temperature swings, but I still
see 6 degrees C swings overnight as out HVAC only runs during business
hours.)

To be continued,

JDB.

On Sun, Feb 23, 2020 at 8:11 PM Attila Kinali via time-nuts <
time-nuts@lists.febo.com> wrote:

> Good evening!
>
> I'm going through some old stuff...
>
>
> On Wed, 27 Nov 2019 00:29:19 +0100
> Jan-Derk Bakker  wrote:
>
> > This has yielded a combined "simple" signal
> > processing path of a differentiator, a double comb filter and the offset
> > estimator, which is getting very close in performance to the "ideal" band
> > pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the
> BPF;
> > full plot:
> >
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
> > for this 60-second recording:
> >
> http://www.lartmaker.nl/time-nuts/600ksec%20run%20with%20PLL,%2010811%20through%20splitter.png
> > . OADEV past ~1000sec is severely compromised by the fact that the
> > measurement setup is in my home lab which sees temperature swings of up
> to
> > 20 degrees C and which does get bumped from time to time. Longer runs in
> a
> > more controlled setting forthcoming).
>
>
> I can offer an explanation for the large effect of the zero correction seen
> here. The LTC2140 is specified to have a +/-10µV/°C drift (at 1Vpp
> setting).
> Converted into phase error due to zero crossing shift, this turns into
> a phase shift of +/-1ps/°C @ 10MHz. Note, the shift is given as +/- and
> per channel, which means, it could very well be that the channels are
> not matched in their temperature characteristics and thus the total phase
> shift could be +/-2ps/°C ... though total shift being closer to 0.5ps/°C is
> more likely.
>
> Summa sumarum: DC offset correction is important if a zero crossing
> detector is used.
>
> Attila Kinali
>
> --
> The bad part of Zurich is where the degenerates
> throw DARK chocolate at you.
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Bob kb8tq via time-nuts]

Hi

Since most mixers also have DC offset issues, it is pretty common to high pass 
filter 
the signal before you try to hit a limiter.  Yes, this can bring in other 
issues, but the
net result is commonly a “win”. 

Bob


> On Feb 23, 2020, at 2:10 PM, Attila Kinali via time-nuts 
>  wrote:
> 
> Good evening!
> 
> I'm going through some old stuff...
> 
> 
> On Wed, 27 Nov 2019 00:29:19 +0100
> Jan-Derk Bakker  wrote:
> 
>> This has yielded a combined "simple" signal
>> processing path of a differentiator, a double comb filter and the offset
>> estimator, which is getting very close in performance to the "ideal" band
>> pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the BPF;
>> full plot:
>> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
>> for this 60-second recording:
>> http://www.lartmaker.nl/time-nuts/600ksec%20run%20with%20PLL,%2010811%20through%20splitter.png
>> . OADEV past ~1000sec is severely compromised by the fact that the
>> measurement setup is in my home lab which sees temperature swings of up to
>> 20 degrees C and which does get bumped from time to time. Longer runs in a
>> more controlled setting forthcoming).
> 
> 
> I can offer an explanation for the large effect of the zero correction seen
> here. The LTC2140 is specified to have a +/-10µV/°C drift (at 1Vpp setting).
> Converted into phase error due to zero crossing shift, this turns into
> a phase shift of +/-1ps/°C @ 10MHz. Note, the shift is given as +/- and
> per channel, which means, it could very well be that the channels are
> not matched in their temperature characteristics and thus the total phase
> shift could be +/-2ps/°C ... though total shift being closer to 0.5ps/°C is
> more likely.
> 
> Summa sumarum: DC offset correction is important if a zero crossing
> detector is used.
> 
>   Attila Kinali
> 
> -- 
>   The bad part of Zurich is where the degenerates
>throw DARK chocolate at you.
> 
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Joseph Gwinn]

Re: time-nuts Digest, Vol 184, Issue 40
On Fri, 29 Nov 2019 20:37:02 -0500, time-nuts-requ...@lists.febo.com 
wrote:

[snip]
> Message: 6
> Date: Fri, 29 Nov 2019 20:37:16 +0100
> From: Gerhard Hoffmann 
> To: time-nuts@lists.febo.com
> Subject: Re: [time-nuts] A simple sampling DMTD
> Message-ID: 
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Am 29.11.19 um 11:45 schrieb Jan-Derk Bakker:
>> In general: as much as I like having it in my toolbox, I don't see how
>> using an FFT would be the best tool for the job in a zero-crossing detector
>> for a DMTD, let alone this particular sampling DMTD. For one, this 8-bit
>> processor doesn't have the spare cycles to run FFTs on the 32-bit data I
>> get from my CIC^2 decimator; besides that, I would only be interested in a
>> single bin (the beat frequency), where it would be more efficient to simply
>> I/Q-demodulate the samples in software (O(N) vs O(N log N)). While I admit
>> that in the latter case windowing would help, at this point I/Q
>> demodulating (effectively calculating only a single bin of the DFT) does
>> not appear to have advantages over least squares fitting the arcsine of the
>> incoming samples. Am I missing something here?
> 
> I admit that I did not follow this thread closely, but the Goerzel filter 
> is the single output line DFT , with O(n).
> 
> 
<https://www.mathworks.com/help/signal/ref/goertzel.html;jsessionid=8816f77eb76ad7dd1913c7021698>
> 
> https://en.wikipedia.org/wiki/Goertzel_algorithm ??? >
> 
> If you need to simulate floats, fractional integers are easiest.
> I/Q demodulation probably requires to recreate a clean carrier if you want
> absolute phase and not only relative jumps. That sounds more like FPGA
> than 8051, or whatever the 8 bit processor of the day may be.
> 
> regards, Gerhard
> 
> 
> 
> OK, in a previous life I did build a system for geophysics, where they fed
> dangerous amounts of AC into the soil and measured the potential at
> some 50 nodes. Rubber boots required.
> Each node had a 8951 to control some switches and communicate setups.
> They were most excited when I gave them the sources so they could
> implement FFT pre-processing locally on each node themselves. 
> That required willingness to suffer.
> 
   
   
I must say that the above all seems to me to be more complex than 
needed.  

The fundamental problem to be solved is to estimate the phases of two 
beatnotes, one per channel (ref, signal under test), the phase 
difference being converted into a relative time delay.  So, we are 
estimating phase twice, against an unknown but common internal 
reference, and the key question here is how best to measure those two 
phases.  Detection of zero crossings is one way, but there are others. 

We know the frequencies of the beatnotes quite accurately, and that the 
waveforms are sine waves (which we will have band-pass filtered in 
hardware before conversion to digital data).  Here, I will assume that 
the frequencies are the same.  The only free variables are thus 
amplitude and phase; these can be estimated using least squares applied 
to successive batches of I samples.  Windowing is still useful to 
reduce end splice effects, as previously discussed.  Given that we are 
working in the numerical domain, it's probably adequate to apply the 
window function to the product of the proposed match and the actual 
data, and then sum the windowed products.

As a quality check, if the estimated amplitude is too small (or too 
large), reject the phase estimate and try again.  If this condition 
persists too long or becomes too common, something is broken.

I doubt that anything of the 8-bit class is practical for this, and 
certainly not for a small-volume product, because programming effort 
increases sharply if the chosen processor is too limited.  Ardinuo and 
maybe StrawberryPi seem more like it.

As for emulation of floating point, the least-squares algorithm defined 
above can certainly be implemented in fixed-point arithmetic, called 
fractional integers above.  
<https://en.wikipedia.org/wiki/Fixed-point_arithmetic>

In the extreme, this kind of algorithm will work with data clipped to a 
few bits per sample.  The underwater sonar folk are masters of this, 
especially back in the days when signal processors were necessarily 
bespoke hardware.  The search term is "one-bit correlator" (without the 
quotes).

Joe

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Gerhard Hoffmann]

Am 29.11.19 um 11:45 schrieb Jan-Derk Bakker:

In general: as much as I like having it in my toolbox, I don't see how
using an FFT would be the best tool for the job in a zero-crossing detector
for a DMTD, let alone this particular sampling DMTD. For one, this 8-bit
processor doesn't have the spare cycles to run FFTs on the 32-bit data I
get from my CIC^2 decimator; besides that, I would only be interested in a
single bin (the beat frequency), where it would be more efficient to simply
I/Q-demodulate the samples in software (O(N) vs O(N log N)). While I admit
that in the latter case windowing would help, at this point I/Q
demodulating (effectively calculating only a single bin of the DFT) does
not appear to have advantages over least squares fitting the arcsine of the
incoming samples. Am I missing something here?


I admit that I did not follow this thread closely, but the Goerzel filter

is the single output line DFT , with O(n).

< 
https://www.mathworks.com/help/signal/ref/goertzel.html;jsessionid=8816f77eb76ad7dd1913c7021698 
>


<   https://en.wikipedia.org/wiki/Goertzel_algorithm     >

If you need to simulate floats, fractional integers are easiest.

I/Q demodulation probably requires to recreate a clean carrier if you want

absolute phase and not only relative jumps. That sounds more like FPGA

than 8051, or whatever the 8 bit processor of the day may be.

regards, Gerhard



OK, in a previous life I did build a system for geophysics, where they fed

dangerous amounts of AC into the soil and measured the potential at

some 50 nodes. Rubber boots required.

Each node had a 8951 to control some switches and communicate setups.

They were most exited when I gave them the sources so they could

implement FFT pre-processing locally on each node themselves.

That required willingness to suffer.




___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Dear Magnus,

Removing the slope between the two sample end points (or: trimming/adding
the fractional sample part of the period) is the point of the estimator I
posted earlier (
http://lists.febo.com/pipermail/time-nuts_lists.febo.com/2019-November/098450.html
).

In general: as much as I like having it in my toolbox, I don't see how
using an FFT would be the best tool for the job in a zero-crossing detector
for a DMTD, let alone this particular sampling DMTD. For one, this 8-bit
processor doesn't have the spare cycles to run FFTs on the 32-bit data I
get from my CIC^2 decimator; besides that, I would only be interested in a
single bin (the beat frequency), where it would be more efficient to simply
I/Q-demodulate the samples in software (O(N) vs O(N log N)). While I admit
that in the latter case windowing would help, at this point I/Q
demodulating (effectively calculating only a single bin of the DFT) does
not appear to have advantages over least squares fitting the arcsine of the
incoming samples. Am I missing something here?

Sincerely,

JDB.

On Fri, Nov 29, 2019 at 2:32 AM Magnus Danielson  wrote:

> Hi,
>
> On 2019-11-28 21:18, Joseph Gwinn wrote:
> > JD,
> >
> > I'll have to think about it, but I will mention that with batch
> > processing using window functions, it's common to precede the FFT using
> > a simple FIR filter to eliminate the low-frequency energy (due to
> > clutter, DC leakage/offset et al), the problem being that the FFT alone
> > may not have sufficient rejection to prevent low-frequency energy
> > breakthrough.
> >
> > An alternate approach is to compute the mean of the windowed data and
> > subtract that mean from all samples in the window before computing the
> > FFT.  In analog terms, this is like a big coupling capacitor blocking
> > DC.
>
> You also wants to remove the slope between the two sample end-points, or
> else that slope represents an in-phase sawtooth function. A
> window-function tends to do that.
>
> Cheers,
> Magnus
>
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Magnus Danielson]

Hi,

On 2019-11-28 21:18, Joseph Gwinn wrote:
> JD,
>
> I'll have to think about it, but I will mention that with batch 
> processing using window functions, it's common to precede the FFT using 
> a simple FIR filter to eliminate the low-frequency energy (due to 
> clutter, DC leakage/offset et al), the problem being that the FFT alone 
> may not have sufficient rejection to prevent low-frequency energy 
> breakthrough.
>
> An alternate approach is to compute the mean of the windowed data and 
> subtract that mean from all samples in the window before computing the 
> FFT.  In analog terms, this is like a big coupling capacitor blocking 
> DC.

You also wants to remove the slope between the two sample end-points, or
else that slope represents an in-phase sawtooth function. A
window-function tends to do that.

Cheers,
Magnus


___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Joseph Gwinn]

JD,

On Thu, 28 Nov 2019 12:00:01 -0500, time-nuts-requ...@lists.febo.com 
wrote:
> Send time-nuts mailing list submissions to
>   time-nuts@lists.febo.com
> 
> To subscribe or unsubscribe via the World Wide Web, visit
>   http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> or, via email, send a message with subject or body 'help' to
>   time-nuts-requ...@lists.febo.com
> 
> You can reach the person managing the list at
>   time-nuts-ow...@lists.febo.com
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of time-nuts digest..."
> 
> 
> Today's Topics:
> 
>1. Re: A simple sampling DMTD (Jan-Derk Bakker)
> 
> 
> --
> 
> Message: 1
> Date: Wed, 27 Nov 2019 23:46:32 +0100
> From: Jan-Derk Bakker 
> To: Discussion of precise time and frequency measurement
>   
> Subject: Re: [time-nuts] A simple sampling DMTD
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> Dear Joe,
> 
> On Wed, Nov 27, 2019 at 7:22 PM Joseph Gwinn  wrote:
> 
>>> [snip]
>>> The 1001-point FIR band pass filter is a good reference to get an idea of
>>> the best case performance of the system, but it is computationally
>>> infeasible to run on an 8-bit processor. While a cheap comb filter can
>> take
>>> a bite out of the HF noise, canceling offset/drift is harder. Early on I
>>> was looking into ways to average all samples of a single period of the
>> beat
>>> note, but I had trouble finding a closed form solution to the fact that
>> the
>>> beat note period is never an exact integer multiple of the sampling rate.
>>> Through numerical methods I did end up finding a good estimator for the
>>> "leakthrough" caused by the fractional part of the beat note period (as a
>>> function of the measured period and the phase offset), which was fairly
>>> inexpensive to implement. [snip]
>> 
>> In the radar world, the standard solution to the leakthrough problem is
>> to batch the data and apply a windowing function to the data in each
>> batch.  Typically, the batches overlap such that every sample appears
>> in two batches.  The window functions largely eliminate the splice
>> error due to the FFT, which in fact splices each batch into a circle,
>> causing a discontinuity at the splice.  If the window function is very
>> small at the splice, there is little discontinuity power sprayed into
>> innocent FFT bins.
>> 
> 
> This is an interesting approach, and one which hadn't occurred to me while
> I was working on the offset/drift cancellation. After some consideration I
> am afraid it will not help much in this particular case.
> 
> What I want is to filter out as much DC/LF energy before running the zero
> crossing detector (ZCD) on the rising edge of the sampled sine wave. To do
> this right now I also run the ZCD on falling edges, and I remember the
> (sub)sample position of the current and previous falling edges. I then
> average a full nominal period of the sine wave between these two falling
> edges(200 samples at 10Hz beat frequency and 2ksps after the first sinc^2
> filter/decimator), to determine the offset at the rising edge in between.
> This is indeed mathematically equivalent to calculating bin 0 of a forward
> Fourier transform with a rectangular window. Because the actual period is
> not an exact integer number of samples, in practice this bin is
> contaminated by spectral leakage. Windowing would help here, if it weren't
> for the fact that all of my wanted signal energy is in bin 1. As any
> windowing function other than the rectangular window trades side-lobe
> suppression for main lobe width, the cure would likely be worse than the
> disease. This could be ameliorated by averaging over multiple periods
> (increasing the transform length), but that would necessarily spread the LF
> noise energy over multiple bins, again making it all but impossible to get
> optimal rejection.
> 
> What I've done instead is make an estimator for the leakage. For a period
> of 200 +/- 1 sample, the following has an estimator error of better than
> -40dB:
> 
>   alpha = 0.5*perOffset^2 + (1.5 - phase)*perOffset - phase
>   correction = (1-alpha) * pointN + alpha * pointN1
> 
> where
> 
>   correction is the estimator (in sample values)
>   perOffset is the difference between the measured period (199...201
> samples) and the nominal period (200 samples)
>   phase is the estimated starting phase of the averaging interval, in
> fractional samples (range: [0,1

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Dear Joe,

On Wed, Nov 27, 2019 at 7:22 PM Joseph Gwinn  wrote:

> > [snip]
> > The 1001-point FIR band pass filter is a good reference to get an idea of
> > the best case performance of the system, but it is computationally
> > infeasible to run on an 8-bit processor. While a cheap comb filter can
> take
> > a bite out of the HF noise, canceling offset/drift is harder. Early on I
> > was looking into ways to average all samples of a single period of the
> beat
> > note, but I had trouble finding a closed form solution to the fact that
> the
> > beat note period is never an exact integer multiple of the sampling rate.
> > Through numerical methods I did end up finding a good estimator for the
> > "leakthrough" caused by the fractional part of the beat note period (as a
> > function of the measured period and the phase offset), which was fairly
> > inexpensive to implement. [snip]
>
> In the radar world, the standard solution to the leakthrough problem is
> to batch the data and apply a windowing function to the data in each
> batch.  Typically, the batches overlap such that every sample appears
> in two batches.  The window functions largely eliminate the splice
> error due to the FFT, which is fact splices each batch into a circle,
> causing a discontinuity at the splice.  If the window function is very
> small at the splice, there is little discontinuity power sprayed into
> innocent FFT bins.
>

This is an interesting approach, and one which hadn't occurred to me while
I was working on the offset/drift cancellation. After some consideration I
am afraid it will not help much in this particular case.

What I want is to filter out as much DC/LF energy before running the zero
crossing detector (ZCD) on the rising edge of the sampled sine wave. To do
this right now I also run the ZCD on falling edges, and I remember the
(sub)sample position of the current and previous falling edges. I then
average a full nominal period of the sine wave between these two falling
edges(200 samples at 10Hz beat frequency and 2ksps after the first sinc^2
filter/decimator), to determine the offset at the rising edge in between.
This is indeed mathematically equivalent to calculating bin 0 of a forward
Fourier transform with a rectangular window. Because the actual period is
not an exact integer number of samples, in practice this bin is
contaminated by spectral leakage. Windowing would help here, if it weren't
for the fact that all of my wanted signal energy is in bin 1. As any
windowing function other than the rectangular window trades side-lobe
suppression for main lobe width, the cure would likely be worse than the
disease. This could be ameliorated by averaging over multiple periods
(increasing the transform length), but that would necessarily spread the LF
noise energy over multiple bins, again making it all but impossible to get
optimal rejection.

What I've done instead is make an estimator for the leakage. For a period
of 200 +/- 1 sample, the following has an estimator error of better than
-40dB:

  alpha = 0.5*perOffset^2 + (1.5 - phase)*perOffset - phase
  correction = (1-alpha) * pointN + alpha * pointN1

where

  correction is the estimator (in sample values)
  perOffset is the difference between the measured period (199...201
samples) and the nominal period (200 samples)
  phase is the estimated starting phase of the averaging interval, in
fractional samples (range: [0,1>)
  pointN is the value of the sample immediately after the averaging
interval (ie sample[200], when the averaging interval is
sum(sample[0]...sample[199])
  pointN1 is the value of the second sample after the averaging interval
(ie sample[201]).

This works very well, both on simulated and actual data. I am embarrassed
to admit that I cannot explain *why* it must be this particular formula
(and I'm very open to get hints here).

Sincerely,

JD 'if you can't do the math, run simulations and do curve fits until it
works' B.
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Joseph Gwinn]

Re: time-nuts Digest, Vol 184, Issue 35
On Wed, 27 Nov 2019 12:00:02 -0500, time-nuts-requ...@lists.febo.com 
wrote:

> 
> Message: 8
> Date: Wed, 27 Nov 2019 00:29:19 +0100
> From: Jan-Derk Bakker 
> To: Discussion of precise time and frequency measurement
>   
> Subject: Re: [time-nuts] A simple sampling DMTD
> Message-ID:
>   
> Content-Type: text/plain; charset="UTF-8"
> 
> [This thread has started about three months ago; first post with design
> considerations is here:
> https://www.mail-archive.com/time-nuts@lists.febo.com/msg04265.html ]
> 
> Dear all,
> 
> In the past month I have managed to get the PLL working, and found a
> lightweight way to eliminate most if not all of the offset/drift.
> 
> After the discussions with Attila and Bob I have expanded the PLL bandwidth
> to 0.5Hz (with a 10Hz PFD frequency I can't go very much higher). The
> damping factor is 0.7 for now; I intend to do more tests on how an
> increased damping affects the ZCD. To get sufficient ECD drive resolution I
> have implemented a 3rd order multibit sigma/delta modulator driving a
> 12-bit ADC (with passive filtering and active buffering). The result of the
> measured beat note period can be seen at
> 
http://www.lartmaker.nl/time-nuts/PSD%20of%20measured%20ZCD%20period%20with%20PLL%20active.pdf
> ; peaking is shown to be limited.
> 
> With an active PLL the beat note spectrum became much narrower (compare
> 
http://www.lartmaker.nl/time-nuts/PSD%20of%20HP10811%20into%20the%20LTC2140%20with%20PLL%20active.pdf
> to
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20input%20spectrum.pdf
> ). This made it possible to use a comb filter to suppress even-order
> harmonics (before adding hardware notch filtering at the input).
> 
> The 1001-point FIR band pass filter is a good reference to get an idea of
> the best case performance of the system, but it is computationally
> infeasible to run on an 8-bit processor. While a cheap comb filter can take
> a bite out of the HF noise, canceling offset/drift is harder. Early on I
> was looking into ways to average all samples of a single period of the beat
> note, but I had trouble finding a closed form solution to the fact that the
> beat note period is never an exact integer multiple of the sampling rate.
> Through numerical methods I did end up finding a good estimator for the
> "leakthrough" caused by the fractional part of the beat note period (as a
> function of the measured period and the phase offset), which was fairly
> inexpensive to implement. This has yielded a combined "simple" signal
> processing path of a differentiator, a double comb filter and the offset
> estimator, which is getting very close in performance to the "ideal" band
> pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the BPF;
> full plot:
> 
http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
> for this 60-second recording:
> 
http://www.lartmaker.nl/time-nuts/600ksec%20run%20with%20PLL,%2010811%20through%20splitter.png
> . OADEV past ~1000sec is severely compromised by the fact that the
> measurement setup is in my home lab which sees temperature swings of up to
> 20 degrees C and which does get bumped from time to time. Longer runs in a
> more controlled setting forthcoming).

In the radar world, the standard solution to the leakthrough problem is 
to batch the data and apply a windowing function to the data in each 
batch.  Typically, the batches overlap such that every sample appears 
in two batches.  The window functions largely eliminate the splice 
error due to the FFT, which is fact splices each batch into a circle, 
causing a discontinuity at the splice.  If the window function is very 
small at the splice, there is little discontinuity power sprayed into 
innocent FFT bins.

In radar, Taylor windows are used, as well as Dolph-Chebyshev if very 
low sidelobes are needed.

.<https://en.wikipedia.org/wiki/Window_function#Dolph%E2%80%93Chebyshev_window>

Taylor is mentioned in the above D-C description, and a link is 
provided.

Joe Gwinn

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

[This thread has started about three months ago; first post with design
considerations is here:
https://www.mail-archive.com/time-nuts@lists.febo.com/msg04265.html ]

Dear all,

In the past month I have managed to get the PLL working, and found a
lightweight way to eliminate most if not all of the offset/drift.

After the discussions with Attila and Bob I have expanded the PLL bandwidth
to 0.5Hz (with a 10Hz PFD frequency I can't go very much higher). The
damping factor is 0.7 for now; I intend to do more tests on how an
increased damping affects the ZCD. To get sufficient ECD drive resolution I
have implemented a 3rd order multibit sigma/delta modulator driving a
12-bit ADC (with passive filtering and active buffering). The result of the
measured beat note period can be seen at
http://www.lartmaker.nl/time-nuts/PSD%20of%20measured%20ZCD%20period%20with%20PLL%20active.pdf
; peaking is shown to be limited.

With an active PLL the beat note spectrum became much narrower (compare
http://www.lartmaker.nl/time-nuts/PSD%20of%20HP10811%20into%20the%20LTC2140%20with%20PLL%20active.pdf
to
http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20input%20spectrum.pdf
). This made it possible to use a comb filter to suppress even-order
harmonics (before adding hardware notch filtering at the input).

The 1001-point FIR band pass filter is a good reference to get an idea of
the best case performance of the system, but it is computationally
infeasible to run on an 8-bit processor. While a cheap comb filter can take
a bite out of the HF noise, canceling offset/drift is harder. Early on I
was looking into ways to average all samples of a single period of the beat
note, but I had trouble finding a closed form solution to the fact that the
beat note period is never an exact integer multiple of the sampling rate.
Through numerical methods I did end up finding a good estimator for the
"leakthrough" caused by the fractional part of the beat note period (as a
function of the measured period and the phase offset), which was fairly
inexpensive to implement. This has yielded a combined "simple" signal
processing path of a differentiator, a double comb filter and the offset
estimator, which is getting very close in performance to the "ideal" band
pass filter (OADEV of 3.77e-13@tau=1s versus 3.25e-13@tau=1s for the BPF;
full plot:
http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20OADEV%20with%20PLL%20and%20various%20filters.pdf
for this 60-second recording:
http://www.lartmaker.nl/time-nuts/600ksec%20run%20with%20PLL,%2010811%20through%20splitter.png
. OADEV past ~1000sec is severely compromised by the fact that the
measurement setup is in my home lab which sees temperature swings of up to
20 degrees C and which does get bumped from time to time. Longer runs in a
more controlled setting forthcoming).

One thing that I didn't expect (but which is obvious in retrospect): the
more filtering before the ZCD, the smaller the effect of adding more points
to the least squares ZCD curve fitting.

As far as I'm concerned this is as good as the microcontroller-only DMTD is
going to get (and not many applications will *need* better performance). I
will be implementing the FPGA daughterboard which I expect will improve the
performance by a factor of 10 (if only by averaging all 100 samples rather
than just dropping 99 of them), mostly because it makes comparing sources
with different frequencies much easier (which is one of my use cases).

Any suggestions?

Once again to be continued,

JDB.

On Sun, Nov 3, 2019 at 1:41 AM Jan-Derk Bakker  wrote:

> Dear all,
>
> Attila got me thinking with his remark:
>
> I am a bit astonished by the high noise level you have. I would have
>> expected
>> this to yield something below 1ps, judging from what we got from what
>> Nicolas
>> acheived in his work on the sine exitation based TIC[1].
>
>
> ...and I realised that I'm expressing the error wrong. What I had
> calculated was the standard deviation of the entire signal (noise +
> drift/wander). For short time periods I do get sub-ps noise levels, even
> without correcting for LF/DC errors.
>
> It may make more sense to look at the Allan deviation. I've used tvb's
> adev1 tool ( http://www.leapsecond.com/tools/adev1.htm ), with a manual
> correction to accommodate the 10sps data. To investigate the effect of high
> pass filtering and attenuating even-order harmonics, I've generated
> 1001-point high pass and band pass FIR filters with GMeteor (
> http://gmeteor.sourceforge.net/ ; the odd size of 1001 points being the
> largest size I could reliably get the program to generate filter solutions
> for); the BPF was generated to have nulls at 20, 40, 60 and 80Hz. 10MHz was
> generated with an 10811 that had been powered up for three days after
> having been in storage for over a year, its output fed to a Mini-Circuits
> ZFSC-2-1 splitter, connected to the DMTD with two 3in semi-rigid cables.
> The test was run for 175k seconds (just over 2 days) in a very 

Re: [time-nuts] A simple sampling DMTD

[Bruce Griffiths]

Merely selecting every 100th sample throws away the opportunity to reduce the 
effective ADC noise by digital filtering before decimation.

Bruce
> On 05 November 2019 at 10:08 Jan-Derk Bakker  wrote:
> 
> 
> Dear Scott,
> 
> You are entirely correct, sampling at 100ksps is mathematically the same as
> sampling at 10Msps and then decimating by a factor of 100. The reason I'm
> doing it in this way is driven by two practical considerations:
> 
> - my ADC, the LTC2140 (selected for bandwidth, dynamic range, aperture
> jitter and availability) has a pipelined design and cannot be clocked as
> slow as 100ksps without degrading performance
> - my CPU, the Atmel/Microchip XMega (selected for its peripherals, toolset
> support and familiarity for both me and my students) is an 8-bit AVR
> running at 30MHz and cannot directly process 10Msps
> 
> A simple D-flipflop based decimator was the easiest way to bridge this gap.
> The DMTD design has connectors for a (forthcoming) FPGA daughterboard to
> properly sinc-filter (and I/Q demodulate and...) the incoming samples.
> 
> Sincerely,
> 
> JD 'walk first, then run' B.
> 
> On Mon, Nov 4, 2019 at 6:38 PM W7SLS  wrote:
> 
> > Hello,
> >
> > (It has been a more few years since I designed / developed DSP for
> > spectrum analyzers for a major company, thanks for your patience.)
> >
> > I recall that:
> >
> > sample @ fs -> decimate (toss samples) by a factor of N
> >
> > is equivalent to
> >
> > sample @ fs / N
> >
> > If we wanted a lower sample rate, we would:
> >
> > sample @ fs  -> lowpass filter at (say) 80% of (fs/2) / N ->
> > decimate
> >
> > Otherwise all of the energy > 50% of (fs / N) gets aliased into your data.
> >
> > Why not just sample at 100 kHz?
> >
> > What am I missing ?
> >
> > Thanks for considering,
> > Scott W7SLS
> >
> > > On Nov 3, 2019, at 12:59 PM, Jan-Derk Bakker  wrote:
> > >
> > > Is this not caused by the fact that I'm currently subsampling the ADC
> > > (conversion rate 10Msps, rate into the microcontroller 100ksps by
> > dropping
> > > 99 put of 100 samples)?
> >
> > ___
> > time-nuts mailing list -- time-nuts@lists.febo.com
> > To unsubscribe, go to
> > http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> > and follow the instructions there.
> >
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[W7SLS - Scott Scheirman]

JD,

Thanks for your cogent reply.  I appreciate it.

Best
Scott

Sent from my iPhone

> On Nov 4, 2019, at 5:03 PM, Jan-Derk Bakker  wrote:
> 
> Dear Scott,
> 
> You are entirely correct, sampling at 100ksps is mathematically the same as
> sampling at 10Msps and then decimating by a factor of 100. The reason I'm
> doing it in this way is driven by two practical considerations:
> 
> - my ADC, the LTC2140 (selected for bandwidth, dynamic range, aperture
> jitter and availability) has a pipelined design and cannot be clocked as
> slow as 100ksps without degrading performance
> - my CPU, the Atmel/Microchip XMega (selected for its peripherals, toolset
> support and familiarity for both me and my students) is an 8-bit AVR
> running at 30MHz and cannot directly process 10Msps
> 
> A simple D-flipflop based decimator was the easiest way to bridge this gap.
> The DMTD design has connectors for a (forthcoming) FPGA daughterboard to
> properly sinc-filter (and I/Q demodulate and...) the incoming samples.
> 
> Sincerely,
> 
> JD 'walk first, then run' B.
> 
>> On Mon, Nov 4, 2019 at 6:38 PM W7SLS  wrote:
>> 
>> Hello,
>> 
>> (It has been a more few years since I designed / developed DSP for
>> spectrum analyzers for a major company, thanks for your patience.)
>> 
>> I recall that:
>> 
>>sample @ fs -> decimate (toss samples) by a factor of N
>> 
>> is equivalent to
>> 
>>sample @ fs / N
>> 
>> If we wanted a lower sample rate, we would:
>> 
>>sample @ fs  -> lowpass filter at (say) 80% of (fs/2) / N ->
>> decimate
>> 
>> Otherwise all of the energy > 50% of (fs / N) gets aliased into your data.
>> 
>> Why not just sample at 100 kHz?
>> 
>> What am I missing ?
>> 
>> Thanks for considering,
>> Scott W7SLS
>> 
 On Nov 3, 2019, at 12:59 PM, Jan-Derk Bakker  wrote:
>>> 
>>> Is this not caused by the fact that I'm currently subsampling the ADC
>>> (conversion rate 10Msps, rate into the microcontroller 100ksps by
>> dropping
>>> 99 put of 100 samples)?
>> 
>> ___
>> time-nuts mailing list -- time-nuts@lists.febo.com
>> To unsubscribe, go to
>> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
>> and follow the instructions there.
>> 
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to 
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Dear Tobias,

Yeah, this thread has been going since late August. As far as I can tell
the best way to get it all in one go is at
https://www.mail-archive.com/time-nuts@lists.febo.com/msg04265.html ; the
main design considerations are listed in the first post.

As for the offset oscillator,I have two versions of the board built, one
with a Taitien TT-series VCTCXO (with which we've good experiences in a few
SDR/GPSDO-designs), and one with a Connor-Winfield DOC020V-series VCOCXO.
Both have ample EFC range to be shifted to 10MHz+10Hz. For the moment I'm
only doing self noise measurements, with an OCXO connected to both
measurement channels. I could not advise you on the suitability of the
HP8662/8663, not being familiar with these instruments.

Sincerely,

JDB.
[while I'm primarily developing this DMTD for use in my lab, I would still
be very happy to do an Open Hardware/Software release of the designs and/or
work with TAPR or others, should there be any demand]

On Mon, Nov 4, 2019 at 6:38 PM Tobias Pluess 
wrote:

> Hi Jan-Derk
>
> this is maybe a bit offtopic, but if you don't mind I would like to ask
> anyway:
> is this a DMTD system you have built yourself? I saw a lot of messages on
> this topic in the archive, but didn't find where it started.
> Since I would also like to do some clock stability measurements but don't
> have a HP 53131A or SR620, I thought the DMTD would be a good technique
> because it allows to measure picosecond phase errors without actually
> having a TIC with that resolution.
> I only have a HP 5335A and 5316A, both of which don't have very high
> resolution and are thus perhaps not suitable to measure stability of OCXOs,
> but with a DMTD, it could be possible.
> What oscillator do you use as the offset oscillator, and what is the
> reference you use?
> I wonder whether it would be possible to use a HP 8662A or 8663A low phase
> noise signal generator as the offset oscillator. Because these can be
> adjusted in frequency for a beat signal which is convenient to measure. And
> the phase noise or stability of the offset oscillator is not of very high
> importance in DMTD measurements.
>
> Best
> Tobias
> HB9FSX
>
> 
> From: time-nuts [time-nuts-boun...@lists.febo.com] on behalf of Jan-Derk
> Bakker [jdbak...@gmail.com]
> Sent: Monday, November 04, 2019 10:33
> To: Discussion of precise time and frequency measurement
> Subject: Re: [time-nuts] A simple sampling DMTD
>
> Dear Bob,
>
> I understand the general concern: perfect synchronization would potentially
> turn the Dual Mixer Time Difference system into a Single Mixer Time
> Difference setup. (Even with perfect synchronization, the dual-channel
> architecture would serve to attenuate the common mode component of the ADC
> aperture jitter and the rest of the front end).
>
> In the Sherman & Roberts NIST paper I mentioned earlier the authors use a
> 3kHz PLL loop bandwidth without apparent ill effect. From my measurements
> of the drift behavior of my VCTCXO I'm considering much lower bandwidths
> (10..50mHz, possibly even lower when I substitute a VCOCXO for the offset
> oscillator). While I feel this should be safe doing so, I admit I need to
> look harder at the underlying math (and pointers are always welcome).
>
> Sincerely,
>
> JDB.
>
>
>
> On Mon, Nov 4, 2019 at 3:00 AM Bob kb8tq  wrote:
>
> > Hi
> >
> > Yes, it only will be fully correlated well inside the loop bandwidth. The
> > loop bandwidth
> > normally used for this sort of thing is >> 1 Hz. By the time you start
> > doing ADEV, you
> > are in the correlated region.
> >
> > Bob
> >
> > > On Nov 3, 2019, at 3:42 PM, Jan-Derk Bakker 
> wrote:
> > >
> > > Hi Bob,
> > >
> > >> If you phase lock the downconversion reference, the VCXO noise that
> now
> > > is uncorrelated
> > >> between the channels will become correlated. That may make things
> worse
> > > rather
> > >> than better
> > >
> > > Does the impact not depend on the loop bandwidth and VCXO performance?
> > If I
> > > read it correctly, in "Oscillator metrology with software defined
> radio"
> > (
> > > https://aip.scitation.org/doi/10.1063/1.4950898 /
> > > https://arxiv.org/abs/1605.03505 , section B, first paragraph) the
> > authors
> > > implement a sampling DMTD on a USRP B210 SDR platform, with the local
> > VCXO
> > > PLL'ed to the input from their maser; I'm looking at a similar setup
> > (with
> > > the expected LO performance being significantly worse than the incoming
> > > signals).
> > >
>

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Dear Scott,

You are entirely correct, sampling at 100ksps is mathematically the same as
sampling at 10Msps and then decimating by a factor of 100. The reason I'm
doing it in this way is driven by two practical considerations:

- my ADC, the LTC2140 (selected for bandwidth, dynamic range, aperture
jitter and availability) has a pipelined design and cannot be clocked as
slow as 100ksps without degrading performance
- my CPU, the Atmel/Microchip XMega (selected for its peripherals, toolset
support and familiarity for both me and my students) is an 8-bit AVR
running at 30MHz and cannot directly process 10Msps

A simple D-flipflop based decimator was the easiest way to bridge this gap.
The DMTD design has connectors for a (forthcoming) FPGA daughterboard to
properly sinc-filter (and I/Q demodulate and...) the incoming samples.

Sincerely,

JD 'walk first, then run' B.

On Mon, Nov 4, 2019 at 6:38 PM W7SLS  wrote:

> Hello,
>
> (It has been a more few years since I designed / developed DSP for
> spectrum analyzers for a major company, thanks for your patience.)
>
> I recall that:
>
> sample @ fs -> decimate (toss samples) by a factor of N
>
> is equivalent to
>
> sample @ fs / N
>
> If we wanted a lower sample rate, we would:
>
> sample @ fs  -> lowpass filter at (say) 80% of (fs/2) / N ->
> decimate
>
> Otherwise all of the energy > 50% of (fs / N) gets aliased into your data.
>
> Why not just sample at 100 kHz?
>
> What am I missing ?
>
> Thanks for considering,
> Scott W7SLS
>
> > On Nov 3, 2019, at 12:59 PM, Jan-Derk Bakker  wrote:
> >
> > Is this not caused by the fact that I'm currently subsampling the ADC
> > (conversion rate 10Msps, rate into the microcontroller 100ksps by
> dropping
> > 99 put of 100 samples)?
>
> ___
> time-nuts mailing list -- time-nuts@lists.febo.com
> To unsubscribe, go to
> http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
> and follow the instructions there.
>
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Tobias Pluess]

Hi Jan-Derk

this is maybe a bit offtopic, but if you don't mind I would like to ask anyway:
is this a DMTD system you have built yourself? I saw a lot of messages on this 
topic in the archive, but didn't find where it started.
Since I would also like to do some clock stability measurements but don't have 
a HP 53131A or SR620, I thought the DMTD would be a good technique because it 
allows to measure picosecond phase errors without actually having a TIC with 
that resolution.
I only have a HP 5335A and 5316A, both of which don't have very high resolution 
and are thus perhaps not suitable to measure stability of OCXOs, but with a 
DMTD, it could be possible.
What oscillator do you use as the offset oscillator, and what is the reference 
you use?
I wonder whether it would be possible to use a HP 8662A or 8663A low phase 
noise signal generator as the offset oscillator. Because these can be adjusted 
in frequency for a beat signal which is convenient to measure. And the phase 
noise or stability of the offset oscillator is not of very high importance in 
DMTD measurements.

Best
Tobias
HB9FSX


From: time-nuts [time-nuts-boun...@lists.febo.com] on behalf of Jan-Derk Bakker 
[jdbak...@gmail.com]
Sent: Monday, November 04, 2019 10:33
To: Discussion of precise time and frequency measurement
Subject: Re: [time-nuts] A simple sampling DMTD

Dear Bob,

I understand the general concern: perfect synchronization would potentially
turn the Dual Mixer Time Difference system into a Single Mixer Time
Difference setup. (Even with perfect synchronization, the dual-channel
architecture would serve to attenuate the common mode component of the ADC
aperture jitter and the rest of the front end).

In the Sherman & Roberts NIST paper I mentioned earlier the authors use a
3kHz PLL loop bandwidth without apparent ill effect. From my measurements
of the drift behavior of my VCTCXO I'm considering much lower bandwidths
(10..50mHz, possibly even lower when I substitute a VCOCXO for the offset
oscillator). While I feel this should be safe doing so, I admit I need to
look harder at the underlying math (and pointers are always welcome).

Sincerely,

JDB.



On Mon, Nov 4, 2019 at 3:00 AM Bob kb8tq  wrote:

> Hi
>
> Yes, it only will be fully correlated well inside the loop bandwidth. The
> loop bandwidth
> normally used for this sort of thing is >> 1 Hz. By the time you start
> doing ADEV, you
> are in the correlated region.
>
> Bob
>
> > On Nov 3, 2019, at 3:42 PM, Jan-Derk Bakker  wrote:
> >
> > Hi Bob,
> >
> >> If you phase lock the downconversion reference, the VCXO noise that now
> > is uncorrelated
> >> between the channels will become correlated. That may make things worse
> > rather
> >> than better
> >
> > Does the impact not depend on the loop bandwidth and VCXO performance?
> If I
> > read it correctly, in "Oscillator metrology with software defined radio"
> (
> > https://aip.scitation.org/doi/10.1063/1.4950898 /
> > https://arxiv.org/abs/1605.03505 , section B, first paragraph) the
> authors
> > implement a sampling DMTD on a USRP B210 SDR platform, with the local
> VCXO
> > PLL'ed to the input from their maser; I'm looking at a similar setup
> (with
> > the expected LO performance being significantly worse than the incoming
> > signals).
> >
> > JDB.
> >
> > On Sun, Nov 3, 2019 at 2:40 PM Bob kb8tq  wrote:
> >
> >> Hi
> >>
> >>> On Nov 2, 2019, at 8:41 PM, Jan-Derk Bakker 
> wrote:
> >>>
> >>> Dear all,
> >>>
> >>> Attila got me thinking with his remark:
> >>>
> >>> I am a bit astonished by the high noise level you have. I would have
> >>>> expected
> >>>> this to yield something below 1ps, judging from what we got from what
> >>>> Nicolas
> >>>> acheived in his work on the sine exitation based TIC[1].
> >>>
> >>>
> >>> ...and I realised that I'm expressing the error wrong. What I had
> >>> calculated was the standard deviation of the entire signal (noise +
> >>> drift/wander). For short time periods I do get sub-ps noise levels,
> even
> >>> without correcting for LF/DC errors.
> >>>
> >>> It may make more sense to look at the Allan deviation. I've used tvb's
> >>> adev1 tool ( http://www.leapsecond.com/tools/adev1.htm ), with a
> manual
> >>> correction to accommodate the 10sps data. To investigate the effect of
> >> high
> >>> pass filtering and attenuating even-order harmonics, I've generated
> >>> 1001-point high pass and band pass FIR filters wi

Re: [time-nuts] A simple sampling DMTD

[W7SLS]

Hello,

(It has been a more few years since I designed / developed DSP for spectrum 
analyzers for a major company, thanks for your patience.)

I recall that:

sample @ fs -> decimate (toss samples) by a factor of N

is equivalent to

sample @ fs / N

If we wanted a lower sample rate, we would:

sample @ fs  -> lowpass filter at (say) 80% of (fs/2) / N -> decimate

Otherwise all of the energy > 50% of (fs / N) gets aliased into your data.

Why not just sample at 100 kHz?

What am I missing ?

Thanks for considering,
Scott W7SLS

> On Nov 3, 2019, at 12:59 PM, Jan-Derk Bakker  wrote:
> 
> Is this not caused by the fact that I'm currently subsampling the ADC
> (conversion rate 10Msps, rate into the microcontroller 100ksps by dropping
> 99 put of 100 samples)?

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Dear Bob,

I understand the general concern: perfect synchronization would potentially
turn the Dual Mixer Time Difference system into a Single Mixer Time
Difference setup. (Even with perfect synchronization, the dual-channel
architecture would serve to attenuate the common mode component of the ADC
aperture jitter and the rest of the front end).

In the Sherman & Roberts NIST paper I mentioned earlier the authors use a
3kHz PLL loop bandwidth without apparent ill effect. From my measurements
of the drift behavior of my VCTCXO I'm considering much lower bandwidths
(10..50mHz, possibly even lower when I substitute a VCOCXO for the offset
oscillator). While I feel this should be safe doing so, I admit I need to
look harder at the underlying math (and pointers are always welcome).

Sincerely,

JDB.



On Mon, Nov 4, 2019 at 3:00 AM Bob kb8tq  wrote:

> Hi
>
> Yes, it only will be fully correlated well inside the loop bandwidth. The
> loop bandwidth
> normally used for this sort of thing is >> 1 Hz. By the time you start
> doing ADEV, you
> are in the correlated region.
>
> Bob
>
> > On Nov 3, 2019, at 3:42 PM, Jan-Derk Bakker  wrote:
> >
> > Hi Bob,
> >
> >> If you phase lock the downconversion reference, the VCXO noise that now
> > is uncorrelated
> >> between the channels will become correlated. That may make things worse
> > rather
> >> than better
> >
> > Does the impact not depend on the loop bandwidth and VCXO performance?
> If I
> > read it correctly, in "Oscillator metrology with software defined radio"
> (
> > https://aip.scitation.org/doi/10.1063/1.4950898 /
> > https://arxiv.org/abs/1605.03505 , section B, first paragraph) the
> authors
> > implement a sampling DMTD on a USRP B210 SDR platform, with the local
> VCXO
> > PLL'ed to the input from their maser; I'm looking at a similar setup
> (with
> > the expected LO performance being significantly worse than the incoming
> > signals).
> >
> > JDB.
> >
> > On Sun, Nov 3, 2019 at 2:40 PM Bob kb8tq  wrote:
> >
> >> Hi
> >>
> >>> On Nov 2, 2019, at 8:41 PM, Jan-Derk Bakker 
> wrote:
> >>>
> >>> Dear all,
> >>>
> >>> Attila got me thinking with his remark:
> >>>
> >>> I am a bit astonished by the high noise level you have. I would have
>  expected
>  this to yield something below 1ps, judging from what we got from what
>  Nicolas
>  acheived in his work on the sine exitation based TIC[1].
> >>>
> >>>
> >>> ...and I realised that I'm expressing the error wrong. What I had
> >>> calculated was the standard deviation of the entire signal (noise +
> >>> drift/wander). For short time periods I do get sub-ps noise levels,
> even
> >>> without correcting for LF/DC errors.
> >>>
> >>> It may make more sense to look at the Allan deviation. I've used tvb's
> >>> adev1 tool ( http://www.leapsecond.com/tools/adev1.htm ), with a
> manual
> >>> correction to accommodate the 10sps data. To investigate the effect of
> >> high
> >>> pass filtering and attenuating even-order harmonics, I've generated
> >>> 1001-point high pass and band pass FIR filters with GMeteor (
> >>> http://gmeteor.sourceforge.net/ ; the odd size of 1001 points being
> the
> >>> largest size I could reliably get the program to generate filter
> >> solutions
> >>> for); the BPF was generated to have nulls at 20, 40, 60 and 80Hz. 10MHz
> >> was
> >>> generated with an 10811 that had been powered up for three days after
> >>> having been in storage for over a year, its output fed to a
> Mini-Circuits
> >>> ZFSC-2-1 splitter, connected to the DMTD with two 3in semi-rigid
> cables.
> >>> The test was run for 175k seconds (just over 2 days) in a very much
> >>> non-temperature controlled attic. The resulting ADEV can be found at
> >>> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20ADEV.pdf ; the
> >>> measured time difference between the channels is
> >>> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise.png ; the input
> >>> spectrum of channel 1 with and without the filters is
> >>>
> >>
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20input%20spectrum.pdf
> >>>
> >>> For tau=1s the Allan deviation without any filtering is 9.5E-13. High
> >> pass
> >>> filtering to eliminate LF noise and drift improves this to 4.6E-13;
> >> adding
> >>> bandpass filtering yields 3.2E-13. Out to 1000s the adev decreases
> >> linearly
> >>> with tau, after that performance degrades (further testing in a
> >> temperature
> >>> controlled room should show whether this is intrinsic or not).
> >>>
> >>> As the high pass filtering seems to have the largest impact, I plan to
> >>> implement this first (still based on averaging over a single period
> >>> centered around the rising flank of the sine; the on-board processor
> >>> doesn't have enough horsepower to run a 1001pt FIR at 2ksps). Next I
> want
> >>> to add code to phase lock the on-board VCTCXO to the reference input,
> >>
> >> If you phase lock the downconversion reference, the VCXO noise that now
> is
> >> uncorrelated
> >> between the 

Re: [time-nuts] A simple sampling DMTD

[Bob kb8tq]

Hi

Yes, it only will be fully correlated well inside the loop bandwidth. The loop 
bandwidth 
normally used for this sort of thing is >> 1 Hz. By the time you start doing 
ADEV, you
are in the correlated region.

Bob

> On Nov 3, 2019, at 3:42 PM, Jan-Derk Bakker  wrote:
> 
> Hi Bob,
> 
>> If you phase lock the downconversion reference, the VCXO noise that now
> is uncorrelated
>> between the channels will become correlated. That may make things worse
> rather
>> than better
> 
> Does the impact not depend on the loop bandwidth and VCXO performance? If I
> read it correctly, in "Oscillator metrology with software defined radio" (
> https://aip.scitation.org/doi/10.1063/1.4950898 /
> https://arxiv.org/abs/1605.03505 , section B, first paragraph) the authors
> implement a sampling DMTD on a USRP B210 SDR platform, with the local VCXO
> PLL'ed to the input from their maser; I'm looking at a similar setup (with
> the expected LO performance being significantly worse than the incoming
> signals).
> 
> JDB.
> 
> On Sun, Nov 3, 2019 at 2:40 PM Bob kb8tq  wrote:
> 
>> Hi
>> 
>>> On Nov 2, 2019, at 8:41 PM, Jan-Derk Bakker  wrote:
>>> 
>>> Dear all,
>>> 
>>> Attila got me thinking with his remark:
>>> 
>>> I am a bit astonished by the high noise level you have. I would have
 expected
 this to yield something below 1ps, judging from what we got from what
 Nicolas
 acheived in his work on the sine exitation based TIC[1].
>>> 
>>> 
>>> ...and I realised that I'm expressing the error wrong. What I had
>>> calculated was the standard deviation of the entire signal (noise +
>>> drift/wander). For short time periods I do get sub-ps noise levels, even
>>> without correcting for LF/DC errors.
>>> 
>>> It may make more sense to look at the Allan deviation. I've used tvb's
>>> adev1 tool ( http://www.leapsecond.com/tools/adev1.htm ), with a manual
>>> correction to accommodate the 10sps data. To investigate the effect of
>> high
>>> pass filtering and attenuating even-order harmonics, I've generated
>>> 1001-point high pass and band pass FIR filters with GMeteor (
>>> http://gmeteor.sourceforge.net/ ; the odd size of 1001 points being the
>>> largest size I could reliably get the program to generate filter
>> solutions
>>> for); the BPF was generated to have nulls at 20, 40, 60 and 80Hz. 10MHz
>> was
>>> generated with an 10811 that had been powered up for three days after
>>> having been in storage for over a year, its output fed to a Mini-Circuits
>>> ZFSC-2-1 splitter, connected to the DMTD with two 3in semi-rigid cables.
>>> The test was run for 175k seconds (just over 2 days) in a very much
>>> non-temperature controlled attic. The resulting ADEV can be found at
>>> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20ADEV.pdf ; the
>>> measured time difference between the channels is
>>> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise.png ; the input
>>> spectrum of channel 1 with and without the filters is
>>> 
>> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20input%20spectrum.pdf
>>> 
>>> For tau=1s the Allan deviation without any filtering is 9.5E-13. High
>> pass
>>> filtering to eliminate LF noise and drift improves this to 4.6E-13;
>> adding
>>> bandpass filtering yields 3.2E-13. Out to 1000s the adev decreases
>> linearly
>>> with tau, after that performance degrades (further testing in a
>> temperature
>>> controlled room should show whether this is intrinsic or not).
>>> 
>>> As the high pass filtering seems to have the largest impact, I plan to
>>> implement this first (still based on averaging over a single period
>>> centered around the rising flank of the sine; the on-board processor
>>> doesn't have enough horsepower to run a 1001pt FIR at 2ksps). Next I want
>>> to add code to phase lock the on-board VCTCXO to the reference input,
>> 
>> If you phase lock the downconversion reference, the VCXO noise that now is
>> uncorrelated
>> between the channels will become correlated. That may make things worse
>> rather
>> than better
>> 
>> Bob
>> 
>>> this
>>> should also make it easy to implement a notch filter to eliminate (even)
>>> harmonics. After that I want to see if I can get a computationally
>>> efficient arcsin/arctan applied to the data, to make it easier to extend
>>> the number of samples used by the ZCD without running into linearity
>>> issues. Meanwhile I'm working on a daughterboard with twin Lattice iCE40
>>> FPGAs.
>>> 
>>> Any suggestions so far?
>>> 
>>> To be continued,
>>> 
>>> JDB.
>>> 
>>> 
>>> On Tue, Oct 22, 2019 at 12:33 AM Jan-Derk Bakker 
>> wrote:
>>> 
 Dear Attila,
 
 Thank you for your feedback, replies inline:
 
 On Tue, Oct 15, 2019 at 6:01 PM Attila Kinali  wrote:
 [snip]
 
> The biggest change I would make, would be to use a higher sampling
> frequency and use an FPGA with a CORDIC as phase detector. Especially
> as your goal is to measure the phase difference of a distribution
>> system,
> where the 

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Dear Attila,

> The test was run for 175k seconds (just over 2 days) in a very much
> > non-temperature controlled attic. The resulting ADEV can be found at
> > http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20ADEV.pdf ; the
>
> This looks good, but I would still expect the start of the ADEV plot,
> ie the precision of the single measurements to be about half an order
> to an order of magnitude lower. For comparison, commercial DMTD systems
> operate at about 1e-13 at 1s, which is mostly dominated by the mixer
> noise and temperature coefficient. I would expect you to be close to
> 1e-12 at 0.1s, even before filtering.
>

Is this not caused by the fact that I'm currently subsampling the ADC
(conversion rate 10Msps, rate into the microcontroller 100ksps by dropping
99 put of 100 samples)? In my simulations this accounts for almost exactly
20dB of noise (as expected). The FPGA board will make a filtered rate
reduction possible, of course.

(I'm also trying to find the balance between "perfect" and "good enough"
here. My original target was 1ps RMS; I'm hitting that even at 100ksps with
some light filtering. This DMTD is a means, not an end, and at some point I
will hit diminishing returns; engineering time spent on the DMTD cannot
also be spent on the phased array. Of course, I do try to get all low
hanging fruit before putting the DMTD into service.)



You do want the notch filters in front of the ADCs. Once the harmonics
> enter the system, they already contributed to noise conversion. Digital
> filtering helps only if you can completely separate the harmonics from
> the signal, which is not possible due to non-linearity of the ADC.
> So, I would suggest to have at least some filtering in the frontend
> and then clean up the rest in the digital domain.
>

Thanks, will put that on the list. This would have to be a separate
pluggable filter, as I need to support different input frequencies with the
same DMTD.

I don't remember what uC you are using, but CORDIC would be the way to
> go in most places, especially if you want lots of bits. You need something
> in the order of 2-5 stages more than you want output bits and about as
> many intermediate bits more.
>

Yes, I'm looking at CORDIC. The CPU I'm using, an Atmel/Microchip XMega,
doesn't have a barrel shifter; to speed up the ZCD I'm playing with an
unrolled CORDIC where I use the hardware multiplier instead.

Sincerely,

JDB.
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Hi Bob,

> If you phase lock the downconversion reference, the VCXO noise that now
is uncorrelated
> between the channels will become correlated. That may make things worse
rather
> than better

Does the impact not depend on the loop bandwidth and VCXO performance? If I
read it correctly, in "Oscillator metrology with software defined radio" (
https://aip.scitation.org/doi/10.1063/1.4950898 /
https://arxiv.org/abs/1605.03505 , section B, first paragraph) the authors
implement a sampling DMTD on a USRP B210 SDR platform, with the local VCXO
PLL'ed to the input from their maser; I'm looking at a similar setup (with
the expected LO performance being significantly worse than the incoming
signals).

JDB.

On Sun, Nov 3, 2019 at 2:40 PM Bob kb8tq  wrote:

> Hi
>
> > On Nov 2, 2019, at 8:41 PM, Jan-Derk Bakker  wrote:
> >
> > Dear all,
> >
> > Attila got me thinking with his remark:
> >
> > I am a bit astonished by the high noise level you have. I would have
> >> expected
> >> this to yield something below 1ps, judging from what we got from what
> >> Nicolas
> >> acheived in his work on the sine exitation based TIC[1].
> >
> >
> > ...and I realised that I'm expressing the error wrong. What I had
> > calculated was the standard deviation of the entire signal (noise +
> > drift/wander). For short time periods I do get sub-ps noise levels, even
> > without correcting for LF/DC errors.
> >
> > It may make more sense to look at the Allan deviation. I've used tvb's
> > adev1 tool ( http://www.leapsecond.com/tools/adev1.htm ), with a manual
> > correction to accommodate the 10sps data. To investigate the effect of
> high
> > pass filtering and attenuating even-order harmonics, I've generated
> > 1001-point high pass and band pass FIR filters with GMeteor (
> > http://gmeteor.sourceforge.net/ ; the odd size of 1001 points being the
> > largest size I could reliably get the program to generate filter
> solutions
> > for); the BPF was generated to have nulls at 20, 40, 60 and 80Hz. 10MHz
> was
> > generated with an 10811 that had been powered up for three days after
> > having been in storage for over a year, its output fed to a Mini-Circuits
> > ZFSC-2-1 splitter, connected to the DMTD with two 3in semi-rigid cables.
> > The test was run for 175k seconds (just over 2 days) in a very much
> > non-temperature controlled attic. The resulting ADEV can be found at
> > http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20ADEV.pdf ; the
> > measured time difference between the channels is
> > http://www.lartmaker.nl/time-nuts/DMTD%20self-noise.png ; the input
> > spectrum of channel 1 with and without the filters is
> >
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20input%20spectrum.pdf
> >
> > For tau=1s the Allan deviation without any filtering is 9.5E-13. High
> pass
> > filtering to eliminate LF noise and drift improves this to 4.6E-13;
> adding
> > bandpass filtering yields 3.2E-13. Out to 1000s the adev decreases
> linearly
> > with tau, after that performance degrades (further testing in a
> temperature
> > controlled room should show whether this is intrinsic or not).
> >
> > As the high pass filtering seems to have the largest impact, I plan to
> > implement this first (still based on averaging over a single period
> > centered around the rising flank of the sine; the on-board processor
> > doesn't have enough horsepower to run a 1001pt FIR at 2ksps). Next I want
> > to add code to phase lock the on-board VCTCXO to the reference input,
>
> If you phase lock the downconversion reference, the VCXO noise that now is
> uncorrelated
> between the channels will become correlated. That may make things worse
> rather
> than better
>
> Bob
>
> > this
> > should also make it easy to implement a notch filter to eliminate (even)
> > harmonics. After that I want to see if I can get a computationally
> > efficient arcsin/arctan applied to the data, to make it easier to extend
> > the number of samples used by the ZCD without running into linearity
> > issues. Meanwhile I'm working on a daughterboard with twin Lattice iCE40
> > FPGAs.
> >
> > Any suggestions so far?
> >
> > To be continued,
> >
> > JDB.
> >
> >
> > On Tue, Oct 22, 2019 at 12:33 AM Jan-Derk Bakker 
> wrote:
> >
> >> Dear Attila,
> >>
> >> Thank you for your feedback, replies inline:
> >>
> >> On Tue, Oct 15, 2019 at 6:01 PM Attila Kinali  wrote:
> >> [snip]
> >>
> >>> The biggest change I would make, would be to use a higher sampling
> >>> frequency and use an FPGA with a CORDIC as phase detector. Especially
> >>> as your goal is to measure the phase difference of a distribution
> system,
> >>> where the frequency of both inputs is exactly the same.
> >>>
> >>
> >> That's the next step (after I've taken this 8-bit processor as far as it
> >> can go). I'm working on a daughterboard with dual Lattice iCE40
> UltraPlus
> >> FPGAs, picked mainly because an open toolchain is available, but also
> for
> >> their price and QFN48 package options (which I've not 

Re: [time-nuts] A simple sampling DMTD

[Attila Kinali]

On Sun, 3 Nov 2019 01:41:08 +0100
Jan-Derk Bakker  wrote:

> The test was run for 175k seconds (just over 2 days) in a very much
> non-temperature controlled attic. The resulting ADEV can be found at
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20ADEV.pdf ; the

This looks good, but I would still expect the start of the ADEV plot,
ie the precision of the single measurements to be about half an order
to an order of magnitude lower. For comparison, commercial DMTD systems
operate at about 1e-13 at 1s, which is mostly dominated by the mixer
noise and temperature coefficient. I would expect you to be close to
1e-12 at 0.1s, even before filtering.

BTW: For this kind of measurement, TDEV is the more useful measure.

> measured time difference between the channels is
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise.png ; the input
> spectrum of channel 1 with and without the filters is
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20input%20spectrum.pdf
> 
> For tau=1s the Allan deviation without any filtering is 9.5E-13. High pass
> filtering to eliminate LF noise and drift improves this to 4.6E-13; adding
> bandpass filtering yields 3.2E-13. Out to 1000s the adev decreases linearly
> with tau, after that performance degrades (further testing in a temperature
> controlled room should show whether this is intrinsic or not).

You care mostly about temperature gradients. If both paths are about the
same temperature, then they will get approximately the same change in delay.
Ie put a cardboard box over it and you will have a pretty stable system.

BTW: a rule of thumb for temp coefficients for quite a large group of
components (mixers, DDS, etc) is 1-5ps/°C,

> 
> As the high pass filtering seems to have the largest impact, I plan to
> implement this first (still based on averaging over a single period
> centered around the rising flank of the sine; the on-board processor
> doesn't have enough horsepower to run a 1001pt FIR at 2ksps). Next I want
> to add code to phase lock the on-board VCTCXO to the reference input, this
> should also make it easy to implement a notch filter to eliminate (even)
> harmonics.

You do want the notch filters in front of the ADCs. Once the harmonics
enter the system, they already contributed to noise conversion. Digital
filtering helps only if you can completely separate the harmonics from
the signal, which is not possible due to non-linearity of the ADC.
So, I would suggest to have at least some filtering in the frontend
and then clean up the rest in the digital domain.


> After that I want to see if I can get a computationally
> efficient arcsin/arctan applied to the data, to make it easier to extend
> the number of samples used by the ZCD without running into linearity
> issues. Meanwhile I'm working on a daughterboard with twin Lattice iCE40
> FPGAs.

I don't remember what uC you are using, but CORDIC would be the way to
go in most places, especially if you want lots of bits. You need something
in the order of 2-5 stages more than you want output bits and about as
many intermediate bits more.

Attila Kinali

-- 
The bad part of Zurich is where the degenerates
throw DARK chocolate at you.

___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Bob kb8tq]

Hi

> On Nov 2, 2019, at 8:41 PM, Jan-Derk Bakker  wrote:
> 
> Dear all,
> 
> Attila got me thinking with his remark:
> 
> I am a bit astonished by the high noise level you have. I would have
>> expected
>> this to yield something below 1ps, judging from what we got from what
>> Nicolas
>> acheived in his work on the sine exitation based TIC[1].
> 
> 
> ...and I realised that I'm expressing the error wrong. What I had
> calculated was the standard deviation of the entire signal (noise +
> drift/wander). For short time periods I do get sub-ps noise levels, even
> without correcting for LF/DC errors.
> 
> It may make more sense to look at the Allan deviation. I've used tvb's
> adev1 tool ( http://www.leapsecond.com/tools/adev1.htm ), with a manual
> correction to accommodate the 10sps data. To investigate the effect of high
> pass filtering and attenuating even-order harmonics, I've generated
> 1001-point high pass and band pass FIR filters with GMeteor (
> http://gmeteor.sourceforge.net/ ; the odd size of 1001 points being the
> largest size I could reliably get the program to generate filter solutions
> for); the BPF was generated to have nulls at 20, 40, 60 and 80Hz. 10MHz was
> generated with an 10811 that had been powered up for three days after
> having been in storage for over a year, its output fed to a Mini-Circuits
> ZFSC-2-1 splitter, connected to the DMTD with two 3in semi-rigid cables.
> The test was run for 175k seconds (just over 2 days) in a very much
> non-temperature controlled attic. The resulting ADEV can be found at
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20ADEV.pdf ; the
> measured time difference between the channels is
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise.png ; the input
> spectrum of channel 1 with and without the filters is
> http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20input%20spectrum.pdf
> 
> For tau=1s the Allan deviation without any filtering is 9.5E-13. High pass
> filtering to eliminate LF noise and drift improves this to 4.6E-13; adding
> bandpass filtering yields 3.2E-13. Out to 1000s the adev decreases linearly
> with tau, after that performance degrades (further testing in a temperature
> controlled room should show whether this is intrinsic or not).
> 
> As the high pass filtering seems to have the largest impact, I plan to
> implement this first (still based on averaging over a single period
> centered around the rising flank of the sine; the on-board processor
> doesn't have enough horsepower to run a 1001pt FIR at 2ksps). Next I want
> to add code to phase lock the on-board VCTCXO to the reference input,

If you phase lock the downconversion reference, the VCXO noise that now is 
uncorrelated
between the channels will become correlated. That may make things worse rather
than better

Bob

> this
> should also make it easy to implement a notch filter to eliminate (even)
> harmonics. After that I want to see if I can get a computationally
> efficient arcsin/arctan applied to the data, to make it easier to extend
> the number of samples used by the ZCD without running into linearity
> issues. Meanwhile I'm working on a daughterboard with twin Lattice iCE40
> FPGAs.
> 
> Any suggestions so far?
> 
> To be continued,
> 
> JDB.
> 
> 
> On Tue, Oct 22, 2019 at 12:33 AM Jan-Derk Bakker  wrote:
> 
>> Dear Attila,
>> 
>> Thank you for your feedback, replies inline:
>> 
>> On Tue, Oct 15, 2019 at 6:01 PM Attila Kinali  wrote:
>> [snip]
>> 
>>> The biggest change I would make, would be to use a higher sampling
>>> frequency and use an FPGA with a CORDIC as phase detector. Especially
>>> as your goal is to measure the phase difference of a distribution system,
>>> where the frequency of both inputs is exactly the same.
>>> 
>> 
>> That's the next step (after I've taken this 8-bit processor as far as it
>> can go). I'm working on a daughterboard with dual Lattice iCE40 UltraPlus
>> FPGAs, picked mainly because an open toolchain is available, but also for
>> their price and QFN48 package options (which I've not found in any other
>> FPGA family of similar density).
>> 
>> (note that for my purposes I do need to DMTD different frequencies, in
>> particular the 10MHz system master clock vs the slaved 50MHz clocks on the
>> individual SDR boards in the phased array).
>> 
>> 
>>> The reason for this is rather simple. You are using a LMS fit over
>>> 32 samples around the zero crossing of a 10Hz signal with a ~10MHz
>>> sampling clock. This means you have just a few samples over what would
>>> be otherwise possible.
>>> 
>> 
>> It's not quite that bad, as the double CIC decimator already performs
>> quite a bit of averaging/filtering. The LMS fit is over 32 samples out of
>> 200 per period (after the CIC). I expect the largest improvement to come
>> from the increase in input sample rate.
>> 
>> 
>>> The other advantage is, that you operate close to the 1/f corner
>>> frequency,
>>> Ie the effect of 1/f noise hits you (almost) fully. Sampling the 

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Dear all,

Attila got me thinking with his remark:

I am a bit astonished by the high noise level you have. I would have
> expected
> this to yield something below 1ps, judging from what we got from what
> Nicolas
> acheived in his work on the sine exitation based TIC[1].


...and I realised that I'm expressing the error wrong. What I had
calculated was the standard deviation of the entire signal (noise +
drift/wander). For short time periods I do get sub-ps noise levels, even
without correcting for LF/DC errors.

It may make more sense to look at the Allan deviation. I've used tvb's
adev1 tool ( http://www.leapsecond.com/tools/adev1.htm ), with a manual
correction to accommodate the 10sps data. To investigate the effect of high
pass filtering and attenuating even-order harmonics, I've generated
1001-point high pass and band pass FIR filters with GMeteor (
http://gmeteor.sourceforge.net/ ; the odd size of 1001 points being the
largest size I could reliably get the program to generate filter solutions
for); the BPF was generated to have nulls at 20, 40, 60 and 80Hz. 10MHz was
generated with an 10811 that had been powered up for three days after
having been in storage for over a year, its output fed to a Mini-Circuits
ZFSC-2-1 splitter, connected to the DMTD with two 3in semi-rigid cables.
The test was run for 175k seconds (just over 2 days) in a very much
non-temperature controlled attic. The resulting ADEV can be found at
http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20ADEV.pdf ; the
measured time difference between the channels is
http://www.lartmaker.nl/time-nuts/DMTD%20self-noise.png ; the input
spectrum of channel 1 with and without the filters is
http://www.lartmaker.nl/time-nuts/DMTD%20self-noise%20input%20spectrum.pdf

For tau=1s the Allan deviation without any filtering is 9.5E-13. High pass
filtering to eliminate LF noise and drift improves this to 4.6E-13; adding
bandpass filtering yields 3.2E-13. Out to 1000s the adev decreases linearly
with tau, after that performance degrades (further testing in a temperature
controlled room should show whether this is intrinsic or not).

As the high pass filtering seems to have the largest impact, I plan to
implement this first (still based on averaging over a single period
centered around the rising flank of the sine; the on-board processor
doesn't have enough horsepower to run a 1001pt FIR at 2ksps). Next I want
to add code to phase lock the on-board VCTCXO to the reference input, this
should also make it easy to implement a notch filter to eliminate (even)
harmonics. After that I want to see if I can get a computationally
efficient arcsin/arctan applied to the data, to make it easier to extend
the number of samples used by the ZCD without running into linearity
issues. Meanwhile I'm working on a daughterboard with twin Lattice iCE40
FPGAs.

Any suggestions so far?

To be continued,

JDB.


On Tue, Oct 22, 2019 at 12:33 AM Jan-Derk Bakker  wrote:

> Dear Attila,
>
> Thank you for your feedback, replies inline:
>
> On Tue, Oct 15, 2019 at 6:01 PM Attila Kinali  wrote:
> [snip]
>
>> The biggest change I would make, would be to use a higher sampling
>> frequency and use an FPGA with a CORDIC as phase detector. Especially
>> as your goal is to measure the phase difference of a distribution system,
>> where the frequency of both inputs is exactly the same.
>>
>
> That's the next step (after I've taken this 8-bit processor as far as it
> can go). I'm working on a daughterboard with dual Lattice iCE40 UltraPlus
> FPGAs, picked mainly because an open toolchain is available, but also for
> their price and QFN48 package options (which I've not found in any other
> FPGA family of similar density).
>
> (note that for my purposes I do need to DMTD different frequencies, in
> particular the 10MHz system master clock vs the slaved 50MHz clocks on the
> individual SDR boards in the phased array).
>
>
>> The reason for this is rather simple. You are using a LMS fit over
>> 32 samples around the zero crossing of a 10Hz signal with a ~10MHz
>> sampling clock. This means you have just a few samples over what would
>> be otherwise possible.
>>
>
> It's not quite that bad, as the double CIC decimator already performs
> quite a bit of averaging/filtering. The LMS fit is over 32 samples out of
> 200 per period (after the CIC). I expect the largest improvement to come
> from the increase in input sample rate.
>
>
>> The other advantage is, that you operate close to the 1/f corner
>> frequency,
>> Ie the effect of 1/f noise hits you (almost) fully. Sampling the full
>> sine wave instead gives you the ability to work far away from the 1/f
>> corner and thus greatly reduces the effect of 1/f noise.
>>
>
> This is definitely true, and at the moment my largest source of errors. As
> an intermediate step I'm considering shifting the beat frequency up some
> (say to 40...50Hz) and then I/Q demodulating in software.I expect this will
> make the filtering of LF noise easier.
>
> If 

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Dear Attila,

Thank you for your feedback, replies inline:

On Tue, Oct 15, 2019 at 6:01 PM Attila Kinali  wrote:
[snip]

> The biggest change I would make, would be to use a higher sampling
> frequency and use an FPGA with a CORDIC as phase detector. Especially
> as your goal is to measure the phase difference of a distribution system,
> where the frequency of both inputs is exactly the same.
>

That's the next step (after I've taken this 8-bit processor as far as it
can go). I'm working on a daughterboard with dual Lattice iCE40 UltraPlus
FPGAs, picked mainly because an open toolchain is available, but also for
their price and QFN48 package options (which I've not found in any other
FPGA family of similar density).

(note that for my purposes I do need to DMTD different frequencies, in
particular the 10MHz system master clock vs the slaved 50MHz clocks on the
individual SDR boards in the phased array).


> The reason for this is rather simple. You are using a LMS fit over
> 32 samples around the zero crossing of a 10Hz signal with a ~10MHz
> sampling clock. This means you have just a few samples over what would
> be otherwise possible.
>

It's not quite that bad, as the double CIC decimator already performs quite
a bit of averaging/filtering. The LMS fit is over 32 samples out of 200 per
period (after the CIC). I expect the largest improvement to come from the
increase in input sample rate.


> The other advantage is, that you operate close to the 1/f corner frequency,
> Ie the effect of 1/f noise hits you (almost) fully. Sampling the full
> sine wave instead gives you the ability to work far away from the 1/f
> corner and thus greatly reduces the effect of 1/f noise.
>

This is definitely true, and at the moment my largest source of errors. As
an intermediate step I'm considering shifting the beat frequency up some
(say to 40...50Hz) and then I/Q demodulating in software.I expect this will
make the filtering of LF noise easier.

If you are interested, I have a parametrizable CORDIC core written
> in VHDL ready for use.


Thank you' I may take you up on that. So far I've been looking at the
(Verilog) CORDIC code in the Ettus USRP sources.

[snip]

> I've been running some tests with a 10MHz sine wave from an Abracon AOCJY1
> > OCXO into a resistive divider, feeding both channels of the DMTD through
> > identical SMA cables (Amphenol 135101-07-M0.50). At the ADC input this
> > yields a -12dBFS sine wave (PSD of the beat note:
> >
> http://www.lartmaker.nl/time-nuts/PSD%20of%20AOCJY1%20into%20the%20LTC2140.pdf
> > ). Over a 34000s measurement period the ZCD as described upthread (least
> > squares fitting of the 32 samples nearest the zero crossing of the rising
> > flank, but without DC/drift correction) shows a time difference of 6.3ps
> > between the two channels, with a standard deviation of 1.6ps (full plot:
> >
> http://www.lartmaker.nl/time-nuts/DMTD%20Time%20between%20zero%20crossings%20with%20resistive%20divider%20(no%20offset%20correction).pdf
> > ).
>
> I am a bit astonished by the high noise level you have. I would have
> expected
> this to yield something below 1ps, judging from what we got from what
> Nicolas
> acheived in his work on the sine exitation based TIC[1].


This is actually better than I had expected, given the drift/LF noise I get
from the LTC2140 ( http://www.lartmaker.nl/time-nuts/LTC2140-14%20drift.pdf
). As I've mentioned upthread I'm looking for a robust way to cancel this
drift; my best plan so far is to calculate the signal average between
subsequent _falling_ edges, and to use this to get the zero level for the
rising edge. (This is a problem which I would expect to have a closed form
solution, even when the period of the sine is not an integer multiple of
the sampling rate. Alas, my undergrad-level math seems to be failing me, so
I'm resorting to the blunt instrument of numerical approximations. I hope
to have more time for this in a week or two; in the meantime I'm very open
for hints.)


> BTW: you want to keep even harmonics as low as possible, as these lead
> to increase of 1/f noise in the system (see [3] for an explanation)
>

Thanks, that's good to keep in mind. What I've shown is the unfiltered
output of the OCXO under test; I've not attempted to do any analog
filtering on this.

Sincerely,

JDB.
___
time-nuts mailing list -- time-nuts@lists.febo.com
To unsubscribe, go to 
http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com
and follow the instructions there.

Re: [time-nuts] A simple sampling DMTD

[Attila Kinali]

Hoi Jan-Derk,

As I am late to the party, I take the liberty to answer a few mails together

On Sun, 1 Sep 2019 02:09:19 +0200
Jan-Derk Bakker  wrote:

> I've been working on a design for a (relatively) simple, standalone
> sampling DMTD. Very rough preliminary schematics can be found at
> http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf .

The design is quite decent and I don't see anything "obviously wrong". ;-)
The choice of the LTC2140 is good, there might be better options in
terms of noise, but the LTC2140 is good and available at a decent price.

The biggest change I would make, would be to use a higher sampling
frequency and use an FPGA with a CORDIC as phase detector. Especially
as your goal is to measure the phase difference of a distribution system,
where the frequency of both inputs is exactly the same.

The reason for this is rather simple. You are using a LMS fit over
32 samples around the zero crossing of a 10Hz signal with a ~10MHz
sampling clock. This means you have just a few samples over what would
be otherwise possible. A CORDIC does cover the whole sine wave. While 
this does not give you n-times as many samples, it improves the SNR quite
considerably. I don't have exact numbers for how much, as I haven't
had the time to go through the math for this, yet.
The other advantage is, that you operate close to the 1/f corner frequency,
Ie the effect of 1/f noise hits you (almost) fully. Sampling the full
sine wave instead gives you the ability to work far away from the 1/f
corner and thus greatly reduces the effect of 1/f noise.

If you are interested, I have a parametrizable CORDIC core written
in VHDL ready for use. At the low sampling frequencies the LTC2140
works, a MAX10 would be already more than good enough. It probably
should be able to support even higher sampling frequencies in the
order of 100MHz (haven't synthesized it for a MAX10, but guesstimating
from the datasheet). The FPGA could also do the (digital) filtering
and down-sampling, so your uC wouldn't have to do any expensive
calculations.

As sampling period I would choose something that is such that the
signal ends up approximately centered within a niquist zone, but
with an as odd ratio as possible. Ie the reduced fraction a/b should
have as large a and b as possible. The reason for this comes from
number theory and the way how spurs form in DDS. 
Alternatively, but with a higher effort, one can choose the sampling
rate such, that a/b has small a and b. This will result in a lot of
the spur energy to fall onto the signal and by that reduce the noise
floor which is mostly spur generated for this kind of application.
The difficulty lies here in having a sampling source that is locked to
the signal but has as low noise as possible, as the close in noise
of the sampling source now defines how well the spurs match up with
the passband signal. Again, I cannot say exactly how much better this
would be, as I haven't gone through the math yet.


On Sat, 5 Oct 2019 20:49:50 +0200
Jan-Derk Bakker  wrote:

> I've been running some tests with a 10MHz sine wave from an Abracon AOCJY1
> OCXO into a resistive divider, feeding both channels of the DMTD through
> identical SMA cables (Amphenol 135101-07-M0.50). At the ADC input this
> yields a -12dBFS sine wave (PSD of the beat note:
> http://www.lartmaker.nl/time-nuts/PSD%20of%20AOCJY1%20into%20the%20LTC2140.pdf
> ). Over a 34000s measurement period the ZCD as described upthread (least
> squares fitting of the 32 samples nearest the zero crossing of the rising
> flank, but without DC/drift correction) shows a time difference of 6.3ps
> between the two channels, with a standard deviation of 1.6ps (full plot:
> http://www.lartmaker.nl/time-nuts/DMTD%20Time%20between%20zero%20crossings%20with%20resistive%20divider%20(no%20offset%20correction).pdf
> ).

I am a bit astonished by the high noise level you have. I would have expected
this to yield something below 1ps, judging from what we got from what Nicolas
acheived in his work on the sine exitation based TIC[1]. The apperture jitter
of the LTC2140 is spec'ed with 100fs, so that should be the first limit
to run against. Though, based on Sherman and Jördens' work[2], about
one fifth of that should be possible.

BTW: you want to keep even harmonics as low as possible, as these lead
to increase of 1/f noise in the system (see [3] for an explanation)

Attila Kinali

[1] "Development of a High Precision Multi-Channel Time-to-Digital Converter",
by Nicolas Bucquey, 2016
https://www.ohwr.org/project/r19-tdc-del-a/uploads/a6a30e7969dd05bda87ee27a3112adb9/document.pdf

[2] "Oscillator metrology with software defined radio", 
by Sherman and Jördens,2016
http://dx.doi.org/10.1063/1.4950898

[3] "A Physical Sine-to-Square Converter Noise Model", Attila Kinali, 2018
http://people.mpi-inf.mpg.de/~adogan/pubs/IFCS2018_comparator_noise.pdf

-- 
It is upon moral qualities that a society is ultimately founded. All 
the prosperity and 

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Another update: Sampling now works at 100ksps. Samples are passed through a
two-stage CIC filter and are decimated to 2ksps for 200 samples per beat
note period. At system boot I am tuning the on-board VCTCXO (a Taitien
TT-series model) to 10Hz above the reference input and then leave the EFC
constant.

I've been running some tests with a 10MHz sine wave from an Abracon AOCJY1
OCXO into a resistive divider, feeding both channels of the DMTD through
identical SMA cables (Amphenol 135101-07-M0.50). At the ADC input this
yields a -12dBFS sine wave (PSD of the beat note:
http://www.lartmaker.nl/time-nuts/PSD%20of%20AOCJY1%20into%20the%20LTC2140.pdf
). Over a 34000s measurement period the ZCD as described upthread (least
squares fitting of the 32 samples nearest the zero crossing of the rising
flank, but without DC/drift correction) shows a time difference of 6.3ps
between the two channels, with a standard deviation of 1.6ps (full plot:
http://www.lartmaker.nl/time-nuts/DMTD%20Time%20between%20zero%20crossings%20with%20resistive%20divider%20(no%20offset%20correction).pdf
).

My preliminary conclusion is that the ZCD works as expected. I did find
that the zero crossing estimator has a bias which increases with the
fractional (in-between-samples) part of the crossing, caused by the
deviation of the sine wave from a straight line; a linear correction
reduces the contribution of this error to <0.1ps (although I need to
validate this against sine waves with varying amounts of harmonics).

I have yet to implement a robust drift cancellation method. The usual
techniques are either not linear phase (IIR HPF) or computationally
infeasible on an 8-bit platform at 2ksps (various FIR HPFs). I am
considering taking the average of the samples in the interval half a beat
note period before to half a beat note period after the ZC of the rising
edge (by detecting the ZCs of the falling edges); I need to work out the
most robust way to handle interpolation of fractional samples.

In the measurement data linked above I see intermittent bursts of increased
estimator error. These appear to happen in a 3600-second interval (and my
test setup is as unshielded as it gets). Might be interference, might be
something else.

After I've tackled drift cancellation and investigated the error bursts I
intend to repeat my measurement with one OCXO but with different cable
lengths from the splitter to the DMTD; if all works well there I'll mix and
match a few other frequency sources (dual 10811s, a Thunderbolt, a custom
GPSDO and a Rb-standard which I hope will fire up again after having been
in storage for a few years).

I'll be fairly busy on other projects for the next few weeks; I expect to
be able to get back to the DMTD by the end of this month.

To be continued,

JDB.
[have not made any further attempts to get raw samples out of the FTDI-chip
yet, either]

On Sun, Sep 22, 2019 at 11:32 PM Jan-Derk Bakker  wrote:

> Update: last Friday our students have populated a few prototype boards (
> http://www.lartmaker.nl/time-nuts/dmtd-proto.jpg), and this weekend I
> managed to get some early code running on it.
>
> The good: Noise performance matches the datasheet (1.19LSB_RMS given,
> 1.21LSB_RMS measured). The 1/f corner is much lower than I feared (
> http://www.lartmaker.nl/time-nuts/LTC2140-14%20noise%20corner.pdf ;
> measured at a sample rate of 10ksps with terminated inputs, PSD averaged
> over 500M samples in 1Msample chunks with a rectangular window), and direct
> measurements at a 10Hz beat frequency should be possible. (I don't
> completely trust this data yet; the absence of 50Hz lines in an unshielded
> setup makes me suspicious.)
>
> The bad: LF noise / drift is significant (
> http://www.lartmaker.nl/time-nuts/LTC2140-14%20drift.pdf; vertical axis
> is in LSB). On a 0dBFS signal with a 10Hz beat note an uncertainty of
> 0.25LSB in the zero crossing point would translate to +/-1ps; what I'm
> seeing here would eat my entire error budget and then some. I need to find
> a computationally cheap way to filter this, or move to the FPGA after all.
>
> The ugly: I can't get the FT2232H channel A to work in asynchronous
> FIFO-mode. I have programmed the EEPROM wth the latest version of the
> FT_PROG tool, but the TXE# line stays high (under Linux; I'm reading data
> from /dev/ttyUSBx with ftdi_sio, a setup which FTDI hints should work). I
> haven't looked too hard yet as I have the serial port as a backup, but it
> would be nice to get this working.
>
> To be continued,
>
> JDB.
> [listadmin: do let me know if you feel these updates are more noise than
> signal]
>
> On Sat, Sep 14, 2019 at 2:25 PM Jan-Derk Bakker 
> wrote:
>
>> Update: I have finished routing the board (placement diagram at
>> http://www.lartmaker.nl/time-nuts/DMTD%20rev1.00%20assembly.pdf ) and
>> ordered a few prototype PCBs.
>>
>> After the earlier discussions on the list I've grown sufficiently
>> concerned about the impact of 1/f converter noise that I have added 

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Update: last Friday our students have populated a few prototype boards (
http://www.lartmaker.nl/time-nuts/dmtd-proto.jpg), and this weekend I
managed to get some early code running on it.

The good: Noise performance matches the datasheet (1.19LSB_RMS given,
1.21LSB_RMS measured). The 1/f corner is much lower than I feared (
http://www.lartmaker.nl/time-nuts/LTC2140-14%20noise%20corner.pdf ;
measured at a sample rate of 10ksps with terminated inputs, PSD averaged
over 500M samples in 1Msample chunks with a rectangular window), and direct
measurements at a 10Hz beat frequency should be possible. (I don't
completely trust this data yet; the absence of 50Hz lines in an unshielded
setup makes me suspicious.)

The bad: LF noise / drift is significant (
http://www.lartmaker.nl/time-nuts/LTC2140-14%20drift.pdf; vertical axis is
in LSB). On a 0dBFS signal with a 10Hz beat note an uncertainty of 0.25LSB
in the zero crossing point would translate to +/-1ps; what I'm seeing here
would eat my entire error budget and then some. I need to find a
computationally cheap way to filter this, or move to the FPGA after all.

The ugly: I can't get the FT2232H channel A to work in asynchronous
FIFO-mode. I have programmed the EEPROM wth the latest version of the
FT_PROG tool, but the TXE# line stays high (under Linux; I'm reading data
from /dev/ttyUSBx with ftdi_sio, a setup which FTDI hints should work). I
haven't looked too hard yet as I have the serial port as a backup, but it
would be nice to get this working.

To be continued,

JDB.
[listadmin: do let me know if you feel these updates are more noise than
signal]

On Sat, Sep 14, 2019 at 2:25 PM Jan-Derk Bakker  wrote:

> Update: I have finished routing the board (placement diagram at
> http://www.lartmaker.nl/time-nuts/DMTD%20rev1.00%20assembly.pdf ) and
> ordered a few prototype PCBs.
>
> After the earlier discussions on the list I've grown sufficiently
> concerned about the impact of 1/f converter noise that I have added headers
> to the board to allow me to replace the D-flipflop sampler with an
> FPGA-based I/Q downconverter. While the main PCBs are in production I'll
> draw a simple daughterboard with dual ice40 UltraPlus FPGAs, If the FPGA
> solution turns out to be necessary (or a noticeable improvement), I'll
> redraw the main PCB.
>
> To be continued,
>
> JDB.
>
> On Sun, Sep 1, 2019 at 2:09 AM Jan-Derk Bakker  wrote:
>
>> Dear all,
>>
>> I've been working on a design for a (relatively) simple, standalone
>> sampling DMTD. Very rough preliminary schematics can be found at
>> http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf .
>>
>> Design goals are:
>> - ps-level accuracy
>> - comparison of frequencies between at least 10 and 50MHz, preferably
>> between 1 and 100MHz
>> - comparison of (selected) different frequencies (in my case: 10MHz vs
>> 50MHz)
>> - standalone operation, field-portable
>> - option for raw data sampling / (post)processing on a PC
>> - option for generating a tuning voltage to lock the measured oscillator
>> to the reference, so the DMTD can act as a PLL in phase noise test setups
>>
>> Context: you may remember that a year or two ago I posted to time-nuts
>> about a GPSDO-design geared for mobile applications, which I was working on
>> for an SDR-platform my students are working with. This SDR-platform has now
>> grown to include a 100-channel phased array receiver. To validate the
>> reference clock distribution in this array (amongst other things) I would
>> like to have a DMTD. As the commercial offerings are outside the budget of
>> our lab, I was planning to roll my own.
>>
>> The core of the system is a transformer-coupled LTC2140-14 dual 14-bit
>> ADC, sampling at an offset frequency of nominally 10MHz+10Hz generated by a
>> VCTCXO (with an option for an OCXO). The ADC was chosen for its large input
>> bandwidth and small aperture jitter. Simulations of a simple software ZCD
>> consisting of a digital filter and least-squares fitting showed that
>> 100ksps would be more than enough to get the desired accuracy. As the ADC
>> design is unable to achieve sample rates lower than 1MSPS, D-flipflops are
>> used to decimate the samples. These DFFs are also used to multiplex the
>> 2x14-bit samples to an 8-bit data bus going into one of the GPIO-ports of
>> an XMega. The XMega runs the ZCD, and generates a tuning voltage for the
>> offset oscillator. Communication to a logging PC is done with a
>> galvanically isolated FT2232H, which has both an ASCII COM-port for the ZCD
>> data and a control interface and an asynchronous FIFO to transfer raw
>> samples. System power comes from the isolated USB bus or a barrel jack; BOM
>> cost in qty10+ is around 100US$.
>>
>> (The DMTD has a few more power rails than I would have liked. Originally
>> I had planned to use the LTC2295 and have a 3v3-only system, but after
>> re-reading the NIST paper on SDR-as-a-DMTD I concluded that the single
>> clocking path of the 2140 would likely have better aperture 

Re: [time-nuts] A simple sampling DMTD

[Bob kb8tq]

Hi

You are not going to get useful phase noise data out of a normal DMTD ….
The DMTD is targeted at ADEV and similar long term / high accuracy 
measurements. If a DMTD “makes it” to a 10 Hz beat note that is about 
as far as most people take it.

Bob

> On Sep 16, 2019, at 10:41 AM, tim...@timeok.it wrote:
> 
> 
>   Hi Jan,
> 
>   this is precisely the instrument that is lacking at a hobbyist price.
> 
>   It would be excellent to have the possibility of measuring phase noise.
> 
>   Can you anticipate the features of the Sampling DMTD?
> 
>   Can it be used with Timelab?
> 
>   We are waiting for your new ones.
> 
>   Luciano
> 
> 
>   Da "time-nuts" time-nuts-boun...@lists.febo.com
>   A "Discussion of precise time and frequency measurement" 
> time-nuts@lists.febo.com
>   Cc
>   Data Sat, 14 Sep 2019 14:25:48 +0200
>   Oggetto Re: [time-nuts] A simple sampling DMTD
>   Update: I have finished routing the board (placement diagram at
>   http://www.lartmaker.nl/time-nuts/DMTD%20rev1.00%20assembly.pdf ) and
>   ordered a few prototype PCBs.
> 
>   After the earlier discussions on the list I've grown sufficiently concerned
>   about the impact of 1/f converter noise that I have added headers to the
>   board to allow me to replace the D-flipflop sampler with an FPGA-based I/Q
>   downconverter. While the main PCBs are in production I'll draw a simple
>   daughterboard with dual ice40 UltraPlus FPGAs, If the FPGA solution turns
>   out to be necessary (or a noticeable improvement), I'll redraw the main PCB.
> 
>   To be continued,
> 
>   JDB.
> 
>   On Sun, Sep 1, 2019 at 2:09 AM Jan-Derk Bakker  wrote:
> 
>> Dear all,
>> 
>> I've been working on a design for a (relatively) simple, standalone
>> sampling DMTD. Very rough preliminary schematics can be found at
>> http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf .
>> 
>> Design goals are:
>> - ps-level accuracy
>> - comparison of frequencies between at least 10 and 50MHz, preferably
>> between 1 and 100MHz
>> - comparison of (selected) different frequencies (in my case: 10MHz vs
>> 50MHz)
>> - standalone operation, field-portable
>> - option for raw data sampling / (post)processing on a PC
>> - option for generating a tuning voltage to lock the measured oscillator
>> to the reference, so the DMTD can act as a PLL in phase noise test setups
>> 
>> Context: you may remember that a year or two ago I posted to time-nuts
>> about a GPSDO-design geared for mobile applications, which I was working on
>> for an SDR-platform my students are working with. This SDR-platform has now
>> grown to include a 100-channel phased array receiver. To validate the
>> reference clock distribution in this array (amongst other things) I would
>> like to have a DMTD. As the commercial offerings are outside the budget of
>> our lab, I was planning to roll my own.
>> 
>> The core of the system is a transformer-coupled LTC2140-14 dual 14-bit
>> ADC, sampling at an offset frequency of nominally 10MHz+10Hz generated by a
>> VCTCXO (with an option for an OCXO). The ADC was chosen for its large input
>> bandwidth and small aperture jitter. Simulations of a simple software ZCD
>> consisting of a digital filter and least-squares fitting showed that
>> 100ksps would be more than enough to get the desired accuracy. As the ADC
>> design is unable to achieve sample rates lower than 1MSPS, D-flipflops are
>> used to decimate the samples. These DFFs are also used to multiplex the
>> 2x14-bit samples to an 8-bit data bus going into one of the GPIO-ports of
>> an XMega. The XMega runs the ZCD, and generates a tuning voltage for the
>> offset oscillator. Communication to a logging PC is done with a
>> galvanically isolated FT2232H, which has both an ASCII COM-port for the ZCD
>> data and a control interface and an asynchronous FIFO to transfer raw
>> samples. System power comes from the isolated USB bus or a barrel jack; BOM
>> cost in qty10+ is around 100US$.
>> 
>> (The DMTD has a few more power rails than I would have liked. Originally I
>> had planned to use the LTC2295 and have a 3v3-only system, but after
>> re-reading the NIST paper on SDR-as-a-DMTD I concluded that the single
>> clocking path of the 2140 would likely have better aperture jitter
>> correlation between the channels. As a 1.8V/10MHz XMega would only be
>> borderline able to handle the computations, I ended up with this design.
>> LVC logic is used to go from 3.3V->1.8V, LV1T translators for the opposite
>> direction.)
>> 
>> Design decisions and/or non-goals:
>> - I conside

Re: [time-nuts] A simple sampling DMTD

[tim...@timeok.it]

   Hi Jan,

   this is precisely the instrument that is lacking at a hobbyist price.

   It would be excellent to have the possibility of measuring phase noise.

   Can you anticipate the features of the Sampling DMTD?

   Can it be used with Timelab?

   We are waiting for your new ones.

   Luciano


   Da "time-nuts" time-nuts-boun...@lists.febo.com
   A "Discussion of precise time and frequency measurement" 
time-nuts@lists.febo.com
   Cc
   Data Sat, 14 Sep 2019 14:25:48 +0200
   Oggetto Re: [time-nuts] A simple sampling DMTD
   Update: I have finished routing the board (placement diagram at
   http://www.lartmaker.nl/time-nuts/DMTD%20rev1.00%20assembly.pdf ) and
   ordered a few prototype PCBs.

   After the earlier discussions on the list I've grown sufficiently concerned
   about the impact of 1/f converter noise that I have added headers to the
   board to allow me to replace the D-flipflop sampler with an FPGA-based I/Q
   downconverter. While the main PCBs are in production I'll draw a simple
   daughterboard with dual ice40 UltraPlus FPGAs, If the FPGA solution turns
   out to be necessary (or a noticeable improvement), I'll redraw the main PCB.

   To be continued,

   JDB.

   On Sun, Sep 1, 2019 at 2:09 AM Jan-Derk Bakker  wrote:

   > Dear all,
   >
   > I've been working on a design for a (relatively) simple, standalone
   > sampling DMTD. Very rough preliminary schematics can be found at
   > http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf .
   >
   > Design goals are:
   > - ps-level accuracy
   > - comparison of frequencies between at least 10 and 50MHz, preferably
   > between 1 and 100MHz
   > - comparison of (selected) different frequencies (in my case: 10MHz vs
   > 50MHz)
   > - standalone operation, field-portable
   > - option for raw data sampling / (post)processing on a PC
   > - option for generating a tuning voltage to lock the measured oscillator
   > to the reference, so the DMTD can act as a PLL in phase noise test setups
   >
   > Context: you may remember that a year or two ago I posted to time-nuts
   > about a GPSDO-design geared for mobile applications, which I was working on
   > for an SDR-platform my students are working with. This SDR-platform has now
   > grown to include a 100-channel phased array receiver. To validate the
   > reference clock distribution in this array (amongst other things) I would
   > like to have a DMTD. As the commercial offerings are outside the budget of
   > our lab, I was planning to roll my own.
   >
   > The core of the system is a transformer-coupled LTC2140-14 dual 14-bit
   > ADC, sampling at an offset frequency of nominally 10MHz+10Hz generated by a
   > VCTCXO (with an option for an OCXO). The ADC was chosen for its large input
   > bandwidth and small aperture jitter. Simulations of a simple software ZCD
   > consisting of a digital filter and least-squares fitting showed that
   > 100ksps would be more than enough to get the desired accuracy. As the ADC
   > design is unable to achieve sample rates lower than 1MSPS, D-flipflops are
   > used to decimate the samples. These DFFs are also used to multiplex the
   > 2x14-bit samples to an 8-bit data bus going into one of the GPIO-ports of
   > an XMega. The XMega runs the ZCD, and generates a tuning voltage for the
   > offset oscillator. Communication to a logging PC is done with a
   > galvanically isolated FT2232H, which has both an ASCII COM-port for the ZCD
   > data and a control interface and an asynchronous FIFO to transfer raw
   > samples. System power comes from the isolated USB bus or a barrel jack; BOM
   > cost in qty10+ is around 100US$.
   >
   > (The DMTD has a few more power rails than I would have liked. Originally I
   > had planned to use the LTC2295 and have a 3v3-only system, but after
   > re-reading the NIST paper on SDR-as-a-DMTD I concluded that the single
   > clocking path of the 2140 would likely have better aperture jitter
   > correlation between the channels. As a 1.8V/10MHz XMega would only be
   > borderline able to handle the computations, I ended up with this design.
   > LVC logic is used to go from 3.3V->1.8V, LV1T translators for the opposite
   > direction.)
   >
   > Design decisions and/or non-goals:
   > - I considered putting a small FPGA (specifically a Lattice ice40
   > UltraPlus) between the ADC and the processor. This was rejected because the
   > performance of the decimator appeared to be sufficient, and I wasn't
   > certain that I could get DDR mode + a CORDIC working in this FPGA.
   > - Especially when I found the necessity to move part of the system to 1.8V
   > I considered moving to an ARM. I stuck with the XMega as performance was
   > sufficient, and I am very familiar with both the CPU and the peripherals
  

Re: [time-nuts] A simple sampling DMTD

[Jan-Derk Bakker]

Update: I have finished routing the board (placement diagram at
http://www.lartmaker.nl/time-nuts/DMTD%20rev1.00%20assembly.pdf ) and
ordered a few prototype PCBs.

After the earlier discussions on the list I've grown sufficiently concerned
about the impact of 1/f converter noise that I have added headers to the
board to allow me to replace the D-flipflop sampler with an FPGA-based I/Q
downconverter. While the main PCBs are in production I'll draw a simple
daughterboard with dual ice40 UltraPlus FPGAs, If the FPGA solution turns
out to be necessary (or a noticeable improvement), I'll redraw the main PCB.

To be continued,

JDB.

On Sun, Sep 1, 2019 at 2:09 AM Jan-Derk Bakker  wrote:

> Dear all,
>
> I've been working on a design for a (relatively) simple, standalone
> sampling DMTD. Very rough preliminary schematics can be found at
> http://www.lartmaker.nl/time-nuts/DMTD_rev0.99.pdf .
>
> Design goals are:
> - ps-level accuracy
> - comparison of frequencies between at least 10 and 50MHz, preferably
> between 1 and 100MHz
> - comparison of (selected) different frequencies (in my case: 10MHz vs
> 50MHz)
> - standalone operation, field-portable
> - option for raw data sampling / (post)processing on a PC
> - option for generating a tuning voltage to lock the measured oscillator
> to the reference, so the DMTD can act as a PLL in phase noise test setups
>
> Context: you may remember that a year or two ago I posted to time-nuts
> about a GPSDO-design geared for mobile applications, which I was working on
> for an SDR-platform my students are working with. This SDR-platform has now
> grown to include a 100-channel phased array receiver. To validate the
> reference clock distribution in this array (amongst other things) I would
> like to have a DMTD. As the commercial offerings are outside the budget of
> our lab, I was planning to roll my own.
>
> The core of the system is a transformer-coupled LTC2140-14 dual 14-bit
> ADC, sampling at an offset frequency of nominally 10MHz+10Hz generated by a
> VCTCXO (with an option for an OCXO). The ADC was chosen for its large input
> bandwidth and small aperture jitter. Simulations of a simple software ZCD
> consisting of a digital filter and least-squares fitting showed that
> 100ksps would be more than enough to get the desired accuracy. As the ADC
> design is unable to achieve sample rates lower than 1MSPS, D-flipflops are
> used to decimate the samples. These DFFs are also used to multiplex the
> 2x14-bit samples to an 8-bit data bus going into one of the GPIO-ports of
> an XMega. The XMega runs the ZCD, and generates a tuning voltage for the
> offset oscillator. Communication to a logging PC is done with a
> galvanically isolated FT2232H, which has both an ASCII COM-port for the ZCD
> data and a control interface and an asynchronous FIFO to transfer raw
> samples. System power comes from the isolated USB bus or a barrel jack; BOM
> cost in qty10+ is around 100US$.
>
> (The DMTD has a few more power rails than I would have liked. Originally I
> had planned to use the LTC2295 and have a 3v3-only system, but after
> re-reading the NIST paper on SDR-as-a-DMTD I concluded that the single
> clocking path of the 2140 would likely have better aperture jitter
> correlation between the channels. As a 1.8V/10MHz XMega would only be
> borderline able to handle the computations, I ended up with this design.
> LVC logic is used to go from 3.3V->1.8V, LV1T translators for the opposite
> direction.)
>
> Design decisions and/or non-goals:
> - I considered putting a small FPGA (specifically a Lattice ice40
> UltraPlus) between the ADC and the processor. This was rejected because the
> performance of the decimator appeared to be sufficient, and I wasn't
> certain that I could get DDR mode + a CORDIC working in this FPGA.
> - Especially when I found the necessity to move part of the system to 1.8V
> I considered moving to an ARM. I stuck with the XMega as performance was
> sufficient, and I am very familiar with both the CPU and the peripherals
> (particularly time-stamping counters and the Event system) that would ease
> the ZCD implementation and issues like synchronization between processor
> and sampling system.
> - I looked into integrating a phase noise measurement, but could find no
> easy way that wouldn't degrade DMTD operation in the process. The tuning
> voltage output is an inexpensive compromise (as I still had a DAC and
> enough cycles to spare)
> - The main thing I'm unsure about is the effect of the balun on phase
> performance wrt temperature and termination matching. I've kept to the
> baluns as they add less noise than a fully differential amplifier would.
>
> While I've made this design for my own purposes, I would be more than
> happy to put it under an Open Hardware-license and/or work with TAPR or
> other parties to get it distributed, should there be interest.
>
> Thoughts?
>
> with kind regards,
>
> Jan-Derk Bakker
> [planning to start board layout tomorrow;