Archive for the “gateways” 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.


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:


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 »

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]


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 »

Good afternoon. A few days ago I posted about a new Multitech device which I was testing that turned out to be very interesting. Today I’m going to continue talking a little bit about Multitech which is perhaps not a very well-known company, but it has always seemed interesting to me especially for a specific application profile.

It’s a family of products with an architecture that Multitech call “Universal Socket”. In short, as the name suggests it’s about a family of communication modules that all have the pin-out in common i.e. if we create a device with PCB designed for use with one of these “Universal Socket” modules, we can interchangeably “click-in” any of these modules.

What types of modules are in this family?

Well there are a total of 10 modules. On one side we have GSM/GPRS/HSDPA communication modules such as SocketModem iCellSocketModem CellSocketModem HSDPA (note is has a Cinterion HC25),  SocketModem EDGE and SocketModem GPRS.


On the other side we have analog communication modems like SocketModem and SocketModemIP.

Finally we have modules that are suitable for other types of communication like SocketEthernet IP (a module which is basically as Serie/Ethernet convertor), SocketWireless Bluetooth (A Bluetooth -serial module i.e. with SPP Bluetooth profile, class 1 (100m range) and  socketWireless Wifi (a wifi-serial gateway for 802.11b/g networks).

So if I design a device for one of these modules, if one day I want to equip my device with GPRS connectivity, Bluetooth, Ethernet or Wi-Fi etc. for a project, would I only have to swap one module for another?

Yes that’s it.

But would I have to make a lot of software changes?

No. The modules have a common serial communication and configuration interface. All multisocket devices are configured through AT commands and some of them (those that provide IP connectivity) have what they call “Universal IP” in Multitech, a common TCP/IP stack i.e. you only need to create a single host software to control each of the modules, whether it’s a GPRS module, HSDPA, Wi-Fi, Ethernet etc.

Very interesting, the best thing I can do from now on is design my devices with one of these modules.

No. Look at the photo of the “Multisocket HSDPA” module in this post, as I said before is put together with a HC25 Cinterion module. What would be cheaper to use, the Multitech module or just the HC25 module? Well obviously it’s cheaper to just use the HC25 module. The same thing happens with “SocketWireless Bluetooth”, it’s cheaper to use a Bluegiga WT11 module than one of these modules. This means that it will depend on the connectivity features that you need for a particular application.

 So when do you recommend to use this type of module?

From my point of view, and as I said from the beginning, they are very interesting but only designed for devices when we want to provide various connectivity possibilities without needing to redesign hardware and with minimal or no software changes (which really saves time designing and improves “time to market”).

 I hope that you find these modules interesting for an application. Until next time. 



Tags: , , , , ,

Comments 1 Comment »

Today I had already started writing an article but then I changed my mind as I preferred to make a short video presentation on the new GPRS terminal that I’m sure will be interesting to more than one of you, in a while it’s going to be very well known.

It’s about the new Matrix terminal, the MTX-IND model, which is a terminal based on the powerful TC65i Cinterion module. I’m sure all of you know this GPRS module that allows you to embed Java applications and is based on an ARM9 like I told you a few months ago.

You’ll see it in the video that I made, but to whet you appetite I’ll tell you in advance that it’s a DIN rail GPRS modem, Java programmable, with 2 RS232/RS485/RS422 serial ports, relay outputs, opto-isolated digital inputs/outputs, ADC converters (0-2.4V / 4-20mA), USB and something even MORE interesting (which isn’t available yet) that you can only see in the video. ;)

Well then, here you have the video, I hope that you like it.

Comments 10 Comments »

I have wanted to write a post about this for quite a while in case somebody would find it useful. It’s about providing Bluetooth connectivity to our Siemens TC65 or MTX65 modems. To do this, by way of example I will describe how to make a Bluetooth-GPRS gateway. At first glance, this type of gateway may not seem useful but as I say by way of example I will give you some ideas. Maybe it makes sense in other applications. For example let’s imagine a project where we want to have Bluetooth connectivity with a machine controlled by an MTX65 that has an embedded Java program. For example with Bluetooth a person who has a PDA can maintain it without having to connect any cables or open any machine.

I’m going to go through it very quickly, let me know if you have any questions as I’m just going to describe how to make the application without going into too many details.

