blogElectronica.com

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 »

Si realizas aplicaciones con módems GPRS en muchas ocasiones te habrás encontrado con el problema de que las direcciones IP asignadas por el operador de telefonía son dinámicas.

¿Que qué es una IP dinámica? Pues significa que cada vez que uno de tus módems se conecte a la red GPRS el operador le va a asignar una dirección IP distinta.

En muchas aplicaciones puede no tener importancia, por ejemplo, si yo tengo un módem que recoge datos de un datalogger y al final del día el módem los envía por GPRS a un servidor central pues importa poco que la dirección IP del módem sea dinámica, pues en este caso es el módem quien realiza la conexión hacia un servidor central (que si debe tener una dirección IP fija, o al menos una DNS).

Lee el resto de esta entrada »

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

- (10) Posts

Hola de nuevo. Muchas veces me han preguntado si tiene batería el MTX65 y si no tiene cómo se puede poner una pequeña batería que aguante en caso de cortes de corrientes, permitiendo tener siempre activo el módem.

Pues bien, para aquellos que les pudiese interesar os presento un nuevo accesorio de los MTX que permite dicha función: el MTX-T ACC Battery Pack.
 

 
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.

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

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.

  Lee el resto de esta entrada »

Hace ya bastantes meses que puse un post acerca del MTXTunnel, si recordáis, un firmware para el módem MTX65 que realiza la función de Gateway Serie-Gprs.

En esta ocasión os presento el MTXGpsTunnel, todavía en versión beta (todavía no disponible), que realiza la función de tunel GPS-Gprs. Es decir, un equipo en el que configurando unos parámetros muy básicos como son, entre otros, la IP y el puerto TCP de destino, envía la posición GPS de forma periódica a dicha IP y dicho puerto.

Que nadie se confunda, esto no es ni pretende ser ni de lejos un sistema de localización completo y acabado, sino un producto base sobre el que desarrollar aplicaciones muy básicas de localización, como pueden ser sistemas de balizas GPS u otras aplicaciones muy sencillas de posicionamiento. Está pensado para aquellas empresas desarrolladoras que no sepan sobre comunicaciones GPRS, necesiten hacer una aplicación de localización sencilla y quieran centrar el esfuerzo únicamente en el software de gestión del servidor. El MTXGpsTunnel no cuenta (ni contará) con gestión de roaming, ni posicionamiento a través de celdas de telefonía, ni ninguna otra característica avanzada y ni mucho menos con un software de gestión detrás.   Es decir, quien necesite implementar un sistema sofisticado de localización GPS deberá programar él mismo el módem. El MTXGpsTunnel es únicamente lo que decía antes, un tunel GPS-GPRS (lo comento antes de que nadie me hable de añadir otras prestaciones, que os conozco , por que no puede ser, esto es lo que es, un equipo sobre el que desarrollar, ni por asomo pretendo hacer una aplicación para usuarios finales).

Lee el resto de esta entrada »

Tenemos nueva familia de módems. Y es que Siemens / Cinterion ha lanzado una nueva gama de módems gprs en formato módulo. Se trata de los nuevos módems gprs TC65i, TC63i y MC75i que, como resulta evidente por el nombre, son la evolución de los ya muy conocidos TC65, TC65 y MC75.
 

¿Qué características nuevas tienen estos módems?

Una primera característica a destacar es el reducido tamaño,pues se ha reducido el tamaño de los módulos considerablemente.

Otra característica importante, quizás la más importante, es que ahora monta un procesador ARM9 frente al ARM7 que montaban sus respectivos antecesores, lo que nos permitirá tener todavía más potencia en nuestras aplicaciones.

Por último tamibén podemos destacar el monitoreado RLS para la supervisión de parámetros de conexión y señalización que permite implementar sistemas de detección antijamming.

Lee el resto de esta entrada »

El Vienes el forero Pua me pasó un documento bastante interesante sobre envío y recepción de SMS en formato PDU el cual incluye ejemplos. He decidido publicarlo, pues seguro que a más de uno, incluido yo, puede necesitar darle un vistazo en alguna ocasión.

Aquí tenéis el manual:
 
 
SMS EN FORMATO PDU

1. Introducción

Hay 2 formas de tratar los mensajes SMS:
-modo texto
-modo PDU (Protocol Description Unit)

El modo PDU trata el SMS como una cadena de caracteres en octetos hexadecimales o semioctetos decimales, de cuya codificación resulta el SMS en modo texto. La ventaja de modo PDU respecto al modo texto es que en modo texto la aplicación queda limitada a la opción de codificación que se haya preestablecido, en modo PDU se puede implementar cualquier codificación.

La cadena PDU no solo contiene el mensaje, sino que lleva información del centro de servicio SMS (AT+CSCA?), hora de llegada, tipo de mensaje, información sobre el que envía el SMS, vigencia del SMS, nº de caracteres del SMS, tipo de llamada (nacional ó internacional), tipo de alfabeto usado…

Lee el resto de esta entrada »