Posts Tagged “tc65”

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.


Puedes comentar este post en el nuevo Foro (click aquí)

- (1) Posts
Etiquetas: , , , , , ,

Comments 5 Comentarios »

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.
 

battery-tc65

 
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.
 

battery-mtx65

 
Os pongo el datasheet aquí.

 
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, foto3Otro día más. ;)

Etiquetas: , , , ,

Comments No Hay Comentarios »

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.

Blog de Electrónica Avanzada

  Lee el resto de esta entrada »

Etiquetas: , , , , , , ,

Comments 2 Comentarios »

Si has trabajado alguna vez con los GPIO de los módems Cinterion TC65 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.

modem-entrada-digital

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

Etiquetas: , , ,

Comments 9 Comentarios »

Tal vez tenía que haber puesto un artículo como el que voy a poner hoy hace ya tiempo, realmente es algo que he comentado bastantes veces en respuestas a preguntas de los usuarios de este blog. Es referente al tema del autobauding y el java.
  
Básicamente lo que quiero decir en este artículo se resume en una línea: si vas a usar java con un módem TC65 o XT65 (o los terminales MTX65 / MTX65+G) no utilices autobauding. Para quien no lo sepa, autobauding es una características de los módems, activable con at+ipr=0, que permite no tener que establecer una velocidad del puerto serie fija al módem, sino que éste, al recibir los primeros datos por el puerto serie “averigua” la velocidad de los datos y se configura para trabajar a esa velocidad).
  
Utilizar autobauding está muy bien en muchas circunstancias, es muy cómodo, pero puede inducir a errores cuando trabajas con Java. Y es que Java y autobauding no se quieren.
 
  
java-autobauding
 
 
¿Y cuales son los problemas?
  
Pues los problemas son varios:
Etiquetas: , , , , , , , ,

Comments No Hay Comentarios »

 

Hoy voy a comentar por encima un parámetro importante del comando AT^SCFG, posiblemente el comando más importante de los módems Siemens / Cinterion. El parámtro en cuestión es el AUTOEXEC, presente en multitud de módems de Siemens / Cinterion, como el TC65, TC63, XT65 y sus correspondientes terminales, el MTX65, MTX63 y MTX65+G distribuidos por Matrix.
 
 
¿Y a grandes rasgos, qué se puede hacer con autoexec?
  
Pues básicamente permite la ejecución automática de comandos AT. Por ejemplo permite ejecutar comandos AT al arrancar el equipo, o ante un determinado evento, o al cabo de x segundos tras arrancar el equipo, o incluso de forma periódica.
 
  
¿Y para qué puedo necesitar ejecutar comandos AT de forma automática?
 
Hombre, ejemplos y situaciones hay muchos. Se me ocurren varios. Imagina un MTX63 junto a un PLC que utilizas para conectarte en ocasiones a través de una llamada CSD desde la oficina para realizar alguna tarea de mantenimiento. En la mayoría de instalaciones que conozco con otros módems que no disponen de autoexec las tarjetas SIM no se configuran con PIN, por ejemplo por que si se va la luz no hay manera de introducir el comando AT+CPIN de nuevo para desbloquear el equipo. Con el autoexec puedes hacer que el equipo al arrancar automáticamente envíe el comando AT+CPIN. De esa manera evitas que alguien te pueda robar la SIM y utilizarla a discrección al no tener PIN.
¿Más ejemplos? pues por ejemplo te puede servir para resetear el módem automáticamente cada x horas. Hay usuarios que por seguridad utilizan programadores horarios externos para resetear los equipos 1 vez al día (cualquier marca de módem gsm, para evitar posibles problemas de red, …). Pues esta operativa es fácil de implementar con el parámetro autoexec para enviar el comando AT+CFUN=1,1 una vez al día.
 
cinterion-autoexec
Etiquetas: , , , , ,

Comments 6 Comentarios »

 

Hoy voy a hablar de un nuevo terminal, del nuevo módem gprs MTX65-ULP, basado en un TC65 Siemens / Cinterion.

El MTX65-ULP es un terminal prácticamente igual a ya muy conocido MTX65, pero con la salvedad de que puede funcionar en modo ultrabajo consumo. De ahí las siglas ULP  (Ultra Low Power).

