jueves, 23 de enero de 2014

El genio sorprende otra vez, el Minima de Farhan (VU2ESE)


No debería sorprendernos nada que salga de la galera del genio de Farham (VU2ESE), el muy celebrado y famoso autor del popular diseño denominado BITX. Entre sus proyectos mas recientes se encuentra el MINIMA, un concepto de transceptor de baja cuenta de componentes y simplicidad constructiva que se basa en conceptos de diseño muy modernos.
Cuando se revisa el circuito se nota una impronta de desarrollo cuya huella nos lleva claramente al diseño BITX. Muchos componentes muy baratos y fáciles de conseguir, en configuraciones de circuito muy simples y repetitivas. Siguiendo la impronta de muchos diseños simples de conversión directa se entra (con un filtrado mas elaborado que el habitual) directamente al mezclador, ese diseño es adecuado para bandas de HF mas bien bajas, quizás hasta 20 metros inclusive; creo que va a ser deficiente en frecuencias mas altas pero habría que medir con mas propiedad que "leyendo" el circuito, que por cierto no he construido.
El mezclador es original, por un lado por su configuración balanceada pero también porque el oscilador local está implementado con un bloque DDS, bien versatil además de "state-of-the-art".
Luego un filtro a cristal de 20 MHz, buena elección que simplifica el diseño en general en cuanto a supresión de productos de mezcla no deseados; seguido de un par de etapas de amplificación (bidireccionales del tipo de los encontrados en el BITX), un mezclador convencional a diodos de frecuencia intermedia y etapas de amplificación de micrófono y audio.
Hasta aqui un ingenioso, pero bastante convencional diseño (excepto el DDS que se ve en circuitos de mayor porte). Pero comienza a ponerse interesante cuando se vé que para programar y manipular el DDS utiliza una placa Arduino. Y con la placa Arduino aparte maneja toda la lógica de conmutación, gestión de frecuencia y también hasta comando remoto (un diseño ultra simple con CAT!!!).
Una maravilla que invita a hacerlo.
Por mi parte veo con satisfacción que el concepto que por otros senderos estamos recorriendo con Willoh al tratar de hacer un SDR super simple es, en esencia y en otro contexto de filosofía de diseño, el mismo que abraza Farham. 
Eso es, un diseño de aficionados, con prestaciones limitadas pero razonables y funcionales para ser usado en el aire en condiciones "reales", que con USD 100.- o menos de costo (según Farham quizás algo menos si tenemos piezas o se hacen reemplazos menores), y con una complejidad constructiva que baja hasta el borde superior del rango simple (o el inferior del rango medio) como para que casi cualquiera pueda juntar valor para hacerlo que aliente a que se lo reproduzca.  El diseño está evolucionando y aún le faltan algunas cosas, como por ejemplo un AGC y algo mas de potencia que solo 1W.  
Si el MINIMA sigue la impronta del BITX es posible incluso que este diseño se haga realmente popular en formato de kit, ojalá que así sea.
Es además un diseño lo suficientemente simple y claro como para que "invite" a experimentar en serio reemplazando partes o incluso, porque no, trabajando con el firmware Arduino para trabajar sus prestaciones. Por ejempo controlarlo totalmente desde una PC con una interfaz remota eliminando todo vestigio de sintonía local.
También, en este caso por la Arduino y en el caso nuestro por una PC, es irreversible el maridaje entre la informática y los transceptores, incluso a nivel de experimentación en su gama mas simple.

 



sábado, 18 de enero de 2014

Un proyecto dando vueltas, HZRotor de LU7HZ

 Voy por la segunda iteración del proyecto de controlador automático de rotor, en mi caso un Walmar de servicio pesado que opero desde hace tiempo con un controlador manual oportunamente compartido en este blog.
En aquella oportunidad utilicé un PIC 12F675, uno de los mas pequeños posibles, y logré exitosamente implementar el controlador automático tanto en su modo remoto soportando el protocolo EZ-ROTOR (compatible DCU-1) como semi-automático estableciendo un acimut de referencia y haciendo que el controlador produzca la rotación hasta alcanzar esa referencia, aquella implementación no tenía modo manual pues asumía operar en paralelo con el controlador manual existente. Aquel diseño funcionó bien en el banco de pruebas, con el rotor siendo simulado mediante un reostato. Lamentablemente no funcionó adecuadamente con el rotor real, fundamentalmente por problemas en el sensado de posición probablemente dañado, con una respuesta claramente alineal y con mucho ruido haciendo que la función semi-automática fuera inusable.
Originalmente había pensado utilizar una placa Arduino One con este propósito, pero una vez que tuve la placa y la empecé a usar en otros proyectos me quedó claro que era un desperdicio "enterrarla" en un proyecto donde los requisitos del procesador y sus capacidades de entrada/salida son tan modestos.
Sin embargo, posteriormente conseguí un par de placas Arduino Nano, versión reducida pero aún así de prestaciones muy sorprendentes. Asi que finalmente me decidí a retomar el proyecto. Desde el punto de vista del desarrollo la placa Nano es mucho mas pequeña y viene en un formato DIP de 30 contactos que permite facilmente integrarla en un circuito (por ahora en un protoboard) con el resto de los componentes.
Electricamente la placa funciona con +5V alimentado desde una conexión USB desde la PC, la que al mismo tiempo se desdobla como un puerto serie emulado. Ese puerto serie se puede usar en desarrollo para cargar el firmware en memoria flash como una vez en funcionamiento para permitir el comando desde programas funcionando en la PC. Los distintos botones de control son CW (rotar en sentido horario), CCW (rotar en sentido anti horario), SET (establecer referencia semi-automática) y AUTO (comenzar movimiento del rotor a la referencia). Hay dos señales digitales de salida que activan por medio de respectivos transistores relays para girar al rotor en un sentido u otro.

Ese sistema de activación podría reemplazarse por componentes de estado sólido pero tenía mas a mano relays electromecánicos convencionales. El controlador tiene dos entradas analógicas, una con la señal de realimentación del rotor que es una tensión entre 0 y 12V (teóricamente) proporcional a la rotación. En la configuración en que lo utilizo tanto la tensión 0V como +12V corresponde a 180 grados (Sur) en ambos lados de la carrera, o sea que el norte es también 0 y 360 grados correspondiente a aproximadamente la mitad del voltaje (~6V). Esta tensión debe ser reducida porque el máximo que toleran las puertas analógicas es de +5V, lo que se hace con un potenciometro que hay que ajustar cuidadosamente para no exceder el máximo. Una segunda entrada analógica alimenta una referencia derivada de los +5V de la placa con un divisor de tensión, esa segunda entrada es para definir un acimut de referencia en el modo automático.
En el modo MANUAL presionando el interruptor CW hace que el rotor gire en un sentido y CCW en el otro; el firmware controla los topes y desactiva el control manual cuando los alcanza.
En modo automático se establece la referencia con el interruptor SET presionado, al presionar el interruptor AUTO el firmware activa el rotor hasta que alcance el valor establecido con la referencia, mientras el interruptor SET está presionado el firmware ignora las indicaciones del botón AUTO.
En el modo remoto el firmware responde a los comandos del protocolo EZ-ROTOR. No todos los comandos del protocolo son implementados, los que implementa son los siguientes:
  • Comienza a rotar hacia el acimut nnn (AP1nnn;).
  • Reporte el acimut corriente (AI1;), reporta el acimut de la referencia mientras SET está en bajo.
  • Detiene la rotación inmediatamente (ST1;).
  • Comienza a rotar hacia el acimut indicado en el último comando AP1 (AM1;).
  • Detener la rotación y hacer reset de estado (;).
Este conjunto de comandos es soportado por un número de programas, entre ellos de mi interés por N1MM a traves del programa N1MMRotor (ver figura). Mi idea original era utilizar el adaptador Ethernet de la placa Arduino One para incluir en el proyecto un mini Web Server que me permitiera utilizar un browser como interfaz gráfica (o incluso controlar el rotor via Internet); la Arduino Nano no tiene tanta facilidad para un puerto Ethernet y eso desvaneció ese aspecto del proyecto. Sin embargo, una vez implementado me doy cuenta que el programa N1MMRotor termina actuando como la interfaz gráfica que había imaginado originalmente. El acceso por Internet sigue siendo posible, indirectamente, tomando control de la PC en forma remota y utilizando la interfaz gráfica.
Se aplica una serie de criterios de prioridad y precedencia para solucionar conflictos por la activación simultanea de mas de un modo, por ejemplo manual con automático o manual con un comando remoto.
El microcódigo, preliminar aún y sobre el que estoy continuando la depuración y prueba, puede obtenerse aqui. Este tiene que compilarse y cargarse en la placa Arduino mediante el IDE de desarrollo de esa plataforma. No hay ninguna razón para que no funcione en otras plataformas aparte de la NANO.



sábado, 4 de enero de 2014

SDR para todos... y todas (de LW3DYL y LU7HZ)

