ESCUELA POLITECNICA DEL EJ´ ERCITO´ - Repositorio de...

ESCUELA POLITECNICA DEL EJERCITO

DEPARTAMENTO DE ELECTRICA Y ELECTRONICA

CARRERA DE INGENIERIA EN ELECTRONICA YTELECOMUNICACIONES

PROYECTO DE GRADO PARA LA OBTENCION DELTITULO DE INGENIERIA

PROTOTIPO DE UNA TARJETA PARA EL CONTROL YLOCALIZACION VEHICULAR UTILIZANDO MENSAJES

SMS

EDGAR EDUARDO BENITEZ OLIVODIANA PAMELA MOYA OSORIO

SANGOLQUI - ECUADOR2008

CERTIFICACION

Certificamos que el presente proyecto de grado titulado ”PROTOTIPO DE UNA TAR-

JETA PARA EL CONTROL Y LOCALIZACION VEHICULAR UTILIZANDO MEN-

SAJES SMS” fue realizado en su totalidad por la senorita Diana Pamela Moya Osorio y

el senor Edgar Eduardo Benıtez Olivo, bajo nuestra direccion.

Ing. Gonzalo Olmedo Ing. Julio Larco

DIRECTOR CODIRECTOR

RESUMEN

El presente proyecto contempla el diseno e implementacion de un prototipo de una

tarjeta para el control y localizacion vehicular utilizando mensajes SMS, y el desarrollo de

una aplicacion en J2ME que sirva de interfaz grafica de administracion, entre el usuario

y la tarjeta.

La tarjeta dispone de cinco salidas, tres digitales y dos de potencia, con las que se

puede controlar el encendido o apagado de cualquier dispositivo o equipo conectado a la

misma. Ademas, incorpora cinco entradas, cuatro digitales y una analogica, en las que se

pueden conectar distintos tipos de sensores, para detectar sus respectivas variaciones.

El cerebro de los procesos que se llevan a cabo en la tarjeta se implemento en un

microcontrolador PIC, para lo cual se desarrollo un programa empleando el compilador

de C PCW de CCS Inc., de manera que permita controlar las salidas, sensar las entradas,

comunicarse con un modem GSM y con un modulo receptor GPS.

La comunicacion del microcontrolador con el modem GSM, el cual corresponde a un

telefono celular en desuso, se realizo a traves de comandos AT y tiene como objetivo la

recepcion y envıo de mensajes SMS; mientras que la comunicacion con el modulo receptor

GPS se implemento bajo las especificaciones del protocolo NMEA, para la obtencion de

la posicion geografica del vehıculo.

Finalmente, la aplicacion en J2ME, desarrollada empleando la herramienta Wireless

Toolkit de Sun, permite ejecutar las siguientes tareas: configuracion del sistema, control de

salidas, reporte del estado de entradas y salidas, requerimientos de posicion y temperatura,

ası como, recepcion de notificaciones de cambio de estado en las entradas.

DEDICATORIA

A mis amados padres Mariana y Oswaldo,

que han sido mi guıa todos los dıas de mi vida,

y a mis queridos hermanos Carolina y Enrique,

mis segundos padres.

Diana Moya O.

DEDICATORIA

A mis padres, Juan y Mary;

a mis hermanos, Jeanny, Mary y Juan Francisco;

a mi abuelita Zoilita y mi tıo Hector;

a mi abuelito Carlos...

...aunque no este entre nosotros,

tengo fe que esta guiandome en el camino.

Edgar Benıtez

AGRADECIMIENTO

Agradezco a Dios por brindarme la oportunidad de llevar una vida llena de felicidad

y tranquila rodeada de personas maravillosas.

A mis padres, por todo el amor que me han entregado a lo largo de mi vida, porque

gracias a su sacrificio, su paciencia y su dedicacion me permitieron llegar a culminar mis

estudios y por ser dos grandes ejemplos para mı y para mis hermanos.

A mis hermanos, Carolina y Enrique por cuidarme, apoyarme y por haber dejado sus

huellas en el camino y permitirme aprender de sus experiencias.

A los ingenieros Gonzalo Olmedo y Julio Larco por abrirnos las puertas y guiarnos en

la consecucion de este proyecto, y a todos aquellos maestros que no se limitaron en trans-

mitirnos conocimientos, sino que nos ensenaron a crecer como personas y nos alentaron a

seguir adelante.

A todos aquellos amigos y companeros que compartieron conmigo estos cinco anos

de estudio y fueron partıcipes de cada experiencia, gracias por permitirme aprender de

ustedes. De manera especial quiero agradecer a Edgar por ser un gran amigo en estos anos

y por haberme acompanado hasta terminar juntos nuestra carrera, gracias por ensenarme

tantas cosas y por ser un gran apoyo para mı.

Agradezco a todas aquellas personas que contribuyeron de una u otra forma en mi

vida y me ayudaron a crecer, a aprender y convertirme en la persona que soy.

Diana Moya O.

AGRADECIMIENTO

Que Dios nos de la sabidurıa para descubrir lo correcto, la voluntad para elegirlo y la

fuerza para hacer que perdure.

Agradezco a Dios todopoderoso; a mis padres, por la oportunidad de existir, por su

apoyo incondicional y los estımulos brindados con infinito amor, gracias a ellos ha sido

posible la culminacion de esta etapa de mi vida.

Quiero expresar tambien, un profundo agradecimiento a todos quienes colaboraron

en la consecucion de este objetivo, de manera especial a mis hermanos y familiares mas

cercanos, han sido un apoyo y aliento permanente. Por supuesto, a Diani y a su familia,

gracias por todos estos anos de amistad.

Quiero tambien extender mi agradecimiento, a traves de los ingenieros Gonzalo Olmedo

y Julio Larco, a mis maestros, porque ademas de construir solidos pilares en nuestra

formacion profesional han sabido enfatizar en nuestra formacion integral y de valores.

Gracias, sin duda el compromiso de seguir superandome, es grande...

Edgar Benıtez

PROLOGO

La red GSM, como tecnologıa de telefonıa movil, ha alcanzado una gran cobertura a

nivel mundial, principalmente gracias a sus ventajas comerciales y la oportunidad para el

desarrollo de aplicaciones que hacen uso de los servicios implementados sobre esta red.

El presente proyecto tiene como objetivo implementar un prototipo de una tarjeta para

el control y localizacion vehicular utilizando precisamente uno de los servicios basicos de

la red GSM, el servicio SMS, puesto que se penso en la ventaja que presenta al ser uno de

los mas utilizados entre los suscriptores de GSM y el bajo costo que implica esta vıa de

comunicacion. De esta manera, este prototipo pretende reducir los precios en comparacion

con otros productos similares basados en otras tecnologıas, por ejemplo GPRS, que tiene

mayor costo por datos transmitidos y no presenta cobertura en todo el paıs.

Otro objetivo de este proyecto fue el de reutilizar telefonos celulares descontinuados y

que han sido desechados, de los cuales es posible aprovechar el modem GSM que llevan

incorporado, logrando ası crear una alternativa mas economica para la implementacion

de este prototipo y realizar un reciclaje de equipos celulares.

Por otro lado, se ha pensado en un prototipo que dote al usuario de total facilidad

en su control y configuracion, para lo cual se desarrollo una interfaz grafica en J2ME,

totalmente amigable, que permita la interaccion con el usuario y lo guıe en el manejo del

sistema.

Este trabajo hace una revision teorica de los temas relacionados con las tecnologıas

que hace uso este prototipo, como son: el sistema GSM, el servicio SMS, el modem

GSM y los comandos AT, el sistema GPS, los microcontroladores PIC y los aspectos mas

relevantes del lenguaje J2ME. Posteriormente se describe la implementacion del hardware

y el desarrollo del software, este ultimo conformado por dos partes importantes que son:

el programa para el cerebro de la tarjeta constituido por un microcontrolador PIC y la

aplicacion en J2ME como interfaz grafica de usuario. Finalmente, se realizaron las pruebas

del prototipo para confirmar su correcto funcionamiento, a lo que se anade un manual de

usuario que sirva de orientacion en la utilizacion del mismo.

Contenido

1 INTRODUCCION A GSM 11.1 DESCRIPCION DEL CAPITULO . . . . . . . . . . . . . . . . . . . . . . 11.2 DEFINICION DE GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.3 ARQUITECTURA DE LA RED GSM . . . . . . . . . . . . . . . . . . . . 21.4 INTERFAZ DE RADIO Um . . . . . . . . . . . . . . . . . . . . . . . . . . 41.5 CARACTERISTICAS TECNICAS . . . . . . . . . . . . . . . . . . . . . . 41.6 SERVICIOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.6.1 Servicios basicos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.6.2 Servicios suplementarios . . . . . . . . . . . . . . . . . . . . . . . . 6

2 SERVICIO DE MENSAJES CORTOS 72.1 DESCRIPCION DEL CAPITULO . . . . . . . . . . . . . . . . . . . . . . 72.2 SERVICIO SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 FORMATOS DEL SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 ARQUITECTURA DE RED . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 NIVEL SM-TL Y PROTOCOLO SM-TP . . . . . . . . . . . . . . . . . . . 12

2.5.1 SMS-SUBMIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.5.2 SMS-DELIVER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.5.3 Cabecera de datos de usuario (UDH) y datos de usuario (UD) . . . 172.5.4 Direccionamiento de puertos de aplicacion . . . . . . . . . . . . . . 182.5.5 Ejemplo de trama SMS-SUBMIT . . . . . . . . . . . . . . . . . . . 20

3 MODEM GSM Y COMANDOS AT 223.1 DESCRIPCION DEL CAPITULO . . . . . . . . . . . . . . . . . . . . . . 223.2 MODEM GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 INTERFAZ CON MODEMS: COMANDOS AT . . . . . . . . . . . . . . . 233.4 INTERFAZ CON MODEMS GSM . . . . . . . . . . . . . . . . . . . . . . 25

3.4.1 Comandos AT+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 SISTEMA DE POSICIONAMIENTO GLOBAL 334.1 DESCRIPCION DEL CAPITULO . . . . . . . . . . . . . . . . . . . . . . 334.2 FUNCIONAMIENTO DEL SISTEMA GPS . . . . . . . . . . . . . . . . . 334.3 INTRODUCCION A LOS RECEPTORES GPS . . . . . . . . . . . . . . . 35

4.3.1 Tipos de receptores GPS . . . . . . . . . . . . . . . . . . . . . . . . 354.4 MODULO RECEPTOR SPK-GPS-GS405 . . . . . . . . . . . . . . . . . . 36

4.4.1 Introduccion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 364.4.2 Principales caracterısticas . . . . . . . . . . . . . . . . . . . . . . . 374.4.3 Especificaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.4.4 Asignacion y descripcion de pines . . . . . . . . . . . . . . . . . . . 374.4.5 Protocolo NMEA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5 MICROCONTROLADORES PIC 435.1 DESCRIPCION DEL CAPITULO . . . . . . . . . . . . . . . . . . . . . . 435.2 CARACTERISTICAS DE LOS MICROCONTROLADORES . . . . . . . 445.3 PIC16F877A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5.3.1 Caracterısticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.4 PROCESO DE DESARROLLO DE UNA APLICACION . . . . . . . . . . 46

5.4.1 Desarrollo del software . . . . . . . . . . . . . . . . . . . . . . . . . 465.4.2 Programacion del microcontrolador . . . . . . . . . . . . . . . . . . 485.4.3 Prueba y verificacion . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.5 COMPILADOR DE C PCW DE CCS . . . . . . . . . . . . . . . . . . . . 48

6 JAVA 2 MICRO EDITION 506.1 DESCRIPCION DEL CAPITULO . . . . . . . . . . . . . . . . . . . . . . 506.2 INTRODUCCION A LA PLATAFORMA JAVA . . . . . . . . . . . . . . . 506.3 INTRODUCCION A J2ME . . . . . . . . . . . . . . . . . . . . . . . . . . 526.4 ARQUITECTURA DE J2ME . . . . . . . . . . . . . . . . . . . . . . . . . 52

6.4.1 Maquinas virtuales en J2ME . . . . . . . . . . . . . . . . . . . . . . 526.4.2 Configuraciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.4.3 Perfiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

6.5 CONNECTED LIMITED DEVICE CONFIGURATION CLDC . . . . . . 556.6 MOBILE INFORMATION DEVICE PROFILE (MIDP) . . . . . . . . . . 566.7 MIDlets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59

6.7.1 Ciclo de vida de un MIDlet . . . . . . . . . . . . . . . . . . . . . . 606.7.2 Estados de un MIDlet durante la ejecucion . . . . . . . . . . . . . . 616.7.3 Estructura de un MIDlet . . . . . . . . . . . . . . . . . . . . . . . . 616.7.4 Etapas del proceso de desarrollo de un MIDlet . . . . . . . . . . . . 626.7.5 Creacion de MIDlets . . . . . . . . . . . . . . . . . . . . . . . . . . 63

6.8 INTERFAZ DE USUARIO DE MIDP . . . . . . . . . . . . . . . . . . . . 656.8.1 Clase Display . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.8.2 Clase Displayable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 656.8.3 Clases Command y CommandListener . . . . . . . . . . . . . . . . 67

6.9 INTERFAZ DE USUARIO DE ALTO NIVEL . . . . . . . . . . . . . . . . 676.10 INTERFAZ DE USUARIO DE BAJO NIVEL . . . . . . . . . . . . . . . . 71

6.10.1 Eventos de bajo nivel . . . . . . . . . . . . . . . . . . . . . . . . . . 716.10.2 Metodo paint() . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 726.10.3 Clase Graphics() . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

6.11 RECORD MANAGEMENT SYSTEM . . . . . . . . . . . . . . . . . . . . 736.12 WIRELESS MESSAGING API . . . . . . . . . . . . . . . . . . . . . . . . 736.13 EL API PUSH REGISTRY . . . . . . . . . . . . . . . . . . . . . . . . . . 75

6.13.1 Metodos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 756.13.2 Conexiones SMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

7 DISENO DEL PROTOTIPO 787.1 DESCRIPCION DEL CAPITULO . . . . . . . . . . . . . . . . . . . . . . 787.2 FUNCIONAMIENTO GENERAL DEL SCL . . . . . . . . . . . . . . . . . 787.3 HARDWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

7.3.1 Microcontrolador PIC16F877A . . . . . . . . . . . . . . . . . . . . 817.3.2 Modem GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 817.3.3 Receptor GPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 837.3.4 Entradas y salidas digitales . . . . . . . . . . . . . . . . . . . . . . 857.3.5 Entrada analogica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 867.3.6 Etapa de potencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 887.3.7 Sistema de alimentacion . . . . . . . . . . . . . . . . . . . . . . . . 887.3.8 Circuito implementado para la TCL . . . . . . . . . . . . . . . . . . 89

7.4 SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 897.4.1 Programa del microcontrolador PIC16F877A . . . . . . . . . . . . . 907.4.2 Aplicacion de administracion del SCL en J2ME . . . . . . . . . . . 107

7.5 COSTOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

8 PRUEBAS Y RESULTADOS 1238.1 DESCRIPCION DEL CAPITULO . . . . . . . . . . . . . . . . . . . . . . 1238.2 AUTENTICACION DEL USUARIO . . . . . . . . . . . . . . . . . . . . . 1248.3 PARAMETROS DE CONFIGURACION DEL SCL . . . . . . . . . . . . . 124

8.3.1 Configuracion del numero del sistema y clave de emergencia . . . . 1248.3.2 Configuracion de las etiquetas de entradas y salidas . . . . . . . . . 1258.3.3 Configuracion de la clave de la aplicacion Scl . . . . . . . . . . . . . 126

8.4 CONTROL DE SALIDAS DE LA TCL . . . . . . . . . . . . . . . . . . . . 1268.5 REPORTE DEL SISTEMA . . . . . . . . . . . . . . . . . . . . . . . . . . 1268.6 FUNCION DE LOCALIZACION . . . . . . . . . . . . . . . . . . . . . . . 1278.7 ENTRADA ANALOGICA . . . . . . . . . . . . . . . . . . . . . . . . . . . 1278.8 NOTIFICACION DE CAMBIO DE ESTADO DE LAS ENTRADAS . . . 127

9 CONCLUSIONES Y RECOMENDACIONES 1359.1 CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1359.2 RECOMENDACIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137

A GSM 7-bit Default Alphabet y codificacion de datos de 7 bits en octetos138A.1 GSM 7-bit Default Alphabet . . . . . . . . . . . . . . . . . . . . . . . . . . 138A.2 Codificacion de datos de 7 bits en octetos . . . . . . . . . . . . . . . . . . . 142

B Hoja de especificaciones del modulo receptor SPK-GPS-GS405 144

C Hoja de especificaciones del microcontrolador PIC16F877A 148

D Hoja de especificaciones del regulador LM317 152

E Hoja de especificaciones del regulador LM1117 154

F Codigo del programa del microcontrolador PIC16F877A 156

G Codigo de la aplicacion de administracion del SCL en J2ME 167G.1 Clase Scl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167G.2 Clase Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173G.3 Clase Fclave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181G.4 Clase Intro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183G.5 Clase Lconfiguracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186G.6 Clase Fcontrol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192G.7 Clase Fpeticion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193G.8 Clase Fnotificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194G.9 Clase GClocalizacionMapa . . . . . . . . . . . . . . . . . . . . . . . . . . . 199G.10 Clase FenvioSms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203G.11 Clase Fesperar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

H MANUAL DE USUARIO DEL SISTEMA DE CONTROL Y LOCAL-IZACION 207H.1 PARTES DEL DISPOSITIVO DE CONTROL . . . . . . . . . . . . . . . . 208

H.1.1 Cara frontal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208H.1.2 Cara posterior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208

H.2 CONSIDERACIONES DE FUNCIONAMIENTO . . . . . . . . . . . . . . 208H.3 CONEXION DE SALIDAS . . . . . . . . . . . . . . . . . . . . . . . . . . 210

H.3.1 Salidas digitales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210H.3.2 Salidas de potencia . . . . . . . . . . . . . . . . . . . . . . . . . . . 210

H.4 CONEXION DE ENTRADAS . . . . . . . . . . . . . . . . . . . . . . . . . 211H.4.1 Entradas digitales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211H.4.2 Entrada analogica . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211

H.5 APLICACION DE LA INTERFAZ DE USUARIO . . . . . . . . . . . . . 211H.5.1 Instalacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211H.5.2 Autenticacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212H.5.3 Configuracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212H.5.4 Control del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . 214H.5.5 Reporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214H.5.6 Localizacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215H.5.7 Temperatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215

Indice de Tablas

2.1 Valores del campo VPF. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Valores del campo MTI. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.3 Esquema de direccionamiento de puertos de aplicacion, direccion de 8 bits. 192.4 Rango de numeros de puerto, direcciones de 8 bits. . . . . . . . . . . . . . 192.5 Esquema de direccionamiento de puertos de aplicacion, direccion de 16 bits. 192.6 Rango de numeros de puerto, direcciones de 16 bits. . . . . . . . . . . . . . 202.7 Ejemplo de trama SMS-SUBMIT. . . . . . . . . . . . . . . . . . . . . . . . 21

3.1 Codigos de resultado relacionados con la operacion de comandos AT. . . . 243.2 Codigos de error del modem GSM. . . . . . . . . . . . . . . . . . . . . . . 253.3 Tipos de memoria de almacenamiento para SMS . . . . . . . . . . . . . . . 26

4.1 Especificaciones del modulo receptor SPK-GPS-GS405. . . . . . . . . . . . 384.2 Descripcion de pines del receptor SPK-GPS-GS405. . . . . . . . . . . . . . 394.3 Estructura del mensaje RMC. . . . . . . . . . . . . . . . . . . . . . . . . . 42

5.1 Caracterısticas del PIC16F877A. . . . . . . . . . . . . . . . . . . . . . . . 465.2 Archivos asociados al compilador de C PCW de CCS. . . . . . . . . . . . . 49

6.1 Librerıas de configuracion CLDC. . . . . . . . . . . . . . . . . . . . . . . . 566.2 Clases de sistema heredadas de J2SE. . . . . . . . . . . . . . . . . . . . . . 566.3 Clases de datos heredadas de J2SE. . . . . . . . . . . . . . . . . . . . . . . 576.4 Clases de utilidades heredadas de J2SE. . . . . . . . . . . . . . . . . . . . 576.5 Clases de E/S heredadas de J2SE. . . . . . . . . . . . . . . . . . . . . . . . 576.6 Clases e interfaces incluidos en el paquete javax.microedition.io . . . . . . . 586.7 Librerıas del perfil MIDP. . . . . . . . . . . . . . . . . . . . . . . . . . . . 596.8 Metodos de la clase Display. . . . . . . . . . . . . . . . . . . . . . . . . . . 656.9 Metodos de la clase Displayable. . . . . . . . . . . . . . . . . . . . . . . . . 666.10 Tipos de los objetos Command. . . . . . . . . . . . . . . . . . . . . . . . . 676.11 Metodos de la clase Form. . . . . . . . . . . . . . . . . . . . . . . . . . . . 696.12 Clases en javax.wireless.messaging. . . . . . . . . . . . . . . . . . . . . . . 746.13 Puertos reservados que no deben usarse para registrar una conexion SMS. . 77

7.1 Descripcion de la asignacion de pines del microcontrolador PIC. . . . . . . 827.2 Descripcion de pines del puerto del telefono Sony Ericsson T290a. . . . . . 847.3 Codigos utilizados en los mensajes enviados desde la aplicacion J2ME al

modem GSM de la TCL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

7.4 Codigos utilizados en los mensajes enviados desde el modem GSM a laaplicacion J2ME del usuario. . . . . . . . . . . . . . . . . . . . . . . . . . . 102

7.5 Detalle de costos del SCL. . . . . . . . . . . . . . . . . . . . . . . . . . . . 122

Indice de Figuras

1.1 Arquitectura de la red GSM. . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Trama TDMA y slots. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Servicio SMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Envıo de un SMS entre una MS y una entidad fija. . . . . . . . . . . . . . 82.3 Servicios basicos SM MT y SM MO. . . . . . . . . . . . . . . . . . . . . . 102.4 Estructura basica de la red para la transferencia de mensajes cortos. . . . . 112.5 Niveles y servicios para el envıo de mensajes cortos. . . . . . . . . . . . . . 122.6 Las 6 PDUs del protocolo SM-TP. . . . . . . . . . . . . . . . . . . . . . . . 132.7 Trama SMS-SUBMIT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.8 Detalle del campo SCA. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.9 Trama SMS-DELIVER. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.10 Estructura del campo UD. . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.1 Esquema logico de la conexion del modem GSM . . . . . . . . . . . . . . . 233.2 Ejecucion del comando CPMS en un modem GSM . . . . . . . . . . . . . . 273.3 Ejecucion del comando CMGF en un modem GSM . . . . . . . . . . . . . 283.4 Ejecucion del comando CMGR en un modem GSM . . . . . . . . . . . . . 293.5 Ejecucion del comando CMGL en un modem GSM . . . . . . . . . . . . . 303.6 Envıo del mensaje ”ESPE-DEEE” a traves del comando CMGS en modo

texto y modo PDU. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.7 Ejecucion del comando CMGD en un modem GSM . . . . . . . . . . . . . 32

4.1 Funcionamiento del sistema GPS. . . . . . . . . . . . . . . . . . . . . . . . 344.2 Modulo receptor SPK-GPS-GS405. . . . . . . . . . . . . . . . . . . . . . . 364.3 Asignacion de pines del receptor SPK-GPS-GS405. . . . . . . . . . . . . . 404.4 Estructura del mensaje NMEA. . . . . . . . . . . . . . . . . . . . . . . . . 41

5.1 Pines del PIC16F877A. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 455.2 Etapas del desarrollo de software. . . . . . . . . . . . . . . . . . . . . . . . 47

6.1 Arquitectura de la plataforma Java 2 de Sun. . . . . . . . . . . . . . . . . 516.2 Arquitectura del entorno de ejecucion J2ME. . . . . . . . . . . . . . . . . . 536.3 Ciclo de vida de un MIDlet. . . . . . . . . . . . . . . . . . . . . . . . . . . 606.4 Estados de un MIDlet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 626.5 Creacion de un nuevo proyecto con el J2ME Wireless Toolkit . . . . . . . . 646.6 Jerarquıa de clases derivadas de Display e Item. . . . . . . . . . . . . . . . 66

7.1 Diagrama de bloques del SCL. . . . . . . . . . . . . . . . . . . . . . . . . . 797.2 Distribucion de pines del microcontrolador PIC. . . . . . . . . . . . . . . . 817.3 Conexion entre el modem GSM del celular y el microcontrolador PIC. . . . 837.4 Telefono Sony Ericsson T290a. . . . . . . . . . . . . . . . . . . . . . . . . . 847.5 Conexion entre el modulo receptor GPS y el microcontrolador PIC. . . . . 857.6 Sensor de temperatura LM35DZ. . . . . . . . . . . . . . . . . . . . . . . . 877.7 Circuito implementado para la etapa de potencia de la salida 5. . . . . . . 897.8 Sistema de alimentacion de la TCL. . . . . . . . . . . . . . . . . . . . . . . 907.9 Circuito esquematico de la TCL. . . . . . . . . . . . . . . . . . . . . . . . . 917.10 Vista superior de la placa de circuito impreso de la TCL. . . . . . . . . . . 927.11 Pistas de la placa de circuito impreso de la TCL. . . . . . . . . . . . . . . 927.12 Circuito implementado de la TCL. . . . . . . . . . . . . . . . . . . . . . . 937.13 Diagrama de flujo del programa del Microcontrolador PIC (I). . . . . . . . 957.14 Diagrama de flujo del programa del Microcontrolador PIC (II). . . . . . . . 967.15 Diagrama de flujo del programa del Microcontrolador PIC (III). . . . . . . 977.16 Diagrama de flujo de la interrupcion por cambio en el nibble mas alto del

Puerto B. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 987.17 Diagrama de clases de la aplicacion en J2ME. . . . . . . . . . . . . . . . . 1097.18 Menu principal de la aplicacion. . . . . . . . . . . . . . . . . . . . . . . . . 1117.19 Formularios para la autenticacion de usuario. . . . . . . . . . . . . . . . . . 1127.20 Animacion de inicio de la aplicacion. . . . . . . . . . . . . . . . . . . . . . 1137.21 Menu para configuracion del SCL. . . . . . . . . . . . . . . . . . . . . . . . 1147.22 Formularios de las opciones de configuracion. . . . . . . . . . . . . . . . . . 1157.23 Formulario FenvioSms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1177.24 Formulario para el control de salidas. . . . . . . . . . . . . . . . . . . . . . 1187.25 Formularios para realizar peticiones a la TCL. . . . . . . . . . . . . . . . . 1197.26 Archivo .map con las equivalencias entre puntos del mapa y su posicion

geografica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120

8.1 Telefono Nokia N95. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1238.2 Ejecucion de la aplicacion Java Scl.jar. . . . . . . . . . . . . . . . . . . . . 1248.3 Formularios para autenticacion del usuario. . . . . . . . . . . . . . . . . . . 1258.4 Formulario con las opciones de configuracion del SCL. . . . . . . . . . . . . 1268.5 Configuracion del numero del sistema y la clave de emergencia. . . . . . . . 1278.6 Confirmacion de configuracion enviado desde la TCL. . . . . . . . . . . . . 1288.7 Configuracion de etiquetas de las entradas y salidas de la TCL. . . . . . . . 1298.8 Modificacion de la clave de autenticacion de usuario. . . . . . . . . . . . . 1298.9 Formulario de control de salidas de la TCL. . . . . . . . . . . . . . . . . . 1308.10 Control de salidas y reporte de la TCL. . . . . . . . . . . . . . . . . . . . . 1318.11 Reporte del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1328.12 Funcion de localizacion del sistema. . . . . . . . . . . . . . . . . . . . . . . 1338.13 Reporte de temperatura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1348.14 Notificacion de cambio de estado de las entradas. . . . . . . . . . . . . . . 134

H.1 Sistema de Control y Localizacion. . . . . . . . . . . . . . . . . . . . . . . 207

H.2 Partes de la cara frontal. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209H.3 Partes de la cara posterior. . . . . . . . . . . . . . . . . . . . . . . . . . . . 209H.4 Ejemplo de conexion de una salida de potencia. . . . . . . . . . . . . . . . 211H.5 Ejemplo de conexion de la entrada analogica. . . . . . . . . . . . . . . . . . 212H.6 Menu Principal de la aplicacion Scl. . . . . . . . . . . . . . . . . . . . . . . 213

GLOSARIO

AMS: Application Management Software

API: Application Programming Interface

AuC: Authentication Center

BSC: Base Station Controller

BSS: Base Station Subsystem

BTS: Base Transceiver Station

CAN: Controller Area Network

CDC: Connected Device Configuration

CLDC: Connected Limited Device Configuration

DA: Destination Address

DCS: Data Coding Scheme

DTMF: Dual Tone Multifrequency

EEPROM: Electrically Erasable/Programable ROM

EIR: Equipment Identity Registry

EMS: Enhanced Messaging Service

ETSI: European Telecommunications Standards Institute

FDD: Frequency Division Duplex

FDMA: Frequency Division Multiple Access

GGA: Global Positioning System Fix Data

GIF: Graphics Interchange Format

GIMP: GNU Image Manipulation Program

GMSK: Gaussian Minimum Shift Keying

GPS: Global Positioning System

GSA: GNSS DOP and Active Satellites

GSM: Global System for Mobile Communication

GSV: GNSS Satellites in View

HLR: Home Location Register

I2C: Inter-Integrated Circuit

IANA: Internet Assigned Numbers Authority

ICANN: Internet Corporation for Assigned Names and Numbers

IMEI: International Mobile Equipment Identity

J2EE: Java 2 Enterprise Edition

J2ME: Java 2 Micro Edition

J2SE: Java 2 Stantard Edition

JAD: Java Application Descriptor

JAR: Java Archive

JNI: Java Native Interface

JVM: Java Virtual Machine

KVM: Kilobyte Java Virtual Machine

MIDP: Mobile Information Device Profile

MR: Message Reference

MS: Mobile Station

MSC: Mobile Services Switching Center

MTI: Message Type Indicator

NMEA: National Marine Electronics Association

NSS: Network and Switching Subsystem

OEM: Original Equipment Manufacturer

OMC: Operations and Maintenance Center

OTA: Over the Air

PDU: Protocol Data Unit

PID: Protocol Identifier

PLMN: Public Land Mobile Network

PWM: Pulse Width Modulation

RAM: Random Access Memory

RD: Reject Duplicates

RISC: Reduced Instruction Set Computer

RMC: Recommended Minimum Specific GNSS Data

RMS: Record Management System

ROM: Read Only Memory

RP: Reply Path

RPE-LPT: Regular Pulse Excitation-Long Term Prediction

RTC: Real Time Clock

SCA: Service Center Address

SCTS: Service Center Time Stamp

SIM: Subscriber Identity Module

SM-AL: Short Message Aplication Layer

SME: Short Messaging Entity

SM MO: Short Message Mobile Originated Point-to-Point

SM MT: Short Message Mobile Terminated Point-to-Point

SMS: Short Message Service

SMSC: Short Message Service Center

SMS-GMSC: Gateway MSC for Short Message Service

SMS-IWMSC: Interworking MSC for Short Message Service

SM-LL: Short Message Lower Layers

SM-RL: Short Message Relay Layer

SM-TL: Short Message Transfer Layer

SPI: Serial Peripheral Interfaces

SRI: Status Report Indication

SRR: Status Report Request

TDMA: Time Division Multiple Access

TPDU: Transfer Protocol Data Unit

UART: Universal Asynchronous Receiver/Transmitter

UD: User Data

UDH: User Data Header

UDHI: User Data Header Indicator

UDHL: User Data Header Length

UDL: User Data Length

USB: Universal Serial Bus

VLR: Visitor Location Register

VP: Validity Period

VPF: Validity Period Format

WMA: Wireless Messaging API

INTRODUCCION A GSM 1

CAPITULO 1

INTRODUCCION A GSM

1.1 DESCRIPCION DEL CAPITULO

Este capıtulo provee una introduccion al sistema GSM (Global System for Mobile Commu-

nication), el cual constituye uno de los principales avances en el campo de las redes

moviles digitales, siendo en la actualidad la tecnologıa mas ampliamente utilizada del

mundo con mas de 3 mil millones de abonados, representando el 81,2% de participacion

en el mercado en cuanto a las suscripciones inalambricas digitales globales [1]. GSM es

una norma abierta, que permite que cualquier fabricante produzca equipos compatibles.

Esto trae aparejados algunos beneficios, entre ellos, las oportunidades que brinda para los

desarrolladores de aplicaciones.

A continuacion se describiran brevemente los conceptos basicos del sistema GSM,

especificaciones, arquitectura de red subyacente y servicios, que seran el preambulo para

detallar en el siguiente capıtulo el Servicio de Mensajes Cortos (SMS), en el cual se basa

el presente proyecto.

1.2 DEFINICION DE GSM

GSM es un estandar globalmente aceptado para comunicaciones celulares digitales. GSM

es el nombre de un grupo de estandarizacion establecido en 1982 para la creacion de

un estandar comun de telefonıa movil europeo que formularıa especificaciones para un

sistema movil celular de radio que opere a 900 MHz [2]. En 1989 la responsabilidad

del GSM se traslado al ETSI (European Telecommunications Standards Institute) y las

primeras especificaciones se publicaron en 1990. El GSM comenzo su servicio de forma

comercial a mediados de 1991, y en 1993 ya habıa 36 redes GSM en 22 paıses. Actualmente


cuenta con mas de 3 mil millones de suscriptores en todo el mundo y esta disponible en

220 paıses.

1.3 ARQUITECTURA DE LA RED GSM

GSM provee recomendaciones, no requerimientos. Las especificaciones GSM definen las

funciones y los requisitos de la interfaz en detalle, pero no dicen nada respecto al hardware.

La razon de esto, es limitar lo menos posible a los disenadores y en cambio permitir a los

operadores de telefonıa celular comprar equipos de diferentes proveedores.

En la Figura 1.1 se muestra de manera resumida la arquitectura de la red GSM. Esta

arquitectura es mas compleja y dispone de mas elementos que los presentados en esta

figura. El objetivo de este proyecto es describir el servicio SMS a nivel de aplicacion, sin

entrar en demasiados detalles de la red subyacente.

La arquitectura GSM esta constituida por cuatro partes:

1. Estacion movil (MS, Mobile Station). Consta del equipo movil (terminal) y una

smart card llamada SIM (Subscriber Identity Module). El SIM es el que permite la

movilidad, ası el usuario con dicha tarjeta puede acceder a la red desde cualquier

terminal. El terminal se identifica de forma inequıvoca mediante el IMEI (Interna-

tional Mobile Equipment Identity).

La MS y la estacion base (BTS) se comunican a traves de la interfaz Um1, a la que

tambien se le conoce como Interfaz aire.

2. Subsistema de estaciones base (BSS, Base Station Subsystem). Esta constituido

por los siguientes elementos:

(a) BTS (Base Transceiver Station): emisor, receptor y antena. Procesa los

canales de radio (Interfaz Um).

(b) BSC (Base Station Controller): Handover, control de las BTS, mapeo de

canales de radio sobre los canales terrestres. Por un lado se comunica con

1Interfaz Um es la interfaz de red GSM, localizada entre la MS y la BTS, que sirve para proveerservicios de voz y datos sobre la interfaz de radio a la MS.


SIM

ME

BTS

BTS

BSC

BSCHLR VLR

MSC

EIR AuC

PSTN

Um Abis A

Movil Subsistema de estacion base Subsistema de red

SIM: Modulo Identificador del Cliente.MSC: Centro de Conmutacion de Moviles.HLR: Registro de Localizacion de Clientes.BTS: Estacion Base Transceptora.AuC: Centro de Autenticacion.

BSC: Controlador de Estacion Base.ME: Equipo Movil.EIR: Registro de Identificacion de Moviles.VLR: Registro de Localizacion de Visitantes.

Figura 1.1: Arquitectura de la red GSM.

las BTS a traves de la interfaz Abis, con canales de 16 kbps y por otro lado se

comunica con los MSC a traves de la interfaz A, con canales de 64 kbps.

Este subsistema hace de interfaz entre la estacion movil y la parte de red.

3. Subsistema de red y conmutacion (NSS, Network and Switching Subsystem).

Conmutacion, gestion de la movilidad, interconexion con otras redes y control del

sistema. Esta es la parte mas compleja, siendo sus elementos principales los si-

guientes:

(a) MSC (Mobile Services Switching Center): centro de conmutacion, entre otras

muchas funciones.

(b) Bases de datos:

i. HLR (Home Location Register)

ii. VLR (Visitor Location Register)

iii. EIR (Equipment Identity Registry)

iv. AuC (Authentication Center)

4. Centro de mantenimiento y operaciones (OMC, Operations and Maintenance

Center).Controla la operacion del sistema y la inicializacion de la red.


Trama TDMA 4.615 ms

1 2 3 4 5 6 7 8

Slot

577µs

Figura 1.2: Trama TDMA y slots.

1.4 INTERFAZ DE RADIO Um

Para la transmision de bits entre la BTS y una MS se utilizan canales fısicos, caracterizados

por un slot y una portadora. Dentro de cada portadora se multiplexan en el tiempo 8

ranuras, formando una trama TDMA como la que se muestra en la Figura 1.2.

A un nivel superior, los canales fısicos se dividen en:

• Canales de trafico: llevan la voz y/o los datos.

• Canales de control: senalizacion y senales de control.

Los canales de trafico pueden ser de 2,4, 4,8 o 9,6 kbps. Para el servicio SMS se

utilizan canales de control.

1.5 CARACTERISTICAS TECNICAS

Las bandas de frecuencia designadas por la UIT (International Telecommunication Union)

para la operacion de GSM en la mayor parte del mundo, incluyendo Europa, Medio


Oriente, Africa y gran parte de Asia, son de 900 MHz y 1800 MHz. Algunos paıses en

America, incluyendo Ecuador, usan las bandas de 850 MHz y 1900 MHz.

Las principales caracterısticas del GSM son:

• Utiliza dos bandas de 25 MHz para la transmision y recepcion de informacion em-

pleando FDD2.

GSM 850 utiliza la banda de 824-849 MHz para el uplink y la banda de 869-894

MHz para el downlink.

• El acceso al medio se realiza mediante TDMA/FDMA (Time Division Multiple

Access/Frequency Division Multiple Access).

• Tiene 124 canales, y cada canal puede dar servicio a 8 o 16 usuarios a la vez.

• Ancho de banda del canal 200 kHz.

• La modulacion empleada es GMSK (Gaussian Minimum Shift Keying).

• La velocidad maxima del canal de radio es 270.833 kbps.

• Duracion de un bit de 3,692 msec.

• La longitud de una trama es de 4,615 msec, y la longitud de un slot de tiempo 577

µsec.

• Codificacion de la voz: RPE-LPT 13 kbps (Regular Pulse Excitation-Long Term

Prediction). Informacion mas detallada respecto a la codificacion de la voz en GSM

se puede encontrar en [3].

• Potencia de salida de 20 mW a 20W.

2FDD (Frequency Division Duplex ) es una tecnica mediante la cual se asigna a la comunicacion dosfrecuencias portadoras, una para transmitir informacion desde la MS a la BTS (uplink) y otra para recibirinformacion en la otra direccion (downlink).


1.6 SERVICIOS

