TI ADS1248 24bit ADC app note error

adcprecisionrtd

I'm looking through the following app note http://www.ti.com/lit/ug/slau520/slau520.pdf

If we look at page 19 of that pdf, there's the following histogram.
enter image description here

I'm trying to work backwards to see what voltage they received for the various bins, but I'm not sure if my values are correct.

According to their design,
Vref = 1.64
Rzero = 120
PGA = 128

The resolution or 1LSB would be \${Vref \over PGA} \over 2^{23} – 1 \$ or ~ 1.52nV

1.52nV * any of the bins = ~ 12mV.

Which to me, seems way to high for this type of circuit. That would translate into 7 ohms off, which is huge in this case. The ideal value we should be seeing is somewhere in the vicinity of 0 because of the Rzero set to 120ohm, it would pretty much cancel the 120 ohm resistor they are using for an RTD.

The only thing I can think of that would make this data make sense, is, if they offset the data by 2^23 -1 to ensure that all bins are positive. I couldn't find anything in any of the pages that would say that this is what they did.

Is my thinking correct that they shifted everything so rather than having a range of +/- 8M, its now just 0 to 16M ?

Best Answer

They're using a ADS1247 for the ADC in that app-note.

This is a 24 bit ADC, so the maximum output count is \$2^{24}\$ or 16,777,216. Considering their values are ~8,380,411, which is very close to \$\frac{2^{24}}{2}\$ (which is 8,388,608, so the offset is 8,197).

Based on that fact, I would assume that they're simply doing a improper twos complement conversion, which would effectively do exactly what you describe in the question - shift a range of +/- 8M to 0-16M.

The ADC in question (ADS1247) does not seem capable of producing a non-signed output, so I have no idea how they're getting those values, but they wouldn't make sense unless they're converting their signed readings into unsigned numbers somehow.


Basically, I suspect your thinking is entirely correct. What they're showing looks exactly like what you would see if one was improperly converting a signed value to an unsigned value.

Unfortunately, they don't detail the digital end of their test-setup in any way, so there is no way to know for sure.