blogElectronica.com

Hace tiempo que no escribo en blogElectronica, por lo que tengo en el tintero bastantes novedades que comentar, algunas muy pero que muy interesantes, sobre todo en relación a equipos 3G con java de los que hablaré dentro de pocas fechas

Pero hoy voy a comentar un nuevo terminal gsm/gprs de la familia MTX que seguro que a más de uno le va a resultar interesante, sobre todo por el ahorro de costes que supone en algunos escenarios donde se utiliza un MTX65i + conversor RS232-RS485.  Se trata del nuevo terminal MTX65i-RS485.

¿Qué características tiene?

Pues básicamente son las mismas que el archiconocido y usado MTX65 aunque con ligeras diferencias. Así, de forma estemática, estas son las principales características:

1.- Módem GSM/GPRS de clase 12
2.- Programable en JAVA, 1.7MB Flash 400KB Ram (opcionalmente 8MB Flash 2MB Ram)
3.- 1 puerto RS485 con borna atornillable
4.- 1 puerto RS232
5.- 1 Puerto USB
6.- 2 convertidores analógicos/digital
7.- 2 entrada digitales optoaisladas
8.- 2 salidas digitales optoaisladas
9.- 1 entrada/salida digital de propósito general
10.- 1 entrada contadora de pulsos (hasta 1KHz)
11.- 1 bus I2C

 

Como véis, a parte de la principal diferencia (y característica) que es el puerto RS485 integrado en el propio módem, se diferencia del MTX65i por un mayor número de E/S (optoaisladas).

Otra diferencia importante de este módem es la posibilidad de poderse apagar. Si recordáis, una de las principales virtudes del módem gprs MTX65i es que está diseñado para que nunca, nunca, bajo ninguna circunstancia, el módem pueda quedarse apagado. Siempre se va a encender. Esto da mucha seguridad cuando se instalan en entornos no urbanos en el que cualquier acción a realizar de forma presencial en el módem resulta traumática. En este caso, esta opción está también disponible para tener la misma seguridad de que el módem no va a fallar, pero si se desea, también se puede llegar a apagar el módem de forma voluntaria con una entrada especial en el conector de alimentación.

¿Puede usarse también este módem gsm/gprs con el software MTXTunnel?

Por supuesto, a partir de la versión MTXTunnel 7.6, de la que hablaré de nuevo aquí para comentar las novedades, puede usarse sin problemas.

Conclusiones.

Si hasta la fecha estás usando el MTX65i junto con un conversor RS485, os podéis ahorrar el conversor, tiempo de instalación y espacio físico con este nuevo módem MTX65i-RS485. En breve vuelvo con más, aprovecho para desearos a todos una feliz entrada en el 2013!!!  Salu2

Etiquetas: cinterion, gprs, gsm, mtx65

Algunos de vosotros ya conocéis la existencia del nuevo módulo GSM/GPRS de Cinterion de nombre TC65i-X, otros muchos no, así que hoy voy a comentar un poco los aspectos más relevantes de este nuevo e interesante módulo.
Como digo el nombre del módulo es TC65i-X y es, básicamente y como puede deducirse de su nombre, un módulo TC65i con algunos cambios. Estos cambios son tanto a nivel de hardware como a nivel de software, todos ellos positivos.

¿Y cuales son los cambios a nivel hardware?

Pues básicamente es cambio es uno y para mi el más importante de todos, incluidos los cambios de software. Como sabéis el módulo gsm/gprs TC65i es programable en Java (J2ME). Este módulo cuenta con unos 400KB de RAM y 1.7MB de Flash. El nuevo módulo TC65i-X aumenta mucho esa capacidad llevando la memoria RAM hasta los 2MB y la memoria flash hasta los 8MB (divididas en 2 particiones de 4MB).

Esto obviamente es importante. Aquellos, entre los que me incluyo, que desarrollamos aplicaciones grandes siempre nos llega un momento en el que tenemos que ir programando con mucha cautela ya que la memoria RAM del TC65i es algo limitada para algunas aplicaciones. Con 2 MB de memoria Ram la cosa cambia mucho y ahora es posible realizar aplicaciones java grandes y complejas sin ningún tipo de problema.  De forma análoga puede ocurrir con la memoria Flash, ahora de 8MB.

