auto-sync 2026-09-10 18:00
This commit is contained in:
parent
b877f0458c
commit
564c3e450d
@ -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,,,"<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.
|
||||||
@ -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.
|
||||||
Loading…
Reference in New Issue
Block a user