[Discuss-gnuradio] FFT normalization issue: noise aliasing

[Marcus Müller]

Hi Jean-Michel,

So, what I see in your flow graph is that you have a (real signal, let's
talk about single-sided bandwidth) ca 13kHz wide piece of noise in your
16 kHz bandwidth – or, to put it so that I can forget about the absolute
(nominal) sampling rate totally, 13/16 of your band is noise after the
"Low Pass Filter" block. After that, you throw away 9 of 10 samples.
You're right, that will lead to aliasing. But, we can look at this two ways:

1. Looking at it as sequence of separate samples
You're really just throwing away random samples, which barely correlate.
The variance of the individual "surviving" sample is just the same as
the variance of the original signal's samples. And since the noise is
still pretty much white before and after the downsampling, as the
throwing away doesn't introduce new correlation, the PSD (in this case,
let's understand PSD as E[|DFT|²] ) should be identical – a horizontal
line at the same height as in the unfiltered signal (ok, lower by a
factor of 13/16, won't easily see that in dB).

2. Looking at it as power signal
You're throwing away 9/10 of the samples – your power per time should go
down by a factor of 10 (if we imagine your samples being modeled as Sinc
sequence or dirac comb in continuous time with the sampling period as
distance).
Now, the aliasing compensates that, so that you get the original power
in your decimated digital signal.

You'll notice the absolute values [dB] of the axes will be different if
you use the Qt GUI sinks instead of WX. GNU Radio will drop the WX GUI
toolkit completely in Release 3.8, because we have no-one to maintain it
(and because Qt GUI has turned out to be significantly more compatible
and faster). So, what we say here about the WX FFT sink doesn't
inherently apply to the Qt GUI sink, and it's not likely we'll fix the
WX behaviour – that would mean breaking backwards compatibility. One of
them divides the output power by the length of the FFT, the other
doesn't. I'm not quite convinced either one is more "right" than the other.

Best regards,

Marcus

On 15.10.2017 14:03, Jean-Michel FRIEDT wrote:
> I want to demonstrate how aliasing rises the noise level upon decimation.
> I have a trivial flow graph with a noise source, whose bandpass I
> limit to make
> sure I know its spectral characteristics, and I compare the spectral
> power
> with and without decimation. The decimation FIR is 1 so I believe no
> filtering
> should be performed. I expect the noise level to rise 10-fold upon a
> decimation
> by 10 through aliasing. That does not happen: the spectral density
> remains the
> same, with and without decimation.
> http://jmfriedt.sequanux.org/aliasing_noise_png.png for the flowchart,
> and
> http://jmfriedt.sequanux.org/noise1.png for the spectra.
> Is this the expected behavior ? I do not expect to be so, and I wonder
> if the
> normalization coefficient is correct.
> GNU/Octave does not help me much on the issue: generating a random
> sequence
> and comparing the fft of the sequence or fft of one in every 10 sample
> *drops*
> the level 10 fold, as summarised in
> jmfriedt.sequanux.org/aliasing_octave.pdf.
>
> Of course we all want ifft(fft(signal)) to be equal to signal, but I
> have seen
> all sorts of normalization (1/N on the FFT and none on iFFT, 1/N on
> iFFT and
> none on FFT, 1/sqrt(N) on both FFT and iFFT with N the number of
> samples on
> which the FFT is computed).
> Shouldn't my aliasing experiment raise the noise floor rather than
> keep it
> constant ?
>
> Thanks, JM
>
> ----------------------------------------------------------------
> This message was sent using IMP, the Internet Messaging Program.
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

smime.p7s
Description: S/MIME Cryptographic Signature