Manual de Operación_ Configuración y Uso de RTL-SD

Manual de Operación: Configuración y Uso de RTL-SDR

--------------------------------------------------------------------------------

1.0 Introducción a la Radio Definida por Software con RTL-SDR

1.1 Visión General y Contexto Estratégico

La Radio Definida por Software (SDR) representa un cambio de paradigma en los sistemas de comunicación, donde componentes tradicionalmente implementados en hardware ---como mezcladores, filtros y demoduladores--- son ejecutados mediante software en una computadora. Esta flexibilidad abre un sinfín de posibilidades para el procesamiento de señales. El RTL-SDR es una herramienta de bajo costo que ha democratizado el acceso al espectro radioeléctrico, permitiendo que tanto profesionales como aficionados puedan explorar las ondas de radio con una inversión mínima. Este manual proporciona los procedimientos operativos estándar para configurar y utilizar esta tecnología de manera eficiente y profesional.

Un dongle RTL-SDR es un dispositivo USB económico, con un costo aproximado de ~$30, que funciona como un escáner de radio basado en computadora. Sus orígenes se encuentran en los sintonizadores de televisión digital terrestre (DVB-T) producidos en masa que utilizaban el chipset RTL2832U. El potencial de estos dispositivos fue descubierto gracias al trabajo pionero de los investigadores Antti Palosaari y Eric Fry, y especialmente de Steve Markgraf de Osmocom, quien desarrolló el controlador de software personalizado que permitió acceder directamente a los datos crudos I/Q del chipset. Este avance transformó un simple sintonizador de TV en un receptor SDR de banda ancha y dio vida al proyecto RTL-SDR.

Es fundamental destacar que el RTL-SDR es un dispositivo de solo recepción; no tiene capacidad para transmitir señales. La gran mayoría del software asociado es desarrollado por la comunidad y se distribuye de forma gratuita, fomentando un ecosistema vibrante de innovación y aplicaciones. El acceso a estas potentes capacidades comienza con un paso crítico: la correcta instalación y configuración de los controladores en el sistema operativo del usuario.

1.2 Especificaciones Técnicas Clave del Hardware RTL-SDR

Comprender las especificaciones del hardware es esencial para operar el dispositivo de manera efectiva. A continuación, se detallan los parámetros más relevantes y sus implicaciones prácticas.

• Rango de Frecuencia: El rango operativo depende directamente del sintonizador integrado en el dongle. El modelo más común, el Rafael Micro R820T/2/R860, cubre de 24 a 1766 MHz. Modelos específicos como el RTL-SDR Blog V3/V4 incorporan mejoras de hardware que permiten la recepción de señales por debajo de 24 MHz, en la banda de HF.

• Tasa de Muestreo (Sample Rate): La tasa de muestreo máxima estable es de 2.56 MS/s (Mega Muestras por Segundo). Aunque el dispositivo puede configurarse a tasas superiores como 3.2 MS/s, esto a menudo resulta en la pérdida de muestras. La pérdida de muestras es aceptable para una visualización general del espectro, pero puede ser problemática para la decodificación precisa de señales digitales.

• Resolución ADC: La resolución nativa del convertidor analógico-digital (ADC) es de 8 bits. Sin embargo, es importante notar que el Número Efectivo de Bits (ENOB) se estima en aproximadamente 7 bits. Técnicas de software como la decimación pueden mejorar este valor en la práctica.

• Impedancia de Entrada: La mayoría de los dongles, diseñados originalmente para TV, tienen una impedancia de entrada de 75 Ohms. Sin embargo, los modelos más recientes equipados con conectores SMA están estandarizados a 50 Ohms. Es importante señalar que la pérdida por desajuste al conectar una antena de 50 Ohms a una entrada de 75 Ohms (o viceversa) es mínima, típicamente inferior a 0.177 dB.

• Requisitos Mínimos del Sistema: Para operar software de SDR con interfaz gráfica (GUI), generalmente se requiere un procesador de doble núcleo. Las herramientas de línea de comandos pueden funcionar con hardware menos potente, siendo una opción viable para dispositivos de placa única como la Raspberry Pi 3 en aplicaciones embebidas o sin interfaz gráfica.

Antes de poder aprovechar estas capacidades, es imperativo configurar correctamente el entorno de software en el sistema operativo correspondiente, un procedimiento que se detalla en las siguientes secciones.

2.0 Procedimiento de Instalación de Controladores y Entorno

2.1 Configuración en Sistemas Operativos Windows

La configuración en Windows exige un paso crítico: la sustitución del controlador DVB-T predeterminado por el controlador WinUSB. Este procedimiento es esencial para que el dongle sea reconocido como un dispositivo SDR genérico por aplicaciones como SDR#, HDSDR y otras. La herramienta estándar para esta tarea es Zadig.

A continuación se presenta el procedimiento detallado basado en la guía de configuración de SDR#:

1. Descargar el Paquete SDR#: Descargue el archivo sdrsharp-x86.zip desde el sitio web oficial de airspy.com.

2. Extraer Archivos: Extraiga el contenido del archivo ZIP en una carpeta dedicada (ej. C:\SDR). Advertencia: No ejecute ningún archivo directamente desde el ZIP. No extraiga el contenido en el directorio Program Files, ya que las restricciones de permisos de Windows pueden causar fallos en la instalación.

3. Ejecutar install-rtlsdr.bat: Dentro de la carpeta extraída, haga doble clic en el archivo install-rtlsdr.bat. Este script descargará automáticamente los archivos necesarios, incluyendo rtlsdr.dll y zadig.exe.

4. Conectar el Dongle: Conecte el dispositivo RTL-SDR a un puerto USB disponible y espere a que Windows intente instalarlo (lo cual fallará o instalará un controlador de TV incorrecto).

5. Ejecutar Zadig: Haga clic derecho sobre zadig.exe y seleccione “Ejecutar como administrador”.

6. Configurar Opciones de Zadig: En el menú de Zadig, navegue a “Options → List All Devices” y asegúrese de que esta opción esté marcada.

7. Seleccionar el Dispositivo Correcto: Seleccione el dispositivo en el menú desplegable. Este puede aparecer con varios nombres, incluyendo “Bulk-In, Interface (Interface 0)”, “RTL2832U”, “RTL2832UHIDIR” o “Blog V4”. Es crucial verificar que el ID de USB corresponda a “0BDA 2838 00” para confirmar la selección correcta.

8. Instalar el Controlador WinUSB: Asegúrese de que WinUSB esté seleccionado en el campo del controlador de destino (el cuadro a la derecha de la flecha verde). Haga clic en “Replace Driver”. Acepte cualquier advertencia de seguridad que pueda aparecer.

Una vez completado este proceso, el RTL-SDR está listo para ser utilizado por el software SDR en Windows. Con los controladores de Windows listos, el siguiente paso es abordar la configuración en entornos Linux.

2.2 Configuración en Sistemas Operativos Linux (Debian/Ubuntu y Derivados)

La configuración en Linux es un proceso más directo a través de la línea de comandos. Implica compilar la librería librtlsdr desde su código fuente, configurar reglas udev para permitir el acceso al dispositivo sin privilegios de superusuario, y deshabilitar los módulos de kernel DVB-T que entran en conflicto.

1. Instalar Dependencias: Abra un terminal e instale los paquetes necesarios para la compilación.

2. Clonar y Compilar rtl-sdr: Descargue el código fuente, compile e instale la librería. El flag adicional -DDETACH_KERNEL_DRIVER=ON es una medida proactiva que ayuda al sistema a desvincular automáticamente los controladores DVB preexistentes, previniendo conflictos.

3. Configurar Reglas udev: La opción -DINSTALL_UDEV_RULES=ON utilizada en el paso anterior está diseñada para instalar automáticamente las reglas udev. Como paso de verificación, o si la instalación automatizada falla, copie manualmente el archivo de reglas al directorio correspondiente para permitir que las aplicaciones accedan al dongle sin sudo.

4. Deshabilitar Controladores DVB-T (Blacklisting): Para evitar que el sistema operativo trate el dongle como un sintonizador de TV, añada el módulo del kernel a la lista negra.

5. Verificación: Reinicie el sistema o simplemente desconecte y vuelva a conectar el dongle. Ejecute rtl_test en la terminal. Una salida exitosa confirmará que el dispositivo y los controladores están correctamente instalados.

Independientemente del sistema operativo utilizado, el siguiente paso crítico para una operación precisa es la calibración de la frecuencia del dispositivo para corregir las imprecisiones inherentes a su oscilador.

3.0 Calibración de Frecuencia y Corrección de PPM

Los dongles RTL-SDR estándar utilizan osciladores de cristal de bajo costo, que presentan una imprecisión inherente en su frecuencia de operación. Este error se mide en Partes Por Millón (PPM) y, aunque puede parecer pequeño (errores de 30 a 50 PPM son comunes), es un factor crítico. Para señales de banda estrecha, como las comunicaciones de voz digital (P25, DMR) o datos (POCSAG), un error no corregido puede hacer que la señal se desplace fuera del ancho de banda del filtro del receptor, impidiendo por completo su decodificación.

La utilidad de línea de comandos kalibrate-rtl (kal) proporciona una solución de bajo impacto para medir este error con alta precisión. Esta herramienta aprovecha las señales de las estaciones base de telefonía móvil (GSM), cuya frecuencia está rigurosamente controlada y referenciada a sistemas GNSS. Al escanear estas señales de referencia, kal puede calcular el error PPM del dongle de forma fiable y automatizada.

A continuación se detalla el procedimiento para utilizar kalibrate-rtl en un entorno Linux:

1. Escanear Bandas GSM: Ejecute kal con el parámetro -s seguido de la banda GSM apropiada para su región (ej. GSM850, GSM900, DCS, PCS). La herramienta buscará estaciones base y mostrará los canales detectados y la potencia de su señal.

2. La salida mostrará una lista de canales, como: GSM-850: chan: 128 (869.2MHz - 3.988kHz) power: 486634.32

3. Calcular el Desplazamiento: Elija uno de los canales con mayor potencia de la lista y ejecute kal de nuevo, esta vez con el parámetro -c seguido del número del canal.

4. Como alternativa, si ya se conoce una frecuencia de una estación base GSM potente, se puede medir directamente el error de PPM utilizando el flag -f, omitiendo el paso de escaneo. Por ejemplo: kal -f 872.6M.

5. Interpretar los Resultados: La herramienta medirá el desplazamiento de frecuencia y calculará el error PPM promedio. La salida será similar a esta:

6. El valor clave es average absolute error. En este ejemplo, el error es 4.709 ppm. Este es el valor de corrección que debe registrarse y utilizarse en la configuración de su software SDR para garantizar una sintonización precisa.

Este valor de PPM se introducirá en la configuración de las aplicaciones GUI para asegurar una sintonización precisa, un paso que se detallará en la siguiente sección.

4.0 Guías de Operación para Software de Recepción

4.1 Operación con SDR# (Windows)

SDR# (SDRSharp) es una de las aplicaciones SDR más populares y fáciles de usar para Windows. Su interfaz intuitiva la convierte en una herramienta ideal para la exploración visual del espectro y la demodulación de señales comunes.

Asumiendo que los controladores se instalaron correctamente como se describe en la sección 2.1, siga estos procedimientos para la operación básica:

1. Iniciar la Aplicación: Ejecute el archivo SDRSharp.dotnet8.exe desde la carpeta donde fue extraído.

2. Seleccionar la Fuente: En el menú de la esquina superior izquierda (menú hamburguesa), despliegue la sección “Source” y seleccione ‘RTL-SDR USB’.

3. Iniciar la Recepción: Presione el botón de Play (triángulo) ubicado en la barra de herramientas superior. Debería empezar a ver la cascada y el espectro en tiempo real.

4. Ajustar la Ganancia (RF Gain): Este es un paso fundamental. Por defecto, la ganancia es cero. Abra la ventana de configuración de la fuente (icono de engranaje) e incremente el control deslizante de ganancia. Aumente el valor hasta que las señales sean claramente visibles por encima del ruido de fondo en la pantalla del espectro.

5. Configurar la Corrección de Frecuencia (PPM): En la misma ventana de configuración, introduzca el valor de PPM que obtuvo en la sección 3.0. Esto calibrará la frecuencia del receptor.

6. Navegación y Demodulación Básica: Para sintonizar una frecuencia, simplemente haga clic sobre la señal de interés en la pantalla de la cascada o el espectro. En el panel “Radio” de la izquierda, puede seleccionar el modo de demodulación adecuado, como NFM (Narrowband FM) para comunicaciones de voz, WFM (Wideband FM) para radio comercial, o AM para aviación.

Con SDR# correctamente configurado, ya está listo para explorar el espectro. HDSDR ofrece otra potente alternativa para los usuarios de Windows.

4.2 Operación con HDSDR (Windows)

HDSDR es una alternativa de software robusta y popular para Windows. Su arquitectura se basa en el uso de módulos ExtIO (External Input/Output), que son DLLs que actúan como interfaz entre el software y el hardware SDR.

Siga estos pasos para una configuración y operación inicial:

1. Instalar el Módulo ExtIO: Descargue el archivo ExtIO_RTL.dll compatible con su RTL-SDR. Copie este archivo DLL directamente en el directorio de instalación de HDSDR (normalmente C:\Program Files (x86)\HDSDR).

2. Iniciar HDSDR y Seleccionar DLL: La primera vez que inicie HDSDR después de copiar la DLL, es posible que le pida seleccionar el módulo de entrada. Elija ExtIO_RTL.dll de la lista.

3. Iniciar la Recepción: Presione el botón Start en la parte inferior de la ventana o use la tecla de atajo F2. El espectro y la cascada deberían activarse.

4. Configurar Parámetros del RTL-SDR: Haga clic en el botón “SDR-Device”. Esto abrirá una ventana de configuración específica del ExtIO, donde podrá ajustar la tasa de muestreo, la ganancia de RF y, lo más importante, la corrección de frecuencia (PPM). Introduzca aquí el valor de calibración obtenido previamente.

5. Sintonización: HDSDR utiliza un sistema de sintonización de dos niveles. Primero, ajuste la frecuencia del Oscilador Local (LO) para centrar el segmento del espectro que le interesa. Luego, realice la sintonización fina haciendo clic directamente sobre la señal deseada en la pantalla de espectro de RF.

Ahora, el manual se enfocará en el entorno Linux, presentando la aplicación GQRX como una solución de código abierto equivalente.

4.3 Operación con GQRX (Linux)

GQRX es un receptor SDR de código abierto muy popular para Linux y otros sistemas operativos tipo Unix. Está construido sobre la base del framework de procesamiento de señales GNU Radio y ofrece una interfaz gráfica completa para la exploración del espectro.

Para la configuración y operación básica, siga estos pasos:

1. Configurar Dispositivo de Entrada: Al iniciar GQRX por primera vez, aparecerá una ventana de “Configure I/O devices”. Seleccione su dispositivo RTL-SDR de la lista de dispositivos. La cadena del dispositivo suele contener “Realtek RTL2838”.

2. Ajustar Parámetros Clave: En la misma ventana de configuración, establezca la tasa de muestreo de entrada (Input rate), por ejemplo, a 2.4e6 (2.4 MS/s). Asegúrese de introducir su valor de corrección de PPM en el campo correspondiente.

3. Iniciar la Recepción: Presione el icono de Play (triángulo) en la esquina superior izquierda para comenzar la adquisición de datos. El espectro y la cascada se activarán.

4. Ajustes de Ganancia y Sintonización: En la pestaña “Input Controls” de la derecha, puede ajustar la ganancia de RF. Increméntela para mejorar la sensibilidad. Para sintonizar una frecuencia, haga clic en la cascada o ajuste la frecuencia directamente en la parte superior de la ventana. Puede seleccionar el modo de demodulación (AM, NFM, etc.) en la pestaña “Receiver Options”.

Más allá del software específico que se utilice, comprender los problemas operativos comunes y cómo resolverlos es clave para una experiencia eficiente, tema que se aborda en la siguiente sección.

5.0 Solución de Problemas Comunes

La configuración y operación del RTL-SDR puede presentar ciertos desafíos, especialmente durante la configuración inicial. Esta sección está diseñada como una guía de referencia rápida para diagnosticar y resolver los problemas más frecuentes, asegurando una operación continua y sin contratiempos.

• Error: “No Device Selected” o “No compatible devices found” en SDR#

  • Causa: Generalmente, esto se debe a un error en la instalación del controlador con Zadig (por ejemplo, haber instalado el controlador en “Interface 1” en lugar de “Interface 0”). Otras causas comunes incluyen el uso de cables de extensión USB de baja calidad, puertos USB 3.0 incompatibles o que el archivo rtlsdr.dll no se descargó correctamente con el script install-rtlsdr.bat.

  • Solución: Vuelva a ejecutar Zadig como administrador, asegúrese de seleccionar “Bulk-In, Interface (Interface 0)” y reinstale el controlador WinUSB. Pruebe conectando el dongle directamente al PC sin cables de extensión.

• La Instalación con Zadig Falla o se Cuelga

  • Causa: Algunas configuraciones de seguridad de Windows pueden bloquear la instalación de nuevos controladores no firmados.

  • Solución: Intente ejecutar Zadig en el Modo Seguro de Windows para evitar posibles conflictos de software o de políticas de seguridad.

• Pico Constante en el Centro del Espectro

  • Causa: Este es un artefacto de DC inherente al diseño de muchos dongles RTL-SDR. Es un comportamiento normal.

  • Solución: En SDR#, active la opción “Correct IQ” en el panel de configuración de la fuente. Esto elimina el pico mediante un algoritmo de software.

• Recepción Pobre o Insensible

  • Causa: La causa más común es no haber ajustado la ganancia de RF, que por defecto está en cero. El uso de la antena de serie en interiores también limita sigfnificativamente la recepción.

  • Solución: Incremente el control deslizante de ganancia de RF en la configuración de su software. Para obtener resultados óptimos, utilice una antena exterior montada en una posición elevada.

• El Dongle Deja de Funcionar Después de una Actualización de Windows

  • Causa: El sistema de actualizaciones automáticas de Windows a veces sobrescribe el controlador SDR personalizado (WinUSB) con un controlador DVB-T genérico.

  • Solución: Simplemente vuelva a ejecutar Zadig y reinstale el controlador WinUSB como se hizo en la configuración inicial. Se recomienda desactivar las actualizaciones automáticas de controladores de Windows.

