This addresses a defect introduced in 6e75abf which causes the
_consecutive_failures count to get reset with every failure, rather
then upon a successful return value.
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.
and /etc/gai.conf is not configured to prefer IPv4 hosts.
The current logic handling the output of getaddrinfo() is
flawed in that it only ever attempts to connect() to the
first address returned.
This is a problem for both round-robin and dual-stack hosts.
Furthermore, rtl_tcp_source_c::rtl_tcp_source_c() assumes a colon
in the device string is a port number. This prevents the use
of raw IPv6 addresses. The function will need to be taught how
to handle IPv6 addresses contained within square brackets, e.g.
"rtl_tcp=[2001:db8::1]:1234".
Therefore further work is required to improve the handling of
multiple addresses, and also device strings containing raw IPv6
addresses.
Signed-off-by: Jeremy Visser <jeremy@visser.name>
When size of output buffer was larger than size of input buffer,
uderflow occured because no check on number of avalilable data was done.
This also improves buffer filling for large output buffers, fill output
until anny input is available.
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).
cpu_format: sc8, sc16, fc32, fc64
otw_format: sc8, sc16
fullscale: specifies the full-scale amplitude when using floats.
peak: specifies a fractional sample level to calculate scaling with the
sc8 wire format.
example:
osmocom_fft -a uhd,otw_format=sc8,fpga=usrp1_fpga_4rx.rbf -s 16M
since dc offset / iq imbalance is not implemented for recent USRPs this
might cause undesired behavior in GRC. As a workaround we do not pass
them to the caller but print them to the stderr.
B210 USRP appears as a 2-channel device by default. We prevent weird
application behavior by restricting the number of connected channels to
the value given via nchan= argument (1 by default).
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.
While the RXVGA2 gain can technically go up to 60 dB, the LMS6002D
datasheet recommends it be clamped to 30dB. libbladeRF clamps to a max
of 30dB, so there's no use in setting max to 60 dB here.
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
folowing rtl-sdr commit 89f73b183f2dac9c0dd75beca4cf2f77f20c4a36
So far we had 32 * 256KB which was a bit overkill, 15 are more than
enough.
15 was chosen instead of 16 because at least on Linux there seems to be
a system-wide limit of 63 transfers (when they are 256KB large), so 4
dongles can be used on a single machine without lowering the default
transfer number.
Requires https://github.com/airspy/host
Usage example:
osmocom_fft -a airspy
The following named gain stages are available:
LNA: 0 to 15, step 1
MIX: 0 to 15, step 1
IF: 0 to 15, step 1
At the moment the gains are not in dB but gain indices internal to R820t
tuner.
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.
Usage example:
osmocom_fft -a sdr-iq=/dev/ttyUSB0
osmocom_fft -a sdr-ip=host[:port]
osmocom_fft -a netsdr=host[:port][,nchan=2]
The following named gain stages are available:
SDR-IQ: ATT: -20 to +10 dB, in 10dB steps
SDR-IP: ATT: -30 to 0 dB, in 10dB steps
The ftdi_sio driver is being used for SDR-IQ. It creates a character
device of the form:
crw-rw---- 1 root dialout 188, 0 Dec 19 22:14 /dev/ttyUSB0
To be able to open the device without root permissions add yourself to
the "dialout" group or do a "chmod 666 /dev/ttyUSB0" after pluggin in.
Several tests have shown that this is the
highest sample rate where no samples
are being dropped on rtl devices.
Signed-off-by: Steve Markgraf <steve@steve-m.de>
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.
- implements broadcast UDP based device discovery
- prints device information (serial/versions) on startup
- reads available frequency range(s) from the device
- integrity checks of IQ stream using sequence numbers
- automatic bandpass or a wideband lowpass selectable
The following named gain stages are available:
ATT: -30 to 0 dB, in 10dB steps
Known limitations:
- setting the sample rate is possible only before the
flowgraph has been started
Unfortunately libhackrf still doesn't offer a way to enumerate devices
*or* to open a specific device by index or it's serial number. Thus we
have implemented a rather hack-ish way to detect the presence of a
device by trying to open it and closing right after that.
Removed the use of an intermediate sample FIFO in the sink
implementation. Note the the FIFO has not been moved out of
bladerf_common --> bladerf_source_c in this commit.
work() now handles converting samples from complex to SC16_Q12, and filling
"transmit-ready" buffers. The callbacks are now only responsible for
marking the provided buffer free, and returning the next buffer.
It appears that a small deadlock issues remains in this changest, which
can be induced by:
1: Using a small sample rate (160Khz)
2: Switching back and forth between sinusoid <-> GSM burst
In this case, it appears that work() is blocked waiting for a buffer to
become free. More investigation here is required...
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.
received from Juha Vierinen:
A student here noticed that there is dc bias even with the rafael tuner.
We looked into this issue and found that using 127.4f instead of 127.5f
removes this bias. I assume this is associated with a bug in the digital
downconversion of the RTL chip. This change fixes the problem.
The gnuradio block https://github.com/dl1ksv/gr-fcdproplus must be
installed before building gr-osmosdr.
Available named gains:
Dongle Classic:
LNA: -5 to 30 dB, in 2.5 dB steps
MIX: 4 or 12 dB
Dongle Pro+:
LNA: 0 or 1, meaning off/on only. no information about real values.
MIX: 0 or 1, meaning off/on only. no information about real values.
BB: 0 to 59 dB, in 1 dB steps
This patch also introduces optional "device" and "type" arguments which
allow to override the values automatically picked by gr-osmosdr:
osmocom_fft -a "fcd,device=hw:2,type=2"
The "device" argument overrides the audio device used by the underlying
driver to access the dongle's IQ sample stream.
The "type" argument selects the dongle type, 1 for Classic, 2 for Pro+.
Thanks to Alexey Bazhin for the initial patch and Volker Schroer for
testing.
Dimitri Stolnikov
SDRplay
Steve Markgraf