[time-nuts] Jan-Derk's DDMTD

[Jan-Derk Bakker]

Dear Jim,

Thank you for your feedback.

The very short version: this design works 'on paper', but there are a few
undocumented unknowns that I can only resolve by actually building and
testing it.

>
> 1.  The input bandwidth of the digitizer chip is 750 MHz (very
> impressive), but what happens to input noise that is aliased?  When
> sampling at 10MHz (plus offset) everything above 5MHz is aliased. Doesn't
> this suggest that high performance bandpass filters on the input, for
> whatever frequencies are of interest, would be helpful when measuring time
> stability (but not phase noise)?  I suppose it as a question of
> noise/instability added by the filter vs. noise removed from the input by
> the filter, and I haven't seen a published analysis of this...
>

Yes, there will be noise aliasing. The ADC noise is specified at
1.2LSB_RMS, or about 150uV. Assuming this noise is white with an equivalent
noise bandwidth of 1GHz, this gives an internal noise floor of about
4.6nV/sqrt(Hz), or -154dBm/sqrt(Hz). For a 0dBm input signal (10dB below
clipping), this gives a baseline for how noisy the DUT can be before
degrading system performance. (Here I run into one of the undocumented
unknowns: what is the noise floor of an 10811 or a maser very far from its
carrier? I have not seen anyone specify that to, say 100+MHz out). I could
add a filter (possibly simply by changing the time constant of the RC
filter at the input of the ADC), but I suspect that what I gain in noise
performance I'll lose in temperature-dependant errors.

I am actually more worried about ADC noise not being white. 1/f noise is
not specified for this ADC (or any high speed ADC I've looked at), but I've
seen high speed low power processes have 1/f corners of 100kHz and over. No
amount of analog filtering is going to help with that; if this turns out to
be the case then a bigger frequency offset for the sampler + an FPGA with a
downconverter would have to be implemented.

2. You mentioned that you are decimating the data to get the sample rate
> down. Doesn't this raise the noise floor above what it could be if all the
> samples were processed?
>

It does, and throwing away 99 out of every 100 samples predictably
increases the RMS error by a factor 10. At least in the (noise-limited)
simulation this still gives an error of less than 1ps.

In practice I expect the system to be limited not by noise but by external
factors such as non-ideal group delay for signal harmonics, unwanted
coupling and EMI, none of which can easily be mitigated by having more
samples per period.

3. What algorithm are you using for the digital ZCD?
>

An extremely simple one. For a 10MHz signal measured with 10Hz offset,
after decimation first I filter with a 60Hz first-order low pass filter
(which will need to be replaced by a shape-preserving filter in the final
code). I then feed the samples at 100ksps to a ring buffer, and I keep a
running sum of the values of the samples in the buffer. When the sign of
this running sum flips from positive to negative, my heuristic concludes
that the zero-crossing is somewhere in the middle of the buffer. I then run
a least squares fit on the buffered samples (modeling the sine near the
zero crossing as a straight line) to determine the time of the zero
crossing. (In a future version I intend to add a digital HPF to correct for
converter DC offset).

Especially with the addition of the LPF the simulator is showing quite
literally unbelievably good performance (example: running the ZCD over
1/40th of the sine for an input signal of 0dBm/-10dBFS gives single digit
femtosecond RMS errors). I fully expect the finished system to perform
worse.

4. How hard would it be to put an Ethernet interface on the output? Would
> it be easier to attached the device to a Raspberry Pi or sim as a
> USB-to-Ethernet converter?  In my lab I find USB to be annoyingly
> problematic, and prefer Ethernet...
>

I've looked into that, but it would require a different processor and
likely add more EMI inside the case. Your suggestion of a RasPi as
USB->Ethernet converter is probably the simplest plan.

JDB.