[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] python gnuradio module

From: Eric Blossom
Subject: Re: [Discuss-gnuradio] python gnuradio module
Date: Sat, 5 Feb 2005 20:26:53 -0800
User-agent: Mutt/1.5.6i

On Sat, Feb 05, 2005 at 05:39:08PM -0800, cfk wrote:
> On Saturday 05 February 2005 16:00, cfk wrote:
> > Gentlemen:
> >
> > I'm a bit new to python and am trying to run a couple of gnuradio python
> > programs. Even though I have done a make and make install with
> > gnuradio-core, I cant import the module gnuradio that python requires.
> >
> > My second question relates to where python executables were installed from
> > gr-usrp-0.3. I can see qa_usrp.py in gr-usrp-0.3/src, along with usrp1.py
> > but I wonder if the make install step installs them *somewhere*.
> >
> I have a handle on the PYTHONPATH now after finding it in a README. It is now 
> set to /usr/local/lib/python2.3/site-packages and the gnuradio directory can 
> be found.
> This gets me back to the original usrp issue which is that although the 
> usrp_interface.ihx and usrp_fpga.rbf files are being loaded and I can control 
> LED1, I cannot yet run ./test_fusb.

Don't use test_fusb, try using test_usrp_standard_tx.

I've just noticed that test_usrp_standard_rx had some bit rot.  It's
now fixed in CVS and will be updated tomorrow when I release the new

[test_fusb was written to exercise the fast usb code prior to the FPGA
code being completely developed.  It no longer sets up a bunch of
stuff that the FPGA requires, and hence just hangs].

FYI, this is the test code I use:

  $ gnuradio-examples/python/usrp1/test_digital_loopback_lfsr.py

It configures the FPGA to loopback what's sent to it over the bus.
The code sends the output of a Linear Feedback Shift Register (pseudo
random number generator) across the bus and checks for good results
on the return.

If it's working, there's no output, except perhaps an underrun or two
at the start.

> This program errors out within usrp_prims.cc:usrp_open_interface. The routine 
> _usrp_hw_rev is returning 2 for the new usrp hardware. I originally thought I 
> was caught in a logic trap where the software might be looking for a hardware 
> rev of 1 instead of 2, but that doesnt seem to be the case.

What distribution are you using?

It's most likely a permission problem on one of the files under
/proc/bus/usb.  On Mandrake, they are in group usb.  Adding yourself
to group usb makes the problem go away.

address@hidden doc]$ ls -lR /proc/bus/usb/
total 0
dr-xr-xr-x  2 root root 0 Feb  3 12:58 001
dr-xr-xr-x  2 root root 0 Feb  3 12:58 002
dr-xr-xr-x  2 root root 0 Feb  3 12:58 003
dr-xr-xr-x  2 root root 0 Feb  3 12:58 004
-r--r--r--  1 root root 0 Feb  5 20:04 devices

total 0
-rw-rw----  1 eb usb 43 Feb  3 12:58 001

total 0
-rw-rw----  1 eb usb 43 Feb  3 12:58 001

total 0
-rw-rw----  1 eb usb 43 Feb  3 12:58 001

total 0
-rw-rw----  1 eb   usb  43 Feb  3 12:58 001
-rw-rw-r--  1 root usb 189 Feb  5 20:04 004     <= this is a USRP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]