Este documento describe un proyecto de radio software definida (SDR) dividido en tres partes interconectadas:
1) La primera etapa realiza la conversión entre señales de radiofrecuencia y muestras digitales de un ancho de banda determinado. 2) La segunda etapa procesa las muestras digitales mediante técnicas de procesamiento digital de señales. 3) La tercera etapa permite la interacción con un operador a través de una interfaz gráfica, botones y pantalla. El proyecto pretende desarrollar
2. Una SDR se puede definir en tres grandes bloques: El primero, incluye los procesos de alta
velocidad y alta frecuencia Su objetivo es extraer un ancho de banda determinado de la señal
y alta frecuencia. Su objetivo un ancho de banda de la señal
de alta frecuencia y pasarlo a banda base para su proceso. Esta operación puede hacerse de
varios modos, cuya descripción se sale del objeto de esta presentación. El objeto de esta etapa
es el de entregar una serie continua de datos digitales que representen la señal de una
determinada frecuencia central y un determinado ancho de banda.
La segunda etapa, toma estos datos numéricos y los procesa mediante técnicas DSP hasta
obtener nuevos valores numéricos que representen el resultado de estos procesos. Si estos
valores representan una señal analógica audible, se pasan directamente a un convertidor para
p g , p p
generar dicha señal audible.
La tercera etapa está constituida por un elemento que permite una interacción con el mundo
exterior, generalmente con un operador. Se trata de un dispositivo que interacciona con dicho
operador y con el resto de los elementos: Botones, una pantalla gráfica... son elementos que
pertenecen a esta tercera fase.
Un receptor como el SDR‐14 o PERSEUS, por ejemplo, solamente tienen la primera etapa. Tanto
el proceso di it l
l digital como lla presentación en pantalla y el control de usuario se ejecutan en un
t ió t ll l t ld i j t
ordenador. Esto plantea algunos problemas, tales como la adecuada asignación de los recursos a
cada tarea. Para ello se debe tener en cuenta que el proceso DSP requiere respuesta en tiempo
real, mientras que la interacción con el usuario no es tan exigente.
Aunque compartidos en un ordenador estándar, estos procesos se podrían ejecutar en dos
ordenadores comunicándose entre sí, o en los dos núcleos de un procesador de docuble núcleo.
Este proyecto pretende atacar cada una de las etapas aquí descritas.
p y p p q
2
4. El hardware se centra sobre el dispositivo descrito. Los procesadores internos se
conectan a los elementos externos como memoria, comunicaciones, codecs... Sobre el
fondo gris están los elementos del dispositivo que implementa las etapas segunda y
tercera.
Alrededor del procesador, que es el centro de todo, se han repartido los elementos por
funcionalidad:
• La memoria: Memoria RAM abundante para un sistema operativo avanzado. Memoria
FLASH SD para cargar aplicaciones, datos...
• El interfase con el operador. La pantalla de color (táctil), botones, pulsadores...
• Las comunicaciones con otros dispositivos, entre ellos radios de otros fabricantes u
ordenadores remotos (TCP/IP, internet)
• Los interfaces analógicos, para radios con dicho interface o para
captación/reproducción de sonido.
Como puede verse el dispositivo puede gestionar cuanquier tipo de radio, tanto a través
de interface digital como analógico, lo que le hace adecuado para cuaqlueir tipo de
dispositivo. Incluso si algún día quedan fuerzas para desarrollar uno propio para la
primera etapa también será conectable.
Si nos fijamos, se ha sustituido el PC típico de cualquier radio digital por un equipo
dedicado que debe funcionar mejor, consumiendo y ocupando menos. Si se quiere
seguir teniendo la pantalla del ordenador, nada impide conectarlo aquí, pero ya no
tendrá que hacer tareas DSP.
4
6. El software se reparte entre los dos dispositivos del OMAP‐L137. Por un lado está el ARM que
gestiona todas las interfaces con el usuario incluyendo la generación de gráficos el análisis de
interfaces con el usuario, incluyendo la generación de gráficos, el análisis de
las acciones del usuario, y la comunicación con la radio, así como la gestión remota por red.
El ARM funciona bajo un sistema operativo Linux que incorpora ya parte de estas funciones. Las
aplicaciones específicas, tales como el interfaz de control de control a determinadas radios o la
presentación gráfica de una FFT, por ejemplo entre las muchas que es necesario desarrollar se
definen en forma modular para facilitar el desarrollo.
Funciones tales como l
l la gestión d b
ó de bases de datos, lectores PDF para d
d d l documentos, programas d
de
gestión de GPS o satélites se pueden incorporar gracias al sistema operativo Linux y a la
memoria masiva.
Por su parte, el DSP se dedica solamente a tareas en las que está especializado: El proceso de
señal. Para facilitar el desarrollo de los diferentes módulos software que implementan los
algoritmos, se emplea un conjunto de normas y herramientas que facilitan un desarrollo
modular.
modular
6
7. El diseño modular del software es la base de la que se debe partir para poder afrontar el
proyecto con éxito. Por otra parte el uso d d
t é it P t t l de desarrollos realizados por t
ll li d terceros, acelera
l
el desarrollo al proporcionar herramientas que sería muy costoso desarrollar uno
mismo.
Los tratamientos DSP pueden ser muy diversos en radio. Se debe definir una lista
completa de la funcionalidad. Se sugiere aquí una división en cuatro grupos, aunque
abierta a nuevas ideas:
•Tratamiento de señales analógicas hasta obtener un muestreo audio
•Tratamiento de señales digitales hasta obtener los datos embebidos en la señal
•Proceso general de señal, como puede ser filtraje en CW o voz (“Speech”) en bandas
laterales
•Otros procesos de señal como FFT para espectrogramas, análisis de señal para señales
débiles como EME o METEOR Scatter
No cabe duda de que podemos considerar otros procesos como semi‐analógicos o
semidigitales. Tal es el caso de los modos de voz digital (modulación digital, pero salida
analógica) o SSTV (Modulación analógica pero salida digital)
7
8. Se pretende que todo el proyecto (esquemas, código, circuitos...) sea abierto y público
para la experimentación.
Dada la tecnología empleada, el montaje no está al alcance de un aficionado medio, por
lo que se busca la masa crítica que permita el desarrollo de un kit.
La programación implicada no es simple y requiere de un tiempo de aprendizaje. Crear
un grupo inicial capaz de desarrollar ese conjunto mínimo de aplicaciones, y capaz de
transmitir los conocimientos es fundamental.
El OMAP‐L137 es un procesador que aún no es comercial. TI está en condiciones de
suministrar un KIT de evaluación, del cual dispongo de una unidad con la que estoy
trabajando. Se espera que el procesador esté disponible para finales del verano.
8