1.6.1 Servicios basicos

Hay dos tipos basicos de servicios que se pueden ofrecer a traves de GSM: telefonıa (tele-

servicios) y datos (servicios portadores). Los servicios de telefonıa son principalmente

servicios de voz que proveen a los suscriptores la capacidad total (incluyendo el equipo ter-

minal necesario) para comunicarse con otros suscriptores. Los servicios de datos proveen

la capacidad necesaria para transmitir datos entre dos puntos de acceso, creando una

interfaz de red. Ademas de la telefonıa normal y llamadas de emergencia, GSM tambien

soporta los siguientes servicios de suscriptor:

• DTMF (Dual-tone multifrequency)

• Fax

• SMS (Short Message Service)

• Buzon de voz

1.6.2 Servicios suplementarios

GSM soporta un amplio conjunto de servicios suplementarios que pueden complementar a

los servicios de telefonıa y datos. A continuacion se listan algunos servicios suplementarios:

• Transferencia de llamada

• Llamada en espera

• Conferencia

• Bloqueo llamadas salientes

• Bloqueo llamadas entrantes

• Facturacion detallada

• Marcacion abreviada.

• Identificacion de llamadas

SERVICIO DE MENSAJES CORTOS 7

CAPITULO 2

SERVICIO DE MENSAJES CORTOS


En este capıtulo se describe el servicio SMS (Short Message Service) ası como la arquitec-

tura de red subyacente, los protocolos empleados y los formatos de SMS, centrandose en

la estructura de las tramas PDU (Protocol Data Unit), particularmente en la cabecera de

los datos de usuario. En este campo de la trama se puede enviar informacion de control

adicional al mensaje, lo cual abre un abanico de funcionalidades que pueden ser imple-

mentadas bajo el servicio SMS. Se revisara entonces el direccionamiento del mensaje hacia

puertos de aplicacion en la estacion movil receptora, una caracterıstica que es de especial

interes en la realizacion del presente proyecto.

En [4] se puede encontrar un estudio completo acerca de las tecnologıas y servicios de

la mensajerıa movil celular, y en [5] informacion especıfica referente al SMS y el formato

PDU.

2.2 SERVICIO SMS

El servicio SMS permite transferir un mensaje de texto entre una MS y otra entidad

denominada SME (Short Messaging Entity) a traves de un centro de servicio SMSC

(Short Message Service Center) como se muestra en la Figura 2.1.

El servicio final ofrecido es una comunicacion extremo-extremo entre la MS y la entidad

SME. La entidad puede ser otra MS o puede estar situada en una red fija. En el caso de

envıo de un mensaje entre dos moviles, ambas partes son estaciones moviles. Cuando se

envıa un mensaje para solicitar algun tipo de servicio, un extremo es una MS y la otra es

un servidor que atiende las peticiones.


MS

SME

SMSC

Figura 2.1: Servicio SMS.

MS SMESMSC

Normalizado por GSM Fuera del ambito de GSM

Figura 2.2: Envıo de un SMS entre una MS y una entidad fija.

En la norma GSM solo se especifica la parte de comunicaciones entre las MS y el

SMSC. La comunicacion entre el SMSC y las entidades fijas, queda fuera del ambito de

esta norma como se presenta en la Figura 2.2.

El mensaje SMS, como especifica la ETSI en los documentos GSM 03.40 y GSM 03.38,

puede tener hasta 160 caracteres de longitud, donde cada caracter es codificado con 7 bits

de acuerdo a un alfabeto especial denominado Alfabeto de 7 bits. (ver Apendice A, GSM 7

bit Default Alphabet y codificacion de datos de 7 bits en octetos). Los mensajes codificados

con 8 bits (maximo 140 caracteres) usualmente no son interpretados por los telefonos

celulares como mensajes de texto, mas bien, son usados para transmitir datos, por ejemplo,

imagenes de baja resolucion y ringtones monofonicos. Los mensajes codificados con 16


bits (maximo 70 caracteres) son usados para mensajes de texto Unicode1 (UCS2), los

cuales son interpretados por la mayorıa de telefonos celulares.

El servicio SMS se divide en dos servicios basicos que son mostrados en la Figura 2.3

y explicados a continuacion:

1. SM MT (Short Message Mobile Terminated Point-to-Point). Servicio de entrega

de un mensaje desde el SMSC hasta una MS, obteniendose un informe sobre lo

ocurrido.

2. SM MO (Short Message Mobile Originated Point-to-Point). Servicio de envıo de un

mensaje desde una MS hasta un SMSC, obteniendose un informe sobre lo ocurrido.

2.3 FORMATOS DEL SMS

Hay dos maneras de enviar y recibir mensajes SMS definidos a continuacion:

• El modo texto. Se encuentra disponible solo en algunos tipos de terminales,

normalmente de gama media o alta y su codificacion es relativamente sencilla. Esta

definido dentro de las redes de telefonıa movil GSM 850, 900, 1800 y 1900.

Los mensajes pueden estar conformados por caracteres de texto, numeros y sımbolos

especiales.

• El modo PDU. La estructura dentro de la cual viaja un SMS se le denomina

PDU la cual ademas de llevar la informacion propia del mensaje de texto, lleva otra

serie de caracteres con los que se pueden hacer algunas funciones de control en la

presentacion del mensaje.

Una de las principales ventajas que este modo presenta, es que el mensaje antes de

ser enviado a la red debe pasar por un algoritmo, el cual hace una codificacion a

nivel de bits con lo que si el mensaje se intenta leer no podra ser interpretado a

primera vista.

1Unicode es un conjunto de caracteres alfanumericos desarrollado para sustituir al codigo ASCII.Unicode se creo para poder representar todos los caracteres existentes, empleando para ello codificacionesen 16 bits, lo que permite el uso de 65.536 caracteres diferentes, en lugar de los 256 que ofrecıa el codigoASCII (en 8 bits).


MS MS

SMS

(a) Servicio SMS entre dos MS

MS SMSC

Envıo de mensaje

Informe

(b) Servicio SM MO

MSSMSC

Entrega de mensaje

Informe

(c) Servicio SM MT

Figura 2.3: Servicios basicos SM MT y SM MO.


SMSC

SMS-GMSC

SMS-IWMSC MSC

MS

HLR VLR

Figura 2.4: Estructura basica de la red para la transferencia de mensajes cortos.

2.4 ARQUITECTURA DE RED

La estructura basica de la red para el servicio SMS se muestra en la Figura 2.4. Las

entidades involucradas son las siguientes:

• MS. Estacion movil

• MSC. Centro de conmutacion

• SMS-GMSC (Gateway MSC for Short Message Service). MSC gateway para el

servicio de mensajes cortos (Servicio SM MT).

• SMS-IWMSC (Interworking MSC for Short Message Service). MSC de inter-

conexion entre la PLMN2 y el SMSC (Servicio SM MO).

• SMSC. Centro de servicio

• HLR, VLR

2En Telecomunicaciones, una PLMN (Public Land Mobile Network) es una red que es implementaday operada por una administracion o por una agencia de operacion reconocida (ROA) con la finalidad deproveer al publico servicios de telecomunicaciones moviles terrestres.


SME

SMSC

SMS-GMSC

SMS-IWMSC MSC MS

SM-AL

SM-TL

SM-RL

SM-LL

Figura 2.5: Niveles y servicios para el envıo de mensajes cortos.

Para la descripcion detallada de la arquitectura, se utiliza un modelo de capas, en

el que cada capa o nivel proporciona un servicio a la capa superior, y este servicio se

implementa mediante el protocolo correspondiente. La arquitectura se divide en 4 capas

como se muestra en la Figura 2.5:

• SM-AL (Short Message Aplication Layer). Nivel de aplicacion.

• SM-TL (Short Message Transfer Layer). Nivel de transferencia. Servicio de trans-

ferencia de un mensaje corto entre una MS y un SMSC (en ambos sentidos) y

obtencion de los correspondientes informes sobre el resultado de la transmision.

• SM-RL (Short Message Relay Layer). Nivel de retransmision. Proporciona un

servicio al nivel de transferencia que le permite enviar TPDU (Transfer Protocol

Data Units) a su entidad gemela.

• SM-LL (Short Message Lower Layers). Niveles inferiores.

2.5 NIVEL SM-TL Y PROTOCOLO SM-TP

Cada capa proporciona los servicios a la capa superior utilizando un protocolo. Se definen

los protocolos SM-TP y SM-RP, que se corresponden con las capas SM-TL y SM-RL. El


SMSC

SMSC

SMSC

MS

MS

MS

SMS-DELIVER

SMS-DELIVER-REPORT

SMS-SUBMIT

SMS-SUBMIT-REPORT

SMS-COMMAND

SMS-STATUS-REPORT

Figura 2.6: Las 6 PDUs del protocolo SM-TP.

nivel de interes para el presente proyecto es el SM-TL, que es el que se usara para enviar

y recibir SMS.

El servicio proporcionado por la capa SM-TL permite al nivel de aplicacion enviar

mensajes a su entidad gemela, recibir mensajes de ella ası como obtener informes sobre

el estado de transmisiones anteriores.

Se utilizan las siguientes 6 PDUs mostradas en la Figura 2.6:

• SMS-DELIVER. Transmitir un mensaje desde el SMSC al MS.

• SMS-DELIVER-REPORT. Error en la entrega (si existiera).

• SMS-SUBMIT. Trasmitir un mensaje corto desde el MS al SMSC.

• SMS-SUBMIT-REPORT. Error en la transmision (si existiera).


1-12

1

11111 2-12 1-7 0-160

SCA PDU-TYPE MR DA PID DCS VP UDL UD

RP UDHI SRR VPFVPF RD MTIMTI

bits

Bytes

0234567

Figura 2.7: Trama SMS-SUBMIT.

• SMS-STATUS-REPORT. Transmitir un informe de estado desde el SMSC al

MS.

• SMS-COMMAND. Transmitir un comando desde el MS al SMSC.

2.5.1 SMS-SUBMIT

La estructura de la PDU SMS-SUBMIT se muestra en la Figura 2.7. Los campos que la

componen son los siguientes:

• SCA (Service Center Address). Numero de telefono del Centro de Servicio de

Mensajes Cortos (SMSC). La estructura detallada se muestra en la Figura 2.8.

Consta de los siguientes campos:

– Longitud. Numero de dıgitos del telefono del SMSC.

– Tipo de numero. Indica si se trata de un numero nacional o internacional.

∗ 81h: nacional

∗ 91h: internacional

– Dıgitos BCD. Numero de telefono del SMSC, en dıgitos BCD.

• PDU TYPE. Contiene informacion sobre el tipo de PDU. Su estructura es la

siguiente:

– RP (Reply Path). Existe camino de respuesta. RP=0 en tramas de tipo SMS-

SUBMIT.


SCA

1 0-1 0-6Bytes

LONGITUD TIPO DE NUMERO TELEFONO

Digito 1Digito 2 Digito 3Digito 4

1 Byte1 Byte

...

Figura 2.8: Detalle del campo SCA.

bit 4 bit 3 Descripcion

0 0 Campo VP ausente0 1 Campo VP presente. Formato relativo (1 octeto)1 0 Campo VP presente. Formato mejorado (7 octetos)1 1 Campo VP presente. Formato absoluto (7 octetos)

Tabla 2.1: Valores del campo VPF.

– UDHI (User Data Header Indicator). Indica si el campo UD (User Data)

contiene solo el mensaje corto (UDHI=0) o si existe una cabecera antes del

mensaje corto (UDHI=1).

– SRR (Status Report Request). Informe de estado no solicitado (SRR=0) o sı

solicitado (SRR=1).

– VPF (Validity Period Format). Indica si el campo VP (Validity Period) esta o

no presente. Los valores que puede tomar este campo se muestran en la Tabla

2.1.

– RD (Reject Duplicates). Rechazar o no duplicados.

– MTI (Message Type Indicator). Tipo de mensaje. Los valores que puede tomar

este campo se muestran en la Tabla 2.2.

• MR (Message Reference). Parametro para identificar el mensaje.


bit 1 bit 0 Descripcion

0 0 SMS-DELIVER0 0 SMS-DELIVER-REPORT0 1 SMS-SUBMIT0 1 SMS-SUBMIT-REPORT1 0 SMS-STATUS-REPORT1 0 SMS-COMMAND1 1 Reservado

Tabla 2.2: Valores del campo MTI.

• DA (Destination Address). Direccion del SME de destino (numero de telefono).

Consta de los siguientes campos:

– Longitud. Numero de dıgitos del telefono del SME.

– Tipo de numero. Al igual que en el caso del numero del SMSC, indica si se

trata de un numero nacional o internacional.

– Dıgitos BCD. Numero de telefono del SME, en dıgitos BCD.

• PID (Protocol Identifier). Identificacion del protocolo de capa superior.

• DCS (Data Coding Scheme). Identificacion del tipo de codificacion dentro de los

datos de usuario.

• VP (Validity Period). Periodo de validez del mensaje.

• UDL (User Data Length). Longitud del campo UD.

• UD (User Data). Datos de usuario.

2.5.2 SMS-DELIVER

Esta trama, transmitida desde el SMSC hasta el MS, tiene una estructura similar a la

trama SMS-SUBMIT y se muestra en la Figura 2.9.

Los nuevos campos que aparecen son los siguientes:

• SA (Sender Address). Direccion del SME que envıa el mensaje.


1-12

1

1111 2-12 7

7

0-160

SCA PDU-TYPE SA PID DCS SCTS UDL UD

RP UDHI SRI sin usosin uso MMS MTIMTI

bits

Bytes

023456

Figura 2.9: Trama SMS-DELIVER.

• SCTS (Time Stamp). Marca de tiempo de cuando el centro de servicio recibio el

mensaje.

Ademas, como se puede apreciar en la Figura 2.9 el campo PDU-TYPE tambien

presenta ciertas variaciones en sus bits:

– SRI (Status Report Indication). Indica si un informe de estado va a ser retor-

nado al SME (SRI=1) o si no va ser retornado (SRI=0).

– MMS (More Messages to Send). Indica si hay mas mensajes para enviar

(MMS=0) o si no existen mas mensajes (MMS=1).

2.5.3 Cabecera de datos de usuario (UDH) y datos de usuario (UD)

El campo de datos de usuario (UD) contiene la parte de texto del mensaje SMS. Op-

cionalmente, el campo UD tambien puede contener una cabecera de datos de usuario

(UDH, User Data Header) de 8 bits. El campo UDH esta conformado de la longitud

de cabecera de datos de usuario (UDHL, User Data Header Length) seguida de una se-

cuencia de elementos de informacion. Los elementos de informacion tienen los siguientes

propositos:

• Control de SMS. En esta categorıa, los elementos de informacion contienen al-

gunas instrucciones de control de SMS tales como informacion de concatenacion,

direccionamiento a puertos de aplicacion, parametros de control del SMSC, entre

otras.


UD

UDH

Longitud UDH en octetos

UDHL IE1 IE2...

IEn bits de rellenodatos: codificacion

7 bits, 8 bits o UCS2

Solo si se usa codificacion de 7 bits

IEI IEDL IED Estructura del elemento de informacion (IE)

Longitud en octetos

Figura 2.10: Estructura del campo UD.

• Objetos EMS basicos y extendidos. En esta categorıa los elementos de infor-

macion contienen la definicion de objetos EMS (Enhanced Messaging Service) tales

como melodıas, imagenes, animaciones, etc.

La estructura del campo UD se muestra en la Figura 2.10. El primer octeto del campo

UDH, denominado UDHL, indica la longitud del UDH. Si el texto es codificado con 7

bits, entonces pueden ser necesarios bits de relleno entre el UDH y la parte restante del

campo UD. Estos bits de relleno garantizan que el texto, el cual sigue al UDH, siempre

empezara en el lımite de un septeto. Esto es importante para permitir a las entidades

SME mas antiguas, que no soporten el concepto de UDH, interpretar la parte de texto

del mensaje.

2.5.4 Direccionamiento de puertos de aplicacion

El direccionamiento de puertos de aplicacion es una caracterıstica que permite el en-

rutamiento de un mensaje recibido al puerto de una aplicacion identificada, la cual se


IEI 0x04Esquema de direccionamiento de puertos de aplicacion, direccion de 8 bits

IEDL 0x02 (2 octetos)IED Octeto 1 Puerto destino

Este octeto indica la direccion de 8 bits del puerto del receptor.Octeto 2 Puerto origenEste octeto indica la direccion de 8 bits del puerto del emisor.

Tabla 2.3: Esquema de direccionamiento de puertos de aplicacion, direccion de 8 bits.

Rango de numeros de puerto DescripcionDesde Hasta

0x00 0xEF Reservado0 (decimal) 239 (decimal)0xF0 0xFF Disponible para asignacion de aplicaciones240 (decimal) 255 (decimal)

Tabla 2.4: Rango de numeros de puerto, direcciones de 8 bits.

encuentra corriendo en la estacion movil. El direccionamiento a puertos de aplicacion

puede realizarse usando dos elementos de informacion distintos. El primer elemento de

informacion es usado para puertos de direccion de 8 bits mientras que el segundo elemento

de informacion es usado para puertos de direccion de 16 bits.

Para aplicaciones con puertos de direccion de 8 bits, se usa el elemento de informacion

mostrado en la Tabla 2.3. En el rango de direcciones de 8 bits, se usan los valores listados

en la Tabla 2.4.

Para aplicaciones con puertos de direccion de 16 bits, se usa el elemento de informacion

mostrado en la Tabla 2.5. En el rango de direcciones de 16 bits, se usan los valores listados

en la Tabla 2.6.

IEI 0x05Esquema de direccionamiento de puertos de aplicacion, direccion de 16 bits

IEDL 0x04 (4 octetos)IED Octetos 1 y 2 Puerto destino

Estos octetos indican la direccion de 16 bits del puerto del receptor.Octetos 3 y 4 Puerto origenEstos octetos indican la direccion de 16 bits del puerto del emisor.

Tabla 2.5: Esquema de direccionamiento de puertos de aplicacion, direccion de 16 bits.


Rango de numeros de puerto DescripcionDesde Hasta

0x0000 0x3E7F Puertos definidos por la IANAa

0 (decimal) 15999 (decimal)0x3E80 0x4267 Disponible para asignacion de aplicaciones16000 (decimal) 16999 (decimal)0x4268 0xFFFF Reservado17000 (decimal) 65535 (decimal)

Tabla 2.6: Rango de numeros de puerto, direcciones de 16 bits.

aIANA (Internet Assigned Numbers Authority), es la Agencia de Asignacion de Numeros deInternet. Antiguo registro central de protocolos, puertos, numeros de protocolo y codigos deInternet. Fue sustituido en 1998 por la ICANN (Internet Corporation for Assigned Names and

Numbers).

2.5.5 Ejemplo de trama SMS-SUBMIT

En la Tabla 2.7 se muestra un ejemplo de la estructura de la trama SMS requerida para

enviar el mensaje ”ESPE-DEEE” al numero de telefono 098646724 y direccionarlo al

puerto de aplicacion 16500.

Hay 27 octetos en este mensaje (54 ”caracteres”). El primer octeto (”00”) no se

cuenta, es solamente un indicador de la longitud del numero de telefono del SMSC.


Octeto(s) Campo Descripcion

00 SCA Longitud del numero de telefono del SMSC. En estecaso la longitud es 0, lo que significa que el numerodel SMSC almacenado en el telefono debe ser usado.

41 PDU TYPE En este caso se han activado los bits 6 (UDHI) y 0(MTI) para indicar que existe una cabecera en losdatos de usuario y que se trata de una trama SMS-SUBMIT respectivamente.

00 MR El valor ”00” permite al telefono determinar el numerode mensaje de referencia por sı mismo.

09 Adress Length Longitud del numero de telefono del SME de destino.

81 Type of Address Tipo de numero. El valor ”81” indica que se trata delformato nacional del numero de telefono.

90686427F4 Phone Number Numero de telefono en semioctetos (098646724) per-mutados de dos en dos. Debido a que la longituddel numero de telefono es impar (9 semioctetos), seanade una ’F’ como si el numero de telefono fuera”098646724F”. Si se usa el formato internacional (91en lugar de 81, en el campo Type os Address), paraEcuador antepuesto el prefijo 593 (59398646724), lasecuencia de octetos permutados serıa 9593686427F4,en donde la longitud es 11 (0B hexadecimal), la cualtambien es impar.

00 PID Protocolo SME-to-SME

00 DCS Este mensaje es codificado de acuerdo al Alfabeto de7 bits.

11 UDL Longitud del campo UD (datos de usuario). Como enel campo DCS se especifico la codificacion de los datoscon 7 bits, la longitud indica el numero de septetos(17). Si en el campo DCS se hubiera especificado lacodificacion con 8 bits o Unicode, la longitud harıareferencia al numero de octetos.

06 UDHL Como en el campo PDU TYPE se especifico la exis-tencia de una cabecera en los datos de usuario (UDH),entonces el valor ”06” indica la longitud en octetos delcampo UDH.

05 IEI El valor ”05” indica que se trata del elemento de in-formacion que permite realizar el direccionamiento apuertos de aplicacion utilizando el esquema 16 bits.

04 IEDL Longitud de los datos del elemento de informacion. Elvalor ”04” indica el numero de octetos, en este casolos dos primeros octetos determinan el puerto destinoy los otros dos restantes el puerto origen.

4074 IED Puerto destino 16500 (decimal). Estos octetos indicanla direccion de 16 bits del puerto del receptor.

4074 Puerto origen 16500 (decimal). Estos octetos indicanla direccion de 16 bits del puerto del emisor.

C529B4D822168B45 Data 7 bit encoding Estos octetos representan el mensaje ”ESPE-DEEE”.El procedimiento para realizar la transformacion deseptetos a octetos se muestra en el Apendice A (GSM

7-bit Default Alphabet y codificacion de datos de 7 bits

en octetos).

Tabla 2.7: Ejemplo de trama SMS-SUBMIT.

MODEM GSM Y COMANDOS AT 22

CAPITULO 3

MODEM GSM Y COMANDOS AT


Como se menciono en los capıtulos anteriores, la red GSM posee una gran cobertura

en nuestro paıs y tambien a nivel mundial; por lo tanto, uno de sus servicios basicos

como es el servicio de mensajes cortos SMS, se presenta como una gran oportunidad para

el desarrollo de aplicaciones basadas en este servicio. Para esto, es necesario disponer

de modems GSM, que son los que permiten la transmision y recepcion de los mensajes

cortos. En el presente capıtulo, se hablara acerca de este tipo de modems, que son

similares a los modems de las computadoras, pero inalambricos y que permiten establecer

comunicaciones a traves de la red GSM.

Para la comunicacion con el modem GSM se recurre a los comandos AT que tambien

seran tema de estudio en este capıtulo y de los cuales nos enfocaremos en aquellos que

permiten el manejo de mensajes SMS que son la base del presente proyecto. Mas infor-

macion sobre los comandos AT soportados por modems GSM se puede encontrar en [6].

3.2 MODEM GSM

El modem GSM es un modem inalambrico que trabaja con la red GSM. Un modem

inalambrico se comporta como un modem dial-up, con la diferencia que este ultimo, envıa

y recibe datos a traves de la lınea telefonica, mientras que el modem inalambrico envıa y

recibe datos por medio de ondas de radio. Mediante un modem GSM podemos conectar

cualquier sistema digital a la red GSM, no solo para enviar mensajes SMS sino tambien

para transmitir datos. El esquema logico de conexion de un modem GSM se puede

observar en la Figura 3.1.


Sistema

DigitalInterfaz

Serie

Modem GSM

Figura 3.1: Esquema logico de la conexion del modem GSM

Los modems GSM puede ser de tres tipos:

1. Modems para circuito impreso. Son modems de tamano reducido y perfecta-

mente apantallados que estan disenados para ser incorporados dentro de un circuito

impreso y que permiten desarrollar un hardware especıfico que no dependa de una

computadora.

2. Modems para PC. Son modems con un tamano igualmente reducido y que dispo-

nen de un conector serial o USB para conectarse a una computadora.

3. Modems embebidos en telefono movil. Son los modems incorporados en los

telefonos celulares con tecnologıa GSM.

3.3 INTERFAZ CON MODEMS: COMANDOS AT

La comunicacion con los modems se realiza a traves de una lınea serial y el estandar

utilizado para su control se basa en los comandos AT Hayes comunmente conocidos como

comandos AT. El modem, antes de realizar una conexion con otro modem, se encuentra

en el estado conocido como modo comando. En este modo, se puede configurar y controlar

el modem utilizando los comandos AT. Una vez establecida la conexion con un modem

remoto, se pasa del modo comando al modo conexion, por lo que la informacion que le llega

al modem por la lınea serial no es interpretada como comandos AT sino como informacion

a transmitir. Una vez terminada la conexion, el modem regresa al modo comando.


Codigos Descripcion

OK Indica que el comando y cualquier parametro especifi-cado fueron validos y que el comando completo su eje-cucion.

ERROR Indica que ha ocurrido un error durante el proce-samiento, ya sea por: un error en la sintaxis del co-mando, uno o mas parametros estan fuera del rango, elcomando no es soportado por el modem o el comandono es apropiado para el servicio.

Tabla 3.1: Codigos de resultado relacionados con la operacion de comandos AT.

Los comandos AT son cadenas ASCII que comienzan con los caracteres ”AT” y fi-

nalizan con el caracter <CR> (retorno de carro). Cada vez que el modem recibe un

comando, lo procesa y devuelve un resultado, que normalmente es una cadena ASCII,

salvo que se haya indicado lo contrario.

Las respuestas del modem GSM a los comandos AT pueden ser: codigos de resultado o

codigos de error. Los codigos de resultado se utilizan para confirmar la correcta operacion

del modem o para identificar cualquier problema con el comando. En la Tabla 3.1 se

describen los codigos de resultado relacionados con la operacion de los comandos AT y

que serviran para entender mas adelante la operacion del prototipo.

Los codigos de error indican fallas en el funcionamiento del modem embebido del

telefono celular, en la Tabla 3.2 se describen algunos de estos codigos que son de interes

para el proposito de este proyecto, el resto de codigos se describen en [6].

A continuacion se listan algunos comandos AT basicos:

• ATA: responder a una llamada entrante.

• ATD: llamar a un numero de telefono.

• ATE: encendido (1) o apagado (0) de eco de comandos.

• ATF: seleccionar modo de conexion.

• ATH: colgar o descolgar.

• ATL: volumen del altavoz.


Codigos que reportan fallos en el telefono movil

Codigos Descripcion

+CME ERROR: 0 Falla en el telefono+CME ERROR: 1 No hay conexion al telefono+CME ERROR: 3 Operacion no permitida+CME ERROR: 4 Operacion no soportada+CME ERROR: 20 Memoria llena

+CME ERROR: 21 Indice invalido+CME ERROR: 22 No encontrado+CME ERROR: 24 Cadena de texto muy larga+CME ERROR: 25 Caracter invalido en la cadena de texto

Codigos que reportan fallos de operacion o acceso

Codigos Descripcion

+CME ERROR: 300 Fallo del telefono movil+CME ERROR: 302 Operacion no permitida+CME ERROR: 303 Operacion no soportada+CME ERROR: 304 Parametro invalido en modo PDU+CME ERROR: 305 Parametro invalido en modo texto+CME ERROR: 322 Memoria llena

Tabla 3.2: Codigos de error del modem GSM.

• ATM: control del altavoz.

• ATZ: reset del modem.

Mas informacion sobre los comandos AT se puede encontrar en [8].

3.4 INTERFAZ CON MODEMS GSM

Como se habıa mencionado anteriormente, los modems GSM se comportan de manera

muy parecida a los modems normales, ası que, al igual que estos, permiten el intercambio

de datos con otro modem y utilizan los comandos AT originales, pero tambien incluyen

muchas mas caracterısticas. Incluyen su propia tarjeta SIM para poder funcionar y por

tanto permiten gestionar la base de datos de telefonos, la lista de los mensajes SMS

recibidos, enviar mensajes SMS, configurar diversos parametros, etc.

Para tener acceso a todos esos servicios, y dado que los comandos AT estaban muy

extendidos y muy estandarizados, se ha realizado una ampliacion, anadiendose nuevos co-

mandos. Estos nuevos comandos comienzan por las letras AT+, y se denominan comandos

AT+.


Codigos Descripcion”ME” Almacenamiento de mensajes en la memoria del telefono”SM” Almacenamiento de mensajes en la tarjeta SIM

Tabla 3.3: Tipos de memoria de almacenamiento para SMS

3.4.1 Comandos AT+

A continuacion se describiran algunos comandos AT+, especıficamente aquellos comandos

para SMS que son de interes para este proyecto.

1. AT+CPMS (Preferred Message Storage). Este comando selecciona el espacio de

memoria de almacenamiento a ser usada para distintas operaciones con los men-

sajes, tales como lectura, escritura, etc. El formato del comando es:

AT+CPMS=< mem1 >,< mem2 >,< mem3 >

Donde:

• mem1 : memoria desde la cual los mensajes son leıdos y borrados.

• mem2 : memoria a la cual se realizan las opciones de escritura y envıo.

• mem3 : memoria a la cual se preferira almacenar los mensajes SMS recibidos.

La Tabla 3.3, describe los tipos de memoria posibles, para el caso de mem3, solo

soporta el tipo ”ME”.

La Figura 3.2 muestra el resultado de la ejecucion de este comando en un modem

GSM, a traves de una conexion serial a una computadora y utilizando el programa

HyperTerminal con los siguientes parametros: 9600 bps, 8 bits de datos, 1 bit de

parada, sin paridad y sin control de flujo. El signo ’?’ despues del comando despliega

la configuracion actual, y el comando seguido de los signos ’=’ y ’?’ muestra si este

es o no soportado por el modem.


Figura 3.2: Ejecucion del comando CPMS en un modem GSM

2. AT+CMGF (Message Format). Este comando selecciona el formato de entrada y

salida para los mensajes SMS, a ser utilizado por el telefono. El formato para este

comando es el siguiente:

AT+CMGF=< modo >

Donde < modo > puede ser 0 para el modo PDU o 1 para el modo texto. La Figura

3.3 muestra la ejecucion de este comando en el modem GSM.

3. AT+CMGR (Read Message). Este comando devuelve el mensaje en la ubicacion

indicada por < ındice > del espacio de memoria seleccionado con el comando CPMS

en < mem1 >. El formato para este comando es el siguiente:


Figura 3.3: Ejecucion del comando CMGF en un modem GSM

AT+CMGR=< ındice >

Donde < ındice > es un numero entero en el rango de numeros de ubicacion so-

portados por la memoria asociada. Si se especifica un numero que no existe, se

devuelve un mensaje de error. La Figura 3.4 muestra un ejemplo de la ejecucion de

este comando en el modem GSM.

4. AT+CMGL (List Message). Este comando devuelve los mensajes con el estado

indicado en < estado > desde la memoria especificada en < mem1 >. El formato

de este comando es el siguiente:

AT+CMGL=< estado >

Los mensajes cortos se dividen en 5 categorıas, cada una identificada por una cadena;

por lo tanto, el campo < estado > identifica la categorıa de los mensajes a listar, la

cual puede ser:


Figura 3.4: Ejecucion del comando CMGR en un modem GSM

• ”REC UNREAD”: mensajes recibidos pero no leıdos.

• ”REC READ”: mensajes recibidos y leıdos.

• ”STO UNSEND: mensajes escritos y almacenados pero no enviados.

• ”STO SENT”: mensajes enviados.

• ”ALL”: todos los mensajes

La respuesta de la ejecucion de este comando en un modem GSM se observa en la

Figura 3.5.

5. AT+CMGS (Send Message). Este comando permite enviar un mensaje SMS desde

un equipo terminal a otro, su formato depende del modo en el cual se este traba-

jando:


Figura 3.5: Ejecucion del comando CMGL en un modem GSM

• Para enviar un mensaje en modo texto (AT+CMGF=1), primero se especifica

el numero de telefono, seguido de un caracter de retorno carro <CR>. El

modem responde enviando el caracter ’>’ que indica que se puede escribir el

mensaje que se quiere enviar. Para delimitar el mensaje hay que ingresar el

caracter <Ctrl+Z> (codigo ASCII 26).

AT+CMGS=< numero ><CR>


Figura 3.6: Envıo del mensaje ”ESPE-DEEE” a traves del comando CMGS en modo textoy modo PDU.

> < mensaje > <Ctrl+Z>

• Para enviar un mensaje en modo PDU (AT+CMGF=0), se especifica la lon-

gitud de la trama PDU en octetos seguido de un caracter de retorno de carro

<CR>. El modem responde enviando el caracter ’>’ y a continuacion se coloca

la trama PDU seguida del caracter <Ctrl+Z>.

La Figura 3.6 muestra la ejecucion de este comando en un modem GSM. El mensaje

que se desea enviar es ”ESPE-DEEE”. En primera instancia se realiza el envıo del

mensaje en modo texto. Posteriormente se emplea el modo PDU para transmitir

el mismo mensaje y direccionarlo a un puerto de aplicacion en el equipo terminal

receptor, de acuerdo a lo revisado en el Capıtulo 2, en la subseccion Ejemplo de

trama SMS-SUBMIT.

6. AT+CMGD (Delete Message). Este comando elimina el mensaje en la ubicacion


especificada por < ındice > de la memoria < mem1 >. Su formato es el siguiente:

AT+CMGD=< ındice >

La Figura 3.7 muestra la ejecucion de este comando en un modem GSM.

Figura 3.7: Ejecucion del comando CMGD en un modem GSM

SISTEMA DE POSICIONAMIENTO GLOBAL 33

CAPITULO 4

SISTEMA DE POSICIONAMIENTO GLOBAL


En este capıtulo se explicara brevemente el funcionamiento del Sistema de Posicionamiento

Global (GPS, Global Positioning System), una red de navegacion basada en satelites, que

permite obtener la posicion de un objeto en cualquier punto del planeta, a cualquier mo-

mento. Este sistema, desarrollado, implementado y gestionado por el Departamento de

Defensa de EE.UU., revoluciono el mundo de la navegacion gracias a su enorme utili-

dad en alta mar, funcionando bajo cualquier condicion climatica; pero, no esta limi-

tado unicamente a la navegacion, sino que deja abierta la posibilidad de implementar un

sinnumero de aplicaciones para usuarios civiles. Por lo tanto, sera motivo de revision en

este capıtulo el tema relacionado a los receptores GPS, centrandose en las caracterısticas

del receptor empleado en el presente proyecto, el SPK-GPS-GS405. Ası tambien, se

revisara el protocolo NMEA, que es el protocolo de comunicacion que utilizan estos dis-

positivos receptores.

Mas informacion sobre el sistema GPS se puede encontrar en su web oficial [9], y en

[10] se ofrece un tutorial que explica a detalle lo relacionado al funcionamiento del sistema

NAVSTAR-GPS.

4.2 FUNCIONAMIENTO DEL SISTEMA GPS

El sistema GPS funciona a traves del denominado segmento espacial mostrado en la

Figura 4.1, integrado por un total de 24 satelites que se encuentran en orbitas circulares

situadas a 20 180 km, girando alrededor de la Tierra de forma continua, de tal manera que

habitualmente cuatro de ellos se encuentran a la vista de cualquier usuario en cualquier


Segmento

Segmento de Segmento de

Espacial

ControlUsuarios

Estacion

Maestra

Figura 4.1: Funcionamiento del sistema GPS.

momento. Cada uno de estos satelites da la vuelta al mundo dos veces al dıa, transmi-

tiendo constantemente su identificacion personal, trayectoria, posicion respecto a un eje

de coordenadas situado en el centro de la Tierra, y tiempo.

Por otro lado, se encuentra el denominado segmento de control, esto es, una estacion

maestra situada en Colorado Springs (EE.UU.) enlazada con una serie de estaciones moni-

torizadas, cada una de las cuales sigue a los satelites que se encuentran a su vista, trans-

mitiendo la informacion entre estos satelites y la estacion maestra.

El proposito de este intercambio de informacion no es otro que el de permitir al satelite

transmitir una senal que es cuidadosamente cronometrada.

Finalmente se encuentra el segmento de usuarios, donde un observador mediante un

receptor GPS puede determinar su posicion y tiempo resolviendo un sistema de cuatro


ecuaciones con cuatro incognitas: x,y,z,t1; observando las senales de cuatro satelites.

La transmision de la informacion se realiza mediante la tecnica de Spread Spectrum,

todos los satelites transmiten en la misma frecuencia, pero cada uno utiliza un codigo

particular que lo identifica. Un receptor extrae la senal de uno en particular mediante un

decorrelator.

De esta manera, la posicion se determina en base a la medicion de las distancias desde

el observador a los satelites, considerando el tiempo de propagacion de la senal.

4.3 INTRODUCCION A LOS RECEPTORES GPS

Un receptor GPS es un sistema microprocesado con una capacidad de procesamiento

suficiente para poder resolver el sistema de ecuaciones planteado. Consta de una etapa

de RF que procesa y extrae las senales de los satelites, y una etapa procesadora de alto

desempeno. Cada canal es un decorrelator que permite extraer la senal de un satelite, y

mediante el procesamiento adecuado se puede utilizar la informacion que este provee en

la resolucion del sistema de ecuaciones. El sistema de ecuaciones basado en calculos de

distancias y tiempos de propagacion es un sistema no lineal, por lo que la resolucion es

en realidad una aproximacion.

Explicado de una forma mas practica, cada vez que un observador solicita al receptor

GPS la posicion en la que se encuentra, el aparato compara la hora en que el mensaje fue

enviado con la hora en que este fue recibido. Esta diferencia de tiempo le dice al GPS lo

lejos que el observador se encuentra de un satelite en particular, a lo que se anaden las

mediciones de distancias efectuadas con respecto a otros satelites, de tal manera que su

posicion queda triangulada.

Ademas si se mantiene el GPS constantemente actualizado, tambien se puede llegar a

saber datos como la velocidad y la direccion a la que se esta navegando.

4.3.1 Tipos de receptores GPS

Existen dos tipos de receptores GPS: los secuenciales y los multicanal (o continuos). Los

primeros cuentan con un unico canal, lo que supone que son mas lentos y no ofrecen

1La inclusion de t es necesaria debido al hecho de que las ondas electromagneticas requieren un tiempopara propagarse.


Figura 4.2: Modulo receptor SPK-GPS-GS405.

tanta precision como los multicanal, que disponen de un mınimo de 4 canales. Actual-

mente, los GPS secuenciales han quedado desfasados, comercializandose casi unicamente

los multicanal.

4.4 MODULO RECEPTOR SPK-GPS-GS405

El modelo del dispositivo GPS con el que se ha trabajado durante el desarrollo del proyecto

es el SPK-GPS-GS405 (Figura 4.2) de SPK Electronics Co., Ltd.

4.4.1 Introduccion

De acuerdo a la informacion proporcionada por el fabricante [11], el SPK-GPS-GS405

es un modulo receptor GPS basado en la tecnologıa de alta sensibilidad SiRF Star III 2.

Ademas incorpora una antena pasiva omnidireccional. Este modulo receptor puede ras-

trear 20 satelites simultaneamente, actualiza los datos de navegacion cada segundo y

provee la informacion exacta de la posicion inmediatamente despues de haberlo encen-

dido.

El SPK-GPS-GS405 esta disenado para una amplia gama de aplicaciones de navegacion

y posicionamiento personal OEM3 (Original Equipment Manufacturer) como dispositivos

