Fft --> ifft

When I take a signal, stream->vector–>FFT–>IFFT–>vector->stream,
I’d expect to get the original signal back. Instead, I’m getting
something like the original signal, but following a very low frequency
carrier.

I thought this was due to the limits in vector size, but making this
very high (many times the sample size and signal freq) and the problem
continues,

What’s weirdest is that a low pass filter or band pass filter on the
output don’t seem to solve the problem!

What is my mistake?

Hi Robert!

This is strange – but could be explained by the fact that numerical
inaccuracy don’t allow us to exactly recreate all values during
fft-ifft operation.
Also, make sure you use a rectangular window.

How do you know there is this very low frequency carrier? how low is it?
How much power does it have?

Greetings
Marcus

On 11/18/13, Marcus M. [email protected] wrote:

Hi Robert!

This is strange – but could be explained by the fact that numerical
inaccuracy don’t allow us to exactly recreate all values during fft-ifft
operation.
Also, make sure you use a rectangular window.

Wow, switching to a rectangular window of fft_size solved it! I’m
baffled: I know windows are a way of pretransforming the wave prior to
FFT, to eliminate artifacts. I just used the default window. Why did
I need a rectangular window here? In what other cases do I need it?

Now, the only discrepancy I see is that the FFT->IFFT ended up
increasing the amplitutde by a constant (not sure why or what the
constant is).

How do you know there is this very low frequency carrier? how low is it? How
much power does it have?

On the osilloscope, I see the input signal as a constant wave, which
it is, and I see the output signal a wave of the same signal, but with
amplitude visually oscillating between very high and nothing. On the
audio, I hear the signal coming in and out, in and out, or, depending
on how I set it, I hear a ringing over it (which I assume is the beat
freq). On the FFT display, I see the carrier as a peak, and a long
thick band trailing off to the left.

I don’t know how to measure the power - according to the FFT display,
it’s not just at one freq, but trails off very far to the left.

On Mon, Nov 18, 2013 at 8:22 AM, Robert J. r[email protected]
wrote:

FFT, to eliminate artifacts. I just used the default window. Why did
I need a rectangular window here? In what other cases do I need it?

Were both windows the same or different? I’ve often seen people trying
this experiment using a window on the forward FFT but no window on the
inverse FFT. That would obviously cause different output results.

Now, the only discrepancy I see is that the FFT->IFFT ended up
increasing the amplitutde by a constant (not sure why or what the
constant is).

The constant is N for an N-point FFT. It’s part of the common
algorithms for computing FFTs to grow the value without scaling it
back, since that’s an added extra step and we want our FFTs to be
fast. You can use a multiply_const_cc block with constant (1.0/fftlen)
after the vector-to-stream block to rescale it yourself.

Tom

On Mon, Nov 18, 2013 at 08:22:08AM -0500, Robert J. wrote:

Wow, switching to a rectangular window of fft_size solved it! I’m
baffled: I know windows are a way of pretransforming the wave prior to
FFT, to eliminate artifacts. I just used the default window. Why did
I need a rectangular window here? In what other cases do I need it?

If you want to keep all the properties of the signal, you need a rect
window. What you did was: apply a window, then do an FFT, apply the
window again, do an IFFT. Obviously, you’re distorting the signal
every time you do the (I)FFT. A boxcar window won’t change the signal.

For spectral analysis or filter design, you typically use other windows.

MB


Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

On 11/18/13, Tom R. [email protected] wrote:

Wow, switching to a rectangular window of fft_size solved it! I’m
baffled: I know windows are a way of pretransforming the wave prior to
FFT, to eliminate artifacts. I just used the default window. Why did
I need a rectangular window here? In what other cases do I need it?

Were both windows the same or different? I’ve often seen people trying
this experiment using a window on the forward FFT but no window on the
inverse FFT. That would obviously cause different output results.

Both were the same - the default blackmanharris, set to the ftt_len size

The purpose of a window is to lower bin-to-bin leakage. It is only
useful
when the FFT is the final product, since it changes the signal. Think
of
it this way – you are multiplying a signal in the time domain when you
window. If you window, then FFT, then IFFT, you will get back the
windowed
signal, not the original signal.

Matt

As Martin said, a rect window makes sense, when you want to keep all
the properties of the signal vector.
You experience leakage, but in fact, leakage is just a concept that
refers to the input vector as a representation of a signal. And one
chooses to use a window to reduce leakage, because for many aspects,
leakage distorts what you want the signal to be.
However, from a mathematical perspective, the DFT (of which FFT is only
a class of clever implementations) is only a mapping between two vector
spaces (or even within the same vector space, if you want so). “Leakage”
is no defect here; the transform of a vector is just the value that
specific vector maps to. If you want to reverse that mapping, you apply
the IDFT (IFFT) to the mapped vector; and it doesn’t care about leakage
etc, it just reproduces the original vector from the mapped one.

I have a rule of thumb:
If I consider the FFT as a bijective mapping between two vector spaces,
and the IFFT as the inverse, then I don’t want windowing.
If I, however, look at the FFT as a means to get the spectrum of a
signal that has temporal properties, then, of course, I choose a window
to avoid leakage, because I look at the DFT as a means to get a good
estimate of the spectrum of a signal from a limited time sequence of
samples.

In communications, you usually need to avoid leakage, thus you usually
window the signal. That, however, might break reversibility of the
transform.

Greetings,
Marcus

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs