Prueba de banco — módem 4G en modo batería (fw 0.5.7 → 0.6.0)

!!! danger "Noche 26/27-sep con 0.5.8: módem oscuro al amanecer (vbat 3.50 V, F9P vivo, LEDs de carga apagados)" 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 y, sin GGA durante el silencio del ahorro, «RTK perdido 15 min» disparó un ciclo de etapa en batería (buscar RECOVERY / rec=1 en la captura, o $PHEV RECOVERY en el servidor). 0.5.8 queda retirada; 0.5.9 no cicla nunca en batería, resetea al volver el 5 V tras ≥ 10 s de respaldo, corre continuo (sin ahorro) y añade la vigilancia del módem.

!!! success "0.6.0 — prueba del cargador (antes de la corrida de batería, misma unidad, paquete bajo)" 1. 24 V + etapa ON, consola abierta. En los primeros 120 s STAT dice carga=HOLDOFF; luego carga=PROVING n/30s y a los ~150 s EVT CARGA ON: riel 5.xx V estable 30 s. En el siguiente STAT: ltc=CARGANDO; en el monitor la unidad muestra 🔌 CARGANDO. 2. Multímetro en P2 (riel del vehículo) 10 min: anotar mínimo visto. Si el riel cae bajo 4.90 V durante una ráfaga LTE, la consola dice CARGA cortada … enfriamiento 60 s y carga=COOLDOWN faltan Ns; luego reintenta. Anotar cortes= al cabo de 1 h y el vbat inicial y final (debe subir). Enfriamientos que llegan a 30 min = la fuente no aguanta 2.4 A + etapa → V5.6 o fuente de 4 A. 3. Quitar 24 V: carga=BATT, CARGA OFF: BATT (nunca carga en batería). Volver 24 V: reset (0.5.9), y a los ~150 s vuelve a cargar.

!!! success "Prueba de aceptación y calibración de 0.5.9 (misma unidad, consola abierta) — vale igual para 0.6.0" 1. 24 V + ignición, módem registrado, RTK fix. 5 min. Anotar de 3–4 STAT: sag5= (nivel «vivo en 24 V»), rtcm_age= (pocos s), sta=. 2. Quitar 24 V. 20 min. Anotar de 3–4 STAT: sagb= (nivel «vivo en batería»); modem=vivo; el módem sigue con LEDs; no debe aparecer ninguna línea RECOVERY; el monitor sigue viendo la unidad con pwr=BATT. 3. Matar el módem a propósito (en batería): P (etapa OFF) y luego P + Y (etapa ON desde batería) → F9P vivo, módem oscuro. 3 min: rtcm=none, sagb cae al piso, flat sube y a las 4 ventanas EVT MODEM SOSPECHOSO + $PHEV MODEM_DARK. Anotar sagb de esas ventanas. 4. Volver los 24 V: 5 V de vuelta … reset del MCU, reinicio, etapa ON a los ~3 s, módem enciende; tras 2 min modem=vivo. 5. Noche completa en batería desde 24 V (sin tocar nada). En la mañana: módem vivo antes de volver los 24 V, y STAT/monitor con la hora de corte 3.40 V si llegó (SLEEP) → autonomía real.

Con los `sag5`/`sagb` de 1–3 se fijan `MODEM_SAG5_V` / `MODEM_SAGB_V` para 0.5.10 (auto-reset en 24 V; reset condicional al volver el 5 V).

!!! success "Resultado 26-sep: hipótesis A confirmada — y cerrada (procedimiento de 0.5.8, retirado)" Con 0.5.7 en batería ningún encendido de etapa arrancó el módem (P, despertar, reset por R/P10); con 24 V todos; y SW4G1 con la etapa ya encendida sí. Es el riel del boost (4.6 V en SW_IN) hundido por la ráfaga de arranque del módem: el buck de 3V3_MODEM (mínimo 4.5 V) cae y el PMIC del módem aborta sin reintentar. No tiene arreglo por firmware en V5.5/V4. Por eso 0.5.8 CAMPO no apaga el módem en batería (respaldo continuo con ahorro: ráfaga de posición cada 10 min, $PHLG cada 3 min). Prueba de aceptación de 0.5.8 (misma unidad, consola abierta, acta):

