Posted by & filed under bladeRF.


A beta release of OpenBTS support is now available at ! Client phones can now associate, and use OpenBTS, there are still a few fixes in the works for USB2.0, RF power and filtering. We need a few more people to help us test our OpenBTS before we get ready for a stable release.

We encourage first time OpenBTS users to come join us in #bladeRF on FreeNode ( use as a web client ) as we prepare an installation guide. We are working on putting together an FAQ for OpenBTS so the more questions we receive, the better!


Hope everyone has a great weekend!

Posted by & filed under bladeRF.


During our Kickstarter campaign we received many requests to expand the bladeRF’s frequency range, so very early on we promised to delivered something that would do just that. Though the original delivery estimate for the transverter came and went with us not having more than a basic schematic, we received nothing but helpful feature requests and feedback from the community. It then became apparent to us what we had to do.  So in the same fashion that we delayed the bladeRF shipments to upgrade our shields, clocking architecture and FPGA size for the x15 backers, we hope to have made this wait equally worth it for everyone with the following transverter upgrades:

  1. Expanded frequency range. The initial specification called for a low frequency range of 10Mhz, the upgraded transverter now goes down to 60kHz. The RF switches provide an easy way of expanding the frequency range, not replacing it, meaning that the transverter board does not have to be unplugged to use the bladeRF’s original frequency range. RX can easily be at 1MHz, while TX is at 3GHz.
  2. The addition of selectable RF filter banks. The RX and TX paths each have a set of 3 filters, at the 49MHz-59MHz, 50MHz-54MHz (6 meter band), and 206-235MHz bands. There are also pairs of SMA connectors that will let users plug their own band filters into the RF path.
  3. Component selection. To achieve really high filter performance, all of the passives in the RF paths are high-Q, low-ESR, low-DCR, and at most 2% tolerant components.
  4. The LO synthesizer has been upgraded to an ADF4351 to improve the phase noise and total system SNR. The synthesizer also draws its reference from the 0.050ppm (50ppb) factory calibrated VCTCXO. The whole clock synthesis compartment is shielded by a thick aluminum RF shield.
  5. The addition of C API and HDL controlled GPIO pins. These GPIOs are fully configurable IO pins that allow for the transverter to control amplifiers, filters, antenna systems, LEDs, etc.

After the preproduction run of units we made in February, the mass production kick-off happened a few weeks ago in early March, so we will begin seeing a trickle of transverter boards later this month, with a very good chance of all orders being shipped out by April. To be certain the transverters arrive at the correct location we will ask everyone to confirm their mailing addresses before we ship out the transverters.

Lastly, we wish to thank everyone for being so patient and bearing with us. Based on your comments and suggestions we have developed a HAM solution we are truly proud of. We hope the drastic specification improvements make up for the delay in delivery. If you have any questions, concerns or feedback about anything please contact us directly at or Robert ( ) or Brian ( ).

Now that we are finally caught up on hardware development, the real fun can begin!

PS. We are still looking for more beta testers for our OpenBTS release candidate!

xb200_front   Front view: The blue passives are high-Q RF capictors and inductors xb200_side Side view: Large coils make for low DCR (thus high Q) inductors! xb200_in_use Warm up! xb200_back

Posted by & filed under bladeRF.


Now that calibration, and timed receives and writes seem to work, we are looking for volunteers to experiment with our OpenBTS support ( ) . The quick start guide on Github should be followed along with the official OpenBTS guide at

The bladeRF steps are as follow:

sudo apt-get install autoconf libtool libosip2-dev libortp-dev libusb-1.0-0-dev g++ sqlite3 libsqlite3-dev erlang libreadline6-dev libncurses5-dev
( cd a53/trunk ; sudo make install)
cd openbts/trunk/
./configure –with-bladeRF
make -j10
sudo mkdir /etc/OpenBTS
sudo sqlite3 -init ./apps/OpenBTS.example.sql /etc/OpenBTS/OpenBTS.db “.quit”
cd apps
ln -s ../Transceiver52M/transceiver transceiver
sudo ./OpenBTS


As always, we are available on FreeNode in #bladeRF or via email at

Posted by & filed under bladeRF.

  Thank you all for a great year of support, feedback, and interesting projects. With your encouragement and the passion we have see from the community, we see a very fun 2014 ahead of us. In the dev-uart_speedup branch ( ) you will see that we have been meticulously working on a couple of things:

  • Mitigating any remaining buffering, and spectral inversion issues some of you may be experiencing.

  • Increasing the baud rate of the UART bridge, which is the link that is used to communicate with the LMS and Si5338 through the Nios core. The new baud rate is 4Mbps, which is up from 115kbps so dumping registers on the CLI, changing channels and others configurations in UIs like GNURadio and OsmoSDR is now much faster.

  • Adding hardware accelerated IQ correction. This HDL based DSP coprocessor corrects for magnitude and phase imbalances right as the samples are captured. The core greatly lessens the computational load on small embedded devices that still want to operate in entirely embedded environments (be it a RaspberryPi or the onboard FX3) and still achieve great system SNR.

  • Acquiring parts for the mass production of the transverter boards. We have made some changes to the system performance that should greatly improve some of the RF characteristics of the expansion board. We will confirm these new specifications once we are sure that all new boards are capable of comfortably achieving them. If you have any questions or concerns about an order you placed that contained a HF/VHF transverter board please send an email to us at .

  • The OpenBTS branch ( adds timed RX and TX capabilities to bladeRF’s HDL through a metadata interface. The metadata packet format also allows for the development of drop-in HDL based modulators and encoders/decoders. More on this, and full instructions for OpenBTS in early January.


PS. We would like to thank Ben for adding bladeRF support to OpenLTE ( )!

Hope everyone has a happy new year!

Posted by & filed under bladeRF.


38.4MHz of RF bandwidth at 2.4GHz with SDR-Radio and bladeRF


We have added many new exciting features and improvements to bladeRF in the past couple of weeks. By upgrading to the latest FX3 image ( ) you can now store FPGA images on the SPI flash by running `bladeRF-cli -L hostedx40.rbf`. This will allow your bladeRF to read an FPGA image from flash and program the FPGA without the need of a host computer. Autoloading was used to get the UAV-SDR operational ( )!

Simon Brown of SDR-Radio fame has recently added bladeRF support to SDR-Radio v2.1 (which is still in beta). To download and try out SDR-Radio follow this link: . Scrolldown for a screenshot of SDR-Radio looking at 38.4MHz of bandwidth in the 2.4GHz band. A moderately active 802.11 device can be seen at 2.437GHz (which coincides perfectly 802.11 channel 6!). The narrower signals between 2.448GHz and 2.451GHz belong to Bluetooth devices.

Preliminary Matlab support with included instructions can be found at . We will update everyone as soon as a separate git repository is launched to address Matlab support for bladeRF! There is also preliminary support for bladeRF in PyBOMBS now at . A quick guide to using PyBOMBS can be found at , please ensure you clone our git repository when following those instructions.

Lastly, the HF/VHF transverter has undergone multiple architecture revisions, although they all seem to work we have felt like there might be room for a little more performance increase. We have taken into consideration many people’s requests and suggestions about the overall architecture of the transverter on IRC, the forums, and over email. We hope the proposed improvements we have come up with will be well worth the wait. We will present the semi-final block diagram and performance characteristics of the expansion board shortly.