Forum: GNU Radio FFT --> IFFT

53a1f0aba6f0489d49f5e6fc3df323fa?d=identicon&s=25 Robert James (robertjames)
on 2013-11-18 03:40
(Received via mailing list)
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?
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-11-18 08:41
(Received via mailing list)
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
53a1f0aba6f0489d49f5e6fc3df323fa?d=identicon&s=25 Robert James (robertjames)
on 2013-11-18 14:23
(Received via mailing list)
On 11/18/13, Marcus Mller <marcus@hostalia.de> 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.
C539637020fd56193dd6daec746c4a84?d=identicon&s=25 Tom Rondeau (Guest)
on 2013-11-18 14:35
(Received via mailing list)
On Mon, Nov 18, 2013 at 8:22 AM, Robert James <srobertjames@gmail.com>
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
Ad80d352eb445a3d7dccd5a779db0e43?d=identicon&s=25 Martin Braun (CEL) (Guest)
on 2013-11-18 14:35
(Received via mailing list)
On Mon, Nov 18, 2013 at 08:22:08AM -0500, Robert James 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 Braun
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
53a1f0aba6f0489d49f5e6fc3df323fa?d=identicon&s=25 Robert James (robertjames)
on 2013-11-18 14:40
(Received via mailing list)
On 11/18/13, Tom Rondeau <tom@trondeau.com> 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
3596cfe1d579c65b9babd35e8787977c?d=identicon&s=25 Matt Ettus (Guest)
on 2013-11-18 17:52
(Received via mailing list)
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
7d89a70df32c0ae27c1235016f9e5441?d=identicon&s=25 "Marcus Müller" <marcus@hostalia.de> (Guest)
on 2013-11-18 18:48
(Received via mailing list)
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
Please log in before posting. Registration is free and takes only a minute.
Existing account

NEW: Do you have a Google/GoogleMail, Yahoo or Facebook account? No registration required!
Log in with Google account | Log in with Yahoo account | Log in with Facebook account
No account? Register here.