blogElectronica.com

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.

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: cinterion, ejemplos java, mtx65+g, xt65

 

I have had the OTAP platform active for a very long time. Since then it has been used for thousands of OTAPs. As you know an OTAP is the process that allows you to remotely update Java applications that we embed in out Siemens/Cinterion modems. Today I’m going to present version 2.0 of this software which is similar to version 1.0 but has some important differences.

The first thing is that it no longer depends on my server www.otap.es. Now the software has a little TCP/IP server to manage OTAP responses. As you know, this means that when an OTAP process ends (good or bad), if the GPRS connectivity is correct it sends a notification (POST request) to a web server indicating the result of the operation. In version 1.0 this notification was always sent to www.otap.es by the modem whereas in version 2.0 you can specify your OTAP confirmation server or use this same application (v2.0) as a confirmation server. I have also prepared for this.

 

If you look at the following screenshot…

 

 …you will see the URL notify parameter. That is the URL that the modem will call when the OTAP process has finished. As I said before, you can specify your own OTAP confirmation server (via IP or DNS) or use this same application as a confirmation server. For the latter, the simplest thing to do is click on the “My IP” button. By pressing this button a URL is automatically created with you router’s public IP address (if you didn’t know). This means that for example, when clicking on the “My IP” button, the URL notify parameter will display something like this (in my case):

 

http://83.56.194.122:20010/?ID=

This indicates that for the server confirmation, the modem must use the IP:  83.56.192.122, the 20010 port and it works like an ID phone number parameter. The software automatically changes the text <phone> for the number corresponding to the SIM which will carry out the OTAP. This is so that when the OTAP confirmation server receives the confirmation, it knows which phone number it’s about.

Two very important things. One is that obviously you have to do a NAT in our company’s ADSL router to redirect the 20010 port (or the port that you are using) to the PC where the OTAP confirmation software is running. The other is that you mustn’t forget the “/” between the port number (20010 in the example) and the question mark (?).

Once all of the necessary data is completed, we are ready to do the OTAP. For this we have to have a GSM modem connected to our PC’s serial port (configured to 115200,8,N1 and with HW flow control) which will be responsible for send OTAP SMSs. Once everything is connected we can press on the button “Initiate OTAP Process”.

 

Here is another difference with version 2.0 with regards to version 1.0. In the figure above and below, if you look, you will see that we have finally decided to use this same application as an OTAP confirmation server you have to enable the “OTAP Server Active” box and specify the TCP port indicated on the previous screen in “URL Notify”. I repeat that you mustn’t forget the NAT in the router and don’t forget to disable the windows firewall and/or antivirus so that they don’t block the chose TCP port.

As soon as this is done we are ready to press “Start OTAP Process” and the process will begin. In this version 2.0, the control OTAP error control has improved considerably. If you look, you will see that the superior table has 3 columns. The first two are the same as version 1.0, but the third one shows a LOG with what has happened. All you have to do is double click with the mouse on a certain LOG to open a screen with the complete LOG. This was it’s much easier to figure out the reason for an OTAP error if there is one. For example, if the OTAP process finished with OK and we open the LOG we will see something like this:

If on the other hand we didn’t specify the correct path (URL) inside the JAD file, we would have an error like the following in the <MIDlet-Jar-UR> parameter of the JAR file:

If we had been mistaken and didn’t specify the correct JAR file size in the <MIDlet-Jar-Size> parameter inside the JAD file, we would get an error like this:

If you wanted to test out the program you could certainly do it with the HelloWorld example that I have on blogElectronica. You can see the correct JAD in:

http://www.blogelectronica.com/TEMP/HelloWorld.jad

I hope that whoever uses OTAP finds it interesting. Here you have the LINK to download OTAP v2.0 software that I put in a zip file with all of the necessary DLLs so you don’t need an installation. If anyone has any problems with DLLs, please let me know. This version is completely free and never expires, but as there’s an important job for me to do, there’s always a “but”, it is limited. You can enter up to 5 modems into the system and therefore you can do OTAP simultaneously with a maximum of 5 modems (with a constant in the source code). But this version will be sufficient for most users.

But for those who don’t want to be limited to 5 modems, want to be able to use all necessary modems and especially want a COMPLETE SOURCE CODE from the OTAP v2.0 application, you are able to get it through PayPal (as it’s personal to me and I email it at 24h) Let’s see… if I was allowed a faster server for blogElectronica and for other future projects what would I have in mind…

Having the source code could be very useful to anyone who has planned their own OTAP application in order to not have to start from scratch and to save time. By having the application’s source code it’s possibly to modify it, made it bigger, add parameters, logos or whatever you want. I haven’t done it in Java, I’ve done it in Visual Basic 6 and I’ve included many comments so that everyone can understand without having to take any classes.

I hope it’s been interesting for you. See you another day, happy Sunday!  

Tags: cinterion, mtx65, OTAP, tc65, xt65

Well here I am back from vacation. This Easter I spent a few wonderful days in Cáceres with my family (a lot of my mother’s family lives there). I had not been there for many years and I missed the drumsticks, the drunkness the family. The truth is that I really enjoyed it and I hope to go back soon.

Ok, let’s get on with it… today we are going to look at implementing a Web Server.

Sometimes it can be interesting to incorporate a little web server in our TC65 or MTX65 GPRS modems. It’s convenient to directly connect to the modem with a browser or any parameter. So today I’m putting up an example that I’ve made, it’s slightly longer than usual, it took up quite a lot of time and it implements this: a small and simple (very simple) Web Server. This example can also be used as a Socket Server example. I don’t remember which blog user it was but I told them that I would post an example or Socket Server in Java. So here it is.

The example here is part of one of my projects. I have taken many things from my project, including error control, to break it down a little bit and make it more understandable. I think that it’s enough. Anyway to remove the code there might be an instruction that’s not necessary, I haven’t looked at everything, I just checked that it worked properly.

Alright, what does this example do? 

If you download and open the project you will see 3 files. To test out the example you just have to edit the main.java and change the connection parameters depending on your operator. If you use Movistar in Spain you can leave the code as it is and compile and run the project.

When you run the program you will see that the modem is connected to the GPRS and the obtained IP will come out through the standard output (normally ASC0). If I run it I get:

After this, open the browser (I only tried with Microsoft Explorer, nothing else) and write something in the address bar like:

http://80.29.209.172/suma.html?a=10&b=20

You will get a response like this:

This means that the modem has received the HTTP GET request, taken the values “a” and “b” from the parameters passed in the URL, added them together and returned them to a HTTP page with the sum. Obviously what this example does (GPRS calculator) is not used a lot and doesn’t make much sense, but I’m sure that this example will spark new ideas.

One more thing, I have put a variable called “numMaxClientesX” in the code. You can specify the number of concurrent requests that you may have in this. By default it’s “1” and you can increase it but remember that Siemens/Cinterion modems support up to 6 sockets and one of them already has the socket listener that listens in the TCP80 port (Http). Also, think about launching a Thread for each connection established.

The example is done using sockets via java classes. To whoever asked me which is better, if you manage the sockets with java classes or with AT commands as I have sometimes done before in this blog, I wouldn’t know what to say as they are more or less the same. The advantage of using java classes is that perhaps the application (socket server) is slightly simpler to implement and with AT commands you have a little more control over each of the socket’s status. They are subjective assessments as both methods work really well; sometimes I use one and sometimes the other.

I hope that you found it interesting, until next time.

www.blogElectronica.com

Tags: cinterion, ejemplo java, mtx65, tc65, xt65

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

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: cinterion, j2me, java, tc65, xt65

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.

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: cinterion, j2me, java, tc65, xt65

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

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

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

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

I hope you found it useful.

Tags: cinterion, ejemplos java, tc65, xt65

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 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: cinterion, j2me, java, mtx65, Siemens, tc65, xt65

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.

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: cinterion, ejemplos java, mtx65, mtx65+g, Siemens, xt65

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.

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: cinterion, j2me, java, mtx65, mtx65+g, Siemens, tc65, xt65

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

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

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

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

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

AT^SPIO=1

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

AT^SCPIN=1,0,0

AT^SCPIN=1,1,0

AT^SCPIN=1,2,0

AT^SCPIN=1,3,0

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

AT^SCPORT=0,1,2,3

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

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

AT^SCPOL=1,112

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

^SCPOL: 112, x

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

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

Tags: cinterion, modem, tc65, xt65