Table of Contents
What is the difference between the xA4 and xA9?
The bladeRF 2.0 micro comes in two variants the xA4 and the xA9. The xA4 variant is a 49KLE Altera FPGA that has about 30KLE free. The xA9 features the largest in class FPGA with a 301KLE Altera FPGA. The xA9 has about 290KLE free, making it ideal for accelerating modems in HDL.
How do I get more amplification?
The bladeRF 2.0 micro features bias-tee circuitry that allows the device to directly power amplifiers through the SMA ports. The BT-100 PA and BT-200 LNA are two wideband amplifiers designed specifically for the bladeRF 2.0 micro.
What OSs are supported?
The bladeRF 2.0 micro works with Windows, OS X, and a wide variety of Linux distributions (including Ubuntu, CentOS, Debian, Arch). To ensure the latest software support, consider compiling from source by following step by step instructions here https://github.com/Nuand/bladeRF/wiki#bladeRF_software_buildinstallation
What is the best way to get started on Linux?
The most effective way of using and developing with Software Defined Radios on Linux is to use PyBOMBs. Instructions can be found on the bladeRF wiki — https://github.com/Nuand/bladeRF/wiki/Getting-Started%3A-Linux#Easy_installation_PyBOMBS
What development environments are supported?
As of version 2.0.0, libbladeRF ships with a lightweight C library, MATLAB and Simulink plugins, and Python bindings.
Does the bladeRF run in a Virtual Machine?
Yes, the bladeRF should work in a Virtual Machine (VM). However, XHCI emulation should be enabled to ensure the bladeRF communicates to the VM using SuperSpeed speeds. In some situations, performance may be impacted.
How is the bladeRF powered?
The bladeRF 2.0 micro draws its power from USB and most normal use cases fit entirely within the 4.5 Watt power budget of USB 3.0. The power consumption of the device can be monitored from bladeRF-cli by running `print hardware`. If more than 4.5 Watts of power consumption is anticipated, a PSU should be plugged in the bladeRF. The bladeRF 2.0 micro’s power circuitry will automatically select the best power supply.
How do I avoid having to manually load the FPGA every time?
libbladeRF will automatically load the corresponding RBF from ~/.config/Nuand/bladeRF/, ~/.Nuand/bladeRF/, and /etc/Nuand/bladeRF/ on Linux and OS X. The Windows directory is %APPDATA%/Nuand/bladeRF. RBFs can be downloaded from http://www.nuand.com/fpga_images/
How do I use the device from bladeRF-cli?
Only a small number of commands are necessary to operate the bladeRF from the command line. Frequency, bandwidth (baseband low pass filtering), sampling rate, gains, and a source or sink are all that is necessary to configure the device.
How do I set gains?
libbladeRF versions 2.0.0 and greater support multiple methods of setting gains. The first method is to individually address gain stages directly by name. For example, “set gain tx dsa 0” (for the bladeRF 2.0) and “set txvga1 -6” (for the bladeRF 1.0) The other method is to set an overall gain on the entire RF and allow libbladeRF to pick the optimal settings. This can be done by calling “set gain rx ##” and “set gain tx ##”
How do I use a 10 MHz reference?
The bladeRF 2.0 micro has two ways to control its VCTCXO. The first, and default, is a 12‑bit onboard DAC. The second method is an onboard analog PLL. Let’s discuss the DAC first.
At the factory, the DAC output voltage is adjusted while the VCTCXO frequency is measured using a frequency counter. Over time and with changes in ambient conditions (e.g. morning shade and afternoon sunlight), this factory-calibrated DAC value may stop producing a sufficiently accurate clock frequency. The clock will remain accurate enough for most applications, but some applications have very strict clock accuracy requirements. This is when the analog PLL is useful for keeping the VCTCXO tuned.
The onboard analog PLL featured on the bladeRF 2.0 micro is used to lock the 38.4 MHz onboard VCTCXO to an external reference of nearly any frequency up to 300 MHz. The reference input is AC-coupled and internally biased to support either 3.3 V CMOS or sinusoidal reference inputs. We have the default reference frequency set to 10 MHz because it is a commonly used reference frequency in test equipment. Once locked to its reference, the PLL will send pulses to its charge pump output. The pulses are proportional to the difference in frequency and phase between the scaled versions of the reference input and VCTCXO output. The result is a mostly steady-state DC voltage that supplies the tune input of the VCTCXO to hold it at “exactly” 38.4 MHz and phase-locked to the 10 MHz reference input. The reference input must remain active at all times while using the analog PLL. In laboratory testing using a GPS Disciplined Oscillator, a 1 GHz carrier can be accurate to approximately 500 mHz (0.5 ppb).
To use the analog PLL, apply a reference clock to the REFIN (J95) U.FL connector located along the top right edge of the bladeRF 2.0 micro, then issue the following bladeRF-cli command:
bladeRF> set clock_ref enable
The command will return the locked status of the PLL. It may initially report unlocked, but subsequent status readings should report locked:
bladeRF> print clock_ref Clock reference: REFIN to ADF4002 (locked)
If using a non-default reference frequency, it may be changed after enabling the PLL. The following command shows how to set the reference frequency to 20 MHz:
bladeRF> set refin_freq 20M REFIN frequency: 20000000 Hz
How to receive an external 38.4 MHz baseband
The bladeRF-micro features a dual-input clock buffer that can select either the onboard VCTCXO, or an external 38.4 MHz clock to be fanned out to the various components on the board. The onboard VCTCXO is selected by default.
Certain applications (e.g. MIMO, RADAR, etc.) may require multiple bladeRFs to be synchronized using the exact same clock source so the frequency and phase differences between each board is as close to zero as possible. In these cases, the external clock input U.FL port, CLKIN (J93), may be used. The external input must be 38.4 MHz and 3.3 V CMOS logic.
It is important to note that the FX3 requires the clock to be within 150 ppm (5 kHz) of its ideal frequency of 38.4 MHz. While Nuand has been able to deviate by as much as 100 kHz before experiencing stability issues, it is recommended to stay as close to 38.4 MHz as possible due to temperature and process variations.
Using the bladeRF-cli, select the external clock input port:
bladeRF> set clock_sel external Clock input: External via CLKIN
To return to the onboard VCTCXO:
bladeRF> set clock_sel onboard Clock input: Onboard VCTCXO
To view the clock selection at any time:
bladeRF> print clock_sel Clock input: Onboard VCTCXO
How to output a 38.4 MHz reference?
One of the outputs of the bladeRF-micro clock buffer is connected to an external U.FL port, CLKOUT (U92). This may be used to supply a 38.4 MHz, 3.3 V CMOS clock to other devices. This output may be enabled or disabled using the bladeRF-cli:
bladeRF> set clock_out enable Clock output: Enabled via CLKOUT bladeRF> set clock_out disable Clock output: Disabled bladeRF> print clock_out Clock output: Disabled
How does automatic power source selection work?
More information is available on our wiki https://github.com/Nuand/bladeRF/wiki/bladeRF-Accessories#bladerf2-micro
How do I examine the hardware state of the bladeRF?
The print command of bladeRF-cli has been updated to include a hardware convenience parameter that groups what would otherwise be multiple status commands into a single command. Currently, only the bladeRF-micro has this hardware group, but it will eventually include the bladeRF Classic.
An example usage of this command is shown below for a bladeRF-micro.
bladeRF> print hardware Hardware status: RFIC status: Temperature: 19.3 °C CTRL_OUT: 0xf8 (0x035=0x00, 0x036=0xff) Power source: USB Bus Power monitor: 4.78 V, 0.6 A, 2.88 W RF switch config: TX1: RFIC 0x0 (TXA ) => SW 0x0 (OPEN ) TX2: RFIC 0x0 (TXA ) => SW 0x0 (OPEN ) RX1: RFIC 0x0 (A_BAL ) <= SW 0x0 (OPEN ) RX2: RFIC 0x0 (A_BAL ) <= SW 0x0 (OPEN )
Under RFIC status section, there is a temperature readout and a status of its CTRL_OUT pins. The RFIC used on the bladeRF-micro has an on-chip thermocouple allowing it to measure the die temperature. The CTRL_OUT pins are a set of eight real-time status outputs that can be configured to represent many different options, as dictated by the AD9361 RFIC’s register contents at addresses 0x035 and 0x036. To view the available options, review the AD9361 Reference Manual (UG-570).
The power source is reported by the onboard automatic power multiplexer. The device above was using USB power, but DC barrel power would be reported as such.
The bladeRF-micro also has a power sensor module that reports instantaneous voltage, current, and power on the main 5 V rail.
Finally, the print hardware command will report the RF switch configuration. The RFIC on the bladeRF-micro has two TX channels and two RX channels (2R2T MIMO). Each RX channel has three band selection options (A, B, and C); and each TX channel has two band selection options (A and B). An external RF switch is used to select which band is active on the SMA port.
How to detect when you flashed a 1.x firmware on a bladeRF 2.0? (Steps to fix firmware included)
While newer FX3 images (v2.2.0 and newer) will work on both bladeRF Classic and bladeRF2‑micro, it is possible to flash an older image onto a bladeRF2‑micro. These older firmware versions only know about the bladeRF Classic and simply report a USB device ID of 0x5246 to the host without first checking the underlying hardware. Newer firmware versions perform this check and report either 0x5246 for bladeRF Classic or 0x5250 for bladeRF2‑micro. Host software older than Git hash e5fb3e9 (8/21/2018) will fail to open the device and immediately fall back to the command shell:
$ ./bladeRF-cli -i [ERROR @ ../bladerf1.c:921] Invalid FPGA size 49. Failed to open device (first available): An unexpected error occurred $
This can be confirmed using the lsusb command and filtering for vendor ID 0x2cf0. If a bladeRF-micro is connected, and 2cf0:5246 shows up, then old firmware was flashed.
$ lsusb -d 2cf0: Bus 002 Device 008: ID 2cf0:5246
If the firmware is old enough (pre-v2.0.0), it is possible for the vendor ID to be reported as OpenMoko, 0x1d50.
$ lsusb -d 1d50: Bus 002 Device 008: ID 1d50:6066
To correct this, it is recommended to update to the latest host software, which will report a critical warning and allow the user to correct the issue (i.e. flash updated firmware), instead of reporting an error and terminating abruptly.
$ ./bladeRF-cli -i [CRITICAL @ .../bladerf1.c:889] Device type mismatch! FPGA size 49 is a bladeRF2 characteristic, but the USB PID indicates bladeRF1. Initialization cannot continue. [INFO @ .../bladerf1.c:892] You must download firmware v2.2.0 or later from https://www.nuand.com/fx3/ and flash it (bladeRF-cli -f /path/to/bladeRF_fw.img) before using this device. [WARNING @ .../bladerf1.c:904] Skipping further initialization... bladeRF> quit $ ./bladeRF-cli -f bladeRF_fw_v2.2.0.img <snip> Flashing firmware... <snip> Done. A power cycle is required for this to take effect. $ <power cycle> $ ./bladeRF-cli -i -l hostedxA4-latest.rbf Deferring device init until after FPGA load Loading fpga... Done. bladeRF> version bladeRF-cli version: 1.6.0-git-df07dd94 libbladeRF version: 2.0.0-git-df07dd94 Firmware version: 2.2.0-git-3d38fac2 FPGA version: 0.7.3 bladeRF> quit
If updating the host software is not possible, the only way to correct this is to force the FX3 into bootloader mode and update the firmware using the recovery procedure on the bladeRF GitHub Wiki: https://github.com/Nuand/bladeRF/wiki/Upgrading-bladeRF-FX3-Firmware#Upgrading_using_the_FX3_bootloader_Recovery_Method