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! ;)

 



Post relacionados:

  1. Adding Data to Files from Java with Siemens-Cinterion Modems On several occasions I have been asked how to add...
  2. FTP Java Example for Siemens Modems Today I am going to write a small post with...
  3. (Español) Ejemplos Java para módems de Siemens Over the last few months I have been getting a...
  4. Java Email Example for Siemens/Cinterion Modems This morning I spent a while testing sending emails through...
  5. Java Application Autostart in Siemens Modems Today I am writing a small post to do with...








Tags: , , , , , , , ,
15 Responses to “How to get the time with MTX terminals and Siemens/Cinterion modems”
  1. Lt_Henry says:

    Hace poco que estoy trabajando con este terminal, y tengo un problema con los sockets que aun no he podido sacar adelante. Creo la conexion, creo el socket y lo abro, envio los datos (y llegan al otro lado) pero cuando vuelvo a lanzar un AT^SISW, se queda bloqueado, aunque sea para hacer un query de el estado de la transmision. La sentencia en cuestion es esta:

    “AT^SISW=0,” + data.length() + “,0,0\r”

    pero vamos, esta sacado de los ejemplos. Lo unico que me desconcierta un poco en lo que estoy haciendo, es que me llega un evento al hacer el primer SISW tal que:

    ^SISW: 0,1

    Por lo que entiendo de la documentacion (algo en lo que Siemens suele suspender) es que el cnfWriteLength es de 1, y no puedo mandar mas de 1 byte a la vez?

    Como veis estoy mas perdido que un pulpo en un garaje. ¿Algun idea?

  2. Currumblera says:

    Hablando del tema de la hora….

    Tengo 2 MTX-65+G V3, y cuando activo los URC´s del GPS, o leo GPSData, tengo una hora menos de la real. ¿Alguien sabe si hay que configurar algo, o como se hace correctamente?. Supongo que habrá que configurar algo, porque la fecha, hora y demas datos los coge de los satélites.
    Espero vuestra ayuda, gracias.

  3. blogElectronica says:

    Hola Currumblera,

    los satélites no envían la hora del lugar en el que estás. (Es decir, un GPS en Canarias no va a recibir una hora menos que un GPS en Madrid, para entendernos. En todos los lugares del planera vas a leer la misma hora).

    El GPS te va a devolver la hora UTC (Coordinated Universal Time). Mira este link:

    http://es.wikipedia.org/wiki/Coordinated_Universal_Time

    Fíjate en España. La hora en España es UTC+1 en Invierno y UTC+2 en verano.

    Espero haberte ayudado.

    Salu2.

  4. Currumblera says:

    Gracias blogElectronica , está clara tu respuesta. Otra cuestión. ¿has probado ya si se puede grabar a la FFS, la lectura de almanac y ephemeris? (para el MTX-65+g V3)
    ¿cual sería el procedimiento para hacerlo?. Es que implantar un A-GPS, lo considero imprescindible en una aplicación final. Gracias por este magnífico foro.

  5. blogElectronica says:

    Hola Lt_Henry,

    el URC: ^SISW: 0,1 te indica que ya puedes enviar más datos. Es decir, en cuanto te conectes con el SISO, al cabo de un instante recibirás un ^SISW: 0,1 indicándote que ya puedes escribir datos. En el ejemplo java, para que fuese breve, he puesto una simple pausa (prometo cambiarlo) pero no habría en enviar datos hasta recibir ese URC. Cuando envíes datos con SISW espera a recibir el SISW: 0,1 para enviar más datos, a ver si a si no tienes problemas.

    P.D. no me digas que Siemens suspende en documentación que me cabreo … :) ) Si algo tiene bueno Siemens es la gran cantidad de documentación, a lo mejor el problema es ese, que hay demasiada …

    Salu2

  6. blogElectronica says:

    Lt_HEndry,

    me olvidaba, por supuesto puedes mandar más de 1 byte a la vez. En la documentación te lo indica, 1500 bytes.

    Salu2.

  7. Lt_Henry says:

    Vale, es cierto, cuando hago el SISO al instante me llega el evento SISW: 0,1. Me espero hasta entonces, envio los datos (que llegan correctamente), sin embargo, aun con esperas de varios minutos, no vuelve a llegar ningun otro evento SISW, y cualquier llamada a comandos AT que tengan que ver con la conexion TCP bloquea el terminal (SISW, SISC, …) lo he probado con el eodFlag a 0 y a 1, con un \r en los datos, con un \n con un \n\r ….
    Es como si se perdiera el ACK de los datos enviados, pero llegar si que llegan siempre.

    Ya no se por donde seguir.

    Otra cosa que no acabo de entender, es porque en ningun ejemplo he visto AT^SICO (que ya perdi varios dias con esta tonteria), sin este comando no se establece una conexion con el APN :S

    PD: La documentacion de siemens es abundante….en numero de páginas, pero no te da la sensacion de que todo lo que lees le falta siempre algo? Lo dejan como para darle intriga xD Es que me he tenido que pelear (no hay otro verbo) con un control numerico y vaya tela me dio :S

  8. blogElectronica says:

    Lt_Henry,

    ¿Has probado realizar lo que intentas hacer con el programa java desde un hyperterminal? ¿Cómo estás haciendo el programa java? ¿no estarás dando vueltas en un while cerrado “en el main” sin un Thread.sleep sin dar opción a que salte el URC?

    Por otro lado, AT^SICO no es necesario para ninguna conexión con el APN y no te hace falta para nada para abrir una sesión GPRS. Cuando haces un SISO ya realiza, en ese momento, la conexión con el APN, es decir, ya se inicia la sesión gprs y después se abre el socket automáticamente. SICO se utiliza para que no te cierre la sesión GPRS cuando no hay un servicio (socket) abierto al cabo del tiempo espedificado en inactTO como ocurre con SISO. En los ejemplos no hace falta y por eso no se ha puesto.

    Salu2

  9. Lt_Henry says:

    Que raro lo del SICO…seria una coincidencia pues. Volviendo al otro tema. El programa ahora mismo no tiene bucle alguno, simplemente abre conexion, socket, envia un par de datos y luego cierra. Para esperar el SISW al principio le meti 60 segundos entre el primer envio y el segundo, pero al no ser suficientes, en mi funcion escribeSocket hice una espera para no poder mandar nada hasta que no llegue el evento SISW: 0,1 y ahora, pues se queda enganchado ahi, porque eso no sucede nunca. (solo la primera vez al hacer el SISO). La verdad es que no he probado ha lanzarlo a mano desde el hyperterminal, creo que es lo siguiente que deberia probar, pero lo que si te puedo decir es que ni SISO ni SISW devuelven un error. :\

    Me estaba preguntando si no es algo de la operadora, que en este caso es SIMYO. No entiendo nada :\

  10. Lt_Henry says:

    He probado con esperas de hasta 60 segundos, y ahora mismo hay una espera en mi funcion escribeSocket que no realiza otro envio hasta recibir el anterior URC de SISW. Y como eso solo sucede una vez, el segundo envio no sucede nunca.

    No he probado a hacerlo a mano desde el hyperterminal, ciertamente es lo proximo que deberia de probar, no obstante ni SISO ni SISW devuelven un error y temo que sea algo de la operadora, porque no tiene sentido :\

    Esto se supone que deberia de funcionar !!!! :_C

  11. blogElectronica says:

    Hola Lt_Henry,

    como es navidad y hay que ser generosos , he dedicado un ratillo de mi primer día de vacaciones a prepararte un ejemplo java que realiza 2 envíos, uno detrás del otro. Lo acabo de probar y funciona correctamente.

    Te lo pongo aquí:
    http://www.blogelectronica.com/TEMP/EJEMPLO_ConexionTCP3.zip

    Te aseguro que funciona, primero envía “Hola” y después “Adios”.

    A ver que tal …

    Salu2 y felices fiestas.

  12. Pablo says:

    Tengo un problema, recibo 4 bytes que son byte[0] = -51, byte[1] = 18, byte [2] = 6 y byte[3] =77, pero el valor que obtengo depués de las operaciones no me da una fecha correcta, supongo que será por el valor negativo que recibo del primer byte. Qué hago mal? Estoy recibiendo mal los datos? Sólo recibo esos 4 bytes. Está mal la codificación? Utilizo para recibir los bytes un array declarado como byte [ ] bytes = new byte [ 4 ]. Qué hago mal?
    Gracias por anticipado

  13. Pablo says:

    Vale, ya me lo he resuelto solo, el problema, como sospechaba estaba en la codificación. El -51 del primer byte es en realidad 256-51, es decir, 205. El resto de bytes son correctos y al usar la fórmula sale la fecha correcta. Gracias por este fantástico tutorial.

  14. Nico says:

    He posteado una duda en el foro sobre sincronización horaria con la red GSM en lugar de vía internet…por si a alguien le interesa.

    http://www.blogelectronica.com/forum/tc65-xt65-mtx65-mtx65g/sobre-la-sincronizacion-horaria/#p23

    Saludos!

  15. Gen says:

    Hola,

    estoy utilizando un XT75 y me encuentro con un problema gordo. Al recibir una trama GPS comparo la hora recibida con la del sistema y si nos igual la actualizo con el comando at+cclk, pero cual es mi sorpresa que la hora del sistema no se actualiza hasta que reinicias el modem, y la coge del valor del RTC, por lo que las clases DAte y Calendar cogen la hora antigua.

    Como puedo hacer que la hora del sistema corresponda con la que grabo en el RTC con el comando at+cclk sin reiniciar el equipo?? La necesito para hacer sincronizaciones horarias en la aplicacion java si tener que apagar el modem.

    Gracias de antemano.

    Saludos

  16.  
Leave a Reply

Puedes publicar un comentario aquí si quieres, pero te recomiendo que uses el nuevo foroElectronica.com para introducir comentarios. Te contestaré más rápido. Recuerda que debes registrarte si no lo estás para publicar un comentario.