# My voltage divider quit working - this is weird?

#### zirconx

Joined Mar 10, 2010
97
Hey this is odd. I'm using a different program now, before I was using a C program I found on github. This node program is some code I threw together from some examples. At first I get 0v on channel 0, the one connected to ground! That is the correct value. But then it switches to 8191. Odd huh?

When I ran the program again, it starts outputting 8191 right away. But occasionally I'll get a 0.

Here is the code.
Code:
const ADS1115 = require('ads1115')
const i2c = require('i2c-bus')
i2c.openPromisified(1).then(async (bus) => {
var coef = .125

for (let i = 0; i < 1000; i++) {
value = value * coef
console.log('0: '+ value)
value = value * coef
console.log('1: '+ value)
value = value * coef
console.log('2: '+ value)
value = value * coef
console.log('3: '+ value)
}
})

#### zirconx

Joined Mar 10, 2010
97
Put your oscilloscope on the voltage input pin and see if the scope is saying the same thing that the ADC is saying. This will tell you if your problem really is noise at the input pin, or a different problem. You can try the Auto button, but that rarely gets the best results. If the noise isn't strong and consistent then it will probably show you 60Hz noise from the power wires in the walls. For manual mode, try these settings; DC coupled, rising edge, 0.5V/div, auto trigger mode. Depending on how bad the noise is, you will see a DC line or a bunch of squiggles. Scroll your trigger point to be just a tad above the DC line, or about the middle of the squiggles. Now switch the trigger mode to Normal and you should start getting a picture if what your noise looks like. You might have to play with the time base until you find the frequency of your noise, but try starting around 200usec/div and go up/down from there.

Edit --> If your pin that is connected directly to ground is reading 8v, then you have a bigger problem.
Here are some readings from my scope. All were on AUTO mode, except the one where I tried to use the settings you suggested.

Here is the output of the voltage divider

Here is the 5v input to the pi

Here is the 3.3v rail from the pi. This is what is powering the ADS1115.

Here is channel 0 on the ADS1115, which is connected to ground (and reads 8191 through my software)

Here is the 5v input to the pi, NOT on auto, I think I used most of the settings you mentioned... Now that I'm thinking about it, I didn't adjust the trigger like you suggested.

Does this look bad or normal?

I captured some of the i2c signals. I don't know what to look for but I don't see anything obviously wrong.

Last edited:

#### MrSoftware

Joined Oct 29, 2013
1,676

At the same time, look at the 5V voltage regulator that you're using to power the Pi. It is likely that the noise on the 3.3v line is the same noise as the 5v line. If the 5V supply is external then see if you can get a better one, or add a lot of capacitance to the input to see if you can quiet it down. Run it from a battery if you can, and if all your problems go away then you know that the 5V noise was the problem.

Joined Jan 15, 2015
5,140
Is your scope probe properly grounded? Your scope probe should have a grounding clip. That ground should be tied to your Raspberry Pi ground as well as the A/D ground, so all grounds should be common. Including the power supply ground of whatever power supply you are using to power everything.

Ron

Ron

#### djsfantasi

Joined Apr 11, 2010
6,196
Does this give you a hint? 8191 in binary is three 0s followed by 13 ones.

how many bits does your ADC return? And what does all 1s signify?

#### ci139

Joined Jul 11, 2016
1,198
If the 5V supply is external then see if you can get a better one, or add a lot of capacitance to the input to see if you can quiet it down.
the capacitance alone won't do the trick (no matter how much you got ← and that usually has a limit of one kind or another (e.g. shorting your 5V PSU at startup) ) . . . or at least won't do it as efficiently as some RC , LC , DLC or other filter

#### MisterBill2

Joined Jan 23, 2018
5,244
Get a well filtered REGULATED supply to run the system with. Power noise and ripple will always cause problems.
I had made the guess that the supply was adequately filtered. It seems that enough initial data was not provided.

#### MrSoftware

