Uno de mis recientes amigos del otro lado del charco me ha pedido que le ayude a traducir su software a Español y a probarlo en diversos dispositivos móviles. No es que ande muy sobrado de tiempo ultimamente, pero imagino que no me llevará demasiado ayudarle y siempre viene bien tener un amigo contento en Canadá . F(x) es un entorno de aplicaciones muy potente diseñado para Symbian (Nokia Series60, 80, 90, y Sony P800, etc…). Ofrece herramientas para construir facilmente pequeños applets que mejoran la productividad personal en temas de finanzas, ingeniería, medicina y otras muchas áreas en las que se requieran cálculos y manejo de datos.
Con F(x) se puede tener desde una calculadora científica personalizada, con sistema de evaluación de fórmulas, un conversor de medidas o una calculadora de estructuras de hormigón, hasta una chuleta personalizada para un examen o un examen en si mismo, ya que dispone de un sistema de formularios muy completo, que permite no solo la publicación de los mismos para que otros los rellenen, sino que también se pueden enviar los datos que se vayan tomando, por lo que resulta una herramienta muy útil para entrevistas y estudios estadísticos de campo.
Aqui podeis ver un pequeño ejemplo, aunque en su página tiene información mucho mas completa.
Si, Makinolo ha estado 3 dias completamente offline y 1 a medio gas. Mi último post se ha perdido para siempre en una marea de sectores defectuosos, al igual que el disco duro que daba vida a mi servidor.
Después de la actualización de hardware que realicé el domingo pasado, con unos poquitos problemas de tarjetas de red que se solucionaron trasteando en el hwconfig y el modules.conf y al intentar devolver el nuevo PC al habitáculo dentro de la estantería que tengo habilitado para el servidor, el disco duro, que era el mismo que el del servidor anterior, un Maxtor 91021U2 de 10Gb, comenzó a dar errores de hardware hasta el punto de no arrancar el Linux. Los errores estaban tan extendidos que alcanzaron a los inodos de los archivos que guardaban el shell y no pude arrancar ni en modo recuperación.
Tuve que montar otro disco duro en el servidor e instalarle un RedHat para poder montar el disco duro defectuoso, pasarle un fsck y recuperar lo que pudiese, pero no sirvio de nada.
Tambien probé con un Knoppix 3.6 el Lunes. Muy bonito pero igual de inefectivo. El fcsk ya no reconocía el disco ni el sistema de archivos… llegó un momento en que ni siquiera el fdisk me reconocía el disco.
Temblad malditos si empezais a ver algo parecido a esto en vuestro arranque o al ejecutar algun comando en Linux:
Por fortuna acababa de hacer backup de mis datos justo antes de comenzar la migración del hardware, con lo que solo he perdido un post, que escribí al terminar dicha migración.
Lo malo ha sido que he tenido que reinstalar todo el sofware del servidor, lo que me ha llevado casi 12 horas repartidas en 2 dias, incluyendo la compilacion del PHP5 unas 12 veces hasta dar con la configuración adecuada para que la librería gd y freetype funcionasen adecuadamente.
Desde luego el Linux no es para usuarios bisoños como dicen los de BULMA, yo estaba ya harto de no entender por que no me funcionaban determinadas funciones de PHP, de tener que recurrir a tarballs por que los rpms no actualizaban debido a las dependencias de paquetes, de tener que actualizar librerias por separado aprendiendome todas las opciones posibles de sus respectivos ./configure (el de php5 es especialmente laaaargo).
Menos mal que también tenía guardado el directorio /etc en el backup y hubo cosas que repuse muy rapidamente, como el samba y los scripts de arranque o la configuracion del Apache.
El MySql me dio mucha guerra también debido a los usuarios con los que se habian creado las bases de datos, que por otro lado son muy faciles de importar… simplemente copiando el directorio data antiguo sobre la nueva instalación.
El nuevo servidor es un Dell Optiplex GX100 (Celeron 500 Mendocino) sin caja ni extensión PCI, con 128Mb de memoria y dos discos duros Seagate, uno de 8Gb (ST38410A) sobrante de mi equipo de trabajo habitual y otro mas antiguo de 1Gb (ST51080A) para la partición de boot y la de swap. Espero que duren mas que el Maxtor.
Como peculiaridad, el ventilador del disipador del procesador “sopla” aire en vez de extraerlo que es lo habitual en los grandes disipadores. La FA hace muy poquito ruido y espero que el conjunto se caliente menos que mi PIII al que he tenido que poner ventilación en los discos duros hace poco (40Gb y 80Gb) por que me estaban horneando la habitación.
Bueno, espero que esta sea de las últimas veces que me toque hacer esto por que estoy un poco harto de tener que dedicar tanto tiempo a reparaciones de mis sistemas, sobre todo si ademas me estresan porque me dejan el servidor offline durante dias.
Y como siempre, después de terminar mas o menos el invento y buscando mas información para hacer un driver para lcdproc que directamente me escriba un fichero con el formato que necesito (el driver de texto solo usa ASCII y por tanto no es capaz de representar caracteres definidos por el usuario) me he dado cuenta de que el otro programa superviviente para LCDs en Linux, el LCD4Linux, tiene un driver que se llama ‘raster’ que te crea directamente una imagen PNG o PPM emulando al LCD y la coloca donde le digas. Vamos que sirve para casi lo mismo que yo quería hacer, salvo que mi Flash se actualiza automaticamente y se puede reescalar, mientras que este PNG tiene un tamaño fijo aunque eso si, carga mucho menos la CPU que mi Flash.
Parece que el desarrollo del LCD4Linux no está tan estancado como el del lcdproc, al menos eso se deduce de las información de sourceforge. Están trabajando en una nueva versión completamente remodelada pero la última release aún funciona.
El LCD4Linux es igual de complicado de instalar que el lcdproc aunque al no ser de arquitectura cliente servidor es mas fácil de poner en marcha.
No lo estaba usando por que el LCD4Linux NO tiene control por software del backlight de un LCD como el mio, compatible con el HD44780, con el esquema de conexiones compatible winamp y el control de backlight por la patilla 17 (Selectin). El lcdproc si lo soporta. He tenido que hacer un apaño hardware (un hilo soldado desde los +5V a la entrada del transistor) para mantenerlo siempre encendido y poder ver algo en el LCD.
Para instalar el LCD4Linux primero hay que descargarse el tarball y descomprimirlo. Hacemos un configure usando el parametro
–with-drivers=
seguido de los drivers que vamos a usar, en mi caso el Hitachi, que es el chip de mi LCD comprado en
CrystalFontz y el PNG.
make clean
./configure –with-drivers=HD44780,PNG
por supuesto, como no podia ser de otro modo, esto da un warning a mitad de configuración diciendo que no tengo instaladas las librerias gd. Es mentira, falso, me engaña… ¿como se cree si no que estoy sacando desde php estos bonitos titulares en mi blog?
Pero en fin, despues de buscar durante un buen rato la manera de contarle al configure donde se encontraban los .h y .so del gd, me di por vencido y lo instalé de nuevo.
Ale, a descargar otro tarball, otro ./configure, otro make install y a reanudar la recompilación del LCD4Linux
make clean
./configure –with-drivers=HD44780,PNG
make
make install
Ahora si, ejecuto el LCD4Linux con esta configuracion en el fichero /etc/lcd4linux.conf:
Display PNG
Size 20×4
font 5×8
pixel 2+1
gap 2×2
border 10
foreground #A8EC09
halfground #1432BE
background #1B3CD5
Los colores son los de un LCD azul, iguales que los que he usado en el Flash, pero se pueden cambiar. Los tamaños están elegidos para que el LCD virtual sea lo mas pequeño
posible respetando las proporciones entre pixeles y espacios. Aún así es bastante grande para mi gusto, pero no se pueden dividir los pixels de una pantalla.
Sale perfectamente, salvo por el hecho de que los iconos definidos por el usuario no se ven, que sigo teniendo problemas con la caché y obviamente, la imagen no se actualiza sola.
Me gustaría poder escribir un driver para el LCD4linux que se comunicase con mi Flash mediante un socket XML para hacerlo realmente real-time, pero me da muuuucha pereza ponerme a investigar el codigo fuente del LCD4Linux y la forma en la que se programan los
drivers, mas aun despues de darme cuenta de lo ‘oxidado’ que tengo la programación en C… si es que lo de la programación orientada a objetos es mucho mejor!!!
En fin, si saco fuerzas de flaqueza pondre a pelearme con el CVS y a estudiarme los fuentes.
Una vez construido el Flash mis sospechas se hicieron realidad. En efecto, como la mayor parte del tiempo el fichero se encuentra abierto para escritura, el 90% de las veces que se pide está vacio. Para solucionarlo he implementado una version chapucera de la técnica del doble buffer. Escribo la pantalla en un fichero auxiliar y cuando cierro el mismo lo muevo al archivo definitivo mediante un comando del shell.
Aqui está el código fuente del pequeño programa.
El rudimento ha funcionado bastante bien, y ahora solo me queda lidiar con la detestable caché del navegador que hace que cada vez que el Flash pide el archivo con los datos, el navegador devuelva el cacheado y por lo tanto no se actualiza la pantalla. Para solucionarlo he añadido a la petición un parametro fantasma
“?foo=contador”
donde contador es un número que se incrementa con cada petición. De esta forma las llamadas son siempre distintas y evito la caché.
Este no ha sido el único dolor de cabeza que me ha proporcionado el Flash. Como no he encontrado una fuente que sea gratuita y que emule las letras de un LCD (la SB Liquid Open lo hace, pero es de pago) me he construido los caracteres mediante una matríz de clips cuadrados de 5×8 puntos y he tenido que definir un mapa de caracteres completo para poder representarlos en dicha matriz mediante un vector de 5 bytes por caracter. De esta forma me puedo construir todos los símbolos que me apetezca, iconos e incluso animaciones. Lo que ocurre es que el driver de texto del lcdproc no me proporciona la definición de los iconos que pudiesen estar mostrandose en pantalla por lo que de momento no he implementado animaciones de caracteres en el Flash.
Para poner un ejemplo, la letra M, cuyo código ASCII es el 77 va contenida en la posicion 77 del array de caracteres y sus 5 bytes indican el mapa de bits que se enciende en cada una de las 5 columnas de la definición del caracter
this.charset[77] = new Array(0×7F,0×20,0×18,0×20,0×7F); // M
Este es el resultado final, con la conexión activa en el que podeis ver el estado actual de mi servidor a través de varias de las pantallas de información que proporciona el lcdproc. Para encenderlo hay que pulsar sobre el, si quieres apagarlo por que te consuma demasiados recursos, vuelve a pulsar sobre el.
He creado varios esquemas de color que se pueden pasar como parámetro al flash (parametro colorscheme) para obtener los 4 tipos de LCD diferentes que comercializa crystalfontz, el azul, el verde, el ambar y el rojo.
Pero esto no es todo, pronto volveré con mas información respecto al LCD virtual.
Estoy intentando hacer un LCD virtual que muestre en una página web la misma información que el LCD físico que tengo conentado a mi servidor para así monitorizarlo remotamente. Mi servidor es un Linux y estoy usando lcdproc para alimentar al LCD actualmente como ya comenté en mi post Gran Azul.
El LCDproc posee un driver que saca texto plano y que está pensado para tareas de debug principalmente.
Yo lo he usado como fuente para hacer el lcd virtual. He redirigido esa salida de texto hacia un programa que escribe un fichero que queda disponible por http ya sea para cargarlo desde un flash y representarlo en el, bien para mediante php y el generador de imagenes, construir un GIF con el contenido, o ambas opciones.
Lo primero es compilar de nuevo el lcdproc por que no tenia activado el driver de texto, para lo cual uso la orden
make clean
./configure –prefix=/usr/local/ –enable-drivers=hd44780,text
make
make install
El hd44780 es el driver para mi LCD físico, un CFAH2004A-TMI-JP de crystalfontz conectado por el puerto paralelo con el cableado estilo winamp y con control para apagar el backlight por software siguiendo este esquema.
El make clean es necesario para eliminar los restos de la anterior compilación que metian errores en el make.
Ahora ya tengo un LCDd (el daemon del LCD que actua de servidor) al que puedo invocar de esta forma:
LCDd -d text -f -a 127.0.0.1 > textoutput
para obtener las primeras pruebas de funcionamiento, que son medio exitosas.
El fichero ‘textooutput’ se llena de pantallitas del LCDd, pero unas detras de otras, y yo solo quiero que aparezca una en el fichero, la mas reciente.
Para conseguir una sola pantalla por fichero he tenido que programar un pequeño programa en C que a partir de la
entrada estandar, stdin, reconoce cuando empieza y termina una pantalla (‘
+———————+
‘ muy sencillo ) y escribe una y otra vez el fichero que se le pasa por parametro con la pantalla que le va llegando. De este modo, redireccionando la salida del LCDd mediante un pipe la envio a mi programa que va generando un fichero con una sola pantalla, siempre la última.
LCDd -d text -f -a 127.0.0.1 | lcdtool textoutput
El único problema que veo es que la creación y destrucción del fichero generado por lcdtool sea tan frecuente que cuando se haga la petición de este fichero por http el apache no pueda servirlo por que esté a medio escribir o simplemente vacio por que acaba de volver a ser creado.
Esto lo probaré en cuanto tenga listo el Flash que mediante un loadVariables va a pedir dicho fichero y lo va a presentar como si fuera un LCD virtual.
El sistema Glicko es un metodo para medir la potencia de juego de un determinado jugador en un juego en concreto. Es similar, de hecho es una evolución de el, al sistema Elo que se usa ampliamente por las federaciones de ajedrez de todo el mundo y que fue creado en los 60 por Arpad Elo.
El sistema Elo categoriza a los jugadores mediante un número que indica la potencia de juego, es decir, un jugador con un Elo mayor que otro se supone que es mejor jugador.
Este sistema calcula el nuevo Elo tras cada partida balanceando el resultado, es decir, si un jugador con Elo 1700 gana a otro con el mismo valor, se le suman 16 puntos al Elo del ganador y se le restan al del perdedor.
Parece un sistema justo y fiable, pero para juegos on-line, como el WorldCap o el ya antiguo y desaparecido Mus que hice para Teknoland hace 5 años, no lo es tanto. La razón es que cuando un jugador entra nuevo o cuando un jugador hace mucho que no juega, su valor de potencia de juego puede estar desfasado o ser completamente incierto.
Para solventar estos problemas, el profesor Mark Glickman, de la universidad de Boston y presidente del comite de rankings de la federación estadounidense de ajedrez, creó en 1995 el sistema Glicko. Este sistema añade un valor a la potencia de juego, la llamada desviación o índice de incertidumbre, que informa sobre lo exacto o inexacto que resulta ese valor.
La desviación puede valer entre 1 y 350 y cuanto mas cerca de 1 esté mas cierto es el valor. Podemos decir que si por ejemplo yo tengo una potencia de juego de 2100 y una desviación de 30, aparte de que sería un auténtico campeón por tener valores tan altos, existen unas probabilidades del 95% de que mi potencia real este entre 2160 y 2040.
La desviación disminuye cada vez que juego una partida y aumenta cuando paso mucho tiempo sin jugar.
De este modo perder o ganar contra jugadores nuevos o que juegan poco tiene menos repercusión sobre nuestro ranking que jugar con jugadores con una desviación muy pequeña, ya que estamos mucho mas seguros de cual es su potencia de juego real.
Otro efecto positivo de la desviación es que incita a la gente a jugar mucho, para que les baje.
Podeis leer la descripción del sistema Glicko de manos del propio autor, donde explica tambien las formulas que se usan para calcular los nuevos valores de Glicko después de cada partida, aunque son mejores y mas orientadas al programador las que se encuentran en las páginas del FICS. Son las que hemos usado para crean nuestra clase de java que utilizamos en todos los proyectos de juegos que funcionan con ranking.
En la práctica el sistema es muy bueno para saber quien entre dos jugadores es mejor, pero es muy difícil crear un ranking oficial, es decir, una lista ordenada por potencias de juego, ya que los valores de glicko nunca son definitivos ni ciertos hasta que no se llega a desviación cero, y hay muy pocos jugadores que lo consiguen.
En el Mus se ordenaba por potencia de juego directamente, y no era una buena solución. En el Worldcap hemos optado por dividir a los jugadores en categorías análogas a las del futbol real y en cada categoría hemos metido a los que tienen una desviación parecida. Dentro de cada categoría se ordena por potencia de juego. De esta forma es mas fácil comparar ya que al menos la incertidumbre de todos los rankings de los jugadores que se encuentran en una misma categoría es similar.
Me disperso demasiado, lo se, pero no puedo evitarlo.
Resulta que mientras hacia las páginas de soygeek, un grupo de amigos con intereses geek, y las que estoy preparando sobre como trabajar el metacrilato (van a estar muy completas) se me ocurrio que podia representar las moléculas de los monómeros del metacrilato y policarbonato mediante un Flash que las dibujase bonitas en 3D y que permitiera su rotación e identificación de átomos y enlaces.
Me puse a investigar y encontré un pequeño flash a medio terminar realizado por Edwin Heijmen que presentaba en unas dudosas 3 dimensiones (usa circulos en lugar de esferas y sin colores) una molécula de un compuesto desconocido.
Con ello aprendí que existe una definición a partir del XML de un lenguaje de descripción de moléculas llamado CML y que en el vienen todos los datos necesarios para representar la molécula, como por ejemplo en esta de la cafeína. También he aprendido que existen otros formatos mas primitivos como el protein database PDB, que para despistar mas se llama igual que el Palm DataBase y el formato MOL originario de la empresa MDL, desde los que se pueden obtener CMLs con conversores como el Open Babel.
Después de esta labor de investigación, y para tener algo por lo que empezar, descompilé el flash con el descompilardor de Sothink, lo estudié y me hice a continuación el mio propio, con una aproximación de POO que ya he utilizado en algunos otros proyectos de Action Script.
Mi SWF es mas permisivo con el formato CML y acepta los campos en cualquier orden, cosa que el CML reader en flash que use de base, no hacía.
He cambiado los circulos grises por esferas coloreadas siguiendo el esquema de colores CPK ( Corey, Pauling, Kultin), los enlaces entre átomos que antes eran líneas los he hecho con cilindros coloreados también, y le he metido algún otro añadido, como la posibilidad de enlazar cada átomo con una URL o ponerle comentarios. También permite que se le especifique el nombre del archivo CML por parametro de llamada.
En fin, que si alguien necesita algo así y para que no tenga que descompilarlo, dejo aqui el código fuente en Action Script de los objetos junto con el FLA que define la visualización y el SWF compilado mas una página que lo lanza. No está comentado ni exquisitamente programado, pero algo tengo que dejar para vosotros ¿no?
aún no he sido capaz de encontrar archivos CML, MOL o PDB de las moléculas de metil metacrilato y Bisfenol A + Carbonato que son las que en un principio pretendía representar. ¿Alguna ayuda?
Actualización (28/11/2004): Gracias a Dominique Verreman he conseguido las moléculas que andaba buscando. Me las ha pasado en MOL y las he convertido a CML con el Open Babel. Los resultados muy pronto en la guia del metacrilato!!
Ultimamente estoy en estado de hiperactividad mental y eso me está haciendo meterme en un montón de proyectos a la vez. Claro, así no hay quien termine nada, y por tanto no he tenido mucho que escribir.
Entre otras cosas estoy liadisimo con el proyecto de modding de la render farm (un blade server de 6 hojas de fabricación casera) para Zinkia, el soporte para estudios de usabilidad en móviles para Dnextep (que está casi acabado y que pondré aquí solo si me dan permiso , la programación de un módulo en PHP para presentar el tiempo que envia en un feed XML The weather channel para incluir en la página de mi grupo ciclista y también he estado trabajando en la lectura e interpretación de los datos de GPS de otro tipo de archivo, los que crea el XMap HandHeld Edition, para lo que he tenido que volver a realizar una labor de ingenieria inversa.
El XMap crea logs de los puntos por los que pasa el GPS y se puede configurar cada cuanto tiempo toma las muestras, cosa que el GPSPilot Tracker 5.05 no hace (el 5.5 si lo hace, pero recordemos que solo funciona para Palm V y yo tengo la PalmIIIx). El Xmap no me presenta el mapa como el GPSPilot, por que usa mapas vectoriales en vez de raster y no tengo mapas vectoriales de las zonas que frecuento (España), pero para el propósito que lo utilizo no lo necesito, ya que solo quiero grabar la ruta y normalmente ni siquiera miro la Palm en todo el trayecto.
El caso es que tuve que volver a bucear en las profundidades de los archivos PDB. Para hacerme la tarea mas fácil grabé un trayecto en tren de la línea C-5 (si el mismo cercanias que uso todos los dias y que pasa por Atocha) entre El soto y Cuatro Vientos.
Saqué el xPDB y me puse a escudriñar los registros del PDB.
El archivo, aparte de los datos propios de la cabecera del PDB, contiene 10 registros que forman la cabecera y que son siempre 10, y luego un numero de registros igual al numero de puntos que han sido guardados durante la sesión de captura del log del GPS.
De la cabecera he conseguido descifrar los 3 primeros registros, los mas importantes, que contienen las latitudes y longitudes de los puntos del log, guardados, eso si, de una forma muy peculiar. Cada valor de latitud y longitud va almacenado en un long, como es habitual, de 4 bytes en Big Endian pero con la peculiaridad de que los datos del primer punto se encuentran en las primeras posiciones del primer registro, el segundo punto esta en las primeras posiciones del segundo registro, el tercer punto en las primeras del tercero, y el cuarto punto, está en las segundas posiciones del primer registro otra vez, y así sucesivamente.
Esto fue lo que mas trabajo me costó averiguar, ya que en un principio yo hacía la lectura secuencial de todas las latitudes y longitudes y me salian valores del recorrido un tanto extravagantes, como que desde el soto a cuatro vientos hay 50Km (en realidad solo hay 10) y que el tren de cercanias viajaba a una velocidad media de 192 Km/h, lo cual era bastante gracioso.
Los 7 valores de los 7 registros siguientes no se aun lo que son, aunque no parecen demasiado relevantes. Se trata de registros que contienen un solo byte.
A continuación vienen los registros de cada punto del trayecto, cada uno conteniendo los siquientes datos:
Tiempo desde el ultimo punto en segundos (int)
Altitud en pies (int)
Rumbo en grados (int 0-360)
Velocidad en millas por hora (int)
Fecha y hora en formato palm (long)
Ciertos datos son un poco redundantes, como la velocidad o el tiempo transcurrido, ya que la primera se puede calcular a partir de las latitudes y el tiempo, y la segunda la sacamos de la diferencia de las fechas de los puntos, pero en fin, sus razones tendrán para hacerlo así.
Como ya tenia hecho el programa para exportar a OZI los tracks del GPSPilot, no me ha costado nada exportar los tracks de XMap.
Para terminar este rollo infumable pongo una muestra de lo que se puede sacar con el OZIExplorer a partir de una sesión grabada en una salida en bici por la sierra de Madrid.
Continuando con mi labor de investigacion sobre el GPS, al final consegui usar el GPS Pilot Tracker 5.05 con la Palm IIIx y pude guardar un par de recorridos de prueba, uno de ellos el que hice para recoger el LCD del post anterior.
Ahora venian los problemas, por que el recorrido, llamado ‘track’, esta en un fichero PDB (Palm Database) que ningun programa de mapas para PC puede leer. Ni siquiera el GPS Babel, que convierte un montón de formatos de GPS, da soporte a este. Gran desolación. Por mas que he buscado no he encontrado nada.
Pero no pasa nada, aunque me ha costado lo mio, despues de vencer la vagueria habitual a la hora de ponerse a programar, entré en una espiral de aprendizaje y me puse a escribir un programa en Java que:
Lee archivos PDB
Extrae sus registros
Lee registros del GPSPilot
Convierte esos registros en formato OziExplorer
Oziexplorer es uno de los programas mas utilizados para la lectura y confección de mapas. Tiene muchas posibilidades de uso y está muy ampliamente extendido entre los usuarios deportivos de GPS, tanto para senderistas, como para ciclistas o para 4×4.
Como me imagino que esto no será de gran utilidad para nadie, pues ni siquiera he publicado el programa. Si alguien lo necesita no tiene mas que pedirmelo. Digamos que es código abierto, software libre y bastante guarro, por que no lo he hecho con vistas a crear ningún proyecto grande.
Lo único que no he conseguido es descifrar del todo el formato de los registros del GPSPilot. He conseguido extraer la información mas necesaria para exportar un track, esto es: la longitud y latitud, la altitud y la fecha y hora de cada punto del track. También he calculado la velocidad entre puntos, la velocidad media y la distancia parcial y total.
Todo esto lo he averiguado por ingenieria inversa, estudiando el archivo PDB, guardando tracks y comparando los valores del archivo con los valores reales y aun despues de pasarme mas de 24 horas en total, varios dias hasta las 5 de la mañana, estudiando el archivo, hay unos cuantos datos que se me escapan.
Concretamente no se como está codificado el valor de la declinación magnética que se supone que viene tras la altitud y la fecha. Por mas vueltas que le doy no me salen los valores que deberían.
Tampoco se que es lo que se representa en la cabecera de cada registro de track, justo después del numero de puntos. Son un montón de bytes cuyo significado desconozco.
Este es mas o menos el formato de cada registro del GPS Pilot Tracker:
Los datos de longitud y latitud hay que dividirlos entre 3600000 para sacar los grados decimales, la fecha es aun peor, por que está en formato Palm, son los segundos transcurridos desde el 1 de enero de 1904.
Y luego vino lo mas divertido, la conversion al formato de tracks del Oziexplorer. La longitud, latitud estuvo facil, la altura hay que pasarla a pies siempre y la fecha… el infierno total. Oziexplorer está desarrollado en Delphi al parecer, y usa fechas en formato Delphi que son un número double en el que la parte entera indica el numero de dias transcurridos desde el 30 de diciembre de 1899 y la parte decimal indica la fraccion de dia, es decir, si es 2.5 es que han pasado 2 dias y medio desde esa fecha, osea, es 1 de Enero de 1900 y son las 12 del mediodia. Un autentico infierno para convertirlo, pero por fin está hecho y ya saco tracks en el Oziexplorer capturados con la Palm y sobre un mapa sacado de varias capturas de la Carta Digital Militar de España.
Solo he tardado 3 semanas en conseguirlo… odio la informática.
Y ahora un par de links para usar el Oziexplorer y las rutas trazadas con el GPS:
www.misrutas.net Pagina con rutas para mountain bike. elgps.com Pagina muy completa sobre GPS, mapas y Oziexplorer.
Me ha dado por desempolvar el receptor de GPS que compré hace bastante tiempo, como 5 años, para usarlo en mis rutas ciclistas. El caso es que quiero guardar un ‘log’ del recorrido que realizamos en las salidas de los domingos para de ese modo luego poder representarlo sobre un mapa de la zona y poder ponerlo en la web (grupo ciclista ‘a joderse’).
El aparato lo compré en USA junto con una Palm IIIx y los cables necesarios para conectar ambos. Se ha tirado mucho tiempo en el baul de los recuerdos por que el software que me venia solo traia mapas de USA y me eran mas bien de poca utilidad, pero ahora me he puesto a buscar con mas ahínco y he encontrado GPS pilot, un conjunto de utilidades para la Palm que me permiten tener una brujula (Compass), ver tu posicion en un mapa (Atlas) o trazar un camino sobre ese mismo mapa de los sitios por los que vas pasando (Tracker).
Ha sido toda una odisea encontrar el software por que mi GPS, el Delorme Earthmate, utiliza un protocolo propietario (el Zodiac o Rockwell binary) para la transmision de los datos de posicionamiento proporcionado por los satélites en lugar del NMEA-0183 (National Marine Electronics Association) que es el estandar para los GPS mas habituales como los de Garmin o Magellan.
Muy poco software para la Palm soporta este protocolo, de hecho solo el propio software de Delorme y el de GPSpilot lo hacen, pero el software de GPSpilot en su ultima version (la 5.5) solo funciona para PalmOS 3.5 o superior. Intentando hacer un upgrade a mi Palm IIIx me he dado cuenta de que el PalmOS 3.5 solo sirve para la Palm V por lo que no podia usarlo.
Solo me quedaba ponerme en contacto con la gente de GPSpilot para que me enviasen una versión anterior del software, y así lo hicieron. En menos de 2 horas recibí la version 5.05 del GPS Tracker. Bravo por su rapidez, aunque el hecho de que el software cueste lo mismo que la versión 5.5 y que ademas no den soporte por ser una versión antigua, pues me ha echado un poco para atras a la hora de comprarlo… son $40.
Funciona perfectamente con los mapas que ya tenia cargados y que son simplemente imagenes tomadas del Mapa digital militar de España (cartografía bastante anticuada, pero no tengo otra cosa). GPSPilot proporciona una herramienta llamada Cartographer que te permite importar imagenes de mapas e indicandole la latitud y longitud de las esquinas, el mismo te hace la escala y te lo deja preparado para meterlo en la Palm en forma de base de datos PDB. Es muy chulo.
Ahora solo me queda hacer una prueba de recorrido y ver con que programas puedo representarla sobre un mapa en el PC para sacar la ruta y tambien el perfil. A mis compis de bici se les va a caer la baba cuando lo vean.
.
