Usrp2_fft.py and changing the gain

GNU Radio
1

Hi all,
I’ve encountered an issue while running usrp2_fft.py with a dbsrx
daughterboard and I was looking for some insight as to what the cause
is (and a pointer towards a solution if one exists).

When I launch usrp2_fft.py with my dbsrx daughterboard installed, the
system comes up just fine and I see the expected spectrum displayed.
I can change frequencies all day long, and it works exactly as
expected.

However, as soon as I try to change the gain via the usrp2_fft.py GUI,
I get an ‘O’ character spit out on the USRP2’s serial port, and the
GUI completely freezes. I then have to do a manual exit from
the GUI window to get back to a cmd prompt, and can re-launch things
from there.

Digging into the USRP2 firmware, the txrx.c main polling loop is where
the putchar(‘O’) gets executed, and there are a few comments
indicating that this is in fact an error case. But it isn’t clear to
me what exactly is causing this. The comments indicate that this may
be some sort of overrun condition, and there is a restart_streaming()
call to possibly deal with this issue, but it is commented out in the
current release. I’ve tried it with a few different daughterboards,
and all seem to result in the same frozen GUI when I go to change the
gain.

Things I’ve tried (with corresponding results):
-Sometimes when I decimate the data sufficiently (say, to 32 or 64), I
can change the gain on the slider without a problem. But not always.
-I can set the gain from the cmd line when usrp2_fft.py is launched,
and it works just fine.

Anyone else encountered this? Any insights as to what the cause may
be? I’d be happy to dig in and work on a resolution if somebody
points me in the right direction.

Here is my setup:
-GNU Radio git repo cloned ~4/5/2010
-USRP2 + DBSRX, plugged directly into the gigE port on a Lenovo
T400/Core 2 Duo laptop running FC12 (32-bit)…I’ve also tried this on
an Acer 8940 with a Core I7 running FC12 (64-bit)…same issue on both

Any help would be appreciated…thanks.

–
Regards,
John O.
CEO/System Architect
Epiq Solutions

2

On Mon, Apr 12, 2010 at 15:27, John O. [email protected]
wrote:

However, as soon as I try to change the gain via the usrp2_fft.py GUI,
I get an ‘O’ character spit out on the USRP2’s serial port, and the
GUI completely freezes. I then have to do a manual exit from
the GUI window to get back to a cmd prompt, and can re-launch things from there.

What you are seeing is a known bug with the current design of the
USRP2 firmware. The internal gain calculations for the DBSRX by the
microcontroller take too long for the polling loop to keep up with the
state machine transitions. When this happens, I find that I can
usually change the frequency via the GUI and the receive stream will
start again.

The solution to this is to go either go to a fully interrupt driven
firmware design, and/or to move the daughterboard code back out of the
firmware and onto the host like USRP1. I believe both of these things
are happening in the Ettus R. UHD driver design, but I am not
certain.

Johnathan

3

On Tue, Apr 13, 2010 at 1:54 AM, Johnathan C.
[email protected] wrote:

state machine transitions. When this happens, I find that I can
usually change the frequency via the GUI and the receive stream will
start again.

The solution to this is to go either go to a fully interrupt driven
firmware design, and/or to move the daughterboard code back out of the
firmware and onto the host like USRP1. I believe both of these things
are happening in the Ettus R. UHD driver design, but I am not
certain.

Thanks for the insight Jonathon. I was doing some testing with our
BURX board as well, and got the same GUI freezing result. The gain
calculations for our board is trivial, so I wouldn’t think that it is
a matter of time being consumed doing these calculations. However,
both the DBSRX and the BURX board use an I2C interface to communicate
from the host to the daughterboard. So I wonder if it is really just
a matter of the aeMB getting held up doing the I2C transaction. But
if this were the case, I’d think any I2C communication would cause
the freeze (such as changing the center frequency, which also happens
over I2C). And changing the center frequency works just fine on both
boards.

Hmm…may not be worth much investigating with UHD coming soon,
assuming this fixes this. I guess it’ll just be a head-scratcher for
now.

Thanks again…

Regards,
John O.
CEO/System Architect
Epiq Solutions

4

On Tue, Apr 13, 2010 at 14:09, John O. [email protected]
wrote:

Thanks for the insight Jonathon. I was doing some testing with our
BURX board as well, and got the same GUI freezing result. The gain
calculations for our board is trivial, so I wouldn’t think that it is
a matter of time being consumed doing these calculations. However,
both the DBSRX and the BURX board use an I2C interface to communicate
from the host to the daughterboard. So I wonder if it is really just
a matter of the aeMB getting held up doing the I2C transaction.

This may very well be the case as my recall is a little hazy (this was
a year or two ago that it came up.) It could be that there need to be
several I2C writes and it works if there is just one, but not if there
are several.

Anyway, there doesn’t seem much chance of a solution until the UHD comes
out.

Johnathan