Posts Tagged “tc65”

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 »


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 »

You will possibly at some point have to make a Java programme for Cinterion modems TC65 or XT65 where you have to capture data (digital and analog inputs, GPS positions, snaps by the serial port etc.) and store them in an internal file in the flash so that they can later be sent to a central server.

Today I am posting a small Java example to do the second part; the data is sent via FTP to a central server. A long time ago I wrote a few posts with many Java examples including:

In the latter there was an FTP example. This today will elaborate more which will allow you to directly upload a file stored in your modem’s flash memory to a server via FTP. You can download the project and the source code from the example here­.


To test it out without any complications, follow the step by step. Create a file called “data.txt” with the data that you want inside and save it in your TC65/XT65 modem’s FLASH memory (in the root directory). After, import the sample project from Eclipse. Open the file in which you will see that some variables are read from the file EjemploFTP.jad.

If you open the file EjemploFTP.jad you will see that you have to set the following properties:

gprs-timeout: 20
remote-file: fichero.txt
user: MiUserDeFTP
pass: MiPasswordDeFTP
remote-dir: TEST
gprs-user: MOVISTAR
gprs-pass: MOVISTAR

Adjust them to your needs, indicating the remote file name (the name that is saved in your FTP server), your FTP server’s IP, the FTP server’s username and password, the folder to store the file (make sure that the folder is created before running the application) and the rest of the parameters that you already know.

Once you have changed the jad properties to your liking, compile the program and run it, you will see how to upload the data.txt file stored within the modem’s FFS to your FTP server. I’m sure that it will be useful occasionally. 

Finally, although it’s a little late (I have been out of action due to a small operation on my eyelids), as this is the first post of the year I would simply like to wish everyone the best for 2010.

I’ll be back with more another day. ;)

Tags: , , , ,

Comments 13 Comments »

Recently I have been asked a lot about the RAM memory in GPRS TC65 and XT65 modules (and their corresponding terminals) so I am going to post a small article relating to this topic.

As you know the TC65 module has a total of 400Kb of RAM memory and 1.7MB of FLASH memory. Obviously the FLASH memory, FFS (File Flash System) will be occupied partly by your Java application (i.e. .jad and .jar files) and by all extra files needed for your application as well as files generated by your Java application i.e. log files, history etc.

Blog de Electrónica Avanzada

Well… I can make a huge program with 1.7Mb and still have some leftover so why am I wasting time reading this? 

It’s true that you can make pretty large programs but it will depend a lot on how you do it and what tools you are using. If your program isn’t put together well you may have serious problems with your memory.

Wow I don’t understand, when I ran my Java application it says “out of memory”, it was working before. The only thing that I have done is add a few more codes. My .jar file occupies 150Kb and I see that the bigger my .jar file, the less RAM memory is free. How is that possible? But the program isn’t in the flash memory and isn’t the 400Kb of RAM exclusively for my application’s variables and data? 

Obviously not, obviously your .jar and .jad files are in your flash memory, if not it would be deleted when you turn the modem off. But he thinks that the .jar file is a zip file (you can open it with winrar if you want) and the bytecodes, files, .class and the compiled Java code files are inside it. The modem will unzip these files and load what is necessary onto the RAM memory. Therefore the bigger your Java program, the less free space you will have in your RAM memory (or not, depending on your programming).

If for example you are old school and despite allowing Java object orientated programming language, you do linear programming, type C programming this means that if your application consists of a single, huge .java file filled with methods (which you will see as functions of C), you could have serious problems as your application grows. If you work in that way, when you boot up your Java application, you are going to have to load the entire program code permanently in the RAM memory and you could have serious problems with your memory in the long term.

The best way to save yourself from those problems is to use structured programming i.e. object oriented programming. Before you write your code map, structure you application into objects creating a .java file (and therefore a .class file) for each of your application’s objects. This way you will only load small .class files onto memory when needed by your application i.e. you create a certain object when you need it and destroy it when you don’t or you free up memory when you no longer need the object stored. If you make a huge, single .java file program you will have the entire code and all of the methods whether they are necessary or not stored in your memory at any given time.

