miércoles, 29 de agosto de 2012

Hinternet Criollo (apuntes)

Por ahora tratando de recopilar información y antecedentes sobre los distintos bloques constructivos de una arquitectura que permita implementar una red de Alta velocidad multimedia (HSMM) para uso de aficionados.
En principio es claro que hay que abordarla con un enfoque disruptivo y no evolutivo sobre lo que históricamente ha sido la red packet; basicamente se trata de pensar en un piso de capacidades que empiece en el 1 Mbps y pueda ser tan alto como 100 Mbps en condiciones controladas; es decir, similar o compatible con lo que puede ser una conexión casera de internet.
Todavia el relevamiento está en la fase "explosiva", como todo tema que se comienza a explorar el patrón de evolución es predecible.
Los progresos son lentos pero hasta ahora he logrado profundizar en la plataforma dd-Wrt (que descarté) y la OpenWrt que creo que es la clave de la infraestructura de la red. Esta última está mucho mas alineada con una actividad de ham radio por su naturaleza abierta pero además porque es una arquitectura mucho mas potente. Se trata de una distribución especial Debian adaptada a la arquitectura MIPS en la que se basan la mayor parte de los routers inalámbricos (con distintas variantes). La curva de aprendizaje es un poco dura al comienzo pero el resultado es disponer de una computadora corriendo un Linux y con enorme flexibilidad para operar como router (incluso en AX.25) al precio de un router hogareño (unas pocas decenas de dolares).
Y ahi aparece la primer brecha tecnológica que obliga a pensar la iniciativa en forma distinta; los procesadores embebidos agregan una dimensión a la arquitectura inexistente hace una década cuando se luchaba con la red AX.25 en base a paquetes propietarios corriendo en una PC. Simplemente usar los mismos paquetes mayormente obsoletos en PC que son dos ordenes de magnitud mas grandes para hacer lo mismo carece de sentido. El enfoque claraemente va por el lado de los "utilitarios".
Es decir la arquitectura tiene que empezar a pensarse como el "appliance" corriendo un Linux especializado encargandose de la red y que es accedido por un "cliente" que es nuestra PC normal. Una de las cosas que "mataba" a la red packet era que no pocas estaciones eran erráticas en su disponibilidad, este enfoque soluciona el problema.
OpenWrt tiene una versión que además corre en procesadores Intel (X86). Y no hay que sacarle ni por un momento la vista de encima a la placa Raspberry Pi que creo tiene un enorme potencial para aplicaciones de aficionados. Gracias a la gestión de Pedro (LU7ABF) se han definido en el espacio ampr.org de Argentina tres subnets clase C (cor, lpg y mdq) con los cuales se están haciendo las pruebas.
Paralelamente, y por una afortunada coincidencia, me encuentro desarrollando una disertación sobre ambientes para desarrollos de sistemas embebidos que daré a comienzos del año próximo. Y digo que es una afortunada coincidencia porque el proceso de investigación me lleva a tener que evaluar varios ambientes embebidos... sin tenerlos. Eso me llevo a crear un ambiente de simulación, mayormente basado en el paquete QEMU, capaz de emular las arquitecturas ARM, MIPS, X86, SPARC y PowerPC. Es decir uno puede tener una "placa" embebida corriendo en un ambiente virtual en la PC que le provee un ecosistema tal que para el software es "indistinguible". Este ambiente tiene enormes ventajas no solo para el desarrollo sino también eventualmente para la ejecución de componentes de la red (una Raspberry PI emulada en mi máquina PC actual con una fracción de sus recursos no es mucho mas chica que mi máquina PC de hace una década).
Además de los "sistemas" y las "distribuciones" que de por si son un tema inagotable hay un número muy importante de cuestiones prácticas que resolver.
La primera es como crear los "túneles" que permitan la conectividad de los distintos LAN en tiempo real, asumiendo que no todos o incluso la mayoría no puedan establecerse por medios radiales puros. Para implementarlos se requiere definir que mecanismo de Point to Point es el mas efectivo, hay varias variantes posibles para establecer VPN que implementen estos enlaces "privados" a traves de Internet; es probable que alguna variante simple de PPTP (point to point tunneling protocol) sea el mas adecuado; sin embargo está claro que hay que comprender como hacer funcionar el ip forwarding por medio del IPIP protocol (tunel IP-IP, se encapsulan datagramas IP de una red en otra) pues es el que usa el gateway ampr.org para hacer el ruteo global. Hay un problema técnico aún no resuelto sobre como operar este protocolo en un medio que hace NAT/Masquereading.
El establecimiento de túneles es esencial tanto para el ruteo "aguas arriba" (conglomeración de MAN) como "aguas abajo" (conglomeración de LAN) de forma que la red pueda escalar en tamaño y en capilaridad.
El transporte en RF no le he prestado demasiada atención aún, pero estimo que deberá hacerse en banda de 5 GHz para aprovechar equipos comerciales ligeramente modificados (con la posible excepcion de utilizar equipos aún mas comunes de sin modificar para 2.4 GHz , los tradicionales Wi-Fi, si se logra una autorización limitada de la CNC para su uso por radioaficionados).
Muy lejos aún de ocupar el centro de la escena es "¿para que?"; como dije en una entrada anterior la respuesta ahora es facil.... el aprendizaje necesario es enorme y eso solo justifica la iniciativa. Pero en un plazo mas largo quizás hay que fijarse en iniciativas como "Buenos Aires Libre" como un modelo de utilización y gestión para la red resultante (que curiosamente no rutea Internet).
Ahhh, y además tenqo que completar una nueva versión del programa MM2OR antes del WAE DX SSB que se viene en un par de semanas (!!!).


