ADC conversion error  - Page 1
Forum section: electronics / projects

author: DarkLight
author_rank: Contributor
timestamp: April 26, 2021, 12:17:25 am
content: I am using ADS1219 to read AIN2 and AIN3 alternatively, AIN3 readings are fine but AIN2 randomly generate wrong values. Here as the plot shows values less than 5 which are marked with red circles are the wrong ones.I altered the following that I thought may help to fix this problem but nothing worked.1. Reduced I2C from 400k to 100k.2. Change SCL & SDA pull up resistors.3. Add as many delay as possible in reading C++ codes.I ran out of my options. I think something maybe wrong with ADS1219 itself. Is this an isolated issue or has anyone seen something similar?

author: ajb
author_rank: Super Contributor
timestamp: April 26, 2021, 02:51:00 am
content: What's connected to the adc input on each channel? Can you swap the circuitry between the two inputs? Are the values that are wrong the raw adc values or the values after you convert them in software?

author: DarkLight
author_rank: Contributor
timestamp: April 26, 2021, 07:25:12 am
content: Thanks for the replyDC volts are connected to AI2 and AI3. But I am not able to swap the channel easily because of the voltage range and resistor dividers, but I will check with the channel 0 and channel 1 (AI0 and AI1).The values that are wrong should be both the raw values and so the converted one. I'm 99.99% sure that the conversion is fine. But I'll check them too.Thanks again for the tip!

author: Twoflower
author_rank: Frequent Contributor
timestamp: April 26, 2021, 07:38:53 am
content: That looks like a pure digital error. Can you post the raw data from those outliners and few of the ones that are correct? That might shed some light what's going on.Have you checked that you're using the right SCL edge to sample in the SDA signal?

author: ajb
author_rank: Super Contributor
timestamp: April 26, 2021, 05:48:24 pm
content: Sometimes even simple-seeming conversion functions can have surprising glitches on certain inputs due to integer overflows in intermediate values or terms getting rounded to zero. It's worth writing a simple test to sweep the input to the conversion function with your entire expected range and show the output as a sanity check. If it's nonlinear then plotting the result may be helpful. If the input range of the conversion function is smaller than the range of the variable that is passed to it (like a 12-bit value passed as a 16-bit int, or where the minimum expected value isn't zero) then it's also worth guarding the conversion function against out-of-range inputs in case of an error in the hardware or a lower level driver or something.There's of course the chance that there's a hardware problem, especially since it sounds like you have at least a resistor network on the ADC input. Something like a missed solder joint might give normal results most of the time but be an intermittent open circuit under vibration/temperature change. Or there could be a problem that makes the input particularly susceptible to induced noise, like a transient on an adjacent trace/wire.If you haven't already done so, it may be worth stripping the application down to ONLY run the ADC, with as much other functionality of the board disabled as possible to reduce the number of potential complicating factors in the hardware and software.

author: DarkLight
author_rank: Contributor
timestamp: April 27, 2021, 04:42:57 am
content: ajb@I checked channel 0 and 1, the error happens in all channels, so I might be wrong it should also happen in channel 3. It appears in the raw data as well. The right column below is the raw values and the left ones are the calibrated ones.| V_Val:+32.0065| V_Raw:+6557023| V_Val:+32.0064| V_Raw:+6556995| V_Val:+32.0064| V_Raw:+6556996| V_Val:+32.0064| V_Raw:+6556991| V_Val: +1.3632| V_Raw: +278881| V_Val:+32.0065| V_Raw:+6557012| V_Val:+32.0066| V_Raw:+6557030| V_Val:+32.0065| V_Raw:+6557018| V_Val:+32.0064| V_Raw:+6556993| V_Val:+32.0066| V_Raw:+6557028@TwoflowerI am using Arduino ADS1219 library, I need to check the source code to figure out how the sampling is taking place based on the SCL edge.

author: Twoflower
author_rank: Frequent Contributor
timestamp: April 27, 2021, 06:27:34 am
content: OK, that rules out any problems while converting the values from LSB to V.But unfortunately the binary pattern of the OK and the bad one doesn't look like a simple bit-flip to me either. A flipped MSB or something in that ballpark would have had been my guess. So I currently wouldn't expect any problems with the SCL edge; at least for receiving data. I assume you checked the signal quality of the I2C signals and the supply of the controller and the ADC.One other idea would be that the controller send bad data to the ADC. That's harder to detect. Do you know the expected voltage of the other channels. Remember to think with LSB (V_Raw) here as you probably have other voltage dividers there and other factors for the converting the values.To narrow down the place of the problem a logic analyzer would come in handy. As the errors seem to happen in that low frequency for a Scope.

author: djerickson
author_rank: Regular Contributor
timestamp: April 27, 2021, 11:22:41 am
content: Ah yes, sporadic ADC errors. Been there, done that. It looks like a digital problem with 2 of the higher bits. The error is about 6.428e6 which is about 3 x 2^21 or 0x0600000. Those 2 adjacent upper bits could have digital cross-talk. I've seen similar ADC issues when AGND and DGND were not solidly tied together at the ADC. If that's not it, check your digital supply bypassing.And check your SPI interface timing. Maybe clock is inverted?Good luck!Dave

author: DarkLight
author_rank: Contributor
timestamp: May 02, 2021, 05:51:31 pm
content: Hey Guys,I finally found the root cause of the error! Although it wasn't any of the issues that you mentioned, without your tips and suggestions I wouldn't be able rule out all other possibilities and find the main cause fast.The problem hadn't anything to do with I2C quality, grounding or supply bypass. I check I2C signal with an oscilloscope, it was much cleaner than I expected. I intentionally removed supply bypass and also disconnected AGND and DGND to see any changes. And yes, there was. Some random noises on the ADC in addition to the wrong values that I wanted to fix. Sometimes I have to wait for hours to make sure I get the original error.Anyway the problem was the ADC1219 itself. In order to read data I continuously keep checking bit 7 of Status Register for availability of a new conversion (page 29 data-sheet). "0" value means no data available and "1" means the conversion is ready. Bits 0 to 6 as mentioned in the data sheet are "Reserved". So naturally I only checked the last bit. But because of the problem, I decided to checked the whole 8 bits of the Status Register for the sake of curiosity. There is either 0x60 (no data) or 0xE0 (data available),but the error appears when the value of this status register jump to 0xFF!!! I have no idea what it means since I couldn't find anything on the data sheet. But what I see when the register value is 0xFF although the bit 7 is one, the conversion is not ready and I have to ignore it.I replaced the ADC and the new one behaved in the same way. Maybe I am checking the status register too often? I don't know.

author: ledtester
author_rank: Super Contributor
timestamp: May 02, 2021, 10:42:23 pm
content: My replies got wiped out with the DB restore, so here's the gist...Make sure you are using the your I2C library calls correctly. For instance, the Arduino Wire.read() call will return -1 if you read more bytes than were actually returned by the responding I2C device. Use Wire.available() to determine the length of the response.Use a scope or logic analyzer to see what the ADS1219 is actually responding with. Maybe there is something else spuriously interfering with the I2C bus. If you have a >= 3 channel scope or a 2 channel scope + ext. trigger, have your MCU raise the trigger on another GPIO pin when it sees the FF. Then scroll back in the capture to see what was on the SCL and SDA lines.