Read More

2014.11-rc3 and Onward


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)