feat: store tx_slice_mode from transmit status in TransmitModel#2773
Conversation
The radio sends "transmit tx_slice_mode=FDVU" when the active TX slice enters a FreeDV mode. This key was previously silently dropped in applyTransmitStatus. Now stored in m_txSliceMode with a txSliceMode() getter and txSliceModeChanged(mode) signal. Cleared on disconnect via resetState(). No UI surface — provides the data layer for future FreeDV TX mode indicators. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Looks good — thanks @NF0T.
Verified the claims in the PR description:
rg tx_slice_modeandrg txSliceModeboth return zero hits onmain, so this key was indeed being dropped.- The parse site at
TransmitModel.cpp:224-227follows the exact same shape as the surroundingmax_power_level/tune_modeblocks, including the "targeted signal + globalstateChanged" pattern you flagged. - Clearing
m_txSliceModeinresetState()is the right call — the FDVU/FDVL strings only make sense if the FreeDV waveform is loaded on the connected radio, so persisting them across a reconnect would be a bug.
No UI consumer yet, but that matches the PR scope, and txSliceModeChanged(const QString&) is a reasonable shape for the eventual TX-status chip to bind against.
One small note (non-blocking): the test plan calls for inserting a temporary qCDebug in applyTransmitStatus to verify the signal fires. If you find yourself doing that more than once for new transmit-status keys, a single trace-level log of unrecognized keys in applyTransmitStatus might be worth a follow-up — but that's clearly outside the scope of this PR.
|
Claude here — landed at 01:12 UTC. Seven clean PRs in a single day, Ryan! 🎉 The data-layer scope is exactly right here. Surfacing the silently-dropped `tx_slice_mode` key into TransmitModel with a focused `txSliceModeChanged(QString)` signal (parallel to `maxPowerLevelChanged` rather than batched into `stateChanged`) means any future UI consumer — a "FreeDV TX" chip in the spectrum overlay, a TX-applet indicator, a TCI export — can wire directly without having to inspect every other transmit field for the change. Clean separation between protocol observation and presentation choice. The grep-confirmed-zero-references audit in the PR description is the right way to demonstrate that a key is genuinely unhandled rather than just unsurfaced — that's the kind of evidence that makes review fast. Today's tally for you: #2745, #2747, #2752, #2754, #2759, #2771, #2773. Seven PRs, seven distinct code paths. Honestly stellar. 73, Jeremy KK7GWY & Claude (AI dev partner) |
Background
When the active TX slice switches to a FreeDV mode, the radio broadcasts:
This key arrives via the existing
object == "transmit"→applyTransmitStatus()route inRadioModelalongside all other transmit keys (rfpower,tunepower,tune_mode, etc.). Prior to this PR, it was silently dropped — confirmed by grepping the entire codebase fortx_slice_mode, which returned zero results. Storing it is the correct data-layer fix that enables any future TX status indicator (e.g. a "FreeDV TX" chip in the panadapter overlay or TX applet) to consume it without revisitingTransmitModel.Summary
m_txSliceModemember toTransmitModel(empty until first transmit status received)txSliceMode()gettertxSliceModeChanged(const QString& mode)signal, emitted immediately on change — consistent with themaxPowerLevelChangedandtxFilterCutoffChangedpattern rather than batched intostateChanged, so consumers that specifically care about FreeDV TX mode get a targeted signaltx_slice_modeparsed inapplyTransmitStatus()alongsidetune_modeandshow_tx_in_waterfallresetState()on disconnect so a stale"FDVU"value does not persist if the user reconnects to a radio without the FreeDV waveform installedNo UI surface is added in this PR.
Test plan
txSliceModeChanged("FDVU")fires (verify via temporaryqCDebuginapplyTransmitStatus)txSliceModeChanged("USB")firestxSliceMode()returns empty string afterresetState()🤖 Generated with Claude Code