Leopoldo Rodríguez
fdc916c6e9
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01QCy5VHMVLkAmftYM6swWmx
144 lines
11 KiB
Markdown
144 lines
11 KiB
Markdown
---
|
||
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
|
||
|
||
!!! warning "Designadores de antes del 22-oct (T43)"
|
||
Este documento conserva los designadores que tenía la tarjeta en su fecha. Desde el 22-oct (T43) la V5.6, la V5.7 y la v6 traen otros, y varios nombres viejos ahora son otra pieza: en la V5.6 y la V5.7 el LTC4040 es ahora U14 (antes U6) y J7 es el USB-C de DFU (antes J11). Para leerlo contra la tarjeta de hoy, usa la [tabla viejo → nuevo](designadores-t43-22oct.md#8-tablas-viejo-nuevo); lo que ya no existía el 22-oct no está en la tabla.
|
||
|
||
> **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).
|
||
4. E (firmware y `board_v56.h`). 5. F (matriz y veredicto). 6. Figuras. 7. LaTeX + Beamer. 8. Cierre.
|