# Descargas

Archivos que el técnico necesita en el banco. Verificar el SHA-256 antes de flashear
(`shasum -a 256 archivo` en macOS, `sha256sum archivo` en Linux, `certutil -hashfile archivo SHA256` en Windows).

## Qué archivo va a qué cosa

Una unidad HBOX tiene **tres cerebros distintos** y cada uno se carga por su propio camino. Antes de
descargar nada, ubica cuál vas a tocar:

| Qué | Qué se le carga | Cómo | Dónde está |
|---|---|---|---|
| **Tarjeta HBOX** (Blackpill / EinarBoard) | Firmware `.bin` | DFU por USB | [§ Firmware del HBOX](#firmware-del-hbox-que-binario-va-en-que-tarjeta) |
| **Módem 4G NTRIP Master** | Archivo de **parámetros** `$$$AS+…` | Terminal serie por el USB *XBEE* | [§ Módem 4G](#parametros-del-modem-4g-ntrip-master) |
| **simpleRTK2B Pro (ZED-F9P)** | Configuración u-center **y** firmware u-blox | u-center por el USB *POWER+GPS* | [§ ZED-F9P](#firmware-y-configuracion-del-simplertk2b-pro-zed-f9p) |

Cada carga se registra en el **[acta de reflasheo](../formularios/reflasheo.html)**, y queda en el
[expediente de esa unidad](../unidad.html) junto con las capturas de antes y después.

!!! warning "Verifica el SHA-256 antes de flashear"
    Un binario incompleto o de otra generación puede dejar la tarjeta inservible.
    `shasum -a 256 archivo` (macOS) · `sha256sum archivo` (Linux) · `certutil -hashfile archivo SHA256` (Windows).

## Firmware del HBOX — qué binario va en qué tarjeta

**Regla: un binario por tarjeta.** La versión del firmware no dice nada de la tarjeta (`0.4.0` no es
"para V4": es una versión vieja del firmware de V5). El binario lleva la tarjeta en el nombre y eso es lo que manda.

| Tarjeta | MCU | Código fuente | **Binario vigente** | Estado |
|---|---|---|---|---|
| **V3** — EinarBoard 1.0, las 3 unidades en campo | Blackpill en zócalo (F411CE) | `blackpillrtkcode_v4` (4.0.0) | [`hbox-tarjetaV3_4.0.0.bin`](hbox-tarjetaV3_4.0.0.bin) | ⚠ compilado, **sin prueba de banco** |
| **V4** — `hbox-watchdog-v4` | Blackpill en zócalo + PCF8574 · W5500 · SC16IS752 | `hbox_v5_bringup` + `board_v4.h` | [`hbox-tarjetaV4_0.6.0.bin`](hbox-tarjetaV4_0.6.0.bin) | ⚠ compilado 27-sep, **sin prueba de banco**. **0.6.0 CAMPO: 0.5.9 + gobernador de carga (la batería por fin se recarga en la unidad)**; puente U13-P7 → SW4G1 opcional — [preparación y prueba V4](../procedimientos/v4-prueba-fw-0.5.6.md) |
| **V5** — `hbox-watchdog-v5`, lote de 15 | STM32F411RET6 soldado | `hbox_v5_bringup` (0.6.0) | [`hbox-v5-bringup_0.6.0.bin`](hbox-v5-bringup_0.6.0.bin) | ⚠ **vigente desde 27-sep (0.6.0 CAMPO)** — **cargador con gobernador** (hasta 0.5.9 estaba apagado: paquete de un solo uso); en batería la etapa y el módem **siguen encendidos y reportando igual que en 24 V** (sin ciclo de 10 min ni ahorro: la V5.5 no arranca el módem en frío sobre el boost); **ningún ciclo de etapa en batería**; corte a 3.40 V; **reset del MCU al volver el 5 V tras ≥ 10 s de respaldo, siempre**; vigilancia del módem solo diagnóstica (`modem=` en STAT); 0.5.1 fue la última en campo |

Los tres reportan al servidor **la misma trama**: `$PHLG` de 29 campos cada 30 s y un `$PHEV` por cada
cambio de estado, en banda por el módem (Modo B). Es exactamente lo que el monitor desplegado parsea hoy
(`retranslator.py`: 20 campos base + 4 de v3 + 5 de 0.5.1, y `$PHEV`), así que las tres tarjetas se ven
igual en la columna *Salud*.

!!! warning "0.5.x (V4 y V5) cambia cómo se ve la unidad en el monitor cuando está en batería"
    Desde 0.5.2 la unidad **apaga el módem entre reportes** mientras está en batería: enciende ~120–180 s cada
    10 min, manda posición y `$PHLG` con `pwr=BATT`, avisa `DUTY_SLEEP next=<s>` y se calla. Para que ese
    silencio **no aparezca como desconexión** (ni dispare el correo del notifier, ni cuente como caída), el
    `retranslator.py` del servidor debe llevar el soporte `DUTY` (24-sep). **Desplegar primero el servidor,
    después flashear.** Con la V3 (4.0.0) no cambia nada: sigue reportando continuo en batería.

    **0.5.9 CAMPO** no apaga el módem ni calla en batería: reporta continuo con `pwr=BATT`, igual que 0.5.1 (el monitor muestra ⚡
    sin badge de silencio). El soporte `DUTY` sigue haciendo falta para las versiones de banco con ciclo o ahorro.

!!! success "0.6.0 — el cargador por fin: gobernador de carga (port de flota v3.0.1)"
    Hasta 0.5.9 el cargador estaba **apagado por firmware** («paquete de un solo uso»): tras la primera noche en batería el paquete
    quedaba gastado y la unidad ya no tenía respaldo (H0008 amaneció a 3.50 V y en 24 V seguía «sin cargar»). No se puede encender sin
    más: en V5.5/V4 `RS1` 8 mΩ → límite de entrada del LTC4040 ≈ 3.1 A, por encima de los 3 A del SD-15B, y `R50` 825 Ω → 2.4 A de
    carga; paquete vacío + etapa + ráfaga LTE hunden el riel al PFI 4.60 V y la unidad entra en bucle (incidente de flota 10-ago).
    **El gobernador** carga solo con etapa ON en 24 V, nunca en los primeros 120 s tras boot o STACK ON, arranca tras 30 s de riel
    ≥ 5.05 V, **corta al instante bajo 4.90 V** con enfriamiento 60 s → 30 min, inhibe con celda ≥ 45 °C y rearma el safety timer del
    LTC4040. En fuente débil la carga es por ciclos: más lenta, pero el módem nunca paga por ella. Eventos `CHG_ON/CHG_SHED/CHG_OFF/
    CHG_HOT/CHG_COOL/CHG_PULSE`, `STAT` → `carga=FASE … ltc=CARGANDO|no cortes=`, tecla `C` = veto. El monitor muestra **🔌 CARGANDO**
    (columna *Energía* y detalle) solo cuando el LTC4040 carga de verdad (`chg=1` en `$PHLG`). `PHLG_FW` = `0.6.0` (sin «-fm»).

    **Prueba de banco** (unidad con paquete bajo, consola abierta, 24 V): a los ~120 s `carga=PROVING n/30s` → `EVT CARGA ON` →
    `ltc=CARGANDO` y 🔌 en el monitor. Multímetro en P2 durante una ráfaga LTE: si baja de 4.90 V debe verse `CARGA cortada …
    enfriamiento 60 s` y reintento. Anotar `cortes=` por hora y si `vbat` sube. Si corta sin parar (enfriamiento en 30 min), la fuente
    no puede con 2.4 A + etapa: V5.6 (`RS1` 10 mΩ, `R50` 1.5 kΩ) o fuente de 4 A.

!!! danger "0.5.9 — la noche con 0.5.8: el recovery en batería mató al módem; sin ciclos de etapa en batería y reset al volver el 5 V siempre"
    Noche 26/27-sep con 0.5.8 (V5.5 toda la noche en batería): amaneció con `vbat` 3.50 V, F9P vivo, **módem oscuro**, los 4 LEDs de
    carga apagados (correcto: DB1 enciende a 3.60 V). Al volver los 24 V el módem siguió oscuro; solo un reset (SW1/P10) o `SW4G1` lo levantó.
    Causa más probable: el recovery de enlace seguía armado en batería — el silencio del ahorro dejó al caster sin GGA → sin correcciones →
    «RTK perdido 15 min» → `RECOVERY rtk_lost` → etapa OFF/ON **en batería** → el módem no arranca (brown-out del boost, abajo) → oscuro
    hasta los 24 V; y 0.5.8 no reseteaba al volver el 5 V si la etapa venía encendida desde 24 V (regla falsa: el estado del módem no se
    puede saber en V4/V5). **0.5.9:** ningún ciclo de etapa en batería (un ciclo en curso al perder el 5 V se aborta con la etapa apagada,
    `RECOVERY_ABORT`); reset del MCU al volver el 5 V tras cualquier respaldo ≥ 10 s (`NRST` solo llega al MCU: es el botón P10);
    **ahorro fuera del build de campo** hasta medirlo en banco (continuo como 0.5.1, ~10–13 h); y **vigilancia del módem solo
    diagnóstica**: `STAT` añade `rtcm_age= sta= rtcm_last= sag5= sagb= flat= modem=vivo|SOSPECHOSO|?` (correcciones RTCM vistas por el
    F9P + caída del riel por ráfagas LTE), eventos `MODEM_DARK` / `MODEM_BACK` / `MODEM_WATCH`. Con esos números se calibra 0.5.10.

!!! danger "0.5.8 — diagnóstico cerrado: la V5.5/V4 NO arranca el módem en frío sobre la batería; por eso el build de campo no lo apaga"
    Banco 26-sep (0.5.7): en batería **ningún** encendido de etapa arranca el módem (ni `P`, ni el despertar, ni un reset del MCU con
    `R` o P10); **con 24 V cualquiera lo arranca**; y en batería **`SW4G1`** pulsado con la etapa ya encendida sí lo arranca. Causa: al
    encender la etapa, simpleRTK2B y módem arrancan a la vez sobre el boost del LTC4040 (4.6 V en `SW_IN` solo con el F9P); la ráfaga
    de arranque del módem (~2 A) hunde el riel, el buck de `3V3_MODEM` (MP1584, mínimo 4.5 V) cae y el PMIC del módem aborta y **no
    reintenta** (todos los LEDs apagados). `SW4G1` lo reinicia solo, sobre un riel ya estable. No tiene arreglo por firmware en V4/V5;
    se corrige en **V5.6** (buck del módem alimentado antes de Q1, reset y enable del módem en el MCU).

    **Por eso 0.5.8 CAMPO nunca apaga el módem en batería:** un módem que ya está encendido sí aguanta el paso de 24 V a batería.
    La etapa sigue encendida hasta el corte de 3.40 V y el MCU (Modo B) recorta el tráfico: ráfaga de posición de ~8 s cada 10 min y
    `$PHLG` cada 3 min (`SAVER_ON`, `DUTY_SLEEP`/`DUTY_WAKE`; `STAT` → `ahorro=`). Autonomía estimada ~30–35 h. Al volver el 5 V solo
    hay reset del MCU si la etapa estaba apagada o arrancó en batería (el módem puede estar oscuro); si venía encendida desde 24 V, no se
    toca. Reset por SW1/P10 en batería: la etapa **no** se reenciende hasta que vuelva el 5 V. Sigue disponible el puente (0.5.6+, ahora
    el pulso va 5 s después de STACK ON):

    ```
    U13 pin 12 (P7)  ──|<──  SW4G1 pad 1 (MODEM_RST)     diodo Schottky de señal BAT54 (o BAT85/BAT43/1N5711) — no 1N5819
                    cátodo   ánodo
    ```

    Verificar con la tecla **`M`** en consola (etapa ON): `SW4G1` pad 1 cae a < 0.4 V durante 0.5 s y los LEDs del módem
    apagan y vuelven. Sin el puente el pulso `MODEM_RST` no llega a nada. Anotar el puente en el acta de la unidad. Detalle en el [procedimiento de batería](../procedimientos/prueba-bateria-modem.md).

!!! note "V4 = la V5 en un Blackpill"
    Cotejada pad por pad en `hbox-watchdog-v4.kicad_pcb` contra `board_v5.h`: mismas redes, mismos pines
    del MCU, mismas direcciones I2C (PCF8574 `0x20`, SHT40 `0x44`, TMP102 `0x48`, SC16IS752 `0x4D`), mismo
    W5500 en SPI2 y misma K1 en `PB5`. **Una sola diferencia:** `ETH_INT` es `PB2` (J1.16) en vez de `PC0`.
    Por eso la V4 no necesita firmware propio: es `hbox_v5_bringup` compilado para Blackpill con
    `board_v4.h`. La V4 **se flashea por DFU solo con USB** (sin 24 V y con la batería desconectada). Ojo: en la V4
    ese USB también alimenta el riel de 5 V de la tarjeta y, con él, al W5500, cuya `INTn` llega a `PB2` = `BOOT1`.
    Si no aparece *STM32 BOOTLOADER*, se flashea la Blackpill fuera del zócalo
    ([procedimiento V4](../procedimientos/v4-prueba-fw-0.5.6.md)).

!!! danger "Lo que NO se puede cruzar"
    - `hbox-v5-bringup_0.5.x.bin` (compilado para el F411RE soldado) en una **V3 o V4**: otro MCU y otro
      mapa de pines. La V4 usa **su propio binario** `hbox-tarjetaV4_…`, compilado para Blackpill.
    - `hbox-tarjetaV3_…` en una **V4**: maneja los LEDs de carga en PB12–PB15, que en la V4 son el SPI del W5500.
    - Cualquier binario de la carpeta `superseded/`: se conservan solo por trazabilidad.

### Versiones superadas

No se flashean. Están para identificar lo que una tarjeta vieja pueda traer y para volver atrás si una prueba de banco lo pide.

| Archivo | Por qué se retiró |
|---|---|
| [`superseded/hbox-tarjetaV3_3.0.4.bin`](superseded/hbox-tarjetaV3_3.0.4.bin) | Misma lógica que las unidades en campo (3.0.3) pero **sin telemetría en banda**: el monitor no ve nada en *Salud*. Sustituida por 4.0.0. |
| [`superseded/hbox-v5-bringup_0.5.9.bin`](superseded/hbox-v5-bringup_0.5.9.bin) · [`superseded/hbox-tarjetaV4_0.5.9.bin`](superseded/hbox-tarjetaV4_0.5.9.bin) | Correcta pero **sin cargador** (paquete de un solo uso). Sustituida por 0.6.0, que añade el gobernador de carga y no cambia nada más. |
| [`superseded/hbox-v5-bringup_0.5.8.bin`](superseded/hbox-v5-bringup_0.5.8.bin) · [`superseded/hbox-tarjetaV4_0.5.8.bin`](superseded/hbox-tarjetaV4_0.5.8.bin) | **No usar.** El recovery de enlace seguía activo en batería: el silencio del ahorro provocaba «RTK perdido» y un ciclo de etapa en batería que dejaba el módem oscuro hasta un reset manual (noche 26/27-sep). Sustituida por 0.5.9. |
| [`superseded/hbox-v5-bringup_0.5.7.bin`](superseded/hbox-v5-bringup_0.5.7.bin) · [`superseded/hbox-tarjetaV4_0.5.7.bin`](superseded/hbox-tarjetaV4_0.5.7.bin) | Despertar de batería por reset del MCU: en banco **no** enciende el módem en batería (brown-out del boost al encender la etapa); solo servía al volver el 5 V. Sustituida por 0.5.8 CAMPO (respaldo continuo con ahorro; conserva el reset al volver el 5 V cuando hace falta). |
| [`superseded/hbox-v5-bringup_0.5.6.bin`](superseded/hbox-v5-bringup_0.5.6.bin) · [`superseded/hbox-tarjetaV4_0.5.6.bin`](superseded/hbox-tarjetaV4_0.5.6.bin) | Pulso `MODEM_RST` por U13-P7 (solo con puente); sin puente el módem seguía sin encender en las ventanas, y un reset en batería dejaba la etapa apagada. Sustituida por 0.5.7 (despertar por reset del MCU; conserva el pulso). |
| [`superseded/hbox-v5-bringup_0.5.5.bin`](superseded/hbox-v5-bringup_0.5.5.bin) · [`superseded/hbox-tarjetaV4_0.5.5.bin`](superseded/hbox-tarjetaV4_0.5.5.bin) | **No usar.** Poner el UART del GNSS en alta impedancia no bastó: en reposo `3V3_MODEM` sigue en ~1 V y el módem no rearranca. Sustituida por 0.5.6, que resetea el módem desde el MCU (puente U13-P7 → SW4G1). |
| [`superseded/hbox-v5-bringup_0.5.4.bin`](superseded/hbox-v5-bringup_0.5.4.bin) · [`superseded/hbox-tarjetaV4_0.5.4.bin`](superseded/hbox-tarjetaV4_0.5.4.bin) | **No usar.** Su ciclo de etapa al volver el 5 V no apagaba de verdad al módem: el UART del GNSS seguía sosteniendo su riel, así que el módem no rearrancaba ni en batería ni al volver el vehículo (solo con reset). Sustituida por 0.5.5. |
| [`superseded/hbox-v5-bringup_0.5.3.bin`](superseded/hbox-v5-bringup_0.5.3.bin) · [`superseded/hbox-tarjetaV4_0.5.3.bin`](superseded/hbox-tarjetaV4_0.5.3.bin) | Ventana de 2 min, pero al volver el 5 V tras batería el módem podía quedarse en *latch* (oscuro hasta un reset). Sustituida por 0.5.4, que cicla la etapa al volver el 5 V. |
| [`superseded/hbox-v5-bringup_0.5.2.bin`](superseded/hbox-v5-bringup_0.5.2.bin) · [`superseded/hbox-tarjetaV4_0.5.2.bin`](superseded/hbox-tarjetaV4_0.5.2.bin) | Primera versión con reporte cada 10 min en batería, ventana mínima de 90 s: **insuficiente para que el módem entregara la posición**. Sustituida por 0.5.3 (120 s). |
| [`superseded/hbox-v5-bringup_0.5.1.bin`](superseded/hbox-v5-bringup_0.5.1.bin) · [`superseded/hbox-tarjetaV4_0.5.1.bin`](superseded/hbox-tarjetaV4_0.5.1.bin) | Última versión de campo antes del reporte cada 10 min en batería (en batería dejaba la etapa encendida hasta vaciar el paquete). Sirve para volver atrás si 0.5.3 da problemas en banco. |
| [`superseded/hbox-v5-bringup_0.4.0.bin`](superseded/hbox-v5-bringup_0.4.0.bin) | Versión de V5 sin `$PHLG` en banda. Sustituida por 0.5.1. |

### Firmware de bring-up — EinarBoard v5

| Archivo | Versión | SHA-256 | Uso |
|---|---|---|---|
| [**hbox-v5-bringup_0.6.0.bin**](hbox-v5-bringup_0.6.0.bin) | **0.6.0 CAMPO** (2026-09-27) — **0.5.9 + gobernador de carga (riel ≥ 5.05 V / corte < 4.90 V / celda < 45 °C); Modo B; respaldo continuo en batería; sin ciclos de etapa en batería; reset del MCU al volver el 5 V; vigilancia del módem; teclas `C`/`M`/`R`** — ⚠ sin prueba de banco | `8a0ee4839763eae8…` | Sección 5 del [procedimiento de prueba y flasheo v5](../procedimientos/v5-prueba-y-flasheo.md) y sección 5 del [ensamble](../procedimientos/v5-ensamble.md) (modo de banco `P` / `n`) |

Flasheo por DFU en **J11** (mantener **SW2**, pulsar y soltar **SW1**, soltar SW2):

```bash
dfu-util -a 0 -s 0x08000000:leave -D hbox-v5-bringup_0.6.0.bin
```

o con **STM32CubeProgrammer** → USB → Connect → Download del `.bin` en `0x08000000`.

!!! success "A/B 0.4.0 vs 0.5.1 — cerrado el 19-sep"
    El 18-sep por la tarde se reportó que con 0.5.1 la etapa RTK no encendía. **Resuelto:** 0.5.1 ensambla,
    enciende y reporta telemetría completa en el monitor desplegado. **Se embarcó con 0.5.1; desde el 27-sep la vigente es 0.6.0.** `0.4.0`
    queda en `superseded/` solo como referencia.

!!! note "Tarjetas ya flasheadas con cualquier versión anterior"
    Re-flashear con **0.6.0** por el mismo procedimiento DFU. **La primera línea de la consola tras reset dice la versión**
    (`hbox-v5-bringup 0.6.0 built …`): si la línea `STAT` no termina en `stack=…`, la tarjeta sigue con 0.1.1.

!!! tip "Consola 0.5.x"
    Líneas `EVT` en cada cambio (stack, ignición, 5 V, cargador, NMEA, fix), `STAT` con nombres cada 5 s y `$PHLG` cada 10 s
    (misma trama de salud que lee el servidor). Teclear `l` para la leyenda y `v` para los puntos de medición de la etapa RTK.
    Para encender la etapa RTK: `P` y luego `Y` (requiere 5 V en P2).

!!! warning "0.5.x = firmware de campo mínimo + telemetría y eventos en banda — AUTO de fábrica"
    Desde 0.4.0 el modo AUTO es el **de fábrica**: la etapa RTK se enciende sola 3 s después de ver 5 V en P2 — no hace falta consola
    ni teclear `A`. Incluye watchdog 16 s, ventilador (política v3.0.3), recuperación de enlace (ciclo de etapa si el F9P deja de
    hablar 60 s; LIMP tras 3 ciclos), LEDs de carga y color de estado, corte térmico 60 °C y corte de batería 3.40 V.
    **Cargador: apagado hasta 0.5.9 (paquete de un solo uso); desde 0.6.0 carga con gobernador** (ver la caja verde). Anotar la versión en el acta.

    **0.6.0 CAMPO:** gobernador de carga: carga solo con etapa ON en 24 V tras 120 s, riel ≥ 5.05 V por 30 s, corte < 4.90 V con enfriamiento
    60 s → 30 min, celda < 45 °C, pulso de rearranque del LTC4040. `STAT` → `carga=`; tecla `C`. Lo demás igual que 0.5.9.

    **0.5.9 CAMPO:** sin ciclo de 10 min ni ahorro en batería (`ENABLE_DUTY 0`, `ENABLE_BATT_SAVER 0`): la etapa y el módem siguen
    encendidos y reportando hasta el corte de 3.40 V; **ningún ciclo de etapa en batería** (`RECOVERY_ABORT` si uno estaba en curso);
    reset del MCU al volver el 5 V tras ≥ 10 s de respaldo. Un reset en batería deja la etapa apagada hasta que vuelva el 5 V.
    Vigilancia del módem solo diagnóstica (`modem=` en `STAT`, `MODEM_DARK`/`MODEM_BACK`/`MODEM_WATCH` en banda).

    **0.5.8 CAMPO (retirada):** igual pero con ahorro (ráfaga cada 10 min) y con el recovery aún activo en batería — ver la caja roja.

    **0.5.7:** cada despertar de batería (≥ 10 min tras la última ventana) y cada regreso del 5 V tras batería es un **reset del
    MCU** (`NVIC_SystemReset`, lo mismo que el botón P10): arranca en ~4 s; sin 5 V la ventana abre de inmediato, con 5 V AUTO
    enciende la etapa a los 3 s. Se pierden uptime y contadores. Tecla `R` = ese reset ahora. Un reset por SW1/P10 en batería
    abre ventana en 60 s (antes dejaba la etapa apagada hasta que volviera el 5 V) y `P` se acepta en batería con vbat ≥ 3.60 V.

    **0.5.6:** 3 s después de cada encendido de etapa el MCU pulsa el reset del módem 500 ms por `U13` P7 (evento `MODEM_RST`,
    contador `mrst=` en `STAT`, tecla `M` = pulso manual). Con la etapa apagada PA9/PA10 quedan en alta impedancia sin pull-up.

    **0.5.5:** con la etapa apagada el UART del GNSS queda en alta impedancia (antes PA2 sostenía el riel del simpleRTK2B y, a través de él, el del módem: el módem
    nunca veía un power-on reset y quedaba oscuro hasta un reset de la tarjeta). Al volver el 5 V tras batería la etapa se cicla 10 s (`PWR_RETURN_CYCLE`).

    **0.5.2–0.5.7 — batería (ciclo retirado en 0.5.8 para V5.5/V4; queda con `-DENABLE_DUTY=1`):** con 5 V perdidos la etapa ya no queda encendida hasta vaciar el paquete: ventana de reporte de 120–180 s
    cada 10 min (`DUTY_WAKE` / `DUTY_SLEEP next=<s>` / `DUTY_SKIP` / `DUTY_END`), ventilador y LEDs apagados en reposo, protecciones
    de batería (< 3.40 V) y temperatura (≥ 60 °C) por encima del ciclo. El MCU sigue despierto: el ahorro es la etapa (~2.3 W).

    **0.5.1 — diagnóstico:** `$PHLG` lleva además `up_s`, `pwr` (VEH/BATT), `v5min`/`vbat_min` (mínimos de la ventana de 30 s)
    y `bkp_n`; cada cambio de estado sale como `$PHEV,<up_s>,<CODIGO>,<detalle>` al servidor (misma línea de tiempo que los `EVT`).

    **0.5.0 — Modo B:** 10 s después de que el F9P empieza a hablar, el MCU conmuta K1 y la trama `$PHLG` viaja al servidor
    cada 30 s junto con el NMEA (columna **Salud** del monitor). En consola: `STAT … modoB=ON relay=… phlg_aire=…` (debe subir de
    1 en 1 cada 30 s). Si el MCU falla, K1 regresa solo al paso directo F9P→módem. `B` lo bloquea/permite para pruebas. Si se pierde el 5 V, la etapa **sigue encendida desde la batería**
    y la consola registra `EVT BACKUP inicio` / `BACKUP fin` con duración y tramas NMEA: esa es la prueba de respaldo.
    Se apaga sola si vbat < 3.40 V o temperatura > 50 °C. `A` de nuevo regresa a MANUAL. El cargador (0.6.0) solo carga en AUTO/MANUAL con la etapa ON y 24 V, según el gobernador.

!!! warning "Solo para la tarjeta v5"
    Este firmware **no** es el de producción: solo prueba la tarjeta (reloj, USB, cristales, I²C,
    LEDs, ADC) sin encender la etapa RTK ni el cargador. **Nunca flashear `blackpillrtkcode_v3`
    (v3.0.3) en una v5.**

**Novedades de 0.5.x:** el `$PHLG` gana 5 campos nuevos (`up_s`, `pwr`, `v5min`, `vbat_min`, `bkp_n` — `vbat_min` caza los hundimientos de 50-200 ms de las ráfagas LTE que una foto cada 30 s nunca ve) y aparece `$PHEV`, una trama por cada cambio de estado. Los analizadores viejos ignoran los campos extra.

Notas de compilación y cambios: [README del firmware de bring-up](hbox-v5-bringup-README.md).

### Firmware de campo — tarjeta V3 (detalle)

!!! danger "Estos binarios todavía NO se flashean en una unidad de campo"
    Compilaron limpio el 19-sep y pasan el simulador, pero **ninguno ha corrido sobre una
    EinarBoard 1.0 real**. Hasta que ingeniería los pruebe en banco (RTK-003 o RTK-006) y quite
    este aviso, solo se usan en la mesa de ingeniería. Esto aplica sobre todo al **4.0.0**, que pone
    el MCU en línea con el enlace que lleva las correcciones RTK.

!!! tip "Prueba de banco del 4.0.0: en par"
    El 4.0.0 activa el Modo B por omisión. Aunque el A/B de V5 ya cerró bien, la primera prueba en
    una V3 real se hace **en par**: el binario publicado y uno compilado con `-DENABLE_MODOB=0`,
    sobre la misma unidad. Si el fix RTK cae al energizar K1, o `v5min` se hunde en ese instante,
    el sospechoso es la bobina de K1 llevando el riel al PFI del LTC4040.
    ```bash
    arduino-cli compile --fqbn "$FQBN" --build-property "compiler.cpp.extra_flags=-DENABLE_MODOB=0" \
      --output-dir build/v4-sinB blackpillrtkcode_v4
    ```

Es el firmware que gobierna la unidad en la máquina, distinto del de bring-up del v5. Se usa en el
[reflasheo en taller](../procedimientos/reflasheo-unidades.md).

| Tarjeta | Archivo | Estado |
|---|---|---|
| **V3** — flota desplegada | [`hbox-tarjetaV3_4.0.0.bin`](hbox-tarjetaV3_4.0.0.bin) · 64 352 B · `a68a87ff…` | ⚠ compilado 19-sep, falta prueba de banco. El «4» es la versión del firmware, **no** la tarjeta |
| **V4** | [`hbox-tarjetaV4_0.6.0.bin`](hbox-tarjetaV4_0.6.0.bin) · 88 556 B · `1458470bbdd95b49…` | ⚠ compilado 27-sep, falta prueba de banco. Es 0.6.0 CAMPO (con cargador) para Blackpill (`-DHBOX_BOARD_V4`), DFU **solo con USB**; puente U13-P7 → SW4G1 opcional (respaldo) — [procedimiento V4](../procedimientos/v4-prueba-fw-0.5.6.md) |

!!! danger "Mientras diga «pendiente», no hay binario aprobado"
    No flashees una unidad V3 o V4 con un archivo que no esté publicado aquí con su SHA-256. Los
    binarios de estas generaciones **no viven en el repositorio** (están en `.gitignore`): tienen que
    compilarse, probarse en banco y publicarse. El procedimiento de generación está en el
    [reflasheo §6](../procedimientos/reflasheo-unidades.md).

!!! warning "Un binario no sirve para otra generación"
    La polaridad del control de carga está **invertida** entre la tarjeta de producción y la de
    protoboard. Flashear el binario equivocado puede dejar la batería cargando justo cuando el
    firmware cree estarla protegiendo por temperatura — la falla #1 del RCA de junio.

## Parámetros del módem 4G NTRIP Master

La configuración se envía por el puerto USB **XBEE** del simpleRTK2B Pro a 115200 baudios, línea por
línea (solo las que empiezan con `$$$AS+`). Cada una debe contestar `OK`.

| Archivo | Qué es |
|---|---|
| [**4G_NTRIP_HelgenSRV-NMEA.example.txt**](4G_NTRIP_HelgenSRV-NMEA.example.txt) | **Plantilla** con todos los parámetros y sus nombres, con los valores sensibles en blanco |

!!! danger "El archivo con los valores reales no está aquí, y es a propósito"
    El archivo lleno contiene **usuario y contraseña del caster NTRIP y de la APN**. Publicarlo en el
    sitio sería ponerlo al alcance de cualquiera que tenga una cuenta de técnico, y meterlo al
    repositorio rompe un invariante del proyecto (*sin secretos en el repo, nunca*).

    **Cómo se obtiene:** pídelo a ingeniería para la unidad que vas a configurar. Llega por un canal
    directo, se usa y no se guarda en el equipo ni se reenvía.

Referencia rápida de los parámetros que más se consultan:

| Comando | Qué configura |
|---|---|
| `AS+I=1111` | Entra a modo configuración |
| `AS+A` · `AS+Q` · `AS+q` | APN: host, usuario, contraseña |
| `AS+S` · `AS+P` | Caster NTRIP: host y puerto |
| `AS+U` · `AS+M` | Caster: `usuario:contraseña` y mountpoint |
| `AS+B` | Velocidad del puerto (115200) |
| `AS+K` | **ID de estación** del módulo — se anota en el acta |
| `AS+r` · `AS+h` | Servidor secundario: IP y puerto |

## Firmware y configuración del simpleRTK2B Pro (ZED-F9P)

Aquí hay que separar dos cosas que se confunden:

| Qué | De dónde sale | Estado |
|---|---|---|
| **Firmware del ZED-F9P** | **Estándar de u-blox**, no es nuestro: [u-blox → ZED-F9P → Documentation & resources → Firmware Update](https://www.u-blox.com/en/product/zed-f9p-module). Serie **HPG**. Se carga con **u-center** (solo Windows) a 115200 | ✅ disponible en el sitio de u-blox |
| **Configuración de Helgen** (`.txt` de u-center) | **Nuestra.** Define UART1 a 115200 (que es lo que lee la tarjeta), UART2 a la velocidad del módem y qué mensajes NMEA salen | ⬜ **pendiente de publicar — este es el que de verdad falta** |

!!! warning "No actualices el firmware del F9P sin una razón concreta"
    El firmware de u-blox **no tiene nada que ver con nuestras fallas**: las correcciones llegan por
    el módem 4G, no por el GNSS, y en las capturas de junio los receptores estaban sanos. Actualizarlo
    es un proceso solo-Windows que puede dejar el receptor a medias, y **borra o invalida la
    configuración**, que es justo la parte que sí importa.

    Primero anota qué versión trae (**u-center → View → Messages → UBX-MON-VER**) y déjala así.
    Solo se actualiza si u-blox publica un arreglo para un problema que estemos viendo, y siempre en
    banco, nunca en una unidad instalada.

Para leer o cargar la configuración: u-center → *Tools → Receiver Configuration*. Después de cargar,
**guardar en FLASH** y reconectar para confirmar que sobrevive al reinicio — una configuración que
solo quedó en RAM se pierde al primer corte de energía, y así perdimos tiempo en junio.

## Cómo se publica un firmware nuevo

Para que un archivo pueda aparecer en esta página tiene que pasar por aquí. No es burocracia: un
binario mal compilado deja unidades muertas en el patio.

- [ ] Compilado con el `TARGET_` correcto para esa generación de tarjeta.
- [ ] **Probado en banco sobre hardware real**, no solo compilado sin errores.
- [ ] Verificada la polaridad del control de carga sobre la tarjeta.
- [ ] Nombre con **tarjeta y versión**: `hbox-tarjetaV3_X.Y.Z.bin`. La versión del firmware nunca se infiere de la tarjeta ni al revés.
- [ ] Su línea en `SHA256SUMS.txt`.
- [ ] Anotado en el `CHANGELOG.md` del repositorio de firmware, con fecha y quién lo probó.
- [ ] Actualizada la tabla de esta página.

Los archivos viven en `docs/descargas/` del repositorio `hbox-docs` y se publican con
`./scripts/deploy.sh`. Los `.bin` de firmware de campo están en `.gitignore` por tamaño y por
control de versiones: se copian a mano a esa carpeta antes de publicar.

## Herramientas

- **STM32CubeProgrammer** (Windows/macOS/Linux): https://www.st.com/en/development-tools/stm32cubeprog.html
- **dfu-util** (macOS: `brew install dfu-util`; Linux: `apt install dfu-util`)
- Terminal serie: CoolTerm, `screen /dev/tty.usbmodem* 115200`, o el monitor serie de Arduino IDE