1
$\begingroup$

Fore-word :Kindly Observe this question has multiple updates take the latest update as question !

here below is my 256pt FFT on an 2Khz sinusoid signal,on a fixed point DSP tms320c5515

enter image description here please ignore this this has occured due to programatic bug

is this above figure expected in the first place ?(with out windowing)

after looking several resources i have came to a conclusion that using a hanning window is the best way to go before an STFT,but my question is how to window an input signal which is a signed data 16bit,

i know generally we go for finding the hamming window vector in matlab for a 256bin and try to multiply that window

enter image description here

but when i did multiply my signal with a vector which i got from the matlab a 256pt hamming window which is having values from 0.08 -0.99 ,still i have my spectral leakages persistent in the FFT results

float window[256]={
    0.0801396321, 0.0805584436, 0.0812561802, 0.0822324185, 0.0834865656, 
    0.0850178601, 0.0868253726, 0.0889080056, 0.0912644947, 0.0938934094,
    0.0967931537, 0.099961967, 0.103397926, 0.107098944, 0.111062774,
    0.115287011, 0.119769089, 0.124506288, 0.129495732, 0.134734391,
    0.140219085, 0.145946484, 0.151913112, 0.158115346, 0.16454942, 
    0.171211429, 0.178097329, 0.185202937, 0.192523942, 0.200055898,
    0.207794233, 0.215734248, 0.223871124, 0.232199921, 0.240715582,
    0.249412937, 0.258286707, 0.267331503, 0.276541836, 0.285912112,
    0.295436645, 0.305109651, 0.314925258, 0.324877507, 0.334960356,
    0.345167684, 0.355493294, 0.365930917, 0.376474217, 0.387116792,
    0.397852183, 0.40867387, 0.419575286, 0.43054981, 0.441590782,
    0.452691497, 0.463845217, 0.47504517, 0.486284557, 0.497556555,
    0.508854319, 0.520170992, 0.531499704, 0.542833575, 0.554165727,
    0.565489278, 0.576797356, 0.588083093, 0.59933964, 0.610560161,
    0.621737846, 0.632865908, 0.643937592, 0.654946175, 0.665884975,
    0.676747351, 0.687526708, 0.698216503, 0.708810244, 0.719301502,
    0.729683906, 0.739951154, 0.750097012, 0.760115322, 0.77, 0.779745046,
    0.789344544, 0.798792666, 0.808083676, 0.817211933, 0.826171896,
    0.834958125, 0.843565286, 0.851988154, 0.860221615, 0.868260671,
    0.876100441, 0.883736166, 0.89116321, 0.898377064, 0.905373349,
    0.912147817, 0.918696356, 0.92501499, 0.931099882, 0.93694734,
    0.942553812, 0.947915896, 0.953030335, 0.957894025, 0.962504013,
    0.966857501, 0.970951846, 0.974784561, 0.97835332, 0.981655957,
    0.984690466, 0.987455005, 0.989947896, 0.992167626, 0.994112846,
    0.995782376, 0.997175203, 0.99829048, 0.999127531, 0.999685848,
    0.999965091, 0.999965091, 0.999685848, 0.999127531, 0.99829048,
    0.997175203, 0.995782376, 0.994112846, 0.992167626, 0.989947896,
    0.987455005, 0.984690466, 0.981655957, 0.97835332, 0.974784561,
    0.970951846, 0.966857501, 0.962504013, 0.957894025, 0.953030335,
    0.947915896, 0.942553812, 0.93694734, 0.931099882, 0.92501499,
    0.918696356, 0.912147817, 0.905373349, 0.898377064, 0.89116321,
    0.883736166, 0.876100441, 0.868260671, 0.860221615, 0.851988154,
    0.843565286, 0.834958125, 0.826171896, 0.817211933, 0.808083676,
    0.798792666, 0.789344544, 0.779745046, 0.77, 0.760115322, 0.750097012,
    0.739951154, 0.729683906, 0.719301502, 0.708810244, 0.698216503, 
    0.687526708, 0.676747351, 0.665884975, 0.654946175, 0.643937592,
    0.632865908, 0.621737846, 0.610560161, 0.59933964, 0.588083093,
    0.576797356, 0.565489278, 0.554165727, 0.542833575, 0.531499704,
    0.520170992, 0.508854319, 0.497556555, 0.486284557, 0.47504517,
    0.463845217, 0.452691497, 0.441590782, 0.43054981, 0.419575286,
    0.40867387, 0.397852183, 0.387116792, 0.376474217, 0.365930917,
    0.355493294, 0.345167684, 0.334960356, 0.324877507, 0.314925258, 
    0.305109651, 0.295436645, 0.285912112, 0.276541836, 0.267331503, 
    0.258286707, 0.249412937, 0.240715582, 0.232199921, 0.223871124, 
    0.215734248, 0.207794233, 0.200055898, 0.192523942, 0.185202937, 
    0.178097329, 0.171211429, 0.16454942, 0.158115346, 0.151913112, 
    0.145946484, 0.140219085, 0.134734391, 0.129495732, 0.124506288,
    0.119769089, 0.115287011, 0.111062774, 0.107098944, 0.103397926,
    0.099961967, 0.0967931537, 0.0938934094, 0.0912644947, 0.0889080056,
    0.0868253726, 0.0850178601, 0.0834865656, 0.0822324185, 0.0812561802,
    0.0805584436, 0.0801396321, 0.08}

