You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Commit 2c42870
Browse filesBrowse the repository at this point in the historyBrowse files
fix(telemetry): stop the estimate flickering, and stop the history eating itself
Five defects in the paths that feed EVChargePilot's range figure and its
trip store.
The adaptive range gated on the live battery power reading. The question
that gate asks is whether this firmware can measure power at all, and the
answer does not change between two polls — but one unanswered sample
erased a figure computed from stored trips and the pack's charge, neither
of which had moved. Latched instead: never published means refuse, once
published stays published.
Trips that happened to agree gave a band of exactly zero. "266,7 ± 0,0
km" reads as a measurement, which is the one thing provenance exists to
stop an estimate doing; the spread of eight of one driver's trips is not
the error of extrapolating to a pack. The band gets a floor.
Quarantining a corrupt history copied it aside and left the original, so
every later read failed on it again and wrote another copy — one file per
read, unbounded, where the driver cannot see them. The original now goes.
Bounding the file re-encoded every remaining trip after each evicted
track, up to two hundred trips of four thousand samples, on the path that
ends a drive. The envelope's size is arithmetic, so eviction subtracts as
it goes.
Decimation dropped the newest sample. The track halves when the sample
just added overflows it, and on an even-sized track that sample sits at an
odd index — so every doubling discarded the most recent moment of the
trip, which is the one a model can least do without.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
0 commit comments