Archive for the “4.PROGRAMACIÓN” Category

A few months ago I presented quite an interesting product called CDP (Cellular Development Platform) from Multitech. Let’s remember that this device is a boxed embedded PC based on a 400MHz ARM9 processor that has a GPRS modem inside, ETH port, RS232 serial port, SD card clot and optional GPS. All is mounted on an open platform based on Linux.

Just to tell you, the newly revised CDP is already available. Now you can have an HSPA internal modem at 7.2Mbps (ideal for video applications as the previous version was only GPRS) as well as something that I missed in the previous version which is an increase in the device’s inputs/outputs (as the previous version had very few). In this version the CDP has a 32-pin connector dedicated to I/Os and in which you can additionally find an SPI bus, I2C, ADC and digital inputs/outputs.

Whoever wants to see the device’s complete description as well as programming examples, the best thing to do is have a look at the website that the manufacturer created exclusively for this product:

http://www.multitech.net/developer/products/cellular-development-platform/

cdp-multitech

Comments 2 Comments »

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.

Blog de Electrónica Avanzada

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:

java-web-server1

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:

java-web-server2

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: , , , ,

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

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

As we saw some time ago, new Java classes have been included in the new SDK versions from the TC65 module’s new firmware release (current version 3.0), XT65 (current version 2.0) and TC65i (current version 1.0).

Months ago we saw the new Watchdog class. Today I am going to post a small example of how to use the new InPort and OutPort classes which enable us to easily manage the digital inputs and output pins in our Siemens/Cinterion modems.

Programación java Siemens


GPIO_API_EXAMPLE 
(Download)

Description: I have based the example on the MTX65v3. As you know this terminal has 4 digital inputs/outputs which are GPIO1, GPIO2, GPIO3 and GPIO4.

In the example I configured GPIO1 and GPIO2 and inputs and GPIO3 and GPIO4 and outputs. I presume that they are directly joined together through cable connections (GPIO1 with GPIO3 pins and GPIO2 with GPIO4). In the example the output statuses are varied (GPIO3 and GPIO4) and the input values (GPIO1 and GPIO2) are shown through the standard output (System.out.println). In the Java example you can see that the code is discussed line by line so I won’t dwell on it much here. If you use the MTX65v3 and run the application, this should be the result:

Valid for modems: TC65 (v3.0), TC65i, XT65 (v2.0) y MTX65v3

I hope you find it useful. See you next time.

P.S. Good luck for tomorrow (the 22nd) for the Christmas Lottery, let’s see if we are lucky enough to win!

Tags: , , , , ,

Comments No Comments »

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 »