AnalogRead - readings are erratic

[cameronasmith]

Hi Guys,

I have an INA125 plugged into a breadboard (i read that this might be a problem) with a strain gauge connected to an Arduino analog pin.

When I take readings it seems to jump around. For example:

101, 102, 101, 101, 102, 101, 101, 101.

Is this normal for a strain gauge? And can anyone recommend a way to not make the signals so erratic.

Thanks,

Cameron.

[(deleted)]

(deleted)

[cameronasmith]

Hi spycatcher2k,

Thank you for the advice . I'm going to give it a try tonight. But my question is why i'm I getting those strange values?

Thanks,

Cameron.

[pito]

101, 102, 101, 101, 102, 101, 101, 101.
Is this normal for a strain gauge?

That is normal with ADC.

[fungus]

Thank you for the advice . I'm going to give it a try tonight. But my question is why i'm I getting those strange values?

There's nothing strange about it, it's just electronic  noise.

"Strange" would be 101, 102, 101, 303, 302, 101, 101, 101.

[CrossRoads]

I'm with the other folks on this one.
You could try putting a low pass filter on the INA125 output, could smooth the output some. 101 to 102 represents ~4.88mV of difference if Aref is using 5V.
Could also try adding some more caps to the Aref pin to make that cleaner.

[cameronasmith]

Hi CrossRoads,

Please could you provide more information on how you would add a low pass filter on:

You could try putting a low pass filter on the INA125 output

and how you would add capacitors on the Aref pin.

Could also try adding some more caps to the Aref pin to make that cleaner.

BTW. I'm not using the Aref pin for anything at the moment.

[dave-in-nj]

I am doing temperature with a LM34

I need to get that to degress.

input is between 0 and 1024 for the ADC, with a 5V supply that is about 10mV per step.
need to divide by the per step value
need to multiply that to get to degrees

I used an integer as a variable and got huge jumps of temperature.

what I wound up doing was to print each value along the way.
once I realized most of my math was after diving the input by 1024.... and then putting that into an integer.
well, it was a wonder I got any readings !

since then, I make sure the values are in the sweet spots of calculations.  multiplying by 10 or 100 to raise the value has made some numbers easier.

also, eliminate any delays in the program.  they seem to accentuate errors.
and lastly, remember, the ADC is using the power as a reference voltage.  either make the power smooth, or use a precision power supply for the sensors.

[cameronasmith]

Hi dave,

Please can you go into more description on:

since then, I make sure the values are in the sweet spots of calculations.  multiplying by 10 or 100 to raise the value has made some numbers easier.

Thanks,

Cameron.

[CrossRoads]

Lowpass filter:
http://sim.okawa-denshi.jp/en/CRlowkeisan.htm
Pick an R and a C, try it out.

Caps on Aref - Put a cap between Aref and Gnd right next to it on the header.

[Docedison]

Smoothing is always in order... and the Arduino unfortunately doesn't have a separate ground plane. ?The other unfortunate thing is the fact that the LSB is not something to really count on because the ADC is a SAR? (sp?) or uses successive approximation as the conversion method..
The addition of an analog ground plane that is connected to the lowest impedance point relative to the power return connection. Or both the analog and the digital ground planes must connect at the same point and close as possible to the PSU ground terminal.

Doc

[dlloyd]

When I take readings it seems to jump around. For example:
101, 102, 101, 101, 102, 101, 101, 101.

Even though a "jump" from 101 to 102 is almost a 1% change (in code), the signal may in fact be so stable that it would take high precision equipment to measure the change.

For instance, if the true signal is:
0.493164 volts for code 101
0.495605 volts (1/2 way between 101 and 102)
0.498046 volts for code 102

Above, it would only need to change by 0.000001 volts (0.495604 to 0.495605) to cause the ADC to output to change by 1 count.

ADDENDUM:
As CrossRoads pointed out, the change in code represents ~4.88mV.
Consider this:
If the signal is changing by 4.879mV exactly between what represents code 101 and 102,
the DAC's output would be stable.
Or, as shown above, it might be only 1 microvolt (or even 1 nanovolt) that causes the code change.

[CrossRoads]

With Aref of 5V, the difference between 101 and 102 is 0.004887V.
Would seem a change of much more than 1uV would be needed to be recognized as one level or the other. I would say more on the order of 0.0024 to 0.0025V.
Datasheet says:
• 0.5 LSB Integral Non-linearity
• ± 2 LSB Absolute Accuracy

Section 24 of the datasheet has more details.

[dlloyd]

Would seem a change of much more than 1uV would be needed to be recognized as one level or the other. I would say more on the order of 0.0024 to 0.0025V.
Datasheet says:
• 0.5 LSB Integral Non-linearity
• ± 2 LSB Absolute Accuracy

The INL is expressed for the full range of the DAC so it may not factor in to much for small code changes. The accuracy wouldn't be the issue - it would more likely be the resolution or precision of reading.

I agree it could be in the order of 0.0024 to 0.0025V because, of course there's noise to contend with that's probably higher.

[Grumpy_Mike]

Any A/D converter will always give a reading that can change by the least significant bit, that is perficatly normal. What is not normal is expecting a stable unchanging reading from a A/D.