Both watches undercount steps. Two divergences from LilyGo's own configuration
for this hardware, applied to both boards:
1. Watermark. LilyGoLib calls setStepCounterWatermark(1) and SensorLib's
BMA423_StepDetector example passes step_counter_wm = 1. Meck's raw-I2C enable
never touched those bits, leaving whatever the config-file blob defaults to.
The watermark is BMA423_STEP_CNTR_WM_MSK (0x03FF), spanning feature_config
[0x36] as LSB and the low two bits of [0x37] as MSB; it does not collide with
the enable bit, which is bit 4 of [0x37]. Both are now written in one
read-modify-write. The bit arithmetic was checked exhaustively against
bma423_step_counter_set_watermark() + feature_enable() over all 65536 starting
states of cfg[0x36]/cfg[0x37]: identical.
2. ODR. SensorLib's step detector example runs the accelerometer at 100 Hz. Meck
used 50 Hz. Everything else already matched: NORMAL, FS_2G, OSR2_AVG2,
CIC_AVG_MODE. Reverting the single 100.0f literal to 50.0f A/Bs this against
the watermark change.
Ruled out: the axis remap is BOTTOM_LAYER_TOP_RIGHT_CORNER on both, identical to
LilyGoLib, and the enable bit itself was already register-for-register what
bma423_feature_enable(BMA423_STEP_CNTR, TRUE) writes.
Not attempted: the 25-value pedometer parameter block at feature_config[0x04..0x35],
reachable via bma423_stepcounter_set_parameter() but with no reference values.
The alarm was self-dismissing after ~10-15 seconds. Cause: AUTO_OFF_MILLIS is
15000, so the display turned off shortly after the alarm fired; UITask.cpp:2769
raise-to-wake then saw !_display->isOn() && board.tiltFired() -- the buzzing motor
on the wrist is exactly what trips the BMA423 tilt detector -- and called
setCurrScreen(lock_screen). The 'navigating away counts as a dismiss' rule added
with the alarm screen then killed it. Any tap did the same.
While ringing, UITask::loop now holds the alarm screen current and pushes
_auto_off forward each iteration. The display therefore stays on, raise-to-wake
is never reached, and checkDisplayOn() passes KEY_ENTER through to handleInput()
rather than swallowing the first press as a wake.
Dismissal is now the PWR key only (KEY_ENTER). Taps are swallowed. The
WATCH_ALARM_RINGING_MS timeout (5 minutes) is unchanged and remains the backstop.
Ringing footer updated from 'Tap to dismiss' to 'Press PWR to dismiss'.
The ordering inside loop() makes this safe: the button dispatch and
curr->handleInput() both run before the alarm hold, so a dismiss takes effect on
the same iteration and the hold is not re-applied. The 90s per-slot fire cooldown
prevents an immediate re-fire within the alarm's own minute.
Fixes a pre-existing bug on both watches. SensorBMA423::begin() calls
bma423_write_config_file(), which re-flashes the BMA423 feature engine and zeroes
the step register on every boot. _stepBaseline and _lastStepDay were RAM-only, so
a reboot mid-day silently reset the day's steps to zero. Persisting the baseline
would not have helped, since the raw count it is measured against restarts at 0.
Replaces the baseline model with accumulate-plus-reset-detection:
delta = (raw >= lastRaw) ? raw - lastRaw : raw
todaySteps += delta
lastRaw is seeded from the chip on the first read rather than from the file,
which is correct whether or not the counter survived the reset.
Persists lastStepDay, todaySteps and history[6] to /steps.dat on the LittleFS
'maps' partition, already mounted before UITask::begin(). Written on day rollover
and at most every 5 minutes otherwise: a >=6s PWR hold is a hardware power cut by
the AXP2101, so there is no clean-shutdown hook to flush from. A rollover across
several days shifts in the completed day then pads with zeros for the days the
watch was off; a clock corrected backwards re-anchors without disturbing history.
Adds StepsHistoryScreen: today plus the previous six days as labelled bars, today
in the tile blue. Reached by long-pressing the steps screen, which on the S3 the
PWR key's short press also delivers (both arrive as KEY_ENTER). Any input returns
to the steps screen.
Gated on MECK_TWATCH, so the Plus gets both the fix and the screen.
Fixes a regression from the MECK_TWATCH rename. main.cpp's tap dispatch had
'#if defined(MECK_TWATCH) && HAS_GPS' wrapped around two unrelated things: the
map tap handler AND the early return that stops the watch falling through to the
T5S3 tile hit-test. MECK_TOUCH_ENABLED is defined for MECK_TWATCH (main.cpp:712),
so on the S3 that early return vanished and a plain tap on the home tile page ran
the T5S3 geometry (tileW=40, tileH=22). Split into two gates. The other three
HAS_GPS gates were audited and are genuinely map-only.
Adds WatchAlarmScreen: four slots, day-of-week presets, vibrate-only. It keeps
AlarmScreen.h's conventions (bit 0 = Sunday, dowFromEpoch, effect 14, the
3-buzz / 1200ms / 4000ms-pause cadence) but shares no code, because AlarmScreen
is bound to ESP32-audioI2S, an SD card and a 1-21 Audio volume scale, none of
which exist here. Config lives on the LittleFS 'maps' partition, already mounted.
Alarms are ticked from UITask::loop, not the screen's poll(), so one fires with
the display off or another screen showing. Navigating away while ringing counts
as a dismiss.
DRV2605Haptic.h is copied into the watch variant rather than shared, so MAX
builds are untouched. The watch needs no motorEnable(): the DRV2605 sits on
BLDO2, which power_init() already brings up.
The Maps tile becomes Alarms on LILYGO_TWATCH_S3 only. The Plus keeps Maps.
The 'buzz' CLI command now also builds on the watch and takes an optional effect
number ('buzz 14'), for characterising the motor. Exact-match behaviour of plain
'buzz' on the MAX is unchanged.
Three build failures, all mine:
1. XPowersLib access. setPowerChannelVoltage, enable/disablePowerOutput and
isPowerChannelEnable are protected on XPowersAXP2101 and public only on
XPowersLibInterface, so holding the PMU as the concrete type made every rail
call illegal. The board now keeps both pointers to the same object: PMU
(interface) for the channel ops, _axp (concrete) for setIrqLevelTime and the
PWRON press/release edges, which the interface does not declare. Verified
against XPowersLib v0.2.9, the version ^0.2.7 resolves to.
2. ENV_INCLUDE_GPS. sensor_base defaults it to 1. The variant zeroed every other
ENV_INCLUDE_* but not that one, so gpsStream, board.gpsPowerOn/Off and the
GPS home page were all still compiled in. Now -D ENV_INCLUDE_GPS=0.
3. GPS_BAUDRATE is referenced unguarded by MyMesh.cpp's gps.baud CLI command.
variant.h now supplies the same #ifndef fallback the T5S3 variant uses.
Also renames the S3 Plus envs to meck_twatch_s3_plus_standalone and
meck_twatch_s3_plus_ble, so they no longer read as the generic watch build.
Nothing outside variants/lilygo_twatch_s3_plus/platformio.ini referenced the old
names.
Same silicon and the same pin map as the T-Watch S3 Plus, verified against the
T_WATCH-S3 schematic (rev 25-03-24) and LilyGo's utilities.h. The differences
are what is populated:
- no onboard GNSS. HAS_GPS/ENV_INCLUDE_GPS are left undefined, which drops the
map screen, the GPS home page and BLDO1 rail control via the gates added in
the MECK_TWATCH rename.
- no GPIO button. Schematic sheet 1 wires the side switch SW7 to net PWR_KEY
-> AXP2101 pin 30 (PWRON), so PIN_USER_BTN is undefined and MECK_PMU_BUTTON
selects PMUButton, which reads PKEY interrupts over I2C. Short press is
enter/select; a 6s hold is a hardware power-off the firmware never sees.
- DLDO1 is the MAX98357A speaker rail (schematic sheet 6, net SPK_VDD), not
'unused' as LilyGo's doc claims. It stays off, so the amp is unpowered.
- VBACKUP is enabled at 3300 mV. It charges the MS412FE coin cell (J12) that
backs the PCF8563's single-VDD supply. Leaving it off drained the cell with
nothing to replenish it.
New envs: meck_twatch_s3_standalone, meck_twatch_s3_ble.
No existing board is affected: MECK_PMU_BUTTON is defined only here.
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.
T-Watch: So many UI changes. Also swapped render battery indicator to use the AXP2101 gauge for hopefully higher accuracy. Also implemnted meck rx duty cycle for watch builds only to test out power saving effects first on watch build before implementing elsewhere.
get dutycycle → reports the current duty as a percentage (e.g. > 50%)
set dutycycle <10-100> → sets it, saves to prefs, persists on reboot; anything below 10 or above 100 returns ERR - duty cycle must be 10-100
set af <value> is untouched, for anyone who prefers the raw factor
A complete `pio run` (all 16 environments) on Linux turned up 6
failures beyond the case-sensitive-include fix already on this
branch:
1. meck_remote_repeater, meck_wifi_repeater, meck_wifi_repeater_t5s3
compile GxEPDDisplay.cpp / FastEPDDisplay.cpp, which #include
MeckFonts.h whenever HAS_MECK_FONTS is defined. HAS_MECK_FONTS is
set at the shared variant-base level (so all envs in that variant
inherit it), but the `-I examples/companion_radio/ui-new` include
path needed to find MeckFonts.h was only added to the
companion-radio envs, not the repeater envs in the same file.
Added the missing -I flag to the three repeater env sections.
2. meck_wifi_repeater_heltec_v3/v4/v4_headless failed with "missing
SConscript file 'merge-bin.py'". esp32_base's extra_scripts still
pointed at merge-bin.py, which was deleted in 451f4b01 ("remove
redundant merge script"). Other variants override extra_scripts
themselves so they never hit the stale base default; the Heltec
variants don't, so they inherited the broken reference. Pointed
esp32_base at merge_firmware.py instead, matching every variant
that already sets this explicitly.
3. After fix#1, meck_wifi_repeater_t5s3 still failed: wifimqtt.cpp
had a hardcoded `extern AutoDiscoverRTCClock rtc_clock;`, but the
T5S3 variant declares its global rtc_clock as PCF85063Clock (a
different concrete RTCClock subclass) in target.h. The local
extern was redundant anyway, since target.h is already included
at the top of this file and declares the correctly-typed global
for whichever variant is being built. Removed the stale extern so
the call resolves through the existing declaration.
Verified: `pio run` now succeeds for all 16 environments.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
The repo has apparently only ever been built on case-insensitive
filesystems (macOS/Windows): every #include in the codebase uses
intended PascalCase/CamelCase header names (e.g. "SettingsScreen.h",
"WiFiMQTT.h"), but 28 of the actual files on disk were saved with
inconsistent casing (e.g. "Settingsscreen.h", "wifimqtt.h"). On a
case-sensitive filesystem (Linux) this is a hard compile failure, not
a cosmetic mismatch -- confirmed by running `pio run -e meck_audio_ble`
on Gentoo Linux, which failed immediately on "target.h: No such file
or directory" and a cascade of similar errors as each fix exposed the
next one.
Root causes, two flavors of the same underlying bug:
1. Header filename casing (29 files renamed via `git mv` to preserve
history): examples/companion_radio/ui-new/*, examples/simple_repeater/*,
and two variant-local headers (PCF85063Clock.h, TCA8418Keyboard.h x2).
Verified safe before renaming: every file has exactly one consistent
intended casing across all the places that #include it (checked via
a repo-wide scan comparing every #include against on-disk filenames,
zero conflicts found), so each rename is a pure no-op for behavior.
2. PlatformIO config paths using the wrong case for variant directories
that are actually lowercase on disk (variants/lilygo_tdeck_pro,
variants/lilygo_t5s3_epaper_pro):
- `-I variants/LilyGo_TDeck_Pro` / `-I variants/LilyGo_T5S3_EPaper_Pro`
in build_flags (3 occurrences, including lilygo_tdeck_max's
reference to TDeck Pro's shared headers) -- broke header resolution
for target.h and friends.
- `+<../variants/LilyGo_TDeck_Pro>` / `+<../variants/LilyGo_T5S3_EPaper_Pro>`
in build_src_filter (2 occurrences) -- silently excluded the board-init
.cpp files (TDeckBoard.cpp etc.) from compilation entirely, which
didn't fail until the *link* stage ("undefined reference to
radio_init()", `TDeckBoard::begin()`, etc.) since PlatformIO's glob
just matched nothing rather than erroring.
Verified fix: `pio run -e meck_audio_ble` now compiles, links, and
produces a firmware image cleanly (RAM 53.1%, Flash 49.6%).
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Keyboard LED brightness (T-Deck Pro MAX):
Adds a "Keyboard LED" row to Settings (MAX only), below Backlight
Brightness and mirroring it: 5-100% in 5% steps, default 50%. The
both-shifts keyboard backlight toggle previously used a hardcoded PWM
level of 8 (~3%), too dim for some users; it now reads the stored
percentage and maps it to PWM, taking effect on the next toggle.
- NodePrefs.h: new kb_backlight_pct field (5..100, default 50)
- Settingsscreen.h: ROW_KB_BACKLIGHT row plus label/edit handling
- DataStore.cpp: load/save/clamp, appended so existing prefs files stay
compatible (fall back to 50%)
- main.cpp: toggle uses kb_backlight_pct (percent -> PWM) instead of 8
Standalone unread counter fix:
On standalone builds the home-page MSG count and channel-picker unread
badges never updated, although messages arrived and displayed normally.
ArduinoSerialInterface::isConnected() is hardcoded to return true (a plain
UART has no connection state), so the periodic
setHasConnection(_serial->isConnected()) in MyMesh left hasConnection()
permanently true -- making UITask mark every received message read on
arrival. The same stuck flag also suppressed the DM counter and the
new-message screen wake. Guard the call so only builds with a real
companion (BLE / WiFi / wired SERIAL_RX) derive connection state from the
interface; companion-less builds report not-connected. The core
ArduinoSerialInterface is unchanged, preserving wired-companion behaviour.
- MyMesh.cpp: guard setHasConnection() for companion-less builds
main.cpp — added a dispatch block in the Settings handler: when the network picker is showing and key=='\b' with shift consumed, it calls ui_task.injectKey('q'), which runs the existing 'q' exit path synchronously (tear-down of EDIT_WIFI, onboarding handling, wifiReconnectSaved()) and refreshes. So Shift+Del and Q now both exit the picker, with no duplicated exit logic.
The "SMS Inbox" badge on the Phone & SMS landing screen previously showed
the number of conversations regardless of read state. It now shows the
number of unread received messages and disappears when there are none.
Read state is tracked persistently, so it survives reboots and modem
power-cycles (the flag lives in each record on the SD card).
SMSStore:
- Add a `read` byte to SMSRecord, reusing one of the reserved bytes so the
record stays 256 bytes and every existing field offset is unchanged
(existing .sms files remain readable).
- saveMessage marks sent messages read and received messages unread.
- loadConversations scans each file and reports unreadCount (received
messages with read=0); preview / last-message behaviour is unchanged.
- markConversationRead / markFileRead flip received-unread records to read
in place (open "r+", rewrite only the affected records).
- begin() runs a one-time migration on first boot that marks all
pre-existing history read, gated by a marker file (/sms/rdmig.dat), so
old messages do not all appear as unread after the update.
SMSScreen:
- Landing-screen badge sums unreadCount across conversations, hidden at zero.
- Opening a conversation marks it read and clears its in-RAM count.
- A message arriving while its conversation is open is marked read.
- Inbox reloads on the landing screen as well as the inbox view, so the
badge updates live when a message arrives.
RX packet counter: shows total received packets (flood + direct) on the
radio details page; RAM-only, resets on boot and on any SF/freq/BW change.
Rx Log: app-style packet sniffer opened from Settings > "Rx Log >>".
Captures the last 100 received packets pre-filter via Dispatcher::logRx
into a PSRAM ring, with decoded "sender: message" lines matched by packet
hash for decryptable channels. Each entry shows route/type, time, size,
hash, path, channel or From/To, SNR. W/S scroll, Q back to Settings;
T5S3 swipe-scroll rides the same path.
Files: MyMesh.h/.cpp, RxLogScreen.h (new), UITask.h/.cpp,
SettingsScreen.h, main.cpp.
GPS — fixed (the "off" toggle and boot path now actually cut the XL9555 rail). Kept in main.cpp + UITask.cpp.
BLE controller — the ~13 mA between the BLE build (BLE off) and standalone is the controller staying initialised; the boot-gate in SerialBLEInterface.cpp/.h defers BLEDevice::init() until first enable, reclaiming it. That's the meaningful idle win.
CPU, gyro rail, ES8311, frontlight — all measured and ruled out. The residual ~12 mA Max-vs-Pro is distributed always-on hardware with no software switch — hardware overhead, not a bug.
Defer ESP32 BLE controller bring-up to first user enable
MyMesh::startInterface() called serial.enable() unconditionally at boot. On the ESP32 BLE build this ran the deferred-init SerialBLEInterface's _realBegin()/BLEDevice::init() and powered the BT controller before main.cpp's boot-time disable(), which only stops advertising and cannot power the controller back down -- so the controller stayed up while "off", drawing ~13 mA at idle. Guard the enable() so ESP32 BLE builds skip it at boot; the controller now comes up lazily on the first enable() when the user turns Bluetooth on from the Bluetooth page. WiFi builds are unaffected and still enable at boot.
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.
meck