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

[ematlis]

Just as an update, I downloaded revision 6599 and tried again, no change 
in the result.  I then tried to compile usrp_std.qpf, and that did work; 
it produced 11,496 total logic elements for a utilization of 95%, so I 
think the Quartus software is working correctly.

> From this it would appear that usrp_multi needs to be updated?

eric

On Mon, 8 Oct 2007, address@hidden wrote:

> 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
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio