Con una cuenta desbloqueas el cuestionario, el foro de dudas y el tutor con IA de esta lección, además del registro de progreso y el certificado verificable al terminar «Estaciones Terrenas y SDR: Recibir Satélites desde Cero».
Tu estación, por bien construida que esté, tiene un límite físico infranqueable: solo ve el trozo de cielo que hay encima de ella. Vale la pena cuantificarlo, porque la cifra es más pequeña de lo que la intuición sugiere.
Ejemplo resuelto: qué fracción de la Tierra cubre una estación
Para un satélite a h=500 km y una elevación mínima operativa ε=10°, el semiángulo central γ del casquete terrestre desde el que ese satélite es visible cumple:
γ=arccos(RT+hRTcosε)−ε
Con RT=6371 km: RT/(RT+h)=0.9272 y cos10°=0.9848, cuyo producto es 0.9132. Entonces arccos(0.9132)=24.05° y γ=24.05°−10°=14.05°, lo que corresponde a un radio sobre el suelo de 6371×0.2452=1562 km. La fracción de superficie esférica que abarca un casquete de semiángulo γ es:
Una estación cubre el 1.5 % de la superficie del planeta. Aunque pudieras colocar las estaciones en posiciones perfectas, harían falta al menos 1/0.015≈67 para cubrir el globo, y en la práctica muchísimas más: el 71 % de la Tierra es océano, los casquetes deben solaparse para no dejar huecos y los satélites transmiten cuando quieren, no cuando pasan sobre tierra firme. La conclusión no es desalentadora sino estructural: la unidad útil de observación satelital no es la estación, es la red.
SatNOGS: la red comunitaria
SatNOGS (Satellite Networked Open Ground Station), proyecto de la Libre Space Foundation, es la materialización de esa idea: cientos de estaciones terrenas de hardware y software abiertos, repartidas por todo el mundo, coordinadas por una plataforma común. Cualquiera puede registrar la suya, y a partir de ese momento el planificador central le asigna observaciones que otros usuarios solicitan. Los datos resultantes —waterfalls, audio, tramas— son públicos.
La pieza que hace funcionar el conjunto es humana y se llama vetting: tras cada observación, una persona la revisa y la etiqueta. Las categorías operativas son esencialmente tres: good (hay señal del satélite esperado y es utilizable), bad (no hay señal reconocible; el pase se ejecutó pero no captó nada) y failed (la observación no llegó a realizarse correctamente por un problema de la estación). Ese etiquetado es lo que separa el ruido del dato, y también, sin haber sido diseñado para ello, uno de los conjuntos de datos etiquetados más interesantes de la radioafición.
El problema del volumen
El éxito de la red crea su propio cuello de botella.
Ejemplo resuelto: cuánta atención humana exige la red
Supón 500 estaciones activas que ejecutan una media de 10 observaciones diarias cada una: 5000 observaciones al día. Si revisar una toma 20 segundos de atención humana:
Thumano=3600s/h5000×20s=27.8h/dıˊa
Más de una jornada completa de trabajo humano cada día, repartida entre voluntarios y sostenida indefinidamente. Un clasificador pequeño que tarde 40 ms por imagen en un núcleo de CPU procesa las mismas 5000 observaciones en 5000×0.04=200 s, poco más de tres minutos. La comparación no propone sustituir a las personas: propone triaje. Que la máquina descarte con alta confianza el 80 % evidente y que la atención humana se concentre en el 20 % dudoso, que es donde aporta juicio.
Clasificar waterfalls con una CNN pequeña
La observación entrega un waterfall en PNG, y un waterfall es una imagen. Eso convierte un problema de radio en un problema de visión por computadora perfectamente estándar: clasificar cada imagen en good, bad o failed. Una CNN (convolutional neural network, red neuronal convolucional) modesta —unas pocas capas convolucionales sobre una entrada reescalada a escala de grises— basta, porque las clases se distinguen por rasgos visuales groseros: una traza inclinada de Doppler, un patrón de ráfagas, una banda saturada, un lienzo uniforme.
Así funciona code-triage, el clasificador del clúster CODE Aerospace. Sus decisiones de diseño son ilustrativas de lo que significa poner aprendizaje automático en producción con restricciones reales:
Dataset del vetting comunitario: las etiquetas no se producen a propósito, se heredan del trabajo que la comunidad ya hacía. Es la forma más barata y más honesta de conseguir datos, y trae sus propios problemas.
Modelo exportado a ONNX (Open Neural Network Exchange): el entrenamiento ocurre en un entorno y la inferencia en otro, con un runtime ligero, sin arrastrar el framework de entrenamiento a producción.
Inferencia en CPU con límites estrictos: el clúster no tiene GPU dedicada al triaje y no la necesita. La restricción de recursos es un requisito de diseño, no una carencia: fuerza a un modelo pequeño, y un modelo pequeño se audita, se versiona y se reentrena sin ceremonia.
Dónde se rompe: la calidad del dataset
El modelo casi nunca es el problema. Los problemas están en los datos, y en este dominio son dos, ambos silenciosos.
El primero son las etiquetas ruidosas. El vetting lo hacen personas distintas con criterios distintos; una traza tenue que una persona marca good otra la marca bad. Existe un techo de exactitud que ningún modelo puede superar, y ese techo lo fija el desacuerdo entre humanos. Reportar una exactitud por encima de la concordancia entre anotadores no es un logro: es una señal de que algo está mal medido.
El segundo, más traicionero, es la fuga por estación (station leakage). Cada estación produce waterfalls con su firma propia: su piso de ruido, sus interferencias locales, su paleta, su escala de ejes. Si repartes las imágenes al azar entre entrenamiento y validación, las de una misma estación caen a ambos lados y el modelo aprende a reconocer la estación en vez de la señal. Las métricas salen excelentes y el sistema fracasa el día que se conecta una estación nueva. La única defensa correcta es partir por grupos: todas las observaciones de una estación van enteras a entrenamiento o enteras a validación, nunca repartidas.
Ejemplo resuelto: por qué la exactitud miente
Un conjunto de validación de 1000 observaciones tiene 850 bad, 120 good y 30 failed. Un clasificador trivial que responda siempre "bad" obtiene:
exactitud=1000850=85%recallgood=1200=0
Un 85 % impecable en el informe, y cero utilidad: no encuentra ni una sola de las observaciones que importan. Un modelo real que acierte 799 de las 850 bad, 96 de las 120 good y 18 de las 30 failed obtiene una exactitud de (799+96+18)/1000=91.3% — solo 6.3 puntos más que el clasificador trivial. Pero su recall macro, el promedio de la exhaustividad por clase, es:
30.94+0.80+0.60=0.78frente a31.00+0+0=0.33
De 0.33 a 0.78: la métrica correcta muestra una diferencia enorme donde la exactitud mostraba una diferencia marginal. Con clases desbalanceadas, la exactitud global es la métrica equivocada; hay que mirar la matriz de confusión y el rendimiento por clase.
El lazo completo
Recorrimos la cadena entera de la lección 1, de la antena a los datos. Falta ver cómo esa cadena se cierra sobre sí misma en un ecosistema real. En CODE Aerospace el lazo es este: el gemelo digital SAT-DT propaga el estado orbital y predice los pases; la estación OrbitEye los ejecuta con los locks y la corrección Doppler de la lección 8; code-triageevalúa el resultado y decide qué merece atención humana; el hub CODE-Nexus encamina los productos entre servicios conservando su procedencia según el modelo W3C PROV, de modo que cada dato sabe de qué observación salió, de qué estación y con qué TLE; y esos datos vuelven a alimentar al gemelo, que mejora la siguiente predicción.
Ningún eslabón es espectacular por separado. Un dipolo de dos varillas, un dongle de 30 dólares, una FFT, un CRC, un lock de hardware, una CNN de pocas capas. Lo que produce un instrumento científico es el encadenamiento correcto de piezas modestas, cada una con su función clara y su punto de fallo conocido. Esa es, si el curso deja una sola idea, la idea.
Repasa el cierre:
Al preparar el dataset de waterfalls etiquetados, ¿por qué se separan entrenamiento y validación por estación y no al azar?
Y fija las ideas de la lección:
1 de 7
Con esto termina el recorrido técnico. Lo que queda no se aprueba leyendo: se aprueba diseñando tu estación, eligiendo tus objetivos y saliendo a recibir. El trabajo final es exactamente eso.