ATMega328 ADC accuracy graph

[Rick Law]

Like everyone else with the ATMega, I too am playing with the ADC on the ATMega to measure voltage as a learning exercise.

This is some info I collected that some may found useful: The ATMega328 ADC voltage compared against UT61E.

Here is the collection environment:
- Since I found the USB's power quality makes a huge difference, I should point out this Arduino is powered via USB (@5.008V) connected to a laptop.
- An Arduino UNO hosts the ATMega328.  A large capacitor discharges and feed the voltage into a simple OpAmp voltage follower and a .1uF as decoupler cap at OpAmp output to the Arduino.  No other circuit involved.
- The UT61E reference reads at the point it enters the Arduino.
- The Arduino does not average or anything fancy - wait 229ms, read analog ports, report back at 19200, and wait till the clock ticks again.
- The conversion is the standard formula 5*adcCount/1023.  As basic and native as it gets.
- The data is collected via a Java program.  The JAVA program reads both the Arduino and the UT61E.
- The Arduino reports data every 229ms - a prime number so the other little things I do (like key debounce) will not be evenly divided into it reporting cycle.
- The Java program understands UT61E's overshoot and will skip a cycle when the UT61E just changed range.
- A big source of error I discovered was the time delta between the UT61E's reading and the Arduino's reading.   So the dV/dT is made as small as possible.  Minimum 20 data point is collected per count (>10 seconds per ADC count since UT61E samples at about 1/2 seconds).
- The Java program will wait for the next report if the one last read is too old.  "How old is too old" is based on experience from the data collected thus far in the run.   Total time delta Sum(time of UT61E's number - time of Arduino's number) for all records is under 700ms.
- The error plotted is the average of AbsoluteValue(error percentage) of that ADC count.    So, a +10% is not going to cancel out a -10%.  Which ever ADC (A0-A3) reports the worst error is the one plotted.

My comment:

With a good USB power source, it does very well on the high ranges but too dependent on the quality of the USB power.  At over 2.5 volt, you can count on better than 1% if USB power is very near but over 5V.  I cannot get consistent results (when USB powered) between different machines or even different ports.  My PCI powered USB/firewire card compared to the USB ports on the mother board has a 100mV USB voltage difference.  The mother board USB power is also different than the USB power on my laptops.  That little delta shows up in the results.

At the low end, it is hopeless unless something is done about it.  Averaging and other techniques, I have achieved better results in my learning exercise.  I collected this native328 results as the base line to see if the results my learning exercise is better, and if so, how much better.

Just thinking some may be interested in how well the native-ATMega328 ADC numbers look.

[madires]

Nice graph! But I got some remarks :-) Using USB as power source might be not the best idea because Vcc is used as voltage reference by the ADC. A good voltage regulator should improve the results (no 78L05, but something like a MCP1702). And for voltages below the internal bandgap reference (around 1.1V, needs be measured) the bandgap reference could be used as voltage reference to increase the resolution by a factor of 5. Or an external voltage reference could be used. The conversion formula should be 5*adcCount/1024. I assume that the DMM averages several measurements. So the ATmega328 should do the same to keep the competition fair. Do we have to consider an isolated USB connection?

[dannyf]

a .1uF as decoupler cap at OpAmp output

Wow! You shouldn't have done that.

The large error at low voltage, depending on how you power the opamp follower, could be due to the opamp.

The AVRs don't have a particularly good adc but it shouldn't be worse than 8-bits (in accuracy).

[dannyf]

An Arduino UNO

The Arduino's analog section is essentially incorrectly designed. It should have utilized some decoupling from Vdd, and you are better off with either the onboard Vref (fairly mediocre for a reference source) or external Vref (a TL431/TL431A would be far better).

[sync]

Looking at the graph. Is this just an offset error?

[Rick Law]

