domingo, 23 de septiembre de 2012

El blog consiguió el DXCC también!!

Cuando puse en marcha el blog lo hice con el espíritu de abrir mi cuaderno de apuntes sobre temas de la radio en general y proyectos en distinto estado de digestión en particular.
En general no escribo para una audiencia en particular, sino que lo hago como lo haría realmente en mi libreta de apuntes con la esperanza que, además, le sea de utilidad a alguien mas. Es como cuando en el colegio prestaba o me prestaban los apuntes de las clases. Me encuentro con frecuencia utilizandolo realmente como mi libreta de apuntes recuperando alguna información que documenté aqui, largamente olvidada pero necesaria para alguna cosa que tengo que hacer.
Recibo con frecuencia comentarios de muy buena onda, con increiblemente pocas excepciones, que comentan en tono positivo lo que comparto aqui. Y es realmente ese el espíritu que quiero preservar, despues de todo si alguien no le gusta, le resulta aburrido lo que comparto o no está de acuerdo siempre puede muy simple y eficazmente solucionar el problema no leyendome.
Leyendo casualmente las estadísticas de acceso encuentro con cierta curiosidad que el blog ha tenido desde su "fundación" algo mas de 90000 "hits" o lecturas únicas (excluidas las mias). Eso implica que lo leen un poco mas de 80 personas todos los dias en promedio; en realidad hago entre 5 y 12 entradas por mes lo que significa que cada entrada la leen en promedio mas de 300 personas, lo que de por si me resulta sorprendente. Mas sorprendente aun me resulta que lo hagan con cierta frecuencia desde una veintena de paises y con menor frecuencia desde algo asi como cincuenta paises. En total han leido el blog desde 110 paises a la fecha, algunos francamente poco plausibles excepto algún error, pero paises al fin!
Por eso que creo que el blog consiguió, despues de todo, el DXCC también. Notese, que me llevó alcanzarlo mas o menos lo mismo que me llevó obtener su contrapartida en radio bajo el sistema eQSL (!!!).
En realidad no es muy realista considerar que tengo un lector en un pais cuando tuve uno o dos hits en tres años, es mas plausible un hit por error o incluso algún hit por temas no relacionados con la radio (hay muchos hits en notas sobre la independencia de Argentina, algun comentario sobre Malvinas o entradas de algun tema totalmente desconectado). A pesar que mis entradas son consistentemente en español hay lecturas desde muchos lugares donde es improbable que hablen mucho español (¿latinos en el exilio quizás?).
Aun asi, las mismas estadísticas me dicen que los artículos técnicos son los que si atraen a los "habitués" y en mas de la mitad de los casos no llegando por navegación desde otro sitio sino accediendo directamente (¿lo tendrán en los favoritos?).
El blog va mutando sus temas centrales según van mutando mis intereses, dependiendo el momento tengo mas inclinación a dedicar tiempo a temas técnicos (QRPp, SDR, Antenas) o mas "blandos" (concursos, software, operación movil,  ideas conceptuales y otros). Lo unico que me he preocupado es no alejarme demasiado del eje de la radio desde una perspectiva amateur y que sea todo lo que materialmente me sea posible en español.
Cada vez que alguien me comenta que le ha sido util en algun momento para algún propósito de alguna manera justifica el esfuerzo.

sábado, 22 de septiembre de 2012

El Arduino One en LU7HZ

Hace algún tiempo había adquirido una placa Arduino One para investigar las posibilidades de la plataforma. Para mi estas placas ocupan un terreno interesante que no había explorado demasiado en sus aplicaciones de radio aunque si en otros ámbitos donde me han sorprendido gratamente por su simpleza y versatilidad.
Un poco el enfoque que había tomado hasta ahora había sido que las funciones de control mas simples las encaraba con un microcontrolador PIC simple (preferentemente un 12F675) y las mas complicadas con un computador embebido como el NS-K330 (y quizás, algún dia cercano la  revolucionaria Raspberry Pi  la que hasta ahora solo he trabajado en una virtualización en PC).
Pero hay un número importante de proyectos para el cual un microcontrolador "no llega" y un procesador embebido "le queda grande". Y para experimentar en ese espacio fue que adquirí mi Arduino, eligiendo entre los muchos modelos posibles el denominado "Uno" que es uno de los mas económicos.
Al mismo tiempo Arduino es mas que la placa en si, es mas adecuado verlo como un "ecosistema" tecnológico alrededor de la placa, el que viene completo con herramientas de desarrollo y una muy importante base de librerias y aplicaciones hechas por otros entusiastas, mayormente bajo un marco de software libre.
La placa en si viene con una abundante capacidad de interconexión tanto en la forma de E/S (entrada/salida) digital, comunicación serie (niveles TTL) y entradas analógicas. También tiene un puerto USB para conexión con la PC (desde donde toma la alimentación durante el desarrollo) y alimentación independiente de +5V.
La programación se hace en un lenguaje muy similar a C que tiene una serie de primitivas para manipular los distintos recursos de E/S. Curiosamente funciona en un paradigma de procesamiento que hacía rato que no había visto; una sección del código denominada "setup()" se encarga de todas las incializaciones necesarias al comenzar la ejecución al encender el dispositivo y otro segmento de código denominado "loop()" ejecuta en forma iterativa cualquiera sea el código que se le defina. Este esquema de "armonizarse" con un ciclo pre-impuesto por el programa era el corazón de un engendro de lenguaje de programación llamado "RPG II" que tuve la dudosa fortuna de haber tenido que emplear hace ya muchos años atrás.
En realidad todos los microcontroladores operan en un loop infinito cuya ejecución vá cambiando en función de eventos o interrupciones, asi que no es un modelo necesariamente descabellado de aplicarse en este caso.
Con el agregado de una placa especial llamada "escudo Ethernet" (Ethernet shield), que aún no tengo, se le pueden agregar librerias que implementan un sistema TCP/IP básico sobre Ethernet; aunque hay formas de agregarle librerías muy rudimentarias TCP/IP solo sobre el puerto serie (lo que vendría a ser un uso bastante avanzado).
Aparte de "jugar" un poco con distintos programas simples como para familiarizarme con las distintas librerias he venido considerando en que proyecto podría darle un buen uso, y por supuesto que salen muchas alternativas.
La que me he decidido es hacer un controlador de rotor de antena "inteligente". Hoy tengo un rotor totalmente manual (ver entrada aqui) pero hace tiempo que vengo considerando implementar algo mas sofisticado. Esto conduce a que tenga varios "modos" de operación.
Debería tener un modo "manual" como hoy, es decir una palanca para girar en un sentido u otro y algún indicador de la dirección que tiene la antena, creo que este modo es siempre necesario para ajustes finos.
Me gustaría agregarle un modo "semi-automático" (o, si se prefiere, semi-manual) donde se le indique, quizás con un dial, que apunte en una dirección y el rotor vaya "solo" a esa dirección. Eso sin duda es util cuando en concurso uno pasa de 10M a 20M y tiene que cambiar casi 180 grados la dirección de la antena o cuando se quiere explorar si viene por paso largo o corto, o simplemente cuando se quiere apuntar a una zona muy diferente del globo. Hoy esto significa varios minutos con la palanca presionada y vigilando que llegue a la dirección correcta lo que quita manos y ojos que en el medio de un concurso no sobran.
Hasta aqui es un proyecto dentro del alcance de un PIC 12F675, y uno relativamente simple.
Pero también para completar la integración de la estación de concursos quisiera agregarle un modo "automático" donde el acimut de la antena se establezca desde un software de control, podría ser el N1MM o incluso alguno de los programas de seguimiento de satélites.
No es un uso terriblemente novedoso puesto que hay muchos controladores comerciales que hacen esta función, y algún que otro proyecto casero también.
Este grado de automatización abre además las puertas a un enorme campo de experimentación con distintos paquetes de software (DXAtlas por ejemplo) para apuntar la antena basado en un mapa. Hay distintos protocolos para esta comunicación, aunque el denominado DCU-1 es probablemente el mas difundido. Este protocolo requiere una conexión serie entre la PC donde corre el programa "controlante" y el "rotor". Implementar una conexión serie ya levanta en un "escalón" las prestaciones necesarias del procesador, y se empieza a complicar usar un PIC 12F675 que no tiene puerto serie. Siempre se puede hacer un puerto serie totalmente por software si fuera necesario, pero probablemente se "comería" el grueso de los recursos del procesador (que son bien limitados).
Probablemente la mayoría de los procesadores de la familia PIC 16Fxxx podrían servir pues tienen soporte para puerto serie incorporado (además de todos los otros recursos del PIC 12F675).
Es necesario admitir que una placa Arduino es mucho para este proyecto, pero no lo es con el agregado de un modo adicional "remoto" donde quiero poder acceder el controlador de rotor mediante TCP/IP, posiblemente con una interfaz Telnet o incluso Web, para su control. Esto habilitaría una enorme cantidad de experimentos sin la atadura del relativamente obsoleto protocolo serie, además de habilitar controlar la antena en forma remota, muy en linea con otras caracteristicas de mi estación que permiten ser usadas también en forma remota.
Por ahora es un proyecto en la libreta de apuntes, pero ciertamente cercano a comenzar a implementarlo porque las ideas y los materiales están empezando a alinearse para hacerlo realidad.
A menudo se reflexiona sobre la utilidad de tener semejante capacidad de conectividad en todos los dispositivos, se ironiza en los foros sobre tener un Linux embebido corriendo en una tostadora, pero si bien hay limites donde se roza el ridiculo tambien es cierto que mientras se pueda hacer y sea divertido hacerlo uno debe preguntarse...¿porque no?.

