Strange behavior with the IFGR gain control

[srs4511351]

Computer:
Raspberry Pi 4
Debian GNU/Linux 12 (bookworm)
SDRplay RSP1A

develop branch

IFGR initially uses an unknown default value when Run is pressed and doesn't reflect the Signal Source slider setting unless it is moved.
If you stop playback and start it again with the Run button, it goes back to the default value and moving the slider slightly restores the setting. RFGR seems to work correctly.
When pressing Run, [WARNING] Not updating IFGR gain because AGC is enabled is displayed in the terminal. Hardware AGC is not checked.
I think that either there should be a button to enable/disable AGC or IFGR shouldn't have any effect when AGC is enabled. In either case, AGC is apparent on the SSB signal wherever IFGR is set.
With the default value, the display only shows stronger signals, so I prefer to increase the value.

[BatchDrake]

Hi,

It seems that, for whatever reason, SDRPlay starts up with the AGC on. This is very odd. I've just explicitly disabled AGC right before setting the initial gains to prevent this from happening. This change is in Suscan. Could you pull & rebuild Suscan and SigDigger (in this order) again?

Thanks,

[srs4511351]

After reinstalling SigDigger and modules, the AGC still starts at the same setting when Run is pressed.
This setting does not seem to be related to the signals on the band, just a default value.
Selecting or deselecting Hardware AGC has no effect.

I do not believe that the AGC action that I hear on SSB is the hardware AGC, but software feature. It is similar to the other SDR software that I have. They have AGC that works without hardware AGC, which does have an effect when selected.

[BatchDrake]

Can you confirm you cloned the latest suscan from develop? I will keep looking into this further, but this is a behavior I cannot reproduce with other radios (like AirSpy).

On the other hand, what you hear in SSB is definitely the a software AGC. I've been a bit unhappy with it lately, because of what it sounds like when I reduce the bandwidth of the signal. Would you consider useful adding a control to disable it? Like a checkbox or something.

[srs4511351]

I don't really know now to tell the version, but the suscan/build folder is dated 6/17/2023 23:20 EDT. The files inside have the same date.
The git checkout command says Your branch is up to date with 'origin/develop'.

I do not see this problem with my HackRF.

The software AGC is very useful with SSB and AM. I would not normally disable it.
It is very good except for the decay, which is too fast. If it could be set longer, it would work very nicely.
Sometimes applications will provide attack, decay and threshold settings. A checkbox to disable it could be added.

[srs4511351]

Would it help to re-output the gain values every time Run is pressed?

[BatchDrake]

I've just tried something else, could you pull Suscan and rebuild Suscan? (and only Suscan)

[srs4511351]

I rebuilt only suscan.
The gain levels are now saved and restored.
Actually, the previous IFGR from before the change was restored.

[srs4511351]

Hardware AGC still has no effect.

[BatchDrake]

Glad to hear that. It seems that the radio started itself with the AGC set to on by default (which is weird, but with SDRPlay everything is weird), and I had to disable it explicitly before setting the gains.

Hardware AGC still has no effect.

I have just tested it again with AirSpy and it works perfectly. Also, it is strange, as I had to disable hardware AGC right before setting the gains because otherwise the SDRPlay API would complain with the warning you paster earlier.

My conclusion is that this one of the (many) SDRPlay issues. There's little I can do about it, except maybe opening a new issue in the SoapySDRPlay's github repo.

[BatchDrake]

Just in case you want to compare it with my results, this is me setting and unsetting the hardware AGC in AirSpy, with no antenna.

[srs4511351]

gqrx set the AGC once when using soapy. After that, it made no difference when turning hardware AGC on or off.
It did work correctly when not using soapy.

On the other hand, AGC does work in SDRangel when using soapy.
This seems to be the hardware AGC, but the documentation does not specify. It does affect gain of the entire received spectrum.

[BatchDrake]

Great, that is the exact behavior we are experiencing, so this makes it perfectly reproducible.

I am going to close this issue, is there anything else I could help you with?

Thanks,

[srs4511351]

Except that SDRangel did work.

Are you considering adding options such as attack, decay and threshold settings for the software AGC?

[BatchDrake]

Except that SDRangel did work.

Yes, because it interfaces with the SDRPlay API directly. The problem is inside the SoapySDR module for SDRPlay.

Are you considering adding options such as attack, decay and threshold settings for the software AGC?

I have several open fronts now, but feel free to open a new issue (as feature request) and I will update you from there. I prefer to keep issues on topic.

[srs4511351]

No, I had the SoapySDR device selected in SDRangel.

[BatchDrake]

I am afraid I cannot reproduce with any of the other radios. Also, just checked SDRAngel's code, and he adjusts the AGC the same way as I do.

The fact that the issue is easily reproducible by Gqrx makes me think that either SDRangel ignores the SoapySDR setting, or that it has been linked against a different version of the SDRPlay API, or something of the sort.

In either case, the SoapySDR API is what it is, and I am not able to maintain device-specific kludges for radios I do not have. But I've just opened an issue in the GitHub repo of the SDRPlay's module so you can follow up the discussion there: pothosware/SoapySDRPlay3#73

[srs4511351]

Thanks for opening the issue. gqrx is having the same trouble.

There is only one version of the SDRplay API on my system. The SDRangel device was the SoapySDR SDRplay driver.

[srs4511351]

In pothosware/SoapySDRPlay3#73 we discovered that the agc_setpoint default in SoapySDRplay3 is so low that strong signals cannot decrease IFGR further.
They added a agc_setpoint=-30 as a default. For SigDigger, you could choose to provide a setting for agc_setpoint or expect the users to update SoapySDRplay3.
I found that if I add agc_setpoint=-30 to the Soapy Device string, it would work.

----Steve