¿Y a nivel software, qué cambios tenemos con el nuevo módulo TC65i-X?

Pues bastantes. Voy a poner aquí las que me parecen más relevantes.

1.- Soporte, por fin, para poder trabajar con el Entorno Eclipse y MES con versiones Windows 64 bits. Esto es, Vista 32/64 bits y Windows7 32/64bits. Básicamente es debido a la nueva versión MES 2.7.0.0 ya disponible.

2.- Inclusión de ciertas APIs java para el manejo del GPS (por si conectamos un módulo GPS a uno de los 2 puertos serie del módulo TC65i-X).

Lee el resto de esta entrada »

Etiquetas: cinterion, java, tc65

Este fin de semana me he traído me he traído a casa un pequeño juguetito para enredar con él. Hacía tiempo que quería probarlo, pues puede ser de utilidad en bastantes aplicaciones relacionadas con el mundo m2m cada vez más y más presente en nuestras vidas, aunque muchos no se den cuenta.

Este pequeño dispositivo es un módulo minicámara, de resolución VGA, de la casa Comedia que a su vez está basado en un sensor cmos de la casa Onmivision (el mayor fabricante del mundo de este tipo de dispositivos, del que casi todos tenemos unos de sus sensores en nuestros teléfonos móviles). Hasta aquí nada especial. Lo peculiar de esta minicámara es que, además de su bajo coste, se puede controlar directamente mediante un puerto serie, una uart, con un protocolo muy básico apto para todos los públicos.

Esto último, obviamente, facilita enormemente el hecho de poder controlar la cámara y obtener una imagen de lo que acontece en el mundo desde cualquier dispositivo con puerto serie. En mi caso me interesa especialmente  la posible integración con los módems MTX65i y en especial con el software MTXTunnel. Estoy un poco evaluando a ver cuanto me llevaría en tiempo integrar la posibilidad de “tomar una instantánea” desde el MTXTunnel o más todavía desde el MTXTunnelGPS.

La cámara que he estado probando es concretamente el modelo que tenía más a mano, el C328R. A grandes rasgos este es el diagrama de bloques de la cámara:

Lee el resto de esta entrada »

Etiquetas: cinterion, mtx65, mtxtunnel

Aprovechando que he tenido que probar el interfaz PCM de los módulos Cinterion y de los módulos bluetooth de Bluegiga voy a poner un post sobre ello que será de gran ayuda para quienes quieran desarrollar algún equipo GSM con voz manos libres (vía bluetooth). Lo voy a poner un poco en modo esquemático, de manera totalmente práctico para que no se complique más de lo necesario, que lo es un poco.

Bueno, vamos allá rápido que las manecillas del reloj vuelan y ya es tarde …

1.- Cogemos una placa de evaluación DSB75 donde insertaremos el módulo GSM de Cinterion que queramos usar (un TC63i, un TC65i, un PH8, …). En mi caso tengo aquí montado un TC65i.

2.- Localizamos los pines en la placa de evaluación DSB75 que corresponden a los PINES de audio PCM. Concretamente corresponden al conector x703 de la placa. En ese conector veremos 7 pines: TXDAI, RXDAI, FS, BITClk, FSIN, BCLKIN y GND.

3.- De esos 7 pines necesitaremos sólo 5, que son los que usa PCM. La elección dependerá de si usamos el módulo de Cinterion en modo PCM MASTER o en PCM SLAVE. Si usamos el módulo Cinterion en modo PCM MASTER usaremos los pines TXDAI, RXDAI, FS, BITCLK y GND.  Si usamos el módulo Cinterion en modo PCM SLAVE usaremos los pines TXDAI, RXDAI, FSIN, BCLKIN y GND. La siguiente foto indica como lo he usado yo, en modo SLAVE, conectando unos cablecillos a dichos 5 pines.