jueves, 20 de septiembre de 2012

El WISPY-10 de G3XBM

Hay un diseño muy interesante que vengo siguiendo en el blog de Roger (G3XBM) relacionado con un transceiver para el modo WSPR para la banda de 10 metros que el ha llamado WISPY-10.
Hay un número de elementos interesantes en este diseño QRPp (200 mW) que me gustaría resaltar.
El primero es el lento pero consistente progreso del modo WSPR , sobre todo en el hemisferio norte. Cuando se pronuncia con fonética inglesa suena muy parecido a "whisper" (murmullo) y tiene toda la pinta de haber recibido lo que se llama un "retrofit" del nombre para significar el acrónimo de "weak signal propagation reporter" (reporte de propagación de bajas señales), inventado originalmente por Joe Taylor (K1JT) y ahora parte de un esfuerzo cooperativo de software libre (open source); Joe incidentalmente es un radioaficionado vastamente mas conocido por el hecho de ser premio Nobel de fisica por sus trabajos en el campo de la astrofísica, donde claramente amasó su vastos conocimientos en procesamiento de señales débiles.
Esto solo justificaría una entrada para discutirse, el enorme potencial de la radio para testear ideas revolucionarias que se encuentran en la frontera de la ciencia; cada vez que escucho que la radio no puede competir con Internet me preocupa la miopía del concepto. Internet es una herramienta la radio es una manifestación de la pasión por experimentar, son cosas diferentes.
WSPR como método requiere algo mas que esta entrada (donde quiero remarcar varias cosas) para describirse, pero la idea general es que se transfieren mensajes de una cantidad de bits pequeña (50 bits), a muy baja velocidad (algo menos de 2 bauds, comparar con PSK31 que transmite a 30 bauds). Debido a la baja cantidad de información y la baja velocidad el ancho de banda que ocupa es muy pequeño, 6 Hz (comparar con los 50 Hz de PSK o los casi 100 Hz de CW en alta velocidad).
Debido a estos factores una señal que está hasta -28 dB por debajo del nivel de ruido en un canal de fonía (algo menos en uno de CW o PSK) puede ser tomado!!! Esto es una señal extremadamente baja, increiblemente baja.
¿Que tan baja?....
Si en 10 metros una estación con 100W en SSB es escuchada en un punto del planeta con un S7 (nada extraordinario, por cierto) y el piso de ruido estuviera en ese momento en S3 (una tarde muy golpeada por el ruido en 10 metros, por cierto) podría llegar a nivel del ruido con una señal 24 dBm menos, o sea con un clásico diseño QRPp de alrededor de 500 mW. Una señal WSPR con 28 dB aún menor, algo mas de 0.5 mW o 500 microWats podría ser tomado sobre ese mismo path. Todo esto es teórico y seguramente se necesita un poco mas de potencia en circunstancias habituales para compensar por el fading, ruido pulsante e interferencias en la banda. Pero muestra una idea del potencial de este modo y las potencias ridículamente bajas en juego.
Es claro que no es un modo para intercambiar información en volumen; aún transmitiendo continuamente el texto de esta nota hasta ahora (unos 500 bytes) tardaría algo menos de 10 minutos en transmitirse; por cierto mejor que nada cuando no hay otras formas de comunicar, pero ciertamente no su principal propósito. Un QSO típico lleva señal distintiva, grid locator y potencia relativa recibida comprimidos en los 50 bits del mensaje y tarda algo mas de 5 segundos en pasarse. Por eso un QSO puede formalizarse en algo menos de 10 segundos (para los puristas, este intercambio es un QSO pues se intercambia distintiva y reporte de señal!!!) lo que es algo mas eficiente que un típico QSO de pileup bien manejado.
En realidad el estilo de comunicación es un poco diferente al convencional, uno comunica al mismo tiempo con todos (!!). Los contactos se "confirman" registrando a quienes se escuchan en un data base central llamado WSPR net.
Mas que un modo de comunicarse es una herramienta formidable para experimentar en el fascinante campo de las señales muy débiles. Primer punto interesante del proyecto, el modo.
El segundo punto interesante que quiero remarcar es la tendencia de como WSPR habilita toda una gama de diseños muy simples pero que aun así no son versiones de baja prestación de equipos mas grandes. En realidad la concepción general es que a medida que se simplifican los diseños, especialmente en el campo de diseños QRPp, se obtienen circuitos muy entretenidos de armar pero con los que rara vez se hace mas que un contacto de prueba antes de "archivarlo". Es decir los equipos QRPp mas simples no se "usan" para comunicar constantemente. En mi experiencia si se usan, mas de una vez he viajado con un Pixie, y hasta hecho algún comunicado en el exterior con el. Pero es cierto que se necesitan condiciones especiales de propagación, antenas en o sobre la media y ciertas habilidades operativas para utilizar mas o menos consistentemente un QRPp y es dificil que se dé la suma de condiciones. Si bien no he progresado demasiado en la implementación de un prototipo creo que las tecnologías alrededor de diseños basados en SDR tienen el potencial de permitir equipos de baja complejidad con razonables prestaciones, al menos superiores a los de los clásicos equipos cristaleros de CW. Aun así es debatible, y con razón, la practicidad de un diseño de SSB de 100 o 200 mW PeP de potencia. El diseño de George es extremadamente simple, solo un poco mas complejo que un diseño clásico simple QRPp y aún asi entrega 200 mW de una señal DSB (doble banda lateral) por lo que equivale a una señal de 100 mW en SSB.
Los diseños DSB sufren, creo que injustamente, de mala fama; o al menos de una consideración menor que sus contrapartes de SSB. Tienen por sobre estos una mayor simplicidad inherente.
En el caso de modos muy angostos, como el WSPR (o incluso el PSK31, o porque no, incluso el CW) el principal problema de los diseños DSB que es la señal "imagen" (la banda lateral no eliminada) no es un problema. Es simplemente filtrada, no ya por el transmisor, sino por el receptor por lo que en la práctica no molesta.
Se puede arguir que la señal de la "otra" banda lateral es una interferencia indeseada; pero realmente hay que abordar esa cuestión con sentido común. Un equipo de 100W si emite una banda lateral o una portadora suprimida en 30 dB es técnicamente correcta, eso significa que se tolera que un equipo cualquiera esté emitiendo una señal "espurea" de 100 mW. Estos equipos QRPp emiten una banda lateral indeseada de alrededor de 100 mW o menos también. ¿Cual es la diferencia?
Siguiendo los artículos del blog se vé que tanto George como algunos comentarios sugieren que este mismo diseño y casi sin modificaciones (otra que de frecuencia) son perfectamente adaptables a PSK31 como equipo dedicado, quizás la estación de field day "perfecta" de PSK31?
Uno llega a proponer algunas mejoras menores para transformarlo en un transceiver SSB por rotación de fase basado en SDR.
... Creo que voy a tener que darle alguna prioridad a mi viejo proyecto del Pixie SSB porque se viene acercando la muchachada.....
Segundo punto interesante, el diseño muy compacto y accesible. Ideal para experimentar.
Hay un tercer punto que a mi me atrae y que no es en realidad abordado por George como uno de sus objetivos. El código de WSPR está planteado como software libre y puede ser aplicado a casi cualquier versión de Linux.
Esto significa que con algunas modificaciones menores es una plataforma que se puede desplegar en sistemas embebidos de cualquier tamaño; lo que los hace ideales para experimentar en balizas y experimentos embarcados varios. Esto además permite abordar algunos comentarios que un proyecto QRPp que necesita una PC atrás (que consume entre 200 y 600W de potencia) no es tan QRPp que digamos.
Como además trabaja en conjunto con Internet puede transformarse en una aplicación de HSMM/Hinternet o al menos aplicar los mismos conceptos.
Es decir, resumiendo, que este proyecto resume un modo interesante, un diseño QRPp interesante y una aplicación interesante de radio. Todo en uno, y por el mismo precio.

