Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Hardware Request: SDRPlay API 3.14 and RSP1b for Windows Version #1351

Open
simplio opened this issue May 2, 2024 · 15 comments
Open

Hardware Request: SDRPlay API 3.14 and RSP1b for Windows Version #1351

simplio opened this issue May 2, 2024 · 15 comments
Labels

Comments

@simplio
Copy link

simplio commented May 2, 2024

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
Copy link
Member

argilo commented May 2, 2024

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.

@argilo argilo added the feature label May 2, 2024
@Axpelle
Copy link

Axpelle commented May 4, 2024

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
Copy link
Member

argilo commented May 4, 2024

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
Copy link
Author

simplio commented May 5, 2024

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
Copy link
Member

argilo commented May 5, 2024

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
Copy link

Axpelle commented May 6, 2024

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

@argilo
Copy link
Member

argilo commented May 6, 2024

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
Copy link

Axpelle commented May 6, 2024

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

@AsciiWolf
Copy link
Contributor

@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
Copy link

Axpelle commented Jun 6, 2024 via email

@vladisslav2011
Copy link
Contributor

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
Copy link

bricewge commented Jun 7, 2024

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
Copy link

Axpelle commented Jun 7, 2024 via email

@nmaster2042
Copy link

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
Copy link

Axpelle commented Jun 10, 2024 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

7 participants