miércoles, 31 de octubre de 2012

Campeonato Argentino de HF (Final 2012)

Aparecieron los resultados del Campeonato Argentino de HF Edición 2012.
Como ya lo marcaban los resultados parciales a partir de la publicación de la 5ta y última fecha el campeón fue Martín (LU9DPM) y el sub-campéon fue Daniel (CX9AU). Pude obtener en esta edición el tercer puesto seguido por Carlos (LU1DKD) y Diego (LU6FHO).
En rigor el resultado por el primer puesto, en contrario a lo que los organizadores decían para mantener viva la llama de la participación, estaba (análisis que he compartido en algún mail privado) mas o menos delineado al concluir la 3ra fecha y se hizo indescontable al finalizar la 4ta fecha; la única forma que Martín no saliera campeon era no participando en la 5ta fecha. Al finalizar la 4ta fecha el resultado por el 2do puesto estaba abierto entre Daniel y yo, con poquisimas chances que Carlos o Diego pudieran alcanzar estos puestos; aunque si bien Carlos no tenía ninguna chance para Diego había al menos un escenario, estadísticamente improbable pero escenario al fin, que pudiera alcanzar el tercer puesto y mandarme a mi al cuarto. Los resultados de la última fecha, en mi caso con malas performances en SSB, buena en CW y mediocre en PSK definió los resultados en favor de Daniel.
Este resultado está dentro de los objetivos que me había puesto al comenzar el año (figurar entre los primeros 5 puestos en la clasificación general) y muestra que la estrategia fue apropiada para disimular el enorme deficit de antena en 80M que arrastro en esta competencia.
La clasificación refleja, como lo hacía preveer una lectura detallada del reglamento, no tanto la performance de cada estación sino su performance promedio en los tres modos (CW, PSK y SSB).
Hubo estaciones que no se preocuparon demasiado porque básicamente buscaban divertirse (y seguramente lo consiguieron), otros lo vieron con sorpresa al tener performance descollantes en alguno de los modos (normalmente en SSB) pero aún asi quedar de la mitad de la tabla para abajo; el método de puntaje es implacable pues cada modo puede otorgar solo un máximo del 1/3 de los puntos en juego. Y esto se vió con algunas estaciones que hacia la 2da o 3ra fecha fue obvio que apuraron el cableado para salir en PSK, y en algunos casos hasta incluso desempolvaron algún vertical olvidado en algún cajón para salvar algunos puntos en CW.
En mi estrategia sabía que en CW salvaba la ropa, y de hecho tomando solo el puntaje de este modo hubiera quedado 2do detrás de Daniel (CX9AU). También sabía que en SSB competía por ver que tan lejos me podía poner del último puesto, y de hecho creo que algunas performances aisladas fueron mucho mejor que lo que hubiera esperado; quizás un poco por haber mejorado la antena de 80M y otro poco por golpes de suerte (o de propagación). Mi gran duda era como iba a poder apalancar el segmento de PSK para poder hacer alguna diferencia, y es un segmento que siento que sin ser desastroso no he podido hacer pié en todo el concurso y que de participar en la edición del año que viene tengo que revisar bastante como planteo la estación para encararlo pues la configuración que usé no me terminó de convencer.
Con la debida perspectiva es un progreso enorme, toda vez que en la edición 2010 (puesto 34) y 2011 (puesto 38, aunque participando solo en el segmento de CW donde salí en primer puesto).
De cara a la, supongo que probable, edición 2013 de éste campeonato creo que si bien los cambios introducidos en este año han sido mayormente para bien hay aspectos estructurales (horarios y duraciones), reglamentarios (categorías), entrenamiento (lineamientos de técnicas y herramientas de concursos) y metodológicos (forma de computar los puntajes) que merecen alguna revisión; lo haré en otra entrada posterior luego de compartirlo en privado con los organizadores.
Buena experiencia y buen cierre del año; muchas felicitaciones para el campeón y el sub-campeón porque lo son en buena ley; y como en todas las competencias, el agradecimiento a los organizadores y los participantes sin los cuales no hay competencia posible.

martes, 30 de octubre de 2012

CQ WW SSB 2012 (Notas)



Y pasó el concurso CQ WW SSB edición 2012, uno de las mas importantes (si no la más importante) fecha del calendario anual; con la participación de una enorme cantidad de concurseros a nivel global.
Participé en la categoría SO AB QRP y mi resultado reclamado es de 609+Z49C94 con un puntaje en el entorno de 244K puntos. Esto es un poco mas de un 20% de contactos que lo planeado y un puntaje dentro del rango esperado. La propagación estuvo mejor que lo esperado al momento de hacer el plan y eso explica mayormente la mejor performance.



