jueves, 29 de noviembre de 2012

Clase magistral de SO2R por Randy K5ZD

Randy (K5ZD) recientemente designado director del concurso CQ WW provee en este video de tres partes (Parte 1, Parte 2 y Parte 3) una explicación y demostración práctica de como se usa y para que sirve la técnica de SO2R (Single Operator 2 Radios). El video está en inglés, pero aún para quienes no manejan el lenguaje seguramente podrán darse una buena idea de la explicación que vá dando. En particular en la parte 2 del video en la demostración práctica si se la escucha con auriculares el audio vá, como en un controlador SO2R típico, al oido izquiero y derecho por separado dando una buena idea de como luce tener dos señales totalmente diferentes.
Aunque parezca mentira en la primera impresión no requiere demasiado entrenamiento adquirir la capacidad de escuchar un oido o el otro indistintamente haciendo que nuestra mente simplemente ignore al otro.
En la demostración el hace S&P con el oido izquierdo y run con el derecho. También dispone, como descubrí que era necesario para no tener problemas de orientación espacial, el rig alineado espacialmente con el oido que lo recibe (oido izq=rig izq, oido der=rig derecho). De hecho yo los uso al revés, para mi el run es el izq y el S&P el derecho. Por supuesto, haganle caso a Randy y no a mi (al comienzo del video muestran sus logros concurseros y son impresionantes). Un detalle que creo impresionante y digno de verse, además de muy ajustado a la realidad, es que si bien está trabajando un ritmo importante en ambas radios el ritmo y stress que parece tener al hacerlo no es muy marcado. Esto contradice la primera imagen mental que se asocia al SO2R (locura inmanejable, mucho stress, etc). Por lo menos para mi me dá resultado intentar usar SO2R cuando la tasa de contactos (indicador instantaneo del N1MM) está en 20 QSO/Hr o por debajo (supongo que cada operador tiene su propia marca).

miércoles, 28 de noviembre de 2012

El "less chirpy" de G3XBM

En su blog Roger (G3XBM) comparte la evolución de su proyecto de un transceiver ultraliviano para 10M. En su momento su manipulación era tan mala que el mismo lo llamó el "chirpy" ("chirp" es click o defecto de manipulación). Luego lo fué evolucionando para ir solucionando el problema hasta el diseño actual que lo llamó, como corresponde, el "less chirpy" (el menos defectuoso).
El transceiver opera con el mismo principio que la mayor parte de los diseños simples QRPp del estilo "Pixie". Un oscilador tipo Colpitts es operado en bajo nivel de señal y se comporta como un mezclador implementando un rudimentario receptor de conversión directa; el componente de audio es extraido del emisor y amplificado por otra etapa. Aún así el nivel de audio es realmente bajo y se necesita amplificarlo excepto que se tenga "muy buen oido". Al cerrar el circuito de manipulación el oscilador es operado en alto nivel y opera como transmisor. La modificación de "chirpy" a "less chirpy" consistió en manipular simultaneamente la capacidad en base (desplazando la frecuencia) y la corriente de emisor (aumentando la potencia).
Como en otros diseños similares se lo puede "aumentar" utilizandolo en conjunto con algún procesador de señales tal como un transceiver SDR o CW Skimmer o CWGet.
No hay referencias hechas por George, pero sin haberlo construido supongo que será posible cambiar el diseño a VXO de forma de poder tener alguna minima variación de frecuencia que lo haga un poco mas útil para contactos "normales". Personalmente lo pondría en una frecuencia mas baja (28020 KHz por ejemplo);   notese que el cristal no es uno de sobretono sino fundamental, supongo que eso lo hace ser un poco fragil a la potencia que se le puede sacar al dispositivo.
El resultado son 70mW; quizás con buena propagación, en una buena ubicación y con una antena razonable (no tan dificil de obtener en 10M) sea suficiente para un divertido dia de campo.
Suena que el tiempo de construcción tiene que ser no mucho mas de un par de horas, y sacando el cristal, todos los componentes son extremadamente comunes y de bajo costo.

martes, 27 de noviembre de 2012

CQ WW CW 2012 (Notas)


Y pasó el CQ WW CW Edición 2012, probablemente LA fecha mas importante de concursos de CW del año y junto con su similar de fonía que ocurrió un més atrás los concursos de mayor convocatoria del año.
Un concurso por mi parte muy esperado puesto que es la conclusión de varios meses de preparativos en varios aspectos.
El resultado reclamado en la categoría SO SB 10M QRP es 946 QSO con 29 Zonas CQ y 73 entidades (radio paises), con un puntaje promedio de 2.90/QSO tengo entonces un puntaje reclamado de algo mas de 283K puntos.



PLANEAMIENTO

