[Top][All Lists]

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

Re: [Discuss-gnuradio] saturation with multi_fft.py

From: ematlis
Subject: Re: [Discuss-gnuradio] saturation with multi_fft.py
Date: Mon, 8 Oct 2007 19:18:28 -0400 (EDT)

Ok, I installed the latest Quartus II ver. 7.2 software onto a virtualized WinXP guest hosted by a Linux x86_64 system running kvm/qemu. I downloaded a recent revision of gnuradio (revision 6595) onto the host.

I started Quartus, and using a samba connection between the virtual guest and the Linux host I opened the usrp_multi.qpf project file in: usrp/fpga/toplevel/usrp_multi

Not knowing anything about Quartus, I took a guess and hit "Start Compilation" under the Processing menu.

The compilation begins, a lot of green and blue lines go by including many "Elaborating entity...", but after a short while the compilation fails with an error:

"Error: Node instance "cic_dec_shifter" instantiates undefined entity "cic_dec_shifter"

The line just before this, says:

"Info: Elaborating entity "sign_extend" for hierarchy "rx_chain:rx_chain_0|cic_decim:cic_decim_i_0|sign_extend:ext_input"

Not sure what to do at this point....


On Sun, 7 Oct 2007, Eric Blossom wrote:

On Fri, Oct 05, 2007 at 05:19:38PM -0400, address@hidden wrote:
Can anybody tell me why the multi_* versions of the fft and scope
applications (found in the multi-antenna directory) seem to have such a
large gain on the input signal for high decimation values (eg 250),
relative to the non-multi versions (at same -g gain setting) of the fft
and scope aps?  I'm saturating the inputs for anything above .3 V p-p
using a function generator, whereas the non-multi versions work fine up to
the 2 V p-p limit of the A/D.

I'm putting in frequencies of 10 kHz and tuning to 0 Hz.  I also noticed
that the magnitudes of the values displayed by the multi_* programs is
dependent on the decimation.  At lower decimation values the magnitudes
are much less.  This variation is not as pronounced on the non-multi
versions, although there is a 'dip' in the response.  To give you some
idea of the magnitude difference:

for a .3 V p-p 10 kHz sine-wave input, here are the peak values:

decimation       usrp_fft.py (with -S)         multi_scope.py
64                     1750                          1750
128                    1750                          1750
144                    1750                          2900
188                    1000                          8000
200                    1200                          10000
250                    1750                          25000

So for decimations greater than 128 the mult_* applications cannot take 2
V p-p. Any ideas?


The FPGA rbf's checked into the trunk are probably not up to date for
the multi_scope case.  I'm not in the habit of building multi-board
versions since I'm not sure how to test them.

If you've got the free (beer) Quartus tools installed, you can rebuild
the rbf's and check.


reply via email to

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