PROPAGACION Y PARTICIPANTES

Tuve una participación muy sesgada a la banda de 10 metros, hice ahi mas del 86% de los contactos, haciendo en 20M un 12% y en 15M un casi inexistente 2%. Si bien la performance en 10M fue mayor a la esperada, la de las otras bandas fue mucho menor a lo esperado y eso terminó no contribuyendo al resultado final. A diferencia de otros concursos del año no pude hacer contactos en las bandas bajas (40 y 80), los intentos de contactos fueron todos infructuosos y las condiciones de propagación me resultaron pobres alli en contraste con las bondades de bandas altas (en especial 10M).
Pude en total contactar 22 Zonas CQ, un número relativamente bajo y sin zonas nuevas, mientras que pude hacer 66 paises (entidades en realidad) lo que también estuvo por debajo de participaciones anteriores lo que también muestra que la estrategia que utilicé no fue la apropiada.


La distribución de paises muestra que casi la mitad de los contactos fue hecho con USA (48%), los paises que contribuyeron también al 70% de los contactos fue Japón (10%), Brasil (5%), Alemania (4%) y Canadá (4%). La distribución de zonas también muestra un sesgo similar Z3+4+5 se llevó 74% de los contactos, mientras que la 14 (Europa) un 14% y la 25 (Japón) un 10%.

Pude operar un total de 27 horas con algunos momentos de tasas de contactos muy buenos (ligeramente arriba de los 60 QSO/Hr sostenidos durante una hora, con picos de 300 QSO/Hr de pocos minutos), estas tasas son una enormidad para QRP. La tasa promedio durante el concurso fue de 23 QSO/Hr, un poco por arriba de lo utilizado para planear. Una combinación de compromisos profesionales con actividades familiares me impidieron estar en horarios importantes en el arranque, durante la 2da noche y en ambos dias ocasionaron algún "bache" visible en la actividad, calculo que de no haberlo tenido quizás podría haber alcanzado 100 a 150 QSO mas.
La propagación estuvo muy "picante" con un SFI que estuvo en todo momento por encima de 120; el K estuvo en 3 o menos durante todo el fin de semana; solo el A tuvo un "pico" de 12 en la tarde del Sábado pero luego volvió a valores menores. Noté un nivel de ruido muy alto en 15 y 20M durante prácticamente lso dos días, y por momentos también en 10M aunque finalmente la banda se aquietó.
Como parte de la preparación miré (en diferido) el Webinar que dió el nuevo manager del concurso (Randy) sobre como plantear el concurso y como interpretar algunos cambios de reglas; algunos cambios conceptualmente útiles fueron cambiar el criterio de dar "QSO B4" ante un contacto duplicado y registrar siempre; ese es un criterio bastante sensato que ya venía aplicando pero que no todos los concursos alientan. El otro cambio es en el vencimiento del plazo de entrega de los logs que es de solo 5 dias ahora.
Escuché durante el concurso relativamente pocas estaciones de Argentina, no estaba LS1D pues sus participantes estaban en HK1NA (que parece tener un score realmente importante en M/M), a LP1H y alguna estación más. Escuché muchas estaciones CX y CE comparadas con otros concursos, lo que es muy bueno. Muchas estaciones en Sud-América donde pude trabajar todos los paises excepto Bolivia de donde no escuché ninguna estación.

TECNICA

Finalmente utilicé una configuración SO2R, con algún problema en la energía del rig2 (FT890) que lo hacía intermitente; pensé en una falla sofisticada pero terminó siendo un falso contacto en el cable de alimentación; conclusión trivial de alcanzar con el equipo en el banco de trabajo pero complicado haciendo mediciones mientras se está contactando con el otro equipo. De todas formas la configuración no rindió ni cerca de lo que en otras oportunidades, lo que es visible en la casi ausencia de contactos en bandas que normalmente hago en el rig2. También se vé en el número relativamente bajo de multiplicadores, que hizo que a pesar de haber estado 22% por encima en contactos el puntaje estuvo por debajo del máximo planeado para muchos menos contactos.
Las dos cosas nuevas que probé no anduvieron bien. Una fue el controlador de antena que estuve desarrollando (en la foto puede verse en su implementación araña) y sobre el que haré una entrada de actualización del proyecto. 
También probé integrar la estación a la base de datos de scoring online (cqcontest.ru); esta integración era mas por curiosidad que por practicidad, vi el comentario en el reflector CQ Contesting sobre su disponibilidad y aunque queda claro que es un recurso de mas utilidad para las grandes estaciones quise probar la integración con el N1MM. El resultado no fue bueno, no conseguí e ningún momento que mi score se viera reflejado.
Durante la preparación preliminar de la estación detecté que la dll que permite al programa de integración OmniRig-N1MM (MM2OR) "conversar" con el FT840 no funcionaba bien, por lo que retrocedí de versión y puse la vieja dll que andaba bien (y que había reemplazado cuando hice modificaciones para incorporar al FT100 durante el WAE). Luego veré cual puede ser la razón, no tenía tiempo de hacerlo con el concurso encima.

