Saturation with multi_fft.py

GNU Radio
1

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

Eric H. Matlis, Ph.D.
Aerospace & Mechanical Engineering Dept.
120 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax: (574) 631-8355

2

On Fri, Oct 05, 2007 at 05:19:38PM -0400, [email protected] wrote:

dependent on the decimation. At lower decimation values the magnitudes
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

3

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

4

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

5

Eric-

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.

This should work Ok, but let me comment that based on personal
experience FPGA tool
software is some of the most fickle, easy-to-crash (/ hang up / produce
inconsistent
results / etc) software out there. If there is any little small thing
wrong with the
virtualization, you could get an incorrect result, and it might be very
hard to pin
down. I would suggest to install Quartus on a WinXP machine, build USRP
logic to be
sure it matches the defined results down to the last detail, and then
compare that
with the Linux-hosted virtualization.

Let me put it another way – if some day you have to ask an Altera/FPGA
online tech
group for assistance and you told them you were not running on native
WinXP, they’d
tell you to do that before spending time to help out.

-Jeff

6

On Mon, Oct 08, 2007 at 08:08:20PM -0400, [email protected] wrote:

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?

Sounds that way.

I may just be missing a verilog file from the project file
usrp_multi.qsf. Try adding the line below:

[eb@dee usrp_std]$ grep cic_dec_shifter *
usrp_std.qsf:set_global_assignment -name VERILOG_FILE
…/…/sdr_lib/cic_dec_shifter.v

Eric

7

On Mon, Oct 08, 2007 at 07:41:06PM -0500, Jeff B. wrote:

down. I would suggest to install Quartus on a WinXP machine, build USRP logic to be
sure it matches the defined results down to the last detail, and then compare that
with the Linux-hosted virtualization.

I don’t think that’s the problem.
I run Quartus on a Win2K guest on VMware on Linux.

Eric

8

On Mon, Oct 08, 2007 at 08:04:24PM -0500, Jeff B. wrote:

software is some of the most fickle, easy-to-crash (/ hang up / produce inconsistent
get identical results to a native WinXP run, then certainly that particular
virtualization config is not a problem. But it should be tested. To compound
things, it’s not like the FPGA vendors have good Q&A – lots of unstable releases.

All good points.

Thanks,
Eric

9

Eric-

virtualization, you could get an incorrect result, and it might be very hard to pin
down. I would suggest to install Quartus on a WinXP machine, build USRP logic to be
sure it matches the defined results down to the last detail, and then compare that
with the Linux-hosted virtualization.

I don’t think that’s the problem.
I run Quartus on a Win2K guest on VMware on Linux.

My comments are general and I also doubt that it’s the problem in this
case. If you
get identical results to a native WinXP run, then certainly that
particular
virtualization config is not a problem. But it should be tested. To
compound
things, it’s not like the FPGA vendors have good Q&A – lots of unstable
releases.

-Jeff

10

Your suggestion worked to fix the compilation problem, along with the
addition of a line for atr_delay.v, however, I’m not able to load the
newly compiled rbf file into the usrp, and the error leads me to believe
I
need to take a step back and make sure I’m working with the right files.

When I copied the newly compiled usrp_multi.rbf to
share/usrp/rev2/, I get the following error with the
verbose environment variable turned on:

usrp: firmware …share/usrp/rev2/std.ihx loaded successfully.
Can’t find fpga bitstream: multi_usrp_test.rbf

even though I specified the name “multi_usrp_test.rbf” in the python
code.

So on a hunch I changed the name of the rbf file to std_4rx_0tx.rbf,
adjusted my python code appropriatly, and now it loads but I get the
following:

usrp: firmware …/share/usrp/rev2/std.ihx loaded successfully.
usrp: fpga bitstream …share/usrp/rev2/std_4rx_0tx.rbf loaded
successfully.
This code requires an FPGA build with 4 DDCs. This FPGA has only 2.

So now my question is, to test the multiple receive capability of the
usrp, exactly which project file (in which directory) do I need to load
into Quartus, do I need to modify it to enable 4 receive ddc’s, and once
it compiles, what do I do with it? Where do I put it and how do I name
it? Why does it need to be named exactly one way and not another?

thanks,
eric

11

Actually no, I want the code that enables a single usrp to receive
signals
on two daughterboards. Sorry about the confusion on that; I assumed the
“multi” in the filenames was referring to multiple daughterboards, I had
forgotten there’s a multi-usrp capability as well.

So, with that cleared up, can you verify which file specifically I
should
load into Quartus? There is only one usrp_std.qpf project file in

usrp/fpga/toplevel/usrp_std

so it is unclear to me how to compile for the two-daughter board case as
opposed to the single. Do I need to configure something in the project
file for the two-daughterboard case?

thanks,
eric

p.s.- on a positive note, at least my efforts to date have revealed what
updates the multi_usrp.qsf file needs to compile!

12

On Tue, Oct 09, 2007 at 12:05:08AM -0400, [email protected] wrote:

Can’t find fpga bitstream: multi_usrp_test.rbf

even though I specified the name “multi_usrp_test.rbf” in the python code.

So on a hunch I changed the name of the rbf file to std_4rx_0tx.rbf,
adjusted my python code appropriatly, and now it loads but I get the
following:

usrp: firmware …/share/usrp/rev2/std.ihx loaded successfully.
usrp: fpga bitstream …share/usrp/rev2/std_4rx_0tx.rbf loaded successfully.
This code requires an FPGA build with 4 DDCs. This FPGA has only 2.

This would indicate that you didn’t build what you think you did (or
that the code that initializes that register value is hosed).
The host reads back a register from the FPGA image to get the answer
to number DDCs and DUCs. I suspect that you may have copied the wrong
rbf to the wrong place, or something similar.

So now my question is, to test the multiple receive capability of the
usrp,

Just to be clear, I think that you mean that you want to use multiple
USRPs to receive multiple signals, NOT a single USRP with two
daughterboards to receive multiple signals. Do I understand you
correctly?

exactly which project file (in which directory) do I need to load
into Quartus, do I need to modify it to enable 4 receive ddc’s, and once
it compiles, what do I do with it? Where do I put it and how do I name
it? Why does it need to be named exactly one way and not another?

The project file for the multi-usrp stuff is in
usrp/fpga/toplevel/usrp_multi

You need to copy the resulting .rbf file into
…/share/usrp/rev{2,4}/multi_4rx_0tx.rbf (or whatever you want to call
it)

Then you need to ensure that you are specifying that filename in the
USRP constructor. E.g.,

u = usrp.source_c(0, decim, fpga_firmware=“multi_4rx_0tx.rbf”)

I’m assuming that you have looked at the code in
gnuradio-examples/python/multi_usrp/*

I’m not exactly sure of that status of that code.
Martin DVH would be the one to ask.

Eric

13

So there is no difference in the fpga code between the standard
usrp_fft.py and multi_fft.py found in the multi-antenna directory? Then
why does the latter specify std_4rx_0tx.rbf?

And to reiterate my original concern, the multi-antenna versions of the
code will not accept more than between .3-.4 V p-p for decimation rates
greater than 128; greater than .4 V p-p and the result acts as if the
A/D
chips are clipping. It’s not a hardware issue with my USRP because the
usrp_fft.py codes correctly measure up to 2 V p-p.

thanks for your help,
eric

14

On Tue, Oct 09, 2007 at 09:11:31AM -0400, [email protected] wrote:

Actually no, I want the code that enables a single usrp to receive signals
on two daughterboards. Sorry about the confusion on that; I assumed the
“multi” in the filenames was referring to multiple daughterboards, I had
forgotten there’s a multi-usrp capability as well.

The standard host and fpga code support multiple daughterboards as
long as they are sharing the same interp and decim rates.

For examples of this please take a look at

gnuradio-examples/python/multi-antenna/*

So, with that cleared up, can you verify which file specifically I should
load into Quartus? There is only one usrp_std.qpf project file in

usrp/fpga/toplevel/usrp_std

so it is unclear to me how to compile for the two-daughter board case as
opposed to the single. Do I need to configure something in the project
file for the two-daughterboard case?

There is nothing for you to do. The standard code supports two
daughterboards. On the fpga it’s handled via the muxes implemented in
the
FPGA. See http://gnuradio.org/trac/wiki/UsrpRfxDiagrams

thanks,
eric

p.s.- on a positive note, at least my efforts to date have revealed what
updates the multi_usrp.qsf file needs to compile!

Thanks!
Eric

15

Thanks so much for clarifying that! I see now that config.vh controls
how
the code is configured.

Regarding the loss of the half-band filters in the multi-antenna fpga
configuration; what is the recommendation to avoid aliasing? Say for
the
case of a 2 MHz carrier AM waveform with modulation out to 100 kHz.
What
kind of filtering would I need to avoid aliasing?

thanks again,
eric

16

On Tue, Oct 09, 2007 at 01:02:18PM -0400, [email protected] wrote:

So there is no difference in the fpga code between the standard
usrp_fft.py and multi_fft.py found in the multi-antenna directory? Then
why does the latter specify std_4rx_0tx.rbf?

Because it wants 4 digital downconverters (it’s a 4 antenna example).
We generate two standard FPGA configurations:

std_2rxhb_2tx.rbf # 2 DDCs w/ halfband filters and 2 Tx paths
std_4rx_0tx.rbf # 4 DDCs w/o halfband filters and 0 Tx paths

And to reiterate my original concern, the multi-antenna versions of the
code will not accept more than between .3-.4 V p-p for decimation rates
greater than 128; greater than .4 V p-p and the result acts as if the A/D
chips are clipping. It’s not a hardware issue with my USRP because the
usrp_fft.py codes correctly measure up to 2 V p-p.

To avoid confusion, let’s make sure we’ve got our terminology
straight. There is no “multi-antenna” version of the FPGA code, only
the two configurations described above. They are built from the same
source, and vary only in which of the .vh files is included.

However, taking a look at the modification dates on the .rbfs in:

http://gnuradio.org/trac/browser/gnuradio/trunk/usrp/fpga/rbf/rev2

It appears that the std_2rxhb_2tx.rbf was updated 3 months ago, but
that the std_4rx_0tx.rbf was updated 6 months ago. They should have
both been generated and updated at the same time. [A makefile to
handle this would be a good idea.]

I will rebuild them both and update the rbf’s in svn.
I’ll post a note when this is done.

thanks for your help,
eric

You’re welcome,
Eric

17

Eric B. wrote:

usrp: firmware …share/usrp/rev2/std.ihx loaded successfully.
This code requires an FPGA build with 4 DDCs. This FPGA has only 2.
Just to be clear, I think that you mean that you want to use multiple

I’m not exactly sure of that status of that code.
Martin DVH would be the one to ask.
That code hasn’t been updated in a while.
usrp_mult/config.vh includes
`include “…/include/common_config_2rxhb_2tx.vh”

Which enables two actual rx and two actual tx channels.
So the default bitstream it generates should be renamed to
multi_2rxhb_2tx.rbf

This code requires an FPGA build with 4 DDCs. This FPGA has only 2.
The code does a few tricks to enable 4 rx channels to enable extra
channels for sample alignment.
(These extra channels don’t carry samples but just samplenumbers)

Is seems like somewhere in the codechain a check was added (or changed)
to check if the bitstream supports the number of channels requested.
Probably there goes something wrong there.

(usrp_multi has two actual channels a samplenumberchannel and a not-used
channel)

Martin

18

Thanks-

I just downloaded, compiled and installed this latest revision. When I
test multi_scope.py in the mutli-antenna examples directory with this
release I get the same issue. Please note, I have the LF_RX
daughterboards, so I change the daughterboard ID from BASIC to LF in the
python code. I also eliminate the second factor of 4 decimation in the
host (sw_decim = 4) by setting it to 1. I then run with the following
command:

multi-antenna]$ ./multi_scope.py -f0 -d250 -g0

while acquiring a 10 kHz 0.3 V p-p signal. The max value shown in the
waveform on the gui is just over 25,000, which is way too much compared
to
the standard usrp_fft.py, which by the way is no longer in the examples
directory; I used one from a previous release. If I increase the input
voltage level to 0.4 V p-p, I get a jagged waveform with sharp
discontinuities.

So, my problem remains. Any ideas?

thanks,
eric

19

On Tue, Oct 09, 2007 at 03:02:33PM -0400, [email protected] wrote:

Thanks so much for clarifying that! I see now that config.vh controls how
the code is configured.

FYI, I’ve committed new rbfs to the trunk. They were built with
Quartus II Web Edition, version 7.1 SP1

Regarding the loss of the half-band filters in the multi-antenna fpga
configuration; what is the recommendation to avoid aliasing? Say for the
case of a 2 MHz carrier AM waveform with modulation out to 100 kHz. What
kind of filtering would I need to avoid aliasing?

thanks again,
eric

With the halfbands, it’s flat to about 70% of the passband.
decim = 320 gives 200kS/s complex baseband, a bit more than you’ll
need.

Without the halfbands, I’d use about 4x the bandwidth of interest,
then filter and decimate in the host for the final channel selection.
In your case, I’d use decim = 160 giving 400kS/s.

Eric

20

I don’t have a chance to test your suggestion at the moment, but no, my
test signal was an un-modulated 10 kHz signal.

eric