Archive for the “Comunic. GSM/GPRS” Category

The following is a useful example of how to easily read RTU Modbus devices via GPRS. There are two ways to complete this task using the GPRS modem MTX65i + MTXTunnel.

The first and classic way is to use the MTX65i + MTXTunnel as a GPRS-serial gateway. This means that when you try to get a reading from a Modbus device, the server connects to the MTX modem’s IP and sends Modbus frames directly to the computer. The frames are read through the MTX modem which acts as a GPRS-serial gateway.

The second way, that I will discuss today, is more suitable when large quantities of computers are involved. Basically, a new feature from the new version of the MTXTunnel v7.14 is used. This new function allows the autonomous reading of Modbus devices connected to your serial port and it also forwards these readings on to the Web Server via JSON object.

modbus

This is the scenario:

  • We have a PLC Modbus RTU. The PLC has a number of readings/records in its internal memory (e.g. a temperature and three meters) which must be periodically read and sent to a Web Server.
  • Every 15 minutes, the MTXTunnel must obtain these readings from the PLC and it does this via the serial port. Record number 20 is the temperature reading while records 21, 22 and 23 are the respective meters.
  • After taking each reading, the MTXTunnel needs to send the values to a Web Server via HTTP GET using a JSON object. However in case there is a GPRS communication failure, it has to be able to store up to 1500 readings in its flash memory so that it can send them as soon as communication is restored.
  • You need to be able to access the MTXTunnel at any time in order to be able to read real-time PLC records as well as being able to write in them and modify PLC configuration records. To resolve this, set the MTXTunnel up like this:

config

Some details from this example to take into account:

  1. This example uses an MTX65i with Modbus RS232 PLC communication, but it could work with an RS485 as well. Therefore you could use the MTX65IND2 model (with built-in RS485 communication).
  2. The following is a summary of this example:
    The modem periodically reads (every 15 minutes) a series of Modbus readings from the PLC and sends them via JSON object to a Web server (to the URL specified in the LOGGER_server parameter). If you can’t send the reading (due to no GPRS network coverage or if the server is down), it stores the data to memory in order to send it later. With Telnet it’s possible to connect to the device directly so you can consult/change the PLC’s records in real time. For this you need to search for the following commands in this manual: AT^MTXTunnel=getmodbus y AT^MTXTUNNEL=setmodbus
  3. The JSON object, that is sent to the specific URL in the LOGGER_server parameter, is encoded in the following way as an example:
    {“IMEI”:353234028103206,”P”:”ID00001″,”A”:1,”TS”:”20/08/12 08:31:44″,”V1″:23,”V2″:275,”V3″:274,”V4″:32765}
    This means that the Web Server receives a JSON object with the modem’s IMEI (IMEI), the password field (P) that we can also use to identify the computer if we don’t want to use the IMEI, the device’s Modbus address (A), the time stamp (TS) which is when the Modbus data was read and V1, V2,… along with every single one of the readings taken.

It’s that easy!!!

Tags: ,

Comments No Comments »

The new version of MTXTunnel is now available, version v7.8. In this new version of MTXTunnel, I have included new features and enhancements suggested by MTXTunnel users. As always, the majority of suggestions do not fall on deaf ears. When interesting suggestions are not used they are written down and included in later versions, especially if they could be useful to other people. So if any MTXTunnel users have any suggestions, I welcome them with open arms!

mtxtunnel

These are the new features:

  1. It now has the ability to read 868MHz Wavelog radio devices (digital input radio equipment). Until now, it was only capable of monitoring Wavetherm radio devices (temperature), Wavesense (4-20mA and 0-5V) and Waveflow (pulse counters for metering applications).
  2. It now has the ability to send embedded AT commands via GPRS-RS232/RS485 gateways, whether it’s the server or client type. This means that it’s possible to send commands through a transparent gateway, like AT+CSQ for example. This command is used to remotely find out a device’s coverage. There are other commands for switching relays, changing settings etc. However this is very useful in scenarios with client type gateways who have telephone operators that do not allow server type connections (from a central PC to the modem) to run through Telnet.
  3. It has the parameter “DNS_mode: remoteat”. This parameter allows you to reproduce an MTX65i/MTX65IND modem’s digital input state in an MTX65IND’s relay. Therefore you can have a switch connected to a GPRS modem in Madrid and switch a modem’s relay in Miami. How does it work? Well basically when the modem detects a digital input change, it sends an AT command to a remote GPRS modem. On receiving this information, the GPRS modem switches the relays if necessary.
  4. It has the parameter MTX_flushSerialBuffers which allows you to clean the serial buffers before creating a TCP connection. Therefore it will delete everything that the modem’s serial port has read before establishing a 232/485GPRS- serial gateway.
  5. TCP_IP2 and TCP_port2 parameters have both been added. Before, you could configure the MTXTunnel to create up to two 232/485 GPRS-serial gateways that ran simultaneously (e.g. a single modem controlling two serial devices). But until now you could only create two “server” gateways. These two parameters now allow you to create two 232/485 “client” GPRS-serial gateways that work simultaneously.
  6. The MTX_clientReconnection parameter has been added. This parameter allows you specify the time (in seconds) that the MTXTunnel has to wait before reopening a client type 232/485 GPRS-serial gateway when it has been closed from the server. By default, it is currently 30 seconds. This means that the MTXTunnel opens a gateway against the server in order to exchange data. If the socket fails or is closed by the server, this parameter specifies the reconnection time.

Here’s the complete manual for the MTXTunnelv7.8. Remember that you can ask for it to be installed in GSM/GPRS modems:MTX65i, MTX65IND, MTX65INDv2, MTX65ULP, MTX65-RS485 y MTX65+G(and in 3G modems soon ;) )

Comments 2 Comments »

A looooong time ago I presented the MTX-INDv1 here which is a GSM/GPRS industrial modem with DIN rail format.  If we remember, that modem had a Cinterion TC65, therefore it was Java programmable with 400KB RAM and 1.7MB flash. It had 6 opto-isolated digital inputs (2 of which could also be configured as opto-isolated outputs), 2 analog inputs, 4 relays and an input power range of 8-30VDC. This modem also has a USB port and 2 ports which are configurable to RS232/485/422. As seen in the video, you could use an 868MHz Wavecard communications card to communicate with sensors via radio, such as Waveflow (pulse counters), Wavetherm (temperature sensors), WaveSense (sensors 4-20 or 0-5V …).

Nowadays we have the MTX-INDv2 version (the MTX-INDv1 version is still in production), which is the modem that I am going to present to those of you who have not heard of it. This is it in the following picture:

modem gsm gprs IP68

It’s basically the same modem ass a big part of the circuit has the same design as the MTX-INDv1. However it has improvements as it is designed for many scenarios that the MTX-INDv1 could not cover. The following are the MTX-INDv2’s characteristics and options:

 

-          It is based on the TC65i GSM/GPRS modem. Therefore it is Java programmable and it also has 400KB RAM and 1.7KB Flash. Alternatively, you can be provided with a TC65i-X internal module. It is exactly the same but with 2MB of RAM and 8MB of flash.

-          6 opto-isolated digital inputs ¡ (2 of which can also be configured as opto-isolated outputs)

-          2 analog inputs

-          4 relay 16A

-          USB port

-          2-port RS232/485/422

 

and here are the main differences:

 

-          IP68 waterproof box. This is ideal for devices that have to be used outside.

-          Power supply 220VAC or 24VDC. This means that you can connect it directly to a 220V network without needing a current adaptor, although it can also be used with 24V DC voltage.

-          It has a 1600mA internal battery which gives it various advantages. For example, you can use you Java application with 220V and if there is a drop in the voltage an alarm can be sent via SMS.

You have many other options:

-          You can order either a 25mW (1Km scope) or 500mW (4Km scope) Wavecard communication card.

-          You can order Ethernet-Serial converter which allows you to connect to a LAN network.

In short, it is an evolved version of the old MTX-INDv1 modem and it allows for a range of very important outdoor scenarios. Another day I will present the MTX-Remote (a series of 868MHz wireless sensors), and also the IP68. I am sure that they will be of interest for many applications that work seamlessly using the MTX-INDv2 as an 868MHz GPRS-radio communications hub.