CONCLUSIONES


En perspectiva no siento que haya aprovechado las fenomenales condiciones de propagación que se disfrutaron en este fin de semana, mas allá que cuando pude tener tasas de contactos altas las aproveché creo que me concentré demasiado en 10 metros. Quizás me entusiasmé con que en todo momento 10M me daba mejor tasa que las otras bandas y por eso luego de cambios de banda cortos con movimiento lentos volvia a tratar de seguir haciendo estaciones en 10M. Es posible que las condiciones hacían que para una operación en QRP no se pudiera hacer gran cosa diferente; es claro que tengo limitaciones de antena en 15M pero la performance de 20 y 40M suele ser bastante mas alta en proporción que lo que obtuve; y ultimamente he podido hacer pocos pero muy fructíferos en términos de multiplicadores contactos en 80M . 
Sin embargo creo que la mejor explicación es que la estrategia "all band" en el CQ WW es muy diferente a la experiencia ganada en SO SB de participaciones anteriores y al de otros concursos de este año que no son "todos contra todos". En efecto, para los grandes concursos regionales (ARRL y WAE) la propagación "dicta" los cambios de banda y en otros casos (CQ WPX) el flujo de multiplicadores está tan fuertemente relacionado con la tasa de contactos que mientras uno se mantenga el otro también. En el CQ WW en cambio y habiendo condiciones la "rotación" de la propagación mantiene el "run" pero no necesariamente el flujo de multiplicadores (esto se vé, en retrospectiva por supuesto) cuando mas del 70% de los contactos están concentrados en media docena o menos de multiplicadores. Algo para pensar en como contrarrestar por cierto, ojalá que pueda adoptar alguna corrección para el CQ WW de CW en poco menos de un mes.
Por otra parte me quedo con alguna reflexión sobre que tan buenas son las condiciones de propagación para la operación QRP; está claro que si no hay propagación QRP es el modo que más tiene que perder. Pero si hay mucha propagación esta también ayuda a las estaciones HP/LP en una medida similar, haciendo que los "run" sean mas prolongados y con menos "baches" de ocio que una estación entrando mucho mas "bajita" pueda aprovechar. En general los contactos en S&P con estaciones que llamaban sin estar en "run" fueron de uno (o a lo sumo dos) llamadas, sin embargo la tasa de intentos fallidos con estaciones que estaban en "run" fue gigantesca; hubo multiplicadores que no pude trabajar (sobre todo del Caribe) a pesar de escucharlos por horas en muy buena forma.
Interesante y divertido, mucho para aprender por cierto; ahora a prepararse para la versión de CW en poco menos de un mes, muchos preparativos para hacer o, mejor dicho, intentar hacer.

martes, 23 de octubre de 2012

CQ WW SSB 2012 (Preliminar)



Y se viene el CQ WW Edición 2012, pleno de cambios reflejando la impronta de su nuevo manager  Randy Thompson (K5ZD) . Consistente con la estrategia que vengo utilizando en este año calendario concursero participaré en la categoría Single Operator All Band QRP (SO AB QRP), siendo la primera vez que lo haré en esta categoría puesto que en las ediciones anteriores había optado por SO SB 10M en diferentes variantes de modo y potencia. Esta decisión es consistente también con mi estrategia durante esta año de utilizar los criterios de clasificación para el WRTC 2014 como fundamento para planear mis participaciones.
Mi estrategia de participación la he diseñado teniendo en cuenta una serie de compromisos personales y profesionales que limitarán la cantidad de horas que pueda operar a 28 horas. Las condiciones de propagación este año pintan, una semana antes, como muy buenas con un SFI relativamente alto de 141, el que resulta similar al que experimentamos el año pasado para este mismo concurso pero aún así las condiciones el año pasado fueron tan excepcionales que no planeo este año tener una mejora significativa en los puntajes para preveer que no lleguen a ser tan buenas.