martes, 18 de septiembre de 2012

PNAMBIC: A las 4am el ayudante no trabaja....

En los ambientes de tecnología se utiliza el acrónimo "PNAMBIC" como adjetivo de una situación donde se necesita intervención manual para que un sistema funcione. Usualmente porque el sistema está en construcción o incompleto y en menor medida cuando se trata de algún fraude.
PNAMBIC significa "pay no attention to the man behind the curtain" (no preste atención al hombre atrás de la cortina) en alusión a que hay alguien que está "ayudando" para que las cosas funcionen (y escondido atrás de una cortina tratando de evitar que se note mucho...).
El término no viene de la informática, se acuño en el libro "El mago de Oz" para describir la verdadera naturaleza del (algo fraudulento) mago.
En su acepción fraudulenta ha sido algo usada en el ámbito de inteligencia artificial donde a propósito o por sesgo inadvertido algunos resultados "espectaculares" no siempre fueron conseguido solo por el software sino que tuvieron errr... ayuda externa.
Anécdotas al margen una red requiere de ciertas acciones automáticas, y en particular que los tuneles y ruteos entre LAN no tengan intervención humana; simplemente las redes no serían confiables si necesitaran de alguien para tener que tirar comandos excepto en circunstancias muy especiales.
Para establecer túneles como los descriptos en una entrada anterior establecidos en una conexión SSH brinda sencillez y seguridad. Pero al establecer el tunel la conexión SSH requiere la password, y nada menos que la password de root (la mas privilegiada de las passwords en un sistema Linux). Passwords que no todos se sienten cómodos en estar distribuyendo. Durante un breve tiempo experimental es inevitable tener que confiar a los experimentadores este tipo de privilegios (quien no se sienta cómodo con este tipo de confianza no debería ofrecerse a hacer experimentos en primer lugar, pero no todos conocen lo suficiente como para entender que no hay otra alternativa).
Pero tambien es justo remarcar que fuera de la experimentación no es razonable que para establecer un tunel uno de los "extremos" tenga que abrir totalmente su sistema confiando la password de root.
Insoluble? No en realidad, siempre que apelemos a la criptografía.
La password es solo para atestiguar que la persona que entra en el sistema es quien, en principio, dice ser. El problema es que teniendo la password de root puede entrar al margen del mero propósito de establecer el tunel y con máximo privilegio administrativo hacer lo que quiera en el sistema.
Sin embargo bastaría para todos los efectos prácticos que el sistema sepa que soy "yo" y que el administrador del sistema haya aceptado que para el solo propósito de establecer el tunel "yo" puedo hacerlo como si fuera root, pero no concediendome los privilegios de root para todo el resto de las funciones.
Esto se implementa mediante certificados criptográficos, de tal manera que la parte pública del certificado sea instalada en el server (el que recibe la conexión); el cliente (quien hace la conexión) conserva la parte privada de su certificado. La matemática atrás del proceso de certificados por clave pública/privada es matemáticamente áspero, pero conceptualmente es sencillo. Hay varios algoritmos pero el mas difundido es el denominado RSA (por sus autores Rivest, Shamir, Adleman) que se basa en el factoreo de números primos muy grandes. La fortaleza reside en la longitud de la clave y a todos los efectos prácticos no puede ser descifrado con recursos convencionales.  Solo la persona con la clave privada puede aparear con la clave pública; todo el mundo puede saber esa clave pública pero es inutil sin la parte privada.
Los sistemas de encripción basados en clave pública/privada es una solución tecnológicamente reciente al dilema ancestral de como transportar en forma segura la password con la que un mensaje debe ser "liberado" o "des-encriptado", comprometer esa password implica comprometer el esquema de seguridad entero. La solución es sorprendentemente trivial, no hay que enviar una password que pueda ser comprometida. La solución matemática que lo permite es otra historia.
El proceso de generación de estos certificados es programáticamente sencillo y está descripto en "Buenos Aires Libre" sobre lo cual hay que hacer solo modificaciones menores.
Se utiliza el paquete ssh-keygen que es parte del paquete openssh-keygen, el que al invocarse requiere que se contesten algunas preguntas (lo indicado en rojo no es para ser tipeado sino instrucciones).


# ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): (no tipear nada aqui, aceptar default)
Created directory '/root/.ssh'. 
Enter passphrase (empty for no passphrase): (no tipear nada aqui, aceptar default)
Enter same passphrase again: (enter)
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
84:1c:d8:24:d9:af:65:97:d7:f3:42:83:51:0a:1f:3c root@lu7hz.ampr.org

Como el mensaje lo indica al finalizar quedan en /root/.ssh dos archivos id_rsa (clave privada) y id_rsa.pub (clave pública). Es interesante ver en que consisten, basta hacer cat id_rsa o cat id_rsa.pub para verlo.
El archivo id_rsa tiene que ser guardado en el sistema cliente (el que origina la llamada) en el directorio /root/.ssh y no ser entregado a nadie, de este hecho depende la seguridad de todo el esquema. El archivo id_rsa.pub en cambio debe ser enviado al administrador del sistema que opera como servidor (el "otro extremo" del tunel).
El administrador tiene que "instalarlo" para que sea reconocido, los comandos para hacerlo son (asumiendo que la clave pública quede depositada en /tmp).

cat /tmp/id_rsa.pub >>/root/.ssh/authorized_keys2
chmod 600 /root/.ssh/authorized_keys2


Es importante el ">>" en el primer comando para no destruir certificados previamente instalados.
Si todo anda bien la siguiente vez que el usuario root del extremo cliente active un tunel con el server SSH entrará directamente sin necesidad de proveer una password, y sin comprometer la seguridad de ninguno de los sistemas.
Un ultimo factor que debe ser considerado. Una red HSMM está implementado por aficionados, usualmente poniendo mas buena voluntad y empuje que conocimientos. No ayuda que el tema de criptografía en general es denso, poco intuitivo y pobremente conocido aún en circulos profesionales. Como sea, la mención "encripción" y "radio" en la misma frase usualmente deriva en una negativa a utilizarla porque, efectivamente, reglamentariamente está prohibido transmitir información encriptada por radio. Pero hay que ser cuidadoso y no tomar decisiones sobre procesos que no se entienden; el canal SSH no se establece por radio, al menos no por radio de bandas de aficionado, sino por Internet. El tráfico de circular por la red "radial" lo hace en texto plano y cumple con la reglamentación, cuando se traslada de un extremo del tunel al otro es que está encriptado, pero vuelve a ser texto plano y reglamentariamente correcto una vez que sale de el. Los certificados por otra parte se intercambian por medios que no son radio (correo electrónico por ejemplo) y solo se intercambian dentro del canal SSH.
Con esta tecnología los tuneles pueden ser establecidos en forma automática, cuando los sistemas se levantan o recuperan de una falla y sin necesidad que el "ayudante detrás de la cortina" tenga que intervenir para nada.

lunes, 17 de septiembre de 2012

eDXCC de LU7HZ (... por fin!)

Despues de haber juntado de a uno los paises finalmente conseguí cumplir los requisitos para obtener el eDXCC (DXCC otorgado por eQSL).
Hace muchos años que conseguí el DXCC "convencional", pero hice el experimento de cuanto podía tardar en obtenerlo unicamente por medio de tarjetas electrónicas tanto de LoTW como de eQSL.
Para mi sorpresa obtuve el DXCC otorgado por la ARRL en base a los registros del sistema LoTW en un poco menos de 1 año. Mientras que el mismo logro, obviamente en base a los mismos registros de base, demoró casi 4 años para alcanzar el mismo logro en eQSL. Mi actividad de DX tiene cierto volumen (varios centenares de contactos por mes a algunos pocos miles en meses de mucha actividad), mayormente en CW salpicado con alguna prueba en SSB o PSK, en especial en preparación para concursos.
Y a eso hay que agregarle una actividad de cierta intensidad en concursos; no es raro en concursos internacionales de magnitud hacer entre 50 y 70 paises (o más) durante el transcurso de una sola competencia. Hay registros en los distintos reflectores sobre concursantes que superan en categorias de mas volumen que las que participo yo (QRP).
Con las salvedades de poder tener alguna causa "especial" asociada a la forma que tengo de operar, me resulta curioso ver la diferencia de tiempo entre LoTW y eQSL (4 veces!!!). Eso a mi me resulta directamente relacionado con el grado de adopción, quizás no tanto en número absoluto como en dispersión geográfico.
Para mi las QSL electrónicas son una salida sensata y práctica al tema de los registros de la actividad de radio; sin embargo, mucha gente tiene marcadas y entendibles preferencias por el equivalente "físico" por lo que los sistemas "reales" y "virtuales" seguirán co-existiendo por algún tiempo. Por mi parte encuentro un compromiso conveniente honrar los envios de QSL físicas via un servicio de QSL manager (EA5GL), las que me envian en forma directa (con el correspondiente SASE+IRC segun lo pido en mi página en qrz.com) y el resto 100% confirmado via formatos electrónicos en eQSL y LoTW donde los registros de la actividad (normal, de DX o de concursos) es subida semanalmente.


jueves, 13 de septiembre de 2012

Campeonato Argentino de HF 4ta Fecha (resultados)

Aparecieron los resultados de la 4ta Fecha del Campeonato Argentino de HF, anteultima del calendario.
El resultado fue mas o menos el previsto en CW y PSK, algo peor a lo previsto en SSB.
En conclusión, quedé 2do de Daniel (CX9AU) en CW, 5to lugar por desempate por tiempo también con Daniel (CX9AU) habiendo ganado Carlos (LU1DKD) el modo  y en un muy lejano  puesto 26 en SSB que fue ganado por Martin (LU9DPM); sabía que el resultado en este modo no habia sido bueno pero no suponía que había sido tan malo.
La suma de resultados de los modos me permitió ubicarme en 4to puesto en la clasificación general.
De no ocurrirle una catástrofe Martín (LU9DPM) es inalcanzable en el primero puesto siempre que participe en la fecha. Las posiciones hasta el 5to puesto están mayormente confinadas de no ocurrir algun imponderable entre Daniel (CX9AU), yo, Carlos (LU1DKD) y Diego (LU6FHO). Expectante para ingresar al lote está Juan Carlos (LU1EK). Aun asi no hay una diferencia indescontable por lo que habrá que esperar a la fecha para saber las posiciones finales.
Este sábado se define y se cierra el capítulo 2012 de este torneo; siendo ya la 3ra edición prolijamente montada por sus organizadores. Supongo que al final podré hacer un resumen o retrospectiva de lo que fue este año, pero en lineas generales creo que, aunque hay espacio para ajustes y mejoras, las modificaciones introducidas en este año parecen ser positivas.

miércoles, 12 de septiembre de 2012

HSMM: Tunel IP con OpenSSH

Uno de los temas técnicos a resolver en el despliegue de una red HSMM es como conectar entre si diferentes LAN (Local Area Network) aislados para formar un MAN (Metropolitan Area Network) y estos a su vez agregarlos en un WAN (Wide Area Network).
El despliegue de nodos wireless en frecuencias de 2 a 5 GHz tiene, asumiendo antenas adecuadas, un radio de acción desde algunos centenares de metros hasta algunos pocos kilómetros.
Los nodos pueden desplegarse en configuración de Access Point (AP) y a su vez extender su alcance en configuración Routed Client (Client); pero como en todas las cuestiones técnicas existe un equilibrio, y este consiste en que cada vez que se "estira" un enlace con este mecanismo se reduce el ancho de banda a la mitad. Para conectar LAN que estén ubicados a, digamos, mas de 10 Km es necesario preveer alguna forma de conexión alternativa. Existen muchas posibilidades para rutear tráfico bajo los protocolos TCP/IP, pero la configuración del dominio ampr.org limita las opciones. En efecto, este dominio Amateur Packet Radio (ampr) , tiene la caracteristica técnica que es "no ruteado" o al menos es "generalmente no ruteado". El DNS del dominio se resuelve en un controlador ubicado en ucsd.edu donde también reside el amprgate, todos los requerimientos sobre el dominio ampr.org son ruteados a este gate quien intenta resolverlos a su destino final. Pero por años, y hasta el presente, el gateway impone a los LAN que se le conectan condiciones muy dificiles de satisfacer (IP fija, ruteo de un grupo significativo de nodos, etc) por lo que las redes efectivamente conectadas son muy pocas. Esto está en vias de cambiar para adecuarse a los requerimientos y demandas de la nueva tecnología HSMM pero no lo ha hecho aún.
Debido a ello si uno quiere acceder a mi nodo (lu7hz.ampr.org) verá que el host se resuelve en cualquier máquina conectada a Internet correctamente (probar con "ping lu7hz.ampr.org" y se verá que se intenta alcanzar la dirección IP 44.153.84.14); sin embargo la conexión no se materializa porque la unica forma que lo sería consistiría en que fuera visible al amprgate y no lo está.
Poder establecer un tunel que permita conectar por Internet distintos LAN es entonces una función importante para asegurar la escalabilidad de la red y su conexión.
Hay muchas formas de implementar este tipo de conexión, he estado experimentando con una que se basa en el paquete OpenSSH y por lo tanto está disponible en una cantidad de plataformas muy significativa; entre ellas la plataforma OpenWrt con lo cual es concebible implementar esta arquitectura de conectividad mediante routers embebidos, o sea en el access point wireless mismo. Este esquema lo vi referenciado en el sitio técnico de Buenos Aires Libre aunque en ese caso se utiliza con el propósito de servir para activar enlaces de backup entre nodos.
El esquema muestra como conectar dos LAN remotos, el subnet C 44.153.81.0/24 y el subnet 44.153.84.0/24; cabe destacar que mientras el primero corresponde a un subnet clase C cor.ampr.org definido formalmente como tal el segundo no lo es y solo tengo asignada una dirección en ese subnet (44.153.84.14). Sin embargo es una prueba local para evaluar el concepto que no molestaría a los reales responsables del resto de los nodos de esa subnet (suponiendo que estuvieran activos, que no lo están).
Es importante observar como el tunel se implementa mediante un subnet virtual, el mismo tiene solo asignadas las direcciones de los extremos, para no gastar direcciones IP del espacio de la LAN se pueden utilizar como en este caso direcciones del subnet clase A no ruteable 10.0.0.0 (a modo de convención se utiliza un subnet clase C correspondiente al número IP del LAN que origina la conexión).
Uno de los lados se define arbitrariamente como el cliente (en este caso el 44.153.84.0/24) y el otro como servidor. El primero tiene que tener instalado el paquete openssh-client (con opkg install) y el segundo el paquete openssh-server. En el caso del lado que opera como servidor es necesario reemplazar el servidor sshd default del OpenWrt que es dropbear y no sirve para esta prueba por el provisto por OpenSSH.
Luego de seguir los pasos de instalación tanto del cliente como del servidor de SSH.
Hay que asegurar las siguientes condiciones en el archivo de configuración de sshd (/etc/ssh/sshd_config)

PermitRootLogin yes
PermitTunnel yes
TCPKeepAlive yes
Strictmodes yes
RSAAuthentication yes
PublickeyAuthorization yes
AllowTcpForwarding yes

Luego de modificar el archivo hay que relanzar el server sshd. La conexión en la configuración de la figura ocurre con los siguientes comandos

(cliente, red 44.153.81.0/24)

