By default, the bladeRF source and sink will expose 1 channel, unless
nchan is set, in which case it will expose either that number of
channels, or the number of channels supported by the device if lesser.
If nchan > 1 (after validation), MIMO mode is enabled.
Since firmware 2016.01-rc1 bladeRF has the ability to lock to an
external reference as well as produce arbitrary frequency signal
(25 MHz here) on its clock output.
Use gr-osmosdr source with the following arguments to produce 25
MHz on the SMB connector:
osmocom_fft -a bladerf,smb=25e6
To lock the bladeRF itself to an external GPSDO reference, use
additional arguments tamer=external for 10MHz or tamer=external_1pps for
1PPS GPSDO signals.
osmocom_fft -a bladerf,smb=25e6,tamer=external
The described method requires https://github.com/Nuand/bladeRF/releases/
Carefully *read the instructions for external reference locking*
(especially max allowed voltage levels) on Nuand's blog https://
The bladerf=X,[arguments] string now supports the following, where X is:
- The "device instance" which represents the Nth bladeRF connected.
This is 0-indexed, in the order displayed by `bladeRF-cli --probe`.
- The device's serial number.
For libbladeRF >= 1.4.1, a subset of the serial number is
supported. The subset must be at least the first three
characters of the serial number.
The backend specifier has been changed from "libusb" to the wildcard
("*"), allowing any available backend to be used.
When running with metadata mode enabled, the bladerf_sink supports 'tx_sob' and
'tx_eob' stream tags. Anything not in the burst will be dropped, and a warning
will be printed.
Use of the bladeRF metadata can be enabled via a 'enable_metadata'
device argument. If running full-duplex, this must be provided to both
the source and the sink. This does not currently any additional features
to the sink.
This change is intended to make the bladeRF source/sink implementations
slightly more resilient to any transient issues in a flow graph.
For poor choices of buffers/transfers or under high CPU load, an RX or
TX operation might time out. Instead of immediately reporting WORK_DONE
and bailing out, an error message is now printed and the device will
attempt to continue transmitting/receiving samples.
After 3 consecutive errors have occurred on an RX/TX operation, the
device will report WORK_DONE; in this situation, something is likely
This avoids inadvertently attempting to use a larger number of transfers
than the underlying USB library/interface allows by specifying a large
value for num_buffers.
Users can specify up to (num_buffers - 1) transfers. However, it is
generally recommended to use half as many transfers as buffers.
This commit adds support for the bladeRF XB-200 transverter expansion
board. To enable the expansion board and to allow the osmocom source or
sink to tune down to 0Hz, parameter xb200 has to be set. XB-200 comes
with 4 filter banks which can be selected by passing their name as
a value of the xb200 parameter. Automatic filter selection will be
enabled if no value is given to the xb200 parameter.
osmocom_fft -a bladerf,xb200
osmocom_fft -a bladerf,xb200=50M
The following values are valid:
"custom" : custom band
"50M" : 50MHz band
"144M" : 144MHz band
"222M" : 222MHz band
"auto3db" : Select fiterbank based on -3dB filter points
"auto" : Select filerbank based on -1dB filter points (default)
To alleviate some confusion (described below), the 'loopback' parameter
may now only be applied to a bladeRF source. A warning will be printed
if it is applied to a sink.
This is intended to help users avoid the case where two different
loopback options are applied to the same device. In this case, the
loopback setting on whichever initializes last will be applied. This,
coupled with the fact that not specifying a loopback defaults to
loopback=none, yields rather unintuitive behavior.
Setting the libbladeRF verbosity level needs to be performed prior to
other operations. Otherwise, the desired diagnostic output will not
appear for startup operations (e.g., device opening, enabling loopback).
A couple issues were present in bladerf_common::close, which caused
entries in the _devs list (our "device cache") to not be removed. This
would result in a stale device handle being used upon attempting to
reopen the device.
Two issues were associated with this bug:
- The weak_ptr expired() conditional was incorrect; the logic was
- The list item removal and iterator increment was done incorrectly
and would result in a crash after the first item was fixed.
The 'verbosity' parameter may be used to increase or suppress output from
libbladeRF. The available log levels are, in order of decreasing
verbose, debug, info, warning, critical, silent
The 'loopback' parameter may be used to put the bladeRF into one of the
supported loopback modes. The valid modes are listed below. Their
descriptions may be found in the libbladeRF documentation:
bb_txlpf_rxvga2, bb_txlpf_rxlpf bb_txvga1_rxvga2, bb_txvga1_rxlpf
rf_lna1, rf_lna2, rf_lna3
libbladeRF provides accessors for rational sample rates, which the
integer sample rate functions use under the hood. Therefore, there's no
need to check if the requested rate contains a fractional portion and
switch between the two sets of functions.