Backup-power evaluation: the procedure

It is not a lot of things to do. It is three measurements and a decision. Everything else in the last three notes is contingent on them — most of that list deletes itself once D3, P1 and P2 come back. Do not start firmware before Gate G1.

Critical path: D3 (requirement) → P1 (sleep floor) → P2 (modem) → F1 (firmware) → S1 (server) → decide the cell last. ≈ 3 weeks of elapsed time, ~7 person-days of work.

Phase D — desk, no hardware. 1 day. Kills most of the list.

#	Task	Owner	Output
D1	Fleet `tbat`/`tntc` histogram from `htracker`: hourly distribution per unit over 30 d; % of day above 42 °C; longest continuous window below 40 °C; correlate `cflt` and charge events with those windows	backend	one chart + two numbers
D2	Ask Telcel: is PSM / eDRX available on our APN and plan? What TAU / Active Timer will the network grant?	Leo	yes/no + granted timers
D3	🔴 Pin the requirement. From ICAVE ops / the contract, not from us: how long must a unit keep reporting on battery, and what must it report?	Leo	a number in hours, and a message spec

Gate G0 — do not proceed without D3. Every number downstream is sized by it. If the answer is "report the outage and survive until someone attends, ~24 h", the whole problem is already solved by the firmware and the cell question closes. If it is "7 days of live tracking", that is a different product and needs a different pack.

D1 query sketch

SELECT cell_id, date_trunc('hour', ts) AS h,
       avg(tbat) AS tbat_avg, max(tbat) AS tbat_max,
       sum((tbat > 42)::int)::float / count(*) AS frac_above_42
FROM phlg WHERE ts > now() - interval '30 days' AND tbat > -100
GROUP BY 1,2 ORDER BY 1,2;

Then: per unit, the longest run of consecutive hours with tbat_max < 40. Success bar is not "always cool" — it is "≥ 15 min below 40 °C per day" (see the duty-cycle brief §3). That is a much easier bar and may already be met.

Phase P — bench. The measurement that decides everything. 2–3 days.

Rig

One v5.5 board, bench PSU at 3.7 V into P4 (pack position), current measured at BAT+ — that is what the pack actually delivers, and it captures the LTC4040 boost's light-load efficiency, which is one of our real unknowns. Measure the 5 V rail in parallel so you get both numbers and can derive the boost efficiency.

⚠ A bench DMM will not do this. You need µA-to-A dynamic range on one trace: a Nordic PPK2 (~US$110) or Joulescope/Otii. Buy it — it pays for itself in this test alone, and every low-power decision after this depends on trusting the number.

P1 — the subtraction ladder 🔴

Measure, then remove one load, measure again. The deltas are the deliverable — they tell you which fixes are worth writing and which are noise.

Step	State	Expect
a	Full `RUNNING`, stack up, fan off	~2.5 W baseline
b	`PWR_CTRL` low (RTK stack off)
c	`BYP_CTRL` low (`K1` released)	−150 mW — confirms the K1 reversal
d	`U12` disabled + `W5500` held in reset	−400 mW?
e	All LEDs off (incl. gauge `PB12–15`)	−50…150 mW
f	`MAX3232` / `SP3485` / `SC16IS752` in shutdown	−5…15 mW
g	MCU in STOP + LSE RTC (not `loop()`)	−150 mW
h	`U17` lifted, `/3V3` fed from bench supply through the meter	isolates the AMS1117's own Iq — the number I most expect to be ugly

Gate G1: is the achievable floor under 50 mW? Yes → proceed to firmware. No → find out what is holding it up before writing any. If step (h) is 25–55 mW as expected, the LDO swap is a one-part change worth doing first.

P2 — modem energy and the burst

Real Telcel SIM. If D2 said yes: AT+CPSMS=1,,,"<TAU>","<Active>". Measure modem sleep current in PSM, and energy per wake→TX→sleep cycle in joules.
If D2 said no: measure energy per full attach cycle the same way.
🔴 The burst test. With a real pack at low SoC and the pack at 45 °C, trigger an LTE attach and watch MAIN5V on a scope. Does PFI (4.60 V) trip? This is the most likely way the design fails in the field and it is cheap to check now.

Gate G2: PSM or power-cycle, and the interval locked. Feed the measured joules back into the runtime table.

Phase F — firmware. 3–4 days, once G1 and G2 pass.

BACKUP_SLEEP as a real state behind a compile flag (ENABLE_BACKUP_DUTYCYCLE), per the state machine in the duty-cycle brief §8. Today's SLEEP stays as the brownout failsafe.
Exercise it first in the hostsim harness already in the repo — state transitions, adaptive cadence, BAT_CRITICAL final message — before it touches silicon.
F1 acceptance, on the bench: real pack, real SIM, 72 h continuous with the meter logging. Deliverable = measured Wh/day and extrapolated runtime.
Gate G3: measured Wh/day within 30 % of the model. If it is not, the model is wrong and everything downstream needs re-deciding — do not paper over it.

Phase S — server-side synthesis. Your idea, and it is a good one. 1–2 days.

Holding the position server-side decouples what the customer sees from what the radio does. The device sends a heartbeat every 30–60 min; retranslator.py keeps feeding Wialon at 1 Hz from the last known fix. That is the right split.

But three rules, and they are not optional:

Mark it. Synthesized points carry an explicit source flag and render differently in the UI. We are generating data that did not come from a sensor; anyone reading the track must be able to see that. Do not let a synthesized point be indistinguishable from a real one.
🔴 Hard stop on a missed heartbeat. The moment a heartbeat is late by more than one interval, stop synthesizing and switch the unit to "last seen at X, T ago — unknown". Synthesizing past the heartbeat window turns a dead unit into a healthy-looking one on the operator's screen. That is strictly worse than reporting nothing, and it is exactly the failure this feature would be blamed for.
Movement breaks the illusion instantly. The U26 accelerometer wake exists for this: if the machine moves during an outage, the unit wakes and sends a real fix, and the server drops out of synthesis on the spot. Without motion-wake, a towed machine keeps reporting from the yard — with a port customer, that is a liability, not a bug.

S1 test: on the bench, cut vehicle power → verify Wialon shows a continuous 1 Hz track flagged as battery-mode → cut the unit entirely → verify the track stops and the unit goes "unknown" within one heartbeat interval, not later. Also check whether ICAVE's contract or Wialon billing counts records — synthesized ones may not be acceptable to count.

Phase C — the cell decision, last

Only now, with measured Wh/day (F1) and the real temperature histogram (D1):

Daily energy < ~2 Wh and D1 shows ≥ 15 min/day below 40 °C → keep the current cell. No LFP, no RNTB change, no new case. Consider shrinking the pack instead.
Otherwise → high-temp LFP + RNTB → 5.6 k + B3380 NTC + JP2 re-strap, per the battery note. Order sample cells at D1 time so they are on the shelf if needed — that is the only long-lead item, and sampling two cells costs nothing.

Phase V — field pilot. 30 days.

Two units at ICAVE on the new firmware, rest of the fleet as control. Track: actual outage events, hours survived, vbat trajectory, charge-window utilisation, and any operator complaint about the synthesized track. Ship to the fleet only after 30 clean days.

What this is not

Not a v6 respin. Nothing above requires new hardware except a possible one-part LDO swap and, if Phase C says so, a cell and one resistor. The 30-unit build is not blocked by any of it — but D3 should be answered before that build ships, because it may change what pack goes in the box.

8.2 KiB Raw Blame History Unescape Escape