portatiles, facilitando la integracion a la plataforma del sistema. Es apropiado para

necesidades exigentes tales como navegacion, mapeo, seguridad, agricultura, entre otras.

2SiRF Star III es una tecnologıa que mejora considerablemente el desempeno de los receptores GPS.Sus principales ventajas son: tiempos mas rapidos para determinar una posicion, alta sensibilidad paraadquirir las senales de los satelites en entornos difıciles, bajo consumo de potencia para prolongar la vidade la baterıa.

3OEM (Fabricante Original de Equipo) es una companıa que adquiere productos o servicios de sufabricante original al por mayor y lo anexa a su producto o servicio propio para ası venderlo.


4.4.2 Principales caracterısticas

• Chipset SiRF Star III incorporado con software estandar SiRF GSW 3.0.

• Antena pasiva Geohelix SMP omnidireccional Sarantel incorporada, para incremen-

tar la sensibilidad de recepcion de la senal.

• 20 canales paralelos para una rapida adquisicion.

• Tamano compacto

• Soporte del protocolo NMEA-0183 V.3.01

• Puerto serial que trabaja con niveles TTL para su integracion en tarjetas de circuito

impreso.

4.4.3 Especificaciones

En la Tabla 4.1 se mencionan las principales especificaciones tecnicas del receptor GPS y

que son relevantes para la realizacion del proyecto.

Las especificaciones relacionadas a la alimentacion del modulo receptor GPS, carac-

terısticas de la antena, condiciones de la alimentacion externa de respaldo, operacion del

software, especificaciones de comunicacion y condiciones del medio ambiente, se pueden

encontrar en el Apendice B, (Hoja de especificaciones del modulo receptor SPK-GPS-

GS405 ).

4.4.4 Asignacion y descripcion de pines

En la Figura 4.3 se puede observar la disposicion de los pines del modulo receptor SPK-

GPS-GS405 y en la Tabla 4.2 se describen las caracterısticas de cada uno de ellos.

4.4.5 Protocolo NMEA

El SPK-GPS-GS405 soporta el formato de mensajes NMEA-0183, estandar definido por

la National Marine Electronics Association (NMEA). Los mensajes NMEA actualmente

soportados para aplicaciones GPS son:

• GGA Global Positioning System Fix Data


Item Descripcion

Chipset Receptor Tecnologıa SiRF Star IIIGeneral Frecuencia L1, 1575,42 MHz

Codigo C/A Tasa de chip de 1,023 MHzNumero de canales 20

Tiempo de adquisicion Arranque en frıo 42 seg. promedioArranque en caliente 8 seg. promedio

Sensibilidad Rastreo -159 dBmPrecision Posicionamiento 10 m 2D RMSa

Alimentacion Voltaje de entrada 3,3V ± 5%V DCConsumo de potencia inferior a 250 mWConsumo de corriente ≃75 mA

Puerto serial Interfaz electrica una interfaz serial full duplexUART TTL

Mensajes de protocolo NMEA-0183 (4800 bps)GGA, GSA, GSV, RMC /porsegundo

Tabla 4.1: Especificaciones del modulo receptor SPK-GPS-GS405.

a10 m 2D RMS indica que el 98% de las lecturas del GPS se encuentran en un cırculo de 10mde radio.

• GSA GNSS DOP and Active Satellites

• GSV GNSS Satellites in View

• RMC Recommended Minimum Specific GNSS Data

El protocolo NMEA-0183 es un protocolo de datos para la comunicacion entre instru-

mentos marinos y tambien los receptores GPS. Todos los datos son transmitidos a traves

de sentencias con caracteres ASCII sobre comunicacion serie a 4800 bps.

El estandar define cada sentencia NMEA como una trama que se compone de un

maximo de 83 caracteres y su estructura se muestra en la Figura 4.4. Los campos que lo

componen son los siguientes:

• Secuencia de inicio. Empieza con el caracter ’$’ y a continuacion se encuentra

una cadena de cinco caracteres. Los primeros dos caracteres son los que identifican

el equipo, y los siguientes tres caracteres identifican el tipo de sentencia que se esta

enviando.


Pin No. Nombre I/O Descripcion

1 GND Tierra2 VIN I Entrada para la fuente principal de DC 3.3V ±

5%V DC3 GND Tierra4 GND Tierra5 GPIO1 O El usuario puede usarlo como pin de I/O para una

funcion especial. Por ejemplo, un LED indicadorde ON/OFF

6 GND Tierra7 BATTERY I Entrada para la fuente de respaldo que alimenta

la SRAM y el RTC (real-time clock) cuando lafuente principal es removida. Sin una baterıa ex-terna de respaldo se ejecutara un arranque en frıodespues de encender el receptor GPS. Conectandouna baterıa externa de respaldo se conseguira uninicio mas rapido del receptor, por ejemplo un a-rranque en caliente. El voltaje de la baterıa debeestar en el rango de 2.0V a 5.0V

8 GND Tierra9 RX I Canal receptor por el cual se pueden ejecutar co-

mandos desde el software SiRFdemo o desde algunsoftware escrito por el usuario.

10 TX O Canal transmisor que envia los datos de nave-gacion y medicion a un software de navegacion o aun software escrito por el usuario. Nivel de salidaTTL, 0V ∼ 2.85V

Tabla 4.2: Descripcion de pines del receptor SPK-GPS-GS405.


1

5

6

10

GND

GNDGND

GNDGND

VIN BATTERY

GPIO1

RX

TX

Figura 4.3: Asignacion de pines del receptor SPK-GPS-GS405.

• Carga util. Cada campo de datos esta delimitado por una coma. Despues del

ultimo campo con datos se usa el caracter ’*’ como delimitador.

• Suma de comprobacion. Despues del caracter ’*’ vienen 2 dıgitos en hexadecimal

que es la suma de comprobacion de la trama. Esta suma de comprobacion se calcula

mediante la operacion XOR (OR exclusiva) de toda la cadena que hay entre el

caracter ’$’ y el caracter ’*’.

• Secuencia de fin. Cada sentencia NMEA termina con <CR><LF> (CR: Retorno

de carro, LF: Salto de lınea).

Cada mensaje se envıa con una cierta periodicidad, sin que esto indique que la in-

formacion entregada es la verdad absoluta. Analizando con detenimiento los mensajes,

se podra determinar si el modulo receptor esta recibiendo correctamente una cantidad

adecuada de satelites. Generalmente uno de los campos del mensaje indica la validez de


Secuencia de inicio Carga utilSuma de

comprobacionSecuencia de fin

Figura 4.4: Estructura del mensaje NMEA.

la cadena. Por ejemplo, en el mensaje RMC, que informa posicion, fecha y hora:

$GPRMC,235948.000,V,0000.0000,N,00000.0000,E,,,091102,,*1E

La ’V’ indica ”void”, cadena no valida, informacion irrelevante.

$GPRMC,161229.487,A,3723.2475,N,12158.3416,W,0.13,309.62,120598,,*10

La ’A’ indica que la informacion es valida.

La salida del modulo GPS puede conectarse a un UART de un microcontrolador, el cual

puede analizar los mensajes NMEA-0183, determinar el estado y calidad de la informacion,

y obtener una posicion. Todos estos datos pueden periodicamente ser reportados mediante

algun sistema de comunicaciones (por ejemplo, los mensajes SMS de la telefonıa celular).

• RMC-Recommended Minimum Specific GNSS Data

Datos de tiempo, fecha, posicion, velocidad y rumbo.

En el siguiente ejemplo se muestra la estructura del mensaje RMC, el mismo que es

utilizado en este proyecto para obtener, a partir de los campos correspondientes, los

datos de latitud y longitud necesarios para determinar una posicion. En la Tabla

4.3 se describe cada uno de los campos que componen esta trama.

– Ejemplo:

$GPRMC,161229.487,A,3723.2475,N,12158.3416,W,0.13,309.62,120608, ,*10

<CR><LF>

Informacion relacionada a la estructura de este y otros mensajes NMEA se puede

encontrar en [12].


Nombre Ejemplo Unidades Descripcion

ID de mensaje $GPRMC GP es un ID de dispositivo, eneste caso, se trata de un GPS.RMC es el tipo de mensaje

Tiempo UTC 161229.487 hhmmss.sssEstado A A=datos validos o V=datos no

validosLatitud 3723.2475 ggmm.mmmmIndicador N/S N N=norte o S=surLongitud 12158.3416 gggmm.mmmmIndicador E/W W E=este o W=oesteVelocidad sobre tierra 0.13 nudosRumbo sobre tierra 309.62 gradosFecha 120608 ddmmaaVariacion magnetica grados E=este o W=oesteSuma de comprobacion *10<CR><LF> Secuencia de fin de mensaje

Tabla 4.3: Estructura del mensaje RMC.

MICROCONTROLADORES PIC 43

CAPITULO 5

MICROCONTROLADORES PIC


Los microcontroladores son computadores digitales integrados en un chip que cuenta con

un microprocesador, una memoria para almacenar el programa, una memoria para al-

macenar datos y puertos de entrada/salida. A diferencia de los microprocesadores de

proposito general, como los que se usan en las computadoras, los microcontroladores son

unidades autosuficientes y mas economicas.

El funcionamiento de los microcontroladores esta determinado por el programa alma-

cenado en su memoria, el cual puede escribirse en distintos lenguajes de programacion.

Por las caracterısticas mencionadas y su alta flexibilidad, los microcontroladores son

ampliamente utilizados como el cerebro de una gran variedad de sistemas embebidos que

controlan sistemas de automatizacion y robotica, domotica, equipos medicos, sistemas

aeroespaciales, e incluso maquinas o dispositivos de la vida diaria como automoviles,

hornos de microondas, telefonos y televisores.

De ahı, la importancia de este capıtulo, puesto que un microcontrolador es el encargado

de gestionar las comunicaciones con el modem GSM del telefono celular y con el receptor

GPS, ası como de controlar los distintos puertos de entrada y salida de acuerdo a los

requerimientos del usuario.

En este capıtulo se tratara algunas nociones basicas sobre los microcontroladores PIC,

centrandose en las caracterısticas del microcontrolador PIC16F877A. Ası tambien, se

hablara sobre el desarrollo de software y la programacion de estos microcontroladores.


5.2 CARACTERISTICAS DE LOS MICROCONTROLADORES

Las principales caracterısticas de los microcontroladores son:

• Unidad de procesamiento central (CPU). Tıpicamente de 8 bits, pero tambien

hay de 4, 32 y hasta 64 bits con arquitectura Harvard, con memoria/bus de datos

separada de la memoria/bus de instrucciones de programa, o arquitectura de Von

Neumann, tambien llamada arquitectura Princeton, con memoria/bus de datos y

memoria/ bus de programa compartidas.

• Memoria de programa. Es una memoria ROM (Read Only Memory), EPROM

(Electrically Programable ROM ), EEPROM (Electrically Erasable/Programable ROM )

o Flash que almacena el codigo del programa que tıpicamente puede ser de 1 kB a

varios MB.

• Memoria de datos. Es una memoria RAM (Random Access Memory) que tıpicamente

puede ser de 1, 2, 4, 8, 16, 32 kB.

• Generador del reloj. Usualmente un cristal de cuarzo de frecuencias que genera

una senal oscilatoria entre 1 y 40 MHz, o tambien resonadores o circuitos RC.

• Interfaz de entrada/salida. Puertos paralelos, seriales (UARTs, Universal Asyn-

chronous Receiver/Transmitter), I2C (Inter-Integrated Circuit), interfaces de perifericos

seriales (SPIs, Serial Peripheral Interfaces), red de area de controladores (CAN,

Controller Area Network), USB (Universal Serial Bus).

• Otras opciones:

– Conversores Analogo-Digitales (A/D) para convertir un nivel de voltaje en un

cierto pin a un valor digital manipulable por el programa del microcontrolador.

– Moduladores por ancho de pulso (PWM, Pulse Width Modulation) para generar

ondas cuadradas de frecuencia fija pero con ancho de pulso modificable.


Figura 5.1: Pines del PIC16F877A.

5.3 PIC16F877A

5.3.1 Caracterısticas

El microcontrolador PIC16F877A de Microchip Technology Inc. es uno de los microcon-

troladores mas utilizados en proyectos electronicos. Su facil uso, precio reducido, infor-

macion, herramientas de ayuda, lo han convertido en un microcontrolador muy popular

y el favorito en un gran rango de aplicaciones.

El microcontrolador PIC16F877A pertenece a la familia Microchip de microcontro-

ladores de gama media de 8 bits (bus de datos) con 40 pines. Como se muestra en la

Figura 5.1, este posee 33 lıneas de entrada/salida (puertos A,B,C,D,E) con tecnologıa

TTL/CMOS, es decir, 5V para un estado logico 1 y 0V para el estado 0. Esta implemen-

tado con arquitectura Harvard y tecnologıa RISC (Reduced Instruction Set Computer), se

programa mediante un juego de 35 instrucciones en lenguaje ensamblador, que manejan

datos de 8 bits. En la Tabla 5.1 se pueden observar las caracterısticas mas relevantes de

este microcontrolador. (Ver tambien el Apendice C, Hoja de especificaciones del micro-

controlador PIC16F877A)

Informacion mas detallada con respecto a las especificaciones y funcionamiento del

PIC16F877A, se puede encontrar en la web del fabricante [13].


Caracterısticas PIC16F877A

Frecuencia maxima 20 MHzMemoria de programa flash palabra de 14 bits 8 KPosiciones RAM de datos 368 BPosiciones EEPROM de datos 256 BPuertos E/S A,B,C,D,ENumero de pines 40Interrupciones 14Timers 3Modulos CCP (Capture/Compare/PWM) 2Comunicacion serie MSSP, USARTComunicaciones paralelo PSPCanales de conversion A/D de 10 bits 8Juego de instrucciones 35 instruccionesLongitud de cada instruccion 14 bitsArquitectura HarvardCPU RISC

Tabla 5.1: Caracterısticas del PIC16F877A.

5.4 PROCESO DE DESARROLLO DE UNA APLICACION

El proceso de desarrollo de una aplicacion basada en microcontroladores se compone de

las siguientes etapas principales, las cuales se explican en las siguientes subsecciones.

• Desarrollo de software

• Programacion del microcontrolador

• Prueba y verificacion

5.4.1 Desarrollo del software

Esta etapa consiste en escribir y compilar/ensamblar el programa que determinara las ac-

ciones del microcontrolador y su funcionamiento. Existen distintas maneras de desarrollar

el programa, dependiendo del lenguaje inicial que se utiliza para escribir el mismo:

• Lenguaje ensamblador - Lenguaje de maquina/Codigo objeto

(.asm) =⇒ ensamblador =⇒ (.hex, .o, .bin, .coff)


Usuario

Archivo

Archivo

Archivo

.c

.asmCompilador

Ensamblador.hex

Figura 5.2: Etapas del desarrollo de software.

• Lenguaje de Alto nivel - Lenguaje ensamblador - Lenguaje de maquina/Codigo

objeto

(.c, .cpp) =⇒ compilador =⇒ (.asm) =⇒ ensamblador =⇒ (.hex, .o, .bin, .coff)

En la Figura 5.2 se muestran las dos alternativas tıpicas que tiene el desarrollador

para generar el codigo de maquina que es entendido por el microcontrolador.

El metodo basico es escribir el programa en lenguaje ensamblador en un archivo de

texto con extension .asm y luego utilizar una programa ensamblador (Assembler) para

generar un archivo en lenguaje de maquina, tambien denominado codigo de maquina

o codigo objeto (object code), compuesto por instrucciones en codigo binario que son

directamente entendidas por la CPU del microcontrolador. El ensamblador normalmente

genera un archivo con extension .hex (hexadecimal), .o (objeto), .bin (binario), o .coff

(common object file format) dependiendo del ensamblador.

Otra alternativa es emplear un lenguaje de alto nivel, mas facil de usar y que ademas

reduce los tiempos de desarrollo. Los lenguajes de alto nivel mas comunes para la pro-

gramacion de microcontroladores son el C y C++, pero tambien existen otros lenguajes

variantes del BASIC y el Pascal. Una vez escrito el programa en el lenguaje de alto nivel,


sera necesario emplear un compilador para traducirlo, ya sea a lenguaje de ensamblador o

directamente a lenguaje de maquina. Una vez que el compilador ha generado el codigo de

ensamblador (.asm), sera necesario utilizar un ensamblador para generar el codigo binario

de maquina.

En el presente proyecto, para el desarrollo del codigo que sera programado en el PIC, se

utilizo el compilador de lenguaje C, PCW de CCS Inc., el cual sera tratado mas adelante.

5.4.2 Programacion del microcontrolador

Este proceso corresponde a utilizar un programa en la computadora que toma el codigo

ensamblado (.hex, .o, .bin, .coff) para el microcontrolador especıfico, y lo envıa mediante

algun puerto (serial, paralelo, USB, etc.) a un dispositivo que lo escribe en la memoria

del microcontrolador. Es importante mencionar que no deben confundirse los terminos

desarrollo o programacion del software y programacion del microcontrolador, el primero

se refiere a escribir el programa, mientras que el segundo se refiere a transferir el codigo

de maquina a la memoria del microcontrolador.

5.4.3 Prueba y verificacion

Una vez programado el microcontrolador, se puede instalar en el circuito final para com-

probar su adecuado funcionamiento. Existen herramientas de software que permiten simu-

lar el comportamiento de un microcontrolador, muy utiles cuando el programa alcanza

cierta complejidad, tal es el caso del simulador de circuitos Proteus.

5.5 COMPILADOR DE C PCW DE CCS

El proceso de desarrollo de aplicaciones para el PIC es equivalente al descrito en la Figura

5.2. En lo que respecta al desarrollo de software para los microcontroladores PIC existen

varias alternativas.

Si se quiere realizar la programacion de los microcontroladores PIC en un lenguaje

como el C, es preciso utilizar un compilador de C. Dicho compilador genera archivos en

formato Intel-hexadecimal, que es el necesario para programar (utilizando un programador

de PIC) un microcontrolador de 6, 8, 18 o 40 pines. El compilador de C que se utilizo en

este proyecto es el PCW de la casa CCS Inc . Este compilador dispone de un entorno de

desarrollo integrado (IDE) que permite implementar cada una de las fases de las que se


Extension de archivo Descripcion

.PJT Contiene informacion relacionada al proyecto.

.LST Muestra cada linea del codigo fuente en C y el codigo enlenguaje ensamblador generado para esa lınea.

.SYM Muestra cada registro y que variables de programa sonalmacenadas en esa localizacion.

.TRE Detalla cada funcion indicando a que otras funcionesllama (de ser el caso) ademas de especificar el uso de lasmemorias RAM y ROM.

.COF Archivo binario que contiene el codigo de maquina einformacion de depuracion.

.COD Archivo binario que contiene informacion de depuracion.

Tabla 5.2: Archivos asociados al compilador de C PCW de CCS.

compone el desarrollo de software de un proyecto, desde la edicion hasta la compilacion

pasando por la depuracion de errores.

Este compilador traduce el codigo C del archivo fuente (.c) a lenguaje de maquina

entendido por los microcontroladores PIC, generando ası un archivo (.HEX) en formato

hexadecimal. Ademas de este, tambien genera otros seis archivos, los cuales se describen

en la Tabla 5.2.

Informacion referente al lenguaje C especıfico para PICs (directivas, librerıas y fun-

ciones) se puede encontrar en [14].

JAVA 2 MICRO EDITION 50

CAPITULO 6

JAVA 2 MICRO EDITION


Este capıtulo en primera instancia da una breve introduccion a la plataforma Java y sus

distintas versiones o ediciones, enfocandose principalmente en J2ME (Java 2 Micro Edi-

tion), que es una version orientada a pequenos dispositivos electronicos con capacidades

restringidas y de la cual hace uso el presente proyecto.

Se realizara una revision de los pilares sobre los que se asienta la plataforma J2ME, su

arquitectura, la configuracion CLDC (Connected Limited Device Configuration), el perfil

MIDP (Mobile Information Device Profile), las aplicaciones de esta plataforma basadas

en este perfil denominadas MIDlets y las principales clases que componen esta edicion.

Ademas se revisara las APIs (Application Programming Interfaces): WMA (Wireless

Messaging API ) y Push Registry, que son de gran importancia para los propositos del

presente proyecto.

Informacion mas detallada sobre Java, sus versiones, entornos de desarrollo, ejemplos

de programacion y especıficamente la plataforma J2ME se pueden encontrar en [15] y

[16].

6.2 INTRODUCCION A LA PLATAFORMA JAVA

Java es un lenguaje de programacion orientado a objetos, que fue lanzado por la empresa

Sun Microsystems a mediados de los anos 90. Debido a la explosion y diversidad tec-

nologica de los ultimos anos, Java se ha ido adaptando a las necesidades actuales, tanto

de las empresas como de los usuarios. Con este objetivo, Sun creo una serie de versiones

o ediciones enfocadas a distintos entornos, contando en la actualidad con tres grandes


Java 2

Enterprise

Edition

Edition

Java 2

Standard

Java 2 Micro Edition

Plataforma Java

HotSpot VM clasicas KVM Card VM

Memoria

Sistema Operativo

10 MB

64 bits

1 MB 500 KB

32 bits

10 KB

16 bits 1 bit

Figura 6.1: Arquitectura de la plataforma Java 2 de Sun.

ediciones que se muestran en la Figura 6.1 y se describen a continuacion:

• J2SE (Java 2 Stantard Edition). Orientada al desarrollo de aplicaciones de usuario

final.

• J2EE (Java 2 Enterprise Edition). Orientada al entorno empresarial.

• J2ME (Java 2 Micro Edition). Orientada a la programacion de aplicaciones para

pequenos dispositivos electronicos con capacidades restringidas.

En la actualidad Java es un conjunto de tecnologıas que abarca a todos los ambitos

de la computacion con dos elementos en comun:

• El codigo fuente en lenguaje Java es compilado a codigo intermedio, el cual es

interpretado por una Maquina Virtual Java (JVM, Java Virtual Machine), por lo

que el codigo ya compilado es independiente de la plataforma.


• Todas las tecnologıas comparten un conjunto mas o menos amplio de APIs basicas

del lenguaje, agrupadas principalmente en los paquetes java.lang y java.io.

6.3 INTRODUCCION A J2ME

J2ME es la version de Java enfocada a aplicaciones en dispositivos electronicos con capaci-

dades computacionales y graficas muy reducidas, como por ejemplo: telefonos moviles,

PDAs o electrodomesticos inteligentes.

J2ME contiene una mınima parte de las APIs de Java. Esto es debido a que la

edicion estandar de APIs de Java ocupa 20 MB, y los dispositivos pequenos disponen de

una cantidad de memoria mucho mas reducida. En concreto, J2ME usa 37 clases de la

plataforma J2SE provenientes de los paquetes java.lang, java.io, java.util, que conforman

lo que se denomina configuracion.

6.4 ARQUITECTURA DE J2ME

La arquitectura de J2ME tiene los siguientes componentes:

1. Maquina Virtual Java (JVM)

2. Configuraciones

3. Perfiles

La Figura 6.2 muestra la arquitectura del entorno de ejecucion J2ME con sus respec-

tivos componentes, los cuales se describen en las siguientes subsecciones.

6.4.1 Maquinas virtuales en J2ME

Una maquina virtual Java es un programa encargado de interpretar codigo intermedio

(bytecode) de los programas Java precompilados, a codigo maquina ejecutable por la

plataforma, efectuar las llamadas pertinentes al sistema operativo subyacente y observar

las reglas de seguridad y correccion de codigo definidas para el lenguaje Java. J2ME

define dos maquinas virtuales con diferentes caracterısticas que son:

• KVM. Su nombre proviene de kilobyte, debido a la poca memoria requerida, entre

40KB y 80KB. Es una implementacion de maquina virtual reducida y orientada a


Aplicacion

RMI Profile

Foundation Profile

Personal Profile

CDC

CVM

Sistema Operativo

Dispositivos Hardware

PDA Profile MID Profile

CLDC

KVM

Figura 6.2: Arquitectura del entorno de ejecucion J2ME.

dispositivos con bajas capacidades computacionales y de memoria. Tiene algunas

limitaciones como:

– No hay soporte para tipos en coma flotante, por lo tanto no existen los tipos

double ni float.

– No existe soporte para JNI (Java Native Interface) debido a los recursos limi-

tados de memoria.

– No existen cargadores de clases (class loaders) definidos por el usuario. Solo

existen los predefinidos.

– No se permiten los grupos de hilos o hilos daemon.

– No existe la finalizacion de instancias de clases.

– No existe el metodo Object.finalize().

– No hay referencias debiles 1.

1Un objeto que esta siendo apuntado mediante una referencia debil es un candidato para la recoleccionde basura. Estas referencias estan permitidas en J2SE, pero no en J2ME.


– Limitada capacidad para el manejo de excepciones debido a que el manejo de

estas depende en gran parte de las APIs de cada dispositivo por lo que son

estos los que controlan la mayorıa de las excepciones.

• CVM. Es la maquina virtual asociada a la configuracion CDC y soporta las mis-

mas caracterısticas que la Maquina Virtual de J2SE, esta orientada a dispositivos

electronicos reducidos pero con mas recursos.

6.4.2 Configuraciones

Una configuracion es un conjunto mınimo de APIs basicas que permiten desarrollar apli-

caciones destinadas a un amplio rango de dispositivos, con ella se especifica un conjunto

de caracterısticas soportadas del lenguaje Java y un conjunto mınimo de caracterısticas

de la JVM. Existen 2 configuraciones definidas en J2ME:

• CLDC (Connected Limited Device Configuration). Enfocada a dispositivos dotados

de conexion y con restricciones de procesamiento y memoria, como los telefonos

moviles o las PDAs de gama baja.

• CDC (Connected Device Configuration). Enfocada a dispositivos con cierta ca-

pacidad computacional y de memoria. Con procesadores de 32 bits, 2MB o mas

de memoria y con conexion de red, como sistemas de navegacion en automoviles o

PDAs de gama alta.

6.4.3 Perfiles

El perfil es un grupo mas especıfico de APIs orientado a un ambito de aplicacion deter-

minado, por lo tanto, un perfil dota a una configuracion de una funcionalidad especıfica.

La configuracion se ajusta a una familia de dispositivos y el perfil se orienta hacia un

grupo determinado dentro de dicha familia. Del mismo modo que tenemos una maquina

virtual asociada a una configuracion, en este caso, tambien tendremos una serie de perfiles

asociados a una determinada configuracion.

Como se observo en la Fig.6.2, los perfiles pueden ser:

• Para CDC


– Foundation Profile

– Personal Profile

– RMI Profile

• Para CLDC

– PDA Profile

– Mobile Information Device Profile (MIDP)

Actualmente las diferencias, computacionales graficas y de memoria, entre los distintos

dispositivos moviles, son tales que resulta imposible implementar una misma aplicacion

que sirva para diversos dispositivos, por ejemplo, para una PDA determinada y un telefono

movil. Por esto, la eleccion del entorno viene dada por el dispositivo en el cual se ejecutara

la aplicacion.

6.5 CONNECTED LIMITED DEVICE CONFIGURATION CLDC

En esta seccion y la siguiente se profundizara en la configuracion CLDC y el perfil MIDP,

puesto que esta ha sido la configuracion mas extendida y conocida de J2ME. La descripcion

de las demas configuraciones y perfiles puede ser encontrada en [17].

CLDC utiliza la maquina virtual KVM, debido a su pequeno tamano. Los dispositivos

que usan CLDC deben cumplir con los siguientes requisitos:

• Disponer entre 160 kB y 512 kB de memoria total disponible, un mınimo de 128 kB

de memoria no volatil para la maquina virtual Java y las bibliotecas CLDC, y 32

kB de memoria volatil para la maquina virtual en tiempo de ejecucion.

• Procesador de 16 o 32 bits con al menos 25 MHz de velocidad.

• Ofrecer bajo consumo, debido a que estos dispositivos trabajan con suministro de

energıa limitado, normalmente baterıas.

• Tener conexion a algun tipo de red.

CLDC aporta las siguientes funcionalidades a los dispositivos:


Nombre del paquete CLDC Descripcion

java.io Clases y paquetes estandar de E/S. Subconjunto deJ2SE

java.lang Clases e interfaces de la maquina virtual. Subconjuntode J2SE.

java.util Clases, interfaces y utilidades estandar. Subconjunto deJ2SE.

javax.microedition.io Clases e interfaces de conexion generica CLDC.

Tabla 6.1: Librerıas de configuracion CLDC.

Clases de sistema (subconjunto de java.lang)java.lang.Class

java.lang.Objectjava.lang.Runnablejava.lang.Runtimejava.lang.String

java.lang.Stringbufferjava.lang.Systemjava.lang.Thread

java.lang.Throwable

Tabla 6.2: Clases de sistema heredadas de J2SE.

• Un subconjunto del lenguaje Java y todas las restricciones de su maquina virtual

(KVM).

• Un subconjunto de las bibliotecas Java del nucleo.

• Soporte para E/S (entrada y salida) basica.

• Soporte para acceso a redes.

• Seguridad.

La Tabla 6.1 muestra las librerıas incluidas en la configuracion CLDC y las clases

provenientes de estas se encuentran en las Tablas 6.2 a la 6.6

6.6 MOBILE INFORMATION DEVICE PROFILE (MIDP)

Este perfil esta construido sobre la configuracion CLDC y fue el primer perfil definido

para J2ME. Este perfil esta orientado para dispositivos con las siguientes caracterısticas:

• Reducida capacidad computacional y de memoria.


Clases de Datos (subconjunto de java.lang)java.lang.Boolean

java.lang.Bytejava.lang.Characterjava.lang.Integerjava.lang.Longjava.lang.Short

Tabla 6.3: Clases de datos heredadas de J2SE.

Clases de Utilidades (subconjunto de java.util)java.util.Calendar

java.util.Datejava.util.Enumerationjava.util.Hashtablejava.util.Randomjava.util.Stack

java.util.TimeZonejava.util.Vector

Tabla 6.4: Clases de utilidades heredadas de J2SE.

Clases de E/S (subconjunto de java.io)java.io.ByteArrayInputStream

java.io.ByteArrayOutputStreamjava.io.DataInput

java.io.DataOutputjava.io.DataInputStream

java.io.DataOutputStreamjava.io.InputStream

java.io.InputStreamReaderjava.io.OutputStream

java.io.OutputStreamWriterjava.io.PrintStream

java.io.Readerjava.io.Writer

Tabla 6.5: Clases de E/S heredadas de J2SE.


Clase DescripcionConnector Clase generica que puede crear cualquier tipo de

conexion.Connection Interfaz que define el tipo de conexion mas generica.InputConnection Interfaz que define una conexion de streams de entrada.OutputConnection Interfaz que define una conexion de streams de salida.StreamConnection Interfaz que define una conexion basada en streams.ContentConnection Extension a StreamConnection para trabajar con datos.Datagram Interfaz generico de datagramas.DatagramConnection Interfaz que define una conexion basada en datagramas.StreamConnectionNotifier Interfaz que notifica una conexion. Permite crear una

conexion en el lado del servidor.

Tabla 6.6: Clases e interfaces incluidos en el paquete javax.microedition.io

• Conectividad limitada (en torno a 9600 bps).

• Capacidad grafica muy reducida (mınimo un display de 96×54 pixels monocromo).

• Entrada de datos alfanumerica reducida.

• 128 kB de memoria no volatil para componentes MIDP.

• 8 kB de memoria no volatil para datos persistentes de aplicaciones.

• 32 kB de memoria volatil en tiempo de ejecucion para la pila Java.

El perfil MIDP establece las capacidades del dispositivo, por lo tanto, especifica las

APIs relacionadas con:

• La aplicacion (semantica y control de la aplicacion MIDP).

• Almacenamiento persistente.

• Trabajo en red.

• Temporizadores.

La Tabla 6.7 muestra las librerıas del perfil MIDP.


Paquetes del MIDP Descripcionjavax.microedition.lcdui Clases e interfaces para GUIs.javax.microedition.rms Record Management Storage. Soporte para el almace-

namiento persistente del dispositivo.javax.microedition.midlet Clases de definicion de la aplicacion.javax.microedition.io Clases e interfaces de conexion generica.java.io Clases e interfaces de E/S basica.java.lang Clases e interfaces de la Maquina Virtual.java.util Clases e interfaces de utilidades estandar.

Tabla 6.7: Librerıas del perfil MIDP.

6.7 MIDlets

Los MIDlets son aplicaciones desarrolladas mediante el perfil MIDP, pensadas para que

puedan ser descargadas a traves de Internet. Este tipo de descarga recibe el nombre

de OTA (Over the Air) y se compone de: un archivo .jar (Java Archive), en el cual

estara la aplicacion en si; un archivo descriptor .jad (Java Application Descriptor) y un

archivo denominado manifiesto. Aunque existen otras formas de transferir estos archivos

al telefono movil, dependiendo de la marca y modelo del dispositivo. Ası se puede utilizar

el puerto de infrarrojos, bluetooth o el cable de datos.

El fichero .jar se compone de:

• Clases del MIDlet 2

• Clases de soporte

• Recursos (imagenes, sonidos, etc...)

En el archivo manifiesto (.mf) se describe el contenido del archivo .jar, pero no se

incluye en este.

El archivo descriptor (.jad) proporciona la informacion requerida por el AMS (Appli-

cation Management Software), que es el programa encargado de manejar la descarga del

MIDlet y de controlar los estados por los que pasa este mientras esta ejecutandose en el

dispositivo, para llevar a cabo la descarga y asegurarse de que ese MIDlet es adecuado

para el dispositivo en el cual se va instalar.

2Un fichero .jar puede contener varios MIDLets. Esta coleccion de MIDLets, se suele llamar ”MIDLetSuite”.


Actualizacion

Borrado

Instalacion

Ejecucion

Localizacion

Figura 6.3: Ciclo de vida de un MIDlet.

6.7.1 Ciclo de vida de un MIDlet

Un MIDlet pasa por 5 fases, las mismas se muestran en la Figura 6.3 y se describen a

continuacion:

1. Localizacion. Es la etapa previa a la instalacion del MIDlet y es donde selec-

cionamos a traves del AMS la aplicacion a descargar. El AMS realiza la descarga

de aplicaciones de diferentes maneras, ya sea mediante un cable o una conexion

inalambrica, dependiendo de la capacidad del dispositivo.

2. Instalacion. En esta fase el AMS controla todo el proceso informando al usuario

tanto de la evolucion de la instalacion como de si existiese algun problema durante

esta.

3. Ejecucion. En esta fase, el AMS tiene la funcion de gestionar los estados del MIDlet

en funcion de los eventos que se produzcan durante esta ejecucion.

4. Actualizacion. El AMS tiene que ser capaz de detectar despues de una descarga si


el MIDlet descargado es una actualizacion de un MIDlet ya presente en el dispositivo.

Si es ası, debe informarlo y dar la oportunidad de decidir si se desea realizar la

actualizacion pertinente o no.

5. Borrado. En esta fase el AMS es el encargado de borrar el MIDlet seleccionado

del dispositivo, previamente pedira una confirmacion e informara cualquier circuns-

tancia que se produzca.

6.7.2 Estados de un MIDlet durante la ejecucion

Durante la ejecucion, el MIDlet pasa por tres estados que son: activo, pausa y destruido.

El MIDlet solo podra estar en un estado a la vez, lo cual es controlado por el AMS, pero

un MIDlet tambien puede cambiar de estado por sı mismo si se hace una llamada a sus

correspondientes metodos.

El MIDlet inicialmente se carga en memoria y pasa al estado Pausa. Se ejecuta el

constructor y si no ha existido ningun problema pasa al estado Activo. Este es el estado

en el cual el MIDlet esta en ejecucion. Durante el estado Activo, el MIDlet puede pasar

al estado de Pausa por una accion del usuario, o bien, por el AMS que reducirıa en todo

lo posible el uso de los recursos del dispositivo por parte del MIDlet.

El MIDlet podra estar entre los estados Activo y Pausa todas las veces que sea nece-

sario, pero solo puede ser destruido una vez. Cuando el MIDlet pasa a estar en el estado

Destruido, el AMS libera todos los recursos ocupados por la aplicacion.

La Figura 6.4 muestra los estados de un MIDlet durante su ejecucion y los metodos

correspondientes para pasar de un estado a otro.

6.7.3 Estructura de un MIDlet

A continuacion se mostrara la estructura o esqueleto tıpico de un MIDlet:

import javax . m i c roed i t i on . mid let . ∗ ;

public class <nombre de l a c l a s e > extends midlet

//Metodo que se l lama a l pasar de es tado Pausado a Activo

protected void startApp ( )


ACTIVO

PAUSADO

DESTRUIDO

New()

startApp() pauseApp()

destroyApp()

destroyApp()

Figura 6.4: Estados de un MIDlet.

/∗ En e s t e metodo se inc l uye e l c od igo que se e j e cu ta cuando e l

MIDlet se a c t i v a . ∗/

//Metodo que se l lama a l pasar de es tado Activo a Pausado

protected void pauseApp ( )

//Metodo que se l lama a l d e s t r u i r s e e l MIDlet

protected void destroyApp (boolean i n c ond i c i o n a l )

/∗ En e s t e metodo se inc l uye e l c od igo que e l MIDlet e j e cu ta cuando

es de s t ru i do . Normalmente aqu ı se l i b e r a ran l o s recursos ocupados

por e l MIDlet como memoria , e t c . ( Opcional ) ∗/

6.7.4 Etapas del proceso de desarrollo de un MIDlet

A continuacion se describe brevemente las etapas del proceso de desarrollo de un MIDlet,

aunque cualquier aplicacion en Java sigue este proceso, excepto las etapas de empaque-

tamiento y preverificacion que son exclusivas de la plataforma J2ME.

• Desarrollo. Escritura del codigo que conforma el MIDlet.


• Compilacion. Compilacion de la aplicacion mediante un compilador J2SE.

• Preverificacion. Comprobar que el codigo del MIDlet no viola ninguna restriccion

de seguridad de la plataforma J2ME.

• Empaquetamiento. Creacion del archivo .jar que contiene los recursos de la apli-

cacion, ası como de un archivo descriptor .jad.

• Ejecucion. Mediante un emulador que permita ejecutar el MIDlet.

• Depuracion. Deteccion de fallos detectados en el MIDlet durante la anterior fase

de ejecucion.

6.7.5 Creacion de MIDlets

Existen diferentes herramientas validas para construir programas bajo el standard J2ME,

como el Sun One Studio de Sun Microsystems o el Jbuilder de Borland. El presente

proyecto hace uso de la herramienta J2ME Wireless Toolkit version 2.5.2 que proporciona

Sun.

Para instalar J2ME Wireless Toolkit, primero se debe instalar el entorno de progra-

macion de J2SE (JDK), el cual proporciona la base sobre la que se instalan el resto

de aplicaciones. A continuacion se instalara el J2ME Wireless Toolkit, el cual ofrece

un entorno de compilacion, depuracion y ejecucion para la creacion de MIDlets bajo la

plataforma J2ME.

El primer paso para la creacion de un MIDlet despues de la instalacion del J2ME

Wireless Toolkit sera inicializar el entorno y crear un nuevo proyecto pulsando sobre el

boton New Project de la pantalla principal de la aplicacion. Durante la creacion de un

nuevo proyecto se incluira el nombre del proyecto y el de la clase principal como lo muestra

la Figura 6.5.

Como resultado se creara una carpeta con el nombre del proyecto dentro del directorio

