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.
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
This allows a block to enable an associated driver to begin
transfering data just before we start to execute the scheduler.
The end result is that this reduces latency in the pipeline
when dealing with audio devices, usrps, etc.