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.