I’m a first time poster who’s generally new to SDR as well as the
gnuradio
software. I’ve recently taken a course in communication networks and
wireless networks, and this summer I’m working on using a few USRP
boards to
implement my own CSMA/CA protocol. However, before I get into the meat
of
that project, I’ve got to make sure that all my board setups are
correct.
Forgive me, this is going to be a mouthful.
First things first - after visiting Dawei Shen’s tutorials at the
GNURadio
website, I found that some of the instructions there were inconsistent
with
the files I got in the package - specifically tutorial number 4. I’ve
installed the gnuradio package, and when reading the usrp tutorial, I’m
told
to make sure that I have a file called usrp_fpga_rev2.rbf in the
/usr/local/share/usrp/rev2/ directory. (Which reminds me, if it helps,
I’m
running Ubuntu Dapper Drake) However, in the usrp package that I
download
from the gnuradio download page, I don’t find that file, but instead I
find
two files called std_2rxhb_2tx.rbf and std_4rx_0tx.rbf. My first concern
is,
why don’t I find the files I was told I’d find?
My second concern still involves the 4th tutorial. I’m told to run
usrp_oscope.py in the gr-build/gnuradio-examples/python/usrp/ directory,
which I’m told will bring up an oscilloscope, which it does, so I’m
assuming
that’s okay. Then I’m told to run wfm_rcv_gui.py [some fm frequency],
which
will let me hear fm signals. This is where my problem starts. First off,
that file doesn’t exist. So I try a file with a similar name -
usrp_wfm_rcv_nogui.py -f 101.5. This gives me an assertion error, which
looks like this:
Using RX d’board A: Flex 2400 Rx
gr_fir_ccf: using SSE
gr_fir_fff: using SSE
Traceback (most recent call last):
File “./usrp_wfm_rcv_nogui.py”, line 149, in ?
fg = wfm_rx_graph()
File “./usrp_wfm_rcv_nogui.py”, line 105, in init
if not(self.set_freq(options.freq)):
File “./usrp_wfm_rcv_nogui.py”, line 125, in set_freq
r = self.u.tune(0, self.subdev, target_freq)
File “/usr/local/lib/python2.4/site-packages/gnuradio/usrp.py”, line
184,
in tune
return tune(self, chan, subdev, target_freq)
File “/usr/local/lib/python2.4/site-packages/gnuradio/usrp.py”, line
122,
in tune
ok, baseband_freq = subdev.set_freq(target_freq)
File “/usr/local/lib/python2.4/site-packages/gnuradio/db_flexrf.py”,
line
174, in set_freq
R, control, N, actual_freq = self._compute_regs(freq)
File “/usr/local/lib/python2.4/site-packages/gnuradio/db_flexrf.py”,
line
392, in _compute_regs
assert self.B_DIV >= self.A_DIV
AssertionError
My second concern is: why does the example file in the 4th tutorial not
exist, and what might be causing this assertion error?
GNURadio is under active development. Therefore, file names can change
and thus tutorials don’t reflect the latest changes until they are
updated. The two file syou found, std_2rxhb_2tx.rbf and
std_4rx_0tx.rbf, are two different versions for the USRP firmware. the
first one has two rx and to tx paths, the second one has 4 rx and no
tx.
When the oscilloscope run, did you see a change in the LED on your
USRP, i.e., did it first blink fast, and once the oscilloscope was
running it blinked slower? If, then everything is fine. If not, then
follow the installation instructions here: http://www.comsec.com/wiki?UsrpInstall
except that I think we are at rev4 for the firmware now, instead of
rev2.
The exception you get is probably because you have the wrong
daughterboard in your USRP. What is the configuration you are using?
On Sat, May 20, 2006 at 11:03:03AM -0700, Thomas S. wrote:
USRP, i.e., did it first blink fast, and once the oscilloscope was
running it blinked slower? If, then everything is fine. If not, then
follow the installation instructions here: http://www.comsec.com/wiki?UsrpInstall
except that I think we are at rev4 for the firmware now, instead of rev2.
The exception you get is probably because you have the wrong
daughterboard in your USRP. What is the configuration you are using?
Cheers,
Thomas
Thanks Thomas. Those are all good suggestions.
Michael,
The problem is twofold.
(1) You asked the 2.4 GHz daughterboard to attempt to tune to 101.5 Hz
usrp_wfm_rcv_nogui.py -f 101.5 # should really be -f 101.5M
(2) There’s a bug in the daughterboard code, that has it blow up
instead of just cleanly returning a failure code.
[Matt, can you please fix this when you return from Dayton? This
problem
may exist for all the RFX boards.]
Also, the tutorials (like most everything) were written by a
volunteer. The underlying code base has changed since they were
written. Perhaps Dawei or someone else can update them if they get a
chance.
Its checked in, but it won’t fix your problem. It will just make the
error more obvious.
Matt
On Mon, 2006-05-22 at 09:48 -0500, Michael F. wrote:
> std_4rx_0tx.rbf, are two different versions for the USRP
not, then
> Thomas
> usrp_wfm_rcv_nogui.py -f 101.5 # should really be -f
Also, the tutorials (like most everything) were written by a
How will I know when the daughterboard code has been updated?
Also, thanks to you and Thomas for your help so far. I’ve got the coding
background for this, but not the DSP background. I’m learning as I go,
but
as you can imagine, I have my struggles understanding. laughs
-Michael F.-
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.