Plan de ejecución, no notebook de investigación abierta: recoge en pasos concretos la conclusión de notebook-infraestructura-transporte.md (arquitectura Móvil↔BLE↔ LoRa↔BLE↔Móvil, 2-5km de referencia de diseño por salto) para llevarla a un piloto real con hardware. Nada de esto está construido ni comprado todavía — es el mapa de pasos para decidir cuándo y cómo empezar.
@meshtastic/js ya da Web Bluetooth nativo desde el navegador, no hace falta wrapper nativo para probar
esto (solo Android/escritorio, iOS sigue bloqueado, ya lo sabíamos).Objetivo: validar en hardware real que la PWA de NumChat (sin cambios en su motor translator.ts +
cartridgeContent.ts) puede enviar y recibir su código de 4 bytes a través de dos nodos LoRa, y medir el
alcance real conseguido frente a la referencia de diseño de 2-5km.
Qué SÍ se prueba aquí:
Qué NO se prueba en este piloto (fuera de alcance deliberadamente):
Investigado para este informe: existe @meshtastic/js, la librería oficial del propio proyecto
Meshtastic, que ya implementa un cliente completo por Web Bluetooth directamente desde el navegador —
sin necesidad de app nativa ni wrapper Capacitor para este piloto. Conecta con el servicio GATT que expone
cualquier nodo Meshtastic (UUID 6ba1b218-15a8-461f-9fa8-5dcae273eafd, con las características ToRadio/
FromRadio/FromNum ya documentadas por el proyecto) y gestiona el protocolo de mensajes (Protobuf) por
detrás.
Consecuencia práctica: el "camino 2" (wrapper nativo Capacitor) que el notebook de infraestructura daba como necesario para BLE real no hace falta para este piloto concreto — la propia PWA, tal cual es hoy, puede hablar con los nodos LoRa desde Chrome/Android o escritorio. La limitación de siempre se mantiene igual: Web Bluetooth central no existe en Safari/iOS, así que este piloto es Android/escritorio-only, coherente con todo lo ya documentado — no es una limitación nueva, es la misma de siempre.
Móvil A (PWA, sin cambios Nodo A: Heltec LoRa32 V3 [RF LoRa 2-5km] Nodo B: Heltec LoRa32 V3 Móvil B (PWA)
en translator.ts/ corriendo firmware Meshtastic <──────────────> corriendo firmware Meshtastic
cartridgeContent.ts) <──> oficial sin modificar oficial sin modificar <──>
Web Bluetooth (@meshtastic/js) Web Bluetooth (@meshtastic/js)
Nuevo servicio en el código, src/services/loraService.ts, siguiendo el mismo patrón subscribe/notify que
ya usan acousticService.ts, peerService.ts y quickAccessService.ts — mismo modelo mental para quien
lea el código, ningún patrón nuevo que aprender.
| Ítem | Coste estimado |
|---|---|
| 2× Heltec LoRa32 V3 | ~40-50€ |
| Antena externa mejorada (opcional) | ~5-10€/nodo |
| Batería externa / carcasa para prueba de campo (opcional) | ~10-20€/nodo |
| Total Fase 1 | ~50-90€ |
@meshtastic/jsnpm i @meshtastic/js.src/services/loraService.ts — conexión por Web Bluetooth a un nodo Meshtastic desde el
navegador.translator.ts para reconstruir la
frase — el motor no cambia nada, solo cambia de dónde le llega el código (antes del canal acústico,
ahora de loraService).| Fase | Coste hardware | Tiempo de ingeniería estimado |
|---|---|---|
| 1 — Adquisición | ~50-90€ | — |
| 2 — Bring-up firmware oficial | — | ~1-2 días |
3 — Integración PWA vía @meshtastic/js |
— | ~3-5 días (la librería ya hace el trabajo pesado de BLE+Protobuf) |
| 4-5 — Medición + estrés | — | ~2-3 días de campo |
| Total piloto completo | ~50-90€ | ~1-2 semanas de una persona |
El coste real de este piloto es tiempo de ingeniería, no hardware — la parte cara del catálogo de transporte (satélite, acústica submarina profesional, VLF) queda muy lejos de esta cifra.
| Riesgo | Mitigación |
|---|---|
Web Bluetooth vía @meshtastic/js no funciona igual en todos los Android/Chrome |
Probar en 2-3 modelos de móvil distintos antes de dar el piloto por válido — mismo criterio de precaución ya aplicado al canal acústico (Xiaomi↔iPhone) |
| iOS sigue bloqueado (Web Bluetooth central no soportado en Safari) | Aceptar que este piloto es Android/escritorio-only — limitación ya conocida, no nueva; no bloquea la validez del piloto para V1 |
| Alcance real por debajo de 2-5km en el entorno de prueba disponible (vegetación, edificios) | Medir en varios escenarios distintos, no depender de un solo dato puntual |
| Duty cycle legal en 868MHz limita cuántas veces se puede repetir el beacon | Verificar la configuración real del firmware en Fase 2, no asumir que el valor por defecto es el correcto para el caso de uso |
Pregunta planteada tras cerrar el presupuesto del piloto: ¿cómo coordinar 3 o más interlocutores sin montar infraestructura de malla (rutas, reenvío multi-salto)? La respuesta reutiliza un mecanismo que ya existe en el código, no hay que inventarlo — solo extenderlo al transporte LoRa.
pairingDigitFromSeed() en acousticProtocol.ts:70-80 deriva un
canal lógico (0-9) a partir de securitySeed, un número compartido acordado fuera de banda entre los
interlocutores — dos dispositivos con la misma semilla se oyen, con semilla distinta se ignoran aunque
estén dentro del mismo alcance físico. Cero UI nueva: es el mismo número que ya cifra los dígitos.
Rebroadcast mode = LOCAL_ONLY (configuración por nodo) desactiva el reenvío — ningún nodo
retransmite el paquete de otro. Con esto, la red deja de ser una malla enrutada y se convierte en una
difusión de un solo salto ("línea compartida"): cada nodo emite y escucha directamente, sin rutas.pairingDigitFromSeed() como filtro de aplicación sobre el payload).Rebroadcast mode = LOCAL_ONLY en todos los nodos.Conclusión: no hace falta montar infraestructura de malla para 3+ interlocutores — basta con extender la semilla ya implementada al canal Meshtastic (Nombre+PSK) y desactivar el reenvío, aceptando que el alcance efectivo pasa a ser "todos dentro del mismo círculo de 2-5km entre sí", no una cadena de saltos.
Comparación completa frente a la opción "sin malla" de arriba — para decidir con los dos escenarios delante, no solo con uno.
Cómo enruta Meshtastic por defecto (Managed Flooding): cada nodo que recibe un paquete con hop_limit
distinto de cero espera un instante, escucha si otro nodo ya está retransmitiendo ese mismo paquete (para
no duplicar esfuerzo), y si no lo oye, lo reenvía decrementando el contador. El límite de saltos por
defecto es 3, con un máximo configurable de 7. No hace falta configurar rutas a mano — es inundación
controlada, no enrutamiento por tabla.
Dato importante sobre privacidad, verificado para este informe: la cabecera de cada paquete Meshtastic siempre viaja sin cifrar — solo el payload se cifra con AES256-CTR y la clave del canal (PSK). Esto significa que cualquier nodo Meshtastic que comparta la misma configuración de radio (frecuencia/preset) puede retransmitir el tráfico de NumChat aunque no tenga la semilla/PSK correcta — puede mover los bytes sin poder leerlos. Consecuencia práctica: en teoría se podría aprovechar la malla comunitaria de nodos Meshtastic ya desplegados por terceros como infraestructura de reenvío gratuita, sin comprometer el contenido del mensaje — a validar con cuidado antes de depender de ello en un despliegue real, no es algo que este informe dé por probado.
Arquitectura resultante con malla:
Rebroadcast mode en su valor por defecto (reenvío activado) en todos los nodos, con hop_limit fijado
según el alcance total que se necesite (3 por defecto, hasta 7).Cuándo elegir cada una: "sin malla" (sección 9) es la opción de menor coste y menor complejidad cuando
todos los interlocutores caben en el mismo círculo de 2-5km — no hay que desplegar nodos intermedios ni
gestionar tráfico de terceros. "Con malla" es la respuesta cuando el escenario real (ej. V2 minería a lo
largo de una galería larga, o V1 en un área de búsqueda extensa) necesita cubrir más distancia de la que da
un solo salto, aceptando el coste de más nodos y algo más de latencia. No son mutuamente excluyentes: el
mismo hardware (Heltec LoRa32 V3 + Meshtastic) sirve para las dos, es solo una cuestión de configuración
(Rebroadcast mode + hop_limit), no de comprar nada distinto.
Escenario límite planteado: cero recarga posible durante días (ejemplo dado — una mina). Hay dos presupuestos de energía completamente distintos, no uno — tratarlos como el mismo problema lleva a la conclusión equivocada.
| Escenario | Consumo medio | Autonomía con una 18650 (~3000mAh) |
|---|---|---|
| Heltec de fábrica, firmware sin optimizar (lo esperable en el piloto de este informe) | ~5-20mA (el chip USB-serie/LEDs/regulador de la placa dev siguen consumiendo aunque el ESP32 "duerma") | ~6-25 días |
| Firmware + hardware optimizados a fondo (proyecto real documentado: ESP32+SX1262 con duty cycle + deep sleep) | ~175µA | ~700 días |
La diferencia es trabajo de ingeniería real (deshabilitar periféricos de la placa dev, cuidar el regulador), no algo que venga gratis con la placa de 20-25€ — para el piloto de este informe, contar con la cifra pesimista (días-semanas), no la optimista.
Opciones para extender autonomía del nodo sin recarga eléctrica:
Un móvil consume órdenes de magnitud más que el nodo (pantalla, SO, radios buscando señal) — ningún power bank razonable lo sostiene "mucho tiempo" en el sentido de este escenario. Mitigaciones directas: modo avión (ya asumido por el diseño de NumChat), pantalla apagada entre usos, power bank externo (10.000- 20.000mAh, ~15-30€).
Respuesta arquitectónica real: si el escenario es "sin electricidad mucho tiempo", la solución no es alargar la batería del móvil, es no necesitar que el móvil esté encendido para la función crítica — la Opción 2 ya documentada en notebook-infraestructura-transporte.md (portar el cartucho semántico al firmware del propio ESP32) deja de ser solo "autonomía del dispositivo", se convierte en la respuesta directa a este escenario límite: el nodo de µA-mA sobrevive semanas/meses, el móvil pasa a ser un accesorio opcional que se enciende un momento para leer/escribir, no el dispositivo que tiene que aguantar toda la emergencia.
Precedente real que confirma que esto no es una idea nueva: el Garmin GPSMAP 67i — comunicación satelital inReach + GPS — funciona con pilas AA normales y da 165 horas de autonomía. Es exactamente la categoría de producto que resuelve el escenario límite de la sección 10, ya validada en mercado, no algo que haya que inventar desde cero.
Para V2-V5 (más presupuesto que el piloto V1 con móvil), tiene más sentido un terminal propio sin pantalla táctil ni sistema operativo de móvil de por medio:
| Componente | Función | Coste estimado |
|---|---|---|
| ESP32 + SX1262 | Radio LoRa + lógica (mismo hardware ya identificado en este informe) | ~20-25€ |
| Pantalla e-ink monocroma pequeña | Muestra la frase decodificada del cartucho | ~10-20€ |
| Botones físicos (no táctil) | Reutiliza el "Modo Guiado Visual" ya existente en el producto (4 decisiones rápidas) sin necesitar pantalla táctil | ~2-5€ |
| Portapilas AA/AAA + convertidor boost | Alimentación con pilas normales en vez de LiPo sellada | ~5-10€ |
| Total por unidad | ~50-80€ |
Una pantalla e-ink consume prácticamente cero mientras muestra una imagen estática — solo gasta energía en el instante en que el texto cambia (llega un mensaje nuevo); "sostener" la imagen no cuesta nada. Fuente consultada: hasta 90% menos consumo que una pantalla LCD convencional, y con deep sleep el consumo cae a microamperios. Combinado con el nodo LoRa bien optimizado (los ~175µA de media citados en la sección 10), aquí sí es realista acercarse a los meses de autonomía — y al ser diseño propio desde cero (no una placa dev genérica reaprovechada), se evita también el problema de periféricos parásitos ya señalado en la sección 10.
| Vertical | Por qué encaja | Matiz |
|---|---|---|
| V2 Minería | Los mineros ya llevan equipo de seguridad con pilas/packs recargables (lámparas de casco, detectores de gas) — se integra en una cultura de equipo ya existente | — |
| V4 Satélite/UAV — terminal del operador humano en tierra | El Garmin GPSMAP 67i es literalmente esta categoría de producto ya en mercado — mercado maduro al que NumChat podría sumarse como capa de mensajería | No aplica al propio dron — ahí el presupuesto de energía es otro, comparte batería con el vuelo, no pilas AA sueltas |
| V3 Submarinos/buceo | Los ordenadores de buceo ya funcionan con pilas de botón/AA durante años — misma categoría de producto | Requiere además carcasa estanca, no investigado a fondo en esta pasada |
| V5 Defensa | Los radios militares ya usan packs de batería estandarizados intercambiables (series BA) — terreno maduro, presupuesto ya asumido en esta vertical | — |