Dudas Universales... (II)

Hace algún tiempo (quizá demasiado para recordarlo) hablaba de una discusión surgida en el foro de openhpsdr sobre el modo de control por el usuario de una radio.

Quedaron pendientes en ese momento comentarios sobre una cuestión anunciada como "más técnica". Antes de entrar en detalle, una pequeña explicación: Actualmente las SDR se pueden dividir fácilmente en dos partes diferenciadas: Un convertidor, que traslada un determinado ancho de banda sobre una frecuencia central a banda base (o viceversa en la transmisión) y cuya salida puede ser analógica o digital y por otro lado un procesador de esa señal en banda base.

Normalmente, cuando se habla de una SDR se habla de la primera parte, ya que la segunda suele consistir en un software que se ejecuta en un ordenador personal.

Evidentemente, ambas partes deben unirse para intercambiar la información. El proyecto Hermes dentro de los proyectos de HPSDR es uno de estos convertidores. Se suscita la discusión de si el intercambio de datos (no sólo los datos sino también la información de control y cambio de contenidos) debe circular por un interfaz USB o por un interfaz ETHERNET.

Es una cuestión que me he planteado en numerosas ocasiones. Finalmente he decidido que tenía que tomar partido. Si sólo se puede elegir una me quedo definitivamente (por ahora) con ETHERNET. ¿La razón? Son varias, pero sobre todo la simplificación de las aplicaciones que se pueden hacer más independientes de "drivers" específicos en cada sistema operativo y la posibilidad de que los paquetes IP viajen por el mundo rápidamente mediante la simple conexión a un router.

He tenido dudas respecto a la capacidad, pero como ejemplo, baste el servidor de la universidad de Twente cuya radio entrega casi 2 MHz de ancho de banda a través de una conexión ETHERNET de 100 MBPS o la SDR-IP que sigue la misma idea y grantiza 1 MHz de ancho de banda sobre muestras I/Q a 24 bits.

Existen otras formas de enlace, y de hecho se han usado en productos comerciales. Incluso se pueden desarrollar medios específicos para el uso en SDR pero de momento esta puede ser la mejor solución: económica y flexible.

Y si es posible... ¡se ponen los dos!. Pero los desarrolladores de Hermes ya han dejado claro que sólo cabe una.

Por cierto, hay un nuevo receptor SDR comercial con ETHERNET a punto de aparecer.

Dudas... universales

Recientemente, en el foro de discusión de openhpsdr han aparecido dos temas que para mí son recurrentes, que ya he tratado con anterioridad en otras entradas de este mismo blog, y que sin embargo aún no he resuelto.

Hace algo más de un par de semanas se abrió un debate sobre cómo debe ser el medio de control de una SDR. Aquí tenemos, como es habitual en toda discusión, posiciones extremas y gama intermedia. Desde quien considera que independientemente de la circuitería interna, debe tener botones accesibles para todas las funciones imaginables, hasta quienes opinan que basta una pantalla y un ratón.

Las posiciones intermedias abogan por el empleo de un ordenador con periféricos más adecuados al uso de una radio como el PowerMate de Griffin, usado habitualmente en entorno de edición multimedia y en trabajo con CAD o cajas de potenciómetros para algunas funciones concretas como las que ofrece Korg NanoKontrol, e incluso mesas D.J. como es el caso de esta Numarak Omni Control.

No cabe duda de que un receptor digital ofrece funcionalidades que no son estrictamente "de botón", pero para ello incorporará siempre una pantalla con mayor o menor grado de sofisticación. Por otra parte, no cabe duda de que TODO es manejable con un pantalla y un ratón, pero que la "sensación" de un botón de un determinado tamaño, forma, rozamiento mecánico... ayudan a un manejo preciso. Hoy en día se podría manejar un coche con un ratón y una pantalla, pero... ´¿sería igual de preciso?. Las sensaciones que trnasmite un volante o un pedal de freno se perderían.

En fin, creo que la discusión va para largo. La aparición de las pantallas táctiles de proyección con capacidad para seguir gestos múltiples puede marcar un camino. El mundo de la comunicación hombre máquina está lleno de logros que quedaron abandonados por no suscitar ningún interés.

Seguiremos experimentando. Si algo de bueno tiene la SDR es que TODAS las soluciones son implementables sin afectar al corazón de la radio, que es siempre la misma.

Por cierto he hablado de dos temas de discusión. El segundo es algo más técnico así que lo reservo para más adelante.

TAPR y las conferencias en Dayton

En la página WEB del Tucson Arizona Packet Radio (TAPR), uno de los grupos con más tradición en la integración de técnicas digitales en la radioafición se han colocado las presentaciones efectuadas en el Dayton Hamvention del pasado Mayo, tanto las relativas al foro TAPR como al foro SDR.

La importante presencia de HPSDR se hace patente en estas presentaciones. De todas ellas me ha llamado la atención especialmente la titulada "Choices in Embedded DSP for SDR" (Elecciones en DSP "empotrados" para SDR).

Se trata de un cuidadoso repaso a las diferentes soluciones tecnológicas para integrar un DSP en una SDR (y de paso eliminar el uso de un PC). Quienes sigan este blog serán conscientes de mi interés por esta parte de una SDR.

Dentro de su análisis trata muchos aspectos, pero hace emnción a uno que tiene gran importancia para el aficionado: El precio de las cosas.

Herramientas de trabajo (ensambladores, compiladores, grabadores...) que son irrenunciables pueden tener un costo excesivo para la mayor parte de aficionados, lo que limita la selección. De hecho, los fabricantes de DSP ya parecen verlo como una limitación a la hora de expandir sus productos, y ofrecen herramientas (a veces con funcionalidad limitada pero suficiente) a precios razonables siempre que se asocien a algunos de sus "kits" de desarrollo.

Pero, volviendo a la presentación, es además un recordatorio de algo sobre lo que al parecer nunca se insiste lo suficiente: SDR no es DSP ni al contrario (aunque están relacionados) y SDR no es radio basada en PC (aunque puede serlo). SDR es... a la presentación de Lyle (KK7P) me remito.

HawkBoard: El front-end que esperaba

Hace algún tiempo ya mencioné en este mismo medio mi interés en encontrar una tarjeta que facilitase el desarrollo de aplicaciones basadas en OMAP-L137. En aquel momento estaba en sus comienzos la tarjeta beagleboard, basada en OMAP3530.

No he dejado de buscar desde entonces. Hace unos días que Kjell, LA2NI un miembro muy activo del grupo HPSDR, que ya conoce mis problemas me llamó la atención sobre una nueva tarjeta denominada HawkBoard.

No voy a decir que me han leído el pensamiento, pero se han aproximado mucho. Se trata de una tarjeta económica, completa, fácil de ampliar y por su fuera poco... ¡libre!. Efectivamente, todo el diseño hardware está disponible para su descarga, con la autorización para reproducirlo como se desee.

Aunque aparecida recientemente ya goza de un éxito importante. Hace una semana observé que el distribuidor Farnell disponía de 23 unidades. Hoy ya no tiene ninguna. Este despiste me va a costar un tiempo extra en conseguir una.

La tarjeta emplea un OMAP-L138, un dispositivo algo más completo que el OMAP-L137 en cuanto a periferia e igual en cuanto a proceso. Junto al circuito incluye 128MB de memoria FLASH y otros 128MB de RAM, dos interfaces USB, uno ETHERNET... e incluso una entrada de vídeo.

Por supuesto, Linux está portado completamente y se está trabajando en nuevas aplicaciones o entornos, entre otros el ya famoso (gracias a Google) Android.

No dispone de pantalla LCD o entrada táctil, pero su incorporación en una tarjeta externa será un trabajo sencillo, gracias al conector de expansión de 100 pines.

La información, como ya es habitual para muchos de estos proyectos en la red, está dispersa en varios puntos: La web del creador y fabricante de la tarjeta, un wiki, un blog, un repositorio para código y un portal con la información técnica entre otros.

STOP PRESS! Cuando he comenzado a escribir esta entrada aún no sabía que hay una nueva versión de la tarjeta denominada HawkBoard-Lite. Elimina algunas funciones no usadas comúnmente y rebaja aún más el precio. ¡Otra buena noticia!

SDR-IP. ¡Ya se puede comprar!

Como estas últimas semanas he estado desconectado es el momento de retomar cosas pendientes. Y entre ellas, uno de los clásicos que reviso con regularidad son los trabajos de Pieter (RFSPACE) y dentro de éstos el SDR-IP.

Ya está disponible para su adquisición. En la página de RF-SPACE se puede acceder a una lista de distribuidores. Ninguno de los dos distribuidores europeos lo ofrecen todavía por lo que si se desea uno habrá que acudir a uno de los distribuidores americanos. Supongo que será debido a la certificación "CE", así que si pedimos uno desde Europa habrá que tenerlo en cuenta.

He entrado en la página de Universal Radio para hacerme una idea de precios. Comienzan en $3000 y pueden llegar a $4000 si se incluyen todas las opciones de reloj de precisión.

Como profesional de la electrónica soy consciente de que los componentes empleados en este tipo de equipos son los de tecnología más moderna y gama más alta dentro de la industria. Un convertidor A/D de alta velocidad es un componente cuyo precio se mide en decenas, cuando no en cientos de euros. Si a esto sumamos la escasez de componentes en los últimos meses, además de la producción limitada, se trata sin duda de un precio adecuado.

Pero este precio está un poco fuera de las expectativas de un aficionado medio. Sin duda, para quienes gustan investigar y operar en los límites de la relación señal/ruido (EME, rebote en Venus, seguimiento de sondas espaciales lejanas, o búsqueda de emisiones extraterrestres...) es una solución muy efectiva y económica (al menos si la comparamos con soluciones "profesionales" de caracterísiticas similares).

En YouTube se pueden encontrar comparaciones entre SDR-IP y Perseus. ¿Es razonable comparar dos equipos cutos precios tienen una relación superior a 3:1?. Creo que no. Estas comparaciones se basan en recepción de audio en onda corta. Pero es realmente en las condiciones extremas comentadas anteriormente cuando se puede hacer la comparación.

Además, no sólo se están comparando los receptores, sino también las aplicaciones estándar de ambos (Spectravue para el SDR-IP y Perseus Software para Perseus).

Aunque para un clásico de la la onda corta, "la oreja" es el juez definitivo, creo que un conjunto bien definido de pruebas de laboratorio sería mucho más interesante.

Mientras tanto, una búsqueda rápida nos ha permitido encontrar un análisis algo más detallado en el blog de PUDXK. Sin duda tendremos más en breve, pero mi duda sigue siendo: ¿No estaremos comparando una moto con un coche sin pararnos a pensar en qué circunstancias se empleará el vehículo?.

Mientras esperamos el precio europeo, planteo una queja al viento. Aún no entiendo el porqué en Europa los precios están habitualmente al menos un 20% más elevados que en USA. Por ejemplo, SDR-IQ: USA=$500, EU=520€. Con los precios del SDR-IP casi merece la pena sacar un vuelo y traerlo en la maleta.

HPSDR puesto al día

Desde que Phil Covington (N8VB) se distanció del proyecto HPSDR, muchas cosas han ocurrido. Hace un año que publiqué una entrada en este mismo blog hablando de las diferencias del princpal impulsor con otros miembros del equipo de desarrollo.
El proyecto no ha sido abandonado, sino que continúa con nuevas aportaciones. Muchas son las ideas que se han añadido, aunque no todas tienen un seguimiento constante.

El concepto original del proyecto HPSR resultaba atractivo desde ciertos puntos de vista aunque algo odioso desde otros. La aproximación modular con un elevado número de componentes que efectúan tareas separadas dentro del diseño de una SDR puede verse como una ventaja al identificar claramente cada función, facilitar el conocimiento de la tecnología, simplificar el añadido de funciones nuevas o la sustitución de unos circuitos por otros. Por otra parte podía verse como un inconveniente dado el elevado número de componentes necesarios para obtener una radio completa lo que suponía un elevado coste y complejidad.

Algo así han debido pensar dos "clásicos" del proyecto: Kevin (M0KHZ) y Phil Harman (VK6APH) junto con Kjell Karsen (LA2NI) entre otros, artífices de varias partes anteriores del proyecto. Y se pusieron manos a la obra.

Para seguir con la filosofía del proyecto en cuanto a nombres se asignaron nombres basados en la mitología clásica: HERMES y APOLO.

HERMES es una tarjeta que une la funcionalidad de tres de las tarjetas anteriores: MERCURY (El convertidor digital de RF a banda base) PENELOPE (El convertidor de banda base a RF) y OZIMANDIAS (un interfaz USB y E/S de control). Se espera disponer de una versión comercial en breve ya que el proyecto está muy avanzado.

APOLO completa el diseño de HERMES incluyendo lo que antes se hacía mediante PENNYWHISTLE (Un amplificador lineal de 15-20W) y ALEXIARES (Un conjunto de filtros de HF para diferentes bandas). No contentos con ello, han añadido un acoplador automático de antena.

El resultado final es una SDR en dos tarjetas de formato Europa. Efectivamente, se ha abandonado el formato clásico de tarjetas insertadas en un bus y el resultado es un equipo mucho más compacto.

Esperemos disponer en breve de este hardware. Seguramente lo suministrará el TAPR, que se ha convertido en el alma del proyecto HPSDR y ya se ha hecho cargo de otras tarjetas del mismo.
De hecho hace un análisis detallado de estos trabajos en un reciente número de su interesante publicación PSR.

Mientras llegan las primeras noticias de la impresión que ha causado el producto en Dayton podemos obtener los esquemas (y dibujos de los circuitos impresos, por si algún valiente se atreve). Aún no está el código fuente de la FPGA, pero será fácil adaptarlo de las tarjetas anteriores para las que sí está disponible. Toda la información está disponible en la página web del proyecto HPSDR. Y también hay un completo manual (provisional).

La fotografía es (c) Kjiell Karlsen, 2010

Nuevas medidas para SDR

En algunas entradas de este blog ya he hecho referencia a ciertas peculiaridades de las SDR que hacen que sea difícil evaluar las características de una radio de este tipo en base a las mediciones clásicas. Me referiré de nuevo al artículo de Nils, DK8OK, al que hice mención en mi entrada anterior.

En él se incluye una sentencia contundente: "Las pruebas de la ARRL sobre el SDR-14 rezuman ignorancia ... ... contienen números hasta el aburrimiento en lugar de ilustrar las nuevas posibilidades e interesantes experiencias que estas tecnologías pueden ofrecer a la escucha.

Yo quiero ir más lejos. Los números son importantes ya que permiten comparaciones claras. Pero los números no lo reflejan toda la información necesaria para valorar las características de un equipo. Y a veces no son comparables. Un ejemplo: ¿Es mejor una cámara de 6 megapíxels o de 10 megapíxels? Solamente con esta información resulta imposible tomar una decisión (no quiero pensar en los miles de compradores de cámaras que sí lo han hecho).

Cuando se evalúa una SDR en comparación con un receptor superheterodino clásico (por ahora no entraré en el emisor) ¿tiene sentido comparar el punto IP3?. Sin duda es un valor interesante para comparar dos receptores superheterodinos, pero no tiene mucho sentido compararlos entre uno de estos y un SDR. Ya escribí hace algún tiempo una entrada sobre esta cuestión.

Esclarecer estos aspectos y definir las mediciones que son de interés en un receptor SDR y que pueden carecer de sentido en un receptor clásico (así como las que se encuentran en la situación opuesta) es un trabajo necesario cara al futuro, cuando los equipos digitales sean ubicuos.

De todos modos, aunque las cifras puedan hacer aparecer a determinado equipo como superior a otro, la sensación del usuario ante el equipo tiene una importancia crucial. Un equipo puede vencer a otro teóricamente superior sólo porque tiene un botón de sintonía más cómodo, o una pantalla más agradable.

Pero volvamos a lo que nos interesa: las medidas. Comenzaré por definir las medidas que pueden ser iguales en ambos tipos de receptores (superheterodinos clásicos y SDR). Pero eso será asunto de la siguiente entrada.

¿Está la tecnología madura?

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.

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.

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?.

SDR-IP ¿También se había pasado?

Hace apenas un mes decía que no podíamos pedir a SSMM los Reyes Magos la esperada SDR-IP.

Algo más recientemente hablaba sobre el tamaño "razonable" de una FPGA para la SDR que intento construir.

No creo que dejase en ninguno de los dos artículos sombre de duda sobre el trabajo de Pieter en este equipo. Poco después del primer artículo, los primeros días de 2010 han aparecido pruebas de que la SDR-IP existe y funciona perfectamente.

La prueba: dos vídeos en YouTube. El primero de ellos, del 1 de enero, muetsra el funcionamiento con SpectraVue y el uso de los dos mandos frontales, que permiten la configuración del equipo y la sintonía. Además, es posible ver su estructura interna. El segundo, más especutacular, permite ver el funcionamiento de la radio en el interior de un horno a 80ºC.

Me ha parecido interesante ver la estructura interna, ya que tiene relación con la segunda entrada que menciono al comienzo. En el circuito se aprecia un circuito FPGA en formato QFP (pines por los cuatro lados) de la serie Spartan de Xilinx. A principios de 2009, en un intercambio de correo, Pieter me hizo saber que estaba trabajando con una FPGA XC3SD3400A de Xilinx. (Superior aún a la del kit que había adquirido).

Pues bien, este modelo de FPGA no se fabrica en formato QFP, sino únicamente en BGA. A la vista del vídeo parece tratarse de una XC3S250D, la más grande que se fabrica en formato QFP.

¿Ha llegado Pieter a la misma conclusión tras sus pruebas?. En el vídeo se aprecia que la construcción del SDR-IP se realiza alrededor de tres tarjetas. Una de ellas, que podríamos llamar "tarjeta base" soporta los filtros de entrada, los interfaces de usuario junto a todos los conectores y alimentación. Otra montada sobre esta, contiene materiales que no llego a identificar ¿Circuitería de audio?. Y finalmente, una tercera contiene toda la circuitería digital, lo que incluye la FPGA, memoria y convertidores A/D y D/A.

Gracias a esta estructura, cambiando la tarjeta digital se pueden cambiar las prestaciones. ¿Se trata sólo de un prototipo o será así como salga el primer SDR-IP al mercado?. Por ahora, seguiremos esperando.

FPGA en DDC/DUC ¿Hace falta tanto?

La tecnología FPGA es uno de mis temas pendientes de estudio. Desde que hace casi 30 años trabajé con sencillos circuitos PAL, ni por mi profesión, ni por otras aficiones he tenido la oportunidad de profundizar en ella.

Sí que me he mantenido al día mediante la lectura de novedades y el seguimiento de sus características. Su uso en SDR me hizo indagar más a fondo, pero hasta ahora no había hehco ninguna práctica. Y digo hasta ahora porque en mi deseo de trabajar con estos dispositivos solicité un kit que me acaba de llegar.

Se trata de una tarjeta de evaluación de Xilinx. El dispositivo que incluye, el XC3SD1800A es una potente FPGA que aparte de soportar circuitos de una complejidad equivalente a 1,8 millones de puertas incluye 84 multiplicadores acumuladores como elementos prediseñados. Los multiplicadores/acumuladores son unidades básicas en la mayor parte de los procesos DSP.

Por supuesto, me está faltando tiempo para instalar todo el software de desarrollo y comenzar mi primer "DDC" o "DUC" (aún no lo he decidido). Esto me ha llevado a revisar la documentación relacionada con FPGA y SDR que he conseguido hasta ahora entre la que se incluye la relativa a otras implementaciones. Perseus usa una XC3S250E, que integra y el receptor multicanal de la universidad de twente emplea una XC3S500E ("por ser la más grande en cápsula soldable fácilmente" según su creador). Ambas son mucho más pequeñas, con 12 y 20 multiplicadores simples (sin acumulador) respectivamente.

¿Me he pasado de frenada?. El receptor de la universidad de Twente recibe siete bandas simultáneamente. Si considero que su FPGA tiene 20 multiplicadores, no llegan a tres por banda. ¿Para qué quiero 84?. Espero que con más capacidad de proceso se puede ofrecer mayor funcionalidad, mejor calidad o ambas cosas al mismo tiempo. Al menos no me quedaré corto.

Por cierto, según me comentó Pieter (el creador del SDR-IP) a principios de 2009 su SDR-IP (del que por cierto hay novedades de las que hablaré pronto) equipaba un dispositivo aún mayor, casi un 30% más de capacidad que el que yo he elegido para mis pruebas. Aunque creo que finalmente ha cambiado de opinión. ¿En qué me baso? Por ahora sólo diré: "stay tuned"

¿Mejor para un usuario, peor para SDR?

Este pasado fin de semana he dispuesto de un tiempo continuado para poder deciarlo al estudio.

Aunque ya he publicado un par de entradas en el nuevo blog (lo que significa dos experimentos) aún quedaba mucho por hacer. Cumplir con el autocompromiso de efectuar una nueva publicación cada semana exige un esfuerzo constante. Eso sin tener en cuenta que he aprovechado para poner un poco de orden y que el trabajo se puede ver con más claridad.

Pero este no era el tema ¿o sí?. En mis experimentos, estoy empleando Spectravue como sistema de visualización de los resultados. Se generan señales de audio a 96000 muestras por segundo en el KIT del DSP de TI (OMAP-L137) se sacan por la salida de línea y se inyectan en la entrada de línea del ordenador. Se configura SpectraVue para que procese dicha entrada y... voilà se puede ver inmediatamente el resultado (señal en el tiempo y espectro).

Mi primer contratiempo fue el de ver que, a pesar de que la tarjeta de audio del llamativamente nuevo ordenador que estaba empleando puede muestrear a 96KSPS, filtra todo lo que le entra a hasta 20 KHz con lo cual, señales por encima de este valor no son visibles. Este significaría que si intento emplear esta tarjeta de audio con un receptor de conversión en cuadratura (SDR-1000, PM-SDR o SoftRock entre otros) el ancho de banda se ve reducido a 40 KHz.

Pero hay algo aún peor. Experimentando con la generación de señales en cuadratura (I/Q) observé que el comportamiento era muy extraño. Tras varias pruebas puede descubir que el equipo aplica control automático de ganancia y que tiende a equilibrar el nivel de los dos canales.

Por si fuera poco, la salida la obtiene de una mezcla de las entradas de los canales y no de cada canal por separado. Y no he encontrado aún la solución (aparte de emplear una tarjeta externa).

Todo esto tal vez sea lo mejor para el que un usuario pueda emplear Skype sin esfuerzo, pero no para los experimentos que tenía planeados. De momento, empleo un convertidor externo con bus USB y puedo seguir adelante.

Minimalismo y CRAY-I

La SDR no sería posible sin potentes máquinas de cálculo. Varios millones de multiplicaciones por segundo de números de con una decena de cifras es una de las tareas de una SDR típica.

Aunque nos hemos acostumbrado a verlo como algo normal, y a disponer de capacidades de cálculo enormes en nuestro bolsillo, no siempre fue así.

De hecho, hace algo más de 30 años alguien diseñó una máquina revolucionaria, capaz de hacer una cantidad de cálculos científicos de alta precisión capz de dejar en ridículo a casi todos los ordenadores de la época. El Cray-1.

Hace poco localicé de forma casi casual el manual de servicio del Cray-1. Tras unos breves segundos estaba en mi poder (algo también difícil de intuir hace 30 años) y comencé a leerlo.

