Fix VFO filter width indicator showing 0.1 kHz too low (#2197)#2435
Merged
Conversation
VfoWidget::updateFilterLabel() used `filterHigh - filterLow`, which is ~100 Hz less than the nominal SSB/digital preset width because of the intentional low-cut offset (e.g. USB lo=95, hi=2800 → 2705 → "2.7K" displayed for an actual "2.8K" filter). The RxApplet filter readout already uses a mode-aware formatter (formatFilterWidth) that returns the high edge for USB/DIGU/FDV/NT, abs(low edge) for LSB/DIGL, and (hi - lo) elsewhere. Promote it to public and have VfoWidget call it directly so the two labels can never drift again — the same drift caused #794, #1225, and now #2197. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Contributor
There was a problem hiding this comment.
Thanks @jensenpat — looks good.
Verified:
RxApplet::formatFilterWidth()already handles USB/LSB/DIGU/DIGL/FDV/NT via the side-aware branches and falls back tohi - lofor symmetric modes (CW, AM, FM, RTTY, etc.), so the VFO readout now matches the applet readout for every mode.SliceModel::mode()returns the sameQStringthe applet's existing callers pass, so no conversion concerns.- Promoting the helper to
publicis the right call here — the alternative (duplicating the logic inVfoWidget) is exactly what regressed this twice already (#794, #1225, #2197). Sharing the function makes the next swap impossible by construction.
Scope is appropriately tight (9/9 lines across 2 files), no AppSettings/RAII concerns, no error-handling gaps at boundaries.
Collaborator
|
Claude here — exactly the right structural fix for a thrice-reported drift bug. The history walk (PR #881 + revert 61251e9) makes it clear that duplicating the logic invites drift, and the comment in updateFilterLabel citing #794/#1225/#2197 should keep the next maintainer from reverting this for the wrong reason. Promoting the static + stateless formatter is the minimal change that prevents the fourth recurrence. Merged. 73, Jeremy KK7GWY & Claude (AI dev partner) |
6 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #2197
Summary
VfoWidget::updateFilterLabel()computedfilterHigh - filterLow, which for SSB/digital modes is ~100 Hz less than the nominal preset width because of the intentional low-cut (e.g. USBlo=95, hi=2800→ "2.7K" displayed for what is actually a "2.8K" filter).RxApplet::formatFilterWidth(). Promote it to public and haveVfoWidgetcall it directly so the two labels share one source of truth.Why a shared call instead of duplicating the logic
The same drift caused #794, #1225, and now #2197. PR #881 made both readouts mode-aware in the same commit, then 61251e9 reverted only the VFO side to "match the buttons" — but the buttons were already mode-aware, so the revert created the opposite imbalance reported here. Calling one shared function is the smallest change that prevents the next swap.
Test plan
🤖 Generated with Claude Code