Posts Tagged “mtx65”

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 »

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 »


I have had the OTAP platform active for a very long time. Since then it has been used for thousands of OTAPs. As you know an OTAP is the process that allows you to remotely update Java applications that we embed in out Siemens/Cinterion modems. Today I’m going to present version 2.0 of this software which is similar to version 1.0 but has some important differences.

The first thing is that it no longer depends on my server Now the software has a little TCP/IP server to manage OTAP responses. As you know, this means that when an OTAP process ends (good or bad), if the GPRS connectivity is correct it sends a notification (POST request) to a web server indicating the result of the operation. In version 1.0 this notification was always sent to by the modem whereas in version 2.0 you can specify your OTAP confirmation server or use this same application (v2.0) as a confirmation server. I have also prepared for this.


If you look at the following screenshot…


 …you will see the URL notify parameter. That is the URL that the modem will call when the OTAP process has finished. As I said before, you can specify your own OTAP confirmation server (via IP or DNS) or use this same application as a confirmation server. For the latter, the simplest thing to do is click on the “My IP” button. By pressing this button a URL is automatically created with you router’s public IP address (if you didn’t know). This means that for example, when clicking on the “My IP” button, the URL notify parameter will display something like this (in my case):

This indicates that for the server confirmation, the modem must use the IP:, the 20010 port and it works like an ID phone number parameter. The software automatically changes the text <phone> for the number corresponding to the SIM which will carry out the OTAP. This is so that when the OTAP confirmation server receives the confirmation, it knows which phone number it’s about.

Two very important things. One is that obviously you have to do a NAT in our company’s ADSL router to redirect the 20010 port (or the port that you are using) to the PC where the OTAP confirmation software is running. The other is that you mustn’t forget the “/” between the port number (20010 in the example) and the question mark (?).

Once all of the necessary data is completed, we are ready to do the OTAP. For this we have to have a GSM modem connected to our PC’s serial port (configured to 115200,8,N1 and with HW flow control) which will be responsible for send OTAP SMSs. Once everything is connected we can press on the button “Initiate OTAP Process”.


Here is another difference with version 2.0 with regards to version 1.0. In the figure above and below, if you look, you will see that we have finally decided to use this same application as an OTAP confirmation server you have to enable the “OTAP Server Active” box and specify the TCP port indicated on the previous screen in “URL Notify”. I repeat that you mustn’t forget the NAT in the router and don’t forget to disable the windows firewall and/or antivirus so that they don’t block the chose TCP port.

As soon as this is done we are ready to press “Start OTAP Process” and the process will begin. In this version 2.0, the control OTAP error control has improved considerably. If you look, you will see that the superior table has 3 columns. The first two are the same as version 1.0, but the third one shows a LOG with what has happened. All you have to do is double click with the mouse on a certain LOG to open a screen with the complete LOG. This was it’s much easier to figure out the reason for an OTAP error if there is one. For example, if the OTAP process finished with OK and we open the LOG we will see something like this:


If on the other hand we didn’t specify the correct path (URL) inside the JAD file, we would have an error like the following in the <MIDlet-Jar-UR> parameter of the JAR file:


If we had been mistaken and didn’t specify the correct JAR file size in the <MIDlet-Jar-Size> parameter inside the JAD file, we would get an error like this:


If you wanted to test out the program you could certainly do it with the HelloWorld example that I have on blogElectronica. You can see the correct JAD in:

I hope that whoever uses OTAP finds it interesting. Here you have the LINK to download OTAP v2.0 software that I put in a zip file with all of the necessary DLLs so you don’t need an installation. If anyone has any problems with DLLs, please let me know. This version is completely free and never expires, but as there’s an important job for me to do, there’s always a “but”, it is limited. You can enter up to 5 modems into the system and therefore you can do OTAP simultaneously with a maximum of 5 modems (with a constant in the source code). But this version will be sufficient for most users.

But for those who don’t want to be limited to 5 modems, want to be able to use all necessary modems and especially want a COMPLETE SOURCE CODE from the OTAP v2.0 application, you are able to get it through PayPal (as it’s personal to me and I email it at 24h) Let’s see… if I was allowed a faster server for blogElectronica and for other future projects what would I have in mind…

Having the source code could be very useful to anyone who has planned their own OTAP application in order to not have to start from scratch and to save time. By having the application’s source code it’s possibly to modify it, made it bigger, add parameters, logos or whatever you want. I haven’t done it in Java, I’ve done it in Visual Basic 6 and I’ve included many comments so that everyone can understand without having to take any classes.


I hope it’s been interesting for you. See you another day, happy Sunday! ;)  

Tags: , , , ,

Comments 10 Comments »

Well here I am back from vacation. This Easter I spent a few wonderful days in Cáceres with my family (a lot of my mother’s family lives there). I had not been there for many years and I missed the drumsticks, the drunkness the family. :) The truth is that I really enjoyed it and I hope to go back soon.

Ok, let’s get on with it… today we are going to look at implementing a Web Server.

Sometimes it can be interesting to incorporate a little web server in our TC65 or MTX65 GPRS modems. It’s convenient to directly connect to the modem with a browser or any parameter. So today I’m putting up an example that I’ve made, it’s slightly longer than usual, it took up quite a lot of time and it implements this: a small and simple (very simple) Web Server. This example can also be used as a Socket Server example. I don’t remember which blog user it was but I told them that I would post an example or Socket Server in Java. So here it is.

The example here is part of one of my projects. I have taken many things from my project, including error control, to break it down a little bit and make it more understandable. I think that it’s enough. Anyway to remove the code there might be an instruction that’s not necessary, I haven’t looked at everything, I just checked that it worked properly.

Blog de Electrónica Avanzada

Alright, what does this example do? 

If you download and open the project you will see 3 files. To test out the example you just have to edit the and change the connection parameters depending on your operator. If you use Movistar in Spain you can leave the code as it is and compile and run the project.

When you run the program you will see that the modem is connected to the GPRS and the obtained IP will come out through the standard output (normally ASC0). If I run it I get:


After this, open the browser (I only tried with Microsoft Explorer, nothing else) and write something in the address bar like:

You will get a response like this:


This means that the modem has received the HTTP GET request, taken the values “a” and “b” from the parameters passed in the URL, added them together and returned them to a HTTP page with the sum. Obviously what this example does (GPRS calculator) is not used a lot and doesn’t make much sense, but I’m sure that this example will spark new ideas.

One more thing, I have put a variable called “numMaxClientesX” in the code. You can specify the number of concurrent requests that you may have in this. By default it’s “1” and you can increase it but remember that Siemens/Cinterion modems support up to 6 sockets and one of them already has the socket listener that listens in the TCP80 port (Http). Also, think about launching a Thread for each connection established.

The example is done using sockets via java classes. To whoever asked me which is better, if you manage the sockets with java classes or with AT commands as I have sometimes done before in this blog, I wouldn’t know what to say as they are more or less the same. The advantage of using java classes is that perhaps the application (socket server) is slightly simpler to implement and with AT commands you have a little more control over each of the socket’s status. They are subjective assessments as both methods work really well; sometimes I use one and sometimes the other.

I hope that you found it interesting, until next time. ;)

Tags: , , , ,

Comments 12 Comments »

With lots of GPRS modem applications, data needs to be stored inside the modem itself. A while ago we saw how to create files inside the GPRS modem’s Flash memory, so it was working as if it were a disk drive.

What type of applications? Well for example, it could be a datalogger, a GPS tracker or any other application that needs to keep a log (a file) that has certain data collected periodically. Obviously if we are working with GPRS modems, it’s to transmit data at some point. When it’s time to transmit the data stored in the modem to a central server via GPRS, compressing data before sending it could be quite interesting depending on the size of the data file that we are working with.

Why would sending compressed data be interesting?

For two reasons. One to save time in the sending process. The other is for economic reasons, remember that in most cases telephone operators charge for traffic volume i.e. the more data you transmit, the more you pay.


And how do you compress files with J2ME?

Well the first thing that usually occurs to all of us is we start looking to see if J2ME has a class that can help us with this task. Regrettably you soon realize that there isn’t, J2ME doesn’t have these classes due to its limitations (remember that J2ME is designed for devices with little resources). Instead, J2SE (Java Standard Edition) has classes. With the complete Java edition you only have to use the package to manage compressed files easily. After seeing this, the next thing that occurs to us is “ok, I am going to see if I can adapt these J2SE classes to try and make them work with J2ME”. But after a few wasted hours of trying, you realize it’s not going to be an easy task as certain native Zlib classes are used.

So you investigate alternatives…  There’s not a lot on the internet when you Google about J2ME compression and there’s a lot less if we search for something related to compression and GPRS modems, so I think that internet users will land on this post. So after searching for a while, you find project JZLib (on the web, which is a free software project where you can re-implement ZLIB. You can get all the information that you want about this site, I won’t go into details.

And does it work? Can you compress files inside the modem using this software library?

Well yes, it works. :)

I’ll post a little Java example that works with a TC65 or MTX65 modem. You can download it by clicking here.

The example basically compresses the text: “en la granja de mi tia iaiaooooooooooooooooooooooooo” :) (equivalent to Old McDonald had a farm in English) and it saves the final result i.e. it saves the compressed text in a file (in the modem’s internal Flash memory) with the name “data.z”. If you see the project’s source code, you can see that I’ve put all of the .java files from the compression library in the same project. Obviously it could have been used as a library but I didn’t want to cause any confusion and you can test out the example without any difficulties.

It works! I’ve compressed the test in a file. But if then if I remove the modem’s compressed file with MES and I put it on my PC, can I not unzip it with WinZip?

No it won’t work with WinZip as a file with just compressed data has been created i.e. ZLIB compresses the file but if you want to use WinZip you will have to build the ZIP files structures, with the headers and everything else. (

Whew, ZIP headers are difficult. Can I not decompress the files in any other way?

Well yes, with a Zlib decompressor. But I will put that in a post in a few days time (probably Sunday). I will also try to include a little program made in VB6 (with a source code that you can use of course) which is able to unzip files made by the modem. That way you will have everything you need in order to compress a file with a modem, send it via GPRS and decompress it afterwards using our server.

Well I hope that you found the post interesting and that it’s useful to you one day. I’m going to have dinner now. ;)

Tags: , , , , , ,

Comments 8 Comments »

On many occasions, we may need to use the FFS (File Flash System) from our Cinterion  TC65 or XT65 GPRS modems to transfer data to files. A typical example is the case of the XT65 and GPS positions. We read the GPS positions every X seconds and we store them in a file to send them to the central server later. There are as many of these types of examples for the TC65 as the XT65.

It’s easy to fall into the temptation of generating files in the Flash memory to store information instead of creating files and deleting them when we think that are processed (e.g. when we have sent them to the central server via GPRS or simply erasing them when we no longer need them).

It really is the easiest way to make an application (we create files and delete them when we no longer need them) but you must be careful with this technique. Writing data onto to the Flash memory is no problem, they are saved byte by byte (as Siemens’ FLASH memory is the NOR type, unlike the NAND type you can save bit by bit. With NAND, it’s cheaper but worse as you save in blocks). However the erasing process IS critical because both the NANDs and the NORs are done in blocks. The cluster size in the Flash modem is 64Kb, this means that when we delete a file, really we are erasing a 64Kb block. So although we are deleting a file that only contains 100 bytes of data, in reality it affects the 64Kb in the modem’s Flash memory.

Blog de Electrónica Avanzada

If we consider the fact that it’s possible to save 100.000 records and a TC65’s Flash memory is around 1.7Mb in size. Taking into account that the size of a cluster is 64Kb, it’s not difficult to see that we shouldn’t abuse deleting files. Let’s look at an example, if we create a small 100 byte file and we delete it every minute, approximately every 26 minutes (1.7 / 0.064) we have “seen” all of the flash memory. This means that after 100,000 x 26 = 2,600,000 minutes (or less) we will have almost certainly loaded the flash. Every day has 1440 minutes, a year 365 x 1440 = 525,600 minutes, which means that the 2,600,000 / 525,600 = after 4.9 years our modem would die (or almost certainly before as the modem has internal processes that also write on the flash). Also you have to keep in mind that when we erase a cluster (for example when we erase a 100 byte file that is inside it), the rest of the information that’s in the cluster shouldn’t be erased, the modem’s FFS manager’s internal algorithms have to rewrite the information which shouldn’t be deleted i.e. it wears out the flash more to further minimize the added risk of a power cut at the time of copying.

What can be done then? 

If you want to use files with your Java application, you need to avoid the continuous clearing as stated above. The best way to avoid problems is to create a file in the Flash (or files you need for the application) and try to NEVER delete it. This means for example you create 2 Log1.txt and Log2.txt files and you store records (by records I mean a fixed longitude GPS frame for example).

Let’s imagine that we set a maximum of 5000 records per file. Once we have written 5000 records in Log1.txt, we start to write data in Log2.txt and then we can send Log1.txt to our central server via GPRS. After the Log1.txt sending process, we do NOT delete the file. When we have written 5000 other records in Log2.txt, we start to write in Log1.txt DESTROYING record 1 and so on up to record 5000. The trick is to overwrite records and not delete files. This is a way to really save us from nasty problems over time due to the Flash memory wearing out.

When we are programming on the TC65 and XT65, we must remember that we are working on an embedded module and not on a Core 2 DUO with HHDD. Yes, there are some very powerful modules and when programming in Java with a file system we sometimes lose the perspective of the embedded module, so we must keep it in mind.

I hope you find this post useful, see you next time! ;)


Tags: , , , , ,

Comments 18 Comments »

If you develop applications in Java for GPRS TC65, XT65 (or their MTX65 or MTX65+G terminals distributed by Matrix), perhaps you will be interested in debugging your application on occasion in the way that I’m going to show you here.

What happens (or what should happen) at the end of any development program is that there is a test phase, a phase where you must thoroughly test the application for any type of error that could have been made. If there are errors in our application, they are easily reproducible so we will find them relatively easily. But occasionally there are errors that are caused by an accumulation of things or due to some very specific situations which are not reproduced in the laboratory but they are in the street.

Debugging such problems can be really tricky, when they occasionally occur they are very difficult to locate.

Blog de Electrónica Avanzada

One way to try and find out what happens with a program could be having a HyperTerminal connected to the serial port to save the errors that we are going to receive via System.out.println, but it doesn’t seem to be the most suitable method for every situation, right? It’s a little contraption if we have to put a PC in a car, in a vending machine or wherever our modem is…

An alternative method that we can use with Siemens/Cinterion modems is redirecting the standard output to a file i.e. instead of receiving the errors through the device’s serial port (to do a System.out.println), they will be thrown into a log text file in the modem’s flash memory. This way, when something strange occurs we can see it in the log and try to see which method or part of the program is going wrong. It’s very useful.

So how do we do this?

We do it with the super command AT^SCFG. With this command you can specify the standard output destination (in this case we will define a file, the file size, the file name and the storage mode).

When we define the file size you need to keep in mind that two files are actually created. For example, if the file name is log.txt, log.txt.0 and log.txt.1 will be created. When log.txt.0 reaches half of the size that we have specified, it starts to write in log.txt.1. Similarly, when log.txt.1 reaches half of its specified size, log.txt.0 will be overwritten and so on. They will take it in turns.

As for storage, we have two modes: “buffered” and “secure”. With “buffered” the output isn’t directly written in the flash, instead it is temporarily stored in an intermediate buffer (in RAM) and when the timer rings the data is saved in the Flash. In “secure” mode it’s directly written onto the Flash. It depends on the type of situation and the severity of the problem whether we should use one mode or another.

Do you have any examples? 

Of course, configure the modem with:


If afterwards (at any time) we do this from our Java application:


we will see in A:/log.txt.0 that we have the “Hola”.

Well, I’ll be back on another day. I hope that this helps someone out who has trouble finding errors. Now I’m going to do one of my least favourite tasks of the year, the income. And to think that there are some people who like doing it… (I know a couple) ;)

Tags: , , , , , , ,

Comments 2 Comments »

On several occasions I have been asked how to add more data to an existing file in the flash memory of our TC65 or XT65 modems (or MTX terminals from Matrix). So today I am going to post a small Java program to help those of you who don’t know how to do this. It’s very simple.

Basically you use the OutputStream object instead of the DataOutputStream (DataOutputStream comes from OutputStream) which I’m sure you saw in the post where the majority of the Java examples are.

Let’s look at a little example today. Let’s assume that we have a file in the modem’s file system called  ”A:/file.txt“ with the text “hola”. If you don’t have one, make one and put it in the modem.

Blog de Electrónica Avanzada

/* Create an object in the FileConnection class and specify the name of the file to open, which will be file.txt*/
FileConnection objFileConnection = (FileConnection)“file:///a:/file.txt”);

/*Check the current file size*/
long fileSize=objFileConnection.fileSize();

/*Create an object in the OutputStream class. With this we can write data in the file and pass it off as a current file size parameter so that the file writing “pointer” is at the end of the file.*/
OutputStream objOutputStream = objFileConnection.openOutputStream(fileSize);

/*Write the text “Adios” inside the file that we have just opened (or created)*/

/*Send it writing everything that’s left in the buffer prior to closing it*/

/*Close the object*/

/*Close the file*/

Once you run the application, if you look at the flie.txt contents you will see that the contents include “holaadios” i.e. it doesn’t overwrite the contents that’s already in the file, it adds the data.

