RF Waterfall: fix the inverted colour ramp and follow the theme - #2759
Closed
vnxdtzip wants to merge 2 commits into
Closed
RF Waterfall: fix the inverted colour ramp and follow the theme#2759vnxdtzip wants to merge 2 commits into
vnxdtzip wants to merge 2 commits into
Conversation
added 2 commits
August 4, 2026 19:54
#### Proposed Changes ####
A module that needs a dimmed or highlighted shade of the active theme has no
way to ask for one. The only helper available, getColorVariation, steps
brightness up or down and cannot mix toward another colour, so modules fall
back to a fixed constant such as TFT_DARKGREY or TFT_WHITE. That is the root
cause of most of the screens in Bruce that stop following the user's theme as
soon as they need more than the primary colour.
This adds two helpers next to it in core/display:
blendColors(a, b, t) linear RGB565 mix; t = 0 keeps a, t = 255 keeps b
buildHeatPalette(lut, n) fills a lookup table with a theme ramp running
from the background up to a brightened primary,
for waterfalls and other intensity plots
Both are pure additions. No existing function is modified, and nothing calls
them in this PR - the modules that consume them follow separately.
#### Types of Changes ####
New Feature (internal helper API). No behaviour change and no breaking change.
#### Verification ####
Nothing on screen changes from this PR alone, so verification is limited to
confirming the build is clean and that only insertions were made:
pio run -e m5stack-cardputer
git show --stat # 2 files changed, 31 insertions(+), 0 deletions(-)
#### Testing ####
Bruce has no unit test harness covering the display layer, so this was
verified by compiling for m5stack-cardputer on this branch. The helpers get
exercised on hardware through the follow-up PRs that use them.
#### Linked Issues ####
None. This is the base commit of a series that standardises the
spectrum-style screens; the module PRs listed below depend on it.
#### User-Facing Change ####
```release-note
NONE
```
#### Further Comments ####
Prerequisite for ui/spectrum-view, ui/rf-waterfall-theme and
ui/rf-spectrum-theme.
#### Proposed Changes ####
The intensity ramp was inverted. rawLevel mapped RSSI so a strong signal
produced 255, then `level = 255 - rawLevel` flipped it, so the noise floor
rendered red and carriers rendered dark blue. An idle band filled the screen
with heat and real signals read as holes in it.
Dropping the inversion makes the ramp run cold to hot, and its bottom 40
levels now dissolve into the theme background so an empty band looks like the
rest of the UI. The full-gamut ramp itself is kept deliberately: in a
waterfall the colour is the measurement, not decoration.
Everything around it now follows the theme instead of a private palette.
fillScreen(0x0), TFT_BLACK, TFT_PINK, TFT_WHITE, TFT_YELLOW, TFT_DARKCYAN and
TFT_DARKGREY are gone. The header block moved from hardcoded y = 0/10/20 to
rows derived from the font height, and now repaints only when its contents
change - previously the text was rewritten every sweep, which flickered.
Screen size comes from tftWidth/tftHeight rather than tft.width()/height().
#### Types of Changes ####
Bugfix (inverted colour ramp) plus UI rework.
#### Verification ####
Flash and open RF -> Waterfall with a CC1101 attached, then compare against
the previous build on the same band:
- with no transmitter, the fall should be dark and blend into the
background, where before it was mostly red
- keying a transmitter inside the band should paint a bright warm streak,
where before it painted a dark blue one
- the header should not flicker while sweeping
- switching to a light theme should keep the header readable, where before
the background stayed black
The band edges, the OK/PREV/NEXT controls and the EXIT item behave as before.
#### Testing ####
No unit test harness exists for this layer. rf_waterfall.cpp compiles clean
for m5stack-cardputer, verified in the combined tree; this branch was not
built in isolation. Not yet verified on hardware by me, and I have no CC1101 -
a reviewer with the radio should confirm the ramp direction against a known
carrier, since that is the substantive change here.
#### Linked Issues ####
None. Depends on ui/color-helpers for blendColors. Does not need the
SpectrumPlot component, so it can be reviewed and merged independently of the
rest of the series.
#### User-Facing Change ####
```release-note
RF Waterfall: fixed an inverted colour ramp that rendered the noise floor as red and strong signals as dark blue. Signals now run cold to hot, and the surrounding UI follows the active theme.
```
#### Further Comments ####
The framebuffer is still a stack VLA sized from the panel width, which is
pre-existing and untouched here, but it is worth flagging: on a 480px display
that is roughly 1KB of stack per call.
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.
Proposed Changes
The intensity ramp was inverted. rawLevel mapped RSSI so a strong signal
produced 255, then
level = 255 - rawLevelflipped it, so the noise floorrendered red and carriers rendered dark blue. An idle band filled the screen
with heat and real signals read as holes in it.
Dropping the inversion makes the ramp run cold to hot, and its bottom 40
levels now dissolve into the theme background so an empty band looks like the
rest of the UI. The full-gamut ramp itself is kept deliberately: in a
waterfall the colour is the measurement, not decoration.
Everything around it now follows the theme instead of a private palette.
fillScreen(0x0), TFT_BLACK, TFT_PINK, TFT_WHITE, TFT_YELLOW, TFT_DARKCYAN and
TFT_DARKGREY are gone. The header block moved from hardcoded y = 0/10/20 to
rows derived from the font height, and now repaints only when its contents
change - previously the text was rewritten every sweep, which flickered.
Screen size comes from tftWidth/tftHeight rather than tft.width()/height().
Types of Changes
Bugfix (inverted colour ramp) plus UI rework.
Verification
Flash and open RF -> Waterfall with a CC1101 attached, then compare against
the previous build on the same band:
background, where before it was mostly red
where before it painted a dark blue one
the background stayed black
The band edges, the OK/PREV/NEXT controls and the EXIT item behave as before.
Testing
No unit test harness exists for this layer. rf_waterfall.cpp compiles clean
for m5stack-cardputer, verified in the combined tree; this branch was not
built in isolation. Not yet verified on hardware by me, and I have no CC1101 -
a reviewer with the radio should confirm the ramp direction against a known
carrier, since that is the substantive change here.
Linked Issues
None. Depends on #2754 (ui/color-helpers) for blendColors. Does not need the
SpectrumPlot component, so it can be reviewed and merged independently of the
rest of the series.
User-Facing Change
Further Comments
The framebuffer is still a stack VLA sized from the panel width, which is
pre-existing and untouched here, but it is worth flagging: on a 480px display
that is roughly 1KB of stack per call.