 # analogRead - divide by 1023 or 1024?

Personally, I would say D) None of the Above. If you’re looking for that kind of accuracy, calibrate it by putting a precisely known voltage on the input, and seeing what readings you get. You’re almost certain to get at least one bit of “dither” as well, as you saw in the that test you ran in another thread yesterday.

Regards,
Ray L.

Nick, what is your verdict ?

When an analog input is clipped to 5.000V, I would like to have 5.000V in my calculation. So I use 1023. I read that the ADC successive approximation requires 1024. However, I didn't think of the 0.5 bit rounding down, and I don't want it to be rounding down.

Talking about the last bit does make sense to me. With many samples for the average, it is possible to get more "relative" accuracy than 10 bits.

Any division of an ADC represents a range, not one particular voltage.
An analogRead that returns a “0” doesn’t mean 0V but 0 to around 4.89mV

Refer the chart attached, sorry my rounding got a little sloppy. Hi,

The way I see it is that you have 1024 levels, GND is zero, so 1023 will be FullScale. There are only 1023 steps. You are counting quantization steps not the resulting levels. Zero is a number. Tom...... :)

Thank you Runaway Pancake.

Then this is what I want (adding half a bit, to avoid rounding down)

``````float voltage = ((float) rawADC  + 0.5 ) / 1024.0 * 5.0;
``````

The voltage would never be 0.0 and never be 5.0

Peter_n:
Nick, what is your verdict ?

First, let’s go back to the datasheet:

0x000 represents analog ground, and 0x3FF represents the selected reference voltage minus one LSB.

So (contrary to what you might expect) 0x3FF (ie. 1023) does not claim to represent Vref, but rather the reference voltage minus one bit (which in the case of 5V is 5/1024 = 4.88 mV).

Thus, the fact that dividing 1023/1024 and multiplying by 5 does not give 5 is entirely consistent with the fact that it does not claim to represent Vref.

The datasheet goes on (on the previous page):

Quantization Error: Due to the quantization of the input voltage into a finite number of codes, a range of input voltages (1 LSB wide) will code to the same value. Always ±0.5 LSB.

So there is an expected error of +/- 2.44 mV.

Therefore I agree with Peter_n’s formula:

``````float voltage = ((float) rawADC  + 0.5 ) / 1024.0 * 5.0;
``````

One of the reasons I was wondering this was that in the other thread my observations were slightly different to the calculated value, namely:

``````Analog port = 14, average result = 508    // 2.5V input
Analog port = 15, average result = 1022   // 5V input
Analog port = 16, average result = 672    // 3.3V input
``````

Using the formula in the datasheet we would expect 2.5V input to give:

`````` 2.5 * 1024 / 5 = 512
``````

However I got 508 above.

So I checked the 5V pin with a meter and found it read 5.026V. Substituting now:

`````` 2.5 * 1024 / 5.026 = 509.3
``````

Much closer to the observed output (508). And since we can also factor in a 0.5 bit quantization error, that brings it down to 508.85 which, truncated, now agrees with the reading I got.

Similarly for the 3.3V input (actually measured to be 3.306V) so now we have:

`````` 3.306 * 1024 / 5.026 = 673.57
``````

Again that is pretty close to the program output (well, out by one).

Therefore I agree with Peter_n's formula:

If we're being pedantic, Peter_n's formula is incomplete. @Runaway Pancake nailed it. For a given ADC value a range of voltages is possible.

``````float voltageLo = ((float) (rawADC  + 0) ) / 1024.0 * 5.0;
float voltageHi = ((float) (rawADC  + 1) ) / 1024.0 * 5.0;
``````

