The BlasterAmp [1] has proven useful to me in testing all sorts of analog-to-digital converter (ADC) circuits, even my digital oscilloscopes. While I mainly conceived it to test integrated ADCs in microprocessors, it can be used to test even RF ADCs. Yes, even that several hundred MHz downsampling ADC can be tested with an audio tone, as you can always break into the signal path right before the ADC and inject a baseband test signal.

This not only tests that the ADC is basically functioning properly, but that the signal processing code is basically operating properly as well. Over the years, I have seen a fair amount of improperly functioning code that was blamed on the ADC being “bad”.

**What To Measure**

Identifying a useful analog-to-digital converter (ADC) metric that a variety of people with varying technical backgrounds can easily use and understand is one of the goals of the BlasterAmp project for me. Because of the confusing specifications and measurement methods between ADC manufacturers, many times the ADC seems to be picked on the raw number of digital bits alone.

That would be a good metric then, the “number of bits” (N), or for an imperfect ADC, the “effective number of bits” (ENOB), as everyone can visualize that metric. That is everyone’s main goal anyway – to have some minimum number of bits in their signal processing.

I am sure that everyone has seen the classic ADC signal-to-noise ratio (SNR) calculation [2],

SNR = 1.76 + 6.02(N) (Eq. 1)

Where SNR is the signal-to-noise ratio in dB, and N is the ideal number of ADC bits.

Equation 1 is derived by calculating what a perfectly linear ADC’s quantization error is, so this is the best-case SNR for any perfect N-bit ADC. By easy extension, you can rearrange the equation to solve for the number of bits, N given a measured SNR.

N = (SNR – 1.76) / 6.02 (Eq. 2)

Unfortunately, this is where things get unclear quickly. Equation 1 was derived from a perfect ADC, whereas any real ADC will have linearity errors, which will lead to harmonic distortion. Also any real ADC will have noise above the best case calculation, and some random spurious signals are thrown in for good measure.

To make things worse, some ADC manufacturers define SNR as a measurement of the ADC’s noise floor only, excluding harmonics and random spurious content, while others define SNR as the ratio between the signal and the next worst single spurious signal. Yet all spurs and harmonics that cannot be processed away must count against the effective resolution or ENOB of the ADC.

This then requires a different measurement that takes into account the non-ideal behaviors, and most manufacturers call this Signal Including Noise and Distortion or SINAD for short,

SINAD = Signal / (Signal + Distortion + Noise + Everything Else) (Eq.3)

To make matters even more confusing the ADC people have redefined the classical definition of SINAD that has been used since the beginnings of radio as a measure of a radio receiver’s performance [3], so be careful to not use the classical radio receiver definition or get confused by it.

**How Hard Could This Be?**

When Hewlett-Packard first started making high-performance Waveform Digitizers, they would calculate ENOB by digitizing a high purity sine wave with sufficient points and then curve fitting a perfect sine-wave to the measured data. The difference between the real ADC data and the perfect sine wave would be the sum of all the distortion products and noise.

This SINAD value was placed into Equation 3 and the ENOB was calculated [3]. The problem with that method is that it mostly requires a variable frequency source that can be added to whatever sampling rate was being used to get a sufficient number of points to faithfully represent a sine wave.

This is something that the BlasterAmp is not designed to do, as it can only produce audio range signals, making the point about digitizing enough of a waveform somewhat problematic when you have only one variable to control, i.e., the sampling rate.

Today fourier transforms (FT) are used to measure ADC’s, and usually a 1 or 2 kHz full-scale input signal is used, but this too has pitfalls. The first is that the noise floor that you see will be different depending on how many samples in the FT you have taken. This is called processing gain and is a result of the noise spectral density being the same, but when you increase the number of samples, the FT bin width decreases, and hence the noise in each bin decreases and the FT bin appears to get lower in amplitude (**Figure 1**).

** ****Figure 1** Processing gain lowers the apparent noise floor by a factor of PG = 10*log10(M) dB, where M is the number of points in the FT. Here the difference between 1,000 points (blue trace) and 100k points (red trace) in the FT results in a processing gain and apparent noise floor difference of 20 dB.

The second problem is that noise cannot be measured the same way as signals are after a normal FT that has a window applied to the raw data. Normally, some window function is applied to the ADC data before the FT to reduce the spurious sidebands that arise because the input test signal is not perfectly coherent with the sampling signal [4]. The window function adds a gain or loss term to the FT that must be accounted for.