He realizado un planeamiento de mínima basado en los resultados que obtuve con el programa VOACAP sobre el rendimiendo promedio de las distintas bandas y por otro lado un planeamiento de máxima basado en el perfil de bandas obtenido por LS1D durante el concurso del año pasado, que gentilmente me hizo llegar Dany (LU3CT). En lineas generales cuando no he tenido datos propios he encontrado que las proporciones de contactos, escalado por factores empíricos a las bondades relativas de mis antenas en las distintas bandas y por supuesto al número de contactos al que aspiro, dá un pronóstico razonable.
En ese marco me pongo como meta conseguir un mínimo de algo mas de 370 y un máximo de algo mas de 500 contactos durante las horas de operación. Estimo que el ritmo de multiplicadores será tal que una de cada cinco estaciones lo será; de darse esto y con la mezcla mas o menos habitual de estaciones del mismo continente y otros continentes aspiro a conseguir en el entorno de 140K a 250K puntos durante la participación.
En lo técnico planeo utilizar la configuración SO2R compuesta por el FT840 como rig1 y el FT890 como rig2, todavía estoy considerando contar con el FT100 como rig3 e intentar una configuración SO3R pero aún no me decido sobre si es ventajoso o no hacerlo. El principal cambio es el controlador automático de rotor en el que he estado trabajando últimamente; su puesta a punto me ha consumido bastante y todavía no está completa por lo que quizás lo utilice solo en forma parcial a los efectos de evaluarlo en condiciones competitivas. He escuchado a varias estaciones haciendo preparativos para el concurso, poniendo a punto antenas y hasta preparandose para viajar a formar parte de estaciones Multi (como el equipo de LS1D).
Como siempre, solo cabe esperar que sea una fiesta para todos los que participemos.




sábado, 13 de octubre de 2012

CQ WW SSB 2011 (Certificado)

En un dia lluvioso llegó en el correo el certificado del CQ WW SSB 2011 donde participé en categoría SO SB(A)/10M QRP y obtuve el 2do puesto World (1ro South America, nuevo record continental).
El primero fue Francesco (I0UZF). Experiencia interesante bajo condiciones de propagación excepcionales. Con el primer puesto World en la misma categoría pero de CW en el 2010 es la segunda vez que tengo un logro significativo en este concurso.
Curiosamente el sistema de pesaje de puntos bajo el criterio de clasificación WRTC 2014 asigna un porcentaje muy menguado a este resultado pues lo compara contra la categoría SO AB LP, lo que es excesivamente sesgado, y por lo tanto obtuve magros 99 puntos con esta participación cuando de haber tenido una performance similar en SO AB QRP hubiera con el mismo puntaje obtenido en el entorno de 800 puntos. Debido a ese sesgo, y consistente con la estrategia de participación que vengo teniendo, participaré este año en SO AB QRP. Mas allá de los puntajes lo considero un logro importante y un muy buen recuerdo.

viernes, 12 de octubre de 2012

HK0NA en el correo!

En el último envio de mi QSL Manager (Pedro, EA5GL) llegó la tarjeta de la DX-pedition a Malpelo Is. (HK0NA).
Interesante recuerdo de una interesante experiencia. Muy bonita QSL por cierto.

miércoles, 10 de octubre de 2012

Control de Rotor de LU7HZ (firmware)

