Posts Tagged “cinterion”

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



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.


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


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:


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


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:


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 »

In order to make the most of the fact that I have had to test out the PCM interface from Cinterion modules and from Bluegiga Bluetooth modules, I will post about it as it will be of great help to those who want to develop a hands-free GSM device (via Bluetooth). In order to not complicate matters, I will post the information in a simplified, practical way. Well, here we go…

1.- Let’s take a DSB75 evaluation board where we insert the Cinterion GSM module that we want to use (a TC63i, a TC65i, a PH8 etc.) In my case I have a TC65i.

2.- Locate the pins on the DSB75 evaluation board that correspond to the PCM audio pins. They specifically correspond to the board’s x703 connector. In this connector we will see 7 pins: TXDAI, RXDAI, FS, BITClk, FSIN, BCLKIN and GND.


3.- Out of these 7 pins, we only need 5 that are using PCM. The choice you make will depend on whether you use the Cinterion module in PCM MASTER mode or PCM SLAVE mode.  If you use the Cinterion module in PCM MASTER mode, use the TXDAI, RXDAI, FS, BITCLK and GND pins. If we use the Cinterion module in PCM SLAVE mode, use TXDAI, RXDAI, FSIN, BCLKIN and GND pins. The following photo shows how I used it in SLAVE mode with the cables connected to these 5 pins.


4.- We took a Bluegiga development kit (the simplest to use is the WT32 Bluetooth module). The reason for choosing this kit is because it has the PCM pins available in the development kit’s PCB. In Bluegiga’s PCB you can easily see where the PCM pins are due to the good screen.


5.- Connect the GSM Cinterion’s PCM pins with the Bluegiga WT32 Bluetooth module’s PCM pins. Basically you have to connect the pins as follows:

TC65i  (Slave)    WT32 (Master)

RXDAI             OUT
TXDAI             IN
FSIN                SYNC
BCLK               CLK
GND                GND

What if you want the opposite? If we wanted to use the GSM module in MASTER mode it would be like this:

TC65i  (Master)   WT32  (Slave)

RXDAI              OUT
TXDAI              IN
FS                       SYNC
BITCLK            CLK
GND                  GND

So once you have done this, all of the hardware is connected. Now you need a Bluetooth hands-free earpiece. I have one from Plantronics with MAC Bluetooth: 00:03:89:a5:a6:72 (I mentioned it because I will use it later).

6.-The next step is to configure the WT32 Bluetooth module to route audio to/from the PCM interface. We do this by sending the following command to the WT32 module via a HyperTerminal at 115200,8,N,1:


7.- We’ve set up the PCM configuration to the Bluetooth module. Due to the complexity of the different PCM configurations, we use an Excel provided by Bluegiga. With this excel we can indicate the configuration that we want and this way we easily obtain the PSKEY_PCM_CONFIG32 value that we need to configure the PCM. In this case PSKEY_PCM_CONFIG32 has a value of 0×08400000.


As in the previous point we can configure the PSKEY by a command from the HyperTermainal:

SET CONTROL PCM 08400000 006C

8.- Now we are going to configure the Cinterion GSM module to use the audio’s digital interface. These commands can have different functions depending on the model used. I am going to do it with a TC65i. Therefore, from a HyperTerminal we send:


So let’s configure the module to use the PCM digital audio in SLAVE mode at 512MHz and Long Frame.

At this point we have already configured both the Bluetooth module and the GSM module.

So now let’s try the audio!!!!

9.- From the Bluetooth hands-free earpiece (that I imagine is already paired with the Bluegiga Bluetooth module), we can connect to the Bluegiga Bluetooth module (by pressing the only button that it has).

10.- Next we physically connect the TC65i module’s ASC0 RS232 serial port to the WT32 Bluetooth module’s serial port with a serial cable crossover.

11.- We make a GSM audio call from a mobile telephone to the TC65 GSM module. On receiving the call, the module lets out a “RING” from the serial port that will be received by the Bluetooth module in order to inform the Bluetooth earpiece that there is an incoming call (we hear the typical beep beep of an incoming call). We answer the call by pressing the button on the Bluetooth earpiece.

