Commit Graph
4 Commits
Author SHA1 Message Date
meck 755f883d66 Watches: set the BMA423 step counter watermark, raise ODR to 100 Hz
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.
2026-07-10 20:30:01 +10:00
meck 006d3bd00c T-Watch S3: alarm rings for the full 5 minutes, PWR key dismisses
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.
2026-07-10 20:13:18 +10:00
meck 9754f93504 T-Watch S3: vibrate alarm clock in place of the Maps tile
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.
2026-07-10 19:39:18 +10:00
meck df00c435f9 Fix T-Watch S3 build; disambiguate the S3 Plus env names
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.
2026-07-10 19:08:15 +10:00