Joined Oct 29, 2013
1,676
the capacitance alone won't do the trick (no matter how much you got ← and that usually has a limit of one kind or another (e.g. shorting your 5V PSU at startup) ) . . . or at least won't do it as efficiently as some RC , LC , DLC or other filter
This is not a bad tip as a more complex filter, like an LC filter, could be more effective than just capacitance, but I've seen some pretty nasty ripple cleaned up with just properly placed capacitance, so I personally would try just capacitance first simply because it's easier and might work. I would personally add 0.1uF, 1uF and 10uF and re-evaluate (use ceramic low ESR caps). If no luck then start looking at adding an inductor or ferrite bead, etc.. Your ripple looks to be in the neighborhood of ~235kHz which would not be an unreasonable frequency for a switching supply, so my guess is whatever 5v supply you're using just has a really noisy output.

#### djsfantasi

Joined Apr 11, 2010
6,196
Get a well filtered REGULATED supply to run the system with. Power noise and ripple will always cause problems.
I had made the guess that the supply was adequately filtered. It seems that enough initial data was not provided.
What does ripple have to do with consistently getting either 0x000 or 0x1FFF?

#### MrSoftware

Joined Oct 29, 2013
1,676
It's not known that the ripple is causing 100% of your issues, but it is know that ripple on the the voltage supply to an ADC is AN issue and will more than likely cause bad readings. So fix that first since it is a known issue, then reevaluate the performance and move forward. To leave a known issue will complicate the rest of your debugging.

#### ci139