• El Dongle se Calienta Excesivamente

  • Causa: Es normal que el dispositivo se sienta tibio o incluso caliente al tacto durante su funcionamiento. Sin embargo, si el calor es tan excesivo que causa fallos intermitentes o el dispositivo deja de funcionar, podría ser indicativo de un defecto de fábrica.

  • Solución: Asegúrese de que haya algo de flujo de aire alrededor del dispositivo. Si el sobrecalentamiento causa fallos, contacte al vendedor para un posible reemplazo.

Con estos procedimientos de solución de problemas, se pueden resolver la mayoría de los inconvenientes operativos. La sección final del manual ofrece recursos adicionales para una exploración más profunda.

6.0 Apéndice: Recursos y Referencias

Esta sección final proporciona materiales de referencia para el profesional que desee profundizar en la tecnología RTL-SDR.

Tabla de Rangos de Frecuencia por Sintonizador

El rango de frecuencia de un dongle RTL-SDR está determinado por el chip sintonizador que utiliza. La siguiente tabla resume los rangos de los sintonizadores más comunes.

Sintonizador Rango de Frecuencia

---

Elonics E4000 52 — 2200 MHz (con un hueco de 1100 a 1250 MHz) Rafael Micro R820T/2/R860 24 — 1766 MHz Rafael Micro R828D 24 — 1766 MHz (Modelo RTL-SDR Blog V4). Otros modelos pueden tener un corte cercano a 1 GHz. Fitipower FC0013 22 — 1100 MHz Fitipower FC0012 22 — 948.6 MHz FCI FC2580 146 — 308 MHz y 438 — 924 MHz (con hueco intermedio)

Fuente: Osmocom

Lista de Enlaces Útiles

• Sitio oficial de Osmocom RTL-SDR: http://sdr.osmocom.org/trac/wiki/rtl-sdr

• Foro de Reddit sobre RTL-SDR: http://www.reddit.com/r/RTLSDR

• Guía de Inicio Rápido de RTL-SDR.com: https://www.rtl-sdr.com/rtl-sdr-quick-start-guide/

• Guía de Usuario de SDR# de RTL-SDR.com: [https://www.rtl-sdr.com/sdrsharp-users-guide/]{.underline}

1. La Fórmula ARFCN y la Frecuencia Válida

La fórmula que has encontrado es la clave para mapear el número de canal lógico (ARFCN) a una frecuencia física específica en el aire (FDL).

¿Cómo calcular la frecuencia válida?

La fórmula general de mapeo para GSM (y E-GSM) es un estándar global. Las frecuencias disponibles están divididas en portadoras de 200 kHz (el ancho de un canal GSM).

Tu fórmula es para el rango E-GSM (GSM Extendido), que utiliza un segmento de frecuencia adicional para la banda de 900 MHz:

FDL​(MHz)=925.2+0.2×(ARFCN−975)

Componente Significado Valor para tu caso (ARFCN 977)

---

ARFCN Absolute Radio Frequency Channel Number (Número de canal) 977 (Tu canal encontrado) 0.2 Ancho de canal en MHz (200 kHz) Fijo 925.2 Frecuencia base para el canal 975 Fijo 975 ARFCN más bajo en este subrango Fijo FDL​ Frecuencia Downlink (Torre → Dongle) 925.6 MHz

Tu cálculo es perfectamente correcto:

FDL​=925.2+0.2×(977−975)=925.2+0.2×2=925.6 MHz

La frecuencia válida que tu dongle debe sintonizar para decodificar la celda 977 es 925.6 MHz.

2. Comunicación Básica (Dongle y Torre)

La comunicación es unidireccional para el propósito de la decodificación con tu dongle (solo escuchas):

La Torre de Telefonía (Estación Base, BTS)

La torre es la que inicia la conversación. Transmite constantemente la información más básica y crítica a través de un canal llamado BCCH (Broadcast Control Channel):

1. BCCH: Transmite datos de Sincronización (para que tu dongle sepa cuándo comienza y termina un paquete de datos).

2. System Information: Transmite los códigos de la operadora (MCC/MNC), el identificador de celda (CID/LAC) y la lista de canales vecinos (ARFCNs) para que los teléfonos puedan moverse entre celdas sin perder la conexión.

El Dongle RTL-SDR

Tu dongle no puede transmitir, solo es un receptor.

1. Recepción de RF: El dongle recibe la señal de radiofrecuencia (RF).

2. Digitalización: Convierte esa señal analógica a datos digitales sin procesar (datos I/Q).

3. GR-GSM (El software): El programa grgsm_livemon toma esos datos I/Q y realiza el trabajo de demodulación y decodificación:

   • Busca la señal de sincronización enviada por la torre.

   • Una vez sincronizado, lee la información del BCCH y extrae los códigos de la red y de la celda.

4. Wireshark (La Interfaz): El software toma los paquetes decodificados por GR-GSM (vía protocolo GSMTAP en el puerto 4729) y los muestra de forma legible, permitiéndote ver los “System Information” y los Paging Requests.

3. Códigos de Operadoras y Celdas

¿Si salta como Orange, es que la torre es de Orange o la celda?

Cuando grgsm_scanner te muestra: MCC: 214, MNC: 3, CID: 44567

• MCC (Mobile Country Code): 214 es el código de España.

• MNC (Mobile Network Code): 3 es el código de la operadora Orange España.

Sí, si el escáner indica Orange, significa que la celda (y por extensión, la torre que transmite esa celda) pertenece a la red de Orange. La celda es el área geográfica cubierta por una antena específica de esa torre.

El término correcto es “Celda”:

• Una Torre puede albergar varias antenas, y cada antena puede emitir varias Celdas (sectores).

• El MCC y MNC identifican la red propietaria de esa Celda específica.

• El CID (Cell ID) identifica de forma única esa celda dentro de la red Orange.

De esta manera, tu teléfono (o tu dongle) sabe exactamente a qué red y a qué punto geográfico de transmisión se está conectando.

1. Estandarización de Frecuencias GSM

La fórmula y los números base que mencionaste pertenecen específicamente a la banda E-GSM 900 (Extended GSM 900).

A. ARFCN (Absolute Radio Frequency Channel Number)

El ARFCN es el índice del canal. Es un número que identifica de forma única la posición de una portadora de 200 kHz dentro de una banda GSM específica.

• ¿Por qué es estándar? Para que un teléfono fabricado en China pueda sintonizar una torre en España o Alemania (si ambos países usan esa banda). Es la manera que tienen las redes de decirle al teléfono: “Sintoniza el canal 977” en lugar de “Sintoniza 925.6 MHz”, lo cual es menos propenso a errores.

B. Frecuencia Base (925.2 MHz)

El valor de 925.2 MHz es la frecuencia de referencia del Downlink (Torre → Móvil) para el ARFCN 975.

• 925.2 MHz (para el Downlink) y 880.2 MHz (para el Uplink) marcan el inicio del rango de frecuencias asignado al segmento extendido de GSM 900.

• El ancho de 0.2 MHz (200 kHz) representa el espaciado entre cada canal (el tamaño de la portadora) y también es un valor fijo y estándar globalmente.

2. Tablas y Rangos Estándar

Existen varias bandas GSM estandarizadas. Cada una tiene su propio rango de ARFCN y su propia fórmula base:

Banda GSM Rango de ARFCN Downlink FDL​ (Torre → Móvil) Frecuencia Base

---

GSM 900 1 a 124 935.2+0.2×(ARFCN−1) 935.2 MHz E-GSM 900 975 a 1023 925.2+0.2×(ARFCN−975) 925.2 MHz GSM 1800 512 a 885 1805.2+0.2×(ARFCN−512) 1805.2 MHz

Tu celda ARFCN 977 se encuentra en el rango E-GSM 900, que se utiliza comúnmente en Europa (incluida España) para dar más capacidad a la red que la que ofrece la banda estándar GSM 900.

Dragon OS - RTL-SDR Optimizado para CLI y Captura en Red

1. Introducción y Fundamentos de Optimización

Este manual proporciona una guía de procedimientos operativos para la configuración y el uso del hardware RTL-SDR exclusivamente a través de la línea de comandos (CLI) en sistemas operativos especializados como Kali Linux o DragonOS. El objetivo principal es minimizar el consumo de recursos de CPU y RAM, permitiendo una operación estable y eficiente en sistemas de bajo rendimiento. La operación mediante la CLI es fundamental para la eficiencia; la principal fuente de consumo de CPU en SDR reside en dos áreas: 1) la tasa de transferencia de datos de Muestras en Fase y Cuadratura (I/Q), y 2) el procesamiento digital de señales (DSP) auxiliar necesario para la visualización. Mientras que las herramientas con interfaz gráfica (GUI) como Gqrx o SDR# imponen una alta carga debido a la renderización constante de la cascada y el espectro, las utilidades de línea de comandos procesan los datos crudos de forma directa a través de tuberías (pipes). Este enfoque elimina la sobrecarga de la visualización y reduce el DSP a sus funciones más esenciales, garantizando el máximo rendimiento con el mínimo impacto. A continuación, se detallan los pasos para configurar correctamente el entorno operativo.

2. Configuración Inicial del Entorno Operativo

Una configuración de sistema limpia y correcta es un prerrequisito crítico para garantizar una operación estable, libre de conflictos y con el máximo rendimiento posible del dongle RTL-SDR. Los siguientes pasos son indispensables para establecer una base operativa robusta antes de proceder a la captura y análisis de señales.

2.1. Instalación de Drivers y Herramientas Esenciales

El núcleo del ecosistema RTL-SDR en Linux es la librería librtlsdr del proyecto Osmocom. Para asegurar la compatibilidad y el rendimiento, es recomendable compilarla directamente desde su código fuente.

1. Instalar dependencias de compilación:

2. Clonar el repositorio oficial de Osmocom:

3. Compilar la librería: Se crea un directorio de compilación para mantener el código fuente limpio. El parámetro -DINSTALL_UDEV_RULES=ON automatiza la preparación de las reglas de acceso al dispositivo.

4. Instalar en el sistema:

5. Copiar reglas udev: Este paso es fundamental para permitir que las aplicaciones accedan al dispositivo RTL-SDR como un usuario estándar, sin necesidad de privilegios de superusuario (sudo). El flag -DINSTALL_UDEV_RULES=ON del paso anterior debería gestionar esto automáticamente durante la instalación, pero este comando manual sirve como verificación o como método alternativo si la instalación automatizada falla.

2.2. Aislamiento del Dispositivo (Blacklisting de Módulos del Kernel)

Por defecto, el kernel de Linux puede identificar el dongle RTL-SDR como un sintonizador de televisión digital (DVB-T) y cargar los drivers correspondientes. Estos módulos del kernel entran en conflicto directo con la librería librtlsdr, impidiendo su uso en modo SDR. Para resolver esto, es necesario poner en una lista negra (blacklist) el módulo conflictivo.

• Comando para crear el archivo de configuración de la lista negra:

Tras ejecutar este comando, se recomienda reiniciar el sistema o desconectar y volver a conectar el dongle.

2.3. Calibración de Frecuencia de Bajo Impacto (PPM)

Los dongles RTL-SDR económicos utilizan osciladores de cristal de baja precisión, lo que genera un error de frecuencia significativo que puede llegar hasta 50 partes por millón (PPM). Una calibración precisa no solo es indispensable para sintonizar correctamente señales de banda estrecha, sino que también es una estrategia de optimización de recursos. Al corregir este error, el software puede aplicar un filtro de banda base mucho más estrecho y preciso, reduciendo así la carga computacional general del DSP.

La utilidad kalibrate-rtl (kal) permite calcular este error con un impacto mínimo en el sistema, utilizando como referencia las estaciones base GSM, cuya frecuencia está estabilizada mediante GNSS.

• Instrucción de uso: Primero, escanee una banda GSM (como GSM900) para identificar los canales activos y sus errores de frecuencia preliminares. Luego, utilice uno de los canales encontrados para realizar un cálculo preciso del error PPM.

• Ejemplo de Comando:

• Conclusión: El comando final mostrará un resumen del error. Anote el valor de “average absolute error”; este es el valor PPM que deberá usar con el parámetro -p en todos los comandos de captura posteriores. Si la calibración falla porque las señales de la torre celular quedan fuera de la banda de paso del receptor, utilice una aplicación con GUI como Gqrx para encontrar manualmente la frecuencia de una señal GSM potente e invóquela directamente con kal -c <canal>.

Nota: En todos los comandos posteriores de este manual, reemplace <PPM> con el valor numérico que ha obtenido en este paso.

Con el entorno ya calibrado y optimizado, podemos proceder a los flujos de trabajo de captura.

3. Comandos de Captura para Bandas Específicas

A continuación se presentan cadenas de comandos optimizadas para explorar y decodificar señales en bandas de interés comunes (GSM, ISM, Sub-GHz). Estos flujos de trabajo están diseñados para un consumo mínimo de CPU y RAM, ideales para operación desatendida en sistemas de bajos recursos.

3.1. Exploración de Bandas GSM (850/900/1800/1900 MHz)

Si bien la decodificación completa de GSM es una tarea intensiva en recursos, el primer paso ---identificar canales de estaciones base activas--- se puede realizar con un impacto computacional muy bajo. La herramienta ideal para este propósito es rtl_power, que opera mediante salto de frecuencia (frequency hopping) y promedia la potencia de la señal a través de integración temporal, en lugar de realizar un análisis FFT continuo. La visualización (p. ej., la generación de mapas de calor) se realiza como un proceso separado y fuera de línea, lo que explica su extremadamente bajo consumo de CPU durante la fase de captura.

• Ejemplo de Comando: El siguiente comando escanea la banda EGSM (una porción de GSM900) y guarda los resultados de potencia de señal en un archivo CSV para su posterior análisis.

  • -f 890M:915M:10k: Define el rango de frecuencia (inicio:fin:paso).

  • -i 5: Especifica un intervalo de integración de 5 segundos, distribuyendo la carga de trabajo en el tiempo.

  • -g 40: Fija la ganancia a un valor conocido (aprox. 40 dB) para evitar fluctuaciones del AGC.

  • -p <PPM>: Aplica la corrección de frecuencia previamente calculada.

Nota: En distribuciones como DragonOS, herramientas más avanzadas como grgsm_scanner (parte del paquete gr-gsm) pueden identificar directamente los parámetros de las estaciones base, aunque suponen un consumo de recursos significativamente mayor que rtl_power.

3.2. Decodificación de Bandas ISM y Sub-GHz (433/868 MHz)

La herramienta rtl_433 es el estándar de facto para decodificar una vasta gama de dispositivos de bajo consumo. Es ideal para este manual, ya que está escrito en C (C99) con un enfoque en el bajo consumo de recursos y mínimas dependencias, lo que le permite ejecutarse en hardware embebido como Raspberry Pi. Para una máxima eficiencia, es crucial especificar únicamente los protocolos que se desean decodificar.

• Comando rtl_433 Optimizado: Este ejemplo se enfoca en decodificar sensores meteorológicos de la marca Acurite (identificador de protocolo 40). Al usar -R 40, rtl_433 solo ejecutará el algoritmo de decodificación relevante, en lugar de intentar aplicar todos los decodificadores disponibles con la opción -G.

• Decodificación de Pagers (POCSAG): Para decodificar mensajes de pagers (protocolo POCSAG), se puede construir una cadena de comandos altamente eficiente utilizando rtl_fm y multimon-ng. La tubería (|) conecta la salida de audio demodulada de rtl_fm directamente a la entrada del decodificador multimon-ng, procesando los datos en memoria sin necesidad de archivos intermedios.

4. Captura en Red para Análisis con Wireshark

Una capacidad clave para el análisis de protocolos es convertir las señales de radiofrecuencia (RF) en tráfico de red. Esto permite utilizar herramientas estándar como Wireshark para capturar y analizar los datos en la interfaz de red local o de loopback (lo).

4.1. Streaming de Muestras I/Q Crudas con rtl_tcp

rtl_tcp es el método más directo y de menor sobrecarga para transmitir los datos I/Q crudos del RTL-SDR a través de una red TCP/IP. El dispositivo que ejecuta rtl_tcp actúa como un servidor, consumiendo una cantidad mínima de CPU, ya que su única tarea es gestionar la transferencia de datos desde el USB a la red.

• Ejemplo de Comando del Servidor: Este comando inicia un servidor rtl_tcp que escucha en la interfaz de loopback (127.0.0.1) en el puerto 1234.

• Instrucciones para Wireshark:

  1. Inicie Wireshark.

  2. Seleccione la interfaz de captura Loopback: lo.

  3. En la barra de filtro de visualización, introduzca tcp.port == 1234 y presione Enter.

  4. Inicie la captura. Observará un flujo constante de paquetes TCP que contienen los datos I/Q crudos del dongle.

4.2. Streaming de Datos Decodificados (Ejemplo con rtl_433)

Algunas herramientas pueden enviar datos ya decodificados a través de la red, lo que permite un análisis de protocolo de nivel superior. rtl_433 puede publicar mensajes decodificados a un broker MQTT, un protocolo estándar para mensajería IoT.

• Ejemplo de Comando: El siguiente comando configura rtl_433 para decodificar sensores en 433.92 MHz y enviar los resultados en formato MQTT a un broker que se ejecute en la máquina local (localhost).

• Instrucciones para Wireshark: Si se está ejecutando un broker MQTT local (como Mosquitto), puede capturar el tráfico en la interfaz lo. Utilice el filtro mqtt para que Wireshark diseccione automáticamente el protocolo, o tcp.port == 1883 (el puerto estándar de MQTT) para ver el tráfico TCP subyacente.

5. Flujos de Trabajo Avanzados y Optimización de Procesos

Para el monitoreo a largo plazo o la decodificación de señales complejas, es fundamental construir cadenas de comandos robustas y gestionar los procesos de manera eficiente para no impactar la estabilidad del sistema.

5.1. Estabilización de Cadenas de Audio con sox

Un problema común al conectar rtl_fm con decodificadores de audio es la aparición de errores de underrun. Estos errores ocurren porque los decodificadores como DSD (Digital Speech Decoder) son extremadamente sensibles a la tasa de muestreo de audio de entrada, requiriendo un flujo estable de 48 kHz. La salida de rtl_fm puede no ser lo suficientemente precisa, causando picos de CPU y pérdida de datos.

• La Solución: La herramienta sox (Sound eXchange), escrita en C, actúa como un intermediario estabilizador, ligero y altamente eficiente. Se inserta en la tubería para recibir el flujo de audio de rtl_fm, remuestrearlo (resampling) a la tasa precisa y estable de 48000 Hz, y entregarlo al decodificador, previniendo los ciclos de error y reintento de los buffers que consumen CPU.

• Ejemplo de Cadena Optimizada (Voz Digital P25): Esta cadena decodifica una señal de voz digital P25. rtl_fm demodula la señal, sox la estabiliza a 48 kHz, y dsd la decodifica. Se antepone padsp para asegurar la compatibilidad en sistemas que usan PulseAudio.

• Análisis del Comando: La parte clave es sox [parámetros de entrada] - [parámetros de salida] -, que actúa como un filtro en la tubería. El parámetro -f1 en dsd es una optimización crucial: especifica explícitamente el modo P25 Fase 1, lo que reduce drásticamente la carga de DSP al evitar la auto-detección del protocolo.

5.2. Gestión de Procesos para Monitoreo Continuo

Para la operación desatendida (headless), especialmente a través de sesiones SSH, es vital gestionar los procesos para que sean persistentes y no interfieran con el rendimiento del sistema.

• nice: Este comando ejecuta un proceso con una prioridad de planificación reducida. Un valor de 19 representa la prioridad más baja, asegurando que las tareas de SDR solo utilicen los ciclos de CPU que no son requeridos por procesos más críticos del sistema.

  • Ejemplo:

• nohup: Este comando (“no hang up”) permite que un proceso continúe ejecutándose incluso si el terminal que lo inició se cierra. Es esencial para tareas de monitoreo a largo plazo.

  • Ejemplo:

  • El & al final del comando envía el proceso a segundo plano, devolviendo el control del terminal al usuario de inmediato.

6. Apéndice: Tabla de Referencia Rápida

La siguiente tabla resume los comandos y cadenas de comandos más importantes discutidos en este manual, con un enfoque en las prácticas de optimización para un bajo consumo de recursos.

Herramienta (Comando) Propósito Principal Ejemplo de Comando Optimizado

---

kal Calcular el error de frecuencia (PPM) del dongle. kal -s GSM900 rtl_power Escanear un rango de espectro con bajo uso de CPU. rtl_power -f 144M:148M:1k -i 60 -g 35 -p <PPM> -1 scan.csv rtl_433 Decodificar sensores y dispositivos en bandas ISM. rtl_433 -f 433.92M -s 250k -R 40 -p <PPM> rtl_tcp Servir muestras I/Q crudas a través de la red. nice -n 19 rtl_tcp -a 127.0.0.1 -p 1234 -s 1.024e6 rtl_fm | sox | … Decodificar señales de banda estrecha (datos/voz). rtl_fm … | sox … -r 48000 - | multimon-ng …

Estrategias CLI para Visualización y Escaneo (rtl_power)

Para escanear grandes porciones de espectro sin la necesidad de una interfaz gráfica (que consume mucha CPU para renderizar la cascada/FFT)

, utilizamos rtl_power.

Esta herramienta es de bajo consumo porque opera saltando de frecuencia y promediando la potencia de la señal (integración), en lugar de realizar análisis FFT continuos

.

Parámetro Propósito Recomendación de Eficiencia

---

-f low:high:step Define el rango de frecuencia y la resolución del bin (paso)

. Ajusta el paso (step) al mínimo necesario para reducir el tiempo de escaneo

---

.

---

-i <intervalo> Tiempo que el dispositivo promedia la potencia en cada bin antes de registrar el resultado (tiempo de integración)

. Usa intervalos largos (ej., 60 segundos) para distribuir la carga computacional en el tiempo, reduciendo la demanda de CPU en un momento dado

---

---

.

---

-1 Realiza un único barrido completo y sale

---

---

. Útil para análisis puntuales

---

---

---

.

---

Ejemplo de Comando de Escaneo de Espectro: Este comando monitorea desde 150 MHz hasta 200 MHz, con una resolución de 2 kHz, e integra la potencia durante 10 segundos antes de guardar la entrada en logfile.csv

:

rtl_power -f 150M:200M:2k -i 10 logfile.csv

Visualización y Exportación de Datos de rtl_power

El archivo .csv resultante no es un CSV tradicional, sino que se utiliza para generar gráficos de mapa de calor (heatmap) o gráficos de cascada (waterfall) fuera de línea (offline)

. Esto asegura que el dispositivo de adquisición (como una Raspberry Pi) sea lo más liviano posible

.

Existen scripts externos de Python (como heatmap.py de CGrassin o keenerd) que procesan el archivo .csv de rtl_power para generar visualizaciones en formato PNG

.

2. Estrategias CLI para Exportación y Captura I/Q (rtl_sdr)

rtl_sdr es la utilidad con menor sobrecarga de CPU, ya que su función principal es volcar directamente los datos binarios de Muestras en Fase y Cuadratura (I/Q)

.

Opción CLI Propósito Recomendación de Eficiencia

---

-s <rate> Tasa de muestreo I/Q (MS/s o Hz)

. Crítico: Usar la tasa mínima requerida para el ancho de banda de la señal. Esto reduce el ancho de banda USB y la cantidad de datos que debe procesar el DSP

---

---

.

---

-n Número exacto de muestras a <samples> capturar

---

. Es vital para evitar la operación infinita por defecto y limitar el tamaño del archivo, optimizando la gestión de RAM y disco

---

.

---

- Se usa como nombre de archivo para volcar las muestras I/Q directamente a una tubería (stdout)

. Permite redirigir el flujo a herramientas de compresión livianas (como gzip) para reducir el espacio de almacenamiento y evitar la saturación de RAM

---

---

.

---

Ejemplo de Comando de Captura I/Q Eficiente: Este comando captura 10 segundos de datos I/Q a 2.4 MSPS (24 millones de muestras) y los comprime al instante

:

rtl_sdr -f 97.4e6 -s 2.4e6 -g 20 -n 24000000 - | gzip > capture_comprimida.gz

Relación con Universal Radio Hacker (URH) y otras GUI

La captura de muestras I/Q con rtl_sdr es la forma más eficiente de obtener datos de alta calidad. Estos archivos binarios pueden luego ser procesados fuera de línea en herramientas de GUI más potentes (como SDRSharp, o incluso, en principio, URH para análisis de protocolos), utilizando conversores de formato si es necesario (como iqToSharp)

.

3. Estrategias CLI para Control y Optimización de la Cadena

La optimización en CLI no solo se trata de las herramientas, sino de cómo se ejecutan los procesos y se mantiene la precisión.

Calibración de Frecuencia (PPM)

Un error en partes por millón (PPM) de hasta 50 es común en dongles

. Para decodificar modos de banda estrecha (como voz digital o POCSAG), la corrección es fundamental, ya que permite al software DSP usar filtros más estrechos, ahorrando recursos

.

Utiliza kalibrate-rtl (kal) para medir el desplazamiento usando señales GSM de alta precisión

.

Ejemplo de Uso de kal (Kali Linux):

1. Escanear la banda GSM (ej. GSM-850)

:

2. Calcular el desplazamiento usando un canal encontrado (ej. canal 128)

:

3. Aplicar el valor de PPM obtenido (ej. 45 ppm) a tus comandos SDR:

Control de Múltiples Dispositivos

Si usas más de un dongle (ej. para monitorear ADS-B y POCSAG simultáneamente)

, debes especificar el dispositivo. Puedes identificar y seleccionar el dispositivo por su índice (-d) o su número de serie

.

1. Listar dispositivos: Si usas un índice inválido, rtl_sdr mostrará los dispositivos conectados con sus índices y números de serie

:

2. Selección por Número de Serie: Para garantizar que el script siempre use el dispositivo correcto (ya que el índice puede cambiar), puedes usar el número de serie con la opción -d

Manual CLI de barridos con rtl_power + heatmap en DragonOS

A continuación tienes:

El script plot_heatmap.sh actualizado con auto‑escala, decimado temporal y listado de picos.

Comandos de barrido típicos para distintas bandas.

Guía de uso paso a paso y cómo ajustar rangos si “todo sale rojo”.

Requisitos

sudo apt update

sudo apt install -y rtl-sdr gnuplot jq

Opcional (para escuchar audio):

sudo apt install -y sox

1) Script plot_heatmap.sh (cópialo tal cual)

Guárdalo como plot_heatmap.sh, dale permisos: chmod +x plot_heatmap.sh

#!/usr/bin/env bash

# Genera un heatmap PNG a partir de un CSV de rtl_power y (opcional) lista de picos.

# Uso básico:

# ./plot_heatmap.sh vhf_12k5.csv

#

# Variables de entorno opcionales:

# MIN_DB, MAX_DB → Rango de color manual (dB). Ej: MIN_DB=-75 MAX_DB=-50

# AUTO=1 → Auto-escala (ignora MIN_DB/MAX_DB)

# SIGMA=2.5 → Si AUTO=1: rango = media ± SIGMA*desv

# DECIMATE=1 → Toma 1 de cada N líneas de tiempo (acelera render)

# FMIN,FMAX → Sobrescribe frecuencias (MHz) para X (por defecto, usa CSV)

# PALETTE=inferno|viridis|jet (por defecto inferno)

# PEAKS=1 → Genera lista de picos

# THR=-55 → Umbral dB para picos (default -55)

# GRID=12500 → Cuantiza picos a grid (Hz), ej 12500 para NFM

# TOPN=50 → Cuántos picos listar

set -euo pipefail

CSV=”${1:-vhf_12k5.csv}”

-f “$CSV” || { echo “ERROR: no existe $CSV”; exit 1; }

OUT=”${OUT:-${CSV%.*}_heatmap.png}”

MATRIX=”${CSV%.*}_matrix.txt”

GP=”${CSV%.*}_plot.gp”

AUTO=”${AUTO:-0}”

SIGMA=”${SIGMA:-2.5}”

DECIMATE=”${DECIMATE:-1}”