4.- Cogemos un kit de desarrollo de Bluegiga, concretamente el más sencillo de usar es el del módulo bluetooth WT32, la razón es que ese kit tiene los pines de PCM disponibles en el PCB del kit de desarrollo. En el PCB de Bluegiga se ve perfectamente donde están los PINES del PCM debido a la buena serigrafía.

5.- Conectamos los pines PCM del módulo GSM Cinterion con los pines PCM del módulo bluetooth WT32 de Bluegiga. Básicamente hay que conectar los pines así:

TC65i  (Slave)    WT32 (Master)

RXDAI             OUT
TXDAI             IN
FSIN                SYNC
BCLK               CLK
GND                GND

¿Cómo? ¿Qué lo quieres al revés?  Venga, te lo pongo, sería algo así: en el caso de que quisiéramos usar el módulo GSM como Master:

TC65i  (Master)   WT32  (Slave)

RXDAI              OUT
TXDAI              IN
FS                       SYNC
BITCLK            CLK
GND                  GND

Bueno, una vez hecho esto ya tenemos todo el hardware conectado. Ahora tenemos que conseguir un pinganillo Bluetooth manos libres. Yo tengo uno de Plantronics, con MAC bluetooth: 00:03:89:a5:a6:72 (la indico porque la usaré después).

6.- El siguiente paso es configurar el módulo bluetooth WT32 para enrutar el audio hacia/desde el interfaz PCM. Para ello lo hacemos enviando al módulo WT32, vía un hyperterminal a 115200,8,N,1 el comando:

SET CONTROL AUDIO PCM PCM

7.- Establecemos la configuración PCM al módulo bluetooth. Debido a la complejidad de las distintas configuraciones de PCM usamos un Excel que proporciona bluegiga. Con este Excel indicamos la configuración que queremos y de esa manera obtenemos de manera sencilla el valor de la PSKEY_PCM_CONFIG32 que necesitamos para configurar el PCM. EN este caso la PSKEY_PCM_CONFIG32 tiene un valor de 0×08400000.

Igual que en el punto anterior podemos configurar la PSKEY mediante un comando desde hyperterminal:

SET CONTROL PCM 08400000 006C

8.- Ahora vamos a configurar el módulo GSM de Cinterion para usar el interfaz digital del audio. Ojo que estos comandos pueden ser distintos en función del modelo que se vaya a usar. Yo lo voy a hacer con un TC65i. Por lo tanto, desde un hyperterminal enviamos:

AT^SAIC=1,1,1,1,1,1

Así configuramos el módulo para usar el audio digital PCM en modo Slave, a 512MHz y Long Frame.

Llegados a este punto ya tenemos configurados tanto el módulo de bluetooth como el módulo GSM. Ahora vamos a probar el audio.

Venga, que ya queda poco !!!!

9.- Desde el pinganillo manoslibres bluetooth (que supongo ya pareado con el módulo bluetooth de Bluegiga) nos conectamos al módulo bluetooth de Bluegiga (pulsando el único botón que tiene para ello).

10.- Seguidamente conectamos físicamente (con un cable serie cruzado) el puerto serie ASC0 RS232 del módulo TC65i con el puerto serie del módulo bluetooth WT32.

11.- Hacemos una llamada GSM de audio desde un teléfono móvil al módulo GSM TC65. Al recibir la llamada el módulo sacará un “RING” por su puerto serie que será recibido por el módulo bluetooth que a su vez informará al pinganillo bluetooth de la llamada entrante (oiremos el típico beep beep de llamada entrante). Aceptamos la llamada con el botón del pinganillo bluetooth.

12.- Una vez hecho eso aceptamos la llamada de voz en el módulo GSM con el comando típico ATA. Si todo ha ido bien en este instante estaremos hablando con nuestro pinganillo manos libres bluetooth, conectado vía bluetooth al módulo WT32 de bluegiga y este a su vez conectado al módulo GSM de Cinterion mediante la interfaz PCM.

