aethersdr / aethersdr/AetherSDR

Add generic radio USB serial passthrough support for peripherals

Open
#4,601 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement external devices GUI maintainer-review protocol
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?

What

Add reusable support for USB serial devices connected to the rear USB ports of a FlexRadio.

AetherSDR should be able to discover compatible USB-to-serial cables attached to the radio and exchange serial data with them through the radio connection. Peripheral implementations could then use the same transport abstraction as a local serial port or network serial server.

This would allow features such as amplifier control to work when the amplifier is connected directly to the radio, rather than requiring:

  • The amplifier to be connected to the computer running AetherSDR
  • A separate computer at the radio site
  • A separately configured ser2net instance
  • A dedicated Ethernet interface in the peripheral

PR #4531 is an immediate example. Its SPE amplifier integration supports a local serial connection or ser2net, but it should also be possible to select a compatible USB serial cable connected to the radio.

This should be implemented as a generic transport rather than being limited to one amplifier model.

Why

Connecting station peripherals to the radio is particularly useful for remote operation.

When using AetherSDR remotely, a serial device connected to the operator's computer is not physically located with the radio and amplifier. Running ser2net at the station works, but requires another computer or network device, additional configuration, and another service that can fail.

The radio is already network-connected and has USB ports intended for supported USB-to-serial cables. Exposing those cables to AetherSDR would provide a simpler remote-station architecture:

Peripheral
    ↕ RS-232
Compatible USB-to-serial cable
    ↕ USB
FlexRadio
    ↕ Radio TCP connection
AetherSDR

A shared passthrough implementation could subsequently be used by:

  • SPE Expert amplifiers
  • ACOM amplifiers
  • Antenna controllers
  • Rotator controllers
  • Tuner controllers
  • AMBE devices
  • Other serial station accessories

Related issue #523 proposes radio-attached USB passthrough specifically for an AMBE dongle. This request is broader: it proposes a reusable peripheral transport that can be consumed by any compatible AetherSDR feature.

How Other Clients Do It

SmartSDR supports serial passthrough for compatible USB-to-serial cables connected to the radio.

On Windows, SmartSDR CAT can expose the remote connection as a virtual COM port. Existing third-party software can then use that COM port without needing to know that the physical cable is attached to the radio.

AetherSDR does not necessarily need to reproduce the virtual COM-port layer. Its built-in peripherals could communicate directly through a common radio USB transport.

Applications such as GQRX and SDR++ generally treat external serial hardware as a locally available operating-system device. They do not provide an equivalent FlexRadio radio-side USB transport because they do not control FlexRadio hardware.

Suggested Behavior

Radio Setup

Add a USB Devices or Radio USB section under:

Radio Setup → Peripherals

The section should:

  1. Enumerate compatible USB-to-serial cables reported by the connected radio.

  2. Show useful identifying information, where available:

    • Cable serial number
    • Configured name
    • Cable type
    • Baud rate
    • Current assignment
  3. Show whether each cable is available, in use, unsupported, or disconnected.

  4. Allow the list to be refreshed.

  5. Avoid silently reconfiguring a cable already assigned to another function.

Example:

Radio USB devices

┌──────────────────────────────────────────────────────────────┐
│ Serial       Name             Type          Status           │
│ FT9ABC12     SPE Amplifier    Passthrough   Available        │
│ FT4DEF34     Band Data        CAT            In use           │
└──────────────────────────────────────────────────────────────┘

[ Refresh ]
Peripheral configuration

Peripheral settings should offer a common connection selector:

Connection:

( ) Local serial port
( ) Network serial server
( ) Radio USB passthrough

When Radio USB passthrough is selected, show:

  • Attached radio
  • USB cable selector
  • Baud rate
  • Data bits
  • Parity
  • Stop bits
  • Flow-control options where supported
  • Connection and device-response status

For example, the SPE amplifier added by PR #4531 could appear in the AppletPanel as normal while its settings use the selected radio USB cable rather than a local QSerialPort or ser2net connection.

The amplifier applet should not otherwise need to know which transport is being used.

Shared transport abstraction

Introduce a common byte-stream interface that can be implemented by:

  • Local serial
  • Raw TCP/ser2net
  • RFC 2217
  • FlexRadio USB passthrough

Peripheral protocol classes should send and receive bytes through this abstraction rather than directly depending on QSerialPort or QTcpSocket.

Connection loss should be represented consistently in the relevant AppletPanel applet:

  • Connected
  • Reconnecting
  • Cable unavailable
  • Radio firmware unsupported
  • Cable claimed by another function
  • Peripheral not responding

When operating through SmartLink, AetherSDR should continue using the radio USB transport without requiring direct LAN access to a separate ser2net server.

Protocol Hints

The FlexRadio API appears to expose USB cable discovery, configuration, and passthrough through the usb_cable command/status family.

Likely operations include:

usb_cable list
usb_cable set <serial> type=passthrough ...
usb_cable write <serial> ...

Incoming serial data may be delivered through usb_cable status messages, potentially with a base64-encoded payload.

The exact commands, status-message format, supported firmware versions, payload limits, flow-control support, ownership semantics, and SmartLink behaviour need to be verified against current FlexRadio protocol documentation or captured SmartSDR traffic.

The implementation should not assume that arbitrary USB devices are supported. FlexRadio radios generally expose supported USB-to-serial adapters rather than functioning as general-purpose USB-over-IP hosts.

Acceptance Criteria

  • AetherSDR can enumerate compatible USB-to-serial cables attached to the connected FlexRadio.
  • A built-in peripheral can select a radio-attached cable and exchange bidirectional serial data without ser2net.
  • The passthrough implementation is reusable by multiple peripheral types and is not tied to a particular amplifier.
  • Local serial, network serial, and radio USB connections present consistent status and reconnection behaviour.
  • Unsupported firmware, disconnected cables, conflicting cable assignments, and SmartLink restrictions produce clear user-visible errors without disrupting radio operation.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by verifying the FlexRadio usb_cable protocol against current documentation or captured SmartSDR traffic, including discovery, passthrough, status, ownership, and SmartLink behavior. Then inspect the existing AppletPanel connection handling and the local QSerialPort or QTcpSocket integrations to define the shared transport boundary. Done means reusable bidirectional radio USB transport, peripheral selection, consistent reconnection status, and clear handling of unsupported or conflicting devices.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
backend-api-design, desktop
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.