[bug] FLEX-6400M v26.9.3 —

Title: FLEX-6400M digital TX output limited to ~2 W with AetherSDR 26.9.3

What happened?

When using AetherSDR 26.9.3 with a FLEX-6400M running firmware 4.2.20.41343, FT8 transmissions from WSJT-X produce only approximately 2.1–2.2 W RF output, despite the radio being configured for 100% RF Power and the AetherSDR/WSJT-X TX audio chain showing substantial signal levels.

The behavior is reproducible and appears to be specific to the AetherSDR Linux digital-mode transmit path.

I performed a controlled A/B comparison using the same FLEX-6400M, the same firmware, the same frequency, the same digital mode, and the same WSJT-X version.

Linux / AetherSDR result

• AetherSDR: 26.9.3
• FLEX-6400M firmware: 4.2.20.41343
• WSJT-X: 3.0.2
• Frequency: 14.074 MHz
• Mode: DIGU
• RF Power: 100%
• Tune Power: 10%
• ATU: Successful
• WSJT-X Pwr: approximately -5 dB
• AetherSDR DAX TX gain: increased as high as 100%
• TX audio was clearly present and the radio entered the transmitting state.
• FLEX radio telemetry confirmed rfpower=100 and dax=1 while transmitting.
• Forward RF power remained approximately 2.1–2.2 W.

Representative measurements from AetherSDR automation during FT8 TX:

WSJT-X Pwr:       -5 dB
RF Power:         100%
DAX TX gain:      100%

Forward power:    ~2.12 W
FWDPWR:           ~33.3 dBm
Reflected power:  ~0.055 W
SWR:              ~1.37

CODEC:            ~-6 dBFS
SC_MIC:           ~-2.9 dBFS
ALC:              ~-2.9 dBFS
SC_FILT_2:        ~-0.5 dBFS
PRE_WAVE:         ~-0.5 dBFS
POST_P:           ~-2.5 dBFS
GAIN:             ~-3.5 dBFS

The result was repeatable. Earlier testing with AetherSDR DAX TX gain at 50–100% and WSJT-X Pwr from -5 dB to 0 dB showed RF output increasing somewhat, but remaining in the approximately 0.6–2.2 W range.

I also tested the TCI path rather than CAT/DAX control. WSJT-X was configured as:

Rig: TCI Client RX1
TCI Server: 127.0.0.1:50001
Use TCI Audio: enabled

TCI audio was received correctly and WSJT-X decoded FT8 normally. However, FT8 TX through TCI also produced only approximately 2.1 W. Changing from USB to DIGU did not materially change the result.

Thus both AetherSDR DAX audio and AetherSDR TCI audio exhibit essentially the same low-power behavior.

Windows control comparison

I then performed an independent test using the official FlexRadio software on a Windows 10 computer.

Configuration:

SmartSDR:          4.2.20
CAT:               4.2.20
DAX:               4.2.20 / DAXv2
WSJT-X:            3.0.2

FLEX-6400M:        firmware 4.2.20.41343
Frequency:         14.074 MHz
Mode:              DIGU
RF Power:          100%
Tune Power:        10%
ATU:               Successful
DAX TX Gain:       47%
WSJT-X Pwr:        -5.1 dB

The Windows configuration produced approximately 100 W RF output on the FLEX-6400M, with both the radio's own meter and SmartSDR's meters showing full output.

The Windows WSJT-X installation also successfully completed an FT8 contact during the test.

Therefore the radio hardware, PA, antenna/ATU, firmware, RF Power setting, frequency, mode, and WSJT-X digital audio generation have all been demonstrated to work correctly when using the official SmartSDR/DAXv2 path.

What did you expect?

With RF Power set to 100%, a properly configured FT8 transmit audio stream at approximately -5 dB WSJT-X Pwr should produce substantially more than 2 W from the FLEX-6400M.

The official Windows SmartSDR/DAXv2 configuration produces approximately 100 W under essentially the same conditions, so I expected AetherSDR's DAX/TCI digital TX path to produce comparable RF output.

I am not necessarily expecting the exact same output level from the two implementations without calibration, but a repeatable ceiling around 2 W is clearly abnormal.

