-
Notifications
You must be signed in to change notification settings - Fork 545
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
Comments
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. |
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. |
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. |
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" A paradox. I want to hear Alexandru Csete OZ9AEC opinion on this. It is ultimately his software. |
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. |
The paradox is still there. Microsoft's credo is closed and proprietary source. |
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. |
Well let's hope a platform agnostic developer reads this and provides connectivity between SDRPlay and GQRX. |
@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. |
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:
***@***.***>
|
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). |
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. |
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:
***@***.***>
|
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. |
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:
***@***.***>
|
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
The text was updated successfully, but these errors were encountered: