T-Watch:
Disabled rx boosted gain & removed meck rx duty cycle flag for S3 and S3 Plus.
Bumped charge rate on S3 to 150MA.
Added watch custom incoming path/hops view in channel message view mode.
Added diagnostic pmubtn build to S3 plus to iron out source of power drain in S3 firmware.
All boards:
ChannelScreen.h -- delivered DMs now render Delivered in the prefix position, exactly where Sending x/N and Failed sit, and the drawn tick is gone entirely (the branch, the reserved gap and the drawDeliveredTick helper -- zero references remain). For what it's worth, the photo vindicates the change: those stray pixels below the line next to "2s" are the tick misplaced, because the GFX fonts position from the baseline rather than the glyph top, so the hand-drawn glyph landed too low. Text is the robust answer.
UITask.cpp -- the toast persistence is a scheduling starvation, and the status pushes made it visible. Dismissal works by scheduling a render at _alert_expiry; but after every frame the e-ink throttle applies an 800ms floor (minNext, UITask.cpp:2856-2860), and the ~644ms partial-refresh block inside endFrame() shifts millis() before the clamp runs. So any render landing inside the alert window -- which a delivered/attempt push now triggers via forceRefresh() -- redraws the overlay and then gets its expiry wake clamped past the expiry. Your user's photo is precisely that frame: tick and toast on screen together, with the clearing render deferred. The fix is a single insertion after the shared clamp: if an alert is still active and lapses before the next scheduled render, wake at expiry instead. One bounded extra render per toast, both display branches covered, and the toast now clears on time no matter what the retry engine pushes mid-window.
Tracked DM sends now retry like the app: 3 flood attempts with no path
set, or 5 with a path (4 direct, then path reset and a final flood).
Each attempt waits its own hop-aware est_timeout. Delivered resolves on
the recipient's ack for any attempt and draws a tick after the message
prefix; Failed shows once all attempts are exhausted.
Status is session-only: SD message format unchanged at v4. Wired for
keyboard, touch, CardKB and T-Watch compose plus channel share. BLE app
sends and the voice envelope path are untouched.
The macro was doing double duty: gating the 240x240 touch UI (tile grid, lock
screen, VKB, grey palette) and gating the Plus's onboard GNSS. A non-GPS watch
cannot reuse the first without dragging in the second.
MECK_TWATCH watch form factor
LILYGO_TWATCH_S3_PLUS Plus-only hardware (GNSS on BLDO1, GPIO0 user button)
MECK_PMU_BUTTON user button is the AXP2101 PWRON key, not a GPIO
84 sites renamed across 14 files. The WatchMapScreen include, construction and
its three touch handlers now also require HAS_GPS, as does the Maps tile branch
inside the home tile grid.
Behaviour-preserving: the Plus defines both MECK_TWATCH and HAS_GPS=1, so every
new condition evaluates as before. No other board defines MECK_TWATCH.
Summary of what changed in each file, all confined to the change points shown in the diffs:
ChannelScreen.h — ChannelMessage gains a session-only scope_idx (initialised to 0xFF in the constructor and explicitly reset to 0xFF on SD load, since region is not persisted); addMessage gains a trailing defaulted scope_idx and stores it. The message-list line now renders (Xh)(Xb) Xm, with the byte figure taken from path_len's upper bits for floods and from the_mesh.getNodePrefs()->path_hash_mode + 1 for the 0xFF/0 sentinels. The path overlay shows Route: ... (N-byte) and a new Region: line (name, or (reg unknown), or nothing when unscoped).
MyMesh.h / .cpp — a fixed 28-entry SCOPE_NAMES table, a _scope_keys array precomputed once at the end of begin() via initScopeKeys(), resolveScopeIndex() (matches pkt->transport_codes[0] against the candidates; 0xFF unscoped, 0xFE unmatched), and the public getScopeName() accessor. onChannelMessageRecv resolves the index and passes it to newMsg.
AbstractUITask.h / UITask.h / UITask.cpp — newMsg gains a trailing uint8_t scope_idx = 0xFF; only the channel addMessage call forwards it. DMs and sent echoes keep the default, so they stay unscoped.
MsgFileRecord and the SD save/load format are untouched, so there's no version bump.
pelgraine