Incorrect implementation: SoapySDRPlay::getGain(const int direction, const size_t channel, const std::string &name)

[dl1bz]

This function is made for get the overall gain, but this is not what I get here.
The overall gain for the SDRPlay is:
RFGR in db (calculated and based with the Gain Reduction Tables from the SDRPlay API Specification) + IFGR = overall gain.

What you have here implemented instead is SoapySDRDevice_getGainElement(), but that's not the overall gain.

In other words, this function doesn't do what it's supposed to. But we need the "real" current Gain value in db through the whole chain.

https://github.com/pothosware/SoapySDR/blob/master/include/SoapySDR/Device.h

/*!
 * Get the overall value of the gain elements in a chain.
 * \param device a pointer to a device instance
 * \param direction the channel direction RX or TX
 * \param channel an available channel on the device
 * \return the value of the gain in dB
 */
SOAPY_SDR_API double SoapySDRDevice_getGain(const SoapySDRDevice *device, const int direction, const size_t channel);

If I use the function from the SOAPY_SDR_API, I get only as return value the RFGR step in the case of SDRPlay device, but never a "overall" value in db (means RFGR in db(!) + IFGR). But that's what I expect.

The question for me is, where is the issue ??? Here in the Soapy-SDRPlay-Modul or in the central Soapy-API or better in the SDRPlay modul implemenation inside of the Soapy-API ??!?

Note: I use the C-Wrapper, because my app is a pure C app which use the Soapy-API.

Heiko

[SDRplay]

Well that's odd, I wrote a long reply, pressed Comment and I could see it as a post, but now it's gone!

I won't go into gain vs gain reduction, but bottom line...

I think what you're asking for is a getGainReduction (as that's what the system works in) - if you want to implement a getGain, then you would need to store the params->gainParams.currGain when the GainChange event occurs in the event callback and return that.

Implementing a setGain is more difficult, but you could instead have setGainReductionElement and then take either IFGR (set only works when IFAGC is disabled) or RFGR (LNAstate) - then you could implement a getGainReductionElement as well.

You guys are best to sort out what works from an SoapySDR point of view and I'm happy to help with a branch to implement this, but it's possible that Franco has already tried this in the many branches he's created for people on this issue.

Best regards,

Andy

[fventuri]

Heiko,
welcome to the never ending discussion about SDRplay gains and gain reductions!

First of all, the title of this this issue (SoapySDRPlay::getGain(const int direction, const size_t channel, const std::string &name) ) has the parameter name at the end, while your quote from the documentation refers to SoapySDRDevice_getGain(const SoapySDRDevice *device, const int direction, const size_t channel) without the name parameter.

Personally I that the SoapySDRPlay module should implement only the functions getGain(..., name) and setGain(..., name) because they are not ambiguous as to what we are talking about.
I also think the functions getGain() and setGain() should not be implemented in that module or perhaps throw an exception if called (I think the SoapySDR specifications allow for that in case a driver is not able to implement a function).

Regarding Andy's suggestion, about three months ago I did implement a getGain(..., "CURRENT") that returns the value of gain.gainVals.curr in this branch: https://github.com/pothosware/SoapySDRPlay3/tree/get-current-gain
If there's interest, I can definitely merge that branch into master, since it is not going to interfere with the overall behavior of the SoapySDRPlay3 module (i.e. it is not going to break existing applications using the module).

73,
Franco K4VZ

[dl1bz]

Thank you guys for fast answers. Don't let us discuss gain vs. gain reduction, in the case of SDRPlay it's clear an attenuation and not a gain. Why "Gain Reduction" is used, don't know. It's simply Attenuation. But that's not important here. Let's just stick with "gain".

My problem was/is, I need from a SDRPlay RX the overall gain. Normally we can use SoapySDRDevice_getGain() for get an overall gain. If I use this function I get as return the RFGR value. In fact, RFGR is not a value in db, it's simply a step in the range 0..4 if RSP1 up to 0..27 if RSPdx. But getGain() is declared with a return value in db, which is not in this case. This breaks the API my opinion at this point.
Steps are not db, even if behind it an attenuation value, which depend from:

• selected step
• used SDRPlay model
• current used frequency or frequency range

