FOTA por 4G: factibilidad por tarjeta (D-22-6) + lote

backend/lotes/2026-10-22_fota-4g.json

@@ -0,0 +1,66 @@
+{
+  "lote": "2026-10-22_fota-4g",
+  "autor": "claude",
+  "motivo": "Factibilidad de actualizar el firmware por 4G (FOTA): sí en V5.6/V5.7 y v6 sin tocar cobre; no en V3/V4/V5.5. Propuesta D-22-6 y piezas F0 a F4",
+  "fuente": "/hardware/fota-4g-factibilidad/",
+  "cambios": [
+    { "crear": { "id": "d-22-6-fota",
+                 "titulo": "D-22-6: FOTA por 4G — la imagen de fábrica de las 108/322 y de las 130 v6 lleva bootloader A/B y receptor; V3/V4/V5.5 siguen por USB",
+                 "pista": "ingenieria", "estado": "por-hacer", "responsable": "leo",
+                 "version_tarjeta": "V5.6", "fecha_limite": "2026-10-24",
+                 "descripcion": "Propuesta de Claude (22-oct). V5.6/V5.7: bajada por la toma RTCM (PC7) con marcos propios inyectados en el caster de Helgen, subida por $PHLG. v6: HTTPS por el A7670SA dentro de FW-3. Sin cambios de cobre. Una unidad que sale de fábrica sin bootloader solo se actualiza con visita. Contestar también las 4 preguntas abiertas (§9).",
+                 "enlaces": [{ "titulo": "Factibilidad FOTA por 4G", "url": "/hardware/fota-4g-factibilidad/" }],
+                 "etiquetas": ["decisión"] },
+      "si_no_hay": ["D-22-6", "FOTA"] },
+
+    { "crear": { "id": "t-fota-f0-banco",
+                 "titulo": "FOTA 0: pruebas rápidas de banco (marco 4xxx hasta DOUT, RTK con carrusel, $$$AS+R? por Modo B, RXM-RTCM con tipos desconocidos)",
+                 "pista": "ingenieria", "estado": "por-hacer", "responsable": "jesus, claude",
+                 "version_tarjeta": "V5.6", "fecha_limite": "2026-10-30",
+                 "descripcion": "Medio día. Las pruebas a y d se pueden hacer con una V4 o V5.5 de banco y un USB-serie en el pin 2 del XBee; b y c con una V5.6 del piloto. Criterios de paso en §10 del documento.",
+                 "enlaces": [{ "titulo": "Pruebas F0", "url": "/hardware/fota-4g-factibilidad/#10-pruebas-rapidas-de-banco-f0" }],
+                 "etiquetas": ["firmware", "fota"] } },
+
+    { "crear": { "id": "t-fota-f1-bootloader",
+                 "titulo": "FOTA 1: bootloader A/B firmado, mapa de flash e imagen de fábrica (V5.6/V5.7; sirve a la v6)",
+                 "pista": "ingenieria", "estado": "por-hacer", "responsable": "claude",
+                 "version_tarjeta": "V5.6", "fecha_limite": "2026-11-06",
+                 "descripcion": "Sectores 0–1 bootloader, 2 metadatos, 3 EEPROM, 4–5 ranura A, 6–7 ranura B. SHA-256 + Ed25519, tarjeta en el manifiesto, prueba con contador en BKP12R–13R, dos builds por versión (build.flash_offset). Imagen de fábrica única por DFU. 4–5 días.",
+                 "enlaces": [{ "titulo": "Mapa de flash", "url": "/hardware/fota-4g-factibilidad/#5-bootloader-y-mapa-de-flash-v56-v57-y-v6" }],
+                 "etiquetas": ["firmware", "fota"],
+                 "bloqueada_por": ["d-22-6-fota"] } },
+
+    { "crear": { "id": "t-fota-f2-receptor",
+                 "titulo": "FOTA 2: receptor por la toma RTCM (PC7), estado en $PHLG y confirmación del servidor — V5.6/V5.7",
+                 "pista": "ingenieria", "estado": "por-hacer", "responsable": "claude",
+                 "version_tarjeta": "V5.6", "fecha_limite": "2026-11-13",
+                 "descripcion": "USART6 por DMA circular, marcos 4xxx con CRC-24Q, pedazos a la ranura B (borrado al inicio, K1 suelto), campos nuevos al final de $PHLG, CONFIRMAR por UID y regreso a los 30 min o a los 3 reinicios. 4–5 días.",
+                 "enlaces": [{ "titulo": "V5.6/V5.7 por el caster", "url": "/hardware/fota-4g-factibilidad/#3-v56-v57-fota-a-traves-del-caster" }],
+                 "etiquetas": ["firmware", "fota"],
+                 "bloqueada_por": ["t-fota-f1-bootloader"] } },
+
+    { "crear": { "id": "t-fota-f3-servidor",
+                 "titulo": "FOTA 3: caster de Helgen con inyección por unidad + campañas en htracker y vista en el monitor",
+                 "pista": "ingenieria", "estado": "por-hacer", "responsable": "gibranlp, claude",
+                 "fecha_limite": "2026-11-13",
+                 "descripcion": "Inyector aparte del relevo de correcciones (si falla, las correcciones siguen), carrusel limitado a 1 KB/s, solo a las conexiones objetivo; campañas por etapas (banco → 1 por sitio → 10 % → todas) leyendo los campos nuevos de $PHLG. Depende de qué software corre hoy el caster (pregunta 1 de D-22-6). 5–7 días.",
+                 "enlaces": [{ "titulo": "Carrusel y números", "url": "/hardware/fota-4g-factibilidad/#32-carrusel-y-numeros" }],
+                 "etiquetas": ["software", "fota"],
+                 "bloqueada_por": ["d-22-6-fota"] } },
+
+    { "crear": { "id": "t-fota-f4-matriz",
+                 "titulo": "FOTA 4: matriz de banco (corte en cada fase, imagen corrupta, tarjeta equivocada, imagen que no arranca, imagen que tumba el enlace, en batería, RTK con carrusel)",
+                 "pista": "ingenieria", "estado": "por-hacer", "responsable": "jesus, claude",
+                 "version_tarjeta": "V5.6", "fecha_limite": "2026-11-20",
+                 "descripcion": "Compuerta de D-22-6: sin esta matriz aprobada no se graba la imagen de fábrica de las 108/322. 3–4 días.",
+                 "enlaces": [{ "titulo": "Riesgos", "url": "/hardware/fota-4g-factibilidad/#8-riesgos-y-mitigaciones" }],
+                 "etiquetas": ["firmware", "fota"],
+                 "bloqueada_por": ["t-fota-f2-receptor", "t-fota-f3-servidor"] } },
+
+    { "id": "t-fw-070",
+      "nota": "FOTA no entra en 0.7.0 para no moverlo del 29-oct. Va después en FOTA 1–4; lo que sí importa es que la imagen de fábrica de las 108/322 ya lleve bootloader y receptor (D-22-6)." },
+
+    { "id": "t-v6-cierre-pedido",
+      "nota": "FW-3 (NTRIP por AT) debe traer FOTA por HTTPS y el mismo bootloader desde su primera imagen, con el socket NTRIP en modo no transparente para dejar libre el canal AT. Sin K1, el regreso a la imagen anterior lo hace el bootloader solo." }
+  ]
+}

