I’ve now had the E100 with WBX for about a week and I feel like I am
going around in circles!
I’ve run the UHD examples and the non-USRP examples because of course
the python examples have not caught up with UHD, the E100 itself works
fine.
I have now found some of the work on the list where people are porting
the examples to python/UHD.
When I try to run some of this example code I get the error message
“ImportError: cannot import name usrp”.
Is this because the board is not actually setup with the python links to
UHD when you get it?
Do I have to go through the whole p.i.t.a. process of recompiling UHD
and gnuradio on the E100 or are these available from some secret
repository so I can use opkg? Huge learning curve at present not helped
at all by the zero information that comes in the $2000 box!
Also, I know grc won’t fully run because there is no wxpython library on
the E100 but am I correct in assuming I should be able to still use grc
to compile my designs to python files and then run those results?
Sorry but I’m struggling with the whole finding the right forum or
complete (and CORRECT) answers to some basic questions on this sexy new
product (E100).
Any newbie pointers would be very much appreciated,
Hi
I am not familiar with the E100 but it sounds like it has a subset of
the GNURadio code which is ok because you don’t need it so just look for
the line at the top of the python file and remove “import usrp”.
You should be able to create code in GRC no problem it’s a great way to
start. Try just connecting UHD source to a gui fft block.
I am still new myself but I hope my limited experience get’s you
started.
When I try to run some of this example code I get the error message
“ImportError: cannot import name usrp”.
Is this because the board is not actually setup with the python links to
UHD when you get it?
The gr-uhd blocks + python and grc wrappers are all installed in the
image shipped with usrp-e100.
The app you ran was either written for the old usrp1 driver, or it had
imports/support for the old driver. If thats the case, you may get it to
work by commenting out the import gnuradio/usrp line.
Do I have to go through the whole p.i.t.a. process of recompiling UHD
and gnuradio on the E100 or are these available from some secret
repository so I can use opkg? Huge learning curve at present not helped
at all by the zero information that comes in the $2000 box!
You dont have to recompile. Many people do this to get the latest and
greatest gnuradio/uhd branches built. The opkg repos will always lag
behind by nature.
On compiling native: it may be slow but all the tools are there, and
same instructions apply as for x86. Its something you would want to let
run overnight (in the case of gnuradio).
Also, I know grc won’t fully run because there is no wxpython library on
the E100 but am I correct in assuming I should be able to still use grc
to compile my designs to python files and then run those results?
I believe that the wx did not cross compile correctly. But it can be
natively built. The gnuradio stuff that uses wx is all python anyhow.
If you don’t build the wx support, you can still use grc to generate
non-gui flow graphs, and use a host pc to view the data. And of course,
you can always do handwritten python or c++ apps w/ gnuradio.
FWIW, I am working on support for the qtgui sinks in grc. So qtgui
sinks, pyqt/pyqwt widgets. Qt is know to be a lot easier to build cross
so ive heard. And its good to have another option.
I have figured out how to change the GRC generated python files to not
refer to the wx libraries, only takes a couple of lines to be edited.
The result is that I can now create flowgraphs in grc on my development
vm, copy the python file to the USRP E100, edit the couple of lines and
my text based project works!
Glad to hear it!
The proof of the pudding is a WBFM receiver that I just fired up and a
couple of NBFM tx programs as well.
I did find a problem with the latest git gnuradio though, the UHD types
are missing a _t at the end eg.
io_type = uhd.io_type.COMPLEX_FLOAT32 is generated by GRC but
io_type = uhd.io_type_t.COMPLEX_FLOAT32 is what is required to work…
Ah, my attempt to simplify the python API. The issue is that the shipped
gnuradio does not handle this case without the _t. When we get updates
for the opkgs this should not not be an issue.
Just so you don’t think I gave up all disillusioned.
I have figured out how to change the GRC generated python files to not
refer to the wx libraries, only takes a couple of lines to be edited.
The result is that I can now create flowgraphs in grc on my development
vm, copy the python file to the USRP E100, edit the couple of lines and
my text based project works!
The proof of the pudding is a WBFM receiver that I just fired up and a
couple of NBFM tx programs as well.
I did find a problem with the latest git gnuradio though, the UHD types
are missing a _t at the end eg.
io_type = uhd.io_type.COMPLEX_FLOAT32 is generated by GRC but
io_type = uhd.io_type_t.COMPLEX_FLOAT32 is what is required to work…
Cheers,
Ingmar
Canberra, Australia
On 13/02/2011 1:26 PM, Ingmar M. wrote:
the examples to python/UHD.
helped at all by the zero information that comes in the $2000 box!