The same for the getGainElement() if RFGR. That's only steps guys, NOT db values or a really numeric gain value ! But the API spec tells me so.
Of course I can determine the overall gain. I'll get IFGR, which come back in real db, I'll get RFGR as step, look in the Gain Reduction table and depend from the SDRPlay model und current frequency I found the correct value in db. Now I add IFGR in db and the real db value from RFGR and I have my overall gain or better overall attenuation.

And that's exactly what I expect when calling the SOAPY_SDR_API double SoapySDRDevice_getGain(const SoapySDRDevice *device, const int direction, const size_t channel);

I know, if using the Hardware-AGC, IFGR is set by automatic. But If I ask the value for IFGR if H-AGC on, I get the current value in db, which the automatic just selected. Of course, the value will be changed a few seconds later. But at the moment I ask I get it.

73,
Heiko, DL1BZ

[fventuri]

Heiko,
I just checked the source code for the module SoapySDRPlay3, and the only getGain() function I see implemented there has the signature double getGain(const int direction, const size_t channel, const std::string &name) const, i.e. it expects a name argument.

The getGain() function you are calling is probably implemented in the SoapySDR layer, and in this case I am not sure why it returns the value of RFGR (I would have perhaps expected IFGR since it is the first name returned by listGains()).

My personal recommendation is that instead you use getGain(..., "CURRENT") from the get-current-gain branch.

73,
Franco K4VZ

[dl1bz]

Franco,

double getGain(const int direction, const size_t channel, const std::string &name) const is mapped to SOAPY_SDR_API double SoapySDRDevice_getGainElement(const SoapySDRDevice *device, const int direction, const size_t channel, const char *name); this works, but it's also incorrect in the case of RFGR. The API spec says clear "return the value of the gain in dB", but RFGR isn't db.
For the RSP2 e.g. you get as return value 8.000 with a range 0.0000 to 8.000. The point is, that's not db. These are 8 steps for the LNA. Every step represent a attenuation value, which need a calculation from the Gain Reduction tables you can find in the SDRPlay API spec PDF. The resulted values depend

• model of SDRPlay
• selected frequency
• selected ant input

And the number of steps differ too at the same model if you change the frequency, e.g. with my RSP2 we have RFGR with 9 steps (0-8) only if ant 1 or 2 selected AND the frequency is 0-420 Mhz. Above 420 Mhz are only 5 steps active and the attenuation will be changed too through these 5 steps. That means, for get the real gain in db if RFGR you need to evaluate ALL of this conditions for RFGR and calculate this dependent on the Gain Reduction tables. Thats what I have done for test with only one model, my RSP2.
I use getGainElement for IFGR, there you get real db. Thats ok. For the real db of RFGR I read the current step and calculate the current value in db through the Gain Reduction table under consideration of current selected ant input and current frequency.
At the end you need add this two values and you will have the real overall gain. For support ALL SDRplay models that means, you need 37(!) gain tables for a correct calculation of RFGR. I certainly won't implement this in code.

The overall gain is needed to draw and scale correct values in the Panadapter and the waterfall of my SDR app and for the S-Meter value. These three parts need ever a recalulation if one of the gains IFGR and/or RFGR will be changed.
My only criticism is that in the case of RFGR no(!) real db values ​​are returned like declaration of the API, but simply the current step of the LNA. But a step is not db, means 0-8 is NOT 0db - 8db. Thats wrong. There are no workarounds that will help; as long as no real db value is returned, this function remains broken in the case of SDRPlay. This applies to both functions _getGain and _getGainElement in the case of RFGR. IFGR is ok. I order meat from the butcher and get cake :-)

Basically, these gain reduction tables have to be built into the SDRPlay module if the driver really only provides these steps and not real dB values. Only in this case the API can "get" real db values. So you have to do exactly what I have now implemented in my code as a test, for all models. Otherwise I can just use the driver API and do without Soapy. It may be that the LNA chip used can only be programmed this way (stepwise).

73 Heiko, DL1BZ

[SDRplay]

Just for clarification, adding the IFGR and RFGR (LNAstate converted to a dB value) values does not give you the overall system gain. The system gain is the maximum gain value for a given RSP and LO frequency combination minus those values. i.e. this is the value that is returned from the event callback. So, if you want to return the actual calibrated system gain value from getGain then you should use the get-current-gain branch as Franco suggested.

