blogElectronica.com

Ya tenemos disponible el nuevo terminal MTX-3G-Java. Este terminal guarda muchas similitudes con el conocido módem MTX-65i, pues la base es exactamente la misma. Podríamos decir que es exactamente el mismo terminal que el MTX-65i, pero que en lugar de ser GSM/GPRS es tamibén 3G.

Como seguramente muchos sabéis, el módem MTX-65i tiene en su interior como core un módulo TC65i programable en java. En esta ocasión lo que hemos hecho ha sido desarrollar un módulo 3G compatible pin a pin con el TC65i, pero basado en el módulo EH6 de Cinterion. Ello nos permite poder reaprovechar toda la gran variedad de terminales que tenemos basados en el TC65i, pues únicamente es substituir un módulo por otro (ya sabéis, MTX-65i, MTX-65i-RS485, MTX-INDv2, MTX-65+Gv6, …)

Es por ello que el primer terminal 3G programable en java que está disponible es el llamado MTX-3G-Java, misma base que el MTX-65i y por ello cuenta con 2 puertos serie RS232, puerto USB, 4 entradas/salidas digitales (0-3V), 2 entradas analógicas AD (0-3V), un DAC (0-3V), bus i2C y salida para alimentación externa de 3V.

¿Es todo exactamente igual que el MTX-65i o hay alguna diferencia a nivel HW?

Es muy similar, con alguna diferencia. Las diferencias son básicamente las siguientes. El MTX-3G-JAVA no tiene audio mientras que el MTX-65i sí lo tiene. Las entradas digitales del MTX-3G-JAVA son de 0-3V en lugar de 0-2.4V como tiene el MTX-65i. Además éstas se controlan mediante I2C. Los ADs también son de rango 0-3V en lugar de 0-2.4V y también se usan a través de un bus i2C interno. El DAC está mejorado con un chip dedicado en lugar de una salida PWM con un RC como tiene el MTX-65i.  También el MTX-3G-JAVA tiene mucha más memoria RAM y FLASH que el MTX-65i (6MB/10MB frente a 400KB/1.7MB). El resto es exactamente igual como podéis ver en la siguiente ilustración

¿Y a nivel de software, un programa java que tengo corriendo en el MTX-65i lo puedo migrar al modelo MTX-3G-JAVA sin más?

No. De forma directa no, pero a nivel de código sí que es en un 99% compatible. Hay que cambiar algunos “imports”, el nuevo terminal es más estricto en temas de mayúsculas, minúsculas, comillas … pero en general el código es igual (el tema de los GPIOs y ADs sí que exige especial atención, pues hay que usar el bus i2c). Sí cambia mucho la parte del autostart (el arranque automático de aplicaciones java) ya que este terminal, a diferencia del MTX-65i en el que sólo podías arrancar 1 única aplicación, permite ejecutar múltiples aplicaciones java de forma simultánea.

También se permite ahora el uso del puerto USB desde java, poder enviar comandos AT a un puerto serie mientras tenemos una aplicación java corriendo dentro, … en fin, un montón de mejoras.

¿Y el firmware MTX-TUNNEL, yo lo uso ahora con el MTX-65i, funcionaría en el módem MTX-3G-Java?

Efectivamente, el MTX-TUNNEL v8 está disponible ya para ser usado en todos los terminales, incluído el nuevo terminal MTX-3G-Java (e incluso el nuevo modelo MTX-3G-JAVA+B (con batería) que está a punto de salir )

A continuación muestro un ejemplo práctico de cómo leer dispositivos ModBus RTU de forma sencilla a través de GPRS. Existen dos maneras de realizar esta tarea utilizando un módem gprs MTX65i+MTXTunnel.

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

Etiquetas: gprs, modbus

Ya está disponible la nueva versión de MTXTunnel, concretamente la versión v7.8.  En esta nueva versión del MTXTunnel he incluido básicamente nuevas prestaciones y mejoras sugeridas por usuarios del MTXTunnel. Como siempre la mayoría de las sugerencias que me comentan los usuarios no caen en saco roto, si no que las anoto y las incluyo en versiones posteriores siempre que sean interesantes y que puedan ser de utilidad para más gente.  Así que quienes estáis usando la aplicación MTXTunnel, si tenéis alguna sugerencia, ¡sabed que las recibo con los brazos abiertos!

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  )

Hace ya muuuuucho tiempo presenté aquí el MTX-INDv1, un módem gsm/gprs industrial, en formato carril DIN.  Aquel módem, si recordamos, constaba de un core Cinterion TC65 (por tanto, programable en Java, con 400KB ram y 1.7MB flash). Disponía de 6 entradas digitales optoacopladas (2 de ellas configurables también como salidas optoaisladas), 2 entradas analógicas y 4 relés, con un rango de alimentación de entrada de 8-30VDc. Este módem también cuenta con puerto USB y con 2 puertos configurables como RS232/485/422. También, como se veía en el vídeo, podía montar una tarjeta de comunicaciones Wavecard, de 868MHz, para comunicarse con sensores vía radio, como son waveflow (contadores de pulsos), wavetherm (sensores de temperatura), wavesense (sensores 4-20 o 0-5V …)

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

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

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

¿Qué características tiene?

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

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

 

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

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

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

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

Conclusiones.

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

Etiquetas: cinterion, gprs, gsm, mtx65

Hoy en día ya parece claro qué es PoE y la ventajas que significa. PoE, acrónimo de Power Over Ethernet es la posibilidad de llevar alimentación a través del cable Ethernet, facilitando la instalación de múltiples sistemas electrónicos que tienen como interfaz una conexión de Ethernet.  Esta tecnología está estandarizada a través del IEEE 802.3af y IEEE802.3at y hoy en día podemos encontrar electrónica y equipos tanto inyectores o  extractores donde el fabricante ha optado por montar un módulo tipo SilverTel.  Estos módulos son fáciles de integrar requiriendo un mínimo de componentes externos cumpliendo normas y seguridad, y lo más importante hoy en día, a bajo coste.

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.

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

¿Y cuales son los cambios a nivel hardware?

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

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

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

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

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

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

Lee el resto de esta entrada »

Etiquetas: cinterion, java, tc65

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

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

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

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

Lee el resto de esta entrada »

Etiquetas: cinterion, mtx65, mtxtunnel

Hoy vamos a hablar de GPS, o mejor dicho, de GNSS.  Hace pocos días cayo en mis manos un documento, muy explicativo, realizado por mi compañero Jesús Santos a raiz de un nuevo producto lanzado por la empresa Fastrax que muchos conocéis. Creo que puede ser de bastante interés para muchos de vosotros, sobre todo los que os dedicáis al tema de localización. Así que aquí os os pongo el artículo.

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

  Lee el resto de esta entrada »

Etiquetas: gps

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

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

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

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

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

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

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

TC65i  (Slave)    WT32 (Master)

RXDAI             OUT
TXDAI             IN
FSIN                SYNC
BCLK               CLK
GND                GND

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

TC65i  (Master)   WT32  (Slave)

RXDAI              OUT
TXDAI              IN
FS                       SYNC
BITCLK            CLK
GND                  GND

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

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

SET CONTROL AUDIO PCM PCM

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

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

SET CONTROL PCM 08400000 006C

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

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

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

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

Venga, que ya queda poco !!!!

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

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

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

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

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

Salu2!!!

.

Etiquetas: bluegiga, bluetooth, cinterion, gsm