Bueno, pues se acaban las vacaciones … Han sido 3 semanas durante las cuales he aprovechado para descansar y desconectar (este año realmente lo necesitaba más que nunca) La primera semana nos quedamos en casa en Cardedeu (Barcelona). Fuimos algunos días a la playa (la tenemos a unos 15km de casa) y aproveché también algunas tardes para terminar cosas pendientes de ciertos negocios personales que tengo entre manos.
La segunda semana de vacaciones nos fuimos a Francia, dirección a Eurodisney. Alex, que ahora en Septiembre hará 4 años, llevaba 3 meses, desde que decidimos ir allí en vacaciones, nervioso con unas ganas tremendas de ir. Se le iluminaba la cara con una sonrisa de oreja a oreja cada vez que se lo recordábamos, así que el día que partimos hacia allí os podéis imaginar lo contento que estaba.
Quien me conoce bien sabe que no me gusta nada volar y evito los aviones siempre que puedo, así que, aprovechando que Sonia tenía desde hace tiempo ilusión por visitar algunos castillos del Valle del Loira (Francia) pues fuimos en coche haciendo algunas etapas. El primer día visitamos e hicimos noche en Limoges, un lugar conocido por su bonita porcelana. Entre nosotros, mi un rollo patatero. El siguiente día fue más entretenido pues visitamos un par de bonitos castillos. Por la mañana visitamos el castillo de Villandry. Un castillo muy curioso y famoso por sus jardines, de hecho los llaman los jardines de Francia. Lo que más me sorprendió de sus jardines es que parte de ellos están hechos con verduras (si, lechugas, coliflores, …) y la verdad es que la armonía del conjunto quedaba muy bien. Ese castillo puede visitarse en cualquier estación del año y en cada una de ellas presenta, obviamente, un aspecto diferente.
Por la tarde visitamos otro castillo, el castillo de Chenonceau. Un castillo más grande que el de Villandry y también con bonitos jardines (aunque no tan curiosos como el anterior). Este castillo, además de ser bonito y de tener un interior muy cuidado con mobiliario de la época, tiene como característica peculiar que está construido sobre un lago, al menos parte de él.
¿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.
Hoy voy a poner un artículo sobre el proceso de carga de las baterías de plomo. Es un artículo que no he hecho yo, sino es una interesantísima traducción que se ha currado hace unos días mi compañero Jesús Santos y me parece oportuno ponerlo aquí.
El artículo original es de la empresa Silver Telecom (cuyo distribuidor en España es Matrix), una empresa que fabrica módulos POE, COIC, SLIC y módulos cargadores de baterías. En el artículo se muestra cuales son las diferentes técnicas para cargar baterías de plomo y muestra qué combinación de técnicas usaría el cargador óptimo que maximizase la vida de las baterías. Ese es el pequeño módulo AG102 que han creado los chicos de Silver.
Aquí tenéis el artículo …
Las baterías selladas de plomo son usadas en múltiples aplicaciones y equipos, pero la carga de ellas es un proceso complejo.
Cargar baterías de plomo (SLA, Sealed Lead Acid) no parece ser un proceso difícil, pero lo realmente complicado es maximizar la vida de la batería. Uno puede usar los simples cargadores de corriente constante o tensión constante, como puede ser conectándola a una fuente de alimentación. La batería se acaba cargando, pero la duración de su vida, los ciclos de carga y descarga que especifica el fabricante se acortarán sustancialmente. Para conseguir la vida esperada de la batería, deben usarse cargadores inteligentes, lo que al final se traduce en un importante ahorro de costes (y por supuesto, cuidamos el medio ambiente).
Antes de entrar en detalle de las diferentes técnicas de carga, es importante conocer los procesos químicos internos de la batería y qué es lo que ocurre en los ciclos de carga y descarga.
Típicamente, una batería de plomo sellada (SLA) está fabricada con placas de dióxido de plomo (PbO2) conectadas al polo positivo y con placas de pomo (Pb) que se conectan al polo negativo. Un electrolito, normalmente ácido sulfúrico (mezclado con un gel), separa y aísla las placas.
¡Pero que poco para las vacaciones! . La verdad es que este año las necesito de verdad. En esta ocasión me cojo las tres últimas semanas de Agosto. Además de la visita obligada al pueblo, mi chica (y ya mi hijo, que con tres años, para cuatro, habla más ya que una cotorra) me han liado para irnos unos cuantos días a Eurodisney.
En fin, hoy, muy brevemente, voy a presentar un nuevo módulo GPS que me ha llamado la antención pues tal vez sea de interés para aquellos que en la actualidad estéis utilizando módulos GPS de uBlox, en concreto me estoy refiriendo a los modelos GPS ublox LEA-4 y LEA-5.
Se trata del nuevo módulo GPS de Fastrax IT350 (distribuido por Matrix en España). Éste es un módulo como digo compatible con la huella de los GPS LEA4 y LEA5 de uBlox (mismo tamaño, 22.4×17.0×2.3mm), pero con mejores prestaciones. Por ejemplo, el consumo es mucho menor, pues estamos hablando de un consumo de 75mW frente a los 120mW del uBlox. Si hablamos de la sensibilidad, ésta también es mejor, -143dBM frente a -142dBM. A nivel de precio, otra “prestación” bastante importante en los tiempos que corren ;), el Fastrax IT350 es bastante más económico que el LEA4.
¿Y puedo substituir en cualquiera de mis equipos un GPS LEA-4 ó LEA-5 por un IT350?
Pues en la mayoría de los casos sí, aunque no en todos. Por ejemplo no es posible substituir el LEA4 por el IT350 si en nuestros circuitos estamos alimentando el módulo GPS con una tensión inferior a 3V (el fastrax necesita una alimentación de entre 3V y 3.6V). Evidentemente tampoco vamos a poder hacer una substitución directa si estamos utilizando el protoloco binario UBX propio de los módulos de UBlox, ni tampoco si se está utilizando el bus SPI (en el caso del LEA-4) o el I2C en el caso del LEA-5.
Aquí van unas fotos del módulo para quien tenga curiosidad:
Si realizas aplicaciones con módems GPRS en muchas ocasiones te habrás encontrado con el problema de que las direcciones IP asignadas por el operador de telefonía son dinámicas.
¿Que qué es una IP dinámica? Pues significa que cada vez que uno de tus módems se conecte a la red GPRS el operador le va a asignar una dirección IP distinta.
En muchas aplicaciones puede no tener importancia, por ejemplo, si yo tengo un módem que recoge datos de un datalogger y al final del día el módem los envía por GPRS a un servidor central pues importa poco que la dirección IP del módem sea dinámica, pues en este caso es el módem quien realiza la conexión hacia un servidor central (que si debe tener una dirección IP fija, o al menos una DNS).
El problema viene cuando queremos trabajar con módems GPRS en modo servidor, es decir, con módems que permanecen conectados a GPRS de forma permamente y que permanecen a la escucha en un determinado puerto TCP a la espera de conexiones entrantes (típico telemantenimiento). En esta situación es necesario conocer la dirección IP de los módems. Hay varias soluciones para resolver este problema, hoy voy a comentar una de ellas, el servicioDynDns.
Con DynDns es posible, gratuitamente, asignar una determinada IP a una DNS. Para ello basta abrise una cuenta en www.dyndns.org.
Veamos un ejemplo concreto.
No voy a poner un ejemplo en java sino que lo vamos a ver directamente con comandos AT. Hacerlo con java a partir de lo siguiente es prácticamente igual si usamos la clase ATCommand.
Imaginemos que tenemos creada nuestra cuenta en DynDns.org con los siguientes datos:
servidor DNS: members.dyndns.org host: blogelectronica.dyndns.org login: miLogin password: miPassword IP actual: 80.100.101.102 (la IP que me ha asignado el operador)
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.
No lo he comentado hasta ahora por falta de tiempo pero hace ya unos días abrí una nueva sección en blogElectrónica, concretamente un foro. Un foro que está integrado en el blog (es decir, dentro del mismo dominio blogElectronica.com) al cual se puede acceder desde el link de arriba a la derecha de la página (donde pone Foros). Esta integración con el blog me permite poder relacionar de manera más sencilla el blog con el foro.
La razón de incorporar un foro es porque el número de comentarios por post está creciendo demasiado y en algún momento tengo que pararlo. En algunos posts hay cientos de comentarios y al final es realmente difícil encontrar información de forma sencilla, pues el motor de búsqueda del blog (basado en wordpress) no está demasiado desarrollado para mi gusto.
En cambio la capacidad de búsqueda del foro es bastante mejor y es por ello que dentro de poco si quieres hacer un comentario a un post tendrás que hacerlo obligatoriamente a través del foro. Yo pondré los post explicativos aquí, como siempre, pero los comentarios se tendrán que hacer a través del foro. A la larga creo que todos saldremos ganando con un mejor acceso a la información.
Para poder participar en el foro hace falta registrarse. Unicamente es necesario un Nick y un email. Tras el registro recibirás un email con la contraseña (luego se puede cambiar en el perfil de usuario). Luego basta con hacer click en el link del email recibido, logarse y a participar.
Por el momento he abierto 4 secciones en el foro. Iré abriendo más. Si a alguno os interesa una sección específica no os cortéis y comentarlo, es el momento.
Lo único malo es que el foro tarda un poquito más que el blog en cargar las páginas. La razón es el hosting que tengo en Godaddy (EEUU). Es económico, pero a la vez lento. A ver si cuando salgamos de la crisis me puedo permitir otro mejor
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.
Hola de nuevo. Muchas veces me han preguntado si tiene batería el MTX65 y si no tiene cómo se puede poner una pequeña batería que aguante en caso de cortes de corrientes, permitiendo tener siempre activo el módem.
Pues bien, para aquellos que les pudiese interesar os presento un nuevo accesorio de los MTX que permite dicha función: el MTX-T ACC Battery Pack.
Como véis en la foto es un pequeño dispositivo con dos bocas RJ12. En una boca, la marcada con “Terminal” con un latiguillo RJ12-RJ12 (como el que aparece también en la foto) conectaremos el terminal MTX65 y en la otra boca RJ12 el alimentador (el mismo que utilizamos con los MTX, que da 12VDC).
En su interior hay una batería que entra en funcionamiento en el momento que se produce un corte de corriente, lo que garantiza el suministro durante unas cuantas horas.
Las especificaciones básicas del equipo son estas:
TECHNICAL DATA
• Ni-MH battery pack
• 8,2V, 2000 mAh
• 11-30V DC
• U-Charge: 11-24Volt 350 mA 6h
• Discharge: max. 600 mA 1A 5sec.
• 100% Cutoff
• Dimensions approx: 60 x 125 x 25 mm
La capacidad es de 2000mAh. El MTX65 (sin transmitir, en idle mode) tiene un consumo aproximado de 20-30mA, si mi memoria no me falla. Basta dividir para hacerse una idea de la duración de la batería en horas en ese modo.
Y ya que estoy hablando de baterías para los MTX, otra opción, no tan cómoda al no tener conectores RJ12 pero sí bastante más económica es usar la fuente SP-AS/AL de Array. La función es similar, pero la batería en este caso no está incluida, es decir, es externa y debes ponerla tú. Otras ventajas de esta fuente es que es carril DIN y que la entrada directamente es 220VAC, es decir, no es necesario el alimentador 12VDC.
Bueno, por hoy vale, que todavía me dura el cansancio del finde, que ha sido de excursiones continuas. Y es que se acerca mi cumple y me he comprado un caprichito (bueno, un caprichazo) por eso de llevar mejor los años, que cada año suman uno sin piedad. Así que este fin de semana hemos estado, mi chica y el peque con la nueva adquisición y yo con mi vieja yamaha Blaster (quad), haciendo muchos pero que muchos kms. La verdad es que se lo pasaron realmente bien, que es lo que más me gusta. Foto1, foto2, foto3. Otro día más.
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í.
Puedes comentar este post en el nuevo Foro (click aquí)
Entradas (RSS)
