Lo podéis descargar haciendo click aquí.

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.
 
Espero que te sea útil la aplicación.

P.D. Este va a ser el primer post donde quien quiera hacer un comentario deberá hacerlo a través del nuevo FORO.

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

- (1) Posts

Posts relacionados:

1. Plataforma OTAP para módems gprs Siemens - Cinterion Hace tiempo que no escribo en el blog. Han  sido...
2. Localizando fallos difíciles de reproducir en los módems Cinterion TC65, XT65 Si desarrollas aplicaciones en Java para los módems gprs TC65,...
3. Añadir datos a ficheros con módems Siemens-Cinterion desde java  En bastantes ocasiones me ha llegado la pregunta de cómo...

 
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

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

- (1) Posts

Posts relacionados:

1. Acerca de Mi nombre es Jose Gallego y te doy la bienvenida...
2. Reestreno de forumElectronica.com Llevo un par de semanas sin postear. Iba a publicar...

 
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

Posts relacionados:

1. Versión 1.1 de la plataforma OTAP Aquí cuelgo para quien lo necesite la versión 1.1 (beta por...
2. Ejemplo FTP Java para módems Siemens Hoy pongo un brevísimo post con un nuevo ejemplo Java...
3. Cómo obtener la hora con los terminales MTX y módems Siemens / Cinterion Llevo casi un mes sin escribir en blogElectronica. Y es...

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 tenemos en cuenta que que en una memoria Flash es posible realizar unas 100.000 grabaciones y que el tamaño de la memoria Flash del TC65 es de unos 1.7MBytes y tendiendo en cuenta que el tamaño del cluster que es de 64KB, no resulta difícil ver que no debemos abusar del borrado de archivos. Es decir, veamos un ejemplo, si creamos un pequeño fichero de 100 bytes y lo borramos cada minuto,  aproximadamente cada 26 minutos (1.7 / 0.064) hemos “dado un repaso” a toda la flash. Esto significa que al cabo de 100.000 x 26 = 2.600.000 minutos (o menos) nos habremos cargado la flash casi seguro. Cada día tiene 1440 minutos, un año 365 x 1440 = 525.600 minutos, lo que implica que a los 2.600.000 / 525.600 = 4.9 años (casi seguro antes, ya que hay procesos internos del módem que también escriben en flash) nuestro módem morirá. También hay que tener presente que cuando borramos un cluster (por ejemplo para borrar un fichero de 100 bytes que hay en él) en resto de la información que hay en el cluster no se debe borrar, por los que los algoritmos internos del gestor de la FFS del módem deben reescribir la información que hay en él y que no debe borrarse, es decir, más desgaste a la flash para descontar además del riesgo añadido que supone el corte de suministro eléctrico en ese momento de la copia.
 
  
¿Cómo actuar entonces?

En caso de querer utilizar ficheros con nuestra aplicación java debemos evitar en lo posible el borrado continuo de los mismos por lo comentado anteriormente. La mejor forma de evitarnos problemas es crear un fichero en la Flash (o los ficheros que precise nuestra aplicación) e intentar no borrarlos NUNCA. Es decir, por ejemplo, creamos 2 ficheros Log1.txt y Log2.txt y vamos almacenando registros (con registro me refiero, por ejemplo, una trama GPS de logitud fija).

Imaginémonos que nos marcamos un máximo de 5000 registros por fichero. Una vez escribamos los 5000 registros en Log1.txt empezamos a escribir los datos en Log2.txt y ya podemos enviar Log1.txt por GPRS a nuestro servidor central. Tras el proceso de envío de Log1.tx NO borramos el fichero. Cuando hayamos escrito otros 5000 registros en Log2.txt empezaremos a escribir en Log1.txt MACHACANDO sobre el registro 1 y así sucesivamente hasta llegar al registro 5000. Es decir, el truco está en sobreescribir los registros y no borrar los ficheros. Esta es una manera de ahorrarnos, de verdad, problemas desagradables al cabo del tiempo por desgaste de la memoria Flash.

Cuando programamos sobre los TC65 y XT65 debemos pensar que estamos trabajando sobre un módulo embebido y no sobre un Core 2 DUO con HHDD. Que sí, que son unos módulos muy potentes y al programar en java y con sistema de archivos a veces perdemos todos un poco esa perspectiva de módulo embebido, pero debemos tenerlo en cuenta.
 

Espero que encontréis de utilidad este post. Otro día más.

Posts relacionados:

1. Localizando fallos difíciles de reproducir en los módems Cinterion TC65, XT65 Si desarrollas aplicaciones en Java para los módems gprs TC65,...
2. Nuevo firmware v2.0 para los módems Siemens / Cinterion XT65 y MTX65+G Desde la semana pasada está disponible el nuevo firmware del...
3. Añadir datos a ficheros con módems Siemens-Cinterion desde java  En bastantes ocasiones me ha llegado la pregunta de cómo...

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.
 

 
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, foto3.  Otro día más.

Posts relacionados:

1. MTX65-ULP. Módem GRPS Ultra Low Power basado en Siemens/Cinterion   Hoy voy a hablar de un nuevo terminal, del...
2. Ejemplo FTP Java para módems Siemens Hoy pongo un brevísimo post con un nuevo ejemplo Java...
3. Nuevo firmware v2.0 para los módems Siemens / Cinterion XT65 y MTX65+G Desde la semana pasada está disponible el nuevo firmware del...

 
Una forma para intentar averiguar qué ocurre con un programa puede ser tener un hyperterminal conectado al puerto serie para ir guardando las trazas que vayamos sacando mediante System.out.println, pero no parece el método más adecuado para todas las situaciones ¿verdad? Un poco armatoste si tenemos que poner un PC en un coche o en una máquina de vending o donde sea que tengamos nuestro módem …

Una manera alternativa que nos permiten los modems Siemens / Cinterion es redirigir la salida estandard hacia un fichero, es decir, que en lugar de sacar las trazas por el puerto serie del equipo (al hacer un System.out.println) se volcarán en un fichero de texto de tipo log dentro de la memoria flash del módem. De esta manera cuando ocurra el suceso extraño podemos mirar los log e intentar ver en qué método o parte del programa o haciendo el qué tenemos el error. Es muy útil.
 
 
¿Y cómo se hace eso?

Pues con el super comando AT^SCFG.  Con eso comando podemos especificar el destino de la salida estandard (en este caso definiremos un fichero, el tamaño del fichero, el nombre del fichero y el modo de almacenamiento.
 
Cuando definamos el tamaño del fichero hay que tener presente que realmente se crearán dos ficheros. Por ejemplo, si el nombre del fichero es log.txt, se crearán log.txt.0 y log.txt.1.   Cuando log.txt.0 alcance la mitad del tamaño que hayamos especificado se empezará a escribir sobre log.txt.1. De igual forma, cuando log.txt.1 llegue a la mitad del tamaño especificado se escribirá sobre log.txt.0 y así sucesivamente de forma rotativa.
 
En cuanto al modo de almacenamiento tenemos dos modos. El de por derecto, “buffered” y el “secure”. Con “buffered” la salida no se escribe directamente en flash, sino que se almacena de forma temporal en un buffer intermedio (en RAM) y cuando toque (cuando lo diga un timer) se salvan los datos en Flash. En modo “secure” se escribe directamente a Flash. Depende del tipo de situación y la gravedad del problema deberemos de usar uno u otro modo.
 
  
¿Algún ejemplo?

Por supuesto, configurando el módem con:
 

AT^SCFG=”Userware/Stdout”,”FILE”,20000,”a:/log.txt”,”secure”

 
Si después, en algún momento  desde nuestra aplicación java hacemos un:
 

…
System.out.println(”Hola”);
…

 
veremos como en A:/log.txt.0 tenemos el “Hola”.
 
  
Bueno, otro día más. Espero que esto pueda ayudar a alguno que tenga problemas difíciles de descubrir. Yo ahora me voy a poner un rato con una de las tareas que menos me gustan de todo el año, la renta. Y pensar que hay gente que disfuta haciendolas …  (palabra que conozco a un par). 

Posts relacionados:

1. Uso correcto de la Flash de los módems Cinterion TC65 y XT65 En muchas ocasiones podemos tener la necesidad de utilizar el...
2. Añadir datos a ficheros con módems Siemens-Cinterion desde java  En bastantes ocasiones me ha llegado la pregunta de cómo...
3. Versión 1.1 de la plataforma OTAP Aquí cuelgo para quien lo necesite la versión 1.1 (beta por...

Posts relacionados:

1. Bandas para comunicaciones radio sin licencia en la Unión Europea En muchas ocasiones podemos tener la necesidad de desarrollar un...
2. Comunicaciones RF utilizando las WaveCard de Coronis Hoy Sábado vamos a retomar un post que puse ya...
3. Conversor serie RS232 Bluetooth   Para variar un poquillo, hoy me salgo del tema...

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.

 
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

Posts relacionados:

1. Plataforma OTAP para módems gprs Siemens - Cinterion Hace tiempo que no escribo en el blog. Han  sido...
2. Clases java InPort y OutPort para los módems gprs Cinterion y terminales MTX Como vimos hace ya un tiempo, con las nuevas versiones...
3. Parámetro Autoexec de los módems Siemens / Cinterion   Hoy voy a comentar por encima un parámetro importante...

Espero que los que os vayáis a unir a la ya gran familia de usuarios / programadores de módems Siemens/Cinterion y terminales MTX (que la verdad, ya somos muchísimos) encontréis el post de utilidad. Otro día más
  
  

Posts relacionados:

1. Añadir datos a ficheros con módems Siemens-Cinterion desde java  En bastantes ocasiones me ha llegado la pregunta de cómo...
2. Autoarranque de aplicaciones Java en módems Siemens Muy buenas. Hoy voy a poner un pequeño post relacionado con...
3. Ejemplos Java para módems de Siemens A lo largo de los últimos meses he ido poniendo...

Para variar un poquillo, hoy me salgo del tema de GSM y nos vamos a Bluetooth. Hoy voy a comentar un producto que conozco desde hace poco pero que es bastante interesante, muy útil para algunos proyectos.  Se trata del módulo LM-048 de la casa LM Technologies (distribuido en españa por Matrix).  Un digamos, conversor serie - bluetooth, o mejor dicho, un conversor serie RS232 - bluetooth. Como puedes ver en las fotos es un modulito de reducidas dimensiones.
  

Básicamente cuenta con un conector DB9 hembra, un interruptor de 2 posiciones en la parte superior y un conector auxiliar al lado de alimentación (conector de tipo mini-usb, en la foto anterior no se ve, está en el otro lado).
 

¿Como se trabaja con este conversor serie - bluetooth?

Pues a través de comandos AT, de igual forma que trabajamos con los módems. Es decir, desde el puerto serie puedes enviarle comandos de configuración. El equipo viene con un pequeño manual impreso con los comandos AT, son un par de docenas, muy poquitos, nada que ver con el nº que estamos acostumbrados a trabajar con los módems en este blog. El LM-048 tiene integrada el stack bluetooth y cuenta con el perfil bluetooth SPP (Serial Port Profile).

  

¿Y cómo funciona, como master o como slave?

Pues como tu quieras, en función de como lo tengas configurado. Hay un comando AT que lo configura como master (ATR0) y otro comando AT (ATR1) que lo configura como slave, así de fácil.

 
¿A qué tipo de equipos puede conectarse, es decir, el módulito trabaja como DCE (como un módem, un inversor, un contador, …) o como DTE (como un PC, un PLC, …)?

También como tú quieras. Al principio del artículo comenté que el módulo tenía un pequeño interruptor en la parte superior de 2 posiciones. Hacia una posición se convierte en DTE y hacia la otra en DCE, es decir, lo que hace realmente el interruptor al conmutar es intercambiar RX por TX  y RTX por CTS.  Además con el equipo viene un pequeño convertidor DB9 macho - macho que te permitirá, por ejemplo, conectar el LM-048 (con conector DB9 hembra) directamente a un módem (con conector DB9 hembra también) como un MTX65. Me refiero a algo así:
 
  

 La única pega es que tenga que alimentarse con un adaptador externo.

No siempre … si el equipo al que lo conectas está preparado no te será necesario el adaptador de corriente. El LM-048 puede alimentarse a través del propio conector DB9 del puerto serie. Si tu equipo está preparado, puedes alimentarlo a través del pin 9 de este conector. Será necesario una alimentación de entre 5 y 6 voltios y 300mA.

¿Y qué alcance tiene?

Pues es un módulo bluetooth de clase 1, osea que teóricamente unos 100 metros.

¿Podría utilizar una pareja para hacer un “cable serie replacer”?

Por supuesto, podrías configurar uno como master y otro como slave y ya lo tendrías.  El LM-048 te permite también ser configurado para conectarse automáticamente a una MAC (para el que haga de master) o admitir una conexión únicamente de una determinada MAC (para el que haga de slave).

¿En qué aplicaciones puede resultar útil?

Pues en las que quieras y te imagines. Por ejemplo si necesitas ir con un PC a conectarte físicamente al puerto serie de un equipo para hacer un mantenimiento y éste es de difícil acceso, tal vez te resulte más cómodo dejar conectado en el equipo uno de estos LM-048 y hacer el mantenimiento sin cables y a una distancia de casi 100 metros. Mucho más cómodo.

Espero que lo hayáis encontrado de interés, otro día más.

Posts relacionados:

1. Gateway Bluetooth-GPRS Desde hace ya un tiempo quería escribir un post acerca...
2. Nuevo módulo bluetooth de bluegiga WT32 Hoy día 19 de Septiembre Bluegiga, fabricante finlandés de módulos...
3. Módulos bluetooth WT11 y WT12 de bluegiga Hoy os presento unos modulos bluetooth que seguramente a muchos os podrán...

Paso1.

Primero configuramos el módem MTX-H25 en modo MDM, desde Windows es muy fácil. Cogemos el módem tal como viene de fábrica y lo conectamos a un PC con Windows. Al cabo de unos segundos (unos 10) veréis que en “Mi PC” aparece un “Mass Storage Device”, es decir, como si fuera un pen drive. Entramos en él y se instalarán los drivers del módem (sí, has acertado, los drivers del MTX-HC25 están dentro del propio módem, ¿chulo verdad? )

Una vez instalados los drivers en el Panel de Control de Windows veréis que se han instalado 3 dispositivos nuevos. Una tarjeta de red, un módem USB y un COM virtual. Mirar el COM virtual creado para averiguar el número de puerto COM.

Una vez tenemos el puerto COM ya podemos abrir el hyperterminal y ejecutar el comando “at^susb?”  Tenéis que configurarlo como lo que os pongo yo aquí debajo, no voy a entrar en más detalles que decir que en el “Startup” tiene que estar en modo Mdm porque es el que se necesita para trabajar en Linux.

at^susb?
^SUSB: “Startup”,”Mdm”
^SUSB: “MaxPower”,”10″
^SUSB: “PowerSource”,”SELF”
^SUSB: “Mdm/DD”,”0″
^SUSB: “MdmNet/DD”,”0″
^SUSB: “MdmNet/TO”,”60000″
^SUSB: “MS/CRC”,”6B1A1842?”
^SUSB: “MS/DD”,”0″
^SUSB: “MS/OnEject”,”MdmNet”
^SUSB: “MS/WProt”,”Disabled”

El parámetro ^SUSB: “MdmNet/TO”,”60000″ dejarlo así, para en caso de que os hagáis un lío en Linux podáis recuperarlo desde Windows (deberéis conectarlo a Windows y al cabo de 60segundos volverá a ser visible desde Windows, al volver al modo MdmNet). Cuando tengáis todo listo en Linux es aconsejable poner este parámetro a 0.

Paso 2.
 
Instalamos los drivers standard CDC-ACM en Linux escribiendo por consola:

sudo modprobe cdc_acm
sudo modprobe usbserial vendor=0×0681 product=0×0047

Después cogemos el módem, le damos alimentación y lo conectamos por USB. Si lo hemos hecho antes es posible que se haya convertido en un Mass Storage si ha pasado más de un minuto desde que lo enchufásteis hasta que instalásteis los drivers. Si es así quita la alimentación al módem y vuélvesela a poner.

Aquí si después de lo anterior mandamos el comando por consola Linux “lsusb” podremos y deberíamos ver listado el módem MTX-H25 como un dispositivo USB más.
  
Una vez hecho esto si queremos podemos enviar comandos AT al módem. Podremos hacerlo símplemente  ejecutando desde la consola Linux:

echo AT+cfun=1,1 > dev/ttyUSB0

(Con el ejemplo anterior enviamos un reset al módem).

Paso 3.

Lanzamos el script de configuración y comprobaremos que Linux detecta bien nuestro módem, ejecutamos desde la consula Linux:

sudo wvdialconf

si todo va bien veremos que el MTXH25 está instalado en /dev/ttyACM0

Paso 4.

Editamos el fichero de configuración /etc/wvdial.conf :

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Phone = *99***1#
New PPPD = yes
Modem Type = USB Modem
Baud = 460800
Auto DNS = off
Modem = /dev/ttyACM0
DNS = 80.58.0.33

[Dialer movistar]
Init3 = AT+CGDCONT=1,”IP”,”movistar.es”
Password = MOVISTAR
Username = MOVISTAR

[Dialer vodafone]
Init3 = AT+CGDCONT=1,”IP”,”airtelnet.es”
Password = vodafone
Username = vodafone

Paso 5.

Venga ánimo, que ya falta poco …

Editamos el fichero /etc/ppp/peers/wvdial, con la configuración ppp para la conexión:

# Name
name wvdial
# No authentification
noauth
# Use PPP interface as default IP table route
defaultroute
# PPPD must not force an IP address’
noipdefault
# Do not use the Server DNS
# usepeerdns
mtu 472

Paso 6.

Ya podemos ejecutar “wvdial” para conectar con el módem a la Red. Para ello ejecutamos desde la consola linux wvdial seguido con el operador que queramos y que tengamos configurado en el fichero /etc/wvdial.conf (Paso 4) tal que así:

wvdial movistar

Paso 7.

Ale, a disfrutar de la velocidad HSDPA del módem MTX-H25  

Espero que le sea útil  a quien busque por Google “MTX-H25 Linux”. Otro día más

Posts relacionados:

1. MTX-H15 - Modem UMTS / HSDPA terminal Hace ya algún algún tiempo, concretamente hace ya un par...
2. Router UMTS / HSDPA con función VRRP Hace unos días hablaba acerca del protocolo VRRP.  Recordemos que,...
3. Familia modems GPRS / UMTS de Siemens Hay muchos tipos de módems en el mercado GSM /...

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.

 

 
 

 

Dices que es posible programar el equipo para enviar comandos AT en un momento determinado. ¿Pero se puede programar para que envíe comandos AT ante eventos como puede ser el cambio de un GPIO?

 

Sí y no. No puedes utilizar un GPIO para lanzar comandos AT de forma automática, pero si puedes utilizar la línea DTR para ello. Por ejemplo puedes hacer que el módem, si detecta un cambio en la línea DTR ejecute el comando AT^SJRA para lanzar una aplicación java (en el caso del MTX65) o que simplemente haga una llamada con el comando ATD (por ejemplo, un MTX63 que haga una llamda en caso de deterctar una alarma conectada al pin DTR).

  

  

¿Tienes algún ejemplo de uso?

 

Anda, pues sí, casualmente tengo algunos

 

Ejemplo 1.    Envío de comando AT una única vez a los 5 segundos de arrancar el módem en PIN. En este caso enviamos el PIN de la tarjeta SIM

 

at^scfg=”Autoexec”,”1″,”1″,”0″,”0″,”AT+CPIN=1243″,”000:00:05″

 

 

Ejemplo 2.    Envío de comando AT cada 10 segundos segundos. En este caso enviamos el comando ATI seguido de otro comando AT+CSQ (uauu, 2 comandos AT seguidos …)

 

at^scfg=”Autoexec”,”1″,”1″,”0″,”4″,”ATI +CSQ”,”000:00:10″

 

 

Ejemplo 3.    Desactivamos el autoexec anterior.
  

at^scfg=”Autoexec”,”0″,”1″,”0″

 
  

Ejemplo 4.    Hacer una llamada de voz cuando detectemos un cambio en la línea DTR, por ejemplo, cuando detectemos una alarma.

 

at^scfg=”Autoexec”,”1″,”0″,”0″,”0″,”ATD660123456;”

 

(para probar este último ejemplo basta con que cierres el puerto COM desde el hyperterminal y lo vuelvas a abrir, eso hará cambiar fácilmente el estado de la línea DTR).

 

 

He intentado lanzar una aplicación con el comando AT^SJRA pero no funciona. Creo que falla el símbolo ^ en el autoexec.

 

Efectivamente, el módem GSM trabaja con el alfabeto GSM y no con el ASCII. Si quieres lanzar una aplicación por ejemplo ante un cambio de la línea DTR debes hacerlo así:

 

at^scfg=”Autoexec”,”1″,”0″,”0″,”0″,”AT\1B\14SJRA=A:/HelloWorld.jar”

 

 

Espero que os haya sido de interés. Otro día más   
 
P.D. En adelante además de equipos de Siemens / Cinterion intentaré comentar  más a menudo de equipos de Maxstream(Zigbee básicamente), Coronis y Bluegiga, entre otros.
  
   

Posts relacionados:

1. Caracteres especiales en Autoexec Feliz nuevo  año a todo el mundo. Mientras me bajo...
2. Autoarranque de aplicaciones Java en módems Siemens Muy buenas. Hoy voy a poner un pequeño post relacionado con...
3. Cómo obtener la hora con los terminales MTX y módems Siemens / Cinterion Llevo casi un mes sin escribir en blogElectronica. Y es...

Seguramente todos los que leéis este blog y estéis trabajando con módems GSM sabéis que la semana que viene se celebra la ya muy conocida feria 3GSM (llamada ahora Mobile World Congress). Este año Matrix Electrónica dispone de un stand en esta feria donde estarán expuestos los terminales MTX que hemos ido viendo por aquí a lo largo de estos últimos meses (MTX63, MTX65, MTX65+G) e incluyendo el que comenté el otro día, el ULP (Ultra Low Power) y uno más, que no me va a dar tiempo a comentar, que es el MTX65-Industrial (Un terminal carril DIN, con relés, comunicaciones RS232/422/485, …). A quien le interese verlos y conocerlos mejor, quien tenga dudas, preguntas, sugerencias … puede pasarse por el stand la semana que viene, concretamente está en Hall 2-1 Stand A06. Yo estaré por ahí el Jueves.
  

Por último decir una de esas cosas que sientan bien. El otro día a Matrix, que como ya sabéis es donde trabajo actualmente, en la reunión anual internacional de distribudores de Siemens, ahora llamada Cinterion, se nos ha otorgado el premio al mejor distribuidor. Como digo sienta bien. Sienta bien porque hay un trabajo inmenso detrás, un trabajo de mucha gente trabajando con los módulos y con los terminales MTX, en diseño, soporte técnico, ventas, … y es bonito que al menos, aunque sea en un papel, el esfuerzo y el intentar hacerlo de verdad lo mejor posible, pues sea reconocido.
  

Posts relacionados:

1. Ejemplo FTP Java para módems Siemens Hoy pongo un brevísimo post con un nuevo ejemplo Java...
2. Baterías para el MTX65 / TC65T Hola de nuevo. Muchas veces me han preguntado si tiene...
3. Protocolo Multiplex con módems de Siemens Hoy voy a hablar un poquito de la característica Multiplex...

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.

¿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.

 
¿Y cómo se consigue este consumo tan reducido en el modo de funcionamiento ULP?

Pues se consigue desactivando absolutamente todo del MTX, se desconecta todo. Únicamente permanece activa una parte muy reducida del MTX65-ULP (que es la que consume los 2.5uA) y de la que forma parte un chip RTC (Real Time Clock) y unos chips latch (unos registros)

 
Y si desconectas todo menos esa pequeña parte del circuito en ese modo de ultra bajo consumo ¿podré comunicarme en ese estado con el módem por GSM, SMS, GPRS …?

Evidentemente no. En ese modo de consumo NO es posible comunicarte con el equipo. Como comento el equipo está, casi, completamente apagado.

 
Y entonces, ¿cómo se sale de ese modo de ultrabajo consumo? ¿cómo se vuelve a activar el módem?

Hay dos maneras. Bien por una alarma programada en la RTC o bien activando una de las entradas que llamaremos “entradas de tamper”.  Veamos primero el funcionamiento por RTC. En la RTC podemos programar una hora a la cual queremos que se despierte el equipo. Por ejemplo. Tenemos un MTX65-ULP alimentado con baterías y queremos que una vez al día el MTX65-ULP se despierte, haga una lectura de un contador a través del puerto serie, transmita los datos por GPRS a una central y el equipo vuelva a modo ultrabajo consumo después de la tarea. Para esto sirve un MTX65-ULP.

Veamos ahora las entradas de tamper. Al igual que el equipo puede salir del modo ULP por una alarma programada en la RTC, puede hacerlo al activarse una de sus entradas de tamper. Tiene 3. Es decir, si el MTX65-ULP está en modo ultrabajo consumo y se activa una de sus entradas de tamper (aplicando tensión o llevándola a 0 en función de la entrada) el equipo se despertará saliendo del modo ultrabajo consumo, por lo que la aplicación java que tengas configurada en el autostart se ejecutará. Por ejemplo, una aplicación de los tamper puede ser detectar una alarma, un intento de manipulación de un equipo, … una vez se despierte el equipo el programa java embebido puede enviar un SMS, o enviar datos por GPRS o lo que necesites.

 
¿Y puedo saber por cual de las 3 entradas se ha despertado el equipo?

Pues sí, para eso están los latch que comentaba al principio del artículo. Cuando el equipo se despierte, desde tu aplicación java puedes leer unos GPIOS (el equipo tiene 3 GPIOS internamente conectados a estos latchs que comentaba) y verás cual de los 3 latch ha sido el causante de que se despertara el equipo y actuar en consecuencia.

 
¿Cual es periordo máximo con el que puedo despertar el equipo con la RTC?

Un mes. Es decir, puedes especificar el día, hora, minutos y segundos al que quieras despertar el MTX65-ULP para realizar la gestión que sea.

 
Pero yo quiero que se despierte sólo cada 3 meses para hacer un envío ¿puedo?

Pues sí, te despiertas cada mes, sumas 1 a un contador y cuando llegue a 3 haces la gestión

 
¿Y si quito la alimentación del MTX65-ULP (desconectando la alimentación del RJ12) se pierde la hora de la RTC interna?

No. El MTX65+ULP cuenta con una pila de botón interna que retiene los datos de la RTC y del latch. 

 
¿Y cuanto dura la pila interna de botón?

Si el equipo no tiene alimentación externa, 10 años.  Piensa que cuando el módem tenga alimentación a través del conector RJ12 la RTC se alimenta de ahí, es decir, que los 2.5uA no tiran de la pila de botón interna sino de la alimentación proporcionada por el RJ12. Únicamente se usa la pila de botón cuando no hay alimentación en el RJ12, para mantener la hora. Con esto quiero decir que no te preocupes por la vida de la pila de botón.

 
¿Hay ejemplos java de uso de todo esto, de cómo programar la RTC (a través de I2C) y de los tamper?

Por supuesto que sí. De hecho los comentaré por aquí también en breve.

Ya para acabar, os pongo las características del ULP. Bueno no, mejor os pongo un link al datasheet del MTX65-ULP donde ya están mencionadas éstas.

Bueno, espero que os haya resultado de interés. Otro día vemos cómo utilizar desde java el equipo, seguro que os gustará, es único en el mercado.  ;)

Posts relacionados:

1. Nuevo firmware v2.0 para los módems Siemens / Cinterion XT65 y MTX65+G Desde la semana pasada está disponible el nuevo firmware del...
2. Baterías para el MTX65 / TC65T Hola de nuevo. Muchas veces me han preguntado si tiene...
3. Nuevos módulos Siemens / Cinterion TC65i, TC63i y MC75i Tenemos nueva familia de módems. Y es que Siemens /...

Ya está diposible una nueva versión del entrenador de módems Siemens/Cinterion, que si recordáis es una aplicación que hice hace algún tiempo para mi, para la evaluación sencilla de módems Siemens, pero que con el tiempo se ha hecho pública para todos los clientes de Matrix. La nueva versión es la v1.8 y está disponible en el FTP de clientes.
 
Tiene algunas diferencias con su predecesora, la más importante es el hecho de que están incluídos los comandos AT para el control de los puertos GPIO y de los ADC. Esto resultará muy últil a quien le interese el nuevo MTX-ULP (terminal similar al MTX65 pero de ultra bajo consumo) pues para su manejo es necesario el uso de puertos GPIO y resulta engorroso la configuración de éstos desde un hyperterminal.
  

Otras pequeñas diferencias son, como me pidió un usuario hace poco, que el puerto COM por defecto sea el ‘1′ en lugar de el ‘5′ (el 5 es el que yo tenía por defecto en mi PC  ), he añadido algún comando más a los botones de acceso rápido, como el importantísimo AT^SCFG? y también he hecho caso a una antigua “reivindicación” de Jesús (compañero mío de trabajo, por cierto, excelente profesional y persona)  y ahora en la zona de pantalla donde se muestran los comandos AT y sus resultados, éstos se muestran ordenadamente de arriba a abajo y no al revés como antes.
 

Espero que os sean útiles las modificaciones, pues sé que mucha gente utiliza este software. Por otro lado a ver si antes de que acabe la semana cuelgo un primer post del nuevo MTX65-ULP, que seguro que os gustará.

Posts relacionados:

1. Entrenador de Módems GPRS Siemens Seguramente si lees mi blog de tanto en tanto has...
2. Parámetro Autoexec de los módems Siemens / Cinterion   Hoy voy a comentar por encima un parámetro importante...
3. MTX65-ULP. Módem GRPS Ultra Low Power basado en Siemens/Cinterion   Hoy voy a hablar de un nuevo terminal, del...

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.
  

/* Creamos un objeto de la clase FileConnection y especificamos el nombre del fichero a abrir, que pondremos fichero.txt */
FileConnection objFileConnection = (FileConnection)
Connector.open(”file:///a:/fichero.txt”);

/*Averiguamos el tamaño actual del fichero*/
long tamanoFichero=objFileConnection.fileSize();

/*Creamos un objeto de la clase OutputStream, con el que escribir datos en el archivo y le pasamos como parámetro la longitud actual del fichero, de tal modo que el “puntero” de escritura del fichero sea el final del fichero*/
OutputStream objOutputStream = objFileConnection.openOutputStream(tamanoFichero);

/*Escribimos un texto “Adios” dentro del fichero que acabamos de abrir (o crear)*/
objOutputStream.write(”adios”.getBytes());

/*Mandamos escribir todo lo que quede en el buffer previo al cierre del mismo*/
objOutputStream.flush();

/*Cerramos el objeto*/
objOutputStream.close();

/*Cerramos el fichero*/
objFileConnection.close();

 
Una vez ejecutemos la aplicación, si miráis el contenido de fichero.txt veréis que el contenido es “holaadios“, es decir, no sobreescribe el contenido que había en el fichero sino que añade los datos.

En breve pondré unos cuantos posts de dos modelos nuevos de terminales, el MTX65+Gv3 (módem gprs terminal con GPS) y el nuevo MTX65-ULP (módem gprs ultra low power). Veremos primero sus características y luego entraré en detalle en la programación de ambos equipos atendiendo a las peculiaridades de cada uno para que todo el mundo sepa perfectamente como utilizarlos. Estoy convencido de que os van a gustar. Esto será dentro de unos días.
  

Espero que te haya resultado de interés. 

Posts relacionados:

1. Cómo usar ficheros con módems de Siemens desde Java. Como seguro ya sabéis, varios de los modelos de módems...
2. Ejemplo FTP Java para módems Siemens Hoy pongo un brevísimo post con un nuevo ejemplo Java...
3. Ejemplos Java para módems de Siemens A lo largo de los últimos meses he ido poniendo...

Pues como decía por ahí arriba este miniPC está basado en un procesador Intel Atom de 1.1GHz ó 1.6GHz (según la versión) y dispone también de una controladora gráfica GMA 500 con 256Mb de memoria de vídeo. Como puertos de E/S tiene 1 puerto Ethernet (Gigabit), 4 puertos USB 2.0, dos puertos COM - RS232 (que siempre vienen bien, por ejemplo para conectar un MTX ), un conector VGA para el vídeo, conectores de entrada/salida de audio y un conector PS2 (para ratón ó teclado).

Mis compañeros de Madrid me han prometido que me enviarán uno (Javi, Dani, no me olvido ) Cuando lo tenga en mis manos haré algunas pruebas y volveré a escribir sobre él con más detalles cuando y le instalaré Windows ó Linux, ya veremos.
  

Posts relacionados:

1. PC Industrial. Módulos COM Express Hace ya unos meses puse unos post referentes a las...

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).
  

 
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:
   

Resultados para el TC65 (ARM7)

at^sjra=”A:/Rendimiento.jar”
OK
Inicio TC65: 1009843287237
Fin TC65: 1009843294968
Diferencia TC65 (Fin-Inicio): 7731
 
at^sjra=”A:/Rendimiento.jar”
OK
Inicio TC65: 1009843313167
Fin TC65: 1009843320847
Diferencia TC65 (Fin-Inicio): 7680
 
at^sjra=”A:/Rendimiento.jar”
OK
Inicio TC65: 1009843325233
Fin TC65: 1009843332936
Diferencia TC65 (Fin-Inicio): 7703
 
at^sjra=”A:/Rendimiento.jar”
OK
Inicio TC65: 1009843340167
Fin TC65: 1009843347824
Diferencia TC65 (Fin-Inicio): 7657

Resultados para el TC65i (ARM9)

at^sjra=”A:/Rendimiento.jar”
OK
Inicio TC65: 1009844179204
Fin TC65: 1009844186003
Diferencia TC65 (Fin-Inicio): 6799
 
at^sjra=”A:/Rendimiento.jar”
OK
Inicio TC65: 1009844196209
Fin TC65: 1009844202999
Diferencia TC65 (Fin-Inicio): 6790
 
at^sjra=”A:/Rendimiento.jar”
OK
Inicio TC65: 1009844305122
Fin TC65: 1009844311902
Diferencia TC65 (Fin-Inicio): 6780
 
at^sjra=”A:/Rendimiento.jar”
OK
Inicio TC65: 1009844320209
Fin TC65: 1009844326999
Diferencia TC65 (Fin-Inicio): 6790

Es decir, el TC65 tarda aproximadamente 7.7 segundos mientras que el TC65i realiza la misma tarea en aproximadamente 6.7 segundos, o lo que es lo mismo, 1 segundo menos. Como decía al principio, no es un test riguroso de rendimiento ni nada, pero da una idea de la diferencia de procesadores.

El TC65i es totalmente compatible con el TC65, es más pequeñito, más potente y vale menos. ¿No está nada mal no?
  

Ale, hasta mañana. Otro día más

Posts relacionados:

1. Nuevos módulos Siemens / Cinterion TC65i, TC63i y MC75i Tenemos nueva familia de módems. Y es que Siemens /...
2. Cómo utilizar el Watchdog del módem GPRS Siemens TC65 Hace muy poquito salió la versión firmware 3.0 del módem...
3. Localizando fallos difíciles de reproducir en los módems Cinterion TC65, XT65 Si desarrollas aplicaciones en Java para los módems gprs TC65,...

Espero que a alguien le pueda servir en alguna ocasión.  
 
P.D.   estoy realizando cambios importantes en el blog, disculpad si en alguna ocasión no se leen bien los posts, se me descentra alguna imagen o hay algún problema con los acentos (me estoy peleando con el UTF-8 y el ISO-8859-1). Espero que a la larga sea positivo.
 
 

Posts relacionados:

1. Instalando el entorno de desarrollo para crear aplicaciones JAVA con el modem Siemens TC65 Crear aplicaciones Java para embeber en un módem Siemens TC65...
2. Versión 1.1 de la plataforma OTAP Aquí cuelgo para quien lo necesite la versión 1.1 (beta por...
3. Baterías para el MTX65 / TC65T Hola de nuevo. Muchas veces me han preguntado si tiene...

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. 

 Como véis se puede programar el AUTOEXEC del comando AT^SCFG para lanzar comandos AT de forma temporizada (hay muchas combinaciones, como dije, ya las veremos).

Por ejemplo, si quisieramos programar el módem para que se resetee cada 20 minutos, podríamos programar el autoexec así:

 
     AT^SCFG=”AutoExec”,1,1,2,5,”AT+CFUN=1,1″,”000:20:00″

 
El problema viene cuando queremos utilizar comandos propietarios de Siemens / Cinterion, ya sabéis, todos aquellos que empiezan por AT^ 

Cuando usamos el comando AT^SCFG y el AUTOEXEC hay que tener presente que el módulo trabaja con el alfabeto GSM y no el ASCII.
 
 
¿Y a mi qué que trabaje con otro alfabeto?

Pues que el módem no es capaz de interpretar el símbolo ^ y lo cambia por otro, con lo que el comando no te va funcionar. Verás que cuando llegue la hora y se deba ejecutar el AUTOEXEC te devolverá un error.
 
 
¿Y entonces no se puede utilizar ese símbolo?

Sí se puede, pero has de utilizar el alfabeto adecuado. Por ejemplo, imagina que quieres lanzar un programa, por el motivo  que sea, a los 10 minutos de que se encienda el módem (10 minutos no se puede hacer con el delay del autostart).

Lo primero que tendemos a poner es:
 

     at^scfg=”AutoExec”,1,1,0,0,”at^sjra=A:/programa.jar”,”000:10:00″

 
pero realmente hay que poner:
 

     at^scfg=”AutoExec”,1,1,0,0,”at\1B\14sjra=A:/programa.jar”,”000:10:00″

 
es decir, substituir el símbolo “^” por su codificación “\1B\14″

¿Y si quiero cambiar el valor del AUTOEXEC desde una aplicación java también se puede hacer?

Pues sí, también se puede hacer, basta con, en vez de escribir algo como:
 

     respuesta=sendAT(”AT^SCFG=\”AutoExec\”,1,1,0,
     0,\”AT^sjra=a:/programa.jar\”,\”000:00:20\”);

subtituir el símbolo ^ por \\1B\\14:

 
     respuesta=sendAT(”AT^SCFG=\”AutoExec\”,1,1,0,
     0,\”AT\\1B\\14sjra=a:/programa.jar\”,\”000:00:20\”);

 
No os olvidéis en el caso de java de poner doble barra (\\), pues la contrabarra (\) hay que introducirla con un comado de escape.
 
 
Bueno, ya está bajada la demo del Warhawk, justo a tiempo.  Hasta otro rato

Posts relacionados:

1. Parámetro Autoexec de los módems Siemens / Cinterion   Hoy voy a comentar por encima un parámetro importante...
2. Localizando fallos difíciles de reproducir en los módems Cinterion TC65, XT65 Si desarrollas aplicaciones en Java para los módems gprs TC65,...
3. Autoarranque de aplicaciones Java en módems Siemens Muy buenas. Hoy voy a poner un pequeño post relacionado con...