With signals, this is sometimes called the “coherent gain” and to make things even more difficult, the window adds a different gain term for noise analysis that is sometimes called the “incoherent gain”. This means if you are measuring FT signal amplitudes, you have to use one window correction factor, and if you are measuring noise, you need to be using a different window correction factor [5].

You may have run across this if you use a Spectrum Analyzer and want to measure noise. Most Spectrum Analyzers have a “Noise Marker” function that gives the marker a correct readout of any noise being measured. With analog spectrum analyzers, this correction for noise measurement was required because the log detectors used responded to signals and noise differently, with a modern FT-based spectrum analyzer, a different correction is needed because of the window function that needs to be added to the ADC data before the FT. I have found that many online tutorials miss this important distinction and hence are not calculating their FT noise properly.

Remember all we wanted was a simple ENOB metric and now we are all hung up not only on how to measure the true signal-to-noise ratio but also on different FT scale factors that need to be applied to properly measure noise and signals… Like always, we end up with this rabbit hole of confusing terms, different definition of terms, and calculation steps that are many times not discussed. Is nothing easy anymore?

**The Simple Route**

I didn’t want to write yet another FT SINAD / ENOB analysis program, and I would just rather use some pre-made solution. While all ADC manufacturers have some sort of analysis software for their ADC’s most are closed source and can only be used with the bit-streams out of their actual hardware devices.

Analog Devices has an interesting analysis program called VisualAnalog [6]. It is interesting because it can work with actual hardware or act as a somewhat general-purpose DSP simulator. VisualAnalog is a drag-and-drop, block-based GUI that with just a few blocks can be programmed to read a text file containing any ADC data, and then analyze the results as shown in **Figure 2**.

**Figure 2** VisualAnalog program script to read ADC data from a test file and then analyze it. This script, along with instructions, can be downloaded from Github, see reference [7].

To test whether VisualAnalog was measuring the ADC data properly, I made a perfect quantizer simulation in Python to generate various bit depths, additive noise, and spurious signals. Since my Python simulation started with known, yet separate signal, noise and distortion products, I was able to sum these all separately in the time domain to find the actual SINAD. I saved the data from every simulation run and analyzed it with VisualAnalog, which is FT based, and then compared the results to my Python analysis. The results were always less than a 0.2 dB difference from my calculations.

So I feel pretty confident that VisualAnalog is doing a proper calculation across a range of scenarios. The only place where VisualAnalog fails is that it appears to treat non-harmonically spurious signals as noise. Very few real-world ADC’s have large amounts of non-harmonic spurs, but it is something to keep an eye on.

**Some actual examples**

To show the typical kinds of output one gets when testing an ADC, I measured a 12-bit embedded ADC with the BlasterAmp under various sampling rates. I show the various measurements and resulting FT transforms in **Figure 3**.

** **

**Figure 3** Using the BlasterAmp as an input, I measured a 12-bit embedded ADC, applied a Blackman-Harris 92 window (BH92) [8], and then took the FT of the resulting data. I adjusted the number of ADC samples so that the bin width would be 1 Hz in all the examples above. (a) 100 kSPS, 100k points, (b) 20 kSPS, 20k points, (c) 1.1kSPS, 1,100 points. This last plot shows the 1 kHz BlasterAmp input tone aliased to an apparent 100 Hz.

The first thing that is noticeable from the FT plots in **Figure 4** is that the noise floor is drastically different looking in each plot, welcome to the real world!

Looking at Figure 3a, you might wonder if the “spike” kind of signals in the noise floor are spurious signals, or noise of some sort. One quick way to tell is to rerun the FT with a smaller number of samples. If the “spikes” change in amplitude, then they are noise floor related and are not discrete spurs.

In this example, I did rerun the FT analysis with fewer points and the “Spike like” signals did change in amplitude, thus indicating that they are indeed noise, not signal, and should be processed as such.

This is an illustration of the difficulty of measuring SINAD properly. A decision needs to be made about each FT bin to the effect of: “Is the FT bin noise such that it gets the window noise correction factor applied, or signal and thus gets the window signal correction factor applied?”

**Table 1** shows the correction factor differences for each of these FT plots. Since the bin width is 1 Hz for all the plots, both the signal and noise window scale factors are the same for each plot in Figure 3.