Steps to reproduce

1. Use a FLEX-6400M running firmware 4.2.20.41343.

2. Run AetherSDR 26.9.3 on Linux.

3. Connect AetherSDR to the FLEX-6400M.

4. Configure a slice for 14.074 MHz DIGU.

5. Configure RF Power to 100%.

6. Confirm ATU status is successful.

7. Enable AetherSDR DAX TX.

8. Configure WSJT-X 3.0.2 for:

   • Rig control through AetherSDR CAT, or alternatively TCI.
   • DAX RX 1 / DAX TX for the DAX test.
   • TCI Audio for the TCI test.

9. Set WSJT-X Pwr to approximately -5 dB.

10. Transmit an FT8 over.

11. Observe the FLEX/AetherSDR forward-power telemetry.

12. Approximately 2.1–2.2 W RF output is observed.

13. Increase AetherSDR DAX TX gain as high as 100% and/or WSJT-X Pwr to 0 dB. RF output increases but remains only a few watts.

14. As an independent control, configure the same radio with SmartSDR 4.2.20/DAXv2 on Windows, DAX TX Gain 47%, and WSJT-X Pwr approximately -5 dB.

15. The same radio then produces approximately 100 W.

Radio model & firmware

• Radio: FLEX-6400M
• Firmware: 4.2.20.41343
• Radio IP: 192.168.1.195
• Radio serial: 4118-0519-6401-0010

OS & version

• OS: Linux
• Distribution: KDE neon User Edition
• Architecture: x86_64
• Qt: 6.8.3
• AetherSDR: 26.9.3
• WSJT-X: 3.0.2
• Audio: PipeWire with PulseAudio compatibility layer

Developer Notes

The current AetherSDR architecture appears to make the DAX/TCI TX path a particularly relevant area for investigation.

The project documentation identifies AudioEngine as the central RX/TX audio component and describes the DAX/TCI path as:

PipeWire / TCI
    -> AudioEngine::feedDaxTxAudio()
    -> DAX/TCI bypass of client voice DSP
    -> VITA-49 TX packetization
    -> FLEX radio DAX TX stream

The current audio-pipeline documentation specifically identifies:

AudioEngine::feedDaxTxAudio()
AudioEngine::feedDaxTxAudioInternal()
PipeWireAudioBridge::pollTxPipe()
TciServer::onBinaryMessage()

as important points in the DAX/TCI TX path.

In the current source, AudioEngine::feedDaxTxAudio() calls feedDaxTxAudioInternal() and the latter explicitly bypasses the normal client voice DSP chain for DAX/TCI audio.

The radio-native DAX path then converts float32 stereo to Int16 mono and sends VITA-49 PCC 0x0123 packets when dax=1 is active.

Relevant current source locations include:

src/core/AudioEngine.cpp
    AudioEngine::feedDaxTxAudio()
    AudioEngine::feedDaxTxAudioInternal()
    AudioEngine::setDaxTxUseRadioRoute()
    AudioEngine::setDaxTxMode()

The current implementation is around lines 9383–9538, although exact line numbers may differ from the 26.9.3 release source.

The current code logs the selected DAX TX route through the lcDax logging category. The relevant messages identify whether the application is using:

radio-dax pcc=0x0123

or:

float32 pcc=0x03e3

The DAX TX path also calculates its client-side input peak/RMS level in feedDaxTxAudioInternal() before packetization. This is useful because the observed AetherSDR TX-chain levels demonstrate that substantial digital audio is reaching the AetherSDR DAX TX path.

The TCI implementation is also relevant. TciServer::onBinaryMessage() receives TX audio, converts it to float32, determines the client's declared sample rate, and resamples it to 24 kHz. The current source explicitly states that WSJT-X normally sends 48 kHz and that the TCI path then feeds AudioEngine::feedDaxTxAudio().

Relevant current source:

src/core/TciServer.cpp
    TciServer::onBinaryMessage()

Current source around lines 2457–2527 handles the incoming TCI TX audio and sample-rate conversion. The TCI setup around lines 3271–3295 explicitly enables the radio DAX TX route with:

