--- tags: [project-drogheda, test-plan, power, battery, firmware, backend] project: Project Drogheda author: Helgen CTO date: 2026-09-10 status: Draft — evaluation procedure --- # Backup-power evaluation: the procedure !!! warning "Designators from before 22-Oct (T43)" This document keeps the designators the board had on its date. Since 22-Oct (T43) the V5.6, V5.7 and v6 carry new ones, and several old names now belong to another part: on the V5.6/V5.7 the LTC4040 is U14 (was U6); on the v6, U6 is the modem and the LTC4040 is U17. To read it against today's board, use the [old → new table](https://drogheda.helgen.online/hardware/designadores-t43-22oct/#8-tablas-viejo-nuevo) (in Spanish); parts already gone by 22-Oct are not in it. > **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 ```sql 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 1. Real Telcel SIM. If D2 said yes: `AT+CPSMS=1,,,"",""`. Measure **modem sleep current in PSM**, and **energy per wake→TX→sleep cycle** in joules. 2. If D2 said no: measure **energy per full attach cycle** the same way. 3. 🔴 **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:** 1. **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. 2. 🔴 **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. 3. **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.