For those who are interested, here is the MTX-INDv2 datasheet

Comments 2 Comments »

It has been a long time since I last wrote in blogElectronica, therefore I have quite a lot of new things in the pipeline. Some are very, very interesting, especially regarding 3G devices with Java, which I will discuss soon. ;)

However today I will discuss a new GSM/GPRS terminal from the MTX family. Certainly, more than one of you will find it interesting, especially as you are able to save costs involved in some scenarios where you use an MTX65i + RS232-RS485 converter. This is the new MTX65i-RS485 terminal.

What features does it have?

Well, basically they are more or less the same as the well-known, widely used MTX65 but there are some slight differences.  Here are the main features:

  1. GSM / GPRS Class 12 modem
  2. Java programmable, 1.7MB Flash, 400KB Ram (optional 8MB Flash and 2MB Ram available)
  3. 1 RS485 port with terminal block
  4. 1 RS232 port
    modem-gsm-gprs-rs485
  5. 1 USB port
  6. 2 analog/digital convertors
  7. 2 opto-isolated digital inputs
  8. 2 opto-isolated digital outputs
  9. 1 general purpose digital input/output
  10. 1 pulse counter input (up to 1kHZ)
  11. 1 I2C bus

As you can see, the main difference/feature is that the RS485 port is built into the modem; it is different from the MTX65i as it has a higher number of opto-isolated inputs and outputs.

Another important difference is the modem’s ability to turn itself off. If you remember, one of the main properties of the MTX65i GPRS modem is that it’s designed to never, ever be turned off under any circumstances. It always needs to be switched on. This gives you extra security like when modems are installed in rural environments and any in-person interaction with the modem would be traumatic. In this case, this option also ensures that the modem won’t fail you. However if you wish you can also get the modem to turn itself off voluntarily with a special input in the power connector.

 

Can you use this GSM/GPRS modem with MTXTunnel software?

Of course, ever since the MTXTunnel version 7.6 was created, you can use it no problem. I will talk about it on here again to discuss is at a later date.

 

Conclusions

If up until now you are using the MTX65i along with an RS485 converter, you could save on the converter, installation time and physical space with the new MTX65i-RS485 modem. This is a brief conclusion, I will add more later on. I will take this opportunity to wish everyone a happy start to 2013!!!

 

Tags: , , ,

Comments 1 Comment »

Some of you already know that the new Cinterion TC65i-X GSM/GPRS module exists, many others may not, and therefore today I will discuss the most relevant aspects of this new and interesting module. As I said before, the name of this module is TC65i-X and as is suggested by its name, it is basically the TC65i module with a few changes. These positive changes affect the product on both hardware and software levels.

How has the hardware changed? 

Basically for me this change is one of the most important changes of them all, including all of the software changes.  As you know the TC65i GSM/GPRS module is Java programme (J2ME). This module has about 400KB of RAM and 1.7MB of Flash. The new TC65i-X module has greatly increased its capacity and has up to 2MB of RAM and 8MB of Flash memory (split into 2 x 4MB parts).

This is obviously very significant. Those, including myself, who develop large applications, always come to a point when we have to cautiously programme because the TC-65i’s RAM memory is somewhat limited for some applications. Everything changes when you have 2MB of RAM as it is possible to make large and complex Java applications without any problems. When thinking about analog, this can also occur with the Flash memory which is now 8MB.

tc65i-x

What are the software changes in the new TC65i-X module? 

