Hardware AGC setting taking effect only once

[BatchDrake]

Hi,

I do not own any SDRPlay receiver, but this comes from a SigDigger user having trouble enabling and/or disabling AGC (automatic gain mode in SoapySDR's jargon) more than once. This issue seems to be observed in Gqrx as well (see the original thread for the full discussion).

Could it be that maybe, once the AGC is disabled, all the gains (as exposed by the module) are still adjusted to whatever was commanded by the AGC and the user sees no effect? This issue does not occur with other radios.

Unfortunately, I do now own any SDRPlay device to figure out these things on my own.

Thanks,

[fventuri]

@BatchDrake, @srs4511351 - thanks for reporting this problem with the SoapySDRPlay3 module.

Tonight I wrote a simple C++ program based on the SoapySDR C++ example (https://github.com/pothosware/SoapySDR/wiki/Cpp_API_Example#basic-c-api-example). I added a few lines to enable/disable the AGC and to change the IF gain reduction (IFGR) a couple of times. I think the output from the example program (attached) is consistent with the expected behavior from the setGainMode() and setGain() commands in the code:

...
start - gain mode=1 - IFGR=50.000000
disable AGC - gain mode=0 - IFGR=55.000000
set IFGR=30 - gain mode=0 - IFGR=30.000000
set IFGR=50 - gain mode=0 - IFGR=50.000000
enable AGC - gain mode=1 - IFGR=50.000000
disable AGC - gain mode=0 - IFGR=53.000000
...

Franco

SoapySDRExample.zip

[srs4511351]

In SigDigger, the default sample rate is 1 Msps. It was with this sample rate that I tried the AGC settings. Hardware AGC had no effect.

Later, I set the sample rate to 2.048 Msps, which seems to be a native sample rate for the SDRplay SDR. When selecting Hardware AGC, gain is reduced to what seems to be near minimum IFGR. Deselecting Hardware AGC does not return IFGR to the setting of the IFGR slider and moving it slightly sets IFGR to the slider's setting.

It does not work at 2 Msps It works at 6 Msps, which is listed as a valid sample rate by SoapySDRUtil --probe="driver=sdrplay" Unfortunately, SoapySDRUtil abbreviated, omitting some of the valid sample rates. ...

[srs4511351]

Here are some tests done with gqrx using the SDRplay Soapy device..

At 1 Msps, Hardware AGC changed the gain once when deselecting it. After that, checking Hardware AGC did nothing. When unchecking Hardware AGC, there is a glitch, which puts a horizontal line on the waterfall. 2 Msps worked the same as 1 Msps. At 2.048 Msps, When selecting Hardware AGC, gain is reduced to what seems to be near minimum IFGR. Deselecting it restores IFGR to the setting from the slider. 6 Msps works like the 2.048 Msps setting.

2 Msps works in gqrx with the non-Soapy device except that Hardware AGC sets the IF gain to somewhere near the middle of the IF gain slider.

[srs4511351]

In gqrx, At 2.048 Msps, When selecting Hardware AGC, gain, it makes a difference in the gain as seen on the display, but it doesn't change the gain when an extremely strong signal appears. It does work on the non-Soapy device.

[fventuri]

@srs4511351 - thanks for all your tests.

To try to troubleshoot this problem, do you mind adding some debugging to the SoapySDRPlay3 module by adding the following lines to the file Settings.cpp?

1. after line 474 (https://github.com/pothosware/SoapySDRPlay3/blob/master/Settings.cpp#L474), please add this:

   SoapySDR_logf(SOAPY_SDR_INFO, "enter setGainMode(%d)", automatic);

2. after line 485 (https://github.com/pothosware/SoapySDRPlay3/blob/master/Settings.cpp#L485), please add this:

   SoapySDR_logf(SOAPY_SDR_INFO, "setGainMode(%d) -> IFGR=%d AGC=%d", automatic, chParams->tunerParams.gain.gRdB, chParams->ctrlParams.agc.enable);

3. after line 496 (https://github.com/pothosware/SoapySDRPlay3/blob/master/Settings.cpp#L496), please add this:

   SoapySDR_logf(SOAPY_SDR_INFO, "enter setGain(%s, %lf)", name.c_str(), value);

4. after line 544 (https://github.com/pothosware/SoapySDRPlay3/blob/master/Settings.cpp#L544), please add this:

   SoapySDR_logf(SOAPY_SDR_INFO, "setGain(%s, %lf) -> IFGR=%d AGC=%d", name.c_str(), value, chParams->tunerParams.gain.gRdB, chParams->ctrlParams.agc.enable);

Then rebuild (make) and reinstall (sudo make install) this SoapySDRPlay3 module.

Run the application that has problems with the AGC and gain settings, and hopefully you should see log messages like this one in your terminal:

[INFO] enter setGainMode(0)

Please post the messages you see when you enable/disable the AGC, and when you change the gain value so we can try to figure out what is the problem.

Franco

[srs4511351]

Neither SigDigger or gqrx worked correctly with Soapy. They didn't work at all with the 2 Msps sample rate, but both appeared to work with the 2.048 Msps rate. With gqrx, using soapy, AGC did not respond to an extremely large signal, but it did with the non soapy device.

For each of these, I set the sample rate and restarted the program. Hardware AGC was initially off. Then I clicked Hardware AGC, Then clicked it again.

SigDigger 2 Msps

[INFO] devIdx: 0
[INFO] SerNo: 19110C0797
[INFO] hwVer: 255
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
[INFO] enter setGainMode(0)
[INFO] setGainMode(0) -> IFGR=50 AGC=0
[INFO] enter setGain(IFGR, 33.000000)
[INFO] setGain(IFGR, 33.000000) -> IFGR=33 AGC=0
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=33 AGC=0
[INFO] Using format CF32.
[INFO] enter setGain(IFGR, 33.000000)
[INFO] setGain(IFGR, 33.000000) -> IFGR=33 AGC=0
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=33 AGC=0
[INFO] enter setGainMode(0)
[INFO] setGainMode(0) -> IFGR=33 AGC=0
[INFO] enter setGainMode(1)
[INFO] setGainMode(1) -> IFGR=33 AGC=4
[INFO] enter setGainMode(0)
[INFO] setGainMode(0) -> IFGR=33 AGC=0

SigDigger 2.048 Msps

[INFO] devIdx: 0
[INFO] SerNo: 19110C0797
[INFO] hwVer: 255
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
[INFO] enter setGainMode(0)
[INFO] setGainMode(0) -> IFGR=50 AGC=0
[INFO] enter setGain(IFGR, 33.000000)
[INFO] setGain(IFGR, 33.000000) -> IFGR=33 AGC=0
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=33 AGC=0
[INFO] Using format CF32.
[INFO] enter setGain(IFGR, 33.000000)
[INFO] setGain(IFGR, 33.000000) -> IFGR=33 AGC=0
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=33 AGC=0
[INFO] enter setGainMode(0)
[INFO] setGainMode(0) -> IFGR=33 AGC=0
[INFO] enter setGainMode(1)
[INFO] setGainMode(1) -> IFGR=33 AGC=4
[INFO] enter setGainMode(0)
[INFO] setGainMode(0) -> IFGR=59 AGC=0

gqrx 2 Msps (unchecking Hardware AGC left the gain extremely high)

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.5.1
built-in source types: file rtl rtl_tcp uhd sdrplay hackrf rfspace soapy redpitaya 
Resampling audio 96000 -> 48000
BandPlanFile is /home/pi/.config/gqrx/bandplan.csv
BookmarksFile is /home/pi/.config/gqrx/bookmarks.csv
[INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.3.0.0+ds1-5
Physical device count: 1
sdrplay=0,hwVer=255,label='SDRplay RSP1A 19110C0797'
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.5.1
built-in source types: file rtl rtl_tcp uhd sdrplay hackrf rfspace soapy redpitaya 
[INFO] devIdx: 0
[INFO] SerNo: 19110C0797
[INFO] hwVer: 255
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
[INFO] Using format CF32.
[INFO] enter setGain(IFGR, 20.000000)
[WARNING] Not updating IFGR gain because AGC is enabled
[INFO] setGain(IFGR, 20.000000) -> IFGR=50 AGC=2
[INFO] enter setGain(IFGR, 20.000000)
[WARNING] Not updating IFGR gain because AGC is enabled
[INFO] setGain(IFGR, 20.000000) -> IFGR=50 AGC=2
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=50 AGC=2
[INFO] enter setGain(IFGR, 20.000000)
[WARNING] Not updating IFGR gain because AGC is enabled
[INFO] setGain(IFGR, 20.000000) -> IFGR=50 AGC=2
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=50 AGC=2
[INFO] enter setGainMode(1)
[INFO] setGainMode(1) -> IFGR=59 AGC=4
[INFO] enter setGainMode(0)
[INFO] setGainMode(0) -> IFGR=59 AGC=0
[INFO] enter setGain(IFGR, 20.000000)
[INFO] setGain(IFGR, 20.000000) -> IFGR=20 AGC=0
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=20 AGC=0
[INFO] enter setGain(IFGR, 20.000000)
[INFO] setGain(IFGR, 20.000000) -> IFGR=20 AGC=0
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=20 AGC=0

gqrx 2.048 Msps (unchecking Hardware AGC left the gain extremely high)

gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.5.1
built-in source types: file rtl rtl_tcp uhd sdrplay hackrf rfspace soapy redpitaya 
Resampling audio 96000 -> 48000
BandPlanFile is /home/pi/.config/gqrx/bandplan.csv
BookmarksFile is /home/pi/.config/gqrx/bookmarks.csv
[INFO] [UHD] linux; GNU C++ version 12.2.0; Boost_107400; UHD_4.3.0.0+ds1-5
Physical device count: 1
sdrplay=0,hwVer=255,label='SDRplay RSP1A 19110C0797'
gr-osmosdr 0.2.0.0 (0.2.0) gnuradio 3.10.5.1
built-in source types: file rtl rtl_tcp uhd sdrplay hackrf rfspace soapy redpitaya 
[INFO] devIdx: 0
[INFO] SerNo: 19110C0797
[INFO] hwVer: 255
[INFO] rspDuoMode: 0
[INFO] tuner: 1
[INFO] rspDuoSampleFreq: 0.000000
[INFO] Using format CF32.
[INFO] enter setGain(IFGR, 20.000000)
[WARNING] Not updating IFGR gain because AGC is enabled
[INFO] setGain(IFGR, 20.000000) -> IFGR=50 AGC=2
[INFO] enter setGain(IFGR, 20.000000)
[WARNING] Not updating IFGR gain because AGC is enabled
[INFO] setGain(IFGR, 20.000000) -> IFGR=50 AGC=2
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=50 AGC=2
[INFO] enter setGain(IFGR, 20.000000)
[WARNING] Not updating IFGR gain because AGC is enabled
[INFO] setGain(IFGR, 20.000000) -> IFGR=50 AGC=2
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=50 AGC=2
[INFO] enter setGainMode(1)
[INFO] setGainMode(1) -> IFGR=59 AGC=4
[INFO] enter setGainMode(0)
[INFO] setGainMode(0) -> IFGR=59 AGC=0
[INFO] enter setGain(IFGR, 20.000000)
[INFO] setGain(IFGR, 20.000000) -> IFGR=20 AGC=0
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=20 AGC=0
[INFO] enter setGain(IFGR, 20.000000)
[INFO] setGain(IFGR, 20.000000) -> IFGR=20 AGC=0
[INFO] enter setGain(RFGR, 0.000000)
[INFO] setGain(RFGR, 0.000000) -> IFGR=20 AGC=0

The gqrx device string was driver=sdrplay,serial=19110C0797,soapy=1 It looks like the non-soapy string was displayed in the output, but the Soapy messages were only displayed with the soapy device selected.

[fventuri]

@srs4511351 - thanks for all your tests and useful comments.

The good new is that it looks like both SigDigger and gqrx call the SoapySDR functions to enable/disable AGC and to change the IFGR (gain reduction), and in both cases it looks like those settings are sent to the SDRplay API. I think at this point you can remove those four debug lines I asked you to add last night, rebuild (make), and then reinstall the SoapySDRPlay3 driver (sudo make install).

I am not 100% sure I fully understand your initial paragraph:

Neither SigDigger or gqrx worked correctly with Soapy. They didn't work at all with the 2 Msps sample rate, but both appeared to work with the 2.048 Msps rate. With gqrx, using soapy, AGC did not respond to an extremely large signal, but it did with the non soapy device.

Can you describe each scenario you are testing in better detail, for instance using a description like this:

Case 1:
- application: SigDigger
- center frequency: 14.000MHz
- sample rate: 2MHz
- AGC: off
- IFGR: 40
- input signal: single tone at 14.100MHz, how its amplitude changes over time, etc
- expected outcome: ...
- actual outcome: ...

and so on for each scenario you think it is important to consider.

Also I am not really sure what is a 'non soapy device': if it is a different hardware running a different API and a different driver, there are too many differences to be able to make a useful comparison between the two.

Franco

[srs4511351]

Please forgive me if I am not clear. I am happy to answer your questions.

Neither SigDigger or gqrx worked correctly with Soapy. They [AGC} didn't work at all with the 2 Msps sample rate, but both appeared to work with the 2.048 Msps rate. With gqrx, using soapy, AGC did not respond to an extremely large signal, but it did with the non soapy device.

I believe the "non-soapy device" is a built-in device (source type). The device string for the "non-soapy device" is hwVer=255,sdrplay=0

In my reply on June 19, I did a series of similar tests with hardware AGC at various sample rates.

In the screen shots, look at the 14.061 MHz signal level, which is increased and decreased repeatedly in Cases 1-6.

Case 1:
- application: gqrx with Soapy device
- center frequency: 14.060 MHz
- sample rate: 2MHz
- HW AGC: on
- IFGR: 50
- input signal: single tone at 14.061 MHz
With a signal generator, I changed the single tone from minimum to maximum output.
With stronger signals, I expect to see a gain reduction and the opposite when it is weak, as seen on the spectrum/waterfall display.
The overall gain does not change.

Case 1: no AGC action

Case 2:
- application: gqrx with Soapy device
- center frequency: 14.060 MHz
- sample rate: 2MHz
- HW AGC: off
- IFGR: 50
- input signal: single tone at 14.061 MHz
With a signal generator, I changed the single tone from minimum to maximum output.
With either strong or weak signals, I do not expect any gain change on the spectrum/waterfall display
The overall gain does not change.

Case 2:

Case 3:
- application: gqrx with Soapy device
- center frequency: 14.060 MHz
- sample rate: 2.048MHz
- HW AGC: on
- IFGR: 50
- input signal: single tone at 14.061 MHz
With a signal generator, I changed the single tone from minimum to maximum output.
With stronger signals, I expect to see a gain reduction and the opposite when it is weak, as seen on the spectrum/waterfall display.
The overall gain does not change.

Case 3: no AGC action

Case 4:
- application: gqrx with Soapy device
- center frequency: 14.060 MHz
- sample rate: 2.048MHz
- HW AGC: off
- IFGR: 50
- input signal: single tone at 14.061 MHz
With a signal generator, I changed the single tone from minimum to maximum output.
With either strong or weak signals, I do not expect any gain change on the spectrum/waterfall display
The overall gain does not change.

Case 4:

Case 5:
- application: gqrx with built in device
- center frequency: 14.060 MHz
- sample rate: 2MHz
- HW AGC: on
- IFGR: 50
- input signal: single tone at 14.061 MHz
With a signal generator, I changed the single tone from minimum to maximum output.
With stronger signals, I expect to see a gain reduction and the opposite when it is weak, as seen on the spectrum/waterfall display.
The overall gain changes to compensate for the signal strength as expected.

Case 5: AGC correctly compensates for changing signal strength.

Case 6:
- application: gqrx with built in device
- center frequency: 14.060 MHz
- sample rate: 2MHz
- HW AGC: off
- IFGR: 50
- input signal: single tone at 14.061 MHz
With a signal generator, I changed the single tone from minimum to maximum output.
With either strong or weak signals, I do not expect any gain change on the spectrum/waterfall display
The overall gain does not change.

Case 6:

Case 7:
- application: gqrx with Soapy device
- center frequency: 14.060 MHz
- sample rate: 2.048MHz
- HW AGC: on and off
- IFGR: 50
- input signal: single tone at 14.061 MHz
With a signal generator, I set the single tone to minimum output.
I toggled Hardware AGC on and off. I expect to see the gain change as it is toggled.
The overall gain does change when Hardware AGC is turned on and off.

Case 7: gain only changes when Hardware AGC is toggled.

Case 8:
- application: gqrx with Soapy device
- center frequency: 14.060 MHz
- sample rate: 2MHz
- HW AGC: on and off
- IFGR: 50
- input signal: single tone at 14.061 MHz
With a signal generator, I set the single tone to minimum output.
I toggled Hardware AGC on and off. I expect to see the gain change as it is toggled.
The overall gain changed only once when AGC was turned off and only after restarting gqrx.
The overall gain does not change when Hardware AGC is turned on and off, but there is a glitch that places a horizontal line on the waterfall.

With gqrx using the Soapy device at 2.048 MHz, where Hardware AGC initially appeared to work (the gain changed when Hardware AGC is checked or unchecked), a strong signal did not change the gain; the signals, other than the test single tone, including background noise as seen on the spectrum/waterfall display are unaffected. See Case 7: gain only changes when Hardware AGC is toggled.

Note that Case 5 is the only scenario where Hardware AGC worked correctly, with the built-in device, not Soapy, Hardware AGC definitely did change the gain when a strong signal appeared and also when it disappeared.

I conclude that with Soapy, the Hardware AGC is not working correctly in any of the tests. Maybe it takes a sample at the instant it is enabled?

Note that With hardware AGC, a signal anywhere in the received spectrum will affect gain. Note the difference between Case 7 and Case 8. The outcome should have been the same, but was not. With the Soapy device, SigDigger behaves like gqrx.

[SDRplay]

Hi all,

Just saw this post and wanted to add a couple of comments...

It's worth noting that the "hardware AGC" is for the IF gain system ONLY and so the range that the IFAGC can set is between 20 and 59 IFGR - if you really want a total hardware AGC, you'll need to create your own that incorporates the RF state because you have a 20-59 dB IF gain range for each RF state value. I note that in all your tests you are at maximum RF gain (RFGR = 0) and that nominally your manual IFGR is 50 which means the internal gain can only be lowered by 9 dB before hitting the end stop.

Please also note that the purpose of the IFAGC system is to ensure that the input signal range fits within the ADC. If the input isn't going to exceed the ADC range then the IFAGC won't make any changes, as there is no need.

One last point is that the input spectrum bandwidth is used for the IFAGC system. For Low-IF this would be 6 or 8 MHz (depending on the IF frequency) and for Zero-IF this would be for whatever the input spectrum bandwidth is (between 2 and 10 MHz). In Low-IF mode the 6 or 8 MHz sample rate is then downconverted and de-rotated to deliver I/Q at a fixed 2MHz final sample rate. If I remember correctly, the SoapySDRPlay library uses Low-IF for final sample rates of 2MHz or lower. Also, note that decimation is AFTER this in software and has decimation filters applied.

I'm slightly surprised that these controlled tests aren't done in a quiet part of the spectrum. I can't see the whole input spectrum that the IFAGC is processing in your screengrabs, but with some of the signals that I see there, it doesn't surprise me that the IF isn't moving.

Also, when you say the IFGR is not moving, are you using the value in the UI for that or looking at the API debug output? The IFGR value that the IFAGC system is always sent to the API callback - so unless the UI is updating it's value from the API callback, it will never change when IFAGC is enabled.

If you want to check whether SoapySDR/SoapySDRPlay/API is working correctly, I would recommend trying to reproduce what you are doing in SDRuno - if there's a difference in behaviour then that's something I can help Franco with.

Hope that helps - I'll keep an eye on the thread and will help where I can.

Best regards,

Andy

[srs4511351]

@SDRplay Thanks for your insight.

These tests were for testing Hardware AGC action with SoapySDR, not a test of the hardware itself. I initially chose the FT8 area of the 20 meter band because there are periodic strong signals there, but later decided to use a signal generator to produce a more controlled large signal. You can see in the Case 5 screen shot, that hardware AGC does compensate for changing signal strength. I am using the spectrum/waterfall display as a gain change indication. With a typical SDR application, there is no other indication of the current IFGR as set by the hardware AGC. I am using a Raspberry Pi, so currently, there is no SDRuno or SDRconnect to try, but these do not use Soapy, which is what we are testing.

I see from these tests that the RSP1A hardware AGC is working, but not with Soapy.

In gqrx, Re-running the AGC tests at a 2.048 MHz sample rate and IFGR initially set to 40 with a less efficient antenna, I get the same results. There are no signals greater than my signal generator. I see a gain response on the waterfall with the built-in device and not with the Soapy device. I believe this shows that the signal generator output is large enough to trigger hardware AGC.

I also noticed that with the Soapy device, enabling Hardware AGC initially brought the gain down a large amount to what looks like an IFGR of 59 (when Hardware AGC is off). It looks like with Soapy, hardware AGC always starts at the minimum IFGR regardless of the initial IFGR setting and thus hardware AGC cannot reduce the gain further for a large signal.

In conclusion, I now suspect that if the Soapy device started with a higher IFGR, the hardware would be able to respond to the large signal change. This is consistent with Andy's comments.

----Steve

[srs4511351]

In gqrx, I tried Hardware AGC again with the 2 MHz sample rate. RFGR was set to 0. When Hardware AGC is enabled, it starts at the current IFGR setting. With IFGR set to 40, there is no visible AGC action when the strong signal is applied.

With IFGR set to 27, applying the same strong signal apparently causes the SDR to overload, causing spurious signals appear across the spectrum. The background noise is reduced, which is interesting. This phenomenon occurs equally with Hardware AGC checked as well as with it unchecked.

Still no hardware AGC action.

----Steve

[SDRplay]

Hi Steve,

Given that there's no feedback mechanism in place (I believe) to update the IFGR in the UI when IFAGC is enabled, can you report what the API debug says the IFGR is when the IFAGC is enabled. You can paste the log here and I'll be able to tell what's going on.

You may need to swap these lines around (comment out one and uncomment the other) unless you've already done so...

https://github.com/pothosware/SoapySDRPlay3/blob/master/Settings.cpp#L1866 https://github.com/pothosware/SoapySDRPlay3/blob/master/Settings.cpp#L1867

and

https://github.com/pothosware/SoapySDRPlay3/blob/master/Streaming.cpp#L356 https://github.com/pothosware/SoapySDRPlay3/blob/master/Streaming.cpp#L357

then the API debug output should appear in the syslog

Best regards,

Andy

[srs4511351]

In CubicSDR, which uses the Soapy driver, the default AGC setpoint is -60. At this setting, AGC is relatively ineffective. With the AGC setpoint at -20, AGC it very responsive to strong signals. CubicSDR does not indicate what the "Automatic Gain" setting is, hardware or software. With Automatic Gain on or off, there always is a software AGC apparent in SSB signals.

In CubicSDR, it appears that hardware AGC (assuming that's what they are using) works well with the right AGC setpoint value. gqrx does not have an AGC setpoint for hardware AGC.

----Steve

[SDRplay]

We use -30 in SDRuno.

Looking at SoapySDRPlay, it looks like it does have a default of -30 but unless this parameter is used "agc_setpoint" then it isn't set. so maybe you can specify agc_setpoint=-30 in the SoapySDR command string that you use in GQRX?

Best regards,

Andy

[srs4511351]

That's it! With gqrx at 2 MHz and adding agc_setpoint=-30 to the device string, it starts with the gain much higher and does respond to the strong single tone from my signal generator. The device string is now driver=sdrplay,serial=19110C0797,soapy=2,agc_setpoint=-30

Adding agc_setpoint=-30 also works at the 2.048 MHz sample rate.

Is there something that SoapySDR can do to use this as a default, or must the application provide that setting?

Do you still need the API debug output requested before?

----Steve

[SDRplay]

Hi Steve,

No need for the debug output, I think this issue can be closed.

-30 is a better default, so maybe that's something that can be added. It will be quite straight forward to do. Someone could do a PR, I'll try to do it but I've got a massive to do list at the moment with SDRconnect!

Glad you got to the bottom of it.

Best regards,

Andy

[srs4511351]

Thanks for the help. Breathlessly awaiting SDRconnect for Raspberry Pi!

----Steve

[fventuri]

@srs4511351 @SDRplay - thanks for all your help troubleshooting and figuring out the issue with the AGC!

I just pushed this commit to the SoapySDRPlay3 master branch: https://github.com/pothosware/SoapySDRPlay3/commit/ab0f5164114ed7fe59938da231e19afc2b6690d4 - it sets the default AGC set point to -30dBfs, which should work much better. This way you shouldn't need to add agc_setpoint=-30 to the connection string.

I also added a check on setFrequency() to make sure it is within the valid frequency range as per this other issue: https://github.com/pothosware/SoapySDRPlay3/issues/72 .

Please give it a try and let me know if it works as expected.

Franco

[srs4511351]

I installed the updated SoapySDRPlay3 and AGC works on gqrx without the gain string.

I tried it on SigDigger, but it gets a Segmentation fault when I press Run in the application. I installed the old version of SoapySDRPlay3 and it works again. CubicSDR also has a Segmentation fault when the SDRplay is started. SDRangel also has a Segmentation fault when the SDRplay Soapy device is selected. Its built-in SDPplay device works.

----Steve

[srs4511351]

I commented out the new code that checks the frequency and recompiled SoapySDRPlay3. It works in SigDigger now and an extremely strong signal reduces the gain. CubicSDR works again. SDRangel works and AGC works.

----Steve

[fventuri]

@srs4511351 - good catch Steve!

Last night when I tested my changes I used the C++ SoapySDR example that I wrote a few days ago, and I forgot that in SoapySDR there are two kinds of frequencies: the center frequency (called "R" in SoapySDR/SoapySDRPlay3) and the frequency correction/ppm (called "CORR").

The range check applies only to the first kind, and it throws a segmentation violation when used in the "CORR" case because there's no range defined for frequency correction/ppm.

This morning I moved that check inside the "RF" case in the function setFrequency(); with this change CubicSDR doesn't crash any more.

I just pushed the code with the fix to the master branch; please give it a try, and let me know if it works with all your SDR applications.

I apologize for this problem, Franco

[srs4511351]

Thanks for the fixes.

The new fix works for the software I tried. I just received the International Space Station with it.

----Steve