Stuck codes in samples from ADC

Question

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 :-)

Answer 1

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.

Answer 2

As an extra test, check your ADC for 'missing codes' with an impeccable source, a large capacitor shunted by a resistor, connected directly to the ADC input. Charge it up, let it run down. No ground loops, no noise injected from power supplies, low impedance, low/no noise, guaranteed by design and simplicity to pass through all voltages in order between the start and the end of the test run. Choose a discharge rate to give you theoretically several counts at each code. It's not linear, but that's why it's an extra, not the only, test.

Last time I built a DAQ system that had that sort of behaviour (and tested for it with the RC I've just suggested), it had crosstalk from the digital outputs back to the analogue input.

Answer 3

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).