Re: [Discuss-gnuradio] Booting a new USRP

[John Gilmore]

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.

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'

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

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

The wxpython doc for PyEventBinder is totally useless, just like all
object-oriented class documentation (including gnuradio's).  It says
things like "Bind (self, target, ...).  Bind this set of event types
to target", without explaining what an event type is, what a target
is, or why or when you might want to do that.  But it does mention
some random stuff about "backward compatability with the old EVT_*
functions".  Is our code perhaps using an obsolete interface that
maybe doesn't work in my version of wxPython?

   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.)

        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".  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.