is my way of windowing correct or wrong ?

UPDATE 1 : Results with out windowing

of updated screen shots of input tone and windowed and FFT:

with suggestions of more explanations requirement i have tried to give a standard 440Hz tone with sampling freq 8000, which is 16bitPCM format, the tone is windowed and then fft was done

with out windowing enter image description here

ater applying my window looking like

enter image description here

after windowing with the above window it has turned the sinusoidal to sqaure(expected ? !) which further given rise to more worse FFT why so ?

enter image description here

UPDATE 2 :Update 1 has bug with the program where i was trying to do FFT with a wrong window array

Here below is the input the effect of windowing and the FFT result,there no problem with the window i have mentioned in the question,i have generated it from matlab and used it as array,

enter image description here

now is the response and every thing OK ! ? i feel its correct,a peak at 14th bin (~430Hz) and 256-14(~7560Hz) now i have to go for the magnitude plotting urgently to get the power of each bin

UPDATE 3 :Magnitude Plot Updated

enter image description here

Now the convnetional problem why two peaks,how to remove the other negative frequency peak can i nullify greater than (fs/2)? people do this by shifting how can i shift the (256-14)7560Hz componed to it left un existing side -14Hz ,How ?

are there any other things i do need to do further improvisation to this FFT ? to further make it better

and also i am seeing a secondary peak next to my desired peak sometimes(not shown in the pic )why so ?

UPDATE 4 : Update is Regarding the new window usage,effects after overlapped frames are used,also zeropadding

With the suggestion from other forums,when people said a zero padding decreases the multiple peaks in the magnitude plot and also a overlapped frames will help

so i have changed my strategy to do a 512pt FFT Frame size 20ms ie., 160 samples(8000 sampling rate) 50 % overlap which makes it to 320 samples rest i have done zero padding

and i also have updated the window to symmetric 4-term Blackman-harris Window which is said to give peaks of dominant frequency and suppress the rest

below figure show the updated results,and magnitude plot resulting in a valley also,which is not desired

But on the other side i have Opensource KissFFT algo which is doing same thing which gives a superb response to the same input

enter image description here output of KissFFT(Open Source Implementation)-which is also trying to take a 160ms frame and do the FFT of 512pt with 50% frame overlap

enter image description here

why so ? whats wrong with my approach what am i missing ? Is this any bug with my hardware FFT algorithm when compared to Cooley-Tukey Algo ? My hardware uses a Radix-2 approach

i really need some inputs to make my fft more strengthened

Very thanks for the answers up to now !

Improve this question
$\endgroup$
2
  • $\begingroup$ What is the sampling frequency? $\endgroup$
    – user7358
    Commented Jan 29, 2014 at 18:40
  • $\begingroup$ Sampling Frequency 8000Hz, a 2Khz signal is generated from audacity and its taken as input $\endgroup$
    – kakeh
    Commented Jan 30, 2014 at 4:30

4 Answers 4

Reset to default
1
$\begingroup$

In the classic windows paper by Harris, he mentions that the Hamming window can be thought of as a modified Hanning (or Hann) window. Although the equation shown in your post is for a Hanning window (same as equation 27b, p. 60 in the Harris paper), you mention both 'Hanning' and 'Hamming' in your post, so I'm not sure which one you want.

