# 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.5.3.bin`](hbox-tarjetaV4_0.5.3.bin) | ⚠ compilado 25-sep, **sin prueba de banco** | | **V5** — `hbox-watchdog-v5`, lote de 15 | STM32F411RET6 soldado | `hbox_v5_bringup` (0.5.3) | [`hbox-v5-bringup_0.5.3.bin`](hbox-v5-bringup_0.5.3.bin) | ⚠ **vigente desde 25-sep** — ventana de 2 min cada 10 min en batería; 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.3 (V4 y V5) cambia cómo se ve la unidad en el monitor cuando está en batería" Con 0.5.3 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=` 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 0.5.3.** Con la V3 (4.0.0) no cambia nada: sigue reportando continuo en batería. !!! 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`. Como `PB2` es `BOOT1` en el F411, la V4 **se flashea por DFU solo con USB** (sin 24 V), para que el W5500 apagado no pueda sostener `BOOT1` en alto. !!! 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.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.5.3.bin**](hbox-v5-bringup_0.5.3.bin) | **0.5.3** (2026-09-25) — **campo + Modo B + ventana de 2 min cada 10 min en batería** — ⚠ sin prueba de banco; requiere servidor con soporte `DUTY` | `2c5349a9a096929c…` | 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.3.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 25-sep la vigente es 0.5.3.** `0.4.0` queda en `superseded/` solo como referencia. !!! note "Tarjetas ya flasheadas con cualquier versión anterior" Re-flashear con **0.5.3** por el mismo procedimiento DFU. **La primera línea de la consola tras reset dice la versión** (`hbox-v5-bringup 0.5.3 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. **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.2/0.5.3 — batería:** 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=` / `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,,,` 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, 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.5.3.bin`](hbox-tarjetaV4_0.5.3.bin) · 81 932 B · `162a8d4f17af36e9…` | ⚠ compilado 25-sep, falta prueba de banco. Es 0.5.3 para Blackpill (`-DHBOX_BOARD_V4`), DFU **solo con USB** | !!! 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