Usrp

I believe I am at the point were I should be able to talk to the USRP,
but can’t.

We presently have the USRP with two BasicTX and BasicRX boards
installed.

We are running Fedora Core 5

We have installed GNU Radio per the instructions in the README as
closely as possible.

If I run the dial_tone.py example, I get the tones out of the
headphones.

If I run the usrp_siggen.py it requires an RF center frequency. I have
no idea how this should be entered (i.e., it is in Hertz, MHz, ???)

I tried

./usrp_siggen.py -f 10

What I got was nine copies of a “connection timed out” message and a
complaint about it not being able to load the FPGA bitstream.

The bitstream it was trying to load was:

/usr/local/share/usrp/rev4/std_2rxhb_2tx.rbf

I know that there is at least some communication going on with the
board, because when I power it up I get the green LED blinking at a
little over 3Hz. When I run the siggen program, the blinking stops (it
usually goes away, but once stayed on continuously). I have to cycle
power to get the blinking light back.

I get the exact same behavior when I try to run the
test_usrp_standard_tx in the */host/apps directory.

Any help would be appreciated.

On Mon, Sep 18, 2006 at 02:16:35PM -0600, Bahn William L Civ USAFA/DFCS
wrote:

I believe I am at the point were I should be able to talk to the USRP,
but can’t.

Sorry to hear that :wink:

If I run the usrp_siggen.py it requires an RF center frequency. I have
no idea how this should be entered (i.e., it is in Hertz, MHz, ???)

I tried

./usrp_siggen.py -f 10

That would be 10 Hz.

Everywhere a frequency is expected you can use a float followed
immediately by an SI suffix. E.g., -f 92.3M

What I got was nine copies of a “connection timed out” message and a
complaint about it not being able to load the FPGA bitstream.

Sounds like at USB problem, perhaps a bad cable.
Try another cable and ensure that the cable is properly seated on both
ends. If you’re using an external USB hub, perhaps in a monitor,
please try without the hub in the path.

The bitstream it was trying to load was:

/usr/local/share/usrp/rev4/std_2rxhb_2tx.rbf

That’s correct

I know that there is at least some communication going on with the
board, because when I power it up I get the green LED blinking at a
little over 3Hz. When I run the siggen program, the blinking stops (it
usually goes away, but once stayed on continuously). I have to cycle
power to get the blinking light back.

It should never stop blinking. When power is first applied, it
should blink at about 3 Hz. After any application is run (which loads
the “real firmware”), the LED should blink at approximately 1 Hz.

Eric

./usrp_siggen.py -f 10

That would be 10 Hz.

Everywhere a frequency is expected you can use a float followed
immediately by an SI suffix. E.g., -f 92.3M

Thanks.

What I got was nine copies of a “connection timed out” message and a
complaint about it not being able to load the FPGA bitstream.

Sounds like at USB problem, perhaps a bad cable.
Try another cable and ensure that the cable is properly seated on both
ends. If you’re using an external USB hub, perhaps in a monitor,
please try without the hub in the path.

We’ve only got the one cable - the one that came with the USRP. I can
try to scrounge another one. I’ve disconnected both ends several times
and have plugged it into each of the two USB ports directly on the
computer.

When I go through the first part of the steps on the following page:

http://comsec.com/wiki?UsrpInstall

All indications are that the USB is working and being recognized - to
the degree that I can properly interpret what I am seeing, anyway.

I know that there is at least some communication going on with the
board, because when I power it up I get the green LED blinking at a
little over 3Hz. When I run the siggen program, the blinking stops (it
usually goes away, but once stayed on continuously). I have to cycle
power to get the blinking light back.

It should never stop blinking. When power is first applied, it
should blink at about 3 Hz. After any application is run (which loads
the “real firmware”), the LED should blink at approximately 1 Hz.

Agreed. My point is that it’s not like the board is completely isolated
from the machine. There is some kind of activity that the program is
causing that the board is responding to.

I’ve been playing with the usrper program and anything that I try with
it says that the firmware is not configured. When I try to use the
load_firmware option is says the same thing.

Bill

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs