Pixino con cariño es ADX

 

En una entrada anterior comenté sobre el proyecto Pixino, básicamente un diseño uSDX pero que como etapas de RF utiliza, en recepción y transmisión, un kit Pixie de bajo costo. La larga lista de ventajas y desventajas que tiene éste enfoque fue discutida en ese artículo, pero baste decir que es un proyecto que requiere mucho ajuste y experimentación, sobre todo del firmware QCX-SSB, por lo que es muy divertido.

En ese artículo referí al pasar sobre el proyecto ADX de Barb (WB2CBA), que es una variante diferente pero en el mismo sentido. Es decir, un transceiver de modos digitales usando una estrategia similar a la utilizada por el transceptor QDX de QRPLabs creado por Hans Summers (G0UPL). La principal similitud consiste en la generación de la señal PSK de FT8 (y otros modos digitales) no por el mecanismo convencional de SDR sino por la combinación de conteo con síntesis de frecuencia. El receptor de QDX es un supeheterodino compacto mientras que Barb utiliza un chip CD2003GP (chip receptor de AM/FM de bajo costo) el cual permite implementar un receptor de conversión directa. Se puede generar FT8 de muchas formas, con un transceptor convencional de SSB, con un transceptor simple de DSB (D4D de CRKits), por técnicas de SDR (uSDX) y por síntesis directa (QDX, ADX, entro otros).  

La estrategia de Barb es minimalista, el transceptor es tan de propósito específico que ni siquiera tiene otra forma de visualizar su funcionamiento que no sea con tres leds y como todo control tiene tres pulsadores que permiten seleccionar banda y modo; asignándole una frecuencia fija a cada uno de los modos FT8, FT4, JS8 y WSPR. El resultado es un transceptor super sencillo pero aún así muy potente, en un video demostración en YouTube Barb trabaja antípodas (circuito W-VK) en 20 metros desde su auto con uno de ellos. En su versión actual la implementación carece de cualquier otra facilidad (CAT, otros modos, etc) aunque Barb admite que podría incluirlos en versiones futuras del software.

Es un proyecto tan simple que entusiasma hacerlo, tanto la documentación de armado, como los circuitos y el firmware están disponibles. De hecho, en una revisión rápida pude verificar que los componentes, con excepción de la placa, los tengo o puedo conseguirlos con cierta facilidad localmente. La placa, para la cual están disponible los archivos Gerber para reproducirla, puede ser enviada a cualquier fabricante con esa información. Y por cuestiones de costo ese fabricante suele ser de China (por ejemplo JLCPCB). No obstante, y exceptuando que se quiera pagar USD $65.- de flete por 5 placas de USD $1 cada una hay que esperar bastante para que lleguen, en el entorno de 60-70 dias usualmente (muchos de los cuales se consumen en la aduana y correo locales, misterios de la logística global).

Asi que mi primer impulso fue construir el proyecto pero sobre una placa experimental de propósito general, soldando "cablecitos" a la vieja usanza. La ventaja es que al no tener ni visor LCD16X2, ni encoder rotativo la cantidad de lineas necesarias es muy pequeña, por lo que es relativamente facil de armar.

Mientras consideraba entrarle de esa forma me di cuenta que para poder usar directamente el transceiver Pixino en realidad necesitaba hacerle una sola modificación; re-localizar el pin de la placa Arduino Nano donde se conecta el encoder rotativo, pues es a esos pines los que el ADX usa para ingresar y procesar el audio. Por lo que decidí ordenar las placas y mientras llegan dar los primeros pasos con el firmware usando Pixino. Y alli fue.

Es interesante entender como funciona el transceiver. En receptor el firmware comanda al módulo DDS Si5351 para que provea la señal de oscilador local a un receptor de conversión directa; como no tiene forma de cambiar la frecuencia ni sintonizar solo basta un botón para que ciclicamente vaya cambiando las cuatro frecuencias de las bandas base de FT8, FT4, JS8 y WSPR. La placa ADX es realmente monobanda, pero prevee la posibilidad de enchufar diferentes filtros pasa-bajos. Al mismo tiempo se prevee en el firmware configurar hasta 4 bandas, sin modificaciones estas son 40,30,20 y 15 metros. O sea que la operación es trabajar en una banda definida y poder cambiarla a otras tres, pero en cada cambio hay que manualmente cambiar el filtro de salida. La recepción en si la hace un chip CD2003GP del cual se utiliza la etapa de RF y el mezclador para obtener un receptor de conversión directa. Es chip es extremadamente económico, pero los reportes indican que funciona muy bien. Barb indica que ese rendimiento decae por encima de los 21 MHz por lo que el transceiver, en principio, no se puede usar en 17, 10 y 6 metros, o al menos se pierde sensibilidad al hacerlo. No hay nada en el firmware que con los ajustes del caso no permita probar, solo hay que hacer el filtro pasa-bajos correspondiente a la salida para cada banda (y configurarla como parte del esquema cíclico de cambio). En que banda está el transceiver y en que modo lo indica mediante sendos LED a modo de interfaz de usuario, el firmware prevee hasta 4 bandas.

En recepción es ingenioso pero no es demasiado diferente de un Pixie, ambos son conversión directa. Sin modificaciones adicionales el kit Pixie está pensado para 40 metros y es bastante menos agil en banda desde el punto de vista filtro pasa bajos de salida.

En transmisión la técnica empleada está descripta en el transceptor QDX como se dijo, pero es implementada en la placa Arduino en forma bastante sencilla. A diferencia del transceptor uSDX no se hacen procesamientos de señal sofisticados para detectar amplitud y fase que luego puedan ser empleados para modificar en tiempo real la fase del DDS (operando en el límite del procesador y el DDS para hacerlo, realmente Guido (PE1NNZ) logró algo cercano a lo imposible). En éste enfoque, en cambio, lo que se hace es medir la frecuencia de entrada de la señal de audio por un método relativamente simple de cruce por cero, y una vez detectada esa frecuencia desplazar la frecuencia del DDS en la misma magnitud. Para un receptor de SSB es inmaterial si la señal se generó mediante un proceso de modulación "convencional" de SSB, por técnicas de SDR  o por éste método; observa una señal que varía en frecuencia al ritmo de una señal de audio que recupera y entrega a un programa como el WSJT-X para demodular. La medición de frecuencia es suficientemente "lenta" para no requerir recursos de procesamiento especiales. Básicamente se configura el Timer1 de la placa Arduino de tal manera que sea alimentado por el clock del procesador (16 MHz) y contar cuantos "ticks" ocurrieron entre dos cruces sucesivos por cero de la señal de entrada; parece algo muy "rápido" pero aún para un procesador tan lento es una lentitud glacial. Cada "tick" del reloj insume 1/16 microsegundos, mucho menos que la velocidad necesaria mínima de 1 microsegundo. La medición de frecuencia resulta entonces con una precisión mejor que 1 Hz lo que es mas que lo necesario para modular correctamente una señal FT8 (y mas aún WSPR). Una vez detectada la frecuencia de la señal de entrada simplemente se altera la frecuencia del DDS Si5351. por encima de la frecuencia base que requiera un dado modo. Por lo demás la señal del DDS se amplifica primero con una serie de compuertas digitales 74HC244 y finalmente con una salida en clase E lograda por 3 transistores BS170 de bajo costo operando en clase E. Nuevamente, el transceptor Pixie, aunque menos eficiente por operar en clase C no es muy diferente, la señal del DDS se alimenta al transistor que es el oscilador en el kit, y que deja de serlo al no instalar el cristal y conectar con el DDS en cambio, para luego resultar amplificado. En el caso del Pixie es necesario utilizar una señal PTT para que fisicamente pase la etapa de salida de funcionar como un mezclador a hacerlo como un amplificador de salida de potencia (dando 1W con suerte).

Dado que las diferencias no son tantas me largué entonces a hacer el proyecto. Me encontré con cierta dificultad en reemplazar los tres "switches" físicos que tiene el ADX por un tres switches virtuales que operan en realidad como niveles analógicos sobre un solo puerto. Hay operaciones como presionar dos switches simultaneamente que no son tan triviales de lograr. Pero usando el "pulsado largo" en reemplazo del "pulsado simultaneo" lo pude ajustar. El firmware ADX es tan simple que solo prevee operar con VOX, no tiene ningún circuito físico para encendido del transmisor. Si hay audio transmite y si no lo hay recibe, bien simple.

Con la idea general de hacerle algunos agregados al firmware original también aproveché a cambiar ligeramente la estructura del código para hacerlo mas facil. Implementé también algunas funciones que Barb había indicado que podían ser útiles en el futuro tales como mas bandas y CAT. También un "watchdog" siempre útil en los transmisores que exigen mucho la etapa de salida para el caso que algún problema en el software deje "clavado" el transmisor en encendido.

Hice todas las modificaciones en un branch público pero derivado del original del firmware ADX (técnicamente lo llama "fork") por lo que quizás en un futuro pueda integrarse con el código original (técnicamente se llama "merge" a ésta acción).

Todavía hay algunas funciones que requieren desarrollo, pero con la ansiedad propia de todos los proyectos en cuanto tuvo en funcionamiento lo básico lo puse a comunicar. Y para mi sorpresa rápidamente hizo los "maiden QSO" (equivalente al "maiden voyage" de los barcos, su viaje inaugural) en forma exitosa, cubriendo 600 Km de distancia a media tarde en 40 metros. Nada mal para 300 mW (ver el log WSJT-X adjunto).

Ahora resta completar el firmware y esperar la placa para armar una versión mas robusta, lo que tengo ahora es una placa experimental para desarrollar a modo de prototipo con pocas chances de sobrevivir ser puesta en un móvil.

Dos proyectos al precio de uno, nada mal.

Pixie+Arduino es Pixino

El "ecosistema" uSDX, término que vengo usando para denotar familias de diseños similares que derivan unos de otros a partir de adaptaciones menores, es muy rico. Dispone de una gama muy amplia de opciones para quien desee utilizarlos como parte de su experimentación que van desde las ideas y conceptos como para que se hagan con ellos armados experimentales, kits de distinto grado de calidad y prestaciones, placas armadas y finalmente equipos comerciales. Y sobre éstos distintos modelos con una gama muy diversa de costos y calidades constructivas que van desde muy baratos a razonables en precio y desde horriblemente construidos a razonablemente bien ensamblados, curiosamente no siempre correlaciona el precio con la calidad. Hay ofertas muy económicas de construcción razonable y al mismo tiempo hay equipos ofrecidos en la gama mas alta del precio (que ronda el rango de los USD $150-200) que muestran deficiencias muy marcadas tanto de construcción como de control de calidad. En algunos casos hay reportes de mala calidad de componentes que provocan un funcionamiento peor al esperado. En la práctica los problemas que han tenido los equipos comprados me las arreglé para superarlos, quizás porque al haber armado varios previamente tenía un conocimiento mas detallado del funcionamiento. En todas sus alternativas es una plataforma muy linda para poder despuntar el vicio de experimentar a distintos niveles de experiencia. Por mi parte, y según puede seguirse en éste blog, el concepto me interesa lo suficiente como para tener varios dispositivos. El primero fue un kit QCX modificado para correr el firmware QCX-SSB de Guido (PE1NNZ) el cual usa un procesador ATMega328P funcionando a 20MHz, lo siguió la placa diseñada por Pablo (EA2EHC) que es una versión simplificada que anda con una placa Arduino Nano también basada en el procesador ATMega328P pero corriendo a 16MHz. Pablo hizo las modificaciones del firmware QCX-SSB en aquellos aspectos dependientes del clock del procesador (timers, velocidades de bus, muestreos, etc.). Adquirí posteriormente dos modelos comerciales, el uSDR (el que ha recibido comentarios muy variados en cuanto a sus prestaciones y calidad de construcción, link) y el micro uSDX (link); ambos reportados en entradas anteriores. Es posible que en algún futuro cercano me haga de un ejemplar de la variante impulsada por Manuel (DL2MAN) en respuesta a los "clones" hechos en China y que tiene el nombre (tru)SDX.

Simultáneamente aproveché la familiaridad que obtuve con el el firmware QCX-SSB, en particular la versión modificada por Pablo, para encarar mi propio proyecto. Use para ese propósito los aprendizajes de un proyecto previo llamado PixiePi donde implementé un transceptor digital utilizando una placa Raspberry Pi Zero (link). Claramente la potencia del procesador del RBPi Z es ordenes de magnitud superior que el de una placa Arduino, pero parte de los algoritmos DSP involucrados son similares. En aquel proyecto como plataforma de RF usé un kit económico Pixie, que se puede adquirir fácilmente y que tiene un rendimiento razonable para lo fácil que es construirlo. El resultado fue sorprendentemente bueno, especial en modos digitales de baja señal (WSPR, FT8 o JS8Call). 

Al diseño lo he llamado Pixino (juntando Pixie con Arduino) y los progresos de su implementación pueden ser seguidos en el sitio del proyecto en GitHub. 

Por ahora el prototipo está construido sobre una placa perforada genérica donde se distribuyen la placa Arduino Nano, el módulo DDS Si5351, la placa LCD 16x2, el encoder y la placa Pixie asi como otros componentes de integración, el cableado por ahora es punto a punto. Quizás en algún futuro progrese a generar una placa PCB pues el diseño está dibujado con KiCAD y es por lo tanto posible integrarlo con el módulo de diseño de circuitos impresos.

¿Porque hacer una versión híbrida del uSDX que usara como plataforma de RF directamente un Pixie? Claramente el enfoque tiene pros y contras. En los pros el ya mencionado que hay un diseño simple, razonablemente económico que puede ser adaptado. Hay varias contras, claramente. La primera es que el receptor del diseño uSDX es un diseño SDR mientras que el Pixie es un receptor de conversión directa (mas ruidoso, mas ancho, menos sensible, etc). En segundo lugar el proceso de mezcla es mas primitivo, en el caso del uSDX es un detector Tayloe de bajo ruido y en el caso del Pixie un mezclador precario y ruidoso hecho con un transistor de juntura. El receptor de conversión directa tiene además una tendencia a tomar ruido de fuente, en particular de 50/100 Hz. Por su parte el Pixie usa un amplificador final clase C que es mucho menos eficiente que el clase E que tiene el uSDX, eso implica mayor consumo de potencia lo que perjudica una potencial operación portátil, pero esto no es una consideración de diseño pues no es mi intención primaria usarlo en forma portátil. Pero una consideración mas importante es que en FT8, y mas aún en WSPR, la etapa de salida está sometida a una emisión continua por 15 segundos a 2 minutos. El kit original Pixie de origen chino no sobrevive a ese requerimiento cuando es alimentado desde +12V y solo lo tolera (calentando mucho el transistor de salida) cuando es alimentado desde +9V pero a expensas de una potencia bastante menor, así que hay que agregarle un disipador generoso para que pueda operar de esa forma obteniendo la mejor potencia posible.

La modificación del firmware QCX-SSB implica eliminar todo aquello que no se usa. La técnica para hacerlo es lograr que activado una directiva especial de compilación (#define PIXINO 1) todas las instrucciones que deben ser removidas o agregadas lo sean, y sin la directiva el firmware sea el que corre en la placa EA2EHC. Las modificaciones cosméticas son varias, pero las esenciales son dos. Por un lado que tanto en recepción como en transmisión la linea CLK2 quede funcionando de manera de proveer el oscilador local a la placa Pixie, en el firmware original el CLK2 opera en transmisión mientras que el CLK0/CLK1 (en cuadratura) lo hacen en recepción. También la modificación incluye operar en todas las opciones de configuración del firmware para que aquellas que no le hagan sentido estén forzada a valores que las anulen, por ejemplo todas aquellas funciones relacionadas con el receptor del estilo de filtros, AGC, NR, ATT, etc. El receptor no es controlado por el firmware, solo se le provee un oscilador local y se toma el audio resultante sin procesamiento alguno.

En transmisión el diseño se puede usar en CW, donde opera como un Pixie con OFV básicamente, o en USB que en realidad no lo es pues el Pixie no tiene forma de dejar controlar la amplitud de la señal, pero que se utiliza en modos digitales de baja señal que son mayormente variantes de modulación PSK. La diferencia entre USB/LSB y CW consiste básicamente en el desplazamiento de la portadora piloto para operar en frecuencia o desplazado para dar el tono de CW de 600-700 Hz.

El diseño se completa con un gestor del PTT del Pixie que permita ponerlo en transmisión en el modo USB o transmitir en el modo CW, el cual se implementa con un JFET. El resto del diseño, filtros de audio, encoder rotativo, switches y display LCD 16x2 son los del diseño uSDX original. 

Hay una modificación adicional en la que es útil detenerse. El uSDX utiliza un enfoque de procesamiento de señales magistralmente implementado por Guido que logra que un procesador tan limitado como el ATMega328P pueda procesar una señal y extraer la información de amplitud y fase necesaria para generar la modulación en los distintos modos que soporta el firmware. Pero también tenía al comienzo del proyecto interés en experimentar por el enfoque propiciado por Hans Summers (G0UPL) en el kit QDX. Es decir en lugar de un procesamiento tan exigente como para comportarse como un transceptor genérico de SSB, asumir que se tratará de una señal digital, modulada en PSK y sin información de amplitud. Mas aún, que lo que tiene que hacer el algoritmo de manejo de señales es programar el DDS Si5351 de manera que "traslade" la frecuencia de audio a una banda de RF, le sume la frecuencia de audio a una frecuencia base por ejemplo en la banda de 7MHz. Como las variaciones de frecuencia son relativamente lentas en FT8/JS8 y mas aún en WSPR el procesamiento necesario en la señal no es tan exigente, en una entrada anterior (link) compartí como se encara en ese kit la medición de frecuencia. O sea que empecé el proyecto con la idea general de poder hacer funcionar al transceptor en la forma convencional uSDX y con el algoritmo QDX. 

Mientras tanto un muy prolífico experimentador, Barbaros (WB2CBA), autor de una muy interesante variante  denominada uSDX-MoNo (por MoNo band) que implementa un transceptor muy compacto, apareció con un diseño extremadamente minimalista de transceptor de modos digitales al que denomina ADX (Arduino Digital Xceiver), donde se pueden ver su descripción (link) y detalles constructivos (link), el que permite emitir en una cantidad discreta de bandas y modos pero que no tiene capacidad de sintonía, ni display, ni CAT ni nada. La sencillez misma. En recepción utiliza un chip de consumo masivo para fabricar radios de AM/FM, el CD 2003GP que se utiliza para implementar un receptor de conversión directa en la gama de HF, al igual que en mi uso del Pixie el firmware no hace mucho mas por la cadena de recepción que aportarle un oscilador local de la frecuencia apropiada. Pero lo que es interesante es el algoritmo que usa para procesar la señal de audio en transmisión. Utiliza una facilidad del procesador ATMega328P denominada Analog Compare que es capaz de muestrear una señal básicamente a la velocidad del clock del procesador y determinar diferencias entre dos entradas denominadas AIN0 y AIN1 (Analog Input 0 y 1), un algoritmo muy sencillo escrito por Burkhard Kainka (DK7JD) (link) permite medir la frecuencia de una señal de entrada mediante el expediente de detectar sus cruces por cero. Basado en ese algoritmo Barbaros implementa un firmware muy sencillo para gestionar el modo recepción y transmisión, controlar el DDS y tomar la entrada para determinar a que frecuencia colocar la salida. El algoritmo opera mediante un control VOX (si detecta señal de audio emite y caso contrario recibe). 

Me pareció una experimentación interesante lograr que el diseño fuera "compatible" con éste algoritmo de manera que se le pudiera cargar el firmware QCX-SSB o el  correspondiente al ADX indistintamente, quizás éste último con alguna mejora para poder usar un display LCD, switches y rotary encoder que están de todas formas disponibles. Para lograrlo hay que introducir una pequeña modificación en la placa. En el diseño original QCX (heredada luego por el uSDX) el encoder rotativo utiliza las líneas D6 y D7 (PD6 y PD7) que se corresponden con las entradas AIN0 y AIN1 respectivamente, por lo que pueden interferir. Para eso se relocalizan éstas líneas al D5 (PD5, no usada en el uSDX) y D8 (PB0, usada en el uSDX pero no en el Pixino pues controla el receptor en el primero y no es necesario en el segundo. Con los cambios, siempre condicionales, del caso en el firmware el encoder sigue funcionando normalmente, pero el audio puede ser alimentado tanto por la entrada analógica A2 donde el muestreado por el algoritmo del QCX-SSB y por las D6/7 donde son procesadas por el comparador.

No tiene mucho sentido incorporar ambos algoritmos en el firmware QCX-SSB pero si poder correr ambos. El firmware del ADX es tan simple que es incluso concebible pensar en correrlo en una placa mas chica (y barata) tal como el Arduino Mini, o incluso el ATmel Tiny85, mucha tela para cortar hasta encontrar que tan chico es chico.

Como sea el resultado, con la implementación del firmware QCX-SSB aún incompleta, con algunas cosas que no funcionan bien aún, fue suficiente como para hacer el QSO de bautismo (Maiden QSO), el cual anduvo sorprendentemente bien para un transmisor no muy ajustado a la antena de solo 500 mW. Se puede ver en el gráfico del sitio PSKReporter.info que el alcance fue sorprendentemente bueno, recibiendo reportes de mas de 1500 Km a una hora donde la propagación no estaba muy abierta, y de hecho pudiendo completar un QSO con una estación a 700 Km, para mi me parece sorprendente la relación entre simplicidad y resultados. Quedan aún algunas cosas que corregir y otras que agregar, como por ejemplo la posibilidad de controlar por CAT la placa o poder utilizar los algoritmos de medición de señal en recepción para proveer alguna indicación del nivel de señal o del nivel de inyección en transmisión. Es una linda plataforma para entretenerse con modificaciones tanto de hardware como de software. Respecto al firmware del ADX la implementación disponible es muy preliminar, quizás si logro alguna mejora no descarto ofrecerle a Barbaros hacer un merge a su versión, el tiempo dirá. Mientras tanto no habrá mas remedio que seguir divirtiéndose con la experimentación.

El (micro)uSDX en LU7DZ

 

En un entrada anterior hice una descripción mas o menos detallada del "ecosistema" de transceptores uSDX. Está siendo bastante común el concepto de "ecosistema" partiendo de un diseño generado y compartido por alguien, el cual va recibiendo sucesivas mejoras, y con el tiempo generando "familias" de aparatos similares que han recibido alguna modificación especializada para un propósito en particular. En entradas anteriores he compartido distintos miembros de esta "familia" y algo de su historia.

La saga de clones chinos continúa, hay muchos modelos ofertados desde distintos fabricantes. El "azul", el "punta roja", el "uSDR", etc. Incluso hay un "clon" de los "clones", pues Manuel (DL2MAN) ha sacado su propia versión llamada (tr)uSDR que se vende en portales chinos tanto en formato kit como dispositivo armado.

Personalmente me fascina el concepto, lo encuentro muy versatil y habiendome familiarizado con el el firmware tiene el potencial para un número de proyectos afines.

Mientras tanto me tropecé buscando otra cosa con una versión extremadamente compacta, no tiene un nombre en particular por lo que lo llamo el (micro)uSDX. ¿Que tan pequeño?... muy pequeño... bastante mas pequeño que un handy de VHF/UHF Baofeng.

Luego de la compra, que coincidió con el año nuevo chino y cierto desbarajuste de las logísticas globales por la invasión de Ucrania finalmente lo recibí.

El resultado de las pruebas me indica que todo depende de que expectativas uno se genera, en función de que tan alto las ponga es mas o menos probable quedar decepcionado.

El precio es imbatible, mucho menos que cualquier modelo armado de uSDX. La especificación mas o menos la habitual para éste diseño aunque con muy poca información constructiva (circuito, manual, etc.). El portal Aliexpress donde lo compré indicaba que es para 40-20-15 mts con potencias de 0.1 a 5W.

Al recibirlo el paquete es la frugalidad misma, básicamente el transceptor sin ningún accesorio (ninguno) y con un papel que dice "consulte la reseña en el artículo del producto"... y no hay reseña alguna... (con excepción del conexionado de la entrada PTT/MIC y la salida SPKR).

Pero bueno, muy familiarizado con el diseño navegué con los menues standard del firmware QCX-SSB y encontré que los valores de fábrica son relativamente inusables, hay que modificarlos para que el aparto cobre vida (NR,AGC,ATT, ATT,ATT2,VOX,NOISE GATE en particular).

El sonido es el esperable en un parlante tan pequeño, tiene micrófono incorporado pero no tiene agujero para el mismo por lo que la voz suena un poco "apagada", Dafydd (Dav) Walters (M0WDV) me sugirió en el sitio de soporte para ucx groups.io (donde se discuten cuestiones de todos los modelos y variantes) que hiciera un pequeño agujero en la carcaza a la altura del micrófono, la idea tiene méritos si se lo va a usar en fonía (que no es mi caso). El PTT externo funciona bien (uno de los switches) tal como es estandar en el diseño uSDX.

Pero primer problema, al intentar usarlo en FT8 el PTT por entrada no funciona. Pude hacerlo andar en el modo configurando el control VOX (el que está inactivado de fábrica), hay que tener cuidado de subir el valor de NOISE GATE a 6 o 7 antes de activar el VOX, caso contrario con el valor de fábrica (2) el VOX se activa con el ruido de fondo y queda permanentemente activado. El firmware QCX-SSB no permite cambiar configuración en transmisión asi que se entra en un loop (queda en transmisión, al apagarlo está grabada la configuración por lo que al encenderlo vuelve a ponerse en transmisor, entonces no arranca ..). Superado el loop macabro y logrando que se haga un "reset" de parámetros a valores de fábrica logré hacerlo andar bastante bien en FT8.

Me llama la atención que el firmware deja seleccionar cualquier banda entre 160 y 6 metros, pero resulta que los filtros son solo para 40,20 y 15 por lo que en cualquier otra banda las espurias son monumentales y es riesgoso poner al equipo en transmisión.

Finalmente desarmé el aparato exponiendo su interior, son dos placas en sandwich muy pegadas entre si y a su vez muy pegadas a las tapas de la carcasa. La construcción parece muy deficiente y desprolija. Los toroides están flojos, los switches tenían un falso contacto y tuve que repasar las soldaduras y lo mismo con el conector de 12V pues al moverlos tenían comportamiento errático. Finalmente solucioné la falta de PTT tirando un cable desde el switch de PTT (que si anda) al pin correspondiente del jack MIC/PTT con lo que quedó andando muy bien (tanto en VOX como en PTT externo).

Tuve que armar un pequeño arnés para combinar la señal de PTT/Manipulador externo con la de MIC, agregar un cable 3.5 mm stereo macho-macho y una fuente 12V@4A que uso para éstas pruebas. También tuve que agregar un acoplador SMA(m)-BNC(m) para poder acoplar a las antenas. El conector de antena luce fragil y su soldado interno lo es mas aún, es aconsejable conectarle la antena con un cable bien flexible que no aplique torque sobre el conector.

Para mas seguridad agregué cinta aislante bajo los pines de la placa que pudieran estar en riesgo de hacer corto contra ella, en particular los de RF de salida y los de alimentación de 12V.

Internamente tiene los conectores para programarle otras versiones de microcódigo pero sin pines, es posible que buscando con el suficiente empeño se encuentre como entrarle con una linea CAT a nivel TTL. No tiene batería ni espacio para ponerla dentro de la carcaza.

No hice aún contactos en CW pero si hice varios en FT8. La potencia de salida (todavía no le ajusto los parámetros del firmware) está en el orden de 300-400 mW sobre una antena dipolo rígido, es una potencia adecuada para un trabajo casual en FT8 y local en CW. Es un tema que hay que seguir investigando, pero no me quedaron muchas ganas de aumentarsela porque los transistores de salida no tienen disipador, mucha eficiencia de clase D/E, pero sin disipador no creo que sea sensato tratar de sacarle mucho mas de 1W a 4 transistores FET de baja señal como el BS170.

Todavía queda bastante para experimentar pero la primer impresión, como dije antes, depende de lo que uno esperaba. Conociendo el diseño en hardware y software e incluso conociendo lo comprometido del diseño del QCX-Mini para entrar en una forma mucho mas pequeña (y siendo éste MAS pequeño que un QCX-Mini) sabía que seguramente habían tenido que realizar muchos compromisos. No tener batería, probablemente cuidado con la potencia. La construcción pésima y el control de calidad peor no lo contaba, en parte se explica por el precio.

En resumen, creo que no es un aparato para iniciados o quien no tenga ganas de abrirlo para reparar y experimentar, aún así bajo esas condiciones de bajas expectativas su precio bajo y su factor de forma miniatura lo hace atractivo.