Comments on: C�mo obtener la hora con los terminales MTX y m�dems Siemens / Cinterion

By: Gen

Gen — Tue, 17 Aug 2010 20:07:45 +0000

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

By: Nico

Nico — Fri, 31 Jul 2009 07:36:47 +0000

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!

By: Pablo

Pablo — Fri, 09 Jan 2009 18:50:35 +0000

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.

By: Pablo

Pablo — Fri, 09 Jan 2009 17:32:56 +0000

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

By: blogElectronica

blogElectronica — Wed, 24 Dec 2008 10:47:50 +0000

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.

By: Lt_Henry

Lt_Henry — Sat, 20 Dec 2008 09:42:45 +0000

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

By: Lt_Henry

Lt_Henry — Sat, 20 Dec 2008 09:23:07 +0000

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

By: blogElectronica

blogElectronica — Fri, 19 Dec 2008 18:41:15 +0000

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

By: Lt_Henry

Lt_Henry — Fri, 19 Dec 2008 08:39:14 +0000

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

By: blogElectronica

blogElectronica — Thu, 18 Dec 2008 19:58:12 +0000

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.

By: blogElectronica

blogElectronica — Thu, 18 Dec 2008 19:56:49 +0000

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

By: Currumblera

Currumblera — Thu, 18 Dec 2008 19:47:08 +0000

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.

By: blogElectronica

blogElectronica — Thu, 18 Dec 2008 19:35:27 +0000

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.

By: Currumblera

Currumblera — Thu, 18 Dec 2008 19:07:53 +0000

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.

By: Lt_Henry

Lt_Henry — Thu, 18 Dec 2008 11:42:05 +0000

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?