aethersdr / aethersdr/AetherSDR
Native SDRplay RSP Support in AetherSDR
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 221
- Forks
- 117
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 299
Description
Request preparation
- I used an AI assistant to help structure this request
- I checked for existing issues covering the same feature
What would you like?
Feature Request
Please add native support for SDRplay RSP receivers to AetherSDR.
SDRplay produces a very capable range of SDR receivers, including the RSP1A, RSP1B, RSP2, RSP2pro, RSPduo and RSPdx/RSPdx-R2. SDRplay provides an official, documented API for controlling these devices.
The goal would be to allow an SDRplay receiver to be selected and operated directly from AetherSDR, without requiring SDRuno, SDRconnect, a virtual audio device, or an additional bridge application.
Desired functionality
A native SDRplay backend should provide, where supported by the individual RSP model:
Device detection and selection
Frequency tuning
Sample-rate selection
Gain control
RF gain / LNA control
IF bandwidth selection
Antenna/input selection
Bias-T control where supported
AGC control
IQ data streaming
Panadapter and waterfall display
Multiple receiver channels where supported, especially for the RSPduo
Correct handling of device capabilities and limitations
Clean connect/disconnect and device recovery
The SDRplay implementation should use the official SDRplay API rather than depending on an external application.
Why this would be valuable
AetherSDR already provides an excellent native SDR interface and is designed to provide a modern amateur-radio workstation experience across Windows, Linux and macOS.
Adding native SDRplay support would make AetherSDR useful not only with FlexRadio hardware, but also as a high-quality general-purpose SDR receiver application.
This would be particularly useful for operators who already own an SDRplay RSP and would like to use the AetherSDR interface for spectrum monitoring, panadapter/waterfall operation, weak-signal reception and amateur-radio applications.
Important consideration
The implementation should respect the SDRplay API and licensing requirements. The SDRplay API is officially available for Windows, Linux and macOS and is the intended software interface for controlling SDRplay hardware.
Ideally, SDRplay support should be implemented as a native AetherSDR hardware backend, rather than requiring users to install and run another SDR application in parallel.
Suggested initial scope
A first implementation could focus on reliable receive-only operation of the most common RSP models, for example:
RSP1A / RSP1B / RSP2 / RSPdx
with additional models and advanced features added incrementally.
Once the basic SDRplay backend is stable, features such as RSPduo dual-tuner operation could be added.
Expected result
After connecting an SDRplay RSP, the user should be able to select something like:
Radio → SDRplay → RSPdx
and immediately get a fully integrated AetherSDR panadapter and waterfall, with frequency, bandwidth, gain and other supported receiver parameters controlled directly from AetherSDR.
This would make SDRplay receivers feel like a first-class hardware platform within AetherSDR.
Thank you for considering this feature request.
73
Martin
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the existing FlexRadio hardware integration and the application's radio-selection path; the issue does not identify files or tests. Confirm the SDRplay API licensing and build requirements, then define an initial receive-only scope for the listed RSP models. Done means an SDRplay receiver can be selected and operated natively with integrated tuning, gain, bandwidth, and IQ display support.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100