UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERÍA INDUSTRIAL PROYECTO FIN DE CARRERA Diseño de un cronotermostato para calefacción sobre teléfonos móviles Estefanía Dolores Sánchez Gómez MADRID, septiembre de 2006
Autorizada la entrega del proyecto al alumno: Estefanía Dolores Sánchez Gómez LOS DIRECTORES DEL PROYECTO Eduardo Pilo de la Fuente Fdo.: Fecha: Ignacio Egido Cortés Fdo.: Fecha: Vº Bº del Coordinador de Proyectos Álvaro Sánchez Miralles Fdo.: Fecha: 2
Resumen del proyecto DISEÑO DE UN CRONOTERMOSTATO PARA CALEFACCIÓN SOBRE TELÉFONOS MÓVILES Autor: Sánchez Gómez, Estefanía Dolores. Directores: Pilo de la Fuente, Eduardo. Egido Cortés, Ignacio. Entidad Colaboradora: ICAI Universidad Pontificia Comillas. RESUMEN DEL PROYECTO: Este proyecto consiste en el diseño de un sistema de programación y control de una calefacción mediante el uso de un teléfono móvil y una tarjeta de interfaz. En el móvil se incorporará un programa Java, que permitirá programar la calefacción y además servirá como interfaz con el usuario. El sistema de control o teléfono móvil, está constituido por: Interfaz de usuario. Gestión de configuración de la calefacción. Comunicación con la tarjeta de interfaz. La tarjeta de interfaz, por otro lado, se ocupa de: Un microcontrolador que controla todo el sistema. Un puerto de comunicaciones. Un actuador para encender o apagar la caldera. Un sensor de temperatura. Un reloj externo, que establece la hora del microcontrolador. Se ha de diseñar el hardware y el software que se ejecutará por un lado en el teléfono móvil y por otro en el microcontrolador. De esta forma se implementa un cronotermostato programable que regula el control de la calefacción, de forma que la interfaz con el usuario se realiza mediante el propio teléfono móvil. El microcontrolador gestiona y actúa en función de la información que le transmite el teléfono. 3
Resumen del proyecto La comunicación entre el teléfono móvil y el microcontrolador se realiza en forma de comunicación serie utilizando Bluetooth en el teléfono y el puerto serie RS-232 en la tarjeta. La adaptación entre ambas señales se realiza mediante un adaptador RS232- Bluetooth comercial. El teléfono móvil interactúa con el usuario a través de una interfaz sencilla que permite realizar toda la configuración del sistema. Además el móvil controla también toda la parte referente a las comunicaciones. Por otro lado la tarjeta de interfaz se encarga de interactuar con la información que le aporta el sensor de temperatura del habitáculo y de manejar el encendido o apagado de la caldera. En la Figura 1, se pueden ver las partes que constituyen el sistema y como están relacionadas. También las partes propias que se han desarrollado en este proyecto. Figura 1 Esquema de configuración del sistema. A continuación se comentan con más detalles cada una de las partes del sistema: INTERFAZ Y SISTEMA DE CONTROL: Está constituido únicamente por un teléfono móvil, en concreto el teléfono NOKIA 6600. Este teléfono y otros muchos permiten la ejecución de aplicaciones en Java y de comunicación Bluetooth. El lenguaje 4
Resumen del proyecto de programación utilizado ha sido J2ME (Java2 Micro Edition), con la configuración CLDC (Connected Limited Device Configuration), orientada a dispositivos dotados de conexión y con limitaciones en cuanto a capacidad gráfica, cómputo y memoria. El modo de funcionar del sistema de control puede ser automático o manual. El modo por defecto es el automático. Cada día actualiza el perfil de temperaturas que previamente el usuario ha tenido que configurar. Entre las acciones que el usuario puede realizar se encuentra el encendido y apagado de la calefacción, concretar una temperatura de referencia y crear un perfil para un día determinado. En cada perfil se pueden programar 4 consignas diferentes de temperatura para todo el día. TARJETA DE INTERFAZ: Se basa en un microcontrolador. Se ha utilizado el microcontrolador PIC 16F873A. Se ha programado utilizando el lenguaje C, empleando el entorno de desarrollo SourceBoost. La tarjeta de interfaz recibe la configuración enviada por el teléfono y en base a dicha configuración realiza el control de la caldera en función de la temperatura indicada por el sensor. Esta tarjeta se ha realizado con la placa MICRO Pic Trainer y posteriormente se construyó otra placa auxiliar de periféricos (reloj, etc ), que se acopla a la misma. En esta segunda placa se ha montado un reloj contador con un cristal de cuarzo, el sensor de temperatura y la circuitería necesaria para la comunicación RS-232. COMUNICACIÓN TELÉFONO MOVIL Y TARJETA DE INTERFAZ: Gran parte de los esfuerzos de este proyecto se han centrado en establecer la conexión entre el teléfono y la tarjeta. El teléfono utiliza el protocolo de comunicación serie Bluetooth: Serial Port Profile (SPP), para comunicarse con la tarjeta. La tarjeta utiliza una conexión serie, en concreto el protocolo RS-232 y dispone de un adaptador externo RS232- Bluetooth. La tarjeta recibe los datos que le llegan del teléfono y responde con la información solicitada por el mismo y confirmando la recepción integra de los mismos. Para comprobar el buen funcionamiento de la comunicación, se ha desarrollado un pequeño programa de prueba en C, que permite actuar como si fuera la tarjeta cuando se comunica con el teléfono y como teléfono cuando lo hace con la tarjeta. Como resultados del proyecto, se ha logrado desarrollar la parte correspondiente a la tarjeta de interfaz y sus comunicaciones. Se ha conseguido implantar el programa en el teléfono, habiendo podido comprobar el funcionamiento de las comunicaciones únicamente mediante simulación. 5
Abstract DESIGN OF A HOURLY-THERMOSTAT FOR A CENTRAL HEATING SYSTEM USING A MOBILE PHONE Autor: Sánchez Gómez, Estefanía Dolores. Directores: Pilo de la Fuente, Eduardo. Egido Cortés, Ignacio. Entidad Colaboradora: ICAI Universidad Pontificia Comillas. ABSTRACT This project consists of the design of a programming and control system of a central heating system, using a mobile phone and a interface card. A Java program will be incorporated in the mobile phone; it will allow programming the heating and will also implement the user interface. The control system in the mobile phone is constituted by: User interface. Heating configuration management. Communication with the interface card. On the other hand the interface card, takes care of: A microcontroller that will control the whole system. A communication port. An actuator to switch on/off the heating. A temperature sensor. An external clock, which establish time in the microcontroller. The hardware and the software that will be executed, on the other hand in the mobile phone and by the other in the microcontroller has to be designed. A programmed hourly-thermostat that will regulate/control the heating system is then implemented. The user interface will be performed by the mobile phone. The microcontroller manages the information transmitted by the telephone which determines its actions. The communication between the mobile phone and the microcontroller is implemented as a serial communication, using Bluetooth in the telephone and the serial port RS-232 in the card. A commercial RS232-Bluetooth adapter serves as the interface between those systems. 6
Abstract The user interacts with the mobile phone through a simple user interface that allows system configuration. The mobile phone also controls the communications. On the other hand the interface card interacts with the information received from the temperature sensor and manages the heating switching on/off. The different components of the system and how they are linked is shown in the Fig. 1. The components developed as part of this project has been indicated in the figure Also it can be seen the project s own parts Figure 1: Diagram of the system configuration. Each of the system s parts are next mentioned in more detail: INTERFACE AND CONTROL SYSTEM: It is constituted by a mobile phone, specifically the telephone NOKIA 6600. This telephone (and many other ones) allows the execution of Java applications and Bluetooth communication. The programming language used is J2ME (Java2 Micro Edition), with the configuration CLDC (Connected Limited Device Configuration), which is oriented to devices provided with connection and with limitations referring to graphic capacity and memory. 7
Abstract The control system can work in two ways: automatic or manual. The default way is the automatic one. The profile of temperatures for the day which must be configured previously by the user is actualised daily. Among the actions can perform the user it is included the manual switching (on/off) the heating, establishing a reference temperature and creating a profile for each day. Four different reference temperatures for the whole day can be programmed in each profile. INTERFACE CARD: It is based in a microcontroller. The PIC 16F873A microcontroller has been used, which has been programmed in C language using the development environment SourceBoost. The interface card receives the configuration the telephone has sent. Among this configuration it makes the control of the heating system with the temperature given by the sensor. This card has been implemented in a MICRO Pic Trainer card and another auxiliary card for peripherals (clock, etc ), has been developed which is connected to the other. In this second card a counter clock with a quartz crystal, a temperature sensor and the circuit necessary to RS232 communications have been included. COMMUNICATION MOBILE PHONE AND INTERFACE CARD: Most of the efforts in this project have been focused on establishing the connection between the mobile phone and the card. The mobile phone uses the communication Bluetooth serial protocol: Serial Port Profile (SPP), to communicate with the card. The card uses a serial connection, specifically the RS232 protocol and has a Bluetooth serial port plug (RS232-Bluetooth commercial external adapter). The card receives data from the telephone and answers with the information required and confirming the data reception. To allow checking all the communications a tested program in C has been developed, which permits to act like the card when it is communicating with the telephone or as the telephone when the communication is with the card. As results of this project, the interface card and the communications have been developed. The program in the telephone has been implanted and its usage has been tested only by simulation. 8
Índice Índice Parte I MEMORIA 1 Introducción 16 44 1.1 Precedentes 16 Capítulo 1 Introducción 1.1 Motivación del proyecto 18 1.2 Objetivos 18 1.3 Metodología/Solución desarrollada 19 1.4 Recursos /Herramientas empleadas 20 Capítulo 2 Sistema de control e interfaz de usuario 2.1 Qué es un perfil? 22 2.2 Software del teléfono móvil 23 2.2.1 Pantalla principal 24 2.2.2 Pantalla de configuración 25 2.2.3 Pantalla de gestión de perfiles 26 2.3 Diagrama de flujo del programa del teléfono móvil 27 2.4 Pruebas 30 Capítulo 3 Tarjeta de Interfaz 3.1 Descripción de la tarjeta de interfaz 32 3.2 Hardware de la tarjeta de interfaz 32 3.3 Software de la Tarjeta de Interfaz 33 3.3.1 Subrutina de Interrupción Puerto Serie 35 3.3.2 Subrutina de Interrupción Reloj externo 36 3.4 Circuitería y Montaje 38 3.4.1 Circuito del reloj externo 38 3.4.2 Circuito del sensor de temperatura. 39 3.4.3 Circuito de la comunicación USART 40 3.5 Pruebas 40 Capítulo 4 Comunicación Sistema de control Tarjeta de Interfaz 4.1 Protocolo de comunicaciones 43 4.1.1 Caso 0! Temperatura de referencia elegida por el usuario. 4.1.2 Caso 1! Temperatura actual del habitáculo. 45 9
Índice 4.1.3 Caso 2! Envío del perfil del día siguiente. 46 4.1.4 Caso 3! Orden directa: Encender la calefacción. 47 4.1.5 Caso 4! Orden directa: Apagar la calefacción. 48 4.1.6 Caso 5! Saber cual es el estado de la caldera: On/Off 49 4.2 Pruebas 49 Capítulo 5 Resultados 5.1 Resultados 52 5.2 Pruebas 52 Capítulo 6 Conclusiones y futuros desarrollos 6.1 Conclusiones 55 6.2 Futuros desarrollos 55 Capítulo 6 Bibliografía Parte II PLIEGO DE CONDICIONES 1 Condiciones Generales 59 2 Condiciones económicas. 60 Parte III PRESUPUESTO Anexo A Código para manejar el RecordStore 1 La clase RecordStore 64 2 Código de las funciones para la gestión de perfiles 65 2.1 Crear perfil 66 2.2 Editar perfil 66 2.3 Eliminar perfil 66 2.4 Ver perfiles 67 2.5 Nota importante 67 Anexo B Características técnicas del hardware de la tarjeta de interfaz. 1 Microcontrolador 16F873A 69 2 Sensor de temperatura LM35 70 10
Índice Anexo C Funcionamiento de la tecnología bluetooth 1 Tecnología Bluetooth: Introducción 72 2 Software de la tecnología bluetooth 73 2.1 INICIALIZACIÓN 75 2.2 Modo SERVIDOR 78 2.3 Modo CLIENTE 80 11
Índice de figuras Índice de Figuras Figura 1 Esquema de configuración del sistema.... 4 Figura 2 Datos de un perfil... 22 Figura 3 Pantalla principal del programa del móvil... 24 Figura 4 Pantalla de configuración del programa del móvil... 25 Figura 5 Pantalla Gestión de Perfiles del programa del móvil... 26 Figura 6 Pantalla Crear Perfil... 26 Figura 7 Pantalla Asignar Perfiles... 27 Figura 8 Diagrama de flujo del programa del móvil... 28 Figura 9 Diagrama de flujo del programa del móvil. Menú perfiles... 30 Figura 10 Esquema del programa principal del microcontrolador... 35 Figura 11 Diagrama de flujo de la subrutina de interrupción puerto serie... 37 Figura 12 Diagrama de flujo de la subrutina de interrupción reloj externo... 39 Figura 13 Montaje del reloj externo... 40 Figura 14 Montaje del sensor de temperatura... 40 Figura 15 Montaje de la comunicación USART... 41 Figura 16 Placa auxiliar... 42 Figura 17 Trama de un mensaje desde el móvil... 45 Figura 18 Trama de un mensaje desde la tarjeta de interfaz... 45 Figura 19 Trama de un mensaje Caso 0... 46 Figura 20 Trama de un mensaje respuesta Caso 0... 46 Figura 21 Trama de un mensaje erróneo de respuesta Caso 0... 46 Figura 22 Trama de un mensaje Caso 1... 46 Figura 23 Trama de un mensaje respuesta Caso 1... 47 Figura 24 Trama de un mensaje erróneo de respuesta Caso 1... 47 Figura 25 Trama de un mensaje Caso 2... 47 Figura 26 Trama de un mensaje respuesta Caso 2... 48 Figura 27 Trama de un mensaje erróneo de respuesta Caso 2... 48 Figura 28 Trama de un mensaje Caso 3... 48 Figura 29 Trama de un mensaje respuesta Caso 3... 48 12
Índice de figuras Figura 30 Trama de un mensaje erróneo de respuesta Caso 3... 49 Figura 31 Trama de un mensaje Caso 4... 49 Figura 32 Trama de un mensaje respuesta Caso 4... 49 Figura 33 Trama de un mensaje erróneo de respuesta Caso 4... 49 Figura 34 Trama de un mensaje Caso 5... 50 Figura 35 Trama de un mensaje respuesta Caso 5... 50 Figura 36 Trama de un mensaje erróneo de respuesta Caso 5... 50 Figura 37 Montaje del proyecto en simulación... 54 Figura 38 Métodos de la clase RecordStore... 66 Figura 39 Métodos para manejar los registros en un RecordStore... 66 Figura 40 Características del dispositivo PIC16F873A... 70 Figura 41 Característica temperatura/tensión de salida. LM35... 71 Figura 42 Etapas de toda aplicación Bluetooth... 75 Figura 43 Actividades de un servidor y un cliente... 76 Figura 44 Inicialización de la aplicación Bluetooth... 77 Figura 45 Implantación del modo servidor... 79 Figura 46 Implantación del modo cliente... 81 Figura 47 DiscoveryAgent y DiscoveryListener... 82 13
Prólogo Prólogo Este documento se divide en tres partes: Parte I: Memoria. Es la principal de este documento, contiene la descripción detallada de todo lo que se ha realizado. Se divide en varios capítulos, el primero hace una introducción muy general. Los capítulos del 2 al 4 tratan de las tres partes que componen el sistema: el teléfono móvil, la tarjeta de interfaz y la comunicación entre ambos. En el capitulo 5 se habla de los resultados obtenidos. Y en el capitulo 6 se comentan las conclusiones que se han obtenido, así como los futuros desarrollos, continuación de este proyecto. El capítulo 7 menciona la bibliografía utilizada. Parte II: Pliego de condiciones. Información complementaria. Parte III: Presupuesto. Se muestra el coste del proyecto y con ello se justifica la realización del mismo.
Parte I MEMORIA
Introducción. Precedentes 1 Introducción El objetivo principal del proyecto es consiste en el diseño de un sistema de programación y control de una calefacción mediante el uso de un teléfono móvil y una tarjeta de interfaz. La funcionalidad de la aplicación desarrollada consiste en la regulación autónoma de la calefacción de un habitáculo cualquiera. Está formado por dos partes: un teléfono móvil y una tarjeta de interfaz. La parte del teléfono es un sistema de control desde donde se puede configurar y enviar consignas de temperatura a la tarjeta de interfaz. La tarjeta de interfaz emplea un microcontrolador para comunicarse con el teléfono o medir la temperatura ambiente y dar la señal de encendido y apagado a la caldera. Así mismo se emplea un adaptador Bluetooth-RS232 para poder comunicar la salida de dicha tarjeta con el teléfono móvil. 1.1 Precedentes A medida que pasa el tiempo, cada vez más son los teléfonos que llevan implementadas una gran cantidad de funcionalidades. Dos funciones fundamentales para el desarrollo de este proyecto son: la comunicación Bluetooth y el desarrollo de aplicaciones en Java. Este proyecto ha dado lugar a una aplicación útil y ha permitido tener las bases y la experiencia para desarrollar nuevas aplicaciones, como por ejemplo sistemas de climatización o alarmas contra incendios o antirrobo. En conclusión, cada vez nos desplazamos con pasos más grandes hacia una era digitalizada, sistemas como el diseñado en este proyecto evolucionarán y dará paso a numerosos beneficios y ventajas a través de instalaciones tradicionales 16
Capítulo 1 Introducción
Introducción 1.1 Motivación del proyecto Este proyecto consiste en el diseño de un termostato donde se pueda programar el uso diario de la calefacción de un hogar a través de un teléfono móvil. Debido al gran número de funciones y actividades complejas que llegan a realizar estos dispositivos se pensó en incluir la programación de un termostato. De esta forma se implementa un crono-termostato programable que regula el control de la calefacción, de forma que la interfaz con el usuario se realiza mediante el teléfono móvil. La otra parte del proyecto, el microcontrolador gestiona y actúa en función de la información que le transmite el teléfono. La comunicación entre el teléfono móvil y el microcontrolador se realiza en forma de comunicación serie utilizando Bluetooth en el teléfono y el puerto serie RS-232 en la tarjeta. La adaptación entre ambas señales se realiza mediante un adaptador RS232- Bluetooth comercial. Las aplicaciones como la que se ha desarrollado en este proyecto no es nueva, ya que se pueden encontrar multitud de dispositivos parecidos en el mercado. 1.2 Objetivos El objetivo principal de este proyecto es desarrollar el hardware y el software para controlar un sistema de calefacción o aire acondicionado desde un teléfono móvil. Este incluye el diseño de un circuito de interfaz entre la caldera y el móvil, así como del software que se ejecuta en el móvil. Objetivos de la tarjeta de interfaz: - Interfaz con la caldera: encender o apagarla. - Comunicación con el móvil, recibir consignas de temperatura. - Medir la temperatura. - Mantener la hora. 18
Introducción - En función de la hora y de la temperatura que haga, encender o apagar la caldera. - Comunicación con el sistema de control: * Recibir la lista de consignas horarias de temperatura. * Recibir hora del sistema de control (Sincronización). * Enviar la temperatura cuando se le pida (monitorización). Objetivos del teléfono móvil: - Interfaz de usuario: Permitir al usuario interactuar con el sistema. - Comunicación con la tarjeta de interfaz: * Enviarle consignas horarias de temperatura. * Enviar la hora y el día. * Pedir y recibir temperatura. 1.3 Metodología/Solución desarrollada En este proyecto existen dos partes diferenciadas, que aunque se pueden diseñar por separado se deben tener en cuenta las características y especificaciones de ambas para llevar a cabo el diseño y desarrollo del sistema completo. Las tareas que se han realizado a lo largo del proyecto son: La parte del teléfono móvil: o Desarrollo y comprobación del funcionamiento del programa con los emuladores. o Comprobación de las comunicaciones con el teléfono móvil NOKIA 6600 y un programa de comunicaciones en C. 19
Introducción La parte de la tarjeta de interfaz: o Con la placa MicroPic Trainer y el hyperterminal o un programa de comunicaciones en C. 1.4 Recursos /Herramientas empleadas Para la realización de este proyecto es imprescindible un ordenador y además será necesario: Para el teléfono móvil: o o En J2ME. Un entorno para desarrollar el programa del móvil: el Jbuilder, Nokia Developer Suite y Nokia Connectivity Framework Lite. o Móvil Nokia 6600. Para el microcontrolador: o o En C, C++. El entorno de desarrollo SourceBoostC y la tarjeta MicroPIc Trainer (a la que se le añadirán los periféricos en tarjeta aparte ). 20
Capítulo 2 Sistema de control e interfaz con el usuario
Sistema de control e interfaz con el usuario En este capítulo se presenta las partes principales del programa del teléfono móvil, cómo se ha desarrollado el software del teléfono y un diagrama de flujo del mismo. El teléfono móvil puede tener dos modos de actuación: automático y manual: Automático: este es el modo por defecto, lejos de cualquier actuación del usuario. Manual: este modo en cambio tiene una vigencia desde que empieza su implantación hasta que acaba el día a las 00:00, cuando vuelve a restaurar el modo automático. El modo por defecto será siempre el automático, de esta forma la funcionalidad del teléfono dependerá de los datos de un perfil que ha sido creado y guardado por el usuario. 2.1 Qué es un perfil? Un perfil es un conjunto de consignas de temperaturas horarias y se organiza en forma de 4 consignas diferentes. Su distribución es la siguiente: la hora (el primer elemento), los minutos de la hora, la temperatura asociada a la hora, la precisión de la temperatura (el último elemento). La Figura 2 muestra el contenido de un perfil: Hora 1 Temp. 1 Hora 2 Temp. 2 Hora 3 Temp. 3 Hora 4 Temp. 4 Figura 2 Datos de un perfil Todo perfil tiene asociado el nombre, puesto por el usuario, cuando se guarda el perfil en la memoria, el nombre se guarda junto a él. 22
Sistema de control e interfaz con el usuario 2.2 Software del teléfono móvil El software diseñado que se estará ejecutando ha de tener bien definidas y estructuradas las siguientes funciones: 1. Comunicación con la tarjeta de interfaz: Esta comunicación ha de poderse realizar siempre que el móvil necesite transmitir una información a la tarjeta. (Ver Capítulo 4: Comunicación sistema de control y tarjeta de interfaz.) 2. Gestión de acceso exclusivo a recursos: El teléfono móvil tiene la posibilidad de comunicarse con varios dispositivos. Para que no haya problemas en el momento de enviar y recibir, por ejemplo si dos envíos se producen al mismo tiempo, el canal de transmisión solo puede ocuparse con uno de los dos. La gestión de esta parte se realiza mediante semáforos de tiempo. 3. Interfaz usuario: El usuario tiene acceso a este sistema únicamente a través del teléfono móvil. El programa del teléfono incluye todas las interfaces gráficas necesarias para la inserción de información por parte del usuario. 4. Gestión de perfiles: El software realizado permite asociar a un día determinado, modificar el contenido de un perfil. (Ver Anexo A: Código para manejar el RecordStore.) Al hablar del programa que se ejecuta en el móvil y de las partes que lo constituyen, se puede hablar de forma equivalente de pantallas. De esta forma se puede decir que en el móvil hay tres partes o tres pantallas principales, que se describen a continuación: a) Pantalla principal. b) Pantalla de configuración. c) Pantalla de gestión de perfiles. 23
Sistema de control e interfaz con el usuario 2.2.1 Pantalla principal En esta pantalla se muestra el contenido que da información importante y en tiempo real al usuario. Como se puede apreciar en la Figura 3, los datos que se muestran son: La temperatura medida del habitáculo, proporcionada por el sensor de temperatura. La temperatura de referencia es la consigna que tiene la tarjeta para compararla con la temperatura que hace realmente en la habitación y si la primera es mayor o menor, encender o apagar la caldera, respectivamente. El móvil puede obtener esta temperatura de referencia, bien del perfil que se encuentra activo ese día, bien del usuario, en un momento dado éste puede introducir una temperatura determinada y el teléfono dejaría de utilizar el perfil para ese día o bien si no hay ni lo uno ni lo otro la temperatura sería 0 ºC. El estado de la caldera, que se lo proporciona la tarjeta. El perfil activo ese día, si ese día está configurado para que actúe dicho perfil. En caso de no estarlo o estar usando la temperatura de referencia introducida por el usuario, aparecería sin perfil. La hora que aparece junto con las medidas de la temperatura y estado de la cadera se refieren a la hora en la que se produjo la última medición, en concreto, la hora en que el teléfono mandó el mensaje correspondiente a la tarjeta para cuestionarle sobre ambas medidas. Figura 3 Pantalla principal del programa del móvil 24
Sistema de control e interfaz con el usuario 2.2.2 Pantalla de configuración Se accede a esta pantalla por medio del comando Configurar, que se encuentra en el menú de comandos llamado Options. Ver Figura 4. Las acciones que se pueden realizar en esta pantalla, son: Encender/Apagar, la acción que aparece por defecto al inicializar el programa es Encender, puesto que todo inicialmente se encuentra a valor 0 ó apagado. Una vez pulsado Encender, instantáneamente se muestra Apagar. El estado de este botón será en función de lo que el usuario introduzca y cuando se inicie el programa de control, en función del estado de la caldera, que lo proporciona la tarjeta. Es una acción que supone una orden directa para la tarjeta: encender o apagar la caldera, dejando de estar en el modo automático y pasando al manual. Fijar la temperatura de referencia, esta función permite al usuario introducir la temperatura que desea establecer en su habitáculo. Como ya se ha comentado con esta función se pasa al estado manual. Selección perfil para hoy, muestra los perfiles existentes y permite al usuario seleccionar cualquiera y establecerlo para hoy. Se pasa a un estado manual. Perfiles, da paso a la tercera pantalla principal, desde la que se gestionan los perfiles. Figura 4 Pantalla de configuración del programa del móvil 25
Sistema de control e interfaz con el usuario 2.2.3 Pantalla de gestión de perfiles Desde esta pantalla se realiza la gestión de los perfiles. En la Figura 5 se aprecia que un perfil hay que crearlo, se puede copiar, editar, eliminar y otras funciones que se detallarán: Figura 5 Pantalla Gestión de Perfiles del programa del móvil Las diferentes funciones disponibles son: Crear perfil: Es una función que permite al usuario crear un perfil, introduciendo previamente el nombre que le quiere asignar, las horas y sus temperaturas asociadas. En la Figura 6 se muestra cómo se puede realizar esto: Figura 6 Pantalla Crear Perfil En el Anexo A se describe en detalle la forma de manejar los métodos de la clase RecordStore, que sirve para manejar una base de datos en un teléfono móvil. 26
Sistema de control e interfaz con el usuario Copiar perfil: copia el perfil que se seleccione, asignándole el nombre por defecto Copia de [nombre del perfil seleccionado]. La copia se añade a la lista de perfiles. Editar perfil, esta función permite al usuario modificar el contenido de los perfiles: nombre, horas y temperaturas. Eliminar perfil, elimina el perfil que se seleccione o todos a la vez. Ver perfiles, muestra el contenido del perfil que se haya seleccionado. Asignar perfiles, permite al usuario asignar un determinado perfil a cada día de la semana. En la Figura 7 se muestra como al miércoles se le ha asociado el perfil con nombre Trabajo. Figura 7 Pantalla Asignar Perfiles 2.3 Diagrama de flujo del programa del teléfono móvil En las Figuras 8 y 9 se presenta un detallado diagrama donde se puede ver cómo está estructurado el programa que se ejecuta en el teléfono móvil. 27
Sistema de control e interfaz con el usuario Pantalla principal Configurar Temperatura medida Temperatura referencia Estado caldera Perfil Gestionado por timers y semáforos. Apagar/Encender Fijar temp. referencia Selección perfil/hoy Perfiles Transmite a tarjeta Modo: manual Actualiza estado caldera Usuario introduce temperatura Transmite a tarjeta Modo: manual Actualiza Temp. referencia y Perfil: sin perfil Usuario elige perfil solo para hoy Transmite a tarjeta Modo: manual Actualiza Perfil:nombre perfil elegido Continúa en la página siguiente Figura 8 Diagrama de flujo del programa del móvil 28
Sistema de control e interfaz con el usuario Viene de la página anterior Perfiles Crear perfil Copiar perfil Editar perfil Eliminar perfil Usuario introduce el nombre del perfil, las horas y temperaturas Usuario selecciona el perfil a copiar entre los disponibles Usuario modifica nombre, horas y temperaturas de cualquier perfil. Perfil Registro Escribir en memoria Escribir en memoria Actualiza/ sobrescribe memoria Actualiza memoria Record Store eliminado Gestión de memoria y funcionamiento automático Ver perfil Asignar perfiles Se muestra la lista de perfiles disponibles Usuario asigna un perfil a un día de la semana Leer de memoria Actualiza memoria 29
Sistema de control e interfaz con el usuario Figura 9 Diagrama de flujo del programa del móvil. Menú perfiles 30
Sistema de control 2.4 Pruebas Para el desarrollo del programa del teléfono móvil, se ha utilizado el entorno Borland JBuilder Foundation 2005 y el de Nokia, éste último permite trabajar con emuladores de teléfonos móviles de NOKIA. Se he realizado un programa en C para comprobar las comunicaciones Bluetooth. 31
Capítulo 3 Tarjeta de Interfaz
Tarjeta de Interfaz 3.1 Descripción de la tarjeta de interfaz Este capítulo desarrolla el hardware y el software de la tarjeta, así como el montaje de la misma. La regulación continua de la calefacción y el ajuste de una determinada temperatura en unas horas concretas implica por un lado una medida continuada y precisa de la temperatura del habitáculo cada pequeños intervalos de tiempo (una interrupción de tiempo), por otro una buena comunicación de la información que le manda el teléfono móvil a la tarjeta. Con esta información la tarjeta también sabe si tiene que actuar en modo manual o en su modo normal: automático. Según el tipo de mensaje la tarjeta ejecutará una acción u otra. (Ver el apartado 4.1: Protocolo de comunicaciones). La tarjeta parte de estas dos fuentes de información: sensor de temperatura y comunicación con el teléfono, para encender y apagar la caldera. 3.2 Hardware de la tarjeta de interfaz A continuación se indica el hardware que posee la tarjeta: Microcontrolador: Es el componente principal de la tarjeta. Se ha utilizado el PIC 16F873A, de 28 patillas, que incorpora una USART para realizar la comunicación a través del puerto serie. El microcontrolador depende de un cuarzo de cristal de 4 MHz, ésta es su frecuencia normal de funcionamiento. Por otro lado necesita mantener la hora diaria, ésta se controla desde otro reloj, el externo. Reloj externo: Está constituido también por un cristal de cuarzo, lo que le hace ser más preciso y estable. Sensor de temperatura: Lo constituye el sensor LM35, del que recibe la temperatura actual del habitáculo. Para más información acerca de este sensor se puede consultar [NATIO94]. 33
Tarjeta de Interfaz En el Anexo B se muestran las características fundamentales del microcontrolador y del sensor de temperatura. 3.3 Software de la Tarjeta de Interfaz El programa que se ejecuta en el microcontrolador se estructura según se indica a continuación y se presenta en la Figura 10. Se comienza por la función principal en la que se encuentra en primer lugar las inicializaciones de los registros y funciones que se utilizaran. Esta función principal se encontrará en modo sleep cuando no sea despertada por las interrupciones o no deba realizar las funciones asociadas a las mismas. 34
Tarjeta de Interfaz Posibles Interrupciones externas WAKE UP Interrupción hora Móvil transmite 1. Mide temp. del sensor 2. Recorre perfil de temp. 3. Actualiza hora 4. Actualiza temp. en caldera. if (mensaje ==comando x) El microcontrolador responde según comando. Inicio () Sleep () Figura 10 Esquema del programa principal del microcontrolador Este programa principal sólo se va a despertar con dos tipos de interrupción: Recepción de caracteres por el puerto serie. Señal de reloj externa. En los siguientes apartados se detallan las acciones a realizar en cada uno de estos casos. 35
Tarjeta de Interfaz 3.3.1 Subrutina de interrupción puerto serie Esta interrupción salta cuando el flag bit de interrupción de recepción de la USART se activa, se encuentra en el registro PIR1 y controla los flag bits de las posibles interrupciones que puede soportar el microcontrolador. El registro que recibe los caracteres del puerto serie es el RCREG. Al mismo tiempo que va recibiendo los caracteres, éstos van pasando a un vector de caracteres donde quedarán guardados todos los datos y por tanto el mensaje recibido. La condición de fin de recepción se produce al encontrar el carácter z. Una vez obtenido el mensaje se calcula su paridad, para ver si el mensaje ha llegado íntegro como lo ha mandado el teléfono. Si la comprobación es correcta el programa pasa a ejecutar la acción correspondiente al comando recibido. Posteriormente envía un mensaje de respuesta al móvil para que sepa que la recepción ha sido un éxito. Si la paridad calculada no coincidiese con la paridad que trae el mensaje, el programa procede a enviar un mensaje de error. (Ver apartado 4.1: Protocolo de comunicaciones). El diagrama de flujo de lo anterior se encuentra en la Figura 11. 36
Tarjeta de Interfaz if ((pir1&0x20)==0x20){ //Ha saltado la interrupción mensajerecibido[i]=rcreg; ProcesaMensaje(); CalculoParidad(); if(es correcta){ }else{ AcciónSegunComando(); MandarMensajeOK(); } } MandarMensajeErr(); Figura 11 Diagrama de flujo de la subrutina de interrupción puerto serie Acerca de la recepción de perfiles, hay que aclarar que el perfil que el teléfono envía y que recibe el microcontrolador un día, por ejemplo el martes, es el perfil que le toca utilizar el miércoles. Los perfiles se guardan en la memoria persistente del microcontrolador, la EEPROM, así cuando se produzca el cambio de día el micro dispone de las consignas para el día siguiente. 3.3.2 Subrutina de interrupción reloj externo Esta subrutina se encarga de despertar al microcontrolador cada 0.25 segundos, para actualizar la hora y de gestionar el control de las funciones encargadas del control de la temperatura. Se ha elegido este intervalo de tiempo porque su manejo es más fácil a la hora de contabilizar las interrupciones y actualizar la hora, puesto que 1 segundo es múltiplo suyo. Se 37
Tarjeta de Interfaz produce cuando por la entrada del micro RB0 llega un pulso del reloj externo y se activa el flag bit de interrupciones externas, que está situado en el registro INTCON. A continuación se captura la temperatura del habitáculo a través del sensor de temperatura LM335. Esto es necesario para que pueda controlar el encendido y apagado de la caldera. Cada segundo el microcontrolador se encarga de revisar el perfil de las horas para comprobar si en ese momento debe actualizar y cambiar la temperatura del habitáculo. Esta interrupción tiene menos prioridad que la del puerto serie, puesto que no se debe perder ningún mensaje que llegase del móvil. Es cierto que se van a perder algunas interrupciones del reloj externo, pero todos los mensajes recibidos llevan incluida la hora en su encabezado. De esta forma, no sólo se recuperan las interrupciones perdidas durante la transmisión, sino que si durante el día se pudiera llegar a producir por ejemplo una pérdida de 5 segundos cada dos horas, en ese momento también se recuperan. El diagrama de flujo de esta subrutina se presenta en la Figura 12. 38
Tarjeta de Interfaz if ((intcon 0x02)==0x02){ ActualizaHora(); Temp = LeeTemperaturaSensor(); if(temp <= (consigna histéresis)){ Se enciende la caldera; }else{ Se apaga la caldera; } Cada segundo{ RevisarVectorConsigna(); Cada 24 horas{ ActualizarPerfil(); } Figura 12 Diagrama de flujo de la subrutina de interrupción reloj externo 3.4 Circuitería y Montaje 3.4.1 Circuito del reloj externo El reloj externo ha de ser muy estable, por eso está formado por un cristal de cuarzo de frecuencia 32.768KHz. Se acopla al contador binario de 14 bits, CD4060BC, para conseguir que la interrupción se produzca cada 0.25 segundos. Su patilla 3 va acoplada a la entrada Rb0 del micro. La frecuencia que se obtiene con la división por 13 bits: 39
Tarjeta de Interfaz 32768Hz 8192 = 4Hz! 0.25 segundos. En la Figura 13 se muestra el montaje del reloj externo. Figura 13 Montaje del reloj externo 3.4.2 Circuito del sensor de temperatura El sensor utilizado es el LM335, su salida incrementa 10mV por grado Kelvin. El potenciómetro de 10 K Ω es para ajustar la precisión del rango de medida que se desee y que se haya fijado, de 0 a 40 ºC. La salida de tensión ha de acoplarse a la entrada RA1 del micro, es una entrada analógica/digital, configurada para este caso como analógica. En la Figura 14 se ve este montaje. Figura 14 Montaje del sensor de temperatura 40
Tarjeta de Interfaz 3.4.3 Circuito de la comunicación USART Para realizar las comunicaciones de la tarjeta con el exterior se han empleado comunicaciones serie RS232. Por ello, ha sido necesario emplear un adaptador TTL-RS232 para adaptar los niveles del microcontrolador (0 a 5 voltios) a los niveles RS232 ( ± 5 V. - ± 12 V. ). En la Figura 15 se muestra este montaje realizado con un el adaptador de niveles Max 232. Figura 15 Montaje de la comunicación USART 3.5 Pruebas Para el desarrollo del firmware se han utilizado dos entornos; uno para la depuración y compilación del programa, llamado SourceBoost. Y el segundo para la programación del microcontrolador, este es el PicProgrammer. Se ha comprobado el funcionamiento del programa ya grabado en el microcontrolador, a través de la placa MICRO PIC Trainer, a esta placa se le ha acoplado otra donde van montados el resto de elementos necesarios para el desarrollo de toda la placa. Para llevar a cabo las funciones para la medición de temperatura, recepción de caracteres vía serie y el reloj externo, se ha montado la placa auxiliar que se muestra en la Figura 16. 41
Tarjeta de Interfaz Figura 16 Placa auxiliar Sensor de temperatura Comunicación con la placa MICRO Pic Trainer Reloj externo Conector DB9 para la comunicación con el PC. Circuitería para la comunicación USART 42
Capítulo 4 Comunicación Sistema de control Tarjeta de Interfaz
Comunicación Sistema de control Tarjeta de Interfaz La comunicación entre el teléfono móvil y la tarjeta de interfaz, se realiza con la ayuda de un dispositivo que actúa de intermediario entre ambas partes. Este dispositivo es el Bluetooth serial port plug F2M01 de Free2Move, (más información en www.free2move.se). Este adaptador se ha utilizado para cumplir con los objetivos de comunicación. El teléfono debe comunicarse vía Bluetooth y la tarjeta vía serie RS232. 4.1 Protocolo de comunicaciones Los mensajes que el móvil envía a la tarjeta son de tipo pregunta u orden, ya que es el único que puede iniciar una comunicación. Una vez enviado el mensaje, el móvil se queda esperando la respuesta de la tarjeta. Si al comprobar la paridad(*) de este mensaje, ésta fuera errónea, el móvil procedería a reenviar el mismo mensaje que antes, y así hasta que la comprobación de la paridad sea correcta. Los mensajes que la tarjeta envía al móvil son siempre de tipo respuesta, ya que la tarjeta nunca toma la iniciativa de mandar nada por su cuenta. Nada más llegar el mensaje a la tarjeta, ésta comprueba la paridad para ver que el mensaje ha llegado integro. Si todo está correcto procede a actuar según lo que le pide el comando y a responder de acuerdo le pregunta el teléfono. Si la paridad no coincidiese, la tarjeta responde con un mensaje de error. Cada mensaje enviado por el teléfono comienza con la hora que se captura en el momento en que se envía el mensaje. La hora se puede decir que es la cabecera del mensaje. Es fundamental mandar la hora, para que el microcontrolador esté en concordancia con el teléfono. A esta cabecera le sigue un dato, llamado comando, con el que se sabe de que tipo es el mensaje que se va a transmitir. A continuación se incluye la información asociada a dicho comando. (*) La paridad utilizada en este proyecto consiste en la suma de los dígitos que componen el mensaje para la comprobación de errores. 44
Comunicación Sistema de control Tarjeta de Interfaz El último carácter de cualquier mensaje del teléfono es un carácter z. En la Figura 17, se muestra el mensaje tipo del teléfono. 8bytes 1byte 0-32bytes 1-3bytes 1byte Cabecera Comando Contenido Paridad z Figura 17 Trama de un mensaje desde el móvil El mensaje que envía la tarjeta es muy parecido al del móvil. Cada mensaje comienza con la hora que venía en el mensaje mandado por el teléfono, siendo en este caso también la cabecera del mensaje. Igual que antes le sigue un comando, que ha de ser el mismo del mensaje que ha recibido. A continuación se le añade el comando de comprobación, es un número: 8 si el mensaje ha llegado correcto (ok) ó un 9 si el mensaje recibido por la tarjeta ha sido erróneo (error). Le sigue la información de repuesta asociada al comando. Y la paridad asociada a este mensaje de respuesta. 8bytes 1byte 1byte 0-4bytes 1-3bytes Cabecera Comando Comando de comprobación Contenido Paridad Figura 18 Trama de un mensaje desde la tarjeta de interfaz A continuación se presentan los distintos tipos de mensajes que el móvil puede intercambiar con la tarjeta y la respuesta de ésta: 4.1.1 Caso 0! Temperatura de referencia elegida por el usuario. El móvil envía una temperatura, consecuencia de que el usuario la ha introducido. Este mensaje provoca que la tarjeta deje de actuar en el modo en el que esté, y pase al estado manual, tomando como temperatura de referencia la que se le acaba de enviar. 45
Comunicación Sistema de control Tarjeta de Interfaz hora minutos segundos comando Temp. Temp. (decimales) paridad fin 1 0 3 0 4 0 0 2 5 0 0 1 0 5 z Figura 19 Trama de un mensaje Caso 0 La tarjeta actualiza su consigna de temperatura, temperatura de referencia, que controla en encendido y apagado de la calefacción. En este caso entra en modo manual dejando de utilizar como referencia el perfil de ese día. El mensaje de respuesta sería: hora minutos segundos comando ok paridad 1 0 3 0 4 0 0 8 8 8 Figura 20 Trama de un mensaje respuesta Caso 0 Si la paridad del mensaje recibido es errónea, la tarjeta envía el siguiente mensaje: hora minutos segundos comando ok paridad 1 0 3 0 4 0 0 9 8 9 Figura 21 Trama de un mensaje erróneo de respuesta Caso 0 4.1.2 Caso 1! Temperatura actual del habitáculo. El móvil está programado para que pregunte a la tarjeta la temperatura de la habitación, este mensaje se envía con una continuidad de 30 segundos, se ha escogido este intervalo por ser menor a un minuto. De esta forma refresca el valor que aparece por pantalla. hora minutos segundos comando paridad final 1 0 3 0 4 0 1 8 1 z Figura 22 Trama de un mensaje Caso 1 46
Comunicación Sistema de control Tarjeta de Interfaz La tarjeta lee la temperatura que el del habitáculo y responde con el siguiente mensaje, en el que se incluye dicha temperatura. hora minutos segundos comando ok temp Temp(decimales) paridad 1 0 3 0 4 0 1 8 2 0 0 0 1 0 9 Figura 23 Trama de un mensaje respuesta Caso 1 Si el mensaje recibido es erróneo, la tarjeta envía el siguiente mensaje: hora minutos segundos comando ok paridad 1 0 3 0 4 0 1 9 8 9 Figura 24 Trama de un mensaje erróneo de respuesta Caso 1 4.1.3 Caso 2! Envío del perfil del día siguiente. El móvil esta funcionando en su modo automático. Cuando comienza un nuevo día, se revisa si hay algún perfil asociado al día siguiente y de ser así se envía. Cuando comience el nuevo día, la tarjeta actualiza el valor del perfil para hoy. Existe una opción dentro de este caso y aparece cuando el usuario decide que hoy quiere cambiar de perfil aunque para hoy esté programado para que actúe otro. Una vez que ha pasado el día se restablece el modo automático y el perfil que se había enviado no se utiliza la próxima vez que llegue el mismo día. Esta opción cambia el comando 2 del mensaje por el 6. hora min. seg. c hr.1 min.1 temp.1 T1(dec.) temp.4 T4(dec.) paridad f 1 0 3 0 4 0 2 1 1 4 5 2 5 5 0 3 0 7 5 3 1 8 z Figura 25 Trama de un mensaje Caso 2 47
Comunicación Sistema de control Tarjeta de Interfaz El mensaje de respuesta que se envía tanto si el perfil que le llega a la tarjeta es del caso 2 o del caso 6 es el siguiente: hora minutos segundos comando ok paridad 1 0 3 0 4 0 2 8 9 0 Figura 26 Trama de un mensaje respuesta Caso 2 Si el mensaje recibido es erróneo, la tarjeta envía el siguiente mensaje: hora minutos segundos comando ok paridad 1 0 3 0 4 0 2 9 8 9 Figura 27 Trama de un mensaje erróneo de respuesta Caso 2 4.1.4 Caso 3! Orden directa: Encender la calefacción. El usuario introduce esta orden, haciendo que la tarjeta actué entonces en modo manual, encienda la calefacción con respecto a una temperatura por defecto de 25ºC. hora minutos segundos comando paridad final 1 0 3 0 4 0 3 8 3 z Figura 28 Trama de un mensaje Caso 3 La tarjeta no tiene que contestar nada, sólo confirmar que ha recibido correctamente el mensaje. hora minutos segundos comando ok paridad 1 0 3 0 4 0 3 8 9 1 Figura 29 Trama de un mensaje respuesta Caso 3 48
Comunicación Sistema de control Tarjeta de Interfaz Si el mensaje recibido es erróneo, la tarjeta envía el siguiente mensaje: hora minutos segundos comando ok paridad 1 0 3 0 4 0 3 9 8 9 Figura 30 Trama de un mensaje erróneo de respuesta Caso 3 4.1.5 Caso 4! Orden directa: Apagar la calefacción. Igual que la anterior, en este caso la calefacción se apaga. hora minutos segundos comando paridad final 1 0 3 0 4 0 4 8 4 z Figura 31 Trama de un mensaje Caso 4 El mensaje de respuesta sería: hora minutos segundos comando ok paridad 1 0 3 0 4 0 4 8 9 2 Figura 32 Trama de un mensaje respuesta Caso 4 Si el mensaje recibido es erróneo, la tarjeta envía el siguiente mensaje: hora minutos segundos comando ok paridad 1 0 3 0 4 0 4 9 8 9 Figura 33 Trama de un mensaje erróneo de respuesta Caso 4 49
Comunicación Sistema de control Tarjeta de Interfaz 4.1.6 Caso 5! Saber cual es el estado de la caldera: On/Off Este mensaje es del mismo tipo que el del caso 1, el estado de la caldera Encendida o Apagada que se muestra en la pantalla de inicio, es un dato que se refresca cada 30 segundos. El mensaje enviado por el teléfono es: hora minutos segundos comando paridad final 1 0 3 0 4 0 5 8 5 z Figura 34 Trama de un mensaje Caso 5 Este mensaje de repuesta junto con el del caso 1 son los únicos que tienen contenido, en este caso es enviar el estado en el que se encuentra la caldera. Un 3 si está encendida o un 4 si está apagada. hora minutos segundos comando ok contenido paridad 1 0 3 0 4 0 5 8 3 9 6 Figura 35 Trama de un mensaje respuesta Caso 5 Si el mensaje recibido es erróneo, la tarjeta envía el siguiente mensaje: hora minutos segundos comando ok paridad 1 0 3 0 4 0 5 9 8 9 Figura 36 Trama de un mensaje erróneo de respuesta Caso 5 4.2 Pruebas Una vez que se han probado la parte del teléfono móvil y la tarjeta por separado, (ya que de esta forma es más fácil detectar el fallo que si se ejecuta todo al mismo tiempo). Se realizan las pruebas de las comunicaciones vía bluetooth que primero se hicieron con dos emuladores. Para esto se necesitó la ayuda de la herramienta Nokia Connectivity Framework Lite, integrada en el 50
Comunicación Sistema de control Tarjeta de Interfaz Jbuilder. Esta herramienta permite habilitar el envío de SMS, MMS y uso del Bluetooth entre emuladores. Una vez depurado y comprobado el buen funcionamiento del programa en el emulador, se instaló en el móvil real, el NOKIA 6600, entre otros permite la ejecución de aplicaciones en java que usen APIs J2ME y en el entorno de trabajo CLDC/MIDP de la versión 1.0. El teléfono sólo usa esta versión, por eso es muy importante que se configure manualmente en el nombredelaaplicación.jad del.java que se haya creado. 51
Capítulo 5 Resultados y pruebas
Resultados 5.1 Resultados Los resultados obtenidos en el desarrollo del proyecto han sido los siguientes: Software del teléfono móvil: desarrollo del programa completo que se ejecuta en el teléfono y realiza el control de todo el sistema. Desarrollo de la tarjeta de interfaz. Firmware del microcontrolador. Tarjeta periférica que se conecta a la placa MICRO Pic Trainer: Montaje del hardware necesario (reloj, sensor, ) para completar las funciones de la tarjeta. Programa en C para el PC para enviar y recibir mensajes tanto del teléfono como del microcontrolador y comprobar su funcionamiento por separado. 5.2 Pruebas En la parte del teléfono móvil: Comprobación del programa del teléfono sobre el teléfono móvil real Nokia 6600. Comprobación del funcionamiento del programa de comunicación Bluetooth con los emuladores. Pruebas de las comunicaciones con el teléfono móvil NOKIA 6600 y un programa de comunicaciones en C. En la parte de la tarjeta de interfaz: Montaje y funcionamiento de la tarjeta de interfaz. Comprobación comunicación de la tarjeta con el PC, tanto con el hyperterminal como con el programa en C, realizado para su efecto, esto es para enviar y recibir mensajes. No se ha logrado realizar la prueba entre la tarjeta y el teléfono móvil. En la siguiente Figura 37, se puede ver la configuración utilizada para las pruebas: 53
Resultados Programa en C Figura 37 Montaje del proyecto en simulación 54
Capítulo 6 Conclusiones y futuros desarrollos
Conclusiones 6.1 Conclusiones El desarrollo realizado demuestra que es posible implantar un sistema de cronotermostato. Este sistema permite programar la calefacción a través de una interfaz con el usuario. Es un circuito sencillo pero los costes que genera son altos. Estos costes están relacionados con la parte Bluetooth ya que el adaptador necesario es caro. Dos soluciones a este problema podrían ser: Utilizar los módulos de la misma empresa que comercializa el adaptador Bluetooth-RS232. Estos módulos están diseñados para poder integrar en cualquier aplicación la posibilidad de comunicarse vía Bluetooth y además utilizando el protocolo SPP. La otra opción sería establecer una comunicación USB. 6.2. Futuros desarrollos Integrar todo y refinar el diseño: Llegar a acoplar las dos partes y comprobar que se comunican. Una vez hecho esto, optimizar el código. Gestión remota mediante SMS. La información que se transmite por SMS sería la misma que la de un usuario cuando la introduce directamente sobre el teléfono del proyecto: perfiles, temperatura, apagar directamente la caldera. Darle a esta aplicación una mayor funcionalidad, añadiendo el control de otro tipo de dispositivos, tales como las alarmas antihumos o antirobo. 56
Capítulo 7 Bibliografía
Bibliografía [MABMO02] Qusay H. Mabmoud: Learning Wíreles Java O REILLY 2002. [ARNO01] David M. Arnow, Gerald Weiss: traducción, Diego Sevilla Ruiz: Introducción a la programación con JAVA: un enfoque orientado a objetos Addison Wesley 2001. [MICRO03] PIC16F87XA Data Sheet (DS39582B). Microchip 2003. http://www.microchipc.com/pic16bootload/pic_bootloader_faq.htm [NATIO94] National Semiconductor. LM35 Precision Centigrade Temperature Sensors. http://www.national.com/pf/lm/lm35.html [FREE206] Información sobre el Bluetooth serial port plug (Adaptador F2M01). De Free2Move. www.free2move.se [ORTIZ05] C. Enrique Ortiz, Febrero del 2005. http://developers.sun.com/techtopics/mobility/apis/articles/bluetoothcore/author# author 58
Parte II PLIEGO DE CONDICIONES
Pliego de Condiciones 1 Condiciones Generales Las condiciones y cláusulas que se establecen en este documento son de obligado cumplimiento por las partes contratantes. I. Tanto el administrador como el cliente se comprometen desde la fecha de la firma del contrato a llevar a cabo lo que se estipule. II. Ante cualquier reclamación o discrepancia en lo concerniente al cumplimiento de lo pactado por cualquiera de las partes, una vez agotada toda vía de entendimiento, se tramitará el asunto por la vía de lo legal. El dictamen o sentencia que se dicte será de obligado cumplimiento para las dos partes. III. Al firmarse el contrato, el suministrador se compromete a facilitar toda la información necesaria para la instalación y buen funcionamiento del sistema, siempre que sea requerido para ello. IV. Asimismo, el cliente entregará al suministrador todas las características distintivas del equipo comprado y aquellas otras que considere oportunas para el necesario conocimiento de la misma a efectos del diseño del presente equipo. V. El plazo de entrega será de tres meses, a partir de la fecha de la firma del contrato, pudiendo ampliarse en un mes. Cualquier modificación de los plazos deberá contar con el acuerdo de las dos partes. VI. En caso de retrasos imputables al suministrador, se considerará una indemnización del 1 % del valor estipulado por semana de retraso. VII. Existirá un plazo de garantía de un año a partir de la entrega del sistema. Dicha garantía quedará sin efecto si se demostrase que el sistema ha estado sometido a manipulación o uso indebido. VIII. Cumplido dicho plazo de garantía, el suministrador queda obligado a la reparación del sistema durante un plazo de cinco años, fuera del cual quedará a su propio criterio atender la petición del cliente. 60
Pliego de Condiciones IX. En ningún momento tendrá el suministrador obligación alguna frente a desperfectos o averías por uso indebido por personas no autorizadas por el suministrador. 2 Condiciones económicas. I. Los precios indicados en este proyecto son firmes y sin revisión por ningún concepto, siempre y cuando se acepten dentro del periodo de validez del presupuesto que se fija hasta Diciembre de 2001. II. El pago se realizará como sigue: h 75% a la firma del contrato. h 25% en el momento de entrega. III. La forma de pago será al contado mediante cheque nominativo o mediante transferencia bancaria. En ningún caso se aceptarán letras de cambio. IV. El suministrador se hará cargo de los gastos de embalaje y del transporte, dentro de la ciudad donde se encuentre la instalación. En caso de ser necesario transporte interurbano, el gasto correrá por cuenta del cliente. En todo caso, el responsable de los posibles desperfectos ocasionados por el transporte será el suministrador. V. Durante el plazo de garantía, la totalidad de los gastos originados por las reparaciones correrán por cuenta del suministrador. VI. Fuera de dicho plazo y durante los siguientes cinco años, los costes serán fijados mediante acuerdo por ambas partes. Pasados 5 años, éstos los fijará exclusivamente el suministrador. 61
Parte III PRESUPUESTO
Presupuesto En este capítulo se desglosan los costes en los que hubiera incurrido una empresa en el caso de haber acometido el proyecto desde cero. Desglose de costes: Componente, herramientas y dispositivos Cantidad uros Construcción de la tarjeta de interfaz: Placa MICRI Pic Trainer 120 Fuente de alimentación conmutada 1 30 Componentes plaquita auxiliar: Condensadores 1 µ F 4 0.24 Condensadores 10 pf 1 0.06 Condensadores 39 pf 1 0.06 Conector DB9 macho 1 0.90 Contador binario 14 bits HCF4060 1 0.20 Cristal de cuarzo 32.768 KHz 1 0.30 Max232 1 0.80 Potenciómetro 10 K Ω 1 0.10 Resistencia 330 K Ω 1 0.05 Resistencia 1 M Ω 1 0.05 Resistencia 220 K Ω 1 0.05 Resistencia 5.5 M Ω 1 0.05 Sensor de temperatura LM335 1 0.50 Teléfono móvil: Nokia 6600 180 Adaptador Bluetooth-Puerto Serie 190 Sueldo Ingeniero 700 horas 7297 Consumo eléctrico 25 Ordenador Intel Pentium 4 1020 Licencias de software Gratuitas Total: 7846 63
Anexo A Código para manejar el RecordStore
Anexo A: Código para manejar el Recordstore 1 La clase RecordStore La clase RecordStore del paquete java.microedition.rms tiene métodos con los que se puede crear un RecordStore, está implementada sobre una base de datos basada en registros llamada Record Management System (RMS), que consiste en un zona de memoria que reserva el teléfono para este propósito. La cantidad de memoria y la zona asignada dependerá de cada teléfono. Entre los métodos que contiene esta clase, se encuentran: Entre las propiedades que se pueden destacar de los RecorStore: 1 Cada Record Store está compuesto por cero o más registros. 2 Un nombre de Record Store es sensible a mayúsculas y minúsculas y está formado por un máximo de 32 caracteres UNICODE. 3 Dentro de un MIDlet no pueden coexistir dos RecordStores con el mismo nombre. Cada uno de los registros que forman parte del RecordStore están formados por dos unidades: o Un número identificador de registro (Record ID) que es un valor entero que realiza la función de clave primaria en la base de datos. o Un array de bytes que es utilizado para almacenar la información deseada. Un Record Store tal como su nombre indica es un almacén de registros. Estos registros son la unidad básica de información que utiliza la clase RecordStore para almacenar datos. En la Figura 38 se muestran métodos de la clase RecordStore: MÉTODOS String getname(). int getversion() int getsize() int getsizeavailable() String[] listrecordstores() void deleterecordstore(string name) DESCRIPCIÓN Devuelve el nombre del Record Store. Devuelve la versión del Record Store. Devuelve el número de bytes ocupado por el Record Store. Devuelve el tamaño disponible para añadir registros. Devuelve una lista con los nombres de los Record Stores que existen en la MIDlet suite. Elimina del dispositivo al Record Store especificado por el parámetro name. 65
Anexo A: Código para manejar el Recordstore void addrecordlistener (RecordListener listener) void removerecordlistener (RecordListener listener) Añade un listener para detectar cambios en el Record Store. Elimina un listener. Figura 38 Métodos de la clase RecordStore En la Figura 39, se muestran los métodos para manejar los registros que constituyen el RecordStore: MÉTODOS int addrecord(byte[] datos, int offset, int numbytes) DESCRIPCIÓN Añade un registro al Record Store void deleterecord(int id) Int getnextrecordid() Borra el registro id del Record Store Devuelve el siguiente id del registro que se vaya a insertar byte[] getrecord(int id) int getrecord(int id, byte[] buffer, int offset) Int getrecordsize(int id) void setrecord(int id, byte[] datonuevo, int offset, int tamaño) Devuelve el registro con identificador id Devuelve el registro con identificador id en buffer a partir de offset Devuelve el tamaño del registro id Sustituye el registro id con el valor de datonuevo Figura 39 Métodos para manejar los registros en un RecordStore 2 Código de las funciones para la gestión de perfiles En este proyecto para el desarrollo de la gestión de perfiles se han utilizado los siguientes métodos y de la forma que se muestra a continuación: 66
Anexo A: Código para manejar el Recordstore 2.1 Crear un perfil: byte[] reg; ByteArrayOutputStream baos; DataOutputStream dos; String nombreperfil; try { baos = new ByteArrayOutputStream(); dos = new DataOutputStream(baos); dos.writeutf(nombreperfil); //Escribo dato de tipo string... dos.writelong(hora1); //Escribo un dato de tipo long... dos.flush(); reg = baos.tobytearray(); rms.addrecord(reg, 0, reg.length); baos.close(); dos.close(); }catch (Exception e) { //"Error al escribir en el RMS" } 2.2 Editar perfil: Se realiza con el código anterior cambiando la instrucción rms.addrecord(reg, 0, reg.length), por esta otra, rms.setrecord(id, reg, 0, reg.length), la única diferencia con la anterior es que en esta se sobrescribe el registro de número id. Todos los registros cuando se escriben por primera vez en el RecordStore se les asocia un id o número identificador. Este número empieza por 1. 2.3 Eliminar perfil: Para realizar la eliminación de un perfil o de todos, el RecordStore ha de estar cerrado previamente. La eliminación de un único perfil se hace con la instrucción rms.deleterecord(id); donde id es el identificador del registro a eliminar. Para eliminar todos los perfiles de una vez, eliminandose también el RecordStore se utiliza RecordStore.deleteRecordStore(nombreRMS), teniendo que pasarle como argumento el nombre del Record Store. 67
Anexo A: Código para manejar el Recordstore 2.4 Ver perfiles: Para poder mostrar datos de la memoria, previamente hay que leerlos de la misma, esto se puede hacer de la siguiente manera: byte[] reg = new byte[75]; ByteArrayInputStream bais; DataInputStream dis; try { bais = new ByteArrayInputStream(reg); dis = new DataInputStream(bais); for (int i = 1; i <= rms.getnumrecords()total; i++) { //Captura el registro numero id rms.getrecord(i,reg,0); bais.reset(); } bais.close(); dis.close(); }catch (Exception e) { //"Error al leer el registro" } Cuando se captura el registro, sus datos se pueden leer con la instrucción String nombreperfil = dis.readutf(); si los datos son strings o long hora1 = dis.readlong(); si son long. 2.5 Nota importante: Todas las funciones que impliquen manejar internamente el RecordStore, como escribir, leer,, éste ha de estar previamente abierto y cuando se vaya a salir del la aplicación, hay que cerrarlo tantas veces como se haya abierto: RecordStore rms; // Definición del RecordStore // Instrucción que lo abre o lo crea si es la primera vez. rms = RecordStore.openRecordStore(nombreRMS, true); // Instrucción que lo cierra rms.closerecordstore(); 68
Anexo B Características del hardware de la tarjeta de interfaz
Anexo B: Características del microcontrolador Pic 16F873A 1 Microcontrolador 16F873A Las características que destacan la elección y uso de este microcontrolador, el 16F873A, son: Tamaño de la memoria EEPROM, comunicación USART, interrupciones, comparadores. Más en detalle, éstas y otras características extraídas del data- sheet de este microcontrolador, se ven en la Figura 40. Figura 40 Características del dispositivo PIC16F873A 70
Anexo B: Características del microcontrolador Pic 16F873A 2 Sensor de temperatura LM35 Características a destacar: - Calibrated directly in Celsius (Centigrade). - Linear + 10.0 mv/ C scale factor. - Rated for full 55 to +150 C range. - Suitable for remote applications. - Less than 60 µa current drain. - Característica temperatura - tensión de salida, se presenta en la Figura 41. Figura 41 Característica temperatura/tensión de salida. LM35 71
Anexo C Funcionamiento de la técnología Bluetooth
Anexo C: CÓDIGO DE LA TECNOLOGÍA BLUETOOTH 1 Tecnología Bluetooth: Introducción Bluetooth es un estándar de facto global que identifica un conjunto de protocolos que facilitan la comunicación inalámbrica entre diferentes tipos de dispositivos electrónicos. Su nombre viene del rey vikingo, Harald Bluetooth (940 A.D.-981A.D.), famoso por su habilidad para la comunicación, y para hacer que la gente hablara entre ella. Bluetooth es una tecnología de radio de corto alcance, que permite conectividad inalámbrica entre dispositivos remotos. Se diseñó pensando básicamente en tres objetivos, que fuera de pequeño tamaño, tuviera un mínimo consumo y ofreciera un bajo precio. Mientras que el hardware Bluetooth había avanzado mucho, hasta hace relativamente poco no había manera de desarrollar aplicaciones java Bluetooth, hasta que apareció JSR 82, que estandarizó la forma de desarrollar aplicaciones Bluetooth usando Java. Ésta esconde la complejidad del protocolo Bluetooth detrás de unos APIs que permiten centrarse en el desarrollo en vez de los detalles de bajo nivel del Bluetooth. Estos APIs para Bluetooth están orientados para dispositivos que cumplan las siguientes características: Al menos 512K de memoria libre (ROM y RAM) (las aplicaciones necesitan memoria adicional). Conectividad a la red inalámbrica Bluetooth. Que tengan una implementación del J2ME CLDC. El teléfono utilizado, Nokia 6600, utiliza su versión 1.0. El objetivo de la especificación JSR 82 era definir un API estándar abierto, no propietario que pudiera ser usado en todos los dispositivos que implementen J2ME. Por consiguiente fue diseñado usando los APIs J2ME y el entorno de trabajo CLDC/MIDP. Los APIs JSR 82 son muy flexibles, ya que permiten trabajar tanto con aplicaciones nativas Bluetooth como con aplicaciones Java Bluetooth. 73
Anexo C: CÓDIGO DE LA TECNOLOGÍA BLUETOOTH Toda la información y gráficos que aparecen a continuación se han extraído de la página web: http://developers.sun.com/techtopics/mobility/apis/articles/bluetoothcore/ author#author 2 Software de la tecnología Bluetooth El desarrollo de esta tecnología aplicada a este dispositivo se ha conseguido con la ayuda de manuales que muestran el código necesario para llevarla a cabo. Sin embargo a la hora de ejecutarlo se tuvieron que realizar cambios y modificaciones que se mostraran más adelante. En toda comunicación Bluetooth siempre han de coexistir dos usuarios desempeñando y funcionando en dos modos diferentes: El cliente El servidor Un mismo usuario puede tener habilidad para ejercer ambos modos, pero claro está, no al mismo tiempo. A continuación se muestra como se debe desarrollar y se ha desarrollado la aplicación bluetooth. Cualquier aplicación bluetooth ha de tener las dos etapas siguientes que se presentan en la Figura 42. 74
Anexo C: CÓDIGO DE LA TECNOLOGÍA BLUETOOTH Figura 42 Etapas de toda aplicación Bluetooth Una primera inicialización de la Bluetooth stack, tanto si opera en modo cliente o servidor. A continuación una definición del modo/papel que va a desempeñar el dispositivo en la comunicación: - El modo cliente que se encarga de utilizar servicios. En primer lugar descubre los dispositivos que se encuentran próximos a él y que son visibles, después con cada uno de los dispositivos descubiertos busca los servicios que son de su interés. - El modo servidor tiene la labor de hacer que los servicios que ofrece sean válidos para los clientes. Los servicios los tiene que registrar en el Service Discovery Database (SDDB) y así pueden ser advertidos por los clientes. A continuación se queda esperando a que se produzca alguna conexión por parte de algún cliente próximo, la acepta y sirve a dicho cliente. Cuando el servicio ya no se necesite más hay que quitarlo de la SDDB. En la Figura 43 se presenta un resumen gráfico de lo comentado anteriormente. Se muestra como funcionan un servidor y un cliente, junto con los métodos e interfaces que utilizan para llevarlo a cabo. 75
Anexo C: CÓDIGO DE LA TECNOLOGÍA BLUETOOTH Figura 43 Actividades de un servidor y un cliente 2.1 INICIALIZACIÓN En primer lugar hay que capturar una referencia al Bluetooth Manager mediante la inicialización de una variable del tipo LocalDevice. También es necesario capturar una referencia a DiscoveryAgent, para que si la aplicación es servidora pueda hacer de sí misma un dispositivo que puede ser descubierto. En el caso que la aplicación actuase en el modo cliente podrá más adelante descubrir los dispositivos y sus servicios disponibles.... private LocalDevice localdevice; private DiscoveryAgent discoveryagent; // local Bluetooth Manager // descubrirá servicios localdevice = LocalDevice.getLocalDevice(); //captura de sí mismo // como dispositivo 76
Anexo C: CÓDIGO DE LA TECNOLOGÍA BLUETOOTH // La siguiente línea es sólo para los servidores, establecen el // método setdiscoverable a GIAC para poder hacerse visibles. localdevice.setdiscoverable(discoveryagent.giac); // La siguiente línea es sólo para los clientes establecen el método //getdiscoveryagent, porque más tarde se encargarán de buscar // los dispositivos y servicios. discoveryagent = localdevice.getdiscoveryagent();... En la Figura 44 se muestra como se lleva acabo la inicialización. Figura 44 Inicialización de la aplicación Bluetooth Cuando el servidor se hace visible con el método setdiscoverable, hay que especificarle el código de acceso de información, the inquiry access code (IAC). Java (JSBWT), soporta dos modos de acceso: DiscoveryAgent.LIAC (Limited Inquiry Access Code): El dispositivo solo será visible un periodo de tiempo limitado y a continuación se vuelve invisible. El otro modo, el que se ha utilizado, es el DiscoveryAgent.GIAC (General Inquiry Access Code), por ser el modo más común y para que el dispositivo desarrollado se encuentre visible siempre. El protocolo que se ha utilizado para establecer las conexiones entre el conector y el móvil ha sido el Serial Port Profile (SSP) RFCOMM. 77
Anexo C: CÓDIGO DE LA TECNOLOGÍA BLUETOOTH Una conexión Bluetooth, se puede crear utilizando el método open() de la interfaz javax.microedition.io.connector. El argumento de esta función es la URL de conexión en la que va incluido el tipo de conexión que se va a realizar. El formato de la URL es el siguiente: btspp://hostname:[cn UUID];parameters Donde: - Btspp: es el encabezado de la URL de una StreamConnection RFCOMM. - Hostname: Es necesario para saber si se está creando una connexion cliente o servidora. Un cliente sustituye esa palabra por la dirección Bluetooth, mientras que un servidor la sustituye por la palabra localhost. - CN: Es el valor del canal numérico, es usado por un cliente cuando se conecta a un servidor. (Un Puerto TCP/IP es un concepto similar a esto). - UUID (Universally Unique Identifier): El Identificador único universal es usado por un servidor cuando establece un servicio. Cada UUID ha de garantizar que sea único en el tiempo y en el espacio. - Parameters: Diferentes nombres que describen el tipo de seguridad que tiene la connexion. En un cliente los parámetros en este orden, serían los siguientes: master, encrypt, authenticate. Y en un servidor: name, master, encrypt, authorize, authenticate. Las URL utilizadas en la comunicación en el momento de probar las comunicaciones entre el teléfono móvil y el programa en C del PC son:!la URL de nuestro dispositivo cuando actua como servidor RFCOMM en la comunicación: btspp://localhost:2d26618601fb47c28d9f10b8ec891363; name=movil;master=false;encrypt=false;authorize= false;authenticate=false;! La URL de nuestro dispositivo cuando se encuentra en la comunicación en modo cliente RFCOMM: btspp://001060a20c62:1;master=false;encrypt=false; authenticate=false 78
Anexo C: CÓDIGO DE LA TECNOLOGÍA BLUETOOTH Durante la realización de las pruebas de la comunicación del adaptador Bluetooth-RS232 y el móvil se ha obtenido su dirección Bluetooth, es:001060a20c62. 2.2 Modo SERVIDOR La Figura 45 se muestra un esquema de una aplicación Servidor. Figura 45 Implantación del modo servidor La forma de establecer el modo servidor para poder crear servicios para que sean consumidos por los clientes, es la siguiente: Lo primero es crear un Service Record, para hacer disponible el servicio que se va a ofrecer. Para esto hay que crear un connection notifier, el StreamConnectionNotifier. Todos los servicios y su atributo tienen su propio Identificador Único Universal. No se puede crear ningún servicio si primero no se le ha asignado un UUID. Las siguientes líneas definen e instancian una conexión notifier RFCOMM, creando el Service Record necesario.... StreamConnectionNotifier scn; // Inicialización // Se define un String de la URL de connexion: String connurl = "btspp://localhost:2d26618601fb47c28d9f10b8ec891363;name=movil" 79
Anexo C: CÓDIGO DE LA TECNOLOGÍA BLUETOOTH // Crear la una conexion servidora, con esto se crea un // Notifier y un Service Record scn = (StreamConnectionNotifier) Connector.open(connURL);... Lo siguiente es añadir este nuevo servicio creado a la base de servicios descubiertos (Service Discovery Database, SDD). Esto se hace con el método acceptandopen (), que además de insertar el servicio en el SDDB, se hace visible a los clientes. StreamConnection sc = scn.acceptandopen(); Automáticamente, este método se bloquea, esperando conexiones entrantes procedentes de los clientes. Estas conexiones serán aceptadas según vayan llegando. Puesto que este método supone un bloqueo debe ser realizado por su propio hilo, lo que en java se conoce como un thread de ejecución, sino la aplicación se puede quedar bloqueada permanentemente (en un punto muerto). Cuando el cliente se conecta, el método anterior devuelve un StreamConnection (una conexión), que representa el punto final del cliente desde el cual el servidor leerá la información. // Aceptar la conexión con un nuevo cliente. RemoteDevice rd = RemoteDevice.getRemoteDevice(sc); // Leer el mensaje entrante. DataInputStream datain = sc.opendatainputstream(); String s = datain.readutf(); // s es el mensaje que el // cliente le transmite al servidor.... Cuando el servicio ya no se necesita más, hay que quitarlo del SDDB mediante el cierre de conexión notifier. streamconnectionnotifier.close(); 80
Anexo C: CÓDIGO DE LA TECNOLOGÍA BLUETOOTH 2.3 Modo CLIENTE La Figura 46 se muestra un esquema de una aplicación Cliente. Figura 46 Implantación del modo cliente Como se ha comentado anteriormente un cliente consume servicios, esto solo lo puede hacer si los ha encontrado previamente. Por esto cualquier cliente primero busca los dispositivos que se encuentren más cercanos y a continuación su servicio asociado. El descubrimiento de dispositivos supone un gran consumo de batería y tiempo. Para evitar esto, el cliente puede comprobar si los dispositivos que anteriormente han sido buscados y por tanto son conocidos proveen el servicio que dicho cliente está preguntando. La clase DiscoveryAgent se encarga de la tarea de descubrir, con la que el cliente inicia y cancela el descubrimiento tanto de dispositivos como de 81
Anexo C: CÓDIGO DE LA TECNOLOGÍA BLUETOOTH servicios. A través de la interfaz DiscoveryListener es como la aplicación del cliente se da cuenta que se ha producido dicho descubrimiento. La Figura 47 muestra la relación existente entre la aplicación del cliente, el DiscoveryAgent, y el DiscoveryListener. Figura 47 DiscoveryAgent y DiscoveryListener Hay que tener en cuenta que en la realización de la aplicación cliente, el móvil ya tiene guardado el nombre del adaptador Bluetooth-RS232, que sólo una vez, la primera ha tenido que buscar y que por tanto ahora ya es conocido. La captura de los dispositivos conocidos o no, se hace con el siguiente método del DiscoveryAgent: RemoteDevice[] retrievedevices(int option); Este método te devuelve la lista de estos dispositivos conocidos previamente, (en este caso solo existe uno). El argumento opción hace que cambie el tipo de dispositivo devuelto por el método: Si option = CACHED, devuelve dispositivos previamente encontrados, cuando se acaba de inicializar una nueva búsqueda de dispositivos. Si option = PREKNOWN, si tiene que devolver dispositivos que ya se conocen. Es ahora cuando comienza el descubrimiento continuado, llamando al método: boolean startinquiry(int accesscode, DiscoveryListener listener); Donde: 82