Bueno, esto es todo por hoy. Es un post quizás algo complejo de entender si no se tienen los equipos delante, pero ya veréis que si alguna vez necesitáis hacer algo parecido este post os irá de perlas pues os ahorraréis muchas horas de trabajo. A mi mismo me irá bien si alguna vez me tengo que volver a poner con ello, ya que he tenido que hacer el montaje 3 veces a lo largo del tiempo y siempre pienso que no se me va a olvidar el montaje y siempre se me escapa algo. A partir de ahora ya no

Salu2!!!

.

Etiquetas: bluegiga, bluetooth, cinterion, gsm

Hoy toca desempolvar unos viejos artículos publicados aquí, en blogElectronica.com, hace ya bastantes meses, casi 2 años. ¿Os acordáis de aquel artículo de finales del 2009?

http://www.blogelectronica.com/cinterion-eu3/

En ese artículo comentaba la inminente aparición nuevo módulo de Cinterion EU3 destacando que una de sus mayores virtudes era es soporte a la nueva banda UMTS 900MHz que se aproximaba. De ese artículo merece recordar lo siguiente:

“Desde el punto de visto técnico es mejor porque ofrece una mayor cobertura y penetración que el actual UMTS2100, lo cual es ideal para dar cobertura en zonas rurales e incluso en ciudades, donde al tener una capacidad de penetración mayor la cobertura en edificios es mejor.

Y desde el punto de vista económico pues es evidente. Una razón es que, al disponer de mayor alcance, para dar cobertura a una determinada área es necesario instalar menos estaciones base con UMTS900 que con UMTS2100. Otra razón es que las actuales estaciones GSM siguen siendo válidas y sólo son necesarias pequeñas y económicas adaptaciones, no como ocurre con UMT2100.

Sólo un consejo más para quienes a día de hoy vayáis a empezar un nuevo proyecto con módulos GSM/GPRS con visión de futuro y estéis evaluando los módulos de distintos fabricantes. El consejo es que leáis la noticia del anuncio del nuevo módulo EU3 publicada en la web de Cinterion. Con especial  atención al título, “Cinterion Announces First UMTS Module to Support Seamless 3G Transition for Existing GPRS/EDGE Designs“

Un poquito más adelante, en mayo del 2010, en el artículo:

http://www.blogelectronica.com/banda-umts-en-900mhz/

comentábamos más en profundidad todo lo relacionado a nivel técnico con el 3G 900MHz (es de recomendable lectura). Una de las cosas a destacar de ese artículo tanto en el cuerpo del mismo como en los comentarios de los lectores es la aclaración (porque muchos lo preguntaron y por tanto muchos se/me/nos lo preguntarán) es que la tecnología actual GSM/GPRS (a 900MHz) convivirá con el nuevo UMTS 900MHz.

Ya por último hace 10 meses puse un artículo sobre el stack TCP/IP del módulo EU3:

http://www.blogelectronica.com/eu3-modem-hsdpa-usb-rs232/

Destaco el último párrafo, donde pone:

“Por último, un detalle a destacar. Con el módulo EU3 Cinterion ha usado el mismo conector B2B y (casi) el mismo pinout que en el TC63i. Por ello, a quien esté diseñando una placa para usar el TC63i, le recomiendo que de un vistazo a una nota de aplicación de nombre EU3_e-migration (que forma parte de la documentación del EU3) donde se indica las pequeñas diferencias a tener en cuenta en una migración del TC63i al EU3. O dicho de otra manera, ese documento nos permitirá diseñar una placa de manera que pueda usar el TC63i ó EU3 indistintamente, con las ventajas evidentes que eso conllevará en un futuro.  Si alguno está también dubitativo entre usar un MC55i o un TC63i en un nuevo diseño (como veo muchas veces que ocurre) este detalle de compatibilidades con EU3 es para tenerlo en cuenta, al menos a mi me acabaría de decidir.”

Pues eso, aquellos que apostaron por el nuevo EU3 de Cinterion o diseñaron con un TC63i y tuvieron en cuenta las nota de aplicación para hacer el circuito compatible tal como comentamos aquí, a partir del 9 de este mes de Septiembre empezarán (porque es un proceso de implantación que durará un par de años) a recoger sus frutos.