ssh -w any:any 200.0.0.1 -l root

Si la conexión es exitosa pedirá la password de root del host 200.0.0.1, que es la interface a Internet de la red a conectar. Una vez completada la conexión existe un tunel (usualmente tun0, o tunx en general) en ambos lados de la conexión que tiene que ser configurado.

(server, red 44.153.84.0/24 a traves de la conexión recién abierta)

ifconfig tun0 10.0.81.2 netmask 255.255.255.0
ifconfig tun0 up
route add -net 10.0.81.0 netmask 255.255.255.0 gw 10.0.81.2 tun0

En otra sesión SSH se configura del lado del cliente (red 44.153.81.0/24)

ifconfig tun0 10.0.81.1 netmark 255.255.255.0
ifconfig tun0 up
route add -net 10.0.81.0 netmask 255.255.255.0 gw 10.0.81.1 tun0

Al finalizar esta configuración ambos lados pueden rutearse utilizando los respectivos extremos del tunel.
El tunel, y la configuración de los extremos, dura mientras dure la conexión SSH que le dio el origen.
Las ventajas son varias. Los paquetes involucrados son livianos y entran aun en dispositivos muy pequeños, la conexión es encriptada, aunque solo durante el transporte por Internet, no en el aire con el ruteo convencional de la red ampr.org; y por cierto totalmente encapsulada. Puede ser, finalmente, transportada con cualquier conexión Internet sin demasiados problemas.
La desventaja es que requiere de ciertos conocimientos de redes para realmente hacerlo andar y por sobre todo para hacer el debug de los problemas que pueden ir apareciendo (en particular con el firewall).
La prueba de concepto tiene que automatizarse con una serie de scripts que establezcan automáticamente el tunel y su configuración, tengan en cuenta los cambios de dirección IP en los extremos en caso de ser direcciones dinámicas y en general tener en cuenta la configuración de ruteos.
Hay otros esquemas para establecer configuraciones de tunel que transportan puertos específicos (por ejemplo el puerto 80 para acceder a un server Web), pero el ruteo a nivel de capa 3 es el mas general posible.

lunes, 10 de septiembre de 2012

WAE DX SSB 2012 (Apuntes)

Y pasó el WAE DX SSB Edición 2012, competición que aporta puntaje para el WRTC 2014 bajo el formato Europa contra el resto del mundo.
Esta competencia tiene la particularidad de incluir el formato "QTC" ademas de contacto normal, en esta modalidad las estaciones DX pueden a voluntad pasar contactos pasados a las estaciones de Europa a modo de "mensajes" (QTC) hasta un máximo de 10 por estación. Complicado para enviarlos e ir gestionando lo que se mandó y lo que no pero calculo que endemoniado para recibir desde el otro lado, realmente operadores de primera linea.
Tuve la oportunidad de superar mis metas alcanzando 403M74 con algo mas de 122K puntos reclamados; pude pasar el 100% de los contactos realizados como QTC. La performance mejor a la prevista estuvo muy influenciada por propagación excepcional en las primeras 24 horas del concurso aunque luego se deterioró en las 2das 24 horas con una declinación muy marcada de las condiciones, baja de las señales e incremento del piso de ruido que hizo durante todo el Domingo muy dicil trabajar estaciones e impidiendo lograr tasas de contactos significativas. En total participé 22 horas alcanzando un promedio de 22 QSO/Hr (muy deteriorado el promedio por la baja actividad del Domingo).
Respecto al plan la noche del Viernes (hora Argentina) el perfil de contactos fue algo superior al esperado; el sábado me encontré con una buena tasa en 10M que no tenia previsto que ocurriera y luego pude obtener el plan en 20M. Durante el Domingo la tasa de contactos en 10M aunque mucho menor que el dia anterior también contribuyo a que esta banda fuera la de mayor performance, luego el resto del perfil de contactos fue aproximadamente el previsto. El resultado final fue que 10M (50%), seguido por 20M (45%), 15M muy por debajo de lo esperado (4%) y 40M virtualmente inexistente. Las estaciones DL dominaron la participación con el 50% de los contactos; 75% de mis contactos ocurrieron con las entidades  DL,EA,SP,UA,S5,F e I.  Tengo la sensación que participaron relativamente pocas estaciones argentinas, escuché a Juan con LT0H (quien vive a un par de cuadras de casa), y vi en distintos momentos en el cluster a otra media docena de estaciones. Pero no parecen haber participado las grandes M/S, o por lo menos no las escuché. Pude durante el transcurso del concurso contactar 37 entidades diferentes. Use en forma alternativa el DX Cluster gráfico de Rick (LU9DA) y el que se encuentra en el sitio DXMaps; a pesar de su similitud encontré que cada uno tiene sus sesgos que los hacen utiles en simultaneo. El de Rick para observar cambios macros en la propagación mientras que el otro para analizar mas en detalle el comportamiento dentro de la banda.
Tuve algunos problemas técnicos, el rig2 FT890 salio de servicio el Domingo con un problema en la alimentación que no pude arreglar con lo que tenia a mano, creo que no es mas grave que problemas en el cable de alimentación pero no tenia repuestos. Lo reemplacé por el FT100 pero sin conexión de micrófono, por lo que no lo utilicé en forma activa sino mas bien para monitorear otras estaciones y cambios de propagación. Tambien tuve problemas de interacción con RF en el teclado y los puertos series de la máquina principal (no de la secundaria) mientras operaba en 10M; el ultimo problema hacia que el CAT se comportara erráticamente y por lo tanto tuve que en varios pasajes poner los equipos en modo manual porque sino me alteraban las lecturas de frecuencia en el log. El resto de los concursos internacionales del año participaré en categorias QRP y no es un problema prioritario, pero no dejo de anotar que algo hay que hacer porque deteriora mucho la performance de la competición cuando ocurre el problema.
Dentro de Septiembre queda la ultima fecha del Campeonato Argentino de HF y posteriormente ya viene el CQ World Wide, cita ineludible en SSB primero (27 Oct) y CW despues (24 Nov).

sábado, 8 de septiembre de 2012

OpenWrt, receta para filesystems llenos

Al instalar OpenWrt en un router, en uno cualquiera de la interminable lista de modelos y fabricantes soportados, uno se encuentra con un sistema Linux bastante completo. Esto incluye el acceso a programas externos no incorporados directamente en la distribución (accesibles con el comando opkg).
Es inevitable "entusiasmarse" y empezar a bajar cosas hasta que uno se pega con la realidad de quedarse sin espacio; el router tiene muy poco espacio de almacenamiento en su filesystem, apenas 4 MBytes (implementado en memoria Flash) de los cuales un poco menos del 15% ya está ocupado luego de completar la configuración básica.
Al empezar a experimentar con paquetes rápidamente el tamaño escala a 60-70% o incluso mas del 90% de ocupación (lo que puede verse con el comando df y mirando el espacio libre en el mount point root o / ).
Entonces se hace lo lógico, se empiezan a remover paquetes instalados en la esperanza de recuperar algo del espacio, no es poca la sorpresa cuando el espacio ocupado no solo no disminuye con cada paquete removido sino que aumenta.
Ocurre por la logica particular con que está implementado el file system en memoria flash que un número de paquetes "basicos" ya están incluidos en memoria ROM (tambien implementado en Flash) y cuando son borrados no se recupera el espacio. La unica solución es hacer un "re-flash" o dicho en criollo volver a la configuración original. Eso es un dolor de cabeza.
Afortunadamente el alma de la configuración está en un solo directorio, el /etc/config y por lo tanto se puede solucionar en parte haciendo el backup del mismo

cd /etc
tar -cvzf /tmp/config.tar.gz config/

El archivo resultante config.tar.gz se puede bajar a la PC donde se lo respalde mediante el comando pscp ejecutado desde la PC (normalmente disponible en Linux o en Windows como parte del paquete Putty).

pscp -scp root@openwrt:/tmp/config.tar.gz config.tar.gz

Luego se re-inicializa la configuración del sistema y se hace el restore de la configuración; en mi caso eso es el 90% de la configuración (debo usualmente agregar un banner, cambiar el nombre de host y alguna pavada mas).
Y luego hay que pensar con cuidado que es lo que realmente se va a necesitar en el router, porque cuando se instalan algunos paquetes no siempre se puede volver atras. Quizás es un buen argumento para que el proximo router tenga la posibilidad de tener puertos USB donde se le pueda montar un filesystem persistente que no tenga este problema.

