discuss-gnuradio
[Top][All Lists]
Advanced

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

Re: [Discuss-gnuradio] Booting a new USRP


From: Eric Blossom
Subject: Re: [Discuss-gnuradio] Booting a new USRP
Date: Fri, 18 Feb 2005 13:20:24 -0800
User-agent: Mutt/1.5.6i

On Fri, Feb 18, 2005 at 02:49:21AM -0800, John Gilmore wrote:
> I have a USRP that seems to be working, though I haven't been able to
> really make it do any work yet.
> 
> I've created a wiki page, http://comsec.com/wiki?UsrpInstall .

> I'm trying to integrate the suggestions that have floated past on the
> mailing list, for how to unpack and check out and use a USRP when it
> arrives.

Thanks.

> 
> You said:
> > usrp_siggen.py is a siggen with no gui.
> > usrp_fft.py plots the FFT of whatever's connected to the input.
> > 
> > $ usrp_siggen.py --help
> > $ usrp_fft.py --help
> 
> ./usrp_fft.py --help  doesn't produce help.  It produces:


> usrp: found usrp rev2
> Traceback (most recent call last):
>   File "./usrp_fft.py", line 27, in ?
>     from gnuradio.wxgui import stdgui, fftsink
>   File "/usr/local/lib/python2.3/site-packages/gnuradio/wxgui/fftsink.py", 
> line 89, in ?
>     EVT_DATA_EVENT = wx.PyEventBinder (myDATA_EVENT, 0)
> AttributeError: 'module' object has no attribute 'PyEventBinder'

The import is failing before I can print the help.

> So, there's a bug in that it doesn't diagnose arguments that it doesn't
> recognize.  (Nor have a help message.)

It's in there, see below.

> I don't understand why it failed, either.  Did I fail to install some
> Python events package in the system?

I think this is because you're using a pre 2.5.2.7 version of
wxPython.

> Is our code perhaps using an obsolete interface that
> maybe doesn't work in my version of wxPython?

Our code is using latest standard interfaces.

>    http://www.wxpython.org/docs/api/wx.PyEventBinder-class.html
> 
> (I think wxPython is not really a package name, it's really called
> libwxgtk2* or something like that.  If so, I have version 2.4.2.6 and
> version 2.5.3.2 installed here.  I think it picks among those with the
> setting in /usr/lib/python2.3/site-packages/wx.pth which is currently
> set to: "wx-2.5.3-gtk2-unicode".  There's a whole mess of stuff under
> that directory, including both "wx" and "wxPython" subdirs.)

On Mandrake 10.1 it looks like this:

$ rpm -qa | grep -i wx
wxPython-common-gtk2-ansi-2.5.3.1-mdk101_py2.3
wxGTK2.5-2.5.1-5.3.101mdk
libwxgtk2.5_1-2.5.1-5.3.101mdk
wxPython2.5-devel-gtk2-ansi-2.5.3.1-mdk101_py2.3
wxPython2.5-gtk2-ansi-2.5.3.1-mdk101_py2.3

wx is the C++ widget library.  wxPython is the python wrapper.
There are various versions of wx depending on the underlying widget
set.  E.g., wxGTK2.5, wxGTK1.2


address@hidden usrp]$ ./usrp_fft.py --help
usrp: found usrp rev2
usage: usrp_fft.py [options]

options:
  -h, --help            show this help message and exit
  -dDECIM, --decim=DECIM
                        set fgpa decimation rate to DECIM
  -cFREQ, --ddc-freq=FREQ
                        set Rx DDC frequency to FREQ
  -mMUX, --mux=MUX      set fpga FR_RX_MUX register to MUX
  -gGAIN, --gain=GAIN   set Rx PGA gain in dB (default 0 dB)



There's a second problem caused by 

  from gnuradio import usrp

in the python code.  This import probes the USB trying to figure out
what kind of a usrp is out there.  If there's no USRP it fails.
I should probably just back out the check for the old usrp0's.  The
1's and 2's have the same high level interface.

>       John
> 
> PS: I wasn't able to run the super automated install, for various
> reasons.  I don't like sudo or root installs, so I added myself to the
> staff group, which can write to /usr/local.  But every attempted sudo
> in the script failed, so I ended up going into the directories and
> running ../buildit by hand, then running "make install".

Of course you can just edit ../buildit.py and remove the sudo.

Or the code could check for writability of the relevant subdirs of
prefix and then elide the sudo when possible...

> AND -- I couldn't build mc4020 since I don't have matching kernel
> source until I figure out how to generate it in Debian.  So it was a
> bit more manual than it's supposed to be, and maybe I didn't do
> something, which may have caused the error above.

If you're on a 2.6 system, you'll need the CVS version of mc4020, but
the 2.4 ought to work assuming it can find the kernel sources ;-)

Eric




reply via email to

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