La primera consiste en la forma clásica, esto es, en utilizar el módem MTX65i+MTXTunnel como una pasarela Serie-GPRS. Es decir, cuando se pretende hacer una lectura del dispositivo Modbus, el servidor se conecta a la IP del módem MTX y envía las tramas modbus directamente al equipo a leer a través del módem MTX, que actúa de pasarela gprs-serie.

La segunda, más indicada para escenarios donde intervienen gran volumen de equipos, es la que voy a tratar hoy. Básicamente se trata de utilizar una nueva prestación de la nueva versión del MTXTunnel v7.14   La nueva funcionalidad permite la lectura autónoma de equipos modbus conectados a su puerto serie para luego reenviar los datos leídos a un Servidor Web mediante un objeto JSON.

El escenario a llevar a cabo es el siguiente:

• Disponemos de un PLC Modbus RTU. Este PLC dispone en su memoria interna de una serie de variables/registros (por ejemplo, una temperatura y 3 contadores, …) las cuales deben leerse y enviarse periódicamente a un servidor Web.
• Por ello, el MTXTunnel debe interrogar periódicamente, cada 15 minutos, por un puerto serie, al PLC para leer dichos registros. Los registros a leer son, para la temperatura el registro nº20, y los contadores están en los registros 21,22 y 23 respectivamente.
• El MTXTunnel debe enviar tras cada lectura el valor de los registros a un servidor web vía HTTP GET usando un objeto JSON, pero debe ser capaz, en caso de fallo de comunicaciones GPRS, de almacenar en memoria flash hasta 1500 lecturas que enviará cuando se restauren las comunicaciones.
• Debe poderse acceder al MTXTunnel en cualquier momento para, de esa manera poder leer en tiempo real los registros del PLC, así como para poder escribir en ellos y modificar registros de configuración del PLC.

Solución, configurar el MTXTunnel de la siguiente manera:

Algunos detalles de este ejemplo a tener en cuenta:

1. En este ejemplo se utiliza un MTX65i con comunicación RS232 para comunicación MODBUS contra un PLC, pero podría ser RS485 sin problemas. Para ello podría usarse un modelo MTX65IND2 (con comunicación RS485 incorporada).
2. El resumen de este ejemplo es el siguiente: el módem va leyendo periódicamente, cada 15 minutos una serie de registros ModBus del PLC y los va enviando mediante un objeto JSON a un servidor web (a la url especificada en el parámetro LOGGER_server). En caso de no poder enviar el registro (por no haber cobertura gprs en ese momento o estar el servidor caído) almacena los datos en memoria para enviarlos posteriormente. Mediante Telnet es posible conectarse al equipo directamente y consultar/cambiar en tiempo real los registros del PLC (para ello buscar en este manual los comandos AT^MTXTunnel=getmodbus y AT^MTXTUNNEL=setmodbus)
3. El objeto JSON enviado a la URL especificada en LOGGER_server está codificado de la siguiente manera, a modo de ejemplo:

{“IMEI”:353234028103206,”P”:”ID00001″,”A”:1,”TS”:”20/08/12 08:31:44″,”V1″:23,”V2″:275,”V3″:274,”V4″:32765}

Es decir, el servidor web recibe un objeto JSON con el IMEI (IMEI) del módem, un campo password (P) que también puede utilizarse para identificar el equipo (si no se quiere usar el IMEI), la dirección modbus del equipo (A), el time stamp (TS) de cuando se han leido los datos modbus, y V1,V2, … con cada una de las variables leídas.
Así de fácil !!!!

Posts relacionados:

1. Nueva versión MTXTunnelv5.4 disponible Un post breve sólo para informar que ya está disponible...
2. Gateway Bluetooth-GPRS Desde hace ya un tiempo quería escribir un post acerca...
3. MTX-Tunnel-Advanced. Gateway GPRS-RS232 avanzado. Hoy me gustaría presentar un nuevo producto GSM/GPRS orientado a...

Estás son las características introducidas:

1.- Se incluye la posibilidad de leer dispositivos radio 868MHz de tipo Wavelog  (equipos radio de entradas digitales). Hasta la fecha sólo era posible monitorizar dispositivos radio Wavetherm (temperaturas), Wavesense (4-20mA y 0-5V) y Waveflow (contadores de pulsos para aplicaciones de metering)

2.- Se incluye la posibilidad de enviar a través de las pasarelas GPRS-RS232/RS485, ya sean del tipo cliente o servidor, comandos AT embebidos. Es decir, por ejemplo, es posible enviar a través de una pasarela transparente comandos como AT+CSQ para conocer remotamente la cobertura de un equipo, u otros para conmutar relés, cambiar configuraciones, …  Esto es MUY útil en escenarios con pasarelas de tipo cliente con operadores de telefonía que no permiten conexiones de tipo server (desde un PC central hacia el módem) para poder ejecutarlos mediante Telnet.

3.- Se incluye el parámetro “DNS_mode: remoteat”.  Este parámetro permite reproducir el estado de una entrada digital de un módem MTX65i o MTX65IND en un relé de un MTX65IND.   Es decir, por ejemplo, tu puedes tener un interruptor conectado a un módem gprs que está en Madrid y conmutar un relé de un módem que está en Miami.  ¿Cómo funciona?  Pues básicamente el módem cuando detecta un cambio en una entrada digital envía un comando AT vía GPRS al módem remoto, y éste, al recibirlo lo ejecuta conmutando/desconmutando los relés.

4.- Se incorpora un parámetro MTX_flushSerialBuffers que permite limpiar los buffers serie antes de crear una conexión TCP, es decir, eliminando todo lo leido por los puertos serie del módem antes del establecimiento de la pasarela GPRS-serie 232/485

5.- Se añaden los parámetros TCP_IP2 y TCP_port2.  Hasta ahora podía configurarse el MTXTunnel para crear hasta 2 pasarelas GPRS-Serie 232/485 funcionando simultáneamente (por ejemplo para controlar con un único módem dos dispositivos serie). Pero hasta ahora sólo podía hacerse con 2 pasarelas tipo “server”.  Estos dos parámetros permiten a partir de ahora crear también 2 pasarelas GPRS-Serie 232/485 de tipo “client” funcinando simultáneamente.

