Multiple TCI Server Ports (one for each slice)

Open
#1,353 7 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
42/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
cpp

Research direction

Start by locating the existing TCI server and reviewing how RxApplet, AppletPanel, VfoWidget, and AppSettings represent slices and settings. Confirm how the current single-port behavior is preserved before defining per-slice listeners and command routing. Done means unique persisted ports, clear UI status, simultaneous independent WSJT-X connections, and no regression for single-slice use.

Written by the indexing model from the issue text.

Description

awaiting-response enhancement priority: low protocol
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?

No duplicates found (the repository currently has 0 open issues).

Here is the complete, ready-to-post FEATURE REQUEST issue (copy-paste directly into a new GitHub issue at https://github.com/ten9876/AetherSDR/issues/new):


Title:
Support separate unique TCI server ports for each Slice

Labels (add these):
enhancement, protocol, external devices

What

AetherSDR’s built-in TCI server should expose a unique, configurable TCP port for each Slice. Users would then be able to run a separate WSJT-X (or other TCI/CAT client) instance for every Slice, each connected to its own dedicated TCI port.

Why

Right now the TCI server runs on a single shared port. This makes it impossible to give each Slice independent CAT control, so multiple WSJT-X instances cannot be used at the same time (they all fight over the same port and commands get mixed up). Many operators want to run digital modes on several slices/bands simultaneously; the current design blocks that workflow.

How Other Clients Do It

  • SmartSDR (FlexRadio’s official Windows client) supports multiple slices and provides per-slice CAT control (via its built-in server or virtual COM ports), allowing independent WSJT-X instances to control individual slices without conflict.
  • GQRX and SDR++ expose configurable or per-receiver CAT/TCI interfaces that can be bound independently, enabling the same multi-instance digital-mode workflow users expect on Linux-native SDR clients.

Suggested Behavior

  • Add a “TCI Port” numeric field inside the RxApplet (or a new compact TCI applet in the AppletPanel) for each Slice.
  • The field defaults to something like 50001 for Slice 0 and auto-increments for additional slices (user-editable).
  • A global “Enable TCI Server” toggle (already present or added in Settings) would start one listener per Slice on its assigned port.
  • The VfoWidget (or slice header in the main window) displays the assigned TCI port for that slice so the user can quickly tell WSJT-X which port to use.
  • When a TCI client connects to a slice-specific port, all CAT commands (frequency, mode, PTT, etc.) are routed exclusively to that Slice’s model.
  • No UI changes are required for single-slice users; the existing single-port behavior remains available as a fallback.

Protocol Hints

Unknown — needs research (TCI server is implemented inside AetherSDR; it is not part of the core FlexLib protocol).

Acceptance Criteria

  • Each Slice can be assigned its own unique TCI port (persisted via AppSettings).
  • Multiple WSJT-X instances can connect simultaneously to different slice ports and control their respective slices independently (frequency, mode, PTT, etc.) with no cross-slice interference.
  • Single-slice / single-port usage continues to work exactly as today (full backward compatibility).
  • UI elements (RxApplet, VfoWidget, AppletPanel) clearly show per-slice TCI ports and status.
  • No regression to core RX/TX flow or Slice 0 behavior; tested on a FLEX-8600 (or equivalent) with firmware v1.4.0.0+.

You can post this exactly as-is. It follows the exact template you asked for, references the UI elements you mentioned, and is ready for the maintainer (or any AI contributor following CLAUDE.md) to pick up.

Dominant language
C++
Stars
221
Forks
117
Avg merge
2d 7h
Merged PRs (30d)
299

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.

More from aethersdr/AetherSDR

All issues in aethersdr/AetherSDR

Similar issues

More C++ issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.