On Aug 27, 2013, at 16:45, Ian Buckley <[email protected]> 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/>


_______________________________________________
Discuss-gnuradio mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to