Adaptive Filter | ADPCM | ADSP | ADSP-2181 | Aliasing | AMR | Anti-Aliasing | ARMA | Autocorrelation | AutoCovariance | Beamforming | Bessel | Blackfin | Butterworth | C6713 | CCS | Chebyshev | CIC Filter | Circular Convolution | Code Composer Studio | Comb Filter | Compression | Convolution | Cross Correlation | DCT | Decimation | Deconvolution | Demodulation | DM642 | DSP Boards | DSP/BIOS | DTMF | Echo Cancellation | Equalization | Equalizer | ETSI | EZLITE (Ez-kit Lite) | FFT | FFTW | FIR Filter | Fixed Point | FSK | G.711 | G.723 | G.729 | Gaussian Noise | Goertzel | GPIO | Hilbert Transform | IFFT | IIR Filter | Interpolation | Invariance | JTAG | Kalman | Laplace Transform | Levinson | LPC | McBSP | MIPS | Modulation | MPEG | Multirate | Notch Filter | Nyquist | OFDM | Oversampling | Pink Noise | Pitch | PLL | Polyphase | QAM | QDMA | Quantization | Quantizer | Radar | Random Noise | Reed Solomon | Remez | Resampling | RTDX | Sampling | Sharc | TI C6711 | Undersampling | Viterbi | Wavelets | White Noise | Wiener Filter | Windowing | XDS510PP | Z Transform

Hi All,

I'm doing some tests with FFTW and it seems to be working ok, but I am
seeing something that's a little odd and was wondering if my reasoning
for it happening was correct.

Basically, I have a 3 second 440hz sine wave file created in Audacity
at 44.1khz sampling rate.  I am running FFTW on a 4096 size window on
the data and moving the window along by a small amount each time.  I
was expecting the sum of all the amplitudes returned from FFTW to be
the same for each run of the window as it moves along, but there is a
noticeable difference.  Is this because the starting point of the
sample of data doesn't start and end cleanly at the same position
along the sine wave?

Thanks
Ray

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Raeldor <r...@gmail.com> wrote:
 
> I'm doing some tests with FFTW and it seems to be working ok, but I am
> seeing something that's a little odd and was wondering if my reasoning
> for it happening was correct.
 
> Basically, I have a 3 second 440hz sine wave file created in Audacity
> at 44.1khz sampling rate.  I am running FFTW on a 4096 size window on
> the data and moving the window along by a small amount each time.  I
> was expecting the sum of all the amplitudes returned from FFTW to be
> the same for each run of the window as it moves along, but there is a
> noticeable difference.  

Why would you expect that?  It is hard to answer without knowing,
as there is little reason to expect it.  If you have a whole
number of cycles of the 440Hz, then it would be a reasonably
expectation.

> Is this because the starting point of the
> sample of data doesn't start and end cleanly at the same position
> along the sine wave?

If this means a whole number of cycles, then yes.

-- glen

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

On Oct 2, 11:29=A0am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Raeldor <rael...@gmail.com> wrote:
> > I'm doing some tests with FFTW and it seems to be working ok, but I am
> > seeing something that's a little odd and was wondering if my reasoning
> > for it happening was correct.
> > Basically, I have a 3 second 440hz sine wave file created in Audacity
> > at 44.1khz sampling rate. =A0I am running FFTW on a 4096 size window on
> > the data and moving the window along by a small amount each time. =A0I
> > was expecting the sum of all the amplitudes returned from FFTW to be
> > the same for each run of the window as it moves along, but there is a
> > noticeable difference. =A0
>
> Why would you expect that? =A0It is hard to answer without knowing,
> as there is little reason to expect it. =A0If you have a whole
> number of cycles of the 440Hz, then it would be a reasonably
> expectation.
>
> > Is this because the starting point of the
> > sample of data doesn't start and end cleanly at the same position
> > along the sine wave?
>
> If this means a whole number of cycles, then yes.
>
> -- glen

Thank you for the reply Glen.  Yes, I meant whole cycles... sorry, I'm
new to this and still picking up the terminology.

If I wanted to get rid of this anomaly would using some kind of
exponential curve on the data set to effectively 'fade in and out'
help?  Are there any other techniques to minimize this?

Thanks
Ray

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

On Oct 2, 12:04=A0pm, Raeldor <rael...@gmail.com> wrote:
> ...
>
> If I wanted to get rid of this anomaly would using some kind of
> exponential curve on the data set to effectively 'fade in and out'
> help? =A0Are there any other techniques to minimize this?
>
> Thanks
> Ray

There is a technique called windowing.

http://utdallas.edu/~cpb021000/EE%204361/Great%20DSP%20Papers/Harris%20on%2=
0Windows.pdf