Regardless, your window points are not correct. For an even N, the w[0] and w[N/2] points should be unique, and the rest of the points should exhibit symmetry. For example, the 256 point Hanning is:

double w[ ] = {

0, //w[0]

0.000150591, //w1

0.000602272, //w[2]

0.00135477, //w[3]

...

...

0.999398, //w[126]

0.999849, //w[127]

1., //w[128]

0.999849, //w[129]

0.999398, //w[130]

...

...

0.00240764, //w[252]

0.00135477, //w[253]

0.000602272, //w[254]

0.000150591 }; //w[255]

Note that the w[0] and w[N/2] points are unique; the w[N/2] point is '1', and the rest of the points display the proper symmetry.

There are variants of the Hamming (eg: exact Hamming), but the one often referred to as Hamming uses a particular coefficient (alpha = 25/46, or approximately .54, as mentioned in the Harris paper). The calculation results in:

double w[ ] = {

0.08, //w[0]

0.0801385, //w1

0.0805541, //w[2]

0.0812464, //w[3]

...

...

0.999446, //w[126]

0.999861, //w[127]

1., //w[128]

0.999861, //w[129]

0.999446, //w[130]

...

...

0.082215, //w[252]

0.0812464, //w[253]

0.0805541, //w[254]

0.0801385 }; //w[255]

Once again, the w[0] and w[N/2] points are unique, the w[N/2] point is '1', and the points display the proper symmetry.

