Re: [Discuss-gnuradio] bladeRF and gnuradio?

[Ralph A. Schmid, dk5ras]

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.


> -----Original Message-----
> From: Brian Padalino [mailto:address@hidden
> Sent: Monday, September 09, 2013 6:38 PM
> 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