hbox-docs/docs/hardware/auditoria-final-protocolo.md

title: "Protocolo de la auditoría final de producción — EinarBoard V5.6 y V5.7 (22-oct-2026)" tags: [project-drogheda, hardware, hbox, einarboard, v5.6, v5.7, auditoria, produccion, protocolo, gerber, firmware] project: Project Drogheda author: Helgen Technologies (auditoría: Claude; decide: Leo) date: 2026-10-22 version: 1.0 status: ACTIVO — es el «reprompt» que Leo pidió antes de empezar; la auditoría misma es el PDF Auditoria-Final-V56-V57/ audience: Leo (decide el pedido), Michelle, Jesús, Aldair, Adriana

Protocolo de la auditoría final de producción — V5.6 y V5.7 · 22-oct-2026

Para qué existe este documento. Leo pidió (22-oct, 10:01): «antes de hacer nada, vuélvete a dar la instrucción y documenta este proceso de auditoría como el último paso antes de producción». Esto es esa instrucción, escrita para que la auditoría sea una sola, completa y decisiva, y para que la próxima tarjeta (v6) se audite igual. Es el paso 7 de la Ruta a producción: entre «Gerber» y «Piloto».

0. El mandato, en las palabras de Leo

1. Meta de V5.6 y V5.7: que todos los puertos funcionen.
2. V5.7 no usa la Mean Well (SD-15B): fuente de 9–32 V a bordo.
3. Ethernet, RS-485 y RS-232 deben ser usables si se les conectan señales.
4. El módem 4G no debe provocar un apagón (brownout), sobre todo en batería.
5. En batería: apagarse o entrar en un modo de muy bajo consumo 10 minutos, despertar, mandar un par de reportes, y volver a dormir. Todo tiene que funcionar como debe.
6. Los Gerber, BOM y archivos de fabricación ya están en kicad/production/HBOX_v5_Rev6_PROD y HBOX_v5_Rev7_PROD.
7. Empezar el firmware: tiene que quedar «spot on».
8. Esta auditoría se hace una vez (las otras sesiones dicen «casi listo»; se dejaron pasar detalles por falta de espacio en la tarjeta): resaltar riesgos y victorias fáciles (easy wins), con una tabla de problema → arreglo, imágenes y explicaciones.
9. Entregables: documento en español, formato Helgen, LaTeX + presentación Beamer; resaltar los algoritmos de las tarjetas; evaluación de riesgos con matriz; solo V5.6 y V5.7.
10. Las tarjetas se piden hoy: la auditoría termina en una decisión GO / NO-GO por tarjeta.

1. Rol y postura

• Actúo como auditor independiente con el sombrero de diseñador de electrónica y de dispositivos de geolocalización: reviso lo que está en los archivos, no lo que los documentos anteriores dicen que está.
• Socio objetivo, no complaciente: si algo no está listo, se dice; si un riesgo se acepta, se dice por qué y con qué mitigación. «Casi listo» no es un veredicto.
• Cada hallazgo cita archivo, red, pin o coordenada y trae un arreglo concreto, clasificado como bloqueante (no se pide hoy), alto (se pide con mitigación y se mide en el piloto), medio, bajo o easy win (barato, sin mover piezas: BOM, un valor, firmware o un paso del pedido).
• No se mueve ninguna pieza ni se toca HBox_PCB en esta auditoría. Si un arreglo pide cambiar los archivos, queda escrito con sus coordenadas y Leo decide si va antes del pedido o a la siguiente revisión.

2. Insumos (los archivos tal como están en la Mac, 22-oct 10:00)