jueves, 6 de septiembre de 2012

El Hinternet criollo, apuntes subre Linux

A poco de ponerse a estudiar el material disponible sobre el HSMM es claro que, parrafaseando el ancestral dicho imperial, "todos los caminos conducen a Linux".
Linux es, en principio, un sistema operativo para computadoras derivado  de la arquitectura Unix. Como definición técnica debería bastar, pero es al mismo tiempo un montón de otras cosas. Es un esfuerzo cooperativo gigantesco que involucra al mismo tiempo a plataformas de procesamiento masivas o diminutas, pero que tuvo un nacimiento casi romántico en las manos del (entonces) adolescente Linus Torsvald inmortalizado casi como un eterno rebelde (aunque ya no lo es tanto). Es una potente plataforma para desarrollar software, en particular  para lo que se denomina "Software Abierto" (Open Software). Es parte de un movimiento tecno-cultural que lo asocia con la "libertad", en algunos ámbitos con un marcado sesgo de confrontación con otras alternativas (quizás la mas marcada, los productos MicroSoft). Es también el origen de la noción que es una plataforma para la que el software "es gratis".
Es concebible desarrollar un concepto como el HSMM sobre Windows, pues los principales "bloques constructivos" están ahi disponibles y de hecho mucho del software necesario es parte del Windows mismo o es gratis o tiene un valor accesible. Hay por supuesto herramientas y aplicativos que pueden ser costosos, pero no serán en general necesarios.
Con el suficiente nivel de profundidad técnica y algunas limitaciones prácticas hay un factor que no es muy difundido; casi cualquier paquete que corra en Windows puede correrse en Linux y viceversa.
En realidad la única razón por la que el Windows no es atractivo no tiene ninguna relación con la eterna (y algo esteril) discusión sobre sistemas "abiertos" o "propietarios". La principal razón es que Windows solo reina en el ámbito (extenso por cierto) de las plataformas Intel (no por casualidad denominadas como Wintel), las versiones para otras plataformas son espasmos mal concebidos y peor implementados del énfasis corporativo de Microsoft de sacar cualquier moneda de cualquier lugar.
Linux puede ser utilizado en virtualmente cualquier plataforma, desde los mas grandes computadores de alta performance (supercomputadores) hasta los mas pequeños dispositivos embebidos; en una gama de procesadores y arquitecturas enorme.
Hace una década las opciones de un aficionado eran solo conseguirse la máquina PC mas grande que pudiera pagar su presupuesto; hoy las opciones son muchas otras. Y eso nos conduce a esta nota.
Linux se "construye", es decir uno puede obtener los binarios para su plataforma, pero si desea modificarlos en algun aspecto siempre puede "contruirlos" desde cero. O llevarlos a otra plataforma ("portarlos"). Esto lo permite una arquitectura increiblemente modular donde cada componente es lo mas pequeño que se pueda implementar para que haga su función y un marco donde todos ellos interoperan. Por eso, el número de componenetes que realmente son diferentes para una determinada plataforma (un procesador por ejemplo) son muy pocos. Una vez "re-escritos" esos pocos componentes el resto es esencialmente el mismo código, compilado para máquinas diferentes. Esta caracteristica es clave, porque puedo adaptar el software para cualquier uso aunque este no hubiera sido previamente concebido, y para hacerlo no tengo que empezar desde cero. Me apoyo en una gigantesca plataforma, estable y sostenida globalmente.
Una plataforma que incluso me permite trabajar en máquinas que aún no tengo (o no existen aún) pues no necesito
... ni siquiera estén construidos en la misma máquina, dado que son usuales los compiladores "cruzados", es decir que funcionan en una arquitectura pero generan código para otra.
... ni siquiera sean ejecutados en la misma máquina, dado que son usuales los emuladores, que permiten simular a cualquier procesador (o mas propiamente, arquitectura de procesador).
Hoy se puede correr Windows bajo un Linux Ubuntu y que esto sea transparente para todos los programas involucrados; o corre un Ubuntu bajo Windows. Programas de emulación como el qemu, VirtualBox o VMWare lo hacen posible.
¿Que pasa si el paquete que quiero usar corre solo en Windows/Linux?... Simple, lo corro bajo emulación en Linux/Windows!!!!
Tambien, aunque es menos atractivo para el propósito de esta entrada, correr aplicaciones en forma cruzada sin recurrir a la emulación del procesador sino utilizando emulaciones de la plataforma misma. Por ejemplo puedo correr aplicaciones concebidas para Linux en la plataforma Windows utilizando un conjunto de librerias denominadas CygWin que le permiten al programa "ver" lo mismo que vería si estuviera corriendo en un Linux, o correr una réplica cruda de Windows pero escrita para Linux como Wine.
Pero esta facilidad no se limita a estas dos plataformas, por cierto ambas en la arquitectura Intel (X86); puedo emular cualquier procesador que se me antoje (ARM, MIPS, PowerPC, etc) con los mismos recursos.
Eso significa que puedo utilizar un ambiente Windows en PC para correr software especializado que solo tiene una expresión conveniente en Linux, puedo tener una máquina virtual que lo haga. O puedo desarrollar en forma cruzada.
Todo esto puede parecer una descripción mas o menos llevadera de las posibilidades tecnológicas de interoperar las dos principales plataformas que se pueden utilizar en radio; pero no se debe ir mucho mas lejos sin reconocer que utilizar estas facilidades requiere muchos menos conocimientos que lo que hubieran sido necesarios hace una década, pero aún por encima del usuario promedio.
El principal atractivo es que en los usos de HSMM hay dispositivos mucho mas económicos que una PC y por eso son tan atractivos para utilizarlos, tanto para construir una infraestructura con ellos como para... jugar con ellos (!!).
Por ejemplo puedo tomar uno de los (literalmente) miles de modelos de dispositivos "utilitarios" de propósitos específico (print server, disk server, settop box, TV controllers, etc) de, generalmente, costo muy moderado (mucho menor que una PC en todo caso) y mediante el cambio de su firmware por una versión "abierta" de Linux transformarlos en un computador de propósito general.
¿Abstracto? Tomemos un router TP-Link modelo WRT741ND (o cualquier otro similar) como el que se compra en cualquier shopping a un costo del entorno de los USD 50, le cambiamos su microcódigo propietario por la versión adecuada al nivel de hardware de OpenWrt (o, con menor énfasis, dd-wrt) y tenemos un pequeño computador Linux de propósito general que además es un muy buen router de protocolos TCP/IP y al cual se le pueden compilar (o desarrollar) toda suerte de protocolos robustos o experimentales, como los que pueden ser útiles para un despliegue experimental de... por ejemplo una red HSMM (!!!).
No son ejemplos aislados, nada impide transformar un printer server o un storage server con la cantidad de memoria adecuada en un Web server, o un DX Cluster o un mail server de bajo volumen; una vez que se le reemplazó el firmware original por un Linux se puede hacer todo lo que se puede hacer con un Linux... es decir... todo. No es teoría, el DXCluster de Rick (LU9DA) corre en esa plataforma.
Me es (muy) dificil encontrarle una diferencia a este tipo de experimentación de lo que podría haber sido construir un receptor "novelero" modificando un receptor de radio común.
La tendencia, habilitada por la revolución tecnológica de los sistemas embebidos, es que incluso las prestaciones de mayor performance de alguna manera reservadas a las PC también estan siendo crecientemente desplazadas por estos utilitarios, solo sigan con atención la maravilla tecnológica llamada "Raspberry Pi".
Un poco para redondear el panorama resta entender como se puede hacer frente a desarrollar para semejante blanco movil de plataformas; si tuviera que desarrollar software para que una Raspberry Pi se comunique con un router inalámbrico justamente me apoyaría en la esencia misma de los sistemas abiertos (e interoperables) que pregona Linux, podría hacerlo porque en definitiva todos los Linux funcionan en forma similar. Pero aunque quisiera llegar tan profundo como estar seguro que lo que estoy experimentando va a funcionar incluso a pesar de las pequeñas diferencias que hay en los Linux entre distintas plataformas, bueno, en ese caso lo que haría sería emular ambos ambientes en mi PC bajo qemu.
Un ecosistema potencialmente tan rico como puede ser una red HSMM requiere una plataforma que se pueda adaptar a todos las probables plataformas que se usen; pero al mismo tiempo que tenga un grado de interoperabilidad con máquinas que corran en versiones mayores de Linux o Windows. Esa plataforma es sin duda Linux.
Por eso es que en materia de HSMM, "todos los caminos conducen a Linux", cuanto antes empecemos la marcha más rápido llegaremos.