sábado, 18 de agosto de 2012

WAE DX CW 2012 (Notas)

 Y pasó el WAE DX CW edición 2012 donde participé en la categoría SO AB LP, obtuve una cantidad de contactos y puntaje reclamado un poco superior a lo planeado, lo que me alegra puesto que marca progresos respecto a la participación del año pasado. Por otra parte, y a pesar de algunos comentarios al respecto,  las condiciones estuvieron mejores que el año pasado en particular en bandas bajas (aunque no para mi aparentemente) por lo que el resto tendrá también sus resultados mejorados. Al momento tengo calculados 423M103 o unos 149K puntos habiendo logrado pasar la totalidad de los contactos como QTC.


PROPAGACION

La propagación estuvo por encima de lo planeado en 10M (51%) donde tenia perspectivas francamente pesimistas en mi plan, aproximadamente como lo planeado en 20M (32%), ligeramente por encima de lo planeado en 15M (16%) puesto que me rindió mucho mas comparativamente que en otras competencias y muy por debajo de lo estimado en 40M (1%). A diferencia de competencias recientes no pude hacer ningun contacto en 80M.
La propagación en general estuvo mejor el primer dia del concurso (SFI 127/A6/K1) que el segundo (SFI 120/A4/K2); en particular el segundo dia tuve un ruido de banda muy peculiar en 10M que levantó durante buena parte del dia el piso de ruido a unos muy poco habituales niveles de S5 a S6 (cuando normalmente es S0 a S1). También tuve, y también es poco habitual, muchos problemas de ruido de ignición en 10M.
La banda de 40M en el otro extremo resultó muy poco productiva, en parte porque estaba muy ruidosa y en parte porque empecé los descansos sin realmente esperarla a que fructificara. La tasa de contactos estuvo ligeramente por debajo de lo planeado con 14 QSO/hr, fundamentalmente deteriorada por el comienzo muy lento de la propagación el Domingo (20 QSO en las primeras 4 horas del concurso); en total tuve una participación de 30 horas,  por debajo del máximo permitido de 36 horas para la categoría SO pero creo que bordeando el limite de lo que fisicamente puedo sostener.
La demografía del concurso fue abrumadoramente dominada por estaciones DL (31%), completando la mitad de todos los contactos con UA, SP, UR e I, en total contacté con 43 paises durante el transcurso del concurso.
Escuché en distintos momentos a varias estaciones de Argentina como ser LS1D (siempre fuerte, sobre todo en las bandas bajas), LU5FZ, LU3MAM y LU8QT, aunque seguramente hubo varios otros que no tuve la oportunidad de escuchar. De SudAmérica escuché en varias oportunidades a CX9AU (no escuché a Jorge CX6VM). Es muy notorio el deficit de estaciones de Argentina en CW, siempre se plantea este problema a la hora de analizar la sempiterna competencia con Araucaria y Bavaria DX Club.

TECNICA

Habia varios cambios a probar durante el concurso. El primero y mas importante fue poner al Yaesu FT100D como equipo principal (rig1) del sistemas SO2R; la conclusión es que creo que fue un error hacerlo. Encontré el lunes por la mañana que el IPO se había activado automáticamente por lo que estaba mas "sordo", pero en general no tuve la performance ni la comodidad que puedo llegar a alcanzar con el FT840 como rig1, asi que seguramente haré las pruebas necesarias para revertir el cambio.