Joined Jul 11, 2016
1,198
in the neighborhood of ~235kHz which would not be an
now that you mentioned that - the SMPS don't like non-half rectified huge capacitive loads some (phone chargers) have the Schottky at (before) their positive output terminal ? some don't - so it may result in Vout ± α·Vout sine like thing (must be tested with load equvalent resistor before connecting the actual)
articles about - there was couple good ones but it was long ago https://www.google.com/search?q=choosing+proper+capacity+for+flyback+output+filter
https://www.we-online.com/catalog/media/o109026v410 AppNotes_ANP044_ImpactOfTheLayoutComponentsAndFiltersOnTheEMCOfModernDCDCSwitchingControllers_EN.pdf
https://www.analog.com/media/en/training-seminars/design-handbooks/Practical-Power-Solutions/Section4.pdf
http://www.interpoint.com/product_documents/DC_DC_Converters_Output_Noise.pdf
What does ripple have to do with consistently getting either 0x000 or 0x1FFF?
it could be somewhere
http://www2.ing.unipi.it/~a008309/mat_stud/MIXED/archive/A2011/Approfondimenti/Understanding_sigma_delta_CUT.pdf
https://www.renesas.com/eu/en/www/doc/application-note/an9504.pdf
my puter got crashed recently and bookmarks went lost ↑ some pdf-s that didn't ↑ maybe there's some use (it's about quantization noise - not input noise ,though)

Last edited:

Joined Jan 15, 2015
5,140
What does ripple have to do with consistently getting either 0x000 or 0x1FFF?
Well I figure it doesn't but here nor there. Then too, as to the ripple component as shown I can't see exactly how the measurements were taken, I have no idea how the scope probe was used assuming a scope probe was used and if so was a probe ground clip used? The I2C signals look like a ground was omitted at the probe and that is only a guess since I can't see the setup.

About all I really see is a collection of symptoms but I doubt what we see riding along on the I2C path would cause the readings problem. Then too, it wouldn't hurt to see nice clean DC levels on the power supplies. Obviously the ripple component is excessive and should not be there be it a component failure or measurement technique issue it should be rectified or fixed.

Just My Take....
Ron

#### djsfantasi

Joined Apr 11, 2010
6,196
It's not known that the ripple is causing 100% of your issues, but it is know that ripple on the the voltage supply to an ADC is AN issue and will more than likely cause bad readings. So fix that first since it is a known issue, then reevaluate the performance and move forward. To leave a known issue will complicate the rest of your debugging.
I agree with your assessment, about solving known issues before tackling the symptoms of the exhibited problem.

It was me, not the TS, asking is it reasonable for ripple to give a constant value as output from an ADC?

Personally, it is too much of a coincidence that the output of the ADC is always 0x1FF. Even more, the output is all 1s. I’d like an explanation why. I think that there is a sneak connection or a bad connection injecting a constant voltage.

#### MisterBill2

Joined Jan 23, 2018
5,244
What I have discovered is that often, when the effect of one variable being wrong is not well known, is that there are effects caused that the relationship is not obvious. Thus while the specific effect of the power supply ripple is not understood, that does not mean that it may not exist.

#### MrSoftware

Joined Oct 29, 2013
1,676
@djsfantasi it is interesting to have the thirteen 1's in a row, though it is a 16-bit ADC. I didn't read the data sheet enough to say if that's significant. I have debugged ADC issues in the past on a commercial product where the ADC was not giving consistent readings, and the cause was power supply ripple that was much smaller than this.

And just by chance, look what popped up in my YouTube stream today!

#### ci139

Joined Jul 11, 2016
1,198

Joined Jan 15, 2015
5,140
it is interesting to have the thirteen 1's in a row, though it is a 16-bit ADC.
Just as a side note one of those 16 bits is used to tell us the sign of the value being read so only 15 of the 16 bits are used to communicate the value of the voltage measurement. Not that it means much.

Ron

#### zirconx

Joined Mar 10, 2010
97
Thanks for all the responses. I have been very busy at work lately and haven't gotten back to this.

Yes my scope probe was grounded during my testing, I used the short ground clip attached to the probe, and had it connected to a ground on the pi.

FYI in some of my testing I had the board running and connected a ground wire to an unconnected input pin on the ADS1115 - it immediately started reading 8191. So I don't think it's a problem with a particular channel on the ADC. Not to mention I have replaced that board.

#### ci139

Joined Jul 11, 2016
1,198
Not to mention I have replaced that board.
it's dangerous to swap components when the exact cause remains unclear -- i have fallen into this trench -- i burned several transistors , before i fugured out that the LTSpice does not simulate the channel conductivity rise due the temperature rise due the signifficant Ic rise due the output SC . . . basically i wanted to test my current limit - but (i speculate) there was an emitter's limiting resistor missing in the pnp+NPN darlington configuration . . .
. . . as it later came out that this type of darlington has also considerable dependence on the input-supply voltage i likely replaced it with npn+NPN one

e.g. -- solving the primary problem led to the other , led to evaluating the design as inapropriate

Last edited:

#### ebeowulf17

Joined Aug 12, 2014
3,175
I think the 8.192V reading has a much simpler explanation than much of this conversation implies. There's a very slight mismatch between the ground reference at the ADC chip and the ground reference being used to tie pin 0 to ground. That small mismatch causes the ADC to read 0V sometimes, and -0.001V (-1mV) at other times.

As others have pointed out, if the negative numbers being sent out from the ADC over I2C are interpreted in code as unsigned integers (instead of signed integers,) then the smallest negative number suddenly becomes the largest positive number on the same scale.

It's important to note that the code output we've seen here several times is not the raw ADC value, but the calculated voltage derived from that number. Since the chip uses an on board reference of 4.096V, and has differential input capability, the total range of output values is +/-4.096V (+/-32,768 raw ADC value divided by 8 to get millivolts, or divided by 8000 to get volts.) So, it's not a mysterious 3 zeroes and 13 ones - it's 16 ones, plus some math to convert raw ADC values into voltages.

All of which is just a really long winded way of saying, nothing is broken on the inputs that read 8.192V when grounded. You're simply seeing 1 LSB of drift in the negative direction. Every system has there potential for at least 1 LSB of error. That's normal.

If anything's "broken," it's the code that isn't interpreting negative numbers as such. If that output had been occasionally drifting between 0mV and -1mV, no one would've batted an eye.

As for the earlier errors with the 2.5V drifting up to 3.3V, I agree with the others who say the protection diode got fried. You mentioned earlier running test measurements with the 5V supply (and 2.5V voltage divider output) active while the ADC was unpowered. Since the protection diode is placed to clamp voltage to the ADC's positive power supply voltage, when the ADC is unpowered, that diode is reverse biased and could easily be overloaded. I think it got fried, and then once it was fried, it was conducting freely in both directions.

Don't allow voltage to reach the ADC input pins when the ADC isn't powered! Or, as others have suggested, put a large enough series resistor inline with the input to guarantee that no damage is done if and when those situations come up.