Posts Tagged “java”

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 »

Today I am going to talk about a small module from Imsys. I really think that I should have already mentioned this company as I’m sure that these types of modules will create some interest because many readers use the well-known TC65 and XT65 Cinterion modules (I will share good news about these soon).

As I was saying, I present to you the new module Snap Stamp from the company Imsys. First of all, here is a photo so that you can recognize it:

snap stamp imsys

As you can see it’s a very small module, each side measures 29mm. It is called Stamp because it’s the size of a stamp.The important thing is that this module is based on the IM3910 Java processor.  You program these modules in the same way that we program the XT65/TC65i Cinterion modules and MTX65 java (J2ME) terminals. This means that if you are already familiar with Java programming in Cinterion and MTX modules, you already know how to program the Snap Stamp module. This obviously is an incredible advantage for time-to-market for all of those who need to start a new project with a processor module, as you could have already developed the knowledge of how to use codes and Java classes in Cinterion modules and MTX terminals. It’s like the latter, compile your program (in Eclipse or Netbeans) and upload your file .JAR to the module (this case is not by OBEX but by local/remote Ethernet and then it will run).

Snap Stamp has a complete TCP/IP stack in the same way that Cinterion modules do, but it also has a web server, ftp, telnet, gestor de I/O etc.

Here are the technical specifications of the module:

• High performance multi-threaded Java execution
• Certified J2ME-CLDC virtual machine
• Four channel A/D 16-bit 44 ksps converter with optional external reference voltage
• Two D/A 16-bit 44ksps converters
 2* / 4* / 8 Mbytes Flash memory
• 8 / 32* Mbytes SDRAM
 10/100Base-T Ethernet MAC and PHY
• Optional 2nd RMII interface
 TCP/IP stack, Web/FTP/Telnet server
• Three serial ports (3.3V levels, 4-wire, 920 kb/s)
• High-speed I2C bus and SPI
• Parallel 8-bit high speed data bus
 8 to 53 General-purpose digital I/O ports
• MMC / SD card support
 Extensive I/O functions through Java APIs, including PPP, FTP, E-mail, GPIO, Timers
• Enhanced performance for special functions e.g. graphics, crypto, and floating point operations
• Rubus JOS RTOS with failsafe flash file system
• High I/O bandwidth (>650 Mbits/s DMA)
• Real time clock and calendar
• On board Temperature sensor
• 150 / 200* MHz oscillator frequency
• Commercial / Industrial* temp range
• Connection for Imsys JTAG Trace Adapter
• Reference designs available, complete with schematics and firmware for:
Dallas/Maxim 1-wire
     TFT LCD, Touch panel
       CD quality Audio

The * indicates that it is optional and they are supplied with a minimum order of parts.

Here you also have a small comparative between the Imsys processor and different processors.


I hope that you find this small module interesting. We are already aware that many people read this blog so I am sure that tomorrow I will have an email asking me a question :)


Tags: , ,

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

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 »

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 »

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 »

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 »

Today I am writing a small post to do with autostart applications for TC65/XT65  Siemens modems and TC65T, MTX65 and MTX65+G terminals distributed by Matrix. Most of you are likely to know about it, but those of you who are beginners won’t. Therefore writing a bit about it is not a bad thing.

If you start working with these Siemens/Cinterion modems, you will probably spend a bit of time reading the initial documentation, installing the development environment and doing the first steps for J2ME (maybe with an example you found on the internet ;) ).

There will come a time when you have made your Java application and you want the application that you have made to automatically start when power is supplied to the modem. Unless you are testing it, it doesn’t make sense to always start the application with the command AT^SJRA.

To auto-configure the modem so that an application starts automatically you use the command AT^SCFG. If you write AT^SCFG? you will see a lot of configuration data. At the bottom near the end you will see something like:

^SCFG: “Userware/Autostart”,”1″
^SCFG: “Userware/Autostart/AppName”,”a:/HelloWorld.jar”
^SCFG: “Userware/Autostart/Delay”,”100″

Programación java Siemens

If you set the “Userware/Autostart” to 1 like in the previous example, supplying the modem with power will automatically start the application specified in “Userware/Autostart/AppName”. In the above example the application “a:/HelloWorld.jar” will start.

I’m to configure the above parameters but I get an error. Why is that?

You probably haven’t specified a password. There are certain commands, including these, where you can set a password to avoid anyone changing anything (a password that you can set in “Userware/Passwd” with the same command AT^SCFG). If you still haven’t specified a password, the right AT command to set autostart is:


Notice the empty double quotes above. They are empty because a password hasn’t been specified.

Now I don’t get an error. What is the Delay for?

The delay allows you to set the length of time from when the modem has a power supply until the Java application specified in “Autostart/AppName” is turned on. The pause is in tenths of a second, so the value of 50 is equal to 5 seconds.

Why would I want a pause? I want it to start immediately. I’ll put 0.

Ok so the application will start almost immediately, but keep in mind that whenever you have a Java application running inside you can’t access the modem by the serial ports or the USB port (neither with AT commands nor MES). So if you put 0, it will cost you a lot to deactivate the autostart for example. The internal Java application will have immediate control of the serial ports.

Argghh I didn’t realize and I’ve already set the Delay to 0 and I can’t access the modem at all. Will I be charged?

No but now you will have to use a Siemens application that you’ll find by clicking on “Start-> All Programs-> Siemens-> (TC65 or XT65 ….) -> Autostart Switch Off.”

This utility sets the “Userware/Autostart” to zero. It’s quite complicated because you have to start the modem and immediately push the software’s button. This is so that for the brief moment from when the modem switches on to when Java application starts, the Switch Autostart Off program will send a command to set autostart to 0. It will take a few minutes so don’t worry.

Anyway if it doesn’t work after a few minutes let me know and I’ll send you a little program that I made which basically does that same as the Siemens program but it’s a lot quicker. With this program when you press the button it sends frames at^scfg=”Userware/Autostart”,””,”0″ at full speed (and not just once) so it is easier for the modem to “catch” a frame.

Ok I’ve managed to unblock it, that scared me! So should I always have a Delay?

I would say yes, at least during the development phase. If you set the delay to 50 for example, it buys you five seconds from when the modem gets a power supply which is plenty of time to send at^scfg=”Userware/Autostart”,””,”0″ to deactivate the autostart.

I hope you found the article useful. See you again soon! ;)

Tags: , , , , , , ,

Comments 34 Comments »