Wiki › SDR SA PRO

bladeRF 2.0 micro

In SDR SA PRO the bladeRF 2.0 micro (Nuand, FPGA chips xA4, xA5 and xA9) is a receiver for 70–6000 MHz with sample rates of 0.52–61.44 MS/s over USB 3. The app drives it through the vendor's library libbladeRF 2.6.0 and loads an FPGA image into the device by itself if the device has none. This page covers the driver and firmware, what the start window shows, the gain controls, losses counted from the device's timestamps, the sweep and how the app survives a USB stall. PRO

What works with a bladeRF 0.9.45

• Receive only, one channel.
• Tuner 70–6000 MHz — that is what the library says; it does not accept the 47 MHz of the maker's data sheet.
• Sample rate 0.52–61.44 MS/s — the limits the device names; the list on the panel has 14 rates from 2 to 61.44 MS/s (below). 12 bits. The app sets the filter bandwidth by itself — 0.8 of the rate, within 0.2–56 MHz.
• Gain as one number, −15…60 dB, or the AGC of the AD9361 chip.
• Everything that works with any IQ receiver: spectrum, waterfall, traces, detectors, sweep, the receiver and IQ recording.
• Levels are in dBFS, uncalibrated; the dBFS — UNCAL badge on the trust bar.

After connecting, the device sits at 2255 MHz with a sample rate of 10 MS/s and a manual gain of 30 dB. The device controls are not saved between launches.

Tested with the built app on an xA4 device with FX3 firmware 2.6.0 and FPGA 0.16.0, over USB 3, without an antenna. The figures on this page come from there. The library also opens the first bladeRF (x40 / x115), but the app has not been tested on it, and the package carries no FPGA images for it.

Library, FPGA image and firmware

• The library libbladeRF 2.6.0 (LGPL-2.1) is a separate file, bladeRF.dll, in the drivers-pro folder, and it can be replaced by another build of the same library. The app refuses an older library under the same name: version 2.6.0 changed the numbering of the stream formats.
• The FPGA image. Without one the device does not work. If its flash holds no image, the app loads the vendor's image 0.16.0 for the device's chip — hostedxA4.rbf, hostedxA5.rbf or hostedxA9.rbf from the drivers-pro folder — and says on the panel The FPGA image was loaded by the program (the device has none in flash). A device with an image in flash skips this step.
• Firmware. FX3 firmware 2.6.0 and FPGA image 0.16.0 are required — Nuand release 2025.10. The library refuses older ones, and the app shows the Could not open the source window with the reason The bladeRF firmware needs updating and the advice to update them with the vendor's tool bladeRF-cli (bladeRF-cli -f bladeRF_fw.img, then the FPGA image) and reconnect USB. The app itself writes no firmware.

Driver

The device needs a driver — the one from the Nuand installer for Windows, or WinUSB assigned with the Zadig tool (step by step — as for the HackRF, The WinUSB driver). The Nuand installer is not in the PRO package. The full sample rates need a USB 3 port; on USB 2 the device works, but see below.

Choosing it in the start window

In the Select a receiver window the bladeRF rows come after the app's own devices; below the list there is a hint about the device.

Without a valid key the rows are the same, but each ends with — an SDR SA PRO key is needed — see SDR SA PRO.

If the device could not be opened, the app shows the Could not open the source window with the reason and advice and returns to the list:

The “Source” group on the “Device” tab

The counters, Pause, Back to live and Reconnect are the same as for the HackRF One. Here is what the bladeRF has of its own:

Type

bladerf.

Instrument

The name with the chip, for example “bladeRF 2.0 micro xA4”, and the versions: “FX3 2.6.0 · FPGA 0.16.0 · libbladeRF 2.6.0”. At the bottom of the group — a description: device, sample rate and frequency.

Instrument sample rate

2, 2.5, 4, 5, 8, 10, 12.5, 16, 20, 25, 30.72, 40, 50 and 61.44 MS/s — within the limits the device names. A rate change restarts the stream: measured 1.0–1.4 s. If the device took a different rate than asked, the panel says The device cannot do … MS/s — … MS/s taken.

Gain

manual or device AGC — the AGC of the AD9361 chip itself. In manual mode levels are comparable between frames; under AGC the gain changes without your knowledge, which is no good for measurements.

Gain, dB