En segundo lugar pude probar la configuración integrando al Reverse Beacon Network (RBN) con el flujo de spots del DX Cluster de Rick (LU9DA) utilizando el programa WinTelnetX elaborado por K1TTT. Este concurso permite utilizar libremente cluster sin tener que declararse como en una categoría asistida. Las conclusiones son buenas pero  el número de spots "busted" que genera es mucho mas importante que el 2% que reclama Peter (N4ZR); En esta primera experiencia diría que está entre un 7 y un 10% de callsigns mal formados. De hecho en oportunidades me veia a mi mismo en mi frecuencia de run como LU7HM# o LU7HI# (el símbolo # al final de la distintiva es agregado por el RBN para diferenciar el spot del producido por el cluster normal.
También utilicé el RBN como "prueba" de propagación viendo como me reportaban los nodos europeos en cuanto a relación S/R a la manera de indicarme mis chances de ser bien escuchado alli. Quede muy satisfecho con el funcionamiento del sistema y que no hubiera degradación visible en la performance que terminara molestando la operación, de todas formas tenía como plan "B" que si eso ocurría pondría como máquina primaria de conexión al cluster la secundaria en la estación, pero finalmente no fue necesario.
El tercer cambio fueron las modificaciones al N1MM referido en una entrada anterior, las mismas consistían en reconstruir el CAT del FT100D (que en su versión original no funcionaba correctamente) pero que lamentablemente no alcanzaron a meterse en la última distribución del N1MM antes del concurso por lo que participé con una versión en beta (lo que pudo haber, aunque no estoy seguro, inducido el problema del IPO en el FT100D y algun cambio no esperado en la configuración mientras transcurría el concurso).
Si bien utilicé el sistema SO2R durante el concurso el número de contactos que hice con el fue relativamente bajo, un 8% en esta ocasión. No obstante no deja de ser un puntaje mayormente oportunista que vale la pena aprovechar.

CONCLUSIONES

Otra oportunidad para probar la estación y modificaciones que se van haciendo, también para verificar que continúa el progreso y se van cumpliendo las metas que me planteo antes del concurso; este mecanismo de establecer metas y luego medirme contra ellas ayuda mucho a mantenerse al margen de las discusiones sobre el cumplimiento de reglas de otros participantes; mi objetivo es cumplir mi plan y lo que hagan los otros participantes no es mi problema. Como a su vez mis planes tienen metas de mejoras crecientes de poderlas mantener en algún momento eso será un problema para el resto de los participantes.
Ahora el siguiente concurso internacional es el WAE DX 2012 edición de Fonía que ocurrirá en un mes; pero antes la 4ta fecha del Campeonato Argentino de HF donde está empezando a perfilarse un acomodamiento muy competitivo entre los cinco primeros, entre los que por fortuna estoy.


jueves, 9 de agosto de 2012

El Hinternet criollo