En esta ocasión, por una combinación de factores, no publiqué el planeamiento para el concurso, pero tanto el resultado basado en datos históricos como el basado en el pronóstico de propagación con el programa VOACAP me hacía suponer que podría aspirar a un orden de 550-580 QSO con 70 paises y 25 zonas. Basado en ocasiones anteriores suponía que podría establecer un promedio de puntos por QSO en el entorno de 2.81 Ptos/QSO. Es evidente que el planeamiento es, en el mejor de los casos, solo indicativo. Hay demasiados factores involucrados y la mayoría de ellos son aleatorios. Sin embargo, aún los procesos aleatorios pueden ser pronosticados, no ya con un enfoque deterministico sino estocástico (palabra dificil para designar rangos de confianza en los valores proyectados). Aun así muchos factores pueden transformarse en "causas especiales" que muevan el resultado fuera del rango de confidencia, cambios en la estación, habilidades adquiridas (o torpezas asimiladas), errores de juicio sistemáticos, propagación (en ambos sentidos) y muchos otros. En ocasiones me han consultado cual es el sentido de planear, con lo que parece ser un cierto cuidado por los detalles, algo que tiene tantas oportunidades de variación; si tanto puede cambiar ..¿para que tratar de estimarlo?.
La respuesta radica en por un lado entender que los pronósticos detallados tienen, aunque no están dibujados de esa manera por una cuestión de legibilidad, en realidad una banda de confianza. Si algo hace que el resultado es diferente o está afuera de esa banda es posible entonces reflexionar que fué (para mal o bien) lo que lo movió fuera. Y en la comprensión de las razones está la materia prima para mejorar. En ocasiones solo es un evento estocástico, por ejemplo un golpe de propagación, sobre el cual poco podemos hacer. En otras hay "causas especiales" que si podemos controlar, como mejoras en la estación y es la forma  de poder analizar con cierto rigor si una "mejora" tiene algún significado estadísticamente relevante o simplemente una variación al azar propia del sistema (en este contexto el sistema es la suma de reglamentos, competidores, categoría, propagación, estación y operador). En este concurso hé tenido tanto "benefactores" como "detractores" especiales, lo que para mi lo tranforma en uno de los concursos mas interesantes que hé participado a la fecha.
Medité mucho sobre que categoría participar, y de hecho hasta algo menos de una semana antes no había volcado mi preferencia por ninguna; hasta el comienzo mismo del concurso en realidad tampoco estaba totalmente decidido. Elegí finalmente SO SB 10M QRP, pero a poco menos de 3 horas de comenzar el concurso cuando la propagación en 10M se estaba extinguiendo (por lo menos para lo que podía hacer en QRP) y dediqué una última reflexión a si cerraba ahi el día o saltaba a 20M para seguir en SO AB QRP, finalmente hice lo primero, lo que creo fue una buena decisión en perspectiva. Las estrategias no son (ni tienen que ser) inamovibles.
Tal como he hecho durante todo el año la "función de utilidad" para definir la estrategia fue el puntaje en la clasificación WRTC 2014; y llamarlo "función de utilidad" no es casual. Es claro que tengo nulas chances de estar mucho mejor en esa clasificación de lo que estoy (en realidad, creo que la clasificación reclamada actual no es razonable y debería estar dos o tres posiciones mas abajo en virtud de las estaciones que están alli). Una función de utilidad no es mas que el criterio para decidir cual es la mejor decisión, la que promete mas o mejores resultados. Consistentemente eso me llevó a participar, con resultados que me tienen muy complacido en SO AB QRP durante casi todo el año (o SO AB LP en los pocos casos como WAE donde no hay categoría QRP). Es claro, bajo esta óptica, que no es conveniente participar en categorías QRP asistidas pues consolidan con las LP, lo que es un sesgo y un despropósito pero asi es. Es también conveniente participar en SO AB porque es con quien consolidan las categorías SO SB a igual potencia; sin embargo en el particular caso del CQ WW (y quizás del CQ WPX) para una estación en SA posiblemente es casi indistinto SO AB o SO SB, sobre todo en 10M. En todo caso veré si el razonamiento es correcto o alguien termina en los hechos mostrando que no lo es.

PROPAGACION Y COMPETIDORES

La propagación se presentaba bien en los pronósticos, cerca de un més despues de la edición de fonía era razonable esperar que Febo completara una rotación sobre si mismo y volviera a exponér las mismas singularidades que generaron buena propagación entonces. Al comienzo se empezó con SFI=127/K=1/A=3, hacia el sábado empezó a subir el A llegando a valores de 15 a 20 (iindicando perturbación) y hacia el Domingo el SFI era de 118. La propagación fué de mayor a menor siguiendo esos valores. El Viernes dió un número inusualmente altos de contactos comparados con experiencias anteriores y el Sábado la mayor proporción de los contactos, aún así la mejor hora (73 QSO/Hora) y el mejor minuto (240 QSO/Hr) ocurrieron el Domingo, el promedio móvil durante todo el concurso fue de 32 QSO/Hr. Estas tres marcas fueron las mejores en mi experiencia competitiva por un margen de entre un 30 y un 50%.
Hay variadas "causas especiales", alguna de las cuales estoy analizando y otras que seguramente iré descubriendo.

