Range-based for loops are available since C++11. Using them reduces
gr-osmosdr's dependence on Boost. Here I've done the replacement using a
global search-and-replace.
Signed-off-by: Eric Wild <ewild@sysmocom.de>
This change removes all usage of boost::mutex,
boost::mutex::scoped_lock, boost::unique_lock, and
boost::condition_variable. It also removes usage of boost::shared_ptr
and boost::weak_ptr outside of block definitions (which must continue to
use Boost until GNU Radio 3.9).
Signed-off-by: Eric Wild <ewild@sysmocom.de>
Squashed commit of rtucker-bladerf-hierarchy branch:
commit 35442da7d390919f6f9cbae3f69d6dc32ca595bb
through
commit 9026136cfdbc7116f55af18cb06d1731330fa13f
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.
Relies on some new libbladeRF API calls. Has been tested
with gqrx on new bladeRF hardware (as a source) but have
not yet tested sink, or existing bladeRF hardware.
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
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
tamer={internal,external_1pps,external}
The described method requires https://github.com/Nuand/bladeRF/releases/
tag/2016.01-rc1
Carefully *read the instructions for external reference locking*
(especially max allowed voltage levels) on Nuand's blog https://
www.nuand.com/blog/2016-01-rc1-release/
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
very wrong.
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.
Example:
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
inverted.
- 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
verbosity are:
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.
Common parameter handling has been moved into bladerf_common::init().
The buflen parameter is now in units of samples, not bytes. This
deviates from the other gr-osmosdr items. However, with the requirement
that buffers be in multiples of 1024 samples, this makes specifying this
parameter a bit easier. The user shouldn't need to know we're operating
on SC16Q12 values under the hood, and have to calculate accordingly.
To avoid confusion when both a bladeRF source and sink are in a flow
graph a [bladeRF source/sink] prefix has been added to output. Error
number have been replaced with bladeRF string representations of these
error values.
Firmware flashing has been removed. The bladeRF-cli or bladeRF-flash
tools are the preferred route for firmware upgrades.
The gr_complex FIFO is no longer used on the TX side, so it doesn't
really make sense to have it in bladerf_common. The associated items
have been moved into bladerf_source, and some renaming has been done in
bladerf_sink to tidy up.
Pending further performance tests of the bladerf_source, the _fifo
member (boost::circular_buffer) may need to be replaced.
This is based on the original work (https://github.com/Nuand/gr-osmosdr)
done by folks at nuand LLC for the gr3.6 branch of gr-osmosdr.
The following modifications have been done in this commit:
* port to gr-osmosdr master codebase (gr3.7)
* moved shared properties to bladerf_common
* added & verified IF filter bandwidth setters
* set LMS6002D registers with values taken from FAQ 5.27
* print device information (serial/versions) on startup
* added fpga= and fw= device arguments to program MCU/FPGA
* added bladerf=# dev. arg. to select a specific bladeRF
* grc gain field controls RF path VGA for RX/TX
* grc BB gain field controls BB path VGA for RX/TX
Usage example:
osmocom_fft -a "bladerf,fpga=/tmp/hostedx115.rbf"
The following RX named gain stages are available:
LNA: 0 to 6 dB, in 3dB steps
VGA1: 5 to 30 dB, in 1dB steps; nonlinear mapping done inside the lib
VGA2: 0 to 60 dB, in 3dB steps; not recommended to be used above 30dB
The following TX named gain stages are available:
VGA1: -35 to -4 dB, in 1dB steps, BB side
VGA2: 0 to 25 dB, in 1dB steps, RF side
Thanks a lot to the team of nuand LLC for this major contribution.
Clayton Smith
Clayton Smith
Dimitri Stolnikov