Re: Problem using the hanning function in embedded mode

[Sergei Steshenko]

----- Original Message -----
> From: Macy <address@hidden>
> To: address@hidden
> Cc: 
> Sent: Monday, December 24, 2012 4:32 PM
> Subject: Re: Problem using the hanning function in embedded mode
> 
> You probably noticed these already but just in case...
> 
> If you wish to 'presrve' the true rms of any signal, be sure to multiply 
> the hanning function by 2, else you will apparently attenuate the signal and 
> lower the energy in your packet. For hamming, multiply by 2/1.08
> 
> For any real signal, like an audio signal, the FFT yields a 'duplicated' 
> spectrum. Usually the lower half the spectrum is of any real interest. To 
> then 
> preserve true rms, multiply the FFT with sqrt(2)/N, where N is the number of 
> terms in your FFT. Then, the values that you retrieve from the lower half 
> spectrum are true rms values.
> 
> You can leave out all these coefficients and obtain answers in 
> 'relative' terms. But getting results in true rms has the advantage of 
> enabling you to compare spectrums derived from different packet sizes 
> [equivalent to changing the BW in a spectrum analyzer]; compare calculations 
> to 
> actual measurements; and relate to noise in the system, etc.
> 
> Also, hamming is awful for 'out of sync' signals and hanning is a bit 
> better. Yet there is another function used by the ADC/DAC industry which is a 
> bit more complicated. Find TI's App Notes relating to their 24 bit audio 
> ADC's especially the ADS1282. They use a different window function that 
> provides better separation between signals [to make their products look 
> better] 
> when the signals are not sync'ed to the ADC process for use in audio 
> systems.
> 
> If you're making some type of presentation of results you may wish to use 
> the same type window function to 'lower' the energy in the spectrum 
> between signals. Make the display 'cleaner'.
> 


Even though I myself use FFT to process audio in real time, I do not understand 
how your post is related to the OP's problem.

It's common knowledge that for real time signals _overlapping_ windows (to be 
more exact, overlapping buffers multiplied by the chosen window) are used, and 
for such applications Hanning window is the most widely and correctly used 
no-brainer.

But, again, I think the OP's problem is (in)validity of the values he obtains 
from an Octave function, and, as I wrote before, my first guess is that it 
might be related to thread safety and/or problems in IPC implementation, the 
processes/threads being the OP's GUI and Octave.

Regards,
  Sergei.