Desde el punto de vista de los participantes hice ligeramente mas paises y zonas que lo planeado; y además conseguí 2 zonas y dos paises nuevos. No me había propuesto hacer el DXCC, pero sigue siendo notable como este concurso "apila" paises, aún en una categoría de intensidad relativamente baja como QRP y en monobanda (10M). Se me han escapado quizás unas 10 zonas durante todo el concurso; algunas de ellas escuchaba el pileup alrededor de ellas y en otros casos los lograba escuchar pero no había forma que pudiera romper el pileup monstruoso que se había formado.
El lado debil de este perfil es que aún así el perfil de paises y zonas es demasiado monocromático, 75% de todos los contactos fueron con solo 3 paises (K 60%, JA 10% y DL 5%), mientras que las zonas 90% en solo 7 de ellas (3-4-5 64%, 25 10% y 14-15 16%).
El perfil de contactos siguió, aproximádamente, lo planeado; pero la tasa promedio de contactos resultó mucho mas alta que lo que había estimado basado en experiencias anteriores, por lo que los máximos fueron mucho mas pronunciados. Los horarios de comienzo y cierre de la propagación fueron bastante bien pronosticados por VOACAP. Hay solo tres horas "negras" el domingo donde la tasa de contactos bajó, sin ninguna buena razón, en forma muy abrupta. Antes y despues tuve tasas de contactos fenomenalmente altas, pero en esas tres horas solo una cantidad de contactos misérrima y muy (muy!) por debajo de lo que tenía planeado. Curiosamente fueron  horas de buena propagación (!!) aunque de condiciones mas ruidosas que lo que habían sido el Sábado (S5-S7 de ruido de fondo en 10M, ciertamente altos). En esa ventana estimo que perdí entre 50 y 100 QSO mayormente de Europa. Era frustrante, no lograba hacer pié en ninguna frecuencia para hacer run, ni lograr nada significativo en los múltiples pileups ni hacerme escuchar por las estaciones aisladas que intentaban mantener un run en estrechisimas islas entre otros pileups. El análisis posterior con el RBN muestra que en ese horario diréctamente no fui escuchado por los nodos de la red o que lo fuí con SNR bajisimos 3 o 4 dB (lo que es menos de media unidad S por encima del QRM+ruido de fondo).
Operativamente he observado distintos comportamientos que ojalá que resulten observados y comience la "concientización" para eliminarlos. Por ejemplo la costumbre de salir con "?" cuando uno está teniendo un run en tasas importantes (al menos, en perspectiva de mi categoría); yo no tardo mas de dos QSO en dar mi licencia, pero aún así a menudo aparecía alguien (con obvia alta potencia) pidiendo "?" como con impaciencia no pudiendo esperar como el resto, es el tipo de estaciones que cuando escuchan finalmente la licencia se ponen encima de todos a llamar. Otro aspecto operativo que me llamó la atención es que muchas (muchas!) estaciones pasaban como reporte solo su zona (en vez de 599 5 o 5nn 5 decían simplemente 5).
Había practicado la posibilidad de utilizar STACK/POP ({STACKANOTHER} y {LOGTHENPOP}), pero no tuve la más mínima chance de utilizarlo en la práctica, será para otra ocasión.
La buena propagación no es exactamente lo mejor para QRP, no sé si ya lo dije :-).

TECNICA

