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 
)
)
abr292013
Lectura autónoma de dispositivo ModBus RTU y envío de datos por GPRS
Escrito por blogElectronica en 2.DISPOSITIVOS (práctico), Comunic. GSM/GPRS, gateways
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:
- 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).
- 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)
- 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 !!!!
Así de fácil !!!!
Etiquetas: gprs, modbus
feb282013
Nueva release MTXTunnel v7.8
Escrito por blogElectronica en 2.DISPOSITIVOS (práctico), Comunic. GSM/GPRS,Comunicaciones Radio
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 )
)
feb262013
Módem gsm/gprs MTX-INDv2
Escrito por blogElectronica en Comunic. GSM/GPRS, Comunicaciones Radio
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
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
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.
No hay comentarios.:
Publicar un comentario