Independiente de cartridge-builder/: aquello es autoría de contenido de un cartucho (categorías,
acciones, matices, clusters). Esto es la capa de transporte — cómo viaja físicamente un
mensaje de un dispositivo a otro — y qué plataforma/modelo/hardware haría viable cada vertical
en un entorno real, no solo en la demo de inversores.
Es un notebook vivo: se actualiza según se prueban cosas, no un informe cerrado. Cada sesión de investigación o experimento añade una sección con fecha.
Ver también notebook-mvp-validacion-institucional.md — la línea de validación de contenido con expertos (bomberos/rescate) debería ir antes de invertir más en cualquiera de los caminos de abajo: su feedback sobre qué necesitan de verdad (alcance, robustez, cómo se integraría con su equipo) es la señal que falta para decidir cuál de los 5 caminos priorizar, en vez de adivinarlo solo desde la parte técnica.
src/services/acousticProtocol.ts + acousticService.ts) — tonos FSK en
banda ultrasónica (17.8-19.6kHz, inaudible) o audible (1.4-3.2kHz, largo alcance). Hoy es un
handshake ida y vuelta pensado para la demo de dos móviles cerca, no un broadcast. El propio
código ya documenta límites reales encontrados probando con hardware real: variabilidad fuerte
entre altavoz/micro de distintos modelos (caso real Xiaomi→iPhone funcionaba, iPhone→Xiaomi no,
resuelto ajustando el margen mínimo entre candidatos a 6dB), umbral de amplitud -74dB, timeout
de 1.2s si un frame no se completa.src/services/peerService.ts, WebRTC vía PeerJS) — necesita internet real
(señalización + servidores STUN). No sirve para el escenario "sin red" que es la propuesta de
valor del cartucho de Situaciones Críticas.Ya se había hablado de un patrón tipo: los emisores lanzan un SOS cada 15 segundos, y el receptor escucha continuamente en busca de cualquier señal, sin necesidad de emparejamiento previo. Eso es exactamente cómo funcionan los beacons BLE (iBeacon/Eddystone): un anuncio corto y periódico que cualquier escáner cercano capta sin conexión. Es la forma natural de resolver "muchos móviles gritando socorro, uno o varios escuchando" — mucho más apropiado para una emergencia real que el handshake 1:1 que tiene hoy el canal acústico.
La pregunta de investigación: ¿es siquiera posible ese patrón desde una PWA sin instalar nada (que es la propuesta de valor actual: "abre una web en dos móviles"), en iOS y Android?
applyConstraints({advanced:[{torch:true}]})); iOS Safari no puede controlar el
flash desde ninguna web — restricción deliberada de Apple que afecta a todos los navegadores
en iOS (todos corren sobre WebKit por imposición de Apple, incluido "Chrome" para iPhone).
Además exige línea de vista directa entre los móviles, lo que no encaja con una emergencia real
("el móvil en el bolsillo").El ejemplo que reorienta la prioridad: un terremoto (ej. Venezuela), un móvil atrapado bajo un derrumbe, equipos de rescate fuera con una estación de escucha potente, e incluso perros de rescate que puedan oír la señal a distancia. Se investigó si esto es técnicamente viable y con qué tecnología concreta — la respuesta cambia el enfoque respecto al resto de este notebook.
Los perros oyen de verdad mucho más alto que los humanos: hasta 45-65kHz según los estudios (algún outlier hasta 105kHz), con mayor sensibilidad entre 4-10kHz. De hecho ya existe la técnica: los silbatos para perros de rescate usan específicamente 23-54kHz, un rango pensado a propósito para estar por encima del oído humano y ser efectivo en operaciones SAR reales. La idea del usuario no es descabellada — es una técnica ya validada en el mundo real.
El problema es el propio altavoz del móvil. El DAC de un smartphone típico muestrea a 44.1 o 48kHz, lo que limita el techo teórico a ~22-24kHz — pero en la práctica la respuesta cae en picado por encima de 20kHz incluso en un iPhone 7/8, y muchos móviles más baratos o antiguos se quedan cortos bastante antes. La banda ultrasónica que ya usa NumChat (17.8-19.6kHz) está literalmente pegada a ese techo — no llega ni de lejos al rango 23-54kHz que usan los silbatos reales para perros. Con el altavoz de un móvil de serie, "solo lo oye el perro" no es alcanzable hoy — se necesitaría un transductor ultrasónico dedicado (hardware añadido), no software.
Investigando los detectores de vida profesionales que ya usan los equipos de rescate (combinan sensor acústico + sensor sísmico) apareció el dato clave: el alcance real es muy distinto según la vía. El sonido transmitido por el aire a través de escombros solo llega de 5 a 25 pies (1.5-7.5m), mientras que la vibración transmitida por el propio material (sísmico) llega de 50 a 150 pies (15-45m) — de 3 a 6 veces más lejos. Es la razón por la que el equipo profesional de USAR (ej. LEADER, Delsar) lleva ambos tipos de sensor, no solo micrófono.
Esto importa porque cualquier móvil ya tiene motor de vibración, controlable desde una web
sin instalar nada vía la Vibration API (navigator.vibrate()) — soporte nativo sólido en
Android/Chrome. En iOS Safari, otra vez el mismo patrón de bloqueo de Apple: nunca se ha
soportado oficialmente. Existen hacks no oficiales (ej. ios-vibrator-pro-max) que consiguen
vibrar en iOS, pero solo dentro de un evento de interacción directa del usuario (click, touch,
input) — y desde iOS 18.4 Apple lo restringió aún más en ese sentido. Eso rompe justo el caso de
uso que importa aquí: un móvil que seguiría vibrando solo, en bucle, sin que nadie lo esté tocando
(la persona puede estar inconsciente o atrapada sin poder interactuar). Conclusión: viable hoy
solo en Android de forma fiable; en iPhone la vibración autónoma en segundo plano no es posible
ni con el hack.
Aun con esa limitación en iOS, un móvil atrapado apoyado contra el escombro, vibrando en un patrón reconocible en Android, transmite esa señal AL MATERIAL — exactamente lo que un sensor sísmico profesional está diseñado para captar, y con 3-6x más alcance que cualquier pitido por el aire.
Conclusión de este caso: la vía más prometedora no es "que el móvil pite más alto/más agudo para que lo oiga el perro" (bloqueado por hardware de altavoz), sino "que el móvil vibre en un patrón reconocible contra el escombro para que lo capte un sensor sísmico" — tecnología que ya existe y ya usan los equipos de rescate, y que un móvil de serie ya es capaz de alimentar sin ningún hardware adicional. El modo "baliza de rescate" ideal combinaría ambas señales a la vez (vibración para sísmico + tono acústico ultrasónico/audible para micrófono), aprovechando lo que cada sensor ya sabe escuchar, en vez de inventar una señal nueva que ningún equipo sepa interpretar.
La limitación no es de NumChat, es de la plataforma: una PWA sin instalar nada, en iPhone y Android, no tiene ninguna forma estándar de emitir un beacon de corto alcance — ni BLE, ni NFC, ni Wi-Fi Direct. Todas esas vías están bloqueadas específicamente en Safari/iOS por decisión de Apple, y el rol de anunciante BLE tampoco existe en NINGÚN navegador, ni siquiera Chrome.
El canal acústico que ya existe sigue siendo, hoy, la única vía verdaderamente cross-platform e instalación-cero para que dos móviles se hablen sin red — el ultrasonido no fue una elección ingenua, es la única que funciona sin renunciar al "abre una web" del pitch actual.
Esto deja tres caminos reales, no mutuamente excluyentes:
Explotar mejor lo que ya hay (coste de infraestructura cero). Rediseñar el uso del canal acústico de "handshake" a "baliza": el emisor repite el frame SOS cada N segundos sin esperar confirmación, el receptor simplemente escucha en bucle. Cambio de lógica de aplicación, no de tecnología — el más barato y rápido de probar.
Aceptar un wrapper nativo ligero (Capacitor) solo para las verticales que de verdad necesiten BLE real: se pierde el "cero instalación", se gana un beacon BLE real de 10-100m igual en iOS y Android (ya existen plugins con rol periférico en ambas plataformas).
Hardware dedicado LoRa para el caso de uso de escala real (protección civil sin cobertura, kilómetros de alcance): la respuesta correcta a largo plazo si el objetivo es un despliegue real, pero convierte el producto en "app + dispositivo".
Vibración contra el material (caso escombros/USAR) — añadido tras el caso extremo de
arriba: usar navigator.vibrate() (ya disponible, cero instalación en Android) para que el
propio móvil transmita un patrón sísmico detectable por el mismo tipo de sensor que ya llevan
los equipos de rescate, con 3-6x más alcance que cualquier señal acústica por el aire a través
de escombros. Actualizado tras probarlo en Android real (2026-09-07): el patrón se reconoce
bien, pero el bucle se corta en cuanto la pantalla se bloquea o apaga — justo el estado más
probable de un móvil dejado atrás por una víctima. Sin resolver ese problema (Wake Lock quema
batería, Service Worker sin confirmar), esta vía no sobrevive al caso de uso real tal como
está y probablemente termine reforzando el camino 2 (wrapper nativo) en vez de sustituirlo.
Wearable dedicado y programable (smartwatch abierto) — añadido 2026-09-07 tras confirmar que el problema de fondo en 2 y 4 es siempre el mismo (navegador/SO de móvil imponiendo un sandbox de ejecución/permisos), no algo resoluble desde dentro de una PWA. La salida es dejar de depender de un navegador por completo: un wearable con firmware propio no tiene sandbox de navegador, ni restricciones de iOS, ni límites de ejecución en segundo plano — el código que escribes es el único que corre ahí.
Dos candidatos reales y baratos, investigados y verificados (no smartbands genéricas de firmware cerrado, que no valdrían para esto):
Sobre batería en modo baliza: confirmado que BLE en anuncio continuo consume mucho (agota una batería de 1000mAh en ~10h), pero con duty cycle real (anuncia unos segundos, duerme el resto) la misma batería dura meses — el ajuste de intervalo que el prototipo web solo podía simular a medias, aquí se implementa de verdad porque no hay sandbox que lo interrumpa.
Coste real de este camino: dejar de ser desarrollo web — hace falta programar firmware en C/Arduino, un salto de herramientas distinto a todo lo hecho en este proyecto hasta ahora, y confirma explícitamente lo que ya apuntaba el camino 3: esto es "app + dispositivo", no "abre una web". Para protección civil (distribución dirigida, no consumo masivo) es un modelo de despliegue perfectamente normal.
Decisión (2026-09-07): documentar y dejar la compra de hardware para más adelante — no se adquiere ningún dispositivo todavía, queda como el candidato más prometedor para cuando se decida invertir en esta vía.
La idea original: volver a los fundamentos del canal acústico y preguntar si añadir un dispositivo externo (ejemplo dado: un reloj) como repetidor mejoraría el alcance — arquitectura propuesta: Móvil A → BLE → Reloj A → ultrasonido → Reloj B → BLE → Móvil B, con los relojes hablándose entre sí por ultrasonido en vez de radio.
Análisis del tramo ultrasónico reloj↔reloj (sin hardware nuevo comprado, estimación de ingeniería):
ultrasonic en acousticService.ts, ya marcada como
poco fiable en pruebas reales Xiaomi↔iPhone).El hallazgo que descarta esta ruta: en cuanto el reloj lleva radio BLE para hablar con su móvil, ya se rompió la pureza "cero RF" del pitch air-gap — el reloj ya tiene un chip de radio integrado. No hay entonces ninguna razón de ingeniería para que el salto reloj↔reloj siga siendo acústico: sustituirlo por BLE (o LoRa) directamente da 10-100m (BLE) o kilómetros (LoRa) por salto, con menos latencia y mucha menos tasa de error, sin coste adicional de hardware — el chip de radio del reloj ya está ahí, y evita tener que añadir y calibrar un transductor ultrasónico dedicado.
Reformulación del objetivo (aclarada por el usuario, 2026-09-11): el móvil es solo la pantalla donde se refleja la conversación (UI, vía BLE de corto alcance hacia el dispositivo que lleva encima) — lo que se busca de verdad es un dispositivo barato y fiable que sea el canal de comunicación real entre punto A y punto B, no necesariamente en forma de reloj. Esto es exactamente el "camino 5" ya documentado más arriba (wearable/dongle dedicado), y la conclusión de este análisis es que ahí LoRa gana a ultrasonido en todos los ejes para ese rol — ver comparación en la sección A.1/B.1/B.2 de notebook-protocolos-transporte-verticales.md:
| Ultrasonido reloj↔reloj (transductor dedicado) | BLE reloj↔reloj | LoRa reloj↔reloj | |
|---|---|---|---|
| Alcance por salto | ~5-15m (estimado, sin medir) | 10-100m (BLE 5 Coded PHY hasta ~400m LoS) | 2-5km típico, decenas de km con línea de vista |
| Coste hardware añadido | Transductor piezo + calibración (2-5€ + tiempo de ingeniería) | Ya incluido en cualquier chip BLE (nRF52832 etc., ~2-5€) | Chip SX1262 ~3-6€, módulo dev completo ~20-25€ (Heltec LoRa32 V3) |
| Fiabilidad | Sensible a ruido ambiental, orientación, distancia — sin historial de prueba real | Estándar maduro, bien probado | Estándar maduro, link budget 170dB, muy robusto a interferencia |
| Forma física | Requiere hueco para el transductor + puerto acústico | Ya integrado en el propio SoC | Ya integrado en placas dev existentes (mismo SoC que ya se iba a usar para BLE) |
Conclusión: no se sigue investigando la vía ultrasonido-entre-repetidores — no aporta nada que BLE o LoRa no den ya mejor y más barato una vez se acepta que el dispositivo repetidor lleva radio. El diseño a evaluar cuando se retome el camino 5 es Móvil (UI) → BLE → Dispositivo dedicado → LoRa → Dispositivo dedicado → BLE → Móvil (UI), usando el mismo hardware que ya se había identificado (Heltec LoRa32 V3 ~20-25€ si no hace falta forma de reloj, o LILYGO T-Watch S3 ~23-40€ si se quiere wearable con LoRa integrado de fábrica) y, para la capa de malla/routing entre repetidores, firmware Meshtastic o MeshCore ya maduro en vez de escribir un protocolo de malla propio desde cero.
Cierre de esta línea — aclaración importante sobre qué tipo de canal es cada cifra de alcance dada en esta conversación (2026-09-11): el canal acústico (móvil↔móvil, ~3m) y la idea de radio analógica vía DTMF sobre un walkie PMR446/ham (ver más abajo en la exploración de radio analógica, mismo día) son ambos canales de audio — el código de 4 bytes de NumChat se convierte primero a tonos (FSK o DTMF), esos tonos viajan como sonido/audio (por el aire, o modulados en la portadora de voz FM de una radio analógica), y en el receptor se decodifica el audio de vuelta a bits. Es un paso intermedio con pérdida y sensible a ruido.
LoRa NO es un canal de audio — es un canal de datos/bits nativo. El chip SX1262 modula directamente el
código binario de NumChat como espectro ensanchado por chirp (Chirp Spread Spectrum) y lo transmite como
señal de radio digital; el receptor demodula directamente de vuelta a los mismos bits, sin pasar nunca por
sonido ni por ninguna capa de audio intermedia. Es, de hecho, un encaje más directo con NumChat que el
propio canal acústico actual — el protocolo ya es binario (4 bytes / 32 bits) internamente
(acousticProtocol.ts lo convierte a tonos solo porque el transporte disponible en una PWA es el
altavoz/micrófono; con LoRa no hace falta esa conversión en absoluto). Esta es la razón técnica de fondo por
la que LoRa consigue kilómetros de alcance con solo 25mW de potencia legal, mientras que un walkie FM
analógico de 500mW se queda en unos pocos km como mucho: la modulación digital de espectro ensanchado tiene
muchísima más ganancia de proceso (170dB de link budget) que una portadora de voz analógica modulando
audio.
La cifra de 2-5km por salto, por tanto, es directamente aplicable al código de 4 bytes de NumChat tal cual es hoy — bits dentro, bits fuera, sin conversión a audio de por medio.
Precisión sobre el tamaño del payload y el alcance (2026-09-11): el alcance de LoRa no lo determina el tamaño del mensaje — lo determina la sensibilidad del receptor (fijada por el Spreading Factor SF7-SF12 y el ancho de banda) y la potencia de transmisión. Un paquete de 4 bytes y uno de 50 bytes tienen el mismo techo de alcance si se envían con el mismo SF/potencia/antena. Donde sí ayuda tener solo 4 bytes:
Conclusión: el techo de 2-5km lo pone la física de la radio, no el tamaño del mensaje — pero el tamaño mínimo de NumChat es lo que permite aprovechar ese techo sin el coste de batería/duty-cycle que sí penalizaría a un protocolo más "charlatán".
Dónde está el valor real de NumChat frente a todo este catálogo de transporte: el transporte (acústico,
BLE, LoRa, satélite...) solo tiene que mover unos pocos bytes de forma fiable — es intercambiable, de
mercado. El valor diferencial está en las dos puntas que rodean al transporte: codificar lenguaje natural a
4 bytes en origen, y decodificar esos 4 bytes a una frase operativa completa en destino vía el cartucho/
diccionario compartido (translator.ts + cartridgeContent.ts) — el mismo argumento que ya usa el informe
de verticales (~3bps equivalente de información real transmitida, frente a 300-2400bps de códecs de voz
para decir lo mismo). El protocolo de transporte que se elija en cada vertical no cambia esta ventaja; solo
decide alcance, coste y fiabilidad del viaje.
El chip LoRa (SX1262/SX1276) no tiene ninguna interfaz que un móvil pueda usar directamente — solo habla SPI con un microcontrolador anfitrión (el propio ESP32 de las placas ya identificadas, Heltec LoRa32 V3 / LILYGO T-Watch S3). Eso significa que hay dos saltos distintos, no uno, entre el cartucho semántico de hoy (que vive en la PWA, en JS, dentro del navegador del móvil) y el enlace LoRa real:
Móvil A Dispositivo dedicado A [RF LoRa] Dispositivo dedicado B Móvil B
(cartucho semántico <──> ESP32 <──SPI──> SX1262 <───2-5km───> SX1262 <──SPI──> ESP32 <──> (cartucho semántico
en la PWA/JS) BLE/USB BLE/USB en la PWA/JS)
Opción 1 — el cartucho semántico se queda en el móvil; el ESP32 solo hace de "tubo tonto" BLE↔LoRa:
Opción 2 — el cartucho semántico se porta al propio ESP32 (firmware en C/C++), sin móvil de por medio:
translator.ts + cartridgeContent.ts en C/C++ — un salto de stack real (de
JS de navegador a firmware embebido), no una portación mecánica. Estimado: semanas, no días — y es
razonable empezar solo portando el lado decode (código→frase, mucho más determinista) dejando el lado
encode (texto libre→código, con los clusters de keywords en varios idiomas) todavía en el móvil, para no
tener que portar de golpe la parte más compleja del motor.Recomendación de orden: empezar por la Opción 1 (con Meshtastic tal cual) para el primer piloto de alcance real — reutiliza el 100% del motor JS ya escrito y probado, y valida la cifra de 2-5km con hardware real antes de invertir semanas en portar el motor a C para la Opción 2.
| Vertical | Por qué encaja | Matiz |
|---|---|---|
| V1 Situaciones Críticas | Encaje directo — es la extensión natural del canal acústico actual cuando se necesita más de unos metros | El caso ya discutido en detalle en este notebook |
| V2 Minería (tramos intactos, no colapsados) | Cadena de repetidores a lo largo de una galería como respaldo barato del leaky feeder ya instalado | No sustituye al VLF/Through-the-Earth (D.1 en el notebook de protocolos) si hay derrumbe real — LoRa no atraviesa roca, solo funciona con algo de línea de vista dentro del túnel |
| Espeleología (ver notebook de protocolos, sección I.1) | Mismo argumento que minería, a escala de rescate voluntario/deportivo en vez de industrial | Misma limitación: solo sirve en tramos sin bloqueo real de roca |
| Rescate en montaña / avalanchas (protocolos I.2) | Repetidores LoRa entre miembros del equipo de rescate desplegados por la ladera, para coordinarse a más distancia de la que da BLE/voz | No sustituye el beacon de avalancha (457kHz) de la víctima — es para la coordinación del equipo buscador, no para localizar a quien está enterrado |
| Marítimo — flota pequeña de pesca (protocolos I.2) | LoRa entre embarcaciones de una misma flota a pocos km, más barato que radio VHF marina certificada | Complementario, no sustituto, del EPIRB/AIS-SART para la emergencia real de hombre al agua |
| Ferrocarril / construcción de gran altura (protocolos I.1) | Repetidores fijos a lo largo de un túnel u obra, como canal independiente de respaldo a GSM-R o a la red de obra | Sin literatura específica investigada todavía — pendiente de una pasada propia si se prioriza |
| V4 (enjambre de UAVs/drones) | LoRa mesh dron-a-dron de corto/medio alcance entre los propios drones, reservando el enlace satelital (F.1/F.2 del notebook de protocolos) solo para el tramo largo hacia tierra | Arquitectura híbrida — no está pensado ni probado, es una idea de diseño a validar |
Lectura general: esta arquitectura (repetidor LoRa dedicado + móvil como pantalla) encaja mejor cuanto más se parece el escenario a "personas con línea de vista parcial, sin cobertura, que ya llevan o pueden llevar un dispositivo adicional" — y encaja peor donde el obstáculo es material sólido bloqueando la radio (derrumbe real, agua profunda), que sigue necesitando la tecnología de nicho correspondiente (VLF para roca, acústica para agua) en vez de LoRa.
acousticService.ts a bucle de emisión + escucha
continua, medir alcance real en un espacio interior típico.setInterval) de
una pestaña en segundo plano o con la pantalla apagada, y con ellos la vibración. Es
exactamente el estado más probable de un móvil dejado atrás por una víctima atrapada o
inconsciente — tal cual está prototipado hoy, esta vía NO sobrevive al caso de uso real
que la motivó.
Qué probar para intentar solucionarlo (no verificado aún):
- navigator.wakeLock.request('screen') (Wake Lock API, disponible en Chrome/Android) para
mantener la pantalla encendida mientras el modo baliza esté activo — soluciona el
problema pero dispara el consumo de batería (la pantalla es lo que más consume), mal
encaje para "atrapado durante horas/días".
- Probar si una Service Worker puede mantener el patrón vivo en segundo plano — dudoso, los
Service Workers también tienen límites de tiempo de ejecución en inactividad, y
navigator.vibrate() es típicamente una API de contexto de ventana, no de worker; hay
que comprobarlo, no asumir que funciona.
- Si ninguna de las dos funciona de forma fiable, esto refuerza el camino 2 (wrapper nativo
tipo Capacitor) — un foreground service de Android SÍ puede mantener el hilo vivo
indefinidamente con pantalla apagada (patrón estándar ya usado por apps de música,
fitness, etc.), a costa de dejar de ser "cero instalación".
Pregunta natural verificada (2026-09-07): ¿instalar el PWA (añadir a pantalla de inicio)
lo arregla? No. Un PWA instalado sigue corriendo sobre el mismo motor Chrome/Blink que
una pestaña normal — instalar cambia la presentación (sin barra de URL, icono propio), no
concede ninguna exención de los límites de ejecución en segundo plano de Android (activos
desde Android 8, iguales para web instalada que para una app nativa sin foreground service).
La única API web pensada para "hacer algo periódicamente en segundo plano" es Periodic
Background Sync, y su intervalo práctico mínimo es de ~12-24 horas, decidido por el
propio navegador según el uso — inservible para un pitido/vibración cada 5-15 segundos. Lo
que sí lo resolvería (un foreground service de Android con notificación persistente, como
usan Spotify o una app de rutas para seguir vivos con la pantalla apagada) no existe como
API web, instalada o no — es terreno exclusivamente nativo. Conclusión: esto no es un
límite "pestaña vs. app instalada", es un límite "web vs. nativo" a secas.
Confirmado (2026-09-07): sí funcionaría en una app nativa/Capacitor, con un matiz de
diseño real. Un foreground service de Android SÍ puede mantenerse vivo con la pantalla
apagada — pero Android exige que muestre una notificación persistente mientras esté
activo (no es opcional, es la condición del sistema para que el usuario sepa que algo sigue
consumiendo batería en segundo plano). El modo baliza no sería invisible: se vería una
notificación fija tipo "Baliza SOS activa" todo el tiempo que dure — probablemente deseable
para este caso de uso (confirma que el modo está realmente activo), pero es un detalle de
producto a diseñar, no gratis.@meshtastic/js, sin wrapper
nativo) mientras los dos nodos se hablan entre sí por LoRa — medir alcance real punto A/punto B
en el mismo tipo de entorno donde se midió el canal acústico (3m+ audible), para tener una
comparación directa de la misma prueba con hardware distinto. Ver el informe enlazado para
fases, presupuesto y criterios de éxito detallados.Cada experimento de la lista de arriba, al ejecutarse, debería añadir aquí debajo una sección de resultado con fecha: qué se probó, con qué hardware, y la conclusión — igual que el propio código del canal acústico ya documenta sus hallazgos de pruebas reales (Xiaomi↔iPhone, márgenes de dB, etc.) en comentarios. Este notebook es el mismo hábito, pero a nivel de decisión de plataforma.