* This change is backwards compatible and checks for API support for step size.
* Created soapy_common.cc/h to house common gain range functions
* Moved factory mutex declaration to common source files as well
Switch to the newer API call which can provide a list of ranges.
There are feature detection ifdefs provided by the library
so that code will always correctly compile.
The soapysdr range type does not provide a step size,
however apps like the osmocom siggen use this size for a slider,
and a value of zero will cause a divide by zero error.
Although many ranges are not actually linear,
the idea to provide some default step to avoid crashes.
A future addition to the API may include providing a step.
When the special 0.0 bandwidth setting is used, set the filter bandwidth to rate * 0.75.
Passing automatic 0.0 bandwidth for some devices was problematic.
Patch provided by Martin Smith.
Last July there were several changes made to the Airspy firmware and
libairspy that added support for a new bit packing mode where 4 sets of
12 bit samples are packed into 3 sets of 16 bits for the transfer across
the USB bus ( https://i.imgur.com/qXnWoEK.png?1 ). 25% less data is
transferred across the bus and this is good for some computers with
cheap USB chipsets. There is an overhead of extra memory bandwidth
required on the host side to unpack the data into a useful format, so
for optimal performance bit packing is disabled by default.
The data is automatically unpacked within libairspy before being passed
along, so no changes are required anywhere else if packing is enabled
(or not enabled). Airspy firmware older than v1.0.0-rc6 does not have
the function, but that is detected and handled by libairspy.
I wrote the attached patch to enable packing in gr-osmosdr, which I
tested and it works. It is basically a clone of the bias=0|1 lines as
pack=0|1 and calls the needed libairspy function.
ref:
https://github.com/airspy/firmware/commit/7e1806bhttps://github.com/airspy/firmware/commit/5b7dcabhttps://github.com/airspy/host/commit/a51eccb
---
Do some Baseline test with Airspy command line tools to have something
to compare USB throughput results
--------------------------------------------------------------------------------------------------------
$ sudo mount -t debugfs none /sys/kernel/debug
$ sudo modprobe usbmon
$ wireshark -i usbmod3 &
$ airspy_info ; sleep 120 ; \
airspy_rx -t 4 -r /dev/null -n 2400000000 ; sleep 120 ; \
airspy_rx -t 4 -r /dev/null -p 1 -n 2400000000 ; sleep 120 ; \
airspy_info
Wireshark->Statistics->IO Graph
The Bytes/Tick are double the actual data rate because of way wireshark
collects the USB packets, I could have added a filter to fix this. But
the relationship is valid 25% less with packing enabled. The data rate
in the IO Grahp drops from 80MB/sec (in+out) [really 40MB/sec] to
60MB/second (in+out) [really 30MB/sec] from unpacked to packed.
10MSPS no packing, packing https://i.imgur.com/pA9LPdE.png?1
2.5MSPS no packing, packing https://i.imgur.com/lA8q5aq.png?1
Verification test with my patched gr-osmosdr
--------------------------------------------
$ sudo mount -t debugfs none /sys/kernel/debug
$ sudo modprobe usbmon
$ wireshark -i usbmod3 &
$ osmocom_fft -a "airspy=0" -s 10000000 --fft-rate=1
$ osmocom_fft -a "airspy=0,pack=1" -s 10000000 --fft-rate=1
$ osmocom_fft -a "airspy=0" -s 2500000 --fft-rate=1
$ osmocom_fft -a "airspy=0,pack=1" -s 2500000 --fft-rate=1
$ osmocom_fft -a "airspy=0" -s 2500000 --fft-rate=1
$ osmocom_fft -a "airspy=0,pack=0" -s 2500000 --fft-rate=1
I ran all of the above tests and the wireshark USB throughput graphs
showed exactly what was expected.
40MB/sec(10MSPS+normal),30MB/sec(10MSPS+packing),10MB/sec(2.5MSPS
+normal),7.5MB/sec(2.5MSPS+packing),10MB/sec(2.5MSPS+normal),10MB/
sec(2.5MSPS+normal).
25% less when packing was enabled and if you did not specify the
"pack=1", then no bit packing is performed by libairspy. All the
magnitudes within the FFT windows looked exactly the same as they do
without bit packing.
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/
use them with airspy,linearity (the default) or airspy,sensitivity
device arguments. Range is 0 to 21. Named gains still work as before.
Requires libairspy commit dc5cbca2f6f03458c40eab7c0f88fdfed60a08ff
This patch adds two gr-osmosdr blocks that can be used with the SDR transceiver
application available from the Red Pitaya application marketplace:
http://bazaar.redpitaya.com
These new source and sink blocks are based on the file block with some pieces
borrowed from the rtl_tcp block.
More details about Red Pitaya SDR transceiver can be found at:
http://pavel-demin.github.io/red-pitaya-notes/sdr-transceiver
Usage example:
osmocom_fft -a "redpitaya=192.168.1.100:1001"
Signed-off-by: Pavel Demin <pavel.demin@uclouvain.be>
This fixes a minor compile issue on VC11 and below
where source_impl.cc and sink_impl.cc use the float NAN define.
The patch simply defines the NAN macro conditionally,
in a common header (which seemed like the best place).
The automatic IQ balance mode is not supported,
but we should not throw when it is set to disabled.
Setting to disabled is techinically allowable,
and currently throwing is disruptive for users.
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.
... to support antenna/phantom power via a new device argument "bias"
(to match Airspy's existing bias power syntax). 0=disable and 1=enable.
I also added a device argument to control bias power at transmit time. I
named this option differently - "bias_tx" - to avoid accidentally
enabling bias power in transmit mode when an LNA may be attached in an
input amplifier configuration.
Original patch provided by Brad Hein
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.