j2mewtk/2.5.2/apps, la cual contiene una serie de carpetas que son:

• bin: contiene los ficheros resultantes de la compilacion y verificacion del codigo.


Figura 6.5: Creacion de un nuevo proyecto con el J2ME Wireless Toolkit

• res: contiene los recursos que se van a utilizar, por ejemplo, imagenes, sonidos,

archivos de datos, etc.

• src: contiene el codigo fuente de las clases que componen la aplicacion. Todos los

archivos .java deben encontrarse en este directorio.

• classes y tmpclasses: directorios secundarios con clases temporales de la apli-

cacion.

La aplicacion se podra desarrollar con cualquier editor de textos, para el presente

proyecto se ha utilizado la herramienta Notepad++ 3, la unica condicion es que los ficheros

residan en los directorios antes mencionados.

La compilacion se debera efectuar bajo el entorno del Wireless Toolkit. Este en-

torno ofrece una serie de posibilidades de depuracion y emulacion que dependen de la

version instalada. Una vez creados los archivos fuentes y colocados en el directorio src

anteriormente comentado, se pulsara el boton Build de la pantalla principal. En ese mo-

mento se realiza la compilacion y la preverificacion de clases. Posteriormente se ejecuta

3Notepad++ es un editor gratuito de codigo fuente, que soporta varios lenguajes de programacion yse ejecuta en MS Windows.


Metodos Descripcion

Displayable getCurrent() Devuelve la pantalla actual.void setCurrent(Alert a, Displayable d) Establece la pantalla d despues de la alerta

a.void setCurrent(Displayable d) Establece la pantalla actual.void setCurrent(Item item) Establece la pantalla en la zona donde se en-

cuentre el item.

Tabla 6.8: Metodos de la clase Display.

Project>Package>Create Package en la barra de menus, para el empaquetamiento de to-

dos los recursos (clases, imagenes, datos, etc..) necesarios para la ejecucion. Los archivos

resultantes son dos: archivo.jar y archivo.jad comentados anteriormente.

6.8 INTERFAZ DE USUARIO DE MIDP

El paquete javax.microedition.lcdui es el que aporta las clases y metodos necesarios para

construir la interfaz grafica en el dispositivo y gestionar las distintas pantallas que podrıa

tener la aplicacion.

Dentro del paquete que nos aporta MIDP para realizar la interfaz de usuario se pueden

hacer dos grandes divisiones: la API de interfaz de usuario de alto nivel y la API de interfaz

de usuario de bajo nivel. En la Figura 6.6 se muestra la interfaz grafica de usuario con

sus respectivas clases y subclases.

6.8.1 Clase Display

La clase Display (public class Display) representa el manejador de la pantalla y los dis-

positivos de entrada, por lo cual todo MIDlet debe poseer por lo menos un objeto Display,

en el que se puede incluir tantos objetos Displayable como se requiera. Los metodos de

esta clase que tienen mayor relevancia para el presente proyecto son los mostrados en la

Tabla 6.8

6.8.2 Clase Displayable

La clase Displayable (public abstract class Displayable) representa a las pantallas de una

aplicacion. La clase abstracta Displayable incluye los metodos encargados de manejar

los eventos de pantalla y anadir o eliminar comandos, algunos de estos metodos son los

mostrados en la Tabla 6.9.


DISPLAY

Command Displayable

Ticker Screen Canvas Graphics

Interfaz de alto nivel Interfaz de bajo nivel

Textbox List Alert Form

ITEM

ChoiceGroup DateField TextField Gauge ImageItem StringItem

Figura 6.6: Jerarquıa de clases derivadas de Display e Item.

Metodos Descripcion

void addComand(Command cmd) Anade el Command cmd.void removeCommand(Command cmd) Elimina el Command cmd.void setCommandListener(CommandListener l) Establece un listener para la cap-

tura de eventos.void setTicker(Ticker ticker) Establece un Ticker a la pantalla.

Tabla 6.9: Metodos de la clase Displayable.


Tipo Descripcion

BACK Peticion para volver a la pantalla anterior.CANCEL Peticion para cancelar la accion en curso.EXIT Peticion para salir de la aplicacion.HELP Peticion para mostrar informacion de ayuda.ITEM Peticion para introducir el comando en un

”item” en la pantalla.OK Peticion para mostrar informacion de ayuda.SCREEN Para Commands de proposito mas general.STOP Peticion para parar una operacion.

Tabla 6.10: Tipos de los objetos Command.

6.8.3 Clases Command y CommandListener

Un objeto de la clase Command mantiene informacion sobre un evento y se lo imple-

menta cuando se requiere detectar y ejecutar una accion simple, es similar a un boton en

Windows.

El formato para crear un objeto Command es el siguiente:

new Command(”Etiqueta”,Tipo,Prioridad)

Donde ”Etiqueta” es el texto que identifica al Command, Tipo que puede ser cualquiera

de las opciones mostradas en la Tabla 6.10 y Prioridad que indica al AMS el orden de

aparicion del Command en pantalla.

En cualquier MIDlet que se incluya Commands, se debe implementar la interfaz Com-

mandListener, la cual incluye un metodo commandAction(Command c, Displayable d)

en donde se indica la accion que se quiere realizar cuando se produzca un evento en el

Command c que se encuentra en el objeto Displayable d.

6.9 INTERFAZ DE USUARIO DE ALTO NIVEL

La clase Screen hereda directamente de Displayable y permite crear las interfaces graficas

de alto nivel. Un objeto que herede de la clase Screen sera capaz de ser mostrado en la

pantalla. Se dispone de cuatro clases que heredan de Screen y son las siguientes:

1. Clase Alert. Permite mostrar una pantalla de texto durante un tiempo o hasta


que se produzca un comando de tipo OK. Se utiliza para mostrar errores u otro tipo

de mensajes al usuario. Su constructor tiene la siguiente forma:

Alert (String tıtulo, String txt alerta, Image img alerta, AlertType tipo)

El tipo de alerta puede ser uno de los siguientes:

• ALARM

• CONFIRMATION

• ERROR

• INFO

• WARNING

La diferencia entre uno y otro tipo de alerta es basicamente el tipo de sonido o

efecto que produce el dispositivo.

2. Clase List. Mediante la clase List se puede crear listas de elementos seleccionables,

su constructor tiene el siguiente formato:

List (String tıtulo, int tipo lista, String[ ] elementos, image[ ] imagenes)

Los posibles tipos de lista son:

• EXCLUSIVE: solo se puede seleccionar un elemento.

• IMPLICIT: se selecciona el elemento que tiene el foco.

• MULTIPLE: permite la seleccion multiple.

3. Clase TextBox. Esta clase permite introducir y editar texto a pantalla completa.

Su constructor presenta el siguiente formato:

TextBox (String tıtulo, String texto, int tamano max, int limitacion)


Metodos Descripcion

Int append(Image imagen) Anade una imagen al formulario.int append(Item item) Anade un Item al formulario.int append(String texto) Anade un String al formulario.void delete(int num) Elimina el Item que ocupa lo posicion num.void deleteAll() Elimina todos los Items del formulario.Item get(int num) Devuelve el Item que se encuentra en la posicion num.

Tabla 6.11: Metodos de la clase Form.

Donde el parametro limitacion puede ser alguna de las siguientes:

• ANY: sin limitacion.

• EMAILADDR: solo una direccion de email.

• NUMERIC: solo se permiten numeros.

• PASSWORD: los caracteres no seran visibles.

• PHONENUMBER: solo numero de telefono.

• URL: solo direcciones URL.

El parametro tamano max indica el maximo numero de caracteres que se pueden

introducir y el parametro texto es el texto inicial que mostrara la caja.

4. Clase Form. Un Form es un elemento de tipo contenedor, es decir, es capaz de

contener una serie de elementos visuales con los que se puede construir interfaces mas

elaboradas. Los elementos que se pueden anadir a un formulario son los derivados

de la clase Item que se muestran en la Figura 6.6. La clase Item representa a

un elemento visual que no ocupara toda la pantalla, sino que formara parte de la

interfaz de usuario junto con otros elementos. Algunos de los principales metodos

de la clase Form se observan en la Tabla 6.11.

5. Clase StringItem. La funcion de esta clase es anadir etiquetas de texto al formu-

lario. El constructor de esta clase tiene el siguiente formato:

StringItem (String etiqueta, String texto)


6. Clase ImageItem. Con esta clase podemos anadir elementos graficos a un formu-

lario. El constructor tiene la siguiente forma:

ImageItem (String etiqueta, Image img, int layout, String texto alternativo)

El parametro texto alternativo es un texto que se mostrara en el caso en el que no

sea posible mostrar el grafico. El parametro layout indica como se posicionara el

grafico en la pantalla. Sus posibles valores son:

• LAYOUT DEFAULT

• LAYOUT LEFT

• LAYOUT RIGHT

• LAYOUT CENTER

• LAYOUT NEWLINE BEFORE

• LAYOUT NEWLINE AFTER

7. Clase TextField. Esta clase es muy similar a la clase TextBox con la diferencia que

TextField esta disenada para integrarse dentro de un formulario en vez de ocupar

toda la pantalla. El constructor de esta clase es similar a la de TextBox :

TextField (String etiqueta, String texto, int tamano max, int limitacion)

8. Clase DateField. Este elemento permite la entrada de datos de tipo fecha o tipo

hora. El constructur tiene el siguiente formato:

DateField (String etiqueta, int modo)

El parametro modo puede tomar cualquiera de los siguientes valores:

• DATE TIME

• DATE TIME


9. Clase ChoiceGroup. Este elemento es similar al de la clase List con la diferencia

que ChoiceGroup puede incluirse dentro de un formulario. El constructor de esta

clase es basicamente el mismo que el de la clase List.

10. Clase Gauge. Representa un elemento tipo barra de estados que permite indicar

un valor graficamente. El constructor tiene la siguiente forma:

Gauge (String etiqueta, bolean interactivo, int val max, int val ini)

Los parametros val ini y val max indican el valor inicial y el valor maximo de la

barra grafica. El parametro interactivo si esta a true, permitira al usuario modificar

el valor de la barra, si no, solo podra mostrar informacion.

Informacion mas detallada de la clases de la interfaz grafica de usuario de alto nivel

ası como de sus respectivos metodos se pueden encontrar en [17].

6.10 INTERFAZ DE USUARIO DE BAJO NIVEL

La clase Canvas es la superclase de todas las pantallas que usan las APIs de bajo nivel,

al igual que Screen lo era para las pantallas que usaban las APIs de alto nivel. En un

mismo MIDlet se puede utilizar pantallas tanto derivadas de Canvas como de Screen.

La clase Canvas permite manejar eventos de bajo nivel y dibujar cualquier cosa por

pantalla. Esta clase posee un metodo abstracto paint() que debe ser implementado obliga-

toriamente y es el que se encarga de dibujar en la pantalla del dispositivo.

A continuacion se describira brevemente las caracterısticas de la clase Canvas y sus

metodos principales. Mayor informacion de la interfaz de usuario de bajo nivel, ası como

de sus metodos se puede encontrar en [17].

6.10.1 Eventos de bajo nivel

Los eventos dentro de la clase Canvas pueden ser manejados de dos formas distintas:

• A traves de Commands.

• A traves de codigos de teclas que son valores numericos que estan asociados a las

diferentes teclas de un dispositivo.


La API de bajo nivel tiene dos funciones principales: controlar los eventos de bajo

nivel y controlar que aparece en la pantalla del dispositivo MID. Canvas proporciona

ciertos metodos para manipular elementos en pantalla y especialmente la clase Graphics.

6.10.2 Metodo paint()

La clase Canvas posee un metodo abstracto paint(Graphics g) que se ocupa de dibujar el

contenido de la pantalla, para lo cual se usa un objeto de la clase Graphics que es el que

contiene las herramientas graficas necesarias y que se pasa como parametro al metodo

paint(). Para implementar este metodo se debe considerar lo siguiente:

• El metodo paint() nunca debe ser llamado desde el programa porque es el gestor

de aplicaciones el que se encarga de realizar la llamada a este metodo cuando sea

necesario.

• Cuando se deba redibujar la pantalla actual debido a alguna accion en concreto del

usuario o como parte de alguna animacion, se debe realizar una llamada al metodo

repaint().

• La implementacion del dispositivo MID no se encarga de limpiar la pantalla antes

de cada llamada al metodo paint(), sino que se debe pintar cada pixel de la pantalla

y ası evitar porciones no deseadas de pantallas anteriores.

6.10.3 Clase Graphics()

Un objeto Graphics proporciona la capacidad de dibujar en una pantalla Canvas y se lo

puede obtener de dos maneras:

• Dentro del metodo paint() de la clase Canvas.

• A traves de una imagen.

La clase Graphics posee multitud de metodos que permiten seleccionar colores, dibujar

texto, figuras geometricas, etc. Estos metodos pueden verse con mayor detalle en [17].


6.11 RECORD MANAGEMENT SYSTEM

El RMS (Record Management System) es un pequeno sistema de bases de datos que

permite anadir informacion en una memoria no volatil del movil. En una base de datos

RMS, el elemento basico es el registro (record). Un registro es la unidad de informacion

mas pequena que puede ser almacenada. Los registros son almacenados en un recordStore

que puede visualizarse como una coleccion de registros.

Cuando se almacena un registro en el recordStore, a este se le asigna un identificador

que identifica unıvocamente al registro. Para poder utilizar RMS se debe importar el

paquete javax.microedition.rms. Algunas operaciones basicas con registros son las siguien-

tes:

• Abrir y cerrar un recordStore. Para abrir un recordStore se utiliza el metodo

openRecordStore(), mientras que para cerrar el recordStore se utiliza el metodo

RecordStore.closeRecordStore()

• Anadir registros. Una vez abierto el recordStore se pueden anadir registros con

el metodo addRecord().

• Leer registros. Para leer registros se utiliza el metodo getRecord(), el cual permite

acceder al registro deseado, siempre que se conozca su identificador.

• Borrar registros. El borrado de registros se realiza con el metodo deleteRecord().

• Recorrer registros. Se hace uso del objeto RecordEnumeration para recorrer todos

los registros almacenados en la base de datos. Para crear una enumeracion se utiliza

el metodo enumerateRecords().

Una descripcion mas detallada de estos metodos y del Record Management System se

encuentra en [17].

6.12 WIRELESS MESSAGING API

WMA es una extension de las especificaciones de CLDC y MIDP para el envıo, la recepcion

y la gestion de SMS desde MIDLets. El API esta compuesto de interfaces ubicadas


Interfaz Descripcion Metodos

Message Interfaz base, de la que derivan getAddress()TextMessage y BinaryMessage getTimestamp()

setAddress()BinaryMessage Subinterfaz de Message que pro- getPayloadData()

porciona metodos para fijar y de- setPayloadData()tectar el payload binario

TextMessage Subinterfaz de Message que pro- getPayloadText()porciona metodos para fijar y de- setPayloadText()tectar el payload de texto

MessageConnection Interfaz a traves de la cual se rea- newMessage()liza el envıo y la recepcion de receive()mensajes send()

setMessageListener()numberOfSegments()

MessageListener Define la interfaz listener paraimplementar la notificacionasıncrona de objetos Message

notifyIncomingMessage()

Tabla 6.12: Clases en javax.wireless.messaging.

bajo el paquete javax.wireless.messaging. Estas interfaces con sus respectivos metodos se

muestran en la Tabla 6.12.

Los javax.wireless.messaging.MessageConection pueden funcionar de dos modos:

• En modo cliente. Solo sirve para enviar SMS a un destinatario. El modo cliente

se lo especifica de la siguiente manera:

MessageConnection con=(MessageConnection)Connector.open (”sms://+59398646724”);

MessageConnection con=(MessageConnection)Connector.open (”sms://+59398646724:16500”);

En ambos casos el SMS serıa enviado al telefono 098646724 de Ecuador (por el

prefijo +593), pero en el primer caso, el SMS serıa tratado por la aplicacion que por

defecto tiene instalada el telefono, mientras que, en el segundo caso, el SMS serıa

tratado por la aplicacion que este escuchando en el puerto 16.500.

• En modo servidor. Sirve para recibir y tratar los SMS que son dirigidos hacia el.

En este modo tambien se pueden enviar SMS. El modo servidor se especifica de la

siguiente manera:


MessageConnection conn = (MessageConnection)Connector.open(”sms://:16500”);

De esta manera los SMS que llegen al puerto 16.500 seran atendidos por el MIDLet.

La especificacion del modo de funcionamiento deseado se lo realiza a traves de la

cadena de conexion que se le pasa a la clase javax.microedition.io.Connector.

6.13 EL API PUSH REGISTRY

Push Registry forma parte del AMS y permite la ejecucion de MIDlets sin intervencion

del usuario.

Un MIDlet puede ser iniciado de dos formas:

• A traves de una alarma o temporizador.

• A traves de una conexion entrante que puede ser una conexion TCP, un datagrama

UDP o un SMS.

6.13.1 Metodos

Esta API tiene como corazon la clase javax.microedition.io.PushRegistry. Algunos metodos

de esta clase son los siguientes:

• public static String getMIDlet(String connnectionString). Devuelve el nombre de la

clase del MIDlet responsable de tratar la conexion especificada como parametro.

• public static String[] listConnections(boolean available). Devuelve una lista con to-

das las cadenas de conexion registradas por el MIDletSuite del que forma parte el

MIDlet. Si se especifica available a true, solo se devolveran aquellas cadenas de

conexion cuyo javax.microedition.io.Connection asociado tengan datos pendientes

de ser tratados.

• public static void registerConnection(String connection, String midlet, String filter).

Registra de manera dinamica una conexion.


– connection: es la cadena de conexion en la que se registra el MIDlet, por

ejemplo:

sms://:16500. Cadena de conexion valida para que el MIDlet trate los SMS

dirigidos al puerto 16.500 del terminal.

– midlet: nombre de la clase del MIDlet que sera activado.

– filter: los filtros que deben cumplir los emisores de la informacion que activa

el MIDlet.

• public static boolean unregisterConnection(String connection). Desregistra dinamicamente

una conexion registrada para el MIDlet que lo invoca.

Para saber si un MIDlet ha sido iniciado por el usuario o por un evento externo se

deben escribir las siguientes lıneas de codigo en el metodo startApp() del MIDlet.

// Obtenemos l a l i s t a de conexiones de l MIDlet

St r ing [ ] connec t i ons = PushRegistry . l i s tConne c t i on s ( true ) ;

i f ( ( connec t i ons == null ) | | ( connec t i ons . l ength == 0))

/∗ El MIDlet ha s ido in i c i ado por e l usuar io a t r a v e s de l a i n t e r f a z

g r a f i c o de l termina l . ∗/

else

/∗ El MIDlet ha s ido in i c i ado por una conexi on entrante o una

alarma . ∗/

6.13.2 Conexiones SMS

Es importante anotar que el MIDlet puede iniciar una conexion (HTTP, socket, etc.)

despues que ha sido activada por un mensaje entrante, si en lo posterior se requiere

intercambiar datos.

El numero de puerto especificado puede estar en el rango de 1 a 65.535, sin embargo

los puertos mostrados en la Tabla 6.13 estan reservados y no deben usados.


Puerto Descripcion

2805 WAP WTA secure connectionless session service2923 WAP WTA secure session service2948 WAP Push connectionless session service2949 WAP Push secure connectionless session service5502 Service Card Reader5503 Internet access configuration reader5508 Dynamic Menu Control Protocol5511 Message Access Protocol5512 Simple e-mail Notification9200 WAP connectionless session service9201 WAP session service9202 WAP secure connectionless session service9203 WAP secure session service9207 WAP vCal Secure49996 SyncML OTA configuration49999 WAP OTA configuration

Tabla 6.13: Puertos reservados que no deben usarse para registrar una conexion SMS.

DISENO DEL PROTOTIPO 78

CAPITULO 7

DISENO DEL PROTOTIPO


Este capıtulo describe en primera instancia, el funcionamiento general del prototipo que

contempla el presente proyecto, denominado Sistema de Control y Localizacion (SCL), el

mismo que consta de dos partes principales: una Tarjeta de Control y Localizacion (TCL)

y una interfaz de usuario desarrollada en J2ME. Posteriormente, se detalla el diseno del

hardware de la TCL, describiendo sus componentes, la interconexion entre los mismos y

sus consideraciones tecnicas.

A continuacion, se describe el software desarrollado para el PIC16F877A, que realiza

el control y monitoreo de la TCL, ası como el software desarrollado en J2ME para la

interfaz de usuario. Finalmente, se evalua el costo total de este sistema.

7.2 FUNCIONAMIENTO GENERAL DEL SCL

El funcionamiento del SCL se basa en la interaccion de sus componentes principales: la

TCL y la interfaz en J2ME. La interfaz en J2ME es una aplicacion que permite al usuario

enviar a la TCL peticiones de control de salidas, de reporte del estado de entradas y

salidas, de localizacion y de temperatura, haciendo uso de los mensajes SMS. La TCL,

por su parte, receptara y procesara estas peticiones, realizara las operaciones solicitadas y

finalmente retornara un mensaje SMS de notificacion o reporte. Estas partes se muestran

en la Figura 7.1 y a continuacion se describen brevemente:

• TCL. Esta gobernada por un microcontrolador PIC16F877A que se encarga del con-

trol de salidas, monitoreo de entradas, adquisicion de la senal analogica proveniente

de un sensor, y la comunicacion con un modem GSM y con un modulo receptor GPS.


Celular del

usuario

(Interfaz J2ME )Red GSM

Modem GSMGPS

Microcontrolador

PIC

Salidas

digitalesdigitales

Entradas Entrada

analogica

Etapa de

potenciaTarjeta de Control y Localizacion (TCL)

5

4

2

RX2 TX1 RX1

Figura 7.1: Diagrama de bloques del SCL.


El microcontrolador es el encargado de interpretar los mensajes SMS de entrada, y

codificar en modo PDU los mensajes SMS de reporte destinados hacia el telefono

celular del usuario, de acuerdo a sus requerimientos.

La TCL ademas, consta de 5 salidas y 5 entradas. Las 5 salidas se dividen en 3

digitales y 2 de potencia, y las 5 entradas se dividen en 4 digitales y una analogica,

la cual ha sido considerada para sensar temperatura.

El bloque de acceso a la red GSM esta conformado por un modem GSM de un

celular en desuso. En este caso se ha utilizado un telefono de la marca Sony Ericsson,

modelo T290a. Este modem se comunica vıa serial con el microcontrolador mediante

comandos AT especıficos para el servicio de mensajes cortos.

El bloque que permite obtener la posicion geografica de la TCL se compone del

modulo receptor GPS GS405, del fabricante SPK Electronics Co., Ltd. Este modulo

envıa la informacion de posicionamiento al microcontrolador a traves de comuni-

cacion serial utilizando el protocolo NMEA.

• Interfaz de usuario. Se trata de una aplicacion en J2ME, constituida por menus

y formularios que permiten al usuario la interaccion con el SCL de una manera facil

y amigable. Esta aplicacion se instalara en el telefono celular del usuario, el cual

debe soportar la plataforma J2ME (configuracion CLDC 1.0 y Perfil MIDP 2.0).

Esta aplicacion se encarga de enviar las peticiones del usuario y atender los reportes

y notificaciones provenientes de la TCL, a traves de mensajes SMS.

7.3 HARDWARE

En esta seccion se describira el hardware de la TCL, el cual se compone de las siguientes

partes:

• Microcontrolador PIC16F877A

• Modem GSM

• Receptor GPS


Figura 7.2: Distribucion de pines del microcontrolador PIC.

• Entradas y salidas digitales

• Entrada analogica

• Etapa de potencia

• Sistema de alimentacion

7.3.1 Microcontrolador PIC16F877A

Las caracterısticas del PIC16F877A fueron detalladas en el capıtulo 5. En esta subseccion

se describira como se han distribuido los pines del PIC para implementar las diferentes

funciones de control, monitoreo y comunicacion con cada uno de los componentes del

hardware. En la Figura 7.2 y en la Tabla 7.1 se detalla tal descripcion.

7.3.2 Modem GSM

Con el fin de cumplir con el objetivo de reutilizar equipos terminales que se encuentren en

desuso y reducir el costo final del SCL, se ha utilizado para la implementacion del mismo,

el modem GSM embebido en un telefono de la marca Sony Ericsson, modelo T290a que

se presenta en la Figura 7.4. Algunas caracterısticas de este modem son:


No. Nombre del Pin Tipo Funcion Descripcion

13 OSC1/CLKIN I Circuito de reloj Entrada del oscilador de cristal14 OSC2/CLKOUT O Circuito de reloj Salida del oscilador de cristal1 MCLR I Circuito de reset Entrada del Master clear (Reset)2 RA0/AN0 I/O Entrada analogica Entrada del sensor de temperatura3 RA1/AN1 I/O Indicador de salida 1 Indicador de salida digital 14 RA2/AN2 I/O Indicador de salida 2 Indicador de salida digital 25 RA3/AN3 I/O Indicador de salida 3 Indicador de salida digital 333 RB0/INT I/O Comunicacion modem GSM Receptor de comunicacion serial34 RB1 I/O Comunicacion modem GSM Transmisor de comunicacion serial35 RB2 I/O Comunicacion GPS Receptor de comunicacion serial37 RB4 I/O Entrada 4 Entrada digital38 RB5 I/O Entrada 3 Entrada digital39 RB6 I/O Entrada 2 Entrada digital40 RB7 I/O Entrada 1 Entrada digital22 RD3 I/O Salida 5 Salida de potencia27 RD4 I/O Salida 4 Salida de potencia28 RD5 I/O Salida 3 Salida digital29 RD6 I/O Salida 2 Salida digital30 RD7 I/O Salida 1 Salida digital8 RE0/AN5 I/O Led indicador Indicador de I/O de SMS

12,31 Vss P Circuito de alimentacion P=Power. Referencia de tierra11,32 Vdd P Circuito de alimentacion Fuente positiva

Tabla 7.1: Descripcion de la asignacion de pines del microcontrolador PIC.

• Es un modem embebido que puede ser accedido mediante el cable de conexion

RS232.

• Velocidades de transmision de datos hasta 9600 bps.

• Soporta comandos AT. Admite modo texto y modo PDU.

En cuanto a la comunicacion serial entre el modem GSM y el microcontrolador PIC,

esta se configuro con los siguientes parametros:

• Bits por segundo: 9600

• Bits de datos: 8

• Paridad: ninguna

• Bits de parada: 1

• Control de flujo: ninguno


5 V

1

20 21

40

3334

PIC16F877A

(4) (5)

3,3 V

(8) (11)

Rx

Rx

TxTx

AGND

Vcc

pines Modem GSM

pin 4

pin 5

pin 8

pin 11

10kΩ

Figura 7.3: Conexion entre el modem GSM del celular y el microcontrolador PIC.

En la Figura 7.3 se muestra la conexion entre el modem GSM y el microcontrolador.

Es importante mencionar que los pines de transmision y recepcion del microcontrolador

trabajan con niveles TTL de 0-0,8 V para el estado logico 0, y 2-5 V para el estado

logico 1; mientras que el modem GSM del telefono celular trabaja con niveles TTL de

0 V (estado logico 0) y 3,3 V (estado logico 1). Por esta razon, en la conexion entre el

TX del PIC y el RX del modem, fue necesario anadir un circuito regulador con un diodo

zener de 3,3 V para obtener el voltaje deseado en el pin RX y ası, evitar inconvenientes

de incompatibilidad de niveles de voltaje. En el otro sentido de la comunicacion serial

(RX del PIC y TX del modem) no se presenta este inconveniente de incompatibilidad.

7.3.3 Receptor GPS

En la Tabla 4.1 se describieron las especificaciones tecnicas del receptor SPK-GPS-GS405,

el mismo que se ha utilizado para obtener las posiciones de la TCL. Ası tambien, en la

Figura 4.3 y en la Tabla 4.2, se describio la asignacion de pines de este modulo receptor.

En la Figura 7.5 se muestra la conexion para la comunicacion serial entre el modulo

GPS y el microcontrolador PIC, para lo cual se ha utilizado unicamente el pin trans-


(a) Equipo movil.

(b) Puerto del telefono Sony Ericsson T290a.

Figura 7.4: Telefono Sony Ericsson T290a.

No. Nombre del Pin Direccion Descripcion

1 ATMS ⇐= Audio to Mobile Station2 AFMS/RTS =⇒ Audio from Mobile Station/RTS3 CTS/ONREQ - CTS/Mobile Station on Request4 Data in ⇐= Data to mobile (RX)5 Data out =⇒ Data from mobile (TX)6 ACC in ⇐= Accesory control to mobile7 ACC out =⇒ Accesory control from mobile8 AGND - Audio signal ground9 Flash - Flash memory voltage10 DGND - Digital ground11 Vcc - DC Battery charging

Tabla 7.2: Descripcion de pines del puerto del telefono Sony Ericsson T290a.


PSfrag

1

20 21

40

35Rx

PIC16F877A

(10)

(4)

3,3 V

SPK-GPS-GS405

(2)

pin 2

pin 4

pin 10

Vin

Tx

GND

Figura 7.5: Conexion entre el modulo receptor GPS y el microcontrolador PIC.

misor del GPS y un pin para la recepcion en el microcontrolador, pues en este caso la

comunicacion es unidireccional ya que el microcontrolador PIC no enviara informacion al

GPS.

La comunicacion serial entre el modulo receptor GPS y el microcontrolador PIC se

configuro con los siguientes parametros, de acuerdo al protocolo de comunicacion NMEA

tratado en el capıtulo 4:

• Bits por segundo: 4800

• Bits de datos: 8

• Paridad: ninguna

• Bits de parada: 1

• Control de flujo: ninguno


7.3.4 Entradas y salidas digitales

Las entradas digitales tienen como objetivo el monitoreo de distintos sensores que pueden

conectarse a la TCL, de manera que, ante cualquier cambio de estado en uno de ellos se

notifique automaticamente de lo ocurrido al usuario. Por otro lado, las salidas digitales

tienen como funcion controlar diferentes dispositivos que pueden conectarse a esta tarjeta.

Para este proposito, tanto los sensores como los dispositivos, deberan acoplarse a los

voltajes con los que trabaja la logica digital TTL, esto es, 5 V para el estado logico 1, y

0 V para el estado logico 0.

En la Figura 7.2 y en la Tabla 7.1 se indicaron los pines del microcontrolador PIC que

fueron asignados para las entradas y salidas digitales.

1. Entradas digitales. Para el caso de las 4 entradas digitales, se han seleccionado los

pines RB4 al RB7 del puerto B del microcontrolador PIC, aprovechando una de las

interrupciones que ofrece el PIC16F877A relacionada a un cambio en cualquiera de

los bits del nibble mas alto del puerto B, de manera que al producirse esta interrup-

cion, sea posible el tratamiento de esta informacion y la notificacion respectiva al

usuario.

Una consideracion importante respecto al estado de las entradas, es que mientras

estas no se encuentren conectadas a ningun sensor, y por lo tanto, no reciban senal

alguna, el estado por defecto es un 1 logico, debido a que se han activado las re-

sistencias de pull-up1 del puerto B, configurables a traves de software.

2. Salidas digitales. Las salidas digitales tienen una corriente maxima de salida de

25 mA, de acuerdo a las especificaciones electricas del PIC16F877A. Ademas, se

han incluido leds indicadores de estado por cada una de las salidas, con el objetivo

de permitir al usuario visualizar el estado de las mismas.

1El termino resistencia de pull-up, o resistencia de polarizacion, se refiere a una resistencia que poseeuno de sus terminales conectado al polo positivo de la fuente, de manera que fuerce una entrada de uncomponente logico a un nivel alto cuando esta abierta, y la lleve a un nivel bajo al cerrarse, sin producirun cortocircuito.


7.3.5 Entrada analogica

Una pieza fundamental en muchos sistemas de medida y control desarrollados con sistemas

mixtos digitales, es el modulo de conversion A/D. El microcontrolador PIC16F877A in-

corpora un modulo de conversion A/D cuyas principales caracterısticas son:

• Ocho canales de conversion, cinco del puerto A (RA0 a RA5) y tres del puerto E

(RE0 a RE2).

• Resolucion de 10 bits, es decir, convierte la senal analogica en un numero digital de

10 bits (0 a 1023 decimal).

• Tension de referencia seleccionable por software. Puede ser la tension de alimentacion

del microcontrolador o la tension aplicada a los pines RA2 y RA3.

En la TCL se ha considerado que la entrada analogica tenga como objetivo el sen-

samiento de temperatura, para lo cual, se ha conectado directamente al pin RA0 del PIC

la salida del sensor de temperatura LM35DZ mostrado en la Figura 7.6, que presenta las

siguientes caracterısticas:

• Calibrado directamente en grados Centıgrados.

• Factor de escala lineal de +10,0 mV/C.

• Precision de 0,5C (a +25C).

• Evaluado en el rango de -55C a +150C.

• Opera desde 4 a 30 V.

• Baja impedancia de salida, 0,1 Ω para una carga de 1 mA.

Cabe aclarar que este sensor no ha sido incorporado en la TCL, sino que esta conec-

tado externamente para brindar la posibilidad de cambiar el tipo de sensor con ciertas

consideraciones en el programa del PIC que se revisaran mas adelante.


(a) Encapsulado de plastico TO-92.

+VS VOUT GND

(b) Vista desde abajo.

Figura 7.6: Sensor de temperatura LM35DZ.

7.3.6 Etapa de potencia

Como se habıa mencionado anteriormente, la TCL cuenta con dos salidas de potencia que

permiten la conexion de dispositivos que trabajan con corriente alterna.

Para la implementacion de estas salidas se utilizo reles de 6A/250VAC o 6A/28VDC,

max. 10A a 125VAC, los cuales se activan con una tension de 12 V.

Para acoplar estos reles al microcontrolador se implementaron dos circuitos, uno para

cada salida de potencia, que utilizan transistores de proposito general NPN 2N3904. En

la Figura 7.7 se muestra el circuito para una de estas salidas (salida 5). Ademas, se

colocaron leds indicadores para visualizar su estado.

7.3.7 Sistema de alimentacion

La TCL trabaja con tres tensiones para la alimentacion de las distintas partes que la

conforman, las mismas son: 12 V, 5 V y 3,3 V DC. El circuito de este sistema se muestra

en la Figura 7.8.

La tension de 12 V, para el caso de aplicaciones en automoviles, puede ser tomada


1

20 21

40

27

PIC16F877A3,3 kΩ

1,5 kΩ

Led indicador

1N4007

12 VDC

Rele

C

C

NC

NC

NA

NA

Comun

Normalmente abierto

Normalmente cerrado

2N3904

Figura 7.7: Circuito implementado para la etapa de potencia de la salida 5.

de la baterıa de los mismos, y para otras aplicaciones, es necesaria la conexion a una

fuente de alimentacion que suministre este voltaje. Los 12 V permitiran la activacion

de los reles de las salidas de potencia como se muestra en la Figura 7.7, una vez que

los transistores entren en el estado de corte. Ademas, esta tension ingresa a un circuito

regulador de 5 V DC, basado en el integrado LM317, que servira para alimentar tanto al

microcontrolador como al resto de elementos de la TCL, incluyendo la baterıa del telefono

celular con excepcion del modulo receptor GPS.

Por otra parte, debido a que el modulo receptor GPS requiere para su alimentacion

una tension de 3,3 V, se ha implementado un circuito regulador adicional, basado en el

integrado LM1117T, el mismo que se encarga de convertir los 5 V que recibe a su entrada

a 3,3 V.

Las especificaciones tecnicas de los integrados reguladores LM317 y LM1117T se

pueden encontrar en los Apendices D y E, respectivamente.


MicrocontroladorPIC16F877A

modulo receptorGPS

12 VDC

LM317

100 ηF100 ηF

VI VIVO VO

ADJ GND

5 VDC 3,3 VDC

10 µF 10 µF10 µF

220 Ω

670 Ω

LM1117T

Figura 7.8: Sistema de alimentacion de la TCL.

7.3.8 Circuito implementado para la TCL

En la Figura 7.9 se puede observar el circuito esquematico de la TCL. En las Figuras 7.10

y 7.11, se muestran tanto la vista superior como las pistas de la placa de circuito impreso,

y en la Figura 7.12 se puede observar la TCL implementada.

7.4 SOFTWARE

El desarrollo de software constituye una de las partes fundamentales en este proyecto,

puesto que de la programacion dependen: el funcionamiento de la TCL gobernada por

el microcontrolador, la aplicacion de administracion en J2ME para el celular del usuario,

ası como la comunicacion entre estos dos elementos del SCL.

En esta seccion, se describira el desarrollo del software del SCL, el cual se divide en

dos partes importantes que son:

• Programa del microcontrolador PIC16F877A

• Aplicacion de administracion del SCL en J2ME

DIS

EN

OD

EL

PR

OT

OT

IPO

91

Sistema de alimentacion

Comunicacion

Comunicacion

con el modem GSM

Etapa de potencia

con el receptor GPS

Salidas digitales

Entradas

digitales

Entrada

analogica

Fig

ura

7.9

:C

ircuito

esq

uem

atic

ode

laT

CL.


Figura 7.10: Vista superior de la placa de circuito impreso de la TCL.

Figura 7.11: Pistas de la placa de circuito impreso de la TCL.


Figura 7.12: Circuito implementado de la TCL.

7.4.1 Programa del microcontrolador PIC16F877A

El programa realizado para el microcontrolador PIC fue escrito en lenguaje C, utilizando

el compilador de C PCW de CCS Inc. revisado en el capıtulo 5. Este programa permite

que el PIC ejecute todas las operaciones necesarias para cumplir con los propositos de

control y localizacion en forma remota a traves de la red GSM, como son: comunicacion

con el modem GSM y el modulo receptor GPS, recepcion de mensajes SMS en modo texto,

control de salidas, monitoreo de entradas, lectura de la entrada analogica, codificacion y

envıo de los mensajes de notificacion y reporte, en modo PDU.

Para este proposito, en primer lugar se configuraron los parametros del microcon-

trolador necesarios para implementar dos interfaces de comunicacion serial, una para el

modem GSM y otra para el modulo receptor GPS. Ası tambien, se habilito la inter-

rupcion del nibble mas alto del puerto B y las resistencias pull-ups para implementar las

entradas de la TCL. Ademas, se configuro el conversor A/D del microcontrolador para la

adquisicion de la senal analogica proveniente del sensor de temperatura.

El programa permitira al microcontrolador PIC, comunicarse con el modem GSM del

telefono celular a traves de comandos AT para la recepcion y envıo de los mensajes SMS.

Despues de recibir un mensaje SMS proveniente de la aplicacion en J2ME, el microcon-


trolador se encargara de procesarlo para determinar que funcion debe ejecutarse en la

TCL. Si se trata de un mensaje de configuracion, se procede a almacenar en la EEPROM

del microcontrolador el numero del remitente y una clave de emergencia. Si se trata de

un mensaje de control, se activaran o desactivaran las salidas de la TCL de acuerdo a

los requerimientos del usuario. Si es un mensaje de peticion de temperatura se empleara

el conversor A/D para la adquisicion de la senal del sensor. En el caso de una peticion

de localizacion, el microcontrolador se comunicara vıa serial con el modulo receptor GPS

para determinar la posicion de la TCL, empleando el protocolo NMEA. Cada una de

estas funciones genera un reporte que es enviado a la aplicacion en J2ME, en el celular

del usuario, a traves de mensajes SMS, para lo cual se emplea el modo PDU, previo a

una codificacion de la cadena de texto.

La secuencia que sigue este programa se describe en el diagrama de flujo que se muestra

en las Figuras 7.13, 7.14 y 7.15.

Como se menciono en la subseccion 7.3.4, un cambio en el estado de cualquiera de las

entradas de la TCL, activa la interrupcion relacionada al nibble mas alto del puerto B, una

vez que esta haya sido habilitada. Esto produce que la secuencia normal del programa se

interrumpa y de paso a la ejecucion del codigo de la interrupcion cuyo diagrama de flujo

se muestra la Figura 7.16.

A continuacion se describiran las secciones mas relevantes del codigo del programa del

microcontrolador PIC, mencionando ciertas consideraciones que se hicieron en el desarrollo

del mismo. El codigo completo se muestra en el Apendice F, Codigo del programa del

microcontrolador PIC16F877A.

1. Lectura de mensaje SMS. Esta operacion comienza inicializando la variable

buffer, destinada al almacenamiento del mensaje; la configuracion del modem en

modo texto, y el listado de los mensajes no leıdos. Esto se ejecuta de manera con-

tinua en un bucle infinito, de manera que la TCL se encuentre monitoreando la

llegada de un nuevo mensaje.

Cuando no hay mensajes nuevos, el modem responde ”OK” ante el comando AT+CMGL,

mientras que cuando hay un mensaje nuevo, el modem responde con una cadena

de texto similar a la de la Figura 3.5, compuesta de varios campos limitados por


SI

SI

NO

NO

Inicio

Configurar modem GSM

Listar mensajes no leıdos del modem

Configurar conversor A/D

Habilitar interrupcion en el nibble

mas alto del Puerto B (RB4-RB7)

Configurar Puerto Bcomo entradas y activar pull-ups

Inicializar buffer

¿SMS nuevo?

Almacenar SMS en buffer

¿buffer vacıo?

1

2

Figura 7.13: Diagrama de flujo del programa del Microcontrolador PIC (I).


SI

SI

SI

SI

SISI

NO

NO

NO

NONO

1

2

3

¿clave correcta?

Leer numero del remitente

¿Comando CONFIGURAR?

Guardar numero y clave SOS

en la EEPROM

Enviar SMS de confirmacion(modo PDU)

¿No. remitente = No. usuario?

¿clave SOS correcta?

¿Comando ON?

Activar salida 1

¿Comando OFF?

Desactivar salidas

Figura 7.14: Diagrama de flujo del programa del Microcontrolador PIC (II).


SI

SI

SI

SI

NO

NO

NO

NO

1

1

2

3

¿Comando CONTROLAR?

Controlar salidas

Enviar SMS de confirmacion

(modo PDU)

(modo PDU)

(modo PDU)

(modo PDU)

¿Comando ENT ANALOG?

Adquirir temperatura del sensor

Enviar SMS de reporte de temperatura

¿Comando REPORTAR?

Leer estado de entradas y salidas

Enviar SMS de reporte

¿Comando DATOS GPS?

Adquirir posicion desde elmodulo receptor GPS

Enviar SMS de reporte de posicion

Figura 7.15: Diagrama de flujo del programa del Microcontrolador PIC (III).


Inicio de interrupcion

Leer estado de las entradas

Enviar SMS de notificacionde cambio de las entradas

(modo PDU)

Fin de interrupcion

Figura 7.16: Diagrama de flujo de la interrupcion por cambio en el nibble mas alto delPuerto B.

el caracter (”, comillas) y finalizando nuevamente con la cadena ”OK”. Por esta

razon, el caracter ’K’ de esta cadena se utilizo para determinar el fin del mensaje

de texto. Ası tambien, se puede apreciar que a partir de la tercera comilla empieza

el numero de telefono del remitente, y a partir de la octava, empieza el contenido

del mensaje propiamente dicho. Por lo tanto, se ha utilizado un contador del carac-

ter (”) para capturar unicamente estos dos campos, que son los que contienen la

informacion relevante para los fines del proyecto. Si no hubiera mensajes nuevos, la

variable buffer permanecerıa vacıa.

Para continuar con el procesamiento de esta informacion se procede a verificar que

la variable buffer no se encuentre vacıa, caso contrario, se regresa al inicio del bucle

en espera de un mensaje nuevo.

while (1 )

//LECTURA DEL MENSAJE SMS

puer to e=0x01 ; // enciende l ed ind icador ( esperando sms nuevo )

con t com i l l a =0;

i n i t b u f f e r ( ) ; // i n i c i a l i z a l a v a r i a b l e b u f f e r

i n i t a ux ( ) ;

for ( i =0; i <10; i++)

numero [ i ]=0x00 ;

num usr [ i ]=0x00 ;


delay ms ( 5 00 ) ;

f p r i n t f (CEL, ”AT+CMGF=1\r \n” ) ; // con f i gura modo t e x t o

delay ms ( 5 00 ) ;

f p r i n t f (CEL, ”AT+CMGL=\”REC UNREAD\”\ r \n” ) ; // l i s t a mensajes no l e ı d o s

while (1 )

ca r c r cb=getc (CEL) ; // captura carac t e r e s proven ien te s de l modem gsm

i f ( c a r c r cb==0x22 ) //compara con e l carac t e r de comi l l a s (”)

con t com i l l a++;

i f ( c on t com i l l a==3 | | con t com i l l a==8)

bu f f e r [ c on t bu f f e r++]=ca r c r cb ; /∗almacena numero de l remitente y

contenido de l sms∗/

i f ( c a r c r cb==’K’ ) // carac t e r l im i t ador de f i n de sms

bu f f e r [ c on t bu f f e r ]=0x00 ;

puer to e=0x00 ; //apaga l ed ind icador ( procesando sms nuevo )

break ;

i f ( strcmp ( bu f f e r , 0 x00 ) ) // v e r i f i c a que e l b u f f e r no e s t e vac ıo

// procesamiento de l contenido de l mensaje

2. Validacion de clave y numero del remitente. Todos los mensajes SMS prove-

nientes de la aplicacion J2ME, llevan como cabecera una clave que permite diferen-

ciarlos de otros mensajes que puedan llegar al modem GSM. La clave utilizada en

esta ocasion es SCL1 (siglas de Sistema de Control y Localizacion, version 1). Para

realizar la validacion de la clave se realiza una busqueda de la cadena SCL1 den-

tro de la cadena de texto leıda desde el modem por el microcontrolador. Si existe,

significa que efectivamente se trata de un mensaje de la aplicacion en J2ME y se

procedera con el procesamiento de los datos enviados, caso contrario, el mensaje

sera descartado y se regresara a inicializar el buffer y esperar por un mensaje nuevo.

Una vez realizada la validacion de la clave, la TCL lee el numero del remitente y

procede a detectar si se trata de un mensaje de configuracion, como el mostrado

en la Tabla 7.3, buscando la cadena ”CF” dentro de el. Si se la encuentra, se

procedera a guardar dicho numero en la memoria EEPROM para que los mensajes


posteriores puedan ser comparados con este numero y determinar si provienen del

usuario correcto; caso contrario, lo descartarıa, aun si existiera la clave SCL1. Por

lo que es necesario, que tanto la clave del sistema como el numero de telefono del

usuario, sean los autorizados.

Despues del proceso anterior, se guardara tambien en la memoria EEPROM, la clave

de emergencia (clave SOS) que corresponde a la cadena de numeros escritos despues

de la ultima ’C’. Esta clave de emergencia ha sido configurada para el caso en el que

el usuario haya extraviado el telefono celular en el cual instalo la aplicacion J2ME,

y permite la ejecucion de funciones de control de manera limitada.

Como se describio al inicio de este capıtulo, se ha disenado una aplicacion en J2ME

que es la unica capaz de interactuar con la TCL, por lo que es necesaria su insta-

lacion en el telefono del usuario, para poder realizar las operaciones de control y

localizacion. La clave de emergencia permitira ejecutar acciones de control (limi-

tadas) desde cualquier telefono celular, por lo tanto es importante que el usuario la

configure y la recuerde.

Finalmente, se enviara una notificacion al usuario, confirmando que el sistema se ha

configurado correctamente. La cadena de confirmacion se muestra en la Tabla 7.4.

i n i t a ux ( ) ;

//VALIDACION DE LA CLAVE DEL SISTEMA

s t r cpy ( aux , c l ave ) ;

i f ( s t r s t r ( bu f f e r , aux )!=NULL) /∗ va l i d a que e x i s t a l a

c l a v e de l s i s tema en l a cadena de t e x t o ∗/

//LEER NUMERO DEL REMITENTE

pos=s t r r c h r ( bu f f e r , 0 x22 ) ; // l o c a l i z a l a u l t ima comi l l a (”)

for ( i =0; i <8; i++)

−−pos ;

num usr [8− i ]=∗pos ; //almacena l o s d ı g i t o s d e l numero de l remitente

num usr [0 ]= ’ 0 ’ ;

//CONFIGURACION DEL NUMERO DEL USUARIO Y CLAVE DE EMERGENCIA

i n i t a ux ( ) ;

s t r cpy ( aux ,CONFIGURAR) ;

i f ( s t r s t r ( bu f f e r , aux )!=NULL) /∗ v e r i f i c a s i e x i s t e ”CF” dentro de l a cadena de


Codigo Tipo de mensaje Descripcion

SCL1CFC<####> Configuracion Configuracion del numero de telefono delusuario y clave de emergencia. El numerodel usuario se obtiene del campo corres-pondiente en el mensaje entrante. Losnumeros enviados despues de la ultima ’C’(<####>) corresponden a la clave deemergencia.

SCL1CTS<#####> Control de salidas De izquierda a derecha se encuentran enorden los estados de las salidas, de la 1 ala 5 (4 y 5 de potencia), donde # puedeser 1 o 0 (1=activar, 0=desactivar).

SCL1RP Reporte Indica a la TCL que se envıe un reportede los estados de las entradas y salidas.

SCL1GP Localizacion Indica a la TCL que se envie un reporte desu posicion actual, para lo cual hace usodel modulo receptor GPS.

SCL1AN Entrada analogica Indica a la TCL que se envıe un reportedel valor adquirido desde el sensor de tem-peratura.

SOS<####><estado> Emergencia Este mensaje puede ser enviado desdecualquier celular siempre y cuandose conozca la clave de emergencia(<####>). La palabra estado puedeser ”ON” u ”OFF”. ”ON” indica a laTCL que encienda la salida 1, ”OFF”indica a la TCL que apague todas lassalidas.

Tabla 7.3: Codigos utilizados en los mensajes enviados desde la aplicacion J2ME al modemGSM de la TCL.


Codigo Tipo de mensaje Descripcion

CF Configuracion Confirmacion que indica que el sis-tema se configuro exitosamente.

AKS<#####> Control de salidas Confirmacion de control de salidas,se envıa tambien el estado en elque se encuentran las salidas actual-mente.

RPS<#####>E<####> Reporte Reporte del estado actual de salidasy entradas.

GPA<####.####><lat>

<#####.####><lon>

Localizacion Reporte de la posicion actual de laTCL. El caracter ’A’ indica que laposicion es valida. El campo lat

puede ser ’S’ o ’N’ y el campo lon

puede ser ’E’ o ’W’.

AN<##.##> Entrada analogica Reporte de la temperatura obtenidapor el sensor con una precision dedos dıgitos decimales.

NTE<#####> Estado de las entradas Notificacion de un cambio ocurridoen el estado de las entradas.

Tabla 7.4: Codigos utilizados en los mensajes enviados desde el modem GSM a la aplicacionJ2ME del usuario.

t e x t o ∗/

for ( i =0; i <9; i++)

write eeprom ( i , num usr [ i ] ) ; // graba e l numero de l usuar io en l a eeprom

//CONFIGURACION DE LA CLAVE DE EMERGENCIA

pos=s t r r c h r ( bu f f e r , ’C ’ ) ; // l o c a l i z a e l u l t imo carac t e r ’C ’

for ( i =0; i <4; i++)

pos++;

write eeprom (10+ i ,∗ pos ) ; // graba l a c l a v e de emergencia en l a eeprom

//REPORTE DE CONFIRMACION DE CONFIGURACION DE NUMERO Y CLAVE DE EMERGENCIA


s p r i n t f ( bu f f e r , ”%s ” ,CONFIGURAR) ; /∗anade ”CF” a l a cadena de t e x t o de l

mensaje de repor t e ∗/

c o d i f i c a c i o n ( ) ; /∗ c od i f i c a c i o n de l a cadena de acuerdo a l a l f a b e t o de 7

b i t s y transformaci on en oc t e t o s ∗/

envio sms (21 , ’ 0 ’ , ’A ’ ) ; /∗21=numero de oc t e t o s de l a trama pdu , ”0A”=numero

de s e p t e t o s de l campo de datos de usuar io ∗/

//VALIDACION DE NUMERO DEL USUARIO

for ( i =0; i <9; i++)


numero [ i ]=read EEPROM( i ) ; // l e e numero de l usuar io desde l a eeprom

i f ( strcmp (numero , num usr)==0) /∗compara numero de l remitente con numero de l

usuar io ∗/

// operac iones de con t ro l y l o c a l i z a c i o n

Las operaciones de control y localizacion son precisamente las encargadas de ejecutar

los requerimientos que el usuario envio en el mensaje de texto por medio de la

aplicacion J2ME. Para esto, se procede de la misma forma que en el mensaje de

configuracion, buscando la cadena correspondiente en el mensaje. Esta cadena puede

ser una de las siguientes:

• CT (Control). En este caso se activaran o se desactivaran las salidas especi-

ficadas en el mensaje, encendiendo o apagando los respectivos pines del PIC

ası como los de los leds indicadores de estado. Finalmente se enviara la confir-

macion al usuario con el formato mostrado en la Tabla 7.4

• RP (Reporte). En este caso se procedera a realizar una lectura del estado

de los pines, tanto de entradas como de salidas, y se enviara un mensaje de

reporte.

• AN (Entrada analogica). Para este caso se leera el conversor A/D y se realizara

el calculo de una equivalencia considerando la resolucion de 10 bits del con-

versor y la salida del sensor de 10 mV/C, con el fin de enviar la temperatura

requerida en C.

• GP (Posicion). En este caso se espera la recepcion de una trama RMC desde

el modulo receptor GPS, la cual contiene la posicion. Se verificara que la trama

contenga el caracter ’A’, que indica que es una trama valida y posteriormente

se enviara un mensaje al usuario, con la posicion correspondiente.

3. Codificacion del mensaje de acuerdo al alfabeto de 7 bits y transformacion

en octetos. Como se habıa mencionado anteriormente, los mensajes enviados desde

el modem GSM hacia la aplicacion en J2ME, deben ser dirigidos hacia un puerto


especıfico, en el cual se encuentra escuchando la aplicacion para poder activarse. Por

este motivo, se hace necesario que el envıo de mensajes se realice en modo PDU,

puesto que es la unica manera de poder especificar un puerto de destino.

El modo PDU requiere que el mensaje propiamente dicho, sea codificado antes

de pasar a formar parte del campo de datos de usuario de la trama. El proceso

de codificacion se puede encontrar en la seccion 2 del Apendice A. Los codigos

mostrados en la Tabla 7.4 son codificados por medio de las siguientes lıneas de

programa:

//ALGORITMO DE CODIFICACION DE DATOS DE 7 BITS EN OCTETOS

void c o d i f i c a c i o n ( )

int i ;

int j ;

int cont ;

int acum ;

char b ina r i o [9 ]= ”00000000” ;

//INICIALIZAR SECCION DE LA EEPROM PARA CODIFICACION

cont cod =0;

for ( i =15; i <64; i++)

write eeprom ( i , 0 x00 ) ;

for ( i =0, cont=0; i<s t r l e n ( bu f f e r ) ; i++,cont++)

i f ( cont==7)

cont=0;

i++;

i f ( i<s t r l e n ( bu f f e r ) )

//TRANSFORMACION DEL EQUIVALENTE ASCII DECIMAL A BINARIO

acum=0;

for ( j =0; j <8; j++)

i f ( ponderac ion [ j ]+acum>( int ) bu f f e r [ i ] )

b ina r i o [ j ]= ’ 0 ’ ;

else

b ina r i o [ j ]= ’ 1 ’ ;


acum+=ponderacion [ j ] ;

//CODIFICACION DE DATOS DE 7 BITS EN OCTETOS

for ( j =0; j<8−cont ; j++)

b ina r i o [7− j ]= b ina r i o [7− cont−j ] ; // desp lazamiento de b i t s

i f ( bu f f e r [ i +1]!=0x00 )

acum=0;

for ( j =0; j <8; j++)

i f ( ponderac ion [ j ]+acum>( int ) bu f f e r [ i +1])

i f ( j>=7−cont )

b i na r i o [ j+cont−7]= ’ 0 ’ ;

else


i f ( j>=7−cont )

b i na r i o [ j+cont−7]= ’ 1 ’ ;

else

for ( j =0; j<cont ; j++)

b ina r i o [ j ]= ’ 0 ’ ;

//TRANSFORMAR DE BINARIO A HEXADECIMAL

//NIBBLE MAS SIGNIFICATIVO

acum=0;

for ( j =0; j <4; j++)

i f ( b i na r i o [ j ]== ’ 1 ’ )

acum+=ponderacion [4+ j ] ;

wr ite eeprom (15+ cont cod++,hexadecimal [ acum ] ) ; // grabar en l a eeprom

//NIBBLE MENOS SIGNIFICATIVO

acum=0;

for ( j =0; j <4; j++)

i f ( b i na r i o [ j+4]== ’ 1 ’ )




4. Envıo de SMS de notificacion o reporte. Esta seccion del codigo se encarga

de construir los mensajes de notificacion o reporte de las operaciones de control y

localizacion, de acuerdo a la estructura de la trama PDU revisada en la Tabla 2.7,

para luego enviarlos por medio del modem GSM a la aplicacion J2ME. El codigo

encargado de realizar tal funcion es el siguiente:

//SUBRUTINA DE ENVIO DE SMS

void envio sms ( int long trama , char l ong datos1 , char l ong datos2 )

int i ;

i n i t b u f f e r ( ) ;

i n i t a ux ( ) ;

//LECTURA DEL NUMERO DEL USUARIO DESDE LA EEPROM

for ( i =0; i <9; i++)

num usr [ i ]=read EEPROM( i ) ;

//FORMATO PDU DEL NUMERO DEL USUARIO

for ( i =0; i <7; i+=2)

aux [0 ]= num usr [ i ] ;

num usr [ i ]=num usr [ i +1] ;

num usr [ i +1]=aux [ 0 ] ;

aux [0 ]= num usr [ 8 ] ;

num usr [8 ]= ’F ’ ;

//LECTURA DEL MENSAJE CODIFICADO DESDE LA EEPROM

for ( i =0; i<cont cod ; i++)

bu f f e r [ i ]=read EEPROM(15+ i ) ;

delay ms ( 5 00 ) ;

f p r i n t f (CEL, ”AT+CMGD=1\r \n” ) ; /∗ borra e l mensaje entrante ya procesado , para

e v i t a r que se sa ture l a memoria de l t e l e f o n o ∗/

delay ms ( 5 00 ) ;

//CONFIGURACION DEL MODEM EN MODO PDU

f p r i n t f (CEL, ”AT+CMGF=0\r \n” ) ;

delay ms ( 5 00 ) ;


//CONSTRUCCION DE LA TRAMA PDU Y ENVIO DE SMS

f p r i n t f (CEL, ”AT+CMGS=%d\ r \n” , long trama ) ;

delay ms ( 5 00 ) ;

f p r i n t f (CEL, ”0041000981% s%c0003%c%c06050440744074%s ” , num usr , aux [ 0 ] , \

l ong datos1 , long datos2 , bu f f e r ) ;

putc (26 ,CEL) ; //ASCII(26)=( c t r l+z ) envia e l mensaje

delay ms (3000 ) ;

5. Monitoreo de las entradas digitales. Como se explico anteriormente, el moni-

toreo de las entradas digitales se realiza mediante la habilitacion de la interrupcion

relacionada al cambio de estado en uno de los bits del nibble mas alto del puerto

B (RB4 a RB7). Por lo que, un cambio en el estado de las entradas activa la

interrupcion y se ejecuta el codigo mostrado en las siguientes lıneas:

#INT RB

int pue r tob ( )

d i s a b l e i n t e r r u p t s (INT RB ) ; // d e s a b i l i t a in t e r rupc i o n

e s t en t r ada s ( ) ; // l e e e l es tado ac tua l de l a s entradas


s p r i n t f ( bu f f e r , ”%sE%s” ,NOTIFICAR, entradas ) ; /∗anade ”NT” y e l es tado de l a s

entradas a l mensaje de no t i f i c a c i o n ∗/



envio sms (26 , ’ 0 ’ , ’F ’ ) ; /∗26=numero de oc t e t o s de l a trama pdu , ”0F”=numero de

s e p t e t o s de l campo de datos de usuar io ∗/

e n ab l e i n t e r r up t s (INT RB ) ; // h a b i l i t a in t e r rupc i o n

delay ms ( 5 00 ) ;

f p r i n t f (CEL, ”AT+CMGF=1\r \n” ) ; // con f i gura e l modem en modo t e x t o

delay ms ( 5 00 ) ;


7.4.2 Aplicacion de administracion del SCL en J2ME

La aplicacion en J2ME es la interfaz del SCL con el usuario. Esta aplicacion utiliza

las bondades de la programacion en J2ME vistas en el capıtulo 6, para dar al usuario

interactividad y amigabilidad con el sistema.

Para el desarrollo de esta aplicacion se definieron las siguientes clases, que en su

mayorıa derivan de las interfaces de usuario de alto y bajo nivel, disponibles en las APIs


de J2ME y cuyo diagrama de clases se muestra en la Figura 7.17:

• Scl

• Sistema

• Fclave

• Intro

• Lconfiguracion

• Fesperar

• FenvioSms

• Fcontrol

• Fpeticion

• GClocalizacionMapa

• Fnotificacion

A continuacion se describira cada una de ellas, resaltando las consideraciones impor-

tantes. El codigo completo de cada clase se encuentra en el Apendice G, Codigo de la

aplicacion de administracion del SCL en J2ME.

1. Clase Scl. Esta clase deriva de la clase MIDlet, por lo tanto, es la clase principal

de la aplicacion. Su nombre son las siglas de ”Sistema de Control y Localizacion”,

y a su vez, define el nombre de la aplicacion J2ME (Scl.jar). Incluye un objeto de

tipo Display llamado pantalla, necesario para administrar los objetos Displayable de

las interfaces de usuario revisadas en el capıtulo 6, requeridas para esta aplicacion.

En esta clase se encuentran declarados e inicializados todos los objetos empleados

en la aplicacion.

Adicionalmente, en el constructor de la clase Scl se realiza el registro de una conexion

sms entrante por el puerto 16.500, mediante el API Push Registry, con el fin de que


MID

let

Cla

seG

Clo

caliza

cionM

apa

Cla

seFnum

Sis

tem

aC

lase

FentS

al

Cla

seFedit

Cla

ve

Cla

seLco

nfigura

cion

Cla

seIn

tro

Cla

seFpeti

cion

Cla

seFnoti

fica

cion

Cla

seFesp

era

rC

lase

Fenvio

Sm

s

Cla

seFco

ntr

ol

Cla

seFcl

ave

Cla

seSis

tem

aC

lase

Scl

-num

ero

:Tex

tfiel

d

-cl

aveS

os:

Tex

tFie

ld

-co

nfirm

arC

lave

Sos

:Tex

tFie

ld-

scl:

Scl

-sc

l:

Scl

-sc

l:

Scl

-sc

l:

Scl

-sc

l:

Scl

-sc

l:

Scl

-sc

l:

Scl

-sc

l:

Scl

-sc

l:

Scl

-sc

l:

Scl

-sc

l:

Scl

-sc

l:

Scl

-en

cEntr

adas

:Str

ingI

tem

-en

cSal

idas

:Str

ingI

tem

-sa

lidas

:Tex

tFie

ld

-en

trad

as:

Tex

tFie

ld

-nuev

aCla

ve:

Tex

tFie

ld

-co

nfirm

arN

uev

aCla

ve:

Tex

tFie

ld

-num

Sis

tem

a:

Fnum

Sis

tem

a

-en

tSal

:Fen

tSal

-ed

itC

lave

:Fed

itC

lave

-M

IME

type

:Str

ing

-pla

yer

:P

laye

r

-ar

chiv

o:

Str

ing

-av

iso

:Str

ingI

tem

-ti

les

:T

iled

Lay

er

-lm

:Lay

edM

anag

er

-m

apaN

oDis

pon

ible

:Im

age

-es

tados

Str

:Str

ing

-et

iquet

as:

Str

ing

-co

nfigu

raci

on:

Str

ingI

tem

-en

trad

as:

Choi

ceG

roup

-an

alog

ica

:Str

ingI

tem

-pos

icio

n:

Str

ingI

tem

-lo

caliza

cion

Map

a:

GC

loca

liza

cion

Map

a

-te

xto

:Str

ingI

tem

-pro

gres

o:

Gau

ge

-te

xto

:Str

ing

-av

iso

:A

lert

-en

via

rSm

s:

Imag

e

-num

Sis

tem

a:

Imag

e

-es

tados

Img

:Im

age

-es

tados

Img

:Im

age

-sa

lidas

:C

hoi

ceG

roup

-sa

lidas

:C

hoi

ceG

roup

-in

gCla

ve:

Tex

tFie

ld

-cl

ave

:Str

ing

-co

mpC

lave

:Str

ing

-den

egad

o:

Cden

egad

o

+ab

rirR

ecor

dSto

re()

+cr

earR

egis

tros

()

+ce

rrar

Rec

ordSto

re()

+ge

tNum

Reg

istr

os()

-rs

:R

ecor

dSto

re

-si

stem

a

-sc

l

-sc

l

-sc

l

-sc

l

-sc

l

-sc

l

-sc

l

-sc

l

-sc

l

-sc

l

-sc

l

-sc

l-

scl

-num

Sis

tem

a

-en

tSal

-ed

itC

lave

-co

nfigu

raci

on

-in

troducc

ion

-pet

icio

n

-lo

caliza

cion

Map

a

-not

ifica

cion

-co

ntr

ol

-cl

ave

-si

stem

a:

Sis

tem

a

-cl

ave

:Fcl

ave

-in

troducc

ion

:In

tro

-m

enu

:Lis

t

-co

nfigu

raci

on:

Lco

nfigu

raci

on

-co

nfigu

raci

on:

Lco

nfigu

raci

on

-co

nfigu

raci

on:

Lco

nfigu

raci

on

-not

ifica

cion

:Fnot

ifica

cion

-co

ntr

ol:

Fco

ntr

ol

-pet

icio

n:

Fpet

icio

n

-m

sgC

on:

Mes

sage

Con

nec

tion

+ve

rOpci

ones

()

+ve

rIntr

oducc

ion()

+ve

rCon

figu

raci

on()

+ve

rNot

ifica

cion

()

+ve

rCon

trol

()

+not

ifyIn

com

ingM

essa

ge(M

essa

geC

onnec

tion

Msg

Con

)

Figura 7.17: Diagrama de clases de la aplicacion en J2ME.


el MIDlet se active al llegar un mensaje desde la TCL dirigido hacia ese puerto. El

registro se lo realizo con la siguiente lınea de codigo:

PushRegistry . r e g i s t e rConnec t i on ( d i r e c c i on , this . g e tC la s s ( ) . getName ( ) , ”∗” ) ;

Como se habıa visto en el capıtulo 6, seccion 13, el campo direccion es una cadena

de conexion que indica el puerto en el que el MIDlet estara escuchando los mensajes

SMS. Para este caso, la cadena es ”sms://:16500”. El segundo campo indica el

nombre de la clase que sera activada; con this.getClass().getName() se registra al

MIDlet que esta en ejecucion. El ultimo campo indica que cualquier emisor puede

activar el MIDlet.

En el metodo startApp() de la clase Scl, se abrio una conexion para atender mensajes

cortos en la direccion ”sms://:16500”, con la siguiente lınea de codigo:

msgCon=(MessageConnection ) Connector . open ( d i r e c c i o n ) ;

Para determinar si el MIDlet fue activado por una conexion entrante o fue activado

por el usuario se colocaron las lıneas de codigo vistas en la seccion 6.13, con el fin

de determinar que formularios deben presentarse.

Ademas, se implemento el metodo run() de la interfaz Runnable debido a que el

metodo que se encarga de la recepcion de los mensajes SMS, debe correr en un hilo

aparte de la secuencia principal, porque interrumpe el flujo del programa quedandose

en espera de los mensajes entrantes, que sirven para llevar informacion proveniente

desde la TCL.

Una vez que haya llegado un mensaje, se procede a leer su contenido con el metodo

getPayloadText() y se muestra en pantalla el formulario Fnotificacion, el cual con-

tiene el reporte o notificacion correspondiente.

En la clase Scl, se instancio tambien, un objeto de la clase List de tipo implıcita,

llamado menu, que contiene las operaciones que el usuario puede ejecutar en el SCL.

El objeto menu se puede observar en la Figura 7.18, la cual fue capturada utilizando

el emulador de Sun Wireless Toolkit 2.5.2, al igual que las figuras subsiguientes.


Figura 7.18: Menu principal de la aplicacion.

2. Clase Sistema. Esta clase no deriva de ninguna otra clase y contiene los principales

atributos que intervienen en la aplicacion y de los cuales hacen uso las demas clases;

ademas, provee los metodos para acceder y modificar los valores de dichos atributos.

Tambien contiene metodos que se encargan del almacenamiento persistente en la

memoria del celular del usuario, debido a que es necesario guardar cierta informacion

como el numero telefonico del modem de la TCL, la clave de ingreso a la aplicacion

Scl.jar, las etiquetas de entradas y salidas asignadas por el usuario, y el estado de

las mismas.

3. Clase Fclave. Esta clase deriva de la clase Form, es decir es un formulario en el

cual podemos agregar objetos de tipo Item. Este formulario permitira el ingreso de

la clave de la aplicacion para la autenticacion del usuario, de no poseer esta clave,

el usuario no podra acceder a la aplicacion.

Esta clase implementa un objeto de tipo TextField derivado de Item. Este campo

esta validado para ingresar un maximo de diez caracteres de tipo numerico y de


tipo password ; por lo tanto, la clave de la aplicacion debe consistir unicamente de

numeros y los mismos se reemplazaran por el caracter ’∗’ cuando sean digitados.

Por otro lado, esta clase validara que la clave ingresada coincida con la almacenada

en la memoria del telefono, en el caso de no ser ası, volvera a presentarse el formulario

esperando por la clave correcta. Despues de tres intentos fallidos, se mostrara en

pantalla un objeto de la clase Cdenegado derivada de la clase Canvas. En este objeto,

se procede a dibujar un fondo blanco sobre el cual se ha insertado una imagen y el

mensaje ”Acceso denegado”, indicandole al usuario que no puede hacer uso de la

aplicacion porque los tres intentos de acceso fueron erroneos.

El formulario Fclave y el objeto de la clase Cdenegado se pueden observar en la

Figura 7.19.

(a) Formulario Fclave (b) Clase Cdenegado

Figura 7.19: Formularios para la autenticacion de usuario.

4. Clase Intro. Esta clase hereda de la clase Canvas y tiene la funcion de mostrar en


pantalla una animacion de inicio de la aplicacion, una vez que el usuario se haya au-

tenticado. Para este proposito, se implemento la API Media de MIDP 2.0 impor-

tando los paquetes javax.microedition.media2 y javax.microedition.media.control3,

lo que permitio presentar una animacion GIF (Graphics Interchange Format) reali-

zada para esta aplicacion, utilizando el programa para la manipulacion de imagenes

con licencia GNU, GIMP 2.4.6 (GNU Image Manipulation Program). Esta ani-

macion tiene un tiempo de duracion limitado, una vez que termina, se presenta

en pantalla el objeto menu revisado anteriormente. Ademas, el usuario tendra la

opcion de interrumpir la animacion presionando cualquier tecla del telefono celular.

La Figura 7.20 muestra una parte de la secuencia de esta animacion.

Figura 7.20: Animacion de inicio de la aplicacion.

5. Clase Lconfiguracion. Esta clase hereda de la clase List y es una lista de tipo

2La API Media de MIDP 2.0 es un bloque directamente compatible con la especificacion Mobile

Media API (MMAPI). MMAPI extiende la funcionalidad de J2ME proporcionando audio, video y otrascaracterısticas multimedia. Es un paquete opcional, simple y ligero, que tambien permite acceder a losservicios multimedia nativos de un dispositivo movil. No presente en MIDP 1.0.

3Este paquete define los tipos de control especıficos que pueden ser usados en el reproductor (Player)de la API Media. No presente en MIDP 1.0.


implıcita que muestra en pantalla un menu con las opciones de configuracion del

SCL como en la Figura 8.4, las mismas que se describen a continuacion:

Figura 7.21: Menu para configuracion del SCL.

• Numero del sistema. Al elegir esta opcion se presentara en pantalla un

objeto de la clase FnumSistema, derivada de la clase Form, y que contiene tres

items de tipo TextField para el ingreso del numero telefonico del modem de la

TCL, la clave de emergencia y la confirmacion de esta clave. Se ha validado

que el numero corresponda efectivamente a un numero de celular, es decir, que

comience con ”08” o ”09” y tenga 9 dıgitos; ademas, se valido que se ingrese

cuatro caracteres para la clave de emergencia y que los mismos coincidan con

los colocados en el campo de la confirmacion. Finalmente, al aceptar se envıa

un mensaje de texto a la TCL creando un objeto de la clase FenvioSms. En la

Figura 7.22(a) se muestra el formulario para la configuracion del numero del

modem GSM en la TCL y clave de emergencia.

• Entradas/Salidas. Esta opcion presentara un objeto de la clase FentSal que

deriva de Form con items de tipo TextField que permiten ingresar etiquetas


para las 5 salidas y 4 entradas de la TCL con el fin que el usuario coloque nom-

bres que le sean faciles de asociar y recordar. Una vez que el usuario presiona

sobre el boton ”Aceptar” se presenta un objeto tipo Alert que corresponde a

una alerta con un mensaje de que los cambios se realizaron satisfactoriamente.

Este formulario se muestra en la Figura 7.22(b).

• Clave. Esta opcion muestra un formulario de la clase FeditClave que permite

configurar la clave para el ingreso a la aplicacion, la misma tiene el valor ”123”

por defecto. Posee dos items de tipo TextField validados para ser de tipo

numerico y password, en el primero se ingresa la clave de maximo 10 dıgitos

y en el segundo se confirma esta clave. Al aceptar se presenta un objeto tipo

Alert que indica que la clave ha sido configurada exitosamente, si los campos

no coincidieron igualmente se presenta una alerta que indique al usuario el

error cometido. Este formulario se muestra en la Figura 7.22(c).

6. Clase Fesperar. Esta clase hereda de la clase Form. Es un formulario que incluye

un item de tipo StringItem, el cual muestra el texto ”Espere un momento...” mientras

se espera por el envıo de un mensaje SMS, despues de realizar una configuracion del

SCL o un requerimiento de control o localizacion.

7. Clase FenvioSms. Esta clase sera la encargada de enviar los mensajes con los

codigos de las respectivas peticiones que haya hecho el usuario, las cuales pueden ser

de configuracion, control, reporte, lectura de entrada analogica y posicion, revisadas

en la Tabla 7.3. Para este proposito, esta clase implementa el Wireless Messaging

API que fue descrito en el capıtulo 6.

En la primera parte, esta clase agrega un item de tipo Gauge que permite mostrar

una barra de progreso con el texto ”Enviando sms...”, la misma que indica el avance

en el proceso de envıo del mensaje. Posteriormente, se implemento el metodo run()

de la interfaz Runnable, correspondiente al hilo paralelo que se va a ejecutar para

el envıo de mensajes, en el cual se abre una conexion de tipo MessageConnection

mediante la siguiente lınea de codigo:


(a) Formulario FnumSistema (b) Formulario FentSal (c) Formulario FeditClave

Figura 7.22: Formularios de las opciones de configuracion.

msgCon=(MessageConnection ) Connector . open ( de s t ino ) ;

En esta lınea, el campo destino contiene la cadena:

”sms :// ”+s c l . s i s tema . getNumSistema()+” : ”+s c l . s i s tema . getPuertoTx ( ) ” ,

la misma que indica que los mensajes seran enviados al numero ingresado en la

opcion de configuracion de ”Numero del sistema” y al puerto especificado en la

clase Sistema, que en este caso tiene el valor de 16.000.

Puesto que se instanciara un objeto de esta clase cada vez que sea necesario enviar

un mensaje a la TCL, se paso como argumento a su constructor, el codigo correspon-

diente de configuracion, control, reporte, entrada analogica o posicion revisados en

la Tabla 7.3, para que sea anadido a la cadena de texto del mensaje y luego enviado.

Esto se logra con las siguientes lıneas de codigo:


TextMessage

sms=(TextMessage )msgCon . newMessage ( MessageConnection .TEXT MESSAGE) ;

sms . setAddress ( de s t ino ) ;

sms . setPayloadText ( s c l . s i s tema . ge tClaveSc l ()+ texto ) ; msgCon . send ( sms ) ;

Finalmente se mostrara en pantalla un objeto tipo Alert con el texto ”Mensaje

enviado”. En caso de que no se haya configurado el numero del modem GSM

en la TCL, se activara un objeto tipo Alert con el texto ”Configurar el numero

del Sistema” indicando que es prioritario configurar este numero. La Figura 7.23

muestra este formulario con el item de tipo Gauge.

Figura 7.23: Formulario FenvioSms.

8. Clase Fcontrol. Esta clase permite al usuario controlar la TCL mediante la acti-

vacion/desactivacion de sus cinco salidas. Para este proposito se implemento cinco

items tipo ChoiceGroup que permiten elegir entre dos opciones: encender (on) o

apagar (off ). Una vez que el usuario haya hecho su eleccion y presionado el boton

”Aceptar” se instanciaran los objetos de las clases Fesperar y FenvioSms para enviar


Figura 7.24: Formulario para el control de salidas.

el codigo de control de salidas respectivo. La Figura 7.24 muestra un formulario de

tipo Fcontrol para el control de salidas de la TCL.

9. Clase Fpeticion. Esta clase deriva de la clase Form e incluye items de tipo String-

Item que preguntan al usuario si desea realizar una peticion de reporte, temperatura

o posicion, de acuerdo a la opcion seleccionada en el formulario menu. Si el usuario

efectivamente desea realizar la peticion, debe presionar el boton ”Aceptar”, despues

de lo cual se instanciaran objetos de las clases Fesperar y FenvioSms para proceder

al envıo del mensaje SMS a la TCL con el codigo de reporte, temperatura o posicion,

segun sea el caso.

La Figura 7.25 muestra tres instancias de esta clase, para las peticiones de reporte,

temperatura y localizacion respectivamente.

10. Clase Fnotificacion. Esta clase deriva de Form y tiene la funcion de mostrar

al usuario las notificaciones, confirmaciones o reportes provenientes desde la TCL.

Este formulario sera instanciado cada vez que llegue un mensaje a la aplicacion sin


(a) Peticion de reporte. (b) Peticion de temperatura. (c) Peticion de localizacion.

Figura 7.25: Formularios para realizar peticiones a la TCL.

importar si el usuario se encuentre dentro de ella o no.

El constructor de esta clase recibe como parametro el texto del mensaje recibido

y de esta manera se logra diferenciar si se trata de un reporte, una confirmacion

de control de salidas, una notificacion del cambio de estado de las entradas, una

confirmacion de configuracion, un reporte de temperatura o una posicion.

Para el caso de control de salidas o notificacion del cambio en el estado de las

entradas, unicamente se presentaran las salidas o entradas que hayan tenido un

cambio. Esto se consigue guardando en la memoria del telefono los estados actuales

para posteriormente poder compararlos y determinar cuales han cambiado.

En el caso de la posicion, esta clase se encarga de separar los grados y minutos, de

las coordenadas enviadas desde la TCL en el mensaje SMS, para poder mostrarlos

al usuario de tal forma que sea mas facil su comprension, y ademas, identifica si

la latitud es norte o sur y la longitud es este u oeste. Adicionalmente, incluye un


boton con la etiqueta ”Ver Mapa” que instanciara un objeto de la clase GClocali-

zacionMapa.

11. Clase GClocalizacionMapa. Esta clase tiene como funcion mostrar al usuario

un mapa, que en este caso unicamente abarca el perımetro de la ESPE. Este mapa

puede ser mostrado cuando llegue una notificacion de la TCL despues de haber

realizado una peticion de posicion.

GClocalizacionMapa deriva de la clase GameCanvas que no es mas que una subclase

de Canvas que anade nuevas capacidades orientadas a la programacion grafica,

permitiendo dibujar de forma rapida e inmediata (sin parpadeos) en la pantalla, y,

ademas, provee acceso al estado de las teclas del dispositivo celular. Su utilidad en la

presente aplicacion, radica en que ha permitido dividir al mapa en recuadros, deno-

minados tiles (de la clase TiledLayer), de manera que se pueda mostrar unicamente

la seccion del mapa que contenga la posicion enviada desde la TCL, pero ademas,

brinda la posibilidad de que el usuario pueda desplazarse por el mapa presionando

las teclas de navegacion del dispositivo.

Para ubicar una posicion geografica dentro del mapa se hace una equivalencia de la

posicion enviada desde la TCL a un punto de la imagen del mapa. Esto fue posible

gracias a la utilizacion del programa gMapMaker que permite obtener el mapa de

un area geografica determinada proveyendo adicionalmente un archivo de texto con

extension .map que se presenta en la Figura 7.26, el cual contiene las equivalencias

entre puntos claves del mapa y sus coordenadas geograficas.

En el caso de que el usuario se encuentre fuera del perımetro de la ESPE, se mostrara

una alerta con el texto ”Mapa no disponible.”

7.5 COSTOS

Para la determinacion del costo total del SCL se consideraron los costos de materiales

directos, mano de obra directa y mano de obra indirecta. En la Tabla 7.5, se muestra en

detalle el valor de cada uno de estos ıtems, dando como costo final el valor de $314,61.


Figura 7.26: Archivo .map con las equivalencias entre puntos del mapa y su posicion geo-grafica.


Materiales directos

Item Cantidad V. Unitario V. TotalPIC16F877A 1 12,00 12,00receptor SPK-GPS-GS405 1 107,05 107,05Modem GSM 1 40,00 40,00Zocalo 40P 1 0,25 0,25Borneras 2P 6 0,35 2,10Borneras 3P 4 0,45 1,80Rele 12 VDC 2 0,90 1,80Cristal 4 MHz 1 0,60 0,60Diodo 1N4007 2 0,09 0,18Zener 3.3 V 1 0,13 0,13Transitor 2N3904 2 0,08 0,16Regulador LM317 1 0,65 0,65Regulador LM1117 1 0,85 0,85Capacitor 22ρF 2 0,08 0,16Capacitor 100 ηF 3 0,08 0,24Capacitor 10 µF 16 V 3 0,08 0,24Resistencia 220 Ω 5 0,02 0,10Resistencia 680 Ω 1 0,02 0,02Resistencia 1.5 kΩ 2 0,02 0,04Resistencia 3.3 kΩ 2 0,02 0,04Resistencia 10 kΩ 3 0,02 0,06Disipador 2 0,50 1,00Conector USB Tipo A 1 0,80 0,80Conector 2P 3 0,30 0,90Conector 5P 2 0,35 0,70Conector 4P 2 0,45 0,90Switch 2P 1 0,20 0,20Pulsador 1 0,13 0,13Jack DC para chasis 1 0,11 0,11Portaled 6 0,40 2,40Cable 1 m 1 1Caja 1 3,00 3,00

Mano de obra directa

Diseno circuito impreso 15,00Diseno software 100,00

Mano de obra indirecta

Ruteado placa 15,50Soldadura 2,00Screen 2,50

Tabla 7.5: Detalle de costos del SCL.

PRUEBAS Y RESULTADOS 123

CAPITULO 8

PRUEBAS Y RESULTADOS


En este capıtulo se muestran los resultados obtenidos despues de haber ejecutado las

pruebas para evaluar el funcionamiento del prototipo tomando en cuenta las funciones

de control y localizacion para las que fue disenado. Para este proposito, se evaluaron las

opciones de administracion de la aplicacion J2ME, ası como aspectos relacionados a la

seguridad de esta aplicacion en un telefono movil real.

La aplicacion J2ME, fue probada en algunos modelos de telefonos celulares, entre

ellos, el Sony Ericsson W300i y W980, Nokia 6300 y N95, y el Motorola Rokr E2. Para la

documentacion de pruebas y resultados, se ha utilizado el telefono del fabricante Nokia,

modelo N95 mostrado en la Figura 8.1.

Figura 8.1: Telefono Nokia N95.


8.2 AUTENTICACION DEL USUARIO

Una vez que el archivo Scl.jar, binario de la aplicacion J2ME, ha sido instalado en el

telefono celular, solo resta ubicarlo y ejecutarlo, tal como se muestra en la Figura 8.2.

(a) Ubicacion (b) Ejecucion

Figura 8.2: Ejecucion de la aplicacion Java Scl.jar.

En primera instancia, se probo la seguridad de acceso a la aplicacion ingresando una

clave incorrecta, tres veces consecutivas, en el formulario de autenticacion de usuario.

Posteriormente, se ingreso correctamente la clave de acceso cuyo valor por defecto es

”123”. Los resultados se pueden observar en la Figura 8.3

8.3 PARAMETROS DE CONFIGURACION DEL SCL

Una vez en el menu principal de la aplicacion Scl, se eligio la primera opcion, llamada

Configuracion, relacionada a los parametros de configuracion del SCL. El menu de con-

figuracion se puede apreciar en la Figura 8.4.

8.3.1 Configuracion del numero del sistema y clave de emergencia

En esta pantalla se probaron las validaciones referentes a la legitimidad del numero de

telefono celular, es decir, que este compuesto por nueve dıgitos y que empiece con ”08” o

”09”. Tambien se probo que el ingreso de la clave coincida en los dos campos destinados

para este proposito, ası tambien que cumpla con el requisito de tener cuatro caracteres.


Figura 8.3: Formularios para autenticacion del usuario.

Finalmente, se ingreso en el campo Numero, el numero de telefono del modem de la TCL,

y en los campos de la clave de emergencia se ingreso la cadena ”1234”. Posteriormente,

se envio el mensaje SMS de configuracion a la TCL, obteniendose los resultados que se

muestran en las Figuras 8.5 y 8.6.

8.3.2 Configuracion de las etiquetas de entradas y salidas

En la segunda opcion del menu de configuracion (Figura 8.4), relacionada a las etiquetas

que identifican las entradas y salidas, se reemplazo los nombres por defecto de las salidas

1,2 y 4 por ”Puertas”, ”Alarma” y ”Foco”, respectivamente. El resultado se muestra en

la Figura 8.7.


Figura 8.4: Formulario con las opciones de configuracion del SCL.

8.3.3 Configuracion de la clave de la aplicacion Scl

Esta es la tercera opcion del menu de configuracion. En esta pantalla se cambio la clave

de autenticacion de usuario para el acceso a la aplicacion Scl. La nueva clave ingresada

fue ”456”. Cabe recordar que esta clave puede tener hasta 10 dıgitos. Los resultados se

presentan en la Figura 8.8.

8.4 CONTROL DE SALIDAS DE LA TCL

La segunda opcion del menu principal denominada Control, permite controlar el estado

de las salidas de la TCL, que por defecto es off.

En este formulario se cambio el estado de las salidas etiquetadas como ”Puertas”,

”Alarma” y ”Foco” (Salida 1, Salida 2 y Salida 4, respectivamente) de off a on como se

muestra en la Figura 8.9. Una vez que la peticion fue procesada por la TCL se recibio el

reporte de la misma como se presenta en la Figura 8.10.

8.5 REPORTE DEL SISTEMA

La tercera opcion del menu principal permite pedir un reporte del estado de entradas

y salidas de la TCL. Luego de ejecutar esta opcion y presionar el boton aceptar del

formulario de confirmacion correspondiente, se obtuvieron los resultados mostrados en la

Figura 8.11, donde se confirmaron los estados respecto de la peticion de control enviada

anteriormente.


(a) Formulario (b) Confirmacion (c) Envıo SMS

Figura 8.5: Configuracion del numero del sistema y la clave de emergencia.

8.6 FUNCION DE LOCALIZACION

Esta opcion permite enviar una peticion a la TCL para obtener su posicion. Cabe recor-

dar que si esta se encuentra dentro del perımetro del campus politecnico de la ESPE,

adicionalmente se puede visualizar la posicion en un mapa. En la Figura 8.12 se pueden

observar los resultados obtenidos desde dos puntos ubicados dentro del campus.

8.7 ENTRADA ANALOGICA

La quinta y ultima opcion del menu principal denominada Temperatura, permite enviar

una peticion a la TCL, para que reporte la temperatura del ambiente que se este sensando

por medio de la entrada analogica. El resultado obtenido despues de ejecutar esta opcion

se muestra en la Figura 8.13.

8.8 NOTIFICACION DE CAMBIO DE ESTADO DE LAS ENTRADAS

Finalmente, se probo la funcion de notificacion de la TCL, cuando se produce un cambio de

estado en cualquiera de las entradas. Con este proposito, se conecto a tierra la Entrada

3 de la TCL, para provocar el cambio de estado, puesto que, como se menciono en el

capitulo 7, el estado por defecto de las entradas es 1 logico (on) cuando no hay dispositivos

conectados.


(a) Notificacion del sistema (b) Reporte de configuracion

Figura 8.6: Confirmacion de configuracion enviado desde la TCL.

Al momento de recibir la notificacion, el celular del usuario no se encontraba ejecu-

tando la aplicacion Scl, se encontraba en la pantalla de menu como puede apreciarse en

la Figura 8.14. Por lo tanto, la siguiente pantalla en aparecer es la de autenticacion de

usuario, para permitir al usuario, identificarse y acceder a la informacion proveniente de

la TCL. Una vez identificado, se pudo observar el formulario de notificacion donde se

indica el cambio ocurrido.


(a) Opcion de configuracion (b) Formulario (c) Confirmacion

Figura 8.7: Configuracion de etiquetas de las entradas y salidas de la TCL.

(a) Nueva clave (b) Confirmacion

Figura 8.8: Modificacion de la clave de autenticacion de usuario.


(a) Formulario de control (b) Cambio de estado

(c) Peticion a ser enviada

Figura 8.9: Formulario de control de salidas de la TCL.


(a) Control de salidas

(b) Notificacion del sistema (c) Reporte de control

Figura 8.10: Control de salidas y reporte de la TCL.


(a) Peticion de reporte (b) Notificacion del sistema

(c) Formulario de reporte

Figura 8.11: Reporte del sistema.


(a) Peticion de localizacion (b) Notificacion del sistema

(c) Formulario de Posicion 1 (d) Opcion para ver mapa (e) Ubicacion en el mapa

(f) Formulario de Posicion 2 (g) Ubicacion en el mapa

Figura 8.12: Funcion de localizacion del sistema.


(a) Peticion de temperatura (b) Notificacion del sistema (c) Formulario temperatura

Figura 8.13: Reporte de temperatura.

(a) Notificacion del sistema (b) Autenticacion de usuario (c) Formulario de notificacion

Figura 8.14: Notificacion de cambio de estado de las entradas.

CONCLUSIONES Y RECOMENDACIONES 135

CAPITULO 9

CONCLUSIONES Y RECOMENDACIONES

9.1 CONCLUSIONES

• El presente proyecto cumple con los objetivos propuestos, implementando mejoras

en ciertos aspectos, como por ejemplo: proveer de un mayor numero de entradas

digitales que las especificadas en el alcance del proyecto, ası mismo, se ha anadido

al prototipo la posibilidad de visualizar la posicion en un mapa, cuando esta se

encuentra dentro del perımetro del campus politecnico.

• El formato de envıo de mensajes SMS mediante tramas PDU, permite enviar in-

formacion de control, adicional al texto del mensaje propiamente dicho, como por

ejemplo: direccionar el mensaje SMS hacia un puerto de aplicacion especıfico de

manera que pueda activar una aplicacion residente en el telefono celular del usuario,

caracterıstica que ha permitido dotar de amigabilidad al midlet Scl.jar en la in-

teraccion con el sistema.

• Una consideracion con respecto a la entrada analogica es que esta se encuentra

adaptada a las caracterısticas del sensor de temperatura LM35; es decir, el codigo del

PIC resuelve el valor en grados centıgrados correspondiente al valor digital entregado

por el conversor A/D, considerando que el sensor utilizado entrega 10mV/C. Por

lo tanto, si se desea conectar otro tipo de sensor, se tendrıa que modificar dicho

algoritmo de conversion en el codigo del PIC, adecuandolo al sensor determinado.

Otra alternativa, podrıa leer unicamente el valor digital del conversor y enviarlo

al usuario, con el inconveniente que este tendrıa que realizar las operaciones de

equivalencia respectivas para obtener la temperatura. Con fines de amigabilidad de


la aplicacion, se ha implementado el codigo de manera que entregue directamente

el valor en grados centıgrados.

• La implementacion del prototipo con salidas de potencia incorporadas, es una gran

ventaja respecto a sistemas de control similares que solo disponen de salidas digitales

y dejan a cargo del usuario adecuar estas salidas a una etapa de potencia mediante

el uso de reles o dispositivos que cumplan con el mismo proposito.

• La API Push Registry se tiene disponible a partir del perfil MIDP 2.0 y permite

activar MIDlets sin la intervencion del usuario, ya sea a traves de una conexion

entrante o mediante la configuracion de alarmas. Esto brinda la posibilidad de

desarrollar una gran cantidad de aplicaciones que hagan uso de esta API, como es

el caso de este proyecto.

• La API Push Registry, provee a la aplicacion Scl de total interactividad con la tarjeta

de control y localizacion, permitiendo al usuario recibir notificaciones y confirma-

ciones sobre los cambios en el estado del sistema de manera amigable, sin emplear

codigos que tenga que memorizar.

• La API WMA (Wireless Messaging API ) permite implementar el envıo y recepcion

de mensajes SMS desde y hacia la aplicacion J2ME, siendo este medio de comuni-

cacion, tan extendido y aceptado por los suscriptores de telefonıa celular, la base

del presente proyecto.

• Es importante considerar que las operaciones de control y localizacion de este pro-

totipo no se realizan en tiempo real, debido a que dependen de los retardos en la

transmision de los mensajes SMS dentro de la red GSM y la congestion en la misma.

• Una ventaja de utilizar un lenguaje de alto nivel en la programacion del microcon-

trolador PIC, es que ha sido posible la implementacion de dos lıneas de comunicacion

serial por software para el intercambio de informacion tanto con el modem GSM,

como con el modulo receptor GPS.


9.2 RECOMENDACIONES

• Para la implementacion de este prototipo se recomienda la utilizacion de un modulo

GPS con tecnologıa Sirf Star III, que entre otras ventajas, permite mayor sensi-

bilidad en la adquisicion de datos desde los satelites, siendo de gran importancia

para este tipo de aplicaciones en las que se requiere obtener posiciones en ambientes

cerrados.

• Se recomienda extender la investigacion de esta aplicacion con la utilizacion de

otros servicios basados en la red de telefonıa celular GSM, como es el servicio MMS

(Multimedia Messaging System) o redes para la transmision de datos como la red

GPRS (General Packet Radio Service), con el fin de abrir las puertas al desarrollo

de aplicaciones que incluyan otro tipo de funcionalidades.

• Se recomienda continuar con la investigacion sobre el desarrollo de aplicaciones en la

plataforma J2ME, especialmente aquellas que implementen otros tipos de protocolos

de comunicaciones, como por ejemplo bluetooth; ası tambien, protocolos de alto nivel

como http (HyperText Transport Protocol).

• Para el desarrollo de aplicaciones en J2ME, se recomienda el uso de emuladores,

los cuales permiten probar estas aplicaciones de manera eficiente. Para este caso

existen varias opciones, entre ellas, los provistos por los fabricantes lıderes en el

mercado de la telefonıa celular, como son Nokia, Sony Ericsson y Motorola, que

ademas ofrecen variada informacion para desarrolladores en sus paginas web. Una

excelente alternativa es el emulador de Sun JavaTM Wireless Toolkit for CLDC que

fue empleado para el desarrollo de la aplicacion Scl.

GSM 7-bit Default Alphabet y codificacion de datos de 7 bits en octetos 138

Apendice A

GSM 7-bit Default Alphabet y codificacion de datos de 7 bits

en octetos

A.1 GSM 7-bit Default Alphabet

El siguiente es el alfabeto de 7 bits (7-bit Default Alphabet), especificado en el docu-

mento GSM 03.38. En la columna del extremo derecho se muestran los codigos decimales

correspondientes ISO-8859-1.

Hex Dec Nombre del caracter Caracter ISO-8859-1

0x00 0 COMMERCIAL AT @ 64

0x01 1 POUND SIGN £ 163

0x02 2 DOLLAR SIGN $ 36

0x03 3 YEN SIGN 165

0x04 4 LATIN SMALL LETTER E WITH GRAVE e 232

0x05 5 LATIN SMALL LETTER E WITH ACUTE e 233

0x06 6 LATIN SMALL LETTER U WITH GRAVE u 249

0x07 7 LATIN SMALL LETTER I WITH GRAVE ı 236

0x08 8 LATIN SMALL LETTER O WITH GRAVE o 242

0x09 9 LATIN CAPITAL LETTER C WITH CEDILLA C 199

0x0A 10 LINE FEED 10

0x0B 11 LATIN CAPITAL LETTER O WITH STROKE Ø 216

0x0C 12 LATIN SMALL LETTER O WITH STROKE ø 248

0x0D 13 CARRIAGE RETURN 13

0x0E 14 LATIN CAPITAL LETTER A WITH RING ABOVE A 197

0x0F 15 LATIN SMALL LETTER A WITH RING ABOVE a 229

0x10 16 GREEK CAPITAL LETTER DELTA ∆

0x11 17 LOW LINE 95



0x12 18 GREEK CAPITAL LETTER PHI Φ

0x13 19 GREEK CAPITAL LETTER GAMMA Γ

0x14 20 GREEK CAPITAL LETTER LAMBDA Λ

0x15 21 GREEK CAPITAL LETTER OMEGA Ω

0x16 22 GREEK CAPITAL LETTER PI Π

0x17 23 GREEK CAPITAL LETTER PSI Ψ

0x18 24 GREEK CAPITAL LETTER SIGMA Σ

0x19 25 GREEK CAPITAL LETTER THETA Θ

0x1A 26 GREEK CAPITAL LETTER XI Ξ

0x1B 27 ESCAPE TO EXTENSION TABLE

0x1B0A 27 10 FORM FEED 12

0x1B14 27 20 CIRCUMFLEX ACCENT ˆ 94

0x1B28 27 40 LEFT CURLY BRACKET 123

0x1B29 27 41 RIGHT CURLY BRACKET 125

0x1B2F 27 47 REVERSE SOLIDUS (BACKSLASH) \ 92

0x1B3C 27 60 LEFT SQUARE BRACKET [ 91

0x1B3D 27 61 TILDE ∼ 126

0x1B3E 27 62 RIGHT SQUARE BRACKET ] 93

0x1B40 27 64 VERTICAL BAR | 124

0x1C 28 LATIN CAPITAL LETTER AE Æ 198

0x1D 29 LATIN SMALL LETTER AE æ 230

0x1E 30 LATIN SMALL LETTER SHARP S (German) ß 223

0x1F 31 LATIN CAPITAL LETTER E WITH ACUTE E 201

0x20 32 SPACE 32

0x21 33 EXCLAMATION MARK ! 33

0x22 34 QUOTATION MARK ” 34

0x23 35 NUMBER SIGN # 35

0x25 37 PERCENT SIGN % 37

0x26 38 AMPERSAND & 38

0x27 39 APOSTROPHE ’ 39

0x28 40 LEFT PARENTHESIS ( 40

0x29 41 RIGHT PARENTHESIS ) 41

0x2A 42 ASTERISK * 42

0x2B 43 PLUS SIGN + 43



0x2C 44 COMMA , 44

0x2D 45 HYPHEN-MINUS - 45

0x2E 46 FULL STOP . 46

0x2F 47 SOLIDUS (SLASH) / 47

0x30 48 DIGIT ZERO 0 48

0x31 49 DIGIT ONE 1 49

0x32 50 DIGIT TWO 2 50

0x33 51 DIGIT THREE 3 51

0x34 52 DIGIT FOUR 4 52

0x35 53 DIGIT FIVE 5 53

0x36 54 DIGIT SIX 6 54

0x37 55 DIGIT SEVEN 7 55

0x38 56 DIGIT EIGHT 8 56

0x39 57 DIGIT NINE 9 57

0x3A 58 COLON : 58

0x3B 59 SEMICOLON ; 59

0x3C 60 LESS-THAN SIGN ¡ 60

0x3D 61 EQUALS SIGN = 61

0x3E 62 GREATER-THAN SIGN ¿ 62

0x3F 63 QUESTION MARK ? 63

0x40 64 INVERTED EXCLAMATION MARK ¡ 161

0x41 65 LATIN CAPITAL LETTER A A 65

0x42 66 LATIN CAPITAL LETTER B B 66

0x43 67 LATIN CAPITAL LETTER C C 67

0x44 68 LATIN CAPITAL LETTER D D 68

0x45 69 LATIN CAPITAL LETTER E E 69

0x46 70 LATIN CAPITAL LETTER F F 70

0x47 71 LATIN CAPITAL LETTER G G 71

0x48 72 LATIN CAPITAL LETTER H H 72

0x49 73 LATIN CAPITAL LETTER I I 73

0x4A 74 LATIN CAPITAL LETTER J J 74

0x4B 75 LATIN CAPITAL LETTER K K 75

0x4C 76 LATIN CAPITAL LETTER L L 76

0x4D 77 LATIN CAPITAL LETTER M M 77



0x4E 78 LATIN CAPITAL LETTER N N 78

0x4F 79 LATIN CAPITAL LETTER O O 79

0x50 80 LATIN CAPITAL LETTER P P 80

0x51 81 LATIN CAPITAL LETTER Q Q 81

0x52 82 LATIN CAPITAL LETTER R R 82

0x53 83 LATIN CAPITAL LETTER S S 83

0x54 84 LATIN CAPITAL LETTER T T 84

0x55 85 LATIN CAPITAL LETTER U U 85

0x56 86 LATIN CAPITAL LETTER V V 86

0x57 87 LATIN CAPITAL LETTER W W 87

0x58 88 LATIN CAPITAL LETTER X X 88

0x59 89 LATIN CAPITAL LETTER Y Y 89

0x5A 90 LATIN CAPITAL LETTER Z Z 90

0x5B 91 LATIN CAPITAL LETTER A WITH DIAERESIS A 196

0x5C 92 LATIN CAPITAL LETTER O WITH DIAERESIS O 214

0x5D 93 LATIN CAPITAL LETTER N WITH TILDE N 209

0x5E 94 LATIN CAPITAL LETTER U WITH DIAERESIS U 220

0x5F 95 SECTION SIGN § 167

0x60 96 INVERTED QUESTION MARK ¿ 191

0x61 97 LATIN SMALL LETTER A a 97

0x62 98 LATIN SMALL LETTER B b 98

0x63 99 LATIN SMALL LETTER C c 99

0x64 100 LATIN SMALL LETTER D d 100

0x65 101 LATIN SMALL LETTER E e 101

0x66 102 LATIN SMALL LETTER F f 102

0x67 103 LATIN SMALL LETTER G g 103

0x68 104 LATIN SMALL LETTER H h 104

0x69 105 LATIN SMALL LETTER I i 105

0x6A 106 LATIN SMALL LETTER J j 106

0x6B 107 LATIN SMALL LETTER K k 107

0x6C 108 LATIN SMALL LETTER L l 108

0x6D 109 LATIN SMALL LETTER M m 109

0x6E 110 LATIN SMALL LETTER N n 110

0x6F 111 LATIN SMALL LETTER O o 111



0x70 112 LATIN SMALL LETTER P p 112

0x71 113 LATIN SMALL LETTER Q q 113

0x72 114 LATIN SMALL LETTER R r 114

0x73 115 LATIN SMALL LETTER S s 115

0x74 116 LATIN SMALL LETTER T t 116

0x75 117 LATIN SMALL LETTER U u 117

0x76 118 LATIN SMALL LETTER V v 118

0x77 119 LATIN SMALL LETTER W w 119

0x78 120 LATIN SMALL LETTER X x 120

0x79 121 LATIN SMALL LETTER Y y 121

0x7A 122 LATIN SMALL LETTER Z z 122

0x7B 123 LATIN SMALL LETTER A WITH DIAERESIS a 228

0x7C 124 LATIN SMALL LETTER O WITH DIAERESIS o 246

0x7D 125 LATIN SMALL LETTER N WITH TILDE n 241

0x7E 126 LATIN SMALL LETTER U WITH DIAERESIS u 252

0x7F 127 LATIN SMALL LETTER A WITH GRAVE a 224

A.2 Codificacion de datos de 7 bits en octetos

El mensaje ”ESPE-DEEE” consiste de 9 caracteres, llamados septetos cuando cada uno

es representado por 7 bits. Estos septetos necesitan ser transformados en octetos para la

transferencia del mensaje SMS.

Mensaje E S P E - D E E E

ISO-8859-1 69 83 80 69 45 68 69 69 69

Septetos 1000101 1010011 1010000 1000101 0101101 1000100 1000101 1000101 1000101

1000101 1010011 1010000 1000101 0101101 1000100 1000101 1000101 1000101

El primer septeto (E) es convertido en octeto anadiendo el bit menos significativo del

segundo septeto. Este bit es insertado a la izquierda, lo que produce 11000101 (”C5”).

El bit menos significativo del segundo caracter es entonces usado, de tal manera que el

segundo caracter (septeto) necesita dos bits (en negrilla) del tercer caracter para trans-

formarse en octeto. Este proceso continua con el resto de caracteres produciendo los

siguientes octetos:

Octetos 11000101 00101001 10110100 11011000 00100010 00010110 10001011 01000101

C5 29 B4 D8 22 16 8B 45


Los 8 octetos procedentes de ”ESPE-DEEE” son C5 29 B4 D8 22 16 8B 45.

Hoja de especificaciones del modulo receptor SPK-GPS-GS405 144

Apendice B

Hoja de especificaciones del modulo receptor SPK-GPS-GS405

Hoja de especificaciones del microcontrolador PIC16F877A 148

Apendice C

Hoja de especificaciones del microcontrolador PIC16F877A

Hoja de especificaciones del regulador LM317 152

Apendice D

Hoja de especificaciones del regulador LM317


Apendice E

Hoja de especificaciones del regulador LM1117

Codigo del programa del microcontrolador PIC16F877A 156

Apendice F

Codigo del programa del microcontrolador PIC16F877A

//PARAMETROS DEL MICROCONTROLADOR PIC16F877A

#include <16F877A . h>

#dev i ce adc=10

#FUSES NOWDT //Watch Dog Timer desac t i vado

#FUSES XT //Osci lador de c r i s t a l <= 4mhz

#FUSES NOPUT //Power Up Timer desac t i vado

#FUSES NOPROTECT //Protecci on de l e c t u r a de l c od igo desac t i vada

#FUSES NODEBUG //Modo debug para ICD desac t i vado

#FUSES NOBROWNOUT //Brownout r e s e t desac t i vado

#FUSES NOLVP //Low vo l t a g e programming desac t i vado

#FUSES NOCPD //Protecci on EE desac t i vada

#FUSES NOWRT //Memoria de programa no pro t eg ida contra e s c r i t u r a

//COMUNICACION SERIAL

#use de lay ( c l o ck =4000000)

#use rs232 ( baud=9600 , pa r i t y=N, xmit=PIN B1 , rcv=PIN B0 , b i t s =8, stream=CEL)

#use rs232 ( baud=4800 , pa r i t y=N, xmit=PIN B3 , rcv=PIN B2 , b i t s =8, stream=GPS)

//LIBRERIAS

#include <s t d l i b . h>

#include <ctype . h>

#include <s t d i o . h>

//DIRECTIVAS

#byte puerto a=0x05

#byte puerto b=0x06

#byte puerto d=0x08

#byte puer to e=0x09

//CONSTANTES

#define LONGBUFFER 50

#define REPORTAR ”RP”

#define CONTROLAR ”CT”


#define CONFIGURAR ”CF”

#define NOTIFICAR ”NT”

#define CONFIRMAR ”AK”

#define ENT ANALOG ”AN”

#define DATOS GPS ”GP”

#define EMERGENCIA ”SOS”

#define ON ”ON”

#define OFF ”OFF”

const int ponderac ion [8 ]=128 ,64 , 32 , 16 , 8 , 4 , 2 , 1 ;

const char hexadecimal [17 ]=”0123456789ABCDEF” ;

const char c l ave [5 ]= ”SCL1” ;

//VARIABLES

char bu f f e r [LONGBUFFER] ;

int c on t bu f f e r ;

int cont cod ;

char entradas [5 ]= ”” ;

char s a l i d a s [6 ]= ”” ;

char aux [5 ]= ”” ;

char num usr [10]=”” ;

char numero [10]=”” ;

//FUNCIONES

//INICIALIZA EL BUFFER DE ENTRADA

void i n i t b u f f e r ( )

int i ;

for ( i =0; i<LONGBUFFER; i++)

bu f f e r [ i ]=0x00 ;

c on t bu f f e r =0;

void i n i t a ux ( )

int i ;

for ( i =0; i <5; i++)

aux [ i ]=0x00 ;

//ESTADO DE LAS ENTRADAS

void e s t en t r ada s ( )

int i ;

for ( i =0; i <4; i++)

i f ( b i t t e s t ( puerto b ,7− i ) )


entradas [ i ]= ’ 1 ’ ;

else

entradas [ i ]= ’ 0 ’ ;

//ESTADO DE LAS SALIDAS

void e s t s a l i d a s ( )

int i ;

for ( i =0; i <5; i++)

i f ( b i t t e s t ( puerto d ,7− i ) )

s a l i d a s [ i ]= ’ 1 ’ ;

else

s a l i d a s [ i ]= ’ 0 ’ ;

//ALGORITMO DE CODIFICACION DE DATOS DE 7 BITS EN OCTETOS

void c o d i f i c a c i o n ( )

int i ;

int j ;

int cont ;

int acum ;

char b ina r i o [9 ]= ”00000000” ;

//INICIALIZAR SECCION DE LA EEPROM PARA CODIFICACION

cont cod =0;

for ( i =15; i <64; i++)

write eeprom ( i , 0 x00 ) ;

for ( i =0, cont=0; i<s t r l e n ( bu f f e r ) ; i++,cont++)

i f ( cont==7)

cont=0;

i++;

i f ( i<s t r l e n ( bu f f e r ) )

//TRANSFORMACION DEL EQUIVALENTE ASCII DECIMAL A BINARIO

acum=0;

for ( j =0; j <8; j++)


i f ( ponderac ion [ j ]+acum>( int ) bu f f e r [ i ] )

b ina r i o [ j ]= ’ 0 ’ ;

else

b ina r i o [ j ]= ’ 1 ’ ;


//CODIFICACION DE DATOS DE 7 BITS EN OCTETOS

for ( j =0; j<8−cont ; j++)

b ina r i o [7− j ]= b ina r i o [7− cont−j ] ; // desp lazamiento de b i t s

i f ( bu f f e r [ i +1]!=0x00 )

acum=0;

for ( j =0; j <8; j++)

i f ( ponderac ion [ j ]+acum>( int ) bu f f e r [ i +1])

i f ( j>=7−cont )

b i na r i o [ j+cont−7]= ’ 0 ’ ;

else


i f ( j>=7−cont )

b i na r i o [ j+cont−7]= ’ 1 ’ ;

else

for ( j =0; j<cont ; j++)

b ina r i o [ j ]= ’ 0 ’ ;

//TRANSFORMAR DE BINARIO A HEXADECIMAL

//NIBBLE MAS SIGNIFICATIVO

acum=0;

for ( j =0; j <4; j++)

i f ( b i na r i o [ j ]== ’ 1 ’ )




//NIBBLE MENOS SIGNIFICATIVO

acum=0;

for ( j =0; j <4; j++)

i f ( b i na r i o [ j+4]== ’ 1 ’ )



//SUBRUTINA DE ENVIO DE SMS

void envio sms ( int long trama , char l ong datos1 , char l ong datos2 )

int i ;


i n i t a ux ( ) ;

//LECTURA DEL NUMERO DEL USUARIO DESDE LA EEPROM

for ( i =0; i <9; i++)

num usr [ i ]=read EEPROM( i ) ;

//FORMATO PDU DEL NUMERO DEL USUARIO

for ( i =0; i <7; i+=2)

aux [0 ]= num usr [ i ] ;

num usr [ i ]=num usr [ i +1] ;

num usr [ i +1]=aux [ 0 ] ;

aux [0 ]= num usr [ 8 ] ;

num usr [8 ]= ’F ’ ;

//LECTURA DEL MENSAJE CODIFICADO DESDE LA EEPROM

for ( i =0; i<cont cod ; i++)

bu f f e r [ i ]=read EEPROM(15+ i ) ;

delay ms ( 5 00 ) ;

f p r i n t f (CEL, ”AT+CMGD=1\r \n” ) ; /∗ borra e l mensaje entrante ya procesado ,

para e v i t a r que se sa ture l a memoria de l t e l e f o n o ∗/

delay ms ( 5 00 ) ;

//CONFIGURACION DEL MODEM EN MODO PDU

f p r i n t f (CEL, ”AT+CMGF=0\r \n” ) ;

delay ms ( 5 00 ) ;

//CONSTRUCCION DE LA TRAMA PDU Y ENVIO DE SMS

f p r i n t f (CEL, ”AT+CMGS=%d\ r \n” , long trama ) ;


delay ms ( 5 00 ) ;

f p r i n t f (CEL, ”0041000981% s%c0003%c%c06050440744074%s ” , num usr , aux [ 0 ] , \

l ong datos1 , long datos2 , bu f f e r ) ;

putc (26 ,CEL) ; //ASCII(26)=( c t r l+z ) envia e l mensaje

delay ms (3000 ) ;

#INT RB int pue r tob ( )

d i s a b l e i n t e r r u p t s (INT RB ) ; // d e s a b i l i t a in t e r rupc i o n

e s t en t r ada s ( ) ; // l e e e l es tado ac tua l de l a s entradas


s p r i n t f ( bu f f e r , ”%sE%s” ,NOTIFICAR, entradas ) ; /∗anade ”NT” y e l es tado de l a s

entradas a l mensaje de no t i f i c a c i o n ∗/



envio sms (26 , ’ 0 ’ , ’F ’ ) ; /∗26=numero de oc t e t o s de l a trama pdu , ”0F”=numero de

s e p t e t o s de l campo de datos de usuar io ∗/

e n ab l e i n t e r r up t s (INT RB ) ; // h a b i l i t a in t e r rupc i o n

delay ms ( 5 00 ) ;

f p r i n t f (CEL, ”AT+CMGF=1\r \n” ) ; // con f i gura e l modem en modo t e x t o

delay ms ( 5 00 ) ;


void main ( )

//VARIABLES DEL PROGRAMA PRINCIPAL

char ca r c r cb=0x00 ;

int con t com i l l a =0;

char ∗pos=NULL;

f loat temp ;

int i ;

//CONFIGURACION DEL MODEM

s e t t r i s a (0 x01 ) ;

puer to a=0x00 ;

delay ms ( 1000 ) ;

f p r i n t f (CEL, ”ATE0\ r \n” ) ; // d e s h a b i l i t a eco

delay ms ( 3 00 ) ;

f p r i n t f (CEL, ”AT+CPMS=\”ME\” ,\”ME\”\ r \n” ) ; // con f i gura memoria de almacenamiento de SMS

delay ms ( 3 00 ) ;

e n ab l e i n t e r r up t s (INT RB ) ; // h a b i l i t a in t e r rupc i o n de l puerto B

e n ab l e i n t e r r up t s (GLOBAL) ;

//CONFIGURACION CONVERSOR A/D


s e tup adc po r t s (AN0) ;

setup adc (ADC CLOCK INTERNAL) ;

s e t adc channe l ( 0 ) ;

//CONFIGURACION DE ENTRADAS Y PULLUPS PUERTO B

s e t t r i s b (0xF1 ) ;

po r t b pu l l up s (TRUE) ;

//CONFIGURACION DE SALIDAS

s e t t r i s d (0 x00 ) ;

puerto d=0x00 ;

s e t t r i s e (0 x00 ) ;

puer to e=0x00 ;

//ESTADO DE LAS ENTRADAS

e s t en t r ada s ( ) ;

while (1 )

//LECTURA DEL MENSAJE SMS

puer to e=0x01 ; // enciende l ed ind icador ( esperando sms nuevo )

con t com i l l a =0;


i n i t a ux ( ) ;

for ( i =0; i <10; i++)

numero [ i ]=0x00 ;

num usr [ i ]=0x00 ;

delay ms ( 5 00 ) ;

f p r i n t f (CEL, ”AT+CMGF=1\r \n” ) ; // con f i gura modo t e x t o

delay ms ( 5 00 ) ;


while (1 )

ca r c r cb=getc (CEL) ; // captura carac t e r e s proven ien te s de l modem gsm

i f ( c a r c r cb==0x22 ) //compara con e l carac t e r de comi l l a s (”)


i f ( c on t com i l l a==3 | | con t com i l l a==8)

bu f f e r [ c on t bu f f e r++]=ca r c r cb ; /∗almacena numero de l remitente y

contenido de l sms∗/

i f ( c a r c r cb==’K’ ) // carac t e r l im i t ador de f i n de sms


puer to e=0x00 ; //apaga l ed ind icador ( procesando sms nuevo )

break ;


i f ( strcmp ( bu f f e r , 0 x00 ) ) // v e r i f i c a que e l b u f f e r no e s t e vac ıo

i n i t a ux ( ) ;

//VALIDACION DE LA CLAVE DEL SISTEMA

s t r cpy ( aux , c l ave ) ;

i f ( s t r s t r ( bu f f e r , aux )!=NULL) /∗ va l i d a que e x i s t a l a

c l a v e de l s i s tema en l a cadena de t e x t o ∗/

//LEER NUMERO DEL REMITENTE

pos=s t r r c h r ( bu f f e r , 0 x22 ) ; // l o c a l i z a l a u l t ima comi l l a (”)

for ( i =0; i <8; i++)

−−pos ;

num usr [8− i ]=∗pos ; //almacena l o s d ı g i t o s d e l numero de l remitente

num usr [0 ]= ’ 0 ’ ;

//CONFIGURACION DEL NUMERO DEL USUARIO Y CLAVE DE EMERGENCIA

i n i t a ux ( ) ;

s t r cpy ( aux ,CONFIGURAR) ;

i f ( s t r s t r ( bu f f e r , aux )!=NULL) /∗ v e r i f i c a s i e x i s t e ”CF” dentro de l a cadena de

t e x t o ∗/

for ( i =0; i <9; i++)

write eeprom ( i , num usr [ i ] ) ; // graba e l numero de l usuar io en l a eeprom

//CONFIGURACION DE LA CLAVE DE EMERGENCIA

pos=s t r r c h r ( bu f f e r , ’C ’ ) ; // l o c a l i z a e l u l t imo carac t e r ’C ’

for ( i =0; i <4; i++)

pos++;

write eeprom (10+ i ,∗ pos ) ; // graba l a c l a v e de emergencia en l a eeprom

//REPORTE DE CONFIRMACION DE CONFIGURACION


s p r i n t f ( bu f f e r , ”%s ” ,CONFIGURAR) ; /∗anade ”CF” a l a cadena de t e x t o de l

mensaje de repor t e ∗/



envio sms (21 , ’ 0 ’ , ’A ’ ) ; /∗21=numero de oc t e t o s de l a trama pdu , ”0A”=numero

de s e p t e t o s de l campo de datos de usuar io ∗/


//VALIDACION DEL NUMERO DEL USUARIO

for ( i =0; i <9; i++)

numero [ i ]=read EEPROM( i ) ; // l e e numero de l usuar io desde l a eeprom

i f ( strcmp (numero , num usr)==0) /∗compara numero de l remitente con numero de l

usuar io ∗/

//CONTROL DE SALIDAS

i n i t a ux ( ) ;

s t r cpy ( aux ,CONTROLAR) ;

i f ( s t r s t r ( bu f f e r , aux )!=NULL) // s i e x i s t e ”CT” dentro de l a cadena de t e x t o

pos=s t r r c h r ( bu f f e r , ’S ’ ) ; // l o c a l i z a e l u l t imo carac t e r ’S ’

for ( i =0; i <5; i++)

pos++;

i f ( ’ 1 ’==∗pos )

b i t s e t ( puerto d ,7− i ) ; // ac t i v a s a l i d a

b i t s e t ( puerto a ,1+ i ) ; // ac t i v a l e d ind icador

else

b i t c l e a r ( puerto d ,7− i ) ; // de sac t i v a s a l i d a

b i t c l e a r ( puerto a ,1+ i ) ; // de sac t i v a l e d ind icador

//REPORTE DE ACTIVACION/DESACTIVACION DE SALIDAS

e s t s a l i d a s ( ) ;


s p r i n t f ( bu f f e r , ”%sS%s” ,CONFIRMAR, s a l i d a s ) ;

c o d i f i c a c i o n ( ) ;

envio sms (26 , ’ 1 ’ , ’ 0 ’ ) ;

//ENTRADA ANALOGICA

i n i t a ux ( ) ;

s t r cpy ( aux ,ENT ANALOG) ;

i f ( s t r s t r ( bu f f e r , aux )!=NULL) // s i e x i s t e ”AN” dentro de l a cadena de t e x t o

temp=read adc ( ) ; // l e e e l conversor A/D

temp=(temp/1023)∗500 ; // r e g l a de e qu i va l enc i a en C

//REPORTE DE TEMPERATURA


s p r i n t f ( bu f f e r , ”%s %02.2 f ” ,ENT ANALOG, temp ) ;


envio sms (26 , ’ 0 ’ , ’F ’ ) ;


//REPORTE DEL SISTEMA

i n i t a ux ( ) ;

s t r cpy ( aux ,REPORTAR) ;

i f ( s t r s t r ( bu f f e r , aux )!=NULL) // s i e x i s t e ”RP” dentro de l a cadena de t e x t o

e s t en t r ada s ( ) ; // l e e e l es tado de l a s entradas

e s t s a l i d a s ( ) ; // l e e e l es tado de l a s s a l i d a s

//REPORTE


s p r i n t f ( bu f f e r , ”%sS%sE%s” ,REPORTAR, s a l i d a s , entradas ) ;


envio sms (31 , ’ 1 ’ , ’ 5 ’ ) ;

//LOCALIZACION

i n i t a ux ( ) ;

s t r cpy ( aux ,DATOS GPS) ;

i f ( s t r s t r ( bu f f e r , aux )!=NULL) // s i e x i s t e ”GP” dentro de l a cadena de t e x t o


s p r i n t f ( bu f f e r , ”%s ” ,DATOS GPS) ;

c on t bu f f e r =2;

c on t com i l l a =0;

while (1 )

i f ( getc (GPS)== ’R ’ && getc (GPS)== ’M’ && getc (GPS)== ’C ’ )

// s i e x i s t e ”RMC” en l a trama r e c i b i d a desde e l GPS

while (1 )

ca r c r cb=getc (GPS) ; /∗ captura carac t e r e s proven ien te s de l

modulo recep tor GPS∗/

i f ( c a r c r cb==0x2C) //compara con e l carac t e r ’ , ’ (coma)


i f ( cont comi l l a >1 && cont comi l l a <7 && ca r c r cb !=0x2C)

bu f f e r [ c on t bu f f e r++]=ca r c r cb ;

i f ( c a r c r cb==’E ’ | | ca r c r cb==’W’ )


break ;

i f ( s t r c h r ( bu f f e r , ’A ’ )!=0x00 )


break ;

//REPORTE DE LOCALIZACION


envio sms (40 , ’ 2 ’ , ’ 0 ’ ) ;

else

//EMERGENCIA

//VALIDACION DE LA CLAVE DE EMERGENCIA

i n i t a ux ( ) ;

for ( i =0; i <4; i++)

aux [ i ]=read EEPROM(10+ i ) ; // l e e c l a v e de emergencia desde memoria eeprom

i f ( s t r s t r ( bu f f e r , aux )!=NULL) // v e r i f i c a s i e x i s t e l a c l a v e dentro de l a cadena

s t r cpy ( aux ,EMERGENCIA) ;

i f ( s t r s t r ( bu f f e r , aux )!=NULL) // v e r i f i c a s i e x i s t e ”SOS” dentro de l a cadena

s t r cpy ( aux ,ON) ;

i f ( s t r s t r ( bu f f e r , aux )!=NULL) // s i e x i s t e ”ON”

b i t s e t ( puerto d , 7 ) ; // ac t i v a l a s a l i d a 1

b i t s e t ( puerto a , 1 ) ; // ac t i v a e l l e d ind icador de es tado

s t r cpy ( aux ,OFF) ;

i f ( s t r s t r ( bu f f e r , aux )!=NULL) // s i e x i s t e ”OFF”

for ( i =0; i <5; i++)

b i t c l e a r ( puerto d ,7− i ) ; // de sac t i v a l a s s a l i d a s

b i t c l e a r ( puerto a ,1+ i ) ; // de sac t i v a l o s l e d s ind i cadores de es tado

Codigo de la aplicacion de administracion del SCL en J2ME 167

Apendice G

Codigo de la aplicacion de administracion del SCL en J2ME

G.1 Clase Scl

import javax . m i c roed i t i on . mid let . ∗ ;

import javax . m i c roed i t i on . l c du i . ∗ ;

import javax . m i c roed i t i on . i o . ∗ ;

import javax . w i r e l e s s . messaging . ∗ ;

public class Sc l extends MIDlet implements CommandListener , Runnable ,

MessageListener

public Display pan ta l l a ;

public Sistema s i s tema ;

private Fclave c l ave ;

private In t ro in t roducc i on ;

private L i s t menu ;

private Lcon f i gu rac i on con f i gu r a c i on ;

private Fno t i f i c a c i o n n o t i f i c a c i o n ;

private Aler t a l a rmaNot i f i c a c i on ;

private Image rec ib i rSms ;

private Fcontro l c on t r o l ;

private Fpet i c i on p e t i c i o n ;

private Command s a l i r ;

private Ticker t i c k ;

private St r ing [ ] conex iones ;

private MessageConnection msgCon ;

private Message mensaje ;

public Thread th ;

private St r ing d i r e c c i o n ;

private boolean formListo ;

private boolean enEjecuc ion ;

public Sc l ( )


panta l l a = Display . getDisp lay ( this ) ; // ob t i ene un ob j e t o d i s p l a y

s i s tema = new Sistema ( ) ;

c l ave = new Fclave ( this ) ;

S t r ing [ ] opConf =”Numero de l s i s tema ” , ”Entradas / Sa l i d a s ” , ”Clave” ;

c on f i gu r a c i on = new Lcon f i gu rac i on ( this , opConf ) ;

n o t i f i c a c i o n=null ;

try

r e c ib i rSms=Image . createImage ( ”/ rec ib i rSms . png” ) ;

catch ( Exception e )

System . out . p r i n t l n ( ”Error a l cargar arch ivo de imagen rec ib i rSms . png” ) ;

a l a rmaNot i f i c a c i on=new Aler t ( ” No t i f i c a c i o n de l Sistema” , ”Usted t i e n e una \

n o t i f i c a c i o n de l Sistema” , rec ib i rSms , AlertType .ALARM) ;

a l a rmaNot i f i c a c i on . setTimeout ( Ale r t .FOREVER) ;

enEjecuc ion=fa l se ;

f o rmListo=fa l se ;

t i c k = new Ticker ( ” Sistema de Control y Loca l i z a c i o n ” ) ;

S t r ing [ ] opc iones= ” Conf igurac i on ” , ”Control ” , ”Reporte ” , ” Loca l i z a c i o n ” , \

”Temperatura” ;

menu = new L i s t ( ”Menu” , L i s t . IMPLICIT , opciones , null ) ;

d i r e c c i o n=”sms : / / : ”+s i s tema . getPuertoRx ( ) ;

menu . s e tT i cke r ( t i c k ) ;

s a l i r = new Command( ” S a l i r ” ,Command.EXIT , 1 ) ;

menu . addCommand( s a l i r ) ;

menu . setCommandListener ( this ) ;

// Reg i s t ro PushRegistry para atender conexiones sms en e l puerto 16500

try

PushRegistry . r e g i s t e rConnec t i on ( d i r e c c i on , this . g e tC la s s ( ) . getName ( ) , ”∗” ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l r e g i s t r a r conexi on ” ) ;

public void startApp ( )

//RecordStore

s i s tema . c r e a rReg i s t r o s ( ) ;

//MessageConnection

i f (msgCon == null )

try


msgCon=(MessageConnection ) Connector . open ( d i r e c c i o n ) ;

msgCon . s e tMessageL i s t ene r ( this ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l c r ea r l a \

conexi on sms” ) ;

conex iones=PushRegistry . l i s tConne c t i on s ( true ) ;

i f ( conex iones == null | | conex iones . l ength == 0)

//El mid l e t es ac t i vado por e l usuar io

s i s tema . setActUsr ( true ) ;

else

//El mid l e t es ac t i vado por una conexi on entrante

s i s tema . setActUsr ( fa l se ) ;

th = new Thread ( this ) ;

th . s t a r t ( ) ;

panta l l a . se tCurrent ( c l ave ) ;

public void pauseApp ( )

th = null ;

public void destroyApp (boolean uncond i t i ona l )

panta l l a = null ;

s i s tema = null ;

i n t r oducc i on = null ;

c l ave = null ;

menu = null ;

c on f i gu r a c i on = null ;

c on t r o l = null ;

th = null ;

i f (msgCon != null )

try

msgCon . c l o s e ( ) ;



System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l c e r r a r l a \

conexi on para r e c epc i o n de l mensaje ” ) ;

not i fyDes t royed ( ) ;

public void commandAction (Command c , Di sp layab l e d)

i f ( c == s a l i r )

destroyApp ( fa l se ) ;

else

switch (menu . ge tSe l e c t ed Index ( ) )

case 0 :

panta l l a . se tCurrent ( c on f i gu r a c i on ) ;

break ;

case 1 :

c on t r o l = new Fcontro l ( this ) ;

pan ta l l a . se tCurrent ( c on t r o l ) ;

break ;

case 2 :

p e t i c i o n=new Fpet i c i on ( this , ”Reporte ” ) ;

pan ta l l a . se tCurrent ( p e t i c i o n ) ;

break ;

case 3 :

p e t i c i o n=new Fpet i c i on ( this , ” Loca l i z a c i o n ” ) ;


break ;

case 4 :

p e t i c i o n=new Fpet i c i on ( this , ”Anal og ica ” ) ;


break ;


// Ver opciones de l menu p r i n c i p a l

public void verOpciones ( )

enEjecuc ion=true ;

i f ( th == null )


th . s t a r t ( ) ;

panta l l a . se tCurrent (menu ) ;

menu . setCommandListener ( this ) ;

//Ver in t roducc i on

public void ve r In t roducc i on ( )

i n t r oducc i on = new In t ro ( this ) ;

pan ta l l a . se tCurrent ( in t roducc i on ) ;

//Ver menu de con f i gurac i on

public void verConf igurac ion ( )

panta l l a . se tCurrent ( c on f i gu r a c i on ) ;

c on f i gu r a c i on . setCommandListener ( c on f i gu r a c i on ) ;

//Ver pan t a l l a de no t i f i c a c i o n

public void v e rNo t i f i c a c i o n ( )

panta l l a . se tCurrent ( n o t i f i c a c i o n ) ;

n o t i f i c a c i o n . setCommandListener ( n o t i f i c a c i o n ) ;

//Ver pan t a l l a para operac iones de con t ro l de s a l i d a s

public void verContro l ( )

panta l l a . se tCurrent ( c on t r o l ) ;

c on t r o l . setCommandListener ( c on t r o l ) ;

public boolean getFormListo ( )

return formListo ;

public void setFormListo (boolean formListo )


this . f o rmListo=formListo ;

public boolean getEnEjecucion ( )

return enEjecuc ion ;

public void setEnEjecuc ion (boolean enEjecuc ion )

this . enEjecuc ion=enEjecuc ion ;

//Funcion que n o t i f i c a e l a r r i vo de un mensaje nuevo

public void not i fyIncomingMessage ( MessageConnection msgCon)

i f ( th == null )


th . s t a r t ( ) ;

//Funcion de l a i n t e r f a z Runnable

public void run ( )

while ( true )

try

mensaje = msgCon . r e c e i v e ( ) ; // r e c i b e e l mensaje nuevo

i f ( mensaje != null && mensaje instanceof TextMessage )

i f ( n o t i f i c a c i o n==null )

n o t i f i c a c i o n=new Fno t i f i c a c i o n ( this ) ; /∗ crea e l formular io para

no t i f i c a c i o n e s o repor t e s ∗/

else

n o t i f i c a c i o n=null ;

n o t i f i c a c i o n=new Fno t i f i c a c i o n ( this ) ;

n o t i f i c a c i o n . prepararFormular io ( ( ( TextMessage ) mensaje ) . getPayloadText ( ) ) ;

setFormListo ( true ) ;

i f ( enEjecuc ion==true )

panta l l a . se tCurrent ( a la rmaNot i f i cac ion , n o t i f i c a c i o n ) ;

this . setEnEjecuc ion ( true ) ;



System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l l anza r e l h i l o \

para r e c epc i o n de l mensaje ” ) ;

G.2 Clase Sistema

import javax . m i c roed i t i on . rms . ∗ ;

public class Sistema

private RecordStore r s ;

private int numEntradas ;

private int numSalidas ;

private St r ing puertoTx ;

private St r ing puertoRx ;

private St r ing c l a v eS c l ;

//Numeros de ID de l o s r e g i s t r o s

private int idRegClave ;

private int idRegNumSistema ;

private int [ ] idRegEtiqEntradas ;

private int [ ] i dRegEt iqSa l idas ;

private int idRegEstEntradas ;

private int idRegEstSa l idas ;

//Datos de l o s r e g i s t r o s

private byte [ ] regClave ;

private byte [ ] regNumSistema ;

private byte [ ] r egEt ique ta s ;

private byte [ ] regEstados ;

private boolean actUsr ;

//Datos para l a funci on de l o c a l i z a c i o n

private int latGrad ;

private int latMin ;

private int lonGrad ;

private int lonMin ;

//Codigos de l s i s tema para l a s operac iones de con t ro l y l o c a l i z a c i o n

private St r ing [ ] cod igos=”CF” , ”CT” , ”AK” , ”RP” , ”AN” , ”GP” , ”NT” ;

public Sistema ( )

// I n i c i a l i z a c i o n de a t r i b u t o s de l a c l a s e

r s=null ;


idRegClave=1;

idRegNumSistema=2;

puertoTx=new St r ing ( ”16000” ) ;

puertoRx=new St r ing ( ”16500” ) ;

c l a v eS c l=new St r ing ( ”SCL1” ) ;

numEntradas=4;

numSalidas=5;

idRegEtiqEntradas=new int [ numEntradas ] ;

idRegEt iqSa l idas=new int [ numSalidas ] ;

for ( int i =0; i<numEntradas ; i++)

idRegEtiqEntradas [ i ]= i +3;

for ( int i =0; i<numSalidas ; i++)

idRegEt iqSa l idas [ i ]= i +7;

idRegEstEntradas=12;

idRegEstSa l idas =13;

//Manejo de l Record Store

public void abr i rRecordStore ( )

try

r s = RecordStore . openRecordStore ( ”Memoria” , true ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l ab r i r e l RecordStore ” ) ;

public void c r e a rReg i s t r o s ( )

abr i rRecordStore ( ) ;

i f ( getNumRegistros ( ) == 0)

/∗Reg i s t ro s : c lave , numero de l sistema , e t i q u e t a s entradas (4) ,

e t i q u e t a s s a l i d a s (5) , e s tados entradas ∗/

St r ing [ ] r e g i s t r o s=”123” , ”” , ”Entrada 1” , ”Entrada 2” , ”Entrada 3” , ”Entrada 4” , \

” Sa l ida 1” , ” Sa l ida 2” , ” Sa l ida 3” , ” Sa l ida 4” , ” Sa l ida 5” , ”0000” , ”00000” ;

try

//Crea r e g i s t r o de c l a v e de l s i s tema

regClave=r e g i s t r o s [ 0 ] . getBytes ( ) ;

r s . addRecord ( regClave , 0 , regClave . l ength ) ;

//Crea r e g i s t r o de numero de l s i s tema

regNumSistema=r e g i s t r o s [ 1 ] . getBytes ( ) ;

r s . addRecord ( regNumSistema , 0 , regNumSistema . l ength ) ;

//Crea r e g i s t r o s de l a s e t i q u e t a s de entradas y s a l i d a s


for ( int i =0; i<numEntradas+numSalidas ; i++)

r egEt ique ta s=r e g i s t r o s [2+ i ] . getBytes ( ) ;

r s . addRecord ( regEt iquetas , 0 , r egEt ique ta s . l ength ) ;

//Crea r e g i s t r o s de l o s es tados de l a s entradas

regEstados=r e g i s t r o s [ 1 1 ] . getBytes ( ) ;

r s . addRecord ( regEstados , 0 , regEstados . l ength ) ;

//Crea r e g i s t r o s de l o s es tados de l a s s a l i d a s

regEstados=r e g i s t r o s [ 1 2 ] . getBytes ( ) ;

r s . addRecord ( regEstados , 0 , regEstados . l ength ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l c r ea r l o s r e g i s t r o s ” ) ;

ce r ra rRecordStore ( ) ;

public void ce r ra rRecordStore ( )

try

r s . c l o s eRecordStore ( ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l c e r r a r RecordStore ” ) ;

public int getNumRegistros ( )

int numRegistros=0;

try

numRegistros=r s . getNumRecords ( ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l obtener e l numero de \

r e g i s t r o s ” ) ;

return numRegistros ;

//Metodos s e t de l o s a t r i b u t o s


public void se tClave ( S t r ing c l ave )


regClave=c lave . getBytes ( ) ;

try

r s . setRecord ( idRegClave , regClave , 0 , regClave . l ength ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l e s c r i b i r c l ave ” ) ;


public void setNumSistema ( St r ing numSistema )


regNumSistema=numSistema . getBytes ( ) ;

try

r s . setRecord ( idRegNumSistema , regNumSistema , 0 , regNumSistema . l ength ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l e s c r i b i r numero \

de l s i s tema ” ) ;


public void s e tEt i que ta s ( S t r ing e t iqueta , int idRegEtiq )


r egEt ique ta s=e t i que t a . getBytes ( ) ;

try

r s . setRecord ( idRegEtiq , regEt iquetas , 0 , r egEt ique ta s . l ength ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l e s c r i b i r l a s \

e t i qu e t a s ” ) ;


public void se tEstados ( S t r ing entSal , S t r ing es tados )


int idReg ;

S t r ing objEntSal=new St r ing ( entSa l ) ;

i f ( objEntSal . equa l s (new St r ing ( ” entradas ” ) ) )

idReg=idRegEstEntradas ;

else

idReg=idRegEstSa l idas ;


regEstados=estados . getBytes ( ) ;

try

r s . setRecord ( idReg , regEstados , 0 , regEstados . l ength ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l e s c r i b i r l o s e s tados ” ) ;


public void setActUsr (boolean actUsr )

this . actUsr=actUsr ;

public void setLatGrad ( int latGrad )

this . latGrad=latGrad ;

public void setLatMin ( int latMin )

this . latMin=latMin ;

public void setLonGrad ( int lonGrad )

this . lonGrad=lonGrad ;

public void setLonMin ( int lonMin )

this . lonMin=lonMin ;

//Metodos ge t de l o s a t r i b u t o s

public int [ ] getIdRegEtiqEntradas ( )

return idRegEtiqEntradas ;

public int [ ] g e t IdRegEt iqSa l idas ( )


return i dRegEt iqSa l idas ;

public St r ing getClave ( )

St r ing c l ave=null ;


regClave = new byte [ 1 0 ] ;

try

regClave=r s . getRecord ( idRegClave ) ;

c l ave=new St r ing ( regClave ) ;


c l ave=new St r ing ( ”” ) ;

System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l l e e r c l ave ” ) ;