6.- Añadido el parámetro MTX_clientReconnection.  Este parámetro permite especificar el tiempo, en segundos, que debe esperar el MTXTunnel en reabrir una pasarela GPRS-Serie 232/485 de tipo cliente cuando ha sido cerrada desde el servidor. Actualmente (y por defecto) está a 30 segundos.  Es decir, el MTXTunnel abre una pasarela contra un servidor para intercambio de datos. Si el socket se cae o es cerrado por el servidor, este parámetro especifica el tiempo de reconexión.

Aquí tenéis el manual completo de la aplicación MTXTunnelv7.8 Recordad que puede solicitarse instalado en los módems gsm/gprs:  MTX65i, MTX65IND, MTX65INDv2, MTX65ULP, MTX65-RS485 y MTX65+G ( y dentro de muy muy poquito, también, en módems 3G  )

Posts relacionados:

1. Nueva versión MTXTunnel-v5.6. Inclusión de pasarela GPRS-Wavenis para aplicaciones de telemetría. Hace un mes puse un post sobre los equipos de...
2. Nueva versión MTXTunnelv5.4 disponible Un post breve sólo para informar que ya está disponible...
3. Pasarela Serie-GPRS. MTXTunnel v5.0 Ya está disponible el nuevo MTXTunnel v5.0. Tras un periodo...

Actualmente existe la versión MTX-INDv2 (la versión MTX-INDv1 sigue fabricándose), que es el módem que voy a presentar para aquellos de vosotros que no lo conozca. Es este que muestro en la siguiente fotografía:

Básicamente es el mismo módem (compate buena parte del diseño del circuito) que el MTX-INDv1, pero con mejoras y pensado para muchos escenarios que hasta ahora no se podían cubrir con el MTX-INDv1.  Estás son las características (y opciones) con las que consta el MTX-INDv2:

- Basado en el módem gsm/gprs TC65i.  Por tanto programable en java, con 400KB Ram y 1.7KB Flash.  Opcionalmente se puede suministrar con un módulo interno TC65i-X, que es exactamente igual, pero con 2MB de RAM y 8 MB de flash.

- 6 entradas digitales optoacopladas (2 de ellas configurables también como salidas optoaisladas)

- 2 entradas analógicas

- 4 relés de 16A

- puerto USB

- 2 puertos RS232/485/422

y aquí las diferencias principales:

- Caja estanca IP68.  Esto es ideal para equipos que tienen que estar a la intemperie

- Alimentación 220Vac ó 24Vdc.  Es decir, directamente conectable a la red de 220V sin necesidad de adaptador de corriente, aunque también puede usarse con tensíon continua de 24V

- Batería interna de 1600mA.  Lo que le confiere toda una serie de ventajas. Por ejemplo, puedes hacer en tu aplicación java, que ante una caída de tensión de 220V, pues envíe un SMS de alarma, por ejemplo

Además tiene otras muchas opciones.

- Puede solicitarse con una tarjeta de comunicaciones Wavecard, bien de 25mW (alcance 1Km) o bien 500mW (alcance 4Km)

- Puede solicitarse con un conversor Ethernet-Serie, lo que permite que se pueda conectar a una red LAN

En definitiva, una evolución del anterior módem MTX-INDv1, que posibilita un abanico de escenarios outdoor muy importante. Otro día presento las MTX-Remote, una serie de sensores radio 868MHz, también IP68 que seguro serán de interés para muchas aplicaciones que funcionan perfectamente usando el MTX-INDv2 como concentrador de comunicaciones gprs-radio 868MHz.
Para quien le interese, aquí está el datasheet del MTX-INDv2

Posts relacionados:

1. Nuevo módem GPRS teminal MTX65 basado en el módem Siemens TC65 Matrix Electrónica ha lanzado la distribución de un nuevo modelo...
2. Modems GSM/GPRS. (II) – Modem Siemens TC65 Hoy vamos a ver las pricipales características del modem GPRS...
3. Controlar una pantalla SPI con un módem gprs Cinterion Hace poco tuve que echar una mano en un proyecto...

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

Posts relacionados:

1. Nuevo módem GPRS teminal MTX65 basado en el módem Siemens TC65 Matrix Electrónica ha lanzado la distribución de un nuevo modelo...
2. Nuevo módem GSM/GRPS Siemens MC55i En la actualidad hay muchísimas empresas utilizando el módem Siemens...
3. MTX65-ULP. Módem GRPS Ultra Low Power basado en Siemens/Cinterion   Hoy voy a hablar de un nuevo terminal, del...

Esta semana me ha llegado la noticia de SilverTel de unos nuevos módulos que permiten llevar alimentación, hasta 100W a través de un cable CAT5/6 Ethernet,  para la tecnología HDBaseT

¿Y qué es HDBaseT?

Lo primero a saber es que es una alianza formada por los grandes fabricantes de electrónica de consumo:  LG, Samsung, Sony  y Valens.  La idea es promocionar y comercializar el llamado HDBaseT. Esto permite eliminar múltiples cables y conexiones en el hogar y oficinas para que con un calble CAT5/6 podamos conectar ordenadores, televisores, consolas, reproductores multimedia … entre sí, garantizando un ancho de banda de 10.2 Gbps.

No entiendo que ventaja me ofrece esto.

Un ejemplo. Supón que tienes un disco duro multimedia de 1080 Full HD y el televisor a una distancia de 100 metros. ¿Cómo los conectas?

Con un cable CAT5e y ambos equipos habilitados con HDBaseT.

Mola… pero no tengo enchufe donde quiero instalar la tele.

No haría falta buscar un enchufe para ese televisor situado a 100 metros del reproductor multimedia si usamos la tecnología PowerOverBaseT, llamada  POH.

No me creo que la tele se alimente con esto.

Ahora mismo una TV LED de 40” consumo unos 70W, y está el propósito (consorcio Energy Star 6.0) de que todas las dimensiones de pantallas y televisores LCD y LED no lleguen a los 85W.

Estupendo … Y encima ahorro energía. Explícame un poco más que es esto de POH

Basada en la tecnología PoE, la idea es llevar por el mismo cable (CAT5/6) , los datos y la alimentación  a una distancia de máximo 100m. Al igual que en PoE tenemos el equipo que inyecta la alimentación o potencia, PSE y el equipo que es alimentado PD (en nuestro ejemplo, la tele).

Y … ¿no puedo usar PoE? Ya tengo funcionando en casa y en la oficina teléfonos, puntos de acceso con PoE. ¿los tengo que tirar?

No, aquí no se tira nada,  hay compatibilidad. Si conectas un telefono PoE a la red POH, el inyector PSE lo reconocerá y le dará menos tension/corriente para  cumplir con las especificaciones, osea no tienes que tirar ningún dispositivo existente.

