Report preparation
What happened?
What happened?Despite the fixes in v0.8.16, the compression (Gain Reduction) meter remains erratic and appears to be inversely correlated with signal strength. In side-by-side testing with SmartSDR (SSDR), AetherSDR exhibits a non-linear response where low input signals trigger high compression readings, while actual compression events (high input levels) result in the meter returning to zero.The user noted that these specific values are subject to the peak-to-average ratio of their voice, but the trend remains consistently inverted across v0.8.16 and v0.8.17.Observed Data Comparison:MIC Level (dB)ASDR Meter (v0.8.16/17)SSDR Meter (v4.1.5)Behavior Note-4000Correct-30-300Erroneous high compression-20-(10-15)-5Inverted scaling-10-(2-3)-15Reads lower as input increases0+0-20Shows no compression at peakThe issue persists on Windows 11 with the internal Processor set to DX+. The signal chain is MIC-to-radio, bypassing PC audio inputs, with EQ and VOX de-expander disabled.What did you expect?The meter should track the actual gain reduction applied by the FlexRadio DSP. As the MIC level increases above the processor threshold, the meter should deflect further downward. It should not peak at low input levels (-30 dB) and then retreat toward zero as the signal gets louder.Steps to reproduceUse AetherSDR v0.8.17 on Windows 11.Set Radio to USB, Enable Processor (DX+), and disable TX EQ.Apply a low-level input (~ -30 dB on MIC meter).Observe AetherSDR showing high reduction (~ -30) while SSDR shows 0.Increase input to 0 dB.Observe AetherSDR returning to 0 while SSDR shows deep compression (~ -20).Radio model & firmwareModel: FLEX-6600Firmware: 4.1.5.39794OS & versionOS: Windows 11 (AetherSDR v0.8.17 / Qt 6.7.3)Developer NotesRoot Cause Re-Evaluation:The data provided in the table suggests that the logic implemented in PR #1580 may not be producing the intended results in a live environment, particularly on Windows 11.Specifically, at a MIC level of -30 dB, ASDR is showing -30. This strongly suggests the UI is still displaying the raw COMPPEAK dBFS level as if it were a reduction value. When the signal hits 0 dB (peak), the COMPPEAK level also approaches 0 dBFS, which the UI interprets as "0 dB reduction," causing the "return to zero" behavior reported.Potential Logic Failure Points:src/models/MeterModel.cpp: The calculation reduction = m_afterEq - m_compPeakRaw depends on both meters being updated. If m_afterEq (Meter 27) is not being correctly subscribed to or updated on Windows 11, the calculation may be defaulting to 0 - m_compPeakRaw, which would perfectly recreate the inverted readings seen in the user's table.Peak-to-Average Dynamics: The user noted the role of peak-to-average ratios. If AFTEREQ and COMPPEAK have different ballistics or integration times in the Flex API, a simple subtraction might produce the "jitter" or non-linear jumps reported as the two values move at different speeds.Suggested Diagnostics:Please verify if AFTEREQ (ID 27) is correctly requested in the sub meter command strings within src/core/radio/FlexRadio.cpp.Logging: Please enable radio.responses and gui.updates in Help → Support and provide a log capturing a transition from silence to loud speech (0 dB MIC level). This will confirm if Meter 27 data is actually arriving and being used in the subtraction.
support-bundle-20260419-093152.zip
What did you expect?
No response
Steps to reproduce
No response
Radio model & firmware
No response
Linux distro & Qt version
Windows 11
Report preparation
What happened?
What happened?Despite the fixes in v0.8.16, the compression (Gain Reduction) meter remains erratic and appears to be inversely correlated with signal strength. In side-by-side testing with SmartSDR (SSDR), AetherSDR exhibits a non-linear response where low input signals trigger high compression readings, while actual compression events (high input levels) result in the meter returning to zero.The user noted that these specific values are subject to the peak-to-average ratio of their voice, but the trend remains consistently inverted across v0.8.16 and v0.8.17.Observed Data Comparison:MIC Level (dB)ASDR Meter (v0.8.16/17)SSDR Meter (v4.1.5)Behavior Note-4000Correct-30-300Erroneous high compression-20-(10-15)-5Inverted scaling-10-(2-3)-15Reads lower as input increases0+0-20Shows no compression at peakThe issue persists on Windows 11 with the internal Processor set to DX+. The signal chain is MIC-to-radio, bypassing PC audio inputs, with EQ and VOX de-expander disabled.What did you expect?The meter should track the actual gain reduction applied by the FlexRadio DSP. As the MIC level increases above the processor threshold, the meter should deflect further downward. It should not peak at low input levels (-30 dB) and then retreat toward zero as the signal gets louder.Steps to reproduceUse AetherSDR v0.8.17 on Windows 11.Set Radio to USB, Enable Processor (DX+), and disable TX EQ.Apply a low-level input (~ -30 dB on MIC meter).Observe AetherSDR showing high reduction (~ -30) while SSDR shows 0.Increase input to 0 dB.Observe AetherSDR returning to 0 while SSDR shows deep compression (~ -20).Radio model & firmwareModel: FLEX-6600Firmware: 4.1.5.39794OS & versionOS: Windows 11 (AetherSDR v0.8.17 / Qt 6.7.3)Developer NotesRoot Cause Re-Evaluation:The data provided in the table suggests that the logic implemented in PR #1580 may not be producing the intended results in a live environment, particularly on Windows 11.Specifically, at a MIC level of -30 dB, ASDR is showing -30. This strongly suggests the UI is still displaying the raw COMPPEAK dBFS level as if it were a reduction value. When the signal hits 0 dB (peak), the COMPPEAK level also approaches 0 dBFS, which the UI interprets as "0 dB reduction," causing the "return to zero" behavior reported.Potential Logic Failure Points:src/models/MeterModel.cpp: The calculation reduction = m_afterEq - m_compPeakRaw depends on both meters being updated. If m_afterEq (Meter 27) is not being correctly subscribed to or updated on Windows 11, the calculation may be defaulting to 0 - m_compPeakRaw, which would perfectly recreate the inverted readings seen in the user's table.Peak-to-Average Dynamics: The user noted the role of peak-to-average ratios. If AFTEREQ and COMPPEAK have different ballistics or integration times in the Flex API, a simple subtraction might produce the "jitter" or non-linear jumps reported as the two values move at different speeds.Suggested Diagnostics:Please verify if AFTEREQ (ID 27) is correctly requested in the sub meter command strings within src/core/radio/FlexRadio.cpp.Logging: Please enable radio.responses and gui.updates in Help → Support and provide a log capturing a transition from silence to loud speech (0 dB MIC level). This will confirm if Meter 27 data is actually arriving and being used in the subtraction.
support-bundle-20260419-093152.zip
What did you expect?
No response
Steps to reproduce
No response
Radio model & firmware
No response
Linux distro & Qt version
Windows 11