PALETTE=”${PALETTE:-inferno}”

MIN_DB=”${MIN_DB:—100}”

MAX_DB=”${MAX_DB:—20}”

THR=”${THR:—55}”

GRID=”${GRID:-12500}”

TOPN=”${TOPN:-50}”

# gnuplot

if ! command -v gnuplot >/dev/null 2>&1; then

echo ”[*] Instalando gnuplot…”

sudo apt update && sudo apt install -y gnuplot

fi

# Frecuencias del CSV (MHz)

FMIN_CSV=”$(awk -F, ‘NR==1{printf(“%.6f”,$3/1e6); exit}’ “$CSV”)”

FMAX_CSV=”$(awk -F, ‘NR==1{printf(“%.6f”,$4/1e6); exit}’ “$CSV”)”

FMIN=”${FMIN:-$FMIN_CSV}”

FMAX=”${FMAX:-$FMAX_CSV}”

# Estadísticos (media, sd, min, max) para auto-rango

if “$AUTO” == “1”; then

read MEAN SD MINV MAXV N <<<”$(awk -F, ’

function add(v){

if(v""||v”nan”||v"-nan"||v”inf”||v==“-inf”){v=-120}

if(v←200||v>50){v=-120}

n++; delta=v-mean; mean+=delta/n; m2+=delta*(v-mean);

if(n==1){min=v; max=v} else { if(v<min)min=v; if(v>max)max=v }

}

{ for(i=7;i⇐NF;i++){ add($i+0) } }

END{

sd=(n>1)?sqrt(m2/(n-1)):0;

printf “%.2f %.2f %.2f %.2f %.0f\n”, mean, sd, min, max, n

}’ “$CSV”)”

# Rango automático

lo=$(awk -v m=“$MEAN” -v s=“$SIGMA” -v sd=“$SD” ‘BEGIN{ printf “%.2f”, m - s*sd }’)

hi=$(awk -v m=“$MEAN” -v s=“$SIGMA” -v sd=“$SD” ‘BEGIN{ printf “%.2f”, m + s*sd }’)

# Asegura dentro de [min,max]

MIN_DB=$(awk -v a=“$lo” -v mn=“$MINV” ‘BEGIN{ if(a<mn) a=mn; printf “%.2f”, a }’)

MAX_DB=$(awk -v b=“$hi” -v mx=“$MAXV” ‘BEGIN{ if(b>mx) b=mx; printf “%.2f”, b }’)

echo ”[*] AUTO rango: mean=$MEAN sd=$SD → MIN_DB=$MIN_DB MAX_DB=$MAX_DB”

fi

# Matriz (potencias); decimado temporal

awk -F, -v dec=“$DECIMATE” ’

NR>0 {

if((NR-1)%dec!=0) next;

line="";

for(i=7;i⇐NF;i++){

v=$i; gsub(/ /,"",v);

if(v""||v”nan”||v"-nan"||v”inf”||v==“-inf”){ v=-120 }

line = line (i==7 ? v : ” ” v)

}

print line

}’ “$CSV” > “$MATRIX”

# Paletas

case “$PALETTE” in

inferno) PAL=“set palette rgb 33,13,10” ;;

viridis) PAL=“set palette defined (0 0.267 0.005 0.329, 1 0.993 0.906 0.144)” ;;

jet) PAL=“set palette defined (0 0 0 0.5, 0.5 0 1 1, 1 0.5 0 0)” ;;

*) PAL=“set palette rgb 33,13,10” ;;

esac

cat > “$GP” <<EOF

set term pngcairo size 1600,900

set output ’${OUT}’

unset key

set xlabel ‘Frecuencia (MHz)’

set ylabel ‘Tiempo (líneas)’

set cblabel ‘Potencia (dB)’

set view map

set pm3d map

$PAL

set cbrange [${MIN_DB}:${MAX_DB}]

set xrange [${FMIN}:${FMAX}]

splot ’${MATRIX}’ matrix with image

EOF

echo ”[*] Generando: $OUT (X=${FMIN}..${FMAX} MHz, cbrange ${MIN_DB}..${MAX_DB} dB, decimate ${DECIMATE}, palette ${PALETTE})”

gnuplot “$GP” >/dev/null 2>&1 || gnuplot “$GP”

echo “[OK] Heatmap: $OUT”

# Lista de picos agregados a GRID (Hz)

if ”${PEAKS:-0}” == “1”; then

PEAKS_OUT=”${CSV%.*}_peaks.txt”

awk -F, -v thr=“$THR” -v grid=“$GRID” ’

{

start=$3+0; bin=$5+0;

for(i=7;i⇐NF;i++){

p=$i+0; if(p>thr){

f = start + bin*(i-7);

fb = int((f + grid/2)/grid)*grid;

k = sprintf(“%.0f”, fb);

if(p>mx[k]){ mx[k]=p; F[k]=fb; }

C[k]++;

}

}

}

END{

for(k in mx){

printf “%.6f MHz\tmax %.1f dB\thits %d\n”, F[k]/1e6, mx[k], C[k];

}

}’ “$CSV” | sort -k3,3nr -k2,2nr | head -“$TOPN” > “$PEAKS_OUT”

echo “[OK] Picos: $PEAKS_OUT (THR=${THR} dB, GRID=${GRID} Hz, TOPN=${TOPN})”

fi

2) Uso paso a paso

Barrer una banda

Ejemplo VHF alto (150—174 MHz) a 12.5 kHz, 10 min:

rtl_power -f 150M:174M:12.5k -i 1 -e 10m -g 35 -c 0.2 vhf_150_174.csv

Generar el heatmap con auto‑escala y lista de picos

AUTO=1 SIGMA=2.5 PEAKS=1 THR=-55 GRID=12500 TOPN=50 ./plot_heatmap.sh vhf_150_174.csv

Si el resultado sale “todo rojo”, usa siempre AUTO=1 y prueba distintos SIGMA:

Más contraste: SIGMA=1.5

Menos saturación: SIGMA=3

Para archivos grandes, acelera con decimado:

AUTO=1 DECIMATE=4 ./plot_heatmap.sh vhf_150_174.csv

Abrir el PNG

xdg-open vhf_150_174_heatmap.png

Ver picos detectados

comando:: cat vhf_150_174_peaks.txt

Escuchar una frecuencia candidata (NFM)

rtl_fm -f 169.650M -M fm -s 12k -g 35 -l 0 -E deemp | play -r 12k -t raw -e s -b 16 -c 1 -

3) Barridos más frecuentes (comandos listos)

Airband (AM) 118—137 MHz:

rtl_power -f 118M:137M:12.5k -i 1 -e 10m -g 35 -c 0.2 airband.csv

AUTO=1 ./plot_heatmap.sh airband.csv

VHF alto 150—174 MHz (PMR, servicios):

rtl_power -f 150M:174M:12.5k -i 1 -e 10m -g 30 -c 0.2 vhf.csv

AUTO=1 ./plot_heatmap.sh vhf.csv

Marítimo 156—162.05 MHz:

rtl_power -f 156M:162.05M:12.5k -i 1 -e 10m -g 35 -c 0.2 marine.csv

AUTO=1 ./plot_heatmap.sh marine.csv

Telemetría EU 169—170 MHz (más fino):

rtl_power -f 169M:170M:5k -i 1 -e 10m -g 35 -c 0.2 iot169.csv

AUTO=1 ./plot_heatmap.sh iot169.csv

ISM 433.05—434.79 MHz (IoT/mandos, paso fino):

rtl_power -f 433.05M:434.79M:2k -i 0.5 -e 10m -g 35 -c 0.3 ism433.csv

AUTO=1 ./plot_heatmap.sh ism433.csv

PMR446 (solo 446.0—446.2 MHz):

rtl_power -f 446.0M:446.2M:12.5k -i 0.5 -e 10m -g 30 -c 0.2 pmr446.csv

AUTO=1 ./plot_heatmap.sh pmr446.csv

ISM 863—870 MHz:

rtl_power -f 863M:870M:5k -i 0.5 -e 10m -g 35 -c 0.3 ism868.csv

AUTO=1 ./plot_heatmap.sh ism868.csv

GSM900 downlink 925—960 MHz (coarse 200 kHz):

rtl_power -f 925M:960M:200k -i 1 -e 5m -g 35 -c 0.2 gsm900.csv

AUTO=1 ./plot_heatmap.sh gsm900.csv

ADS‑B 1090 MHz (de referencia):

rtl_power -f 1087M:1093M:5k -i 0.5 -e 5m -g 40 -c 0.2 adsb.csv

AUTO=1 ./plot_heatmap.sh adsb.csv

Notas:

Ajusta -g según saturación/ruido. Si el heatmap es “plano”, baja o sube la ganancia y repite.

Usa -p <ppm> si conoces tu offset.

4) Si sigues viendo todo rojo

Usa auto‑escala: AUTO=1 SIGMA=1.5

Comprueba el rango de valores reales del CSV:

awk -F, ’

function upd(v){ if(v""||v”nan”||v"-nan"||v”inf”||v==“-inf”) v=-120;

if(v←200||v>50) v=-120;

if(NR1&&i7){min=v; max=v}

if(v<min)min=v; if(v>max)max=v}

{ for(i=7;i⇐NF;i++){ upd($i+0) } }

END{ printf(“min=%.2f max=%.2f\n”,min,max) }’ vhf_12k5.csv

Si te dice, por ejemplo, min≈−48 y max≈−36, pinta así:

MIN_DB=-50 MAX_DB=-35 ./plot_heatmap.sh vhf_12k5.csv

5) Extra: Top de frecuencias desde el CSV (rápido)

THR=-55 GRID=12500 TOPN=50 PEAKS=1 ./plot_heatmap.sh vhf_12k5.csv

cat vhf_12k5_peaks.txt

Te dará las frecuencias más “activas” según el umbral y el grid de canal.

# Informe de Laboratorio: Auditoría de Radiofrecuencia y Hacking Hardware en DragonOS

**Entorno:** DragonOS (Linux)

1. Auditoría de Redes Móviles (4G/LTE)

**Hardware:** Dongle USB 4G Genérico

**Chipset:** Qualcomm 4094 (Firmware UFI003)

**Objetivo:** Interacción a bajo nivel (Serial), inyección de drivers, desbloqueo de SIM e inteligencia de señales (SIGINT).

1.1 Preparación del Entorno (Sysadmin)

El dispositivo no fue reconocido nativamente como módem serial. Se requirió intervención en el Kernel y limpieza de demonios.

* **Inyección de Driver:** Se forzó al módulo `option` (gestor de serial USB) a reconocer el ID del fabricante.

sudo modprobe option

sudo sh -c ‘echo 05c6 90b3 > /sys/bus/usb-serial/drivers/option1/new_id’

* **Neutralización de ModemManager:** Se deshabilitó el gestor automático de Linux para evitar que “secuestrara” el puerto serial e interfiriera con nuestros comandos manuales.

sudo systemctl stop ModemManager

sudo systemctl mask ModemManager

1.2 Interacción Serial (Comandos AT)

**Conexión:** `sudo screen /dev/ttyUSB0 115200`

Registro de Operaciones y Explicación Técnica

`AT` **Attention**. Ping básico al procesador del módem. `OK` (Comunicación establecida).

`ATI` **Information**. Consulta de firmware y modelo. Reveló modelo Qualcomm 4094 y revisión UFI003.

`AT+CPIN=“1234”` **Enter PIN**. Autenticación de la SIM en el HLR local. Desbloqueo exitoso. **Nota Crítica:** El módem se bloquea tras cada desconexión.

`AT+CPIN?` **Query Status**. Verificación de estado. | `READY` (Indispensable verificar esto antes de comandos avanzados). |

`AT+CSQ` **Signal Quality**. Medición de RSSI (Fuerza de señal). Resultado `19,99`. >15 indica señal excelente.

`AT+COPS=?` **Operator Selection**. Escaneo activo de todas las bandas. | El módem salta frecuencias y decodifica el MCC/MNC de torres cercanas (Movistar, Orange, Vodafone).

1.3 Inteligencia de Red (Geolocalización)

Extracción de identificadores únicos para ubicar físicamente la torre celular.

* **Comando:** `AT+CEREG?` (Estado de registro EPS/LTE).

* **Respuesta obtenida:** `+CEREG: 2,5,“6FDA”,“447810A”,7`

* **Estado 5:** Roaming (Correcto: SIM Digi usando red Movistar).

* **TAC (Hex):** `6FDA` → **28634** (Decimal). Área de rastreo.

* **ECI (Hex):** `447810A` → **71794698** (Decimal). Identificador único de celda.

* **eNB ID (Cálculo):** `71794698 / 256` = Torre **280449**.

**Aplicación:** Estos datos permiten triangular la posición exacta de la antena emisora usando bases de datos como *CellMapper*.

1.4 Pruebas Activas

* **Prueba de Voz:** `ATD+346XXXXXXXX;` → Resultado `NO CARRIER`.

* *Análisis:* Confirma que la SIM/Plan es “Data Only” o el módem está forzado en modo LTE sin CS-Fallback para voz.

---

Auditoría Wi-Fi (2.4 GHz)

**Hardware:** TP-Link TL-WN722N v2/v3

**Chipset:** Realtek RTL8188EUS

**Driver:** `r8188eu` (Modificado para Monitor Mode)

**Objetivo:** Vigilancia pasiva, resolución de problemas de drivers y captura de Probe Requests.

2.1 Problemática del Chipset Realtek

El chipset RTL8188EUS presentó inestabilidad con los scripts estándar (`airmon-ng`), mostrando errores de “Failed initializing” o incapacidad para cambiar de modo.

2.2 Solución: Activación Manual del Modo Monitor

Se descartó la automatización en favor de la manipulación directa de interfaces de red.

**Procedimiento Exitoso:**

1. **Limpieza de procesos:** `sudo airmon-ng check check kill` (Mata NetworkManager).

2. **Down:** `sudo ip link set wlx7cc2c613a9f0 down`

3. **Cambio de Modo:** `sudo iw dev wlx7cc2c613a9f0 set type monitor`

4. **Up:** `sudo ip link set wlx7cc2c613a9f0 up`

5. **Verificación:** `iwconfig` → Confirmado `Mode: Monitor`.

2.3 Troubleshooting: El “Congelamiento” de Canales

**Síntoma:** Al ejecutar `airodump-ng` estándar, la tarjeta intentaba saltar canales (Hopping) pero la pantalla permanecía vacía (sin datos), o el driver se bloqueaba.

**Diagnóstico:** El driver tiene dificultades para gestionar el salto rápido de frecuencia y la sincronización de radio al mismo tiempo.

**Solución Aplicada:**

1. **Reinicio Físico:** Desconexión/Reconexión del USB para limpiar la memoria del firmware.

2. **Escaneo Estático:** Se forzó la escucha en un solo canal, eliminando la necesidad de saltar.

```bash

# Escaneo forzado en canal 6 y solo banda G (2.4GHz)

sudo airodump-ng -c 6 —band bg —manufacturer wlx7cc2c613a9f0

```

2.4 Resultados de la Auditoría Pasiva

Una vez estabilizado el driver en canal fijo:

1. **Inyección de Paquetes:**

* Comando: `sudo aireplay-ng —test wlx7cc2c613a9f0` (requirió fijar canal previamente con `iwconfig`).

* Resultado: **“Injection is working!”**. Confirmada capacidad ofensiva (Deauth/Handshake capture).

2. **Vigilancia de Clientes (Probe Requests):**

* Comando: `sudo airodump-ng —manufacturer …`

* Hallazgo: Se visualizaron dispositivos cercanos (STATION) enviando solicitudes de conexión (“Probes”) buscando redes conocidas, revelando historial de ubicaciones de los usuarios sin necesidad de que se conectaran a nuestra red.

3. Conclusión y Restauración

El laboratorio demostró que hardware económico y con soporte limitado (Realtek) puede ser funcional para auditoría avanzada si se prescinde de herramientas automáticas y se comprenden los fundamentos del sistema (Kernel/Drivers).

**Restauración del servicio:**

sudo airmon-ng stop wlx7cc2c613a9f0

sudo service NetworkManager restart

Captura de Credenciales Cifradas (WPA Handshake)

Archivo de Evidencia: handshake_xiaomi-01.cap

Fecha de Captura: 17 de Diciembre de 2025

Técnica: Desautenticación Dirigida (Deauth Attack)

1. Identificación del Objetivo (Target)

Basado en el análisis de espectro previo, se seleccionó el siguiente Punto de Acceso (AP) para la extracción de credenciales, debido a su alta potencia de señal y actividad de clientes.

Parámetro Valor Identificado Notas

---

ESSID DIGIFIBRA-PkGR Red doméstica del auditor. BSSID (MAC) 2C:70:4F:0C:F8:0B Dirección física del router. Canal 8 (2.4 GHz) Frecuencia fija para evitar pérdida de paquetes (Hopping desactivado). Cifrado WPA2-PSK (CCMP) Vulnerable a captura de Handshake + Cracking Offline. Potencia (RSSI) -49 dBm Calidad de señal excelente (Proximidad < 5 metros).

2. Metodología de Ataque

Se ejecutó un ataque activo de denegación de servicio temporal (DoS) para forzar la reconexión de un dispositivo legítimo y capturar el “saludo de 4 vías” (4-Way Handshake).

Monitorización: La tarjeta se fijó en el Canal 8 para escuchar exclusivamente el tráfico entre el AP y los clientes.

Selección de Víctima: Se identificó el cliente con MAC B0:81:84:9B:52:78 (Dispositivo Xiaomi/Android) con una señal estable de -44 dBm.

Inyección: Se enviaron paquetes de desautenticación (aireplay-ng -0) dirigidos específicamente a la víctima.

Efecto: El dispositivo se desconectó y reconectó automáticamente en < 2 segundos.

3. Análisis Forense de la Captura (.cap)

El archivo handshake_xiaomi-01.cap contiene la secuencia EAPOL completa necesaria para intentar descifrar la contraseña.

Datos extraídos del log (.csv):

Total Paquetes Capturados: >737 paquetes de datos del cliente objetivo.

Integridad del Handshake: La captura incluye los marcos de autenticación críticos. Al verificar con aircrack-ng, se confirma:

[1 Handshake] detectado para la red DIGIFIBRA-PkGR.

4. Conclusión de la Prueba de Intrusión

La prueba ha sido EXITOSA. Se ha obtenido una copia válida del hash de la contraseña de la red.

• Impacto: Un atacante con este archivo .cap puede proceder a un ataque de fuerza bruta (diccionario) offline sin necesidad de estar físicamente cerca de la red.