12.- Once you have done this, we answer the voice call in the GSM module with the typical ATA command. If everything has gone well up to now, we will be talking with our hands-free Bluetooth earpiece, connected via Bluetooth to the Bluegiga WT32 module and this in turn is connected to the Cinterion GSM module through the PCM interface.

Well, that’s all for today. This post is perhaps a bit complicated to understand if you don’t have the devices in front of you. But you’ll see that if you ever need to do something similar, this post will be a gem and it will save you lots of working hours. I’ll be fine if I ever need to do it again because I have had to assemble this 3 times over the years. I always think that I won’t forget how to do it but something always slips my mind. From now on this won’t happen ;)



Tags: , , ,

Comments No Comments »

Today we are going to touch on and dig out some old, published articles here on from several months ago, nearly two years ago. Do you remember this article from the end of 2009?

In this article, I talked about the imminent appearance of the new EU3 Cinterion module highlighting that one of its greatest strengths was that it supported the new 900MHz UMTS band that was approaching. The following is worth remembering from this article:

“From a technical point of view it’s better because it offers a greater coverage and penetration than the current UMTS2100, which is ideal for rural coverage and even coverage in cities where the greater the ability to penetrate, the better the coverage in buildings.

It’s obvious from an economic point of view.  One reason is that in order to have a greater scope to cover a specific area, you need to install less base stations with UMTS900 than UMTS2100. Another reason is that the current GSM stations are still valid and they only require small, inexpensive adaptations unlike the UMT2100.

I only have one more tip for those of you who are going to start a new project today with GSM/GPRS modules and who are looking into the future and who are evaluating modules from different manufacturers. The tip is that you read the announcement in the news about the new EU3 module published on Cinterion’s website. Pay special attention to this title, “Cinterion Announces First UMTS Module to Support Seamless 3G Transition for Existing GPRS/EDGE Designs”.


A little later in the article from May 2010:

We talked about everything more deeply on a technical level with the 3G 900MHz (it is recommended reading). One thing to note from this article, as many people asked and will ask this question, is that both in the text as well as in reader’s comments is the clarification that current GSM/GPRS technology (at 900MHz) will coexist with the new 900MHz UMTS.

Finally 10 months ago I posted an article on the EU3 module’s TCP/IP stack:

Note the last paragraph where it says:

“Finally here is a detail worth noting. The same B2B connector and (nearly) the same pinout as in the TC63i have been used with the EU3 Cinterion module. Therefore, whoever is designing a board to use with the TC63i, I recommend you to take a look at an application note called EU3_e-migration (which is part of the EU3 documentation) as it shows small differences to consider when moving from the TC63i to the EU3. Or rather, this document allows us to design a board in a way that we can use the TC63i or EU3 interchangeably, with obvious advantages that we can use in the future. If some of you are undecided whether to use a MC55i or a TC63i with a new design (I see this happen often), you should consider the compatibility with the EU3. At least it helped me to decide.”

Those who betted on the new EU3 Cinterion module or made a design with a TC63i and considered the application notes to make a compatible circuit like we talked about here, they can start to reap the benefits from the 9th of September (because it’s an implementation process that will last a couple of years). :)

Here you have more information of the implementation of the new 900MHz UMTS:

Well, I hope that this article has been interesting for some of you and satisfying for others who have made the right choice. I will now continue working on the new version of the MTXTunnel v6.0 manual which will be out soon. :)



Tags: ,

Comments No Comments »

Today I am going to post an article that I’m sure will be interesting and curious to many, especially those of you who are regularly working with GSM devices. Last Thursday, I finally brought a little gadget home that I had bought just a few weeks ago. Nobody has anything bad to say about it, so I wanted to be able to test and compare its ability to Cinterion modems as until now it had not been possible to test it and I had to believe in Jamming detection.

I have based my tests on the official Cinterion application note called “AN_45_Jamming_Detection.pdf”. Here you have all of the documentation on that subject, I2m going to focus on the practical part. As for the modem, I have used a Matrix MTX65i that has a TC65i inside, however I could have used another MTX or Cinterion model and it would have made no difference.

Well yes ok. But what is Jamming detection?

Well to put it simply it is the modem’s ability to detect an intentional interference in communication channels that block them.

You might think that it doesn’t matter and certainly in the vast majority of GSM application this is true, but in safety-related applications (alarms etc.), it’s quite important (or it should be).