return c l ave ;

public St r ing getNumSistema ( )

St r ing numSistema=null ;


regNumSistema = new byte [ 9 ] ;

try

regNumSistema=rs . getRecord ( idRegNumSistema ) ;

numSistema=new St r ing ( regNumSistema ) ;


numSistema=new St r ing ( ”” ) ;

System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l l e e r e l numero de l \

s i s tema ” ) ;


return numSistema ;

public St r ing ge tEt ique ta s ( int idRegEtiq )

St r ing e t i qu e t a s=null ;



r egEt ique ta s = new byte [ 1 5 ] ;

try

r egEt ique ta s=r s . getRecord ( idRegEtiq ) ;

e t i q u e t a s=new St r ing ( r egEt ique ta s ) ;


e t i qu e t a s=new St r ing ( ”” ) ;

System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l l e e r l a s e t i qu e t a s ” ) ;


return e t i qu e t a s ;

public St r ing getEstados ( S t r ing entSa l )

St r ing es tados=null ;

S t r ing objEntSal=new St r ing ( entSa l ) ;

int numBytes=0;

int idReg=0;

i f ( objEntSal . equa l s (new St r ing ( ” entradas ” ) ) )

numBytes=numEntradas ;

idReg=idRegEstEntradas ;

i f ( objEntSal . equa l s (new St r ing ( ” s a l i d a s ” ) ) )

