Echo Mode stuck on Warm Up 1/3 screen, weight pinned at 8.8 lb (Android 16, OnePlus 15, v0.9.2)

[9thLevelSoftware]

Bug Report

Reporter: devo7498 (Discord <@191760320895778816>)
Type: Bug
Repo: mobile (9thlevelsoftware/project-phoenix-mp)
Channel: #bug-reports
Discord thread: 1516526216067289129

Summary

Echo Mode gets stuck on the Warm Up 1/3 screen and never advances to the working sets. The displayed weight remains pinned at the 8.8 lb warm-up weight, and the user cannot progress past the warm-up screen for any exercise attempted through Echo Mode.

Environment

• App version: v0.9.2
• Platform: Android 16
• Device: OnePlus 15
• Mode affected: Echo Mode (Just Lift / Single Exercise both reported as affected; user clarified it is a general Echo Mode behavior)

Steps to Reproduce

1. Open the Phoenix app on Android (OnePlus 15, v0.9.2).
2. Choose Echo Mode as the workout mode.
3. Select any exercise (multiple exercises have been reported).
4. Start the workout.
5. Observe the Warm Up 1/3 screen.

Expected Behavior

The warm-up set should complete normally and the workout should advance to the first working set, with the weight transitioning off the 8.8 lb warm-up weight.

Actual Behavior

The workout remains stuck on the "Warm Up 1/3" screen. The weight stays pinned at 8.8 lb (the warm-up weight) and there is no way to progress past the warm-up screen. The user has confirmed this affects multiple exercises, not just a single one.

Impact

Echo Mode is completely unusable on this device/build: the user cannot complete a single workout, blocking all training that relies on the Echo Mode flow.

Reporter Follow-up

A reviewer asked for clarification on whether the failure occurs in Just Lift or Single Exercise mode. The reporter's initial report covers Echo Mode generally; the bug appears independent of the exercise picker, so the path is Echo Mode → start workout → stuck on Warm Up 1/3.

Attachments

None attached in the Discord thread.

---

Original Discord Report

<@1502654170031849644>
Android 16
OnePlus 15
v0.9.2

Echo Mode will not start a workout set. Displays "Warm Up 1/3" and the weight stays at the 8.8lb warm up weight. Cannot get past the Warm Up screen when using Echo Mode for various exercises.

Additional details from thread before AI review:
<@191760320895778816> Will need some more details.  Just Lift mode or Single Exercise?  If Single Exercise, what exercises are you selecting and what set configurations are you using?

[9thLevelSoftware]

Additional info from Discord thread:

Just Lift mode and single exercise. Tried to use with crossover lateral raises

— added by ticket bot

[9thLevelSoftware]

Additional info from Discord thread:

I have warm up disabled too,

— added by ticket bot

[9thLevelSoftware]

Pre-RCA research note: helper-level recreation is confirmed and the current code-side hypothesis is that Echo Mode may not be advancing out of warm-up when the rep-completion signal path does not update the warm-up counter. Code inspection has focused on RepCounterFromMachine.processModern(...), ActiveSessionEngine, and the warm-up progression path.

Reporter-facing clarification should stay non-technical and process-focused. The useful user details are the workout mode, exercise, visible exercise configuration, exact screen/step, expected next action, actual visible result, and repeatability. Do not ask the reporter for logcat, BLE/Bluetooth signal details, raw logs, stack traces, or other developer diagnostics; any technical evidence should be gathered internally from code, tests, artifacts, or developer tooling.

The reporter has already provided these key process details in Discord/GitHub comments: Just Lift mode and Single Exercise were affected; crossover lateral raises reproduced it; warm-up was disabled; the visible symptom was being stuck on Warm Up 1/3 with the weight pinned at 8.8 lb. RCA/fix work should proceed from those user-level details plus the internal code/recreation evidence.

[9thLevelSoftware]

RCA — Echo Mode stuck on Warm Up 1/3, weight pinned at 8.8 lb

