Enabling diversity on a second slice silently tears down the existing diversity pair

Report preparation

• I used the AI-assisted bug report tool (Help → Support → File an Issue)
• I have attached a support bundle or log file

What happened?

Enabling diversity on a second slice silently tears down the existing diversity pair

What happened

On a FLEX-8600 with a diversity pair already running, enabling diversity on a
second slice brings up a working second pair — and breaks the first one at the
same moment.

The first pair's two antennas separate back into two independent slices, each
with its own flag, and it is no longer operating in diversity. The net result
is one working diversity pair instead of two.

The loss is silent. No dialog, no toast, no status-bar message, nothing in the
VFO flag to say the first pair was dropped. The only way to notice is to look
back at the first pair's flags and see that they have split.

What did you expect?

What I expected

Either of these would be acceptable:

1. If two simultaneous diversity pairs are supported by the radio — both
   pairs are held at once, and enabling the second does not disturb the first.

2. If the radio cannot hold two diversity pairs (see "Suggested fix" below —
   this looks like the likely case) — AetherSDR declines the second diversity
   request with a clear, specific reason, and leaves the running pair alone.
   Something like: "Diversity is already active on Slice A/B. This radio has
   two SCUs and can hold one diversity pair at a time. Disable diversity on
   Slice A/B first."

What should not happen under any interpretation is the current behavior:
quietly dismantling a pair the operator has already set up and is actively
using, in order to satisfy a later request.

Steps to reproduce

Steps to reproduce

1. Open a slice and enable diversity from the VFO flag. Confirm the pair forms
   and is working — two flags merged into a diversity pair.
2. Open a second slice.
3. Enable diversity on the second slice.
4. Observe: the second slice comes up as a working diversity pair. Look back at
   the first slice — its pairing has broken and its two antennas are now two
   independent slices with separate flags.

No warning or message appears at any point in step 3 or 4.

Environment

• AetherSDR v26.9.1
• OS Windows
• Radio FLEX-8600, firmware 4.2.20.41343
• AetherSDR also holds the PGXL, TGXL and Antenna Genius in the same session

Suggested fix

I suspect the underlying constraint here is the radio, not AetherSDR: the
FLEX-8600 has two SCUs, a diversity pair consumes both, and so only one pair
can exist at a time. There is a FlexRadio community report of the same symptom
on a 6600M, where the second slice's diversity antenna ends up following the
first slice's main RX antenna.

If that is correct, the bug is not "the second pair failed" — it is that
AetherSDR issues the second diversity request unconditionally and lets the
radio silently drop the first pair, rather than checking the constraint and
saying so.

Two things worth checking:

1. Where does the teardown originate? Is AetherSDR sending anything that
   tears down the first pair, or is the radio doing it on its own and AetherSDR
   just reflecting the resulting slice status? A packet capture across step 3
   would settle this. If the radio initiates it, this is an unsolicited state
   change AetherSDR should surface to the user rather than absorb quietly.

2. Gate the control on capability. v26.7.1 moved diversity capability to the
   FlexLib platform table. If that table exposes SCU count, the diversity toggle
   on a second slice could be disabled (greyed with a tooltip explaining why)
   while a pair is already live, instead of being offered and then silently
   costing the operator their existing pair.

A pre-flight check plus a refusal message would fix this regardless of which
layer is doing the teardown.

Protocol Hints

Unknown — needs research. My rough understanding, which needs verifying against
FlexLib and a capture:

• Diversity is enabled per-slice, roughly slice set <index> diversity=1
• The radio reports diversity state back in slice status, with fields along the
  lines of diversity=, diversity_parent=, diversity_child=,
  diversity_index=

The specific questions a capture should answer:

• Does the radio return an error or a bare 0| acknowledgement to the second
  diversity request?
• Does the first pair's teardown arrive as an unsolicited slice status update,
  or does AetherSDR send its own teardown?
• Is SCU count or a diversity-pair budget exposed anywhere in the FlexLib
  platform capability table?

Related

• #5197 — Antenna Management and Diversity Control as first class applets
  (adjacent; a first-class diversity applet would be the natural home for the
  capability check and the refusal message)

AetherSDR version

v26.9.1

Radio model & firmware

FLEX-8600, firmware 4.2.20.41343

Operating system

Windows

OS version and hardware

Windows 11

Start by tracing the diversity toggle and the FlexLib platform capability table, then inspect slice-status handling for diversity_parent, diversity_child, and diversity_index. Capture the protocol while enabling diversity on a second slice to determine whether AetherSDR or the radio tears down the first pair. Done means the second request is safely refused with a clear message, or both pairs remain intact when supported.