Nice graph! But I got some remarks :-) Using USB as power source might be not the best idea because Vcc is used as voltage reference by the ADC. A good voltage regulator should improve the results (no 78L05, but something like a MCP1702). And for voltages below the internal bandgap reference (around 1.1V, needs be measured) the bandgap reference could be used as voltage reference to increase the resolution by a factor of 5. Or an external voltage reference could be used. The conversion formula should be 5*adcCount/1024. I assume that the DMM averages several measurements. So the ATmega328 should do the same to keep the competition fair. Do we have to consider an isolated USB connection?

This one is a "native" to set a baseline.  I actually did exactly that with my "real one".  During the prototype for the "real one" using a home-made arduino, I cut the USB power and externally power it, plus a 78L05 as external voltage reference.  That took away most of the USB port dependencies.   With my "real one" that I am doing for learning, I use a 7805 for power and use internal reference.

Interestingly, a smaller error then show up that I did not expect: an upto +-3mV variation from presence/absence of TxRx signal.

Since it is a logger, I made sure it is "calibrated" for the presence of Tx/Rx.

[Rick Law]

a .1uF as decoupler cap at OpAmp output

Wow! You shouldn't have done that.

The large error at low voltage, depending on how you power the opamp follower, could be due to the opamp.

The AVRs don't have a particularly good adc but it shouldn't be worse than 8-bits (in accuracy).

I was getting some oscillation that a 0.1uF almost but not entirely eliminates for the range I was playing around with.

Re: OpAmp inpact - good point!  I path it through an OpAmp to emulate how I have been test my "real thing" - a volt logger that I am doing as a learning exercise.  This one is what I did as a base-line.  I probably should have eliminated the OpAmp.

I'll say this - while I have always know that working in mV/uV is hard, but I was not giving it its due respect.  This learning exercise  is forcing me to "give a lot more respect" to working around mV range...

If I do this for money, I'd loose my shirt for sure.  The ADC works rather nice at higher range.  I was able to develop some technique to get some good results.  But it certainly is neither cheaper, nor more flexible, nor more convenient, nor more accurate (as compare to something like a 20 dollar DMM).  But it does data logging, 4 channels but unfortunately all with common ground...

[dannyf]

I was getting some oscillation that a 0.1uF almost but not entirely eliminates for the range I was playing around with.

You should always be extreme cautious with capacitance on the output.

but I was not giving it its due respect. 

Quality analog work is far more difficult, even for trained pros, than comparable digital work.

If you reasonably good adc, follow the datasheet on the VAdd pin decoupling, and use the internal bandgap - you can correct that either off line or during run-time.

[Rick Law]

The large error at low voltage, depending on how you power the opamp follower, could be due to the opamp.

The AVRs don't have a particularly good adc but it shouldn't be worse than 8-bits (in accuracy).

Re: OpAmp inpact - good point!  I path it through an OpAmp to emulate how I have been test my "real thing" - a volt logger that I am doing as a learning exercise.  This one is what I did as a base-line.  I probably should have eliminated the OpAmp.


[/quote]

I must have been tired as hell.  I got so many grammatical errors in the first post, and I totally forgot a point of fact when replying to your reply.   Recalling that now, I can say the low end error has nothing to do with the OpAmp.  The low end error were all ADC's errors (or the UT61E).  It is not a case of UT61E measuring OpAmp in and the other measures opAmp out.  Both are measuring OpAmp out at the same physical point.

The rail for the discharge testing circuit is split -2V to 5V.  The capacitor discharge from +5 to -0.2V and the OpAmp is wired to be able to output from +5V to pass 0.00 down to almost -0.2V.

Since both the UT61E and the ATMega measure the OpAmp output at the same physical point, any deviation between their values are errors that has nothing to do with the OpAmp.  With my discharge circuit, I also connect my Hantek 6022BE USB scope, so I know I have no significant oscillation.  Given the close agreement between my 4 DMMs, I know the UT61E is the more accurate than the ATMega.  So I can comfortably assume the low end errors are the ADC's own - except perhaps some noise picked up from AC at +-5mV as shown by the 6022BE.  5mV can affect the ADC by +-1 count.  But that is the extreme end and the graph was half way to heaven way before ADC at 1 count.