Aprovechando el fin de semana largo provocado por el "puente" del feriado del 12 de Octubre, que en el peculiar calendario argentino de feriados se celebra el Lunes 8 de Octubre, pude progresar en completar la construcción del prototipo de hardware asi como la finalización y la depuración del firmware.
El hardware está documentado en una entrada anterior y no ha tenido variantes significativas con la excepción de remover el capacitor de desacople en pin 4 (GP3) del PIC 12F675 que probó generar mas problemas que los que solucionaba. Por ahora la versión prototipo sigue teniendo un potenciometro para simular la señal de realimentación de posición del rotor.
El firmware, tal como lo había anticipado, fue construido en mikro Pascal PRO for PIC usando el excelente ambiente provisto por Mikroelectrónica. Este software en su versión FREE permite desarrollar código de hasta 1K de extensión, lo que es ideal para el PIC 12F675 que no tiene mas que eso.
Tal como de alguna manera ya anticipaba la combinación de un hardware muy básico con una aplicación relativamente compleja para los recursos disponibles resultó un desafío interesante y entretenido. En primer lugar hice un pequeño software de diagnóstico que me permitiera poner a punto la configuración del PIC, las rutinas de entrada/salida serie y los puertos digitales/analógicos configurados. Esto parece a priori como un trabajo redundante porque ese pequeño programa (que llamé hztest.mpas) se deja de lado para el programa final. Sin embargo ahorra tiempo en forma invaluable al permitir concentrarse en configurar correctamente las opciones y registros del PIC 12F675, luego testear los cableados eléctricos y finalmente poner a punto tanto la recepción como la transmisión serie. Una opción interesante pare este propósito es poder emitir letras "U" (así mayúsculas) puesto que en ASCII mas con un bit de arranque y uno de parada dan un tren de pulsos regulares que permite medir con bastante precisión el ancho usando un osciloscopio y por lo tanto ir calibrando los retardos para dar con la velocidad justa. La conversión de niveles de tensión RS232 a TTL se resuelve muy económica y simplemente con el MAX232 el cual confirma que es la mejor opción para este tipo de diseños.
El segundo paso fue avanzar sobre el corazón de la lógica del programa principal, pero utilizando directivas de compilación condicional ({$DEFINE},{$IFDEF/$ENDIF}) para agregar o separar pedazos de código.
Es importante utilizar estos recursos en lugar del mucho mas crudo recurso de "comentar" partes del programa que uno quiere incluir o excluir, la experiencia me dice que esa es una mala práctica con la que inevitablemente comentamos algo de mas o de menos, o peor aun, borramos algo que no debemos con lo que se generan "bugs" de muy dificil seguimiento.
Con este recurso anulé todas las partes relativas a I/O tanto digital como serie o analógico para que las rutinas respectivas no estuvieran esperando un input que no ocurriría (todavía) y los retardos no fueran tediosos de seguir (apretar 100 veces una tecla para recorrer un loop de retardo, por ejemplo). Con esta salvedad ejecuté el programa en el ambiente de simulación provisto por el compilador con lo que pude depurar la lógica de mas alto nivel de procesamiento de comandos, lectura de sensores y control de rotación.
El tercer paso fue probar el programa ya compilado completo con un terminal ASCII (una versión provista por el compilador mismo) hasta despulgar tanto la recepción como emisión por el puerto serie y luego la lógica básica del control.
Para ayudarme en este paso inclui en el programa un modo especial de "diagnóstico" que se activa si cuando el micro se prende descubre que está apretado el pulsador en GP4 (que posteriormente se utilizará para establecer el acimut semi-automático). En este modo de diagnóstico el programa emite alguna información adicional que ayuda para saber si el funcionamiento es correcto.
Aqui me enfrenté con el primer problema realmente serio, tal como está implementada la rutina serie es "half-duplex", es decir no puede recibir y transmitir a la vez. Esto ocurre porque los "bits" durante la recepción o la transmisión son controlados mediante retardos de software muy precisos, pero que mientras el procesador los controla no puede hacer otra cosa; es decir, si está controlando la duración de un bit parte de la transmisión de un caracter no está leyendo el pin de entrada para ver si está comenzando la recepción de otro (y viceversa). Y la recepción de comandos por momentos era buena y por momentos dejaba de serlo. Finalmente fui depurando los retardos para que el funcionamiento fuera consistentemente correcto; para mi sorpresa la lógica básica de funcionamiento "semi-automático" funcionó bien rápido y el controlador actuaba correctamente prendiendo el pin correspondiente al actuador correcto para ir en la dirección de giro que se suponía que tenía que ir y deteniendose cuando la posición del rotor (simulado) marcaba lo pedido.
Por último conecté el controlador con el programa N1MMRotor.exe de la suite del N1MM, por gentileza deTom Wagner (N1MM) especialmente para esta prueba contaba con el código fuente de este programa y por lo tanto sabía exactamente que enviaría y que esperaría recibir en cada momento, lo que facilitó enórmemente el proceso de depuración. Proceso que resultó mas lento y engorroso que lo que hubiera esperado por pruebas previas puesto que el programa utiliza el puerto serie con solo un bit de stop (había escrito el firmware para poder realizar el procesamiento durante los dos bits de stop); lamentablemente el programa no tiene como opción configurar esto; y esto restringía enormemente los recursos disponibles en el procesador. Este programa N1MMRotor ordena al controlador que tiene que hacer y obtiene información de estado por medio del protocolo Hy-Gain DCU-1 (en realidad una variante mas moderna implementada en el rotor EZ-Rotor).
Al principio nada andaba. Siguiendo con el osciloscopio las señales (curiosa la combinación de mundos en este tipo de diseño...) pude verificar que los comandos efectivamente llegaban a la pata 4 del PIC (GP3) con la polaridad y tiempos correctos pero nada salia de la pata 2 (GP5) en respuesta. Es decir el firmware no estaba entendiendo que lo que recibía fueran comandos válidos, y por lo tanto no generaba respuestas. En particular al comando "AI1;" al cual el controlador debería contestar con "nnn;" donde "nnn" es el acimut en grados. Multiples pruebas despues llegué a la conclusión que el problema era de timing por lo que con ajustes progresivos a las rutinas respectivas primero consegui que funcionaran los comandos básicos (tales como AI1; o AM1;) con lo que pude verificar que cuando el comando era comprendido y se producía una respuesta esta era correctamente tomada e interpretada por el programa N1MMRotor. El problema remanente fue con "AP1nnn;" que es el comando para establecer una dirección de destino; distintos problemas en la lógica de interpretar ese comando, por ser mas largo y por tener que convertir desde la representación en ASCII del número a un número que pudiera manipularse matemáticamente requirieron iteraciones adicionales.
El problema básico es lo muy al límite que se encuentran los recursos del procesador (pero sin que esto sea una queja, despues de todo es la fuente de diversión). El N1MMRotor envia en forma continua "AP1xxx;AM1;", esto es establece la dirección de destino y dispara el movimiento. Lo hace además son solo un bit de parada entre ambos comandos (200 microsegundos a 4800 bps), es un tiempo relativamente corto para hacer todo el procesamiento, en especial cuando la lógica original del puerto serie esperaba medio bit para asegurar que estaba el stop bit como corresponde, dejando solo algo menos de 100 microsegundos de margen. Esto es poco toda vez que eso equivale a un poco mas de 50 instrucciones de máquina, y esto es mas o menos lo que toma la lógica de procesar los comandos, controlar los sensores y vigilar la rotación. 
Finalmente, ajustando los retardos y optimizando el código pude acomodar que tuviera margen para procesar. Afortunadamente ninguno de los dos comandos requiere respuesta. Por otra parte si el N1MMRotor enviara un pedido de acimut en forma inmediatamente anterior a estos comandos probablemente ahi si van a existir conflictos porque estaría enviando la respuesta cuando le llega el nuevo comando; confío que en la práctica eso será un escenario poco frecuente y que no complicara el uso real del controlador.
En el estado actual el firmware está implementado en el programa HZRotor  (con su versión en hex Intel HZRotor). El programa ha superado las primeras pruebas y anda razonablemente bien, resta aún someterlo a pruebas mas rigurosas y al "bautismo de fuego" de efectivamente utilizarlo en el aire, y si mostrara signos de solidez incluso durante el CQ WW que se aproxima. Tiene aún una tendencia a ignorar los comandos de cambio de dirección, los que en oportunidades tienen que emitirse mas de una vez, sospecho del mismo problema de atiempamiento que al comienzo impedía recibir todos los comandos, solo que mas mitigado.
Seguramente haré las pruebas en un clásico estilo "araña" sobre el controlador de rotor actual (manual) aunque el destino final es construir un controlador totalmente nuevo con esta plataforma.

