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
geo- grafica. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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
INTRODUCCION A GSM 2
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.
INTRODUCCION A GSM 3
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.
INTRODUCCION A GSM 4
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
INTRODUCCION A GSM 5
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).
INTRODUCCION A GSM 6
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
2.1 DESCRIPCION DEL CAPITULO
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.
SERVICIO DE MENSAJES CORTOS 8
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
SERVICIO DE MENSAJES CORTOS 9
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).
SERVICIO DE MENSAJES CORTOS 10
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.
SERVICIO DE MENSAJES CORTOS 11
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.
SERVICIO DE MENSAJES CORTOS 12
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
SERVICIO DE MENSAJES CORTOS 13
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).
SERVICIO DE MENSAJES CORTOS 14
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.
SERVICIO DE MENSAJES CORTOS 15
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.
SERVICIO DE MENSAJES CORTOS 16
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.
SERVICIO DE MENSAJES CORTOS 17
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.
SERVICIO DE MENSAJES CORTOS 18
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
SERVICIO DE MENSAJES CORTOS 19
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.
SERVICIO DE MENSAJES CORTOS 20
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.
SERVICIO DE MENSAJES CORTOS 21
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
3.1 DESCRIPCION DEL CAPITULO
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.
MODEM GSM Y COMANDOS AT 23
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.
MODEM GSM Y COMANDOS AT 24
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.
MODEM GSM Y COMANDOS AT 25
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+.
MODEM GSM Y COMANDOS AT 26
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.
MODEM GSM Y COMANDOS AT 27
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:
MODEM GSM Y COMANDOS AT 28
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:
MODEM GSM Y COMANDOS AT 29
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:
MODEM GSM Y COMANDOS AT 30
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>
MODEM GSM Y COMANDOS AT 31
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
MODEM GSM Y COMANDOS AT 32
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
4.1 DESCRIPCION DEL CAPITULO
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
SISTEMA DE POSICIONAMIENTO GLOBAL 34
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
SISTEMA DE POSICIONAMIENTO GLOBAL 35
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.
SISTEMA DE POSICIONAMIENTO GLOBAL 36
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.
SISTEMA DE POSICIONAMIENTO GLOBAL 37
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
SISTEMA DE POSICIONAMIENTO GLOBAL 38
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.
SISTEMA DE POSICIONAMIENTO GLOBAL 39
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.
SISTEMA DE POSICIONAMIENTO GLOBAL 40
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
SISTEMA DE POSICIONAMIENTO GLOBAL 41
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].
SISTEMA DE POSICIONAMIENTO GLOBAL 42
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
5.1 DESCRIPCION DEL CAPITULO
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.
MICROCONTROLADORES PIC 44
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.
MICROCONTROLADORES PIC 45
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].
MICROCONTROLADORES PIC 46
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)
MICROCONTROLADORES PIC 47
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,
MICROCONTROLADORES PIC 48
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
MICROCONTROLADORES PIC 49
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
6.1 DESCRIPCION DEL CAPITULO
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 MICRO EDITION 51
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.
JAVA 2 MICRO EDITION 52
• 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
JAVA 2 MICRO EDITION 53
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.
JAVA 2 MICRO EDITION 54
– 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
JAVA 2 MICRO EDITION 55
– 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:
JAVA 2 MICRO EDITION 56
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.
JAVA 2 MICRO EDITION 57
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.
JAVA 2 MICRO EDITION 58
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.
JAVA 2 MICRO EDITION 59
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”.
JAVA 2 MICRO EDITION 60
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
JAVA 2 MICRO EDITION 61
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 ( )
JAVA 2 MICRO EDITION 62
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.
JAVA 2 MICRO EDITION 63
• 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.
JAVA 2 MICRO EDITION 64
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.
JAVA 2 MICRO EDITION 65
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.
JAVA 2 MICRO EDITION 66
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.
JAVA 2 MICRO EDITION 67
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
JAVA 2 MICRO EDITION 68
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)
JAVA 2 MICRO EDITION 69
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)
JAVA 2 MICRO EDITION 70
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
JAVA 2 MICRO EDITION 71
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.
JAVA 2 MICRO EDITION 72
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].
JAVA 2 MICRO EDITION 73
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
JAVA 2 MICRO EDITION 74
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:
JAVA 2 MICRO EDITION 75
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.
JAVA 2 MICRO EDITION 76
– 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.
JAVA 2 MICRO EDITION 77
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
7.1 DESCRIPCION DEL CAPITULO
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.
DISENO DEL PROTOTIPO 79
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.
DISENO DEL PROTOTIPO 80
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
DISENO DEL PROTOTIPO 81
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:
DISENO DEL PROTOTIPO 82
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
DISENO DEL PROTOTIPO 83
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-
DISENO DEL PROTOTIPO 84
(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.
DISENO DEL PROTOTIPO 85
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
DISENO DEL PROTOTIPO 86
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.
DISENO DEL PROTOTIPO 87
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.
DISENO DEL PROTOTIPO 88
(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
DISENO DEL PROTOTIPO 89
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.
DISENO DEL PROTOTIPO 90
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.
DISENO DEL PROTOTIPO 92
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.
DISENO DEL PROTOTIPO 93
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-
DISENO DEL PROTOTIPO 94
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
DISENO DEL PROTOTIPO 95
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).
DISENO DEL PROTOTIPO 96
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).
DISENO DEL PROTOTIPO 97
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).
DISENO DEL PROTOTIPO 98
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 ;
DISENO DEL PROTOTIPO 99
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
DISENO DEL PROTOTIPO 100
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
DISENO DEL PROTOTIPO 101
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.
DISENO DEL PROTOTIPO 102
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
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
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++)
DISENO DEL PROTOTIPO 103
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
DISENO DEL PROTOTIPO 104
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 ’ ;
DISENO DEL PROTOTIPO 105
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
acum+=ponderacion [ j ] ;
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 ’ )
acum+=ponderacion [4+ j ] ;
wr ite eeprom (15+ cont cod++,hexadecimal [ acum ] ) ; // grabar en l a eeprom
DISENO DEL PROTOTIPO 106
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 ) ;
DISENO DEL PROTOTIPO 107
//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
i n i t b u f f e r ( ) ;
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 ∗/
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 (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 ) ;
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
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
DISENO DEL PROTOTIPO 108
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
DISENO DEL PROTOTIPO 109
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.
DISENO DEL PROTOTIPO 110
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.
DISENO DEL PROTOTIPO 111
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
DISENO DEL PROTOTIPO 112
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
DISENO DEL PROTOTIPO 113
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.
DISENO DEL PROTOTIPO 114
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
DISENO DEL PROTOTIPO 115
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:
DISENO DEL PROTOTIPO 116
(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:
DISENO DEL PROTOTIPO 117
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
DISENO DEL PROTOTIPO 118
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
DISENO DEL PROTOTIPO 119
(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
DISENO DEL PROTOTIPO 120
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.
DISENO DEL PROTOTIPO 121
Figura 7.26: Archivo .map con las equivalencias entre puntos del mapa y su posicion geo-grafica.
DISENO DEL PROTOTIPO 122
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
8.1 DESCRIPCION DEL CAPITULO
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.
PRUEBAS Y RESULTADOS 124
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.
PRUEBAS Y RESULTADOS 125
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.
PRUEBAS Y RESULTADOS 126
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.
PRUEBAS Y RESULTADOS 127
(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.
PRUEBAS Y RESULTADOS 128
(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.
PRUEBAS Y RESULTADOS 129
(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.
PRUEBAS Y RESULTADOS 130
(a) Formulario de control (b) Cambio de estado
(c) Peticion a ser enviada
Figura 8.9: Formulario de control de salidas de la TCL.
PRUEBAS Y RESULTADOS 131
(a) Control de salidas
(b) Notificacion del sistema (c) Reporte de control
Figura 8.10: Control de salidas y reporte de la TCL.
PRUEBAS Y RESULTADOS 132
(a) Peticion de reporte (b) Notificacion del sistema
(c) Formulario de reporte
Figura 8.11: Reporte del sistema.
PRUEBAS Y RESULTADOS 133
(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.
PRUEBAS Y RESULTADOS 134
(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
CONCLUSIONES Y RECOMENDACIONES 136
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.
CONCLUSIONES Y RECOMENDACIONES 137
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
GSM 7-bit Default Alphabet y codificacion de datos de 7 bits en octetos 139
Hex Dec Nombre del caracter Caracter ISO-8859-1
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
GSM 7-bit Default Alphabet y codificacion de datos de 7 bits en octetos 140
Hex Dec Nombre del caracter Caracter ISO-8859-1
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
GSM 7-bit Default Alphabet y codificacion de datos de 7 bits en octetos 141
Hex Dec Nombre del caracter Caracter ISO-8859-1
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
GSM 7-bit Default Alphabet y codificacion de datos de 7 bits en octetos 142
Hex Dec Nombre del caracter Caracter ISO-8859-1
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
GSM 7-bit Default Alphabet y codificacion de datos de 7 bits en octetos 143
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 modulo receptor SPK-GPS-GS405 145
Hoja de especificaciones del modulo receptor SPK-GPS-GS405 146
Hoja de especificaciones del modulo receptor SPK-GPS-GS405 147
Hoja de especificaciones del microcontrolador PIC16F877A 148
Apendice C
Hoja de especificaciones del microcontrolador PIC16F877A
Hoja de especificaciones del microcontrolador PIC16F877A 149
Hoja de especificaciones del microcontrolador PIC16F877A 150
Hoja de especificaciones del microcontrolador PIC16F877A 151
Hoja de especificaciones del regulador LM317 152
Apendice D
Hoja de especificaciones del regulador LM317
Hoja de especificaciones del regulador LM317 153
Hoja de especificaciones del regulador LM1117 154
Apendice E
Hoja de especificaciones del regulador LM1117
Hoja de especificaciones del regulador LM1117 155
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”
Codigo del programa del microcontrolador PIC16F877A 157
#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 ) )
Codigo del programa del microcontrolador PIC16F877A 158
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++)
Codigo del programa del microcontrolador PIC16F877A 159
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
acum+=ponderacion [ j ] ;
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
Codigo del programa del microcontrolador PIC16F877A 160
//NIBBLE MENOS SIGNIFICATIVO
acum=0;
for ( j =0; j <4; j++)
i f ( b i na r i o [ j+4]== ’ 1 ’ )
acum+=ponderacion [4+ j ] ;
wr ite eeprom (15+ cont cod++,hexadecimal [ acum ] ) ; // grabar en l a eeprom
//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 ) ;
Codigo del programa del microcontrolador PIC16F877A 161
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
i n i t b u f f e r ( ) ;
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 ∗/
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 (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 ) ;
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
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
Codigo del programa del microcontrolador PIC16F877A 162
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 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 ;
Codigo del programa del microcontrolador PIC16F877A 163
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
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
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 ∗/
Codigo del programa del microcontrolador PIC16F877A 164
//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 ( ) ;
i n i t b u f f e r ( ) ;
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
i n i t b u f f e r ( ) ;
s p r i n t f ( bu f f e r , ”%s %02.2 f ” ,ENT ANALOG, temp ) ;
c o d i f i c a c i o n ( ) ;
envio sms (26 , ’ 0 ’ , ’F ’ ) ;
Codigo del programa del microcontrolador PIC16F877A 165
//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
i n i t b u f f e r ( ) ;
s p r i n t f ( bu f f e r , ”%sS%sE%s” ,REPORTAR, s a l i d a s , entradas ) ;
c o d i f i c a c i o n ( ) ;
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
i n i t b u f f e r ( ) ;
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)
con t com i l l a++;
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’ )
bu f f e r [ c on t bu f f e r ]=0x00 ;
break ;
i f ( s t r c h r ( bu f f e r , ’A ’ )!=0x00 )
Codigo del programa del microcontrolador PIC16F877A 166
break ;
//REPORTE DE LOCALIZACION
c o d i f i c a c i o n ( ) ;
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 ( )
Codigo de la aplicacion de administracion del SCL en J2ME 168
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 ( ) , ”∗” ) ;
catch ( Exception e )
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
Codigo de la aplicacion de administracion del SCL en J2ME 169
msgCon=(MessageConnection ) Connector . open ( d i r e c c i o n ) ;
msgCon . s e tMessageL i s t ene r ( this ) ;
catch ( Exception e )
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 ( ) ;
catch ( Exception e )
Codigo de la aplicacion de administracion del SCL en J2ME 170
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 ” ) ;
pan ta l l a . se tCurrent ( p e t i 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 ” ) ;
pan ta l l a . se tCurrent ( p e t i c i o n ) ;
break ;
Codigo de la aplicacion de administracion del SCL en J2ME 171
// 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 = new Thread ( this ) ;
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 )
Codigo de la aplicacion de administracion del SCL en J2ME 172
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 = new Thread ( this ) ;
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 ) ;
Codigo de la aplicacion de administracion del SCL en J2ME 173
catch ( Exception e )
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 ;
Codigo de la aplicacion de administracion del SCL en J2ME 174
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 ) ;
catch ( Exception e )
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
Codigo de la aplicacion de administracion del SCL en J2ME 175
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 ) ;
catch ( Exception e )
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 ( ) ;
catch ( Exception 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 RecordStore ” ) ;
public int getNumRegistros ( )
int numRegistros=0;
try
numRegistros=r s . getNumRecords ( ) ;
catch ( Exception e )
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
Codigo de la aplicacion de administracion del SCL en J2ME 176
public void se tClave ( S t r ing c l ave )
abr i rRecordStore ( ) ;
regClave=c lave . getBytes ( ) ;
try
r s . setRecord ( idRegClave , regClave , 0 , regClave . l ength ) ;
catch ( Exception e )
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 ” ) ;
ce r ra rRecordStore ( ) ;
public void setNumSistema ( St r ing numSistema )
abr i rRecordStore ( ) ;
regNumSistema=numSistema . getBytes ( ) ;
try
r s . setRecord ( idRegNumSistema , regNumSistema , 0 , regNumSistema . l ength ) ;
catch ( Exception e )
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 ” ) ;
ce r ra rRecordStore ( ) ;
public void s e tEt i que ta s ( S t r ing e t iqueta , int idRegEtiq )
abr i rRecordStore ( ) ;
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 ) ;
catch ( Exception e )
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 ” ) ;
ce r ra rRecordStore ( ) ;
public void se tEstados ( S t r ing entSal , S t r ing es tados )
Codigo de la aplicacion de administracion del SCL en J2ME 177
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 ;
abr i rRecordStore ( ) ;
regEstados=estados . getBytes ( ) ;
try
r s . setRecord ( idReg , regEstados , 0 , regEstados . l ength ) ;
catch ( Exception e )
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 ” ) ;
ce r ra rRecordStore ( ) ;
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 ( )
Codigo de la aplicacion de administracion del SCL en J2ME 178
return i dRegEt iqSa l idas ;
public St r ing getClave ( )
St r ing c l ave=null ;
abr i rRecordStore ( ) ;
regClave = new byte [ 1 0 ] ;
try
regClave=r s . getRecord ( idRegClave ) ;
c l ave=new St r ing ( regClave ) ;
catch ( Exception e )
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 ” ) ;
ce r ra rRecordStore ( ) ;
return c l ave ;
public St r ing getNumSistema ( )
St r ing numSistema=null ;
abr i rRecordStore ( ) ;
regNumSistema = new byte [ 9 ] ;
try
regNumSistema=rs . getRecord ( idRegNumSistema ) ;
numSistema=new St r ing ( regNumSistema ) ;
catch ( Exception e )
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 ” ) ;
ce r ra rRecordStore ( ) ;
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 ;
Codigo de la aplicacion de administracion del SCL en J2ME 179
abr i rRecordStore ( ) ;
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 ) ;
catch ( Exception e )
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 ” ) ;
ce r ra rRecordStore ( ) ;
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 ;
abr i rRecordStore ( ) ;
regEstados = new byte [ numBytes ] ;
try
regEstados=r s . getRecord ( idReg ) ;
e s tados=new St r ing ( regEstados ) ;
catch ( Exception e )
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 ” ) ;
ce r ra rRecordStore ( ) ;
return e s tados ;
Codigo de la aplicacion de administracion del SCL en J2ME 180
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 ;
Codigo de la aplicacion de administracion del SCL en J2ME 181
G.3 Clase Fclave
import javax . m i c roed i t i on . l c du i . ∗ ;
public class Fclave extends Form implements CommandListener
private TextFie ld ingClave ;
private Ticker t i c k ;
private St r ing c l ave ;
private St r ing compClave ;
private Command s a l i r ;
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;
public void commandAction (Command c , Di sp layab l e d)
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 ) )
Codigo de la aplicacion de administracion del SCL en J2ME 182
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 ;
private Command aceptar ;
private Sc l s c l ;
public Cdenegado ( Sc l s c l )
this . s c l=s c l ;
aceptar=new Command( ”Aceptar” ,Command.EXIT , 1 ) ;
this . addCommand( aceptar ) ;
this . setCommandListener ( this ) ;
try
imagen=Image . createImage ( ”/AccesoDenegado . png” ) ;
catch ( Exception e )
System . out . p r i n t l n ( ”Error a l cargar arch ivo de imagen AccesoDenegado . png” ) ;
Codigo de la aplicacion de administracion del SCL en J2ME 183
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 ) ;
public void commandAction (Command c , Di sp layab l e d)
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 . l c du i . ∗ ;
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 Sc l s c l ;
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 . s c l=s c l ;
this . a r ch ivo=”/ i n t r o . g i f ” ;
Codigo de la aplicacion de administracion del SCL en J2ME 184
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 ;
s c l . verOpciones ( ) ;
private void r e s e t p l a y e r ( ) throws MediaException
Codigo de la aplicacion de administracion del SCL en J2ME 185
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 ;
r e s e t p l a y e r ( ) ;
// 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 ;
s c l . verOpciones ( ) ;
private void detenerP layer ( )
try
r e s e t p l a y e r ( ) ;
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 ” ) ;
Codigo de la aplicacion de administracion del SCL en J2ME 186
p laye r = null ;
G.5 Clase Lconfiguracion
import javax . m i c roed i t i on . l c du i . ∗ ;
public class Lcon f i gu rac i on extends L i s t implements CommandListener
private Sc l s c l ;
private Ticker t i c k ;
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 ) ;
this . s c l=s c l ;
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 . s e tT i cke r ( t i c k ) ;
this . addCommand( a t r a s ) ;
this . setCommandListener ( this ) ;
public void commandAction (Command c , Di sp layab l e d)
i f ( c == at ra s )
s c l . verOpciones ( ) ;
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 :
Codigo de la aplicacion de administracion del SCL en J2ME 187
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 ;
private Sc l s c l ;
public FnumSistema ( Sc l s c l )
super ( ”Numero de l Sistema” ) ;
this . s c l=s c l ;
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) ;
Codigo de la aplicacion de administracion del SCL en J2ME 188
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 ) ;
this . addCommand( a t r a s ) ;
this . addCommand( aceptar ) ;
this . setCommandListener ( this ) ;
public void commandAction (Command c , Di sp layab l e d)
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 ( ”” ) ;
Codigo de la aplicacion de administracion del SCL en J2ME 189
class FentSal extends Form implements CommandListener
private Ticker i nd i c a c i on ;
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 Command atras , aceptar ;
private Sc l s c l ;
private Lcon f i gu rac i on con f i gu r a c i on ;
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 . s c l=s c l ;
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 . . . ” ) ;
this . s e tT i cke r ( i nd i c a c i on ) ;
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 ] ) ;
a t r a s=new Command( ”Atras ” , Command.BACK, 1 ) ;
aceptar=new Command( ”Aceptar” , Command.OK, 1 ) ;
this . addCommand( a t r a s ) ;
this . addCommand( aceptar ) ;
this . setCommandListener ( this ) ;
Codigo de la aplicacion de administracion del SCL en J2ME 190
public void commandAction (Command c , Di sp layab l e d)
i f ( c==at ra s )
s c l . ve rConf igurac ion ( ) ;
i f ( c==aceptar )
for ( int i =0; i<s c l . s i s tema . getNumEntradas ( ) ; i++)
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);
for ( int i =0; i<s c l . s i s tema . getNumSalidas ( ) ; i++)
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” ) ;
catch ( Exception e )
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 Ticker i nd i c a c i on ;
private TextFie ld nuevaClave ;
private TextFie ld confirmarNuevaClave ;
private Command atras , aceptar ;
private Sc l s c l ;
private Lcon f i gu rac i on con f i gu r a c i on ;
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 . s c l=s c l ;
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) ;
Codigo de la aplicacion de administracion del SCL en J2ME 191
confirmarNuevaClave=new TextFie ld ( ”Confirmar c l ave :\n” , ”” ,10 , TextFie ld .NUMERIC | \
TextFie ld .PASSWORD) ;
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 ( nuevaClave ) ;
this . append ( confirmarNuevaClave ) ;
this . addCommand( a t r a s ) ;
this . addCommand( aceptar ) ;
this . setCommandListener ( this ) ;
public void commandAction (Command c , Di sp layab l e d)
i f ( c==at ra s )
s c l . ve rConf igurac ion ( ) ;
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” ) ;
catch ( Exception e )
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 ) ;
Codigo de la aplicacion de administracion del SCL en J2ME 192
G.6 Clase Fcontrol
import javax . m i c roed i t i on . l c du i . ∗ ;
public class Fcontro l extends Form implements CommandListener
private Ticker t i c k ;
private Image [ ] estadosImg ;
private ChoiceGroup [ ] s a l i d a s ;
private Command aceptar , a t r a s ;
private Sc l s c l ;
public Fcontro l ( Sc l s c l )
super ( ”Control de Sa l i d a s de l Sistema” ) ;
this . s c l=s c l ;
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” ) ;
catch ( Exception e )
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 ” ) ;
for ( int i =0; i<s c l . s i s tema . getNumSalidas ( ) ; i++)
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 ] ) ;
aceptar=new Command( ”Aceptar” ,Command.OK, 1 ) ;
a t r a s=new Command( ”Atras ” ,Command.BACK, 1 ) ;
this . s e tT i cke r ( t i c k ) ;
this . addCommand( a t r a s ) ;
this . addCommand( aceptar ) ;
this . setCommandListener ( this ) ;
Codigo de la aplicacion de administracion del SCL en J2ME 193
public void commandAction (Command c , Di sp layab l e d)
i f ( c==at ra s )
s c l . verOpciones ( ) ;
i f ( c==aceptar )
St r i ngBu f f e r estadosAct=new St r i ngBu f f e r ( ”” ) ;
for ( int i =0; i<s c l . s i s tema . getNumSalidas ( ) ; i++)
estadosAct . append ( St r ing . valueOf ( s a l i d a s [ i ] . g e tSe l e c t ed Index ( ) ) ) ;
new Fesperar ( s c l ) ;
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
import javax . m i c roed i t i on . l c du i . ∗ ;
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 ;
private Sc l s c l ;
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 . s c l=s c l ;
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 ?” ) ;
aceptar=new Command( ”Aceptar” ,Command.OK, 1 ) ;
c anc e l a r=new Command( ”Cancelar ” ,Command.CANCEL, 1 ) ;
this . append ( av i so ) ;
this . addCommand( cance l a r ) ;
Codigo de la aplicacion de administracion del SCL en J2ME 194
this . addCommand( aceptar ) ;
this . setCommandListener ( this ) ;
public void commandAction (Command c , Di sp layab l e d)
i f ( c==cance l a r )
s c l . verOpciones ( ) ;
i f ( c==aceptar )
new Fesperar ( s c l ) ;
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 ” ) )
new FenvioSms ( s c l , s c l . s i s tema . getCodigos ( 5 ) ) ;
else
new FenvioSms ( s c l , s c l . s i s tema . getCodigos ( 4 ) ) ;
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 ;
private Command aceptar ;
Codigo de la aplicacion de administracion del SCL en J2ME 195
private Sc l s c l ;
// 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 ;
private Command s a l i r ;
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” ) ;
this . s c l=s c l ;
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 ;
aceptar=new Command( ”Aceptar” ,Command.OK, 1 ) ;
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” ) ;
catch ( Exception e )
System . out . p r i n t l n ( ”Error a l cargar arch ivo de imagen ro j o . png/ verde . png” ) ;
this . addCommand( aceptar ) ;
this . setCommandListener ( this ) ;
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 \
Codigo de la aplicacion de administracion del SCL en J2ME 196
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 ( ) ) ;
//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++)
Codigo de la aplicacion de administracion del SCL en J2ME 197
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 ) ;
//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 ( ) ) ;
//Escr ibe es tado ac tua l
s c l . s i s tema . se tEstados ( ” entradas ” , estadosAct ) ;
//Borra l a s entradas de l ChoiceGroup
i f ( entradas . s i z e ( ) != 0)
entradas . 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 [ ] idRegEtiqEntradas=s c l . s i s tema . getIdRegEtiqEntradas ( ) ;
//Compara l a s modi f i cac iones de l o s es tados
for ( int i =0; i<estadosAct . l ength ( ) ; i++)
entradas . append ( s c l . s i s tema . ge tEt ique ta s ( idRegEtiqEntradas [ 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 ( entradas ) ;
//Asignaci on de pos i c i one s en e l Choicegroup
for ( int i =0; i<s c l . s i s tema . getNumEntradas ( ) ; i++)
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 ) ) ) ;
Codigo de la aplicacion de administracion del SCL en J2ME 198
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 ) ;
this . setCommandListener ( this ) ;
//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 ” ) ;
//Escr ibe es tado ac tua l
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 ( ) ;
//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 ) )
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)) ] , \
estadosImg [ In 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)) ] , \
estadosImg [ In 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
Codigo de la aplicacion de administracion del SCL en J2ME 199
s c l . setEnEjecuc ion ( fa l se ) ;
public void commandAction (Command c , Di sp layab l e d)
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 . ∗ ;
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 ;
Codigo de la aplicacion de administracion del SCL en J2ME 200
private int deltaMinLon ;
private int de l taLat ;
private int deltaLon ;
private TiledLayer t i l e s ;
private LayerManager lm ;
private Image mapaNoDisponible ;
private Sc l s c l ;
public GClocalizacionMapa ( Sc l s c l )
super ( true ) ;
this . s c l=s c l ;
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 ;
Codigo de la aplicacion de administracion del SCL en J2ME 201
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” ) ;
catch ( Exception e )
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 ;
Codigo de la aplicacion de administracion del SCL en J2ME 202
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” ) ;
catch ( Exception e )
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 ;
Codigo de la aplicacion de administracion del SCL en J2ME 203
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 . 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 . ∗ ;
Codigo de la aplicacion de administracion del SCL en J2ME 204
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 Sc l s c l ;
private Image enviarSms ;
private Image numSistema ;
public FenvioSms ( Sc l s c l , S t r ing texto )
super ( ”” ) ;
this . s c l=s c l ;
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” ) ;
catch ( Exception e )
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 ) ;
s c l . pan ta l l a . se tCurrent ( this ) ;
Codigo de la aplicacion de administracion del SCL en J2ME 205
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” ) )
s c l . ve rConf igurac ion ( ) ;
else
s c l . verOpciones ( ) ;
catch ( Exception e )
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 ( ) ;
catch ( Exception 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 ) ;
catch ( Exception e )
System . out . p r i n t l n ( ”Error : ” + e . t oS t r i ng ( ) + ”Error s l e e p run” ) ;
s c l . verOpciones ( ) ;
Codigo de la aplicacion de administracion del SCL en J2ME 206
G.11 Clase Fesperar
import javax . m i c roed i t i on . l c du i . ∗ ;
public class Fesperar extends Form implements CommandListener
private Str ingItem texto ;
private Command ver ;
private Sc l s c l ;
public Fesperar ( Sc l s c l )
super ( ”” ) ;
this . s c l=s c l ;
t exto=new Str ingItem ( ”” , ”Espere un momento . . . ” ) ;
ver=new Command( ”Ver Menu” ,Command.BACK, 1 ) ;
this . append ( texto ) ;
this . addCommand( ver ) ;
this . setCommandListener ( this ) ;
s c l . pan ta l l a . se tCurrent ( this ) ;
public void commandAction (Command c , Di sp layab l e d)
i f ( c==ver )
s c l . verOpciones ( ) ;
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.
MANUAL DE USUARIO DEL SISTEMA DE CONTROL Y LOCALIZACION 208
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.
MANUAL DE USUARIO DEL SISTEMA DE CONTROL Y LOCALIZACION 209
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.
MANUAL DE USUARIO DEL SISTEMA DE CONTROL Y LOCALIZACION 210
• 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.
MANUAL DE USUARIO DEL SISTEMA DE CONTROL Y LOCALIZACION 211
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
MANUAL DE USUARIO DEL SISTEMA DE CONTROL Y LOCALIZACION 212
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
MANUAL DE USUARIO DEL SISTEMA DE CONTROL Y LOCALIZACION 213
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
MANUAL DE USUARIO DEL SISTEMA DE CONTROL Y LOCALIZACION 214
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.
MANUAL DE USUARIO DEL SISTEMA DE CONTROL Y LOCALIZACION 215
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,
Fecha de consulta: 15-03-2008.
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,
Fecha de consulta: 10-06-2008.
[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 consulta: 16-06-2008.
FECHA DE ENTREGA:
Sr. Edgar Benıtez Srta. Diana Moya
AUTORES
Ing. Gonzalo Olmedo
DIRECTOR DE CARRERA DE INGENIERIA
EN ELECTRONICA Y TELECOMUNICACIONES
Top Related