By the way.  I set the negative volt to -0.2V (there about) rather than +-5V.  I made a mistake one time and let it go past 0.0 too far negative and not even for long.  With less than 1 minute of -5V, that ATMega328 is no longer on this earth as a functioning member of MCU society.  RIP.

[sync]

So I can comfortably assume the low end errors are the ADC's own - except perhaps some noise picked up from AC at +-5mV as shown by the 6022BE.  5mV can affect the ADC by +-1 count.  But that is the extreme end and the graph was half way to heaven way before ADC at 1 count.

I think you see the ADC offset voltage (V_os) error here. Your graph looks like ((V+V_os)/V-1)*100% where V_os=0.0125V. See my attached graph. Simply add or subtract 0.0125V from your ATmega readings.

By the way.  I set the negative volt to -0.2V (there about) rather than +-5V.  I made a mistake one time and let it go past 0.0 too far negative and not even for long.  With less than 1 minute of -5V, that ATMega328 is no longer on this earth as a functioning member of MCU society.  RIP.

Using a series resistor at the analog input protects it. Use a value between 1k and 10k.

[dannyf]

Your graph looks like ((V+Vos)/V-1)*100%

As the absolute level of measurements goes down, the relative magnitude of a given level of measurement errors goes up.

Having said that, it should be more than a few LSBs off so something else is at play here.

[sync]

Your graph looks like ((V+Vos)/V-1)*100%

As the absolute level of measurements goes down, the relative magnitude of a given level of measurement errors goes up.

But this looks really like a missing compensation for the offset.

Having said that, it should be more than a few LSBs off so something else is at play here.

12.5mV equals 2.5 LSB. The datasheet specs 2 LSB max.

[nctnico]

If Vref of the ADC is available on an external pin it will help a lot to use a more precise reference like an LM4040 at 3V or 4.096V. A standard voltage regulator can also do the job but there is a wide variety in accuracy. Some can have an error up to 3% so check the datasheet. The best ones are about 1% accurate (like the LM1117). If you need more accuracy then you'd need to use a precision reference.

[Rick Law]

So I can comfortably assume the low end errors are the ADC's own - except perhaps some noise picked up from AC at +-5mV as shown by the 6022BE.  5mV can affect the ADC by +-1 count.  But that is the extreme end and the graph was half way to heaven way before ADC at 1 count.

I think you see the ADC offset voltage (V_os) error here. Your graph looks like ((V+V_os)/V-1)*100% where V_os=0.0125V. See my attached graph. Simply add or subtract 0.0125V from your ATmega readings.

By the way.  I set the negative volt to -0.2V (there about) rather than +-5V.  I made a mistake one time and let it go past 0.0 too far negative and not even for long.  With less than 1 minute of -5V, that ATMega328 is no longer on this earth as a functioning member of MCU society.  RIP.

Using a series resistor at the analog input protects it. Use a value between 1k and 10k.

Wait, I am getting very confused now...

Why should the OpAmp's vOffset be an issue?  I stuck a few measuring devices at the OpAmp output.  The OpAmp output -0.2volt to +5volt.  It is not a case of comparing OpAmp in and OpAmp out.  Both the Arduino and the UT61E measure at OpAmp output.

From the measuring devices' perspective, they are all connected to the same physical point and they just see a voltage.   They then compare the voltage to each other.  So, the source of that voltage should not matter.  The voltage could have come from battery, AC wall brick, capactor, opAmp, whatever, it should not matter at all.  They all see a voltage at the same physical point and they compare the number against each other's readings.