martes, 4 de septiembre de 2012

El Hinternet Criollo, algunas perspectivas

Uno de los aspectos que hace fascinante al concepto del High Speed Multi-Media (HSMM) network, red multimedial de alta velocidad para aficionados, a veces llamada el "Hinternet". Es que al mismo tiempo engloba varios temas que creo son claves para la actividad de radio.
La promesa de una red lo suficientemente veloz como para ser comparables a lo que usualmente puede obtenerse en Internet es, quizás, la mas inmediata y visible.
Personalmente no creo que la Internet (y sus múltiples ofertas) alejen a la gente de la radio. Mas bien lo contrario, creo que Internet tiene el potencial de contribuir a la radio a traves de su vasta capacidad de difundir ideas, habilitar esfuerzos participativos, obtener información y la inagotable provisión de herramientas. Creo que lo que atrae gente a la radio es la posibilidad de experimentar, con la comunicación siendo una especie de sub-producto que aparece como resultado aunque no tanto como fin. Es dificil ver una especialidad dentro de la radio que no haga, al mismo tiempo, un uso mas o menos intensivo del Internet para su desempeño.
En una época la radio tenía una capacidad creible de ser una alternativa de comunicación, incluso corriente, cuando la capacidad de telefonía, y en particular de telefonía celular, no estaban desarrolladas lo suficiente. En mi opinión esa situación no es asi, y no lo es desde hace mucho tiempo. Puede que mucha gente se acercara al hobby con esa motivación, y es natural ahora que carece de fundamentos que se alejen. Los métodos de comunicación modernos operan en una escala y con una cobertura que salvo excepciones no puede ser igualada por medios "amateurs".
Los argumentos que toda esa infraestructura colapsa en condiciones de emergencia para mi no es del todo convincente, porque la infraestructuar de radioaficionados no está preparada para emergencias tampoco.
Pero la velocidad comparable a Internet, algo asi como un Internet propio  creo que es solo uno de los aspectos que lo hace atractivo. La enorme capacidad de desarrollo y experimentación es el aspecto que creo termina resultando clave al momento de comprender el potencial. Pero para entenderlo es necesario un cambio de paradigma respecto a lo que nosotros entendemos por "experimentar".
Cuando comencé en radio (circa 1970) el radioaficionado que se preciaba de tal construia sus propios equipos, esa era la impronta. El que no tomaba esa ruta y se decidía por la por entonces escasa y costosa oferta de equipos comerciales recibía el mote (con cierto sesgo cargado) de "perillero", es decir el que hacía radio y su operación se limitaba a utilizar sus equipos "moviendo las perillas". Creo que esa separación era (y es) injusta toda vez que operar bien un equipo de radio es un arte complicado de manejar y que también requiere (y dá mucho espacio) para experimentar. Pero, con la excepción de unos muy pocos artesanos, la experimentación partía de un piso de agregación de sistemas que eran los componentes. Muy pocos podían construir sus valvulas (en realidad no conozco a nadie, pero ciertamente es posible), sus capacitores, resistencias o componentes especiales. La experimentación consistía entonces en "armar" equipos a partir de componentes de mayor o menor disponibilidad, siguiendo un esquema publicado en revistas o medios gráficos y en algunos casos bajo la supervisión o ayuda de alguien mas experimentado. Muy poca gente conocía entonces profundamente de electrónica, conocían si algunos conceptos físicos básicos y aumentados muy marcadamente por un bagaje de experiencia vivencial o empírica. Muy poca gente polarizaba una válvula siguiendo las cartas del fabricante, a lo sumo miraba mas o menos que tensiones máximas de placa o corrientes de grilla eran necesarias para hacer volar el dispositivo por el aire para intentar (no siempre con éxito) no superarlos; menos aún modelaba "electrónicamente" la válvula.  Muchos menos aún eran capaces de comprender los fenómenos fisicos detallados que tenían lugar para que una válvula realmente funcionara. Casi cualquier sabía que los filamentos emitían electrones (por algo descripto como emisión "termoiónica" que poquisima gente podía caracterizar en detalle como fenómeno físico) y que distintos juegos de voltajes producían los distintos fenómenos de conducción o inhibición que terminan haciendo operar una válvula. Es natural que así sea, la física y la matemática necesaria para estudiar en detalle estos fenómenos se encuentra aproximadamente a nivel de un 2do o 3er año de Ingeniería. El conocimiento de nivel secundario es suficiente solo para dominar el uso con un enfoque mas o menos práctico solamente.
Mas o menos lo mismo con cualquier componente, casi todos sabían que un capacitor es algo que se estudiaba como dos placas de metal con voltajes y que por un método mas o menos misterioso se hacía un cilindrito, lo mismo con las resistencias y asi sucesivamente.
Los mas avanzados, entre ellos mi maestro en radio Ernesto Stellini (LU5EZ,SK) podían calcular sus inductores y sus transformadores. Pero en general la reproducción y la experimentación se colocaba un "click" arriba, es decir, dados los componentes que se podía hacer con ellos. Los cambios de tecnología fueron alejando este tipo de experimentación de las manos de los aficionados hasta llegar a hoy donde es improbable que un aficionado medio (o incluso muy especial) sea capaz no ya de armar sino incluso de reparar sus propios equipos con excepción de las cosas mas triviales. Es hasta natural en esta perspectiva observar, con cierta angustia incluso, que los componentes para sostener este tipo de experimentación son cada vez mas dificiles de conseguir
Queda, por fortuna, un amplio espacio para la experimentación con algunos subsistemas (procesamiento de señales, antenas), modos de emisión y, por supuesto, la adquisición de habilidades operativas que son tan complicadas ahora como lo fueron siempre. Pero es claro que el hobby como conjunto bajo esas premisas está lentamente declinando, su población envejeciendo y su atractivo disminuyendo.
Quizás es hora de comprender que el paradigma ha cambiado. Que simplemente buscar que vuelvan las épocas pasadas o que la alternativa sea "nada" no es razonable.
¿En que formas puede cambiar el paradigma? Creo que en comprender que los ingredientes básicos siguen estando ahi, solo que ahora toman otra forma a la luz de los cambios tecnológicos, pero su esencia no ha cambiado. La electrónica ha migrado con el tiempo del dominio analógico al digital, la radio tal como la conocemos se ha quedado en muchos de sus aspectos en el primero.
Hoy potentes procesadores de información, del cual una enorme mayoría de la población desconoce como funcionan excepto en forma muy rudimentaria, posibilitan la creación prácticamente ilimitada de artefactos capaces de procesar señales cuya construcción si está al alcance de un público mucho mas amplio, y por cierto que lo está de los radioaficionados. Técnicas como DSP o SDR son ejemplos en este sentido. La plataforma de experimentación ha cambiado desde el hardware al firmware de los dispositivos, ese es el cambio que no es tan evidente y que muchos simplemente no estan viendo porque no conocen lo suficiente del nuevo mundo como para entenderlo, o se aferran al anterior por resistencia al cambio o simplemente un menú complejo de motivos que está fuera del alcance de esta reflexión el explorar.
La placa del procesador, o el módulo de RF, estan construidos ahora con métodos tecnológicos fuera del alcance del aficionado promedio, tal como los capacitores o las válvulas (o los transistores) lo fueron en su momento; el aficionado se colocaba entonces un escalón por encima del mínimo nivel para el que tiene capacidad de operar con recursos y conocimientos razonables. Si uno visualiza ese cambio entonces todos los componentes de un modelo virtuoso de hobby vuelven a estar presentes.
Los radioaficionados, de aceptarse esta perspectiva, vuelven a poder construir sistemas complejos a nivel del estado del arte, integrando componentes tecnológicos disponibles; el truco consiste en aceptar que ha cambiado el piso desde el que se parte. En algunos casos esa integración sigue las formas o "recetas" de otros experimentadores de forma tal que la experimentación consiste en adquirir habilidades mediante la "reproducción" del estado del arte; seguido de la capacidad de "adaptar" creaciones de otros para finalmente llegar al estadio de "desarrollar". Dado que el resultado final termina siendo algo comparable al estado del arte tecnológico de uso diario, el desarrollo de las competencias en sus distintos grados producto de este tipo de actividad termina teniendo el mismo atractivo de aprendizaje que todo hobby lleva implicito pero al mismo tiempo tiene cierta utilidad o correlato con habilidades que son relevantes en el desempeño fuera del hobby, a tal punto que no sería demasiado disparatado que con la evolución y los aprendizajes del caso las personas puedan con el tiempo definir si lo mantienen como una actividad de esparcimiento solamente o terminen siendo la actividad a la que se dediquen para vivir. Tal como ocurrió por décadas con los radioaficionados "de antes".
Para completar la conexión luego de un rodeo bastante amplio creo que iniciativas como el HSMM tienen estos ingredientes; usa tecnología de punta (procesadores, nodos, dispositivos de red, componentes de RF) en una mezcla variopinta. La "receta" para hacerlos funcionar no es dificil de seguir, los rudimentos de conocimientos como para tener una idea general de como funciona puede adquirirse con una educación personal. Pero atrás de cada uno de sus componentes hay tecnologías cuyo dominio requieren esfuerzos mas considerables que una vez adquiridos traen como premio la posibilidad de experimentar con cambios y esto tiene el potencial de derivar en un proceso continuo de aprendizaje y experimentación de nuevos aspectos.
¿Que es lo que diferencia a los radioaficionados de cualquier otro "amateur" interesado en informática? Despues de todo no hay que tener licencia para tener una PC y jugar con ella, pero tampoco hay que tener licencia para comprar componentes y armarse una alarma o un robot, o incluso un radio control. La licencia dá la posibilidad de usar frecuencias, y además usarlas con potencias, que otros aficionados que no la tienen no pueden. Y eso establece la diferencia entre el entusiasta en electrónica que se arma un micrófono inalámbrico para comunicarse con el vecino de un entusiasta que lo hace para comunicarse a decenas (o decenas de miles) de kilometros. Es posible que nuestra actividad deba evolucionar incluso reglamentariamente para acompañar semejante "desplazamiento del paradigma" (paradigm shift).
A grandes rasgos las areas que este planteo requiere que se exploren son el hardware/firmware involucrado (como se implementa), el software de aplicación (como se usa), los componentes de radio propiamente dichos (como se despliega) y la topología (como se opera); no necesariamente todos al mismo tiempo ni en ese orden.
Cuando empecé en radio soñé con que quizás algún dia esa fuera mi profesión, los sistemas lo fueron en cambio; lo que nunca imaginé es que uno y el otro con el tiempo se harían tan indistinguibles. Puedo atestiguar que el cosquilleo en el estómago que se siente cuando se logra finalmente que un circuito electrónico ande es idéntico al que se tiene cuando finalmente anda un software que uno hizo; y ni que hablar si ese software lo está usando para comunicarse con otro.
La radio es, en definitiva, no el fin sino solamente el medio de algo mucho mas profundo, la necesidad de las personas de aprender, experimentar y conocer. Esa es la invariante y la impronta de nuestro hobby lo que en mi opinión determinará si continúa o desaparece.