Let’s take an example. A house or a car has a typical GSM alarm. If the alarm goes off it must communicate this to a central office of GSM alarm receivers. But, what happens if some thugs use a GSM inhibitor? Could the GSM alarm communicate with the central office? Will the alarm at least be capable to detect interference with a GSM inhibitor and act accordingly?

Obviously, no device (no mobile, GSM/3G module etc.) would be capable of making a GSM communication with a powerful enough GSM inhibitor present. But yes, some devices have (al least) the ability to detect interference from a GSM inhibitor: Cinterion modules. This ability allows them to act accordingly. This means to say that if a device suspects that there is interference, it can try to communicate while the interference is still weak (it can pre-activate warning sound etc.). In short, it’s always best for an alarm device to know what’s happening than to not know, how it acts in these situations will depend on the ability and imagination of whoever developed the alarm.

How to operate Jamming Detection in Cinterion modules:

As I said before, all of the documentation is in Cinterion’s applications 45 note. Basically and quickly summarized, it describes the activation of the communication link’s stability indicator “Ista”, for example with:


And to activate URCs with:


As soon as we activate jamming (interference), we will see how the modem is going to indicate the situation through URCs (sending messages through your serial port). First of all it will send messages like this:

+CIEV: “lsta”, , ,

This indicates that there are errors in the communication link. “lstaEdv” (which is a countdown timer) which will quickly decrease to “0″. Hmm… the suspicion begins…

After this URC, the modem will return another type of message:

+CIEV: “lsta”, , , , , ,

This URC already indicates network coverage loss. According to Cinterion documentation, when you get a URC with “IstaNo” = 40, a low “Istavar” (lower than 10) and “IstaMean” > 40, this is a clear indication of jamming.

As everyone always understands better with pictures, here you have a video which is even better. (If you have received the article via email you will probably have to watch it on (


I hope that you found it interesting. Bye  ;)




Comments No Comments »

Today I am going to talk a bit about the new HSDPA EU3 module communication interfaces and we will look at an example of using TCP/IP stack which is integrated into this module as it differs slightly as to what we were used to with the MC55i, XT65, TC63i and TC65i modules.

Communication Interfaces

The EU3 module has a serial port and a USB port. If you know the HC25 module, unlike this it’s possible to simultaneously use the serial port and the USB port with the EU3. In fact there are various ways to configure these interfaces. To do this we use the AT^SDPORT command (which is very important for the first contact with this module) that should be configured correctly.

With AT^SDPORT we can configure 4 modes.

Mode 1: default mode, it should only be used to configure an appropriate speed with AT+IPR and to change to SDPORT=2, SDPORT=3 or SDPORT=4

Mode 2: UART mode. We can only use the EU3 via serial port.

Mode 3: USB mode. To only use the EU3 via USB port, an application modem COM port and a virtual COM port are created. For example, this is in order to be able to send state AT commands to the modem at the same time as having established a 3G/HSDPA connection via the COM modem.

Mode 4: USB + UART mode. To be able to use the USB port in 3G/HSDPA connections and to use the UART to check the modem’s status by using AT commands.

Furthermore, as I indicated at the beginning of the post, we are going to see how to create a 3G/HSDPA connection using the modem’s internal TCP/IP stack i.e. we are going to create a socket to remote server to send/ receive data.

TCP/IP client connection example:

The first thing to do is define the connection profile with the context, e.g. 101



Note: it’s very important to use a context number between 101 and 116 as they are the most appropriate for service profiles (to create sockets). If you use values between 1 and 16 IT WILL NOT WORK as these are used with an external TCP/IP stack.

Afterwards, we simply activate the 101 context that we have just created.

AT + CGACT = 1,101


After receiving the OK, the EU3 modem should be connected to the 3G/HSDPA, i.e. it should have an IP address assigned to the operator. To try it we can run the following command:


+CGPADDR: 101,”″

Note that we did not need to specify neither a login nor a password to initiate the 3G/HSDPA connection. In any case, if we had needed it we would have to use the AT^SGAUTH with something like this:


So once we have the IP, we can connect to a remote server. To do so we will proceed in a similar way to what we do with the rest of the Siemens/Cinterion family (MC55i, XT65, TC63i and TC65i) configuring a service profile or in this case a TCP/IP client socket.


We can open the socket to connect to it:


If we use the trainer as a socket listener we can see how the modem has connected.


Reading/writing with a socket is the same as what we did with the MC55i, XT65, TC63i and TC65i, therefore I’m not going to expand on it. If you have any questions don’t hesitate to ask me.


A new change in the EU3 stack is the ability to use it transparently i.e. without using AT^SISR or AT^SISW commands. In short, everything we send through the modem’s serial port is sent directly via 3G/HSPDA and everything that we receive via 3G/HSDPA is directly forwarded to the modem’s serial port i.e. transparently.

In order to do this we use the AT^SIST command (T for Transparent) after the service is opened with AT^SISO=x. As we have opened the service profile “0”…



You can see that CONNECT appears, just like when you make a CSD call. From this moment, we have a transparent 3G/HSDPA connection. To exit this mode, in a similar way to CSD calls, simply send “+++” to exit command mode.

And that’s it, as you can see this EU3 module’s TCP/IP stack is somewhat different from what we were used to with the rest of the Siemens/Cinterion modules.

Now here’s my personal evaluation. The best thing about this TCP/IP stack is that you can also use a socket in transparent mode, which could be very interesting for many applications. I don’t like the fact that for now (with the current firmware), you can’t create TCP server sockets. This is because the module is really aimed at M2M applications and most of these applications use TCP/Client sockets to send data to remote servers.

Here is a last detail to point out. The EU3 Cinterion module has the same B2B connector and (almost) the same pinout as the TC63i. Therefore anyone who is designing a board for the TC63i, take a look at the application note called EU3_e-migration (part of the EU3 documentation) as it points out slight differences to take into account when changing from a TC63i to a EU3. Or rather, this document will allow you to design a board that you can use with either the TC63i or the EU3, with obvious advantages that will help you in the future. If you, like others, have any doubts about whether to use a MC55i or a TC63i in a new design, you should consider the fact that the TC63i is compatible with the EU3. It would help me decide.

I hope that you have found it interesting. Until next time. ;) Read the rest of this entry »

