I am working on a USRPproject.Can you help me with a problem thatiam
stuck in for a long time.I googled the probem and found this
post:http://www.archivum.info/[email protected]/200807/msg00130.htmlI
have installed gnuaradio3.1.3 from the trunk on fedora 8 . I have tested
my gnuradio setup by checking the dailtone.py output I am unable to
check my USRP borad.It has two daughter boards,DBSRX and TVRX board.
When i run the usrposcope.py and the usrpwfm.py ,I get the following
error usrpprims.cc:244: internal error! 09a926bef43a11bd566940c764467e93
is dumped I have followed the wiki…Can you tell me whether i have to do
anything else to get the usrp running. Waititng for a
reply…RegardsMayurDear manicka! Get Yourself a cool, short @in.com
Email ID now!
I am working a USRP project andi am very new ti it,Can you help me with
a problem that I am stuck in for a long time.I googled the errorand
found this
post:http://www.archivum.info/[email protected]/200807/msg00130.htmlI
have installed gnuaradio3.1.3 from the trunk on fedora 8 . I have tested
my gnuradio setup by checking the dailtone.py output I am unable to
check my USRP borad.It has two daughter boards,DBSRX and TVRX board.
When i run the usrposcope.py and the usrpwfm.py ,I get the following
error usrpprims.cc:244: internal error! 09a926bef43a11bd566940c764467e93
is dumped I have followed the wiki…Can you tell me whether i have to do
anything else to get the usrp running. Waititng for a
reply…RegardsMayurDear manicka! Get Yourself a cool, short @in.com
Email ID now!
On Sun, Mar 15, 2009 at 9:08 AM, mayur sarode [email protected]
wrote:
I am working on a USRP project.Can you help me with a problem that iam stuck
in for a long time.usrp_prims.cc:244: internal error!
More information about your configuration would help, in particular
the version of libusb you have installed, but also, the usual OS, GNU
Radio version, and installation method.
The error results from getting an unexpected value from opening the
USB port via libusb. It may be caused by in incompatible version.
Johnathan
Johnathan C. wrote:
The error results from getting an unexpected value from opening the
USB port via libusb. It may be caused by in incompatible version.
I think he said this was a Fedora 8 box. My Fedora 8 box has
libusb-0.1.12.
On a related note, does anyone know why the usrp code has to look at
value obtained from the internals of libusb? With libusb-1, this value
is no longer accessible.
Philip
On Sun, Mar 15, 2009 at 11:03 AM, Philip B. [email protected]
wrote:
On a related note, does anyone know why the usrp code has to look at value
obtained from the internals of libusb? With libusb-1, this value is no
longer accessible.
We use libusb for housekeeping, but interact directly with the file
descriptor it creates (for performance reasons).
It’s something we’ll have to revisit soon as distributions move to
libusb-1.
Johnathan
On Mar 15, 2009, at 2:10 PM, Johnathan C. wrote:
It’s something we’ll have to revisit soon as distributions move to
libusb-1.
The USRP’s FUSB code for Darwin / OSX does the same thing with libsub
0.1.12: use LIBUSB for parsing currently available USB devices &
related housekeeping, and making use of LIBUSB’s internal structures
and variables to find information about the file descriptors but using
custom code to do the actual data I/O (again, for performance reasons:
libusb 0.1 series provides only synchronous data I/O on Darwin).
IIRC, the libusb 1.0 series currently works only on Linux but does
provide an API for extending to other platforms. This OS limitation,
obviously, makes it an issue for GNU Radio & other solidly cross-OS
projects.
That said, there is a “libusb-compat-0.1 compatibility layer” for
libusb 1.0 … anyone tested this out for various-OS usability?
Reading through the source code it looks like Linux-only.
< http://libusb.wiki.sourceforge.net/LibusbCompat0.1 > - MLD
On Sun, Mar 15, 2009 at 1:50 PM, Michael D. [email protected]
wrote:
That said, there is a “libusb-compat-0.1 compatibility layer” for libusb 1.0
… anyone tested this out for various-OS usability? Reading through the
source code it looks like Linux-only.< http://libusb.wiki.sourceforge.net/LibusbCompat0.1 > - MLD
From the Wiki however:
“As the compatibility layer implements the exact same ABI and API, no
modifications to existing libusb-0.1-based applications are needed.
You do not even have to recompile them. This compatibility layer is a
drop-in replacement.”
So for Linux, anyway, this sounds like good news for us. Needs testing
Johnathan
I have downloaded gnuradio3.1.3 fromsvn repository.I am installing on
fedora 8.My libusb version is 1.0.0 and libusbcompat0.1.0.which version
of libusb should i use?tRegards mayur> I am working on a USRP
project.Can you help me with a problem that iam stuck > in for a long
time. > > usrpprims.cc:244: internal error!More information about your
configuration would help, in particular the version of libusb you have
installed, but also, the usual OS, GNU Radio version, and installation
method.The error results from getting an unexpected value from opening
the USB port via libusb.It may be caused by in incompatible
version.Johnathan
On Sun, Mar 15, 2009 at 02:13:28PM -0700, Johnathan C. wrote:
“As the compatibility layer implements the exact same ABI and API, no
modifications to existing libusb-0.1-based applications are needed.
You do not even have to recompile them. This compatibility layer is a
drop-in replacement.”So for Linux, anyway, this sounds like good news for us. Needs testing
Johnathan
I might work, but we’ll still need to figure out how to fish out the
file descriptor (which is likely to be stored someplace else in the
data structure.) It would be some much nicer if they just provided an
interface to get it…
In answer to Philip’s Q, we fish out a file descriptor that we use
with a linux-specific ioctl, because libusb 0.1 did not provide a way to
submit and reap asynchronous bulk requests. Without doing it
asynchronously, we couldn’t achieve 32MB/s. I don’t know if there is
an interface for this in libusb-1.0. If there is, we should at least
consider using it. If not, we should find out the libusb-1.0 way to
fish out the file descriptor and carry on as we have been.
Eric
On Sun, Mar 15, 2009 at 9:07 PM, mayur sarode [email protected]
wrote:
I have downloaded gnuradio-3.1.3 from svn repository.I am installing on
fedora 8.My libusb version is -1.0.0 and libusb-compat-0.1.0.
which version of libusb should i use?
tRegards mayur
You will need to to use libusb-0.1. The ‘compatibility’ shim for
libusb-1.0 does not work, as you have found.
Johnathan
Eric B. wrote:
"As the compatibility layer implements the exact same ABI and API, no
data structure.) It would be some much nicer if they just provided an
interface to get it…In answer to Philip’s Q, we fish out a file descriptor that we use
with a linux-specific ioctl, because libusb 0.1 did not provide a way to
submit and reap asynchronous bulk requests. Without doing it
asynchronously, we couldn’t achieve 32MB/s. I don’t know if there is
an interface for this in libusb-1.0. If there is, we should at least
consider using it. If not, we should find out the libusb-1.0 way to
fish out the file descriptor and carry on as we have been.
I’m no expert at this stuff, but the story I head is libusb1 is
“faster”. libusb1 is advertised as having an asynchronous interface,
which libusb does not. So maybe there is a way to code libusrp to use
the libusb1 interface without directly accessing the file descriptor.
The other approach is to try to extract the file descriptor from
libusb-compat.
There is an interesting variable name at line 81:
I’m going to see if I can extract this and if it works.
Finally, it looks like you can omit libusb-compat and install
libusb-0.1.x with libusb1. I need to see about this also.
Philip
2009/3/16 Philip B. [email protected]
Philip
Hi, we are also coming across the same error of usrp_prims.cc: 244:
internal
error! when we try to interface with the USRP using the Angstrom
distribution of Linux. We were able to get GNU Radio 3.1.3 running on a
Gumstix OMAP3 board using the audio scripts (dial_tone.py, etc.) but get
the
error when running usrp_benchmark_usb.py.
Philip mentioned in a previous post that Angstrom can be built with
libusb-1.12 as a workaround so we can look into some sort of kernel
hacking
as well. But if there were a better approach than this it would be
useful.
Anyway, please let us know if there is an effective way to connect to
the
USRP with Angstrom (or other OS). Right now we are just trying to
establish
a connection and can look into improving performance later.
Thanks,
Dan
Eric B. wrote:
with >libusb1.
as well. But if there were a better approach than this it would be useful.No kernel hacking is required. libusb-* is a user space library.
There are some tricky dependencies in the OE build system that make
mixing libusb-0.12 and libusb-compat tricky. Making the switch is a
little easier todo now OE uses git.
My desk is a disaster at the moment. I need to fabricate a small board
organizer so I can get some work done.
Dan, can you build the latest from OE? I switched gnuradio recipe so it
builds from svn, with the fff fir filter converted to NEON (so it runs
faster). When you update OE, the packages directory is now called
recipes, so you will need to change BBFILES and BBPATH vars. I’ll see if
I can supply a patch to OE meta-data that uses libusb-0.12 again.
Longer term, I am hopeful I can work out how to find the required bits
from libusb-compat and eventually hope that the improvements in libusb1
resolve the performance issues.
Philip
On Thu, Mar 19, 2009 at 03:49:14PM -0400, Dan wrote:
with >libusb1.
Philip mentioned in a previous post that Angstrom can be built with
libusb-1.12 as a workaround so we can look into some sort of kernel hacking
as well. But if there were a better approach than this it would be useful.
No kernel hacking is required. libusb-* is a user space library.
Anyway, please let us know if there is an effective way to connect to the
USRP with Angstrom (or other OS). Right now we are just trying to establish
a connection and can look into improving performance later.
Try installing libusb-0.12
Eric
On Thu, Mar 19, 2009 at 06:18:53PM -0400, Philip B. wrote:
little easier todo now OE uses git.
Longer term, I am hopeful I can work out how to find the required bits
from libusb-compat and eventually hope that the improvements in libusb1
resolve the performance issues.Philip
One approach is to write a new fusb_* variant (fusb_libusb1?) that
uses the 1.0 API directly. We could select the appropriate variant at
configure time based on the version of the libusb library we find.
Of course, if the new libusb-1.0 API can’t sustain transmitting and
receiving at 32MB/s, then we’ll need to try something else.
Any volunteers out there who’d like to take a look at this?
Besides fusb_linux.{h,cc}, you’ll probably want to look at
the much simpler fusb_generic.{h,cc} for ideas.
Eric