[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] WX FFT in 3.7 (master)
From: |
Kevin Reid |
Subject: |
Re: [Discuss-gnuradio] WX FFT in 3.7 (master) |
Date: |
Tue, 27 Aug 2013 18:51:56 -0700 |
On Aug 27, 2013, at 16:45, Ian Buckley <address@hidden> wrote:
> So none else currently has any problems with WX GUI FFT functionality in 3.7
> at head of master? (c1f0b50d1d5a817c98130726997ba284ea980d95)
> I'd be grateful if someone could try the attached test case flow graph and
> see if they can reproduce these (incorrect) results
> http://ianbuckley.net/fft3.7_test.png
>
> I was expecting something very close to this output from 3.6:
> http://ianbuckley.net/fft3.6_test.png
FWIW, I've been seeing similar effects myself since upgrading to 3.7, but in
the output of the 'logpwrfft' block fed into my own GUI, not WX GUI. They look
to be implemented similarly internally, though. In my case, if I shift the
frequency of the signal, the tails of the curve gets wider or narrower
(specifically, at its widest when the peak is exactly between two FFT-bins).
I asked on IRC about it and the answer I got was that what I was seeing was
inevitable artifacts of the FFT computation, but my memory says that when I was
using 3.6 this effect didn't occur. But my memory is not all that reliable, and
my understanding of DSP is not sufficient to evaluate the claim.
Here's my own comparison pictures, both running in 3.7(.1 I think?) but with
slightly different tuning of a live signal:
http://switchb.org/kpreid/2013/gr37fft0
http://switchb.org/kpreid/2013/gr37fft1
I got similar results to yours with a signal generator.
(I can't run your test myself, or the above again, because I currently don't
have WX GUI available, due to the current issues with MacPorts wxPython.)
--
Kevin Reid <http://switchb.org/kpreid/>