221 lines
23 KiB
Markdown
221 lines
23 KiB
Markdown
---
|
||
title: "Notas de versión — firmware V4 / V5"
|
||
tags: [project-drogheda, hbox, firmware, notas-de-version, v4, v5, cargador, ltc4040, descargas]
|
||
date: 2026-09-29
|
||
project: Project Drogheda
|
||
author: Helgen Technologies
|
||
version: "1.0"
|
||
---
|
||
|
||
# Notas de versión — firmware V4 / V5
|
||
|
||
Un solo código fuente (`hbox_v5_bringup`) para las dos tarjetas: la V5 usa `hbox-v5-bringup_X.Y.Z.bin` y la V4 `hbox-tarjetaV4_X.Y.Z.bin`. La V3 tiene firmware propio (4.0.0) y no entra aquí. Binarios, SHA-256 y reglas de flasheo: [Descargas](index.md).
|
||
|
||
!!! abstract "Las versiones en una línea"
|
||
- **0.5.9**: en batería no se apaga ni cicla la etapa, pero **no carga**. La batería es de un solo uso.
|
||
- **0.6.0**: **carga**, con un gobernador que protege al módem. Pero con la ruta de 5 V justa cortaba la carga en cada ráfaga del módem, y el monitor casi nunca mostraba 🔌 CARGANDO.
|
||
- **0.6.1** (retirada al día siguiente): el gobernador distingue una ráfaga del módem de una fuente que no aguanta. Pero su `$PHLG` era demasiado largo para el módem y el monitor se quedó sin Salud ni Energía.
|
||
- **0.6.2** (en preparación): el gobernador de 0.6.1 con el `$PHLG` de siempre y el estado del gobernador en una sentencia corta aparte.
|
||
|
||
## Estado al 29-sep-2026
|
||
|
||
| Versión | Fecha | Estado | Binarios |
|
||
|---|---|---|---|
|
||
| 0.6.2 | — | En preparación: se publica después de probarla en H0027 | — |
|
||
| 0.6.1 | 28-sep | **Retirada el 29-sep: no flashear.** Su telemetría no llega al monitor ([por qué](#por-que-se-retiro-061)) | [V5](superseded/hbox-v5-bringup_0.6.1.bin) · [V4](superseded/hbox-tarjetaV4_0.6.1.bin) |
|
||
| **0.6.0** | 27-sep | **Vigente otra vez.** Carga, pero con la ruta de 5 V justa se corta con las ráfagas del módem | [V5](hbox-v5-bringup_0.6.0.bin) · [V4](hbox-tarjetaV4_0.6.0.bin) |
|
||
| 0.5.9 | 27-sep | Retirada. No carga | [V5](superseded/hbox-v5-bringup_0.5.9.bin) · [V4](superseded/hbox-tarjetaV4_0.5.9.bin) |
|
||
|
||
## Por qué se retiró 0.6.1
|
||
|
||
El módem 4G NTRIP Master reenvía al monitor solo líneas NMEA completas hasta cierto largo y descarta, sin aviso, las más largas. El `$PHLG` de 0.6.0 mide 99–107 caracteres y pasa. El de 0.6.1, con sus 7 campos nuevos, mide 125–131 y no llega nunca.
|
||
|
||
Lo confirmó el banco del 29-sep con H0027 en 0.6.1. La consola mostraba el `$PHLG` saliendo cada 30 s (`phlg_aire` subía). En el historial crudo del servidor llegaron todas las sentencias del GPS y los `$PHEV` cortos, pero ningún `$PHLG`, ni siquiera cortado. H0018, con 0.6.0 y el mismo modelo de módem, entregaba su `$PHLG` de 102–105 caracteres cada 30 s. El servidor no tiene límite de largo.
|
||
|
||
Consecuencia: una unidad con 0.6.1 manda posición y eventos, pero el monitor no ve batería, carga ni temperaturas. El gobernador en sí funcionaba bien (carga continua, sin cortes, aviso de ruta de 5 V débil).
|
||
|
||
0.6.2 vuelve al `$PHLG` de 29 campos de 0.6.0 y manda el estado del gobernador en una sentencia corta aparte, de unos 40–55 caracteres. El servidor la une a la salud de la unidad. Además trae una prueba desde la consola para medir el largo máximo que deja pasar el módem.
|
||
|
||
## Comparación rápida
|
||
|
||
| | 0.5.9 | 0.6.0 | 0.6.1 → 0.6.2 |
|
||
|---|---|---|---|
|
||
| Cargador (LTC4040) | Apagado por firmware (`CHRG_EN` alto) | Encendido por un gobernador | Gobernador corregido |
|
||
| Cuándo arranca la carga | Nunca | 24 V + etapa ON, ≥ 120 s tras el arranque y tras cada STACK ON, riel ≥ 5.05 V durante 30 s | Igual, midiendo la media del riel en 200 ms |
|
||
| Cuándo corta la carga | — | En cuanto **una** muestra rápida (ms) baja de 4.90 V: con el riel cerca de 5.0 V al cargar, una ráfaga LTE basta | **DURO**: una muestra < 4.70 V. **SOSTENIDO**: la media de 200 ms < 4.90 V durante 1 s seguido, o < 4.85 V |
|
||
| Quitar el 24 V mientras carga | — | Cuenta como corte y duplica la espera | No cuenta (`CHG_OFF BATT`) |
|
||
| Espera tras un corte | — | 60 s, se duplica en cada corte, tope 30 min | Igual, pero solo por cortes contados |
|
||
| Pulso de rearranque del LTC4040 | — | vbat < 3.90 V, 1 cada 30 min | Solo entre 3.00 y 3.80 V, nunca con FALLA del cargador |
|
||
| PFI que supone el firmware | — | 4.60 V (el de la V3) | 4.40 V (el real de V4 / V5.5) |
|
||
| `$PHLG` | 29 campos, `0.5.9-fm` | 29 campos, `0.6.0` | 0.6.1: 36 campos (el módem los descarta). 0.6.2: 29 campos + sentencia corta del gobernador |
|
||
| Monitor, columna Energía | «cargador OFF (fw)» | 🔌 CARGANDO solo si la muestra de cada 30 s cae cargando; si no, «sin cargar» (o ✅ CARGADA con ≥ 3.97 V y 5 V del vehículo) | 0.6.1: nada (no llega el `$PHLG`). 0.6.2: fase del gobernador («espera de arranque 2:30», «corte por riel»…), «cargó N %», «casi lleno», ✅ CARGADA |
|
||
| En batería | Etapa y módem encendidos, sin ciclos de etapa; corte a 3.40 V | Igual | Igual |
|
||
| Al volver el 24 V tras ≥ 10 s en batería | Reset del MCU | Igual | Igual |
|
||
| Build de banco con Ethernet | `0.6.0-eth` (sin cargador) | `0.6.0-eth` (con gobernador) | `0.6.1-eth` (ya no repite el DHCP cada 5 s) |
|
||
|
||
## 0.6.1 → 0.6.2: el gobernador ya no corta la carga por las ráfagas del módem
|
||
|
||
0.6.1 salió el 28-sep y se retiró el 29-sep por la telemetría ([arriba](#por-que-se-retiro-061)). 0.6.2 lleva exactamente este gobernador; lo único que cambia es cómo viajan sus datos al monitor.
|
||
|
||
### Qué pasaba con 0.6.0
|
||
|
||
En el banco, H0027 (V4) con fuente de 5.30 V y ~0.15 Ω de cable hasta P2: el cargador arrancaba a los 157 s y cada carga duraba 57 s, 0 s o 9 s antes de que el gobernador la cortara. Al cargar, el riel en P2 baja de ~5.20 a ~5.00 V. Una ráfaga de transmisión LTE dura milisegundos y se come los ~100 mV que quedan, y a 0.6.0 le bastaba **una** muestra rápida bajo 4.90 V para cortar. Cada corte duplicaba la espera (60 s, 2 min, 4 min… hasta 30 min), así que la batería casi no cargaba.
|
||
|
||
El monitor lee `CHRG_STAT` (campo 22 del `$PHLG`) una vez cada 30 s y casi nunca caía dentro de una de esas cargas cortas: por eso «no se veía cargando». El LTC4040 y el cargador estaban bien; H0008 (V5.5) estaba llena.
|
||
|
||
### Qué cambia
|
||
|
||
- **Corte en dos niveles.** DURO: una muestra rápida bajo **4.70 V**, que es la fuente colapsando (sobrecarga, hiccup); se corta en esa misma muestra, todavía 0.3 V sobre el PFI. SOSTENIDO: la **media de 200 ms** bajo **4.90 V durante 1 s seguido**, o una sola media bajo **4.85 V**; eso es la fuente o el cable sin fuerza para la carga. Las ráfagas del módem ya no cortan, ni solas ni cuando una ventana de 200 ms junta varias. La prueba de 30 s antes de arrancar (≥ 5.05 V) usa la misma media.
|
||
- **PFI real: 4.40 V.** En V4 y V5.5 el LTC4040 pasa el consumo de la tarjeta al paquete (boost) cuando el riel baja de 4.40 V (R51 270 k / R52 100 k), no en los 4.60 V de la V3 que suponía 0.6.0 (`BOARD_PFI_FALL_V` en `board_v4.h` / `board_v5.h`).
|
||
- **Quitar el 24 V no cuenta como corte.** Un corte solo cuenta si 3 s después sigue habiendo 5 V. Si no, sale `CHG_OFF BATT` y la espera no se duplica. Una fuente que se cae y vuelve en menos de 3 s sí cuenta: no sostuvo la carga.
|
||
- **Prueba de la ruta de 5 V (`CHG_RAIL`).** 5 s después de cada arranque de la carga el firmware mide cuánto bajó el riel. Lo esperado es menos de 0.10 V; más de 0.15 V es una ruta de 5 V débil hasta P2 (cable, conector o fuente). Sale como evento, en `STAT caida=` y en los datos del gobernador (`cdrop`).
|
||
- **Siete datos nuevos del gobernador**, para que el monitor vea su fase y las cargas cortas entre dos reportes. En 0.6.1 iban al final del `$PHLG` (campos 30–36), y por eso el módem lo descartaba; en 0.6.2 van en una sentencia corta aparte:
|
||
|
||
| Campo | Nombre | Qué es |
|
||
|---|---|---|
|
||
| 30 | `cgov` | Fase del gobernador: `HOLDOFF` `PROVING` `WAIT` `ON` `SHED` `COOLDOWN` `BATT` `NOTRUN` `PWRCYC` `INIT`, o `HOT` (celda caliente), `OP` (vetado con `C`), `OFF` (compilado sin cargador) |
|
||
| 31 | `cwait` | Segundos hasta que pueda arrancar la carga, contando los 30 s de prueba del riel (0 = carga permitida, −1 = nada programado) |
|
||
| 32 | `csheds` | Cortes contados desde el arranque (quitar el 24 V no cuenta) |
|
||
| 33 | `cduty` | % de los últimos 30 s cargando de verdad (−1 = sin dato) |
|
||
| 34 | `cchg_s` | Segundos cargando desde el arranque |
|
||
| 35 | `cdrop` | mV que bajó el riel en el último arranque de la carga (−1 = sin medir) |
|
||
| 36 | `vdda` | Referencia del ADC medida, en mV (0 = se usó la nominal de 3.30 V) |
|
||
|
||
- **ADC calibrado con VREFINT.** El MCU mide su propia referencia con el dato de fábrica, así que 4.70 / 4.90 / 5.05 V valen lo mismo con cualquier regulador de 3.3 V. Fuera de 3.15–3.45 V usa 3.30 V nominal.
|
||
- **Pulso de rearranque del LTC4040, más prudente.** Solo entre 3.00 y 3.80 V: bajo ~3.90 V (V_RECHRG) el LTC4040 vuelve a cargar solo y arriba de eso un pulso no hace nada; 3.80 V deja margen para la tolerancia de V_RECHRG. Nunca con FALLA del cargador: con una batería mala el pulso reiniciaría su temporizador de 30 min y seguiría cargando una celda muerta. Se cuenta desde que `CHRG_EN` volvió a ON, así que una pausa ya no gasta el pulso de cada 30 min.
|
||
- **Fases más claras.** `WAIT` = riel bajo, o espera tras una caída cuando no había corriente de carga (no cuenta como corte). `SHED` = los 3 s en que se clasifica un corte. `COOLDOWN` = solo después de un corte contado. `PWRCYC` = ciclo de etapa (antes salía `NOTRUN`). La pausa por NTC (CHRG y FAULT bajos a la vez) ya no se cuenta como carga. Evento nuevo `CHG_FAULT ntc|bateria|fin`.
|
||
- **Robustez.** La espera de 120 s tras el arranque queda cerrada una vez cumplida: 0.6.0 la volvía a abrir a los 49.7 días, cuando el reloj del MCU da la vuelta. El cargador se pone en pausa antes de lo que bloquea el lazo varios segundos (`r`, `g`, `i`, `A`, el DHCP del build `-eth`) y el gobernador lo retoma al terminar.
|
||
- **Build de banco `0.6.1-eth`.** Con cable directo a la laptop y sin servidor DHCP, `0.6.0-eth` repetía el DHCP entero en cada intento: 4–5 s bloqueado cada 5 s, con el cargador puesto. `0.6.1-eth` hace un solo intento de DHCP al conectar el cable y después renueva el lease una vez por minuto, solo si lo hubo. Si el W5500 no responde, reintenta cada 10 min tras 3 fallos.
|
||
|
||
### Qué se ve en la consola
|
||
|
||
Cada evento sale como `EVT up=<s> <texto>`; en la tabla, solo el texto.
|
||
|
||
| Línea | Qué significa |
|
||
|---|---|
|
||
| `CARGA ON: riel 5.xx V estable 30 s, vbat=…` | Arrancó la carga |
|
||
| `CARGA: riel 5.2x -> 5.0x V con el cargador (caida 0.xx V)` | 5 s después del arranque. Si sale además `RUTA DE 5 V DEBIL`, revisar cable, conector o fuente hasta P2 |
|
||
| `CARGA cortada (DURO): muestra rapida …` | La fuente colapsó |
|
||
| `CARGA cortada (SOSTENIDO): media 200 ms …` | La fuente o el cable no sostienen la carga |
|
||
| `CARGA OFF: se fue el 5 V … no cuenta como corte del gobernador` | Se quitó el 24 V |
|
||
| `CARGA en pausa: pruebas r …` | Pausa durante `r`, `g`, `i`, `A` o DHCP; se retoma sola |
|
||
| `STAT … carga=ON 812s pin=ON ltc=CARGANDO cortes=0(duro 0/sost 0) media=5.03 duty=100% cargado=812s caida=0.21V vdda=3.297` | Fase y segundos en ella, pin `CHRG_EN`, estado real del LTC4040, cortes (duros / sostenidos), media del riel, % cargando en los últimos 30 s, segundos cargando desde el arranque, caída del último arranque, referencia del ADC |
|
||
|
||
Eventos en banda (`$PHEV`, los ve el servidor): `CHG_ON`, `CHG_SHED duro|sost`, `CHG_OFF`, `CHG_RAIL`, `CHG_FAULT`, `CHG_PULSE`, `CHG_HOT`, `CHG_COOL`, y `CHRG_ON` / `CHRG_IDLE` (flanco real del LTC4040).
|
||
|
||
### Qué se ve en el monitor
|
||
|
||
Columna **Energía** (lista y detalle). El tile de batería del detalle dice lo mismo con otras palabras («sin cargar: espera de arranque…», «cargador permitido pero sin corriente»). Las cuentas atrás incluyen los 30 s de prueba del riel.
|
||
|
||
| Dice | Qué significa | Qué hacer |
|
||
|---|---|---|
|
||
| 🔌 CARGANDO | El LTC4040 estaba cargando en la muestra de 30 s | — |
|
||
| cargó N % | Cargó ese % de los últimos 30 s aunque la muestra no lo vio | — |
|
||
| espera de arranque 2:30 | Primeros 120 s tras el arranque o tras encender la etapa (el módem se registra antes de cargar), más la prueba del riel | Esperar |
|
||
| comprobando riel 0:12 | Los 30 s de prueba del riel antes de arrancar | Esperar |
|
||
| riel bajo para cargar | La media del riel no llega a 5.05 V, o espera tras una caída sin corriente de carga (con cuenta atrás; no cuenta como corte) | Fuente a 5.2–5.4 V medidos en P2; revisar cable |
|
||
| corte por riel | Los 3 s en que se clasifica un corte | Si se repite, ver la fila siguiente |
|
||
| espera tras corte 1:30 · 1 corte | Espera tras un corte contado: 60 s, que se duplican con cada corte (tope 30 min), más la prueba del riel | Varios cortes: [ruta de 5 V débil](#el-limite-de-la-ruta-de-5-v) |
|
||
| ciclo de etapa | Recuperación de enlace; la carga espera 120 s más la prueba de riel | — |
|
||
| etapa apagada | La etapa RTK está apagada | — |
|
||
| celda caliente | Celda ≥ 45 °C; vuelve a cargar bajo 40 °C | Revisar ventilación y sol directo |
|
||
| vetado (C) | Alguien bloqueó el cargador con `C` en la consola | `C` otra vez |
|
||
| casi lleno | Gobernador en ON y el LTC4040 terminó (pasó C/8) con 3.85–3.97 V | Normal. Bajo 3.90 V el LTC4040 vuelve a cargar solo |
|
||
| ✅ CARGADA | 5 V del vehículo presentes y batería ≥ 3.97 V | — |
|
||
| cargador sin corriente | Gobernador en ON pero el LTC4040 no carga, bajo 3.85 V | Entre 3.00 y 3.80 V el firmware manda el pulso de rearranque. Si sigue: paquete, NTC P4-3 y R50 |
|
||
| ⏸ PAUSA NTC · ⚠ FALLA CARGADOR | Lo dice el LTC4040: NTC del paquete fuera de rango o batería mala | Revisar NTC P4-3 y paquete |
|
||
| riel −0.2x V al cargar (detalle) | `cdrop` > 150 mV | Cable, conector o fuente hasta P2 |
|
||
|
||
En HISTORIAL la franja verde marca también los intervalos con `cduty` > 0, y el tooltip dice la fase del gobernador. Las exportaciones CSV / XLSX / PDF traen las 7 columnas nuevas al final.
|
||
|
||
### El límite de la ruta de 5 V
|
||
|
||
No es falla del firmware. La corriente de entrada del cargador es máxima cuando el paquete pasa de corriente constante a voltaje constante (~3.8 V): ~2.2 A al cargador más ~0.6 A de la etapa, unos **2.8 A** por el cable hasta P2. Con esa corriente la media del riel en P2 tiene que quedar en 4.90 V o más:
|
||
|
||
**R hasta P2 ≤ (V de la fuente − 4.90 V) / 2.8 A** → con 5.30 V, 0.14 Ω como máximo; con 5.40 V, 0.18 Ω.
|
||
|
||
Con más resistencia, los cortes SOSTENIDOS empiezan antes de ese punto, cuando el paquete llega a cierto voltaje, y la carga se estanca ahí. El módem queda protegido, pero el paquete no se llena. H0027 en el banco (0.15 Ω a 5.30 V) está en ese caso: cortes desde ~3.6 V. Con la fuente a 5.40 V pasa la regla. Remedio: subir la fuente dentro del rango del manual de la tarjeta (5.2–5.4 V en P2), acortar o engrosar el cable, o ambas cosas. La medición del firmware sirve de guía: `caida=` en `STAT` (evento `CHG_RAIL`) debería quedar bajo 0.10 V. En la V5.6 el cargador pide ~1.3 A (`R50` 1.5 kΩ) y el margen es mucho mayor.
|
||
|
||
### Cómo se probó y qué falta
|
||
|
||
- Simulador en PC (`tools/hostsim_v5` del repositorio de firmware): compila el sketch sin cambios contra un modelo eléctrico de la entrada de 5 V calibrado con H0027 y revisa 21 escenarios, con un invariante de seguridad del cargador en cada vuelta del lazo. 0.6.0 reproduce el síntoma: 6 cortes y 0 % del tiempo cargando en 40 min. 0.6.1: 0 cortes, 100 %. También cubre desconexión, hiccup, caída sostenida, batería mala, pausa NTC, veto, autoprueba `r`, ciclo de etapa, vuelta del reloj y VDDA de 3.25 V.
|
||
- **La prueba de banco se hace con 0.6.2** ([módem en batería §1](../procedimientos/prueba-bateria-modem.md#1-cargador-062), vale también para la V4). Primero, que el monitor muestre la fase del gobernador; después: H0027 30 min cargando sin cortes con el paquete bajo 3.5 V, quitar el 24 V ~5 s y volver a ponerlo, bajar la fuente a ~4.85 V en P2, y una noche con H0027 a 5.40 V y H0008 en 24 V. Las dos deben amanecer en «casi lleno» o ✅ CARGADA, sin cortes nuevos durante la noche.
|
||
|
||
### Archivos de 0.6.1 (retirados, no usar)
|
||
|
||
| Archivo | Tarjeta | Tamaño | SHA-256 |
|
||
|---|---|---|---|
|
||
| [`superseded/hbox-v5-bringup_0.6.1.bin`](superseded/hbox-v5-bringup_0.6.1.bin) | V5.5 (V5.6 solo con paquete Li-ion) | 93 584 B | `6fbbc583ac2415a742ed062c1208d4a807e61085eb2615d76e4c6da400961ad2` |
|
||
| [`superseded/hbox-tarjetaV4_0.6.1.bin`](superseded/hbox-tarjetaV4_0.6.1.bin) | V4 | 93 096 B | `ef43a901ae9a875e6346ae8f84cc5f150a2419ff7cd577fe8f69780236840757` |
|
||
|
||
Compilados del commit `708ee0a` del repositorio de firmware (arduino-cli 1.3.1, STM32duino 3.0.0). Detalle técnico: `CHANGELOG.md` del firmware, sección 0.6.1. Los umbrales de batería son de Li-ion (flotación 4.00 V, corte 3.40 V, LEDs, monitor). Una V5.6 con el paquete LFP-HT necesita un build propio con flotación 3.50 V y esos umbrales recalculados; la [ECO V5.6](../hardware/v56-eco.md) lo prevé como 0.7.0.
|
||
|
||
## 0.6.0: el cargador vuelve, con gobernador (27-sep)
|
||
|
||
### Por qué
|
||
|
||
Hasta 0.5.9 el firmware dejaba el cargador apagado: tras la primera noche en batería la unidad se quedaba sin respaldo. H0008 amaneció a 3.50 V y en 24 V seguía «sin cargar». En V5.5 / V4 no se puede encender el cargador sin más. `RS1` de 8 mΩ fija el límite de entrada del LTC4040 en ≈ 3.1 A, por encima de los 3 A del SD-15B, y `R50` de 825 Ω pide 2.4 A de carga con el paquete vacío. Paquete vacío + etapa + ráfaga LTE sobrepasan la fuente, el riel cae al PFI, el LTC4040 pasa el consumo al paquete (que está vacío) y la unidad entra en brown-out, reset y bucle: el incidente de flota del 10-ago.
|
||
|
||
### Qué hace
|
||
|
||
- **Gobernador de carga** (`chargeService`, adaptado del firmware de flota v3.0.1). Es lo único que mueve `CHRG_EN` después del arranque:
|
||
- Carga solo con la etapa ON en 24 V, sin respaldo de batería ni ciclo de etapa en curso.
|
||
- Nunca en los primeros 120 s tras el arranque ni tras cada STACK ON: primero se registra el módem.
|
||
- Arranca tras 30 s de riel ≥ 5.05 V.
|
||
- Corta al instante si una muestra rápida del riel baja de 4.90 V. Espera 60 s antes de reintentar, y la espera se duplica con cada corte hasta 30 min; vuelve a 60 s tras 10 min cargando bien.
|
||
- Con la celda (TMP102) a 45 °C o más no carga; vuelve bajo 40 °C. El NTC del paquete (R55) sigue como respaldo en el propio LTC4040.
|
||
- Si tras 60 s permitido el LTC4040 no carga y el paquete está bajo 3.90 V, un pulso de 500 ms en `CHRG_EN` rearma su temporizador de seguridad (máximo uno cada 30 min).
|
||
- **Consola**: `STAT … carga=FASE … pin= ltc= cortes=`; eventos `CHG_ON`, `CHG_SHED`, `CHG_OFF`, `CHG_HOT`, `CHG_COOL`, `CHG_PULSE` y `CHRG_ON` / `CHRG_IDLE`; tecla `C` = veto del operador.
|
||
- **`$PHLG` sin cambios** (29 campos). `PHLG_FW` pasa a `0.6.0` (sin «-fm»: ya no es el «field-minimum» sin cargador). El campo 22 (`chg`) sigue siendo el `CHRG_STAT` real del LTC4040.
|
||
- `-DENABLE_CHARGE=0` compila el comportamiento de 0.5.x (cargador siempre apagado).
|
||
|
||
### Qué salió mal
|
||
|
||
El corte por una sola muestra rápida bajo 4.90 V confundía las ráfagas del módem (milisegundos) con una fuente que no aguanta, y la espera crecía con cada corte. En unidades con la ruta de 5 V justa la batería casi no cargaba. Además el monitor solo veía `CHRG_STAT` en el instante de cada muestra de 30 s. Lo resuelve 0.6.1.
|
||
|
||
## 0.5.9: la base, sin ciclos de etapa en batería y sin cargador (27-sep)
|
||
|
||
### Por qué
|
||
|
||
Noche 26/27-sep con 0.5.8 (V5.5 en batería toda la noche): amaneció a 3.50 V con el F9P vivo y el módem oscuro, y al volver los 24 V el módem siguió oscuro hasta un reset (SW1 / P10) o `SW4G1`. En V5.5 / V4 el módem no arranca en frío sobre el boost del LTC4040. 0.5.8 tenía dos fallas: la recuperación de enlace seguía activa en batería y probablemente cicló la etapa esa noche, y al volver el 5 V no reseteaba si la etapa «venía de 24 V».
|
||
|
||
### Qué hace
|
||
|
||
- **Ningún ciclo de etapa en batería.** La recuperación de enlace (sin NMEA, RTK perdido) solo actúa con 5 V presente. Un ciclo en curso al perder el 5 V termina con la etapa apagada (`RECOVERY_ABORT`) y la etapa vuelve con el 5 V.
|
||
- **Reset del MCU al volver el 5 V tras ≥ 10 s de respaldo, siempre.** Es lo mismo que pulsar P10. Un parpadeo de menos de 10 s no resetea.
|
||
- **Sin ahorro en batería.** La etapa y el módem siguen encendidos y reportando igual que en 24 V (~10–13 h) hasta el corte de 3.40 V.
|
||
- **Vigilancia del módem, solo diagnóstico.** V4 / V5 no tienen señal de estado del módem; el firmware lo infiere por las correcciones RTCM que llegan al F9P y por las caídas del riel que hacen sus ráfagas. `STAT` añade `rtcm_age= sta= rtcm_last= sag5= sagb= flat= modem=vivo|SOSPECHOSO|?`; eventos `MODEM_DARK`, `MODEM_BACK`, `MODEM_WATCH`. No actúa sobre el módem.
|
||
- **Cargador apagado**, como en todas las 0.4.x–0.5.x. El paquete no se recarga en la unidad. Monitor: «cargador OFF (fw)».
|
||
- `$PHLG` de 29 campos; `PHLG_FW` = `0.5.9-fm`.
|
||
|
||
### Si la unidad viene de 0.5.1–0.5.8
|
||
|
||
0.5.1 fue la última embarcada antes de 0.6.0. Al pasar a 0.6.1 también cambia esto:
|
||
|
||
- 0.5.1 podía ciclar la etapa en batería (recuperación de enlace activa) y dejar el módem oscuro hasta los 24 V más un reset. Desde 0.5.9 no pasa.
|
||
- 0.5.2–0.5.7 apagaban la etapa entre ventanas de reporte cada 10 min en batería; 0.5.8 mandaba ráfagas cada 10 min. Retiradas: desde 0.5.9 el reporte en batería es continuo.
|
||
- Desde 0.5.6, 5 s después de cada STACK ON (3 s hasta 0.5.7) el MCU pulsa el reset del módem por U13-P7. Hace falta el puente a `SW4G1`; sin él no hace nada.
|
||
- Desde 0.5.7: tecla `R` (reset del MCU por software, igual que P10).
|
||
|
||
Detalle de cada versión anterior: [Descargas → versiones superadas](index.md#versiones-superadas).
|
||
|
||
## Cómo saber qué versión tiene una unidad
|
||
|
||
- Consola USB: al arrancar, bajo una línea de `=====`, sale `hbox-v5-bringup 0.6.1 built …` y en la línea siguiente `board=EinarBoard v5 (HBOX v5)` o `v4`.
|
||
- `$PHLG`, campo 1: `0.5.9-fm`, `0.6.0`, `0.6.1` (`-eth` en los builds de banco con Ethernet). Ojo: `0.6.0-eth` salió de dos códigos, 0.5.9 (sin cargador; el monitor dice «sin cargar») y 0.6.0 (con gobernador).
|
||
- Monitor: detalle de la unidad, chip **fw**.
|
||
|
||
## Pendiente
|
||
|
||
- V5.5 / V4: si el módem se apaga en batería no vuelve a arrancar sobre el boost. Es hardware y lo corrige la V5.6; el firmware evita apagarlo.
|
||
- La vigilancia del módem todavía no actúa: sus umbrales se fijan con la [prueba en batería §2](../procedimientos/prueba-bateria-modem.md#2-aceptacion-059-y-06x).
|
||
- Lazo y eco de RS-485 / RS-232: queda para un build posterior. 0.6.1 salió como arreglo del cargador y solo comprueba que el SC16IS752 responde.
|
||
- V5.6: `RS1` 10 mΩ y `R50` 1.5 kΩ (~1.3 A de carga). Con eso el gobernador casi nunca tendrá que cortar.
|
||
|
||
## Historial de revisiones
|
||
|
||
| Versión | Fecha | Cambios |
|
||
|---|---|---|
|
||
| 1.0 | 2026-09-29 | Primera versión: 0.5.9, 0.6.0 y 0.6.1. |
|
||
| 1.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. |
|