Reconcile SDRPlay gains with SoapySDR abstractions

[dlaw]

Good morning and a happy new year to all!

This PR is an attempt to reconcile the unusual SDRPlay gains with the standard SoapySDR abstractions as cleanly as possible. It solves pothosware/SoapySDRPlay2#44. This is a port of pothosware/SoapySDRPlay2#61 to the new version 3 driver.

(The first commit is a solution to pothosware/SoapySDRPlay2#60; I also opened a separate PR #25 with just that commit.)

A brief summary of the changes:

1. SoapySDR and various SoapySDR clients expect that a larger gain results in more amplification. However, SDRPlay exposes a gain reduction, resulting in backwards controls and/or unstable AGC loops in generic SoapySDR clients. The solution is to define the gain to be equal to the negative of the gain reduction. For example, if a radio has an IF gain reduction range of 20 to 59 dB, this will now be exposed as an IF gain with a range of -20 to -59 dB.

2. A slightly thornier issue is that the "RF gain reduction" setting is not actually a gain setting in dB, but rather a mode selection for the front-end LNA. Semantically, it belongs in the settings and not in the gains. However, for the convenience of users who prefer to have the LNA setting available as a gain, a build option is provided. As with the IF gain, RF gain reduction values are negated so that larger values result in greater amplification.

I have built and tested this PR with the SDRPlay driver version 3.07 and an RSP1A on Debian Linux.

References:

1. Block diagram of RF and IF gains: SDRPlay application note
2. Actual dB losses caused by RF Gain setting: SDRPlay API documentation, section 5.3

[fventuri]

Thanks for pointing out the problems with the gains/attenuations @dlaw

A few months ago we had a possibly similar discussion with @SDRplay and @vsonnier (see here: cjcliffe/CubicSDR#825), where I ended up creating a branch new-gain-controls (https://github.com/pothosware/SoapySDRPlay3/tree/new-gain-controls) with the proposed changes.

I think that, in light of your observations, we should resume that discussion together to see what the others have to say.

This will also give me some time to complete the other changes related to #23 that I am currently working on.

Franco

[dlaw]

Thanks for the pointers! I was not aware of #10 and cjcliffe/CubicSDR#825. Obviously my proposal here is redundant with the work that has been done on the new-gain-controls branch.

I do have a few proposed tweaks to new-gain-controls. (For example, I would like to advocate that the new "IF" gain should range from -59 to -20 rather than from 0 to 29. In my opinion a negative gain value is a very sensible way to represent a gain reduction, and this provides the most direct correspondence between SoapySDR clients and the SDRPlay hardware documentation.)

Once that is done, perhaps we can open a pull request for new-gain-controls against master to provide a place for any further discussion. Even if we are not ready to merge it right away, opening the pull request makes it much easier to place comments on specific lines of code. It is sort of confusing to find the discussion of a branch of SoapySDRPlay3 development over in a CubicSDR issue ;-)

The other major difference between this PR and new-gain-controls is the handling of the LNA state aka RF gain. Mapping from LNA states to decibel gains is a nice solution (though extra work to implement!) and this is analagous to the way the HackRF amplifier is exposed as a gain which only takes values of 0 or 14 dB.

I will close this PR in favor of #27, which reconciles my proposed changes with new-gain-controls. Let's continue the discussion over in #27.

Cheers!
David