Skip to content

Low-battery warnings latch once per discharge; only a charger re-arms - #549

Merged
brickbots merged 1 commit into
mainfrom
fix/low-battery-warner-latch
Jul 27, 2026
Merged

Low-battery warnings latch once per discharge; only a charger re-arms#549
brickbots merged 1 commit into
mainfrom
fix/low-battery-warner-latch

Conversation

@brickbots

Copy link
Copy Markdown
Owner

The bug (heard in the field)

During the 2026-07-24 bench discharge runs the 10%/5% low-battery warning earcon fired ~90 times per run (replaying the telemetry through LowBatteryWarner reproduces 93 fires on one unit, 86 on the other — every 30–90 s for the final ~90 minutes). Design intent was once at 10% and once at 5%.

Why the hysteresis failed

The shipped guard re-armed a threshold when the estimate climbed 2 points clear of it. But near the discharge curve's flat knee, one BATV ADC step (20 mV) is worth ~3 SoC points, and under the varying solve load the published estimate bounced across 4–23% for the whole tail of the discharge. Every two-step upward bounce re-armed a threshold; the next dip re-fired it. The published SoC values in that window were {4, 6, 8, 10, 13, 16, 19, 23} — swings of 6+ points between 5-second samples. No percent-based hysteresis clears quantisation noise that large while still re-arming on any genuine recovery a single-cell battery can produce.

The fix

Crossings latch for the whole discharge; thresholds re-arm only on external power (so the next discharge warns afresh). Nothing within a discharge re-arms them — not a climbing estimate, not a blind (None) sample. The blind-twilight guard from #541 is unchanged (and the field data confirmed it worked — zero re-fires from blind samples).

battery_fake gains a two-poll charging phase between laps, since with the latch a -fh -fb dev run would otherwise demo the warnings on the first lap only.

Tests

  • test_field_discharge_tail_warns_exactly_twice — replays the actual pf4-dev discharge tail (one sample per minute, 20:00–21:15, embedded as a fixture): exactly one 10% and one 5% warning across the full noisy descent. The old code re-fires many times on this same sequence.
  • test_field_discharge_repeats_after_a_charge — the latch is per-discharge, not forever.
  • test_climb_never_rearms_within_a_discharge, updated jitter test with realistic (multi-LSB) bounces; all other Low battery: blind-floor shutdown, 10%/5% warnings, re-anchored SOC_LUT (ADR 0021) #541 warner semantics (fast-drop most-severe-once, twilight guard, charging re-arm) unchanged and still covered.

Full suite: 990 unit+smoke passed; ruff + mypy clean.

🤖 Generated with Claude Code

The 2026-07-24 bench discharges fired the 10%/5% warning earcon ~90
times per run (93 and 86 on the two units, every 30-90 s for the final
~90 minutes). The 2-point climb-clear hysteresis was no match for the
real signal: near the discharge curve's flat knee one BATV LSB (20 mV)
is ~3 SoC points, and under the varying load the published estimate
bounced across 4-23% — every two-step upward bounce re-armed a
threshold and the next dip re-fired it.

No percent-based hysteresis clears noise that large while still
re-arming on any genuine recovery a single-cell battery can produce, so
crossings now latch for the whole discharge and only external power
re-arms them. The blind-twilight guard (None never re-arms) is
unchanged and was confirmed working in the same runs.

battery_fake gains a two-poll charging phase between laps so the -fh
-fb dev loop still demos the warnings on every lap, not just the first.

Regression tests replay the actual pf4-dev discharge tail (one sample
per minute, 20:00-21:15): exactly one 10% and one 5% warning, and the
same again after a charge.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@brickbots
brickbots marked this pull request as ready for review July 25, 2026 22:36
@brickbots
brickbots merged commit afcb80a into main Jul 27, 2026
4 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant