Helgen-Services/hbox-docs
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

hbox-docs: sitio MkDocs Material para tecnicos (ES)

Browse Source 
- contenido curado desde Drogheda via scripts/sync-docs.sh (procedimientos
  de banco, montaje/arneses, diagnostico remoto, guias git)
- scripts/deploy.sh: mkdocs build --strict + rsync al servidor Helgen
- README con setup de nginx + htpasswd para acceso privado de tecnicos

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01YJ4eAB6zjQT49RVwpgfKdt
This commit is contained in:
Leopoldo Rodríguez 2026-09-15 18:23:26 +00:00
commit 01dc30c06a
18 changed files with 1687 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
.gitignore vendored Normal file
View File

@ -0,0 +1,3 @@
site/
.cache/
__pycache__/

81
README.md Normal file
View File

@ -0,0 +1,81 @@
# hbox-docs — sitio de documentación técnica del HBOX
Sitio **MkDocs Material** (español) con el subconjunto de documentación del proyecto
Drogheda que los técnicos necesitan: procedimientos de banco, montaje/arneses,
diagnóstico remoto y la guía Git. Vive como **submódulo de Drogheda**, igual que el
repo de KiCad.
## Flujo de trabajo
```bash
# 1. actualizar el contenido desde Drogheda (la lista curada vive en el script)
./scripts/sync-docs.sh
# 2. ver el sitio en local
pip install mkdocs-material # una sola vez
mkdocs serve # http://127.0.0.1:8000
# 3. commit + push de este repo (y bump del submódulo en Drogheda)
# 4. publicar al servidor
./scripts/deploy.sh # git@git.helgen.online:/var/www/hbox-docs (puerto 222)
```
**Política de publicación:** solo se publica lo que está en la lista de
`scripts/sync-docs.sh`. Nada de finanzas, briefs de diseño ni auditorías EMC; para
agregar un documento al sitio se agrega a esa lista (y con eso queda auditado en git).
## Configuración del servidor (una sola vez)
En el servidor (`git.helgen.online` u otro), como root:
```bash
mkdir -p /var/www/hbox-docs
chown git /var/www/hbox-docs # el usuario con el que hace rsync deploy.sh
# usuarios para los técnicos (HTTP Basic)
apt install -y apache2-utils
htpasswd -c /etc/nginx/hbox-docs.htpasswd luz
htpasswd /etc/nginx/hbox-docs.htpasswd leo
```
Bloque de nginx (por ejemplo `/etc/nginx/sites-available/hbox-docs`, con el certificado
que ya tenga el servidor o uno nuevo de certbot para `docs.helgen.online`):
```nginx
server {
listen 443 ssl;
server_name docs.helgen.online;
# ssl_certificate ... ; # certbot --nginx -d docs.helgen.online
# ssl_certificate_key ... ;
root /var/www/hbox-docs;
index index.html;
auth_basic "Helgen HBOX docs";
auth_basic_user_file /etc/nginx/hbox-docs.htpasswd;
location / {
try_files $uri $uri/ =404;
}
}
```
```bash
ln -s /etc/nginx/sites-available/hbox-docs /etc/nginx/sites-enabled/
nginx -t && systemctl reload nginx
```
Los técnicos entran a `https://docs.helgen.online` con su usuario y contraseña.
Alternativa sin subdominio: servirlo como `location /hbox/` dentro del server block
existente, con el mismo `auth_basic`.
## Estructura
```
mkdocs.yml configuración del sitio (nav, tema, español)
docs/ contenido publicado (generado por sync-docs.sh + index.md)
scripts/sync-docs.sh lista curada Drogheda → docs/
scripts/deploy.sh mkdocs build --strict + rsync al servidor
```

180
docs/diagnostico/protocolo-diagnostico-remoto.md Normal file
View File

@ -0,0 +1,180 @@
# Remote Diagnostic Protocol — Pulled HBOX Units
**Date:** 2026-06-19 · **Owner:** Leo Rodriguez
**Situation:** all HBOX units were **removed from the machines**. We have **4 units
in hand: 3 not working, 1 working-ish.** They are **physically in Veracruz**; the
team is in **Querétaro** → debugging is **remote** until they're shipped or someone
on-site acts as our hands.
**Firmware on these units = v1** (no MCU thermal log) → thermal evidence must come
from **physical inspection + a bench power test**, not from the firmware.
> The single working-ish unit is the **control**. Every measurement below should be
> taken on it too, so "bad" readings on the dead units have a baseline to compare
> against.
---
## 0. Decision gate (make this call first)
**Recommendation: ship all 4 units to Querétaro.** They are small, and remote-
debugging *dead* electronics is slow and rarely conclusive — a 1–2 day courier buys
full bench access (PSU with current limit, scope, u-center, reflash, thermal soak,
teardown). Bring the working-ish unit too; it's the reference.
Choose remote-hands **only if** shipping is blocked (client chain-of-custody, the
units must stay on-site, or courier delay is unacceptable). Confirm with ICAVE who
**owns** the units and whether they may leave the terminal.
| Path | When | Cost |
|---|---|---|
| **Ship to QRO** *(recommended)* | units may leave Veracruz | courier + 1–2 days |
| **Remote-hands in Veracruz** | units must stay; cooperative on-site tech exists | needs the protocol below + their time |
Either way, **start §2 (backend analysis) now from Querétaro** — it needs no units.
---
## 1. What we can / cannot learn remotely
| Question | Remote-hands? | How |
|---|---|---|
| Is the LiPo swollen / burnt / leaking? | ✅ | photo checklist (§3 Tier 0) |
| Connectors/SMA loose, solder cracked? | ✅ | photos + wiggle test |
| Does it draw current / boot on power? | ✅ | bench PSU **current reading** (§3) |
| LED state on power-up? | ✅ | film the LED, decode (§4) |
| Battery V, fix quality, state, packets | ✅ (Tier 1) | USB dashboard capture |
| Does the 4G modem attach / get a fix? | ✅ (Tier 1–2) | dashboard / u-center / remote desktop |
| Does it reach our gateway when powered? | ✅ | watch htracker for that unit's `cell_id` |
| Exact failed component / thermal soak | ❌ (needs bench) | **ship to QRO** |
So ~80% of triage is remotely achievable; only component-level confirmation and
thermal reproduction strictly require the units in QRO.
---
## 2. Do this NOW from Querétaro (no units needed)
The backend is on our own server — fully debuggable from QRO, and per
`02-Architecture-Software/backend-review.md` it can take healthy units off Wialon by itself.
1. **Historical online-vs-offline split.** For the days before removal, compare each
unit's **htracker** record (online on UDP receipt) against **Wialon** (online on
positions received). A unit that was **online in htracker but offline in Wialon**
was a **backend victim** (anti-jump lock-out / HOL stall), *not* dead hardware —
that reframes which "dead" units are actually hardware failures.
2. **Gateway logs around the death window:** look for the anti-jump warning
(`¡Filtro Anti-Salto Activado!`) spamming one `cell_id` (→ lock-out), and for
`netstat -su` UDP receive-buffer drops (→ HOL stall).
3. **Bench-reproduce with the working-ish unit** once it's powered (in VER via
remote-hands, or in QRO): point it at the gateway and watch whether the
retranslator forwards it cleanly or trips the filter.
4. Caster (HelgenSRV) uptime + **per-SIM data balance/suspension** for the window.
This is the highest-leverage work we can do today and it needs nobody in Veracruz.
---
## 3. Remote-hands protocol (tiered by what the on-site person has)
Give the on-site tech the matching tier. A ready-to-send Spanish version is in §6.
### Tier 0 — power + a phone camera (minimum)
For **each** unit, before powering:
1. **Photograph**: the whole inside, then close-ups of the **LiPo** (any swelling,
bulging, brown/black marks, leaks?), the **PowerBoost**, every **connector/Dupont**,
the **SMA antenna** joints, and any **discoloured/burnt** components.
2. **Wiggle test** (gently): do any Dupont/terminal/SMA connectors move or fall off?
3. **Bench power-on with a current-limited PSU** at the unit's normal voltage
(12 V or 24 V), current limit ~2 A:
- Read **inrush** then **steady current**. Record the number.
- **0 mA / trips at 0:** open circuit / dead input stage / blown fuse.
- **Hits the current limit / very hot:** short → **power off immediately**.
- **~50–150 mA steady, nothing else:** MCU only, stack not powering (load switch
/ boost / modem).
- **Normal-ish draw + LED activity:** boots — go to Tier 1.
- Compare every reading to the **working-ish unit**.
4. **Film the LED** for ~60 s from power-up (decode in §4).
### Tier 1 — Tier 0 + USB cable + a laptop
5. Plug the Blackpill **USB** into the laptop; open **PuTTY/TeraTerm at 115200**.
The v1 watchdog prints a live dashboard. **Capture 3–5 min** (log to file) and
send it. Read off: **BATTERY V**, **SYSTEM STATE**, **RTK FIX**, **PACKETS TX'd**,
PWR/IGN inputs. (No MCU-temp line — these are v1.)
6. Note whether **PACKETS TX'd increments** (GNSS+serial alive) and whether **RTK
FIX** ever reaches 4/5 (corrections arriving = 4G/NTRIP working).
### Tier 2 — Tier 1 + remote-desktop (AnyDesk/TeamViewer) into the laptop
7. We drive from QRO: read the live dashboard, run **u-center** on the ZED-F9P
(fix, sat levels, config), issue **AT commands** to the 4G modem (attach, signal),
and if useful **reflash v2** to gain thermal logging + better recovery.
---
## 4. LED quick-decode (v1)
| LED | State | Read as |
|---|---|---|
| Fast blink | BOOTING | powered, waiting for 4G/GNSS |
| Solid ON | RUNNING, vehicle power, RTK fixed | healthy |
| Heartbeat (1 s) | RUNNING on battery | on LiPo, 30 s rate |
| Slow blink | searching / no corrections | 4G/NTRIP not delivering |
| Off (with power applied) | SLEEP / dead | battery-critical logic **or** not booting |
"Off while powered from a good bench supply" on a unit that should boot = a strong
**no-boot / power-stage** signal — correlate with the current reading.
---
## 5. Per-unit triage decision tree
```
Power on bench PSU (current-limited)
├─ 0 mA ............................. dead input / blown fuse / open → ship to QRO
├─ hits limit / hot ................ SHORT (power off!) ............... → ship to QRO
└─ draws current
├─ no LED, no USB dashboard ...... MCU/boot dead .................... → ship to QRO
└─ boots (LED + dashboard)
├─ PACKETS not incrementing ... GNSS/serial dead ................ Tier 2 / ship
├─ FIX stuck 0/1 (never 4/5) .. 4G/NTRIP not delivering ......... check modem/SIM/antenna
└─ FIX 4/5 + packets OK ........ HARDWARE IS FINE ............... → backend victim (§2)
```
The last branch is the important one: a pulled unit that **boots, fixes, and
transmits on the bench is not the failure** — its disappearance from Wialon is then
backend (§2), and re-installing it unchanged would just repeat the problem.
---
## 6. Safety — heat-damaged LiPo (tell the on-site tech)
A swollen/puffy or hot LiPo is a **fire risk**. Do **not** charge it, puncture it, or
keep powering a unit whose battery is visibly swollen. Disconnect it, place it in a
**LiPo-safe / fireproof bag or a metal container**, keep it away from anything
flammable, and ventilate. Photograph first, then isolate. If it's hot, vented, or
smells: stop and isolate immediately.
---
## 6b. Spanish — instrucciones para el técnico en sitio (Tier 0/1)
> Para **cada** unidad: (1) **Fotos** del interior y de cerca de la **batería LiPo**
> (¿inflada, manchas cafés/negras, fuga?), del **PowerBoost**, de **cada conector
> Dupont**, de las **antenas SMA**, y de cualquier componente **quemado/decolorado**.
> (2) Prueba de **movimiento** suave: ¿algún conector se mueve o se cae? (3) Enciéndela
> con una **fuente de banco** a su voltaje normal (12 V/24 V), límite de corriente ~2 A,
> y anota la **corriente** (arranque y estable). Si llega al límite o se calienta,
> **apágala de inmediato** (corto). (4) **Graba el LED** ~60 s desde el encendido.
> (5) Si hay laptop: conecta el **USB** del Blackpill, abre **PuTTY/TeraTerm a 115200**
> y **graba 3–5 min** del tablero (BATERÍA V, ESTADO, RTK FIX, PAQUETES). **Seguridad:**
> una batería **inflada o caliente** es riesgo de incendio — no la cargues ni la
> perfores; aíslala en bolsa/recipiente seguro y ventila.
---
## 7. What to send back to Querétaro (capture checklist)
Per unit, labeled with its `cell_id`/machine: the **photos**, the **current reading**
(inrush + steady), the **LED video**, the **3–5 min USB dashboard capture**, and a
one-line note (boots? fix? packets?). With that, we can classify all 4 units against
the tree in §5 and the backend evidence in §2 — and decide which truly need teardown
in QRO.

106
docs/git/git-guide-en.md Normal file
View File

@ -0,0 +1,106 @@
# HBox_PCB — Guide for External Collaborators
**Project:** EinarBoard / HBOX watchdog (Helgen Technologies)
**Repository:** KiCad hardware design files only
**Contact:** Leo Rodríguez — leo@helgen.tech
---
## 1. What this repository is
The complete KiCad design history of the HBOX watchdog board, versions v3 through v6.
- **Active design: `hbox-watchdog-v6.*`** — this is the only version under development.
- `hbox-watchdog-v3/v4/v5.*` are frozen history. Do not modify them.
- Files ending in `-PROD` are snapshots of boards that were actually fabricated. Never touch these.
- Symbol and footprint libraries (`Drogheda-v6.kicad_sym`, `Drogheda-v6.pretty/`, `sym-lib-table`, `fp-lib-table`) live inside the repo with project-relative paths, so a clone is self-contained — no external library setup needed.
- `docs/` contains the **EinarBoard v6 Copper Plan — Placement & EMC Guide** (English and Spanish). Read its §0 (EMC laws) and §8 (master proximity table) before proposing any placement or routing change.
## 2. Getting access
1. Ask Helgen to create an account for you on the Git server `git.helgen.online` and to grant you access to `Helgen-Services/HBox_PCB`.
2. Log in to the web interface and add your **SSH public key** under your account settings.
3. Note that SSH runs on **port 222**, not 22.
## 3. Cloning
SSH (recommended):
```bash
git clone ssh://git@git.helgen.online:222/Helgen-Services/HBox_PCB.git
cd HBox_PCB
```
HTTPS (if your network blocks port 222):
```bash
git clone https://git.helgen.online/Helgen-Services/HBox_PCB.git
```
For a read-only review, a shallow clone is much faster (the repo carries 3D STEP/STL models and full history):
```bash
git clone --depth 1 ssh://git@git.helgen.online:222/Helgen-Services/HBox_PCB.git
```
## 4. Tooling
- **KiCad 10.x is required.** The project is saved in the KiCad 10 format.
- Do **not** open the files with KiCad 9 or older.
- Do **not** let a newer major version migrate/re-save the files without agreeing with Helgen first.
- Open `hbox-watchdog-v6.kicad_pro`; the schematic and PCB hang off it.
## 5. Ground rules — KiCad files and git
KiCad's `.kicad_sch` and `.kicad_pcb` are single large text files. Concurrent edits do not merge cleanly, so:
1. **One editor at a time.** Announce before you start editing, and say when you are done.
2. **Pull before opening KiCad. Never pull while the project is open in KiCad.** Close KiCad first, pull, reopen.
3. **Never commit:**
- lock files (`~*.lck`)
- backup files (`*bak`, `*-bak*`, autosave files)
- `*.kicad_prl` (per-user display preferences — your local one will change constantly; leave it out of your commits)
- fabrication outputs or reports you generated locally
4. **Do not run** "Update PCB from Schematic", global re-annotation, or library/format migrations unless that is the agreed task — they generate huge diffs that bury real changes.
5. Keep commits small and single-purpose.
## 6. Contribution workflow
Never commit to `main` directly.
```bash
# start from up-to-date main
git checkout main
git pull
# create your branch
git checkout -b review/<yourname>/<topic> # e.g. review/ana/emc-g2
# ... work in KiCad, then close KiCad and check what changed
git status
git diff --stat
# stage only the intended files
git add hbox-watchdog-v6.kicad_pcb
git commit -m "v6 PCB: <what you changed> (<why>)"
# publish and open a Pull Request to main in the web interface
git push -u origin review/<yourname>/<topic>
```
Before opening the Pull Request, refresh your branch:
```bash
git fetch origin
git rebase origin/main
```
Helgen reviews and merges. Never force-push to `main`.
## 7. Review-only feedback (no file edits)
If your role is review rather than editing, do not modify files at all: open an **Issue** in the web interface. Reference parts by their reference designator (`U25`, `C149`, `J12`…) and, where relevant, the Copper Plan section number (e.g. "§8, U25 group"). Screenshots of the KiCad view are welcome.
## 8. Questions
Anything unclear — ask before pushing. A five-minute question is cheaper than untangling a bad merge of a 1.5 MB board file.

106
docs/git/guia-git-es.md Normal file
View File

@ -0,0 +1,106 @@
# HBox_PCB — Guía para colaboradores externos
**Proyecto:** EinarBoard / HBOX watchdog (Helgen Technologies)
**Repositorio:** únicamente archivos de diseño KiCad
**Contacto:** Leo Rodríguez — leo@helgen.tech
---
## 1. Qué es este repositorio
El historial completo de diseño en KiCad de la tarjeta HBOX watchdog, versiones v3 a v6.
- **Diseño activo: `hbox-watchdog-v6.*`** — es la única versión en desarrollo.
- `hbox-watchdog-v3/v4/v5.*` son historial congelado. No los modifiques.
- Los archivos terminados en `-PROD` son instantáneas de tarjetas que ya se fabricaron. No los toques nunca.
- Las bibliotecas de símbolos y huellas (`Drogheda-v6.kicad_sym`, `Drogheda-v6.pretty/`, `sym-lib-table`, `fp-lib-table`) viven dentro del repositorio con rutas relativas al proyecto, así que el clon es autocontenido — no hay que configurar bibliotecas externas.
- `docs/` contiene el **Plan de Cobre EinarBoard v6 — Guía de colocación y EMC** (inglés y español). Lee su §0 (leyes de EMC) y su §8 (tabla maestra de proximidad) antes de proponer cualquier cambio de colocación o ruteo.
## 2. Obtener acceso
1. Pide a Helgen que te cree una cuenta en el servidor Git `git.helgen.online` y te dé acceso a `Helgen-Services/HBox_PCB`.
2. Entra a la interfaz web y agrega tu **llave pública SSH** en la configuración de tu cuenta.
3. Ten en cuenta que SSH corre en el **puerto 222**, no en el 22.
## 3. Clonar
SSH (recomendado):
```bash
git clone ssh://git@git.helgen.online:222/Helgen-Services/HBox_PCB.git
cd HBox_PCB
```
HTTPS (si tu red bloquea el puerto 222):
```bash
git clone https://git.helgen.online/Helgen-Services/HBox_PCB.git
```
Para una revisión de solo lectura, un clon superficial es mucho más rápido (el repositorio incluye modelos 3D STEP/STL e historial completo):
```bash
git clone --depth 1 ssh://git@git.helgen.online:222/Helgen-Services/HBox_PCB.git
```
## 4. Herramientas
- **Se requiere KiCad 10.x.** El proyecto está guardado en el formato de KiCad 10.
- **No** abras los archivos con KiCad 9 o anterior.
- **No** dejes que una versión mayor más nueva migre o re-guarde los archivos sin acordarlo antes con Helgen.
- Abre `hbox-watchdog-v6.kicad_pro`; el esquemático y el PCB cuelgan de él.
## 5. Reglas de oro — archivos KiCad y git
Los `.kicad_sch` y `.kicad_pcb` de KiCad son archivos de texto únicos y grandes. Las ediciones concurrentes no se fusionan bien, así que:
1. **Una sola persona editando a la vez.** Avisa antes de empezar a editar y avisa cuando termines.
2. **Haz pull antes de abrir KiCad. Nunca hagas pull con el proyecto abierto en KiCad.** Cierra KiCad, haz pull, y vuelve a abrir.
3. **Nunca subas al repositorio:**
- archivos de bloqueo (`~*.lck`)
- respaldos (`*bak`, `*-bak*`, archivos de autoguardado)
- `*.kicad_prl` (preferencias de vista por usuario — el tuyo cambia constantemente; déjalo fuera de tus commits)
- salidas de fabricación o reportes generados localmente
4. **No ejecutes** "Update PCB from Schematic", re-anotación global, ni migraciones de biblioteca/formato salvo que esa sea la tarea acordada — generan diffs enormes que entierran los cambios reales.
5. Haz commits pequeños y de propósito único.
## 6. Flujo de contribución
Nunca hagas commit directo a `main`.
```bash
# parte de un main actualizado
git checkout main
git pull
# crea tu rama
git checkout -b review/<tunombre>/<tema> # p. ej. review/ana/emc-g2
# ... trabaja en KiCad, luego cierra KiCad y revisa qué cambió
git status
git diff --stat
# agrega solo los archivos que quieres cambiar
git add hbox-watchdog-v6.kicad_pcb
git commit -m "v6 PCB: <qué cambiaste> (<por qué>)"
# publica y abre un Pull Request hacia main en la interfaz web
git push -u origin review/<tunombre>/<tema>
```
Antes de abrir el Pull Request, actualiza tu rama:
```bash
git fetch origin
git rebase origin/main
```
Helgen revisa y hace el merge. Nunca hagas force-push a `main`.
## 7. Retroalimentación de solo revisión (sin editar archivos)
Si tu papel es revisar en lugar de editar, no modifiques archivos: abre un **Issue** en la interfaz web. Refiérete a los componentes por su designador de referencia (`U25`, `C149`, `J12`…) y, cuando aplique, por el número de sección del Plan de Cobre (p. ej. "§8, grupo U25"). Las capturas de pantalla de KiCad son bienvenidas.
## 8. Dudas
Cualquier cosa que no esté clara — pregunta antes de hacer push. Una pregunta de cinco minutos cuesta menos que desenredar un mal merge de un archivo de tarjeta de 1.5 MB.

25
docs/index.md Normal file
View File

@ -0,0 +1,25 @@
# HBOX — Documentación técnica
Sitio interno de Helgen Technologies para técnicos de banco y colaboradores del proyecto
HBOX (EinarBoard). Aquí vive la copia publicada de los procedimientos; la fuente de verdad
es el repositorio **Drogheda** — no edites estas páginas a mano, se regeneran con el
script de sincronización.
## Empieza aquí
- **¿Vas a probar y flashear el lote v5 (15 tarjetas)?** → [EinarBoard v5 — Prueba y flasheo](procedimientos/v5-prueba-y-flasheo.md)
- **¿Armado de arneses o gabinete?** → [Pinout de arneses](montaje/pinout-arneses.md) y la [guía de ensamble](montaje/assembly-guide.md)
- **¿Una unidad en campo falla?** → [Protocolo de diagnóstico remoto](diagnostico/protocolo-diagnostico-remoto.md)
- **¿Vas a trabajar con los archivos de diseño (KiCad)?** → [Guía Git para colaboradores](git/guia-git-es.md)
## Reglas de la casa
1. Los procedimientos se siguen **en orden y completos**; una tarjeta que falla una sección
no avanza a la siguiente.
2. Toda medición fuera de rango se anota con su **valor**, no solo "FALLA".
3. Si algo del documento no coincide con lo que ves en la tarjeta, **detente y pregunta**
a ingeniería antes de continuar.
---
*Última sincronización: la fecha aparece en el pie de cada página. Contacto: leo@helgen.tech*

BIN
docs/montaje/0007-1000_Assembly_Guide.pdf Normal file
View File

Binary file not shown.

8
docs/montaje/assembly-guide.md Normal file
View File

@ -0,0 +1,8 @@
# Guía de ensamble (PDF)
La guía de ensamble completa del gabinete HBOX es un PDF:
**[Abrir 0007-1000_Assembly_Guide.pdf](0007-1000_Assembly_Guide.pdf){:target="_blank"}** (≈9 MB)
Se recomienda descargarla en la tablet o laptop del banco antes de empezar, para no
depender de la red durante el armado.

140
docs/montaje/bom-split.md Normal file
View File

@ -0,0 +1,140 @@
---
title: HBOX Watchdog v3 PROD — Assembly BOM Split
project: Project Drogheda
date: 2026-07-05
tags: [project-drogheda, hardware, pcb, assembly, jlcpcb, bom]
status: Board routed, DRC fab-clean — assembly reference for JLCPCB PCBA order
---
# HBOX Watchdog v3 PROD — Assembly BOM Split
Audit of the routed board (`kicad/hbox-watchdog-v3-PROD.kicad_pcb`, 126 footprints)
for the JLCPCB assembly order. Three buckets: **(A)** what JLC solders onto the
board, **(B)** the plug-in modules that sit on top (you install), and **(C)** what
lives off-board and connects through the JST harness.
| Bucket | Count | JLC assembles? |
|---|---|---|
| A. On-board parts (SMD + THT) | 103 parts + 12 connectors + 5 sockets | **Yes** |
| B. Plug-in modules (on top) | 3 modules | No — you install |
| C. External via JST harness | wired to 12 connectors | No — off-board |
| Fab features (2 test points, 4 mounting holes) | 6 | n/a |
---
## A. Assembled by JLC — on the PCB
### A1 · SMD parts (standard PCBA — 98 parts)
| Qty | Value | Package | Refs |
|---|---|---|---|
| 10 | 10k | R0603 | R2, R5, R6, R7, R8, R41, Rigb, Rled, Rrp, Rtp |
| 8 | 100k | R0603 | R20, R56, R57, R58, Ren1, Rfreq, Rfreq2, Rgs |
| 7 | 100nF | C0603 | C5, C7, C9, C11, C24, Cu3, Cu4 |
| 5 | LED | LED0805 | D1, DB1, DB2, DB3, DB4 |
| 4 | 1k | R0603 | R1, R3, R40, Rts |
| 4 | 330R | R0603 | RB1, RB2, RB3, RB4 |
| 3 | SS34 | D_SMA | D2, Dbk, Dbk2 |
| 3 | 22uF | C0805 | C35, C40, C41 |
| 3 | 100k/1% | R0603 | R52, R54, R60 |
| 2 | MP1584EN | SOIC-8-EP | U2 (fan buck), U7 (modem buck) |
| 2 | 2.2nF | C0603 | Ccomp, Ccomp2 |
| 2 | 100R | R0603 | Rg, Rig |
| 2 | 10uF | C0805 | C30, C34 |
| 2 | 4.7k | R0603 | R30, R31 |
| 2 | 40.2k | R0603 | Rcomp, Rcomp2 |
| 2 | MMBT3904 | SOT-23 | Q5, Q6 |
| 2 | 10nF | C0603 | Cbst, Cbst2 |
| 2 | AO3400A | SOT-23 | Q2, Q4 |
| 2 | 10k/1% | R0603 | R42, R55 |
| 2 | 47uF | C1210 | C32, C33 |
| 1 | **LTC4040EUFD** | QFN-24 | U6 (backup-supply/charger) |
| 1 | AO4406A | SOIC-8 | Q7 |
| 1 | AO3401A | SOT-23 | Q1 |
| 1 | IRFR5305 | TO-252 | Q10 |
| 1 | BZX84C15 | SOT-23 | DzG |
| 1 | BAT54 | SOD-123 | D5 |
| 1 | 1N4148W | SOD-123 | D6 |
| 1 | SMBJ33A | D_SMB | D10 |
| 1 | **SHT40-AD1B** | DFN-4 | U3 (humidity/temp) |
| 1 | **TMP102** | SOT-563 | U4 (temp) |
| 1 | 8mR/1% | R1206 | RS1 (current sense) |
| 1 | PPTC 3A | Fuse1812 | F1 |
| 3 | 2.2uH / 10uH / 10uH-2A | SRU8028 8×8 | L6, L2, L7 |
| 1 | 22uF/50V | C1210 | C22 |
| 1 | 22uF/16V | C0805 | C23 |
| 1 | 2.2uF | C0603 | C31 |
| — | *(single-value R's)* | R0603 | Ren2 20k, Rdfu 22k, R21 19.1k, R50 825R, R51 287k, R53 499k, R61 31.6k |
| 4 | jumpers | SolderJumper | JP1 (0R), JP2 (F2), JP3 (F1), JP4 (F0) |
### A2 · Through-hole parts (THT — JLC "through-hole assembly" surcharge, or hand-solder)
| Ref | Part | Note |
|---|---|---|
| K1 | Omron G5V-1 DC5 relay | Modo-B fail-safe bypass |
| SW1 | 6 mm push (RESET) | |
| C3, C10, C43 | Radial electrolytics (47µF, 47µF/50V, 100µF) | |
### A3 · Connectors & module sockets (THT — soldered to board)
| Ref | Part | Purpose |
|---|---|---|
| P1 | Phoenix MKDS 1.5-5 (5-pos terminal) | GX16 machine power in |
| P2, P8, P10, P11, P12 | JST-XH 2-pin | see bucket C |
| P4, P13 | JST-XH 3-pin | |
| P3, P5, P6 | JST-XH 4-pin | |
| H3 | 1×3 pin header | USART1 reserved |
| **J1, J2** | 1×20 female 2.54 | **Blackpill socket** |
| **J7, J8** | 1×10 female 2.00 | **4G XBee socket** |
| **MOD1** | Arduino-UNO-form female headers | **simpleRTK2B Pro socket** |
> ⚠️ **Confirm before ordering:** engineering notes flag **P3 / P13 / H3 as DNP**
> (Modo-B + K1 NC bypass makes them redundant), but they are **not** marked DNP in
> the board file — so JLC would populate them. Decide per-connector.
---
## B. Plug-in modules — mounted ON TOP (you install, NOT in the JLC order)
These are complete boards that seat into the sockets above. Do **not** add them to
the JLC BOM — they're hand-fitted after the PCBA arrives.
| Module | Seats into | Notes |
|---|---|---|
| **simpleRTK2B Pro** (ZED-F9P) | MOD1 (Arduino headers) | GNSS RTK receiver |
| **STM32F411 Blackpill** | J1 + J2 (2×20) | watchdog MCU |
| **4G NTRIP Master** (XBee LTE) | J7 + J8 (2×10, 2 mm) | modem, 3V3 socket |
---
## C. External — connected via the JST harness (NOT on the board)
Everything that plugs into the edge connectors and lives outside the HBOX (or in the
cabinet). Wire per the harness pinout (`harness-connector-pinout.md`).
| Conn | Wires to (external) | Key pins |
|---|---|---|
| **P1** GX16-5 | Machine power + ignition from the cabinet | 1 = 24V_IN ⚡, 3 = IGN_IN, 2 = GND |
| **P2** 5V-IN | Mean Well SD-15B-05 5 V supply (VEH5V rail) | 1 = VEH5V ⚡, 2 = GND |
| **P3** RTK2B-UART1 | RTK2B UART1 tap (GNSS TX/RX) | 1 = SW_5V ⚡, 3 = GNSS_TX, 4 = GNSS_RX |
| **P4** BATT | 1S4P 12 Ah pack + NTC | 1 = BAT_PLUS ⚡, 3 = NTC, 2 = GND |
| **P5** TEMP_PROBE | External I²C temp/probe header | 1 = 3V3, 3 = SDA, 4 = SCL |
| **P6** FAN | Cooling fan (5 V, tach) | 1 = 5V_FAN ⚡, 2 = FAN_RET, 4 = TACH |
| **P8** PANEL_LED | Panel status LED | 1 = LED_A, 2 = LED_K |
| **P10** RESET-EXT | External reset button | 1 = NRST, 2 = GND |
| **P11** CUTOFF-SW | Power cutoff switch (SYS→MAIN 5 V) | 1 = MAIN5V ⚡, 2 = SYS5V ⚡ |
| **P12** NTC-HOTSPOT | Cabinet hotspot NTC | 1 = NTC_TEMP, 2 = GND |
| **P13** MODO-B-UPLINK | Modo-B uplink to 4G | 1 = USART1_RX, 2 = DIN_4G, 3 = GND |
---
## Action items before the JLCPCB order
1. **Add LCSC part numbers** to the BOM (`fab-jlcpcb/…-BOM.csv`) — it exports value +
footprint only; JLC PCBA matches on LCSC part #. Watch the odd ones:
**LTC4040EUFD, SHT40-AD1B, TMP102, MP1584EN, AO4406A, Bourns SRU8028** — verify JLC/LCSC stock.
2. **Decide THT assembly** — JLC charges extra for through-hole (K1, SW1, C3/C10/C43,
all connectors/sockets). Common approach: JLC does SMD, you hand-solder the
connectors + sockets (also avoids paying JLC for the big Phoenix/JST parts).
3. **Resolve the P3 / P13 / H3 DNP question** above.
4. Do **not** BOM the three plug-in modules (bucket B).

112
docs/montaje/pinout-arneses.md Normal file
View File

@ -0,0 +1,112 @@
---
title: HBOX Watchdog v3 PROD — Harness / Connector Pinout
project: Project Drogheda
date: 2026-07-04
tags: [project-drogheda, hardware, harness, pinout]
---
# HBOX Watchdog v3 PROD — Harness / Connector Pinout
Auto-generated from the PCB netlist (placement-independent). `GND` = the board ground plane (In1.Cu); its full pad list is omitted. Power nets flagged for wire gauge.
| Conn | Function | Pins |
|---|---|---|
| **P1** | GX16-5 | 5 |
| **P2** | 5V-IN-SD15B05 | 2 |
| **P3** | RTK2B-UART1 | 4 |
| **P4** | BATT-1S4P+NTC | 3 |
| **P5** | TEMP_PROBE | 4 |
| **P6** | FAN | 4 |
| **P8** | PANEL_LED | 2 |
| **P10** | RESET-EXT | 2 |
| **P11** | CUTOFF-SW | 2 |
| **P12** | NTC-HOTSPOT | 2 |
| **P13** | MODO-B-UPLINK | 3 |
## P1 — GX16-5
| Pin | Net | Ties to |
|---|---|---|
| 1 | `24V_IN` ⚡power | D10.1, Q10.2 |
| 2 | `GND` | board ground plane |
| 3 | `IGN_IN` | Rig.1 |
| 4 | — | *(no net)* |
| 5 | — | *(no net)* |
## P2 — 5V-IN-SD15B05
| Pin | Net | Ties to |
|---|---|---|
| 1 | `VEH5V` ⚡power | C30.1, C31.1, JP1.2, R51.1, R55.1, R7.1, RS1.1, U6.6, U6.16 |
| 2 | `GND` | board ground plane |
## P3 — RTK2B-UART1
| Pin | Net | Ties to |
|---|---|---|
| 1 | `SW_5V` ⚡power | C3.1, C40.1, MOD1.5, Q1.3, U7.2, U7.7 |
| 2 | `GND` | board ground plane |
| 3 | `GNSS_TX` | J1.8, MOD1.16 |
| 4 | `GNSS_RX` | J1.9, MOD1.15 |
## P4 — BATT-1S4P+NTC
| Pin | Net | Ties to |
|---|---|---|
| 1 | `BAT_PLUS` ⚡power | C35.1, L6.2, R5.1, U6.23 |
| 2 | `GND` | board ground plane |
| 3 | `NTC` | R55.2, U6.17 |
## P5 — TEMP_PROBE
| Pin | Net | Ties to |
|---|---|---|
| 1 | `3V3` ⚡power | Cu3.1, Cu4.1, D5.1, J1.18, J2.20, MOD1.2, R3.1, R30.1, R31.1, R42.1, R57.1, R58.1, Rdfu.2, Rtp.1, U3.3, U4.5 |
| 2 | `GND` | board ground plane |
| 3 | `I2C_SDA` | J2.15, R31.2, U3.1, U4.6 |
| 4 | `I2C_SCL` | J2.14, R30.2, U3.2, U4.1 |
## P6 — FAN
| Pin | Net | Ties to |
|---|---|---|
| 1 | `5V_FAN` ⚡power | C23.1, D2.1, JP1.1, L2.2, R20.1 |
| 2 | `FAN_RET` | D2.2, Q2.3 |
| 3 | `GND` | board ground plane |
| 4 | `FAN_TACH_RAW` | Rts.1 |
## P8 — PANEL_LED
| Pin | Net | Ties to |
|---|---|---|
| 1 | `LED_A` | D1.2, R3.2 |
| 2 | `LED_K` | D1.1, Q4.3 |
## P10 — RESET-EXT
| Pin | Net | Ties to |
|---|---|---|
| 1 | `NRST` | J1.5, SW1.1 |
| 2 | `GND` | board ground plane |
## P11 — CUTOFF-SW
| Pin | Net | Ties to |
|---|---|---|
| 1 | `MAIN5V` ⚡power | C32.1, C33.1, C34.1, JP2.1, JP3.3, JP4.1, Q7.1, Q7.2, Q7.3, R53.1, U6.1, U6.24 |
| 2 | `SYS5V` ⚡power | D6.1, F1.1, J1.20, J2.18, K1.2, R2.2 |
## P12 — NTC-HOTSPOT
| Pin | Net | Ties to |
|---|---|---|
| 1 | `NTC_TEMP` | C24.1, J1.15, R42.2 |
| 2 | `GND` | board ground plane |
## P13 — MODO-B-UPLINK
| Pin | Net | Ties to |
|---|---|---|
| 1 | `USART1_RX` | H3.2, J2.7, K1.1, MOD1.23, Rdfu.1 |
| 2 | `DIN_4G` | J7.3, K1.5, K1.6 |
| 3 | `GND` | board ground plane |

102
docs/procedimientos/einarboard-1.0-bringup.md Normal file
View File

@ -0,0 +1,102 @@
---
title: EinarBoard 1.0 (rev 1.1) — Bring-Up Runbook & Anticipated-Trouble Register
tags: [project-drogheda, hardware, einarboard, bringup, testing, runbook]
project: Project Drogheda
author: Helgen CTO
date: 2026-07-08
status: ACTIVE — execute in order when boards arrive
---
# EinarBoard 1.0 — Bring-Up Runbook
**Order (FINAL — replacement of 2026-07-08):** original PCBA SMT026070860564 cancelled (2 BOM
lines lost at matching); replacement placed 2026-07-08, **live-verified complete: 53 lines,
116/118 designators assembled** incl. D2/DBK2/DBK1 and all six LEDs. Rotations confirmed by Leo
in the placement viewer. Deltas vs the original parts map: LEDs = **C2295 KT-0805R (RED — all
indicators red by choice)** · RS1 = **C2988654** (HoLLR1206-1W-8mR-1%, spec-compliant alternate) ·
100nF = C1591 · 22µF ×4 = C76637 · R51 = C22972 · 22k = C31850. **J1/J2 NOT assembled (the only
unselected parts)** → bench jig-solder; buy two 1×20 2.54 female sockets locally (the C50984 reel
is locked in JLC inventory for future PCBA). Setpoints re-derived from ordered values 2026-07-08: fan 4.99 V · modem 3.33 V ·
I_chg 2.42 A · input limit 3.12 A · PFI 4.61 V · backup 4.79 V — all on target.
---
## A. NOW — before production starts (the $479 gate)
- [ ] **DFM Analysis check (4–6 h after ordering, Order History → DFM Analysis).** Verify the
polarity dozen against the answer sheet: **U6 pin-1 TOP-LEFT · U2/U7 pin-1 BOTTOM-RIGHT ·
Q7 pin-1 TOP-LEFT · bands: D2/Dbk2/D5/D10 LEFT, Dbk1 TOP, D6 RIGHT · electrolytics "+":
C3 BOTTOM, C10/C43 LEFT · LED cathodes LEFT (D1, D4G1, DB1–4)**. The preview already caught
U6 and U2 turned 180° once — assume nothing.
- [ ] **Confirm Production File is set to Yes with 48 h auto-confirm** — an unwatched weekend
approves itself. Approve only after the DFM check passes.
- [ ] Answer every JLC review email **same day** (schedule protection).
## B. Reception (day of delivery)
- [ ] Visual vs the ordered renders: DNPs bare (P3/P13/H3, MOD1 field), all sockets present,
P1 wire-entry toward the edge, J9 opening at the edge.
- [ ] Polarity dozen again, on physical boards, one board, 5 minutes with a loupe.
- [ ] Measure J1↔J2 socket spacing on one board (decision record says 15.00 mm) and test-insert
a Blackpill — expect light preload if the module measures wider; note insertion force.
## C. Board #1 electrical bring-up — NO modules socketed, current-limited bench supply
1. **Resistance sanity (unpowered):** 24V_IN→GND, MAIN5V→GND, 3V3_MODEM→GND — no shorts (>1 kΩ).
2. **24 V path:** bench supply 24 V, limit 200 mA → P1 pins 1/2. Check: 24V rail after Q10 ≈ 24 V
(reverse-protection FET conducting), **5V_FAN = 5.0 V** (U2 running), fan header P6 pin 1.
3. **Vehicle 5 V path:** 5 V, limit 500 mA → P2. Check: **MAIN5V ≈ 5 V** (LTC4040 input FET
passing), SYS5V after P11 jumpered/switched ON, Blackpill socket pins J1-20/J2-18 = 5 V.
4. **Load switch default-OFF (invariant #1):** with no MCU, SW_5V must be **0 V**. Then short
J1-7 (PWR_CTRL) to 3V3 momentarily → SW_5V = 5 V, **3V3_MODEM = 3.33 V** (U7 up).
5. **Ignition sense:** 12 V and 24 V through P1-3 → IGN_SENSE (J1-11) clamps ≈ 3.5–3.6 V; 0 V → <0.3 V.
6. **⚠ CHARGER NTC TRAP (this WILL look like a dead charger):** with no battery-harness NTC on
P4-3, the LTC4040's NTC pin is pulled to VIN by R55 → reads "battery too cold" → **charging
silently paused**. For bench charge tests, connect **10 kΩ from P4-3 to P4-2 (GND)** to emulate
25 °C. Do not debug the charger without it.
7. **Charger (with NTC emulation + real 1S4P pack or bench cell):** connect pack to P4 →
CHRG (J2-11) low while charging; charge current ramps ≤ 2.42 A; input current never exceeds
~3.1 A (watch the bench meter — this validates RS1/CLPROG behavior).
8. **Backup event (THE LTC4040 validation — this block never saw a proto):** system running on
P2 5 V with pack connected → pull P2 → **VSYS holds ≈ 4.79 V** from boost, board keeps running.
Measure: no back-feed voltage appearing on the disconnected P2 pins (validates Q7 orientation
fix). Restore P2 → seamless return + recharge. **Do this before any fleet commitment.**
9. **K1 fail-safe:** unpowered board: continuity K1 pin 1 ↔ pins 5/6 (NC closed = corrections
path exists with dead MCU). Powered + PB5 high: path opens to NO (pin 10).
## D. Module integration (board #1 only, then replicate)
- [ ] **MOD1 socket strips: solder using the simpleRTK2B Pro as the jig** (strips on module →
insert → solder → remove). Same jig trick for any stiff J1/J2 fit.
- [ ] Blackpill in (USB end toward board-left / VB-B12 corner at pads-1 — sockets don't key!).
Flash bench firmware via module USB.
- [ ] **Firmware flag: PROD `CHRG_EN` (PA8) is HIGH = charge OFF** — the proto TP4056 logic was
INVERTED (`CHRG_RUN` HIGH = ON). Port the flag before flashing, or units will disable charging
when they mean to enable it.
- [ ] Pro into MOD1 (antenna top-left, USBs bottom, per the validated orientation). **Old-rev
Pros: XBee switch → UART1. All revs: Pro's own XBee socket stays EMPTY; never plug the Pro's
"USB XBee" port in service** (its FTDI sits on the RTCM3 downlink on new revs).
- [ ] **F9P config: write to FLASH, not RAM** (Jun-20 finding — RAM-only config dies at power
cycle). Verify with a power cycle before shipping any unit.
- [ ] 4G NTRIP Master into J7/J8 (VCC row = J7). Telcel micro-SIM installed first. Board USB-C
(J9) enables the modem's USB only when a host provides VBUS — bench console via J9 is safe;
it does not fight the uplink.
- [ ] End-to-end: open sky, corrections from caster → **GGA quality 4 (RTK fixed)** — the
fleet's first-ever verified fix ≥4 per the Jun-20 gap.
## E. Known-accepted risks (decision register — watch, don't re-litigate)
| Risk | Decision/owner | Watch for |
|---|---|---|
| J1/J2 rows at 15.00 mm vs 15.24 reading of module | Leo, vernier-verified, 2026-07-07 | Insertion force; pin preload; use jig-solder trick if stiff |
| LTC4040 block fab'd without proto validation | Gate waived consciously (boards cheap) | Step C.8 is the validation — run it FIRST |
| C22 = 35 V part on 24 V node (spec said 50 V) | Accepted at order | Nothing expected; note for rev 1.2 BOM |
| C778721/C90142 ceramic bias derating | Within design margins | — |
| D4G1 modem LED driven from 1.8 V pin | Known-dim (audit L4) | Don't debug as a fault |
| Backup boost budget 1.93 A of 2.5 A at modem TX burst | Margin accepted; 104 µF VSYS bank | Brownout during TX only if budget exceeded — scope VSYS during TX test |
## F. Fleet replication (after board #1 passes everything)
Per-unit checklist: NTC harness populated (removes the C.6 emulation) · module orientations ·
switch-to-UART1 on old Pros · F9P FLASH config verified by power cycle · jig-soldered strips ·
GGA≥4 open-sky check · then HBOX integration per the enclosure docs (fit verified 2026-07-07).

85
docs/procedimientos/fan-policy-bench-test.md Normal file
View File

@ -0,0 +1,85 @@
---
title: "Procedimiento de banco — Validación de la política de ventilador FW v3.0.3"
project: Project Drogheda
date: 2026-08-18
version: v1.0
audience: ingeniería (banco)
target: EinarBoard 1.0 / 2.0 (V4) + firmware blackpillrtkcode_v3 v3.0.3
tags: [project-drogheda, testing, ventilador, firmware, banco]
---
# Validación en banco — política de ventilador por potencia (FW v3.0.3)
## 0. Qué se está probando
Desde v3.0.3 el ventilador **ya no se modula**: solo tiene dos estados.
| Condición | Ventilador |
|---|---|
| VEH5V presente **Y** ignición ON | **100 % fijo (DC), a cualquier temperatura** |
| Falta VEH5V **o** falta ignición ("modo batería") | Termostato: **enciende ≥ 48 °C, apaga < 45 °C** (temperatura de control = la más alta de aire SHT40 / batería TMP102 / MCU) |
La lógica reacciona en ≤ 2 s (cadencia térmica) más el debounce de entradas (~0.75 s). No hay sensado de 24 V: la **ignición es el testigo** de que el riel de 24 V existe.
> ⚠️ **PELIGRO:** hay 24 V en P1. Verifique polaridad antes de energizar. No conecte ni desconecte el ventilador (P6) con la tarjeta energizada.
> 🛑 **ALTO:** en banco sin batería, el riel de 5 V debe estar en **≥ 5.2 V** o con el pack conectado (disparo PFI 4.60 V del LTC4040 bajo ráfaga LTE — nota 24-jul). Si la unidad se reinicia sola durante la prueba, revise esto primero.
## 1. Equipo
Fuente de 24 V (≥ 1 A), fuente de 5 V ajustada a 5.2 V (o el SD-15B de la unidad), fuente o puente de 12–24 V para ignición, multímetro, laptop con terminal serie (USB del Blackpill, **115200 8N1**), pistola de aire caliente (a baja, < 70 °C), osciloscopio (opcional, para confirmar DC).
## 2. Puntos de medición
| Conector | Pin | Señal | Uso en esta prueba |
|---|---|---|---|
| **P1** (GX16-5 / Phoenix) | 1 | `24V_IN` | Alimenta SOLO el buck del ventilador (U2 → `5V_FAN`) |
| | 2 | `GND` | Retorno común |
| | 3 | `IGN_IN` | Ignición cruda 12–24 V (divisor Rig 22k / Rigb 10k → PA5) |
| **P2** | 1 | `VEH5V` | 5 V del SD-15B (= "vehículo presente" para el firmware, umbral ON > 4.2 V / OFF < 3.8 V) |
| **P6** (ventilador) | 1 | `5V_FAN` | +5 V del buck — debe medir ~5 V siempre que haya 24 V en P1.1 |
| | 2 | `FAN_RET` | Drenaje de Q2 (lado bajo). **Fan ON → ~0 V; fan OFF → ~5 V** |
| | 4 | `FAN_TACH_RAW` | No usado (ventilador de 2 hilos) — debe quedar al aire |
| **PA6** (Blackpill / Rg) | — | `FAN_PWM` | Comando del MCU vía Rg (100 Ω) → gate de Q2. **ON → 3.3 V DC plano; OFF → 0 V** |
La medición que decide es **P6.2 respecto a GND** (o la tensión P6.1↔P6.2 a través del ventilador: ~5 V girando, ~0 V parado). PA6 confirma qué está comandando el firmware; P6.2 confirma que Q2 y el ventilador obedecen.
## 3. Telemetría de referencia
Abra la terminal serie antes de empezar. Cada 2 s sale una línea `TLM`; las columnas relevantes (ver línea `COLS` al arranque):
`...,veh,ign,...,tair,rh,tbat,fan_rpm,fan_pwm,fan_fault,...`
- `veh` / `ign`: entradas ya con debounce — confirman que la tarjeta ve lo que usted conectó.
- `fan_pwm`: **solo puede valer 0 o 100** en v3.0.3. Cualquier valor intermedio = firmware equivocado (¿quedó una v2.3/3.0.1?).
- La línea `BOOT` debe reportar `fw=3.0.3`. Si no, deténgase y reflashee.
## 4. Procedimiento
Estado inicial: P1 con 24 V, P2 con 5.2 V, **ignición desconectada**, ventilador en P6, unidad a temperatura ambiente (< 40 °C).
| # | Acción | Resultado esperado | Verificar |
|---|---|---|---|
| 1 | Energizar la unidad (arranque en frío) | **Self-test**: los 4 LEDs de gauge encienden en secuencia y el ventilador da un soplo de ~0.8 s | Confirma que Q2 + ventilador funcionan, independiente de la lógica |
| 2 | Esperar 10 s, sin ignición | Ventilador **apagado** | P6.2 ≈ 5 V · PA6 = 0 V · TLM: `veh=1 ign=0 fan_pwm=0` |
| 3 | Aplicar 12–24 V a P1.3 (ignición) | En ≤ 3 s el ventilador arranca al **100 %**, aun frío | P6.2 ≈ 0 V · PA6 = 3.3 V **DC plano** (sin PWM en el osciloscopio) · TLM: `ign=1 fan_pwm=100` |
| 4 | Mantener 5 min | Sigue al 100 % sin interrupciones; `fan_fault=0` | Sin parpadeos en P6.2 |
| 5 | Quitar ignición (24 V y 5 V se quedan) | En ≤ 3 s el ventilador **se apaga** (modo batería, unidad fría) | P6.2 ≈ 5 V · `ign=0 fan_pwm=0` |
| 6 | Sin ignición: calentar el sensor SHT40 (sonda P5) con aire caliente, gradual | Al llegar `tair` a **48 °C** el ventilador arranca al 100 % | TLM: `tair≥48 → fan_pwm=100`. **No** debe arrancar a 45–47 °C (histéresis) |
| 7 | Retirar el calor y dejar enfriar | Sigue girando entre 45–47 °C; **se apaga solo por debajo de 45 °C** | `tair=46 → fan_pwm=100` · `tair=44 → fan_pwm=0` |
| 8 | Reconectar ignición con la unidad aún tibia | 100 % inmediato sin importar la temperatura | `fan_pwm=100` |
| 9 | (Opcional, con pack conectado) Quitar el 5 V de P2 dejando 24 V + ignición | El firmware pasa a modo batería (gate incompleto): manda termostato, no el 100 % fijo | `veh=0 → fan_pwm` según temperatura |
> ℹ️ **NOTA sobre el paso 6:** apunte el aire caliente a la **sonda SHT40 (P5)**, no a la tarjeta completa — así el resultado es reproducible. No exceda ~65 °C: arriba de 45 °C en la celda el firmware además corta la carga (`Cell hot -> charge OFF` en el log); es comportamiento esperado, no una falla.
## 5. Criterios de aceptación
La unidad PASA si: (1) `fw=3.0.3` en BOOT; (2) `fan_pwm` solo toma valores 0 y 100 durante toda la prueba; (3) con ignición + VEH5V el ventilador gira al 100 % en frío (paso 3 — este es el cambio de comportamiento clave vs. versiones anteriores); (4) la histéresis 48/45 °C del modo batería se cumple en ambos sentidos (pasos 6–7); (5) PA6 es DC plano en ON (sin portadora de 25 kHz); (6) `fan_fault=0` al final.
Cualquier desviación: capture el log serie completo (es append-only, basta guardar la sesión de terminal) y repórtelo con el número de paso.
## 6. Registro
| Unidad | Fecha | Ingeniero | P3 (100 % frío) | P6/P7 (histéresis) | fan_fault | PASA/FALLA |
|---|---|---|---|---|---|---|
| H____ | | | | | | |

196
docs/procedimientos/historico-proto-bench-v3.md Normal file
View File

@ -0,0 +1,196 @@
---
title: Watchdog v3 — Proto Bench Bring-up & Build-Readiness (DEV board)
tags: [project-drogheda, hardware, watchdog, prototype, breadboard, bring-up, readiness]
project: Project Drogheda
author: Helgen CTO
date: 2026-06-24
status: Active — tomorrow's bench guide (supersedes the procedure half of watchdog-protoboard-bringup.md for v3)
---
# Watchdog v3 — Proto Build Readiness & Bench Bring-up
> **Scope:** breadboard the **DEV** watchdog on the existing Blackpill and prove the state
> machine + sensing + load switch + fan/temp loop. **PCB layout is explicitly out of scope
> for tomorrow** (do it after the proto works). Authority: [[watchdog-electrical-design-state]]
> (canonical) · firmware `04-Source-Code/firmware/blackpillrtkcode_v2/` (v2.3) ·
> schematic `kicad/hbox-watchdog-v3.kicad_sch`.
> **⚠ UPDATE 2026-07-03 — sensor suite changed to parts in hand.** Proto sensors are now
> **AHT10** (0x38, I²C1 **alone**, 3V3) + **LM35 → PA7** + **NTC → PB1** (no SHT40/TMP102 on
> proto — PCB-only). The kit's TP4056 has **no TEMP pin** → charge cutoff is **PA8 `CHRG_RUN`**
> (IRF9540N on TP4056 IN+, **inverted vs PROD CHRG_EN**). Cutoff switch wired: nodo SYS → SPST
> → MAIN5V. **The fan in hand is 2-wire** → PB10 tach test drops. §1/§3 rows below are patched;
> the authoritative wiring = ledger xlsx + `Drogheda_Guia-Conexion-Protoboard_ES_v2.2.pdf`.
> **Firmware v2.3 still reads SHT40 (0x44)** — the AHT10 driver / LM35 channel / CHRG_RUN flag
> are a pending firmware pass; until then the I²C and charge-cut rows are wire-now/test-later.
---
## 0. Verdict — are you ready to build? **Yes, with three caveats**
You can build and bring up the **core watchdog** tomorrow. Nothing about the schematic or its
ERC state blocks a breadboard build. The caveats are about *firmware coverage* and *scope
discipline*, not readiness:
1. **ERC "issues" are cosmetic — not a blocker.** File-based ERC on `hbox-watchdog-v3.kicad_sch`
= **0 errors, 1 warning** (a `Q_NPN_BCE` symbol-cache mismatch). The ground net is unified
(4 `GND` symbols, **0** placed `GNDREF` instances — the GNDREF you may see is just an orphaned
library-cache entry, not a real second ground). None of this affects a breadboard. *(Clean it
only before you go to PCB layout — see §2.)*
2. **Two v3 sub-circuits aren't in firmware yet.** The flashed v2.3 build does **not** drive the
4-LED battery gauge (PB12–15) or `CHRG_EN` (PA8). You can wire them, but they'll sit dark/idle
until a firmware pass. Decide per §4 whether to build them now or defer.
3. **v2.3 has never been hardware-validated.** Repo invariant: *bench-test before flash.*
Tomorrow is its first real bench test — treat step 1 (flash + confirm telemetry) as the gate
before trusting any later step.
**The one thing I couldn't verify:** your exact purchased parts. The two proto BOM `.xlsx`
(`watchdog-protoboard-BOM-3boards.xlsx`, `watchdog-LISTA-DE-COMPRAS-ES.xlsx`) are locked open in
LibreOffice, so I rebuilt the checklist (§3) from the design docs. Close LibreOffice and I'll diff
your actual list against it.
---
## 1. What you can prove tomorrow (firmware v2.3 supports it) vs. not
| Sub-circuit | Pins | v2.3 firmware | Testable tomorrow? |
|---|---|---|---|
| Boot + `$PHLG`/STREAM telemetry (USB) | USB-C | ✅ `ENABLE_PHLG=1` | **Yes** — this is the gate |
| Status LED (blink codes) | PB0 | ✅ | **Yes** |
| **RTK-stack load switch** (the recovery heart) | PA1 → 2N3904 → IRF9540 | ✅ OFF-at-reset, MCU-asserts-ON | **Yes** |
| Sense: battery / 5 V / ignition | PA0 / PA4 / PA5 | ✅ hysteresis + debounce | **Yes** |
| Smart fan (PWM) | PA6 · *(PB10 tach = DNP, fan in hand is 2-wire)* | ✅ 25 kHz PWM · RPM/stall **n/a** | **Yes** (PWM ramp; no tach) |
| I²C temp/RH — **AHT10 0x38, alone on the bus** [2026-07-03] | PB6/PB7 | ❌ v2.3 reads SHT40 0x44 → **AHT10 driver pending** (+ MCU-temp fallback works) | wire OK, **reads after firmware patch** |
| Analog temp ×2 — NTC→PB1 + **LM35→PA7** [2026-07-03] | PB1 / PA7 | ❌ channels not coded | wire OK, verify with multimeter meanwhile |
| 4-LED battery gauge | PB12–15 | ❌ not coded | wire OK, **stays dark** |
| Temp-qualified charge cut — **`CHRG_RUN`** [2026-07-03] | PA8 → 2N3904 → IRF9540N on TP4056 IN+ | ❌ not coded (**inverted vs PROD `CHRG_EN`** — needs flag) | wire OK; hand-test by jumpering PA8 high/low |
| Reset (hardware) | NRST | n/a (HW only) | **Yes** — button just works |
**Fan note [updated 2026-07-03]:** the fan in hand is **2-wire** → no tach; PB10 stays DNP and
v2.3's RPM/stall check reads nothing (harmless). Fan-fault will be inferred from temperature in
the firmware pass. PWM drive on PA6 through the IRLZ44N tests exactly the same.
---
## 2. The ERC situation (so you can stop worrying about it tonight)
- **What ERC actually reports on the DEV file:** 0 errors, 1 warning (`Q_NPN_BCE` not found in
lib `Device`). That warning means the symbol in your schematic is from the project cache and the
installed `Device` lib has a slightly different name/pins — **purely a library-link cosmetic**.
- **The GNDREF you may have seen:** there are **no placed GNDREF symbols** — only the leftover
symbol *definition* in the embedded cache. Your ground is one net.
- **Why it doesn't block the breadboard:** ERC validates a *netlist for fabrication*. On a
breadboard you tie all grounds together physically; off-grid placement and a cache-name mismatch
are invisible to copper you wire by hand.
- **Before PCB layout (later), clean these in KiCAD:** Tools → *Update Symbols from Library*
(clears the `Q_NPN_BCE` cache warning), then *Annotate* and re-run ERC; nudge any off-grid parts
onto the 1.27 mm grid. **Don't let me edit the schematic while you have KiCAD open** (file-lock
conflict) — close it first and I'll do the cleanup pass.
---
## 3. Pre-build parts checklist (reconstructed — confirm against your box)
**Already have (don't buy):** Blackpill STM32F411, USB-C cable, 18650 + PowerBoost (or bench PSU),
Mean Well SD-15B-05 (or bench 5 V), multimeter, a heat source (hair-dryer/cup of hot water) for the
fan test. *F9P + 4G master are NOT needed for this bring-up.*
**Core (the "brains" — must-have):**
- [ ] Breadboard ×2 (830-pt) + jumper kits (M-M and M-F)
- [ ] Resistor assortment incl. **330 Ω, 1 k, 4.7 k, 10 k, 100 k, 220 Ω**
- [ ] **2N3904** ×3 (load-switch driver, TO-92)
- [ ] **IRF9540 / IRF9540N** ×2 (P-FET high-side 5 V switch, TO-220)
- [ ] LED ×5 (status) · **100 nF** ceramic ×10 (ADC filters/decoupling) · 100 µF ≥16 V ×4 (bulk)
- [ ] **10 kΩ trim pot** ×2 + tactile button/slide switch ×2 (sweep VBAT / simulate ignition)
- [ ] Male header strip 1×40 (to pin any bare module)
**Thermal (v3 new):**
- [x] 5 V fan, 40–60 mm — **2-wire, in hand** [2026-07-03] (no tach; PB10 DNP)
- [ ] **IRLZ44N** ×2 (logic-level N-FET, fan low-side) — *plain IRF540/IRFZ44 won't turn on from
3.3 V; if out of IRLZ44N use 2N2222A/TIP120 + 1 kΩ base*
- [ ] **1N5819** ×3 (fan flyback; 1N4007 acceptable)
- [x] I²C **AHT10** breakout (0x38) — **in hand** [2026-07-03]; **alone on the bus**, 3V3 only;
firmware read patch pending (v2.3 speaks SHT40)
- [x] **LM35** (TO-92) — **in hand** [2026-07-03]; analog temp #2 on **PA7**, powered from 5 V
**v3 additions (build only if you want them wired now — see §4):**
- [ ] Reset: tactile button → NRST↔GND (+ optional 2-pin header for external reset)
- [ ] Battery gauge: **4× LED + 4× 330 Ω** on PB12–15 *(will stay dark until firmware)*
- [ ] Battery-backup stand-in: **TP4056** module + **MT3608** boost + **2× 1N5819** (OR-ing)
*(reproduces charge / power-loss→backup / BAT_SENSE)*. **[2026-07-03]** The kit's TP4056 has
**no TEMP pin** → the 10 kΩ charger-NTC is unused; the temp-qualified cutoff **is now on the
proto in hardware**: PA8 `CHRG_RUN` → 1 k → 2N3904 → IRF9540N (10 k pull-up) on TP4056 IN+
(HIGH = charge; MCU absent = no charge — inverted vs PROD). Plus the **cutoff switch**:
nodo SYS → SPST → MAIN5V (kills vehicle **and** battery)
---
## 4. Decision before you sit down: how much of v3 to wire
- **Recommended for tomorrow — build the testable core + thermal** (everything in §1 marked
*Yes*). It proves the whole watchdog logic and the new fan/temp loop, which is the point of the
proto. Add the **reset button** (free — works with no firmware).
- **Gauge (PB12–15):** wire it if you want the layout/feel, but it won't light until I write the
gauge driver. *Cheaper to add later.* — **I can write that firmware pass tonight/tomorrow if you
want the LEDs live.**
- **Battery-backup stand-in (TP4056+MT3608):** worth wiring if you specifically want to watch
power-loss → backup hand-off and `BAT_SENSE` track the cell. Skip if tomorrow is about the
watchdog logic only.
---
## 5. Bring-up sequence (run in order — each step gates the next)
1. **USB only — flash & gate.** Compile v2.3 (Arduino IDE / STM32duino, board = Blackpill F411CE),
flash via DFU (hold BOOT0). Open serial @115200. **Confirm `BOOT` / `COLS` / `TLM` lines and a
`$PHLG,...*CS` every 30 s.** If this fails, stop and fix firmware before wiring anything.
2. **Status LED** — PB0 → 330 Ω → LED → GND. Watch blink codes change with state.
3. **Load switch (the recovery heart)** — PA1 → 1 kΩ → 2N3904 base; collector → IRF9540 gate;
10 kΩ gate→5 V; drain → switched 5 V; put an LED+330 Ω on the switched output.
**Confirm: OFF at reset, ON when PA1 asserts.** (Power-off is the safe state.)
4. **Sense dividers** — 10 k/10 k ÷2 into **PA0** (battery via 18650/pot) and **PA4** (5 V rail);
10 kΩ pot into **PA5** (ignition). Sweep and watch `veh`/`ign`/`vbat` flip in TLM with
hysteresis (V5V_ON 4.20 / V5V_OFF 3.80; BAT_CRIT 3.40 / BAT_REC 3.70).
5. **Fan + tach** — PA6 → 220 Ω → IRLZ44N gate; fan(−) at the drain; 1N5819 ∥ fan; 100 kΩ
gate→GND. 3-wire tach → 10 kΩ pull-up to 3V3 → PB10. Watch it spin/ramp; **unplug fan →
`fan_fault`** in telemetry.
6. **I²C temp** — SHT40/TMP102 on PB6/PB7 (+4.7 kΩ pull-ups each). Heat it → fan ramps on the
45→70 °C curve. *No sensor? The MCU-temp fallback still ramps the fan — warm the whole board.*
7. **(Optional) reset button** — NRST↔GND momentary; press → clean reboot, reset-cause line in log.
8. **(Optional) battery-backup stand-in** — vehicle 5 V → TP4056 IN; cell on TP4056 BAT; TP4056/cell
→ MT3608 → 5 V via 1N5819 OR-ing into the rail; NTC by the cell. Pull vehicle 5 V → watch backup
hold the rail and `BAT_SENSE` track.
---
## 6. Wiring cheat-sheet (Blackpill side, v3)
```
PA0 ← BAT ÷2 (10k/10k) from 18650+ / pot PA6 → 220Ω → IRLZ44N gate; fan(−); 1N5819 ∥ fan
PA4 ← 5V ÷2 (10k/10k) from 5V rail PB10 ← fan tach, 10k pull-up → 3V3
PA5 ← IGN ÷2 (10k/10k) from pot/switch PB6/PB7 → I²C SCL/SDA (+4.7k each → 3V3)
PA1 → 1k → 2N3904 base; collector → IRF9540 PB0 → 330Ω → LED → GND
gate; 10k gate→5V; drain → switched 5V NRST ← reset button → GND (optional)
→ stack (LED+330Ω as a test load) PB12–15 → 330Ω → LED → GND (gauge; dark till FW)
GND / 5V / 3V3 rails common. Fan 5V from a SEPARATE 5V (2nd PSU / LM2596) — not the switched stack rail.
```
> **Proto↔PCB part map (don't get confused):** the schematic uses SMD equivalents (Q1 **AO3401A**
> P-FET, Q5 **MMBT3904**, Q2 **AO3400A** fan FET). On the breadboard you use the through-hole
> stand-ins above (**IRF9540N / 2N3904 / IRLZ44N**) — same topology, same firmware.
---
## 7. After the proto works — next steps (not tomorrow)
- Firmware pass: gauge-LED driver (PB12–15 from `BAT_SENSE`) + `CHRG_EN` cut-charge-when-hot logic.
- KiCAD: cosmetic ERC cleanup → footprints → **then** PCB layout (DEV first, then build PROD per
[[watchdog-production-schematic-delta]]).
- Pack Ah confirmed **~12 Ah** (2026-06-30; "40 Ah" label was wrong) — sizes the LTC4040 charge current (≈C/5, ≤2.5 A).
## Related
[[watchdog-electrical-design-state]] (CANONICAL) · [[watchdog-protoboard-bringup]] (Jun-22 shop
list) · [[watchdog-production-schematic-delta]] (PROD build spec) · `kicad/hbox-watchdog-v3.kicad_sch`

130
docs/procedimientos/historico-protoboard.md Normal file
View File

@ -0,0 +1,130 @@
---
tags: [project-drogheda, hardware, watchdog, prototype, breadboard, bom, bring-up]
project: Project Drogheda
author: Helgen CTO
date: 2026-06-22
status: Active — shop list for the Blackpill bring-up
---
# Watchdog Bring‑up — Protoboard Shopping List (print me)
> **⚠ SUPERSEDED for sensors (2026-07-03):** the proto suite is now **AHT10 (0x38, alone on
> I²C1, 3V3) + LM35→PA7 + NTC→PB1** — no SHT40/SHT31/BME280/TMP102 on the proto (PCB-only).
> Charge cutoff = **PA8 `CHRG_RUN`** on the TP4056 IN+ (the kit module has no TEMP pin).
> Current shop lists = `watchdog-protoboard-BOM-3boards.xlsx` / `watchdog-LISTA-DE-COMPRAS-ES.xlsx`;
> wiring = ledger xlsx + Guía v2.2. The sensor/substitute rows below are kept for history only.
> Goal: breadboard the v2.2 watchdog on your **existing Blackpill**, prove the
> state machine + sensing + load switch + fans + temp loop, **before** any PCB.
> All parts are **through‑hole / breadboard‑friendly** and stocked at a normal MX
> electronics shop (Steren / AG Electrónica / local). Quantities include spares.
> Pin map: [[03-Architecture-Hardware/watchdog-pcb-v3-design#2|design §2]] ·
> firmware: `blackpillrtkcode_v2.ino` (v2.2).
## 0. Already have — do NOT buy
STM32F411 Blackpill · USB‑C/micro cable · 18650 + PowerBoost · Mean Well SD‑15B‑05
(or a bench PSU) · multimeter · the F9P + 4G master (only needed later, not for the
bring‑up). A **heat source** (hair dryer / lighter / hot water cup) to trigger the
thermal/fan test — household, no need to buy.
---
## 1. Core — bring up the "brains" (buy this even if the shop is sparse)
| # | Item | Qty | Value / part | ~MXN | For |
|---|---|---|---|---|---|
| 1 | Breadboard 830‑pt | 2 | half/full | 120 | build surface (2 = room for fans/sensors) |
| 2 | Jumper wires M‑M | 1 pk | 65 pcs | 60 | board wiring |
| 3 | Jumper wires M‑F | 1 pk | 40 pcs | 50 | to Blackpill / modules |
| 4 | Resistor assortment box | 1 | ¼ W (incl. 330Ω,1k,4.7k,10k,100k,220Ω) | 120 | dividers, gates, pull‑ups |
| 5 | LED (any) | 5 | 3/5 mm | 10 | status LED on PB0 |
| 6 | Ceramic cap 100 nF | 10 | 0.1 µF (104) | 20 | ADC filters + decoupling |
| 7 | Electrolytic 100 µF / ≥16 V | 4 | — | 20 | rail bulk / modem‑burst reservoir |
| 8 | **2N3904** (NPN, TO‑92) | 3 | load‑switch driver | 15 | PA1 → P‑FET gate |
| 9 | **IRF9540 / IRF9540N** (P‑MOSFET, TO‑220) | 2 | high‑side 5 V switch | 40 | switched 5 V to "stack" |
| 10 | **10 kΩ trim pot** | 2 | breadboard trimmer | 30 | sweep VBAT / ignition to test thresholds |
| 11 | Tactile button or slide switch | 2 | — | 20 | simulate ignition on/off |
| 12 | Male header strip | 1 | 1×40, 2.54 mm | 15 | solder onto any module that needs pins |
**Core subtotal ≈ 520 MXN.** With this you can flash v2.2, watch the `$PHLG`/TLM log,
and validate the **load switch + the three sense dividers + LED** — the whole watchdog
logic — without the thermal parts.
---
## 2. Thermal add‑ons — fans + temperature (the v3 new stuff)
| # | Item | Qty | Value / part | ~MXN | For / note |
|---|---|---|---|---|---|
| 13 | 5 V fan, 40–60 mm, **3‑wire** | 1 | 3‑wire = has tach | 60 | one extraction fan; 3‑wire so PB10 reads RPM. Grab a 2nd as a spare if cheap |
| 14 | **IRLZ44N** (logic‑level N‑MOSFET, TO‑220) | 2 | fan low‑side PWM | 30 | 1 + spare; **must be logic‑level**; see substitute below |
| 15 | Schottky **1N5819** | 3 | fan flyback | 10 | one across the fan (1N4007 ok if out) |
| 16 | I²C temp+RH breakout | 1 | **SHT31 / SHT40** ideal | 120 | matches firmware (0x44). RH catches condensation |
| 17 | Analog temp **LM35** (TO‑92) | 2 | sure‑thing fallback | 25 | every shop has it; heat it → watch fans ramp |
| 18 | **DS18B20** waterproof probe | 1 | 1‑wire | 45 | great as the battery/modem hot‑spot probe |
| 19 | LM2596 buck module (adj.) | 1 | 24/12 → 5 V | 35 | dedicated **fan 5 V** rail (caveat §0a) if no 2nd bench PSU |
**Thermal subtotal ≈ 260 MXN** (one fan + driver + one temp option). Grab #13–15 for the fan, and **one** temperature option
(#16 ideal, else #17/#18).
---
## 3. Substitutions (shop stock varies — these all work)
| If they're out of… | Buy instead | Catch |
|---|---|---|
| IRLZ44N (logic‑level FET) | **2N2222A** (TO‑92) or **TIP120** (Darlington) | BJT: add 1 kΩ base resistor; fine for a <0.5 A fan. **Plain IRF540/IRFZ44 won't fully turn on from 3.3 V — avoid.** |
| SHT31/SHT40 I²C breakout | **BME280/BMP280** (I²C, common) | address 0x76/0x77 → small firmware change |
| Any I²C sensor | **LM35** (analog) or **DS18B20** (1‑wire) | not I²C → firmware reads ADC / 1‑wire instead (I'll patch it) |
| IRF9540 P‑MOSFET | keep your original, or **2N2222 high‑side** is awkward — ask for any P‑channel ≥30 V | gate fully pulled to GND by the 2N3904, so a standard P‑FET is OK here |
| 1N5819 Schottky | **1N4007** | slightly slower; fine at fan PWM |
---
## 4. Bring‑up order (so the list maps to actions)
1. **Just USB** — flash v2.2, open serial @115200. Confirm `BOOT/COLS/TLM` lines **and a
`$PHLG,...*CS` every 30 s**. (No external parts — this proves the firmware.)
2. **LED on PB0** via 330 Ω → watch the blink codes change with state.
3. **Load switch** — 2N3904 + IRF9540 + 1 kΩ (base) + 10 kΩ (gate pull‑up) from a 5 V rail;
put an LED+330 Ω on the switched output. Toggle: confirm **OFF at reset**, ON when PA1
drives. (This is the heart of recovery.)
4. **Sense dividers** — two 10 kΩ each (÷2) into **PA0** (battery via 18650) and **PA4**
(5 V rail); a 10 kΩ pot into **PA5** (ignition). Sweep them and watch `veh`/`ign` flip in
the TLM with hysteresis/debounce.
5. **Fan** — PA6 → gate (220 Ω) of IRLZ44N → fan(−); flyback diode across the fan;
100 kΩ gate→GND. Watch it spin/ramp; tach wire → 10 kΩ pull‑up to 3V3 → PB10 →
RPM in the log; **unplug the fan → `FAN_FAULT`**.
6. **Temperature** — I²C breakout on PB6/PB7 (+4.7 kΩ pull‑ups), or LM35 on an ADC pin.
Heat it → fans ramp per the 45→70 °C curve; at 75 °C the existing thermal derate kicks in.
---
## 5. Wiring cheat‑sheet (Blackpill side)
```
PA0 ← BAT ÷2 (10k/10k) from 18650+ PA6 → 220Ω → IRLZ44N gate; fan(−); 1N5819 ∥ fan
PA4 ← 5V ÷2 (10k/10k) from 5V rail PB10 ← fan tach, 10k pull-up → 3V3 (1k series)
PA5 ← IGN ÷2 (10k/10k) from pot/switch PB6/PB7 → I²C SCL/SDA (+4.7k each → 3V3)
PA1 → 1k → 2N3904 base; collector → IRF9540 PB0 → 330Ω → LED → GND
gate; 10k gate→5V; drain → switched (PA7/PB12 left free — 2nd fan if ever needed)
5V → stack (use an LED load to test)
GND/5V/3V3 rails common; fan 5V from a SEPARATE 5V (LM2596 or 2nd PSU) — not the stack rail.
```
---
## 6. Note on the temp sensor + firmware
The v2.2 firmware reads **I²C SHT40 (0x44) + TMP102 (0x48)**. Whatever you bring back:
- **SHT31/SHT40** → works as‑is (SHT40) or a 1‑line address tweak (SHT31).
- **BME280** → change address + read call.
- **LM35 / DS18B20** → analog / 1‑wire; tell me which and I'll patch `buildPHLG()` +
the fan‑curve input to read it. For *tomorrow's* bring‑up the fan loop can also be
driven off the **MCU‑internal** temp (already in firmware) — heat the whole board and
the derate still triggers, so you can prove the fan path even before the sensor arrives.
## Related
- **3-board PROTO BOM (use this for bring-up):** `watchdog-protoboard-BOM-3boards.xlsx` (engineering, ≈MXN 5,341) + `watchdog-LISTA-DE-COMPRAS-ES.xlsx` (plain-Spanish shop list). **v3 adds:** reset (on-board + external), 4-LED battery gauge, power-cutoff switch, and battery backup (proto: TP4056+MT3608+OR-diodes+NTC; PCB: **LTC4040**). Canonical electrical state: [[03-Architecture-Hardware/watchdog-electrical-design-state|watchdog-electrical-design-state.md]].
- [[03-Architecture-Hardware/watchdog-pcb-v3-bom|v3 BOM (production + bench, xlsx)]] ·
[[03-Architecture-Hardware/watchdog-pcb-v3-design|v3 design (pin map, sub‑circuits)]] ·
`04-Source-Code/firmware/blackpillrtkcode_v2/blackpillrtkcode_v2.ino`

311
docs/procedimientos/v5-prueba-y-flasheo.md Normal file
View File

@ -0,0 +1,311 @@
---
title: EinarBoard v5 (HBOX v5) — Procedimiento de prueba y flasheo por tarjeta
tags: [project-drogheda, hardware, einarboard, v5, bringup, testing, flasheo, procedimiento]
project: Project Drogheda
author: Helgen Technologies
date: 2026-09-15
version: 1.0
status: ACTIVO — aplicar a cada una de las 15 tarjetas del lote JLC 22-Ago-2026
audience: técnicos de banco
---
# EinarBoard v5 — Procedimiento de prueba y flasheo
**Lote:** 15 tarjetas `hbox-watchdog-v5` (JLCPCB, pedido 22-Ago-2026).
**Objetivo:** verificar que cada tarjeta enciende sin cortos, que sus rieles están en valor,
y dejarla flasheada con el firmware de arranque entregado por ingeniería.
**Duración estimada:** 15–20 min por tarjeta.
> ⛔ **REGLA 1 — NO flashear `blackpillrtkcode_v3` (v3.0.3) en esta tarjeta.**
> Ese firmware es para la EinarBoard 1.0 (Blackpill). En la v5 usa los pines PB12–PB15 como
> LEDs de batería, pero en esta tarjeta esos pines son el bus SPI del chip Ethernet (W5500).
> Solo se flashea el archivo `.bin` que entregue ingeniería para v5.
>
> ⛔ **REGLA 2 — Sin batería y sin módulos en estas pruebas.** No conectar nada en P4
> (batería), ni insertar el simpleRTK2B en MOD1, ni el módem 4G en J7/J8.
>
> ⛔ **REGLA 3 — Fuente de banco siempre con límite de corriente.** Si la corriente llega al
> límite o un componente se calienta: apagar, marcar la tarjeta como FALLA y pasar a la siguiente.
---
## 0. Material
| Cant. | Ítem |
|---|---|
| 1 | Multímetro (continuidad / V DC) |
| 1 | Fuente de banco 0–30 V con límite de corriente ajustable |
| 1 | Cable USB-C ↔ USB-C (o USB-A ↔ USB-C) **con datos** (no solo carga) |
| 1 | Laptop con **STM32CubeProgrammer** instalado (o `dfu-util` en terminal) |
| 1 | Archivo de firmware: **`hbox-v5-bringup_0.1.0.bin`** (repo: `04-Source-Code/firmware/hbox_v5_bringup/release/`, SHA-256 inicia `1a9a77ae`) |
| 1 | Jumper 2.54 mm para P11 (interruptor de corte) |
| 1 | Lupa o lámpara con aumento |
| — | Hoja de registro (sección 7) |
**Identificación en la tarjeta** (serigrafía):
| Ref. | Qué es | Dónde se usa |
|---|---|---|
| **J11** | USB-C **DFU** (junto a SW1/SW2 y J10 Ethernet) | Alimentar solo el MCU y flashear |
| **J9** | USB-C del **módem** | NO se usa en este procedimiento |
| **SW1** | Botón **RESET** | Reiniciar el MCU |
| **SW2** | Botón **BOOT0** | Entrar en modo DFU |
| **TP7 / TP6** | Puntos de prueba **3V3 / GND** | Medir el riel de 3.3 V |
| **TP3 / TP4 / TP5** | SWDIO / SWCLK / NRST | Solo si ingeniería pide programar por ST-Link |
| **P2** | Entrada **5 V** (donde va la Mean Well SD-15B) | Prueba del riel de 5 V |
| **P1** | Entrada **24 V** (GX16) — pin 1 = +24 V, pin 2 = GND | Prueba del buck del ventilador |
| **P11** | Header **CUTOFF-SW** (2 pines) | Puentear para que pase MAIN5V → SYS5V |
| **P6** | Header del ventilador (2 pines) — pin 1 = +5V_FAN, pin 2 = retorno conmutado | Medir salida del buck (pin 1 contra GND) |
| **MOD1** | Zócalo UNO del simpleRTK2B — pin **"5V"** | Verificar que la etapa RTK arranca **apagada** |
| **D18** | LED verde **PWR** | Enciende cuando hay 3.3 V |
| **D17** | LED azul **C13** | Lo controla el firmware (apagado en chip virgen) |
| **U17** | Regulador AMS1117 3.3 V | Tocar para verificar temperatura |
| **Y2** | Cristal **3.6864 MHz** (HC-49, marcado `3.6864` / `36.864`) | Verificación visual |
---
## 1. Inspección visual (sin energía) — 3 min
Con lupa, en cada tarjeta:
- [ ] No hay puentes de soldadura visibles entre pines de **U16** (MCU, 64 pines), **U11**
(W5500), **U10** (SC16IS752), **U6** (LTC4040).
- [ ] **Y2** dice `3.6864` (o `36.864`). Los otros tres cristales: **Y1** y **Y3** = `25.000`,
**Y4** = pequeño de 32.768 kHz. Si Y2 dice `1.8432` → marcar y avisar a ingeniería.
- [ ] Botones **SW1** y **SW2** presentes y con "clic".
- [ ] Conectores **J11**, **J9**, **J10 (RJ45)** bien asentados, sin pines doblados.
- [ ] Jumpers de configuración del cargador presentes: **JP2, JP3, JP4** (no tocar su posición).
- [ ] Sin componentes faltantes evidentes ni marcas de quemado.
---
## 2. Continuidad — cortos a tierra (sin energía) — 2 min
Multímetro en **ohms** (no en modo continuidad/beep, porque los capacitores dan lecturas
transitorias). Punta negra en **TP6 (GND)**. Esperar a que la lectura se estabilice.
| Medir en | Riel | Esperado | Si es < 100 Ω |
|---|---|---|---|
| **TP7** | 3V3 | > 1 kΩ (la lectura sube lentamente) | FALLA — corto en 3.3 V |
| **P2 pin 1** | VEH5V (entrada 5 V) | > 1 kΩ | FALLA — corto en entrada 5 V |
| **P11 pin 1** | MAIN5V | > 1 kΩ | FALLA — corto en 5 V del sistema |
| **P1 pin 1** | 24V_IN | > 10 kΩ | FALLA — corto en 24 V |
| **MOD1 pin "5V"** | SW_5V (etapa RTK) | > 1 kΩ | FALLA |
> Nota: es normal ver lecturas de unos cientos de ohms **que van subiendo** — son los
> capacitores cargándose con el multímetro. Lo que NO es normal es una lectura fija de 0–20 Ω.
---
## 3. Prueba del riel de 3.3 V por USB (J11) — 3 min
Con USB solo se energiza el MCU y la lógica de 3.3 V; el riel de 5 V del sistema queda apagado.
Es la forma más segura de encender la tarjeta por primera vez.
1. Conectar el cable USB-C en **J11** (el que está junto a los botones), otro extremo a la laptop
o a un cargador USB.
2. Verificar:
| Punto | Esperado |
|---|---|
| **D18** (LED verde PWR) | **Encendido** |
| **TP7** respecto a TP6 | **3.20 – 3.40 V** |
| **U17** (AMS1117) al tacto tras 1 min | Tibio, se puede tocar. **Si quema → FALLA** |
| **D17** (LED azul) | Apagado o fijo (chip virgen — normal) |
3. Si D18 no enciende o TP7 < 3.0 V → desconectar, marcar **FALLA (3V3)**.
4. **Dejar el USB conectado** para la sección siguiente.
---
## 4. Prueba de rieles de 5 V y 24 V con fuente de banco — 5 min
Se hace **con el MCU virgen (sin firmware)**: así todos sus pines quedan en alta impedancia y la
etapa RTK permanece apagada por diseño. Esto es lo que se está verificando.
### 4a. Riel de 5 V (entrada P2)
1. Fuente de banco: **5.0 V, límite 500 mA**, salida apagada.
2. Colocar el **jumper en P11** (CUTOFF-SW).
3. Conectar fuente a **P2**: pin 1 = +5 V, pin 2 = GND. (Puede quedarse el USB en J11.)
4. Encender la salida y medir:
| Punto | Esperado |
|---|---|
| Corriente de la fuente | **< 300 mA** (típico 100–250 mA) |
| **P11 pin 1** (MAIN5V) | 4.8 – 5.1 V |
| **P11 pin 2** (SYS5V, con jumper) | 4.8 – 5.1 V |
| **TP7** (3V3) | 3.20 – 3.40 V |
| **MOD1 pin "5V"** (SW_5V, etapa RTK) | **0 V** ← obligatorio. Si hay 5 V aquí → FALLA (etapa RTK no arranca apagada) |
| **U6** (LTC4040), **U12** (buck Ethernet) al tacto | Tibios, no queman |
5. Apagar la salida de la fuente. Desconectar de P2.
### 4b. Riel de 24 V → buck del ventilador (entrada P1)
1. Fuente de banco: **24.0 V, límite 200 mA**, salida apagada.
2. Conectar a **P1**: pin 1 = +24 V, pin 2 = GND. **Pin 3 (ignición) sin conectar.**
3. Encender la salida y medir:
| Punto | Esperado |
|---|---|
| Corriente de la fuente | **< 50 mA** (sin ventilador) |
| **P6 pin 1** (5V_FAN) respecto a **TP6 (GND)** | **4.9 – 5.1 V** (no medir contra P6 pin 2: es el lado conmutado del ventilador) |
| **U2** (buck) al tacto | Frío o tibio |
4. Apagar salida. Desconectar de P1. Quitar el jumper de P11 (opcional; puede dejarse).
> Si algún valor está fuera de rango: marcar FALLA con la sección (4a o 4b) y el valor medido.
> **No flashear una tarjeta con FALLA.**
---
## 5. Flasheo por USB DFU (J11) — 5 min
Solo para tarjetas que pasaron las secciones 1 a 4.
### 5a. Entrar en modo DFU
1. Solo el **USB en J11** conectado a la laptop (nada en P1/P2).
2. **Mantener presionado SW2 (BOOT0).**
3. Sin soltar SW2, **presionar y soltar SW1 (RESET)**.
4. **Soltar SW2.**
5. La laptop debe detectar un dispositivo **"STM32 BOOTLOADER"** (ID `0483:DF11`).
> El chip viene **vacío de fábrica**: no hace nada hasta que se flashea, y **solo** entra al
> programador con esta secuencia de botones. Si no aparece el dispositivo: cambiar el cable
> USB (muchos son solo de carga), repetir la secuencia con calma (SW2 debe estar presionado
> cuando se suelta SW1).
### 5b. Flashear con STM32CubeProgrammer (recomendado)
1. Abrir **STM32CubeProgrammer**.
2. Arriba a la derecha, en el selector de conexión elegir **USB**. Pulsar el botón de refrescar;
debe aparecer `USB1`. Pulsar **Connect**.
3. Ir a la pestaña **Erasing & Programming** (icono de flecha hacia abajo, lado izquierdo).
4. **File path** → seleccionar `hbox-v5-bringup_0.1.0.bin`.
5. **Start address** = `0x08000000`. Marcar **Verify programming** y **Run after programming**.
6. Pulsar **Start Programming**. Esperar "File download complete" y "Verify… successful".
7. Pulsar **Disconnect**.
### 5c. Alternativa por terminal (`dfu-util`, macOS/Linux)
```bash
dfu-util -l # debe listar [0483:df11]
dfu-util -a 0 -s 0x08000000:leave -D hbox-v5-bringup_0.1.0.bin
```
### 5d. Verificación después del flasheo
1. Abrir un terminal serie en la laptop (CoolTerm, Serial, `screen`, o el monitor de Arduino)
y dejarlo listo. Pulsar **SW1** (RESET) una vez.
2. Esperado en los primeros 5 segundos:
| Punto | Esperado |
|---|---|
| **D17** (LED azul) + LED de panel en P8 (si hay) | **Parpadean** a 1 Hz (MCU ejecutando el firmware) |
| **DB1 → DB4** (LEDs del indicador de batería) | Se encienden **en secuencia** una vez, luego se apagan; después R, G, B en P14 si hay LED RGB conectado |
| Laptop | Aparece un **puerto serie** nuevo ("STMicroelectronics Virtual COM Port" / `usbmodem…`) |
| Terminal serie a **115200 baud** | Encabezado `hbox-v5-bringup 0.1.0`, luego líneas `[PASS]` / `[FAIL]`, y al final **`>>> BOARD OK`** |
3. Si el terminal se abrió tarde y no se vio el reporte: teclear **`r`** en el terminal → repite
todas las pruebas (y vuelve a encender los LEDs en secuencia).
4. Reporte esperado (todas `[PASS]`):
```
[PASS] CLOCK_HSE SYSCLK=96000000 Hz HSE_RDY=1 PLL_SRC=HSE ← cristal Y3 y USB OK
[PASS] LSE_Y4 Y4 32.768k LSERDY=1 ← cristal Y4 OK
[PASS] I2C PCF8574 U13 @0x20 ACK
[PASS] I2C SHT40 U3 @0x44 ACK
[PASS] I2C TMP102 U4 @0x48 ACK
[PASS] I2C SC16IS752 U10 @0x4D ACK
[PASS] TMP102 TMP102 27.50 C
[PASS] SHT40 SHT40 27.8 C 45.0 %RH
[PASS] SC16IS752 0x4D ACK, SPR rd=0xA5 (exp A5), LSR=0x60
[PASS] GAUGE_WALK visual — technician confirms ← el técnico confirma que vio DB1→DB4
[PASS] ADC vbat=0.00 v5=0.00 ntc=..C mcu=..C ← vbat y v5 en 0 es NORMAL con solo USB
[PASS] DIN ign=0 chrg=.. fault=.. ser_irq=1 eth_int=..
---- RESULT: 12 PASS / 0 FAIL ----
>>> BOARD OK
```
Después imprime una línea `STAT …` cada 2 s con temperaturas y voltajes — es normal.
5. Cualquier `[FAIL]` → anotar la línea completa en la hoja de registro y marcar **FALLA (POST)**.
El LED azul que no parpadea → repetir 5a–5b una vez; si vuelve a fallar → **FALLA (FLASH)**.
> Este firmware **no enciende la etapa RTK ni el cargador**: solo prueba la tarjeta. El firmware
> de producción v5 se flashea después, por el mismo procedimiento DFU.
---
## 6. Cierre de la tarjeta
- [ ] Desconectar USB.
- [ ] Etiquetar la tarjeta con su número de serie (**V5-01 … V5-15**) y fecha, en la esquina
cerca de MH4 (sin tapar serigrafía ni componentes).
- [ ] Llenar la hoja de registro.
- [ ] Guardar en bolsa antiestática. Las tarjetas con FALLA van en bolsa aparte con la nota
del punto que falló.
---
## 7. Hoja de registro del lote
| Tarjeta | Visual (1) | Cortos (2) | 3V3 USB (3) | 5 V (4a) | 24 V (4b) | DFU (5a) | Flash (5b) | Post-flash (5d) | OK / FALLA | Técnico | Fecha |
|---|---|---|---|---|---|---|---|---|---|---|---|
| V5-01 | | | | | | | | | | | |
| V5-02 | | | | | | | | | | | |
| V5-03 | | | | | | | | | | | |
| V5-04 | | | | | | | | | | | |
| V5-05 | | | | | | | | | | | |
| V5-06 | | | | | | | | | | | |
| V5-07 | | | | | | | | | | | |
| V5-08 | | | | | | | | | | | |
| V5-09 | | | | | | | | | | | |
| V5-10 | | | | | | | | | | | |
| V5-11 | | | | | | | | | | | |
| V5-12 | | | | | | | | | | | |
| V5-13 | | | | | | | | | | | |
| V5-14 | | | | | | | | | | | |
| V5-15 | | | | | | | | | | | |
Anotar el valor medido cuando esté fuera de rango (ej. "TP7 = 2.9 V").
---
## Anexo A — Notas de ingeniería (no requeridas para el técnico)
Verificado contra `hbox-watchdog-v5.kicad_pcb` / `.kicad_sch` (netlist, 15-Sep-2026):
- **Alimentación por J11:** VBUS → D13 (SS34) → `/LDO_IN` → U17 AMS1117 → `/3V3`. `/SYS5V`
queda apagado, por lo tanto U12 y `/3V3_ETH` (W5500) quedan apagados. R100/R101 (5.1 k en CC)
presentes: un cable C-a-C entrega VBUS.
- **DFU:** BOOT0 = pin 60 de U16, pull-down R98 10 k, SW2 lo lleva a 3V3. `/BOOT1_STRAP`
(PB2, pin 28) fijo a GND por R99 10 k. HSE = Y3 25 MHz en PH0/PH1 (el bootloader ROM lo
requiere, AN2606). USB en PA11/PA12 (pines 44/45) con ESD D14/D15.
- **SWD:** TP3 SWDIO (PA13), TP4 SWCLK (PA14), TP5 NRST, TP6 GND, TP7 3V3.
- **Colisión firmware v3.0.3 ↔ v5 (única encontrada):** `PIN_BATLED1..4` = PB12–PB15 (pines
33–36) = `/ETH_CS`, `/ETH_SCK`, `/ETH_MISO`, `/ETH_MOSI` (SPI2 del W5500). PB14 es salida del
W5500. El indicador de batería en v5 está en U13 PCF8574 (A0–A2 a GND → dirección I²C
0x20, salidas P0–P3 → RB1–RB4 120 R → LEDs). Todo el resto del mapa de pines de v3 coincide
con v5: PA0 BAT_SENSE, PA1 PWR_CTRL, PA2/PA3 GNSS, PA4 5V_SENSE, PA5 IGN_SENSE, PA6 FAN_PWM,
PA8 CHRG_EN, PA9/PA10 USART1, PB0 EXT_LED, PB1 NTC, PB3 CHRG_STAT, PB4 CHRG_FAULT,
PB5 BYP_CTRL, PB6/PB7 I²C1, PC13 LED (activo bajo, R102 1 k a 3V3), PB10 tach = NC.
- **Pines de v5 que v3 no conoce (firmware v5 debe manejarlos):** PC0 `/ETH_INT`,
PA15 `/ETH_RST` (sin pull-up: flota si el MCU no lo maneja), PB8 `/SER_IRQ` (SC16IS752),
PC14/PC15 LSE 32.768 kHz (Y4). `/SER_RSTn` sí tiene pull-up R80 10 k.
- **Cristales (BOM = maestro):** Y2 = C2238 X49SM36864MSD2SC-1 = **3.6864 MHz** para el
SC16IS752 (`XTAL_FREQ 3686400`); el campo "1.8432MHz" del esquemático/BOM es un error de
etiqueta. Y1 (W5500) y Y3 (HSE del MCU) = C14872 X49SM25MSD2SC = **25 MHz**, confirmados contra el BOM de ensamble en JLCPCB. Y4 = 32.768 kHz LSE.
- **Estado del archivo KiCad vs tarjetas fabricadas:** el `.kicad_pcb` vivo tiene 35 huellas
movidas después del pedido (commits 24-Ago y 07-Sep: reubicación de la zona Ethernet/DFU
J10/U11/U12/Y1/C90–C103/J11, D14–D16, R20, C101). La netlist no cambió. La referencia
física de este lote es `production/HBOX_v5_PROD.zip` (22-Ago). En las tarjetas recibidas
D14–D16 están junto al MCU, no junto a J11.
- **Buck del ventilador U2 se habilita solo:** `/EN_FAN` = divisor Ren1 100 k / Ren2 20 k desde
`/24V` (≈4 V con 24 V de entrada), no depende del MCU → la prueba 4b es válida con chip virgen.
`/FAN_RET` es el lado bajo conmutado por Q2 (gate desde PA6): con MCU virgen queda abierto.
- **Objetivo de compilación del firmware v5:** `STMicroelectronics:stm32:GenF4:pnum=GENERIC_F411RETX`
(no `BLACKPILL_F411CE`), `HSE_VALUE=25000000` con `SystemClock_Config` explícito en HSE para
que el USB CDC tenga reloj exacto.

56
mkdocs.yml Normal file
View File

@ -0,0 +1,56 @@
site_name: HBOX — Documentación Técnica
site_description: Procedimientos de banco, montaje y diagnóstico del HBOX (EinarBoard) — Helgen Technologies
site_url: https://docs.helgen.online/hbox/
copyright: "© Helgen Technologies — uso interno"
theme:
name: material
language: es
palette:
- scheme: default
primary: deep orange
accent: deep orange
toggle:
icon: material/weather-night
name: Modo oscuro
- scheme: slate
primary: deep orange
accent: deep orange
toggle:
icon: material/weather-sunny
name: Modo claro
features:
- navigation.sections
- navigation.top
- search.highlight
- content.code.copy
- toc.integrate
markdown_extensions:
- admonition
- tables
- attr_list
- pymdownx.details
- pymdownx.superfences
- pymdownx.tasklist:
custom_checkbox: true
- toc:
permalink: true
nav:
- Inicio: index.md
- Procedimientos de banco:
- "EinarBoard v5 — Prueba y flasheo (lote 15 pzas)": procedimientos/v5-prueba-y-flasheo.md
- "EinarBoard 1.0 — Bring-up runbook": procedimientos/einarboard-1.0-bringup.md
- "FW v3.0.3 — Prueba de banco (política de ventilador)": procedimientos/fan-policy-bench-test.md
- "Histórico — Proto bench v3": procedimientos/historico-proto-bench-v3.md
- "Histórico — Protoboard": procedimientos/historico-protoboard.md
- Montaje y arneses:
- "Pinout de arneses y conectores": montaje/pinout-arneses.md
- "BOM dividido para ensamble": montaje/bom-split.md
- "Guía de ensamble (PDF)": montaje/assembly-guide.md
- Diagnóstico:
- "Protocolo de diagnóstico remoto": diagnostico/protocolo-diagnostico-remoto.md
- Git:
- "Guía Git (español)": git/guia-git-es.md
- "Git guide (English)": git/git-guide-en.md

14
scripts/deploy.sh Executable file
View File

@ -0,0 +1,14 @@
#!/usr/bin/env bash
# Construye el sitio y lo sube al servidor de Helgen por rsync/ssh.
# Uso: ./scripts/deploy.sh [usuario@servidor] [ruta-remota]
# Requiere: pip install mkdocs-material y llave SSH hacia el servidor.
set -euo pipefail
cd "$(dirname "$0")/.."
REMOTE="${1:-git@git.helgen.online}"
REMOTE_PATH="${2:-/var/www/hbox-docs}"
PORT="${SSH_PORT:-222}"
mkdocs build --strict
rsync -az --delete -e "ssh -p $PORT" site/ "$REMOTE:$REMOTE_PATH/"
echo "Publicado en $REMOTE:$REMOTE_PATH (puerto $PORT)"

32
scripts/sync-docs.sh Executable file
View File

@ -0,0 +1,32 @@
#!/usr/bin/env bash
# Sincroniza el subconjunto de técnicos desde el repo Drogheda (el padre de este submódulo)
# hacia docs/. Ejecutar desde la raíz de hbox-docs: ./scripts/sync-docs.sh
# La lista de abajo ES la política de publicación: lo que no está aquí, no se publica.
set -euo pipefail
cd "$(dirname "$0")/.."
SRC="${DROGHEDA_ROOT:-..}" # hbox-docs vive como submódulo directo de Drogheda
declare -a MAP=(
"06-Testing-Validation/2026-09-15_Drogheda_EinarBoard-v5_Procedimiento-Prueba-y-Flasheo_ES_v1.0.md|docs/procedimientos/v5-prueba-y-flasheo.md"
"06-Testing-Validation/2026-07-08_Drogheda_EinarBoard-1.0_BringUp-Runbook_v1.0.md|docs/procedimientos/einarboard-1.0-bringup.md"
"06-Testing-Validation/2026-08-18_Drogheda_FW-v3.0.3_Fan-Policy_Bench-Test_v1.0.md|docs/procedimientos/fan-policy-bench-test.md"
"03-Architecture-Hardware/watchdog-proto-bench-bringup-v3.md|docs/procedimientos/historico-proto-bench-v3.md"
"03-Architecture-Hardware/watchdog-protoboard-bringup.md|docs/procedimientos/historico-protoboard.md"
"06-Testing-Validation/remote-diagnostic-protocol.md|docs/diagnostico/protocolo-diagnostico-remoto.md"
"03-Architecture-Hardware/harness-connector-pinout.md|docs/montaje/pinout-arneses.md"
"03-Architecture-Hardware/Assembly-BOM-Split.md|docs/montaje/bom-split.md"
"03-Architecture-Hardware/0007-1000_Assembly_Guide.pdf|docs/montaje/0007-1000_Assembly_Guide.pdf"
"03-Architecture-Hardware/kicad/docs/GIT-GUIDE_Colaboradores-Externos_ES.md|docs/git/guia-git-es.md"
"03-Architecture-Hardware/kicad/docs/GIT-GUIDE_External-Collaborators_EN.md|docs/git/git-guide-en.md"
)
n=0
for entry in "${MAP[@]}"; do
src="$SRC/${entry%%|*}"; dst="${entry##*|}"
if [ ! -f "$src" ]; then echo "AVISO: falta $src (¿renombrado?)" >&2; continue; fi
mkdir -p "$(dirname "$dst")"
cp "$src" "$dst"
n=$((n+1))
done
echo "sincronizados $n archivos desde $SRC"
echo "Revisa 'git status' y haz commit de los cambios que quieras publicar."