From 564c3e450dd56e4df87d872dc0274bc0055faa67 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Leopoldo=20Rodr=C3=ADguez?= Date: Thu, 10 Sep 2026 18:00:14 -0600 Subject: [PATCH] auto-sync 2026-09-10 18:00 --- ..._Backup-Power_Evaluation-Procedure_v1.0.md | 158 ++++++++++++++++++ ..._Drogheda_Consulta-Vectro_PSM-eDRX_v1.0.md | 72 ++++++++ 2 files changed, 230 insertions(+) create mode 100644 03-Architecture-Hardware/2026-09-10_Drogheda_Backup-Power_Evaluation-Procedure_v1.0.md create mode 100644 03-Architecture-Hardware/2026-09-10_Drogheda_Consulta-Vectro_PSM-eDRX_v1.0.md diff --git a/03-Architecture-Hardware/2026-09-10_Drogheda_Backup-Power_Evaluation-Procedure_v1.0.md b/03-Architecture-Hardware/2026-09-10_Drogheda_Backup-Power_Evaluation-Procedure_v1.0.md new file mode 100644 index 0000000..9acbfc4 --- /dev/null +++ b/03-Architecture-Hardware/2026-09-10_Drogheda_Backup-Power_Evaluation-Procedure_v1.0.md @@ -0,0 +1,158 @@ +--- +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 + +> **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. diff --git a/03-Architecture-Hardware/2026-09-10_Drogheda_Consulta-Vectro_PSM-eDRX_v1.0.md b/03-Architecture-Hardware/2026-09-10_Drogheda_Consulta-Vectro_PSM-eDRX_v1.0.md new file mode 100644 index 0000000..16ff0d5 --- /dev/null +++ b/03-Architecture-Hardware/2026-09-10_Drogheda_Consulta-Vectro_PSM-eDRX_v1.0.md @@ -0,0 +1,72 @@ +--- +tags: [project-drogheda, comms, vendor, telecom] +project: Project Drogheda +author: Helgen CTO +date: 2026-09-10 +status: Draft para envío — cubre la tarea D2 del procedimiento de evaluación +--- + +# Correo a Vectro — PSM / eDRX en las líneas Telcel + +> Cubre **D2** de `2026-09-10_Drogheda_Backup-Power_Evaluation-Procedure_v1.0.md`. +> Las preguntas 1–4 están redactadas para reenviarse **tal cual** a Telcel; las 5–7 sólo +> las puede responder Vectro. + +--- + +**Asunto:** Consulta técnica — modos de ahorro de energía PSM / eDRX en las líneas Telcel + +Estimado [Nombre]: + +Requerimos confirmar si las líneas Telcel que nos suministran soportan **PSM (Power Saving +Mode)** y **eDRX (extended DRX)**, definidos en **3GPP Release 13**. La respuesta determina +el diseño de nuestro modo de respaldo por batería, por lo que agradeceremos su apoyo para +escalar la consulta con Telcel si no está a su alcance responderla directamente. + +**Contexto:** operamos equipos de telemetría GPS/RTK en terminales portuarias. Ante un corte +de energía, el equipo debe seguir reportando posición y estado durante varios días con +batería. PSM permite que el módem duerma a ~10 µA **manteniendo el registro en la red**, en +lugar de volver a registrarse en cada envío. En nuestros cálculos la diferencia en autonomía +es de **días contra semanas**, con el mismo hardware. + +## Preguntas técnicas (pueden reenviarse tal cual a Telcel) + +1. ¿Está habilitado **PSM** en el APN y el perfil de SIM que tenemos contratado, para + dispositivos **LTE Cat-1bis**? +2. En caso afirmativo, ¿qué valores otorga la red para el **T3412 extendido (TAU)** y el + **T3324 (Active Timer)**? Nuestra solicitud sería **TAU de 30 a 60 minutos** y + **Active Timer de 0 a 60 segundos**. +3. ¿Está habilitado **eDRX**? ¿Cuál es el **ciclo máximo** que otorga la red? +4. Si PSM o eDRX no están disponibles en nuestro APN actual, ¿existe un **APN de IoT/M2M** + donde sí lo estén, y cuál sería el procedimiento y el costo de migrar nuestras líneas? + +## Preguntas comerciales y operativas (para Vectro) + +5. ¿Existe alguna política de **suspensión o baja por inactividad**? Un equipo en PSM puede + permanecer **varios días sin generar tráfico**, y necesitamos confirmar que la línea no se + suspenda ni se dé de baja por ese motivo. +6. ¿El plan factura por **sesión / attach**, o únicamente por **volumen de datos**? +7. ¿Podemos habilitar **una línea de prueba** con PSM activo, para validarlo en banco antes + de aplicarlo a la flota? + +Agradeceremos su respuesta **a más tardar el viernes 19 de septiembre**, ya que esta +definición bloquea la siguiente etapa de nuestro desarrollo. + +Quedo atento a sus comentarios. + +Saludos cordiales, + +**Leo Rodríguez** +Helgen Technologies + +--- + +## Notas para Leo (no enviar) + +- Ajustar **[Nombre]** y la fecha del compromiso. +- La **pregunta 5 es la más importante para Vectro** y la que un revendedor suele pasar por + alto: una política de inactividad que suspenda la SIM anularía todo el beneficio de PSM. +- Si Vectro responde "no sé", el objetivo mínimo del correo es la **pregunta 7** — con una + sola línea de prueba podemos medir en banco lo que la red realmente otorga + (`AT+CPSMS?` y `AT+CEDRXRDP` devuelven los valores concedidos, que casi nunca son los + solicitados) y dejar de depender de la respuesta comercial.