To summarize, I will put up a few posts about two new terminal models, the MTX65+Gv3 (GPRS terminal modem with GPS) and the new MTX65-ULP (GPRS ultra low power modem). Firstly we will look at their features and then I will go into more detail about programming both devices, paying attention to the peculiarities of each one so that everyone will know exactly how to use them. I’m sure you’ll like it. This will be in a few days time.

I hope it’s been interesting for you. ;)

Tags: , , , , , , ,

Comments 7 Comments »

On several occasions I have been asked how to create a dial-up network connection with an MTX63 GPRS modem or an MTX-HC25 UMTS/ HSDPA modem. Sure it’s obvious for most of us, but not for people who are less accustomed to using modems (this is normal as nobody is born with this knowledge, but throughout my life I have met people who strangely seem to think otherwise…).

So for those of you who don’t know how to do it, here are the steps for how to create a dial-up network connection via USB for the MTX63 and MTX-HC25. Actually the following applies to any modem, either for the modems mentioned before, for the MTX65 or the MTX65+G or even mobiles if you can connect them via USB so that they act as a gprs or umts modem.

Acecso telefónico a redes
How to create a dial-up network connection with a GPRS/UMTS modem (with Windows XP):
1.-Install the modem’s USB driver.
2.-Click on the “Start” menu -> Connect to -> Show all connections
3.-Go on the left hand menu -> click on “Create a new connection”.
4.-Click on the button “Next”
5.-Select “Connect to the Internet”. Click the “Next” button.
6.-Select “Set up my Connection Manually”. Click the “Next” button.
7.-Select “Connect Using a Dial-Up Modem”. Click the “Next” button.
8.-Select the modem from the list (Siemens AG WM USM… or whatever is it). Click “Next”.
9.-Give the connection a name e.g. “SIEMENS Connection”. Click “Next”.
10.-Put *99***1# in the telephone number. Click “Next”.
11.- Select “Used by Anyone”. Click “Next”
12.-In the username put MOVISTAR, vodafone or CUSTOMER depending on whether it’s Telefónica, Vodafone or Orange respectively. You will have to consult other operators. In the password put MOVISTAR, Vodafone, AMENA depending on whether it’s Telefónica, Vodafone or Orange. You will have to consult other operators. Take care with the capital letters in the login and password. Click “Next”.
13.- Press the “Finish” button.
14.- Now open the Windows “Control Panel” -> Select System -> Hardware Tab –> Device Manager -> Select modem -> Right click Modem Properties (The Siemens/Cinterion one or the one that you are configuring) -> Advanced Options. In Additional Initialization Commands put:
If it’s Telefónica:
If it’s Vodafone:
If it’s Orange:
Press the Accept button.

15.-The button is now ready for the connection. Just double click on the network’s connection icon in network connections to start the connection.

I hope that is will help someone. ;)  

P.S. I am making some very important changes to the blog so sorry if you ever can’t read the posts properly, if the image isn’t in the centre or if there are problems with accents (I’m fighting with the UTF-8 and the ISO-8859-1). I hope that the changes will be positive in the end.

Tags: , , , , ,

Comments 2 Comments »

As we saw some time ago, new Java classes have been included in the new SDK versions from the TC65 module’s new firmware release (current version 3.0), XT65 (current version 2.0) and TC65i (current version 1.0).

Months ago we saw the new Watchdog class. Today I am going to post a small example of how to use the new InPort and OutPort classes which enable us to easily manage the digital inputs and output pins in our Siemens/Cinterion modems.

Programación java Siemens


Description: I have based the example on the MTX65v3. As you know this terminal has 4 digital inputs/outputs which are GPIO1, GPIO2, GPIO3 and GPIO4.

In the example I configured GPIO1 and GPIO2 and inputs and GPIO3 and GPIO4 and outputs. I presume that they are directly joined together through cable connections (GPIO1 with GPIO3 pins and GPIO2 with GPIO4). In the example the output statuses are varied (GPIO3 and GPIO4) and the input values (GPIO1 and GPIO2) are shown through the standard output (System.out.println). In the Java example you can see that the code is discussed line by line so I won’t dwell on it much here. If you use the MTX65v3 and run the application, this should be the result:

Valid for modems: TC65 (v3.0), TC65i, XT65 (v2.0) y MTX65v3

I hope you find it useful. See you next time.

P.S. Good luck for tomorrow (the 22nd) for the Christmas Lottery, let’s see if we are lucky enough to win!

Tags: , , , , ,

Comments No Comments »