ADC Conversion Result

Go To Last Post
13 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

 

ATmega328P: 1024
ATmega4809: 1023

 

I have difficulties to understand this difference.
 

The truth is more important than the facts.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

The max number you can ever get IS 1023 (from 10 bits)...the difference is: can you go all the way to vref or one count below it. 

The typical standard is that you can go to Vref-1 lsb MAX

https://masteringelectronicsdesi...

 

note, also, they could scale the result by adding an internal resistor divider to give any smaller desired number (1000, 1023, 378, 555, etc) with max voltage at the pin.

So while Vin*1024/vref is correct, they could theoretically give vin*555/vref , or anything smaller than 1024 (such as vin*1023/vref)

 

 

 

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

Last Edited: Wed. Sep 16, 2020 - 07:21 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That difference COULD depend on the internal design of the ADC. It was a pretty significant redesign because speeds are now quite a bit faster. So, Microchip does not tell us what, if anything has changed. As a result we don't know what the difference, if any, is. We may never know!

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Isn't it just a case of whether you're counting fence panels, or fence posts?

 

The maximum reading you can get from the ADC is all 10 bits at 1; ie, 0x3FF = 1023

 

But the number of different values that the ADC can return is 1024

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The definitions there are a bit unclear.   Usually, they are equipped with a floor or ceiling operation.

Maybe consider an analogous case where the converter is 2 bits instead of 10 and make a graph of RES versus Vin/Vref for each case.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

awneil wrote:
Isn't it just a case of whether you're counting fence panels, or fence posts?
Indeed it is and there's been a lot of prior discussion about this. No doubt "fence post" will be a good search term. It's almost like a religion in fact - some people argue hotly for 1023 some for 1024. Seems like the two different document authors were simply of differing opinion.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
some people argue hotly for 1023 some for 1024.

Indeed.

 

In practice, at the end of the day, it's just a 1 LSB "error" - which isn't likely to be significant.

 

 

Seems like the two different document authors were simply of differing opinion.

Exactly.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 2

It's also going to be a whole lot easier to multiply/divide by 1024 rather than 1023, which might be important if power consumption and/or code size are important.

 

Steve

Maverick Embedded Technologies Ltd. Home of Maven and wAVR.

Maven: WiFi ARM Cortex-M Debugger/Programmer

wAVR: WiFi AVR ISP/PDI/uPDI Programmer

https://www.maverick-embedded.co...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

scdoubleu wrote:
a whole lot easier to multiply/divide by 1024 rather than 1023

Absolutely. Excellent point.

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Indeed it is and there's been a lot of prior discussion about this. No doubt "fence post" will be a good search term. It's almost like a religion in fact - some people argue hotly for 1023 some for 1024. Seems like the two different document authors were simply of differing opinion.

I seem to recall some definitive stuff in a prior discussion.  Was it something like "you can't really get a 5.0V result when converting the 5V signal"?  Now, how in the world will we be able to search out the pertinent prior discussions?

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

scdoubleu wrote:

It's also going to be a whole lot easier to multiply/divide by 1024 rather than 1023, which might be important if power consumption and/or code size are important.

Yeah, I see 1023 and I think WTF??

 

But if you're doing an N/D scaling, you can also just choose your N to be 1024/1023 larger.  Or just ignore it because it's down in the noise anyway.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

Indeed it is and there's been a lot of prior discussion about this.

Indeed!

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

theusch wrote:
Quote:
Also, you should be dividing by 1024, NOT 1023.
Quote:
Why? (ok it's cheaper). Isn't 1023 max?
LOL--this has been tossed about before: 2004: https://www.avrfreaks.net/index.p... 2007: https://www.avrfreaks.net/index.p... 2008: https://www.avrfreaks.net/index.p... 2010: https://www.avrfreaks.net/index.p... ... and others. ...

 

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

https://www.avrfreaks.net/forum/...

Bergie5737 wrote:

Disclaimer:Thread title copied verbatim with no permission from owner. smiley

 

Here is the link my post refers to:  http://www.electro-tech-online.com/threads/why-adc-1024-is-correct-and-adc-1023-is-just-plain-wrong.132570/

 

I found the above post quite interesting, and not being a member of the above forum, I thought you may find it interesting and comment on it a bit.

 

I found it strange that anyone would divide by 1023 in the first place. Then in the second post I find this line.

Doing the incorrect math of ADC *5 /1023, gives ONE advantage, it means that the top ADC reading of 1023 will give an output result of "5v"

The disadvantages is also there. But the most interesting bit for me is the last heading at the end of the second post.

I'm quoting it all here highlighting what I what like to be lectured about.

Doing the ratio scaling math right!

First let's clear one thing up, the ratio scaling math of *x /n is perfect, it has no error.

But there are two rounding down errors that we need to deal with;

1. The ADC hardware itself causes a rounding down error. Every possible input voltage is reounded down to the nearest ADC unit. This error occurs BEFORE any ratio math is done, and can be compensated by adding 0.5 ADC counts to every ADC sample BEFORE any conversion.

Since it is impossible to add 0.5 in integer math the best way is to double the ADC value, and then just add 1, ie; (ADC*2)+1

2. The math *x /n does not introduce error with the *x but the /n operation using integer math causes a rounding down error to the nearest n unit. This integer division rounding down error can be compensated by adding half the divisor; +0.5n /n which in our case is +512 /1024.

However since we have the ADC value already doubled from the previous operation, we need to divide by double, or 2048. So it becomes; +1024 /2048.

Putting it all together.

To get a reading of 0.00v to 5.00v from the PIC ADC can be done using the correct data scaling of all samples, and properly compensated integer rounding on all samples, by the following integer math;

((ADC*2)+1) *500 +1024 /2048

Using *x of *500 means we are converting 1024 ADC units to 500 output units (which represent 0-500 ie 0.00v to 5.00v).

  • The ADC causes rounding down .... I guess that is true for AVR as well as I suppose its the same type of ADC and nothing to be done about it, unless perhaps feed a slightly lower reference voltage?

 

  • /n (divide by n) causes a rounding down in integer math ....  true.

 

  • And then the final result, i.e. the formula in turquoise...  1024/2048 should always return 0 in integer maths? I am not so   sure if the formula is correctly printed there.
  • I think it should read (((ADC*2) +1) * 500 + 1024) / 2048

 

          Crickey, I've never even given it the slightest consideration when converting, and I doubt it will make a difference in most projects, but considering a perfect environment, will it actually make a difference?

...

 

... and more.  OP should digest these and them come back with anything specific.  After reviewing some of the threads in making the list, it still makes my head swim.  In practice, for me, as long as the ADC gives monotonic results I'm happy. Real-world work discards a few counts at the top and bottom anyway, leaving a convenient

~1000 counts of usable range.

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

  • The ADC causes rounding down .... I guess that is true for AVR as well as I suppose its the same type of ADC and nothing to be done about it, unless perhaps feed a slightly lower reference voltage?

 

  • /n (divide by n) causes a rounding down in integer math ....  true.

 

  • And then the final result, i.e. the formula in turquoise...  1024/2048 should always return 0 in integer maths? I am not so   sure if the formula is correctly printed there.
  • I think it should read (((ADC*2) +1) * 500 + 1024) / 2048.

 

The two round-off additions can be rolled into one by noting that +1 * 500 / 2048  is 500 / 2048 which is 250 / 1024.  So this could be done (more clearly IMO) as  ((ADC * 500 + (250+512)) / 1024.  Does it matter?  I'm not convinced.  Especially since any system that needs more than trivial accuracy will end up being calibrated anyway.