Alguno dirá  ”bah, el MTX65 ya tiene modos de funcionamiento de bajo consumo…”   Bueno, sí, pero aunque en este último desconectes la radio (modo airplane) y aunque actives el modo de bajo consumo  seguirás consumiendo alrededor de 9ma-10ma.   Esta cifra puede parecer poco, pero realmente no lo es. Para un sistema que necesite estar alimentado a base de baterías 10mA es una barbaridad, pues haría que una batería agote su carga rápidamente a los pocos días. No es operativo.

 modem-gprs

¿Y cuanto consume el MTX65-ULP?

Pues en funcionamiento normal o de bajo consumo igual que el MTX65. La diferencia radica en el nuevo modo ULP. En este modo de funcionamiento el consumo es de tan sólo 2.5uA, es decir, un consumo unas 3000 veces menos que el modelo MTX65 en el modo de funcionamiento de menor consumo. Esto, evidentemente, hace que se alargue la vida de las baterías enormemente.

  Lee el resto de esta entrada »

Etiquetas: , , , , ,

Comments 7 Comentarios »

En bastantes ocasiones me ha llegado la pregunta de cómo añadir más datos a un fichero ya existente dentro de la memoria flash de nuestros módems TC65 o XT65 (o de los terminales MTX de Matrix). Por ello hoy voy a poner un pequeño programa java para que ayude a quien no sepa cómo hacer esto. Es muy sencillo.

Básicamente consiste en utilizar el objeto OutputStream en lugar de DataOutputStream (DataOutputStream hereda de OutputStream) que seguro visteis en el post donde tengo la mayoría de los ejemplos java.

Vamos con el ejemplillo de hoy. Vamos a suponer que tenemos un fichero en el sistema de ficheros del módem de nombre “A:/fichero.txt” y con el texto “hola“, por lo que si no lo tienes, crea uno y ponlo dentro del módem.

Blog de Electrónica Avanzada

Lee el resto de esta entrada »

Etiquetas: , , , , , , ,

Comments 7 Comentarios »

Esta mañana he hecho un test muy básico comparando la ejecución de un mismo programa en un módulo gprs TC65 (versión 3 de firmware) y en en el nuevo módulo TC65i, del que posteé hace un tiempo. Acordáos que el TC65 monta un micro ARM7 y el nuevo TC65i monta un ARM9.

Lo que he hecho es un programa supersencillo, simplemente para comparar de manera empírica y muy básica la velocidad de ambos módulos. Una vez compilado el programa lo he ejecutado en ambas plataformas (la misma compilación, no he recompilado nada).
  

velocidad-tc65i

 
Este es el programilla:
  

long contador=0, i=0, inicio=0, fin=0;
inicio=System.currentTimeMillis();
System.out.println(“Inicio TC65: ” + inicio);
for (i=1;i<10000000;i++)
{
     contador++;
}
fin=System.currentTimeMillis();
System.out.println(“Fin TC65: ” + fin);
System.out.println(“Diferencia TC65 (Fin-Inicio): ” + (fin-inicio));

 

Un programa que lo único que hace es realizar 10 millones de sumas y calcular los milisegundos que tarda en hacerlas.

Estos han sido los resultados de ejecutar 4 veces el programa en cada módem:
   
Lee el resto de esta entrada »

Etiquetas: , , ,

Comments 2 Comentarios »

Feliz nuevo  año a todo el mundo. Mientras me bajo una demo del Warhawk para la PlaySation3que me han traido los reyes por ser muy bueno el año pasado :) )  voy a poner un pequeño artículo que posiblemente le resulte útil a más de uno en alguna ocasión.

El artículo es válido para los módems gprs TC65, TC63 y XT65 y para sus respectivos terminales MTX65, MTX63 y MTX65+G que son distribuidos en España por Matrix.

En ocasiones puede que nos sea neceario utilizar el AUTOEXEC del comando AT^SCFG, para temporizar tareas que queramos realizar. No voy a entrar ahora en detalle del comando AUTOEXEC , de que ya habñaré en breve en otro pequeño artículo. Pero digamos que queremos utilizar el AUTOEXEC para, por ejemplo, lanzar un programa java (comando AT^SJRA) a una hora determinada o para resetear el módem (AT+CFUN=1,1) cada x horas o para lo que queramos. 

 

navidad 2009

Lee el resto de esta entrada »

Etiquetas: , , ,

Comments 8 Comentarios »