Quien puede dudar que el CQ WW, tanto en su versión de telefonía como telegrafía, son las fechas ineludibles del calendario concursero; es inevitable que al comenzar el año se los pone en los planes y un poco que todo el resto se hace alrededor o en referencia a esa participación tan esperada. En mi caso no es la excepción y varios proyectos durante el año estuvieron orientados directa o indirectamente a este concurso. 
Al comenzar el año jugueteé un poco con algún proyecto creativo para participar en la categoría "extrema". Es una categoría cautivante que al presente ha tenido competidores en dos grandes categorías; la de estaciones remotas (single) o distribuidas (múltiples) por un lado y los de distintas variantes de operadores automáticos por el otro. Por algún tiempo esbocé la posibilidad de unir la tecnología de CW Skimmer con la de AIML (nodemapper) como una combinación (con algunos agregados) capaz de abordar la casi imposible proposición de capturar la esencia de un concursero y abordar un autómata competidor; es un proyecto realmente ambicioso pero que requiere mucho mas tiempo que lo que hubiera podido asignarle, no ayuda que el CW Skimmer no tiene salidas externas de su decodificación y Alex sostiene que no se pueden implementar sin deteriorar su performance (o simplemente es la excusa amable que aportó ante no tener ganas de hacerlo o no interesarle el proyecto); es posible conceptualmente, pero se necesita mucho esfuerzo para intentar morder el problema; quizás para el año que viene (o el otro...). El algoritmo original que desarrollé para decodificar Morse en la entonces ZX81 está ahí aún, solo basta implementarlo en Assembler de un PIC o de un ARM solo un par de centenares de veces mas potentes que el procesador original.
Por su parte el (fallido) controlador automático de antena, que me consumió bastante tiempo de desarrollo solo para descubrir que tengo mi propio rotor en malas condiciones (al menos la parte que sensa la posición) y no es de gran utilidad. 
Asi mismo a comienzos del año me había puesto por objetivo superar, o al menos intentar, superar la marca de 1000 QSO en un concurso. La principal razón es que es el requisito para reglamentariamente acceder a una SDE bajo la reglamentación vigente. Ese objetivo es endemoniadamente dificil en QRP, ya lo sé desde hace algún tiempo. Tito Corda (LU7EE,SK) rompió todos los contadores con su record para SA de 1134/(Z33+P107) en 1999; los records que duran tanto tiempo no es porque sean fáciles, ni quienes lo hacen lo logran por casualidad. En el caso de Tito tiene, por si fuera poco, los records de 10, 15 y 20 metros (!!).
Estuve bastante cerca de lograr por primera vez de arañar este objetivo, de no ser por las tres horas "negras" podría haber seguramente sobrepasado por primera vez esta marca de los 1000 QSO, aunque aún asi con toda la carne sobre el asador habría estado casi  150 por debajo de la marca actual, en alguna parte Tito debe estár sonriendose como solo los grandes pueden.
Hubo algo de propagación en este resultado tan bueno; pero también hubo al menos 4 meses de práctica diaria (en simuladores como Morse Runner o PileUp Runner) así como en aire de poder pararme en el concurso a 34 WPM y poder sostener tasas de 200+ QSO/Hr (en el emulador). En la práctica se tiene que arbitrar mas bajo que eso; en el emulador siempre sobran estaciones y en las condiciones reales (y en QRP) no; por otra parte los "corresponsales" del entrenador siempre entienden a 34WPM (o no tienen miedo de encararnos al menos) mientras que en condiciones reales si. Pude mantener la mayor parte del concurso a 32 WPM, por tramos 30 WPM (para levantar un poco la concurrencia, lo que notoriamente ocurre) y contestando a 26-28 WPM en el S&P que parece ser la medida mas efectiva para evitar el retrabajo (llegar bajo y rápido es, despues de todo, una mala mezcla certificada).
El segundo factor crítico es un proyecto que conceptualmente es muy ambicioso, pero con el fin de evaluarlo lo implementé con el equivalente informático a un prototipo "atado con alambre" de lo que es una consola de competición para procesamiento de señales. El proyecto, que he llamado por ahora "Deaf Blue" (el sordo azul) es un experimento que combina ideas sueltas con algoritmos de procesamiento paralelo de señales, con técnicas de visualización que "aumentan" la capacidad del cerebro de manipular señales. La descripción en detalle seguramente ocupará varias entradas en el futuro, y su complejidad es bastante alta, pero creo que ha sido uno de los factores que me permitió alcanzar una mejora "disruptiva" en mi performance.
En resumen, la idea sale de comprender que si quiero alcanzar el máximo posible en la categoría en que compito tengo que mejorar en un 30 o 40% mi performance promedio; y esta tiene muchos aspectos para mejorar pero pocos son "evolutivos" o sea simplemente más práctica. En su momento con otros avances disruptivos (como el SO2R, la automatización de la señal alrededor de Omnirig, el procesamiento digital de señales y otros) he logrado alcanzar los niveles que he podido poner en juego este año, poder tomar telegrafía a 35 WPM por ejemplo (hace menos de dos años eso hubiera sido casi una broma de ser considerado). Pero por formación o fisiología o edad o falta de talento era claro que me es extremadamente dificil comprender telegrafía en presencia de muchas señales, simplemente me confundo y no lo logro (o la performance que tengo es miserable). Es curioso porque cuando recibo múltiples señales pero en oidos distintos (en el SO2R) he aprendido a manejarlo mentalmente enfocandome en lo que viene por un oido u el otro. Hasta ahora he solucionado las señales múltiples trabajando con un filtro digital sintonizable de 150 a 200 Hz de ancho de banda, pero el tiempo de sintonía es muy perjudicial, pues pierdo mucho tiempo al hacerlo cuando me contestan varios. Por otra parte necesito trabajar con separaciones importantes con las otras señales (tipo 1000 o 1500 Hz) para que no me molesten, y semejantes espacios no son frecuentes en una banda congestionada por un concurso global.
El software en cuestión es una combinación de varios conceptos experimentales; por un lado algoritmos experimentales para procesamiento en paralelo de filtros FIR que permiten resolver con la potencia equivalente de un filtro de 2 o 3 pasos uno de un orden de magnitud mas, por el otro lado algoritmos de detección de SNR (que originalmente he realizado y publicado en trabajos cooperativos de investigación académicos) ultrarápidos. A estos componentes se le suma la noción (un poco trivial, concedo) que es mas efectivo en lugar de desarrollar un filtro efectivo para proteger lo que uno desea es preferible desarrollar un filtro "notch" para eliminar lo que no. Con los filtros "notch" no voy a descubrir la pólvora, casi cualquier equipo moderno los tiene (aunque mis equipos que no son modernos, al menos el FT840 que es mi equipo primario no los tiene). Pero lo que los equipos modernos no tienen es la capacidad de tener un número ilimitado de filtros notch independientes entre si, docenas, centenares si es necesario.Entonces en vez de proteger las señales que me interesan (con límites prácticos en la distorsión que puedo aceptar al hacerlo) elimino las que no (donde no me preocupa la distorsión que le introduzco). Tomé prestado además un concepto que lo ví implementado en el CW Skimmer, aunque no tengo acceso al código fuente (y nunca me animé a pedirselo a Alex VE3NEA), a ojo de buen cubero puedo decir que lo que hace es implementar un número de filtros independientes entre si con una heurística de SNR (Signal to Noise Ratio, Relación Señal a Ruido) y luego SUMAR los resultados de todos los filtros (es un mecanismo de procesamiento de señales llamado "voting"). Como resultado se obtiene una banda pasante con mucho menos ruido que la original, con solo las señales útiles claramente delimitadas y cada una filtrada por su propio procesamiento individual.
Otra idea subyacente es decidir a cual estación prestar atención cuando contestan varias; supongo que hay formas muy sofisticadas de resolver esta cuestión, pero la mía es cruda y simple... contesto a la más fuerte. Entonces si mi algoritmo es tan simple.. porque no automatizarlo. Obviamente tengo hacia los auriculares solo un canal angosto, pues dejo que un algoritmo decida que señal es la que debo escuchar y se mantiene en alla hasta que la trabajo.
Finalmente, el waterfall de CW Skimmer (limpio de basuras) permite "leer" las señales gráficamente; por supuesto que CW Skimmer no es tan bueno para decodificar Morse, pero si para mostrar las señales muy filtradas. Aparte no es posible "leer" gráficamente las señales en el waterfall (en mi caso solo si van de derecha a izquierda, no funcionan en el otro sentido ni de arriba hacia abajo), en realidad el proceso cognitivo al hacerlo es mucho mas lento que el auditivo y no es efectivo. Pero luego de mucho practicar empeza a formarse, casi sin quererlo, un circuito cognitivo oido-vista-mente donde se empieza a relacionar el patrón auditivo con el patrón visual, yt poco a poco la combinación de ambos logra sacar del ruido señales que individualmente no eran claras. Requiere docenas de horas de práctica y no es claro porque ocurre, pero es como en el caso de recibir señales con el SO2R que son diferentes en cada oido, al cabo de algún tiempo se puede coexistir con ello y seleccionar a voluntad con que oido prestaremos atención. Supogo que con suficiente perseverancia es posible (porque de hecho los grandes talentos de telegrafía si pueden) discriminar en un mismo oido entre diferentes señales.
Esto es una descripción superficial de los principales lineamientos del experimento; desarrollar un software con estas funciones es un proceso de muchos centenares, quizás algunos miles, de horas y no tuve ni por asomo la posibilidad de hacer semejante inversión. Pero probar una cosa asi en el CQ WW es irresistible, asi que tomé por el "camino bajo" e implementé un prototipo "crudo" apelando a componentes existentes, algoritmos simplificados y la implementación parcial de algunas funciones. Como resultado durante el concurso fue que el software era incompleto, ineficiente y fragil. Tengo que ejecutarlo dentro del debugger para que no me "trapee" la máquina, la cantidad de taps de los filtros es mínima para que la máquina no se consuma solo en su ejecución, el algoritmo de asignación automática de prioridades no funcionó y hacía tantos disparates que tuve que recompilar el programa en el medio del concurso para "comentar" las partes relevantes y que no molestara mas. Pero los notch funcionaron bien, la combinación vista-oido también y algunos aspectos de los filtros dinámicos también. Quizás la más notable mejora fue la posibilidad de poder trabajar, con cierto comfort, en espacios entre otras estaciones de 500 Hz o en ocasiones menos; jamás creí que eso fuera posible, pero lo es. Y mis corresponsales no tenían problemas aparentemente en tomarme en esas condiciones, los máximos los obtuve en frecuencias mas despejadas pero aún en condiciones tan "estrechas" pude mantener tasas mas que interesantes, impensables sin esas herramientas en todo caso. Un aspecto que no tuve suficientemente en cuenta fueron el AGC del receptor y el retardo de procesamiento de los filtros. El primero hace que si la señal está en el pasabanda del receptor (que no tiene filtros específicos para CW) la estación potente la "elimino" del audio con un notch dedicado, pero su efecto de modular el AGC del receptor no. En consecuencia el ruido transmite la señal eliminada (si es suficientemente fuerte) al revés, un claro límite al enfoque.
Por otra parte el filtro tiene un retardo muy molesto de 1 segundo luego de transmitir, es un blackout producto de la señal propia al llamar que hace que los distintos mecanismos de realimentación se ajusten y demoren algún breve tiempo en volver a su máxima sensibilidad (aprox. 1 segundo), el cual resultó crucial porque con las tasas mas altas me hacían perder la primer letra del corresponal. Con el transcurrir del concurso aprendí algunos trucos para mitigar en parte el efecto (por ejemplo una O era probablemente la cola de una W, y una A la de una K; aunque hubo muchos casos donde la O era una J o la A la segunda A de un AA); es un tema a corregir sin dudas.
Finalmente, el RBN (Reverse Beacon Network) está ahi y está para quedarse; y es utilizado por mucha gente ahora que está totalmente integrado con el sistema de DX  Clusters; "nadie" usa Clusters, pero basta que uno sea "spoteado" para tener una avalancha de contactos. Basta también un desplazamiento de 100 o 150 Hz en la frecuencia de run para que el RBN decida que hay que volver a reportarnos y mantenga vivo el número de corresponsales. Esto creo que es un paso en la dirección de eliminar la distinción de participación asistida de lo que no lo és; solo hay que convencer con los trucos apropiados a "hombre de lata" para que se mantenga reportandonos en el cluster.
El balance fue muy positivo, como resultado tuve los máximos históricos en minuto, hora y promedio movil de tasa de contactos, resultado que no es posible explicar solamente con aspectos externos. Es un concepto que merece seguir invirtiendole horas para desarrollarlo al menos en algunos de sus aspectos, en resumen.