**Table 1** The difference in the BH92 window scale factor for the plots shown in Figure 3 is shown above. Since the bin width is a constant 1 Hz for each run in Figure 3, the scale factors are the same for all the runs.

We can see from Table 1 that the difference between the noise and window scale factors for my examples is 3 dB. This illustrates the problem of misidentifying a signal as a noise component and vice versa. Every misidentified component could be added to the final result with a 3 dB error. The effect this has on your final result will depend on the amplitude and number of components misidentified.

The error could be much worse, however. For instance, if the sample rate was 1 MSPS and the FT size was 32,000 points, then the window scale factor difference between signal and noise would be on the order of 18 dB instead of 3 dB. Generally, the bigger the FT bin width, the bigger the delta between the signal and noise window correction factor [9]. Running a VisualAnalog analysis on the data from Figure 3a is shown in Figure 4.

** **

**Figure 4** The VisualAnalog script results of running the 100 kSPS, 100k points data from Figure 3a. The VisualAnalog calculated SINAD is 47.9 dB.

Using the SINAD value from Figure 4 in Equation 4 results in an ENOB calculation of 7.7 bits. All the plots of Figure 3 have the same SINAD, only varying in the tenths of a dB.

ENOB = (SINAD – 1.76) / 6.02 (Eq. 4)

**Conclusion**

With all the confusion on terms and different definitions between semiconductor manufacturers, it is difficult to compare data sheet parameters beyond the raw number of digital bits, and digital bits never equal “actual bits” of resolution.

I have found that the effective number of bits (ENOB) is an easy to use and understand term for audiences of a variety of technical backgrounds, as it directly relates to the resolution of any digitized point, and it forgoes any mention of dB which confuses a lot of less technical folks. Likewise, using ENOB prevents any misinterpretation of the differences between SNR and SINAD measurements, which happens a lot.

The “bottom line” for determining the performance of any ADC is:

- It is important to measure your ADCs, especially ones embedded in other ICs.
- It is important to find some analysis algorithm that is reliable and to stick with it, as every piece of analysis software will give you different results.
- Keep it easy for others to understand, use one set of definitions, and beware of blindly comparing data sheet numbers between manufacturers.
- Use a single ADC performance definition, like ENOB, and stick with it.

**References**

[1] Steve Hageman, “Simplify testing of embedded analog-to-digital converters”, EDN.com, June 2022 https://www.edn.com/simplify-testing-of-embedded-analog-to-digital-converters/

[2] Bonnie Baker, “What does the ADC SNR mean?”, EDN.com, May 27, 2004 https://www.edn.com/what-does-the-adc-snr-mean/

[3] Classical or Radio SINAD definition (BEWARE: This is not the same definition of SINAD that ADC manufacturers use), https://en.wikipedia.org/wiki/SINAD

[4] Steve Hageman, A series of articles on the FFT, DFT, windows, and techniques,

[5] Martin B. Grove; “Measuring Frequency Response and Effective Bits Using Digital Signal Processing Techniques”, Hewlett-Packard Journal, February 1992. https://archive.org/details/hpjournal

[6] Analog Devices, Inc. VisualAnalog, https://www.analog.com/en/design-center/interactive-design-tools/visualanalog.html

[7] The VisualAnalog script and test data are available on my GitHub at, https://github.com/Hagtronics/BlasterAmp/tree/main/VisualAnalog

[8] G. Heinzel, A. Rudiger, and R. Schilling, “Spectrum and spectral density estimation by the Discrete Fourier transform (DFT), including a comprehensive list of window functions and some new ﬂat-top windows.”, Max-Planck-Institut fur Gravitationsphysik, February 15, 2002

[9] For brevity, I have not shown how the correction factors are calculated as I have gone over that many times before. See references [4] and [8], or use one of my open-source libraries to run the calculations for yourself,

—*Steve Hageman has been a confirmed “Analog-Crazy” since about the fifth grade. He has had the pleasure of designing op-amps, switched-mode power supplies, gigahertz-sampling oscilloscopes, Lock In Amplifiers, Radio Receivers, RF Circuits to 50 GHz and test equipment for digital wireless products. Steve knows that all modern designs can’t be done with Rs, Ls, and Cs, so he dabbles with programming PCs and embedded systems just enough to get the job done.*

**Related Content**