hbox-docs/docs/diagnostico/protocolo-diagnostico-remoto.md
Leopoldo Rodríguez 01dc30c06a hbox-docs: sitio MkDocs Material para tecnicos (ES)
- contenido curado desde Drogheda via scripts/sync-docs.sh (procedimientos
  de banco, montaje/arneses, diagnostico remoto, guias git)
- scripts/deploy.sh: mkdocs build --strict + rsync al servidor Helgen
- README con setup de nginx + htpasswd para acceso privado de tecnicos

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YJ4eAB6zjQT49RVwpgfKdt
2026-09-15 18:23:26 +00:00

181 lines
8.9 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Remote Diagnostic Protocol — Pulled HBOX Units
**Date:** 2026-06-19 · **Owner:** Leo Rodriguez
**Situation:** all HBOX units were **removed from the machines**. We have **4 units
in hand: 3 not working, 1 working-ish.** They are **physically in Veracruz**; the
team is in **Querétaro** → debugging is **remote** until they're shipped or someone
on-site acts as our hands.
**Firmware on these units = v1** (no MCU thermal log) → thermal evidence must come
from **physical inspection + a bench power test**, not from the firmware.
> The single working-ish unit is the **control**. Every measurement below should be
> taken on it too, so "bad" readings on the dead units have a baseline to compare
> against.
---
## 0. Decision gate (make this call first)
**Recommendation: ship all 4 units to Querétaro.** They are small, and remote-
debugging *dead* electronics is slow and rarely conclusive — a 1–2 day courier buys
full bench access (PSU with current limit, scope, u-center, reflash, thermal soak,
teardown). Bring the working-ish unit too; it's the reference.
Choose remote-hands **only if** shipping is blocked (client chain-of-custody, the
units must stay on-site, or courier delay is unacceptable). Confirm with ICAVE who
**owns** the units and whether they may leave the terminal.
| Path | When | Cost |
|---|---|---|
| **Ship to QRO** *(recommended)* | units may leave Veracruz | courier + 1–2 days |
| **Remote-hands in Veracruz** | units must stay; cooperative on-site tech exists | needs the protocol below + their time |
Either way, **start §2 (backend analysis) now from Querétaro** — it needs no units.
---
## 1. What we can / cannot learn remotely
| Question | Remote-hands? | How |
|---|---|---|
| Is the LiPo swollen / burnt / leaking? | ✅ | photo checklist (§3 Tier 0) |
| Connectors/SMA loose, solder cracked? | ✅ | photos + wiggle test |
| Does it draw current / boot on power? | ✅ | bench PSU **current reading** (§3) |
| LED state on power-up? | ✅ | film the LED, decode (§4) |
| Battery V, fix quality, state, packets | ✅ (Tier 1) | USB dashboard capture |
| Does the 4G modem attach / get a fix? | ✅ (Tier 1–2) | dashboard / u-center / remote desktop |
| Does it reach our gateway when powered? | ✅ | watch htracker for that unit's `cell_id` |
| Exact failed component / thermal soak | ❌ (needs bench) | **ship to QRO** |
So ~80% of triage is remotely achievable; only component-level confirmation and
thermal reproduction strictly require the units in QRO.
---
## 2. Do this NOW from Querétaro (no units needed)
The backend is on our own server — fully debuggable from QRO, and per
`02-Architecture-Software/backend-review.md` it can take healthy units off Wialon by itself.
1. **Historical online-vs-offline split.** For the days before removal, compare each
unit's **htracker** record (online on UDP receipt) against **Wialon** (online on
positions received). A unit that was **online in htracker but offline in Wialon**
was a **backend victim** (anti-jump lock-out / HOL stall), *not* dead hardware —
that reframes which "dead" units are actually hardware failures.
2. **Gateway logs around the death window:** look for the anti-jump warning
(`¡Filtro Anti-Salto Activado!`) spamming one `cell_id` (→ lock-out), and for
`netstat -su` UDP receive-buffer drops (→ HOL stall).
3. **Bench-reproduce with the working-ish unit** once it's powered (in VER via
remote-hands, or in QRO): point it at the gateway and watch whether the
retranslator forwards it cleanly or trips the filter.
4. Caster (HelgenSRV) uptime + **per-SIM data balance/suspension** for the window.
This is the highest-leverage work we can do today and it needs nobody in Veracruz.
---
## 3. Remote-hands protocol (tiered by what the on-site person has)
Give the on-site tech the matching tier. A ready-to-send Spanish version is in §6.
### Tier 0 — power + a phone camera (minimum)
For **each** unit, before powering:
1. **Photograph**: the whole inside, then close-ups of the **LiPo** (any swelling,
bulging, brown/black marks, leaks?), the **PowerBoost**, every **connector/Dupont**,
the **SMA antenna** joints, and any **discoloured/burnt** components.
2. **Wiggle test** (gently): do any Dupont/terminal/SMA connectors move or fall off?
3. **Bench power-on with a current-limited PSU** at the unit's normal voltage
(12 V or 24 V), current limit ~2 A:
- Read **inrush** then **steady current**. Record the number.
- **0 mA / trips at 0:** open circuit / dead input stage / blown fuse.
- **Hits the current limit / very hot:** short → **power off immediately**.
- **~50–150 mA steady, nothing else:** MCU only, stack not powering (load switch
/ boost / modem).
- **Normal-ish draw + LED activity:** boots — go to Tier 1.
- Compare every reading to the **working-ish unit**.
4. **Film the LED** for ~60 s from power-up (decode in §4).
### Tier 1 — Tier 0 + USB cable + a laptop
5. Plug the Blackpill **USB** into the laptop; open **PuTTY/TeraTerm at 115200**.
The v1 watchdog prints a live dashboard. **Capture 3–5 min** (log to file) and
send it. Read off: **BATTERY V**, **SYSTEM STATE**, **RTK FIX**, **PACKETS TX'd**,
PWR/IGN inputs. (No MCU-temp line — these are v1.)
6. Note whether **PACKETS TX'd increments** (GNSS+serial alive) and whether **RTK
FIX** ever reaches 4/5 (corrections arriving = 4G/NTRIP working).
### Tier 2 — Tier 1 + remote-desktop (AnyDesk/TeamViewer) into the laptop
7. We drive from QRO: read the live dashboard, run **u-center** on the ZED-F9P
(fix, sat levels, config), issue **AT commands** to the 4G modem (attach, signal),
and if useful **reflash v2** to gain thermal logging + better recovery.
---
## 4. LED quick-decode (v1)
| LED | State | Read as |
|---|---|---|
| Fast blink | BOOTING | powered, waiting for 4G/GNSS |
| Solid ON | RUNNING, vehicle power, RTK fixed | healthy |
| Heartbeat (1 s) | RUNNING on battery | on LiPo, 30 s rate |
| Slow blink | searching / no corrections | 4G/NTRIP not delivering |
| Off (with power applied) | SLEEP / dead | battery-critical logic **or** not booting |
"Off while powered from a good bench supply" on a unit that should boot = a strong
**no-boot / power-stage** signal — correlate with the current reading.
---
## 5. Per-unit triage decision tree
```
Power on bench PSU (current-limited)
├─ 0 mA ............................. dead input / blown fuse / open → ship to QRO
├─ hits limit / hot ................ SHORT (power off!) ............... → ship to QRO
└─ draws current
├─ no LED, no USB dashboard ...... MCU/boot dead .................... → ship to QRO
└─ boots (LED + dashboard)
├─ PACKETS not incrementing ... GNSS/serial dead ................ Tier 2 / ship
├─ FIX stuck 0/1 (never 4/5) .. 4G/NTRIP not delivering ......... check modem/SIM/antenna
└─ FIX 4/5 + packets OK ........ HARDWARE IS FINE ............... → backend victim (§2)
```
The last branch is the important one: a pulled unit that **boots, fixes, and
transmits on the bench is not the failure** — its disappearance from Wialon is then
backend (§2), and re-installing it unchanged would just repeat the problem.
---
## 6. Safety — heat-damaged LiPo (tell the on-site tech)
A swollen/puffy or hot LiPo is a **fire risk**. Do **not** charge it, puncture it, or
keep powering a unit whose battery is visibly swollen. Disconnect it, place it in a
**LiPo-safe / fireproof bag or a metal container**, keep it away from anything
flammable, and ventilate. Photograph first, then isolate. If it's hot, vented, or
smells: stop and isolate immediately.
---
## 6b. Spanish — instrucciones para el técnico en sitio (Tier 0/1)
> Para **cada** unidad: (1) **Fotos** del interior y de cerca de la **batería LiPo**
> (¿inflada, manchas cafés/negras, fuga?), del **PowerBoost**, de **cada conector
> Dupont**, de las **antenas SMA**, y de cualquier componente **quemado/decolorado**.
> (2) Prueba de **movimiento** suave: ¿algún conector se mueve o se cae? (3) Enciéndela
> con una **fuente de banco** a su voltaje normal (12 V/24 V), límite de corriente ~2 A,
> y anota la **corriente** (arranque y estable). Si llega al límite o se calienta,
> **apágala de inmediato** (corto). (4) **Graba el LED** ~60 s desde el encendido.
> (5) Si hay laptop: conecta el **USB** del Blackpill, abre **PuTTY/TeraTerm a 115200**
> y **graba 3–5 min** del tablero (BATERÍA V, ESTADO, RTK FIX, PAQUETES). **Seguridad:**
> una batería **inflada o caliente** es riesgo de incendio — no la cargues ni la
> perfores; aíslala en bolsa/recipiente seguro y ventila.
---
## 7. What to send back to Querétaro (capture checklist)
Per unit, labeled with its `cell_id`/machine: the **photos**, the **current reading**
(inrush + steady), the **LED video**, the **3–5 min USB dashboard capture**, and a
one-line note (boots? fix? packets?). With that, we can classify all 4 units against
the tree in §5 and the backend evidence in §2 — and decide which truly need teardown
in QRO.