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. _______________________________________________ time-nuts mailing list -- [email protected] To unsubscribe, go to http://lists.febo.com/mailman/listinfo/time-nuts_lists.febo.com and follow the instructions there.