Para los cultores del packet radio que en alguna oportunidad intentaron experimentar con TCP/IP montado sobre AX.25 siempre resultó una frustración las limitaciones que imponía primariamente la velocidad (1200 o 9600 bps) y en segunda medida el protocolo AX.25 mismo, al menos en su version 1. No hubo nunca redes que realmente aprovecharan las ventajas de  la versión 2 del protocolo, en particular de packets mayores a 256 bytes.
La red packet ha languidecido en la última década hasta llegar al punto hoy de ser prácticamente inexistente, con excepción de algun BBS todavia en funcionamiento mas por nostalgia que por uso y de la relativamente modesta pero aun útil infraestrctura de APRS.
El uso de TCP/IP ha evolucionado mientras tanto para que sea dificil navegarlo con velocidades relativamente bajas; aún 512 Kbps es una velocidad donde no es cómodo navegar, siendo velocidades superiores al 1 Mbps mas la norma que la excepción en estos dias.
Como un hecho que pocos conocen la red packet tiene un dominio en Internet, el ampr.org y un subnet clase A (el 44.0.0.0/255.0.0.0) que es administrado globalmente como un dominio no ruteable y no conectado aunque un gateway en ucsd.edu resuelve su DNS y bajo ciertas condiciones rutea desde y hacia Internet. Cada geografía tiene un coordinador que administra un subnet Clase B de esa alocación, la que nos corresponde en Argentina es la 44.153.0.0/255.255.0.0; la que a su vez se separa en subnet Clase C con un criterio geográfico.
Recientemente se está produciendo una corriente de desplegar infraestructuras de alta velocidad (11 Mbps o superiores) en bandas de aficionado de microndas basada en equipos comerciales modificados que recibe el nombre de HSMM (High Speed Multi Media network) o Hinternet (Ham Internet).
Esto por su parte genera la reacción de aggiornar la infraestructura de ruteo con internet, especificamente el gateway en ucsd.edu para nivelarlo a los tiempos que corren.
Junto con un equipo de "vagos y mal entretenido" hemos pedido y obtenido 3 subnet clase C (256 direcciones cada uno) localizados en Córdoba (cor.ampr.org), Mar del Plata (mdq.ampr.org) y La Plata (lpg.ampr.org) destinados a realizar experimentos con estas tecnologías que ya son accesibles desde Internet (probar ping router.cor.ampr.org) aunque aun no tienen infraestructura desplegada que responda. No hay un plan claro y no es posible determinar a que velocidad progresará el experimento y que grado de avances producirá y por cierto cual será su resultado; el tiempo de todos los participantes es muy limitado y son muchos los aspectos a cubrir.
Por lo pronto hay que trabajar sobre equipo comercial que opere en 5 GHz (hay una idea de hacer algunas pruebas en 2.4 GHz como banda no licenciada, pero esto requerirá en algún momento una autorización de la CNC) para lo cual hay que buscar formas de aumentar potencia y alcance respecto a un router doméstico normal.
Por otra parte el tipo de ruteo necesario exige trabajar con el firmware de los routers comerciales para agregar opciones de tunelización IP-IP, protocolos especiales de RIP y quizás algun esquema especial de extensión de rango); para ello hay que partir de desarrollos como dd-wrt u Openwrt y modificar su configuración, los módulos que están activos e inclusive agregarle extensiones "custom".
Por ultimo hay que trabajar en conectar y rutear los tres LANs (o MANs en realidad) para que eventualmente puedan engancharse con el gateway en USA que los haga visibles en Internet; para ello hay que establecer túneles IP-IP.
Mucho trabajo, cansa solamente enumerarlo, mas aun pensar en lo que falta y ni que hablar de hacerlo.
Mas allá de lo interesante (o divertido) que sea jugar con estas cosas hay que pensar también en encontrar una buena respuesta a la pregunta "¿para que?".
En este momento la respuesta es obvia... "porque es divertido", pero cuando acabe la experimentación quedará aun la pregunta de que uso se le puede dar a una infraestructura asi.
Obviamente si bien puede usarse para navegar por Internet carece de sentido con ese propósito, excepto como muy secundario. El real desafío de una infraestructura de este tipo es ver si en ella florecen aplicaciones propias de aficionados, como en su momento lo fueron el DX-Cluster o APRS, o implementaciones originales de tecnologías existentes para usos de radioaficionados.
¿Carecemos de ideas o simplemente hay que crear el marco para que se implementen? No hay forma de saberlo hasta que probemos.
Por lo pronto estaremos construyendo una maceta, luego el tiempo dirá que clase de flor puede aparecer ahi.

miércoles, 8 de agosto de 2012

N1MM bug con FT-100D CAT SO2R

