Posts Tagged “mtx65+g”

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 »

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

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

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

Blog de Electrónica Avanzada

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

What can be done then? 

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

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

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

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

 

Tags: , , , , ,

Comments 18 Comments »

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

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

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

Blog de Electrónica Avanzada

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

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

So how do we do this?

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

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

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

Do you have any examples? 

Of course, configure the modem with:

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

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

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

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

I hope that is will help someone. ;)  

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

Tags: , , , , ,

Comments 2 Comments »

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 »

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 »

Today I am going to talk about a little Multiplex feature in Siemens modems. As you know, some of the current modems like the MTX65+G  (GPRS+GPS modem) and the imminent MTX-HC25+PLUS (UMTS+GPS) have a single communication serial port.

There may be some applications where we’d like to have more than one serial port.

Why would I want more than one serial port?

Well for example it could be to maintain a GPRS communication through a serial port, to monitor the coverage level through another serial port and to obtain GPS coordinates through the other serial port. So yes it is possible but we use Multiplex mode for this.

The Multiplex protocol (GSM 07.10 y 3G TS 27.010) enables an asynchronous serial interface to be split into three virtual channels. It’s basically a communications protocol that encapsulates communications between the host (e.g. PC/ microprocessor) and a corresponding device (modem) with three virtual serial ports.

How do you use it?

Siemens provides some drivers for Windows (XP/2000) to be able to use this feature. If you don’t want to use a PC with Windows and you want to use a microprocessor for example, you can install the Multiplex protocol. It’s quite complex but it can be done.

To use driver in Windows, all you have to do is install the Siemens WinMux application. When you run it a window like this will appear:

Driver Multiplex All you have to do is have the modem physically connected to the PC’s COM port so that the driver will find it by clicking on the “Start Scan” button. Once the modem is connected it will suggest some port numbers as to where you should install the 3 virtual serial ports. As you can see in the figure above, I have installed it in COM24, COM25 and COM26.

After installing the driver, go to Start-> Control Panel-> System-> Hardware-> Device Manager:

Driver Multiplex  You will se that the “Serial Multiplex Driver” has been assigned to a COM, in my case COM1. If you right click on the installed driver’s properties you will be able to change the assigned COM, the speed and the virtual COM numbers.
Multiplex

One last thing, there’s a catch with the number assigned to each of the COM ports (it’s probably Windows’ fault) and the catch is that it doesn’t let you install it on any COM number. For example there are programs which don’t accept high COM numbers (COM24/COM25/COM26). If you want to change it, I have already registered to Windows you already know:

Start -> Run -> Manage

I searched for a VirtPort1 string and I changed the assigned COM for another one that interested me. It worked without any problems although I had to restart the computer after making a change before using it.

regedit-driver.gif

If we no try to open up to 3 HyperTerminal windows, each one associated with a virtual COM port, and we send AT commands you will see that it works without any problems.

I hope you found this interesting, see you next time. ;)  

Tags: , , , , , , ,

Comments 10 Comments »

Today I am going to write a small post with a new Java example for Siemens modems, it follows on from the post with examples that I wrote a few days ago. I will be posting more examples from time to time that you can use. If you ever want to share any examples or ideas with me they will be gladly received. ;)

Programación java Siemens


FTP_EXAMPLE
 (Download)

Description: it’s a basic FTP application with Java for Siemens modems. It creates a FTP connection and it creates a file called “file.txt” in the remote server and it contains “123”. All you have to do it modify the code line where the login, password and FTP server are that you want to use.

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

I want to comment on one detail from the examples that I posted the other day. I posted all of the examples in the format EXAMPLE_xxx. Well all of the examples work perfectly with the command AT^SJRA but if you put that name in the AT^SCFG command’s “Userware/Autostart/AppName” so that the application starts automatically, it will not work. Don’t write the underscore (_) in your .jar file’s name for autostarting.