domingo, 7 de octubre de 2012

Control de Rotor de LU7HZ (bocetos)

 He podido empezar la construcción de los primeros prototipos para el controlador automático de rotor de antena. No he recibido aún la tarjeta Arduino Ethernet Shield que me permita utilizar la placa Arduino One como controladora.
Me decidí entonces luego de algunos experimentos de rutinas aisladas en   MikroPascal Pro en hacerlo utilizando un PIC 12F675 como controlador.
Aun no he podido hacer andar la parte del programa que implementa el puerto serie por software (este PIC no tiene un UART incorporado).
Sin embargo, la totalidad del programa ya está escrito por lo que tengo una razonable confianza que entrará en la memoria flash de 1K y las pocas docenas de bytes de memoria RAM.
Es claro que sin lujos, al finalizar el programa que termina siendo implementado en un hibrido entre Pascal y Assembler ocupa algo mas de 980 bytes (algunas docenas de bytes menos que el máximo posible).
La interfaz de hardware es simple, el procesador tiene 6 puertos de entrada y salida; dos lineas se usan como salida para controlar al rotor (giro en sentido horario y anti-horario), dos para entrada-salida serie, una para sensar la posición del rotor y otra para comandar el modo automático. El comando de modo automático conmuta si se sensa la posición del rotor mismo o de la referencia guía (para ajuste semiautomático). El software sensa si este comando está alto o bajo para decidir si la lectura corresponde al rotor o a la referencia local. Si estos son diferentes dentro de un margen del +/- 5% se activa el rotor en el sentido que corresponda y se procede automáticamente a girarlo hasta que la posición del rotor iguale a la referencia. Es curioso como un diseño embebido difiere de un programa convencional, durante algun tiempo tuve dificultades en lograr que el programa funcionara correctamente en su función semiautomática; en el emulador lo hacía correctamente pero en el hardware real no. Terminó siendo que se detectaba que el switch de comando pasaba a alto e inmediatamente se leia la posición de acimuth.... cuando aún el relay no había conmutado (situación que solo podría durar algunos pocos microsegundos...), bastó un pequeño retardo para que todo funcionara correctamente; pero muestra como técnica de programación la necesidad de siempre ver la "pelicula" en este tipo de software (imaginar la secuencia de tiempos mas que la lógica en si).
Se utiliza un integrado MAX232 como conversor TTL/RS232 para el puerto serie, es una solución económica y efectiva para convertir los niveles correspondientes. Todo el manejo de control se hace con relays para que el contacto se independice de las tensiones presentes, pero con el rotor en particular que tengo (Walmar) las tensiones son menores a 30V cc por lo que podría perfectamente utilizarse  un transistor con ese propósito. Para independizarme del rotor fisico durante las pruebas agregué un potenciometro adicional para simular al del rotor mismo y poder hacer pruebas locales, este "volará" cuando empiece con las pruebas en el rotor real.
El diseño todavia puede cambiar en la medida que finalice el firmware, en particular el puerto serie. El puerto serie es necesario para poder comandar el controlador usando el protocolo Hy-Gain DCU-1. Hasta ahora estoy intentando con un microcódigo que implementa un puerto half-duplex (no puede recibir y transmitir al mismo tiempo) el que creo es suficiente para este propósito; en caso que la validación del diseño muestre que no es asi el implementar un puerto serie full duplex por software es un poco mas complicado y tengo mis dudas que logre meterlo en el PIC 12F675 (si solo estuvera el puerto serie por supuesto que entraría, solo que también tienen que entrar las otras funciones del controlador). En ese caso tendría que ver como utilizar otro PIC (quizás el PIC 16F877 o similar), o directamente esperar la placa que me falta para hacerlo con la Arduino One.

