I was initially testing one of your ADCs successfully, and suddenly I started getting some rather bizarre FFT results. What’s going on?
I received this inquiry recently and I was able to resolve it rather quickly. The designer’s problem is illustrated in the FFT results below:
What the customer reported was that not only did the FFT results seem crazy, they were also inconsistent. This behavior was also consistent with my initial guess at what was happening: the clock source was turned off or not connected, and the converter’s input sample clock receiver was oscillating on its own. This can also happen if the cable connecting the clock is intermittent or a component in the signal path is flaky. As I said, this one didn't take too long to solve because I’ve seen similar results many times. Figure 2 has a flavor of some other FFTs you might see in this operating condition:
In almost all applications, you want the sample clock input to be a single frequency. Any variation due to phase or thermal noise, frequency instability, or unwanted frequency content will cause the expected relationships between the sample clock and analog input signal to break down when you look in the frequency domain. See application note AN-756 for some common examples of how subtle phase noise or modulation on the clock can distort the input signal as it is sampled.
What is the culprit in this case? The sample clock inputs for high speed ADCs are typically differential inputs that share the same common-mode bias, and the receiver has a very high gain. So, with no differential signal applied, the inputs are biased at the same voltage and any noise that is not common mode can cause the sample clock receiver to oscillate. In this condition, the oscillation will not be a pure frequency (if it were, it might be a nice feature). Instead, the frequency will vary randomly. With the sample clock frequency varying randomly, the analog input’s energy will be spread across the Nyquist bandwidth in the frequency domain.
In most cases you will just want to recognize this and restore the intended clock reference to continue with your testing. But if you want to verify that this is the issue, observe the ADC’s data clock out (DCO) (note—this is not applicable to JESD204B outputs). This is usually a delayed replica of the ADC’s sample clock, or a divided down version of the sample clock, if you are employing any digital features that decimate the data rate. For the good and bad FFTs in Figure 1, the data clock outputs are shown in Figure 3:
As you can see, the period is varying as we expected. I certainly understand why you wouldn’t recognize this on the first encounter (or even first few). On face value it looks like the test bed is functioning, but the results are suddenly confusing. Was the ADC damaged? Is the data capture confused? Is the software corrupted? No, there is just a missing signal source.