Tags: , ,

Comments 2 Comments »

The new MTXTunnel v5.0 is now available.

After a fairly long period of time it’s finally finished. The new version has a lot of changes compared to the previous version MTXTunnel v4.0 (to give you an idea the manual used to have 20 pages and now has 210 pages). A lot of the features have been suggested by people who currently use MTXTunnel v4.0 or previous versions, and I have included these suggestions in this new version. Things like being able to control 2 devices with a single MTX65i modem (one for each serial port), being able to use it in ultra low power scenarios, UDP/TCP communications, SSL security, DynDNS, embedded Webserver, Telnet, sending telemetries (GPIOs and ADCs…), sending GPS position etc. All of these things are included in the new version; I think that it’s quite complete.

As I said, the manual is quite extensive but I have added about 30 configuration examples for different scenarios. That way the majority of users find an example that relates to what they want to do or modify slightly, depending on their requirements. This means that you don’t have to read the entire manual.

Normally I add FAQs in the manuals to try answer any questions that may arise. The FAQs that are in the new MTXTunnel v5.0 manual are shown below. I hope you find them interesting. As always, if you have any suggestions let me know. If they are interesting they won’t fall on deaf ears, they will be included in later versions just like I have done with previous suggestions in this new version.

Here are the FAQs, they are quite long but they summarize all of the main, new things that you can do with your device. If you have five minutes to read them, you will see that MTXTunnel v5.0 can be useful in many future applications.

What is MTXTunnel?

MTXTunnel v5.0 is a software application that can be pre-installed by  Matrix (if requested) in one of the following MTX modems (MTX65i, MTX65IND, MTX65ULP y MTX65+G).


What is MTXTunnel used for?

The MTXTunnel can be mainly used to create a transparent Gateway (or tunnel) from the SerialPort to the GPRS. If you already have a machine or device with a serial port, you could read/control it in the same way as if it were physically connected to your computer.


This is the scenario: serial equipment connected to a PC to read/write …