Well there are lots of changes, I will write about what seems most relevant to me.

  1. Finally you can now work with the following as it supports: Entorno Eclipse and MES with 64-bit Windows versions, that is, 32/64-bit Vista and 32/64-bit Windows7. Basically it’s due to the new MES 2.7.0.0 being available.
  2. It includes certain Java API’s for GPS handling (just connect a GPS module to one of the two TC65i-X module’s serial ports).
  3. Transparent TCP sockets – You already know that these days you use AT commands to work with Cinterion TCP/IP stack. To send data through a socket you use the command AT^SISW and to read data you use AT^SISR. However personally for me, the best way to work is with multi-socket. In order to be able to have multi-socket, Cinterion has added the ability to send data through a socket in a transparent manner. This for some users (and for monosocket applications) may be interesting for resolving simple issues.
  4. TLS/SSL support from its own AT commands to socket and to http. Until now it was only possible from Java, but it’s now also possible from AT commands.
  5. COM port gateway. The TC65i-X as well as the TC65i both have 2 serial ports and a USB port. Therefore you can configure the modem so that the data comes through the ASC0 and goes out the ASC1 and vice versa or you can configure the combinations ASC0-USB/ASC1-USB. However it’s a shame that it’s not a permanent configuration in the flash memory and also that you can’t configure it from any ports where it will “intervene in the couple”.
  6. One of the most interesting things for me is the introduction of the AT^SNMON command. This command (even without a SIM) will return a complete list of all GSM antennas around it that are organized by RSSI. For me, this is very important because if you are going to install a modem in a certain place, you can see beforehand which operator will offer you the best coverage without having to go there with a rucksack full of SIMs from different operators.
  7. Continuing from the last point, Cinterion has included the interesting command AT^SPCL. With this command we can make a list of preferred GSM antennas that the modem will try to connect to. So if we have a list of available antennas from the same operator (obtained with AT^SNMON), we could always connect to a specific antenna, for example the one with the most coverage. Or even the other way around, as in some cases you may install a modem that’s only a few metres away from a GSM antenna and then the modem could have signal saturation problems.

Very interesting. So can I use a Java programme that I have developed for the TC65i and put it in the TC65i-X?

No. You need to make a few small changes to the software and you will need to recompile it.

Oh, man, I have programmes for the TC65 and I can run them on the TC65i. Why I can’t I do it with the TC65i-X?

Well it’s for business reasons, Cinterion (the old Siemens M2M) no longer wants to use the word Siemens in its products; this has been dragged out over the past few years. The only change you will have to make in your programs will be to change the line:

import com.siemens.icm

import com.cinterion

That’s all.

So we have a new GSM/GPRS module which is Java programmable with a lot more memory and features. Despite the hard times we are going through, in time there will be more pleasant surprises.

Tags: , ,

Comments 7 Comments »

This weekend I brought a little toy home to mess around with. I wanted to try it out for a long time. It could be useful in some applications in the m2m world which is becoming more and more present in our lives, although many do not realize it.

This little device is a mini camera module with VGA resolution from Comedia which in turn is based on a CMOS sensor from Onmivision (the world’s largest manufacturer of these types of devices, so much so that nearly all of us have one of their sensors in our mobile phones). So far it’s nothing special. The peculiar thing about this mini camera is that as well as its low cost, you can directly control a uart through a serial port with a very basic protocol suitable for everyone.

The latter obviously enormously helps you to be able to control the camera and get a picture of what is happening in the world from any device with a serial port. In my case, I am particularly interested in the possible integration with MTX65i modems, especially with MTXTunnel software. I am assessing how much time it would take to integrate the possibility of “taking a snapshot” from the MTXTunnel or even from the  MTXTunnelGPS.

The camera I’ve been testing is particularly the model I had at hand, the C328R. The following is the block diagram of the camera:

camara-serie-diagrama

It’s a very small camera (only 2cm x 2.8cm), with VGA resolution, with low power consumption (60mA) and as I said before with the serial control peculiarity (UART). Note that this camera has serial ports but doesn’t have an RS232, this means that RX and TX output level is 0-3.3V so we can’t directly connect to a PC’s serial port or a MTX GPRS modem. Fortunately, there is also a small evaluation board called C328-EV232 that allows this and adapts RS232 levels. This is what I am testing.

Here is a picture of the evaluation board next to an MTX65i so that you can see how big it is:

camara-uart

And here is another with the C328 module mounted on its mini evaluation board:

camara-rs232

Together with the mini evaluation board you get a CD-Rom with the datasheet from the camera and from the evaluation board itself, a rapid use test program (which does not work with Win7 but works with WinXP, it doesn’t really matter) and most importantly, the complete manual of the camera’s protocol which tells you how to configure the camera (resolution, compression etc.) and how to get an image from the serial port. It’s fairly informative which means that it is easy to do the first tests. This is a picture of the software test:

camara-serie-ejemplo

Basically, in addition to trying out the test program that comes in the CD-Rom, I have done some tests sending serial frames to the camera from a VB6 program. I followed the protocol and example in the manual and it responds very well. From what I gather, it doesn’t take much to generate the necessary JAVA code to take a snapshot from an MTX terminal.

It’s obvious that you can’t send video streaming from a GPRS terminal as the bandwidth does not allow it. But yes, it could be interesting to occasionally send some snapshots (we’re talking about very few KB, according to the settings less than 10KB per image) as this doesn’t cause any problems for GPRS transmission. For example, if we designed an alarm system using an MTX65i GPRS terminal, it could be interesting as we could send an image as well as sending an alarm. Or it could be interesting for a fleet management system (based on the MTX65 + G) that as well as GPS positioning via GPRS, it allows you to physically visualize the load at any given moment (for example when opening a trailer’s doors).

To conclude, if you sacrifice very little time and money, this little camera allows you to send photographs to any device that has a single serial port free. Small details like this are what differentiate devices that we can design over others, in a world which is becoming more and more competitive and in which there is more and more of everything.

Tags: , ,

Comments 2 Comments »

Today I am going to present an interesting device from the company Multitech. I will be making use of a document written by my colleague Jesús Santos, whom I thank. I will be talking about the MultiConnect AW MT200A2W.

Very good. What is it?

Well, imagine you have a device that uses an analog modem to communicate (one external or internal inside the device itself) or simply imagine that you have a switchboard or a traditional fax machine where data is managed (not voice data).

Now imagine that you want to install this device and for whatever reason but it turns out that you don’t have a free telephone line to connect to or simply imagine that you don’t want to use a new analog line or that the telephone cable installation could be expensive.

For that you need this device. It’s an analog line emulator for GSM (for data). This means that instead of plugging the analog modem into the conventional telephone socket, you can connect it to this Multitech device’s RJ11 opening. Thanks to its internal SLIC (that we’ve already talked about), it’s a module that emulates a telephone line.

How easy! Does that mean that the MT200A2W collects data from the SLIC coming from my analog modem and it sends the data directly through its internal GSM modem?

No, you are missing something. The MT200A2W also has an internal analog modem socket that communicates with your analog modem through SLIC. Therefore sending analog signals directly via GSM through the audio channel wouldn’t work due to the damage that these signals would suffer in the GSM network. Then the data is routed through the internal GSM modem in the Multitech device.

This means [your analog modem] — [SLIC--- analog modem socket --- microprocessor --- GSM modem]

mt100a2w-mt200a2w

Can I not do this with the classic FCT, wireless local loop or gateway that my GSM operator gives me?

No, it won’t work. The devices that you are talking about are designed to connect to analog telephones and to route calls when we phone a mobile telephone, but only to route VOICE calls, not DATA calls. Data calls will NOT work properly with a FCT.

That’s interesting. I understand that you’re talking about the MT200A2W but I see that in reality that there are various models.

Yes, there are two. The MT200A2W, a device designed more for indoor use which has plastic housing and is nicer aesthetically. On the other hand we have the MT100A2W which has aluminium housing, a voltage range, extended temperature range, RS232 port etc. This means it’s more industrial. An important thing to consider when choosing the model is that the MT200A2W model is only able to make calls (calls made by your analog modems) and the MT100A2W is able to both make and receive data calls.

Well that’s all for today. I hope you all had a good holiday. As for me, I had a great 3 weeks holiday. I spent most of the time in Huesca, a great place to relax, to do adventure sports, to eat well as well as always having nice people everywhere. In short, my family and I had a lovely holiday.

Best wishes. ;)

 

 

Comments 5 Comments »

Today I am going to post a short video about  Multitech routers.

Personally I find these routers (any version: GPRS, HSDPA) very attractive in both performance and robustness as well as being good value for money.  It’s rare, very rare, that a Multitech router malfunctions. In fact I don’t remember anyone returning the product for this reason, as I say they are extremely robust. But it’s not rare for users to have some trouble when using DNAT for port mapping (this is the only thing I don’t like about these devices). It’s not that it doesn’t work as the DNAT works amazingly, it’s the fact that the way of doing it is a little different from what you could be accustomed to when using other types of routers.