CONCLUSIONES

Como lo he comentado ha sido un evento concursero con muchos ingredientes y resultados muy por encima de mis expectativas; muchas enseñanzas pero también muchos temas que abordar para mejorar, quizás muchos mas que los que realistamente se pueden abordar. Es posible que este concurso haya tenido una participación record mostrando la "vitalidad" del CW en general. De no mediar dificultades (que siempre se empeñan en aparecer a último momento e impedirme participar) estaré en el ARRL 10M por primera vez en un par de semanas. 





domingo, 18 de noviembre de 2012

El ATTiny85, un chiquito grandote

Es casi imposible concebir una estación moderna de radio que no tenga uno o mas procesadores de propósito general o dedicados (embebidos) para hacer distintas funciones.
Casi cualquier equipo moderno tiene uno o mas para controlar las distintas funciones (que los llamamos genéricamente "la CPU") así como una variedad de software en PC convencionales de arquitectura X86 para propósitos tales como logging, generación de modos especiales, pronostico de propagación y trayectorias y otros.
Crecientemente se esta utilizando también procesadores ya no en un role auxiliar sin en el corazón mismo de una estación de radio, en la generación o procesamiento de las senales con algoritmos DSP (Digital Signal Processing) o SDR (Software Defined Radio).
Es natural que se incorpore también procesadores como parte de la experimentación misma; sin ir mas lejos en este blog he compartido proyectos basados en el PIC 12F675 para implementar balizas, manipuladores electrónicos, controladores SO2R y SO3R, controladores de rotor de antena entre otros.
También he compartido la utilización de dispositivos embebidos operando bajo versiones de Linux embebido como componentes de red en arquitectura HSMM.
Un dispositivo particularmente potente y atractivo es el ATM Tiny85, se trata de un microprocesador de 8 bits fabricado por ATMEL capaz de aportar una sorprendente flexibilidad. Con 8K de memoria de Flash de programa (contra 1K en el PIC 12F675), y 512 bytes tanto de EEPROM como RAM es mucho mas potente que el PIC 12F675, aun asi tiene un factor de forma, costo y flexibilidad similar.
Un bonus que lo hace particularmente util para aficionados es que es un dispositivo pensado para integrarse con el ambiente Arduino. Este ambiente provee todo un marco de herramental de desarrollo (IDE, librerías  ejemplos, etc) que normalmente puede utilizarse para desarrollar (en un lenguaje relativamente simple similar al C) un numero importante de aplicaciones, las que una vez probadas
en la placa de desarrollo pueden ser "bajadas" al ATM Tiny85 y ejecutadas allí  La plataforma Arduino (por ejemplo la Arduino One) puede ser utilizada tanto para desarrollar y probar como luego para "grabar" el resultado en el Tiny85. En realidad la plataforma ArduinoOne tiene mas capacidad y potencia de procesamiento que el Tiny85 por lo que hay que tener cuidado de limitarse, pero no es algo demasiado grave puesto que la mayoría de las aplicaciones de radio la potencia de procesamiento realmente no es relevante (en el firmware de un rotor de antena o un manipulador la mayor parte del tiempo se esta perdiendo tiempo en retardos porque los eventos están en otra escala de tiempo que la del procesador por ordenes de magnitud, ejemplo fracciones de segundo contra microsegundos).
La potencia de esta combinación reside en que la placa de desarrollo Arduino, con lo razonablemente económica que es, sigue siendo lo suficientemente cara como para que uno dude antes de comprometerla en forma "permanente" en un aparato de la estación  Pero ese no es mas el caso, una vez que el desarrollo esta terminado el aparato bajo desarrollo solo tiene el Tiny85 mas la circuiteria propia del desarrollo que se esta haciendo a un costo muchismo menor. Vale la pena experimentar el concepto.

