Posted by & filed under bladeRF.

The 2015.02 release is available on GitHub.

This release mainly fixed up a few build/configuration items remaining after the 2015.01-rc2 update. Thanks go out to mambrus for his CLI help text generator fixes, and to everyone on IRC and the GitHub tracker for providing lots of helpful insight about reported issues. We love it when we see nicely organized and detailed bug reports, so some helpful bug reporting guidelines are provided here.

The Windows installer, its guide and the complete list of installers have been updated accordingly. Windows users will now find that they have the option of using either a Cypress CyUSB3 driver or a libusb-based driver. If you have any trouble with one, it’s definitely worth trying the other (and then keeping us in the loop via the issue tracker). The libbladeRF shipped with the installer supports both drivers.

Just to recap from an earlier blog post, a packaging guide has been added to the bladeRF repository to help out package maintainers. This explains some recommended configuration flags (e.g., -DVERSION_INFO_EXTRA="" -DVERSION_INFO_OVERRIDE=Package-version-here) as well as our versioning and tagging scheme.

If you’re hacking on the codebase, be sure to check out the patch submission guidelines and code conventions to help us expedite the process of getting changes merged upstream.

Admittedly this blog post is a bit belated, so be sure to check out latest developments on our GitHub page. There will be some upcoming fixes and changes for an RC1, either at the end of March or April. The gears are turning on catching up on more documentation and introducing some official examples, so hopefully within the next post or two we’ll have some more updates on that.

As always, all are welcome and encouraged to join us on the forums and the #bladeRF channel on Freenode. Thank you all for making this such an enjoyable project to work on!

Jon (jynik)

Posted by & filed under bladeRF.

A 2015.01-rc2 release candidate has been posted to GitHub.

This update includes a number of libbladeRF fixes and improvements, as well as a few minor bladeRF-cli fixes. Next week we’ll post an updated beta Windows installer and update the Ubuntu PPA.

Thanks to the efforts and suggestions by Cosmin from Null Team and YateBTS, the issue of devices requiring power-on-resets (on some USB 3.0 controllers) after an application exits without closing a bladeRF device handle has been resolved! To GNU Radio Companion users affected by this issue, this means the bladeRF should now happily re-open and continue to operate if you use the (red X) “Kill the flowgraph” button.

To aid those debugging applications which may suppress libbladeRF’s log output to stderr, mambrus provided patches to introduce syslog support to libbladeRF, as well as to control the default verbosity level via a BLADERF_LOG_LEVEL environment variable. As noted by the libbladeRF, syslog can be enabled at compile-time by passing DENABLE_LIBBLADERF_SYSLOG=ON to CMake. This functionaliy is not enabled by default, as to remain consistent with previous versions.

Some additional libbladeRF fixes have resolved some unintended attenuation in the bladeRF’s normal tuning range when using the XB-200 (i.e., with the XB-200 mixer in bypass mode). Another libbladeRF fix addresses some noticeable spectral images that could be observed prior to running any of the LMS6002D DC calibration routines.

While working on his Haskell bindings, victoredwardocallaghan identified and provided a fix for some bladeRF-cli documentation build issues on NixOS. Arch Linux users may have also experienced this when building the bladeRF-cli interactive help and manual page. Should anyone continue to see issues here, please let us know via the issue tracker.

As always, thank you to everyone on #bladeRF (Freenode), the Nuand forums, GitHub, etc., (and whomever I inevitably forgot to thank above) who has kindly offered suggestions/fixes, advice, and reported issues. It’s a huge help, and we really appreciate it!

– Jon (jynik)

Posted by & filed under bladeRF.

A 2014.12-rc1 release candidate has been posted to GitHub.

This update just ties up some loose ends pertaining to the Cypress driver backend (for Windows), and adds a couple libbladeRF API calls for identifying devices in bootloader mode and downloading firmware to them.

A corresponding beta Windows installer has been posted here and linked to from the installers page. This includes the option to use either the libusb (WinUSB) driver or CyUSB3 driver.

Have a wonderful and safe holiday season folks!

– Jon (jynik)

Posted by & filed under bladeRF.

The 2014.11 release has been posted to GitHub.

