Adding separate default gain behaviors, ifgr-only and legacy.

[luarvique]

Added two default gain (setGain() with no name) behaviors: IFGR-only and default (aka legacy). These can be switched with the initial "gain_behavior" parameter, set to "ifgr" for IFGR_only gain behavior.

It is worth noting that the default setGain() behavior in Soapy is incorrect w.r.t. SDRPlay device gains, so it is not really worth keeping around, other than to please people who do not own or use SDRPlay devices.

It is also worth noting that the proposed change allows for adding more gain behaviors, such as the new gain computation algorithm discussed in several issue threads.

[fventuri]

@luarvique - thanks for your suggestions.

I have been busy with my regular work lately, but hopefully this long weekend I should find some time to address this problem.

Franco

[luarvique]

So, I decided to check what RFGR setting really does on my MSI.SDR dongle (have a real RSPduo as well, but the dongle is part of an inexpensive OpenWebRX setup). Using NOAA weather broadcast at 162.475MHz, disabling AGC, and setting IFGR=-35dB:

RFGR=0 => SIGNAL=-7.6dB
RFGR=1 => SIGNAL=-26.1dB
RFGR=2 => SIGNAL=-20.7dB
RFGR=3 => SIGNAL=-45dB

Looks like RFGR bit0 adds ~-25dB reduction and bit1 adds ~20dB reduction. The MSI.SDR probably has more bits there, but since Soapy considers it an RSP1, it limits RFGR to two bits only.

In general though, the above example seems to indicate that it is not reasonable to treat RFGR value as a reasonable gain value, whatever convoluted tables and formulas you are trying to apply =( It makes way more sense to keep it a separate setting.

[jketterl]

In general though, the above example seems to indicate that it is not reasonable to treat RFGR value as a reasonable gain value, whatever convoluted tables and formulas you are trying to apply =( It makes way more sense to keep it a separate setting.

If that's the case, there should be a few other things happening.

• The setting should be renamed (if it cannot be treated as a gain setting, it should not be called gain)
• Any control of the now RFGR setting should be removed from the gain APIs
• A proper documentation of how this new setting works and affects the expected outcome should be supplied to users

[luarvique]

Removing RFGR from the set of available gains may break compatibility with the existing software. As to the rest (renaming rfgain_sel and documenting its meaning), I have no objections to that.