NOW with GPRS-Serial MTXTunnel gateway, the above scenario is showed in the following example. Now your PC has to establish a TCP/IP connection with MTXTunnel. Then, EVERYTHING you send to this TCP/IP connection will be sent to the equipment’s serial port by MTXTunnel. On the contrary, all of the information in the equipment’s serial port is sent to your server using the GPRS network.


Is MTXTunnel needed at the PC server’s side?

It depends, but in general, it is not needed at the PC server’s side 99% of the time.

Not needed: If you already have your PC control software and already have the option to connect as TCP/IP or UDP, a modem with MTXTunnel is not needed. Just configure the IP and port of remote MTXTunnel and your PC will use the ready internet connection to send and receive data remotely.

Not needed: If your PC control software does not have the option of connecting using TCP/IP or UDP and the only option you have is to choose a COM port, the MTXTunnel+modem is also not needed. There are some freeware drivers for your operating system as Windows can emulate a COM port. Once this free driver is installed, a virtual COM (like COM100) will be installed in your PC and you must point to the IP and TCP port of the MTXTunnel remote. You must choose this virtual COM in your PC software. Please contact Matrix for more information about recommended virtual serial drivers.

Needed: If you need a “serial cable replacer” because for example you have to communicate 2 RS232 serial devices remotely and there is no intelligence or PC control software (you cannot install virtual COM port), you will need 2 MTXTunnels, one in each end. This is an example of this scenario:


Who starts the connection?

MTXTunnel has the following modes TCP Server, TCP Client and UDP.

  • TCP Server mode. MTXTunnel is waiting for incoming connections. This is to say that the remote device (PC server) will start and establish the GRPS-Serial Gateway.
  • TCP Client mode. MTXTunnel will start the Gateway. It will connect to the configured IP + port of the server PC AND establish the GRPS-Serial Gateway automatically.
  • UDP mode. UDP is not oriented to connection protocol. MTXTunnel just waits for UDP packet and sends them to the serial port and vice versa. The data present at serial port is sent to a PC via UDP.


It is mandatory to be permanently connected to GPRS when already configured as TCP Server, TCP Client or UDP?

No. It’s not. If your application requires it to do so, MTXTunnel can be GPRS connected 100% of the time. Remember that network operators will bill the data volume, not time.

If you do not need MTXTunnel to be connected 100% of the time and you want the connection to be sporadic, MTXTunnel can be activated in these situations:

1. – Missed call from authorized phone number.

2. – Incoming SMS including the word “on” from an authorized phone number.

3. – By activating a digital input in MTXTunnel.

4. – When an analog input value is out of range.

5. – Depending on programmed date/hour (up to ten).

6. – When there is serial data (only TCP Server mode).

So… how long is MTXTunnel active for (GPRS connected)?

It’s configurable by the GPRS_timeout parameter. You can specify the time in minutes after which, if it doesn’t detect traffic at GPRS connection, MTXTunnel will close the session.


I want to use MTXTunnel as TCP Server so I can connect to them periodically from my PC. Will I need SIMs with IP fixed provisioned?

It is not mandatory. You have various ways to find out the remote IP if using normal dynamic IP addressing SIMs. You can either make a missed call or send an SMS with the word “on” to remote MTXTunnel equipments. MTXTunnel will reply with an SMS including the IP obtained at this moment in time.