sábado, 10 de noviembre de 2012

El NAS-K330 en LU7HZ






 Llegó con alguna demora el mini-servidor embebido NAS (Network Attached Storage, Almacenamiento Asociado a la Red) modelo NAS-K330. El mismo trabaja un servidor muy compacto alrededor de una arquitectura ARM corriendo (originalmente) un firmware propietario que por indicios externos sospecho una construcción derivada de Linux (aunque restringido y sin ningún tipo de mención a su uso, lo que en el mundo Linux es una contravención importante).
Como sea, eso es totalmente inmaterial puesto que el firmware original
duró solo el tiempo necesario para desembalar el server, conectarlo y ver que funcionara correctamente mediante la corrida de su protocolo de inicialización, el cual está explicado (supongo) con cierto lujo de detalles en el manual en chino y con un inglés algo rudimentario pero seguible.
Una vez que comprobé que funciona correctamente reemplacé el firmware original por la mucho mas potente distro Debian denominada SnakeOS para este aparato. Esta distro mantiene la filosofía original del dispositivo, la cual es el operar como un servidor de bajo consumo para almacenamiento e impresora. Una vez configurado al dispositivo se lo puede acceder, como a cualquier Linux, mediante SSH, Telnet, FTP y Web. También provee una interfaz SAMBA para exportar su almacenamiento a la red como si fuera una "carpeta" de Windows. Corre un cliente BitTorrent por lo cual también se lo puede utilizar para bajar información en forma continua aunque hay que tener cuidado de parametrizarlo en forma no "agresiva" porque se corre el riesgo que se consuma todo el ancho de banda disponible solo para eso.
El almacenamiento del dispositivo es mas bien pequeño (su memoria), pero mediante dos puertos USB se le puede agregar cualquier dispositivo, en este caso un viejo USB Drive de 2G es mas que suficiente para el propósito que quiero darle. Su consumo es ridiculamente bajo, comparado con una PC al menos, y sus prestaciones  son mas que razonables para operar como server para un grupo reducido de gente. En mi red lo voy a poner a ocupar la dirección HSMM (que todavía no está expuesta al aire) bajo el host lu7hz.cor.ampr.org (44.153.81.3).
El SnakeOS es una distro especializada en la función de NAS y los paquetes disponibles para ella son vastamente superiores a las funciones que provee el firmware original, aun asi no tiene los protocolos necesarios para operar con la red HSMM, pero eso es facilmente solucionable porque es relativamente sencillo instalarle un chroot Debian que permite acceder a una inagotable fuente de paquetes compilados para esa distro bajo la arquitectura ARM, con ellos hay prácticamente todo lo necesario para operar en cualquier paquete que se pueda necesitar (o compilarlo desde otra distro de no existir).
El costo de este aparato es muy modesto para las prestaciones y se paga en un mes de consumo de electricidad si reemplaza una PC (que muchas veces es lo único que se disponía para tener algo permanentemente prendido). La única dificultad que le veo por ahora es que no tiene WiFi y por lo tanto tiene que estar colgado por Ethernet de algun router (por ahora lo está de router.cor.ampr.org/44.153.81.1, tampoco visible aún).

