discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] any possible change in gr.fft_vcc from earlier ve


From: Alex Dusowitz
Subject: Re: [Discuss-gnuradio] any possible change in gr.fft_vcc from earlier versions?!
Date: Sun, 19 May 2013 14:57:35 -0400

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


On Sun, May 19, 2013 at 5:31 AM, Tom Rondeau <address@hidden> wrote:
On Sat, May 18, 2013 at 11:15 PM, Alex Dusowitz <address@hidden> wrote:
> 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

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

Attachment: ofdm_carrier_mapper.dat
Description: Binary data

Attachment: testFFT.py
Description: Binary data

Attachment: ofdm_ifft_test_3.2.2.dat
Description: Binary data

Attachment: ofdm_ifft_test_3.6.4.1.dat
Description: Binary data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]