Bug #5562


Gain level setting not applied by default on SDRplay devices

Added by AsciiWolf about 2 months ago. Updated 25 days ago.

Target version:
Start date:
Due date:
% Done:


Spec Reference:


When using SDRplay devices, gain (IFGR and RFGR) level seems to be set to a minimal gain when Gqrx, or other SDR software is started. The sliders are displayed with correct values in Gqrx, but I have to manually check and uncheck the "Hardware AGC" checkbox to make the values be actually applied.

DL2KCD found the root cause of this issue and made an one-line patch that fixes it. Here is a copy of his comment1:

I encounter the same with an SDRplay RSP2pro using gr-osmosdr from willcode. I analyzed the problem with gdb and found the following cause.

In gr-osmosdr/lib/, function bool source_impl::set_gain_mode( bool automatic, size_t chan ) does this:

        if ( _gain_mode[ chan ] != automatic ) {
          _gain_mode[ chan ] = automatic;

This is apparently the only place where _gain_mode is written. It is initially an empty map, and on the first call, the condition check accesses a map element before it is initialized. That returns 0, meaning no automatic gain. So if the "Hardware AGC" box is not checked on start, the function is called with automatic == 0, and then wrongly assumes that this has been already set. Unfortunately, the default inside the SDRplay specific routines is to have AGC enabled, causing an inconsistency. The manual gain settings are then overridden by the AGC.

By checking the AGC box before starting, the function gets called with a nonzero value in automatic, so _gain_mode[ chan ] gets properly initialized and the change is propagated to the SDRplay driver. Unchecking AGC again then works as expected.

That particular piece of code still exists in the upstream code of gr-osmosdr from osmocom, apparently also without proper initialization.

In theory, GQRX could work around this by emulating the check/uncheck of the AGC box in software, but it would be better if gr-osmosdr was fixed to correctly initialize _gain_mode or check if _gain_mode[ chan ] exists before reading it.

This change in gr-osmosdr/lib/ fixes it for me:

-        if ( _gain_mode[ chan ] != automatic ) {
+        if ( (_gain_mode.count(chan) == 0) || (_gain_mode[ chan ] != automatic) ) {


Actions #1

Updated by AsciiWolf about 2 months ago

I forgot to mention that I use the original gr-osmosdr from Osmocom, not the willcode fork. So, the issue is definitely also present in the upstream gr-osmosdr.

Actions #2

Updated by AsciiWolf about 1 month ago

The patch was already applied downstream in Fedora1 and works fine, no regressions were found.


Actions #3

Updated by laforge 25 days ago

  • Assignee set to steve-m

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)