jueves, 1 de noviembre de 2012

El controlador de rotor que no controla de LU7HZ

Un poco contra reloj antes del concurso CQ WW SSB, y en el escasisimo tiempo que me dejan las obligaciones, traté de terminar el controlador de rotor e integrarlo con el rotor Walmar para el que está diseñado.
Si bien las pruebas de banco fueron exitosas, la integración con el rotor mismo no funcionó debidamente; ni en el modo semi-automático  ni en el modo automático.
El controlador en si implementa, y hasta donde puedo probar lo hace correctamente, las distintas funciones necesarias.
Es decir, si en el banco de prueba coloco un reóstato que simule el rotor, al poner una referencia en modo semi-automático los actuadores correctos aplican cierran los contactos correctos (aplicando tensión) hasta que la lectura del rotor (controlada manualmente) iguala a la de la referencia dentro un margen de tolerancia (arbitrariamente definido en 5 a 10 grados, sujeto a una experimentación que requiere una estabilidad que no he conseguido aún).
El puerto serie, uno de los puntos mas dificiles de implementar en los muy limitados recursos del controlador PIC 12F675 utilizado curiosamente anda muy bien, los comandos "AI1;" (reportar posición del rotor) y "AP1nnn;" (establecer la posición destino en la dirección nnn) son recibidos y procesados correctamente, generandose como en el caso semi-automático las respuestas de los controladores en la dirección correcta y deteniendose cuando el rotor (simulado) marca las tensiones objetivo. También la integración con el programa N1MMRotor.exe (parte del logger N1MM) funciona correctamente, los comandos que éste envía son procesados y las respuestas mostradas correctamente.
Pero al integrarlo con el rotor "verdadero" (un Walmar de servicio pesado) nada parece andar bien; para una prueba rápida integré el controlador automático en paralelo con el manual; pero ahi descubrí que el manual tenía un notorio ripple en la fuente de "continua" que alimentaba el reóstato de referencia del rotor, sobre todo en las posiciones de menor valor de resistencia (mas corriente), como resultado la lectura del procesador era absolutamente errática (si lograba sensar en un pico marcaba una cosa y en los valles otra), lecturas sucesivas daban diferencias de hasta 90 grados en la posición (tanto como para confundir Oeste con Norte, por ejemplo). El controlador manual, con un lector analógico de baja resolución muestra alguna oscilación, pero es un eficaz "integrador" de pulsos.
Corregido ese problema, o mitigado al menos, con un mejor diseño de la fuente, la lectura sigue errática y es muy dificil calibrar la lectura con la posición real. El principal problema viene del hecho que la lectura del reóstato muestra una resistencia marcadamente alineal con la posición, en principio pensé que el reóstato era en realidad logarítmico y ajusté la matemática del controlador para tener en cuenta el desvío. Pero si bien las lecturas mejoraron la oscilación de la marcación es enorme. Lecturas de otros rotores similares que me pasó gentilmente Jorge Viaña (LU1DA) en el foro LU-Técnica muestra que, además, la lectura del rotor debería ser muy próxima a una relación lineal con la posición.
Es evidente que hay algún problema en el rotor, tan simple como suciedad y tan complicado como un daño en el reóstato, que hace que las lecturas sean marcadamente erráticas y que el comportamiento no sea lineal.
Mientras no se solucione ese problema no puedo continuar con las pruebas ni con el desarrollo, y subir a la torre no es algo que yo pueda hacer así que pasará algún tiempo antes que alguien que me pueda dar una mano lo haga por mi.
Los valores erráticos y los "picos" de ruido que recibe hacen que el controlador funcione pero no sea efectivo; por un lado no puede leer con ningún grado de exactitud la posición y por el otro las funciones de rotación automática y semi-automática no terminan de llegar al acimut objetivo que algún ruido lo interrumpe; como el error puede ser amplio esto hace que en la práctica se detenga mucho antes de lo que debería.
Las pruebas de banco me llevan a tener confianza en el controlador; sin embargo creo que una vez que esté reparado el rotor hay que abordar como filtrar las oscilaciones y "latigazos" que vá dando el rotor mientras gira, sin ese ajuste aunque todo funcione bien igual tendrá lecturas erroneas. Quizás es parte del mismo problema y la limpieza que haya que hacer para que la lectura sea correcta haga que gire con mas "suavidad". Mientras tanto el estado actual del esquema (sujeto a modificaciones) puede obtenerse aqui y el microcódigo en su versión actual escrito en Pascal aqui o en Hex aqui.
El duro negocio de experimentar y que los experimentos den pelea.... ¿o es diversión?

Buscar este blog

Vistas de página en total