New MTXTunnel V5.0 is DynDNS featured. DynDNS is a service allowing you to associate DNS name (like to the IP obtained by MTXTunnel. For now, you can use this for free: .

I found that in my case I’m going to use thousands of MTXTunnel devices. I cannot use missed calls or SMSs to work out IP addresses. I do not want to use DynDNS as it can be difficult to handle and even costly. What can I do?

The MTXTunnel will inform the server PC every time an IP address changes.  

You just need to enable a configuration parameter so each time MTXTunnel changes the IP it will send frame data to a server PC with the following information: IMEI, the newly obtained IP obtained and an optional user-configurable text.


Is it possible to send the new IP to a Web server? I’m more familiar with Web programming –ASP, PHP- rather than TCP-IP sockets. I’m thinking about using a Data Base. Is this possible?

Yes, it is. If you prefer, it’s possible for MTXTunnel to send the newly obtained IP address to a Web Server using http GET (URL + parameters).

MTXTunnel can be installed on several Cinterion-based modem terminals like MTX65i, MTX65IND, MTX65ULP y MTX65+G.  What are the differences between them? 

For main applications, the MTX65i is suitable.

If you need RS485 serial communication, remote activation of relays, or to be able to remotely read 4-20mA, the recommended modem is MTX65IND.

If power consumption is critical, use the MTX65ULP modem as it can be completely powered-off (consumption is around 2uA) except in the configured situations.

If you need some extra features like GPS positioning, you should choose the MTX-65+G.

You are talking about relays, analog inputs…  Is MTXTunnel not a Serial-GPRS Gateway?

At the same time, MTXTunnel is a serial-GPRS Gateway and can also control digital input/outputs, analog inputs, relays, GPS receiver, devices connected to SPI/I2C…


-MTXTunnel can remotely read a digital input or change a digital output.

-MTXTunnel can send (X seconds configurable) the GPS positioning to a PC or Web Server and can remotely read a sensor connected to SPI/I2C. MTXTunnel can automatically send, every X configured seconds, the status of all input/outputs or GPS position to a server PC or WebServer. SMS messages can also be used.

So for example, could I control the relay from the PC in my office by sending an AT command through a TCP/IP connection?

Yes but as well as sending an AT command via TCP/IP connection, there are other ways. You can also send them through the modem’s serial port or via SMS. You can also switch a relay or read an MTXTunnel digital/analog input status from your own web page (look at the API manual in this manual for annex example scenarios).

So, using MTX-IND, I can activate a relay using a SMS, but… it’s not practical because the AT command is not intuitive or easy to remember.

You do not have to send the exact AT command. This means that the SMS text does NOT have to be “AT^SSIO=0, 0” to activate Relay #1. You can configure it and use ALIAS text.

Example: “RELE1ON” is the text of the SMS to activate GPIO0 (Relay #1). MTXTunnel will interpret it to AT^SSIO=0, 0.

You can create up to 10 different ALIAS text strings.

MTX65i, MTX65IND and MTX65ULP modem terminals have 2 serial ports. Could I control 2 external devices with one terminal? 

Yes, you can.  MTXTunnel can control 2 RS232 external devices with just one SIM card. MTXTunnel will run 2 serial-GPRS running in parallel.

Just remember that the MTX65i and the MTX65ULP secondary port cannot use flow control because the do not have the CTS and RTS lines; they only have the TX and RX lines.



What about MTXTunnel installed on MTX65+G which has a GPS receiver inside? Can I use it for fleet management? 

It’s not intended for professional fleet management. MTXTunnel reads the GPS positioning using some of the MTXTunnel GSM/GPRS services: IP tunnel, WebServer, Telnet or SMS.

MTXTunnel can be configured to automatically send the GPS position every X seconds. However, MTXTunnel does not internally store the position in the Flash memory. This is a typical application if GPRS coverage is lost. So, this is for basic fleet management as professional ones normally stores position points like a data logger.

There is another version of MTXTunnel intended for professional track & trace using the MTX-65+G device. This version is called the MTXTunnel-GPS and has another license price, configuration parameters and also the general functionality is different. Please ask for more information.

What is WebServer used for?

MTXTunnel WebServer which is included can be used to read the digital input/outputs or analog inputs and to change digital outputs easily in a PC (connected to internet) using a common internet browser.

Not only this, you can see and modify the MTXTunnel remotely. Also you can execute AT remote commands, like network coverage (AT+CSQ), check incoming SMS…

What is Telnet used for? 

You can basically do the same with the Telnet service in MTXTunnel as you can with WebServer but it’s more common used for third party application integration. Please read TELNET and API section.

I’m worried about unauthorized access using WebServer or Telnet.

MTXTunnel has an internal firewall which can be activated. Then MTXTunnel will only accept connections from previously configured IP addresses. Any other IP addresses will be blocked.

For maintenance purposes, I would like access to MTXTunnel at any time and in any location, from any IP address.

In this case Firewall WebServer must be disabled, but we recommend protecting WebServer with a Login and Password. MTXTunnel can work with our without a Login/Password (public WebServer). The same applies for Telnet.

Could I or somebody else receive an SMS when an input changes, like alarm detection?

You can configure MTXTunnel to send special and configured SMS text strings up to 10 configured different phone numbers.

SMS text can be configured in different text strings related with digital or analog input.

MTXTunnel 5.0 is a GRPS-Serial tunnel Gateway. What is a GRPS-I2C, GPRS-SPI, HTTP-Serial or SMS-Serial tunnel? Do you have some examples?


GPRS-I2C Tunnel: You can read an I2C sensor remotely like a temperature sensor.

GPRS-SPI Tunnel: For example you can write data on SPI bus and if a display is connected to it, the data will be on display.

HTTP-Serial Tunnel: Example. You have a Web page with a form. All filled form data can be sent to serial port MTXTunnel connected device. Then MTXTunnel will collect the machine response and send the data as a web response to your Web page.

SMS-Serial Tunnel:  Example. You can define a special text like “MTX” at the beginning of the SMS string. The text after this special string will be redirected to the serial port of the machine. MTXTunnel can get the response from the machine and send another SMS to the user. Example: “MTX 12345”: MTXTunnel will send “12345” string to the serial port and will get a response from the machine like “67890”, which will be sent as SMS.

I need a low power application MTX65ULP terminal modem. What can MTXTunnel do?

The MTX65ULP is normally switched off completely. This way the power consumption is about 2 uA. The modem is off and cannot do anything. It cannot receive calls, SMSs or communicate at all. Therefore an event needs to happen.

This event is similar to an interruption. A digital input level change or an alarm can wake up the modem.

As an example, MTXTunnel will wake up every 24 hours; send the telemetry (all the inputs values, RS232 …) and after 5 minutes of being awake, the terminal will be automatically switched off. You can control or configure the wake up time and the sleep time period.

Is it also possible to define scheduled wake up tasks. For example, MTX65ULP can wake up X minutes every day at 10.00 AM or only on the 1st and 15th days of the current month at 08.00am and 08.00 pm.

Keep in mind that the MTX65ULP is the ideal solution for remote water counter metering where there is no external power so it needs batteries to run for a long time (7 years…).

If MTXTunnel can be woken up in a configured time, does this mean that there is clock inside?  But you can also say that it’s powered off. Please explain.

MTX65ULP has own Real Time Clock independent to TC65 RTC and is always powered from external power, but it also has own battery source. This RTC allows to the modem wake up at configured-scheduled time/date.

Can this timing be synchronized?

All RTCs have some deviations. So, MTXTunnel V7 can use network timing synchronization. This feature is mandatory to use with the MTX65ULP. This way, every time MTXTunnel is connected to GPRS, it is linked to a timing server and can update the internal timing.


MTXTunnel used on the MTX65ULP wakes up at configured day/hour for some time (x minutes). Will the GPRS-Serial Gateway be active at this time?

During wake-up time, the modem will start and will run all configured services (WebServer, Telnet, Input/output telemetries…) as well as the serial tunnel gateway.

What about SSL security? How does it work?

Some applications need some encryption data transmission. SSL is used. This way the data is transmitted and received SSL encrypted, avoiding data recovering sniffer. SSK is only available in TCP client mode. Be sure than your server can support SSL sockets in the following specifications:

Nevertheless, we recommend SSL encryption if it is mandatory due to the bigger amount of data volume and the reduction in data speed transfer.

What does “API” feature mean?

API is mainly a way to integrate MTXTunnel in end user application. Basically it’s like a special AT commands end user. It can easily integrate in a web page and for example can also switch a relay (change an Output).

API could also be used to remotely access MTX configuration and send AT commands at the same time without knowing all of the configuration parameter syntax.

The new MTXTunnelv5.0 has many options… How do you configure a specific scenario?

The new MTXTunnel V5.0 has a lot of configuration parameters, more than explained in the FAQ section. Take a look in the configuration section.

Next you can find step-by-step MTXTunnel examples of first configuration scenarios; they are very useful for you for first hand-on.

In the Annex there are lots of examples of scenarios with the appropriate configuration to get MTXTunnel working. Try to find the closest scenario to you and review the copy & paste selected configuration, it’s nothing more special than that.

If you have specific questions contact the support line

And that’s it. If you have read this far I would like to thank you J If you have any questions you can leave a comment in the forum forum I will gladly help you. You could also send me an email to and my work email address is

I hope it’s been interesting, see you next time. 

Tags: , , , ,

Comments 4 Comments »

Today I am going to post about Proguard, an obfuscator for Java. A lot of you probably have heard of it and use it with your j2me applications. But for those of you who haven’t heard of it, I advise you to take a look at this article which will help you with any new projects with Cinterion (TC65, XT65) or MTX terminals.


Using an obfuscator with our j2me applications is interesting, more interesting than being able to “obfuscate the code”, as it reduces the total “.jar” file size generated. Never forget (although sometimes some of us seem to do so ;) ) that we’re not programming a Core2Duo processor,rather we are programming devices with very limited RAM and FLASH memory. For example, an MT65 GPRS modem has 400Kb RAM memory and 1.7Mb FLASH memory. Using an obfuscator will make the most of the precious FLASH memory, and especially the RAM memory in our modems.


To give us an idea, the new MTXTunnelv5.0 firmware that comes out soon (this month) takes up around 130Kb without obfuscating and 80Kb obfuscating. You can see that the reduction is quite significant.


What do you have to do to use an obfuscator?


Well first of all you need to download it.


With eMule?


No, it’s free.


Where is it?

You will find it here:

Download it and unzip it inside the Eclipse folder i.e. within:


Then go to Window > Preferences > J2ME > Packaging > Obfuscation and select the suitable PATH like you can see in the following screen:


Once you have done this you can “compile” your file obfuscating it. Instead of making a “Create Package”, to do this we make a “Create Obfuscated Package”.

Yes it worked, but there was an error.

This is because you need to specify a complete path to a JDK and you probably have a JRE. Change it, to do this go to Window > Preferences > Java > Installed JREs and select the appropriate JDK directory. In my case:


I hope that you find it useful. Now I’m going to go to sleep as I have to gain some strength for tomorrow, I’m trembling with fear as tomorrow my son celebrates his fifth birthday and Sonia has invited her friends round. At first it was 2 or 3 friends, then it was 5 or 6, then 7 or 8 and today I was told it was a whopping 12 or 13. Also I expressed my happiness with the tea that she has prepared. There are no ham sandwiches no, but she has prepared an endless number of rolls filled with lotsssss of chocolate (Think of my sofas, the walls…) Anyway I think that I will stay on the top floor of my house (where my computers are) ensuring that no brats get into the restricted area. :)


