Any possible change in gr.fft_vcc from earlier versions?!

GNU Radio
1

Hi list,

I have ported some code from Gnuradio-3.2.2 version to most recent
UHD-based 3.6.4 version and I was trying to check the functionality of
my
ported code by comparing the output of its every block versus the old
code
one by one. Some of the blocks I’ve used in Python are written in C++
and
some are default from gnuradio-core.

I have problem matching the output of gr.fft_vcc block in two codes,
directly used from gnuradio-core, but from two different versions.
Despite
seeming highly unlikely, I checked the C++ source code for fft_vcc in
both
gnuradio versions and couldn’t find any difference between the two. By
making sure that the input to the blocks in both codes are the same, now
I
have run out of other possible solutions. I appreciate if someone could
give me a lead on this!

Thanks,
Alex

2

On Sat, May 18, 2013 at 11:15 PM, Alex Dusowitz
[email protected] wrote:

seeming highly unlikely, I checked the C++ source code for fft_vcc in both
gnuradio versions and couldn’t find any difference between the two. By
making sure that the input to the blocks in both codes are the same, now I
have run out of other possible solutions. I appreciate if someone could give
me a lead on this!

Thanks,
Alex

Hi Alex,

Can you please use the bug tracker for this? One benefit is that you
can post example code and results easily for us to see. Even attach
some images to the page to show the difference between the two.

But just a quick thought: are you sure it’s not just an FFT shift? I
think we might have changed how this was enabled by default.

Tom

3

Tom,

I guess I can’t use the bug tracker since I’m not a contributor! Am I
right? Although I created an account (“Alexdu”) in case I can be added
by
you.

In the mean time, attached are 4 files, the FFT input, a simple test
python
code that takes the input and write the FFT result into an output file.
The
outputs are different when I run the code in 3.2.2 and 3.6.4!

Also I couldn’t relate this to FFT shift, I tried with both cases and
still
the results were different. FFT and IFFT wouldn’t change this either.

–Alex

4

On Sun, May 19, 2013 at 02:57:35PM -0400, Alex Dusowitz wrote:

I guess I can’t use the bug tracker since I’m not a contributor! Am I right?
Although I created an account (“Alexdu”) in case I can be added by you.

In case you couldn’t already, now you can post.

In the mean time, attached are 4 files, the FFT input, a simple test python
code that takes the input and write the FFT result into an output file. The
outputs are different when I run the code in 3.2.2 and 3.6.4!

Also I couldn’t relate this to FFT shift, I tried with both cases and still the
results were different. FFT and IFFT wouldn’t change this either.

Have you tried explicitly setting the window? I faintly remember seeing
something like this a while ago… there was a weird default value for
window somewhere (not rectangular).

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

5

I think it was my mistake somehow, I used hexdump to see the values of
the
FFT results and seemed like the differences were in the LSB digits and
hence different rounding perhaps. I was running the two code on two
different laptops, although entirely identical in terms of hardware
spec,
ubuntu and gnuradio installation and I was expecting them to produce
identical results as well. Running the two codes on the same machine
with
two different gnuradio versions produced identical FFT results. So I
guess
this case is closed.

And thanks for adding me to the reporters list…

–Alex