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.

Posted by & filed under Events.

Nuand will be at BSidesROC 2016

…and we’re looking forward to seeing you there on Saturday, April 23rd!

If you haven’t already signed up for the event, be sure to register.

Nuand will have a table set up running demos and offering bladeRF kits at a discount in celebration of our local Rochester hacker scene. Stop over and say, “hello!”

For those of you wishing to dive into the SDR deep end, Brian Padalino will be offering a training session on Friday, April 22nd.

Be sure to check out the schedule and other events at the con — there are some really awesome prizes and give-aways this year thanks to the wonderful sponsors!

Jon (jynik)