Tenéis más información aquí sobre la implantación del nuevo UMTS 900MHz:

http://bandaancha.eu/articulo/8031/3g-mejorara-drasticamente-cobertura-partir-9-septiembre

Bueno, espero que el artículo haya sido de interés para algunos y de satisfacción para otros por haber elegido bien. Yo me pongo ahora a continuar con el manual de la nueva versión MTXTunnel v6.0 que saldrá dentro de poco . Salu2!!!

Etiquetas: cinterion, umts

Hoy voy a poner un artículo que seguro que resulta interesante y curiosos a muchos, sobre todo a quienes estamos trabajando de forma habitual con equipos GSM. Y es que ayer Jueves por fin me llegó a casa un aparatito que compré hace unas semanas únicamente, y que nadie piense mal, para poder probar esta capacidad con la que cuentan los módems de Cinterion y que hasta ahora no había podido probar y me la tenía que creer: el Jamming detection.

Para las pruebas me he basado en la nota de aplicación oficial de Cinterion de nombre “AN_45_Jamming_Detection.pdf”. Ahí tenéis detallada toda la documentación al respecto, yo me voy a centrar en la parte práctica. En cuanto al módem he utilizado un MTX65i de Matrix, que tiene un TC65i en su interior, pero podría haber utilizado otro modelo de MTX o Cinterion, sería lo mismo.

Bueno, sí, vale, ¿pero qué es el Jamming detection?

Pues en pocas palabras es la capacidad que tiene el módem para detectar una interferencia intencionada en los canales de comunicaciones para bloquearlos.

Quizás pienses que no tiene importancia, y seguramente en la inmensa mayoría de aplicaciones GSM así sea, pero en las aplicaciones relacionadas con seguridad, alarmas … sí es bastante importante (o lo debería ser).

Pongamos algún ejemplo. Una casa o un coche que cuente con una alarma típica GSM, una alarma que si salta debe comunicarlo a una oficina central receptora de alarmas GSM.  Pero, ¿qué ocurre si unos maleantes perpetran su acción con un inhibidor GSM? ¿Podrá la alarma GSM comunicarse con la central? ¿Será la alarma al menos capaz de detectar que está siendo interferida con un inhibidor GSM para actuar en consecuencia?

Obviamente ante la acción de un inhibidor GSM suficiente potente ningún equipo (ningún teléfono móvil, módulo GSM/3G, …) será capaz de realizar una comunicación GSM. Pero sí que algunos dispositivos tienen, al menos, la capacidad de detectar que están siendo interferidos por un inhibidor GSM: los módulos de Cinterion. Esta capacidad permite actuar en consecuencia, es decir, si un equipo sospecha que empieza a ser interferido pues puede intentar una comunicación cuando la interferencia es todavía débil, puede pre-activar avisos acústicos etc etc etc. En definitiva, siempre será mejor que un equipo de alarma sepa lo que está ocurriendo a que no lo sepa, el cómo se actúe en esas situaciones ya dependerá de la capacidad e imaginación de quien desarrolle la alarma.

Funcionamiento del Jamming Detection en los módulos Cinterion.

Como decía anteriormente toda la documentación está en la nota de aplicaciones 45 de Cinterion. Básicamente, y muy resumido, consiste en activar el indicador de estabilidad del link de comunicaciones “lsta”, por ejemplo con:

 AT^SIND=”lsta”,1,5

y activar los URCs con:

 AT+CMER=2,,,2

Una vez activamos el jamming (la interferencia) veremos como el módem va indicando la situación  mediante URCs (enviando mensajes por su puerto serie). Primeramente enviará mensajes del tipo:

+CIEV: “lsta”, , ,

indicando que están ocurriendo errores en el link de comunicaciones. “lstaEdv” (que es un contador cuanta atrás) irá decrementando rápidamente hasta llegar a “0″. Mmmm … empieza la sospecha …

Tras este URC el módem nos devolverá otro del tipo:

+CIEV: “lsta”, , , , , ,