¿Lo reconoce? ¿Cómo?

Al conectarse un equipo POE o POH antes de que la fuente PSE de toda la potencia, alimenta con un par de voltios y hay una comunicación entre ellos ya que el equipo habiitado para POE-POH tiene una firma electrónica interna. Si es válida, el inyector aplica después toda la potencia. Si no, evidentemente el equipo no es POE-POH y no aplica tensión.

Vale. Soy fabricante de equipos y quiero ponerle POH. ¿Qué electronica necesito? ¿Por dónde empiezo?

No nos compliquemos. La compañía SilverTel tiene una larga experiencia en módulos inyectores PSE y extractores PoE, PoE+ y PoE Ultra, y acaba de lanzar unos nuevos módulos Ag6600 y Ag5600 compatibles con la norma POH para HDBaseT. Lleva ya 7 años preparándose para POH. Con estos modulos no necesitarás conocer la norma, con un mínimo de componentes tu electrónica estará lista.

Esto parece dirigido al fabricante de televisores….

No es así. Existen otras aplicaciones donde POH tiene un gran potencial y que se necesite alta potencia. Unos ejemplos son etapas de potencia de sonido (a veces integrada en el altavoz), terminales punto de venta con pantalla, aplicaciones de señalización y paneles.  También donde la seguridad de alimentar en CC sea imprescindible.

Espero que os haya gustado. Es un interesante artículo de mi compañero Jesús Santos. Gracias.

Posts relacionados:

1. Iluminación Power Led Hoy voy a hablar un poquito de los leds de...
2. MTX65-ULP. Módem GRPS Ultra Low Power basado en Siemens/Cinterion   Hoy voy a hablar de un nuevo terminal, del...

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

3.- Sockets TCP transparentes.  Ya sabéis que la manera de trabajar hasta día de hoy con el stack TCP/IP de Cinterion es con comandos AT. Es decir, para enviar datos por un socket hay que utilizar el comando AT^SISW y para leerlos el AT^SISR.  Bien, pese a que para mi (personalmente) la mejor manera de trabajar es esa (para poder tener multisocket) Cinterion ha añadido la posibilidad de enviar datos por un socket de manera transparente. Eso para algunos usuarios (y para aplicaciones “monosocket”) puede resultar interesante por temas de sencillez.

4.- Soporte de TLS/SSL desde los propios comandos AT para socket y para http. Hasta ahora sólo posible desde java. Ahora también con comandos AT

5.- Pasarela de puertos COM. El TC65i-X al igual que el TC65i cuenta con 2 puertos serie y un puerto USB.  Pues bien, puedes configurar al módem para que los datos que vengan por el ASC0 sacarlos por el ASC1 y viceversa, o la combinación ASC0-USB, o la combinación ASC1-USB. La pena de esto es que no sea una configuración permanente en memoria flash y que no puedas realizar la configuración desde ninguno de los puertos que “intervengan en el binomio”.

6.- Una de las cosas más interesantes para mí es la introducción del comando AT^SNMON.   Este comando (incluso sin SIM) te devuelve una lista completa de todas las antenas GSM que tiene alrededor, además ordenadas por RSSI. Esto para mi es muy importante ya que si vas a instalar un módem en algún sitio puedes ver de antemano qué operador te ofrece mejor cobertura en un determinado lugar, sin necesidad de ir con una mochila repleta de SIMs de los distintos operadores.

7.- Un poco al hilo del anterior punto, Cinterion ha incluido el interesante comando AT^SPCL.  Con este comando podemos seleccionar una lista con las antenas GSM preferidas y que será a las que intentará conectarse el módem. Es decir, podríamos llegar al caso de que si tenemos una lista de antenas disponibles para un mismo operador (obtenidas con AT^SNMON) a nosotros nos interese enlazarnos siempre a una determinada antena, por ejemplo a la de más cobertura. O incluso al revés pues se de algunos casos que uno va a instalar un módem que está a unos pocos metros una antena GSM y el módem tiene problemas por saturación de señal. En esos casos mejor sea registrarse usando una antena algo más lejana.

Muy interesante. ¿Y puedo coger un programa java que ya tengo desarrollado para el TC65i y ponerlo en este TC65i-X sin más?

No. Necesitas de unos pequeños cambios en el software y de una recompilación.

Vaya hombre, los programas que tengo para el TC65 sí puedo ejecutarlos en el TC65i. ¿Por qué no puedo hacerlo en el TC65i-X?

Pues porque por razones de empresa, Cinterion (recordad, antigua Siemens M2M) ya no va a usar la palabra Siemens en sus productos, algo que ha ido arrastrando durante todos estos últimos años. El único cambio que tendréis que hacer en vuestros programas es cambiar la línea:

import com.siemens.icm

import com.cinterion

eso es todo.

Pues eso, que tenemos un nuevo módulo GSM/GPRS programable en java, con mucha más memoria y prestaciones. Dentro de un tiempo, pese a los tiempos que corren, más sorpresas agradables.

Posts relacionados:

1. Módulo GPRS tc65 vs tc65i Esta mañana he hecho un test muy básico comparando la...
2. Cambiando el módulo gprs TC63/TC65 por un TC63i/TC65i Como comenté hace ya tiempo,  Cinterion (antigua Siemens) sacó los...
3. Clases java InPort y OutPort para los módems gprs Cinterion y terminales MTX Como vimos hace ya un tiempo, con las nuevas versiones...

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:

Es una cámara muy pequeña, de tan solo 2cm x 2.8cm, de resolución VGA, de bajo consumo (60mA) y como digo con la peculiaridad de control serie (uart). Hay que decir que esta cámara es serie pero no RS232, es decir, la salida de RX y TX es de niveles 0-3.3V por lo que no la podemos conectar directamente a un puerto serie de un PC o de un módem GPRS MTX.  Afortunadamente también existe una pequeña placa de evaluación, llamada C328-EV232, que permite eso, una adaptación de niveles a  RS232 y que es con la que estoy haciendo las pruebas.

Para que veáis un poco el tamaño real de la cámara y su placa de evaluación aquí os pongo una foto junto a un MTX65i:

Y aquí otra con el módulo C328 montado en su miniplaca de evaluación.

Junto a la miniplaca de evaluación también viene un CDRom con el datasheet de la cámara y de la propia placa de evaluación, un programa de test de uso rápido (que no me funciona en Win7 pero y sí en WinXP, tampoco importa mucho) y lo más importante, el manual completo del protocolo de la cámara, esto es, cómo configurar la cámara (resolución, compresión, …) y cómo obtener una imagen vía puerto serie. Está bastante completito en información y resulta sencillo hacer las primeras pruebas. Esta es una imagen del software de test.

Yo básicamente, además de probar el programa de test que viene en el CDRom, he hecho unas pruebas enviando tramas serie a la cámara (desde un programa en VB6) siguiendo el ejemplo del manual del protocolo y responde muy bien. Por lo que veo no cuesta mucho generar el código java necesario para tomar una instantánea desde un terminal MTX.

Es evidente que desde un terminal GPRS no es posible enviar streaming de vídeo pues el ancho de banda no lo va a permitir. Pero sí puede ser interesante enviar en alguna ocasión alguna instantánea (estamos hablando de muy poquitos KB, según configuraciones menos de 10KB por imagen) y eso sí que no presenta problemas para una transmisión GPRS. Por ejemplo, si hemos diseñado mediante un terminal GPRS MTX65i un sistema de alarmas, pues puede ser interesante que además de enviar una alarma exista la posibilidad en enviar una imagen. O para un sistema de control de flotas (basado en el MTX65+G) que además de la localización GPS vía GPRS permita visualizar físicamente la carga en un momento determinado (por ejemplo cuando se abren las puertas del remolque).

En resumen, esta pequeña cámara permite, por muy poco esfuerzo en tiempo y en dinero, dotar de capacidad fotográfica a cualquier equipo que cuente con un simple puerto serie libre. Pequeños detalles como éste son los que permiten diferenciar los equipos que podamos diseñar frente a otros, en un mundo cada vez más y más competitivo y en el que cada vez hay más y más de todo.

Salu2!!!

.

Posts relacionados:

1. Pantallas LCD para dispositivos serie. Posiblemente alguna vez hayáis pensado en incorporar una pantalla en...
2. Conversores USB-Serie de Quatech Cada vez es más raro encontrar ordenadores con puerto serie,...
3. Gateway serie-ethernet Etherlite de digi. Hoy pongo un breve post de un aparato gateway-concentrador serie...

¿Qué es GNSS?

GNSS significa Sistema Global de Navegación por Satélite. Vamos, que “módulos GNSS” son eso, receptores de satélites, sean de la marca o país que sean. Lo que pasa es que usamos la palabra receptores GPS para todo lo relacionado con la localización, y está bien indicado, pero no sólo hay ese sistema americano, hay otros muchos:

• GLONASS sistema Ruso
•  Beiuou-2/Compass en China
• QZSS Japón
• Gagan en India
• Y esperemos que el Europero Galileo previsto para el 2014 …

Fastrax tiene un módulo GNSS., El IT600 (basado en un chipset de ST). Lo estupendo de este módulo GPS es que puede funcionar tanto con el sistema americano GPS, con el sistema ruso GLONASS, como con ambos de forma simultánea.

Alguno pensará … ¿y esto en que me beneficia?

La respuesta es que el receptor funcionará en las condiciones más extremas. Supongamos una calle con edificios altos (lo que se llama cañon urbano). El receptor no solo podrá ver los pocos satélites GPS, sino que también podrá usar los GLONASS.

Veámoslo con un ejemplo.  Fijaros en el gráfico siguiente. Azul claro satélites GPS. Azul oscuro satélites GLONASS.  Ahí tenéis al módulo IT600 trabajando con 22 satélites simultáneamente.

Más claro, ahora sobre un mapa. Aquí tenéis una prueba de conducción en Dallas. En amarillo tenéis la traza de un módulo únicamente GPS, de los más “buenos” trabajando con 4-6 satélites todo el tiempo.  En azul tenéis el mismo recorrido trabajando con un módulo IT600 y con 8-12 satélites simultáneos (tanto GPS como GLONASS).  ¿El resultado?  Brutal, el dibujo lo dice todo.

¿Y me vale la misma antena que uso en mi módulo GPS actual con este IT600?

Pues no.  La frecuencia del GPS difiere un poco del GLONASS. Para que estos receptores GNSS funcionen bien, deben de tener una antena preparada para recibir las 2 señales. ¿Existen estas antenas? Existen.

Muy interesante. ¿Qué otras características destacables tiene este módulo?

Pues muchas. Aquí tienes unas cuantas:

• El módulo IT600 puede asistirse (AGPS) el sólo (lo que se conoce como Autonomous AGPS) o predictivo AGPS.  El más interesante es el primero, ya que él solo se lo guisa y se lo come. Podemos decir, de manera simplificada, que recoje las efemerides, calcula la predicción de la misma para 5 días y las guarda en una memoria Flash SQI (un bus rápido) que lleva dentro. Para la otra posibilidad se necesita el clásico servidor AGPS para recogerlas periódicamente vía GPRS/HSPA.
• DR support (Odometro/Gyro or CAN DWP).
  ¿Y esto qué es?
  Dead Reckoning. Capacidad del receptor de seguir dando posición sin visibilidad de satélites gracias a sensores externos (casi siempre Giróscopo y Odómetro).   Hay que decir que esta característica no está implementada todavía.
• CAN. Pues eso, bus CAN.
• DWP: Differencial Wheel Pulse info.   (algo parecido al odómetro)
• I2C  for MEMS sensors

Lo más importante de todo esto son los sensores que podemos conectar al IT600.  Un acelerómetro da idea de la aceleración que sufre un cuerpo. Tiene que haber un cambio en  su velocidad para que actúe. Un e-compas o magnetómetro mide el campo magnético de la tierra, como las brújulas. Es realmente eso, una brújula electrónica que ayuda al acelerómetro en bajas velocidades (o parado) para saber el rumbo. Muchos móviles y PDAs incorporan la brújula para ayudar en el posicionamiento. Resumiendo sensores: velocidad (odómetro o también DWP), aceleración (acelerómetro), giróscopo (giros) y magnetómetro (brújula electrónica).

Estos sensores se ponen todos juntitos en el bus I2C que lleva el IT600 y él solito usará y sacará la información de los mismos por puerto serie UART.   Y para culminación de todo, además, se le puede conectar el bus CAN  del vehículo.

Vaya módulo, tiene unas prestaciones de infarto …