Best regards,

Andy

[dl1bz]

Ok, for my understand:
With this branch get-current-gain - if I use CURRENT as third element - I get the real "overall" gain (or better gain reduction) in db over all infected parts in the chain ? Is this correct ?

Heiko

[SDRplay]

It will return the total calibrated system gain from the API

Best regards,

Andy

[dl1bz]

Ok, this works for the first for me. But we need a final solution for this.

In the SDR API itsef we call normally the function
SOAPY_SDR_API double SoapySDRDevice_getGain(const SoapySDRDevice *device, const int direction, const size_t channel), which works without name and represent the gain value what "CURRENT" returns.
For the patched function I need to use SOAPY_SDR_API double SoapySDRDevice_getGainElement(const SoapySDRDevice *device, const int direction, const size_t channel, const char *name), here I can use the name parameter.
That means, we need a final solution for SoapySDRDevice_getGain() in the Soapy API for get (in the case of SDRPlay) the correct gain value if using a SDRPlay device. Thats what other moduls do as far as I know. I know, that the counterpart SoapySDRDevice_setGain() cannot be used in the case of SDRPlay, because we need to set Gain Reduction for IFGR and RFGR, the last can only set in steps, but never in db.

So we have now only a "half" solution. What you think can be the final solution to break not the Soapy API itself, but taking into account with the patched solution "CURRENT" in addition of RFGR and IFGR ?

@SDRplay: Question: What is the real range for Gain (minimum and maximum) ?

Heiko

[fventuri]

Heiko,
I just created a new branch heiko just for you with all the changes you requested: https://github.com/pothosware/SoapySDRPlay3/tree/heiko

Franco

[dl1bz]

Many thanks Franco. We are on the right way. I see your last commits, but there are two functions they need your attention:

SOAPY_SDR_API SoapySDRRange SoapySDRDevice_getGainRange(const SoapySDRDevice *device, const int direction, const size_t channel);
SOAPY_SDR_API SoapySDRRange SoapySDRDevice_getGainElementRange(const SoapySDRDevice *device, const int direction, const size_t channel, const char *name);

in the case of using CURRENT.
That's why I ask @SDRplay "What is the real range for Gain (minimum and maximum) ?"

And please don't forget my second issue #97 :-)

73 Heiko

[SDRplay]

I don't have those numbers - you could probably write a script to collate them all if you want to...

bear in mind this is very crude because in reality one measurement per band doesn't model the filter shape, but if you want some ball park figures, you can probably use something like this...

1. disable IFAGC
2. set LO frequency to the centre of each RSP & band as listed in each product data sheet (not section 5 of the API specification because you can have the same RF attenuation for multiple bands but represent different system gain values)
3. set IFGR to 20 (assuming normal mode is in use, use 0 for extended mode) and LNAstate to 0
4. record currGain as max
5. set IFGR to 59 and LNAstate to the maximum state value allowed for the given RSP & band
6. record currGain as min
   that would then get you max and min gain for each RSP and band combination.

Our system works in gain reduction, sorry attenuation :-), from the maximum gain measured at various points across each band. So whilst we display the overall system gain, it isn't what you need to set. So you need to decide whether the functions should accept and return values that the system uses or you'll need to keep converting them on the fly or through tables.

btw you can also record lnaGRdB from the event callback (same place where you get currGain from) which will convert the currently selected LNAstate into the gain reduction value in dB. You can also get gRdB there as well to return what the IFGR is in the case where IFAGC is enabled.

Best regards,

Andy

[dl1bz]

@SDRplay Maybe the answer is here https://www.sdrplay.com/docs/Default_Gain_Tables.pdf ?

My question was only: What is is minimum (I think 0) and what the possible maximum (I see 102db for HF/VHF/UHF and 85db Band 4+5/83db L-band). I meant the maximum values ​​that can be achieved.

73 Heiko

[SDRplay]

That document was made for the RSP1 - the RF gain has become way more sophisticated than that over the years. You can calculate the attenuation range from the tables in the API specification, but that's not the same as knowing what the total overall system gain range is - you would need to do what I suggested in the post above.

So it depends what you need I guess.

Best regards,

Andy