Insumo	Archivo	SHA-256 (8)
V5.6 PCB (el de los Gerber)	kicad/hbox-watchdog-v5.kicad_pcb	f07ad5b5
V5.6 esquemático	kicad/hbox-watchdog-v5.kicad_sch	dc9381d7
V5.6 proyecto / reglas	kicad/hbox-watchdog-v5.kicad_pro · .kicad_dru	f6721eb7 · 8e4d3a7b
V5.7 PCB (el de los Gerber)	kicad/hbox-watchdog-v57.kicad_pcb	9373ebe8
V5.7 esquemático	kicad/hbox-watchdog-v57.kicad_sch	e0e6caf6
V5.7 proyecto / reglas	kicad/hbox-watchdog-v57.kicad_pro · .kicad_dru	d36d5139 · 8e4d3a7b
Paquete V5.6	production/HBOX_v5_Rev6_PROD.zip + _bom.csv + _positions.csv + _designators.csv (22-oct 01:55)	49969628 · 3fbb69f2 · 0904080d
Paquete V5.7	production/HBOX_v5_Rev7_PROD.zip + _bom.csv + _positions.csv + _designators.csv (22-oct 15:55)	fb18a61b · 08e53137 · c6f2c750
Firmware de referencia	04-Source-Code/firmware/hbox_v5_bringup/ 0.6.3 (hbox_v5_bringup.ino, board_v5.h, board_v4.h)	—
Auditorías previas	16-oct (producción), 19-oct (re-auditoría y críticos), 21-oct (pasada 4–6, T32–T37), ECO V5.6 (27-sep), ECO V5.7 (13-oct)	—
Hojas de datos	LTC4040, AP64350, TPS54360B, MP1584, SC16IS752, W5500, SP3485, MAX3232, SC7A20, STM32F411RE, SMBJ33(C)A, IRFR5305	—

Verificado antes de empezar: los dos .kicad_pcb solo difieren de sus respaldos .T35bak / .T37bak en lo que T35 y T37 agregaron (la vía de U7 y la vía de GND de C129): nada se movió después de la pasada 6, y los Gerber se exportaron después del último guardado de cada PCB (V5.6 01:05 → 01:55; V5.7 01:30 → 15:55).

3. Método — qué se revisa y cómo (A a G)

A · Integridad del paquete de fabricación. Regenerar Gerber + taladros desde cada .kicad_pcb con kicad-cli 10.0.4 en copias y comparar capa por capa con lo exportado; juego de capas completo (F/In1/In2/B, máscaras, pasta, serigrafía, contorno, PTH/NPTH); tamaño de tarjeta; mínimos de pista, holgura y barreno contra la capacidad de JLC de 4 capas; pasta del EP de U6 (≤ 50 %) y de U7/U25; serigrafía sobre pads; BOM: toda pieza montada con código LCSC, sin duplicados de valor con dos códigos, DNP realmente fuera; CPL: cuenta de huellas contra el PCB, rotaciones de U6, U7, U25, Q7, RS1, U16 y de todo lo polarizado (JLC gira distinto que KiCad); reglas DFM del 8-oct (vías del EP de U6 «Epoxy Filled & Capped», rayos X).

B · Revisión eléctrica por bloque, sobre el netlist exportado de cada esquemático. Entrada de V5.7 (P1 → F2 → D10/Q10 → U25 → L22/D34 → VEH5V; FB, compensación, soft-start, UVLO, polaridad invertida, 9–32 V); LTC4040 (PFI/PFO, flotación LFP, RNTB, RPROG, límite de entrada con RS1 Kelvin, VSYS/C129, BSTFB, F0–F2); riel del módem (AP64350 desde SYS5V, MODEM_EN con su pull-down, MODEM_RST, MODEM_LED, C130, corriente de ráfaga); etapa RTK (PA1 → Q5 → Q1, SW_5V, pull-up de seguridad); MCU (HSE/LSE, BOOT0/BOOT1, DFU/SWD, NRST, VBAT, ADC de ignición en PA5 con 12 V y 24 V); bus I²C (direcciones, pull-ups, un solo maestro); Ethernet (W5500, reset con pull-down, J10, LEDs, terminación); RS-485 (U14: DE/RE, estado tras reset, TVS, polarización); RS-232 (U15, H4, R1OUT); sensores (SHT40, TMP102); acelerómetro (SC7A20, INT1 → PB9 = EXTI, dirección 0x18); ventilador (JP1, Q2); LEDs y gauge (PCF8574); conectores y ESD (J9/J11, P1–P14, GX16).

