Context
Forward power dropping to ~0 W during digital TX while the radio still keys is widely reported across the FlexRadio/DAX community, likely with several root causes. One common thread is the fix: restart WSJT-X or switch the audio source and power returns — i.e. a soft state cured by re-establishing the dax_tx stream (working hypothesis: the stream goes stale/desynchronized on the client side).
Rather than chase one root cause, this proposes a general, root-cause-agnostic solution: an opt-in watchdog that detects the zero-power condition across TX cycles and resets the dax_tx stream in real time — automating the manual recovery users already do, whatever their specific trigger. POC PR to follow.
Environment
- FLEX-8400, firmware 4.2.20.41343 · AetherSDR 26.7.1, Linux
- TCI + DAX, digital (DIGU), WSJT-X FT8, 30 m (10.136 MHz), drive fixed at 50 W
Observations (measured)
- FWDPWR meter reads ~0 W at the fixed 50 W drive while the radio shows
state=TRANSMITTING, tx_allowed=1 — it keys, but almost no RF leaves the radio.
- Recovery: a
stream remove 0x… → stream create type=dax_tx restores power on the next cycle (captured on the wire) — same effect as the "restart WSJT-X / switch audio" fix.
Occurrence
Recurring across many FT8 sessions over time — intermittent, with no reliable trigger I can reproduce on demand. It's likely a combination of factors — sustained calling CQ and/or abrupt mid-TX unkeys (WSJT-X "Halt Tx") seem associated. The cause is unknown, but the stream-desync hypothesis fits and the fix is consistent: re-establishing the dax_tx stream restores power. That's the case for a root-cause-agnostic auto-recovery rather than chasing a single cause.
Related
Context
Forward power dropping to ~0 W during digital TX while the radio still keys is widely reported across the FlexRadio/DAX community, likely with several root causes. One common thread is the fix: restart WSJT-X or switch the audio source and power returns — i.e. a soft state cured by re-establishing the
dax_txstream (working hypothesis: the stream goes stale/desynchronized on the client side).Rather than chase one root cause, this proposes a general, root-cause-agnostic solution: an opt-in watchdog that detects the zero-power condition across TX cycles and resets the
dax_txstream in real time — automating the manual recovery users already do, whatever their specific trigger. POC PR to follow.Environment
Observations (measured)
state=TRANSMITTING,tx_allowed=1— it keys, but almost no RF leaves the radio.stream remove 0x… → stream create type=dax_txrestores power on the next cycle (captured on the wire) — same effect as the "restart WSJT-X / switch audio" fix.Occurrence
Recurring across many FT8 sessions over time — intermittent, with no reliable trigger I can reproduce on demand. It's likely a combination of factors — sustained calling CQ and/or abrupt mid-TX unkeys (WSJT-X "Halt Tx") seem associated. The cause is unknown, but the stream-desync hypothesis fits and the fix is consistent: re-establishing the
dax_txstream restores power. That's the case for a root-cause-agnostic auto-recovery rather than chasing a single cause.Related
split_enablesemantics collide with two-pan operation — WSJT-X rig-control errors, and a drop can strand the audio session #4085 — a drop can strand the audio session.