---
title: "Descargas"
tags: [project-drogheda, hbox, descargas, firmware, v3, v4, v5, modem, zed-f9p]
date: 2026-10-01
project: Project Drogheda
author: Helgen Technologies
version: "2.3"
---

# Descargas

| Qué | Qué se le carga | Cómo | Sección |
|---|---|---|---|
| Tarjeta HBOX (Blackpill / EinarBoard) | Firmware `.bin` | DFU por USB | [Firmware](#firmware-del-hbox-que-binario-va-en-que-tarjeta) |
| Módem 4G NTRIP Master | 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](../unidad.html) con las capturas de antes y después.

## Verifica el SHA-256

Antes de flashear. Un binario incompleto o de otra tarjeta puede dejarla inservible.

```bash
shasum -a 256 archivo.bin                          # macOS / Linux (o sha256sum)
certutil -hashfile archivo.bin SHA256              # Windows (cmd)
Get-FileHash .\archivo.bin -Algorithm SHA256       # Windows (PowerShell)
```

Debe coincidir carácter por carácter con [`SHA256SUMS.txt`](SHA256SUMS.txt). Si no coincide, descarga otra vez; si sigue sin coincidir, no lo uses y avisa.

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

Un binario por tarjeta. El nombre lleva la tarjeta y eso manda; el número de versión no dice nada de la tarjeta (`0.4.0` no es "para V4": es una versión vieja del firmware de V5).

