Hardware Request: SDRPlay API 3.14 and RSP1b for Windows Version

[simplio]

Please add support for SDRPlay API 3.14 and RSP1b and all RSP's in the windows version. RSP1b is my goto SDR. I know GQRX windows supports RTL-SDR Blog v4, in which I have, but I prefer my RSP1b. I like GQRX well enough to think it has vast potential to support SDRPlay API 3.14 very efficiently and effectively.

Thanks for hearing my request.
simplio

[argilo]

Unfortunately, I don't anticipate being able to do this. Unlike most other SDRs, the SDRplay's drivers are not open source, which makes it impractical to redistribute them as part of an open source project. I would suggest sticking to devices that provide open source drivers.

[Axpelle]

Version 3.14 of the API is freely available from SDRPlay's website and I know of at least one developer who has already integrated it in his free software, namely SDRAngel. As for version 3.12 of the API, it has been successfully integrated in SDR++, which is also free.

[argilo]

It may be possible to include SoapySDRPlay3 (https://github.com/pothosware/SoapySDRPlay3) with Gqrx binaries, and let the user download the API on their own.

If someone wants to take a crack at that, they're welcome to. But I'm not going to spend my own personal time to support a company that does not provide drivers under an open source license.

[simplio]

SDRPlay API is open for developers but not sure about the windows driver. What's confusing is GQRX on the linux version supports the older MSi251x MRD chip. GQRX device compatibility instructions won't work with the windows version.

"We don't like closed source drivers"
HDSDR, SDR-Console, SDR++, SDRTrunk and SDRAngel saw it feasible to implement support for their end user base. It works very well in all of them. Also, that attitude is like saying you don't want the end user to use SDRPlay products in GQRX windows version. How are you even able to work with some of the closed source components in windows and still say "We don't like closed source drivers"?

A paradox.

I want to hear Alexandru Csete OZ9AEC opinion on this. It is ultimately his software.

[argilo]

Gqrx is created and maintained by volunteers, who work on features that they are interested in. If someone has the desire to add SDRplay support, they are welcome to.

[Axpelle]

The paradox is still there. Microsoft's credo is closed and proprietary source.

[argilo]

What is the paradox? I have no interest in Windows either. Windows support in Gqrx was contributed by others who had an interest in it.

[Axpelle]

Well let's hope a platform agnostic developer reads this and provides connectivity between SDRPlay and GQRX.

[AsciiWolf]

@simplio Did you try asking SDRplay directly to add support for their devices in Gqrx for Windows? As far as I know, the biggest problem is that SoapySDRPlay3 needs to be compiled against the API installed on the system. So, if end-user had a different version of that API, it most likely would not work. And bundling SDRplay libraries and other parts of the API directly with Gqrx is against the SDRplay license. Don't get me wrong, I really like my RSPdx, but I must agree with Clayton on this.

[Axpelle]

Thank you for taking the time to share your views on this topic. Some background from me will help set the context. Until very recently (say January 2024) there was a complete dearth of software to run SDRs natively on a Mac. GQRX, CubicSDR and SDRAngel were about the only ones available; in fact GQRX has a well designed window and it works beautifully with RTLSDR. However, its functions are quite limited (eg it does not scan). Updates are also infrequent. CubicSDR is almost all mouse driven and not very user friendly. It has not been updated for a long time. The reason for asking to have SDRPlay hardware supported in GQRX in particular was to take advantage of the higher level of performance of such hardware compared to RTL2832 based dongles and of its clear and intuitive interface. In the meantime SDRAngel has been updated at a steady pace and its developer recently added integration with the latest APIs from SDRPlay. Its latest version runs well on Widows, Android, OSX and Macs using the M series of chips. But the learning curve of SDRAngel is steep and its interface is very austere. Ideally I would love to see the functionality of SDRAngel with a GQRX interface. Another factor to bear in mind is that finally SDRPlay is developing software for Mac with SDRConnect. But SDRConnect is far from a finished product (still in “Preview” mode). Not having GQRX work with SDRPlay is not a deal breaker but I would enjoy being able to use it with my RSP1A. Regards Axel ——— Original message received from "AsciiWolf" ***@***.***> on 06/06/2024 03:22:34 ———

…

@simplio <https://github.com/simplio> Did you try asking SDRplay directly to add support for their devices in Gqrx for Windows? As far as I know, the biggest problem is that SoapySDRPlay3 needs to be compiled against the API installed on the system. So, if end-user had a different version of that API, it most likely would not work. And bundling SDRplay libraries and other parts of the API directly with Gqrx is against the SDRplay license. Don't get me wrong, I really like my RSPdx, but I must agree with Clayton on this. — Reply to this email directly, view it on GitHub <#1351 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2P2IKR5METMCK2V7YTACFTZF6MTVAVCNFSM6AAAAABHC3YF26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJRGEYTKNRVGU>. You are receiving this because you commented.Message ID: ***@***.***>

[vladisslav2011]

From my perspective adding SDRPlay family of devices support to a free software like Gqrx would require reverse-engineering the proprietary MSi2500 firmware, writing a free firmware alternative (AFAIK 3 different firmware images are required to run all flavours of SDRPlay devices) and writing a support library (libmirisdr may be a good starting point).

[bricewge]

I didn't take the time to try it yet, but I think all the bricks are there to support RSP1b in gqrx. And it could be done without the pesky SDRplay RSP API.

It should be achievable by using the Soapy driver https://github.com/ericek111/SoapyMiri together with the library https://github.com/ericek111/libmirisdr-5. Currently, libmirisdr-5 doesn't support RSP1b but adding it doesn't look too complicated when seeing how the support for RSP2 was added.

[Axpelle]

That is indeed very encouraging to hear. I am computer savvy but certainly not a coder and it’s my sincere hope that this goal will be achieved in the next release. ——— Original message received from "Brice Waegeneire" ***@***.***> on 07/06/2024 11:45:36 ———

…

I didn't take the time to try it yet, but I think all the bricks are there to support RSP1b in gqrx. And it could be done without the pesky SDRplay RSP API. It should be achievable by using the Soapy driver https://github.com/ericek111/SoapyMiri together with the library https://github.com/ericek111/libmirisdr-5. Currently, libmirisdr-5 doesn't support RSP1b but adding it doesn't look too complicated when seeing how the support for RSP2 <ericek111/libmirisdr-5@4c7f505> was added. — Reply to this email directly, view it on GitHub <#1351 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2P2IKXUM3BTSO62ER7BR53ZGFQKBAVCNFSM6AAAAABHC3YF26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJUGI4DANRVHA>. You are receiving this because you commented.Message ID: ***@***.***>

[nmaster2042]

I think the best way to add support of SDRPlay devices, is to improve soapySDR integration into Gqrx as I stated in another issue.

The actual SoapySDR support in gr-osmosdr is quite limited, all device options aren't available, and for SDRPlay devices family it just makes it not usable.

I haven't skills to to it by myself but I think, the best way would be to replace old, unmaintained gr-osmosdr by gr-soapy witch is now part of GNU Radio if my understanding is correct.

But to do this, it requires a lot of dev work.

I hope something like this will be developed one day.

Then, any new SDR getting a SoapySDR driver would be supported into Gqrx.

[Axpelle]

Let’s keep fingers crossed 🤞 ———— Original message received from "nmaster2042" ***@***.***> on 10/06/2024 18:43:44 ———— Subject Re: [gqrx-sdr/gqrx] Hardware Request: SDRPlay API 3.14 and RSP1b for Windows Version (Issue #1351)

…

I think the best way to add support of SDRPlay devices, is to improve soapySDR integration into Gqrx as I stated in another issue. The actual SoapySDR support in gr-osmosdr is quite limited, all device options aren't available, and for SDRPlay devices family it just makes it not usable. I haven't skills to to it by myself but I think, the best way would be to replace old, unmaintained gr-osmosdr by gr-soapy witch is now part of GNU Radio if my understanding is correct. But to do this, it requires a lot of dev work. I hope something like this will be developed one day. Then, any new SDR getting a SoapySDR driver would be supported into Gqrx. — Reply to this email directly, view it on GitHub <#1351 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2P2IKUUTOQ3533YEDPCMDTZGW3SBAVCNFSM6AAAAABHC3YF26VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNJYGU2TQNJXG4>. You are receiving this because you commented.Message ID: ***@***.***>