This release is intended to be a relatively stable point for package maintainers and application developers to base their work upon.

As noted on the aforementioned release page, some important fixes have been included:

  • libbladeRF now waits for SPI flash autoloading to complete when opening a device. This requires FX3 Firmware v1.8.0. If you’re using flash-based FPGA autoloading, you may be interested in trying out host-based FPGA autoloading.
  • FPGA v0.1.2 includes fixes in timestamp functionality.
  • An issue causing SPI flash corruption when using libusb with the WinUSB driver has been addressed. Some users encountered this with the 2014.11-RC3 installer and had to recover from the bootloader.

As denoted by the libbladeRF version bump to v1.0.0, the API is now being treated as “stable,” meaning that its users can operate under the assumption that no further reverse-incompatible changes will be made within the 1.x.x series. There are no plans to introduce any changes that would warrant a version bump to 2.x.x in forseeable future.

libbladeRF 1.0.0 API documentation has been uploaded to the Nuand website, and is linked from the Support page. This Support page link will be updated with each successive libbladeRF update, but older documentation will remain on the site for reference.

The Windows installer and its associated instructions have been updated. The Ubuntu PPA has also been updated, thanks to Ryan!

For those looking to contribute, a few helpful documents have been added to the source tree:

As always, thank you so much to everyone who has contributed bug reports, fixes, feedback, and suggestions. It is greatly appreciated!

– Jon (jynik)

Posted by & filed under bladeRF.


We have just released the 2014.11-rc3 release candidate, which introduces some new features and important fixes. The Windows installer and Ubuntu PPA will be updated over the course of the next week.

As the name implies, we pushed the official first release to the end of November because we felt that it was important to spend the extra time addressing some of the various issues that cropped up. While there are still some issues to investigate and resolve for the 2014.11 release, we are pleased with the results so far and hope you will be too! Below are some of the highlights. You can find more information at the release page on GitHub.

libbladeRF timestamp metadata support

One exciting update is the addition of timestamp metadata support in libbladeRF’s synchronous interface, via the added BLADERF_FORMAT_SC16_Q11_META format. When specifying this format to bladerf_sync_config(), you can now use the bladerf_sync_rx() and bladerf_sync_tx()in very much the same way that you have previously. However, with this format, you now may pass a pointer to a bladerf_metadata structure to:

  • Retrieve the timestamp associated with received samples.
  • Specify a timestamp at which you would like to receive samples. The bladerf_sync_rx() function will block until the desired timestamp has occurred, the specified timeout has elapsed, or an error has occured.
  • Detect RX overruns via the BLADERF_META_STATUS_OVERRUN bit in the bladerf_metadata.status field.
  • Transmit bursts of samples immediately or at the specified time. Zeros will be transmitted up to and after the burst.

Some example usages of these new features are included in the libbladeRF/doc/examples directory. Snippets from these examples are included in Synchronous data transmission and reception section of the Doxygen-generated API documentation. Additional information about the sample formats and the bladerf_metadata structure may be found here.

A huge thank you goes out to Ryan Tucker for developing, hosting, and maintaining the bladeRF Automatic Build-O-Matic, which kindly generates nightly builds of firmware, FPGA images, and the documentation linked above.

libbladeRF CyUSB3/CyAPI-based backend

A Windows-specific libbladeRF backend that sits atop the Cypress CyUSB3 driver and CyAPI DLL has been introduced. Initial results have shown that this performs very nicely, and it has been reported to work well on some systems/USB 3 controllers that were exhibiting issues with the libusb-based backend implementation.

As this is still a bit experimental, this support must be built from source, and requires the Cypress FX3 SDK. After installing the SDK and running a clean CMake configuration, the SDK location will be detected and support for this new libbladeRF backend will become enabled. When building support for this new backend, the necessary driver files are copied from the SDK into the bladeRF build’s output directory, for convenience.

Note that it is possible to have both the libusb and Cypress backends enabled in libbladeRF; this allows you to switch between them by replacing the driver associated with the bladeRF. In fact, you could have two devices operating simultaneously — one with the libusb backend, and another with the Cypress backend. For example, you could run an instance of the bladeRF-cli for each device:

> bladeRF-cli -p

  Backend:        libusb
  Serial:         xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  USB Bus:        3
  USB Address:    4

  Backend:        CyUSB driver
  Serial:         yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
  USB Bus:        0
  USB Address:    6

> bladeRF-cli -i -d "libusb:serial=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
bladeRF> info

  Serial #:                 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
  VCTCXO DAC calibration:   0x87e0
  FPGA size:                40 KLE
  FPGA loaded:              yes
  USB bus:                  3
  USB address:              4
  USB speed:                SuperSpeed
  Backend:                  libusb
  Instance:                 0

... In another console ...

> bladeRF-cli -i -d "cypress:serial=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy"
bladeRF> info

  Serial #:                 yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
  VCTCXO DAC calibration:   0x8da0
  FPGA size:                115 KLE
  FPGA loaded:              yes
  USB bus:                  0
  USB address:              6
  USB speed:                SuperSpeed
  Backend:                  CyUSB3 driver
  Instance:                 0

A better approach would be to specify the backend via the * wildcard, allowing libbladeRF to determine which backend is currently supporting the specified device: 

> bladeRF-cli -i -d '*:serial=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx'
> bladeRF-cli -i -d '*:serial=yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy'

For a programatic way to open a specific device via its serial number, with any available backend, see the example in bladerf_open_with_devinfo() documentation.

We would love to hear about your experiences and any issues with this new USB backend. Once we have done some more testing and have gotten some more reports on it, we will look to make this an option in the Windows installer!

DC calibration fixes

We are happy to report that a handful of fixes have addressed some of the DC calibration errors that have been reported.

Specifically, a timing fix in the FPGA resolved some corrupted SPI reads from the LMS6002D’s registers, which often manifested itself as LMS DC calibration registers reading back as all 31’s in the bladeRF-cli. This timing fix has also allowed the SPI clock to be increased to 40 MHz.

By expanding some parameter ranges in the bladeRF-cli’s TX DC calibration algorithm, the error that reported invalid “m01” and “m23” values has been addressed.

Lastly, a libbladeRF change now ensures that the LMS6002D DC calibration registers are properly written to the device, using values from the calibration tables. This should alleviate the need to run a ‘cal lms’ command, despite having DC calibration tables already auto-loaded.

Thread safety in libbladeRF

In libbladeRF v0.16.2 and earlier, users were responsible for ensuring that…

  • …device control functions (e.g., bladerf_set_frequency()) were performed on a device by only one thread at a time.
  • …device control functions were not made on a device from stream callback functions associated with that same device.

However, some users reported that these guidelines were inconvenient, so as of libbladeRF v0.17.0, functions have been made thread-safe where applicable. So if you have a device lock implemented in your code, you should be able to remove this as of libbladeRF v0.17.0. Developers: note that you can run the CMake configuration with -DCMAKE_BUILD_TYPE=Debug -DENABLE_LOCK_CHECKS=Yes to enable some deadlock checks in the libbladeRF and bladeRF-cli code.

Toward the 2014.11 release and Onward

Between now and the end of November 2014, our efforts are going to focus on resolving remaining bugs and developing/improving documentation. We are striving for the 2014.11 release to be a stable point in the codebase that application developers and package maintainers can target support for.

As such, new features an major changes will be scheduled for inclusion after this release. (We may stage such additions in a master-next branch, if there is need.) At this time, we have no further plans to introduce any backwards-incompatible API changes. If there is ever a need to do so, it will be after the 2014.11 release, and the major version number on the relevant component(s) will be incremented to denote this.

Once reaching a relatively stable point with the aforementioned release, we will be looking to focus efforts on some developing some fun and interesting projects and tutorials. Suggestions on this are always welcome; feel free to discuss desired topics on the forums or the #bladeRF channel on Freenode.


Thank you!

Being my first blog post, I just wanted to take the opportunity to thank everyone in the community for their contributions, support, feedback, comments, questions, and reporting of issues (which is very helpful). It has been really inspiring to see folks with a shared passion and enthusiasm for SDRs collaborate and exchange knowledge. I’m very thankful for the opportunity to be a part of this project, and am greatly looking forward to the journey ahead!

– Jon (jynik)