Pues todavía hay más.  Es un equipo programable, sí, puedes hacer tu propia aplicación y embeberla dentro, es decir, usar el módulo como un microprocesador, pues este módulo lleva un procesador ARM946 con sus GPIOs programables, 3 uart, SPI, I2C, CAN, 2 ADC …   un micro de 208MHz con una capacidad de memoria de 8MBit de Flash y 128KB de SRAM.

Espero que haya sido de interés hablar de GNSS para quienes no conociérais otros sistemas.  Y bueno, aprovecho para desearos a todos una feliz navidad y un estupendo año 2012 (y como no, mucha suerte con la lotería de Navidad de pasado mañana). Madre mía como me toque, jejeje, que barato es soñar …

.

No hay posts relacionados.

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

.

Posts relacionados:

1. Como hacer un manos libres bluetooth con identificación de llamada. Hoy vamos a ver cómo hacer un sencillo manos libres...
2. Nuevo módulo bluetooth de bluegiga WT32 Hoy día 19 de Septiembre Bluegiga, fabricante finlandés de módulos...
3. Utilizando el AS como concentrador bluetooth. En el último post hablamos de los modulitos WT12 y WT11 de...

Como decía, os presento el nuevo módulo Snap Stamp de la casa Imsys. Lo primero de todo, una foto, para que os conozcáis:

Como véis es un modulito muy pequeño, de 29mm de lado (de ahí el nombre Stamp, del tamaño de un sello).  Este módulo está basado, y aquí está lo importante, en el procesador JAVA IM3910.  Es decir, de la misma forma que programamos los módulos Cinterion XT65, TC65i y terminales MTX65 en java (J2ME) se programan estos módulos. Es decir, si ya estás familiarizado con la programación java de los módulos Cinterion y MTX, ya sabes programar el módulo Snap Stamp. Esto, evidentemente, es una ventaja en time-to-market increíble para todos aquellos que tengan que iniciar un nuevo proyecto con un módulo procesador, por el know how y por el aprovechamiento del código y clases java que uno pueda ya tener desarrollado para los módulos Cinterion y terminales MTX.  Es como con éstos últimos, compilas tu programa (en Eclipse o Netbeans) subes tu fichero .JAR al módulo (en este caso no por OBEX, sino por ethernet (ya sea local o remotamente) y a funcionar.

De la misma forma que con los módulos de Cinterion el Snap Stamp tiene un completo stack TCP/IP, pero además servidor web, ftp, telnet, gestor de I/O, …

Aquí están las características técnicas del módulo:

• High performance multi-threaded Java execution
• Certified J2ME-CLDC virtual machine
• Four channel A/D 16-bit 44 ksps converter with optional external reference voltage
• Two D/A 16-bit 44ksps converters
• 2* / 4* / 8 Mbytes Flash memory
• 8 / 32* Mbytes SDRAM
• 10/100Base-T Ethernet MAC and PHY
• Optional 2nd RMII interface
• TCP/IP stack, Web/FTP/Telnet server
• Three serial ports (3.3V levels, 4-wire, 920 kb/s)
• High-speed I2C bus and SPI
• Parallel 8-bit high speed data bus
• 8 to 53 General-purpose digital I/O ports
• MMC / SD card support
• Extensive I/O functions through Java APIs, including PPP, FTP, E-mail, GPIO, Timers
• Enhanced performance for special functions e.g. graphics, crypto, and floating point operations
• Rubus JOS RTOS with failsafe flash file system
• High I/O bandwidth (>650 Mbits/s DMA)
• Real time clock and calendar
• On board Temperature sensor
• 150 / 200* MHz oscillator frequency
• Commercial / Industrial* temp range
• Connection for Imsys JTAG Trace Adapter
• Reference designs available, complete with schematics and firmware for:
Dallas/Maxim 1-wire
CAN
     TFT LCD, Touch panel
       CD quality Audio

Donde pone * indica que es opcional, y se suministran así bajo un pedido mínimo de piezas.

Aquí tenéis también una pequeña comparativa entre el procesador Imsys y distintos procesadores.

Espero que encontréis el modulito de interés. Vamos, conociendo ya a muchos de los fieras que leen este blog estoy seguro que así será y que mañana ya tengo algún email preguntando.

Posts relacionados:

1. TC65i-X Nuevo módulo gsm-gprs de Cinterion programable en java Algunos de vosotros ya conocéis la existencia del nuevo módulo...
2. Java y Autobauding. Tal vez tenía que haber puesto un artículo como el...
3. Ejemplo de FTP Java para módems gprs Cinterion TC65 y XT65 Posiblemente en alguna ocasión tengas que hacer un programita en...

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

Posts relacionados:

1. Banda UMTS en 900MHz Hola de nuevo, como comenté en el anterior artículo,...
2. De la telefonía movil analógica a UMTS ¿Alguien recuerda alquellos tiempos del Moviline de Telefónica? Aquellos móviles...
3. M2M component SIM, SIM-Chip Hace pocos días que mi compañero Jesús Santos, ingeniero de...

Muy bien, ¿y para qué sirve?

Pues imaginate que tienes un equipo que usa, para comunicarse, un módem analógico (uno externo o interno dentro del propio equipo) o que simplemente dispones de una centralita o FAX tradicional donde se manejan datos (no voz).

Ahora imagina que quieres instalar ese equipo y resulta que por lo que sea no tienes una línea telefónica libre para poder conectar el conectarlo o que simplemente no se quiere contratar una línea analógica nueva o que la instalación del cable telefónico (con regatas en paredes y demás) pueda resultar cara.

Pues para eso es este equipo. Es un emulador de línea analógica por GSM (para datos). Es decir, que en lugar de enchufar el módem analógico a la roseta de telefonía convencional lo puedes conectar a la boca RJ11 de este equipo de Multitech que gracias a su SLIC interno, que recuerda (como ya hablamos) es un  modulo que emula una línea telefónica.

¡Qué fácil! Osea que el MT200A2W coge los datos del SLIC provinientes de mi módem analógico y los envía directamente a través su módem GSM interno.

No, te falta algo. El MT200A2W tiene también un socket módem (analógico) interno que se comunica con tu módem analógico a través del SLIC pues enviar directamente las señales analógicas vía GSM por el canal de audio no funcionaría debido a la degradación que sufrirían dichas señales en la red GSM. Después ya si se enrutan los datos a través del módem GSM interno que también dispone el equipo de Multitech.

Es decir:  [tu módem analógico] —- [ SLIC --- socket modem analógico --- microprocesador --- modem GSM ]

¿Y esto no lo puedo hacer con la clásica FCT, wireless local loop o Gateway que mi operador GSM me regala?

No, no te funcionará. Estos equipos que dices están pensados para conectar teléfonos analógicos y routear llamadas cuando llamamos a un teléfono móvil, pero para enrutar llamadas de VOZ, no de DATOS. Las llamadas de datos NO funcionarán correctamente con una FCT.

Es interesante. Veo que hablas del MT200A2W pero en realidad veo que hay varios modelos.

Sí, básicamente hay dos. El MT200A2W, un equipo con carcasa de plástico más pensado para interiores y digamos también más bonito estéticamente. Por otro lado está el MT100A2W, con carcasa de aluminio, rango de tensión y temperatura extendido, puerto RS232, etc …  es decir, un equipo más industrial. Una cosa importante a tener en cuenta en la elección del modelo es que el modelo MT200A2W sólo es capaz de realizar llamadas (las llamadas realizadas por tus módems analógicos) y el MT100A2W es capaz tanto de realizar llamadas de datos como de recibirlas.

Bueno, pues eso es todo por hoy. Espero que hayáis pasado unas buenas vacaciones. Yo por mi parte me lo he pasado genial estas 3 semanas que me he tomado de vacaciones, pues buena parte del tiempo lo he pasado en Huesca, un sitio estupendo para descansar, para hacer deportes de aventura, para comer estupendamente, siempre con muy buena gente por todas partes … en definitiva, que mi familia y yo nos lo hemos pasado muy pero que muy bien.

Salu2!!!

Posts relacionados:

1. Conexión CSD a módulo GSM desde módem analógico Aunque cada vez es más frecuente el uso de comunicaciones...
2. Interfaces de línea telefonica Tal vez en alguna ocasión hemos tenido que diseñar algún...
3. Cómo implementar un WebServer en un módem TC65 ó MTX65 Bueno, ya estoy aquí de vuelta de vacaciones. Esta Semana...

El problema se acentúa sobre todo si el dispositivo que estamos diseñando va a utilizar periféricos USB, por ejemplo porque se va a conectar un pendrive de memoria, una cámara de vídeo USB, un módem GPRS-3G, …   A corto y medio plazo, si las vibraciones son intensas, es fácil ver como los dispositivos USB fallan debido a que físicamente se sueltan del conector. No son pocos los desarrolladores que utilizan incluso silicona para fijar los conectores USB y evitar este problema.

Ya sabéis que yo no suelo hablar de conectores pero sí que me gusta comentar de tanto en tanto algunos que destacan por alguna razón especial. Por este motivo hoy os pongo aquí uno de esos conectores que facilitan la vida del ingeniero. Se trata del nuevo conector de la casa Amphenol LUSB-A111-00. Aquí tenéis una foto:

Si os fijáis veréis que el conector USB cuenta con una pestaña en la zona superior. Esa pestaña es basculante tal y como indico con la flecha dibujada, es decir, podemos subirla haciendo presión con un dedo.

Cuando la pestaña está bajada, dos pivotes se anclan en los 2 agujeros de anclaje que tiene el conector de cualquier dispositivo USB. De esta manera ninguna vibración, por fuerte que sea, va a conseguir desconectar el dispositivo USB de nuestro conector. Se necesita una fuerza de 10Kg para soltarlo por lo que la única manera de soltarlo es de forma intencionada.

Pues eso, otro conector interesante para tener en cuenta y evitar así los problemas y disgustos típicos de equipos instalados en escenarios de fuertes vibraciones.

Espero os resulte de interés para algún proyecto. Salu2.

Posts relacionados:

1. Conector conmutador de antena interna y externa Normalmente no hablo de conectores en mi blog pero el...

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.

Posts relacionados:

1. Cinterion. Nuevos módulos GSM/GPRS LGA Hoy voy a hablar de unos nuevos módulos de Cinterion...
2. Nuevos módulos Siemens / Cinterion TC65i, TC63i y MC75i Tenemos nueva familia de módems. Y es que Siemens /...

Para ello voy a usar un módulo bluetooth de Bluegiga que cuenta con el firmware iWrap en su versión v4, y que me soluciona totalmente la vida para llevar a cabo de manera rápida  y efectiva la aplicación.  Realmente para lo que voy a hacer podemos coger cualquiera de los módulos WT12, WT11, WT41 o WT32. Funcionará con cualquiera, aunque si más adelante quisiera audio, yo me decantaría por el WT32, basado en el Bluecore5 de CSR, más indicado para aplicaciones multimedia (audio stereo).

Bueno, pues vamos a suponer que nuestro “indicador bluetooth de llamada entrante” cuenta principalmente con un micro (uno simple, con dos uarts), un display y un módulo bluetooth WT12 de Bluegiga. Tanto el display como el WT12 los tendremos conectados al micro mediante una uart.

Configuración del WT12

Lo primero que hay que hacer es configurar desde nuestro micro el módulo bluetooth WT12. Para ello desde la uart del micro conectado al módulo de Bluegiga enviaremos los comandos:

SET PROFILE HFP ON
SET PROFILE PBAP ON
RESET

Con ello activamos en el módulo WT12 los perfiles bluetooth HFP (Hands Free Profile) y el PBAP (Phone Book Access Profile, para controlar la agenda del teléfono móvil).  Esto es necesario hacerlo sólo una vez, pues una vez hecho ya queda residente en la memoria NO volátil del WT12.

Asociación / conexión bluetooth.

Ahora lo que vamos a hacer es conectar el módulo bluetooth con nuestro teléfono móvil. Seguramente lo normal sería coger nuestro teléfono móvil, buscar en la sección bluetooth el módulo WT12 y pulsar “conectar”. Esto funciona (lo he probado) pero yo lo quiero hacer al revés, quiero seleccionar en mi display bluetooth mi teléfono móvil y hacer la conexión desde el display bluetooth hacia el teléfono móvil.

Para ello, desde el micro se envía al módulo WT12 el comando:

HFP 0 RING
HFP 0 CALLERID “681319891″ “” 81
HFP 0 RING
HFP 0 CALLERID “681319891″ “” 81

Posts relacionados:

1. Como hacer un equipo GSM manos libres bluetooth con audio PCM Aprovechando que he tenido que probar el interfaz PCM de...
2. Utilizando el AS como concentrador bluetooth. En el último post hablamos de los modulitos WT12 y WT11 de...
3. Gateway Bluetooth-GPRS Desde hace ya un tiempo quería escribir un post acerca...

Bueno, pues eso, aquí pongo un pequeño vídeo donde muestro como realizar un DNAT de puertos.

Posts relacionados:

1. Modem-Router GPRS de Multitech Hoy Sábado voy a hablar brevemente de los modems routers...
2. Optimizando nuestros routers WiFi. Este es un breve artículo para quien le interese optimizar...
3. Módulos Universal Socket de Multitech Muy buenas. Hace unos días escribí un post sobre un...

Pues bien, aprovechando todo esto, en la nueva versión MTXTunnelv5.6 (una aplicación que como muchos sabéis puede solicitarse dentro de cualquier terminal MTX programable) he incluido una prestación adicional muy interesante: una pasarela de comunicaciones GPRS-Coronis.

¿Y pasa qué demonios sirve una pasarela GPRS-Coronis?

Pues pongamos un ejemplo. Imagina que tienes una extensa área de varios kilómetros cuadrados con varios cientos de contadores de agua y los quieres leer cada día. Un contador de agua, muy simple, genera un pulso (contacto seco) por cada X litros de agua que circula por él. Por ello a cada contador de agua vamos a conectarle físicamente un Waveflow. La misión de cada waveflow será la de ir contando los pulsos que va generando su contador de agua asociado, es decir, dicho llanamente, cada Waveflow va a saber el agua que ha circulado por el contador en cada momento.

Obviamente para leer los contadores podríamos acercarnos cada día al lugar donde están éstos con un PC + Waveport, pero probablemente te parecerá mejor hacer la lectura desde tu propia oficina (calentito en invierno y fresquito en verano ) y sin necesidad de gastos de desplazamiento. Es aquí donde encontrarás de utilidad esta nueva prestación de pasarela GPRS-Coronis. Veamos un gráfico explicativo:

Como puedes ver el concentrador de comunicaciones es un MTX-Industrial (con la opción de wavecard interna) + el MTXTunnelv5.6.

Muy bien ¿y cómo leo los datos de los contadores desde mi oficina?

Pues el MTXTunnel, entre sus múltiples prestaciones, tiene la posibilidad de Telnet. Conectándote vía Telnet desde tu oficina al MTXTunnel puedes enviar comandos AT, como por ejemplo para conmutar un relé remotamente, leer una entrada digital o analógica, leer la cobertura GSM, etc etc. Pues bien, he añadido dos comandos AT más, muy simples, de nombre AT^MTXTUNNEL=SETWAVENIS,tramawavenis y AT^MTXTUNNEL=GETWAVENIS. Con estos dos comandos AT puedes enviar tramas Wavenis vía Telnet directamente a la wavecard interna de MTX-Industrial que te permitirán comunicarte y leer los contadores Waveflows.

Sí, esta nueva prestación del MTXTunnelv5.6 no te libra de tener que darle un vistazo al manual del protocolo Wavenis (¡chupao!) pero te puede ahorrar mucho trabajo. Por ejemplo, si yo quiero comunicarme con un waveflow remoto tan sólo tendré que hacer algo como esto:

Es decir, con “AT^MTXTUNNEL=SETWAVENIS” enviamos la “trama pregunta” a un waveflow y con “AT^MTXTUNNEL=GETWAVENIS” cogemos la respuesta recibida del waveflow. Así de simple. Lo mismo vale para ser usado con cualquiera de los equipos Coronis, es decir, para monitorizar temperaturas (wavetherm), entradas digitales y analógicas distribuidas (wavelog), etc etc …  Tenéis más información en el manual y por supuesto, cualquier duda me la podéis dejar aquí en el blog o en jose @ blogelectronica / jgallego @ matrix.es

Posts relacionados:

1. Nueva release MTXTunnel v7.8 Ya está disponible la nueva versión de MTXTunnel, concretamente la...
2. Pasarela Serie-GPRS. MTXTunnel v5.0 Ya está disponible el nuevo MTXTunnel v5.0. Tras un periodo...
3. Nueva versión MTXTunnelv5.4 disponible Un post breve sólo para informar que ya está disponible...

Se trata de un conector de antena. Veamos primero unas fotos y luego os lo explico:

Como podéis ver en las fotos es un conector de antena especial que permite conmutar entre una antena interna y una externe de manera física. Es decir, imaginemos que diseñamos un equipo GPRS en el cual queremos usar de manera habitual una antena interna pero como ya estamos curtidos en el mundo del GSM, y no queremos problemas, lo queremos dejar preparado para poder usar una antena externa en aquellos escenarios en los que instalemos el dispositivo en lugares de muy baja cobertura. Pues bien, con este conector lo tenemos chupao. Usando este conector, cuando físicamente no conectamos una antena externa el equipo radio usará la antena interna pero cuando se conecte una antena externa, el conector físicamente conmutará desconectando la antena interna y el equipo radio usará pues la antena externa.

Como véis, un conector tan sencillo de usar como útil. Está disponible para conectores de tipo SMA, RP-SMA y tipo N.

Cualquier duda, ya sabéis. Salu2!!!

Posts relacionados:

1. Tipos de conectores habituales en las antenas (GSM, GPS, …) Hoy escribo un breve post para hablar únicamente de los...
2. Conector USB antivibraciones Si en alguna ocasión has desarrollado equipos dentro de la...

Pues bien, tan sólo comentar que ya está disponible la nueva revisión de este CDP. En esta revisión se incluye la posibilidad de contar con un módem interno HSPA a 7.2Mbps (ideal para aplicaciones de vídeo, la versión anterior sólo era GPRS) así como algo que echaba de menos en la versión anterior, y es un aumento de las E/S del equipo, pues la versión anterior tenía muy pocas. En esta versión el CDP incluye un conector de 32 pines dedicado a E/S y en el que podrás encontrar adicionalmente un bus SPI, I2C, ADC y entradas / salidas digitales.

El que quiera ver una descripción completa de este equipo así como ejemplos de programación lo mejor que puede hacer es dar un vistazo a una web que ha creado el fabricante exclusivamente para este producto:

http://www.multitech.net/developer/products/cellular-development-platform/

Posts relacionados:

1. Como hacer DNAT con routers Multitech Hoy voy a poner un pequeño vídeo sobre los routers...

Como cualquier cambio que ha habido a lo largo de la historia, todo cambio profundo tiene un lado bueno y un lado malo. El lado bueno de la telemetría es evidente, un ahorro considerable en personal y la posibilidad de controlar en cualquier cosa en tiempo real. El lado malo, la pérdida de puestos de trabajo. Cualquier oficio cuya función principal sea la de acudir a un lugar a hacer una medida o una actuación simple, tiene los días contados.

En el post de hoy voy a describir unos equipos acabados (es decir, en caja, listos para ser usados) algunos de ellos muy conocidos por algunos de vosotros, son los equipos de la marca francesa Coronis (distribuida en España por Matrix) como son: el Wavetherm, Waveflow, Wavelog, Wavesense, Waveport y Wavetalk. Como son muchos equipos voy a hacer una descripción de ellos superficial, únicamente para tener una idea, así vosotros no os cansáis de leer ni yo de escribir . Ya entraré en detalle equipo por equipo más adelante.

Vamos allá. Todos los equipos de Coronis que acabo de nombrar son equipos radio que trabajan en la banda de 868MHz (banda ISM, es decir banda libre, no hay que pagar licencia por usarla). Todos los equipos menos el waveport están acabados en caja IP68 (es decir, son equipos pensados y diseñados para poder trabajar a la intemperie) y cuentan con batería interna que otorga una autonomía a los equipos de hasta 10 años tal y como comentaré más adelante. Estos equipos destacan por dos cosas: la distancia del radioenlace y el bajísimo consumo.

Wavetherm.

Equipo para medir temperaturas. Existen varias opciones pues puede adquirirse un wavetherm que use una sonda Dallas DS1821, o las conocidas PT100 y PT1000. Es un equipo parametrizable, tiene capacidad logger y es posible configurar un umbral de temperatura mínima y máxima a partir de las cuales lance un mensaje de alarma.

Waveflow.

Equipo para realizar telemedidas de contadores de energía, agua y gas. Básicamente consta de un lector de pulsos, es decir, por ejemplo, en un contador de agua cada vez que circulan X litros se abre/cierra un contacto seco. Estos pulsos son “contados” por el waveflow cuya medida se guarda en su interior. Existen waveflows de 2 y 4 entradas.

Wavelog.

Es básicamente un equipo para realizar medidas de entradas digitales o bien controlar salidas digitales. Dispones de hasta 4 entradas/salidas digitales.

Wavesense.

Al igual que el wavelog es para señales digitales, el wavesense se encarga de tomar medidas de señales analógicas. Hay dos versiones. Por un lado está el wavesense para señales de 0-10V y por otro lado el wavesense para leer equipos con salida de 4-20mA

Muy bien, ya veo que Coronis tiene muchos equipos para realizar telemedidas, pero, ¿Cómo los leo?

Con el Waveport.

El waveport es un equipo que está disponible con dos interfaces de comunicaciones. Con puerto USB o con puerto RS232. Básicamente son lo mismo ya que quien use la versión USB realmente tendrá un COM Virtual (usa el típico chip FDTI), es decir, el manejo es idéntico.

El waveport está pensado para conectarse a un equipo inteligente, a un concentrador de comunicaciones, como puede ser un PC, un PLC, … es decir, algo donde haya un programa corriendo que se encargue de decir al waveport “anda, dime qué temperatura indica el Wavetherm con dirección MAC XXXXXXX”.

¿Qué alcance tienen las comunicaciones con equipos Coronis?

Pues depende del tipo de equipo. Los equipos waveport y wavetalk los encontrarás en versiones de 25mW y de 500mW. El resto de equipos sólo en version 25mW.  A grandes rasgos los equipos Coronis de 25mW tienen un alcance real, en visión directa, de 1Km, los de 500mW de 4Km.

¿Y qué ocurre si la distancia es superior a las mencionadas?

Pues que puedes usar los repetidores de Coronis, los equipos Wavetalk. En una comunicación con equipos de Coronis puedes intercalar hasta 3 repetidores, es decir, hasta 3 equipos wavetalk. Es decir, usando equipos de 500mW podrías tener un alcance de radioenlace de hasta 16Km.

¿Entonces siempre es mejor usar equipos de 500mW que los de 25mW no?

Pues no. Son algo más caros, consumen más y a diferencia de los equipos de 25mW no usan FHSS (frecuency hopping) y por tanto son menos inmunes a interferencias. Los equipos de 500mW hay que usarlos cuando por distancia es totalmente necesario.

Ahí arriba decías que la duración de las baterías es de hasta 10 años. ¿Es así?

Sí, pero depende mucho del uso que se haga del equipo y del escenario donde se encuentre. Es algo complicado, por lo que si alguna vez te interesa saber qué duración tendrán tus baterías en un determinado escenario coméntamelo. Para que te hagas una idea, las baterías de un equipo waveflow (para lectura de contadores) al cual se le realice una lectura al día tendrán una durabilidad aproximada de 10 años.

¿Una lectura al día? Qué poco …

Los equipos acabados de Coronis (con baterías) NO están pensados para un uso intensivo de los mismos, al menos no los alimentados con baterías. Son equipos pensados para hacer pocas lecturas en el tiempo y que se van a pasar la mayor parte del tiempo dormidos. Si por ejemplo estás buscando un equipo para realizar la telemedida de un contador cada 10 segundos, un waveflow no te conviene. Podrías usarlo así, pero fulminarás la batería en unas semanas.

¿Y sólo están en versión IP68 con baterías integradas? Me gustaría poder integralos como módulo OEM en un circuito mío, así podría usarlos con otras baterías más grandes o incluso usar un adaptador de 220V para no depender de baterías.

Coronis también tiene la versión OEM de estos equipos. La limitación es el MOQ (Minimun Order Quantity). Es decir, si tienes un proyecto para 100 o más equipos podrás adquirir los módulos OEM. Si es un proyecto para pocas unidades no será posible.

Bueno, por hoy ya está bien. Esto es una lectura muy superficial de estos equipos. No hemos entrado para nada en detalle (estos equipos permiten muchísimas más cosas de lo mencionado aquí). Hoy se trata sólo de una descripción, ya entraré en detalle del protocolo de comunicaciones Wavenis, arquitectura de red, concentradores de comunicaciones etc etc en próximos post.

Posts relacionados:

1. Alcance módulo RF Xbee-868MHZ   Hace ya bastante tiempo puse algunos artículos sobre modulitos...
2. Comunicaciones RF utilizando las WaveCard de Coronis Hoy Sábado vamos a retomar un post que puse ya...
3. Software Remote AT Command para el MTX-Tunnel-Advanced Hace tiempo ya hablé de la pasarela GPRS-RS232 MTX-Tunnel-Advanced, un...