sábado, 6 de octubre de 2012

Compilador Pascal para PIC de mikroE

Para explorar la posibilidad de implementar un rotor automático de antena basado solamente en el controlador PIC 12F675 estuve explorando posibles herramientas.
Por supuesto que se puede hacer en assembler, el MPLAB asm provisto por Microchip es gratuito y muy potente; de hecho todos mis proyectos al presente los he hecho en ese lenguaje.
Pero el controlador de rotor tiene la particularidad de tener algunos requerimientos diferentes a los proyectos anteriores.
Por un lado en el 12F675 hay que implementar un controlador serie por software puesto que el chip no tiene una UART.
En segundo lugar en el programa hay que implementar un procesador de comandos, de estructura simple pero aún asi requiriendo cierta capacidad de manipulación de caracteres. Finalmente se requiere alguna matemática diferente de sumas y restas, en particular la capacidad de multiplicar y dividir enteros de 16 bits para poder manipular las conversiones de acimut a las escalas de lectura de los sensores.
La opción mas lógica es recurrir al compilador C también provisto por Microchip, opción que utilicé en alguna ocasión sin que me termine de convencer; porque no soy un fan de C y porque el código que genera en assembler no me luce demasiado eficiente. Esto último es un defecto propio de "assemblero", siempre uno puede programar mas eficiente en assembler que un compilador.
Había tenido cierta exposición a la excelente gama de compiladores ofrecidos por Mikroelectrónica para una lista bastante apreciable de plataformas embebidas, y entre ella los PIC de Microchip, por lo que decidí explorarlo para este propósito con mas detenimiento. Para cada plataforma se ofrece un compilador BASIC, uno C y uno Pascal. En particular el de Pascal (mikroPascal PRO) para PIC me llamó la atención, mi debilidad por ese lenguaje data de varias décadas y es por lejos el que mas a gusto me siento. Desafortunadamente los buenos compiladores Pascal para la plataforma Windows son escasos y su uso ha decaido en creación de software profesional en favor de lenguajes con otras caracteristicas como Java o C++.
Aun asi, esta implementación me resultó atractiva tanto por la riqueza del IDE (ambiente de desarrollo), la enorme cantidad de librerías de soporte tanto de dispositivos como de algoritmos y el extenso soporte al proceso de debug del software.
Rápidamente estuve en condiciones de comprender las particularidades del ambiente (como configurar el PIC target básicamente), encontrando que tiene una integración muy natural con assembler pudiendose escribir con facilidad largos segmentos de assembler "inline" pero referenciando a las mismas variables y procedimientos utilizados también por Pascal. Se puede, mediante directivas de compilación, tener un gran control de la utilización de memoria y tiene un soporte muy natural para las interrupciones.
Entonces es relativamente facil escribir el código que realmente necesita ser eficiente en assembler al mismo tiempo que el que depende de librerías (matemática, manejo de cadenas, etc) en Pascal pudiendo crear programas bastante complejos en la exigua plataforma de solo 1K de memoria flash del 12F675.
Si bien el compilador cuesta USD 199.-, lo que para este tipo de herramientas no es un disparate, me encontré con el bonus que la versión free tiene la totalidad de las bibliotecas y funciones y la única limitación es que no puede generar código de mas de 1K de longitud; no es un problema ciertamente significativo para la plataforma 12F675 que tiene, justamente, solo 1K de memoria (!!!). Por supuesto que se puede usar para cualquier otro PIC, pero el limite de memoria puede crear problemas en los chips de mayor capacidad.
Respecto al controlador de rotor de antena, sigo trabajando en el y compartiré su diseño cuando logre hacerlo andar, para lo que falta aún algún tiempo.

jueves, 4 de octubre de 2012

Picloops al rescate!

Es bastante común cuando se programa en general, y cuando se programa con microcontroladores como el PIC12F675 en particular, tener que establecer una base de tiempo con bastante precisión.
La forma mas precisa de hacerlo es por medio de alguno de los dos timers disponibles (T0 o T1) implementando un manejador de interrupción (interrupt handler) que satisfaga el requerimiento de interrupción (interrupt service request, isr).
Sin embargo, la implementación de un manejador de interrupciones tiene sus complicaciones y puede estar "contaminado" por interacciones con otras partes del programa.
Otra alternativa es establecer un retardo por software; si además se enmascaran las interrupciones (crlf INTCON) el retardo puede ser bastante preciso, aún con el clock interno del PIC.
En efecto, cada instrucción simple (excepto algunos saltos) consume 4 ciclos de reloj, y el reloj opera en estas condiciones a 4 MHz, es decir cada instrucción toma 1 uSeg en ejecutarse.
Un loop simple como
            .....
            movlw    100
            movf      cnt,1
loop     decfsz    cnt,1
            goto       loop
           ....

Demorará una cantidad fija de ciclos de CPU por cada iteración mas algun retardo de comienzo y de fin. Por lo tanto variando la cantidad de veces que se itera se puede demorar distintos tiempos; esta configuración de código sirve para demorar entre unos pocos microsegundos y algo menos de 200 milisegundos.
Para implementar puertos serie por software se necesitan retardos para el muestreo entre bits sucesivos del orden de 200 microsegundos para 4800 bps, por lo que resulta mas que adecuado.
Pero siempre puedo "apilar" contadores si quiero demorar mas, por ejemplo si quisiera demorar 1 segundo haría


movlw 6
movwf DelayC
movlw 19
movwf DelayB
movlw 173
movwf delayA
loop decfsz delayA,1
goto loop
decfsz DelayB,1
goto loop
decfsz DelayC,1
goto loop
retlw 0


Donde los contadores DelayA,DelayB y DelayC operan en cascada para multiplicar el lazo básico, el máximo que puedo alcanzar con tres contadores es de algo mas de 3 horas de retardo (nada impide que coloque mas contadores en cascada).
El programa PicLoops es útil a la hora de calcular este tipo de timers de precisión. Dado que la arquitectura de las instrucciones es similar en las distintas familias de controladores Microchip (PIC) bastará adecuar el reloj con el que opera el circuito para obtener la calibración correcta.

Buscar este blog

Vistas de página en total