Hi,
"double" is a floating point. This is what I´d avoid. And why "double"it´s just overkill in precision.
* ADC[] could be signed (or unsigned 16 bit). ... if you want to save RAM.
* Instead of calculating han[] on runtime you could do a 128 tap (x4 quadrants) 16 bit look up table. To avoid overflow problems I´d go up to 32766 only (It´s still a better resolution than your 11 bit input)
The table calculation would then be
--> hann = 16383 * (1 - cos(2*PI*i/511));
I guess the FFT needs signed input. so use 16 bit signed (15 bits positive)
So your ADC uses 12 bits and the hann uses 15 bits.
To do the math with 32 bits precision I´d use a "cast".
Then after the multiplication you get a 12bits + 15 bits (all positive) value.
To fit into a 16 bit signed variable you need to shift 12 bits right. This gives you the best precision for FFT calculation, but needs to be corrected after the FFT.
(But if you want to maintain ADC precision you need to shift 15 bit right)
(from my understanding hanning attenuates all signals by 6dB. Please check on this.)
So in short:
* hann[]: 16 bit signed. range 0...32766
* ADC[]: 16 bit signed. range (0) 1800 ... 3200 (32767)
* Multiplication: signed_16_bit x signed_16_bit = signed_32_bit
* Then shift right to fit into 16 bit signed
****
Generally the hann values don´t need to have more precision than the ADC values. It does not improve the end result. So using values 0...32766 is well enough.
No need to worry about the mathematical error of 32768/32766. The ADC error will be worse.
Klaus