Windowing may help your expectation when you do not have a integer
number of cycles of your sine wave in your fft. It may hurt your
expectations when you don't.

The fact that you refer to what you have found as an anomaly makes
your expectations suspect. Better to find out how things actually work
first and then grow expectations. Many people come to comp.dsp with
continuous/infinite Fourier transform expectations for discrete/finite
transform behavior. Sometimes it is close. Sometimes it isn't.
(Depending on what you expect 'close' to mean. :)

Dale B. Dalrymple

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Raeldor <r...@gmail.com> wrote:
> On Oct 2, 11:29 am, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>> Raeldor <rael...@gmail.com> wrote:

>> > Basically, I have a 3 second 440hz sine wave file created in Audacity
>> > at 44.1khz sampling rate.  I am running FFTW on a 4096 size window on
>> > the data and moving the window along by a small amount each time.  I
>> > was expecting the sum of all the amplitudes returned from FFTW to be
>> > the same for each run of the window as it moves along, but there is a
>> > noticeable difference.  

>> Why would you expect that?  It is hard to answer without knowing,
>> as there is little reason to expect it.  If you have a whole
>> number of cycles of the 440Hz, then it would be a reasonably
>> expectation.
(snip)
 
> Thank you for the reply Glen.  Yes, I meant whole cycles... sorry, I'm
> new to this and still picking up the terminology.
 
> If I wanted to get rid of this anomaly would using some kind of
> exponential curve on the data set to effectively 'fade in and out'
> help?  Are there any other techniques to minimize this?

The way to get rid of it is to include only whole cycles.

If you can't do that, then you need to say what you are really
trying to do.  The first post sounded like you were testing out
FFTW, though the actual use might be different.

The math for it says that the sum of the squares in frequency space
is proportional to the sum of the squares in real space.

-- glen

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

Raeldor <rael...@gmail.com> wrote:

> (snip)

Let's see. You've got N = 4096 and a sampling rate (s_r) of 44100, so
your 'bin width' and bin spacing in the frequency domain is s_r/n =
10.76 hz or so. You can tell immediately that you'll have leakage in
your results because the 440 hz sine wave is not an integer multiple
of your bin spacing (i.e.: you don't have an FFT output point that
corresponds EXACTLY to the frequency off your input).  Based on the
numbers you're using, the closest bins are at k = 40 (corresponds to
40*s_r/N = 430.66 hz) and k = 41 (corresponds to 41*s_r/N = 441.43
hz).

You can figure out the number of cycles of your 440 tone within the
4096 FFT samples by considering that your 'sampling interval' (total
length of time represented by your 4096 samples) is s_r/N = 4096/44100
= .09287 seconds, and a single cycle of your 440 hz input is 1/440 = .
00227 seconds.  So dividing your sampling interval by the time for 1
cycle of your input gives you about 40.87 cycles.

So what you're seeing is probably due to leakage in the frequency
domain.

I said probably because you also mentioned a window in your post. Is
that an implied rectangular window, or an explicit one (e.g.: Hann,
Hamming, etc.)?  Explicit windows can help you reduce leakage effects,
but there are trade-offs and subtleties in using them (see Dale's link
in the dbd post above for the well known Harris paper on windows).
You have to know how the parameters of the window can affect your
results.  There are even 'sum of cosine' windows that can reduce the
leakage to zero above and below certain points, even if you have an
input sinusoid that's non-periodic in the sampling interval (R. J.
Webster, IEEE Proc., Oct 1980).

Kevin McGee

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

On Oct 3, 2:09=A0am, kevin <kevinjmc...@netscape.net> wrote:

Dang! Second line above should be s_r/N, not s_r/n.  One of these days
I'll learn to type properly.

Kevin McGee

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

On Oct 3, 2:12=A0am, kevin <kevinjmc...@netscape.net> wrote:

Aaargh! Another mistake - the 'sampling inteval' in the second
paragraph should be N/s_r, not s_r/N.

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.

On Oct 2, 11:15=A0pm, kevin <kevinjmc...@netscape.net> wrote:
> On Oct 3, 2:12=A0am, kevin <kevinjmc...@netscape.net> wrote:
>
> Aaargh! Another mistake - the 'sampling inteval' in the second
> paragraph should be N/s_r, not s_r/N.

Thanks for the replies, guys.  As usual it'll take me a little while
to digest all the great info.  It may be less of an issue in a real
sample (I'm analyzing voice for closeness of pronunciation), but I
noticed in my test samples with sine waves it really showed it's head
pretty clearly.  I'll experiment a little with different windowing
options and see how it looks on both the sine wave samples and the
voice samples.

Thanks again!

______________________________
New DSP Code Snippets Section now Live.   Learn more about the reward program for contributors here.