lunes, 3 de septiembre de 2012

MM2OR Version 1.5 de LU7HZ

Finalmente y sobre la hora del WAE DX CW 2012 pude completar el retrabajo de mi programa MM2OR (v1.5). Todo empezó con mi cambio de configuración donde retiré el FT840 como rig1 y puse en su lugar el FT100. Solo para descubrir que en general no funcionaba con mi configuración basada en OmniRig.
El programa N1MM no permite en forma natural trabajar con OmniRig. Hay incluso algún rechazo de los autores a incorporar esa facilidad con argumentos no del todo fundados.
Como sea en su momento hice este programa como un "integrador" que permita que N1MM piense que se utiliza el puerto serie pero este en realidad es emulado mediante com0com quien lo comunica con este programa quien a su vez opera el rig via comandos de OmniRig. La principal ventaja es que permite que otros programas comanden el transceptor al mismo tiempo que N1MM (ver figura). Contra lo que a veces se afirma no basta con colocar un "port splitter" y dejar que OmniRig y N1MM se comuniquen al mismo tiempo con el transceptor, simplemente no anda porque los programas se inundan de respuestas que no esperan y consideran un error (debido a requerimientos de los "otros" programas).
Como sea, el FT100 no andaba bien controlado de esta forma y para mi sorpresa tampoco lo hacía cuando el N1MM lo manejaba en forma nativa. Tuve la fortuna que John (K3CT) uno de los autores del N1MM decidiera abordar el tema e introducir los cambios necesarios, por mi parte cooperé en lo que pude con el test de la versión que se completó justo antes de empezar el concurso.
Como resultado tuve los elementos para entender alguno de los problemas que habia tenido al programar originalmente le programa y entonces abordarlos. Pude incluso empezar a alejarme de la necesidad de tener una dll por cada rig que se soporta para empezar a poder manejar una única dll genérica configurable en forma externa (no lo he logrado del todo aún con el FT890 por razones que estoy investigando por lo que sigue teniendo una dll propia.

WAE DX SSB 2012 (Preliminar)

Y se viene el WAE DX SSB Edición 2012  torneo, junto con su versión de CW, válido para la clasificación del WRTC 2014. Competencia además muy interesante por su formato y la novedad de poder obtener puntos adicionales mediante el recurso de pasar contactos pasados dentro del concurso con un formato de QTC.
El año pasado las condiciones estuvieron muy "raras" con baja performance en las bandas bajas y al mismo tiempo con las bandas altas con su performance reducida por la época del año. Terminó siendo 20 metros la mejor banda, y mi plan para este año asume que volverá a ser la banda clave para esta edición. Aun así alcanzó para ganar Argentina y tener una posición significativa a nivel SA, dependerá de muchos factores pero intentaré de ser posible repetir la experiencia.
Apuntaré a conseguir una mejora sobre la performance del año pasado y por lo tanto estar en el entorno de 200 a 300 QSO con algo menos de 200 multiplicadores, tratando de pasar el 95% o mas de los contactos como QTC. La categoría a participar está muy determinada en SO AB LP (no existe la categoría SB ni QRP).
Con la experiencia de varias ediciones tanto de CW como de SSB no tengo aún claro cual es la mejor estrategia para manejar los QTC. Daria la impresión que hay que reservarselos para pasar en los momentos en que baja el run, pero al mismo tiempo cuando baja el run es porque se cayeron las condiciones y también es dificil entonces encontrar a quien pasarselos.

Si tuviera que sintetizar una estrategia diría que hay que pasar siempre que se pueda los QTC pendientes excepto que la tasa de contactos sea excepcionalmente alta (en mi caso arriba de 30 QSO/hora) o 2X la tasa promedio en general.
El perfil esperado de contactos, basado en la historia del año anterior mezclada con el perfil de contactos en la edición de CW. Es una forma de tener en cuenta las caracteristicas estacionales y de participación propias del concurso de fonía con los perfiles mas recientes debidos a la propagación. Ese perfil preveo requerirá aproximadamente la mitad de los contactos en 20 metros, algo menos (40%) en 10 metros y el resto repartido en alguna proporción mayormente basado en oportunismo entre 15 y 40 metros; salvo alguna circunstancia excepcional no preveo contactos en 80 metros.
Técnicamente volveré a utilizar la configuración que tan buenos resultados me ha dado en este año, el equipo FT840 como rig1 y el FT890 como rig2; no me dio resultados satisfactorios utilizar el FT100 como equipo principal. Habiendo reparado el FT890 me permite volver a tenerlo en una función que cumple muy versatilmente de 2do equipo. En WAE se puede utilizar cluster sin hacer diferencia como categoría asistida.
Preveo entre 17 y 20 horas de operación efectiva, mas que nada limitada por la propagación, muy por debajo de los limites máximos establecidos por el reglamento para la categoria.

Buscar este blog

Páginas vistas en total