One number for the whole receive path, −15…60 dB: the chip itself splits it between its stages. The limits depend on frequency, and the app reads them again after every retune. The decibels follow the chip's table and are uncalibrated; what is shown is what the device took. Under AGC the slider is disabled.

Total gain

In manual mode — the same number. Under AGC — the chip's AGC drives the gain — the number on the knob is not in effect.

The app does not switch on antenna power (bias tee), and there is no control for it.

Since 0.9.46 retuning is done by the NIOS in the device's FPGA — one command instead of about a hundred exchanges over USB 0.9.46. The first block after a retune is already at the new frequency: verified by the device's own spur at 806.4 MHz, 30 out of 30. The app discards samples taken before the moment of the retune by the device's clock. In 0.9.45 retuning was still done by the app from the computer and took 12–23 ms. With an FPGA image that has no NIOS mode (the first bladeRF) it stays that way.

Losses — from the device's timestamps

Every buffer of samples carries the device's timestamp — its own sample counter. If the next buffer's timestamp jumps beyond the end of the previous one, exactly that many samples did not arrive. So with a bladeRF, Lost in transit is a true count, not an estimate by the clock as with the HackRF or the Fobos SDR, and the gap in the spectrum sits exactly where the samples are missing.

• On the tested device: 10 and 30.72 MS/s — no losses; 61.44 MS/s — 0…0.05 % in probes of 3–5 s.
• A stall of the app itself — screen, recording — longer than 0.4 s at 10 MS/s or 0.07 s at 61.44 MS/s also loses samples, and they are counted.
• In the first four buffers after the stream starts, the library aligns its timestamps. Jumps there are marked as a gap but do not go into the loss counter.

Sweep

The device has no hardware sweep. The sweep is a software one: the app retunes the device for every segment, as with the RTL-SDR, and since 0.9.46 the retune itself is done by the NIOS in the FPGA.

• Measured in 0.9.46: 70–6000 MHz at 61.44 MS/s — 161 segments, a pass of about 3.5 s without USB stalls; with a stall recovery in the middle of a pass — up to 8 s. A sweep step takes 19–21 ms.
• In 0.9.45, with retuning from the computer, the same pass took 5.2–5.3 s.
• A USB stall in the middle of a sweep does not stop the sweep — below.

USB stall and automatic recovery 0.9.46

At the full rate the USB channel occasionally stalls. On the owner's device — roughly once per 14 minutes of streaming at 61.44 MS/s, and in a 70–6000 MHz sweep once every few passes. The cause — cable, port, USB 3 controller or firmware — has not been found. The app survives it by itself:

1. it closes the device and waits for it to reappear on the bus — up to 10 s;
2. it opens the same device by its serial number and restores all settings;
3. it brings the stream back up and repeats the retune — the sweep and reception carry on.

While this goes on, the panel shows USB stall (…) — restoring the connection…, and afterwards USB stall (…) — the connection was restored automatically, time …; a gap of ≈ … s in the data. The data have a gap at that place; it does not go into the transport loss counter.

The app gives up and shows the Device connection lost window, as before, if:

• there are more than three stalls a minute;
• the device did not come back within 10 s;
• the library crashed inside opening — then only Reconnect can follow.

After such a refusal the app reports the loss of connection on every read rather than staying silent. Exiting the app during a recovery works at once. Device silence — 3 s without data — does not count as a stall and is not recovered: that is also Device connection lost, and Reconnect helps.

On USB 2

On USB 2 the device opens and works but cannot deliver the full rate. The panel says The device is on USB 2: above ~10 MS/s samples will, by estimate, not arrive — watch the loss counter. On USB 2 the app limits the sweep rate to 10 MS/s. Both figures are estimates from the USB 2 throughput; nothing has been measured with the device on USB 2.

Limitations

• Receive only, and one channel.
• FX3 firmware 2.6.0 and FPGA image 0.16.0 are required; the app does not write firmware.
• The app does not switch on antenna power (bias tee).
• No hardware sweep — only a software one.
• The first bladeRF (x40 / x115) has not been tested, and the package has no FPGA images for it.
• Operation on USB 2 has not been measured.
• Levels are dBFS, uncalibrated; the gain decibels follow the chip's table.

The other PRO receivers are the ADALM-Pluto / Pluto+ and the Fobos SDR; for the key and the libraries in the package see SDR SA PRO.

The wiki describes version 0.9.49. Your app's version is shown in the Help menu, under About. Found a mistake? Write to us.