Helgen-Services/hbox-docs
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
d173fb1b21
hbox-docs/docs/descargas/index.md

17 KiB
Raw Blame History

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
Módem 4G NTRIP Master Archivo de parámetros $$$AS+… Terminal serie por el USB XBEE § Módem 4G
simpleRTK2B Pro (ZED-F9P) Configuración u-center y firmware u-blox u-center por el USB POWER+GPS § ZED-F9P

Cada carga se registra en el acta de reflasheo, y queda en el expediente de esa unidad 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 ⚠ 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.4.bin ⚠ compilado 25-sep, sin prueba de banco
V5 — hbox-watchdog-v5, lote de 15 STM32F411RET6 soldado hbox_v5_bringup (0.5.4) hbox-v5-bringup_0.5.4.bin ⚠ vigente desde 25-sep (0.5.4) — ventana de 2 min cada 10 min en batería + ciclo de etapa al volver el 5 V; 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 0.5.4. 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 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.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-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-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 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.4.bin 0.5.4 (2026-09-25) — campo + Modo B + ventana de 2 min cada 10 min en batería + ciclo de etapa al volver el 5 V — ⚠ sin prueba de banco; requiere servidor con soporte DUTY 83a4f929b9a68ec9… Sección 5 del procedimiento de prueba y flasheo v5 y sección 5 del ensamble (modo de banco P / n)

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

dfu-util -a 0 -s 0x08000000:leave -D hbox-v5-bringup_0.5.4.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.4. 0.4.0 queda en superseded/ solo como referencia.

!!! note "Tarjetas ya flasheadas con cualquier versión anterior" Re-flashear con 0.5.4 por el mismo procedimiento DFU. La primera línea de la consola tras reset dice la versión (hbox-v5-bringup 0.5.4 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.4:** al volver el 5 V después de batería la etapa se cicla 5 s (`PWR_RETURN_CYCLE`) para rearrancar un módem en *latch* por subvoltaje.

**0.5.2–0.5.4 — 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=<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 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.

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.

Tarjeta Archivo Estado
V3 — flota desplegada 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.4.bin · 82 164 B · c96041aea04b1e65… ⚠ compilado 25-sep, falta prueba de banco. Es 0.5.4 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.

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