The only time I saw that made a difference is when there is some high frequency oscillation (5kHz'ish).  The speed of the ADC's come into play.  Otherwise, they are just all comparing what they read at that point.

I would appreciate any clarification.  I am confused.

Thanks
Rick

[Rick Law]

If Vref of the ADC is available on an external pin it will help a lot to use a more precise reference like an LM4040 at 3V or 4.096V. A standard voltage regulator can also do the job but there is a wide variety in accuracy. Some can have an error up to 3% so check the datasheet. The best ones are about 1% accurate (like the LM1117). If you need more accuracy then you'd need to use a precision reference.

That (external vref) was the trick I used with my first prototype.

But, the point of this one graph is a to set a baseline when nothing is done -- so as I can compare "nothing done" vs my other learning exercise that I do every I could reasonably do or want to do.  So I left this one as native as possible -- except the OpAmp in the discharge circuit.

That OpAmp in the discharge circuit is.....I am getting confused by some of the comments as to why it matters that Vin for both UT61e and ATMega is from an OpAmp.  Hopefully, I will get some clarification from the commenters.

[Rick Law]

So I can comfortably assume the low end errors are the ADC's own - except perhaps some noise picked up from AC at +-5mV as shown by the 6022BE.  5mV can affect the ADC by +-1 count.  But that is the extreme end and the graph was half way to heaven way before ADC at 1 count.

I think you see the ADC offset voltage (V_os) error here. Your graph looks like ((V+V_os)/V-1)*100% where V_os=0.0125V. See my attached graph. Simply add or subtract 0.0125V from your ATmega readings.

By the way.  I set the negative volt to -0.2V (there about) rather than +-5V.  I made a mistake one time and let it go past 0.0 too far negative and not even for long.  With less than 1 minute of -5V, that ATMega328 is no longer on this earth as a functioning member of MCU society.  RIP.

Using a series resistor at the analog input protects it. Use a value between 1k and 10k.

Wait, I am getting very confused now...

Why should the OpAmp's vOffset be an issue?  I stuck a few measuring devices at the OpAmp output.  The OpAmp output -0.2volt to +5volt.  It is not a case of comparing OpAmp in and OpAmp out.  Both the Arduino and the UT61E measure at OpAmp output.

From the measuring devices' perspective, they are all connected to the same physical point and they just see a voltage.   They then compare the voltage to each other.  So, the source of that voltage should not matter.  The voltage could have come from battery, AC wall brick, capactor, opAmp, whatever, it should not matter at all.  They all see a voltage at the same physical point and they compare the number against each other's readings.

The only time I saw that made a difference is when there is some high frequency oscillation (5kHz'ish).  The speed of the ADC's come into play.  Otherwise (for pure DC) they are just all comparing what they read at that point.

I would appreciate any clarification.  I am confused.

Thanks
Rick

[sync]

Why should the OpAmp's vOffset be an issue?

Not the op amp offset. The ADC offset. It has one too. Ideally an ADC output value of 0 is 0V. In reality it's not exactly 0V, e.g. 12.5mV. See attachment and section 23.6.3 of the ATmega 328 data sheet.

If you don't compensate this offset error in software then your absolute error goes through the roof at the low end.

[Rick Law]

Why should the OpAmp's vOffset be an issue?

Not the op amp offset. The ADC offset. It has one too. Ideally an ADC output value of 0 is 0V. In reality it's not exactly 0V, e.g. 12.5mV. See attachment and section 23.6.3 of the ATmega 328 data sheet.

If you don't compensate this offset error in software then your absolute error goes through the roof at the low end.

Oh, I get it.  I was confused and thinking the comments were referring to the Vos of the OpAmp feeding the voltage to the ADC/UT61E to compare.

Compensation improvement was exactly why I made the graph.  I want this baseline so I can compare the improvement (if any) from my adjustments against the "native" ATMega328.

[pavlii]

Not the op amp offset. The ADC offset. It has one too. Ideally an ADC output value of 0 is 0V. In reality it's not exactly 0V, e.g. 12.5mV. See attachment and section 23.6.3 of the ATmega 328 data sheet.

Oh great.
I was experimenting with the ATMEGA 328P ADC and the most precise current sensor available - the LTC6102.

According to the LTC datasheet, it's input offset should be around 3 microvolts on the shunt resistor, but my tests shown something around 40 microvolts with 0.00025 ohm shunt resistor. I was curious what causes this discrepancy.

I started to blame Linear Technology (they did not answered my email at all), but later I found, that transformed to the ADC input voltage offset it was something around 11,3 mV voltage offset in my calculations. I started to think about other possible causes of the behavior and started to suspect the AD controller and it's input offset. I found, there should be some offset in the datasheet, but I was not able to find any concrete value.
But now, when I found this topic - the 12.5 mV value you published is very close to the 11.3mV value I measured, so this seems to be the cause! I'm going to test it today - shift the GND of the LTC6102 sensor by some diode up by 0.6Volts or so and connect the sensor to the ADC, if the zero offset of the sensor will decrease. I hope it will solve my problems 

[Rick Law]

Originally when I viewed these post, I distracted by thinking we were talking about Vos of my charging circuit.  A newest response made in this thread made me review the earlier post...

By the way.  I set the negative volt to -0.2V (there about) rather than +-5V.  I made a mistake one time and let it go past 0.0 too far negative and not even for long.  With less than 1 minute of -5V, that ATMega328 is no longer on this earth as a functioning member of MCU society.  RIP.

Using a series resistor at the analog input protects it. Use a value between 1k and 10k.

I should try that next time...

So I can comfortably assume the low end errors are the ADC's own - except perhaps some noise picked up from AC at +-5mV as shown by the 6022BE.  5mV can affect the ADC by +-1 count.  But that is the extreme end and the graph was half way to heaven way before ADC at 1 count.

I think you see the ADC offset voltage (V_os) error here. Your graph looks like ((V+V_os)/V-1)*100% where V_os=0.0125V. See my attached graph. Simply add or subtract 0.0125V from your ATmega readings.

When I first view my graph, I recognize that it looked like an inverse polynomial curve, so I did looked into it being a simple offset where
V(actual) = V(measured) +- constant.
But I found that there is a distinct break point (see attached graph of V measured vs V-calculated in this reply)

I made only one complete runs (adc=0 to 1023), but many partial runs.  The partial runs consistently have this change from -deltaMV to +deltaMV at around the middle somewhere.

However, these analysis were before I realize certain external impact (such as when the Air Conditioner came on, or the Washing machine, or the dish washer...).  That baseline was done when a couple of months ago when it was hot, so AC was coming on every now and again.  The ripples coming into my discharge circuit could knock it into oscillation for a while - I didn't know that then.   I may do another round of measurement now that I am more experienced.

[madires]

Not the op amp offset. The ADC offset. It has one too. Ideally an ADC output value of 0 is 0V. In reality it's not exactly 0V, e.g. 12.5mV. See attachment and section 23.6.3 of the ATmega 328 data sheet.

If you don't compensate this offset error in software then your absolute error goes through the roof at the low end.

The compensation is very easy to do:
- select Gnd as ADC input
- measure voltage (= offset)
- substract offset for all other measurements

[sync]

Your results are good. The integral non-linearity is specified as 0.5 LSB. With your 5V reference voltage this would be 2.5mV (5V / 1024). You measured less than 1mV error.

But I found that there is a distinct break point (see attached graph of V measured vs V-calculated in this reply)

I made only one complete runs (adc=0 to 1023), but many partial runs.  The partial runs consistently have this change from -deltaMV to +deltaMV at around the middle somewhere.

That's nothing unusual for a ADC.

[sync]

The compensation is very easy to do:
- select Gnd as ADC input
- measure voltage (= offset)
- substract offset for all other measurements

Unfortunately this is not working here. The ADC output code can't go negative (below zero).

[pavlii]

Not the op amp offset. The ADC offset. It has one too. Ideally an ADC output value of 0 is 0V. In reality it's not exactly 0V, e.g. 12.5mV. See attachment and section 23.6.3 of the ATmega 328 data sheet.

If you don't compensate this offset error in software then your absolute error goes through the roof at the low end.

The compensation is very easy to do:
- select Gnd as ADC input
- measure voltage (= offset)
- substract offset for all other measurements

This will not work. My ADC reports result = 0 for any voltage below ~ 12mV. (ATMEGA328P)

[madires]

This will not work. My ADC reports result = 0 for any voltage below ~ 12mV. (ATMEGA328P)

I see. Is it the same when using Vcc and the internal bandgap reference as reference for the ADC?