The problem with offset correction in code is that you have to know for sure that offset never changes. Unless the reference is reasonably stable across supply voltage and temperature fluctuations, it's still not very precise even if you can calibrate it to bang-on at 20C on a fresh battery. Just something to be aware of, in case you haven't thought about it yet.

It's true you can damage the Vref circuit if you set the voltage reference to internal and have an external voltage source connected as well. In a decision that is either questionable or efficient -- I'm not really sure which -- the Vref pin becomes an external exposure of the internal voltage reference when the internal Vref is selected. This allows you to apply additional filtering to reduce noise, or even (buffer it! and) use it for other references.

As with any software-selectable input / output pin, you have to be careful to match up the initialization code with the hardware topology. Not much different than the port I/O pins themselves, really, except when using pre-baked firmware like the Arduino library, you don't always know for sure what's being done for you. Kind of a good reason to graduate to straight AVR C, IMO, but that's obviously not a reasonable option for everyone. Arduino got me into embedded programming and digital electronics, and I'm grateful for that. But I was also quite relieved when I got through my first successful Atmel Studio project.

SirNickity wrote:

The problem with offset correction in code is that you have to know for sure that offset never changes. Unless the reference is reasonably stable across supply voltage and temperature fluctuations, it's still not very precise even if you can calibrate it to bang-on at 20C on a fresh battery. Just something to be aware of, in case you haven't thought about it yet.

It's true you can damage the Vref circuit if you set the voltage reference to internal and have an external voltage source connected as well. In a decision that is either questionable or efficient -- I'm not really sure which -- the Vref pin becomes an external exposure of the internal voltage reference when the internal Vref is selected. This allows you to apply additional filtering to reduce noise, or even (buffer it! and) use it for other references.

As with any software-selectable input / output pin, you have to be careful to match up the initialization code with the hardware topology. Not much different than the port I/O pins themselves, really, except when using pre-baked firmware like the Arduino library, you don't always know for sure what's being done for you. Kind of a good reason to graduate to straight AVR C, IMO, but that's obviously not a reasonable option for everyone. Arduino got me into embedded programming and digital electronics, and I'm grateful for that. But I was also quite relieved when I got through my first successful Atmel Studio project.

Thanks.
When my batteries are low I'll measure again the Vref internal to see that if the 1.054v is changed cause that way I think the only option would be the external one. EDIT: I've just measured and now internal AREF was 1.049v... 😵 lowering with battery going down? maybe.

I'd like to ask you if you're expert on FFT libraries about spectrum calculation. I've this power meter logarithmic amplifier that gave these voltages depending of dBm measured but it's really wide band from mhz to ghz and I was thinking I may add just as a cool feature, an approximate useless low res lcd spectrum graph and I was thinking if the FFT calculations would be enough to have partial graphs (cause the 16Mhz limitation of the cpu). Because the module itself only gives out a voltage from that 2.10 to 0.40 volts and no other info; the dBm and all possible values are calculated from datasheet expressions but the module works on the entire frequency range and the antenna logics choice.
Would I need external hardware, oscillators, generators to make comparing calculation and sort of draw a graph? Because I've seen microphone based arduino project that seems like really easy with the FFT doing the same thing.
Thank

You can scale the FFT load by controlling the sample range and the update period. i.e. 64 samples 15 times/sec will be 1/4 the load of 128 samples 30 times/sec. Fixed point FFT algorithms are a real grab bag (extending to pure ASM implementations) and depend somewhat on what micro you're using and what your precise requirements are.