numBytes=numSalidas ;

idReg=idRegEstSa l idas ;


regEstados = new byte [ numBytes ] ;

try

regEstados=r s . getRecord ( idReg ) ;

e s tados=new St r ing ( regEstados ) ;


e s tados=new St r ing ( ”” ) ;

System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l l e e r l o s e s tados ” ) ;


return e s tados ;


public int getNumEntradas ( )

return numEntradas ;

public int getNumSalidas ( )

return numSalidas ;

public St r ing getPuertoRx ( )

return puertoRx ;

public St r ing getPuertoTx ( )

return puertoTx ;

public St r ing getClaveSc l ( )

return c l a v eS c l ;

public boolean getActUsr ( )

return actUsr ;

public St r ing getCodigos ( int i )

return cod igos [ i ] ;

public int getLatGrad ( )

return latGrad ;

public int getLatMin ( )

return latMin ;

public int getLonGrad ( )

return lonGrad ;

public int getLonMin ( )

return lonMin ;


G.3 Clase Fclave


public class Fclave extends Form implements CommandListener

private TextFie ld ingClave ;


private St r ing c l ave ;

private St r ing compClave ;


private Command aceptar ;

private Cdenegado denegado ;

private int i n t en t o s ;

private Sc l s c l ;

public Fclave ( Sc l s c l )

super ( ” Autent i cac i on de usuar io ” ) ;

this . s c l=s c l ;

ingClave=new TextFie ld ( ” Ing r e s a r c l ave :\n” , ”” ,10 , TextFie ld .NUMERIC | TextFie ld .PASSWORD) ;

t i c k=new Ticker ( ” Sistema de Control y Loca l i z a c i o n ” ) ;

c l ave=new St r ing ( ) ;

compClave=new St r ing ( ) ;

s a l i r=new Command( ” S a l i r ” ,Command.EXIT , 1 ) ;

aceptar=new Command( ”Aceptar” ,Command.OK, 1 ) ;

this . s e tT i cke r ( t i c k ) ;

this . append ( ingClave ) ;

this . addCommand( s a l i r ) ;

this . addCommand( aceptar ) ;

this . setCommandListener ( this ) ;

denegado=new Cdenegado ( s c l ) ;

i n t en t o s =0;


i f ( c==s a l i r )

s c l . destroyApp ( fa l se ) ;

i f ( c==aceptar )

c l ave=s c l . s i s tema . getClave ( ) ;

compClave=ingClave . g e tS t r i ng ( ) ;

i f ( c l ave . equa l s ( compClave ) )


i f ( s c l . s i s tema . getActUsr ( ) == true )

s c l . v e r In t roducc i on ( ) ;

else

while ( s c l . getFormListo ( ) == fa l se )

s c l . v e rNo t i f i c a c i o n ( ) ;

else

i n t en t o s++;

ingClave . s e t S t r i n g ( ”” ) ;

i f ( i n t en t o s == 3)

s c l . pan ta l l a . se tCurrent ( denegado ) ;

// Panta l l a de adver t enc ia ¡ACCESO DENEGADO!

class Cdenegado extends Canvas implements CommandListener

private Image imagen ;



public Cdenegado ( Sc l s c l )


aceptar=new Command( ”Aceptar” ,Command.EXIT , 1 ) ;



try

imagen=Image . createImage ( ”/AccesoDenegado . png” ) ;


System . out . p r i n t l n ( ”Error a l cargar arch ivo de imagen AccesoDenegado . png” ) ;


public void paint ( Graphics g )

g . s e tCo lo r (255 , 255 , 255 ) ;

g . f i l l R e c t (0 , 0 , getWidth ( ) , getHeight ( ) ) ;

//Imagen

g . drawImage ( imagen , getWidth ( )/2 , getHeight ( )/2 , Graphics .HCENTER| Graphics .VCENTER) ;

//Color de l t e x t o

g . s e tCo lo r ( 0 , 0 , 0 ) ;

//Texto : ¡Acceso Denegado !

Font fuente=Font . getFont ( Font .FACE PROPORTIONAL, Font .STYLE BOLD, Font . SIZE LARGE) ;

g . setFont ( fuente ) ;

g . drawString ( ”¡ACCESO DENEGADO! ” , getWidth ( )/2 , \

getHeight ()/2− imagen . getHeight ()/2−10 , Graphics .BASELINE | Graphics .HCENTER) ;

//Texto : Mensaje

f uente=Font . getFont ( Font .FACE PROPORTIONAL, Font . STYLE PLAIN, Font .SIZE MEDIUM) ;

g . setFont ( fuente ) ;


i f ( c==aceptar )

s c l . destroyApp ( fa l se ) ;

s c l . not i fyDes t royed ( ) ;

G.4 Clase Intro

import java . i o . ∗ ;


import javax . m i c roed i t i on . media . ∗ ;

import javax . m i c roed i t i on . media . c on t r o l . ∗ ;

public class In t ro extends Canvas implements PlayerL i s t ene r , Runnable


private St r ing MIMEtype ;

private Player p laye r ;

private St r ing arch ivo ;

public In t ro ( Sc l s c l )


this . a r ch ivo=”/ i n t r o . g i f ” ;


this .MIMEtype=”image/ g i f ” ;

Thread h i l o=new Thread ( this ) ;

h i l o . s t a r t ( ) ;

public void keyPressed ( int keyCode )

detenerP layer ( ) ;

s c l . verOpciones ( ) ;

public void paint ( Graphics g )

int x = g . getClipX ( ) ;

int y = g . getClipY ( ) ;

int w = g . getClipWidth ( ) ;

int h = g . getCl ipHe ight ( ) ;

g . s e tCo lo r (255 , 255 , 255 ) ;

g . f i l l R e c t (x , y , w, h ) ;

public void run ( )

this . p lay ( arch ivo ) ;

public void playerUpdate ( Player player , S t r ing p l aye r s t a t e , Object ob j e c t )

i f ( p l a y e r s t a t e == Playe rL i s t ene r .END OF MEDIA)

try

r e s e t p l a y e r ( ) ;

catch ( MediaException me)

System . out . p r i n t l n ( ”Error 2” ) ;

p laye r = null ;


private void r e s e t p l a y e r ( ) throws MediaException


i f ( p laye r != null )

p laye r . c l o s e ( ) ;

p laye r = null ;

private void play ( S t r ing arch ivo )

try

InputStream i s=getC la s s ( ) . getResourceAsStream ( arch ivo ) ;

VideoControl vc ;


// Crea una in s t anc i a de l reproductor

p laye r = Manager . c r ea t eP laye r ( i s , this .MIMEtype ) ;

p laye r . p r e f e t ch ( ) ;

p laye r . addPlayerL i s tener ( this ) ;

vc = ( VideoControl ) p laye r . getContro l ( ”VideoControl ” ) ;

i f ( vc != null )

vc . in itDisplayMode ( VideoControl .USE DIRECT VIDEO, this ) ;

vc . s e tD i sp layLocat i on ( ( ( this . getWidth()−vc . getDisplayWidth ( ) ) / 2 ) , \

( this . getHeight ()−vc . getDisp layHeight ( ) ) / 2 ) ;

vc . s e tV i s i b l e ( true ) ;

this . setFul lScreenMode ( true ) ;

p laye r . s t a r t ( ) ;

this . s c l . pan ta l l a . se tCurrent ( this ) ;

catch ( Throwable t )

System . out . p r i n t l n ( ”Error 3” ) ;

p laye r = null ;


private void detenerP layer ( )

try


catch ( MediaException e )

System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l r e s e t e a r e l r eproductor ” ) ;


p laye r = null ;

G.5 Clase Lconfiguracion


public class Lcon f i gu rac i on extends L i s t implements CommandListener



private Command at ra s ;

private FnumSistema numSistema ;

private FentSal entSa l ;

private FeditClave ed i tC lave ;

public Lcon f i gu rac i on ( Sc l s c l , S t r ing [ ] opc iones )

super ( ” Conf igurac i on ” , L i s t . IMPLICIT , opciones , null ) ;


t i c k=new Ticker ( ” E l i j a l a opci on que desea ed i t a r . . . ” ) ;

a t r a s=new Command( ”Atras ” ,Command.BACK, 1 ) ;


this . addCommand( a t r a s ) ;



i f ( c == at ra s )


else

switch ( this . g e tSe l e c t ed Index ( ) )

case 0 :

numSistema = new FnumSistema ( s c l ) ;

s c l . pan ta l l a . se tCurrent ( numSistema ) ;

break ;

case 1 :


entSa l = new FentSal ( s c l , this ) ;

s c l . pan ta l l a . se tCurrent ( entSa l ) ;

break ;

case 2 :

ed i tC lave = new FeditClave ( s c l , this ) ;

s c l . pan ta l l a . se tCurrent ( ed i tC lave ) ;

break ;

class FnumSistema extends Form implements CommandListener

private Ticker i nd i c a c i on ;

private TextFie ld numero ;

private TextFie ld c laveSos ;

private TextFie ld conf i rmarClaveSos ;

private Aler t numIncorrecto ;

private Aler t c l a v e I n c o r r e c t a ;

private Aler t ing r e sa rC lave ;

private Aler t numCharClave ;

private Command atras , aceptar ;


public FnumSistema ( Sc l s c l )

super ( ”Numero de l Sistema” ) ;


i nd i c a c i on=new Ticker ( ” Ing r e s e e l numero de l c e l u l a r de l s i s tema . . . ” ) ;

numero=new TextFie ld ( ”Numero : ” , ”” , 9 , TextFie ld .NUMERIC) ;

c l aveSos=new TextFie ld ( ” Ing r e s a r c l ave de emergencia (4 c a r a c t e r e s ) : \ n” , ”” ,4 , \

TextFie ld .NUMERIC | TextFie ld .PASSWORD) ;

conf i rmarClaveSos=new TextFie ld ( ”Confirmar c l ave de emergencia :\n” , ”” ,4 , \

TextFie ld .NUMERIC | TextFie ld .PASSWORD) ;

numIncorrecto=new Aler t ( ”Numero In co r r e c t o ” , ” Ing r e s e correctamente e l numero \

t e l e f o n i c o de l Sistema” , null , AlertType .ERROR) ;

numIncorrecto . setTimeout ( Ale r t .FOREVER) ;

c l a v e I n c o r r e c t a=new Aler t ( ”” , ”Los campos no co inc iden ” , null , AlertType .ERROR) ;

c l a v e I n c o r r e c t a . setTimeout ( Ale r t .FOREVER) ;

ing r e sa rC lave=new Aler t ( ”” , ” Ing r e s e l a c l ave de emergencia ” , null , AlertType .ERROR) ;

ing r e sa rC lave . setTimeout ( Ale r t .FOREVER) ;

numCharClave=new Aler t ( ”” , ” Ing r e s e 4 c a r a c t e r e s ” , null , AlertType .ERROR) ;


i ng r e sa rC lave . setTimeout ( Ale r t .FOREVER) ;

a t r a s=new Command( ”Atras ” , Command.BACK, 1 ) ;

aceptar=new Command( ”Aceptar” , Command.OK, 1 ) ;

this . s e tT i cke r ( i nd i c a c i on ) ;

this . append (numero ) ;

this . append ( c laveSos ) ;

this . append ( conf i rmarClaveSos ) ;





i f ( c==at ra s )

s c l . ve rConf igurac ion ( ) ;

i f ( c==aceptar )

St r ing numTelefono=numero . g e tS t r i ng ( ) ;

//Valida que sea numero t e l e f o n i c o

i f ( numTelefono . l ength ()==9 && ( numTelefono . s tartsWith ( ”09” ) | | \

numTelefono . s tartsWith ( ”08” ) ) \

&& ( c laveSos . g e tS t r i ng ( ) . equa l s ( conf i rmarClaveSos . g e tS t r i ng ( ) ) ) && \

c laveSos . g e tS t r i ng ( ) . equa l s ( ””)==fa l se && claveSos . s i z e ()==4)

/∗Guarda e l numero de l s i s tema y envia un sms de con f i gurac i on de l numero

de l s i s tema ”CF”∗/

s c l . s i s tema . setNumSistema ( numTelefono ) ;

new Fesperar ( s c l ) ;

new FenvioSms ( s c l , s c l . s i s tema . getCodigos (0)+”C”+c laveSo s . g e tS t r i ng ( ) ) ;

else i f ( numTelefono . l ength () !=9 | | ( numTelefono . s tartsWith ( ”09”)==fa l se && \

numTelefono . s tartsWith ( ”08”)==fa l se ) )

s c l . pan ta l l a . se tCurrent ( numIncorrecto , this ) ;

else i f ( c l aveSos . g e tS t r i ng ( ) . equa l s ( ”” ) )

s c l . pan ta l l a . se tCurrent ( ingre sarClave , this ) ;

else i f ( c l aveSos . s i z e ( ) !=4)

s c l . pan ta l l a . se tCurrent ( numCharClave , this ) ;

else

s c l . pan ta l l a . se tCurrent ( c l av e In co r r e c t a , this ) ;

c l aveSos . s e t S t r i n g ( ”” ) ;

conf i rmarClaveSos . s e t S t r i n g ( ”” ) ;


class FentSal extends Form implements CommandListener


private Str ingItem encEntradas ;

private Str ingItem encSa l i da s ;

private TextFie ld [ ] s a l i d a s ;

private TextFie ld [ ] entradas ;




private Image ok ;

public FentSal ( Sc l s c l , Lcon f i gu rac i on con f i gu r a c i on )

super ( ”Entradas / Sa l i d a s ” ) ;


this . c on f i gu r a c i on=con f i gu r a c i on ;

i nd i c a c i on=new Ticker ( ” Ing r e s e un nombre para l a s entradas / s a l i d a s de l s i s tema . . . ” ) ;


encEntradas=new Str ingItem ( ”Entradas : ” , ”” ) ;

this . append ( encEntradas ) ;

entradas=new TextFie ld [ s c l . s i s tema . getNumEntradas ( ) ] ;

for ( int i =0; i<s c l . s i s tema . getNumEntradas ( ) ; i++)

entradas [ i ]=new TextFie ld ( S t r ing . valueOf ( i +1) , s c l . s i s tema . ge tEt ique ta s (3+ i ) , \

15 , TextFie ld .ANY) ;

this . append ( entradas [ i ] ) ;

encSa l i da s=new Str ingItem ( ” Sa l i d a s : ” , ”” ) ;

this . append ( encSa l i da s ) ;

s a l i d a s=new TextFie ld [ s c l . s i s tema . getNumSalidas ( ) ] ;

for ( int i =0; i<s c l . s i s tema . getNumSalidas ( ) ; i++)

s a l i d a s [ i ]=new TextFie ld ( S t r ing . valueOf ( i +1) , s c l . s i s tema . ge tEt ique ta s (7+ i ) , 15 , \

TextFie ld .ANY) ;

this . append ( s a l i d a s [ i ] ) ;








i f ( c==at ra s )


i f ( c==aceptar )


s c l . s i s tema . s e tEt i que ta s ( entradas [ i ] . g e tS t r i ng ( ) , i +3);


s c l . s i s tema . s e tEt i que ta s ( s a l i d a s [ i ] . g e tS t r i ng ( ) , i +7);

try

ok=Image . createImage ( ”/ok . png” ) ;


System . out . p r i n t l n ( ”Error a l cargar arch ivo de imagen ok . png” ) ;

Aler t con fEt ique ta s=new Aler t ( ”” , ”Los cambios se han r e a l i z a d o \

s a t i s f a c t o r i amen t e ” , ok , AlertType .CONFIRMATION) ;

con fEt ique ta s . setTimeout ( Ale r t .FOREVER) ;

s c l . pan ta l l a . se tCurrent ( con fEt iquetas , c on f i gu r a c i on ) ;

class FeditClave extends Form implements CommandListener


private TextFie ld nuevaClave ;

private TextFie ld confirmarNuevaClave ;




private Image ok ;

public FeditClave ( Sc l s c l , Lcon f i gu rac i on con f i gu r a c i on )

super ( ”Clave” ) ;


this . c on f i gu r a c i on=con f i gu r a c i on ;

