Posted by & filed under bladeRF.


The long-awaited 2017.12-rc1 release is now available on GitHub! This release includes a stable version of Automatic Gain Control (AGC) for the bladeRF, as well as a new way of using a configuration file to quickly configure your bladeRF with your favorite settings. The software features are available for all bladeRF devices.

This remainder of this blog post dives into the internals of the bladeRF’s AGC.


The bladeRF’s RF front-end (pictured below) is composed of several RF switches, baluns, and the LMS6002D RF transceiver IC. The internal RX path of the LMS6002D has three gain stages: the low-noise amplifier (RXLNA), and two variable gain amplifiers (RXVGA1 and RXVGA2).



Amplification at the front-end will increase the peak-to-peak voltage of a signal picked up by an antenna to a level that allows for an analog-to-digital converter (ADC) to digitize it. Even a moderately strong RF signal that is received at -65 dBm is only 356 microvolts peak-to-peak (µVpp) when incident on a 50 Ω antenna. This voltage swing is far too low to be digitized by inexpensive ADCs used in consumer RF applications. Therefore, the signal must be amplified by several tens of dB to bring it up to a usable voltage swing. There is no industry standard, but in general, the internal ADCs used in RF applications need the analog baseband signal to enter the ADC at more than 280 mVpp.

As with most LNAs, the RXLNA of the LMS6002D offers a very modest gain (6 dB), but its primary design goal is to offer a low noise figure (NF), meaning it adds very little noise to the initial signal. The VGA stages following the LNA offer much higher gains (up to 30 dB!), but at the expense of higher noise figures. The gains are multiplicative, so the total system gain may be calculated by summing the dB gains of each of the 3 stages. On the other hand, calculating the total system noise figure requires a more complicated equation, known as Friis’ formula:

F_{total} = F_1+\frac{F_2-1}{G_1}+\frac{F_3-1}{G_1G_2}+\frac{F_4-1}{G_1G_2G_3}+{\ldots}+\frac{F_n-1}{G_1G_2{\ldots}G_{n-1}}

In Friis’ formula, Fn and Gn is the noise figure and gain at each stage n. By inspecting the equation, it quickly becomes apparent that the system’s total noise figure is most greatly impacted by the noise figure of the first element (F1), and somewhat less and less at each additional stage. This is why it is very important to choose an amplifier with a very low noise figure (specifically, an LNA) for the first stage, even if it only offers a modest signal gain. It follows from this equation, that to minimize the impact of noise on a signal received by the bladeRF, we must increase RXLNA first, followed by RXVGA1, and lastly RXVGA2 until the target gain is achieved.



This process can be visualized by looking at an incoming tone in a spectrum analyzer application such as gqrx. In the previous image, the central spike is the DC offset, and not an actual signal.The signal-to-noise ratio (SNR) can be thought of as the deflection of an incoming signal above the noise floor. This distance is commonly expressed in dB. Looking at an incoming tone in gqrx, the distance can be measured as the difference between the peak of the incoming signal and the noise floor. Amplifiers indiscriminately amplify both noise and signal, so amplifiers must be chosen in a way that maintains that relative distance (SNR) between the noise floor and the peak of a signal, while also amplifying very weak RF signals until they can be digitized by a reasonable ADC. The higher a component’s noise figure, the more it destroys the SNR by decreasing that distance.

The bladeRF’s RF front-end has a quadrature 12‑bit ADC, with an Effective Number of Bits (ENOB) of about 10 bits. At roughly 6 dB of static range per bit, the bladeRF has a static range of 60 dB. If, for example, the RX gains are adjusted in such a way that the bladeRF can receive a signal at +10 dBm without clipping, the least powerful signal it could possibly receive is ‑50 dBm. Alternatively, if the RX gains are configured in such a way that the bladeRF is barely sensitive enough to detect a ‑100 dBm signal, any signal that is stronger than ‑40 dBm will be clipped, as the digitized value would fall outside the signed, 12‑bit range of the ADC (±2047).