To do this I am going to use an MTX65 modem with the MTXTunnel application embedded inside and a Bluegiga WT11 Bluetooth module that I will use with its development board (the MTX65, the MTXTunnel firmware and the WT11 are all distributed by Matrix in Spain). The reason for using the WT11’s development board is because it has an RS232 port and it’s very easy to connect it to an MTX65 simply with a serial cable. Remember that the WT11 Bluetooth module is in class 1 and therefore theoretically we will have a range of about 100m. If we want a smaller range we can choose the WT12 which is a class 2 Bluetooth module that theoretically has a range of about 20m.

gateway bluetooth gprs

On the other hand I will use my amazing Fujitsu-Siemens T830 mobile with Windows Mobile :) I installed the mobile version of this onto my mobile from the well known puTTY terminal (a small program similar to a HyperTerminal).

The SPP (Serial Port Profile) must be enabled in the Bluetooth module’s configuration. All you have to do to check this is find out the SET command response which is sent to the WT11 from a PC with a HyperTerminal connected. This command shows the current settings.

If you have already enabled the SPP in the WT11 Bluetooth module and you have already configured the MTXTunnel configuration parameters (the client mode, the IP and the port the server will connect to), we can connect the WT11 Bluetooth module to MTXTunnel (through the RS232 connector in the development kit) and supply power to both. By doing this MTXTunnel will automatically connect to the IP address and the specified ports via GPRS. The WT11 will keep waiting to receive an incoming Bluetooth connection.

Now touch the phone. First, install puTTY. Once this is installed we have to pair the phone up with the WT11 via Bluetooth. With the telephone’s Bluetooth connection manager, you can find out the WT11’s Bluetooth services in which you should see the SPP (Serial Port Profile). After this is done, we will link this serial port to one of the phone’s virtual COMs.

Terminal pocketPutty

Now launch the puTTY application and open the COM that is associated to the SPP profile that we linked up earlier. When you are opening the COM with the puTTY, what you are really doing is connecting to the WT12 via Bluetooth. Once the COM is open (i.e. the Bluetooth connection is established), everything that is sent through the terminal (puTTY) from the phone to the WT12 is via Bluetooth. The WT12 then sends it through the (development board’s) serial port to the MTX65 (remember that both are linked by a serial cable). Then the MTX65 sends it to the IP address and the previously specified port via GPRS i.e. we have a Bluetooth-GPRS gateway.

I hope that this has been interesting for some of you, as you can see incorporating Bluetooth connectivity into Bluegiga modules or Siemens/Cinterion modems is really simple. See you next time. ;)  

Tags: , , ,

Comments No Comments »

As I said yesterday, today I’m going to present a new product that Matrix is going to distribute soon. It’s a firmware, only 7 Euros, for the MTX65 GPRS modem that we have already talked about (and of course we are going to keep talking about) in this blog. This firmware + the MTX65 GPRS modem are called MTX-Tunnel.

Basically MTX-Tunnel is a GPRS-serial gateway designed for remote maintenance application this means that you can avoid moving by simply connecting an RS232 serial cable to a device. It’s also designed to provide a GPRS connection to those devices that only have an RS232 serial port (e.g. meters, temperature sensors etc.).

There are other solutions, I’ve already told you about some on here like some Digi routers but the MTX-Tunnel has certain advantages in both performance and price that I will tell you about soon.


To be honest I have to say that this device is special to me, as I have quite involved with the firmware that goes inside the MTX65 and altogether they make the MTX-Tunnel.

That said, for those of you who are interested I’ll put more information on here like I usually do. You already know the question/answer routine.

What is the MTX-Tunnel device used for? 

The MTX-Tunnel is basically a GPRS-serial gateway that allows you to connect to an office with any device that has an RS232 serial port without moving via GPRS. You could do the same thing connecting an RS232 serial cable to the device; you can do it remotely via GPRS with MTX-Tunnel.

Is it complicated to set up?

In all, it is very simple. Basically you have to edit a file with notepad to configure certain parameters (IP, port, baud rate etc.). Once configured, simply drag the file inside the modem as if it were a pen drive. The MTX-Tunnel is then configured.

How does it work? Is it the MTX-Tunnel who connects to the central server in the office via GPRS or does it wait for incoming connections? In other words, does it act as a TCP/IP client or server?

It can be configured to work in two ways.

If MTX-Tunnel is configured to work in client mode, when you power it up it automatically connects to a server i.e. to a certain IP and port (specified in the configuration file). Once the connection is established with the server, all the data that comes from the server through the TCP/IP socket via GPRS is sent out through the serial port and vice versa. All of the data that enters through the serial port is sent towards the server through the socket via GPRS.

