Sdrplay RSP1 (and RSP1A) through Soapy shows only a small hump out of the full sample rate.

[ageras1]

Someone made a post on his blog of this issue with screenshots and a work around it. I can put a link to it, but i don't know if it is allowed.
The issue is not about the latest version, it existed about a year ago (not sure exactly probably less).
Even though you put in the Configure I/O Devices panel Input rate 5000000 (or 8000000 or whatever) and press ok, you can see all of the spectrum (lets say 5000000) but it is only usable a very small portion of it at the center. In the small usable center you have the noise floor and the stations you can receive and the rest spectrum is just like a noise floor but many db lower and not any signals at all.
The work around was to put in the Configure I/O Devices panel Bandwidth 0.6 MHz and select another device, press ok, then return to the Configure I/O Devices and select the correct device you want to use and press ok. That worked for a while but now you have to do the same except you must set the Bandwidth to 8.0 MHz.
Hope that helps, i can give you more info if you like but the blog post will make it more clear.
I tried the Arch linux Gqrx package and the aur gqrx-git (v2.14.4-23-g272bd75) with soapysdr (0.8.1), soapysdrplay3-git and libsdrplay 3.07 (but if i am not mistaken the same happens with the earlier libsdrplay 2.???)

[AsciiWolf]

Thanks! I had the same issue and setting bandwidth to 8.0 MHz fixed it.

[sibrat]

RSP1 supports 8 fixed bandwidths: 0.2, 0.3, 0.6, 1.536, 5, 6, 7, 8 Mhz. Any other value interprets as invalid and defaults to 0.2MHz

[argilo]

Any other value interprets as invalid and defaults to 0.2MHz

I had a peek at the gr-osmosdr source code, and that doesn't appear to be the case:

https://github.com/osmocom/gr-osmosdr/blob/a100eb024c0210b95e4738b6efd836d48225bd03/lib/sdrplay/sdrplay_source_c.cc#L554-L561

However, specifying 0 will result in the 0.2 MHz filter being selected, whereas for most other SDR types it will cause a sensible default to be chosen based on the requested sample rate. So I think the issue here lies in gr-osmosdr, not Gqrx.

[ageras1]

@argilo as you said the issue must be at gr-osmosdr, i tried the fixed bandwidths and the other ones with the same result.

I looked at the dependencies of some software that i use who depend on soapy (without gr-osmosdr in the middle) and they work fine. only gqrx (in my case) goes through gr-osmosdr to soapy and has these problem.

Should we (or me) put an issue on gr-osmosdr?

It works fine if you set the Bandwidth to 8.0 MHz (not the Input Rate) but i found the solution on a "random" blog (after long time) and it brightened my day. so if someone knows the right path to "fix" this please do or tell me what can i do. should i just open an issue at gr-osmosdr?