Usable RF signals “in the wild” generally have power levels between -120 dBm and +10 dBm at the receiver. This is a 130 dB range, yet the hardware can only cleanly receive 60 dB at a time! Receiving signals across that entire range, without missing weak signals or clipping strong ones, requires dynamically adjusting RX gains using an Automatic Gain Controller (AGC). These systems work by waiting in the highest gain setting, and quickly decreasing the system gain when a stronger signal is received. When the strong signal weakens or disappears, the AGC returns to a higher gain level, ensuring the system won’t miss weak signals.



The bladeRF’s AGC is consists of a power measurement block, a master controller, and a gain driver for the LMS6002D.

The power measurement block is a simple 2‑tap IIR of the incoming signal power (P = I^2 + Q^2).

The controller uses that filtered power level to decide whether to command a gain change. If the incoming power falls below a certain threshold, the controller commands a gain increase. Conversely, when the signal’s level rises above another threshold, the gain is decreased. These hand-picked thresholds are chosen to provide hysteresis for stability, as well as ample headroom for transient power increases. Since these values are very device‑specific, they must be empirically derived and tested for each new kind of RF front-end.

The gain driver has three states: the high-gain state (also known as the idle state), the mid-gain state, and the low-gain state. The code snippet in bladerf_agc_lms_drv.vhd, specifies the estimated signal level range for each gain state, along with the corresponding RXLNA, RXVGA1, and RXVGA2 settings. The states are tabulated below:

Gain state Incoming Signal Power Range RXLNA RXVGA1 RXVGA2
HIGH_GAIN -82 dBm to -52 dBm 6 dB (Max) 30 dB 15 dB
MID_GAIN -52 dBm to -30 dBm 3 dB (Mid) 30 dB 0 dB
LOW_GAIN -30 dBm to -17 dBm 3 dB (Mid) 12 dB 0 dB

Since the bladeRF’s AGC bases its decisions on the filtered history of the instantaneous power of samples (I^2 + Q^2), DC offsets must be compensated for, or eliminated altogether. An interesting thing to note about the bladeRF is that the inherent DC offset varies significantly with changes to frequency, bandwidth, or gain. Therefore, as soon as the AGC begins adjusting gain values away from the calibrated level, the bladeRF exhibits very strong DC offsets, until it returns to the original level. The SPI-based mechanism for controlling DC correction is far too slow to keep up with the fast attack of the AGC algorithm, making it impractical to rapidly adjust DC offset values when adjusting gains. Instead, the bladeRF’s AGC uses a lookup table to quickly subtract out DC offsets when the gains are adjusted away from the idle (high gain) state. These gain-specific DC offset values are now calculated by libbladeRF when a DC calibration table is generated.

To use the AGC, first ensure you have a new DC calibration table that includes AGC data. After upgrading libbladeRF and bladeRF-cli, a new DC calibration table should be generated following the Generating a DC offset table instructions on our Wiki. Also ensure that you’re using FPGA version 0.7.1 or later. Once the new DC calibration table is in place, run bladeRF-cli -i and enable the AGC by running set agc on.

Also new in 2017.12‑rc1: libbladeRF support for local and global configuration file! If the tool you are using doesn’t support setting certain bladeRF-specific options, they can now be set using a bladeRF.conf file. To enable the AGC this way, write the following line to a bladeRF.conf in your local or global bladeRF directory: agc on

The AGC can be see in action by capturing samples from a Vector Signal Generator using the bladeRF.



A VSG was configured to transmit a continuous wave signal at -70 dBm and -25 dBm with a 50% duty cycle over a 1ms period. The lower power signal was also configured to be at a slightly higher frequency. Baudline was used to zoom in on the rising edge of the signal coming from the VSG. The flatline (in the yellow circles) is an artifact caused by the VSG. Basically, the VSG disables its output when it adjusts its output power.

It is evident that when the bladeRF’s AGC is disabled, a strong incoming signal will cause the RF front-end to clip, and turn a sinusoidal wave into a square wave! The bottom capture shows the AGC very quickly latching on the new higher power signal (the short burst after the yellow circle).

Below is a longer capture of multiple rising and falling edges, with and without the AGC being enabled.


