exposed access to linearity gain and sensitivity gain in libairspy

[ghost]

In reality both gains are just setting LNA, VGA and MIXER gains using a lookup table that has been optimised for either linearity or sensitivity. ref: https://github.com/airspy/airspyone_host/blob/master/libairspy/src/airspy.c#L117

If the LINEARITY and SENSITIVITY gain names are too long winded you can always trim them down to LIN and SEN, I'm not sure if I'm stepping outside of the standard, it is your code, I'm just exposing an underlying feature I'd like access to in libairspy while using your abstraction layer. Thanks.

[ghost]

I'm just after thinking that there may be a small gain synchronisation problem with this, which could be solved by additional code being added to libairspy and the firmware running on the Airspy.

https://github.com/airspy/airspyone_host/blob/master/libairspy/src/airspy_commands.h#L71

There is no way to query the device to find out what LNA, MIXER and VGA are currently. So if you did something screwy like set the LNA gain, and then proceeded to set the LINEARITY gain, and finally set the SENSITIVITY gain - all three internal gains in SoapyAirspy (lnaGain, linearityGain, sensitivityGain) would think their value was right but two would be wrong. One solution would be to add extra commands to the airspy firmware and libairspy for: airspy_get_lna_gain airspy_get_mixer_gain airspy_get_vga_gain Which could be called directly after airspy_set_linearity_gain and airspy_set_sensitivity_gain to keep internal variables within SoapyAirspy in sync with what they actually are.

I don't think it is a reason not to add the above patch, I'll post an enhancement request for this feature to the Airspy developers. ( EDIT: ref https://github.com/airspy/airspyone_host/issues/46 )

[guruofquality]

It seems useful to have those additional hooks in there, but keep in mind that the automatic behaviour of void SoapyAirspy::setGain(const int direction, const size_t channel, const double value) is to distribute a value in db to all of the elements listed in listGains.

I think this change needs to consider how void SoapyAirspy::setGain(const int direction, const size_t channel, const double value) could be better implemented to use these functions or how best to implement gain distribution otherwise. Since this pull might otherwise break this function.

[ghost]

Ok thanks, totally missed that, any suggestions.

I suppose at the end of the day all I want to do is to have easy access for people to LNA/VGA/MIXER gains and LINEARITY/SENSITIVITY gains (which modifies the previous three in two different optimal ways).

[guruofquality]

I don't know enough about this to answer properly. If you want to keep everything working as is, don't list the gains LINEARITY/SENSITIVITY is listGains and it will just be an additive change. Keep the setGain additions, thats pretty harmless in any case

If we want to keep LINEARITY/SENSITIVITY in the gains list, we need to reimplement setGain(direction, channel, value) variant. This can take two forms:

• set LNA/VGA/MIXER based on a single gain value in db just like its doing now, but implemented in SoapyAirspy because of the additional gains which arent really gain stages
• or, does setLinearity/setSensitivity do a better job of this? aka should the overload for setGain(direction, channel, value) just always call airspy_set_linearity_gain as a rule of thumb (for example)?

Finally, as an option, since these API calls arent really gain stages, we can put LINEARITY/SENSITIVITY calls into writeSettings and friends. Its probably not as fitting, but arbitrary settings can advertise themselves nicely in applications like cubicsdr. And technically, we can do both, an unnamed gain setting, and a named arbitrary setting.

Thats just a few options. I'm not an airspy user myself, so I will take any hints as to what works best with libairspy.

[ghost]

Thank You. I'm going to have to do some more reading (I'm more a C person than a C++, but I usually understand enough to submit a patch). I'll close this off read more code and think a bit more and come back with a new pull request.

I probably would choose linearity as the default for adjusting gains for the Airspy, it was created by the designer of the hardware.

I'll be back!

[guruofquality]

Just FYI, if you just want to get the functionality in for the time being without disturbing any of the existing setGain stuff, just remove the lines.

+    results.push_back("LINEARITY"); 
+    results.push_back("SENSITIVITY"); 

If that helps. And of course we can add more to that later if you figure something out.