1. 24 V + ignición: etapa ON a los ~3 s, módem registra, `MODOB ON` (clic de K1 ~13 s), el monitor ve la unidad con fix.
2. Quitar 24 V (dejar la batería): `V5 PERDIDO` → `BACKUP inicio` → `AHORRO en bateria`. **El módem sigue con sus LEDs encendidos.**
   A los ~8 s: `AHORRO: rafaga #1 enviada … silencio 592 s`. En el monitor: badge de batería «~10 min», sin alarma.
3. Esperar 10 min: `AHORRO: rafaga #2` y la posición llega al monitor (el módem seguía registrado; no hubo encendido nuevo).
   Entre ráfagas, a los 3 y 6 min, un `$PHLG` (el monitor sigue viendo salud). Anotar `vbat` de cada `STAT`.
4. Volver los 24 V con el módem vivo: `V5 PRESENTE` → `BACKUP fin` → `AHORRO fin`. **Sin reset** (la etapa venía encendida desde 24 V).
5. Caso reset: con 24 V quitados, pulsar P10 (o `R`): la etapa **no** se reenciende en batería (por diseño). Volver los 24 V:
   reset del MCU (`5 V de vuelta con etapa apagada`) y a los ~4 s arranca todo, módem incluido.
6. Soak opcional hasta el corte de 3.40 V (`SLEEP`): anotar la hora de inicio y de corte → autonomía real (estimada 30–35 h).

Lo que sigue abajo es el procedimiento original de 0.5.7 (diagnóstico); se conserva por trazabilidad.

Versión: 1.0 · 26-sep-2026 · Para: laboratorio QRO · Dura: ~45 min por unidad · Registro: ▶ acta de esta prueba — trae las tres tablas para llenar en el teléfono o la laptop, y ahí se adjunta la captura de consola.

!!! warning "¿Es una tarjeta V4? Usa su procedimiento y su acta" En la V4 el USB de la Blackpill está unido al riel de 5 V de la tarjeta: con un cable normal la laptop alimenta la tarjeta y la prueba en batería no vale. Para una V4 sigue V4 — preparación y prueba con 0.5.6 (puente, interruptores del simpleRTK2B, cable de consola sin 5 V) y regístrala en el acta de prueba V4.

Qué se está buscando

Con 24 V la unidad funciona bien: módem registrado, LEDs UART del simpleRTK2B en parpadeo rápido (correcciones RTCM entrando + NMEA saliendo), se oye el clic de K1 a los ~13 s y el monitor la ve.

En batería (0.5.3: ventana de 2 min cada 10 min) la unidad enciende la etapa, pero el módem nunca llega a transmitir: los LEDs UART del simpleRTK2B parpadean lento, ~1 por segundo (solo la GGA saliendo, sin correcciones) y el servidor no recibe nada. Se observó que el cambio ocurre justo después del clic de K1.

Hay dos explicaciones posibles y esta prueba las separa:

Hipótesis	Qué la delataría
A · El riel se hunde. En batería el módem cuelga del boost del LTC4040 (~4.79 V en MAIN5V), no de los 5.2–5.4 V del SD-15B. La ráfaga de registro LTE (~2 A) hunde el riel, el módem se reinicia y nunca termina de registrarse.	MAIN5V o SW_5V caen por debajo de ~4.4 V mientras el módem intenta registrarse; sus LEDs se apagan y reencienden. Falla igual con Modo B bloqueado.
B · El camino por K1. Con K1 conmutado (Modo B) la GGA llega al módem a través del MCU; si en batería esa ruta no entrega bien, el módem no manda GGA al caster y no recibe correcciones.	Con Modo B bloqueado (tecla `B`) el módem sí registra y aparecen las correcciones (parpadeo rápido). Los rieles se mantienen.

!!! note "El firmware no ve el riel de la batería" v5/v5min de la consola y del $PHLG miden el 5 V del vehículo (P2), no el riel del boost. En batería leen ~0 y no dicen nada. Por eso hay que medir con el multímetro: la prueba no vale sin las lecturas.

Material

