I don't look at ADC as the mechanics only. Considering how ADC levels are always across a range as the least value by approximation, +1/-0 ...
I abstract that to /1023 between-steps that I stretch from 0 to VCC with error about the same as /1024 +1/-0, just 1 step less. Note that GND and VCC read true with /1023. The stretch is 1 step wide from center out, the fiction in the approximation made from the ADC reading.
Analog instruments abstract physical readings into voltage or current, collected and digitized by an ADC... I think it's okay to abstract that within hardware tolerance. And besides, it's EASY.
Reading the AVR docs on ADC, I can be sure to 8 bits and +/- to 10!
AI-assisted paraphrased version of post #1, and now I can understand.
I look beyond the raw mechanics of an ADC. Since ADC readings inherently approximate continuous voltages into discrete steps (carrying a +1/-0 step error range), I prefer dividing by 1023 rather than 1024. Dividing by 1023 scales the range neatly so that ground 0V and VCC align with the true extremes, introducing only a minor mid-scale offset that easily falls within typical hardware tolerances. Analog sensors already abstract real-world data into electrical signals, so using a simpler math model is a practical choice. Ultimately, ATmega datasheet specs guarantee accuracy to 8 bits, with typical performance reaching closer to 10 bits.
Please suggest to your AI that it learns more about the subject of sentences and paragraphs in English grammar if it wants its replies to be understood
Typical is default 10-bit ADC. Less than typical is taking steps to improve accuracy like putting the core to sleep during read.
Default ADC is not closer to 10 bits. It is 10 bits. It is the most range the ADC is capable of, > 1000 steps. Averaging successive reads can reduce error, take care with the word can as it is not will.
Overall, that AI turns text to lower content mush.
I struggled to follow the technical wording in post #1, so I used AI to help rephrase the concepts to ensure I understood the key points. Before moving forward with questions based on post #2, I’d appreciate the OP’s confirmation that this interpretation accurately captures their original meaning.
I don't.
I divide/multiply with 1024 and add/subtract with 1023.
That gives cleaner calculations, which could be more important than accuracy.
About accuracy,
Remember that the default A/D of most Arduinos measure a ratio, not a voltage.
That ratio usually comes from a reference of the USB supply, which is far from 10-bit (0.1%) stable. Practically, using 1023 or 1024 is unimportant.
If you want to measure a true voltage, which requires a more stable reference, then you need a calibration factor for the external (or internal) reference voltage accuracy, the resistor divider accuracy and the use of 1023 or 1024.
Again, making the use of 1023 or 1024 irrelevant.
That's like dividing a given number of hours by 23 to get days (comparing 0 to 23 counting system with 0 to 1023 counting system). 2^10 has 1024 values. Day^1 has 24 hour values.
Correct what.
The display of the correct temperature depends on a lot more than a calculation.
USB voltage, sensor accuracy, etc.
I suppose you mean a thermistor. Then the pull up resistor is another variable.
All these unknown and constantly varying variables have a greater effect on the temperature.
IMHO code is used for a final practical purpose.
It seems that you have used code from an LM35 or TMP36 (the *100).
That sensor should not be read with default (5volt) Aref anyway.
I know that some calculations have a more sensible outcome (to humans) with 1023 or with 1024. The 1023 in your code outputs a clean 5.0 at max A/D.
1023>>2 or 1024>>2 works better with 1024, and fits in an int.
Take your pick. My choice depends on the rest of the code and hardware.
I'm just looking at my clocks.
One says 18:59 and the other one says 18:59:59.
Does that mean the first one is wrong?