Lastly, the bladeRF was subjected to a power ramp from -100 dBm to -20 dBm at 3 dB steps. Without looking at the configuration panel, can you tell which capture was taken with the AGC enabled?



Posted by & filed under Events.

The Nuand team is headed to DEF CON 24.



Stop by our booth in the vendor area see a variety of demos and to purchase a bladeRF x40 or x115. We’ll have a number of additional accessories and other goodies available, including:

  • Cases
  • The XB-300 amplifier (2.4 GHz band)
  • 2.4 GHz antennas
  • Dual-band antennas (690-960/1710-2620 MHz)
  • Bootable USB 3.0 flash drives containing the GNU Radio Live SDR Environment
    • These provide a quick and easy way to get started with your new SDR!
    • The bladeRF 2016.06 release has been included on these drives.
  • T-Shirts (S, M, L, XL, 2XL, 3XL, 4XL)
  • Free stickers and magnets

Be sure to stop by during the first or second day of the con. The word on the street is that there will be some special DC24 discounts on the bladeRFs, so they might sell out quicker than last year! 😉

Posted by & filed under bladeRF.

The 2016.06 release is available on GitHub.

An updated Windows installer and installation guide (PDF) may be via the Nuand Support page.

Major additions in this release include…


libbladeRF API calls to configure the SMB clock port as an input or output

These API calls provide the ability to programmatically configure the use of the J62 SMB clock connection. This allows one device to supply its reference clock for other devices, which yields sampling using a common clock.

Previously, this functionality was only implemented in the bladeRF-cli via the mimo command. While still present, the mimo command has been superseded in the bladeRF-cli with the set smb_mode and print smb_mode commands, which utilize these added libbladeRF API functions. Running set smb_mode with no arguments will print the associated usage text.


Synchronization trigger support

Thanks to the excellent contributions of Jan Dohl, the FPGA and libbladeRF updates in this release introduce support for multi-device sampling synchronization. This section of the libbladeRF API describes this functionality, and a simple example of bladeRF-cli usage of this functionality is presented here.

This functionality operates by gating sample insertion into the FPGA’s RX and TX FIFOs, pending the delivery of a trigger signal on pin 4 of the J71 Mini Expansion header. One device is configured to output (“fire”) this trigger signal, while other connected devices receive this trigger. These triggers are handled per-module (i.e., RX, TX), meaning that a single device’s transmission and reception can be synchronized as well.

Once the trigger is “fired” on the master device, the samples are ungated and all devices should be synchronized within +/-1 sample. Although the devices will not be phase-coherent (due to the independent mixer PLLs), the phase offsets between each device should remain fixed.

This functionality should allow for some fun and interesting work. I’m personally excited to see this go to use in projects such as David Lonard’s 3 bladeRF Astronomical Interferometer, or perhaps a multi-device variant of Robert’s FFT stitching and frequency sweeping modifications to gqrx/gr-osmosdr used to achieve wider spectrum viewing.


XB-300 Support
This release includes libbladeRF and bladeRF-cli support for the XB-300. While this has been in the mainline code-base for some time now, Windows users can now easily leverage this functionality out-of-the-box from the latest Windows installer.

Some important notes…

As of FX3 firmware v2.0.0, the bladeRF will utilize the USB VID=2cf0 and PID=5246. This requires libbladeRF v1.16.0 or later. (This release includes libbladeRF v1.7.2.)

If you’re using third party software (e.g., SDR Console) that ships its own bladeRF.dll or a libbladeRF from your Linux distribution’s package repository and cannot detect the bladeRF, it may be the case that you’ve flashed v2.0.0 or later firmware, but are using an older libbladeRF version. If you ever find yourself in this situation, don’t fret! You can use the bootloader mode to flash firmware v1.9.1. For convenience, the latest Windows installer provides v2.0.0 and v1.9.1 firmware. It is recommended to select the v1.9.1 firmware if compatibility with older libbladeRF versions is required.


We’ve heard about and identified some CyUSB3 driver issues during transmit operations that we haven’t previously seen. We’ll be investigating this and hopefully following up with some fixes in a future release. If you’re currently using the CyUSB3 driver in Windows and experience timeouts or crashes during transmissions, it is recommended that you switch to the libusb (WinUSB) driver via the latest installer or Zadig.

Happy SDR-ing!
– Jon (jynik)

Posted by & filed under bladeRF.


6/22 Update: The coupon has changed to 30% off and been extended for one more day!

6/21 Update: Coupon now applies to 25 x115s as well!



Software defined radios are capable of a surprising number of things. After nearly a year of development, we have developed a method of increasing the bladeRF’s spectrum analysis bandwidth up to 124MHz. This software-only change takes advantage of the bladeRF’s advanced hardware design, and requires only a few additional changes to osmocom-sdr, and GQRX. With 96MHz it is possible to monitor the entirety of the 2.4GHz ISM band and not miss any Bluetooth or WiFi frames.

To celebrate this achievement and mark the beginning of summer, we are offering up to 50 bladeRF x40 for $199 for one day only. Use coupon code MHZ when checking out.

So how does this work? The bladeRF features a few HDL accelerators that allow it to calibrate and tune the underlying RF front-end several thousand times a second. By performing these tasks so quickly, the bladeRF can take in digitize and stitch together up to 200MHz of additional bandwidth.

How do I get this running? You will have to compile and use gr-osmosdr and GQRX from the Nuand branches, , and . 


To compile and run gr-osmosdr

$ cd ~/software/gnuradio-build/
$ git clone
$ cd ~/software/gnuradio-builds/gr-osmosdr
$ mkdir build
$ cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/opt/gnuradio- ../
$ make -j8 && sudo make install && sudo ldconfig

To compile and run GQRX

$ cd ~/software/gnuradio-build/
$ git clone
$ cd gqrx
$ mkdir build
$ cd build
$ cmake -DCMAKE_INSTALL_PREFIX=/opt/gnuradio- ../ 
$ make -j8 && sudo make install && sudo ldconfig


Monitor the entire 2.4GHz band with one radio.




NB: Screenshots showing 96MHz width represent a configured value below the maximum of 124MHz.

Posted by & filed under ADS-B, bladeRF.


Source release

Github repository :


We are releasing the source to a high performance hardware accelerated ADS-B decoder that is compatible with the bladeRF. The decoder, and all relevant VHDL, C, and MATLAB design files are available. The decoder has a range of >270miles, can resolve many bit errors, and correct for packet collisions; these features that have only been available in commercial decoders until now. The decoder runs on the FPGA instead of the CPU, meaning that even a Raspberry Pi is able to handle the decoder’s maximum performance. The decoder is compatible with the dump1090 visualizer, however it simply passes fully decoded hex packets to dump1090 for displaying flights.

Pre-built bitstreams can be downloaded from

The source code and documentation are being released in conjunction with a multi-part series that explains the applied DSP theory and FPGA implementation of the ADS-B decoder.

The decoder runs on any bladeRF including the bladeRF x40 and bladeRF x115. Any low noise amplifier works with the bladeRF, however there is a bladeRF specific LNA available, the XB-300.




This multi part article will describe the design decisions and implementation of a Software Defined Radio based receiver. The article will focus on ADS-B and Mode-S.


What are ADS-B and Mode-S?


ADS-B, or Automatic Dependent Surveillance – Broadcast, is a wireless protocol used by commercial and private aircraft to identify themselves and broadcast their location in realtime. ADS-B is the digital packet format that sits on top of Mode S, the RF standard ADS-B is broadcasted over.




Why accelerate modems in hardware (with VHDL)?


Hardware acceleration allows for efficient, real-time processing of signals. An FPGA implementation of an algorithm can be designed so that a pipelined design can process a sample per clock cycle. This is not to say that a sample can be processed within one clock cycle of it arriving but rather the pipelined architecture will compute one sample per clock cycle after the pipeline fills up.


