Summary

Pressing the radio's hardware PTT (footswitch into the radio, hand-mic PTT) doesn't produce forward RF when mic_selection = PC. The radio enters TX state on the interlock side, but AetherSDR's TX state machine doesn't engage — the Aetherial Audio Channel Strip TX indicator never lights, and the radio appears to receive no modulating audio so forward power stays at zero on SSB.

MOX (button click on the GUI, or any path that calls TransmitModel::requestPttOn) still works correctly.

"It used to work" — Jeremy KK7GWY, on the FLEX-8600 setup.

Repro

1. Connect to a Flex radio
2. Set mic_selection to PC in Radio Setup → Phone tab
3. Ensure DAX TX is off
4. Engage TX via the radio's hardware PTT (mic PTT or footswitch into the radio)

Expected: Radio enters TX, modulates the AetherSDR PC mic audio, forward power matches RF Power slider, Aetherial Audio strip TX indicator lights up red.

Actual: Radio enters TX state (visible on radio front panel), but no forward RF. Strip TX indicator stays dim. Audio doesn't appear to flow.

Verified working baseline

• MOX button → forward RF ✓
• Strip TX indicator lights on MOX ✓
• Mic input is fine (MOX path proves PC mic is being captured and forwarded)

Root cause (preliminary)

RadioModel::onStatusReceived for the interlock object at RadioModel.cpp:3385 explicitly forces TransmitModel::setTransmitting(false) when the radio reports state == "TRANSMITTING" but we didn't locally request TX:

if (!m_txOwnedByUs || (!m_txRequested && !m_cwKeyActive
                       && !m_cwxActive && !m_transmitModel.isTuning())) {
    // Another client owns TX, or local unkey requested:
    // force local TX/audio gate off through all interlock states.
    m_transmitModel.setTransmitting(false);
    if (m_txAudioGate) {
        m_txAudioGate = false;
        emit txAudioGateChanged(false);
    }
}

When the user presses hardware PTT into the radio:

• Radio reports state=TRANSMITTING with tx_client_handle=<our_handle> → m_txOwnedByUs = true ✓
• BUT m_txRequested = false (we didn't initiate via setTransmit)
• m_cwKeyActive = false, m_cwxActive = false, isTuning() = false
• → Outer condition true → setTransmitting(false) called

So TransmitModel::isTransmitting() stays false, moxChanged(false) propagates, and:

• AudioEngine::setTransmitting(false) stays in effect → mic audio path may be partially disabled
• AetherialAudioStrip::setTxActive(...) is gated on tx.isTransmitting() and stays dim
• Docked Chain applet TX pulse is also gated on this and stays dim

Where the regression came from

User says hardware PTT used to work, so something changed. Suspects in chronological order from the recent merges:

• Quindar tones — Apollo K/BK on PTT engage and disengage (#2262) #2334 (Quindar) — added requestPttOn/Off coordinator, which is the new TX entry point. May have changed how m_txRequested propagates.
• Fix and trace netCW keying for straight key and iambic CW #2336 (netCW) — protocol change, unlikely to affect hardware PTT.
• Gate compression meter on radio TX state #2363 (compression meter) — UI gating only.
• Fix waterfall TX trail by gating on radio interlock state (#1927) #2368 (waterfall freeze) — moved spectrum freeze to radioTransmittingChanged, doesn't touch the m_transmitting path.

A git bisect on the "hardware PTT into the radio drives the Aetherial Audio TX indicator" case would identify the exact regression point.

Acceptance criteria

When the radio reports state == "TRANSMITTING" and we own TX (tx_client_handle == clientHandle()):

• TransmitModel::isTransmitting() returns true regardless of whether TX was locally initiated
• AetherialAudioStrip TX indicator lights up red
• Docked Chain applet TX endpoint pulses red
• Forward RF appears on the radio (mic audio modulates the carrier)
• MOX path still works (no regression)
• When ANOTHER client owns TX (!m_txOwnedByUs), local indicators stay dim and no audio flows (Multi-Flex correctness preserved)

The fix is probably at the RadioModel.cpp:3385 condition: when m_txOwnedByUs && state == "TRANSMITTING", accept the TX state as authoritative even without m_txRequested set. Hardware PTT into the radio is a legitimate way for "us" to be transmitting — the radio knows we own it.

73, Jeremy KK7GWY & Claude (AI dev partner)