hbox-docs/docs/descargas/notas-de-version.md

title	tags	date	project	author	version
Notas de versión — firmware V4 / V5	project-drogheda hbox firmware notas-de-version v4 v5 cargador ltc4040 descargas	2026-10-01	Project Drogheda	Helgen Technologies	1.4

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.

!!! 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 (prueba de banco del 30-sep, sustituida por 0.6.3): el gobernador de 0.6.1, con la telemetría en dos líneas cortas que el módem sí deja pasar. - 0.6.3 (en prueba de banco desde el 1-oct): 0.6.2, y además el módem que se apagaba en un respaldo corto con el paquete bajo vuelve solo, el motivo de cada reset llega al servidor y la unidad avisa si el cargador no carga un paquete bajo.

Estado al 1-oct-2026

Versión	Fecha	Estado	Binarios
0.6.3	1-oct	En prueba de banco desde el 1-oct. No flashear en campo hasta que pase (abajo)	V5 · V4
0.6.2	29-sep	Prueba de banco del 30-sep; sustituida por 0.6.3 el 1-oct (abajo)	V5 · V4
0.6.1	28-sep	Retirada el 29-sep: no flashear. Su telemetría no llega al monitor (por qué)	V5 · V4
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 · V4
0.5.9	27-sep	Retirada. No carga	V5 · V4

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 pasa. El de 0.6.1, con sus 7 campos nuevos, mide 125–131 caracteres 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).

Ojo con 0.6.0: su $PHLG crece con el tiempo encendida (up_s y rx_count ganan dígitos), de ~102 caracteres al arrancar a ~108 tras unas horas y ~113 a los 12 días. Hasta 105 está comprobado. Si el límite del módem queda por debajo, una unidad 0.6.0 que lleva mucho encendida deja de mandar Salud (la posición sigue). La tecla X (0.6.2 y 0.6.3) dice dónde está el límite.

Desde 0.6.2 el firmware manda en banda el $PHLG con los campos 1–24 y, en el hueco siguiente, una línea $PHCG con el resto: las dos de 100 caracteres o menos aunque la unidad lleve meses encendida. El servidor las une en la salud de la unidad. Además trae una prueba desde la consola (tecla X) para medir el largo máximo que deja pasar el módem. Detalle: 0.6.2.

Comparación rápida

	0.5.9	0.6.0	0.6.1 → 0.6.3
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 y 0.6.3: en consola 29 campos + $PHCG; en banda campos 1–24 + $PHCG, 100 caracteres o menos cada una
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 y 0.6.3: 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. 0.6.3: el corte de 3.40 V va con la media de 200 ms (una ráfaga LTE ya no lo dispara)
Al volver el 24 V tras un respaldo	Reset del MCU tras ≥ 10 s	Igual	Igual. 0.6.3: también tras ≥ 1 s si el paquete bajó de 3.70 V; el motivo sale en $PHEV BOOT
Build de banco con Ethernet	0.6.0-eth (sin cargador)	0.6.0-eth (con gobernador)	0.6.1-eth … 0.6.3-eth (ya no repite el DHCP cada 5 s)

0.6.3 en prueba de banco (1-oct)

Publicada el 1-oct solo para ingeniería y el banco (Descargas, carpeta prueba/). Sustituye a 0.6.2 con la misma telemetría (sirve el mismo servidor), los mismos cortes del gobernador de carga y el mismo encendido del módem. En campo sigue 0.6.0.

Qué pasó en el banco del 30-sep con 0.6.2

• V5, «el 4G no enciende». A los 144 s del primer arranque, todavía sin cargar, el 24 V se fue 9 s y la etapa siguió con el boost sacando 3.52 V del paquete. Ahí se apagó el módem: sus ráfagas dejaron de verse en el riel (sag5 de ~90 mV a 24 mV). Al volver el 24 V no hubo reset, porque la regla de 0.5.9 pide 10 s de respaldo o más (suponía el paquete cargado), y el módem quedó oscuro hasta que alguien apretó reset. Después del reset el módem volvió, pero el paquete no cargó: CARGA ON, pulso de rearranque y 27 min con el LTC4040 en «casi lleno» (C/8) con el paquete en 3.60 V. En un segundo corte de 24 V, con el paquete en 3.52 V, el módem se volvió a caer en batería. No es una regresión de 0.6.2: el encendido del módem no cambió.
• V4, telemetría a medias. La V4 mandaba bien sus dos líneas (phlg_aire subía cada 30 s, aire_max 89–91). Lo que faltaba en el monitor (fuente, uptime, fase del gobernador) es justo lo que trae la $PHCG: el servidor no estaba corriendo el retranslator.py con $PHCG. Eso se arregla en el servidor, no en el firmware.

Qué cambia