Tags: , ,

Comments 4 Comments »

As you all already know, I have talked about the MTX65+G modem on many occasions in this blog, it’s a GPRS modem with integrated GPS. It has a Cinterion XT65 module on the inside, which has very similar features to the well known TC65 (cpu, features etc.) but it also includes a GPS. This GPS module is from the uBlox company is specifically put together with an Antaris 4.

Normally when programming the MTX65+6 modem (i.e. the XT65) in Java, we do it in 2 ways. Either we use the ATCommand class with the command that allows Cinterion (AT^SGPSR) to read current GPS positions (this is the most popular method, I use this method myself) or we use the API Location for J2ME (JSR 179).

However, there’s another way to worth the GPS. As you know the TC65 module has 2 serial ports and the XT65 only has 1. The reason for only having one serial port is that the other has been routed to the serial port that is assembled with the GPS module i.e. the serial port with the XT65 that controls the GPS.


El MTX65+G / XT65 allows us to communicate directly with the GPS module in an analog manner no matter how the serial communication is running. This means that if we open Java from the serial port associated with the GPS, we can directly read NMEA frames returned by the modem.


Bah, why would I want to fight with NMEA frames when the TX65 gives the GPS position with Location class or rather using the AT^SGPSR command?


As I said above the XT65 mounts a uBlox GPS. This GPS module has a number of settings which you can adjust to refine results. In some situations you may be interested in modifying/adjusting these settings and not using the ones given by default when you buy a MTX65+G or a XT65. You cannot adjust these settings with Java, but to do this the GPS module must be in transparent mode (removing NMEA frames) i.e. when the modem starts we put the GPS in transparent mode.

Today, for those who are interested, I am going to post about an example project where I will show you how to read NMEA frames from JAVA (it is posted in the user download section in It will be the basis of the program that I will use with the next example that I post, where we will see how to modify some of the GPS module’s internal parameters to adjust our localization application to the max.

See you another day. Good night ;)


Tags: , , ,

Comments 4 Comments »