23 KiB
| title | tags | date | project | author | version | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Notas de versión — firmware V4 / V5 |
|
2026-09-29 | Project Drogheda | Helgen Technologies | 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.
!!! 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é) | 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 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). 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_Venboard_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 BATTy 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, enSTAT 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 cgovFase del gobernador: HOLDOFFPROVINGWAITONSHEDCOOLDOWNBATTNOTRUNPWRCYCINIT, oHOT(celda caliente),OP(vetado conC),OFF(compilado sin cargador)31 cwaitSegundos hasta que pueda arrancar la carga, contando los 30 s de prueba del riel (0 = carga permitida, −1 = nada programado) 32 cshedsCortes 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_sSegundos cargando desde el arranque 35 cdropmV que bajó el riel en el último arranque de la carga (−1 = sin medir) 36 vddaReferencia 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_ENvolvió 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íaNOTRUN). La pausa por NTC (CHRG y FAULT bajos a la vez) ya no se cuenta como carga. Evento nuevoCHG_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-ethrepetía el DHCP entero en cada intento: 4–5 s bloqueado cada 5 s, con el cargador puesto.0.6.1-ethhace 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 (R50 1.5 kΩ) y el margen es mucho mayor.
Cómo se probó y qué falta
- Simulador en PC (
tools/hostsim_v5del 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, autopruebar, 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, 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 (V5.6 solo con paquete Li-ion) | 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 mueveCHRG_ENdespué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_ENrearma su temporizador de seguridad (máximo uno cada 30 min).
- Consola:
STAT … carga=FASE … pin= ltc= cortes=; eventosCHG_ON,CHG_SHED,CHG_OFF,CHG_HOT,CHG_COOL,CHG_PULSEyCHRG_ON/CHRG_IDLE; teclaC= veto del operador. $PHLGsin cambios (29 campos).PHLG_FWpasa a0.6.0(sin «-fm»: ya no es el «field-minimum» sin cargador). El campo 22 (chg) sigue siendo elCHRG_STATreal del LTC4040.-DENABLE_CHARGE=0compila 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.
STATañadertcm_age= sta= rtcm_last= sag5= sagb= flat= modem=vivo|SOSPECHOSO|?; eventosMODEM_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)».
$PHLGde 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
=====, salehbox-v5-bringup 0.6.1 built …y en la línea siguienteboard=EinarBoard v5 (HBOX v5)ov4. $PHLG, campo 1:0.5.9-fm,0.6.0,0.6.1(-ethen los builds de banco con Ethernet). Ojo:0.6.0-ethsalió 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.
- 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:
RS110 mΩ yR501.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. |