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

28 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.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
V5 — hbox-watchdog-v5, lote de 15 STM32F411RET6 soldado hbox_v5_bringup (0.6.0) 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).

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

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

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