Posts Tagged “ejemplos java”

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

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

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

gps-nmea

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

 

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

 

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

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

See you another day. Good night ;)

 

Tags: , , ,

Comments 4 Comments »

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.

compression-j2me

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 »

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

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

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

Blog de Electrónica Avanzada

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

What can be done then? 

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

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

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

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

 

Tags: , , , , ,

Comments 18 Comments »

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 »