Ya no recordaba sus características, que tuve ocasión de conocer a través de un número especial de la versión española de la revista Scientific American (Investigación y Ciencia). En aquel número se hablaba de unos tipos de Xerox en Palo Alto que trabajaban (Creo recordar que con un PDP-11) en un terminal en el que se podían tener varios programas visibles gracias a que cada uno estaba en una "ventana", de un microcontrolador que lo tenía todo en una pieza y que se llamaba MCS51, de... bueno, volvamos al tema.

Cuando un microprocesador de la época funcionaba en torno a 1 MHz con palabras de 8 bits en CRAY 1 funcionaba con palabras de 64 bits a más de 80Mhz. Mientras un microprocesador con multiplicador de la época era capaz de multiplicar dos palabras de 8 bits en 1000ns, (uno estándar podía tardar entre 10 y cuatrenta veces este tiempo) el CRAY1 podía multiplicar dos número de coma flotante en 12,5 ns.

Para el cálculo de una multiplicación en coma flotante de 64 bits la relación de tiempos entre un micoprocesador de la serie MCS51 y un CRAY1 era de al menos 100000:1. Es decir, mientras un microprocesador hacía esta operación, el CRAY-1 había hecho 100000.

Este ordenador introdujo muchos conceptos de arquitectura (física y lógica) nuevos y aún en muchos DSP modernos se puede ver su influencia. La tecnología que ha permitido la integración en pequeños espacios ha solventado muchos de los problemas de este diseño original en el que las señales tenían que recorrer distancias "enormes" lo que suponía un problema añadido para el sincronismo de todas ellas y la velocidad de proceso.

Esta maravilla se diseñó con sólo tres tipos de circuitos integrados lógicos y un tipo de circuito de memoria. Puro minimalismo. Como en el proceso digital de señales se buscan algorimos que en base a repetir operaciones muy simples (sumas y productos) se puedan conseguir resultados asombrosos. También puro minimalismo.

Si seguimos el mismo ritmo, dentro de 30 años podremos tener sobre la mesa un SDR capaz de procesar TODO el espectro (O al menos de 0 a 10 GHz) identificando automáticamente los tipos de señales que previamente se le hayan instruido, interpretando las llamadas vocales en busca de un indicativo concreto y pasándonos una llamada concreta a cualquier punto en el que estemos. ¿Acabará esto con la radio? Creo que no, que los avances son inevitables, que hay muchas formas de hacer radio y que todas deben ser bienvenidas, y que la naturaleza impondrá límites y nuevos retos.

Mientras tanto gracias a todos los pioneros que trabajan en ir venciendo esos nuevos retos. Y como aún no conozco a muchos de ellos le daré las gracias a Seymour Cray por abrir nuevos caminos.

AUDIO, USB, ETHERNET, FIREWIRE... ¿HDMI?

Si observamos las radios de aficionado con tecnología SDR nos encontramos en la mayor parte de los casos con una "caja" que convierte las señales de radio a señales en banda base (y a la inversa durante la transmisión) y un ordenador al que llegan (o del que parten) dichas señales.

Dependiendo de la radio que nos ocupe, tendremos diferentes formas de enlace para dichas señales.

La forma más clásica (audio analógico) empleada en los convertidores QDC ha ido dando paso a formas más sofisticadas y potentes. Incluso receptores QDC emplean sus propios convertidores ADC y entregan señales digitales para obtener mejores características.

El paso de información digital al ordenador se hace a través de interfaces clásicos de ordenador. Por ejemplo, SDR-14 y PERSEUS emplean USB, FlexRadio emplea "FireWire" (entre otros) y el ordenador a su vez puede intercambiar la información que recibe o transmite a través de redes ETHERNET (Como lo hace el SDR-IP).

Todos estos interfaces son interfaces clásicos de ordenador, no diseñados especialmente para SDR.

