Skip to content

Conversation

@stevenjoezhang
Copy link

@stevenjoezhang stevenjoezhang commented Oct 17, 2025

The purpose of this PR is to migrate the currently used SDRPlay API from v2 to v3. (Tested with v3.15.2)

Issue resolved: #783
Issue resolved: #1116
See also #1006

I have an SDRPlay RSP1 device, and I encountered crashes when using URH to open it on Apple Silicon macOS. I noticed that URH is still using the SDRPlay v2 API, which does not provide a macOS ARM64 library and relies on Rosetta, making it difficult to debug and fix. Therefore, I decided to migrate it to the SDRPlay v3 API.

截屏2025-10-18 上午1 03 21

Part of the migration was assisted by a large language model (mainly for defining data structures in csdrplay.pxd, as v3 introduces many new structs). I tested the SDRPlay RSP1 with the migrated code on both macOS and Windows and confirmed it works correctly. Since I don't have other SDRPlay models, I couldn't test them. If any issues are found, I'm happy to help investigate and fix.

Note: SDRplay v3 wraps some functionality into a system service. Users must manually install the SDRplay API (from https://www.sdrplay.com/) for their platform and start the API server before it can be used.

Screenshot on macOS:

截屏2025-10-18 下午9 25 41

Screenshot on Windows:

截屏2025-10-18 下午11 32 16

@CLAassistant
Copy link

CLAassistant commented Oct 17, 2025

CLA assistant check
All committers have signed the CLA.

@stevenjoezhang
Copy link
Author

stevenjoezhang commented Oct 18, 2025

Known issue: The SDRPlay v3 API requires a relatively long time (around 2 seconds) to close stream, release the device, and close the API. The main process has a default timeout of 1 second, after which it terminates the subprocess. If the subprocess is killed before it completes its cleanup (closing the API), it can leave the SDRPlay device driver in an inconsistent state, preventing it from being reopened.
截屏2025-10-18 下午2 37 16

To address this, I temporarily increased the timeout to 3 seconds.

@stevenjoezhang stevenjoezhang marked this pull request as ready for review October 18, 2025 06:37
@stevenjoezhang
Copy link
Author

stevenjoezhang commented Oct 19, 2025

The CI builds succeeded on macOS and Linux (https://github.com/stevenjoezhang/urh/actions/runs/18631182001/job/53116057036), but fail on Windows; I'm working on a fix: jopohl/sdrbuild#14. There's actually a circular dependency between URH and sdrbuild, so the checks didn't pass.

To build & test URH with SDRplay support on Windows:

Download and install SDRplay API v3.15 for Windows, then copy its dll C:\Program Files\SDRplay\API\x64\sdrplay_api.dll to "C:\Windows\System32". (Maybe not the best practice, but it works.)

Run the following commands in PowerShell to build and install the Python package with SDRplay support:

git clone -b sdrplay-v3 https://github.com/stevenjoezhang/urh
$inc = 'C:\Program Files\SDRplay\API\inc'
$lib = 'C:\Program Files\SDRplay\API\x64'
python setup.py build_ext --with-sdrplay -I "$inc" -L "$lib"
python setup.py install --with-sdrplay
urh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

SDRplay support in current devices Add support for SDRPlay v3 API

2 participants