• Reset al volver el 24 V también tras un respaldo corto con el paquete bajo. Si el respaldo duró 1 s o más y la media de 200 ms del paquete bajó de 3.70 V, al volver el 24 V el MCU se resetea, igual que tras 10 s. El umbral queda entre los dos puntos del banco: la V5 a 3.52 V perdió el módem y la V4 a 3.91 V no. Es la media y no una muestra porque cada ráfaga LTE en batería hunde la lectura 0.1–0.2 V unos milisegundos. Antes del reset, $PHEV PWR_RETURN_RESET con la razón sale hacia el módem; llega al servidor solo si el módem seguía vivo (si no, el motivo llega igual en el BOOT siguiente).
• El motivo del reset llega al servidor. Queda guardado en el MCU (registros de respaldo del reloj: sobreviven al reset, no a un corte de energía) y sale en el $PHEV BOOT siguiente como prev=paquete_bajo, respaldo_largo, etapa_apagada, operador (tecla R)…, con n=.
• Si la carga tumba la fuente, la carga espera más. Si el 24 V se fue menos de 10 s después de arrancar la carga, el motivo lleva +carga y el arranque siguiente espera 4, 8, 16 y hasta 30 min para cargar en vez de 2. Sin esto, el reset borraba la espera del gobernador y la unidad se resetearía cada ~2.5 min. Vuelve a 2 min tras 5 min cargando de verdad.
• Aviso cuando el cargador no carga un paquete bajo: CHG_NOCHG. La carga está permitida, el pulso de rearranque ya se probó y el LTC4040 sigue diciendo «casi lleno» con el paquete bajo 3.80 V. No es el gobernador: la flotación del LTC4040 está fijada más baja que el paquete (JP2/JP3/JP4; JP2 en 2-3 = LiFePO4, 3.45–3.60 V; este firmware espera Li-ion de 4.00 V: F2 = 1, F1 = 0, F0 = 1) o el paquete está mal. En consola sale CARGA permitida pero el LTC4040 NO carga … y al servidor CHG_NOCHG, una vez (otra solo después de una carga real); STAT ltc=C8_BAJO mientras dure.
• Corte de 3.40 V en batería con la media de 200 ms. Con 0.6.2 una sola muestra dentro de una ráfaga podía apagar la etapa de un paquete a ~3.5 V.
• Vigilancia del módem sin falsas alarmas (solo diagnóstico). «Oscuro» tras 4 ventanas de 30 s seguidas con el riel plano (menos de 30 mV, en 24 V y en batería) y sin correcciones RTCM de menos de 2 min; «vivo» con 50 mV o más, o con RTCM reciente; entre medio no cambia. No cuentan las ventanas con un corte o una vuelta del 24 V, ni las que tienen un arranque o un corte de la corriente de carga. Con 0.6.2, H0008 alternaba MODEM_DARK / MODEM_BACK toda la noche, el corte y la vuelta del 24 V daban un «vivo» falso y el módem caído de la V5 en batería (15–18 mV) seguía «vivo».
• Para separar «la unidad no manda» de «el servidor no muestra»: STAT phcg_aire= cuenta las $PHCG enviadas (junto a phlg_aire), y la tecla t muestra además aire> …, las dos líneas exactas que salen hacia el módem, con su largo. Si las dos cuentas suben cada 30 s y el monitor no muestra fuente, uptime ni gobernador, avisa a ingeniería: es el servidor.
• Autopruebas nuevas: RTC_BKP (el MCU puede guardar el motivo del reset) y TMP102 contra el SHT40 (FALLA si difieren más de 15 °C).

Qué se ve en la consola

Línea	Qué significa
EVT … 5 V de vuelta (paquete_bajo vbat_min=3.47 dur=5s): reset del MCU …	Volvió el 24 V tras un respaldo con el paquete bajo: reset para que el módem arranque. Otras razones: respaldo dur=… (10 s o más), etapa_apagada, etapa_encendida_en_bateria; con +carga si la carga tumbó la fuente
EVT … RESET anterior: paquete_bajo (n=0)	Al arrancar: por qué fue el reset anterior
EVT … CARGA: el reset anterior fue porque la carga tumbo el 5 V (n=2 seguidos): espera de carga 480 s, no 120 s	Espera de carga alargada
EVT … CARGA permitida pero el LTC4040 NO carga: CHRG y FAULT en alto (= C/8, casi lleno) con el paquete a 3.60 V …	CHG_NOCHG: revisar JP2/JP3/JP4 y el paquete
STAT … ltc=C8_BAJO …	Lo mismo, mientras dure
STAT … phlg_aire=21 phcg_aire=21 aire_max=91	Líneas enviadas por el módem; las dos cuentas suben juntas, 1 cada 30 s
aire> $PHLG,0.6.3,RUN,… (92)	Tecla t: la línea exacta que va al módem y su largo