It’s too late… I’ve already made my application and I’ve got memory problems. I can’t do it all again, it would take weeks and my boss would kill me. Can I do anything? 

You’re in luck, yes (but when you make another application, structure it better). You can use a Java obfuscator. For example, to obfuscate the compiled code is to compress .class files even further. In fact, if you create a package through an obfuscator you will see how the .jar file occupies a lot less space, even half. This is going to give you an advantage as your won’t have to redo the entire application but I recommend more structured programming in the future.

Which obfuscator do you use? 

Personally I use the integrated Proguard in Eclipse. Another day I’ll talk about it in more depth in an article, that’s it for today.

Today is Saturday, let’s see I will finish an outstanding project that I have never had chance to finish off as I have been overworked lately. It’s a little online project that I launched a few days ago in the domain:, a portal for rental apartments, as the name indicates in Spanish.

The truth is that it’s one of the best domain names that I have (and I have more than a hundred). I say that it’s the “Great Reserve of 2002” as that was the year that I acquired the domain. Over the years, I have nearly sold it on several occasions as I have received a few offers to buy it. The last offer was 3,000€ which made me hesitate but finally, seeing as it’s in the yard of the Spanish house that I made, the rent will increase, so I kept it. Time will tell if I did the right thing.

I hope you have a great weekend. ;)

Tags: , , , ,

Comments 8 Comments »

A few weeks ago  I posted about J2ME file compression in Cinterion TC65 and XT65 modems. I posted an example of how to compress files to subsequently make a GPRS connection and send less data too (it’s cheaper and faster).

The issue of unzipping files remained. I.e. if you compress a file with a GPRS modem and send it to a central server, at some point in this server, the file will have to be unzipped in order to process the data.

This can be done easily (in Windows) using a free FLL called zlibwapi.dll.


With this library, it’s easy to create a data decompression program. Here you have a very simple program made in VB6 which allows you to compress (in the same way as the modem) and decompress files. It’s a very simple program using the DLL that I spoke about.

I hope you found it useful. ;)

Tags: , , ,

Comments No 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 »

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 »

If you’ve ever worked with GPIOs from Cinterion TC65 or XT65 (or their MTX terminals), you will have realized that there are different ways to work with them. There are AT commands that allow us to set a specific GPIO as an input/output and there are other AT commands that let us know the status of the GPIO set as an input (1 or 0) or even allow us to change an output status.

In one of the Java examples that I have been posting on this blog, specifically in the GPIO EXAMPLE, I simply used the command AT^SGIO which returns the pin status at that point in time. So it depends on the application that you want to run as this AT command could suffice, but this system isn’t usually used as we obtain a very low “sweep frequency” (in addition to loading the system) and therefore it’s very complicated to detect very small changes in the input pin status. If for example you have to detect a volumetric detection pulse, you might not catch it.


The best thing to do to detect GPIO status changes is to use polling. This way the modem sends you a URC message each time a GPIO change is detected.

Let’s look at an example. Imagine that you want to control GPIO1, GPIO2, GPIO3 and GPIO4 inputs. How do we do it?

Well the first thing you need to do is enable the GPIOs, to do this send:


Then, configure the pins GPIO1, GPIO2, GPIO3 and GPIO4 as inputs, to do this:





After that we create a port, i.e. a port with all of the GPIOs that we want to involve in the polling process:


By sending this command, the AT command will return an IDPort (port identifier) e.g. it will response with IDPort = 112

And now we have everything ready to activate polling. We activate doing this:


This way whenever there is a change in one of the GPIOs, the modem will send us a URC in this style:

^SCPOL: 112, x

X can be worth 0-1024 i.e. it returns the status of the 10 possible GPIOs that you can control with the TC65 modem.

Well I’ll be back another day, I’m going to go and make dinner now as today CSI Las Vegas is on and it’s the only bit of TV I watch all week. The truth is every time I watch the TV I realize that I like is less and less. Am I getting old?! :S

Tags: , , ,

Comments 9 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 »