Right that’s it for today, it’s my daughter’s birthday today and I want to set up the Wii that I bought her before she gets home. And no it’s not a boomerang gift, I’m more of a Playstation guy. :) I will automatically get myself a PS3 as a gift before the end of the year. See you next time.

Tags: , , , , , , ,

Comments 33 Comments »

Over the last few months I have been getting a number of programming examples for gprs Siemens modems (TC65 and XT65) and for terminals  (TC65T, MTX65 and MTX65+G) both distributed by Matrix in Spain.

Today it’s Saturday and I’m going to give you a set of examples from these modems so that they are there when you need them. The majority of them can be found in previous posts although there are a few new ones.

They are quick examples i.e. I don’t completely run all of the exceptions or anything but if you are just starting out with these modems, I think this may be a good guide. You will see that the vast majority of applications that you can get for real projects are based on small tasks, which is what the following examples show:

Programación java Siemens

Here we go; these are the examples that are in the blog:

EXAMPLE_HelloWorld (Download)

Description: All this basic application does is take information from the modem’s standard output. First you have to configure the standard output with the command AT^SCFG for example AT^SCF=”Userware/Stdout”,””,”ASC0″

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

EXAMPLE_SMS (Download)

Description: Basically what this example does is send an SMS to a specific phone number every minute.

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

EXAMPLE_Thread (Download)

Description: The program launches a thread, what this does is count up to 5 taking the result from the standard output. The program waits for the end of the thread before finishing.

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

EXAMPLE_Timer (Download)

Description: This example creates a 5 second timer i.e. every 5 seconds it runs task, what it does is take data from the modem’s standard output.

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

EXAMPLE_GPIO (Download)

Description: It shows how to configure a GPIO input and output with Java, e.g. changing the GPIO output status or how to read the input.

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

EXAMPLE_TCPConnection (Download)

Description: This shows how to create a TCP/IP connection with the AT command class. The example creates a connection with a socket that connects to Google’s IP; it sends a frame through the socket and receives a string through the socket which shows the standard output.

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

EXAMPLE_TCPConnection2 (Download)

Description: It shows how to create a TCP/IP connection using Java classes themselves. The example creates a connection with a socket that connects to Google’s IP. It sends a frame through the socket and receives a string through the socket which shows the standard output.

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

EXAMPLE_Files (Download)

Description: This shows how to create a file in the modem’s flash memory, how to write data in it and read the data too.

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

EXAMPLE_GPS (Download)

Description: This shows how to use GPS with the AT command class. The boot up program activates the GPS and it programs it to receive a URC with the position every 5 seconds. This position is stored in a variable and it also shows the standard output.

Valid for modems: XT65 and MTX65+G

EXAMPLE_GPS_JSR179 (Download)

Description:

This example briefly shows how to capture a GPS position without using the AT commands class i.e. using the JSR179’s Location class.

Valid for modems: XT65 and MTX65+G

EXAMPLE_HTTP (Download)

Description: This example creates a GPRS connection and uses the Java class HttpConnection that is downloaded and shown through Google homepage’s standard output

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

EXAMPLE_SerialPort (Download)

Description: This shows how to use the modem’s serial port/s with Java. It opens the two serial ports ASC0 and ASC1 and whatever it receives at ASC0 at 115200 bauds is retransmitted by the ASC1 at 57600 and vice versa. It’s designed for the TC65 but it is used to see how to operate the XT65’s ASC0 port.

Valid for modems: TC65, TC65T and MTX65 (XT65 and MTX65+G only 1 serial port).

EXAMPLE_Watchdog (Download)

Description: This shows how to use the TC65v3’s new Watchdog. The program has up to 25000. After 10000 the program stops refreshing Watchdog so that you see how to reset it after 15 seconds.

Valid for modems: TC65, TC65T and MTX65 (with version 3.0 de firmware)

I hope that you find these examples useful. I will try to put more on soon related to low power modes and FTP.

So congratulations to those of you who are on holiday and to those who aren’t like me, cheer up we’re almost there! ;) See you next time!

Tags: , , , , , , ,

Comments 157 Comments »