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>
This is a typo, some modules use the "CORR" string
in the setFrequency(dir, chan, name, value) API
to perform fine frequency adjustments.
Updated modules will use setFrequencyCorrection(),
this is support for backwards compatible implementations.
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.
* 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.