Desde que aparecieron los primeros SDR ha existido una discusión abierta sobre las ventajas e inconvenientes de estos equipos respecto a los analógicos clásicos. Estoy seguro de que esta discusión permanecerá en el tiempo, como la discusión entre vinilos y formatos digitales. (Aquí puede verse una versión humorística de Texas Instruments de cómo sería el mundo sin MP3).
Para mí, no cabe duda de que la tecnología digital acabará desplazando a la analógica, pero ¿está la tecnología en condiciones de hacerlo ya?. Me ha llamado a esta reflexión un artículo que encontré recientemente aunque está escrito en 2007 por Nils Schiffhauer, DK8OK. Su título: "Dinosaur concepts: why ar always so conservative?"
En él, el autor se plantea los motivos que pueden concurrir en el hecho de que la mayor parte de las radios que se fabrican y distribuyen actualmente son analógicas. Incluso equipos de altísimo nivel como pueden ser la ICOM IC-9500 o Hilberling-PT8000 siguen manteniendo arquitecturas analógicas.
¿Es realmente que la tecnología no está suficientemente desarrollada? En el campo profesional se emplea actualmente de forma regular el Rhode & Schwarz EM510, un receptor completamente digital de muestreo directo. Su precio es elevado, pero hablamos del campo profesional.
¿Se puede comparar un SDR-14 o un Perseus a un EM510?. Desde luego, no tiene la misma capacidad, pero en el uso diario de un aficionado es posible que no se note la diferencia. Muchas de las características que ofrece un EM510 y que lo hacen tan costoso no son de ningún interés para un aficionado. ¿O acaso hay muchos aficionados que deseen observar el espectro a un ritmo de 600000 canales/segundo?
Para el aficionado las caracterísiticas importantes se basan en una buena recepción. Características como la sensibilidad y selectividad, rango dinámico, IP3... definen mejor lo que necesita un aficionado. Pero, ya que se tiene capacidad digital, ¿por qué no aprovecharla?. Visualización de un espectro amplio, selección "continua" (sin saltos) del ancho de banda FI o RIT automático en SSB son posibles mejoras de un receptor digital.
Y en lo que interesa ¿está la tecnología preparada?. Son muchas preguntas para responderlas ahora mismo. Voy a adelantar que desde mi punto de vista la respuesta es indudablemente ¡SI!. Pero iré justificando mi razonamiento en próximas entradas.
jueves, 25 de febrero de 2010
lunes, 8 de febrero de 2010
Todo son facilidades... o casi
Desde que el "Time To Market" es un término ubicuo, los fabricantes de dispositivos electrónicos intentan ofrecer medios que reduzcan el tiempo en que un usuario está en condiciones de trabajar con un determinado componente o sistema ("Learning Curve" por citar otro térmico estándar).
Compiladores de lenguajes de alto nivel, librerías de casi cualquier función imaginable, incluyendo funciones DSP en los procesadores DSP eran habituales en los componentes que he empleado.
En las FPGA sucede algo similar. Existen "componentes" prediseñados que se pueden integrar fácilmente. Estos componentes cubren un amplio espectro de necesidades, desde un simple contador hasta un completo procesador de 32 bits son piezas que se pueden tomar para ser integradas en una FPGA.
Los kits de desarrollo, que incluyen la pieza que se somete a evaluación y estudio junto con las herramientas necesarias para comenzar a trabajar y abundante software de prueba con documentación detallada y alguna específica para seguir paso a paso, acortan el tiempo de aprendizaje.
Tal es así que apenas acabo de poner mis manos sobre el nuevo KIT de la altera Cyclone III, y ya he instalado las herramientas, he desarrollado mi primera aplicación (eso sí, copiada de unas instrucciones para seguir paso a paso) y he desarrollado mi segunda aplicación (esta mía) consistente en un oscilador programable (gracias a las librerías).
El desarrollo es simple, pero presenta algunos inconvenientes. Como en el caso de determinadas librerías, no se dispone del código fuente. He conseguido hacer algo pero no sé cómo lo he hecho. No he tenido tiempo para mucho más, pero he intuido cómo desarrollar un DUC o un DDC, una interfaz serie, incluso un microprocesador... ¡sin tener ni idea de cómo está hecho!.
Las facilidades están bien, pero hay que saber usarlas. En cierta ocasión, ayudando en la depuración de una aplicación que se desarrolló para Linux, llegué a la conclusión de que el problema estaba en un determinado "driver". "No puede ser" me dijo el desarrollador. "¿Por que'? contesté yo. "Porque ese driver lo he bajado de Internet" respondió. Por supuesto, el problema estaba en el driver. Sin comentarios.
La tendencia actual a la reutilización puede producir diseños rápidos, e incluso en muchos casos altamente fiables, pero conocer los más mínimos detalles de cuanto afecta a un diseño es el único modo de resolver problemas complejos.
De todos modos, aunque cambiaré mi forma de trabajo para disponer de toda la información, el kit me sirve para dar estos primeros pasos en apenas unas horas. Así que sigue siendo un equipo válido. Y espero tener esta noche un transmisor SSB basado en un tono de audio y DUC completo, todo ello en la FPGA. Aún no dispongo del necesario convertidor DAC de alta velocidad para la salida de HF, pero... esto me da pie para un próximo comentario técnico.
Compiladores de lenguajes de alto nivel, librerías de casi cualquier función imaginable, incluyendo funciones DSP en los procesadores DSP eran habituales en los componentes que he empleado.
En las FPGA sucede algo similar. Existen "componentes" prediseñados que se pueden integrar fácilmente. Estos componentes cubren un amplio espectro de necesidades, desde un simple contador hasta un completo procesador de 32 bits son piezas que se pueden tomar para ser integradas en una FPGA.
Los kits de desarrollo, que incluyen la pieza que se somete a evaluación y estudio junto con las herramientas necesarias para comenzar a trabajar y abundante software de prueba con documentación detallada y alguna específica para seguir paso a paso, acortan el tiempo de aprendizaje.
Tal es así que apenas acabo de poner mis manos sobre el nuevo KIT de la altera Cyclone III, y ya he instalado las herramientas, he desarrollado mi primera aplicación (eso sí, copiada de unas instrucciones para seguir paso a paso) y he desarrollado mi segunda aplicación (esta mía) consistente en un oscilador programable (gracias a las librerías).
El desarrollo es simple, pero presenta algunos inconvenientes. Como en el caso de determinadas librerías, no se dispone del código fuente. He conseguido hacer algo pero no sé cómo lo he hecho. No he tenido tiempo para mucho más, pero he intuido cómo desarrollar un DUC o un DDC, una interfaz serie, incluso un microprocesador... ¡sin tener ni idea de cómo está hecho!.
Las facilidades están bien, pero hay que saber usarlas. En cierta ocasión, ayudando en la depuración de una aplicación que se desarrolló para Linux, llegué a la conclusión de que el problema estaba en un determinado "driver". "No puede ser" me dijo el desarrollador. "¿Por que'? contesté yo. "Porque ese driver lo he bajado de Internet" respondió. Por supuesto, el problema estaba en el driver. Sin comentarios.
La tendencia actual a la reutilización puede producir diseños rápidos, e incluso en muchos casos altamente fiables, pero conocer los más mínimos detalles de cuanto afecta a un diseño es el único modo de resolver problemas complejos.
De todos modos, aunque cambiaré mi forma de trabajo para disponer de toda la información, el kit me sirve para dar estos primeros pasos en apenas unas horas. Así que sigue siendo un equipo válido. Y espero tener esta noche un transmisor SSB basado en un tono de audio y DUC completo, todo ello en la FPGA. Aún no dispongo del necesario convertidor DAC de alta velocidad para la salida de HF, pero... esto me da pie para un próximo comentario técnico.
lunes, 1 de febrero de 2010
Ha pasado un "Cyclone"
El trabajo para hacer una SDR me lleva por caminos muy distintos. Por una parte, Linux, por otra procesadores DSP especializados y por otra FPGA. Me es imposible mantener toda la información en mi cabeza, pero me resulta también muy difícil mantenerla organizada a pesar de las inmensas capacidades de los discos actuales.
Cada una de estas áreas de trabajo implica un conjunto de herramientas específico. Por si fuera poco, las herramientas se ofrecen en varias versiones, desde gratuitas hasta de costos elevados. Por supuesto, para un aficionado es importante trabajar con las gratuitas.
Bien, repasemos la situación:
1. Linux precisa un entorno Linux para el trabajo. Teniendo en cuenta que se trata de un ARM es conveniente emplear una distribución adecuada. Por suerte, TI proporciona una distribución Montavista básica con su sistema. No está "a la última" (Kernel 2.6.17) pero funciona bien. Pero necesito una máquina Linux (real o virtual) para trabajar.
2. El DSP 6747 del OMAPL137 tiene su propio entorno de desarrollo: El CCStudio. Comencé con la versión 3.3 pero con un cambio reciente de ordenador debo pasar a la 4.0. He tenido que obtener una licencia (gratuita por ahora) que no funciona bien, por lo que ando con otra que tiene fecha de caducidad.
3. La FPGA. Hace poco recibí un KIT de Xilinx. Tras obtener una licencia e intentar instalar el entorno gratuito pude ver que se precisa una versión "professional" del sistema operativo. El ordenador que empleo tiene una versión "Home". De nuevo ¿Qué hago? ¿Gasto los más de 200 € que cuesta actualizarme a una versión "pro" de Windows 7?.
En fin, con todo estos líos en la cabeza he decidido cambiar de estrategia, devolver el KIT de Xilinx y pasarme a las FPGA de Altera. Antes de esto comprobé que su entorno de desarrollo gratuito funcionaba correctamente bajo Windows 7 Home.
Así que en unos días espero estar en condiciones de comenzar el trabajo con Altera. La FPGA que espero usar es de la serie "Cyclone III" una serie asentada en el mercado (Altera ya ha anunciado la serie "Cyclone IV"). Uno de estos dispositivos es el que emplea la QS1R de Phil Covington, concretamente la EP3C25. Esta es la misma que se incluye en el kit que he solicitado.
Con este paso espero reducir mis problemas.
Sirva esto para recordar que la elección de uno u otro dispositivo en este caso se debe a una estrategia de facilidad de uso desde el punto de vista de un aficionado, y que cuando se trabaja en la implementación debe hacerse de forma que el paso de un dispositivo a otro sea lo más simple posible. ¿O alguien espera que estos circuitos se fabriquen siempre?.
Cada una de estas áreas de trabajo implica un conjunto de herramientas específico. Por si fuera poco, las herramientas se ofrecen en varias versiones, desde gratuitas hasta de costos elevados. Por supuesto, para un aficionado es importante trabajar con las gratuitas.
Bien, repasemos la situación:
1. Linux precisa un entorno Linux para el trabajo. Teniendo en cuenta que se trata de un ARM es conveniente emplear una distribución adecuada. Por suerte, TI proporciona una distribución Montavista básica con su sistema. No está "a la última" (Kernel 2.6.17) pero funciona bien. Pero necesito una máquina Linux (real o virtual) para trabajar.
2. El DSP 6747 del OMAPL137 tiene su propio entorno de desarrollo: El CCStudio. Comencé con la versión 3.3 pero con un cambio reciente de ordenador debo pasar a la 4.0. He tenido que obtener una licencia (gratuita por ahora) que no funciona bien, por lo que ando con otra que tiene fecha de caducidad.
3. La FPGA. Hace poco recibí un KIT de Xilinx. Tras obtener una licencia e intentar instalar el entorno gratuito pude ver que se precisa una versión "professional" del sistema operativo. El ordenador que empleo tiene una versión "Home". De nuevo ¿Qué hago? ¿Gasto los más de 200 € que cuesta actualizarme a una versión "pro" de Windows 7?.
En fin, con todo estos líos en la cabeza he decidido cambiar de estrategia, devolver el KIT de Xilinx y pasarme a las FPGA de Altera. Antes de esto comprobé que su entorno de desarrollo gratuito funcionaba correctamente bajo Windows 7 Home.
Así que en unos días espero estar en condiciones de comenzar el trabajo con Altera. La FPGA que espero usar es de la serie "Cyclone III" una serie asentada en el mercado (Altera ya ha anunciado la serie "Cyclone IV"). Uno de estos dispositivos es el que emplea la QS1R de Phil Covington, concretamente la EP3C25. Esta es la misma que se incluye en el kit que he solicitado.
Con este paso espero reducir mis problemas.
Sirva esto para recordar que la elección de uno u otro dispositivo en este caso se debe a una estrategia de facilidad de uso desde el punto de vista de un aficionado, y que cuando se trabaja en la implementación debe hacerse de forma que el paso de un dispositivo a otro sea lo más simple posible. ¿O alguien espera que estos circuitos se fabriquen siempre?.
Suscribirse a:
Entradas (Atom)
