fix: preserve rtty_mark_default when radio resets mark on band change#1968
Conversation
When rtty_mark_default is set to a non-standard value (e.g. 915 Hz), changing bands while in RTTY mode caused the slice rtty_mark to snap back to 2125 Hz. Audio channel offset and TX mark frequency were wrong until the user changed mode away from RTTY and back. Root cause: the radio always resets a slice's rtty_mark to 2125 in the status broadcast that follows a band change, regardless of the configured rtty_mark_default. SliceModel::applyStatus() accepted this value blindly, overwriting the user's configured mark frequency. Changes: SliceModel: add m_rttyMarkDefault member (default 2125) and setRttyMarkDefault() setter. In applyStatus(), when rtty_mark=2125 arrives but m_rttyMarkDefault differs, push the correct value back to the radio with "slice set <id> rtty_mark=<default>" and update the local model to the default rather than the factory-reset value. RadioModel: call s->setRttyMarkDefault(m_rttyMarkDefault) immediately after constructing a new SliceModel so the correct default is in place before the first applyStatus() call. Also propagate the value to all existing slices whenever the radio status updates rtty_mark_default.
![aethersdr-agent[bot]](https://avatars.githubusercontent.com/in/3286087?s=60&v=4){kind=small}
There was a problem hiding this comment.
Nice fix, @chibondking — the root cause analysis is solid and the change is well-scoped. A few observations:
Looks good:
- Setting
m_rttyMarkDefaultbefore the firstapplyStatus()call on new slices is correct — the ordering inhandleSliceStatusensures the default is in place before status parsing. - Propagating the default to all existing slices when
rtty_mark_defaultchanges inhandleRadioStatushandles mid-session profile changes. - No loop risk: the correction command will echo back with the non-2125 value, so the guard won't re-trigger.
One concern — the v == 2125 heuristic:
The condition v == 2125 && m_rttyMarkDefault != 2125 assumes that any incoming rtty_mark=2125 is a radio reset rather than an intentional value. Consider this sequence:
- User has
rtty_mark_default=915 - User manually sets
rtty_markto 2125 viasetRttyMark(2125)(e.g., switching to a standard RTTY net) - Radio echoes
rtty_mark=2125in the next status broadcast applyStatus()seesv == 2125with default 915, overrides it back to 915
This would fight the user's explicit choice. In practice this may be rare (if your default is non-standard, you probably don't manually set 2125), but it's worth considering. A possible mitigation: track a m_rttyMarkUserOverride flag that gets set in setRttyMark() and cleared on band change, so the heuristic only fires when the user hasn't explicitly chosen 2125. That said, this is a judgment call — if the real-world use case is narrow enough, the current approach is pragmatic and you could address it later if users report it.
No other issues found — the changes stay within scope, no null-pointer risks, and the new member is properly initialized. Thanks for the contribution!
When rtty_mark_default is set to a non-standard value (e.g. 915 Hz), changing bands while in RTTY mode caused the slice rtty_mark to snap back to 2125 Hz. Audio channel offset and TX mark frequency were wrong until the user changed mode away from RTTY and back. Root cause: the radio always resets a slice's rtty_mark to 2125 in the status broadcast that follows a band change, regardless of the configured rtty_mark_default. SliceModel::applyStatus() accepted this value blindly, overwriting the user's configured mark frequency. Changes: SliceModel: add m_rttyMarkDefault (seeded by RadioModel) and m_rttyMarkUserOverride members. In applyStatus(), when rtty_mark=2125 arrives but m_rttyMarkDefault differs and the user has not explicitly chosen 2125, push the configured default back to the radio. The override flag is set in setRttyMark() when the user intentionally picks 2125 while the default is non-standard, preventing a fight between the correction logic and the user's explicit choice. The flag is cleared whenever RF_frequency changes (band change), so the restore fires correctly on the next band hop. RadioModel: call s->setRttyMarkDefault(m_rttyMarkDefault) immediately after constructing a new SliceModel so the correct default is in place before the first applyStatus() call. Also propagate the value to all existing slices whenever the radio status updates rtty_mark_default.
|
@AetherClaude suggestions added. One flag from you "setRttyMark(2125) (e.g., switching to a standard RTTY net)" should be a standard RTTY offset, not a RTTY net. |
|
Good catch @chibondking, thanks for the correction. You're right — 2125 Hz is the standard RTTY mark frequency (offset), not a "RTTY net." That was sloppy wording on my part. If that appeared in a code comment or doc string in the PR, it should read something like "e.g., restoring the standard 2125 Hz mark frequency" instead. Appreciate the careful review. |
2 participants
When rtty_mark_default is set to a non-standard value (e.g. 915 Hz), changing bands while in RTTY mode caused the slice rtty_mark to snap back to 2125 Hz. Audio channel offset and TX mark frequency were wrong until the user changed mode away from RTTY and back.
Root cause: the radio always resets a slice's rtty_mark to 2125 in the status broadcast that follows a band change, regardless of the configured rtty_mark_default. SliceModel::applyStatus() accepted this value blindly, overwriting the user's configured mark frequency.
Changes:
SliceModel: add m_rttyMarkDefault member (default 2125) and setRttyMarkDefault() setter. In applyStatus(), when rtty_mark=2125 arrives but m_rttyMarkDefault differs, push the correct value back to the radio with "slice set rtty_mark=" and update the local model to the default rather than the factory-reset value.
RadioModel: call s->setRttyMarkDefault(m_rttyMarkDefault) immediately after constructing a new SliceModel so the correct default is in place before the first applyStatus() call. Also propagate the value to all existing slices whenever the radio status updates rtty_mark_default.