In server mode the MTX-Tunnel is connected to the GPRS and is stays listening through a certain port waiting to receive an external connection. Upon receiving the connection it behaves the same as in the previous case. When it comes via GPRS it is sent out through the RS232 serial port and vice versa.

Does MTX-Tunnel have to have a SIM card with a fixed IP address in client mode? 

No, not in this mode seeing as the MTX-Tunnel initiates the connection you don’t need to have a fixed IP. The server that is connects to has to have a fixed IP address, if it doesn’t you need to get an office router with DynDNS so that a DNS type yourOffice.yourDomain can tell you your company’s IP address.

And if it’s in server mode does it have to have a fixed IP address? 

It’s recommended but it’s not essential. If you have a SIM card with a fixed IP address it’s very quick to make a connection. If you don’t the IP you should work out the IP address assigned by the operator (Movistar, Vodafone etc.) to MTX-Tunnel when it connects to the GPRS.

And how do you find out the IP address that has been assigned to MTX-Tunnel by the operator? 

There are two ways. You can make a missed call or send an SMS to MTX-Tunnel. If MTX-Tunnel is configured to do this (indicated in the configuration file), the MTX-Tunnel will return an SMS to the phone number that sent the SMS or made the missed call, the SMS will contain the IP address that has been assigned by the operator.

So anyone who accidentally makes a missed call can get the device’s IP? 

No. In the MTX-Tunnel’s configuration file you can set up to ten valid phone numbers which can request actions like sending the IP address. If the telephone isn’t valid the MTX-Tunnel doesn’t do anything.

Does the MTX-Tunnel have to be permanently connected to GPRS? 

It depends. In client mode yes, the connection is permanent. As soon as the device has power it is connected to a specific IP address and port as I said before. If communication is lost for any reason, the MTX-Tunnel keeps trying to reconnect (every 30 seconds) until it is connected.

In server mode you do not need to be permanently connected to GPRS. If we want to be connected to GPRS at any point, all we need to do is make a missed call or send an SMS with the word “on”. Then you will be connected to GPRS and as I said in point 6, if configured to do so it will send an SMS with the IP address assigned by the operator.

And if MTX-Tunnel is in server mode and you don’t want the connection to be permanent, once you remotely activate the GPRS connection with the missed call or SMS, how do you disconnect from the GPRS connection? 

You can define a time out in the configuration file. Let’s suppose that you set it to 3 minutes. If the MTX-Tunnel doesn’t detect GPRS traffic after 3 minutes it will automatically disconnect from the GPRS network.

And if MTX-Tunnel works in server mode can you connect to any IP? I.e. can intruders connect to my devices? 

No. It’s the same with the telephone numbers. You can set up to 10 IPs that you can connect to in the configuration file. Any other attempted connection with an unauthorized IP is aborted.

But I already have a private VPN network i.e. I’m not going to have any unauthorized access to MTX-Tunnel. Do you need to specify authorized IP addresses like you said in the previous section? 

It’s not necessary. If you specify an authorized IP as you can connect to MTX-Tunnel from any IP address. Remember that this option is only recommended for VPN networks in order to avoid any unauthorized access.

Can you configure the MTX-Tunnel’s serial port parameters?

Of course. You can change the baud rate, flow control, data bits and stop bits. As always you can do all this through the configuration file.

Let’s imagine that we have 100 temperature sensors which are all the same, without any intelligence and all using 100 MTX-Tunnels in client mode i.e. all 100 are permanently GPRS connected to a server. If the MTX-Tunnels don’t have a fixed IP address, how do I know which temperature probe corresponds to which temperature that the server receives? 

MTX-Tunnel has a configurable identification parameter that allows you to set which is sent to the server first once the connection is established. With this you always know which device corresponds to which data in cases like I mentioned where devices work in client mode and don’t have a fixed IP address to send identification.

Will I have a problem with any up to date application that I use with a serial cable if I substitute it for an MTX-Tunnel? 

Usually not, but there is one thing that you should keep in mind. That is that GPRS communications are quick but they have a bit of a delay (just as it’s not the same to work with a LAN via the internet). Let me explain. If you have a question-answer application (a typical example of a PC questioning a temperature sensor), you have to take into account the time from when you send the command from via GPRS to when you receive the answer with the sensor’s data. This obviously will take more time than if you used a cable. It’s the only things that you have to keep in mind so that you can modify the timeout.

There’s more information on Matrix: / telephone 915602737

I hope that you found it interesting. See you next time, have a good weekend. ;)

Tags: , ,

Comments 54 Comments »