[Top][All Lists]
[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
- Re: [Discuss-gnuradio] Booting a new USRP, (continued)
- Re: [Discuss-gnuradio] Booting a new USRP, Rahul Dhar, 2005/02/11
- Re: [Discuss-gnuradio] Booting a new USRP, cfk, 2005/02/11
- Re: [Discuss-gnuradio] Booting a new USRP, Rahul Dhar, 2005/02/11
- [Discuss-gnuradio] usrp_oscope.py, cfk, 2005/02/11
- Re: [Discuss-gnuradio] usrp_oscope.py, Eric Blossom, 2005/02/11
- Re: [Discuss-gnuradio] Booting a new USRP, Eric Blossom, 2005/02/11
- Re: [Discuss-gnuradio] Booting a new USRP, John Gilmore, 2005/02/18
- Re: [Discuss-gnuradio] Booting a new USRP,
Eric Blossom <=
- Re: [Discuss-gnuradio] Booting a new USRP, John Gilmore, 2005/02/19
- Re: [Discuss-gnuradio] Booting a new USRP, Matt Ettus, 2005/02/19
- Re: [Discuss-gnuradio] Booting a new USRP, Eric Blossom, 2005/02/19
- Re: [Discuss-gnuradio] Booting a new USRP, Eric Blossom, 2005/02/11
Re: [Discuss-gnuradio] FC3 build problems, Chris, 2005/02/04