Al servidor ($PHEV): PWR_RETURN_RESET,<razón> (si el módem seguía vivo), BOOT,reset=SOFT fw=0.6.3 prev=<razón>[+carga] n=N y CHG_NOCHG,vbat=… flot=4.00 c8.

Cómo probarla

1. Servidor: una unidad con 0.6.2 o 0.6.3 debe verse en el monitor con fuente, uptime y fase del gobernador. Si no, avisa a ingeniería antes de seguir.
2. Flashea prueba/hbox-tarjetaV4_0.6.3.bin (V4) o prueba/hbox-v5-bringup_0.6.3.bin (V5) y verifica el SHA-256. Consola: hbox-v5-bringup 0.6.3 built …; en las autopruebas, RTC_BKP PASS y, en la V5, TMP102 PASS.
3. Corte corto con el paquete bajo (bajo 3.7 V en reposo): etapa ON en 24 V; quita el 24 V ~5 s y vuelve a ponerlo. Debe salir 5 V de vuelta (paquete_bajo …): reset del MCU, la etapa a los ~4–7 s del arranque (hasta 4 s esperando la consola USB) y MODEM_RST 5 s después, y el módem registra. La unidad vuelve a reportar en el monitor. Si el corte cae menos de 10 s después de CARGA ON o del pulso de rearranque, sale paquete_bajo+carga … n=1 y la carga espera 4 min: es lo esperado.
4. Corte corto con el paquete cargado (3.9 V o más): el mismo corte de 5 s no resetea: no sale 5 V de vuelta (…) ni RESET por software, y el up= de STAT sigue contando. El módem sigue vivo. (BACKUP fin … SOSTUVO la etapa sale en los dos casos.)
5. Cargador: tras CARGA ON debe verse ltc=CARGANDO. Si en vez de eso, ~2 min después, sale CARGA permitida pero el LTC4040 NO carga y ltc=C8_BAJO, apaga la tarjeta y revisa JP2/JP3/JP4 y el paquete. Después, la prueba del gobernador: módem en batería §1.
6. Tecla t: dos líneas aire>, de 100 caracteres o menos cada una.

Anota todo en el acta de la prueba y manda el log de la consola a ingeniería.

Hallazgos de hardware (V5 del banco, 30-sep)

• El paquete en 3.60 V que el LTC4040 da por lleno: revisar JP2/JP3/JP4 con la tarjeta sin energía, y el paquete.
• El TMP102 (U4, temperatura del paquete) leía 29–30 °C. Justo al volver el 24 V pasó a 0 °C, siguió en 0–2.4 °C unos 17 min (también después del reset) y volvió a ~32 °C. El código que lo lee no cambió. Revisar U4 y el bus I²C de esa tarjeta; la autoprueba nueva lo marca si pasa al arrancar.

Archivo	Tarjeta	Tamaño	SHA-256
prueba/hbox-v5-bringup_0.6.3.bin	V5 / V5.5 (no V5.6)	99 640 B	3641159a4c68ef093a0e5ab3402356254a8165b2ce1b77d8ad2362415b0d7edd
prueba/hbox-tarjetaV4_0.6.3.bin	V4	99 152 B	a6c3b4677fa696bb08b99abae70d464c8593aad8be0d3f3883815d3769e0d281

Compilados con arduino-cli 1.3.1 y STM32duino 3.0.0. Detalle técnico: CHANGELOG.md del firmware, sección 0.6.3. Simulador en PC: 54 escenarios y 273 comprobaciones, todas bien; contra 0.6.2 reproduce el caso del banco (sin reset tras 5 s de respaldo con el paquete bajo). La V5.6 no corre 0.6.x: necesita 0.7.0 (el módem no enciende sin MODEM_EN).

0.6.2: telemetría en dos líneas cortas (prueba de banco 30-sep)

Publicada el 30-sep solo para prueba de banco y sustituida el 1-oct por 0.6.3, que lleva todo lo de esta sección sin cambios; sus binarios están en superseded/. El gobernador es el de 0.6.1 sin cambios (sección siguiente); lo que cambia es cómo viaja la telemetría:

• Consola USB (y Ethernet del build -eth): el $PHLG vuelve a los 29 campos de 0.6.0, idéntico, y detrás sale una línea nueva, $PHCG.
• En banda (por el módem): el $PHLG va con los campos 1–24 y, en el hueco siguiente, $PHCG,<up_s>,<pwr>,<v5min>,<vbat_min>,<bkp_n>,<cgov>,<cwait>,<csheds>,<cduty>,<cchg_s>,<cdrop>,<vdda>: los campos 25–36 de 0.6.1, mismos valores. Las dos líneas quedan en 100 caracteres o menos aunque la unidad lleve meses encendida (el $PHLG de 29 campos crece con el tiempo encendida). En esa copia nmea_age_ms se topa en 99999.
• Cada línea del MCU sale sola: solo se mete cuando la línea hacia el módem lleva más de 8 ms sin nada que mandar. Así da igual si el módem corta por línea o por ráfaga.
• Servidor primero: el retranslator.py con $PHCG (htracker, 30-sep) une las dos líneas en la salud de la unidad; el monitor y la base no cambian. Con el servidor viejo, una unidad 0.6.2 sale sin fuente VEH/BATT, sin uptime y sin gobernador.
• Tecla X, prueba de largo de línea (con Modo B activo; X otra vez la cancela): 105 líneas $PHTST de largo exacto (100 a 140 caracteres, líneas de control de 60 y 6 pares pegados), una cada 500 ms, ~50 s, entre $PHEV PHTST ini y fin. Unos 15 s después de PRUEBA DE LARGO fin: 105 lineas, baja el historial crudo de la unidad en el monitor (⬇ Historial crudo) y pásalo por phtst_report.py: python3 phtst_report.py H0027.txt. Dice el límite por línea, si el módem corta por línea o por ráfaga, y si recorta las líneas en vez de descartarlas.
• STAT aire_max=: la línea más larga que el MCU metió en banda desde el arranque (sin contar las de prueba); debe quedar en 100 o menos.
• Banner: la línea del cargador ya no sale cortada. Ayuda: MODEM_RST 5 s después de STACK ON (así desde 0.5.8).

Cómo probar la telemetría (con 0.6.3)

1. Servidor desplegado con $PHCG.
2. Flashea 0.6.3 (arriba). Consola: cada 10 s $PHLG,0.6.3,… y $PHCG,….
3. Monitor: la unidad con ⚡ VEHÍCULO, su uptime y las fases del gobernador (espera de arranque → comprobando riel → 🔌 CARGANDO). En el historial crudo, cada 30 s un $PHLG de 24 campos y su $PHCG.
4. Tecla X y phtst_report.py (arriba). Manda el resultado a ingeniería.
5. La prueba del cargador: módem en batería §1.

Archivo	Tarjeta	Tamaño	SHA-256
superseded/hbox-v5-bringup_0.6.2.bin	V5.5 (no V5.6)	96 180 B	3a183fccfbff32bc7f686ff5c68d959b783c910c2ae6b668e9ea069f90f76ebf
superseded/hbox-tarjetaV4_0.6.2.bin	V4	95 692 B	ec7425ace7a43d36238ecf9536c82d06b6f9b5304aad49748031ebe35b5167af

Compilados del commit d090cbf del repositorio de firmware (arduino-cli 1.3.1, STM32duino 3.0.0). Detalle técnico: CHANGELOG.md del firmware, sección 0.6.2. Simulador en PC: 24 escenarios y 130 comprobaciones, todas bien; incluye 30 días encendida, la tecla X y apagar la etapa con eventos en cola.

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). 0.6.2 y 0.6.3 llevan 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
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 (R58 1.5 kΩ; antes de T43, R50) 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.3 (módem en batería §1, 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	V5.5 (no V5.6)	93 584 B	6fbbc583ac2415a742ed062c1208d4a807e61085eb2615d76e4c6da400961ad2
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 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.

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, 0.6.2, 0.6.3 (-eth en los builds de banco con Ethernet). Desde 0.6.2 detrás de cada $PHLG sale una $PHCG. 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 y lo recupera con un reset al volver el 24 V (desde 0.6.3 también tras un respaldo corto con el paquete bajo).
• La vigilancia del módem todavía no actúa: sus umbrales se fijan con la prueba en batería §2.
• Lazo y eco de RS-485 / RS-232: queda para un build posterior. 0.6.1–0.6.3 salieron como arreglos del cargador, la telemetría y la recuperación del módem, y solo comprueban que el SC16IS752 responde.
• El largo máximo de línea que deja pasar el módem: lo mide la tecla X (0.6.2 y 0.6.3) en el banco.
• El umbral de 3.70 V del paquete (reset tras un respaldo corto) sale de dos puntos del banco; se confirma con cortes de 5 s a varios voltajes del paquete.
• V5.6: R68 10 mΩ y R58 1.5 kΩ (~1.3 A de carga; antes de T43, 22-oct, RS1 y R50). 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.
1.2	2026-09-30	0.6.2 en prueba de banco: telemetría en $PHLG corto + $PHCG, tecla X y cómo probarla; binarios en prueba/.
1.3	2026-10-01	0.6.3 en prueba de banco: reset tras un respaldo corto con el paquete bajo, motivo del reset al servidor, CHG_NOCHG, cómo probarla, hallazgos de la V5 del banco; 0.6.2 a superseded/; 0.6.x no sirve en la V5.6.
1.4	2026-10-22	Designadores T43 (22-oct): la V5.6 ya se nombra con R68 y R58 (antes RS1 y R50).