i nd i c a c i on=new Ticker ( ” Conf igurac i on de nueva c l ave . ” ) ;

nuevaClave=new TextFie ld ( ” Ing r e s a r c l ave :\n” , ”” ,10 , TextFie ld .NUMERIC | \

TextFie ld .PASSWORD) ;


confirmarNuevaClave=new TextFie ld ( ”Confirmar c l ave :\n” , ”” ,10 , TextFie ld .NUMERIC | \

TextFie ld .PASSWORD) ;




this . append ( nuevaClave ) ;

this . append ( confirmarNuevaClave ) ;





i f ( c==at ra s )


i f ( c==aceptar )

i f ( nuevaClave . g e tS t r i ng ( ) . equa l s ( confirmarNuevaClave . g e tS t r i ng ( ) ) )

s c l . s i s tema . setClave ( nuevaClave . g e tS t r i ng ( ) ) ;

try

ok=Image . createImage ( ”/ok . png” ) ;


System . out . p r i n t l n ( ”Error a l cargar arch ivo de imagen ok . png” ) ;

Aler t c l aveCor r ec ta=new Aler t ( ”” , ”La c l ave ha s ido con f igurada \

s a t i s f a c t o r i amen t e ” , ok , AlertType .CONFIRMATION) ;

c l aveCor r ec ta . setTimeout ( Ale r t .FOREVER) ;

s c l . pan ta l l a . se tCurrent ( c laveCorrecta , c on f i gu r a c i on ) ;

else

Aler t c l a v e I n c o r r e c t a=new Aler t ( ”” , ”Los campos no co inc iden ” , null , \

AlertType .ERROR) ;

c l a v e I n c o r r e c t a . setTimeout ( Ale r t .FOREVER) ;

nuevaClave . s e t S t r i n g ( ”” ) ;

confirmarNuevaClave . s e t S t r i n g ( ”” ) ;

s c l . pan ta l l a . se tCurrent ( c l av e In co r r e c t a , this ) ;


G.6 Clase Fcontrol


public class Fcontro l extends Form implements CommandListener


private Image [ ] estadosImg ;

private ChoiceGroup [ ] s a l i d a s ;

private Command aceptar , a t r a s ;


public Fcontro l ( Sc l s c l )

super ( ”Control de Sa l i d a s de l Sistema” ) ;


t i c k=new Ticker ( ” Estab lezca e l estado de l a s s a l i d a s . . . ” ) ;

s a l i d a s=new ChoiceGroup [ s c l . s i s tema . getNumSalidas ( ) ] ;

S t r ing [ ] e s tados=” o f f ” , ”on” ;

try

estadosImg=new Image [ 2 ] ;

estadosImg [0 ]= Image . createImage ( ”/ r o j o . png” ) ;

estadosImg [1 ]= Image . createImage ( ”/ verde . png” ) ;


System . out . p r i n t l n ( ”Error a l cargar arch ivo de imagen ro j o . png/ verde . png” ) ;

St r ing estadosAnt=s c l . s i s tema . getEstados ( ” s a l i d a s ” ) ;


s a l i d a s [ i ]=new ChoiceGroup ( s c l . s i s tema . ge tEt ique ta s ( i+7)+” : ” , ChoiceGroup .POPUP, \

estados , estadosImg ) ;

s a l i d a s [ i ] . s e tS e l e c t ed Index ( In t eg e r . pa r s e In t ( estadosAnt . sub s t r i ng ( i , i +1)) , true ) ;

this . append ( s a l i d a s [ i ] ) ;


a t r a s=new Command( ”Atras ” ,Command.BACK, 1 ) ;







i f ( c==at ra s )


i f ( c==aceptar )

St r i ngBu f f e r estadosAct=new St r i ngBu f f e r ( ”” ) ;


estadosAct . append ( St r ing . valueOf ( s a l i d a s [ i ] . g e tSe l e c t ed Index ( ) ) ) ;


new FenvioSms ( s c l , s c l . s i s tema . getCodigos (1)+”S”+estadosAct . t oS t r i ng ( ) ) ;

G.7 Clase Fpeticion


public class Fpet i c i on extends Form implements CommandListener

private Str ingItem av i so ;

private St r ing t i tu loForm ;

private Command aceptar , c anc e l a r ;


public Fpet i c i on ( Sc l s c l , S t r ing t i tu loForm )

super ( t i tu loForm ) ;


this . t i tu loForm=new St r ing ( t i tu loForm ) ;

i f ( t i tu loForm . equa l s ( ”Reporte ” ) )

av i so=new Str ingItem ( ”” , ”\nSe r e a l i z a r a una p e t i c i o n de r epo r t e a l s i s tema . \

\n\n ¿Desea cont inuar ?” ) ;

else i f ( t i tu loForm . equa l s ( ” Loca l i z a c i o n ” ) )

av i so=new Str ingItem ( ”” , ”\nSe r e a l i z a r a una p e t i c i o n de l a l o c a l i z a c i o n \

de l s i s tema .\n\n¿Desea cont inuar ?” ) ;

else

av i so=new Str ingItem ( ”” , ”\nSe r e a l i z a r a una p e t i c i o n de l a temperatura de l \

s i s tema .\n\n¿Desea cont inuar ?” ) ;


c anc e l a r=new Command( ”Cancelar ” ,Command.CANCEL, 1 ) ;

this . append ( av i so ) ;

this . addCommand( cance l a r ) ;





i f ( c==cance l a r )


i f ( c==aceptar )


i f ( t i tu loForm . equa l s ( ”Reporte ” ) )

new FenvioSms ( s c l , s c l . s i s tema . getCodigos ( 3 ) ) ;

else i f ( t i tu loForm . equa l s ( ” Loca l i z a c i o n ” ) )


else


G.8 Clase Fnotificacion

import javax . m i c roed i t i on . l c du i . ∗ ; import net . dc lausen . m i c r o f l o a t . ∗ ;

public class Fno t i f i c a c i o n extends Form implements CommandListener

private Image [ ] estadosImg ;

private St r ing [ ] e s t ado sS t r=” : o f f ” , ” : on” ;

private St r ing [ ] e t i q u e t a s=” Conf igurac i on : ” , ”Estado de l a ( s ) entrada ( s ) : ” , \

”Estado de l a ( s ) s a l i d a ( s ) : ” , ”Temperatura : ” , ” Pos i c i o n ” ;

private int [ ] posEnt ;

private Str ingItem con f i gu r a c i on ;

private ChoiceGroup entradas ;

private ChoiceGroup s a l i d a s ;

private Str ingItem ana log i ca ;

private Str ingItem po s i c i on ;

private int i n d i c e ;




// Atr i bu tos para l o c a l i z a c i o n en e l mapa

private GClocalizacionMapa loca l i zac ionMapa ;

private Command verMapa ;


public Fno t i f i c a c i o n ( Sc l s c l )

super ( ” No t i f i c a c i o n de l Sistema” ) ;


posEnt=new int [ 4 ] ;

for ( int i =0; i <4; i++)

posEnt [ i ]=−1;

c on f i gu r a c i on=null ;

entradas=null ;

s a l i d a s=null ;

ana l og i ca=null ;

p o s i c i on=null ;


verMapa=new Command( ”Ver Mapa” ,Command.OK, 1 ) ;

s a l i r=new Command( ” S a l i r ” ,Command.EXIT , 1 ) ;

try

estadosImg=new Image [ 2 ] ;

estadosImg [0 ]= Image . createImage ( ”/ r o j o . png” ) ;

estadosImg [1 ]= Image . createImage ( ”/ verde . png” ) ;


System . out . p r i n t l n ( ”Error a l cargar arch ivo de imagen ro j o . png/ verde . png” ) ;



public void prepararFormular io ( S t r ing textoMsg )

//Busca c od igo de confirmaci on de con f i gurac i on

i n d i c e=textoMsg . indexOf ( s c l . s i s tema . getCodigos ( 0 ) ) ;

i f ( i nd i c e != −1 && con f i gu r a c i on == null )

c on f i gu r a c i on=new Str ingItem ( e t i qu e t a s [ 0 ] , ”\nEl s i s tema se ha con f igurado \

ex itosamente . ” ) ;

this . append ( con f i gu r a c i on ) ;

i n d i c e=textoMsg . indexOf ( s c l . s i s tema . getCodigos ( 2 ) ) ; // busca c od igo de repor t e \


de con t r o l de s a l i d a s

i f ( i nd i c e != −1)

i f ( s a l i d a s == null )

s a l i d a s=new ChoiceGroup ( e t i qu e t a s [ 2 ] , ChoiceGroup .EXCLUSIVE) ;

i nd i c e+=3;

//Estado ac tua l

St r ing estadosAct=textoMsg . sub s t r i ng ( ind i c e , i n d i c e+s c l . s i s tema . getNumSalidas ( ) ) ;

//Estado an t e r i o r

St r ing estadosAnt=s c l . s i s tema . getEstados ( ” s a l i d a s ” ) ;

//Escr ibe es tado ac tua l

s c l . s i s tema . se tEstados ( ” s a l i d a s ” , estadosAct ) ;

//Borra l a s entradas de l ChoiceGroup

i f ( s a l i d a s . s i z e ( ) != 0)

s a l i d a s . d e l e t eA l l ( ) ;

//Obtiene l o s id de l o s r e g i s t r o s de l a s e t i q u e t a s de l a s s a l i d a s

int [ ] i dRegEt iqSa l idas=s c l . s i s tema . ge t IdRegEt iqSa l idas ( ) ;

//Compara l a s modi f i cac iones de l o s es tados

for ( int i =0; i<estadosAct . l ength ( ) ; i++)

i f ( estadosAct . charAt ( i ) != estadosAnt . charAt ( i ) )

s a l i d a s . append ( s c l . s i s tema . ge tEt ique ta s ( idRegEt iqSa l idas [ i ])+ \

e s tado sS t r [ I n t eg e r . pa r s e In t ( estadosAct . sub s t r i ng ( i , i +1)) ] , \

estadosImg [ In t eg e r . pa r s e In t ( estadosAct . sub s t r i ng ( i , i +1 ) ) ] ) ;

this . append ( s a l i d a s ) ;

i n d i c e=textoMsg . indexOf ( s c l . s i s tema . getCodigos ( 3 ) ) ; // busca c od igo de repor t e

i f ( i nd i c e != −1)

// Sa l i da s

i f ( s a l i d a s == null )

s a l i d a s=new ChoiceGroup ( e t i qu e t a s [ 2 ] , ChoiceGroup .EXCLUSIVE) ;

i nd i c e+=3;

//Estado ac tua l

St r ing estadosAct=textoMsg . sub s t r i ng ( ind i c e , i n d i c e+s c l . s i s tema . getNumSalidas ( ) ) ;


s c l . s i s tema . se tEstados ( ” s a l i d a s ” , estadosAct ) ;


i f ( s a l i d a s . s i z e ( ) != 0)

s a l i d a s . d e l e t eA l l ( ) ;


int [ ] i dRegEt iqSa l idas=s c l . s i s tema . ge t IdRegEt iqSa l idas ( ) ;




s a l i d a s . append ( s c l . s i s tema . ge tEt ique ta s ( idRegEt iqSa l idas [ i ])+ \



this . append ( s a l i d a s ) ;

//Entradas

i f ( entradas == null )

entradas=new ChoiceGroup ( e t i qu e t a s [ 1 ] , ChoiceGroup .EXCLUSIVE) ;

i nd i c e+=6;

//Estado ac tua l

estadosAct=textoMsg . sub s t r i ng ( ind i c e , i n d i c e+s c l . s i s tema . getNumEntradas ( ) ) ;


s c l . s i s tema . se tEstados ( ” entradas ” , estadosAct ) ;


i f ( entradas . s i z e ( ) != 0)

entradas . d e l e t eA l l ( ) ;


int [ ] idRegEtiqEntradas=s c l . s i s tema . getIdRegEtiqEntradas ( ) ;



entradas . append ( s c l . s i s tema . ge tEt ique ta s ( idRegEtiqEntradas [ i ])+ \



this . append ( entradas ) ;

//Asignaci on de pos i c i one s en e l Choicegroup


posEnt [ i ]= i ;

i n d i c e=textoMsg . indexOf ( s c l . s i s tema . getCodigos ( 4 ) ) ; // busca c od igo de repor t e \

de entrada ana l o g i c a

i f ( i nd i c e != −1)

i n d i c e+=2;

S t r ing temperatura=textoMsg . sub s t r i ng ( i nd i c e ) ;

ana l og i ca=new Str ingItem ( e t i qu e t a s [ 3 ] , ”\nLa temperatura es : ”+temperatura+”C” ) ;

this . append ( ana l og i ca ) ;

i n d i c e=textoMsg . indexOf ( s c l . s i s tema . getCodigos ( 5 ) ) ; // busca c od igo de repor t e de \

l o c a l i z a c i o n

i f ( i nd i c e != −1)

i n d i c e+=3;

S t r ing l a t i t u d=textoMsg . sub s t r i ng ( ind i c e , i n d i c e +10);

S t r ing l ong i tud=textoMsg . sub s t r i ng ( i nd i c e +10, i nd i c e +21);

s c l . s i s tema . setLatGrad ( In t eg e r . pa r s e In t ( l a t i t u d . sub s t r i ng ( 0 , 2 ) ) ) ;

s c l . s i s tema . setLatMin ( MicroFloat . par seF loat ( l a t i t u d . sub s t r i ng ( 2 , 9 ) ) ) ;


s c l . s i s tema . setLonGrad ( In t eg e r . pa r s e In t ( l ong i tud . sub s t r i ng ( 0 , 3 ) ) ) ;

s c l . s i s tema . setLonMin ( MicroFloat . par seF loat ( l ong i tud . sub s t r i ng ( 3 , 1 0 ) ) ) ;

p o s i c i on=new Str ingItem ( e t i qu e t a s [ 4 ] , ”\nLa po s i c i o n es :\ nLatitud : ”+ \

s c l . s i s tema . getLatGrad ()+” ”+MicroFloat . t oS t r i ng ( s c l . s i s tema . getLatMin ())+” ’ ”+ \

l a t i t u d . charAt (9)+”\nLongitud : ”+s c l . s i s tema . getLonGrad()+” ”+ \

MicroFloat . t oS t r i ng ( s c l . s i s tema . getLonMin ())+” ’ ”+long i tud . charAt ( 1 0 ) ) ;

this . append ( po s i c i on ) ;

this . addCommand( verMapa ) ;


//Busca c od igo de no t i f i c a c i o n de cambio en l a s entradas

i n d i c e=textoMsg . indexOf ( s c l . s i s tema . getCodigos ( 6 ) ) ;

i f ( i nd i c e != −1)

i f ( entradas == null )

entradas=new ChoiceGroup ( e t i qu e t a s [ 1 ] , ChoiceGroup .EXCLUSIVE) ;

i nd i c e+=3;

//Estado ac tua l

St r ing estadosAct=textoMsg . sub s t r i ng ( ind i c e , i n d i c e+s c l . s i s tema . getNumEntradas ( ) ) ;

//Estado an t e r i o r

St r ing estadosAnt=s c l . s i s tema . getEstados ( ” entradas ” ) ;


s c l . s i s tema . se tEstados ( ” entradas ” , estadosAct ) ;

//Obtiene l o s id de l o s r e g i s t r o s de l a s e t i q u e t a s de l a s entradas

int [ ] idRegEtiqEntradas=s c l . s i s tema . getIdRegEtiqEntradas ( ) ;



i f ( estadosAct . charAt ( i ) != estadosAnt . charAt ( i ) )

i f ( posEnt [ i ] != −1)

entradas . s e t ( posEnt [ i ] , s c l . s i s tema . ge tEt ique ta s ( idRegEtiqEntradas [ i ] ) \

+es tadosS t r [ I n t eg e r . pa r s e In t ( estadosAct . sub s t r i ng ( i , i +1)) ] , \


else

posEnt [ i ]= entradas . append ( s c l . s i s tema . ge tEt ique ta s ( idRegEtiqEntradas [ i ] ) \

+es tadosS t r [ I n t eg e r . pa r s e In t ( estadosAct . sub s t r i ng ( i , i +1)) ] , \


i f ( entradas . s i z e ( ) !=0)

this . append ( entradas ) ;

else


s c l . setEnEjecuc ion ( fa l se ) ;


i f ( c==aceptar )

i f ( l oca l i zac ionMapa !=null )

l oca l i zac ionMapa=null ;

s c l . th=null ;

s c l . verOpciones ( ) ; // vue l v e a l menu p r i n c i p a l

i f ( c==verMapa )

i f ( l oca l i zac ionMapa==null )

l o ca l i zac ionMapa=new GClocalizacionMapa ( s c l ) ;

l oca l i zac ionMapa . addCommand( s a l i r ) ;

l oca l i zac ionMapa . setCommandListener ( this ) ;

s c l . pan ta l l a . se tCurrent ( loca l i zac ionMapa ) ;

l oca l i zac ionMapa . s t a r t ( ) ;

i f ( c==s a l i r )

s c l . pan ta l l a . se tCurrent ( this ) ;

G.9 Clase GClocalizacionMapa


import javax . m i c roed i t i on . l c du i . game . ∗ ;

import net . dc lausen . m i c r o f l o a t . ∗ ;

public class GClocalizacionMapa extends GameCanvas implements Runnable

private boolean done ;

private boolean va l i do ;

private int posx , posy , mapx , mapy ;

private int frameTime ;

private int l a tBase ;

private int lonBase ;

private int deltaMinLat ;


private int deltaMinLon ;

private int de l taLat ;

private int deltaLon ;

private TiledLayer t i l e s ;

private LayerManager lm ;

private Image mapaNoDisponible ;


public GClocalizacionMapa ( Sc l s c l )

super ( true ) ;


done = true ;

v a l i do=true ;

frameTime = 80 ;

//Datos de l mapa de l campus de l a ESPE

l a tBase=MicroFloat . par seF loat ( ” 18.6217 ” ) ; // l a t i t u d mınima

lonBase=MicroFloat . par seF loat ( ” 26.3781 ” ) ; // l ong i t ud mınima

de l taLat=MicroFloat . par seF loat ( ” 0 .6592 ” ) ; // d i f e r en c i a de l a t i t u d

deltaLon=MicroFloat . par seF loat ( ” 0 .6592 ” ) ; // d i f e r en c i a de l ong i t ud

//Ca lcu lo de l a l a t i t u d

deltaMinLat=MicroFloat . sub ( s c l . s i s tema . getLatMin ( ) , l a tBase ) ;

posy=MicroFloat . div ( MicroFloat . mul ( deltaMinLat , 7 68 ) , de l taLat ) ;

//Ca lcu lo de l a l ong i t ud

deltaMinLon=MicroFloat . sub ( s c l . s i s tema . getLonMin ( ) , lonBase ) ;

posx=MicroFloat . div ( MicroFloat . mul ( deltaMinLon , 7 68 ) , deltaLon ) ;

// Crear mapa y

t i l e s = crearMapa ( ) ;

lm = new LayerManager ( ) ;

lm . append ( t i l e s ) ;

i f ( posx>=0 && posx<=getWidth ( ) )

mapx=−t i l e s . getWidth ()+getWidth ( ) ;

posx=getWidth()−posx ;

else i f ( posx>=t i l e s . getWidth()−getWidth ( ) && posx<=t i l e s . getWidth ( ) )

mapx=0;

posx=t i l e s . getWidth()−posx ;

else i f ( posx>getWidth ( ) && posx<t i l e s . getWidth()−getWidth ( ) )

mapx=posx−t i l e s . getWidth ()+getWidth ( ) / 2 ;

posx=getWidth ( ) / 2 ;


else

va l i do=fa l se ;

i f ( posy>=0 && posy<=getHeight ( ) )

mapy=0;

else i f ( posy>=t i l e s . getHeight ()− getHeight ( ) && posy<=t i l e s . getHeight ( ) )

mapy=−t i l e s . getHeight ()+ getHeight ( ) ;

posy=getHeight ()−( t i l e s . getHeight ()−posy ) ;

else i f ( posy>getHeight ( ) && posy<t i l e s . getHeight ()− getHeight ( ) )

mapy=−posy+getHeight ( ) / 2 ;

posy=getHeight ( ) / 2 ;

else

va l i do=fa l se ;

private TiledLayer crearMapa ( )

Image imagen = null ;

Ti ledLayer t i l e dLaye r = null ;

try

imagen = Image . createImage ( ”/ espe . png” ) ;


System . out . p r i n t l n ( ”Error a l cargar arch ivo de imagen espe . png” ) ;

t i l e dLaye r=new TiledLayer (12 ,12 , imagen , 6 4 , 6 4 ) ;

for ( int i =0; i <144; i++)

int c o l = i %12;

int row = ( i−c o l ) /12 ;

t i l e dLaye r . s e tC e l l ( co l , row , i +1);

return t i l e dLaye r ;


public void s t a r t ( )

i f ( va l i do==true && s c l . s i s tema . getLatGrad ( ) ==0 && s c l . s i s tema . getLonGrad ( ) ==78)

done = fa l se ;

new Thread ( this ) . s t a r t ( ) ;

else

try

mapaNoDisponible=Image . createImage ( ”/mapaNoDisponible . png” ) ;


System . out . p r i n t l n ( ”Error a l cargar arch ivo de imagen mapaNoDisponible . png” ) ;

Aler t avisoMapa=new Aler t ( ”” , ”Mapa no d i s pon i b l e ” , mapaNoDisponible , AlertType . INFO) ;

avisoMapa . setTimeout ( Ale r t .FOREVER) ;

s c l . pan ta l l a . se tCurrent ( avisoMapa ) ;

public void stop ( )

public void run ( )

long s t a r t , end ;

int durat ion ;

Graphics g = getGraphics ( ) ;

// GameLoop

while ( ! done )

s t a r t = System . cur r entT imeMi l l i s ( ) ;

input ( ) ; // l e e que t e c l a pres ion o e l usuar io

render ( g ) ; // a c t u a l i z a l a imagen que aparece en pan t a l l a

// s inc ron i zac i o n

end = System . cur r entT imeMi l l i s ( ) ;

durat ion = ( int ) ( end − s t a r t ) ;

i f ( durat ion < frameTime )

try

Thread . s l e e p ( frameTime − durat ion ) ;

catch ( Inter ruptedExcept ion i e ) done=true ;


public void input ( )

// Desplazamiento por e l mapa

int keyStates = getKeyStates ( ) ;

i f ( ( keyStates & LEFT PRESSED)!=0 && mapx<0)

posx+=6;

mapx+=6;

i f ( ( keyStates & RIGHT PRESSED)!=0 && mapx>getWidth()− t i l e s . getWidth ( ) )

posx−=6;

mapx−=6;

i f ( ( keyStates & UP PRESSED)!=0 && mapy<0)

posy+=6;

mapy+=6;

i f ( ( keyStates & DOWN PRESSED)!=0 && mapy>getHeight ()− t i l e s . getHeight ( ) )

posy−=6;

mapy−=6;

public void render ( Graphics g )

// Borra l a pan t a l l a

g . s e tCo lo r (0 x f f f f f f ) ;

g . f i l l R e c t (0 , 0 , getWidth ( ) , getHeight ( ) ) ;

// Dibuja e l mapa

t i l e s . s e tPo s i t i o n (mapx ,mapy ) ;

lm . pa int ( g , 0 , 0 ) ;

//Dibuja l a pos i c i on en e l mapa

g . s e tCo lo r (0 x f f 0000 ) ;

g . drawRect ( posx−8,posy −8 ,16 ,16) ;

g . f i l l A r c ( posx−3,posy −3 ,6 ,6 ,0 ,360) ;

f l u shGraph i c s ( ) ;

G.10 Clase FenvioSms


import javax . m i c roed i t i on . i o . ∗ ;

import javax . w i r e l e s s . messaging . ∗ ;


public class FenvioSms extends Form implements Runnable

private Gauge progreso ;

private St r ing texto ;

private Thread envio ;

private Aler t av i so ;


private Image enviarSms ;

private Image numSistema ;

public FenvioSms ( Sc l s c l , S t r ing texto )

super ( ”” ) ;


this . t exto=texto ;

progre so=new Gauge ( ”” , false , 1 0 0 , 0 ) ;

progre so . s e tLabe l ( ”Enviando sms . . . ” ) ;

try

enviarSms=Image . createImage ( ”/ enviarSms . png” ) ;

numSistema=Image . createImage ( ”/numSistema . png” ) ;


System . out . p r i n t l n ( ”Error a l cargar arch ivo de imagen enviarSms . png/numSistema . png” ) ;

envio=new Thread ( this ) ;

envio . s t a r t ( ) ;

this . append ( progreso ) ;

public void run ( )

i f ( s c l . s i s tema . getNumSistema ( ) . equa l s ( ”” )!= true )

St r ing de s t ino=”sms :// ”+s c l . s i s tema . getNumSistema()+” : ”+s c l . s i s tema . getPuertoTx ( ) ;

MessageConnection msgCon = null ;

try

msgCon=(MessageConnection ) Connector . open ( de s t ino ) ;

TextMessage sms = ( TextMessage )msgCon . newMessage ( MessageConnection .TEXT MESSAGE) ;

sms . setAddress ( de s t ino ) ;

sms . setPayloadText ( s c l . s i s tema . ge tClaveSc l ()+ texto ) ;

msgCon . send ( sms ) ;



for ( int i =0; i <100; i++)

Thread . s l e e p ( 5 ) ;

progre so . setValue ( i ) ;

av i so=new Aler t ( ”” , ”Mensaje enviado ” , enviarSms , AlertType . INFO) ;

av i so . setTimeout ( 2000 ) ;

s c l . pan ta l l a . se tCurrent ( av i so ) ;

Thread . s l e e p ( 2000 ) ;

i f ( t exto . equa l s ( ”CF” ) )


else



System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l env ia r mensaje ” ) ;

i f (msgCon != null )

try

msgCon . c l o s e ( ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error a l c e r r a r l a \

conexi on para env ıo de l mensaje ” ) ;

else

av i so=new Aler t ( ”” , ”Conf igure e l numero de l Sistema . ” , numSistema , AlertType . INFO) ;

av i so . setTimeout ( 4000 ) ;

s c l . pan ta l l a . se tCurrent ( av i so ) ;

try

Thread . s l e e p ( 3000 ) ;


System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error s l e e p run” ) ;



G.11 Clase Fesperar


public class Fesperar extends Form implements CommandListener

private Str ingItem texto ;

private Command ver ;


public Fesperar ( Sc l s c l )

super ( ”” ) ;


t exto=new Str ingItem ( ”” , ”Espere un momento . . . ” ) ;

ver=new Command( ”Ver Menu” ,Command.BACK, 1 ) ;

this . append ( texto ) ;

this . addCommand( ver ) ;




i f ( c==ver )


MANUAL DE USUARIO DEL SISTEMA DE CONTROL Y LOCALIZACION 207

Apendice H

MANUAL DE USUARIO DEL SISTEMA DE CONTROL Y

LOCALIZACION

El sistema de control y localizacion consta de dos partes, el dispositivo de control y la

aplicacion Scl.jar a instalarse en un telefono celular.

Figura H.1: Sistema de Control y Localizacion.


H.1 PARTES DEL DISPOSITIVO DE CONTROL

H.1.1 Cara frontal

1. Salidas Digitales.

2. Leds indicadores de estado para las salidas digitales.

3. Tierra para salidas digitales

4. Salidas de Potencia.

5. Leds indicadores de estado para las salidas de potencia.

6. Led indicador de envıo y recepcion de mensajes.

H.1.2 Cara posterior

7. Switch de encendido y apagado.

8. Entrada de 12 voltios DC.

9. Antena del modulo receptor GPS.

10. Entrada analogica para el sensor de temperatura.

11. Tierra para el sensor de temperatura.

12. Salida de 5 voltios DC para el sensor de temperatura.

13. Entradas digitales.

14. Tierra para las entradas digitales.

H.2 CONSIDERACIONES DE FUNCIONAMIENTO

• Alimentacion mınima requerida de 12 voltios DC, maxima de 28 voltios DC.

• Previo a la utilizacion del dispositivo, debera insertar la tarjeta SIM al telefono

celular incorporado dentro de la caja de control y localizacion.


1

2

3

4

5

6

Figura H.2: Partes de la cara frontal.

7

8

9

10

11

12

13

14

Figura H.3: Partes de la cara posterior.


• El telefono del dispositivo debe contar con un plan de mensajes cortos.

• En la instalacion del dispositivo, procurar que este se encuentre en un lugar donde

cuente con lınea de vista al cielo, especialmente la antena del modulo receptor GPS,

caso contrario, no se garantiza el correcto funcionamiento en la determinacion de la

posicion.

• Para la entrada analogica se recomienda la utilizacion del sensor de temperatura

LM35DZ, de no ser el caso, se puede utilizar cualquier otro sensor de temperatura

que tenga una sensibilidad de 10mV/C.

• El led indicador de envıo y recepcion de mensajes, permanece encendido mientras

el sistema tenga alimentacion, se apaga unicamente cuando llegan mensajes del

sistema y se enciende una vez que haya procesado estos mensajes y se haya enviado

una confirmacion o reporte.

H.3 CONEXION DE SALIDAS

H.3.1 Salidas digitales

• Conectar unicamente dispositivos que trabajen con logica TTL, es decir, 0 y 5

voltios.

• Todo dispositivo que se conecte a las salidas digitales, debe conectarse igualmente

a tierra. (Ver Figura H.2, numero 3).

• Conectar cargas no superiores a 25 mA.

• Mientras la salida se encuentre activada permanecera prendido su respectivo led

indicador.

H.3.2 Salidas de potencia

• Conectar dispositivos que trabajen con 110 VAC, 60 Hz.

• Mientras la salida se encuentre activada permanecera prendido su respectivo led

indicador.


Salida 4 (potencia)

Toma de 110 VAC

Dispositivo AC ∼

Figura H.4: Ejemplo de conexion de una salida de potencia.

• La figura H.4 muestra un ejemplo de conexion para una salida de potencia.

H.4 CONEXION DE ENTRADAS

H.4.1 Entradas digitales

Conectar unicamente dispositivos cuya salida tenga logica TTL (0 y 5 voltios).

Cada salida debe ser conectada a tierra. (Ver Figura H.3, numero 14).

H.4.2 Entrada analogica

• Es una entrada disenada estrictamente para el sensamiento de temperatura.

• La Figura H.5 muestra un ejemplo de conexion del sensor de temperatura.

H.5 APLICACION DE LA INTERFAZ DE USUARIO

La aplicacion que viene con el sistema lleva por nombre ”Scl” siglas de Sistema de Control

y Localizacion, y constituye una aplicacion para ser instalada en cualquier telefono celular

que soporte Java CLDC 1.0 y MIDP 2.0.

H.5.1 Instalacion

El proceso de instalacion se basa en enviar el archivo Scl.jar hacia el telefono celular,

por medio de una conexion bluetooth, infrarrojo o serial. Una vez enviado el archivo


LM35DZ

5 VDC

Tierra

Entrada sensor

Figura H.5: Ejemplo de conexion de la entrada analogica.

Scl.jar, el mismo dispositivo movil pedira instalar la aplicacion, a lo cual se respondera

afirmativamente.

Una vez instalado, el telefono puede preguntar si desea iniciar la aplicacion, al respon-

der afirmativamente, se preguntara si se desea permitir a la aplicacion recibir mensajes,

a lo cual se contestara Sı y se dara paso al inicio de la misma.

H.5.2 Autenticacion

Al iniciar la aplicacion, se pedira la clave de autenticacion para acceder al menu princi-

pal (Figura H.6). Ingresar el valor ”123” en el primer acceso. Existen unicamente tres

posibilidades de errar en la clave de autenticacion, despues de estos intentos se presentara

el mensaje ”Acceso Denegado” y la aplicacion se cerrara. Se puede volver a ejecutar la

aplicacion para ingresar nuevamente la clave.

Recomendacion: Cambie la clave para acceso a la aplicacion, ver subseccion de Con-

figuracion de clave de autenticacion.

H.5.3 Configuracion

1. Configuracion del Numero del Sistema. Ir a Configuracion>Numero del sis-

tema en el menu principal. Introduzca el numero de telefono de la tarjeta SIM


Figura H.6: Menu Principal de la aplicacion Scl.

insertada en el dispositivo de control. A continuacion ingrese la clave de emergencia

(debe tener cuatro dıgitos) y confirme.

La clave de emergencia le permitira controlar el sistema, de manera limitada, desde

cualquier telefono celular, incluso si no se encuentra instalada la aplicacion Scl. En

este caso se debe escribir un mensaje de texto con el siguiente codigo:

SOS< clavedeemergencia >ON −→ Para encender la salida 1 del sistema.

SOS< clavedeemergencia >OFF −→ Para apagar todas las salidas del sistema.

Ejemplo:

SOS1234ON

SOS1234OFF

Una vez terminada la configuracion del numero del sistema y la clave de emergencia,

presione el boton Aceptar y elija Sı cuando se le pregunte si desea enviar un mensaje


SMS. Aparecera un aviso notificandole que el mensaje ha sido enviado. Despues

de unos segundos, el dispositivo de control enviara un mensaje de confirmacion,

aparecera una notificacion con el texto: ”El sistema se ha configurado exitosamente”.

2. Configuracion de entradas y salidas. Permite asignar etiquetas a las entradas

y salidas del sistema. Ir a Configuracion>Entradas/Salidas, dirıjase hacia el campo

de la entrada o salida que desea editar, borre el contenido e ingrese un nombre

adecuado para asociarlo al dispositivo conectado a la respectiva entrada o salida.

3. Configuracion de la clave de autenticacion. Ir a Configuracion>Clave, ingrese

una clave de maximo 10 dıgitos y confirme. Esta es la clave que debera utilizarse

posteriormente para acceder a la aplicacion.

H.5.4 Control del Sistema

Para el control de las salidas del sistema, ir a Control en el menu principal y elija la salida

que desea activar/desactivar, se desplegara un menu con dos opciones: on (verde) y off

(gris), ubıquese sobre la opcion deseada y pulse Seleccionar.

Una vez terminada la seleccion de estados de cada salida, a continuacion presione el

boton Aceptar. Se pedira autorizacion para enviar un mensaje de texto desde la aplicacion,

responda Sı y espere un momento hasta recibir una confirmacion del sistema.

H.5.5 Reporte

Para solicitar un reporte del estado de las entradas y salidas del sistema dirıjase al menu

principal, seleccione Reporte y despues Aceptar. El sistema enviara en unos segundos,

una respuesta con el reporte de los estados de cada entrada y salida.


H.5.6 Localizacion

Para solicitar la posicion del dispositivo de control, dirıjase al menu principal, seleccione

Localizacion y despues Aceptar. El sistema enviara en unos segundos, una respuesta con

la posicion geografica, en grados y minutos con una precision de 4 decimales.

Adicionalmente, puede presionar sobre el boton Ver Mapa. Si la posicion se encuen-

tra dentro del perımetro del campus de la ESPE, aparecera un recuadro de color rojo

indicando la posicion en un mapa y podra desplazarse sobre el, utilizando las teclas de

navegacion. En caso de no encontrarse dentro del perımetro del campus aparecera el

mensaje ”Mapa no disponible”.

H.5.7 Temperatura

Para conocer la temperatura del ambiente sensado, dirıjase al menu principal, seleccione

Temperatura y despues Aceptar. El sistema enviara en unos segundos, una respuesta con

la temperatura correspondiente en C.

Bibliografıa 216

Bibliografıa

[1] World Cellular Information Service, Subscriptions by Technology,

www.wcisdata.com/newt/l/wcis/research/subscriptions by technology.html, Agosto

2008, Fecha de consulta: 22-08-2008.

[2] International Engineering Consortium, Global System for Mobile Communication

(GSM), www.iec.org/online/tutorials/gsm/index.asp, 2007, Fecha de consulta: 22-

08-2008.

[3] Leister, Wolfgang, GSM speech coding, www.uio.no/studier/emner/matnat/ifi/

INF5080/v04/mkt05b-gsm.pdf, 2004, Fecha de consulta: 26-08-2008.

[4] Le Bodic, Gwenael, Mobile Messaging Technologies and Services-SMS, EMS and

MMS, Segunda Edicion, John Wiley & Sons, Ltd, Inglaterra 2005.

[5] DreamFabric, SMS and the PDU format, www.dreamfabric.com/sms/, Enero 2005,

Fecha de consulta: 13-04-2008.

[6] Sony Ericsson, Developers Guide AT Commands Online Reference, de-

veloper.sonyericsson.com/util/SearchCMS.do?criteria=commands, Octubre 2004,


Bibliografıa 217

[7] Dıaz, Jose, SMS su estructura y otras perspectivas de aplicaciones, guach-

erna.uac.edu.co/congreso sistemas 2005/sitio/content/memorias/sms.pdf, 2005,


[8] Eveliux, Comandos AT, eveliux.com/mx/index2.php?option=com content&do

pdf=1&id=150, 11-07-2007, Fecha de consulta: 02-09-2008.

[9] National Space-Based Positioning, Navigation, and Timing Coordination Office,

Global Positioning System-Serving the World, www.gps.gov, Fecha de consulta: 26-

06-2008.

[10] Del Pozo, Jesus, Sistema NAVSTAR-GPS, www.tel.uva.es/personales/jpozdom/

telecomunicaciones/tutorial/contenido.html, Fecha de consulta: 26-06-2008.

[11] SPK Electronics Co., Ltd., Smart Antenna SPK-GPS-GS405, v 1.0, Taipei, Taiwan,

Septiembre 2006.

[12] Baddeley, Glenn, GPS-NMEA sentence information,

home.mira.net/∼gnb/gps/nmea.html, Junio 2007, Fecha de consulta: 28-06-2008.

[13] Microchip Technology Inc., PIC16F877A, www.microchip.com/wwwproducts/Devices

.aspx?dDocName=en010242, Octubre 2003.

[14] Canovas, Andres, Manual de usuario del compilador PCW de CCS,

www.cursos.ucv.cl/eie48700/referencias/CCS C Manual.pdf. Fecha de consulta:

20-02-2008.

Bibliografıa 218

[15] Forum Nokia, JavaTM ME Developer’s Library 1.1,

www.forum.nokia.com/ME Developers Library/, 2008, Fecha de consulta: 03-

05-2008.

[16] Sun Microsystems, Java ME Technology APIs Docs,

java.sun.com/javame/reference/apis.jsp#api, 2008, Fecha de consulta: 10-05-

2008.

[17] Sergio Galvez, Lucas Ortega, J2ME Java 2 Micro Edition,

www.lcc.uma.es/∼galvez/J2ME.html, 2003, Fecha de consulta: 02-04-2008.

[18] Carlos Garcıa, J2ME Push Registry. Activacion automatica de MIDlets,

www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=pushRegistry, 21-

05-2007, Fecha de Consulta: 10-06-2008.

[19] Carlos Garcıa, J2ME, Java Wireless Message API (WMA),

www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=wma, 08-05-2008,


FECHA DE ENTREGA:

Sr. Edgar Benıtez Srta. Diana Moya

AUTORES

Ing. Gonzalo Olmedo

DIRECTOR DE CARRERA DE INGENIERIA

EN ELECTRONICA Y TELECOMUNICACIONES

ESCUELA POLITECNICA DEL EJ´ ERCITO´ - Repositorio de...

Documents

Transcript of ESCUELA POLITECNICA DEL EJ´ ERCITO´ - Repositorio de...