• Recomendación: Si la contraseña es débil (ej: solo números, palabras de diccionario, menos de 10 caracteres), la red se considera comprometida. Se recomienda el uso de contraseñas WPA2 robustas (>12 caracteres alfanuméricos) o migración a WPA3.

Análisis de captura `handshake_xiaomi-01.cap` (EAPOL / Handshake WPA2)

Contexto

Objetivo: verificar si en la captura existe un 4-way handshake WPA2 para el AP con:

- **ESSID**: `DIGIFIBRA-PkGR`

- **BSSID**: `2C:70:4F:0C:F8:0B`

- **Seguridad**: WPA2-PSK (según CSV/Kismet)

Comandos ejecutados y salida

1) Contar tramas EAPOL en la captura

tshark -r handshake_xiaomi-01.cap -Y eapol | wc -l

Salida:

4

Interpretación:

Hay 4 tramas EAPOL en la captura. Esto cuadra con un 4-way handshake completo (M1—M4) en términos de conteo.

Aun así, el conteo por sí solo no garantiza al 100% que sea “válido” para crackeo (depende de que haya pares STA/AP consistentes y datos necesarios como MIC/ANonce/SNonce, etc.).

2) Intento de ver campos “msg” y “key_info” del Key Descriptor

tshark -r handshake_xiaomi-01.cap -Y “eapol && wlan.bssid==2c:70:4f:0c:f8:0b” -T fields -e frame.number -e wlan.sa -e wlan.da -e eapol.keydes.msg -e eapol.keydes.key_info

Salida (error):

tshark: Some fields aren’t valid:

eapol.keydes.key_info

eapol.keydes.msg

Interpretación:

Esta versión/build de tshark no expone esos campos con esos nombres (cambian según versión, compilación o naming de dissector).

No implica que no exista handshake; implica que esos field names concretos no están disponibles en ese entorno.

3) Identificar los pares SA/DA implicados en EAPOL

tshark -r handshake_xiaomi-01.cap -Y eapol -T fields -e wlan.sa -e wlan.da | sort | uniq -c

Salida:

2 2c:70:4f:0c:f8:0b d6:ec:62:5b:62:57

2 d6:ec:62:5b:62:57 2c:70:4f:0c:f8:0b

Interpretación:

El intercambio EAPOL se da entre:

• AP (BSSID): 2C:70:4F:0C:F8:0B

• STA (cliente): D6:EC:62:5B:62:57

• Hay 2 tramas en cada dirección, lo que encaja con un 4-way handshake (mensajes alternando AP→STA y STA→AP).

Conclusión parcial:

Hay evidencia fuerte de handshake completo entre ese BSSID y esa STA.

Metadatos del PCAP (encapsulado, tamaño, duración)

capinfos handshake_xiaomi-01.cap 2>/dev/null || file handshake_xiaomi-01.cap

Salida relevante:

• File type: pcap

• File encapsulation: IEEE 802.11 Wireless LAN

• Number of packets: 5,260

• Capture duration: 60.547238 seconds

Interpretación:

El archivo es un PCAP estándar con encapsulado 802.11, con tráfico suficiente (5260 paquetes) y ~60s de captura.

Esto sugiere que el fallo posterior de aircrack-ng no es por “archivo vacío”, sino por cómo aircrack está interpretando/parseando el contenido.

Resultado de aircrack-ng y qué significa

Comando:

aircrack-ng -a2 -b 2C:70:4F:0C:F8:0B handshake_xiaomi-01.cap

Salida:

• Pre-condition Failed: ap_cur != NULL

• Aborted (core dumped)

Interpretación:

aircrack-ng crashea al procesar la captura y no llega a construir el contexto del AP.

Esto puede deberse a:

• Bug/compatibilidad de la versión de aircrack con ese PCAP.

• Inconsistencia de parsing (aunque el encapsulado sea 802.11).

• Falta/ausencia de ciertos frames “management” que aircrack espera para “crear” el AP internamente (aunque haya EAPOL).

• Aun con el crash de aircrack, tshark sí confirma que existen las EAPOL y que corresponden al BSSID/STA indicados.

Evidencia clave (resumen)

• EAPOL total: 4

• BSSID implicado en EAPOL: 2C:70:4F:0C:F8:0B

• STA implicada en EAPOL: D6:EC:62:5B:62:57

• Encapsulado del archivo: IEEE 802.11 Wireless LAN

• aircrack-ng crashea: no concluyente (fallo de herramienta)

Filtros en Wireshark (GUI) para ver el handshake WPA2 del BSSID 2C:70:4F:0C:F8:0B

1) Ver solo EAPOL (lo más directo)

En la barra de filtros (Display Filter), escribe:

Todos los EAPOL:

eapol

Deberías ver 4 paquetes (según tu tshark).

2) EAPOL solo del AP (BSSID) que te interesa

Wireshark suele exponer el BSSID como wlan.bssid cuando puede decodificarlo:

EAPOL + ese BSSID:

eapol && wlan.bssid == 2c:70:4f:0c:f8:0b

Si esto te devuelve 0 paquetes, no significa que no haya handshake; a veces el campo wlan.bssid no se rellena en esas tramas. Entonces usa filtro por MAC origen/destino.

3) EAPOL entre AP y la STA detectada (D6:EC:62:5B:62:57)

Como ya confirmaste con tshark que los EAPOL son entre estas dos MACs, filtra así:

EAPOL con AP ↔ STA (en cualquier dirección):

eapol && ((wlan.sa 2c:70:4f:0c:f8:0b && wlan.da d6:ec:62:5b:62:57) || (wlan.sa d6:ec:62:5b:62:57 && wlan.da 2c:70:4f:0c:f8:0b))

Esto normalmente te deja exactamente las 4 tramas del handshake.

4) Ver “los mensajes” del 4-way handshake (M1—M4) en Wireshark

Una vez filtres eapol, selecciona uno de los paquetes y mira el panel central:

IEEE 802.1X Authentication

Key (Message 1 of 4) / Message 2 of 4 / etc. (Wireshark lo suele etiquetar así)

o dentro de WPA Key Data / Key Information

Si no ves “Message X of 4”, fíjate en Key Information flags (Ack, MIC, Install, Secure). Con eso se puede inferir el número de mensaje.

5) Atajo muy útil: “Follow” y “Conversation”

Para confirmar rápido la pareja AP/STA:

Statistics → Conversations → pestaña WLAN

Busca la conversación entre 2C:70:4F:0C:F8:0B y D6:EC:62:5B:62:57.

Desde ahí puedes aplicar un filtro automáticamente (botón “Apply as Filter”).

6) Si el tráfico es enorme: filtra por ESSID (cuando haya beacons/probes)

Para ver frames donde aparece el nombre de red:

Beacons del ESSID:

wlan.fc.type_subtype 0x08 && wlan_mgt.ssid “DIGIFIBRA-PkGR”

Probes/assoc relacionados (según decodifique):

wlan_mgt.ssid == “DIGIFIBRA-PkGR”

Esto no es el handshake, pero te ayuda a encontrar el AP y confirmar que estás mirando la red correcta.

Qué deberías ver exactamente

Con eapol (o con el filtro AP↔STA) deberías ver:

4 paquetes EAPOL

2 en dirección AP→STA y 2 STA→AP

En el detalle, un bloque tipo “RSN Key” / “Key Information” que identifica el 4-way handshake

Qué pasa “en teoría” con la contraseña en el handshake (y qué se puede / no se puede)

• En el 4‑way handshake no viaja la contraseña (PSK) en claro.

• Lo que viaja son nonces (ANonce del AP y SNonce del cliente) y valores de integridad (MIC) que prueban que ambas partes conocen la clave derivada, sin revelarla.

• A partir de la contraseña (o del PMK si es WPA2-Enterprise) y esos nonces se deriva la PTK, que sirve para cifrar tráfico y validar MIC.

Pero de ahí no se deduce “imposible saber la contraseña”. Lo correcto es:

1) Con el handshake no puedes “leer” la contraseña directamente

No hay un campo tipo “password=…”. Eso es cierto.

2) Pero el handshake sí permite verificar contraseñas por prueba

Si alguien tiene:

El handshake (como el tuyo),

El SSID (lo tienes),

entonces puede hacer un ataque offline de diccionario/fuerza bruta: probar una contraseña candidata → derivar la clave → comprobar si el MIC cuadra con lo capturado.

Eso no “descifra” la password mágicamente; es validación por intento.

Entonces, ¿se puede saber la contraseña de tu Wi‑Fi?

Depende solo de la fortaleza de la clave y del modo de WPA:

• Si tu Wi‑Fi es WPA2‑PSK y la contraseña es débil (corta, común, patrón predecible): sí, podría recuperarse con tiempo/recursos.

• Si tu Wi‑Fi es WPA2‑PSK con una contraseña fuerte y aleatoria (p.ej. 16—20+ caracteres aleatorios): en la práctica no (porque el espacio de búsqueda es enorme).

• Si fuera WPA2‑Enterprise (802.1X), el escenario cambia (no es “adivinar PSK”).

• Si fuese WPA3‑SAE, capturar el “handshake” no da el mismo vector clásico de ataque offline de WPA2 (aunque hay otros matices), y suele ser más resistente a diccionarios offline.

Qué significan los nonces “intermedios”

Los nonces no cifran la contraseña; se usan para:

asegurar frescura (evitar replays) mezclar aleatoriedad en la derivación de claves (PTK),

de forma que aunque repitas la misma PSK, cada sesión genere claves diferentes.