Leopoldo Rodríguez
d70dd806be
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QCy5VHMVLkAmftYM6swWmx
162 lines
8.7 KiB
Markdown
162 lines
8.7 KiB
Markdown
---
|
||
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,,,"<TAU>","<Active>"`. 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.
|