docs/bitacora.md

@@ -23,6 +23,7 @@ Arriba, lo que pasó en el tablero de pendientes y en las actas en los últimos
 ### Octubre de 2026
 
 **22 oct**
+:   [FOTA por 4G: factibilidad por tarjeta](hardware/fota-4g-factibilidad.md): **sí en V5.6/V5.7** (bajada por la toma RTCM en PC7 con marcos propios que inyecta el caster de Helgen, subida por `$PHLG`) **y en la v6** (HTTPS por el A7670SA, dentro de FW-3), **sin tocar cobre**; **no en V3, V4 ni V5.5** (el MCU no recibe nada del módem: siguen por USB). Lo que decide el costo es la imagen de fábrica: propuesta **D-22-6** (bootloader A/B firmado y receptor en las 108/322 y las 130 v6) y piezas FOTA 0 a 4, ≈ 3 semanas.
 :   [Instalaciones por sitio](tableros/instalaciones.md): tablero nuevo, una tarjeta por unidad con **en qué vehículo está** (número económico, tipo, 12/24 V), sus actas y su etapa: enviada → recibida → instalada → **probada en sitio** → en operación, más «con falla». Acta nueva [Prueba en sitio](formularios/prueba-sitio.html): solo con ella aprobada una unidad cuenta para la meta de 1–2 por sitio.
 :   [Estado de la v6, rev. 1.3: T40, MH4 libre](hardware/v6-estado-21oct.md#7-t40-22-oct-tarde-mh4-libre): D23 y D24 fuera del barreno, `/SIM_CLK` por In1, `/SIM_RST` por arriba de D25 y `/NTC` alrededor del barreno; las tres TVS de la SIM y los pines 92/94 de U19 con vía de GND propia. DRC: **11 errores** (los encimes de margen), 0 sin conectar. Leo decide D-22-4: las TVS siguen del lado del módem y Claude recomienda pasarlas junto a J14. Falta el push de T40; lote `2026-10-22_t40-v6`.
 :   [Plan de fines de semana de la v6, rev. 1.5](hardware/v6-plan-fines-de-semana.md#34-barrenos-mh4-y-mh6-1-h): MH4 ya quedó; de los barrenos solo queda D-22-4.

docs/hardware/fota-4g-factibilidad.md

@@ -0,0 +1,231 @@
+---
+title: "FOTA por 4G: qué hace falta y en qué tarjetas se puede"
+date: 2026-10-22
+---
+
+# FOTA por 4G — actualizar el firmware por el módem, tarjeta por tarjeta
+
+**22-oct-2026 · Claude, a pedido de Leo · v1.0.** Pregunta: ¿qué hace falta para mandar actualizaciones de
+firmware por el módem 4G, y se puede en todas las versiones de la tarjeta?
+
+Fuentes revisadas: `board_v4.h`, `board_v5.h`, `board_v56.h` y `hbox_v5_bringup.ino` (firmware 0.6.3),
+[mapa de pines de la v6](v6-pinmap.md), el diagnóstico del 4G NTRIP Master del 8-oct (protocolo de su
+herramienta de carga), los binarios publicados (0.6.2 = 96 180 bytes) y el manual AT de la serie A76XX de SIMCom.
+
+## 0. Veredicto
+
+| Tarjeta | Unidades | ¿FOTA por 4G? | Por qué | Qué falta |
+|---|---|---|---|---|
+| <span class="badge-v3">V3</span> (Blackpill en zócalo) | 3 en campo | **No** | El MCU no recibe nada del módem: la salida del 4G NTRIP Master (DOUT) va solo al RX2 del F9P. El Blackpill (48 pines) ni siquiera tiene PC7. | Seguir por USB en visita, o reemplazar |
+| <span class="badge-v4">V4</span> (Blackpill en zócalo) | 15 | **No** | Igual que la V3. | Igual |
+| <span class="badge-v55">V5.5</span> | 15 | **No** | PC7 está sin conectar (`board_v5.h`: «PC6..PC9 NC»); la toma RTCM llegó con la V5.6 (ECO del 27-sep). Tampoco controla el módem (solo SW4G1 o 24 V lo reviven). | Igual |
+| <span class="badge-v56">V5.6</span> / <span class="badge-v57">V5.7</span> | 108 + 322 (más el piloto de 5 + 5) | **Sí, sin tocar cobre** | **Bajada:** `PIN_RTCM_TAP` PC7 = USART6_RX ← R111 1 k ← DOUT_4G, a 115200. **Subida:** Modo B (PA9 → K1 NO → DIN_4G), por donde ya viaja `$PHLG`. Control del módem: MODEM_EN PC3, MODEM_RST PC1. Respaldo LTC4040 para escribir flash. | Firmware (bootloader + receptor) y servidor (caster con inyección + campañas) |
+| <span class="badge-v6">v6</span> | 130 + reemplazos | **Sí, la más limpia** | El MCU es dueño del A7670SA (PC6 → R148 0 Ω → RXD; PC7 ← TXD; K1 DNP): descarga por HTTPS con los comandos AT del propio módem. | Va dentro de FW-3 (NTRIP por AT), que todavía no existe |
+
+**Lo que decide el costo es la imagen que se graba en fábrica.** Una unidad que sale de Querétaro sin
+bootloader y sin receptor solo se actualiza después con una visita y un cable USB, aunque su hardware pueda.
+Por eso la propuesta **D-22-6** (§9): la imagen de fábrica de las 108 / 322 y de las 130 v6 lleva el bootloader
+A/B y el receptor desde el primer día. Los pilotos (5 + 5 y los 20 de la v6) no lo necesitan: se regraban por
+USB en el banco.
+
+## 1. Qué hace falta para actualizar por aire (cualquier tarjeta)
+
+1. **Camino de bajada hasta el MCU** — que los bytes que manda el servidor lleguen a un RX del STM32.
+2. **Camino de subida** — que la unidad diga qué versión tiene, qué pedazos le faltan y si la imagen nueva
+   arrancó bien. Sin esto el servidor manda a ciegas.
+3. **Lugar en flash + bootloader** — dos ranuras: corre una y se escribe la otra; el bootloader elige cuál
+   arranca y regresa a la anterior si la nueva falla.
+4. **Imagen firmada** — la imagen pasa por el caster y por internet; sin firma, quien pueda meter bytes en el
+   flujo puede regrabar la flota completa.
+5. **Energía y recuperación** — un corte a media escritura no debe dejar la unidad muerta (con dos ranuras no
+   pasa: se escribe la que no corre), y siempre queda el DFU por USB en J11, que vive en la memoria de sistema
+   del STM32 y no se puede borrar. **En el peor caso una unidad requiere visita; nunca queda inservible.**
+
+El STM32F411 (RET6 en V5.x y v6, CEU6 en el Blackpill) tiene 512 KB de flash y el firmware 0.6.2 pesa 96 KB:
+caben dos ranuras con margen aunque el 0.7.x crezca (Ethernet, SC16IS752, ciclo de respaldo).
+
+## 2. Lo que tiene cada tarjeta
+
+| | V3 / V4 | V5.5 | V5.6 / V5.7 | v6 |
+|---|---|---|---|---|
+| Módem | 4G NTRIP Master (Telit + app de ArduSimple) | igual | igual | A7670SA soldado |
+| Bajada hacia el MCU | ✗ | ✗ (PC7 sin conectar) | ✓ PC7 toma RTCM, 115200 | ✓ PC7 USART6_RX |
+| Subida desde el MCU | Modo B (PA9 → K1) | Modo B | Modo B | PC6 directo (R148) |
+| Control del módem | ✗ | ✗ | MODEM_EN PC3 · MODEM_RST PC1 · MODEM_LED PC2 | MODEM_PWR_EN PC10 · RST PC11 · PWRKEY PC8 · STATUS PC9 |
+| Si el MCU se muere | K1 NC: NMEA y RTCM siguen pasando | igual | igual | **Nada reporta** (K1 DNP, decisión B-13) |
+| Flash | 512 KB | 512 KB | 512 KB | 512 KB |
+
+## 3. V5.6 / V5.7: FOTA a través del caster
+
+### 3.1 La idea
+
+El 4G NTRIP Master es un cliente NTRIP: lo que el caster manda después del encabezado sale por DOUT a 115200
+hacia el RX2 del F9P **y** hacia PC7 (por R111). Si el caster es nuestro, puede intercalar entre los mensajes
+de corrección **marcos RTCM 3 propios** (un número de mensaje del rango propietario 4001–4095 que no use nuestra
+base) con pedazos de la imagen:
+
+- El F9P los descarta: es un tipo que no usa, y cada marco lleva su CRC-24Q. Se confirma en banco que el RTK no
+  se mueve (prueba F0-b).
+- El MCU arma los marcos que ve en PC7, se queda con los suyos y escribe cada pedazo en la ranura que no corre.
+- No cambia nada en el módem ni en sus parámetros: mismo caster, mismo mountpoint.
+
+Formato de cada marco (propuesta): `D3 · longitud · tipo 4xxx (12 bits) + subtipo (4 bits) · campaña (2 B) ·
+tarjeta (1 B) · destino (UID del MCU, o 0 = todas) · pedazo n / total · datos ≤ 900 B · CRC-24Q`. El primer marco
+de cada campaña es el **manifiesto**: versión, tarjeta (V5.6 y V5.7 usan el mismo binario), ranura, tamaño,
+SHA-256 y firma Ed25519.
+
+### 3.2 Carrusel y números
+
+- La línea DOUT da 11.5 KB/s (115200 8N1) y las correcciones ocupan una fracción. Con el carrusel limitado a
+  **1 KB/s**, 100 KB pasan en **≈ 2 min por vuelta**.
+- Una unidad que se conecta a medio carrusel completa lo que le falta en la vuelta siguiente; los pedazos que se
+  pierden (el loop del MCU bloqueado unos segundos, una reconexión LTE) se recuperan igual. Para no depender del
+  loop, el receptor lee USART6 por DMA circular.
+- Datos por unidad y campaña: ≈ 0.1–0.3 MB (la imagen de 1 a 3 veces). Si el caster inyecta solo en las
+  conexiones de las unidades objetivo, el resto de la flota no gasta nada. Para eso conviene **un usuario NTRIP
+  por unidad** (`AS+U`), que además dice quién está conectado.
+
+### 3.3 Subida y confirmación
+
+- `$PHLG` gana campos al final (regla de solo agregar): ranura activa, versión, campaña, pedazos
+  `tengo/total` y estado (`bajando · lista · prueba · confirmada · regresó`).
+- La imagen nueva arranca **en prueba**. El servidor la confirma con un marco `CONFIRMAR` dirigido al UID cuando
+  ve la unidad sana N minutos: NMEA a 1 Hz, `$PHLG` con la versión nueva y RTK ≥ 4 si la unidad lo tenía antes.
+  Sin confirmación en 30 min, o con 3 reinicios seguidos, el bootloader regresa a la ranura anterior.
+- En V5.x, si la imagen nueva se cuelga, el IWDG (16 s) reinicia y K1 cae a NC: **la unidad sigue reportando
+  posición** mientras tanto (invariante 2).
+
+### 3.4 Escribir la flash sin perder posiciones
+
+Borrar un sector de 128 KB detiene al núcleo ≈ 1–2 s (el F411 tiene un solo banco). El firmware ya suelta K1
+antes de escribir flash (`relayDisengage("flash_write")`), así que la NMEA sigue directo por K1 NC y solo se pausa
+`$PHLG`. La ranura B son dos sectores de 128 KB: se borran al empezar la campaña, no a media descarga. No se
+escribe flash en batería baja (mismo umbral del gobernador de carga).
+
+### 3.5 Lo que sale de regalo con el mismo camino
+
+- **Parámetros del 4G NTRIP Master a distancia.** El MCU puede mandar `$$$AS+X=…` por el Modo B: la app los acepta
+  mientras corre y contesta `$GPTXT,… STORED AS` por DOUT → PC7 (prueba F0-c). Cambiar caster, mountpoint o APN
+  sin visita, **con regreso automático** a los valores anteriores si no llegan correcciones a PC7 en N minutos
+  (con MODEM_RST para aplicarlos). El archivo real de parámetros sigue sin ir al repo ni al sitio.
+- **Configuración del F9P a distancia.** El MCU habla con el UART1 del F9P (PA2/PA3): `UBX-CFG-VALSET` en RAM,
+  BBR y flash. Cierra la clase de fallas «configuración solo en RAM» del 20-jun.
+- **Comandos:** reiniciar el módem, ciclar la etapa, pedir un volcado de diagnóstico.
+
+## 4. v6: FOTA por HTTPS con el A7670SA
+
+- Sin 4G NTRIP Master, el MCU maneja el módem por AT: `AT+HTTPINIT` / `AT+HTTPPARA` / `AT+HTTPACTION`, y luego
+  `AT+HTTPREAD` por pedazos directo a la ranura B, o `AT+HTTPREADFILE` al sistema de archivos del módem y
+  `AT+CFTRANTX` / `AT+FSREAD` (manual A76XX, cap. 12, 13 y 16). TLS con `AT+CSSLCFG` y el certificado cargado
+  con `AT+CCERTDOWN`. El tamaño libre del sistema de archivos se revisa con `AT+FSMEM` en el banco.
+- 100 KB por el UART a 115200 son ≈ 10 s más el protocolo AT; el enlace LTE no es el cuello de botella.
+- Con FW-3 como está planeado (el MCU entrega el RTCM al F9P por USART2), el canal AT queda libre para HTTP
+  mientras corre NTRIP **si el socket NTRIP se lee en modo no transparente** (lectura manual del socket). Eso se
+  decide al escribir FW-3, no después.
+- El firmware del propio A7670SA también se actualiza por aire (`AT+CFOTA`, paquetes delta de SIMCom). No es
+  urgente.
+- **Sin K1, si el MCU de la v6 se muere nada reporta.** Por eso en la v6 el regreso a la imagen anterior lo
+  decide el bootloader solo (contador de arranques + IWDG), sin esperar al servidor, y lo primero que hace la
+  app nueva es levantar el enlace.
+- El manifiesto firmado lleva la tarjeta: el bootloader rechaza un binario de V5.6 en una v6 y al revés. Eso
+  cubre el riesgo de D-08 (un build de V5.6 pone PC3 en alto contra el RTK_STAT del F9P) mejor que un strap.
+
+## 5. Bootloader y mapa de flash (V5.6, V5.7 y v6)
+
+| Sectores | Dirección | Tamaño | Uso |
+|---|---|---|---|
+| 0–1 | `0x0800 0000` | 32 KB | Bootloader (nunca se actualiza por aire) |
+| 2 | `0x0800 8000` | 16 KB | Metadatos: ranura activa, estado de prueba, versión, hash (dos copias alternadas) |
+| 3 | `0x0800 C000` | 16 KB | EEPROM emulada (hoy vive en el último sector; se mueve aquí) |
+| 4–5 | `0x0801 0000` | 192 KB | Ranura A |
+| 6–7 | `0x0804 0000` | 256 KB | Ranura B |
+
+- **Dos builds por versión**, uno por ranura. STM32duino acepta un desplazamiento de flash (`build.flash_offset`
+  → `LD_FLASH_OFFSET` y `VECT_TAB_OFFSET`); se confirma con un build de prueba en la Mac. El servidor manda el de
+  la ranura que no corre (la unidad la reporta en `$PHLG`). No se copia ni se intercambia nada: cambiar de imagen
+  es escribir un registro de metadatos, y regresar es inmediato.
+- **Bootloader mínimo:** deja los pines en estado seguro (PB5 bajo = K1 NC, etapa apagada: invariante 1),
+  verifica SHA-256 + Ed25519 (Monocypher), cuenta los arranques en prueba en BKP12R–BKP13R (libres: el firmware
+  usa BKP16–19 y el núcleo BKP1, BKP4 y BKP10), refresca el IWDG mientras verifica y salta.
+- La app nunca escribe por debajo de su ranura (guardia en el código). La protección por *option bytes* (WRP) de
+  los sectores 0–1 se evalúa después del piloto: complica el regrabado por DFU de los técnicos.
+- BOR del STM32 en nivel 2 o 3 (*option bytes*) para no escribir flash con voltaje bajo; revisar el valor actual.
+- **Imagen de fábrica:** un solo `.bin` (bootloader + ranura A + metadatos) que se graba por DFU en J11 igual que
+  hoy, con la tarjeta en el nombre (por ejemplo `hbox-v56-fabrica_0.7.x.bin`). Un `.bin` 0.6.x viejo grabado en
+  `0x0800 0000` borra el bootloader: **en V5.6, V5.7 y v6 solo se graban imágenes de fábrica**.
+- **La llave privada de firma no va al repo ni al servidor** (invariante 6): la guarda Leo; el servidor solo
+  tiene imágenes ya firmadas.
+
+## 6. V3 / V4 / V5.5: por qué no y qué hacer
+
+El MCU de estas tarjetas no tiene ningún RX conectado a la salida del módem. Opciones, de más a menos recomendada:
+
+1. **Seguir por USB en cada visita**, como hoy. Son 33 unidades.
+2. **Reemplazarlas por V5.6 / V5.7** conforme lleguen, si van a seguir en servicio después del primer trimestre.
+3. **Experimento (30 min de banco, prueba F0-d): canal lateral por el F9P.** Con `UBX-RXM-RTCM` activado en su
+   UART1, el F9P le reporta al MCU (PA3) el **tipo** de cada marco RTCM que recibe; hasta donde sé lo hace también
+   con tipos que no soporta (por confirmar). Un servidor que manda marcos mínimos de 64 tipos distintos deletrea
+   6 bits por marco: a ≈ 100 marcos/s son ≈ 75 B/s, o sea 100 KB en ≈ 25 min más reenvíos. Sirve para comandos y
+   quizá para FOTA lenta, pero igual pide **una visita** para grabar bootloader y receptor, y hay que probar que
+   el RTK no sufre. Solo vale la pena si V4 / V5.5 se quedan mucho tiempo en campo.
+4. **Cable en la V5.5** (DOUT_4G → 1 k → PC7, pin 38 del LQFP64 a 0.5 mm): posible en banco, **no recomendado**
+   para equipo en puerto (vibración).
+
+## 7. Lo que no se actualiza por aire en ninguna tarjeta
+
+- El firmware del **ZED-F9P** (herramienta de u-blox por USB o UART, en sitio; en la v6, por el puente de J11).
+- La app del **4G NTRIP Master** (`m2mapz.bin`, 643 KB): no cabe en el MCU y el módulo queda fuera de línea
+  mientras se carga (`AT#M2MWRITE` en su ventana de arranque). Sus **parámetros** sí se pueden cambiar (§3.5).
+- El **bootloader**, por diseño.
+
+## 8. Riesgos y mitigaciones
+
+| Riesgo | Mitigación |
+|---|---|
+| Imagen mala a toda la flota | Campañas por etapas: 1 unidad de banco → 1 por sitio → 10 % → todas; confirmación del servidor; regreso automático |
+| Imagen que arranca pero tumba el enlace | Confirmación de extremo a extremo (el servidor ve la versión nueva reportando); sin ella, regreso a los 30 min |
+| Alguien inyecta una imagen | Firma Ed25519; la llave privada fuera del servidor |
+| Binario de otra tarjeta | Tarjeta dentro del manifiesto firmado; el bootloader lo rechaza |
+| Se cae el caster propio | Ya es punto único de las correcciones; el inyector va aparte del relevo, así que si el inyector falla las correcciones siguen |
+| El carrusel estorba al RTK | Límite de 1 KB/s, marcos completos entre mensajes de la base; prueba F0-b |
+| Corte de energía a media campaña | Se escribe la ranura que no corre; la descarga se reanuda por pedazos |
+| El borrado de flash detiene el núcleo | K1 suelto durante el borrado (ya es regla del firmware); borrado al inicio de la campaña |
+| Datos de la SIM | 0.1–0.3 MB por unidad y campaña, solo a las unidades objetivo |
+| Un técnico graba un `.bin` viejo | En V5.6+ solo imágenes de fábrica, con la tarjeta en el nombre |
+
+## 9. Esfuerzo, orden y decisión
+
+| Pieza | Quién | Estimado |
+|---|---|---|
+| F0 — pruebas rápidas de banco (§10) | Jesús + Claude | ½ día |
+| F1 — bootloader, mapa de flash, firma e imagen de fábrica | Claude | 4–5 días |
+| F2 — receptor V5.6 / V5.7 (PC7, ranura B, `$PHLG`, confirmación y regreso) | Claude | 4–5 días |
+| F3 — caster con inyección por unidad + campañas en htracker + vista en el monitor | Gibran + Claude | 5–7 días |
+| F4 — matriz de banco (corte en cada fase, imagen corrupta, tarjeta equivocada, imagen que no arranca, imagen que tumba el enlace, en batería, RTK con carrusel) | Jesús + Claude | 3–4 días |
+| F5 — v6: HTTPS dentro de FW-3 | Claude | 2–3 días sobre FW-3 |
+
+Son ≈ 3 semanas de calendario con dos personas en paralelo. **No entra en el 0.7.0** (vence el 29-oct) para no
+moverlo. Sí alcanza para las 108 / 322: tienen NO-GO hasta que el piloto pase el banco, esperan el pago, y su
+imagen de fábrica se graba al ensamblar.
+
+**D-22-6 (propuesta; decide Leo).** (1) La imagen de fábrica de las 108 V5.6, las 322 V5.7 y las 130 v6 lleva
+bootloader A/B firmado y receptor FOTA, y no se graban sin que F4 pase en banco. (2) En V5.6/V5.7 el transporte
+es el caster de Helgen con inyección; en la v6, HTTPS dentro de FW-3. (3) V3, V4 y V5.5 se quedan con
+actualización por USB en visita; el experimento F0-d decide si vale la pena más.
+
+**Preguntas abiertas para Leo:**
+
+1. ¿Qué software corre hoy el caster de HelgenSRV? Si es nuestro, se le agrega el inyector; si es de terceros, se
+   pone un relevo propio enfrente (base → relevo → unidades).
+2. ¿Un usuario NTRIP por unidad (para inyectar solo a quien toca y saber quién está conectado)?
+3. ¿Quién guarda la llave de firma y dónde?
+4. ¿Cuánto tiempo siguen en campo las V4 y V5.5?
+
+## 10. Pruebas rápidas de banco (F0)
+
+| | Prueba | Pasa si |
+|---|---|---|
+| a | Caster de prueba en HelgenSRV (otro mountpoint) que intercala un marco 4xxx propio cada segundo; unidad de banco apuntada a él | El marco sale íntegro por DOUT (USB-serie en el pin 2 del XBee de cualquier V4/V5.5 de banco, o PC7 en una V5.6 del piloto) |
+| b | Carrusel a 1 KB/s durante 30 min con cielo abierto | Fix 4 sostenido; `UBX-RXM-RTCM` sin fallas de CRC en los mensajes de la base |
+| c | `$$$AS+R?` mandado por el Modo B (MCU → K1 → DIN) | La respuesta de la app aparece en DOUT |
+| d | Marcos de tipos que el F9P no soporta, con `UBX-RXM-RTCM` activado en UART1 | El F9P los reporta (decide el experimento de §6) |

docs/hardware/index.md

@@ -15,6 +15,9 @@ Estado de cada versión de la EinarBoard al **22-oct-2026**, con sus documentos
 
     [**▶ Auditoría final (veredicto, hallazgos, riesgos)**](auditoria-final-22oct.md) · [PDF completo, 33 pp.](2026-10-22_Drogheda_Auditoria-Final-Produccion_V5.6-V5.7_ES_v1.0.pdf) · [presentación, 19 láminas](2026-10-22_Drogheda_Auditoria-Final-Produccion_V5.6-V5.7_Presentacion_ES_v1.0.pdf) · [protocolo](auditoria-final-protocolo.md). Antes: [auditoría del 21-oct (pasadas 4 a 6)](v56-v57-auditoria-21oct.md) · [re-auditoría del 19-oct](re-auditoria-19oct.md) · [qué es crítico en la V5.6](v56-clasificacion-19oct.md) · [plan v6 (rev. 1.5)](v6-plan-fines-de-semana.md).
 
+!!! info "22-oct: FOTA por 4G — sí en V5.6/V5.7 y v6 sin tocar cobre; no en V3, V4 ni V5.5"
+    La V5.6/V5.7 ya tiene bajada (toma RTCM en PC7) y subida (Modo B); la v6 maneja su módem por AT. Falta firmware y servidor (≈ 3 semanas) y que la **imagen de fábrica** de las 108/322 y de las 130 v6 lleve bootloader A/B y receptor (propuesta D-22-6). [Factibilidad por tarjeta](fota-4g-factibilidad.md).
+
 | Tarjeta | Estado | Pedido | Proyecto KiCad | Firmware |
 |---|---|---|---|---|
 | <span class="badge-v55">V5.5</span> | En campo (15 pzas, 22-ago). No se fabrica más. | — | `hbox-watchdog-v5` (tag `v5.5-as-fabbed`) | `hbox-v5-bringup_0.6.0` CAMPO · 0.6.3 banco |

docs/tableros/ingenieria.md

@@ -37,6 +37,7 @@ hide:
   <h2>Últimas decisiones</h2>
   <p class="sub">Lo decidido manda hasta que otra decisión con fecha posterior lo cambie. Fuente: notas del proyecto; detalle en la sección de hardware.</p>
   <ul class="decisiones">
+    <li><b>22-oct (16:30)</b> — <b>FOTA por 4G: factibilidad por tarjeta</b> (D-22-6, <b>propuesta de Claude; decide Leo</b>). Sí en V5.6/V5.7 sin tocar cobre: bajada por la toma RTCM (PC7) con marcos RTCM 3 propios que inyecta el caster de Helgen, subida por <code>$PHLG</code>, la imagen nueva queda en prueba hasta que el servidor la confirma y si no, regresa sola. Sí en la v6 por HTTPS con el A7670SA, dentro de FW-3. No en V3, V4 ni V5.5 (el MCU no recibe nada del módem): siguen por USB en visita. Propuesta: la imagen de fábrica de las 108/322 y de las 130 v6 lleva bootloader A/B firmado y receptor, y no se graba sin la matriz de banco (FOTA 4). FOTA no entra en el 0.7.0. <a href="/hardware/fota-4g-factibilidad/">Documento</a>.</li>
     <li><b>22-oct (14:30)</b> — <b>Instalaciones por sitio y prueba en sitio</b> (D-22-5; Leo: hay 3 o 4 unidades instaladas sin saber en qué vehículo, y metas de instalación sin prueba). Una unidad cuenta para la meta de 1–2 por sitio <b>solo con el acta «Prueba en sitio» aprobada</b>: fix RTK 4 (o 5 explicado) en el monitor, reporte en el monitor y en Wialon, posición coherente, respaldo en batería si aplica y fotos. Pasa a «en operación» 7 días después de la prueba si no se registra una falla (los 7 días los propone Claude; se cambian en <code>backend/instalaciones.py</code>). El acta de instalación registra el vehículo: número económico, tipo (RTG, Reach Stacker, Empty Handler, Tractoplana, Montacargas…) y 12/24 V. <a href="/tableros/instalaciones/">Instalaciones</a> · <a href="/formularios/prueba-sitio.html">Prueba en sitio</a></li>
     <li><b>22-oct (14:10)</b> — <b>v6: T40, MH4 libre</b> (Claude). D23 quedó debajo de U19.31 y D24 junto a R129/R133. <code>/SIM_CLK</code> va por In1, <code>/SIM_RST</code> por arriba de D25 y <code>/NTC</code> alrededor del barreno; antes lo cruzaba por In2. Las tres TVS de la SIM tienen vía de GND propia. Los pines 92 y 94 de U19 también, porque el canal de <code>/SIM_RST</code> los dejaba sin relleno. DRC: <b>11 errores</b>, los encimes de margen; 0 sin conectar.
       <b>D-22-4 (decide Leo):</b> las TVS siguen del lado del módem, a 27–41 mm de pista del zócalo. Claude recomienda (b): pasarlas a <code>/SIMB_*</code>, pegadas a J14 y cada una con su vía de GND. Son las mismas piezas; lo hace T41 o Michelle el sábado. Falta el push de Leo. <a href="/hardware/v6-estado-21oct/#7-t40-22-oct-tarde-mh4-libre">T40</a> · <a href="/hardware/v6-estado-21oct/#72-las-tvs-de-la-sim-se-quedan-del-lado-del-modem-d-22-4">D-22-4</a></li>

docs/tableros/juntas.md

@@ -17,7 +17,9 @@ no queda en el chat ni en la memoria de alguien: termina como pendientes, con re
 
 ## Cómo funciona
 
-1. **Se graba.** Leo graba la junta con Gemini (notas y transcripción).
+1. **Se graba, en español.** Leo graba la junta con Gemini (notas y transcripción). Antes de empezar, en Meet:
+   *Tomar notas por mí* → *Configuración* → *Idioma de la reunión: Español*. Se pone en cada junta (no se guarda para
+   las siguientes). Si se queda en inglés, lo que se dice en español se pierde: pasó en la junta del 22-oct.
 2. **Claude la lee.** Leo le pasa la transcripción o las notas a Claude.
 3. **Claude escribe un lote.** Un archivo con los cambios al tablero: pendientes nuevos, los que se cierran, los que se
    mueven, cada uno con su sitio, responsable, fecha y una nota que dice qué se acordó.
@@ -31,7 +33,7 @@ Si en la junta alguien mueve un pendiente a mano, mejor: el lote no lo vuelve a
 | # | Tema | Pregunta | Dónde se ve |
 |---|---|---|---|
 | 1 | **Semáforo** | ¿Sigue en rojo? ¿Qué lo cambia? | Inicio → semáforo |
-| 2 | **Por sitio** | ICAVE · TIMSA · EIT · LCT · Querétaro: ¿qué avanzó, qué está bloqueado? Meta: 1–2 unidades instaladas por sitio | [Pendientes](pendientes.md) → filtro por sitio o vista **Por sitio** |
+| 2 | **Por sitio** | ICAVE · TIMSA · EIT · LCT · Querétaro: ¿qué avanzó, qué está bloqueado? Meta: 1–2 unidades instaladas y probadas por sitio | [Pendientes](pendientes.md) → filtro por sitio o vista **Por sitio** |
 | 3 | **Bloqueos** | ¿Quién destraba cada bloqueado y para cuándo? | Columna **Bloqueado** |
 | 4 | **Quick wins** | ¿Qué se puede cerrar esta semana sin dinero ni material nuevo? | Etiqueta `quick-win` |
 | 5 | **Acuerdos** | Cada acuerdo con responsable y fecha | El lote de la junta |
@@ -59,3 +61,4 @@ Si en la junta alguien mueve un pendiente a mano, mejor: el lote no lo vuelve a
 | Fecha | Junta | Lote | Acuerdos |
 |---|---|---|---|
 | 22-oct | Arranque del modo crisis | `2026-10-22_crisis` | Semáforo rojo; tablero por sitio; meta 1–2 unidades por sitio |
+| 22-oct, 14:00 | Junta de instalación urgente (13 invitados, 1 h 47 min) | por escribir | Gemini la transcribió en inglés y se perdió casi todo lo dicho en español; los acuerdos se confirman con Leo. [Notas en español](https://docs.google.com/document/d/1YZ5dw7Lru0s8HoCK44LbsGkDF0X5PFuk4LtmgAzkcGg/edit) |

mkdocs.yml

@@ -155,6 +155,7 @@ nav:
           - hardware/index.md
           - Manuales por tarjeta: manuales/index.md
           - Auditorías y pasadas:
+              - 22 oct · FOTA por 4G: hardware/fota-4g-factibilidad.md
               - 22 oct · Auditoría final V5.6/V5.7: hardware/auditoria-final-22oct.md
               - 22 oct · Protocolo auditoría final: hardware/auditoria-final-protocolo.md
               - 22 oct · Estado v6 (T25–T40): hardware/v6-estado-21oct.md

scripts/sync-docs.sh

@@ -155,6 +155,8 @@ declare -a MAP=(
   "03-Architecture-Hardware/img/2026-10-22_Drogheda_Autonomia-Ciclo_v1.0.png|docs/hardware/img/2026-10-22_Drogheda_Autonomia-Ciclo_v1.0.png"
   "03-Architecture-Hardware/img/2026-10-22_Drogheda_Matriz-Riesgo_v1.0.png|docs/hardware/img/2026-10-22_Drogheda_Matriz-Riesgo_v1.0.png"
   "03-Architecture-Hardware/img/2026-10-22_Drogheda_V5.7-Fuente-U25_v1.0.png|docs/hardware/img/2026-10-22_Drogheda_V5.7-Fuente-U25_v1.0.png"
+  # 2026-10-22 (tarde): FOTA por 4G — factibilidad por tarjeta (D-22-6)
+  "02-Architecture-Software/2026-10-22_Drogheda_FOTA-por-4G_Factibilidad_ES_v1.0.md|docs/hardware/fota-4g-factibilidad.md"
 )
 
 n=0