How to reset USRP hardware via GNURadio

GNU Radio
1

I get strange results running my block. To resolve
this problem, I must unplug the DC power from the USRP
for 3 seconds and plug it back in. Is there a
GNURadio, C++, PYTHON command to reset the USRP
hardware so that I do not have to a hard power down
and up?

I probably get these issues since ctl-c does not work
to cancel the GNURadio python code and therefore I
must use ‘kill -9’ instead which probably causes the
issue described above.

Thanks,

George B.
[email protected]

2

On Thu, Apr 12, 2007 at 02:03:11PM -0700, George B. wrote:

issue described above.

Thanks,

George B.
[email protected]

Try two control-C’s

Eric

3

Eric,

I will try the 2 ctl-c method. Also, is there a
software reset command in GNURadio to recover from any
corruption? This can be a software initiated reboot
of the USRP or something similar.

Thanks,

— Eric B. [email protected] wrote:

and up?
George B.
[email protected]

Try two control-C’s

Eric

George B.
[email protected]

4

On Thu, Apr 12, 2007 at 06:07:01PM -0700, George B. wrote:

Eric,

I will try the 2 ctl-c method. Also, is there a
software reset command in GNURadio to recover from any
corruption? This can be a software initiated reboot
of the USRP or something similar.

Thanks,

We can’t get completely back to the power-on state from software,
because there is some h/w state in the AD9862’s that we can’t write
from s/w. When we open the USRP, we do rewrite all the registers that
we can get at, so that’s pretty close to a reset.

There is also a long standing bug where in some cases the first few
blocks of samples received from the USRP are semi-bogus. When the
problem shows up, it’s in the first 1024 complex samples. The problem
is in the FX2 firmware. Larry Doolittle tracked it down a year or
more ago for his UXO detector at LBNL, but the changes never made it
back into our code base.

Eric

5

Eric B. wrote:

On Thu, Apr 12, 2007 at 06:07:01PM -0700, George B. wrote:

Eric,

There is also a long standing bug where in some cases the first few
blocks of samples received from the USRP are semi-bogus. When the
problem shows up, it’s in the first 1024 complex samples. The problem
is in the FX2 firmware. Larry Doolittle tracked it down a year or
more ago for his UXO detector at LBNL, but the changes never made it
back into our code base.
I couldn’t find anything about this in the mailinglist archives.
Do you have a link?

greetings,
Martin

6

On Fri, Apr 13, 2007 at 05:11:52PM +0200, Martin D. wrote:

more ago for his UXO detector at LBNL, but the changes never made it
back into our code base.
I couldn’t find anything about this in the mailinglist archives.
Do you have a link?

greetings,
Martin

Eric

Hi Martin,

I didn’t find a link to the message, but here’s Larry’s revised code:
http://recycle.lbl.gov/~ldoolitt/xguff.html

His gadget uses a Spartan 3, but as I recall, the fix is in the
resetting of the buffers and/or in their initialization.

I think a basic diff should turn up the changes. We haven’t really
touched the FX2 code in a couple of years.

Eric