Este URC ya indica pérdida de cobertura de Red. Según detalla la documentación de Cinterion, cuando se obtiene un URC con un “lstaNo” = 40, un “lstavar” bajo (inferior a 10) y un “lstaMean” > 40 es indicación clara de Jamming.

Como siempre todo se entiende mejor con imágenes y si es un vídeo pues mejor todavía, por lo que aquí lo tenéis. (Si has recibido el artículo por email es probable que tengas que verlo desde www.blogelectronica.com).

 

Espero que os haya parecido interesante. Otro día más.

Etiquetas: cinterion

Hoy voy a comentar un poco por encima los interfaces de comunicación del nuevo módulo HSDPA EU3 y veremos un ejemplo de uso del stack TCP/IP integrada en este módulo, ya que cambia un poco a lo que estábamos acostumbrados con los módulos MC55i, XT65, TC63i y TC65i.

Interfaces de comunicación.

El módulo EU3 cuenta con un puerto serie y un puerto USB. Si conocéis el módulo HC25, a diferencia de éste, con el EU3 si es posible usar simultáneamente el puerto serie y el puerto USB. De hecho hay varias formas de configurar estos interfaces. Para ello usaremos el comando AT^SDPORT  (comando muy importante para la primera toma de contacto con este módulo), que debe estar correctamente configurado.

Con AT^SDPORT podemos configurar 4 modos de funcionamiento.

Modo 1: modo por defecto, debería servir sólo para configurar una velocidad adecuada con AT+IPR y luego cambiar a SDPORT=2, SDPORT=3 ó SDPORT=4

Modo 2: modo uart. Podremos usar el EU3 sólo por puerto serie.