La unidad completa (tarjeta V5 o V4 con 0.5.3, simpleRTK2B, módem 4G con SIM, batería conectada), antenas GNSS y LTE conectadas, antena GNSS con cielo (aunque sea ventana).
Fuente de 24 V al GX16 (o al P2 según cómo esté armada la unidad). Un interruptor o simplemente desconectar.
Laptop con terminal serie en el USB del HBOX (115200, CR+LF) grabando a archivo toda la sesión.
Multímetros (dos, o uno y paciencia) en tres puntos: MAIN5V (U6 pin 1 / C32 — o P11 pin 1, que es lo mismo), SW_5V (MOD1 pin 5 / C3) y, el que más importa, 3V3_MODEM (zócalo XBee pin 1 = J7 pin 1 / J8 pin 7): es el que alimenta al módem. Negro a GND. Si hay osciloscopio, mejor en 3V3_MODEM con 5 s/div.
El monitor abierto en otra pantalla con la unidad ubicada.
Cronómetro (el del teléfono).

Teclas de consola que se usan: s = STAT ahora · v = puntos de medición · B = Modo B permitido/bloqueado · l = leyenda.

Corrida 0 — referencia con 24 V (5 min)

24 V puesto, consola grabando. Esperar a EVT … STACK ON, luego a MODOB ON (~13 s; se oye el clic).
Anotar en la tabla: patrón de LEDs del módem (describir: cuál LED, color, rápido/lento/fijo), LEDs UART del simpleRTK2B (rápido esperado), MAIN5V y SW_5V (esperado ≈ 5.2–5.4 V y ≈ 5.0 V), y que el monitor muestre la unidad con Salud ($PHLG) y ⚡.
Teclear s y copiar la línea STAT.

Si la corrida 0 no sale limpia, detenerse: el problema no es la batería.

Corrida 1 — batería con Modo B (la falla) (25 min)

Con todo funcionando, quitar los 24 V y arrancar el cronómetro. Consola: V5 PERDIDO → BACKUP inicio … modo reporte cada 10 min. La etapa sigue encendida (esta primera ventana arranca con el módem ya registrado, así que todavía transmite — no es la que interesa).
A los ~2 min: DUTY reposo … etapa OFF. Verificar con el multímetro que SW_5V = 0 V y que el módem se apagó (LEDs apagados). Si el módem sigue encendido con SW_5V = 0, anotar y avisar: algo lo alimenta por otro lado (¿USB conectado al simpleRTK2B o al módem?).
Esperar el despertar: DUTY despertar #1 … etapa ON a los ~10 min del paso 1. Aquí empieza lo importante. Desde ese instante, durante los 2 minutos, registrar cada 15 s en la tabla:
- MAIN5V y SW_5V (el valor más bajo que se vea; los multímetros baratos promedian — anotar el mínimo que alcancen a leer),
- LEDs del módem (¿se apagan y reencienden? ¿llegan a parpadeo lento/fijo de "registrado"?),
- LEDs UART del simpleRTK2B (lento 1/s = sin correcciones · rápido = con correcciones),
- momento del clic de K1 (consola: MODOB ON),
- línea STAT (teclear s a los 30 s y a los 90 s; interesan vbat y vbatmin).
En el monitor: ¿la unidad recibió algo en esa ventana? (fila actualizada, $PHLG con 🔋, o nada).
Dejar que cierre la ventana (DUTY reposo) y no tocar: se necesita una segunda ventana para la corrida 2.

Corrida 2 — batería SIN Modo B (25 min)

Mientras la unidad está en reposo (etapa OFF), teclear B en la consola → debe responder MODO B BLOQUEADO por operador. Ahora al despertar K1 no conmuta: el F9P habla directo con el módem.
Esperar DUTY despertar #2 y repetir exactamente el registro del paso 3 de la corrida 1.
Resultado:
- Si ahora el módem registra y el simpleRTK2B parpadea rápido → hipótesis B (camino por K1). Anotarlo y dejar la unidad así; ingeniería revisa el firmware.
- Si sigue igual que en la corrida 1 → hipótesis A (riel). Seguir a la corrida 3.
Teclear B otra vez para dejar Modo B permitido.

Corrida 3 — solo si la 2 dio "A": ¿es la batería o es el boost? (20 min)

