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.
The "3.6" branch of the gnuradio block https://github.com/dl1ksv/gr-
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.
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.
usage examples:
osmocom_fft -a "rtl=0" -f 100e6 -s 2.4e6 -g 15
osmocom_siggen_gui -a "hackrf=0" -s 5e6 -f 100e6 --sine
osmocom_siggen_gui -a "hackrf=0" -s 5e6 -f 100e6 --sweep -x 2M -y 1 -c34
known issues:
- switching between siggen modes is broken at the moment (WIP) and has
to be made via cli switches only.
- filter bandwidth controls have no effect for TX (this has to be
investigated)
features:
- gain control for AMP & VGA
- frequency error correction
- automatic baseband filter
- up to 20M sampling rate
limitations:
- no DC offset correction implemented (yet)
- high sampling rates may not work on slow machines
the following TX named gain stages are available:
RF: MGA-81563, switchable 0 or 14dB
IF: MAX2837 VGA, 0 to 47dB in 1dB steps