blogElectronica.com

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.

Lee el resto de esta entrada »

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!!!

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”, <indValue>, <lstaEdv>, <lstaRssi>

 
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”, <indValue>, <lstaNo>, <lstaMax>, <lstaMin>, <lstaMean>, <lstaVar>

 
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.

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 »

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 »

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 »

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 »

Hace ya mucho tiempo que tengo la plataforma OTAP activa. Desde entonces ha sido utilizada para hacer miles del OTAPs. Como sabéis un OTAP es el proceso que permite actualizar remotamente las aplicaciones java que embebemos en nuestros módems Siemens/Cinterion. Hoy presento la versión 2.0 de este software que es similar a la versión 1.0 pero presenta algunas diferencias importantes.

La primera es que ya no depende de mi servidor www.otap.es.   Ahora el software incluye un pequeño servidor TCP/IP para gestionar las respuestas OTAP. Es decir, como sabéis, cuando un proceso de OTAP finaliza (bien o mal) si la conectividad GPRS es correcta envía una notificación (petición POST) a un servidor web indicando el resultado de la operación. En la versión 1.0 esta notificación era enviada por el módem siempre a www.otap.es mientras que en esta versión 2.0 podéis especificar vuestro servidor de confirmación OTAP o bien utilizar esta misma aplicación (v2.0) como servidor de confirmación. También la he preparado para ello.
 
Si os fijáis en la siguiente captura de pantalla:

  Lee el resto de esta entrada »

Hace pocos días que mi compañero Jesús Santos, ingeniero de Matrix, ha publicado un artículo muy pero que muy interesante (en www.redeweb.com , número de Mayo) para todos los que tenemos la suerte (o eso creo yo) de trabajar en el mundo del GSM. Así que dado el interés, y por supuesto con el permiso ya concedido del autor , lo voy a publicar aquí para uso y disfrute de todos, aunque fraccionando en dos artículos el artículo original, al ser éste bastante extenso y comprender dos temáticas diferentes.
 
Vamos allá. Este primer artículo trata una nueva tecnología que veremos en un futuro muy próximo, las llamadas M2M component SIM. Aquí os lo dejo:
 
 
M2M component SIM
 
También llamada C-SIM (component SIM), E-SIM (electronic SIM), embedded SIM, chip on SIM, M2M component SIM, etc… es una SIM en un nuevo formato en forma de chip en un encapsulado SMD miniatura. Es exactamente lo mismo que en su actual formato de cartón-plástico, pero en forma de circuito integrado. Esta nueva tecnología evita tener que poner los conectores zócalos porta-sim, con sus inconvenientes de ocupación de espacio, costo, problemas mecánicos y de contactos, fallos de SIM en entornos agresivos, y de acceso al usuario, como el robo o sustracción de la SIM.
 
Este componente se puede poner, al igual que actualmente, externo al módulo GSM, a través del interfaz SIM. También se puede “integrar” dentro del módulo, para ello el modulo GSM debe estar preparado para integrar internamente el chip-SIM.
 
Ya existen fabricantes y suministradores que ofrecen estos chips en producción.  Un ejemplo es Infineon como fabricante de chips y Gemalto como fabricante de tarjetas SIM. Estos chips llevan internamente una memoria no volátil donde se carga la información del operador. El operador suministra estos chips al cliente final al igual que actualmente ofrece las SIMS tradicionales en soporte clásico de cartón/plástico, ya que es el operador el que posee los datos a grabar (encriptados) en estos chips. No en todos los países los operadores están preparados para ello. Tened en cuenta que se pueden adquirir estas SIM y activarlas posteriormente, así como cambiar los servicios asociados (Voz, Datos, IP fijas…)
 
Para el chip-SIM integrado dentro del módulo es necesario un acuerdo entre los tres factores que tiene que  permitirlo: integrador, operador y fabricante de módulos GSM, como Cinterion. En este caso las C-SIM se entregan ya grabadas y Cinterion las monta internamente en el proceso de fabricación/montaje del módulo, en fábrica.
Resumiendo, hablamos realmente de lo mismo, las tarjetas SIM tradicionales vienen encapsuladas en un “cartón” o plástico en forma de uña y la tarjeta M2M SIM vendrá encapsulada en formato de componente SMD como el VQFN-8. Como veis, es algo relacionado a su forma y poco más.
 

 
Lee el resto de esta entrada »

Bueno, ya estoy aquí de vuelta de vacaciones. Esta Semana Santa he pasado unos estupendos días en Cáceres con la familia (ahí reside gran parte de mi familia por parte de Madre). Hacia ya muchos años que no iba y ya echaba de menos  el jamoncito, las torrijas, …  a la familia . La verdad es que me lo he pasado muy bien y espero no tardar tanto tiempo en regresar.
 
Bueno, vamos a lo nuestro … hoy vamos a ver la implementación de un WebServer.
 
En ocasiones puede resultar interesante incorporar un pequeño web server en nuestros módems gprs TC65 ó MTX65. Resulta cómodo conectarse directamente al módem con un navegador y consultar algún parámetro. Pues bien, hoy os pongo un ejemplo que he hecho, algo más largo de lo habitual y que me llevó cierto tiempo en su día, y que implementa eso: un pequeño y simple (muy simple) WebServer. Sirva este ejemplo también como ejemplo de Socket Server. No recuerdo a qué usuario de este blog le dije que en breve pondría un ejemplo de Socket Server en java. Pues aquí está.
 
El ejemplo que os cuelgo aquí  es una parte de uno de mis proyectos al cual le he quitado muchas cosas, entre ellas parte del control de errores, para que no sea tan extenso y sea más entendible. Creo que lo es bastante. De todas formas al quitar código es posible que haya alguna variable o instrucción que no sea necesaria, no me he puesto a revisarlo todo al 100%, sólo que funcione correctamente.
 

  Lee el resto de esta entrada »