24 V puesto, etapa apagada (P la apaga si está encendida, o simplemente esperar el reposo). Desconectar la batería de su conector y conectar en su lugar una fuente de banco a 3.9 V con límite de 3 A (respetar polaridad; medir antes de conectar).
Repetir la corrida 1 (quitar 24 V, esperar el despertar, registrar los 2 min).
Resultado:
- Funciona con la fuente → el problema es el paquete (resistencia interna alta: celda caliente, vieja o descargada). Anotar el voltaje de la batería en vacío y la temperatura que reporte STAT (tbat).
- Falla igual → el problema es la etapa de boost (LTC4040 / capacitancia en MAIN5V). Es hardware; no cambiar nada, reportar las lecturas.

Corrida 4 — regreso de los 24 V sin reset (5 min)

Observado el 25-sep: con la unidad en batería y el módem oscuro, al volver los 24 V el simpleRTK2B revive pero el módem sigue oscuro hasta un reset de la tarjeta. Medir 3V3_MODEM en ese estado: si marca ~3.3 V con el módem apagado, el módem está en latch por subvoltaje (no rearranca hasta que se le quita la alimentación). La causa (26-sep): con la etapa OFF el MCU seguía sosteniendo el riel del módem por el UART del GNSS (PA2 → simpleRTK2B → DIN_4G), así que el módem nunca veía un power-on reset. 0.5.5 puso ese UART en alta impedancia y cicla la etapa 10 s al volver el 5 V — no bastó: en reposo 3V3_MODEM sigue en ~1 V (C43+, 26-sep), el módem no ve un apagado real y no rearranca.

Lo que sí lo revive (confirmado 26-sep): un pulso en SW4G1 y también un reset del MCU por P10 con 24 V — mientras que un ciclo de etapa desde el firmware (P/P+Y, 5–60 s) nunca lo enciende. Por eso 0.5.7 hace en cada despertar de batería y en cada regreso del 5 V un reset del MCU (arranca en ~4 s, ventana de inmediato).

Corrida 0-bis (antes de la corrida 1): con el módem oscuro en 24 V, tecla R (reset por software). Si el módem enciende igual que con P10 → seguir con las corridas 1 y 4: en cada ventana debe verse el banner de arranque con reset=SOFT y BACKUP tras reset SOFT … ventana AHORA, y el módem encender solo. Si R no lo enciende, el reset por pin hace algo que el reset por software no hace: se pasa al puente.

Respaldo — el puente (0.5.6+, sigue en el firmware): 3 s después de cada encendido de etapa el MCU pulsa el reset del módem por el pin libre P7 de U13 (PCF8574). Eso necesita un puente en la tarjeta:

U13 pin 12 (P7)  ──|<──  SW4G1 pad 1 (MODEM_RST)     diodo Schottky de señal BAT54 (o BAT85/BAT43/1N5711) — no 1N5819
                cátodo   ánodo

Con la etapa ON, teclear M: el multímetro en SW4G1 pad 1 debe caer a < 0.4 V durante 0.5 s y los LEDs del módem apagar y volver. Si no, el puente no está.
Repetir la corrida 1 (batería) y la corrida 4 (regreso de 24 V sin reset): en cada ventana debe verse EVT … MODEM_RST stack_on a los 3 s y el módem registrar solo.
En reposo, anotar además SW_5V en C3(+) (no en Q1) y si el LED POWER del simpleRTK2B está encendido; y confirmar que no hay cable en el USB-C J9 (es el USB del módem: su VBUS llega al módulo). Eso dice quién sostiene el ~1 V.

Registro

Todo se llena en el acta de la prueba: configuración, corrida 0, la tabla de 2 minutos de cada despertar (una por corrida), el resultado A/B y el archivo completo de la consola. Queda en el expediente de la unidad. Si no hay señal en el laboratorio, la misma tabla en papel y se captura después:

t	MAIN5V (mín)	SW_5V (mín)	3V3_MODEM (mín)	LEDs módem	LEDs UART simpleRTK2B	K1	`vbat` / `vbatmin`	¿Servidor recibió?
0:15
0:30
0:45
1:00
1:30
2:00

!!! danger "Lo que NO se hace" No cambiar el firmware, no mover puentes (JP2/JP3/JP4), no tocar el trimmer del SD-15B. La prueba sirve porque la unidad está como en campo. Y nunca conectar la fuente de banco a la batería con la batería puesta.

15 KiB Raw Blame History Unescape Escape