Jan-Derk's DDMTD
Jan-Derk-
Excellent and exciting work! Thanks for sharing with the newsgroup...
I have a couple of questions:
-
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...
-
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?
-
What algorithm are you using for the digital ZCD?
-
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 have been experimenting with DDMTD setups using commercial 14- and 16-bit simultaneous-sampling digitizer boards, and processing the phase data at the full rates (from a few MHz to 250 MHz or so sample rate) by correlation method instead of ZCD. The results have been o.k. but not quite as good as I was hoping for. There is a complex relationship between the sample rate and performance which I haven't quite worked out. Also, the number-crunching takes a while on conventional PC.
Thanks-
Jim
Jim
Hello,
This is a topic that interest me greatly as well. Some of the work we have done uses a digital frequency tracking loop to generate frequency errors directly from sampled data using a sampling system and ethernet system of our own design. We opted for using a look-up table-based DDS in the final frequency conversion to baseband (you mentioned considering CORDIC) and CIC filters/decimation..all in FPGA (Altera Cyclone III). This was done for testing two-way coherent transponders. See a description herehttps://www.researchgate.net/publication/332241644_Coherent_tracking_error_characterization_in_microwave_transponders.
Yes, it seems to me that a band limiting filter on the input would be absolutely necessary, since the sampling BW of the ADC is so high.
Also, run ADCs at full sampling rate, then use low pass filtering (Hogenauer/CIC filters?) with decimation in the digital domain. You will get extra bits of resolution that correspond to the effective oversampling (ADC SPS / Decimated SPS) possibly allowing a smaller ADC word width.
Raspberry Pi is your friend in a project like this! We used a dsPIC series processor in our work because we already had an ethernet interface already up and running on this device and all the chips are hand-solderable (TQFP instead of BGA).
Looks like a great project. I will be lurking around when you post updates!
Cheers,
Bill
On 01.09.19 17:49, AC0XU (Jim) wrote:
Jan-Derk-
Excellent and exciting work! Thanks for sharing with the newsgroup...
I have a couple of questions:
-
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...
-
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?
-
What algorithm are you using for the digital ZCD?
-
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 have been experimenting with DDMTD setups using commercial 14- and 16-bit simultaneous-sampling digitizer boards, and processing the phase data at the full rates (from a few MHz to 250 MHz or so sample rate) by correlation method instead of ZCD. The results have been o.k. but not quite as good as I was hoping for. There is a complex relationship between the sample rate and performance which I haven't quite worked out. Also, the number-crunching takes a while on conventional PC.
Thanks-
Jim
Jim
time-nuts mailing list -- time-nuts@lists.febo.commailto: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.
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.
- 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.
- 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.
- 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.
- 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.
Correction:
On Sun, Sep 1, 2019 at 8:24 PM Jan-Derk Bakker jdbakker@gmail.com wrote:
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).
That was indeed too good to be true. A case of me misreading my own log
file format: the RMS error is 0.0287 of a sample period, which at 100ksps
corresponds to 0.287 microseconds, or 287 femtoseconds at signal
frequencies for a 10Hz/10MHz DMTD. (Multiply by 10, not divide by 10...).
My apologies,
JDB.
On 9/1/19 10:10 AM, Bill Slade wrote:
Hello,
This is a topic that interest me greatly as well. Some of the work we have done uses a digital frequency tracking loop to generate frequency errors directly from sampled data using a sampling system and ethernet system of our own design. We opted for using a look-up table-based DDS in the final frequency conversion to baseband (you mentioned considering CORDIC) and CIC filters/decimation..all in FPGA (Altera Cyclone III). This was done for testing two-way coherent transponders. See a description herehttps://www.researchgate.net/publication/332241644_Coherent_tracking_error_characterization_in_microwave_transponders.
This is quite interesting.. It's always a challenge to adequately
characterize the turnaround performance of a transponder, particularly
in a rapidly changing Doppler environment.Say your probe is orbiting
Europa or Titan, and you want to do precision radiometric measurements
for radio science.
back in the day, with an all analog transponder, you could test at
constant frequencies, and do some analytical stuff to estimate
incremental ADEV in the turnaround, as well as the imperfections from
tracking a higher order variation in Doppler than the loop order. And
mission design didn't do orbits around moons, but flybys (e.g. Cassini,
Galileo, Voyager) But these days, most transponders implement the
carrier tracking loop in software, and there's always all sorts of
arguments about what the implementation of that loop does to the turnaround.
Yes, it seems to me that a band limiting filter on the input would be absolutely necessary, since the sampling BW of the ADC is so high.
and, probably, on the sampling clock - the clock input on these kind of
devices is also quite wideband