Where the measured voltage is greater than or equal to voltageLo and less than voltageHi. (With successive approximation converters we can never tell that we've reached exactly the voltage reference.)

Including an offset (0.5 in Peter_n's formula) can cause serious problems for some applications; like PID control. It is assumed that an ADC value of zero is close enough to zero to be considered zero. If that assumption is not true a converter with more resolution is needed.

In other words, if adding an offset solves a problem the problem is much better solved with a better converter.

1 Like

Some things I’ve noticed when trying to get very precise readings from an AVR based Arduino…

• USB power can be electrically noisy

• USB voltage can vary significantly with minor load changes

• Performing an analog conversion can cause the USB voltage to vary skewing the reading

• The AVR processor is electrically noisy which can affect a conversion; using the ADC Noise Canceler can make a significant difference

• A nearby pin outputting a PWM signal can wreak havoc on a conversion

• Something like this… http://www.adafruit.com/product/2200 …plus noise cancelling gives very good results even when the board is USB powered

• When powered from USB and not using noise cancelling ±2 bits is about as good as it gets

• The 3.3V regulator makes a fairly good reference

• Simple averaging improves the accuracy

I mentioned above that each reading represented a range, but I agree it is worth being aware of what you mentioned. As an approximation (eg. to display the temperature) "going halves" and assuming that it is in the middle of the range is probably an OK assumption.

I re-ran the test in the other thread, also measuring against Gnd, and always got a reading of 0, so it is interesting that I got 1022 (not 1023) for 5V, but Gnd was correct.

If it is any consolation, this has been bugging me for 30 years and I am still not convinced.

A idealised ADC converter would have an output which, if you plotted it on a graph as a function of output versus input, would be a straight diagonal line.

An actual adc output looks like the side view of a staircase. The theoretical diagonal line might be touching the top corners of each step, or the bottom corner of each step, or slicing through the middle or each tread and riser.

Also, the top or bottom step might be the same width as the others, or only half the width. Also, the staircase might end at the top end with a vertical step rather than a horizontal one, which might be incapable of being represented in the output available. After all, there is no really good reason why 1024 could not be a valid output for 5.0 V, it is a 16 bit number after all.

If I was to answer this question, I'd get a very stable adjustable voltage source, and actually measure the behaviour of the device. Is the bottom step a full step wide, or only half a step wide ? And so on. Once I had deduces the apparent position of the staircase, relative to the nominal diagonal line, then you are in a position to map the adc outputs back to the nominal voltage, represented by the midpoint of each step.

Well this is quite amusing. I tried to do it with noise cancelling (by going to sleep).

``````#include <avr/sleep.h>

void setup ()
{
Serial.begin (115200);
Serial.println ();
}  // end of setup

const int ITERATIONS = 500;
unsigned long totals ;

// when ADC completed, take an interrupt

{
ADMUX = bit (REFS0) | ((port - A0) & 0x07);  // AVcc

// ensure not interrupted before we sleep
noInterrupts ();
set_sleep_mode (SLEEP_MODE_ADC);    // sleep during sample
sleep_enable();

// start the conversion
interrupts ();
sleep_cpu ();
sleep_disable ();

// reading should be done, but better make sure
// maybe the timer interrupt fired

// ADSC is cleared when the conversion finishes
{ }

// combine the two bytes
return (high << 8) | low;

}

void loop ()
{
for (int whichPort = A0; whichPort <= A3; whichPort++)
totals [whichPort - A0] = 0;

for (int i = 0; i < ITERATIONS; i++)
{
for (int whichPort = A0; whichPort <= A3; whichPort++)
{
totals [whichPort - A0] += result;
}
}

for (int whichPort = A0; whichPort <= A3; whichPort++)
{
Serial.print ("Analog port = ");
Serial.print (whichPort);
Serial.print (", average result = ");
Serial.println (totals [whichPort - A0] / ITERATIONS);
}

Serial.println ();
delay (1000);
}  // end of loop
``````

Output:

``````Analog port = 14, average result = 506
Analog port = 15, average result = 1022
Analog port = 16, average result = 670
Analog port = 17, average result = 0
(repeated)
``````

Those figures are noticeably lower than before (506 compared to 508, and 670 compared to 672). But! During sleep mode, the load on the 5V bus decreased, and the 5V pin jumped to 5.028V. So recalculating with the new reference voltage gave similar answers to before.

This would appear to strongly support Coding Badly’s suggestion of using a proper reference voltage, as clearly the 5V voltage isn’t really 5V.

I support 1024 as it's mathematically "clean". The ADC gives integer results in the half-open interval [0, 1024) which map to the half-open interval [0, Vref).

michinyon: If it is any consolation, this has been bugging me for 30 years and I am still not convinced.

A idealised ADC converter would have an output which, if you plotted it on a graph as a function of output versus input, would be a straight diagonal line.

An actual adc output looks like the side view of a staircase. The theoretical diagonal line might be touching the top corners of each step, or the bottom corner of each step, or slicing through the middle or each tread and riser.

http://en.wikipedia.org/wiki/Analog-to-digital_converter

christop: I support 1024 as it's mathematically "clean". The ADC gives integer results in the half-open interval [0, 1024) which map to the half-open interval [0, Vref).

Thanks, I was trying to remember that terminology. Half-open interval sounds right.

2 bits = 4

0-1(v) 1-2 2-3 3-4 2 bit resolution

so it should be "/1024" for arduino 10 bit adc

[quote author=Nick Gammon date=1424748580 link=msg=2109172]Well this is quite amusing. I tried to do it with noise cancelling (by going to sleep).[/quote]

Bear in mind the timer 0 overflow interrupt (or any other interrupt event) can wake the processor early slightly spoiling the result.

This is the essence of what I do to deal with early waking (if you need any of the missing bits let me know)...

``````uint16_t analogReadRawOnce( void )
{
uint16_t rv;

// Generate an interrupt when the conversion is finished to wake the processor

// Can't use SLEEP_MODE_ADC because it turns off the I/O clock (no PWM)
set_sleep_mode( SLEEP_MODE_IDLE );
sleep_enable();

uint8_t SleepCount;
uint8_t TriesRemaining;
uint8_t SaveSREG;

// Preserve the I-flag.  This code is unlikely to be used in an interrupt service
// routine so save-restore is probably not necessary but the difference is just one or
// two machine instructions so we'll save-restore.
SaveSREG = SREG;

// Make two attempts to take an ADC reading with no interruption
TriesRemaining = 2;

do
{
--TriesRemaining;

// Any interrupt will wake the processor including the millis interrupt so we have to...
// Loop until the conversion is finished
SleepCount = 0;
do
{
++SleepCount;
// The following line of code is only important on the second pass.  For the first pass it has no effect.
// Ensure interrupts are enabled before sleeping
sei();
// Sleep (MUST be called immediately after sei)
sleep_cpu();
// Checking the conversion status has to be done with interrupts disabled to avoid a race condition
// Disable interrupts so the while below is performed without interruption
cli();
}

// There is a slight possibility that the interrupt flag will be set at this point.  Clear the flag.
}
while ( (SleepCount > 1) && (TriesRemaining > 0) );

// No more sleeping
sleep_disable();

// Restore the I-flag
SREG = SaveSREG;

// Finished.  Disable interrupts.

// Save the value now in case disabling the ADC interferes

return( rv );
}