lunes, 9 de marzo de 2015

Medición del DDS 9850

 Aprovechando el utilizar el módulo DDS basado en el chip AD9850 para un práctico en la facultad hice una serie de mediciones en el laboratorio para explorar como es su respuesta en las distintas bandas; eso a su vez me dará una mejor idea de como dimensionar las etapas de RF que tienen que ser agregadas para disponer de un transceiver de apróximadamente 1W de salida en las distintas bandas.
El módulo es (engañosamente) publicitado como que opera hasta 70 MHz, aunque hay numerosas referencias en la red que en realidad un defecto de fabricación le impide trabajar en las frecuencias mas altas.
La mala noticia es que los comentarios en la red tienen razón, la buena es que aún así el módulo es suficientemente bueno para muchos proyectos en el espectro de HF y funciona razonablemente bien para ellos.
La mejor respuesta la tiene en 3.5 MHz (no probé 1.8 MHz o frecuencias menores) donde la respuesta de señal es de aprox. 1 Vpk-pk con razonable pureza espectral puesto que su espuria mas intensa se situa a mas de 45 dB por debajo de la fundamental.
El nivel de señal decae significativamente en la medida que se sube de frecuencia 700 mVpk-pk en 7 Mhz,  500 mVpk-pk en 14 MHz, 250 mVpk-pk en 21 MHz y 200 mVpk-pk en 28 MHz. La pureza espectral también se va deteriorando progresivamente en la medida que se aumenta la frecuencia, la espuria mas cercana pasa de 45 dB por debajo de fundamental en 3.5 MHz a un poco mas de 30 dB en 28 MHz.
Las mediciones en 50 MHz muestran una señal de muy bajo nivel, poco mas de 100 mVpk-pk y extremadamente deformada, la primera armónica se encuentra solo 10 dB por debajo de la fundamental. La señal es además visiblemente inestable y con ruido de fase. Posiblemente inusable para proyectos en esa frecuencia. El punto de corte de funcionamiento "correcto" parece estar en el entorno de 40 MHz, aunque no dediqué mucho tiempo a caracterizarlo con detalle.
El chip es sorprendentemente versatil, su programación se hace por medio de una placa Arduino Nano en la modalidad serie (lineas FQ_UP,CLK,DATA,RESET), si bien la comunicación con la placa Arduino se hace con un protocolo CAT a 4800 bps la corresponiente a la programación entre Arduino y DDS se hace a velocidad de bus, la que está dictada por la velocidad de procesamiento de la placa. Esto hace viable cambiar la frecuencia para implementar WSPR o Dominó, posiblemente también PSK y RTTY. Por supuesto también CW (para implementar el offset necesario para ese modo).

















lunes, 2 de marzo de 2015

Progreso del Pixie Aggiornado (de LU7HZ)

El proyecto de desarrollar una versión "aggiornada" de un Pixie va tomando cuerpo.
La idea básica es tomar un diseño como el Pixie en cuanto a sistema de mezcla y recepción pero reemplazando su oscilador local por un DDS, por otra parte controlando el DDS con una placa Arduino Nano y conectando todo a una PC mediante una placa serie USB-TTL.
El circuito es potencialmente capaz de salir en cualquier modo digital basado en modulación de frecuencia o de fase en el rango de 0 a 30 MHz.
Claramente un Pixie no tiene la complejidad circuital como para modular en amplitud (AM o SSB), pero variando la configuración del DDS puede trabajarse en CW, RTTY, PSK, JT65 y WSPR. Teóricamente podría hacerlo también en cualquier variante de FM o SSTV, pero tendría que refinar un poco el concepto y hacer pruebas para verificarlo, como rareza mas que nada porque no son modos que estén indicados para una potencia reducida.
Por ahora está lista la cadena de DDS y el firmware básico para controlarlo mediante una placa Arduino.
La placa Arduino que uso es la mas económica, y como tal carece de interfaz serie, lo que se soluciona con una pequeña placa de puerto serie USB a nivel TTL (en realidad la placa Arduino no necesita RS232).
El firmware inicial implementa un beacon WSPR aunque la salida aún no puede alimentarse a una antena, se requiere todavía la construcción de las etapas de RF propiamente dichas.
La programación del DDS se hace con el protocolo serie, el cual es configurado mediante señales de +5V en los pines D0,D1 junto con GND en D2. El control propiamente dicho se realiza con 3 lineas: DATA, W_CLK y FQ_UD. Opcionalmente he cableado también la linea RESET para tener flexibilidad en el futuro.
Todo el conjunto es alimentado en este momento por el puerto USB de una PC, aunque seguramente no podrá trabajarse de esta forma el diseño final.
La señal que se obtiene del DDS es limpia y estable (ver osciloscopio). La implementación tuvo, como todo diseño desde cero, sus tiroteos. 
Primero para poder grabar el firmware en la placa Arduino, lo que requiere un proceso algo crítico aunque es facil tomarle la mano (recomendaciones y discusión en el foro TECNICA-LU). Luego las complicaciones propias de desarrollar tres sistemas simultaneamente, de forma que cuando hay una falla no se sabe en cual de los tres está.
El primero en despulgarse fue la placa Arduino, de forma que pudiera grabar sistemáticamente microcódigo. Al poderlo hacer desarrollé un controlador muy básico del DDS para poderlo programar, y trabajé en la interfaz hasta que pude controlar su inicialización primero y sus parámetros despues, sobre ese controlador muy básico desarrollé la lógica de una baliza WSPR.
Finalmente, con todo ya funcionando, me dediqué a implementar un sub-sistema CAT para poder controlar el funcionamiento externo; para poder hacer el debug de este desarrollo hice un programa de "test bed" en Pascal que me permite controlar todas las variables y que utilicé para ir despulgando los mensajes de control y de estado. Junto con la implementación básica fui construyendo el esqueleto del futuro transceptor en cuanto a proveer la posibilidad de realizar PTT remoto, operar en SPLIT y disponer de dos VFO. No hay razón para que no utilice otras funciones en el futuro. Queda todavia pendiente lograr que este protocolo pueda operarse mediante OmniRig para completar la integración, cosa que por razones que está por verse aún no ocurre. El protocolo es esencialmente el utilizado por Yaesu  con los mensajes  0x01 (SPLIT), 0x05 (VFO), 0x0f (PTT), 0x0C (modo) y 0x0a (FREQ); también reacciona al 0x10 (Status) y 0xfa (Flags). El resto de los mensajes del protocolo son ignorados y no están implementados. Utilicé el mensaje 0xff para sincronismo de tiempo (no existe en los Yaesu), basicamente coloca al controlador en el minuto 00 lo que es importante mantener con precisión para el modo WSPR.
Quedan todavía muchas horas de laboratorio y pruebas, pero va por el buen camino.

Buscar este blog

Vistas de página en total