Como parte del ajuste de la configuración de mi estación he cambiado al FT100 para que opere como rig1 manteniendo al FT890 como rig2; esa es la configuración que ensayaré al menos en WAE DX CW 2012 y la siguiente fecha del campeonato argentino de HF. Este cambio saca al FT840 que necesita reparaciones nuevamente por una muy marcada distorsión que tiene cuando trato de operarlo en LP (no molesta en QRP), y se vienen 4 concursos de LP (WAE CW/SSB y dos fechas del Argentino de HF).
Sin embargo al terminar el conexionado me encontré con un funcionamiento muy errático del N1MM operado a traves del CAT. Como lo he comentado en este blog el N1MM no da soporte al OmniRig, ni lo dará nunca según palabras de uno de los desarrolladores Joe Subich (W4TV) en una respuesta en el reflector. Según el porque el OmniRig no puede soportar todas las funciones. Eso es una pamplina por supuesto, todo se puede en informática.
Es importante contar con la sintonía integrada entre N1MM y los equipos del SO2R dado que en WAE se puede operar en forma asistida, y pienso sacar todas las ventajas que pueda de hacerlo.
Y en particular en este caso hay una función del OmniRig llamada "custom command" donde el OmniRig no intenta manejar los envios y respuestas del transceptor sino que transfiere transparentemente todo lo que pasa el programa y todo lo que el transceptor contesta. Como sea implementé un programa llamano MM2OR que actúa como una interfaz; le presenta al N1MM una interfaz como si fuera un transceptor conectado por un puerto serie y transfiere los comandos via OmniRig y en sentido contrario las respuestas.
El programa implementa cada transceptor con una Dynamic Linked Library (DLL) que se adquiere por configuración y tienen en cuenta las particularidades de cada equipo; hasta ahora implementé las correspondientes al FT817, FT840, FT890 y FT100.
Lo he usado en varios concursos y anda muy bien. Pero para el caso del FT100 nunca anduvo demasiado bien. Por un lado N1MM hace una implementación defectuosa del CAT en los equipos Yaesu en general y en el FT100 en particular. El programa envia dos comandos separados (0xfa y 0x10) con el objetivo de obtener el estado del transceiver, y lo hace continuamente. El primer comando tiene una respuesta de 8 bytes y el segundo depende del modelo de transceptor pero normalmente es de 32 bytes, los primeros 16 reflejando el estado del VFOA y los 2dos 16 para el VFOB.
Por su defecto de implementación N1MM espera siempre una respuesta de 40 bytes juntos, o sea que la mas minima latencia en la respuesta en los dos comandos hace que de errores; pedir los dos comandos juntos no está mal, esperar las dos respuestas juntas como si fuera una sola si. Cuando la PC corriendo el N1MM habla con el equipo directamente y si tiene buen tiempo de respuesta no tiene problema en procesar la relativamente lenta respuesta de un puerto serie de tal manera que las dos respuestas sean inmediatas; pero cuando hay software middleware en el medio no necesariamente eso ocurre asi y por lo tanto produce fallas erráticas.
En particular en SO2R anda mal, y dá continuamente error. Y siempre he pensado que se trataba de "algo" que mi programa MM2OR daba como respuesta que aunque correcta no terminaba de cumplir lo que el N1MM esperaba; e invertí una cantidad de horas importantes en tratar de resolver el problema; cosa que finalmente logré en todos los transceptores menos el FT100 tomando las respuestas y almacenandolas internamente para luego enviar bloques de 40 bytes contiguos. Hasta que para obtener un patrón de comparación corrí el N1MM directamente controlando al transceptor (con un analizador de tráfico en el puerto serie) para ver que pasaba. Grande fue mi sorpresa al ver que el mismo problema que me daba usando MM2OR lo daba sin el, el problema está en N1MM (!!).
Como en modos digitales uso el N1MM controlando directamente el rig (sin OmniRig hasta este cambio que acabo de hacer) siempre pensé que andaba bien de esa forma. Pero lo que no había tenido en cuenta es que  en digitales el N1MM está configurado como SO1V mientras que en el resto de los modos como SO2R, y es en ese modo que falla malamente.
Afortunadamente John (K3CT) amable como siempre ha tomado el problema y está produciendo versiones de prueba con los que progresivamente superar el problema, y ha empezado a re-escribir el manejo del FT100 completamente. No es la primera vez que John tiene una respuesta tan comprometida y tan buena, y es una maravilla tener semejante soporte de un paquete de software gratuito como es el N1MM. Asi que con un poco de suerte va a quedar todo en orden y andando.

martes, 7 de agosto de 2012

CQ WW SSB 2011 (Resultados)

Han aparecido los resultados del CQ WW SSB Edición 2011. Si bien ya estaba anticipado por los resultados claimed veo con mucha satisfacción que se confirma mi 2do Puesto World (1ro Continental SA, 1ro Argentina) en la categoría SO SB(A) QRP en la que participé. El puntaje fue 532M26+82 o 152280 puntos. El ganador World fue Francesco ( I0UZF) con mas de 243000 puntos.
El analisis de los UBN provisto por los organizadores muestra una merma un poco menor al 10% por lo que se evidencia una mejora operativa respecto a participaciones anteriores.
Es una categoría linda y con buena propagación resultó agil en cuanto a estaciones constantemente disponibles casi las 24 horas; sin embargo es una categoría que desde el punto de vista WRTC tiene un puntaje demasiado mermado al compararse con SO SB(A) LP, lo que creo que es injusto pero marche preso.
Es probable que este año participe en SO AB QRP tanto en SSB como en CW tal como ya lo hiciera en el CQ WPX.

Buscar este blog

Vistas de página en total