Project

General

Profile

Actions

Bug #5562

closed

Gain level setting not applied by default on SDRplay devices

Added by AsciiWolf almost 2 years ago. Updated 4 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Target version:
-
Start date:
05/13/2022
Due date:
% Done:

0%

Spec Reference:

Description

When using SDRplay devices, gain (IFGR and RFGR) level seems to be set to a minimal gain when Gqrx, Welle.io 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/source_impl.cc, 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/source_impl.cc fixes it for me:

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

[1] https://github.com/gqrx-sdr/gqrx/issues/979#issuecomment-1003528059

Actions #1

Updated by AsciiWolf almost 2 years 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 over 1 year ago

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

[1] https://src.fedoraproject.org/rpms/gr-osmosdr/c/01cd07aef4d2c20e3209cec1eb920837068fdfb1?branch=rawhide

Actions #3

Updated by laforge over 1 year ago

  • Assignee set to steve-m
Actions #4

Updated by AsciiWolf 10 months ago

It looks like this was still not fixed in upstream, only in Fedora. Any chance that the patch could be accepted in upstream? Thanks!

Actions #5

Updated by laforge 10 months ago

I'm sorry to see the lack of feedback / progress here. I'm not personally involved in this project. All the related developers are already in the list of watchers here, so there's not much else I can do to help, sorry.

Actions #6

Updated by AsciiWolf 4 months ago

laforge wrote in #note-5:

I'm sorry to see the lack of feedback / progress here. I'm not personally involved in this project. All the related developers are already in the list of watchers here, so there's not much else I can do to help, sorry.

Any update?

Actions #7

Updated by Hoernchen 4 months ago

  • Status changed from New to Resolved
  • Assignee changed from steve-m to Hoernchen
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)