Continuando con las pruebas sobre el hardware prototipo construido por Willoh (LW3DYL) y cuyo diseño de hardware está profusamente documentado en distintas entradas de su blog. hice una implementación simple de un generador de SSB; utilicé para ello el programa DSPBASIC que es como un "protoboard" para evaluar en forma sencilla configuraciones DSP. El script resultante ssbgenerator.dsp esencialmente toma la señal del microfono (u otra entrada de la placa de sonido, definida como default) y lo mezcla con un oscilador piloto con señales en cuadratura; esa es una forma de correr en frecuencia la señal puesto que si no lo hiciera se proporcionaría a la placa SDR una banda base de audio defasada en 90 grados pero fija alrededor de su oscilador local. 
Este proceso de mezcla, que vale la pena remarcar que ocurre en el mundo digital enteramente, genera las frecuencias suma y resta; tal como lo indica el método de rotación de fase se pueden obtener las bandas laterales superior e inferior por suma y resta de estos componentes.
Posteriormente se toma la banda lateral superior de esa mezcla y se la procesa con un filtro Hilbert para obtener dos señales defasadas en +/- 45 grados (90 grados en total) que es la que luego puede ser alimentada a la placa SDR (señales I/Q). 
Las pruebas hasta ahora fueron con baja potencia pero permiten observar que la supresión de portadora de la placa SDR es muy buena, superior a 36 dB. Sin embargo la supresión de la banda lateral indeseada es muy pobre, solo algo mas de 10 dB. Dado que tanto el oscilador de cuadratura de la placa como la señal de audio inyectada tienen 90 grados de defasaje evidentemente algo en el proceso de mezcla está causando un error que hace que esta cancelación sea mas pobre que lo que debería. Materia para seguir trabajando. Estoy encontrando problemas para hacer funcionar el diseño con la mayoría de los programas SDR disponibles. Rocky se niega a reconocer las placas de sonido que estoy utilizando, KGKSDR tiene problemas erráticos con las placas de sonido en la versión transceiver aunque se comporta correctamente en la versión receptor. Todas las variantes de SDR para el Flex requieren ese hardware conectado. WinRad funciona correctamente aunque es solo de recepción.


viernes, 3 de enero de 2014

Actualización del HZPTT de LU7HZ

Aunque no he podido aún probarlo en condiciones de mediana performance (y menos aún en condiciones de concurso) he estado trabajando en ajustar algunos aspectos del funcionamiento del programa HZPTT.
El mismo básicamente monitorea una linea definida de una de las placas de sonido disponibles en el sistema en que corre (seleccionable) y cuando el nivel de energía supera determinado umbral activa el PTT del emisor.
El nivel de energía al que se dispara y el retardo en apagarse son seleccionables.
El comando de PTT se dá via el CAT del transceiver a través de facilidades del paquete OmniRig (Alex,VE3NEA), el que debe estar instalado.
Opcionalmente puede utilizarse un puerto serie (RTS/DTR) para activar el PTT, aunque será necesaria una interfaz de hardware para producir la manipulación física y solo podrá controlarse un transmisor únicamente. Por ahora no realizo en forma automática la selección sobre si el equipo a encender es el A (rig1) o el B (rig2), por lo que la selección es manual. No encontré una forma sencilla de poder extraer del N1MM cual es el equipo con foco en forma externa (aunque no descarto que termine encontrando la forma).

Progreso con SDR LW3DYL-LU7HZ

Finalmente pude hacer algunas pruebas con la última versión de hardware prototipo del diseño de transceiver SDR (ver figura). Por ahora las pruebas fueron en recepción y anduvieron razonablemente bien con el programa KGKSDR. 

El rechazo de imagen es del orden 20 dB y la sensibilidad es razonablemente buena para la simplicidad que en definitiva tiene el diseño. Casi la totalidad del trabajo ha sido hecha por Willoh (LW3DYL) hasta ahora pero se vá aproximando que cambie para la parte de software del proyecto. Por ahora me tengo que concentrar en lograr dos prototipos simples de receptor y transceiver que sirvan fundamentalmente para hacer mediciones y optimización del hardware. 

También hay que dar tiempo a que Duncan (M0KGK) envie finalmente una versión alfa del nuevo KGKSDR que podamos integrar con este diseño. El archivo de audio muestra un segmento de la prueba donde se sintoniza un contacto entre estaciones de San Luis, Mendoza y Buenos Aires; las condiciones en 80 metros no eran particularmente buenas (muchos estáticos al momento); durante la grabación se sintoniza primero con el filtro digital de 3.1 KHz, luego sucesivamente con 2.6 KHz, 2.1 KHz y finalmente con el Noise Blanker digital activado, nada mal para cuatro diodos y un montón de software, ¿no?

Buscar este blog

Vistas de página en total