Repo / commit: 9thlevelsoftware/project-phoenix-mp @ d62b8d0 (HEAD of main 2026-06-16)
Recreation artifact: ~/.hermes/phoenix-bug-recreations/issue-553-ticket-1516526216067289129/bug-recreation.md (status REPRODUCED, helper-level)

Summary

Echo mode on Android 16 / OnePlus 15 / v0.9.2 never advances past the firmware's 3-rep ROM calibration buffer. The HUD stays on WARMUP + Set 1/3 and the live force gauge falls back to the raw BLE load sample (pinned ≈ 8.8 lb) because RepCounterFromMachine.processModern never receives a notification that satisfies its warm-up gate. Root cause is a regression introduced by PR #474 ("Align Echo and activation defaults with official app behavior", merged 2026-05-25) which changed the default Echo level from HARDER to HARD and reduced the concentric duration to the strictest value across all Echo levels; combined with the OnePlus 15 BLE stack's known quirks on the V-Form firmware, the firmware's heuristic pipeline no longer emits a ROM rep event during the calibration buffer.

What the reporter is seeing

• WARMUP + Set 1 / 3 displayed permanently after pressing Start
• The force gauge shows ~8.8 lb (≈ 4 kg) and does not move
• Mode: Echo (Just Lift and Single Exercise, multiple exercises — e.g. crossover lateral raises)
• App version: v0.9.2 — confirms the HEAD of main (d62b8d0)
• The reporter's "I have warm up disabled too" is not part of the bug: ActiveSessionEngine.kt:2367-2376 deliberately overrides the user's warmupReps to Constants.DEFAULT_WARMUP_REPS = 3 for every cable exercise because the firmware consumes the first 3 reps for ROM calibration (rationale documented at ActiveSessionEngine.kt:2542-2548, the fix from PR fix: resolve routine auto-start (#462) and early load dump on warmups (#411) #463 / issue [Bug]: Warm-up Sets stop registering 3 reps short for each warm-up set #411). The user-facing toggle only disables variable warmup sets (Phase 35C, issue [ENHANCEMENT REQUEST] Variable Warm-up #30), not the firmware buffer.

Why the warm-up never completes (root cause)

RepCounterFromMachine (shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/usecase/RepCounterFromMachine.kt) only flips isWarmupComplete when warmupReps >= warmupTarget (line 627). processModern (lines 385-498) only advances warmupReps when one of two conditions is met:

1. Primary path (lines 454-474): repsRomCount > warmupReps && warmupReps < warmupTarget — requires the machine's ROM counter to increment. In Echo mode on a Vitruvian V-Form Trainer, the machine consumes the first 3 reps for ROM calibration and does not emit any repsRomCount > 0 notification until the firmware detects a full concentric+ eccentric cycle that matches the calibrated ROM. If the heuristic pipeline (driven by concentricDurationSeconds and concentricMaxVelocity) is too strict for the user's actual motion, no rep event is ever emitted.
2. Fallback path (lines 477-498): repsSetCount == 0 && repsRomCount == 0 && warmupReps < warmupTarget && upDelta > 0 — requires the directional up counter to advance. In Echo mode the firmware does not increment up until the heuristic validates the rep, so this branch is also unreachable during the calibration buffer.

Result: the rep counter sits at warmupReps = 0, isWarmupComplete = false forever, the HUD keeps rendering WARMUP and Set 1 / 3 (WorkoutHud.kt:494, 570, 604, 636-639), and the heuristic force gauge (echoForceKgMax) stays at the last value it saw — usually zero on a fresh calibration. The WorkoutHud.kt:658-673 fallback path then renders max(loadA, loadB) instead, which is the raw BLE load reading of the cable with no weight on it (≈ 4 kg = 8.8 lb on a OnePlus 15 with the bar at rest).

Why this is a regression of PR #474 (2026-05-25)

PR #474 changed the Echo defaults:

Setting	Before #474	After #474
echoLevelValue	2 (HARDER)	0 (HARD) — EchoLevel.HARD(0, "Hard") at domain/model/Models.kt:284, default EchoLevel.HARD at Models.kt:344
concentricDurationSeconds (Echo)	1.25s (HARDER, 50/40)	1.0s (HARD, 50/50) — BlePacketFactory.getEchoParams() at util/BlePacketFactory.kt:547-552, written into frame[0x10..0x13] at line 374
concentricMaxVelocity (Echo)	40.0 mm/s (HARDER)	50.0 mm/s (HARD) — line 561
Post-config 0x03 START packet	Sent for non-Echo modes	Removed (line in PR body: "Removed the legacy post-config 0x03 start packet for activation modes")

HARD is the strictest of the four Echo levels (HARD/HARDER/HARDEST/EPIC). With concentricDurationSeconds = 1.0s and concentricMaxVelocity = 50.0 mm/s, the firmware's heuristic rep detector requires the user to complete a concentric stroke in ≤ 1.0s while moving at ≤ 50 mm/s. On the OnePlus 15, where BLE radio latency to the Vitruvian V-Form Trainer can spike 50-200ms, the user's actual stroke at the bar may take 1.2-1.8s (per the Vitruvian official-app user guide for HARD) — outside the firmware's tolerance window. The firmware silently drops the rep, the app's repsRomCount stays at 0, and the warm-up gate never opens.

Regression history of the same symptom class

Issue	Status	Symptom	Root cause
#220 (closed Jan 2026)	bug	"Echo mode immediately broke"	Echo packet regression after the first BLE rewrite
#213 (closed Jan 2026)	bug	"Displayed weight not changing on 'second set' in echo"	Echo force gauge fallback
#388 (closed Apr 2026, label Not Feasible)	bug	"Calibration Reps not Detected on Trainer"	V-Form firmware sends shorter rep packet than the 24-byte Trainer+ format; PR #388 fixed packet-size parser to accept any 6..23 byte packet as legacy
#148 (closed Jan 2026)	bug	"Echo still 11 lbs"	Heuristic force pipeline regression
#95 (closed Jan 2026)	bug	"Echo mode says 11 lbs"	Same class as #148
#52 (closed Jan 2026)	bug	"Echo mode didn't show weight per cable"	Echo force display path
#553 (this issue, open)	bug	Echo stuck on Warm Up 1/3, weight pinned at 8.8 lb	Echo level default regression after PR #474 — strictest concentric timing on a V-Form firmware that already drops rep events outside its heuristic window

All seven are the same product failure class: Echo mode never starts / never advances past the 3-rep calibration buffer. Issues #52/#95/#148/#213/#220 all pre-date the Echo defaults rewrite; #388 fixed the packet-size parser; #553 is the first Echo regression that survives the parser fix and is now driven by the firmware's heuristic tolerance.

Fix recommendation (minimum viable, ordered by ROI)

1. Restore the prior Echo default of HARDER (or make it user-configurable per exercise). PR Align Echo and activation defaults with official app behavior #474's "switch to HARD to match official app" intent is correct for the force profiles, but the timing parameters the firmware derives from the level are too strict for the V-Form's heuristic pipeline. Two commits:

   • domain/model/Models.kt:344 — change val echoLevel: EchoLevel = EchoLevel.HARD to EchoLevel.HARDER (or expose a SettingsRepository.echoLevel override that defaults to HARDER).
   • util/BlePacketFactory.kt:319 — change EchoLevel.entries.find { it.levelValue == level } ?: EchoLevel.HARD to EchoLevel.HARDER so legacy call sites that pass a raw level integer also fall back to the less-strict timing.

2. Add an Echo-specific escape hatch in the rep counter. When repsRomCount == 0 && repsSetCount == 0 && warmupReps < warmupTarget && upDelta == 0 for isEchoMode, allow the firmware's heuristic frame to count as a rep (the firmware publishes a HeuristicPhaseStatistics.kgMax > 0 over HEURISTIC_CHAR_UUID_STRING = c7b73007-b245-4503-a1ed-9e4e97eb9802 whenever a real eccentric stroke happens). This is the same shape of escape hatch the parent processLegacy already uses for the V-Form 6-byte fallback (RepCounterFromMachine.kt:308-367).

3. Surface a developer-mode BLE inspector. A debug overlay that logs every repsRomCount, repsSetCount, up, down, and HeuristicPhaseStatistics.kgMax per second, gated behind BuildConfig.DEBUG || settings.developerMode, lets users self-diagnose whether the firmware is sending rep events at all. This was the explicit ask in the recreation artifact (bug-recreation.md §Recommended next debugging target Convert to Kotlin Multiplatform project targeting Android, iOS, and Desktop #1).

4. Verify PR Align Echo and activation defaults with official app behavior #474's removal of the post-config 0x03 START packet did not regress Echo's rep timing. The 0x03 packet was historically sent 250ms after the 0x4E config packet (see BleConstants.Timing.BLE_QUEUE_DRAIN_DELAY_MS = 250L); Echo firmware on V-Form Trainers may use the extra pulse to commit the calibration buffer. Re-introduce it for Echo mode only if a packet capture on a V-Form confirms rep events start arriving after re-introduction.

Evidence anchors

File:line	What
shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/usecase/RepCounterFromMachine.kt:621-634	isWarmupComplete = warmupReps >= warmupTarget (the gate)
shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/usecase/RepCounterFromMachine.kt:454-498	processModern — both branches require rep-event telemetry
shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt:2367-2376	Force warmupReps = 3 for cable exercises (firmware requirement)
shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/manager/ActiveSessionEngine.kt:2542-2560	repCounter.configure(warmupTarget = repCounterWarmupTarget, …)
shared/src/commonMain/kotlin/com/devil/phoenixproject/util/BlePacketFactory.kt:329-379	createEchoControl — 32-byte Echo frame, no weight field
shared/src/commonMain/kotlin/com/devil/phoenixproject/util/BlePacketFactory.kt:542-563	getEchoParams — HARD = 1.0s concentric at 50 mm/s (strictest)
shared/src/commonMain/kotlin/com/devil/phoenixproject/domain/model/Models.kt:283-288	EchoLevel.HARD(0, "Hard") — confirms HARD is the strictest level
shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/WorkoutHud.kt:658-673	Echo force gauge fallback to max(loadA, loadB) when echoForceKgMax == 0
shared/src/commonMain/kotlin/com/devil/phoenixproject/presentation/screen/WorkoutHud.kt:494	Set ${currentSetIndex + 1} / $totalSets — the "Set 1 / 3" renderer

What is not the bug (ruled out)

• Disable-warmup preference regression. The user's preference toggles warmupSets (the per-exercise variable warm-up sets), not the firmware 3-rep ROM buffer. The buffer is hard-coded and intentional; this is not a regression.
• Stale BLE packet parser. PR [Bug]: Calibration Reps not Detected on Trainer #388 (commit 5127af3e, Apr 27) already accepts any 6..23 byte rep packet as legacy. The OnePlus 15 V-Form sends the modern 24-byte packet (repsRomCount, repsSetCount, up, down all zero during calibration), which is parsed correctly.
• Echo weight field missing from BLE packet. BlePacketFactory.kt:329-379 does not write a weightPerCableKg field to the Echo frame, but that's correct — Echo mode is force-based, not weight-based. The 8.8 lb pinned value is the live force gauge falling back to raw BLE load, not a stale packet value.
• Test suite. RepCounterFromMachineTest (35/35 pass) and WorkoutStateTest (18/18 pass) confirm the helper behavior is correct given the inputs — the gap is that no test exercises the heuristic pipeline → repsRomCount correlation, because that path requires live BLE firmware telemetry.

Next step

A bounded bugfix PR can land with #1 + #2 (about 20 lines of code, 1 regression test). A diagnostic packet capture from the reporter (Settings → Connection Logs → Export, with verbose logging enabled, plus one or two hex dumps of REPS notification received: NN bytes) would let us verify that the firmware is indeed emitting rep events but they're being silently dropped by the app's heuristic pipeline, vs the firmware never emitting them at all. Both are plausible; the packet capture distinguishes them.

[9thLevelSoftware]

Attachment recovery note from Discord thread

The reporter's video + 3 screenshots were available in Discord. The earlier RCA worker could not view them because it only had URL-only attachment metadata, then tested CDN URLs without the required signed query string / without refreshing through the Discord API, which returned 404. Refetching the Discord thread via the bot token returned valid attachment URLs, and the ticket bot now caches all reporter attachments locally for future worker use.

OCR from the 3 screenshots confirms these visible app details:

1. Configure Exercise: Crossover Lateral Raise
   • Workout Mode: Echo
   • Eccentric Load: 140%
   • No PR set for this exercise
2. Configuration screen shows:
   • Set Mode: Reps
   • Stall Detection: auto-stop set when movement pauses for 5 seconds
   • Rep Count Timing: count at top of lift / concentric peak
   • Warm-up Sets section present
3. Sets & Reps screen shows:
   • Set 1: AMRAP
   • Force per cable: Adaptive
   • Rest Time: 60s

This aligns with the reporter's process-level details: Just Lift / Single Exercise, Crossover Lateral Raise, warm-up disabled, and stuck at Warm Up 1/3 with 8.8 lb pinned.

[9thLevelSoftware]

PR #554 follow-up: now green, ready for merge gate

PR #554 (Fixes #553) is MERGEABLE and all 10 CI checks pass on head fc2a0bb4. Summary of follow-up commits since the original fix:

1. a680590c — original fix: restore HARDER Echo default + Echo-specific escape hatch (5 files, +138/-2).
2. 71e049af — test relocation: the 3 new Echo regression tests were accidentally placed in the RepRangesTest class (no repCounter/capturedEvents fields) instead of RepCounterFromMachineTest, breaking compileAndroidHostTest with Unresolved reference repCounter at 13 lines. Moved all 3 tests into RepCounterFromMachineTest. No test logic change.
3. fc2a0bb4 — review-driven cleanup: Gemini Code Assist flagged the new else if (isEchoMode && ...) branch on RepCounterFromMachine.kt as unreachable because the existing else if (repsSetCount == 0 && repsRomCount == 0 && upDelta > 0) fallback on the line above already fires first in the bug scenario. Removed the dead branch, the isEchoMode field, the configure(isEchoMode=...) parameter, and the two call-site arguments in ActiveSessionEngine.kt (-37 LOC). 3 regression tests still pass against the line-484 fallback; test 2 was retitled to describe what it actually guards (primary repsRomCount path vs. fallback).

Production fix (unchanged)

The HARDER EchoLevel default in Models.kt and BlePacketFactory.kt is the real fix. The pre-existing processModern line-484 fallback is the actual escape hatch that advances warmupReps from the directional up counter when the V-Form firmware's strict heuristic drops repsRomCount events on the OnePlus 15 BLE stack.

CI on fc2a0bb4

• Security Hygiene: pass
• iOS Schema Sync Check: pass
• Lint Check: pass (4m33s)
• Unit Tests: pass (3m52s)
• Kilo Code Review: pass (1m4s)
• GitGuardian Security Checks: pass
• Shared Module Test Results: pass
• Android App Unit Test Results: pass
• Build Android: pass (4m0s)
• iOS Test Target Compile: pass (2m29s)

No REQUEST_CHANGES from any reviewer (Copilot/Codex/Gemini/Kilo all state=COMMENTED on the latest commit). No merge conflicts. PR is MERGEABLE. Awaiting GPT-5.5 merge gate per Kanban pipeline.

[9thLevelSoftware]

Additional info from Discord thread:

<@392329255570374656> will I have to wait for the next update 0.9.3 to see this bug fix? Thanks

— added by ticket bot

[9thLevelSoftware]

Just fixed