| Tarjeta | MCU | Código fuente | Binario vigente | Estado |
|---|---|---|---|---|
| V3 — EinarBoard 1.0, 3 unidades en campo ([manual](../manuales/manual-tarjeta-V3.md)) | Blackpill en zócalo (F411CE) | `blackpillrtkcode_v4` (4.0.0) | [`hbox-tarjetaV3_4.0.0.bin`](hbox-tarjetaV3_4.0.0.bin) · 64 352 B · `a68a87ff…` | Compilado 19-sep, sin prueba de banco |
| V4 — `hbox-watchdog-v4` ([manual](../manuales/manual-tarjeta-V4.md)) | Blackpill + PCF8574 · W5500 · SC16IS752 | `hbox_v5_bringup` + `board_v4.h` (`-DHBOX_BOARD_V4`) | [`hbox-tarjetaV4_0.6.0.bin`](hbox-tarjetaV4_0.6.0.bin) · 88 556 B · `1458470bbdd95b49…` | Vigente otra vez desde el 29-sep: 0.6.1 se retiró ([por qué](notas-de-version.md#por-que-se-retiro-061)). DFU solo con USB; puente U13-P7 → SW4G1 opcional ([procedimiento V4](../procedimientos/v4-prueba-fw-0.5.6.md)) |
| V5 — `hbox-watchdog-v5`, lote de 15 ([manual](../manuales/manual-tarjeta-V5.md)) | STM32F411RET6 soldado | `hbox_v5_bringup` (0.6.0) | [`hbox-v5-bringup_0.6.0.bin`](hbox-v5-bringup_0.6.0.bin) · 89 028 B · `8a0ee4839763eae8…` | Vigente otra vez desde el 29-sep: 0.6.1 se retiró. Uso: [prueba y flasheo §5](../procedimientos/v5-prueba-y-flasheo.md) y [ensamble §5](../procedimientos/v5-ensamble.md) |

0.6.0 CAMPO (V4 y V5): 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 (la V5.5 no arranca el módem en frío sobre el boost, ver [módem en batería](../procedimientos/prueba-bateria-modem.md#3-hallazgos-2527-sep)); 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; vigilancia del módem solo diagnóstica (`modem=` en `STAT`); teclas `C`/`M`/`R`. 0.5.1 fue la última embarcada antes de 0.6.0. Qué cambió en cada versión y por qué: **[notas de versión](notas-de-version.md)**.

!!! danger "0.6.1 retirada (29-sep): no la flashees"
    Su `$PHLG` de 36 campos (125–131 caracteres) no pasa por el módem 4G NTRIP Master, que descarta las líneas largas: el monitor se queda sin Salud ni Energía (batería, carga, temperaturas). El gobernador de 0.6.1 sí funcionaba. 0.6.2 y 0.6.3 llevan el mismo gobernador y mandan la telemetría en dos líneas cortas; 0.6.3 está publicada solo para prueba de banco (abajo). Detalle: [notas de versión](notas-de-version.md#por-que-se-retiro-061).

!!! warning "0.6.3 EN PRUEBA DE BANCO (1-oct): solo para ingeniería y el banco, no flashear en campo"
    Sustituye a 0.6.2 (prueba del 30-sep), con la misma telemetría y los mismos cortes del gobernador de carga. Lo que trae, por el banco del 30-sep:

    - **El módem que se apaga en un respaldo corto vuelve solo.** En la V5 del banco el 24 V se fue 9 s con el paquete en ~3.5 V. En el boost el módem se apagó y, como 0.6.2 solo resetea tras ≥ 10 s de respaldo, quedó oscuro («el 4G no enciende») hasta que alguien apretó reset. 0.6.3 también resetea al volver el 24 V tras ≥ 1 s de respaldo si el paquete bajó de 3.70 V.
    - **El motivo de cada reset llega al servidor** (`$PHEV BOOT … prev=…`). Si fue la carga la que tumbó la fuente, la siguiente carga espera 4, 8, 16 y hasta 30 min en vez de repetir el reset cada ~2.5 min.
    - **Aviso cuando el cargador no carga un paquete bajo** (`CHG_NOCHG`, `STAT ltc=C8_BAJO`): revisar JP2/JP3/JP4 y el paquete.
    - Corte de 3.40 V en batería con la media de 200 ms; vigilancia del módem sin falsas alarmas; `STAT phcg_aire=`; tecla `t` con las líneas exactas que van al módem; autopruebas `RTC_BKP` y `TMP102` contra el SHT40.

    El servidor es el mismo de 0.6.2: el `retranslator.py` con `$PHCG` (htracker, 30-sep). Si una unidad 0.6.2 o 0.6.3 sale en el monitor sin fuente (vehículo / batería), sin uptime y sin fase del gobernador, el servidor no está corriendo esa versión; no es el firmware ([cómo comprobarlo](notas-de-version.md#063-en-prueba)).

    | Tarjeta | Binario de prueba | Tamaño | SHA-256 |
    |---|---|---|---|
    | V4 | [`prueba/hbox-tarjetaV4_0.6.3.bin`](prueba/hbox-tarjetaV4_0.6.3.bin) | 99 152 B | `a6c3b4677fa696bb…` |
    | V5 / V5.5 | [`prueba/hbox-v5-bringup_0.6.3.bin`](prueba/hbox-v5-bringup_0.6.3.bin) | 99 640 B | `3641159a4c68ef09…` |

    Qué probar y qué debe verse: [notas de versión → 0.6.3](notas-de-version.md#063-en-prueba). La prueba de largo de línea (tecla `X`, de 0.6.2) sigue igual: [`prueba/phtst_report.py`](prueba/phtst_report.py) (Python 3). Los binarios de 0.6.2 pasaron a `superseded/`.

!!! warning "No se cruzan"
    - `hbox-v5-bringup_…` (F411RE soldado) en una V3 o V4: otro MCU y otro mapa de pines. La V4 usa `hbox-tarjetaV4_…`.
    - `hbox-tarjetaV3_…` o `blackpillrtkcode_v3` en una V4 o V5: manejan los LEDs de carga en PB12–PB15, que ahí son el SPI del W5500.
    - Nada de `superseded/`: se guarda solo por trazabilidad.
    - Nada de `prueba/` en campo: son builds para el banco hasta que pasen y entren a la tabla de vigentes.
    - Nada que no esté publicado aquí con su SHA-256. Los `.bin` de V3 y V4 no viven en el repositorio; se compilan, se prueban en banco y se publican ([reflasheo §5](../procedimientos/reflasheo-unidades.md#5-para-ingenieria-generar-y-publicar-un-binario)).

Las tres tarjetas mandan la misma trama: `$PHLG` de 29 campos cada 30 s y un `$PHEV` por cambio de estado, en banda por el módem (Modo B). El monitor la parsea igual (`retranslator.py`: 20 campos base + 4 de v3 + 5 de 0.5.1, y `$PHEV`) y las tres se ven igual en Salud. Ninguna línea en banda puede pasar de lo que deja pasar el módem: hasta 105 caracteres está probado; las de 125 o más (el `$PHLG` de 0.6.1) se pierden. El `$PHLG` de 29 campos crece con el tiempo encendida (`up_s` y `rx_count` ganan dígitos): ~102 caracteres al arrancar, ~108 tras unas horas, ~113 a los 12 días. 0.6.2 y 0.6.3 (en prueba) mandan en banda el `$PHLG` con los campos 1–24 y aparte una `$PHCG`, las dos de 100 caracteres o menos; su tecla `X` mide el límite exacto.

!!! warning "V3 4.0.0: todavía no en unidades de campo"
    Compila y pasa el simulador, pero no ha corrido en una EinarBoard 1.0 real. Solo en la mesa de ingeniería hasta que se pruebe en banco (RTK-003 o RTK-006) y se quite este aviso. 4.0.0 activa Modo B por omisión (el MCU queda en línea con el enlace de correcciones), así que la primera prueba es en par: el binario publicado y uno sin Modo B sobre la misma unidad. Si el fix RTK cae al energizar K1, o `v5min` se hunde en ese instante, sospecha de 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
    ```

### Gobernador de carga (0.6.x)

No se podía encender el cargador sin más: en V5.5/V4 `RS1` 8 mΩ → límite de entrada del LTC4040 ≈ 3.1 A (más que los 3 A del SD-15B) y `R50` 825 Ω → 2.4 A de carga; paquete vacío + etapa + ráfaga LTE hunden el riel hasta el PFI del LTC4040 y la unidad entra en bucle (incidente de flota 10-ago). H0008 amaneció a 3.50 V tras una noche en batería y seguía "sin cargar" en 24 V.

El gobernador de 0.6.0 (vigente) carga solo con etapa ON en 24 V; nunca en los primeros 120 s tras boot ni tras cada STACK ON; arranca tras 30 s de riel ≥ 5.05 V; corta al instante si una muestra baja de 4.90 V, con enfriamiento de 60 s a 30 min; inhibe con celda ≥ 45 °C; rearma el safety timer del LTC4040. Con la ruta de 5 V justa (riel cerca de 5.0 V al cargar) cualquier ráfaga del módem corta la carga: la batería carga poco y el monitor casi nunca muestra 🔌 CARGANDO. 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 solo con `chg=1` en `$PHLG`. 0.6.3 (en prueba de banco, arriba; el mismo gobernador de 0.6.1 y 0.6.2) corrige los cortes y manda el estado del gobernador al monitor ([notas de versión](notas-de-version.md#063-en-prueba)); su prueba de banco: [módem en batería §1](../procedimientos/prueba-bateria-modem.md#1-cargador-063). Si corta sin parar: ruta de 5 V débil hasta P2 ([regla](notas-de-version.md#el-limite-de-la-ruta-de-5-v)) o fuente sin margen de corriente (el SD-15B da 3 A; carga + etapa piden ~2.8 A). La V5.6 (`RS1` 10 mΩ, `R50` 1.5 kΩ) pide mucho menos.

### Monitor con builds de ciclo

Builds con ciclo o ahorro en batería (0.5.2–0.5.8, o compilados con `-DENABLE_DUTY=1`) apagan el módem entre reportes: ~120–180 s cada 10 min con `pwr=BATT` y `DUTY_SLEEP next=<s>`. Para que ese silencio no cuente como caída ni dispare el correo del notifier, `retranslator.py` debe llevar el soporte `DUTY` (24-sep): despliega primero el servidor, después flashea. 0.5.9+ y la V3 4.0.0 reportan continuo en batería (el monitor muestra ⚡ sin badge de silencio).

### V4 = V5 en un Blackpill

Cotejada pad por pad (`hbox-watchdog-v4.kicad_pcb` contra `board_v5.h`): mismas redes, pines, direcciones I²C (PCF8574 `0x20`, SHT40 `0x44`, TMP102 `0x48`, SC16IS752 `0x4D`), W5500 en SPI2 y K1 en `PB5`. Única diferencia: `ETH_INT` en `PB2` (J1.16) en vez de `PC0`. Se flashea por DFU solo con USB (sin 24 V, batería desconectada); ese USB alimenta el 5 V y el W5500, cuya `INTn` llega a `PB2` = `BOOT1`. Sin `STM32 BOOTLOADER`, se flashea la Blackpill fuera del zócalo ([procedimiento V4](../procedimientos/v4-prueba-fw-0.5.6.md)).

### Flasheo y consola (V5)

DFU por J11 (mantén SW2, pulsa y suelta SW1, suelta SW2):

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

o STM32CubeProgrammer → USB → Connect → Download en `0x08000000`. Tarjetas con cualquier versión anterior se reflashean igual. Al arrancar, la consola imprime la versión (`hbox-v5-bringup 0.6.0  built …`); si `STAT` no trae `stack=`, la tarjeta sigue con 0.1.1.

Consola: `EVT` en cada cambio (etapa, ignición, 5 V, cargador, NMEA, fix), `STAT` cada 5 s y `$PHLG` cada 10 s. `l` = leyenda, `v` = puntos de medición de la etapa RTK, `P` y luego `Y` = encender la etapa (requiere 5 V en P2).

El nombre "bring-up" viene de 0.1.x, que solo probaba la tarjeta; desde 0.4.0 es el firmware de campo de la V5. Compilación y cambios: [README del firmware](hbox-v5-bringup-README.md).

### Versiones superadas

No se flashean. Sirven para identificar lo que trae una tarjeta vieja o 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) | Lógica de campo (3.0.3) sin telemetría en banda: el monitor no ve Salud. Sustituida por 4.0.0. |
| [`superseded/hbox-v5-bringup_0.6.2.bin`](superseded/hbox-v5-bringup_0.6.2.bin) · [`superseded/hbox-tarjetaV4_0.6.2.bin`](superseded/hbox-tarjetaV4_0.6.2.bin) | Prueba de banco del 30-sep, sustituida el 1-oct por 0.6.3 (misma telemetría y mismo gobernador). Tras un respaldo corto con el paquete bajo el módem podía quedar oscuro hasta un reset. |
| [`superseded/hbox-v5-bringup_0.6.1.bin`](superseded/hbox-v5-bringup_0.6.1.bin) · [`superseded/hbox-tarjetaV4_0.6.1.bin`](superseded/hbox-tarjetaV4_0.6.1.bin) | No usar. Su `$PHLG` de 36 campos no pasa por el módem: el monitor pierde Salud y Energía. El gobernador corregido vuelve en 0.6.2 ([notas de versión](notas-de-version.md#por-que-se-retiro-061)). |
| [`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) | Sin cargador (paquete de un solo uso). 0.6.0 añade el gobernador y 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. Recovery activo en batería: el silencio del ahorro provocaba "RTK perdido" y, probablemente, un ciclo de etapa que dejaba el módem oscuro hasta un reset (noche 26/27-sep). |
| [`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); solo servía al volver el 5 V. |
| [`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 no encendía en las ventanas y un reset en batería dejaba la etapa apagada. |
| [`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. UART del GNSS en alta impedancia no bastó: `3V3_MODEM` queda en ~1 V y el módem no rearranca. |
| [`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. El ciclo de etapa al volver el 5 V no apagaba el módem (el UART del GNSS sostenía su riel): no rearrancaba sin reset. |
| [`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; al volver el 5 V el módem podía quedar en latch hasta un reset. |
| [`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) | Primer reporte cada 10 min en batería; ventana de 90 s insuficiente para entregar la posición. |
| [`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 de campo antes del ciclo de 10 min (en batería dejaba la etapa encendida hasta vaciar el paquete). |
| [`superseded/hbox-v5-bringup_0.4.0.bin`](superseded/hbox-v5-bringup_0.4.0.bin) | Sin `$PHLG` en banda. Sustituida por 0.5.1. |

??? note "Historial por versión, 0.4.0 → 0.6.3"
    - Desde 0.4.0: AUTO de fábrica (la etapa RTK enciende sola 3 s después de ver 5 V en P2); watchdog 16 s; ventilador (política v3.0.3); recuperación de enlace (ciclo de etapa si el F9P calla 60 s; LIMP tras 3 ciclos); LEDs de carga y color de estado; corte térmico 60 °C; corte de batería 3.40 V. Anota la versión en el acta.
    - 0.6.3 (en prueba de banco desde el 1-oct, carpeta `prueba/`): 0.6.2 + reset al volver el 5 V también tras ≥ 1 s de respaldo si el paquete bajó de 3.70 V (con el paquete bajo el módem se apaga en el boost); motivo del reset en `$PHEV BOOT … prev=`; espera de carga creciente si la carga tumbó la fuente; `CHG_NOCHG`; corte SLEEP con la media de 200 ms; vigilancia del módem con histéresis; `phcg_aire` y tecla `t` con `aire>`; autopruebas `RTC_BKP` y `TMP102` contra el SHT40. [Notas de versión](notas-de-version.md#063-en-prueba).
    - 0.6.2 (prueba de banco del 30-sep; sustituida por 0.6.3, en `superseded/`): el gobernador de 0.6.1; en banda `$PHLG` de 24 campos + `$PHCG` (fuente, uptime, gobernador), cada línea sola en el cable; tecla `X` (prueba de largo de línea). [Notas de versión](notas-de-version.md#062-en-prueba).
    - 0.6.1 (retirada el 29-sep): gobernador corregido, pero con un `$PHLG` de 36 campos que el módem descarta; el monitor se quedaba sin Salud. Ese gobernador vuelve en 0.6.2. [Notas de versión](notas-de-version.md#por-que-se-retiro-061).
    - 0.6.0 CAMPO (vigente): 0.5.9 + gobernador de carga; con la ruta de 5 V justa corta la carga en cada ráfaga del módem (lo corrigen 0.6.2 y 0.6.3).
    - 0.5.9 CAMPO: sin ciclo ni ahorro en batería (`ENABLE_DUTY 0`, `ENABLE_BATT_SAVER 0`); ningún ciclo de etapa en batería (`RECOVERY_ABORT`); reset del MCU al volver el 5 V tras ≥ 10 s; un reset en batería deja la etapa apagada hasta que vuelva el 5 V; vigilancia del módem: `STAT` con `rtcm_age= sta= rtcm_last= sag5= sagb= flat= modem=vivo|SOSPECHOSO|?`, eventos `MODEM_DARK`/`MODEM_BACK`/`MODEM_WATCH`. Con esos números se calibra 0.5.10.
    - 0.5.8 CAMPO (retirada): nunca apaga el módem en batería (un módem ya encendido aguanta el paso de 24 V a batería); ráfaga de posición de ~8 s cada 10 min y `$PHLG` cada 3 min (`SAVER_ON`, `DUTY_SLEEP`/`DUTY_WAKE`, `ahorro=`); autonomía estimada ~30–35 h; recovery aún activo en batería.
    - 0.5.7: cada despertar de batería (≥ 10 min tras la última ventana) y cada regreso del 5 V es un reset del MCU (`NVIC_SystemReset`, igual que P10): arranque en ~4 s; se pierden uptime y contadores. Tecla `R`. Un reset por SW1/P10 en batería abre ventana en 60 s y `P` se acepta en batería con vbat ≥ 3.60 V.
    - 0.5.6: 3 s tras cada encendido de etapa, pulso de 500 ms al reset del módem por U13 P7 (`MODEM_RST`, `mrst=`, tecla `M`); requiere el puente U13 pin 12 → diodo BAT54 → SW4G1 pad 1. Con la etapa apagada PA9/PA10 en alta impedancia sin pull-up.
    - 0.5.5: con la etapa apagada el UART del GNSS queda en alta impedancia (PA2 sostenía el riel del simpleRTK2B y, por él, el del módem); al volver el 5 V la etapa se cicla 10 s (`PWR_RETURN_CYCLE`).
    - 0.5.2–0.5.7: en batería, 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). Retirado en 0.5.8 para V5.5/V4; queda con `-DENABLE_DUTY=1`.
    - 0.5.1: `$PHLG` suma `up_s`, `pwr` (VEH/BATT), `v5min`/`vbat_min` (mínimos de la ventana de 30 s; cazan hundimientos LTE de 50–200 ms) y `bkp_n`; cada cambio de estado sale como `$PHEV,<up_s>,<CODIGO>,<detalle>`. Los analizadores viejos ignoran los campos extra. El 18-sep se reportó que la etapa no encendía; resuelto el 19-sep: 0.5.1 ensambla, enciende y reporta completo.
    - 0.5.0: Modo B. 10 s después de que habla el F9P, el MCU conmuta K1 y `$PHLG` viaja cada 30 s con el NMEA (`STAT … modoB=ON relay=… phlg_aire=…`, sube 1 cada 30 s). Si el MCU falla, K1 vuelve al paso directo. `B` lo bloquea para pruebas. Sin 5 V la etapa sigue desde la batería (`EVT BACKUP inicio` / `BACKUP fin` con duración y tramas); se apaga con vbat < 3.40 V o > 50 °C. `A` regresa a MANUAL.

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

Se envían por el USB XBEE del simpleRTK2B a 115200, línea por línea (solo las que empiezan con `$$$AS+`); cada una contesta `OK`.

[`4G_NTRIP_HelgenSRV-NMEA.example.txt`](4G_NTRIP_HelgenSRV-NMEA.example.txt): plantilla con todas las claves y los valores sensibles en blanco.

| Clave | Configura | En la plantilla |
|---|---|---|
| `AS+I=1111` | Entra a modo configuración | Fijo |
| `AS+A` · `AS+Q` · `AS+q` | APN: host, usuario, contraseña | `<APN_HOST>` `<APN_USER>` `<APN_PASS>` |
| `AS+S` · `AS+P` | Caster NTRIP: host y puerto | `<NTRIP_CASTER_HOST>` `<NTRIP_CASTER_PORT>` |
| `AS+U` · `AS+M` | Caster: `usuario:contraseña` y mountpoint | `<NTRIP_USER>:<NTRIP_PASS>` `<NTRIP_MOUNTPOINT>` |
| `AS+B=115200` | Velocidad hacia el F9P | Fijo |
| `AS+r` · `AS+h` · `AS+k=2` | Servidor secundario (monitor Helgen): IP, puerto, modo | `<SECONDARY_SERVER_IP>` `<SECONDARY_SERVER_PORT>` |
| `AS+K` | ID de estación = `H00xx` de la unidad; se anota en el acta | `<STATION_ID>` |

!!! warning "Credenciales"
    El archivo con los valores reales (usuario y contraseña del caster y de la APN) no está en el sitio ni en el repositorio: sin secretos en el repo, nunca. Pídelo a ingeniería para la unidad que vas a configurar; llega por canal directo, se usa y no se guarda ni se reenvía. Nunca lo escribas en un acta.

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

| Qué | Origen | Estado |
|---|---|---|
| Firmware del ZED-F9P | Estándar de u-blox, serie HPG: [u-blox → ZED-F9P → Documentation & resources → Firmware Update](https://www.u-blox.com/en/product/zed-f9p-module). Se carga con u-center (solo Windows) a 115200 | Disponible en u-blox |
| Configuración Helgen (`.txt` de u-center) | Nuestra: UART1 a 115200 (lo que lee la tarjeta), UART2 a la velocidad del módem, mensajes NMEA | Pendiente de publicar |

!!! warning "No actualices el firmware del F9P sin razón concreta"
    Las correcciones llegan por el módem, no por el GNSS, y en las capturas de junio los receptores estaban sanos. Actualizar es solo-Windows, puede dejar el receptor a medias y borra la configuración. Anota la versión (u-center → View → Messages → UBX-MON-VER) y déjala. Solo se actualiza por un arreglo de u-blox a un problema que estemos viendo, en banco, nunca en una unidad instalada.

Leer o cargar la configuración: u-center → Tools → Receiver Configuration. Después, guarda en FLASH y reconecta para confirmar que sobrevive al reinicio; una configuración solo en RAM se pierde al primer corte (así se perdió tiempo en junio).

## Publicar un firmware nuevo

Lista y comandos: [reflasheo §5](../procedimientos/reflasheo-unidades.md#5-para-ingenieria-generar-y-publicar-un-binario).

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

## Historial de revisiones

| Versión | Fecha | Cambios |
|---|---|---|
| 1.x | 2026-09-19 → 2026-09-27 | Cada binario nuevo (0.4.0 → 0.6.0) añadió su nota. |
| 1.8 | 2026-09-29 | Historial por versión en cajas plegables; enlaces a manuales. |
| 1.9 | 2026-09-29 | Edición breve. Una sola tabla de binarios vigentes; verificación SHA-256 con encabezado propio; tabla de parámetros del módem completa (antes en la configuración de la unidad); lista de publicación → reflasheo §5. |
| 2.0 | 2026-09-29 | Firmware 0.6.1 vigente en V4 y V5; 0.6.0 a `superseded/`; `$PHLG` de 36 campos; gobernador 0.6.1; [notas de versión](notas-de-version.md). |
| 2.1 | 2026-09-29 | 0.6.1 retirada (su `$PHLG` no pasa por el módem): 0.6.0 vigente otra vez; 0.6.2 en preparación. |
| 2.2 | 2026-09-30 | 0.6.2 publicada solo para prueba de banco, en `prueba/` (V4 `ec7425ac…`, V5 `3a183fcc…`), con `phtst_report.py`; 0.6.0 sigue vigente. |
| 2.3 | 2026-10-01 | 0.6.3 en prueba de banco, en `prueba/` (V4 `a6c3b467…`, V5 `3641159a…`); 0.6.2 a `superseded/`; 0.6.0 sigue vigente. |

Versiones anteriores en git.