Well there you go, here’s a short video that shows you how to make a DNAT.

multitech

Tags: ,

Comments No Comments »

A month ago I posted about Coronis telemetry devices. We saw that they have IP68 devices that can read remotely via radio frequency (on the 868MHz band), digital inputs, 4-20mA or 0-10V analog inputs and temperatures/meters for water/gas/electricity. A lot longer ago, I also posted a video about the MTX-Industrial modem which you can optionally order with a Zigbee, Bluetooth or Coronis communications card.

So taking advantage of all of this, I have included an additional, interesting feature to the new MTXTunnelv5.6 (which is an application that as many of you know can be requested in any programmable MTX terminal). I have added a GPRS-Coronis communications gateway.

What do you use a GPRS-Coronis gateway for?

Let’s take an example. Imagine that you have a large area (several kilometres squared) with several hundred water meters that you want to read every day. A water meter quite simply generates a pulse (dry contact) for every X litres of water that flows through it. Therefore we will physically connect a Waveflow to each water meter. The purpose of each Waveflow is to count pulses that are generated by the water meter that it’s associated with i.e. said simply each Waveflow will know about the water that has flown through the meter at all times.

Obviously to read meters we could go to wherever they are every day with a PC + Waveport, but it would probably be better to take a reading from your own office as it’s warm in winter and cool in summer and you also avoid travel costs.  This is where you will find the new GPRS-Coronis gateway useful. Let’s look at this explanatory graph:

concentrador-gprs-coronis-w

As you can see the communications hub is an MTX-Industrial (with optional internal Wavecard) + MTXTunnelv5.6.

Very good and how do I read the data from meters from my office?

Among all of its features, you can use Telnet with MTXTunnel. When connecting to MTXTunnel from your office via Telnet you can send AT commands (e.g. switch a relay remotely), read a digital or analog input, read GSM coverage etc. So I’ve added two simple AT commands called AT^MTXTUNNEL=SETWAVENIS,tramawavenis and AT^MTXTUNNEL=GETWAVENIS. With these two AT commands you can directly send Wavenis frames to the MTX-Industrial’s internal Wavecard via Telnet. This will allow you to read and connect to Waveflow meters.

Yes the MTXTunnelv5.6′s new feature doesn’t get rid of the fact that you have to take a look at the Wavenis protocol manual, but it can save a lot of work. For example if I want to communicate with a remote Waveflow I only have to do something like this:

telnet-wavenis

This means that with “AT^MTXTUNNEL=SETWAVENIS”, we send the “frame in question” to a Waveflow and with “AT^MTXTUNNEL=GETWAVENIS” we get the response received from Waveflow. It’s as simple as that. The same goes for being used with any Coronis device, i.e. to monitor temperatures (wavetherm), distributed digital inputs/outputs etc. You have more information in the manual and of course if you have any doubts you can tell me on the blog or via email jose@blogelectronica / jgallego@matrix.es

Tags:

Comments No Comments »

This is a brief post just to let you know that the MTXTunnelv5.4 is already available. This new version of MTXTunnel is totally compatible with previous versions. Basically, it has two new features in addition to the many that it already has:

On one hand it allows telemetries to be sent via GPRS socket or HTTP (i.e. the state of digital and analog inputs) when there is a change in digital inputs or an analog value is over/under the limit. In previous versions, telemetries could be sent periodically every X amount of time, now they are sent when something changes. It works in the following way: once it detects a “trigger condition”, the states of all digital and analog inputs are read and sent to a remote server.

alarmas-gprs

On the other hand, you can configure MTXTunnelv5.4 as a GPRS ModBus-TCP to ModBus-RTU gateway just by simply adding the following parameter to the configuration file:  ”MTX_gatewayModBus: on”

modbus-tcp-modbus-rtu

As always the User Manual includes working examples. Specific examples with these new characteristics are numbers 2.13 and 2.14 in pages 185 and 187 respectively.

Regards.

Tags:

Comments 2 Comments »