Hardware AGC setting taking effect only once #73
Comments
|
@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 ( Franco |
|
In SigDigger, the default sample rate is 1 Msps. Later, I set the sample rate to 2.048 Msps, which seems to be a native sample rate for the SDRplay SDR. It does not work at 2 Msps |
|
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 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. |
|
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. |
|
@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
Then rebuild ( 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: 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 |
|
Neither SigDigger or gqrx worked correctly with Soapy. For each of these, I set the sample rate and restarted the program. Hardware AGC was initially off. SigDigger 2 Msps SigDigger 2.048 Msps gqrx 2 Msps (unchecking Hardware AGC left the gain extremely high) gqrx 2.048 Msps (unchecking Hardware AGC left the gain extremely high) The gqrx device string was |
|
@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 ( I am not 100% sure I fully understand your initial paragraph:
Can you describe each scenario you are testing in better detail, for instance using a description like this: 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 |
|
Please forgive me if I am not clear. I am happy to answer your questions.
I believe the "non-soapy device" is a built-in device (source type). 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: no AGC action Case 2: Case 3: no AGC action Case 4: Case 5: AGC correctly compensates for changing signal strength. Case 6: Case 7: gain only changes when Hardware AGC is toggled. 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. |
|
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 |
|
@SDRplay 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. 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). 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. ----Steve |
|
In gqrx, I tried Hardware AGC again with the 2 MHz sample rate. RFGR was set to 0. With IFGR set to 27, applying the same strong signal apparently causes the SDR to overload, causing spurious signals appear across the spectrum. Still no hardware AGC action. ----Steve |
|
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 and https://github.com/pothosware/SoapySDRPlay3/blob/master/Streaming.cpp#L356 then the API debug output should appear in the syslog Best regards, Andy |
|
In CubicSDR, which uses the Soapy driver, the default AGC setpoint is -60. At this setting, AGC is relatively ineffective. In CubicSDR, it appears that hardware AGC (assuming that's what they are using) works well with the right AGC setpoint value. ----Steve |
|
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 |
|
That's it! Adding 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 |
|
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 |
|
Thanks for the help. ----Steve |
|
@srs4511351 @SDRplay - thanks for all your help troubleshooting and figuring out the issue with the AGC! I just pushed this commit to the SoapySDRPlay3 I also added a check on Please give it a try and let me know if it works as expected. Franco |
|
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. ----Steve |
|
I commented out the new code that checks the frequency and recompiled SoapySDRPlay3. ----Steve |
|
@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 I just pushed the code with the fix to the I apologize for this problem, |
|
Thanks for the fixes. The new fix works for the software I tried. ----Steve |
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,
The text was updated successfully, but these errors were encountered: