Add native ADALM-Pluto and Pluto+ multi-channel RX/TX support

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?

What

Add native support for Analog Devices ADALM-Pluto and Pluto+ devices as full receive and transmit SDR backends in AetherSDR.

The implementation should support both connection methods from the initial release:

• USB
• Ethernet / network IIO

Ethernet support should be considered a day-one requirement, not a later enhancement.

AetherSDR should detect the capabilities of the connected hardware rather than assuming a fixed number of RF channels.

For example:

• Standard ADALM-Pluto configurations may expose a single RX/TX signal path.
• Pluto+ hardware can expose 2 RX and 2 TX channels.

Each available RX and TX channel should be independently selectable and controllable.

From the user's perspective, AetherSDR should be able to:

• Discover or connect to a Pluto over USB
• Connect to a Pluto using its hostname or IP address over Ethernet
• Receive and display IQ from any available RX channel
• Transmit IQ using any available TX channel
• Tune RX and TX frequencies independently
• Control RX gain and TX attenuation/gain
• Use AetherSDR's normal SSB/DSP/audio processing
• Operate full duplex where supported
• Support multiple RX channels simultaneously where the hardware supports it

The primary use case is QO-100 satellite operation, where Pluto-family devices are widely used as compact full-duplex SDR transceivers.

Why

SDR Console is popular with QO-100 operators because it provides integrated RX and TX support for Pluto-family SDRs.

Many QO-100 installations also use the Pluto over Ethernet rather than USB. This allows the SDR to be installed closer to the RF equipment or dish while the operating computer remains elsewhere on the network.

Requiring USB would unnecessarily restrict these installations and would make AetherSDR less useful as a replacement for applications such as SDR Console.

Native Pluto support would allow a complete QO-100 station to operate directly from AetherSDR without requiring another SDR application alongside it.

It would also add a reusable foundation for other transmit-capable and multi-channel SDR devices in future.

How Other Clients Do It

SDR Console

SDR Console treats Pluto-family hardware as a complete SDR transceiver and is commonly used for QO-100.

Typical functionality includes:

• RX
• TX
• Full-duplex operation
• Independent RX/TX tuning
• Spectrum and waterfall
• Gain/power control
• USB-connected devices
• Network-connected Pluto devices

This is broadly the level of integration AetherSDR should aim to provide.

GQRX

GQRX supports Pluto reception through standard SDR/IIO interfaces, demonstrating that network and USB Pluto access can be abstracted from the application UI.

Its normal workflow is primarily receive-oriented, however, rather than providing the integrated RX/TX satellite-station experience required here.

SDR++

SDR++ demonstrates the advantage of placing SDR hardware behind a common device/backend abstraction.

A similar approach in AetherSDR would allow the Pluto implementation to expose device capabilities such as:

RX channels: 2
TX channels: 2
Full duplex: Yes
Connection: Ethernet

rather than putting Pluto-specific assumptions into GUI code.

Suggested Behavior

Pluto should appear as a selectable radio/device backend.

For example:

Radio / Device
  ADALM-Pluto
    USB
      PlutoSDR [serial number]

    Network
      pluto.local
      192.168.1.50
      Add network device...

A user should be able to select Add network device... and enter either:

pluto.local

or:

192.168.1.50

AetherSDR should then connect using the appropriate network IIO interface.

Previously configured network devices should be remembered and shown in the device list.

When a multi-channel device such as Pluto+ is connected:

• Each RxApplet should be able to select RX1, RX2, etc.
• Multiple RxApplet instances should be able to use separate RX channels.
• TX configuration should allow selection of TX1, TX2, etc.
• Frequency and gain should be independently controlled per channel where supported.
• The UI should expose only the channels reported by the connected hardware.

For normal operation:

• VfoWidget should control the assigned RX frequency.
• RxApplet should display spectrum/waterfall data from the selected RX channel.
• Pressing PTT should route AetherSDR's TX audio/DSP output to the selected TX channel.
• AetherSDR's existing TX indication and controls should be reused where possible.

For QO-100 it should be possible to configure displayed frequencies such as:

RX: 10.489 GHz
TX:  2.400 GHz

while using configurable LO/transverter offsets so the operator sees actual satellite frequencies.

Connection method should not affect the operating experience. Once connected, an Ethernet Pluto should behave the same way as a USB Pluto.

Protocol Hints

This is not primarily a FlexLib/SmartSDR protocol feature.

The most likely interface is Analog Devices libiio, which supports local/USB and network-accessible IIO devices.

The backend should investigate support for connection contexts equivalent to:

USB / local IIO

and:

ip:192.168.1.50
ip:pluto.local

The implementation should ideally separate:

Pluto device backend
        |
        +-- USB transport
        |
        +-- Network IIO transport

from the higher-level AetherSDR RX/TX abstractions.

Device capability discovery should determine:

• Number of RX channels
• Number of TX channels
• Supported sample rates
• Gain/attenuation ranges
• Full-duplex capability
• Available RF ports

RX/TX streaming, latency, buffering, sample-rate conversion and interaction with AetherSDR's existing DSP/audio chain will need research.

Acceptance Criteria

• AetherSDR can detect and connect to a Pluto-family SDR over USB.
• AetherSDR can connect to a Pluto-family SDR over Ethernet using hostname or IP address.
• Network-connected and USB-connected devices provide equivalent RX/TX functionality.
• AetherSDR discovers the available RX/TX channels rather than assuming a single RX and TX.
• Pluto+ can expose and independently use its available RX1/RX2 and TX1/TX2 channels.
• Pluto RX produces a usable AetherSDR spectrum/waterfall with frequency and gain control.
• AetherSDR can transmit SSB through the selected Pluto TX channel using its normal microphone/DSP/PTT path.
• RX and TX frequencies can be independently configured, including offsets suitable for QO-100 operation.
• Switching between Pluto and existing FlexRadio backends does not break normal FlexRadio operation.

Start by locating AetherSDR's existing radio/device backend abstractions and the RxApplet, VfoWidget, and TX control entry points mentioned in the request. Investigate how libiio could provide both USB and network contexts, then map capability discovery and streaming requirements to those abstractions. Done means the acceptance criteria are met for USB, Ethernet, RX/TX channel discovery, independent control, and coexistence with FlexRadio backends.