Re: [Discuss-gnuradio] bladeRF and gnuradio?

[Ralph A. Schmid, dk5ras]

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.

> -----Original Message-----
> From: Brian Padalino [mailto:address@hidden
> Sent: Monday, 9 September, 2013 18:38
> To: Ralph A. Schmid, dk5ras
> Cc: GNURadio Discussion List
> Subject: Re: [Discuss-gnuradio] bladeRF and gnuradio?
> 
> On Mon, Sep 9, 2013 at 6:43 AM, Ralph A. Schmid, dk5ras <address@hidden>
> 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?
> 
> Brian