blogElectronica.com

Hace unos días hablé del nuevo MTXTunnelv5.0.   Como comenté entonces, este software que pueden montar opcionalmente los módems MTX, permite llevar a cabo multitud de aplicaciones, no sólo una pasarela GPRS-RS232. Hoy voy a comentar cómo utilizar el MTXTunnel v5.0 para controlar relés mediante SMS (es decir, por ejemplo se puede activar/desactivar luces, calderas, … mediante un mensaje SMS).
 
Como queremos conmutar relés, vamos a suponer que el MTXTunnel5.0 se está utilizando con un módem MTXIND (de Matrix), pues es el único módem de la familia MTX que incorpora relés. Realmente el MTXTunnel5.0 no es que esté concebido para conmutar relés, sino que va mucho más allá, el MTXTunnelv5.0 tiene la posibilidad de ejecutar comandos AT mediante SMS.

¿Y que quieres decir?
 
Pues quiere decir que ahora vamos a ver cómo conmutar unos relés por SMS, pero que podría usarse el mismo concepto para conmutar una salida digital, leer una entrada analógica o digital, leer la cobertura GSM del equipo, …
 
 
¿Entonces quieres decir que para conmutar un relé del módem gsm MTXIND basta con enviar un SMS con un comando AT?
 
Eso es. El MTXIND dispone de 4 relés llamados RL1,RL2,RL3 y RL7. Estos relés están asociados, respectivamente, a los GPIOs 1,2,3 y 7 del core del módulo, es decir, del módulo TC65i interno que gobierna el MTXIND.
 
Por ejemplo, si queremos actuar sobre el relé RL1 (relé asociado a GPIO1) bastaría con enviar el comando AT:   AT^SSIO=0,0  para activar el relé  y el comando:   AT^SSIO=0,1   para desactivar el relé. Cuando digo “bastaría con enviar el comando” me refiero a enviar un SMS con el texto “AT^SSIO=0,0″ ó “AT^SSIO=0,1″. Es decir, el fichero de configuración el MTXTunnelv5.0 que nos permitiría gobernar los relés del equipo por SMS podría ser así:

 
MTX_PIN: 0000    Si la tarjeta SIM no tiene PIN, dejar en 0000
MTX_model: MTX65IND   El modelo MTX escogido es el MTX65IND por los relés
MTX_mode: none    No necesitamos túneles serie-gprs

SMS_allPhones: off   Sólo queremos que puedan actuar teléfonos autorizados
SMS_validPhone1: 666123456  Teléfono autirizado nº 1
SMS_ATEnabled: on   Se aceptan comandos AT por SMS

Lee el resto de esta entrada »

Muy buenas a todos. Hoy voy a poner un breve post de un nuevo producto que ha llegado a mis manos hace unos pocos días y sobre el cual he empleado un tiempecito en hacer algunas pruebas. Ya sabéis que siempre que puedo comparto aquí en mi blog las cosas (que a mi parecer) pueden ser interesantes.

El producto que voy a comentar es el llamado CDP (ó Cellular Development Platform para quien como a mi no le gusten demasiado las frías siglas). Es un equipo de la empresa Multitech.

 
 ¿Y qué es el CDP?
 
Pues básicamente es una plataforma ARM9 en caja (de metal, muy robusta) con un linux embedded (kernel 2.6.28.x) que cuenta con un módem GPRS ó 3G interno y con portasim integrado, GPS interno, ranura para tarjetas de memoria SD, puerto USB Host, Puerto RS232 y puerto ETH. Como siempre nada mejor que unas fotos clarificadoras.

 
¿Y no tiene GPIOs?
 
Sí, también tiene GPIOs, aunque están en pines compartidos con el conector DB9 del puerto serie, dicho de otra manera, es posible usar las señales DCD, RI, DSR o DTR como E/S.  También dispone de leds (5 en total) en el frontal para ser controlados por parte del usuario.
 
En las pruebas que he hecho he usado algunas  GPIOs sin mayor problema, pues con el SDK se suministran los drivers adecuados para controlar todos los periféricos (GPIOs, RTC (reloj en tiempo real), sensor de temperatura, …)

  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 »

Hola de nuevo a todos, espero que hayáis disfrutado de vuestras vacaciones.
 
Supongo que a muchos, como a mi, se os acaban las vacaciones esta semana y toca volver al deber la semana que viene. Animo!!!
 
Yo este año he estado combinando un poco trabajo y vacaciones, pero aún así me lo he pasado bastante bien. De las tres semanas de vacaciones he estado, como cada verano, una semanita en Huesca con la familia de Sonia, 4 días en Peñíscola (ahí si que no he hecho más que descansar )y el resto por casa, en Cardedeu.
 
La verdad es que hace casi tres meses que no escribo nuevos posts (aunque sí que intento siempre encontrar un hueco para contestar a todo el que comenta los posts del blog). La razón fundamental es que he estado obsesionado muy ocupado en estos últimos tiempos en varios proyectos. Especialmente he estado muy ocupado con la nueva versión de firmware del MTXTunnel, la v5.0, que verá la luz durante este Septiembre de 2010. Me ha llevado muchísimo trabajo pero creo que el resultado final merece la pena. Ya os la presentaré cuando tenga 100% finalizada la documentación, que es básicamente lo que estoy terminando.
 
