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

[ematlis]

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....

thanks,
eric

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?
> >
> > thanks,
> > eric
>
> 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.
>
> Eric