Report preparation
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:
-
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.
-
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
- Open a slice and enable diversity from the VFO flag. Confirm the pair forms
and is working — two flags merged into a diversity pair.
- Open a second slice.
- Enable diversity on the second slice.
- 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:
-
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.
-
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
AetherSDR version
v26.9.1
Radio model & firmware
FLEX-8600, firmware 4.2.20.41343
Operating system
Windows
OS version and hardware
Windows 11
Report preparation
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:
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.
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
and is working — two flags merged into a diversity pair.
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
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:
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.
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:
slice set <index> diversity=1lines of
diversity=,diversity_parent=,diversity_child=,diversity_index=The specific questions a capture should answer:
0|acknowledgement to the seconddiversity request?
or does AetherSDR send its own teardown?
platform capability table?
Related
(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