Modo 3: modo USB. Para usar el EU3 sólo por puerto USB (se crea un puerto COM módem y un puerto COM virtual de aplicación (es decir, por ejemplo, para enviar comandos AT de estado al módem a la vez que tenemos establecida una conexión 3G/HSDPA por el COM módem).

Modo 4: modo USB + uart. Para usar el puerto USB en conexiones 3G/HSDPA y la uart para ir consultando el estado del módem mediante comandos AT.

A continuación, como indicaba al comienzo del post, vamos a ver cómo crear una conexión 3G/HSDPA y, usando la pila TCP/IP interna del módem, es decir, vamos a crear un socket contra un servidor remoto para enviar/recibir datos.

Lee el resto de esta entrada »

Etiquetas: cinterion, hsdpa, umts

Ya está disponible el nuevo MTXTunnel v5.0.

Tras un periodo de trabajo bastante largo por fin está finalizado.    La nueva versión 5.0 trae muchísimos cambios con respecto a la versión anterior MTXTunnel v4.0  (para que os hagáis una idea el manual pasa de unas 20 páginas a unas 210)   Muchas de las prestaciones que han ido sugiriendo los propios usuarios actuales de la versión v4.0 y anteriores las he incluído en esta nueva versión. Cosas como poder controlar 2 equipos con un único módem MTX65i (uno por cada puerto serie), como poder usarlo en escenarios de ultra bajo consumo, comunicaciones UDP (además de TCP), seguridad SSL, DynDNS, Webserver embebido, Telnet, envío de telemetrías (GPIOs y ADCs …), envío de posición GPS, etc etc … forman parte de esta nueva versión. Creo que ha quedado bastante completo.

El manual como digo es extenso, pero he añadido unos 30 ejemplos de configuración para diferentes escenarios. De esa manera a la mayoría de los usuarios les bastará con buscar el ejemplo que más se parezca a lo que quieren hacer y modificarlo un pelín según sus requerimientos. (Es decir, no hace falta leerse todo el manual )

Como es costumbre en todo lo que hago suelo añadir unas FAQ en los manuales para intentar disipar las dudas que me imagino puedan surgir. Estas FAQs del manual del nuevo MTXTunnel 5.0 son las que os pongo a continuación. Espero que las encontréis interesantes. Y ya sabéis, como siempre, cualquier sugerencia me la podéis comentar que si son interesantes os aseguro que no van a caer en saco roto, si no que serán incluídas en posteriores versiones, tal y como he hecho con sugerencias pasadas en esta nueva versión.

Aquí os pongo las FAQ, son un poquito largas, pero resumen todo lo principal que puede hacer el nuevo equipo. Si tienes 5 minutos y las lees verás que el MTXTunnel 5.0 te puede ser de utilidad para muchas de tus aplicaciones futuras.

¿Qué es el MTXTunnel?

El MTXTunnel 5.0 es un software que puedes solicitar a Matrix instalado dentro los siguientes módems de la familia MTX  (MTX65i, MTX65IND, MTX65ULP y MTX65+G)

  Lee el resto de esta entrada »

Etiquetas: cinterion, dynDNS, gateway, gprs, rs232

Hoy voy a poner un pequeño post sobre Proguard, un ofuscador para Java. Probablemente muchos lo conozcáis y lo utilicéis ya con vuestras aplicaciones j2me, pero para los que no, os aconsejo dar un vistazo a este articulillo, que os irá bien, sinó ahora, más adelante, en alguna ocasión, con algún nuevo proyecto con módems Cinterion (TC65, XT65) o los terminales MTX.

El uso de un ofuscador para nuestras aplicaciones j2me es interesante, más que por su capacidad de “ofuscar el código”, por la reducción del tamaño final del fichero “.jar” generado. Nunca hay que olvidar (aunque alguno a veces parece que lo haga ) que no estamos programando un procesador Core2Duo, sino que estamos programando dispositivos con un tamaño de memoria RAM y FLASH muy limitada. Por ejemplo un módem GPRS MTX65 dispone de una memoria RAM de unos 400KB y de 1.7MB de memoria FLASH. El uso de un ofuscador nos hará aprovechar al máximo la preciada memoria FLASH y sobre todo la memoria RAM de nuestros módems.

Para hacernos una idea, el nuevo firmware del MTXTunnelv5.0 que saldrá en breve (este mes) ocupa, sin ofuscar, unos 130KB, mientras que ofuscándolo unos 80KB. Podéis ver que la reducción es bastante significativa.

¿Y qué hay que hacer para usar un ofuscador?

Pues lo primero de todo bajárselo.

¿Con el emule?

No, que es gratis.

¿Y dónde está?

Lo encontrarás en este Link: http://sourceforge.net/projects/proguard/files/

Bájalo y descomprímelo dentro de la carpeta del Eclipse, es decir, dentro en:

c:\Eclipse\proguard4.5.1\

Después ves a Window > Preferences > J2ME > Packaging > Obfuscation y selecciona el PATH adecuado tal y como puedes ver en la pantalla siguiente.

Una vez hecho esto ya puedes “compilar” tu aplicación ofuscándola. Para ello en lugar de hacer un “Create Package” hacemos un “Create Obfuscated Package”.

Lee el resto de esta entrada »

Etiquetas: cinterion, j2me, java

Como todos ya sabéis, el módem MTX65+G del que he hablado en muchas ocasiones en este blog, es un módem GPRS con GPS integrado. En su interior cuenta con un módulo Cinterion XT65, un módulo muy similar en prestaciones al conocidísimo TC65 (cpu, prestaciones, …) pero el cual incluye además un GPS. Este GPS es un módulo GPS de la casa uBlox, concretamente monta un Antaris 4.

Normalmente, cuando programamos en java el módem MTX65+G (es decir, el XT65) lo hacemos siempre de 2 maneras. O bien usamos la clase ATCommand con el comando que proporciona Cinterion (AT^SGPSR) para leer la posición GPS actual (este es el método más utilizado y en el que yo me incluyo) o bien utilizamos la API Location para J2ME (JSR 179).

Sin embargo, existe otra manera de actuar sobre el GPS. Como sabéis el módulo TC65 dispone de 2 puertos serie y el XT65 sólo dispone de 1. La razón de que sólo disponga de un puerto serie es que el otro lo tiene routeado hacia el puerto serie del módulo GPS que monta, es decir, es el puerto serie con el que el XT65 controla el GPS.

Lee el resto de esta entrada »

Etiquetas: cinterion, ejemplos java, mtx65+g, xt65