# Stuck codes in samples from ADC

I am currently testing a 16-bit DAC and a 18-bit ADC. In many tests I have found the ADC to get "stuck" at codes, especially at the ends of the input range.

Both the DAC and ADC operate in bipolar mode and are interfaced with analog circuitry that amplifies/attenuate and also provide common mode offset and clipping to ensure that signal fits the differential inputs on the ADC. The data converters are connected to a micro controller with SPI. The data is transferred from the micro controller to a PC with a serial port.

I am using the ADC to sample the output of the DAC in order to test precision and noise etc. The resulting data should be straight line when the DAC is used as x-values and the corresponding ADC samples plotted on the y-axis.

Note that the full scale range is different: The DAC outputs voltages between -20.48 and 20.4794. The ADC reads voltages between -16.384 and 16.3839.

The plot below shows the samples from the ADC when the DAC is set from 0 to 65535 in steps of 1 LSB. The total number of samples is 65536.

Zooming in at the center of the full scale range (x-span: 1000, y-span: 5000), the plot looks like this (a little noisy, but otherwise OK):

However, zooming in at the lower part of the full scale range, stuck codes are clearly visible:

The same can be said about the upper samples:

Note that all three plots are on the same scale but different areas.

Looking at a segment of the data is interesting (keep in mind that the analog interfaces introduces some gain and offset error):

One can clearly see, that the ADC is stuck even though the resolution of the 18-bit ADC is better than the 16-bit DAC.

Even more interesting is that the difference between two stuck codes, like 255648-255712 = -64 and 255712-255808 = -96, seems to be in multiples of 32. That rules out any problems with the analog interface, I think.

To show the problem better, I made a plot of the difference between one sample and the next sample over the entire full scale range:

The plot clearly shows that stuck codes does not occur at the center of the full-scale range. Moving towards the ends of the range, stuck samples become more and more obvious.

In order to solve the problem, I tried to slow the SPI-communication and also sampling at lower speeds. This did not make any difference. I also wonder if the problem could be the conversion of the 18-bit ADC output from Two's Complement to Offset Binary. I use this code to do the conversion, which I believe is correct:

uint32_t y = (131072 ^ Y >> 6) & 0x3FFFF; // Y is 18-bit Two's Complement


So, what could cause this problem? I have also checked the voltage reference, decoupling and other analog issues that might cause the problem. Still the stuck codes are multiples of 32, it looks to me like the problem is digital rather than analog.

Any help or ideas are appreciated! Thanks in advance :-)

• First point is that you may not know (yet) whether the ADC or DAC is at fault. I would suggest running the DAC around its centre and adding 15V (near full scale V) so you know the DAC is operating well; does the ADC performance improve? Ditto run the DAC near -ve full scale and add voltage, so the ADC is near the centre of its range. – Brian Drummond Jun 10 '14 at 15:24
• Thanks for your brilliant idea :-) I will return with the results later. – pvh1987 Jun 10 '14 at 15:35
• As the ADC codes are nice round numbers, it's likely the ADC is the problem, but worth making sure. – Brian Drummond Jun 10 '14 at 15:42
• Using a higher resolution DAC to measure the DNL and INL of an ADC is standard practise. Simply because it is way easier to make a higher precision DAC than it is to make a ADC. You just have to make sure your DAC is OK. I agree with Brian that is likely the ADC. – placeholder Jun 10 '14 at 15:52
• Which ADC (and DAC) are you using? What you see might be well within the specs. For instance, one Freescale chip I receintly cehecked has a 16-bit ADC (as the first page of the datasheet proudly states), but the specification section states the mimimum effective number of bits at 11.4 when averaging 4 samples. That's a lot less than 16. – Wouter van Ooijen Jun 10 '14 at 17:19

Interesting. I don't think I've ever seen this anomaly before.

It's often convenient to think of a SAR ADC as if it samples the input analog voltage at some instant in time. In practice, there is a narrow window of time where changes in the input analog voltage -- or noise on the analog voltage reference, or noise on the GND or other power pins of the ADC -- can affect the output digital value.

If the input voltage is slowly rising during that window, then the less-significant bits of the SAR output will be all-ones.

If the input voltage is slowly falling during that window, then the less-significant bits of the SAR output will be all-zeros.

A very narrow noise pulse at the "wrong" time during conversion can have a similar effect.

Right now my best guess is that you're using some sort of analog switches or op amps that don't work quite as well (higher resistance or something) near the high and low power rails as they do near mid-scale, somehow letting in one of the above kinds of noise, which causes the less-significant bits to be all-ones or all-zeros.

I've seen some sigma-delta ADCs and sigma-delta DACs that have good resolution at mid-scale, but worse resolution near the rails -- but the effect looks different than what you show.

The "plot of the difference between one sample and the next sample over the entire full scale range" is fascinating.

If I were you, I would make a similar plot that, instead making the X value the difference between one sample and the next, make the X value the least-significant 6 bits of the raw ADC output sample. That would quickly show if the "stuck" values are mostly lots of 1s in the least-significant bits (maybe input is slowly rising?) or lots of 0s in the least-significant bits (maybe input is slowly falling?).

I am sampling "pulsed" DC voltages. That means that for each measurement I put a voltage on the DAC, let it settle for at least 100 times it's settle time, then tell the ADC to convert - and when conversion is finished, I put the DAC back to 0 V.

My understanding is that when ADC manufacturers say "no missing codes", the test they use involves several capacitors adding up to a huge capacitance directly connected to the ADC input, and some system driving a large resistor connected to that capacitance that very slowly charged or discharged that capacitor, slowly enough that the ADC is expected to see exactly "the same" voltage (within 1/2 LSB) for several conversion cycles before it sees "the next" voltage (incremented by 1 going up, decremented by 1 going down).

If I were you, I would see if such a "continuous slope" test gives the same weird "stuck code" symptoms as the "pulsed test". Perhaps that would give more clues as to exactly what component(s) are causing this problem.

Please tell us if you ever figure out what caused these symptoms.

What's the technology used in these converters (type)? What's sampling rate? Try to slow down the frequency used in order to eliminate problems with ADC input impedance coupling. Linking a DAC to an ADC has limited relevance when evaluating the performance, due to the increasing of issues regarding quantization errors (also differents). Try to build a plot like that above, but ramping the input using a linear voltage, instead a DAC output - for comparison. Remember the noise from operational amplifiers interferes as well (since you are using high resolution). Furthermore, ADC exhibits "missing codes". The datasheet states something like "...no missing codes to n bits..." (where n < ADC resolution in bits).

• As I just commented above, the DAC is DAC8831 from Texas Instruments (R2R-ladder) and the ADC is AD7691 from Analog Devices (SAR). The datasheet states "no missing codes" for all 18 bits. I have measured the noise of the ADC including analog interface (connecting the analog input circuit feeding the DAC to ground and taking 65536 samples). The RMS noise in LSB's (standard deviation) is 2.80 and the histogram looks quite like a standard distribution. If noise is the problem, that does not explain the "digital steps" between stuck codes, like 32, 64, 96 etc. Very slow sampling does no difference – pvh1987 Jun 10 '14 at 19:13