Posiblemente en alguna ocasión tengas que hacer un programita en Java para un módem Cinterion TC65 o XT65 en el que tengas que capturar datos (entradas digitales, analógicas, posiciones GPS, capturas realizadas por el puerto serie …) y almacenarlas en un fichero interno de la flash para su posterior envío a un servidor central.
Hoy os cuelgo un pequeño ejemplo en Java para hacer la segunda parte, el envío de los datos por FTP a un servidor central.
En este último también había un ejemplo de FTP. Este de hoy es más elaborado, pues permite subir directamente un archivo almacenado en la memoria flash de nuestro módem a un servidor vía FTP. El proyecto y código fuente del ejemplo lo puedes descargar de aquí.
Para probarlo sin complicaciones haz lo siguiente paso a paso. Crea un fichero de nombre “datos.txt” con los datos que quieras en su interior y grábalo en la memoria FLASH de tu módem TC65 / XT65 (en el directorio raíz). Después importa el proyecto de ejemplo desde Eclipse. Abre el fichero FtpHandle.java, en él verás que se leen algunas variables del fichero EjemploFTP.jad
Últimamente me han preguntado bastante en relación a la memoria RAM de los módulos gprs TC65 y XT65 (y sus correspondientes terminales) así que voy a poner un pequeño artículo en relación a este tema.
Como sabéis el módulo TC65 tiene un total de 400KB de memoria RAM y 1.7MB de memoria FLASH. Es evidente que la memoria flash, FFS (File Flash System, el sistema de archivos) estará en parte ocupada por nuestra aplicación java (es decir, por los ficheros .jad y .jar) y por todos aquellos archivos extra que necesitemos para nuestra aplicación así como los propios archivos generados por nuestra aplicación java, es decir, ficheros con logs, históricos, etc etc …
Bueno … con 1.7MB puedo hacer un programa inmenso y me sobra ¿para qué me voy a perder el tiempo leyendo esto?
Es cierto que puedes hacer programas bastante grandes pero va a depender mucho de cómo los hagas y de las herramientas que estés utilizando. Si no estructuras bien tu programa puedes llegar a tener problemas serios de memoria.
Mi compañero Jesús Santos, gran experto en GPS y GSM, me ha enviado esta mañana una noticia por email que no me puedo resistir a publicar. Además ha tenido el detalle de escribirlo en el estilo que me gusta, a modo pregunta / respuesta.
Y es que se anuncia que, después de muchos años de pruebas e historias, el sistema EGNOS está por fin operativo.
Muy bien, ¿y qué es esto del EGNOS?
Pues son 3 satélites geoestacionarios (dícese de aquellos que giran a la misma vez que la tierra, es decir, que siempre están en el mismo punto) colocados entre el Océano Atlántico y Europa. Son satélites añadidos a los ya existentes del sistema GPS, es decir, no los substituyen, los complementan.
Estos satélites son controlados por 40 estaciones terrestres con las que hablan. Actualmente estos satélites son gestionados por la Agencia Espacial Europea (ESA)
¿Y de qué hablan, del tiempo, de salud?
Pues sí, más o menos. Las estaciones terrestres envian a estos 3 satélites, información del resto de constelación de satélites GPS y sobre la salud de los mismos, desviaciones de su ruta y sobre todo, los cálculos de correcciones de estas órbitas, de timing, correcciones debidas a la atmósfera (más concretamente la ionosfera), etc. Estos tres satélites geoestacionarios después, con todos los datos, hacen sus cálculos y nos envían una información más fiable sobre el sistema GPS.
Hace unas semanas puse un post sobre compresión de archivos en j2me con los módems Cinterion TC65 y XT65. Puse un ejemplo de cómo comprimir archivos para posteriormente realizar una conexión GPRS y enviar así menos datos (más barato y más rápido).
Quedaba pendiente el tema de la descompresión de archivos. Es decir, si con un módem gprs comprimimos un archivo y lo enviamos a un servidor central, luego, en este servidor, en algún momento tendremos que descomprimir el archivo para poder procesar los datos.
Esto puede hacerse de manera sencilla (en Windows) usando una DLL gratuita de nombre zlibwapi.dll.
Con esta librería es muy sencillo crear un programa de descompresión de datos. Aquí os dejo un programa muy simple hecho en VB6 que permite comprimir (de la misma manera que lo haría el módem) y descomprimir archivos. Es un programa muy simple de uso de esta DLL que os comentaba.
¿Que qué tipo de aplicaciones? pues por ejemplo una aplicación podría ser un datalogger, ó un tracker GPS, o cualquier otra aplicación que precise de ir guardando un log (un fichero) con ciertos datos capturados periódicamente. Evidentemente si estamos trabajando con módems GPRS es para transmitir los datos en algún momento. Cuando llegue el momento de transmitir vía GPRS los datos almacenados en el módem a un servidor central, en función del tamaño del fichero de datos que estemos manejando, puede ser bastante interesante comprimir los datos antes del envío.
¿Por qué puede ser interesante comprimir los datos?
Pues básicamente por dos motivos. Uno es por el ahorro de tiempo en el proceso de envío. El otro es por cuestiones económicas, pues, recordemos, en la mayoría de los casos los operadores de telefonía facturan por volumen de tráfico, es decir, cuantos más datos transmitamos más pagaremos.
www.blogElectronica.com
¿Y cómo comprimo ficheros con J2ME?
Pues lo primero que se nos suele ocurrir a todos es empezar buscando si J2ME tiene alguna clase que nos facilite esta tarea. Lametáblemente pronto uno se da cuenta de que no, que J2ME no tiene estas clases debido a sus limitaciones (recordemos que j2me está pensado para dispositivos con poquitos recursos). En cambio J2SE (java standard edition) sí que las tiene. Con la edición completa de java basta con usar el paquete java.util.zip. para gestionar fácilmente la compresión de archivos. Viendo esto último, lo siguiente que a uno se le ocurre es “pues venga, voy a ver si puedo adaptar estas clases de J2SE para intentar que me funcionen en J2ME”. Pero tras unas horas gastadas en el intento uno acaba viendo que no va a ser tarea fácil, pues se utilizan ciertas clases nativas de Zlib.
Así que toca ponerse a investigar alternativas … Poca cosa aparece en Internet googleando acerca de la compresión con J2ME y mucho menos si buscamos algo relacionado con compresión y módems GPRS, así que creo que en este post aterrizarán bastantes navegantes. Bueno, tras buscar un rato, uno llega al proyecto JZLib (en la web http://www.jcraft.com/jzlib/) un proyecto de software libre donde han realizado una re-implementación de ZLIB. Podéis obtener toda la información que queráis de esa web, yo no voy a entrar en detalles.
¿Y funciona? ¿Podemos comprimir archivos dentro del módem usando esa librería?
Pues sí, funciona :)
A continuación os voy a poner un ejemplito java que funciona en un módem TC65 ó MTX65. Lo podéis descargar haciendo click aquí. El ejemplo básicamente lo que hace es comprimir el texto: “en la granja de mi tia iaiaooooooooooooooooooooooooo” y guarda el resultado final, es decir, el texto comprimido, en un fichero (en la memoria flash interna del módem) con el nombre “datos.z”. Si véis el código fuente del proyecto podéis ver que he puesto todos los archivos .java de la librería de compresión en el mismo proyecto. Obviamente se podría haber utilizado como librería pero para que nadie se me pierda y pueda probar el ejemplo sin dificultad lo dejo así.
¡Funciona! Me ha comprimido el texto en un archivo. Pero si luego saco el archivo comprimido del módem con el MES y me lo llevo a mi PC no soy capaz de descomprimirlo con el WinZip.
No va a funcionar con WinZip puesto que únicamente se ha creado un fichero con los datos comprimidos, es decir, ZLIB comprime el archivo pero si quieres utilizar el winzip tendrás que construir la estructura de los ficheros ZIP, con sus cabeceras y demás. (http://www.pkware.com/products/enterprise/white_papers/appnote.html).
Uff, que difícil lo de las cabeceras ZIP. ¿No se puede descomprimir de otra forma?
Pues sí, con un descompresor ZLib. Pero eso lo pondré en otro post dentro de unos días (el Domingo seguramente). Intentaré poner un programita hecho en VB6 (con código fuente, por supuesto, para que lo podáis utilizar) que sea capaz de descomprimir los ficheros generados por el módem. De esa manera tendréis todo lo necesario para poder comprimir un archivo con el módem, enviarlo vía GPRS y descomprimirlo después en nuestro servidor.
Bueno, espero que os haya interesado el post y que os sea útil algún día, me voy a cenar.
Aquí cuelgo para quien lo necesite la versión 1.1 (beta por el momento) del software OTAP para la actualización remota del software java de los módems gprs Siemens / Cinterion, como comentaba en un post anterior.
He añadido algunas cositas con respecto a la versión previa 1.0. Por ejemplo, quien quiera probar/usar la aplicación y no tenga un servidor HTTP para poner sus archivos JAD y JAR le dejo usar mi servidor. Para ello fijáos en la pantalla principal de la aplicación:
Arriba, a la derecha, puedes ver un botón “Upload”. Si haces click en el aparerá una pantalla como esta:
Aquí basta con que selecciones tu fichero JAD y tu fichero JAR y pulses el botón que indica “Subir archivos”. Los archivos se subirán automáticamente a: http://www.otap.es/temp/ y será la ruta (URL Jad) que deberás indicar en la aplicación (como puedes ver en la primera imagen de este post).
¿Qué no tienes ahora ningún fichero .JAD y .JAR para probar la aplicación? No te preocupes, aquí te pongo unos. Cuando te bajes los ficheros abre con el bloc de notas el fichero .JAD y fíjate en la ruta del fichero .JAR, te lo comento para que lo tengas en cuenta cuando generes los tuyos, que la ruta al fichero .JAR debe ser correcta.
Hace tiempo que no escribo en el blog. Han sido unas semanas bastante intensas para mí en las que no he podido sacar apenas tiempo para nada, y es que el trabajo y algunos proyectos personales que quería llevar a cabo me han quitado todo el tiempo.
En cuanto al trabajo algunos ya sabéis por qué, pues hemos tenido la ocasión de vernos las caras. Para quien no lo sepa, he estado junto con tres compañeros (Jesús, Daniel y Carmen) trabajando en lo que llamamos en Matrix ”Jornadas Tecnológicas” (aunque nosotros lo conocemos internamente como RoadShow ) y que consiste en unas pequeñas charlas y sobre todo demostraciones prácticas de muchos tipos de equipos electrónicos y que en mi caso han sido equipos RF (equipos bluetooth, 868Mhz, Zigbee, …) Estuvimos en 6 ciudades, por orden fueron Zaragoza, Barcelona, Bilbao, Madrid, Valencia y Sevilla. En todos los sitios tuvimos la gran suerte de encontrar a gente superagradable e interesante. Y es de agradecer, porque estar cada día en un sitio distinto la verdad ha sido agotador.
Y como decía al principio también he estado acabando proyectos personales que tenía empezados desde hace bastante tiempo. El que voy a mostrar hoy es una primera versión de un software (o plataforma) para realizar OTAP en módems gprs Siemens/Cinterion. (Para los despistaos que no sepan que es un OTAP decir brevemente que es un proceso mediante el cual podemos actualizar remotamente (sin desplazamientos) los programas java que tengamos embebidos en nuestros módems gprs Cinterion TC65, XT65 o sus terminales MTX65 ó TC65T. Podéis encontrar más información aquí, pues he hablado otras veces).
Mediante esta plataforma es muy sencillo realizar un proceso de actualización remota (OTAP) a un módem o a un grupo de módems gprs (hasta 1000, si alguien necesita más que me lo diga). Básicamente lo que hace la plataforma es enviar los SMS apropiados y debidamente codificados en PDU a todos los módems a los que pretendamos actualizar el software y también se encarga de comprobar si el proceso de OTAP acabó de forma satisfactoria. Para esto último se apoya en un servidor que tengo contratado (todavía me faltan por acabar cosas) en www.OTAP.es
Como siempre digo, una imagen vale más que mil palabras, así que aquí pongo un vídeo que muestra de forma sencilla como funciona este software:
Debo decir que ésta es una herramienta que quien la necesite la puede usar de forma totalmente gratuita durante todo este año. A lo largo del año 2010, dependiendo del volumen de uso que tenga es posible que haga una versión gratuita (limitada en prestaciones) y una de pago. (Nada …, poquita cosa …, hace ya años que sé que no me voy a hacer rico con la electrónica, simplemente para compensar un poco las horas que he dedicado y porque el servidor tiene un coste y tampoco es plan que lo financie yo todo, que sino mi chica se me enfada )
La primera versión beta del software OTAP (v1.0) la colgaré enseguida, cuando acabe unos detalles que me faltan, pondré otro post. Espero que sea durante esta semana que empieza y que resulte de interés. Cualquier duda / sugerencia ya sabéis, me la contáis y encantado de poder ayudar.
En muchas ocasiones podemos tener la necesidad de utilizar el FFS (File Flash System) de nuestros módems gprs CinterionTC65 ó XT65 para realizar volcados de datos a ficheros. Ejemplo típico es el caso del XT65 y las posiciones GPS. Vamos leyendo las posiciones GPS cada X segundos y las vamos almacenando en un fichero para su posterior envío a la central. Ejemplos de este tipo hay muchos tanto para el TC65 como para el XT65.
Es fácil caer en la tentación de ir generando ficheros en la memoria Flash para el almacenaje de información. Creando ficheros y borrándolos cuando los consideremos procesados (por ejemplo, cuando los hayamos enviado por GPRS a la central o simplemente borrándolos cuando ya no los consideremos necesarios).
Realmente es la manera más sencilla de realizar una aplicación (creamos ficheros y los borramos cuando no los queremos) pero debemos tener precaución con esta técnica. Escribir datos en la memoria flash del módem no es problema, éstos se graban byte a bye (ya que la memoria FLASH de los Siemens es de tipo NOR que a diferencia de las tipo NAND la grabación puede hacerse incluso bit a bit. Con las NAND, más baratas pero también más malillas, la grabación es por bloques). El proceso de borrado, en cambio, SÍ es crítico, porque tanto con las NOR como con las NAND se realizan por bloques. El tamaño del cluster en la flash del módem es de 64KB, eso implica que cuando borramos un archivo realmente estamos borrando un bloque de 64KB. Así es, aunque borremos un fichero que tan solo contenga 100 bytes de datos en realidad estamos actuando sobre 64KB en la memoria flash del módem.
Si desarrollas aplicaciones en Java para los módems gprs TC65, XT65 (o sus terminales MTX65 o MTX65+G distribuidos por Matrix), tal vez pueda interesarte en alguna ocasión debugar tu aplicación de la manera que te voy a indicar aquí.
Como ocurre (o debería ocurrir) al final del desarrollo de cualquier programa, hay una fase de test, una fase en el que se debe probar a fondo la aplicación en busca de cualquier tipo de error que hayamos podido cometer. Si lo errores en nuestra aplicación son fácilmente reproducibles los encontraremos de manera relativamente sencilla, pero en ocasiones puede haber errores que se deban a un cúmulo de cosas o debido a unas situaciones muy concretas que no se reproducen en el laboratorio y sí en la calle.
Depurar este tipo de problemas puede llegar a ser realmente complicado, ya que si se producen de forma muy ocasional son difíciles de localizar.
Si has trabajado alguna vez con los GPIO de los módems CinterionTC65 o XT65 ( o sus terminales MTX) habrás comprobado que hay varias formas de trabajar con ellos. Hay comandos AT que nos permiten configurar un determinado GPIO como entrada o como salida y hay otros comandos AT que nos permiten saber el estado de un GPIO configurado como entrada (si hay un 1 ó un 0) o bien nos permiten cambiar el estado de una salida.
En uno de los ejemplos java que he ido poniendo por este blog, concretamente en el EJEMPLO_GPIO, utilizaba simplemente el comando AT^SGIO que devuelve el estado del pin en ese momento. Depende de la aplicación que queramos llevar a cabo puede ser suficiente con este comando AT, pero lo normal no es utilizar este sistema ya que la “frecuencia de barrido” que podemos conseguir es muy baja (además de cargar el sistema) y por tanto resulta muy complicado detectar cambios muy pequeños en el estado de un pin de entrada, es decir, que si por ejemplo tienes que detectar el pulso de detección de un volumétrico a lo mejor no lo cazas.
Lo mejor que puedes hacer para detectar los cambios de estado de las GPIOs es utilizar el polling. De esta manera el módem te devuelve un mensaje URC cada vez que se detecta el cambio en uno de sus GPIOs.
Veámoslo con un ejemplo. Imagina que quieres controlar las entradas GPIO1, GPIO2, GPIO3 y GPIO4 ¿Cómo lo hacemos?
Pues lo primero es habilitar los GPIOs, para ello enviamos:
AT^SPIO=1
Después configuramos los pines GPIO1, GPIO2, GPIO3 y GPIO4 como entradas, para ello:
AT^SCPIN=1,0,0
AT^SCPIN=1,1,0
AT^SCPIN=1,2,0
AT^SCPIN=1,3,0
Tras ello creamos un puerto, es decir, un puerto con todos aquellos GPIO que queramos involucrar en el polling:
AT^SCPORT=0,1,2,3
Al enviar este comando el comando AT nos devolverá un IDPort (un identificador de puerto), por ejemplo nos devuelve IDPort = 112
Y ya lo tenemos todo listo para activar el polling. Lo activamos haciendo:
AT^SCPOL=1,112
De esta manera cada vez que haya un cambio en una de las GPIO, el módem nos enviará un URC del estilo:
^SCPOL: 112, x
donde x puede valer de 0 a 1024, es decir, devuelve el estado de los 10 posibles GPIO que puedes controlar con el módem TC65.
Bueno, otro día más, ahora me voy a preparar la cena, que hoy dan CSI las vegas y es de la poca TV que veo en toda la semana. Y es que, la verdad, noto que cada vez me gusta menos la tele. ¿Me estaré haciendo mayor? :S
Puedes comentar este post en el nuevo Foro (click aquí)
Entradas (RSS)