Title:
support-bundle-20260531-115947.zip
What happened?
When operating with multiple slices open simultaneously, the squelch level appears to be globally shared rather than maintained independently for each slice.
I have two slices open on different bands with significantly different noise floors. To operate effectively, each slice requires a different squelch threshold. However, adjusting the squelch level on one slice immediately changes the squelch setting on the other slice as well.
As a result, it is impossible to optimize squelch independently for each receiver. Setting the squelch appropriately for one slice makes the setting incorrect for the other slice.
This behavior is especially noticeable when monitoring bands with substantially different background noise levels.
What did you expect?
Each slice should maintain its own squelch level and squelch state independently.
Changing the squelch control on Slice A should only affect Slice A. Slice B (and any other slices) should retain their existing squelch settings unless explicitly changed by the operator.
This matches the operational model used for many other slice-specific receiver controls and allows each receiver to be optimized for its own band conditions.
Steps to reproduce
Connect AetherSDR to a FLEX-6600.
Open two slices.
Tune the slices to different bands with noticeably different noise floors.
Enable squelch on both slices.
Adjust the squelch level on Slice A.
Observe that the squelch level on Slice B changes to the same value.
Adjust the squelch level on Slice B.
Observe that Slice A is updated to the new value as well.
Radio model & firmware
Radio: FLEX-6600
Firmware: 4.2.18.41174
OS & version
OS: Windows
AetherSDR Version: 26.5.3
Qt Version: 6.8.3
Developer Notes
This appears to be a state-management issue where squelch level is being stored or propagated as a global UI/application property rather than a per-slice property.
Relevant protocol behavior:
FlexRadio exposes squelch and squelch_level as slice-specific properties on the SmartSDR TCP/IP slice object. The radio protocol associates these settings with individual slice receivers rather than with the radio globally.
Areas of the codebase likely involved:
Slice model classes that represent radio slice state.
Slice command handlers that process squelch_level updates from the radio.
UI controls bound to squelch settings.
Any settings persistence layer that stores receiver parameters.
View-model synchronization code between the radio state model and Qt widgets.
Potential root causes:
Multiple slice widgets are bound to a shared squelch property rather than a slice-specific property.
A singleton or global settings object is being used for squelch level.
Signal/slot wiring is updating all slice instances when one squelch control changes.
Persistence restoration logic is overwriting per-slice values with a single shared value.
Slice update processing is applying incoming squelch_level events to all slices instead of the targeted slice ID.
Suggested diagnostics:
Enable logging from Help → Support that captures:
Flex protocol command transmission.
Flex protocol status/event reception.
Slice creation/destruction events.
Slice state synchronization.
Model/view binding updates.
Settings persistence and restoration activity.
Useful evidence would include:
The outbound command generated when changing squelch on one slice.
Any inbound status messages showing whether the radio reports a change for only the selected slice or for multiple slices.
Logs showing how AetherSDR routes the resulting update into the slice model.
Expected protocol behavior:
When changing the squelch level of one slice, AetherSDR should send a slice-specific squelch_level command and only update the corresponding slice model instance. Other slices should retain their existing squelch settings unless the radio explicitly reports changes for those slices.
Title:
support-bundle-20260531-115947.zip
What happened?
When operating with multiple slices open simultaneously, the squelch level appears to be globally shared rather than maintained independently for each slice.
I have two slices open on different bands with significantly different noise floors. To operate effectively, each slice requires a different squelch threshold. However, adjusting the squelch level on one slice immediately changes the squelch setting on the other slice as well.
As a result, it is impossible to optimize squelch independently for each receiver. Setting the squelch appropriately for one slice makes the setting incorrect for the other slice.
This behavior is especially noticeable when monitoring bands with substantially different background noise levels.
What did you expect?
Each slice should maintain its own squelch level and squelch state independently.
Changing the squelch control on Slice A should only affect Slice A. Slice B (and any other slices) should retain their existing squelch settings unless explicitly changed by the operator.
This matches the operational model used for many other slice-specific receiver controls and allows each receiver to be optimized for its own band conditions.
Steps to reproduce
Connect AetherSDR to a FLEX-6600.
Open two slices.
Tune the slices to different bands with noticeably different noise floors.
Enable squelch on both slices.
Adjust the squelch level on Slice A.
Observe that the squelch level on Slice B changes to the same value.
Adjust the squelch level on Slice B.
Observe that Slice A is updated to the new value as well.
Radio model & firmware
Radio: FLEX-6600
Firmware: 4.2.18.41174
OS & version
OS: Windows
AetherSDR Version: 26.5.3
Qt Version: 6.8.3
Developer Notes
This appears to be a state-management issue where squelch level is being stored or propagated as a global UI/application property rather than a per-slice property.
Relevant protocol behavior:
FlexRadio exposes squelch and squelch_level as slice-specific properties on the SmartSDR TCP/IP slice object. The radio protocol associates these settings with individual slice receivers rather than with the radio globally.
Areas of the codebase likely involved:
Slice model classes that represent radio slice state.
Slice command handlers that process squelch_level updates from the radio.
UI controls bound to squelch settings.
Any settings persistence layer that stores receiver parameters.
View-model synchronization code between the radio state model and Qt widgets.
Potential root causes:
Multiple slice widgets are bound to a shared squelch property rather than a slice-specific property.
A singleton or global settings object is being used for squelch level.
Signal/slot wiring is updating all slice instances when one squelch control changes.
Persistence restoration logic is overwriting per-slice values with a single shared value.
Slice update processing is applying incoming squelch_level events to all slices instead of the targeted slice ID.
Suggested diagnostics:
Enable logging from Help → Support that captures:
Flex protocol command transmission.
Flex protocol status/event reception.
Slice creation/destruction events.
Slice state synchronization.
Model/view binding updates.
Settings persistence and restoration activity.
Useful evidence would include:
The outbound command generated when changing squelch on one slice.
Any inbound status messages showing whether the radio reports a change for only the selected slice or for multiple slices.
Logs showing how AetherSDR routes the resulting update into the slice model.
Expected protocol behavior:
When changing the squelch level of one slice, AetherSDR should send a slice-specific squelch_level command and only update the corresponding slice model instance. Other slices should retain their existing squelch settings unless the radio explicitly reports changes for those slices.