Hoy publico el Protocolo Operativo del Sistema BEACON v1.0, un documento de trabajo con un objetivo muy simple: dejar fijados los parámetros de una sesión para que cualquier análisis posterior (o réplica) sea reproducible y no dependa de “ajustes a ojo”.
BEACON no es radio ni un sistema de telecomunicaciones clásico. Aquí la “señal” es un patrón láser monitorizado con sensores (fotodiodos/LDR), y lo que se estandariza es cuándo se transmite/espera la interacción, qué clave identifica la sesión, y cómo se procesa la señal en frecuencia (waterfall/espectrograma) para decodificarla.
1) Ventana temporal (TX)
El protocolo define una ventana temporal de transmisión (TX):
-
10:00–12:00 (hora local)
¿Por qué importa esto? Porque, si no acotas el tiempo, luego es imposible comparar sesiones o descartar artefactos. Con una ventana fija, todo lo que se analice queda referenciado a un intervalo concreto.
2) Clave BEACON (identificador de sesión)
En BEACON uso una clave en dos formatos:
-
Clave (plain):
27/01/2026/LUNA -
Clave (Base64):
MjcvMDEvMjAyNi9MVU5B
Esto es importante: Base64 no es “cifrado”, es codificación. Se usa para que la clave sea un identificador estable, sin caracteres problemáticos, y fácil de transportar/pegar en scripts, repositorios o metadatos sin ambigüedades.
3) Señal y sensores (S1–S4)
La lectura se realiza sobre:
-
S1–S3: fotodiodos/LDR que capturan variaciones del patrón (canales de señal y control)
-
S4: canal de estado/confirmación (marca operativa del sistema, no una “respuesta” en sí misma)
En otras palabras: S2 se trata como canal objetivo, mientras que S1 y S3 actúan como controles para comprobar si lo que aparece en S2 es específico o simplemente ruido común del montaje.
4) Parámetros de análisis (waterfall / espectrograma)
Para que el análisis espectral sea replicable, el protocolo fija estos parámetros:
-
Fs (sampling rate): 20 Hz
-
NFFT / FFT size: 1024 (2¹⁰)
-
Ventana: Hann
-
Solape (overlap): 75%
-
Canal objetivo: S2 + controles S1 y S3
Con esto se genera un waterfall (espectrograma) comparable entre sesiones: misma tasa de muestreo, misma resolución en frecuencia/tiempo y mismo tipo de ventana. Si cambias estos valores, cambias la “huella” del espectro y luego es fácil autoengañarse sin querer.
5) Qué pretende garantizar este protocolo
Este v1.0 no “demuestra” nada por sí solo. Lo que hace es poner orden:
-
Reproducibilidad: mismo TX + misma codificación + mismo pipeline espectral.
-
Trazabilidad: cada sesión queda ligada a una clave única (plain/Base64).
-
Control experimental: S2 se interpreta con contraste contra S1/S3.
6) Qué viene después
A partir de aquí, lo correcto es trabajar con datasets registrados en esa ventana y aplicar el mismo método de análisis siempre, comparando sesiones y controles. Si hay señal, tendrá que aparecer de forma consistente bajo este marco. Si no aparece, se descarta. Sin drama: así funciona un protocolo serio.
Si te interesa seguir el desarrollo o replicar el análisis con los mismos parámetros, iré publicando sesiones y resultados asociados a esta estructura BEACON v1.0.
No hay comentarios:
Publicar un comentario