transmit set dax=1

This is consistent with what I observed from the FLEX native API during an actual FT8 transmission:

rfpower=100
tx_slice_mode=DIGU
dax=1

The FLEX interlock also reported the radio as actually transmitting, so this does not appear to be a simple failure to key the transmitter.

Potential areas worth investigating

I do not have enough information to identify the exact root cause, but the evidence suggests looking at the signal level and scaling between the external digital-mode audio source and the RF level ultimately produced by the FLEX radio.

In particular:

1. Linux PipeWire DAX TX level/scaling

   The Linux DAX path accepts 24 kHz mono s16le and converts it to float32 before duplicating it to stereo. The current architecture documentation identifies PipeWireAudioBridge::pollTxPipe() as the relevant conversion point.

2. DAX float32 → Int16 mono conversion

   AudioEngine::feedDaxTxAudioInternal() uses the radio-native DAX path to collapse float32 stereo to Int16 mono before constructing PCC 0x0123 packets.

3. WSJT-X Pwr / client-leveling interaction

   AetherSDR has previously made changes specifically related to WSJT-X Pwr and client-leveled DAX/TCI audio. It would be useful to verify that the current 26.9.3 implementation produces the expected DAX TX amplitude for WSJT-X digital audio and that no unintended attenuation is being applied before VITA packetization.

4. Flex firmware 4.2.20 compatibility

   The radio is running 4.2.20.41343. The same firmware produces approximately 100 W using SmartSDR/DAXv2, so this is not evidence of a radio firmware/hardware problem. However, the DAX VITA-49 implementation in AetherSDR should be compared against the behavior expected by this firmware version.

5. VITA-49 PCC 0x0123 payload amplitude

   A packet capture or additional instrumentation comparing the actual transmitted sample amplitudes from AetherSDR with the samples produced by the known-good Windows DAXv2 implementation would likely be very informative.

Recommended diagnostic logging

For a support bundle, I would especially capture the audio/DAX and radio-control diagnostics around one complete FT8 transmission.

The most relevant logging categories appear to be:

lcAudio
lcDax

and, for the TCI comparison:

lcCat

The support bundle should ideally capture:

• DAX TX route selection
• DAX TX input peak/RMS
• TX stream ID
• transmit dax=1 state
• TX interlock state
• VITA TX packet activity
• sample-rate conversion activity
• any DAX packet rejection/drop messages
• radio-provided forward/reflected power telemetry
• WSJT-X/TCI client connection information

A support bundle generated immediately before and after one reproducible FT8 transmission should provide useful diagnostic context.

Summary

This appears to be a reproducible difference between the AetherSDR digital TX implementation and the official FlexRadio Windows DAXv2 implementation.

The strongest evidence is the controlled comparison:

                         AetherSDR       SmartSDR/DAXv2
Radio                    FLEX-6400M     FLEX-6400M
Firmware                 4.2.20.41343   4.2.20.41343
WSJT-X                   3.0.2          3.0.2
Frequency                14.074 MHz     14.074 MHz
Mode                     DIGU           DIGU
RF Power                 100%           100%
WSJT-X Pwr               ~-5 dB         -5.1 dB
Digital TX path          DAX / TCI      DAXv2
Observed RF output       ~2.1 W         ~100 W

The radio itself is capable of full output under these conditions, and the AetherSDR installation is successfully receiving FT8 audio, controlling the radio, entering TX, and delivering measurable digital TX audio. The remaining problem appears to be in the AetherSDR digital TX signal-level/transport path rather than basic radio configuration.

support-bundle-20260914-164855.zip

support-bundle-20260914-164855.zip

Start with src/core/AudioEngine.cpp, especially feedDaxTxAudioInternal() and the DAX route and packetization functions, then inspect PipeWireAudioBridge::pollTxPipe(). Compare this with TciServer::onBinaryMessage() in src/core/TciServer.cpp, reproducing one FT8 transmission with lcAudio, lcDax, and lcCat logs. Done means the cause of the roughly 2 W ceiling is identified and the DAX/TCI path no longer exhibits the abnormal attenuation.