C · Apagón del módem y ciclo de 10 minutos en batería. Presupuesto de corriente en respaldo (lo que el LTC4040 puede dar desde el paquete vs lo que piden etapa + módem en ráfaga), capacitancia de SYS5V y 3V3_MODEM, umbrales (PFI 4.40 V, UVLO del AP64350 3.8 V, PSM del módem), piso de sueño (qué consume con todo apagado: U17, K1, LEDs, U12/W5500, transceptores, MCU en STOP), fuentes de despertar (RTC con LSE Y4, INT1 del SC7A20, PFO/VEH5V), rieles que el firmware puede cortar y cuáles no; la secuencia de dormir y despertar, con tiempos, y qué pasa si algo falla a medio ciclo.

D · Cobre final, sobre los archivos exactos de los Gerber. DRC de KiCad con el .kicad_dru, «Rellenar zonas» y «Comprobar paridad» en copias; prueba Kelvin de RS1 (VIN y CLN); vías de corte (cambios de capa de potencia con una sola vía); potencia por capas internas; vías sueltas; lazos de U25, U7 y U6; holguras mínimas de lo que cambió en la pasada 6.

E · Firmware. Leer 0.6.3 y board_v5.h; derivar board_v56.h pin a pin del netlist de V5.6 (y confirmar que V5.7 es idéntica en el MCU); documentar los algoritmos que ya existen (gobernador de carga, ventilador, recuperación de enlace, modo B/K1, telemetría $PHLG/$PHEV, corte térmico, baja batería) y diseñar los que faltan (ciclo de 10 min: STOP + alarma RTC, secuencia del módem sin brownout, reporte y regreso a dormir; SC16IS752 con el RS-485 libre tras el reset; Ethernet de campo; SC7A20; ignición por ADC), con pseudocódigo y máquinas de estados; listar los riesgos de firmware que el piloto tiene que probar.

F · Evaluación de riesgos. Matriz 5 × 5 (probabilidad × impacto) por hallazgo; clase y dueño del arreglo; qué se mide en el piloto de 5 + 5; criterio GO / NO-GO por tarjeta.

G · Entregables y cierre. Documento LaTeX (estilo Helgen, XeLaTeX) con tabla de hallazgos, figuras anotadas y matriz; presentación Beamer (helgen-beamer); board_v56.h; este protocolo; y el cierre en el centro de mando (lote, docs, Ruta, decisiones, índice maestro, copia al Project).

4. Criterio de decisión

Veredicto	Significa	Condición
GO	Se pide hoy el piloto de 5 (y las 108 / 322 después del banco).	Ningún hallazgo bloqueante; los altos tienen mitigación escrita y prueba en el piloto.
GO con cambios de paquete	Se pide hoy, pero después de corregir BOM/CPL/opciones del pedido (sin tocar cobre).	Los bloqueantes están todos en BOM, CPL u opciones del pedido.
NO-GO	No se pide hasta corregir el cobre.	Hay un hallazgo bloqueante en cobre (corto, red abierta, pieza fuera de capacidad de fábrica, riesgo de daño).

Bloqueante = algo que, fabricado así, deja una función del mandato (§0) sin poder cumplirse ni con firmware, o daña la tarjeta. Alto = compromete el mandato en condiciones de campo (calor, batería baja, ráfaga LTE) pero se puede mitigar con firmware, BOM o un paso del pedido, y se mide en el piloto.

5. Reglas durante la auditoría

• Todo en copias; HBox_PCB no se toca. kicad-cli solo sobre copias.
• Cada afirmación numérica sale de un archivo (netlist, PCB, Gerber, datasheet) y se cita.
• Español mexicano para todo lo que lee el equipo; sin secretos (el archivo de parámetros 4G/NTRIP no se cita).
• Lo que ya estaba cerrado el 21-oct se vuelve a comprobar, no se da por hecho.
• Si aparece algo que solo se puede confirmar en el banco, se escribe como prueba del piloto con criterio de aceptación, no como suposición.
• Termina con el bloque «Centro de mando» para Leo.

6. Orden de trabajo (hoy)

1. Este protocolo → Leo (listo). 2. A + D (paquete y cobre, con kicad-cli). 3. B + C (eléctrica y batería).
2. E (firmware y board_v56.h). 5. F (matriz y veredicto). 6. Figuras. 7. LaTeX + Beamer. 8. Cierre.