In contrast, the window points you show look like a reversed Hamming window for an odd N (the .08 is shown last, and your N/2 point is not '1', so you don't have the proper symmetry).

Looking at your re-edited 440 hz graphs, your input seems good, but your 'after windowing' graph is definitely a problem. It seems to be just a clipped version of the input. Most window deemphasize the beginning and ending parts of the input data, so that the data has more of a bulging shape - the beginning and ending data are near zero amplitude, and the middle of the data is near or at original height.

Your results show quite a bit of noise, probably due to giving the FFT that clipped input waveform. But your results also show something around the proper places (ie: sample rate/N gives you a frequency spacing of 31.25 hz, so a 440 hz tone should show up at the 440/31.25 = 14.08 hz point, which is very nearly bin 14, and also at the negative frequency bin 256-14). But your results should be two sharp spikes, instead of the slightly smeared out data shown (this could also be due to the clipping).

In addition, you should present your result as a magnitude.

Your incorrect window points can certainly cause problems, but I can't say for sure if that is your only source of error.

Improve this answer
$\endgroup$
7
  • $\begingroup$ yes you are absolutely correct the window was the culprit,i have been using a different window in the code,so i have updated the window to that i have mentioned in the question,which has modified the signal as you said,soon i will update the results in my question $\endgroup$
    – kakeh
    Commented Jan 30, 2014 at 9:14
  • $\begingroup$ you can have a look i have updated the magnitude plot $\endgroup$
    – kakeh
    Commented Jan 30, 2014 at 13:21
  • $\begingroup$ Your windowed input now looks correct. Instead of magnitude, you might try plotting 10*log(magnitude), since that is the way these charts are usually shown. A good exercise is to use the same parameters as in the Harris paper and try to see if you can recreate his charts. You can learn a lot that way. $\endgroup$
    – Kevin McGee
    Commented Jan 31, 2014 at 4:06
  • $\begingroup$ but @KevinMcGee can i do something like,doing a 512pt FFT with 50%overlap and ignore the second half,or taking 256pt FFT with 50%overlap,can you suggest me any further improvisations to strengthen my FFT over a extent $\endgroup$
    – kakeh
    Commented Jan 31, 2014 at 4:24
  • $\begingroup$ You can often disregard the negative frequencies when interpreting your graphs, since, for real only inputs, they are just conjugates of the positive ones. But math operations based on numbers from the graph can get messed up if you don't include them - it all depends on what you're doing. As for the large size of your peaks - almost all window based graphs are normalized such that all values are considered relative to the largest one (eg: if point w[0] is the largest, then you plot the log of w[0]/w[0], w[1]/w[0], w[2]/w[0], w[3]/w[0], etc.). $\endgroup$
    – Kevin McGee
    Commented Feb 1, 2014 at 6:48
0
$\begingroup$

First your formula does not appear to be correct. The Hamming window (not to be confused with the von Hann or occasionaly ,,Hanning'' window, which your formula seems to represent) is

$ w(n) = 0{,}54 + 0{,}46 \cdot \cos\left(\frac{2\pi n}{M}\right), \; n = -\frac{M}{2}, \ldots, \frac{M}{2}-1$

Which is somewhat close to the vector you give. But that does not explain why you are not satisfied with the results. Actually, different windows often behave similarly enough that you do not easily see the difference. You should have the peak of the window at $1$, even in fixed point representation.

You say you want to detect a certain peak, which does not seem to be represented well in the diagram. You said you got the figure not using a window. In that case either your signal is rather curious (not a sinusoid at all) or something is wrong in your calculation. A sinusoid would be expected to transform into a $\operatorname{sinc}$. Your transformed looks somewhat different. There appear to be two peaks equally strong and some signal inbetween. That is certainly not what is expected.

Maybe you try transforming a simple pulse (a $1$ surrounded by $0$s). It should come out as a simple exponential $y_k=e^{(ck+d)j\omega}$ for some $c$ and $d$, i.e. it should have magnitude $1$ everywhere.

Improve this answer
$\endgroup$
1
  • 1
    $\begingroup$ any how the window array i am using is from matlab it will the same as you mentioned,i will soon update the question with the input waveform also $\endgroup$
    – kakeh
    Commented Jan 30, 2014 at 4:44
0
$\begingroup$

"after windowing with the above window it has turned the sinusoidal to sqaure(expected ? !) which further given rise to more worse FFT why so ?"

Windowing is point-wise multiplication, that is, you would multiply sample 1 with the first sample of the window, sample 2 with the second, and so on. You appear to ,,chain'' the window function and your signal ($f^\star{}(x)=\mathrm{window}(f(x))$), which is just the wrong thing to do.

Apparently you resolved a problem in your transform. The new result certainly looks better: there is a clear peak, as would be expected.

Improve this answer
$\endgroup$
2
  • $\begingroup$ sorry i was using an window which is not mentioned in my question in my experimentation it was commented so i have updated it and soon will update my question with results $\endgroup$
    – kakeh
    Commented Jan 30, 2014 at 9:16
  • $\begingroup$ you can have a look i have updated the magnitude plot $\endgroup$
    – kakeh
    Commented Jan 31, 2014 at 11:57
0
$\begingroup$

First I do not see any mention of complex numbers at all. Maybe you are just evaluating the real part of your transform, then the problem with double (or rather, oscillating) peaks could be explained. Kevin McGee referred to that.

The second half of your transform should be conjugate symmetric to the first half, if you transform a real signal (which you certainly appear to do). It is then redundant and can be ignored.

Improve this answer
$\endgroup$
6
  • $\begingroup$ yes you are right,my complex fft expects a complex input so i give real part and zeroed imaginary part,then after my result is complex number array,so i use to plot magnitude using the formula sqrt(real^2 + img^2),even then why my magnitude plot has multiple peaks,more over why they have such a high value ? $\endgroup$
    – kakeh
    Commented Feb 1, 2014 at 5:51
  • $\begingroup$ You should not zero the imaginary part, but take the magnitude first. Instead, you should ignore the second half of the signal (which is something else, but I can see how the confusion arises). I do not know why the values are ,,so high'', they should at least be proportional to the expected values. $\endgroup$
    – user7358
    Commented Feb 1, 2014 at 8:10
  • $\begingroup$ its ok but why am i getting the multiple peaks in my magnitude plot does i require any normalizing to be done,any suggestions on normalization of fft results to a size of short or int $\endgroup$
    – kakeh
    Commented Feb 3, 2014 at 6:03
  • $\begingroup$ Maybe because you are not evaluating the imaginary part of your result? $\endgroup$
    – user7358
    Commented Feb 3, 2014 at 10:03
  • $\begingroup$ no its not that,even though i am taking img part to consideration,actual problem lies in my magnitude calculation,some algorithms like KissFFT are giving the real and img part scaled in range of +/-32K,how can i do that?,because i really want to do that because the output from fft is so large $\endgroup$
    – kakeh
    Commented Feb 3, 2014 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.