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, [EMAIL PROTECTED] 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, [EMAIL PROTECTED] 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
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
