# Prueba de banco — módem 4G en modo batería (fw 0.5.7) **Versión:** 1.0 · 26-sep-2026 · **Para:** laboratorio QRO · **Dura:** ~45 min por unidad · **Registro:** [**▶ acta de esta prueba**](../formularios/prueba-bateria.html) — 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](v4-prueba-fw-0.5.6.md) (puente, interruptores del simpleRTK2B, cable de consola sin 5 V) y regístrala en el [acta de prueba V4](../formularios/v4.html). ## 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) 1. 24 V puesto, consola grabando. Esperar a `EVT … STACK ON`, luego a `MODOB ON` (~13 s; se oye el clic). 2. 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 ⚡. 3. 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) 1. 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). 2. 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?). 3. 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`). 4. En el monitor: ¿la unidad recibió algo en esa ventana? (fila actualizada, `$PHLG` con 🔋, o nada). 5. 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) 1. 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. 2. Esperar `DUTY despertar #2` y repetir **exactamente** el registro del paso 3 de la corrida 1. 3. 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. 4. 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) 1. 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). 2. Repetir la corrida 1 (quitar 24 V, esperar el despertar, registrar los 2 min). 3. 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 ``` 1. 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á. 2. 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. 3. 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](../formularios/prueba-bateria.html)**: 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.