Recientemente, haciendo experimentos, me he visto en la necesidad de conectar un convertidor A/D de alta velocidad (2 canales a 1,5 MSPS) a un DSP. La conexión puede hacerse de dos formas: En serie o en paralelo. Dado que en el DSP me resultaba difícil disponer de las 20 líneas para la conexión paralelo, rápidamente me decidí por la serie.

El convertidor debe ir en una tarjeta separada de la del DSP, conectada mediante cables. Dada la velocidad de datos (1,5M*2*16 bit = 48 Mbits/s) las conexiones deben ser cortas o ir "guiadas" a través de líneas de transmisión.

Aquí es dónde me aparece la pregunta: ¿Cuán lejos se pueden separar ambas tarjetas?. El número de conexiones entre ambas es de tres o cuatro señales de alta velocidad (Según el modo de trabajo), además de un interfaz I2C de baja velocidad para la configuración. Este es un interfaz típico entre un DSP y un convertidor A/D o D/A.

Esto significa montar un mazo de cables con cuatro líneas de transmisión independientes además de (al menos) tres cables extra. ¿Es posible que exista tal cable? ¡Existe!. Un cable HDMI tiene cuatro líneas de transmisión y al menos seis cables extra para señales de baja velocidad.

Por supuesto, no conozco ordenadores que vengan con este interfaz salvo dedicado a su uso original, la salida de vídeo, y no proponga introducir las señales por aquí. Lo que proponga es el empleo de este tipode conexión ya que el cable es estándar y de fácil localización, para separar la conversión del proceso (o al menos de parte del proceso) de señal y ésta del interfaz de usuario que de nuevo puede ser un ordenador.

Un receptor/transceptor SDR típico debe preparar la señal para ser transferida a través de un interfaz estándar (lo que provoca un retraso y no añade información) Tras viajar a través del medio, el ordenador remoto debe recoger la información en el formato que haya llegado, procesarla a través del sistema operativo para identificar su punto de destino y entregarla a la aplicación (nuevo retraso) y finalmente procesar la señal para obtrener una salida, compartiendo el tiempo de proceso con otras tareas (más retraso).

Lo que propongo es definir un "estándar" de interfaz para conectar señales digitales sin procesar a un procesador que las reciba directamente usando cables HDMI para evitar los retrasos y ofrecer toda la capacidad de proceso dedicada. Ya os contaré mis avances en este sentido.

Año nuevo ¿New Life?

Comienza un año nuevecito del todo. Aunque realmente, en el momento de escribir estas llíneas ya se ha gastado el 0,46552% de 2010. ¡Hay que ver cómo pasa el tiempo!.

Casi ha pasado también un año desde que comencé a escribir entradas en este blog, aunque en mi mente parece que fue ayer. Revisando lo realizado en este tiempo he visto que al comenzar tenía muchas ideas y poco tiempo, muchas ganas de reunir información y experiencia, de aprender teoría y aplicarla en la práctica.

Este tiempo me ha servido para conseguir y estudiar abundante información, para ordenar ideas, para conocer nueva gente con inquietudes similares y en menor medida para practicar con ellas.

Sí, parece que fue ayer, pero visto con perspectiva, y a pesar del tiempo dedicado que siempre me parece escaso, el avance ha sido importante.

Ha llegado el momento de dar un nuevo salto. Pretendo que esa visión práctica sobre la que tan poco había avanzado comience a tomar forma. Esto afectará a la forma de presentarlo en internet, eso que los modernos llaman WEB 2.0.

Por supuesto, este blog segirá adelante, con más brío incluso, y se mantendrá el grupo creado el año pasado para el intercambio de información SDR. Pero para este enfoque práctico necesitaba una estructura nueva.

Por ello hay y habrá novedades. La primera es la incorporación de un blog dedicado únicamente a aspectos prácticos. La segunda es la creación de una página WEB que sirva de repositorio para alojar documentos y código asociados. La razón de iniciar una nueva página es simple: Esta nueva página será en inglés, pretendiéndose una mayor apertura al mundo.

Por cierto, para acceder al nuevo blog: http://dspradio.blogspot.com/. Desde aquí se encontrarán los enlaces necesarios para el acceso al resto de recursos.