Although FPGAs have slower clock rates than processors, FPGAs can massively parallelize tasks. For applied DSP tasks, an FPGA running at 80MHz routinely outperforms an Intel i7 running at 3.5GHz. These capabilities are similar to GPGPUs. A modern GPU running CUDA or OpenCL can outperform a processor at number crunching because of the large number of parallel arithmetic cores in a GPU. So why use an FPGA for applied DSP? One main reason is cost, even the most inexpensive desktop processor setup will cost at least $150, whereas FPGAs can achieve a comparable performance for a fifth of the price. Additionally, a single chip is much smaller, more low power and power efficient than a complicated GPGPU desktop setup. Although GPGPU solutions in the same price range as FPGAs contains far more on-chip arithmetic processing power than an FPGA, FPGAs do have an added advantage. FPGAs have very a flexible programmable logic fabric that allows for clock-cycle accurate control of the FPGA’s resources. An effective engineer can utilize that level of control to do more with an FPGA running at 80MHz than a GPGPU. In my experience, GPGPUs are better suited for applications where raw computation power is needed and considerations like data latency, processing latency, and power efficiency do not matter.


What design flow is recommended?


Our preferred design flow is to model and simulate in MATLAB, implement and validate the modem using fixed-point arithmetic in C, and ultimately use the C model as a reference to implement the modem in VHDL.


MATLAB is a great tool for prototyping ideas very quickly. A few lines of Matlab can easily capture the essence of an idea that could take hours to implement in C. The goal of the ASD-B core MATLAB script is to simulate the end to end performance of the ADS-B waveform and observe how the modem reacts to expected channel effects (such as fading), and receiver phenomenon (such as DC offsets, clipping, quantization).


It is in this stage of the design that the acquisition, equalization, and decoding algorithms are developed.


Many of the channel effects, and receiver phenomenon are random number processes which means the only way to get a good understanding for the modem’s performance is to simulate many packets with similar perturbations. Some parameters such SNR, and multipath require sweeping, for example sweeping SNR from -5 dB to 3dB with 0.25dB increments is a good idea when working with a waveform that necessitates 1dB of SNR. Simulations where the SNR is swept across such a range is usually referred to as a BER (Bit Error Rate) curve and is one of the fundamental ways of characterizing the performance of a receiver.


Once the receiver architecture is validated by good simulated BER and PER (Packet Error Rate) performance, it is time to implement the modem. Going to VHDL may seem appealing at this point however it is much more time efficient to implement the modem in C. The MATLAB model uses floating point arithmetic and most of the operations are performed on vectors whereas the final VHDL implementation will be a pipelined fixed point arithmetic implementation. There are far too many design decisions that need to be made and validated in going from MATLAB to VHDL, a good intermediary step is to implement the modem in C. C provides 64bit fixed point data types and arithmetic operations, complements of the underlying x86 processor, that perfectly emulate how the VHDL implementation will work. The C implementation will work as an easy to debug implementation and good reference point for how the VHDL should behave.


The final translation to VHDL from a fixed-point C implementation is not without challenges. The greatest challenge in implementing the modem in VHDL is, as almost always, meeting timing closure. Almost all additions can fit in one clock cycle. Some multiplications can fit in one clock system, others may not. And almost no divisions can happen in less than N/2 clock cycles (where N is the number of bits in the dividend). These simple heuristics can be used as a rule of thumb for designing the arithmetic pipelines but there will still likely be timing problems that will have to be resolved.


Stage Pros Cons Notes
MATLAB Very efficient way of prototyping algorithms Many existing DSP and Telecomm tools Not real-time Can use a lot of RAM and CPU time The receiver architecture and techniques should be known before progressing.
C Can be real-time Memory and CPU efficient Provides bit level accurate simulations with VHDL Memory management, file IO, and all signal processing functions have to be implemented The sample-based fixed point implementation should be designed here. The modem should be able to match the vector-based floating point MATLAB reference modem.
VHDL Very fast, efficient, and customizable Very hard to debug interactively Design is no longer entirely a digital design, some physical effects of silicon can cause the design to misbehave Design defensively against operations that might cause problems with timing closure


The next article will begin diving in to the MATLAB code.