# 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-por-generacion-de-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

**La versión del firmware no dice nada de la tarjeta.** `0.3.0` no es "para V3" ni `0.4.0` "para V4":
son versiones viejas del firmware de **V5**. El binario lleva la tarjeta en el nombre y eso es lo que manda.

| Tarjeta | MCU | Firmware (código) | Binario vigente |
|---|---|---|---|
| **V3** — EinarBoard 1.0, las 3 unidades en campo | Blackpill en zócalo (F411CE) | `blackpillrtkcode_v3` · `_v4` | [`hbox-tarjetaV3_3.0.4.bin`](hbox-tarjetaV3_3.0.4.bin) ⚠ sin prueba de banco |
| **V3** con telemetría en banda | Blackpill en zócalo | `blackpillrtkcode_v4` (4.0.0) | [`hbox-tarjetaV3_4.0.0.bin`](hbox-tarjetaV3_4.0.0.bin) ⚠ sin prueba de banco |
| **V4** — `hbox-watchdog-v4` | Blackpill en zócalo + PCF8574 · W5500 · SC16IS752 | **ninguno** | — |
| **V5** — `hbox-watchdog-v5`, lote de 15 | STM32F411RET6 soldado | `hbox_v5_bringup` | [`hbox-v5-bringup_0.5.1.bin`](hbox-v5-bringup_0.5.1.bin) ✅ **en despliegue** |

!!! danger "Lo que NO se puede cruzar"
    - Un binario de **V5** en una **V3 o V4**: es otro MCU (soldado vs Blackpill), otro reloj y otro mapa
      de pines. Lo más probable es que ni enumere por USB.
    - `blackpillrtkcode` en una **V4**: maneja los LEDs de carga en PB12–PB15, que en la V4 son el SPI
      del W5500. La V4 **no tiene firmware todavía**; hasta que lo tenga, no se flashea con nada.
    - `hbox-v5-bringup_0.4.0` (o 0.3.0) en cualquier tarjeta: son versiones **superadas** de V5, sin
      watchdog, ventilador ni recuperación de enlace. Solo se conservan por trazabilidad.

### Firmware de bring-up — EinarBoard v5

| Archivo | Versión | SHA-256 | Uso |
|---|---|---|---|
| [`hbox-v5-bringup_0.4.0.bin`](hbox-v5-bringup_0.4.0.bin) | 0.4.0 (2026-09-17) — **superada**, sin telemetría en banda | `a8de74b3d7768e9d…` ([SHA256SUMS](SHA256SUMS.txt)) |
| [**hbox-v5-bringup_0.5.1.bin**](hbox-v5-bringup_0.5.1.bin) | **0.5.1** (2026-09-18) — **campo + Modo B / telemetría — EN PRUEBA** (reportado: etapa RTK no enciende) | `e1f351084e803306…` | 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.5.1.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 embarca con 0.5.1.** `0.4.0`
    sigue descargable solo como referencia de versiones anteriores.

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

!!! tip "Consola 0.5.1"
    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.1 = 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.
    **El cargador sigue APAGADO: el paquete es de un solo uso hasta el firmware de producción.** Anotarlo en el acta de la unidad.

    **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 sigue apagado en todos los modos.

!!! 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 (`blackpillrtkcode_v3` / `v4`), distinto del de
bring-up del v5. Se usa en el [reflasheo en taller](../procedimientos/reflasheo-unidades.md).

| Generación | Archivo | Estado |
|---|---|---|
| **V3** — flota desplegada | [`hbox-tarjetaV3_3.0.4.bin`](hbox-tarjetaV3_3.0.4.bin) · 62 464 B · `035ebeb3…` | ⚠ compilado 19-sep, falta prueba de banco |
| **V3** con telemetría | [`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 |

!!! 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