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

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

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 »

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 »

Hoy os voy a presentar un interesante equipo de la casa Multitech aprovechando un documento escrito por mi compañero Jesús Santos, a quien doy las gracias. Se trata del MultiConnect AW MT200A2W.

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 ]

Lee el resto de esta entrada »

Hoy voy a poner un pequeño vídeo sobre los routers de Multitech. Personalmente estos routers (en cualquier versión: GPRS, HSDPA) me resultan muy atractivos tanto en prestaciones como en robustez y además tienen una muy buena relación calidad precio. Raro, muy raro, es que un router de Multitech tenga problemas de funcionamiento, de hecho no recuerdo ningún caso de devolución por problemas de este tipo, como digo son tremendamente robustos. Pero no es extraño que los usuarios tengan algún lío (y esto es lo único que no me gusta de estos equipos) con el tema del DNAT, para el mapeo de puertos. No es que no funcione, ni mucho menos pues el DNAT funciona de maravilla, sino que la manera de hacerlo es un poco diferente de lo que uno puede estar acostumbrado con otro tipo de routers.

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

Hace un mes puse un post sobre los equipos de temetría de la casa Coronis. Vimos que disponen de equipos IP68 para leer remotamente vía radiofrecuencia (en la banda de 868MHz) entradas digitales, entradas analógicas de 4-20mA o 0-10V, temperaturas y contadores de agua, gas ó electricidad. También, pero de esto ya hace mucho más tiempo, puse un post con un vídeo sobre el módem MTX-Industrial el que opcionalmente puede solicitarse con una tarjeta de comunicaciones Zigbee, Bluetooth o Coronis.

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