Posts Tagged “j2me”

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 blogElectronica.com 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
CAN
     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.

snap-stamp-imsys-prestacion

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: http://sourceforge.net/projects/proguard/files/

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

c:\Eclipse\proguard4.5.1\

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

proguard-1

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:

proguard-1

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:
http://www.blogelectronica.com/ejemplos-java-j2me-modem-gprs-siemens/
or
http://www.blogelectronica.com/j2me-ftp-cinterion-tc65-xt65-mtx65-tc65t/

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

FTP J2ME

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 FtpHandle.java 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
server: 100.100.100.100
user: MiUserDeFTP
pass: MiPasswordDeFTP
remote-dir: TEST
gprs-apn: movistar.es
gprs-user: MOVISTAR
gprs-dns: 80.58.0.33
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: www.PisosDeAlquiler.com, 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.

compression-j2me
www.blogElectronica.com

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 java.util.zip 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 http://www.jcraft.com/jzlib/), 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. (http://www.pkware.com/products/enterprise/white_papers/appnote.html).

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:

AT^SCFG=”Userware/Stdout”,”FILE”,20000,”a:/log.txt”,”secure”

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


System.out.println(“Hola”);

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)
Connector.open(“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)*/
objOutputStream.write(“adios”.getBytes());

/*Send it writing everything that’s left in the buffer prior to closing it*/
objOutputStream.flush();

/*Close the object*/
objOutputStream.close();

/*Close the file*/
objFileConnection.close();

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 »

I haven’t written on blogElectronica for nearly a month. For one reason or another it’s been hard to find any spare time in the past few weeks… I’ve had a lot of work, a personal project that has required more of my attention than usual, a small operation to remove some small spots from my eyelids (I’m sure someone asked me what had happened to my eyes the other day ;) ) and the last few days I have been unwell with the flu. From now on I hope the go back to writing an article every week or so.

Right let’s get started, this is an easy article to pick up the pace. We are going to look at an example of how to get the date/time in your TC65 Siemens/Cinterion modems (of course all this applies to other terminals like the MTX65MTX65+G and TC65T).

Occasionally we need to have the current date/time in our Java program for these modems. What for? For example it’s to save the time on a log along with some data or to do a task at a specific time etc. This means that there are multiple situations where we need to have the correct time. As I’m sure you know, the TC65 has an RTC, but unless we have a back-up battery for this RTC (the MTX65 has the footprint for it), after rebooting the computer the RTC won’t have the time.

RFC868

So how do we get the date/time? 

Well there are several ways. If we are talking about a  GPS device like the XT65 (or MTX65+G) it’s a lot easier as it can be extracted from the position frame i.e. if we reed the position with AT^SGPSR=0 we will get the response:

  ^SGPSR: [GpsDate, GpsUTCTime, GpsLatitude, NS-Indicator, GpsLongitude, EW-Indicator, GpsAltitude, GpsSpeed, GpsCourse, GpsStatus]

where in GpdDate and GPSUTCTime we get the date and time respectively. But this doesn’t work will all modems like with the TC65, MTX65 and TC65T that have GPS. In fact even for the XT65/MTX65+G we can need to know the time even without GPS coverage.

What can be done then? 

Well a typical and simple way is to send itself an SMS message. I will be able to get the date/time at the end of the SMS after I have received it. Once I have got it from the SMS, I can establish the time in the modem with the command AT+CCLK. This method doesn’t give a very accurate time, as you can tell easily.

Without doubt the best way to get the date/time is using NTP (Network Time Protocol). NTP allows you to synchronize the clock with variable latency networks like the internet with very high precision. For this method UDP packets are used. However this protocol is quite complex and the vast majority of applications don’t need to have millisecond accuracy.

And how do you get the time with some precision in a simple way?

With Time Protocol (RFC868). It’s very, very simple. There are many time servers online that offer Time Protocol e.g.:

time-a.timefreq.bldrdoc.gov
time-b.timefreq.bldrdoc.gov
time-c.timefreq.bldrdoc.gov
utcnist.colorado.edu
time-nw.nist.gov
nist1.nyc.certifiedtime.com
nist1.dc.certifiedtime.com
nist1.sjc.certifiedtime.com
nist1.datum.com
ntp2.cmc.ec.gc.ca
ntps1-0.uni-erlangen.de
ntps1-1.uni-erlangen.de
ntps1-2.uni-erlangen.de
ntps1-0.cs.tu-berlin.de
time.ien.it
ptbtime1.ptb.de
ptbtime2.ptb.de

 

Very good, how does it work? 

Well basically these servers are listening to the TCP/UDP 37 port and the procedure is as follows (for TCP):

1.- Connect to the time server via the TCP37 port.
2.- After connecting, without us sending anything, the server sends us a 4-byte data package with the date/time (with the seconds passed from 00:00:00 of 1/1/1990).
3.- The server closes the socket.

It’s that easy.

Indeed it’s not as precise as using NTP, but the time from when the server sends the 4-byte data package until the time that we receive it can vary slightly. But as I said before, being one or two seconds out isn’t important for most of our applications

Java Example.

I’m posting  a Java example here for the MTX65/MTX65+G for those who need it. It does what I mentioned before. It connects to a time server, gets 4-bytes with the time and calculates the date/time. How easy is that?

The program is very simple, but just so nobody gets confused I will go over the following lines from the code:

//Calculate the seconds passed from 1/1/1900 secondsFrom1900=buffer[0]*16777216 + buffer[1]*65536 + buffer[2]*256 + buffer[3];

//Now calculate the milliseconds passed from 1/1/1970
millisecondsFrom1970=secondsFrom1900-Long.parseLong(“2208988800″);

//As Java needs milliseconds (not seconds) to
//calculate the date from 1/1/1970 we multiply it by 1000
millisecondsFrom1970=millisecondsFrom1970*1000;

//We get the current date/time (GMT)
date = new Date(millisecondsFrom1970);
System.out.println(“Date/Time:  ” + date.toString());

The protocol specified in the RFC868 indicates that the server has returned the seconds that have passed since 1/1/1900 at 00:00:00 and I store and calculate it in the secondsFrom1900 variable.

But Java, the constructor of the Date class, needs the milliseconds (milli, not seconds) passed from 1/1/1970.  This is why we firstly subtract the seconds passed from the year 1900 to today from the seconds passed from 1900 to 1970 (some 2208988800 seconds), obtaining the seconds passed from 1/1/1970 to today. After we multiply the value by 1000 as we need to work with milliseconds and not seconds. The rest of the program is very simple.

Well I hope that you found this article interesting, see you next time. Be good! ;)

 

Tags: , , , , , , , ,

Comments 15 Comments »

This morning I spent a while testing sending emails through AT commands with a TC65 Siemens modem, so to make use of what I have in mind I have made a brief example with Java, in the same style as I did it a while ago.

Programación java Siemens


EMAIL_EXAMPLE 
(Download)

Description: It’s a basic application for sending EMAILS with Java for Siemens modems. It creates a GPRS connection and sends an email to the specified email address. All you have to do is modify the code lines that indicate the SMTP server, your email account’s login and password, the original email address that sends the email and the destination email address where the email is sent.

Valid for modems: TC65, XT65, TC65T, MTX65 y MTX65+G

Well I hope you found it interesting, see you next time. Good night! ;)  

Tags: , , , , ,

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

at^scfg=”Userware/Autostart”,”",”1″
at^scfg=”Userware/Autostart/AppName”,”",”a:/HelloWorld.jar”
at^scfg=”"Userware/Autostart/Delay”,”",”50″

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 »