También estas vacaciones he dedicado un tiempo para replantearme un proyecto que he intentado llevar a cabo en un par de ocasiones, pero que por unas cosas o por otras no he conseguido que funcione tal y como tenía en mente: un foro de electrónica. Y es que muchos posts del blog tienen demasiados comentarios ya y creo que lo mejor es un foro. Sí, ya sé que tengo uno integrado en mi blog, pero es que es excesivamente lento y tedioso de usar. Y si a mi me da pereza entrar por lo lento que es (y no digamos ya de administrar) supongo que a los “navegantes” que lleguen a él, pues más.
 

 
Para este nuevo foro he comprado el script del Sistema de foros de VBulletin, algo caro (195$), pero después de lo que he leído (y probado), creo que simplemente es el mejor. Ahora me falta comprar el VBSeo, un mod para VBulletin, pero imprescindible para el buen posicionamiento en buscadores, que es de donde siempre provienen la mayor parte de las visitas. Al menos a mi, que entre todas mis webs suman casi 2 millones de páginas vistas al mes, las visitas provienen en más de un 85% de los motores de búsqueda.
 
Por otro lado, a parte del script para el foro está el tema del nombre del dominio a usar. Quería un dominio distinto de blogElectronica.com, pero como casi todo el mundo sabe, el tema de los nombres de dominio de Internet está a día de hoy muy complicado. Todos los dominios .COM , buenos y malos, están registrados. A mi personalmente me parece totalmente imprescindible tener un buen nombre de dominio (.COM) para cualquier proyecto con presencia en Internet. No es que sea determinante para que un proyecto tenga éxito pero sí es una ayuda muy grande en cuanto a generación de tráfico type-in, en SEO y en branding. Así que, viendo que “por suerte” los antiguos propietarios de los dominios “foroElectronica.com” y “foroDeElectronica.com” los tenían en venta, he negociado con ellos un precio y los he comprado, pues, aunque me han salido algo caros (unos 500€ al cambio), considero que ambos dominios son los más apropiados para un foro de electronica.
 
Como véis, tal y como decía el actor Richard Attenborough en su papel en Jurassic Park “no hemos reparado en gastos” con mi nuevo foro.
 
Por el momento no eliminaré el antiguo foro incluído en blogElectronica, pero por favor, para introducir nuevos comentarios, usar foroElectronica.com 

 
En fin, no me enrollo más. Que tengáis una feliz re-entrada en el trabajo !!!

 
Salu2.

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 »

Hola de nuevo, como comenté en el anterior artículo, hoy doy paso a la segunda parte del artículo de Jesús. En este caso trata de la nueva banda UMTS 900MHz que veremos en la calle dentro de un tiempo. Este artículo, como el anterior, también ha sido publicado en www.redeweb.com (de mayo 2010). Revista en la que por cierto, también aparece anunciado brevemente el MTX-Tunnel-Advanced, hecho por un servidor
 
Aquí tenéis a el artículo:
 
Existe actualmente una fuerte necesidad, negocio y momento para lanzar UMTS en la banda de 900MHz, que ayudará a los operadores extender eficientemente servicios de voz, y un gran ancho de banda móvil para datos en la bandas de baja frecuencia.
 
En Europa, los terminales móviles operan según las especificaciones GSM, en dos bandas, la de 900MHz (880-915MHz, pareada con 925-960MHz) y 1800mHz (1710–1785 MHz pareada con  1805–1880 MHz). El 27 de Julio de 2009 el congreso de Ministros Europeo aprobaron la propuesta de la directiva GSM (Comisión Europea) para legislar el uso del espectro de radiofrecuencia para dar luz verde al desarrollo de tecnología 3G en la banda actual de 900MHz, el llamado UMTS900. Esta comisión adopta la decisión de forzar como directiva la coexistencia de teléfonos 2G/GSM con este nuevo sistema UMTS móvil en la frecuencia de 900MHz. Las administraciones nacionales tendrán la decisión final de habilitar este espectro de frecuencia para 3G. La especificación técnica para esta nueva banda 3G, WCDMA-HSPA en la banda de 900MHz (UMTS900) ha sido acabada por el grupo 3GPP en diciembre de 2005.
 
 
Beneficios de UMTS900
 
El hacer llevar cobertura total 3G en la banda de 2100 MHz es algo económicamente extenso, en algunos casos difícil y podría llevar demasiado tiempo a los operadores. Una de las ventajas de la banda de 900MHz es que las pérdidas de retorno son mucho menores. Para el mismo servicio y cobertura, se requieren de menos estaciones base. La cobertura en edificios es mejor en 900MHz, traduciéndose en mejor Calidad de Servicio –QoS-
 
Los usuarios de telefonía móvil cada vez más se suscriben a redes 3G (WCDMA) donde se solicitan mayor transmisión de datos de alta velocidad, a menor precio, con tarifas planas, incluso en situaciones de no movilidad (domicilio). UMTS900MHz puede dar respuesta a estas necesidades.
 

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 »