Are there any out here with experience in getting bladeRF being usable
with
gnuradio/grc? So far I followed the usual steps, bladerf and gr-osmosdr
compiled, but as documentation is being far from getting finished, I
only
reach the point of loading manually the FPGA image, nothing more
Furthermore, with the latest changes in code bladeRF even does not
compile
any more…
I know the forum, but I prefer mailing lists like this - maybe there
even is
some active bladeRF list?
On Mon, Sep 9, 2013 at 6:43 AM, Ralph A. Schmid, dk5ras [email protected] wrote:
Hi,
Are there any out here with experience in getting bladeRF being usable with
gnuradio/grc? So far I followed the usual steps, bladerf and gr-osmosdr
compiled, but as documentation is being far from getting finished, I only
reach the point of loading manually the FPGA image, nothing more
Furthermore, with the latest changes in code bladeRF even does not compile
any more…
There was a recent change which added a call to libusb_get_version()
which doesn’t exist in 1.0.9 of libusbx. So if you’re running that,
you should consider updating to a newer version. I know it exists in
1.0.12 and later. What version of libusbx are you using? Is it a
possibility to update? version 1.0.17 was recently released.
https://github.com/libusbx/libusbx
I know the forum, but I prefer mailing lists like this - maybe there even is
some active bladeRF list?
We’ve gone through some restructuring of the library and where it’s
installed to so if you’ve potentially got a stale version somewhere
you’re not expecting it to be, that might cause issues.
After moving to libusb instead of a straight kernel driver, the
current work to go on the driver right now is to interface with the
asynchronous stream instead of using the synchronous transmit and
receive interface. The kernel driver did a bit of pseudo asynchronous
shenanigans on the synchronous interface whereas the libusb
synchronous interface does not. This will limit the effective
samplerate, but we’re working on getting it resolved.
As for any other issues - anything specifically you’re seeing that is
an error and stopping the flowgraph?
Gave it a short try during lunch break - gnuradio wants to address
hackrf,
although I do not own this and in fact even did unselect hackrf in
gr-osmosdr cmake command.
Ralph.
1.0.12 and later. What version of libusbx are you using? Is it a
possibility to
update? version 1.0.17 was recently released.
https://github.com/libusbx/libusbx
I know the forum, but I prefer mailing lists like this - maybe there
even is some active bladeRF list?
We’ve gone through some restructuring of the library and where it’s
installed
to so if you’ve potentially got a stale version somewhere you’re not
expecting it to be, that might cause issues.
After moving to libusb instead of a straight kernel driver, the current
work to
go on the driver right now is to interface with the asynchronous stream
instead of using the synchronous transmit and receive interface. The
kernel
driver did a bit of pseudo asynchronous shenanigans on the synchronous
interface whereas the libusb synchronous interface does not. This will
limit
the effective samplerate, but we’re working on getting it resolved.
As for any other issues - anything specifically you’re seeing that is an
error
OK, got it. I had to remove all osmocom files and completely reinstall
gr-osmosdr, then I got rid of the hackRF, and the bladeRF was
recognized. RX
works fine, TX does work, but the modulation (plain FM) does not work,
have
to check with my USRP1 if this is a gnuradio or a bladeRF issue…
The TCXO needs some alignment before it could be used for OpenBTS; but
as
this is not yet supported, this is not very urgent for now.
Ralph.
Are there any out here with experience in getting bladeRF being usable
with gnuradio/grc? So far I followed the usual steps, bladerf and
gr-osmosdr compiled, but as documentation is being far from getting
finished, I only reach the point of loading manually the FPGA image,
nothing more Furthermore, with the latest changes in code bladeRF
even does not compile any more…
There was a recent change which added a call to libusb_get_version() which
doesn’t exist in 1.0.9 of libusbx. So if you’re running that, you should
consider
updating to a newer version. I know it exists in
1.0.12 and later. What version of libusbx are you using? Is it a
possibility to
update? version 1.0.17 was recently released.
https://github.com/libusbx/libusbx
I know the forum, but I prefer mailing lists like this - maybe there
even is some active bladeRF list?
We’ve gone through some restructuring of the library and where it’s
installed to
so if you’ve potentially got a stale version somewhere you’re not
expecting it to
be, that might cause issues.
After moving to libusb instead of a straight kernel driver, the current
work to go
on the driver right now is to interface with the asynchronous stream
instead of
using the synchronous transmit and receive interface. The kernel driver
did a bit
of pseudo asynchronous shenanigans on the synchronous interface whereas
the
libusb synchronous interface does not. This will limit the effective
samplerate,
but we’re working on getting it resolved.
As for any other issues - anything specifically you’re seeing that is an
error and
There was a recent change which added a call to libusb_get_version() which
doesn’t exist in 1.0.9 of libusbx. So if you’re running that, you should
consider
updating to a newer version. I know it exists in
1.0.12 and later. What version of libusbx are you using? Is it a
possibility to
update? version 1.0.17 was recently released.
https://github.com/libusbx/libusbx
Ah, OK, this one did the job Thanks!
After moving to libusb instead of a straight kernel driver, the current
work to go
on the driver right now is to interface with the asynchronous stream
instead of
using the synchronous transmit and receive interface. The kernel driver
did a bit
of pseudo asynchronous shenanigans on the synchronous interface whereas
the
libusb synchronous interface does not. This will limit the effective
samplerate,
but we’re working on getting it resolved.
As for any other issues - anything specifically you’re seeing that is an
error and
stopping the flowgraph?
To be honest, I even am not sure that I am doing things right, following
the
settings a guy posted in the forum. There the path to the fpga file is
entered as an option into the osmo block. My problem is, I am a radio
guy,
not a Linux guy - I know that the whole sw support is very beta and in a
growing process, but collecting small pieces of information from a
confusing
forum and not knowing if valid or outdated, this is not exactly the way
that
brings me to success
At the moment I can load the FPGA from the command line (and the LEDs
start
flashing then), but not out of grc. Of course there are errors, and I
can
repeat the procedure and post them, but at the moment I guess that I
simply
do some basic stuff totally wrong.
Brian
Ralph.
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
Thanks!