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.