How to Increase the Resolution of analogRead()! (from 10-bits up to 21-bits)

Hackscribble:
I have done a bit of analysis on the readings in Grumpy_Mike's spreadsheet.

The 328 ADC readings cover 21 discrete values, ranging from 1.447030780 to 1.447183510. The gap between each value averages 7.630 uV. This is 10% of the "uV per sample for 16 bits" value in the spreadsheet.

The frequency distribution of the readings is shown in the attached graph. The mode is 1.447152990.

Grumpy_Mike, thanks for doing the background reading and testing my library! That's what I like to see. I hate it when "smart people" attack others' work without even trying it out. If my work is lousy, sorry. That's why it's under the GNU license. It's not guaranteed to do anything useful, like the license says. If my work is deemed lousy by some "smart" person, without them even testing it, that's unfair and ignorant. If my work is actually useful, but imperfect, that's good enough for me and my purposes, and it's good enough to be useful to many others too.

Now, as for your results: I'm very pleased with them. They very clearly indicate that the 16-bit resolution results truly are 16-bit resolution results. Again, let me refrain from using "precision" and "resolution" interchangeably. I was wrong. The 10-bit ADC as a 10-bit ADC doesn't even have 10-bit precision. It has 10-bit resolution. Even with a pot on a fixed setting it can occasionally vary a little when using analogRead().

Hackscribble, thanks a ton for looking at the results and making note of the above items. You said, "The gap between each value averages 7.630 uV. This is 10% of the "uV per sample for 16 bits" value in the spreadsheet."
-This is very clearly indicative of what could be expected from a 16-bit-resolution reading, where each reading is actually the avg. of 10 16-bit readings, which is what Grumpy_Mike did. He had num_samples set to 10, so each value returned was the avg. of 10 16-bit readings. Therefore, it makes sense that the gap between each value, or the resolution, is 10% of the expected resolution. Looking at my spreadsheet found here, you can see that the expected 16-bit resolution, or minimum distinguishable step-size between readings, is 76.4uV. Hackscribble made note of 7.630uV, which is 10% of 76.4 due to the 10-sample avg thing mentioned above. So, 7.63x10 = the expected 16-bit resolution, which matches my prediction. These results make me happy. They indicate the whole concept of oversampling is valid, and for at least this case, they are good. I plan on utilizing my library a lot in the future, on pretty much any project I do where I need fine steps in resolution.

__Don't be fooled though, you still need to meet the criteria in the last two columns of my table, or else what you're doing is useless, as your data will be highly aliased. __