BLUELIGHT

SISTEMA PARA EL CONTROL DE LA INTENSIDAD

DE LUZ DE LÁMPARAS INCANDESCENTES POR
MEDIO DE BLUETOOTH

LEANDRO FLÓREZ ARISTIZÁBAL

2009
 BLUELIGHT
SISTEMA PARA EL CONTROL DE LA INTENSIDAD DE LUZ DE LÁMPARAS
INCANDESCENTES POR MEDIO DE BLUETOOTH

LEANDRO FLÓREZ ARISTIZÁBAL

COD. 1071118

INSTITUCIÓN UNIVERSITARIA ANTONIO JOSÉ CAMACHO

FACULTAD DE INGENIERÍAS
TECNOLOGÍA EN SISTEMAS
SANTIAGO DE CALI, JULIO DE 2009

2
 BLUELIGHT
SISTEMA PARA EL CONTROL DE LA INTENSIDAD DE LUZ DE LÁMPARAS
INCANDESCENTES POR MEDIO DE BLUETOOTH

LEANDRO FLÓREZ ARISTIZÁBAL

COD. 1071118

DIRECTOR
ALEXIS ALBERTO RAMÍREZ OROZCO
Ms@. En ingeniería con énfasis en Electrónica

Proyecto de grado presentado para

optar al título de tecnólogo en
sistemas

INSTITUCIÓN UNIVERSITARIA ANTONIO JOSÉ CAMACHO

FACULTAD DE INGENIERÍAS
TECNOLOGÍA EN SISTEMAS
SANTIAGO DE CALI, JULIO DE 2009

3
 Nota de aceptación

_____________________________________
_____________________________________________
_____________________________________________
_____________________________________________
_____________________________________________

______________________________
Firma del director

______________________________
Firma del jurado

______________________________
Firma del jurado

Santiago de Cali, 28 de Julio de 2009

4
 AGRADECIMIENTOS

A mis padres, quienes con su apoyo y amor han hecho de mí, una persona con
valores, determinada y exitosa. Deseo agradecer en especial a mi madre, quien
con sus consejos, me ha ayudado a tomar las mejores decisiones en mi vida.

A Dios, por las oportunidades que me ha brindado de salir adelante, por hacerme
parte de una familia maravillosa y permitirme conocer personas grandiosas en
esta aventura llamada VIDA, personas como Alexis Ramírez, quien no solo es mi
director de proyecto, sino también mi amigo.

5
 CONTENIDO

INTRODUCCIÓN ...................................................................................................................... 12

1. DOMÓTICA...................................................................................................................... 14

1.1 Domótica con control independiente ................................................................................ 15

1.2 Domótica con control centralizado ................................................................................... 15

1.3 Domótica con control distribuido en red ........................................................................... 15

2. TECNOLOGÍA BLUETOOTH................................................................................................ 17

2.1 Forma de operación......................................................................................................... 18

2.2 Seguridad........................................................................................................................ 19

2.2.1 BlueJacking. ......................................................................................................... 20

2.2.2 BlueSnarfing......................................................................................................... 21

2.2.3 BlueBugging. ........................................................................................................ 21

2.2.4 BlueTiming o Toothing. ......................................................................................... 22

2.3 PILA DE PROTOCOLOS BLUETOOTH................................................................................... 22

2.3.1 Radio. .................................................................................................................. 25

2.3.2 Banda Base. ......................................................................................................... 25

2.3.3 Link Manager Protocol (LMP) o Protocolo de Gestión de Enlace. ............................. 28

2.3.4 Host Controller Interface (HCI) o Interfaz del Controlador de Enlace. ....................... 28

2.3.5 Logical Link Control and Adaptation Protocol (L2CAP). ............................................ 28

2.3.6 Sevice Discovery Protocol (SDP) o Protocolo de Descubrimiento de Servicio. ........... 29

2.3.7 Protocolo RFCOMM (Radio Frequency Communication).......................................... 30

2.4 PERFILES BLUETOOTH ...................................................................................................... 32

2.4.1 Perfil Genérico de Acceso (GAP). ........................................................................... 34

2.4.2 Perfil de Puerto Serial (SPP). .................................................................................. 34

6
 2.4.3 Perfil Genérico de Intercambio de Objetos (GOEP). ................................................ 34

2.4.4 Perfil de Aplicación de Descubrimiento de Servicio (SDAP). ..................................... 34

2.5 PROCESO DE CONEXIÓN................................................................................................... 35

2.5.1 Proceso de Búsqueda............................................................................................ 35

2.5.2 Búsqueda de servicios. .......................................................................................... 35

2.6 CARACTERÍSTICAS............................................................................................................ 40

2.6.1 Composición de las especificaciones. ..................................................................... 40

2.6.2 Espectro............................................................................................................... 41

2.6.3 Interferencias....................................................................................................... 41

2.6.4 Alcance. ............................................................................................................... 41

2.6.5 Potencia............................................................................................................... 42

3. TELÉFONO CELULAR......................................................................................................... 43

3.1 CÓMO FUNCIONAN LOS TELÉFONOS CELULARES ............................................................... 43

3.2 DIFERENCIAS ENTRE LOS TELÉFONOS CELULARES Y LOS RADIOS DE BANDA CIVIL ................ 45

3.2.1 Simplex Vs. Dúplex................................................................................................ 46

3.2.2 Canales. ............................................................................................................... 46

3.2.3 Rango. ................................................................................................................. 46

3.3 SOFTWARE PARA DISPOSITIVOS MÓVILES ......................................................................... 47

4. JAVA ............................................................................................................................... 48

4.1 J2ME............................................................................................................................... 51

4.1.1 Configuraciones.................................................................................................... 53

4.1.2 Perfiles................................................................................................................. 54

4.1.3 Paquetes opcionales. ............................................................................................ 54

4.1.4 APIs Java para Bluetooth (JSR-82 / JABWT)............................................................. 55

7
5. MICROCONTROLADORES ................................................................................................. 63

5.1 Recursos comunes a todos los microcontroladores. ........................................................... 64

5.1.1 Arquitectura básica............................................................................................... 64

6. DISEÑO E IMPLEMENTACIÒN............................................................................................ 67

6.1 METODOLOGÍA DE DESARROLLO ...................................................................................... 67

6.2 SOFTWARE BLUELIGHT..................................................................................................... 68

6.3 HARDWARE..................................................................................................................... 90

6.3.1 PIC16F876A.......................................................................................................... 91

6.3.2 Módulo Bluetooth BlueSMIRF Silver V2. ................................................................. 92

6.3.3 Detector de Cruce x cero. ...................................................................................... 93

6.3.4 Etapa de potencia. ................................................................................................ 94

6.3.5 Descripción del software del microcontrolador. ..................................................... 94

6.4 PRUEBAS Y AJUSTES....................................................................................................... 105

RESULTADOS FINALES ........................................................................................................... 107

CONCLUSIONES .................................................................................................................... 108

BIBLIOGRAFÍA ....................................................................................................................... 110

8
 LISTA DE FIGURAS

Figura 1. Casa Domótica .......................................................................................................... 14

Figura 2. Logo Bluetooth ......................................................................................................... 17

Figura 2.1 Pila de protocolos Bluetooth .................................................................................... 23

Figura 2.2 Piconets y Scatternets ............................................................................................. 26

Figura 2.3 Perfiles Bluetooth.................................................................................................... 33

Figura 2.4 Establecimiento de una conexión ............................................................................. 36

Figura 2.5 Service Discovery DataBase...................................................................................... 37

Figura 3. Red de Celdas de telefonía Celular ............................................................................. 44

Figura 4. Celular vs. Radio........................................................................................................ 46

Figura 5. Arquitectura de la plataforma Java 2 de SUN .............................................................. 50

Figura 6. Relación entre las APIs de la plataforma Java .............................................................. 52

Figura 6.1 Relación entre CDC y CLDC....................................................................................... 54

Figura 7. Caso de uso específico de una aplicación Bluetooth .................................................... 61

Figura 8. Elementos que componen típicamente un MIDlet Bluetooth. ...................................... 62

Figura 9. Microcontrolador...................................................................................................... 64

Figura 9.1 Arquitectura HARVARD............................................................................................ 65

Figura 10. Diagrama de bloques del sistema BLUELIGHT............................................................ 67

Figura 10.1 Diagrama de bloques del software Bluelight V2.0 .................................................... 68

Figura 10.1.1 Clase BTMidlet ................................................................................................... 69

Figura 10.1.2 Clase HiloConexion ............................................................................................. 70

Figura 10.1.3 Clase Registro..................................................................................................... 71

Figura 10.1.4 Clase LocalDevice ............................................................................................... 72

Figura 10.1.5 Clase DiscoveryAgent e interfaz DiscoveryListener................................................ 76

9
Figura 10.1.6 Clase RemoteDevice ........................................................................................... 77

Figura 10.1.7 Diagrama de clases del software Bluelight............................................................ 79

Figura 10.1.8 Pantalla de bienvenida........................................................................................ 79

Figura 10.1.9 Formulario de ingreso ......................................................................................... 80

Figura 10.1.10 Alerta de Error por nombre de usuario y/o contraseña no válidos ....................... 81

Figura 10.1.11 Pantalla de búsqueda de dispositivos ................................................................. 82

Figura 10.1.12 Alerta de Error si no se encuentran dispositivos.................................................. 82

Figura 10.1.13 Lista de Dispositivos encontrados ...................................................................... 83

Figura 10.1.14 Pantalla de búsqueda de servicios...................................................................... 84

Figura 10.1.15 Pantalla de servicio encontrado ......................................................................... 84

Figura 10.1.16 Pantalla de confirmación para establecer conexión cliente.................................. 85

Figura 10.1.17 Mensaje de espera mientras se establece la conexión......................................... 85

Figura 10.1.18 Pantalla de error en la conexión con BLUELIGHT ................................................. 86

Figura 10.1.19 Pantalla de selección de luces............................................................................ 87

Figura 10.1.20 Pantalla de control de luces............................................................................... 88

Figura 10.1.21 Pantalla de petición para guardar el estado actual de las luces ............................ 89

Figura 10.1.22 Créditos del software Bluelight .......................................................................... 89

Figura 10.2 Diagrama de bloques del hardware Bluelight .......................................................... 90

Figura 10.2.1 Hardware Bluelight............................................................................................. 90

Figura 10.2.2 PIC16F876A ........................................................................................................ 91

Figura 10.2.3 Módulo BlueSMIRF Silver V2 ............................................................................... 92

Figura 10.2.4 Señal de cruce por cero a la entrada del microcontrolador .................................... 94

Figura 10.2.5 División de tiempos de la señal de línea ............................................................. 103

Figura 10.2.6 Control de una luz a una intensidad de 7. ........................................................... 104

10
 LISTA DE TABLAS

Tabla 1. Identificadores de servicios más comunes y su tipo ...................................................... 38

Tabla 2. UUIDs más comunes .................................................................................................. 39

Tabla 3. Protocolos de comunicación Bluetooth ....................................................................... 60

11
 INTRODUCCIÓN

La tecnología parece no tener límites, pues día a día surgen cada vez nuevos y
mejores dispositivos que permiten crear lo que hasta hace poco parecía imposible.
Al parecer, si algo puede ser imaginado por el hombre, entonces puede ser creado
y cuando de automatización de hogares se habla, la imaginación parece no tener
fin, ya que una necesidad que tiene n casi todos los seres humanos es llevar una
vida segura y confortable, empezando en ese lugar al que todos llaman hogar.

¿Quién no se ha imaginado viviendo en un ambiente donde se pueda emplear el

tiempo en realizar ciertas tareas mientras otras se ejecutan por sí mismas? Un
lugar donde se pueda tener el control de todo alrededor sin moverse del lugar
donde se encuentre o dejar de hacer otras actividades. Aunque es común que
cualquier persona sueñe con este tipo de escenarios, estos sueños por lo general
se ven frustrados al darse cuenta que esta tecnología está disponible para unos
pocos que cuentan con los ingresos suficientes para adquirirla. Afortunadamente,
los dispositivos con los que se puede implementar esta tecnología cada vez son
más económicos y fáciles de usar, el problema es que muchos los desconocen y
si ya los poseen aún no se han dado cuenta de su existencia o simplemente no
saben aprovecharlos.

La tecnología más apetecida por los usuarios del hogar es sin duda el control de
las diferentes tareas del hogar sin desplazarse de un lugar a otro . Los elementos
que permiten este tipo de automatización son también conocidos como
dispositivos de control remoto.

Los dispositivos de control remoto, no solo están diseñados para controlar tareas
del hogar, también se pueden usar en la industria, donde se requiere una acción
de control sobre cargas de alto riesgo, sustancias tóxicas o explosivas, las cuales
pueden poner en riesgo la vida de un ser humano.

12
Se obtiene mayor rapidez de respuesta en el momento de tomar acciones sobre
los equipos a controlar, lo que se traduce en mayor eficiencia.

Una de las razones por las que este tipo de dispositivos es tan popular en
viviendas es el confort que genera, ya que se reduce el esfuerzo físico al hacer
uso de elementos de control remoto.

Basándose en esta característica esencial de la domótica, el sistema BLUELIGHT

permitirá ejercer control sobre la intensidad de las luces de un hogar haciendo uso
del Bluetooth de un teléfono celular, lo que se traduce en reducción de costos al
hacer uso de una tecnología que se posee, pero que no se aprovecha al máximo y
que además no genera ningún costo adicional por hacer uso de ella.

La investigación que se empleó en la realización del proyecto fue de tipo aplicativa

(de campo) ya que no solo se hizo el diseño sino también la implementación del
sistema, incluyendo hardware y software. La recolección de la información se hizo
por medio de entrevistas no formales con el director del proyecto y algunos
asesores, también por medio de internet en la búsqueda de documentos
relacionados, foros de discusión sobre los temas tratados en el proyecto y revisión
documental de diferentes universidades.

13
 1. DOMÓTICA

La domótica es el nombre que se le da a una disciplina tecnológica y todos los

sistemas aptos para la robotización doméstica, en mayor o menor medida, quedan
incluidos por definición dentro de este término, por este motivo es importante
determinar los grados de domotización cuando se utiliza la frase "casa domótica"
y para valorar con éxito una casa de este tipo es necesario definir la domótica lo
mejor y más claro posible.

Domótica se refiere a la automatización de las diferentes tareas del hogar, desde

un simple interruptor controlado a distancia, hasta un sistema completo que esté
monitoreando variables y ejerciendo control sobre diferentes dispositivos.

Figura 1. Casa Domótica

Fuente: Tomado de [http://www.microciencia.eu/etiqueta/domotica]

Es una disciplina que se aplica en la Robotización Doméstica con el fin de

aumentar la seguridad, el confort, los servicios multimedia, el uso del diseño
bioclimático y el ahorro energético. Cada uno de estos conceptos pueden contener

14
otros que nos permitan ir dividiendo la domótica con el fin de conseguir detallar el
alcance de los proyectos, por ejemplo, la seguridad en esta tecnología tiene dos
vertientes: La Seguridad por Intrusismo y La Seguridad Técnica [Flor07 ].

Las tecnologías domóticas aplicadas en la robotización doméstica giran en torno a

tres sistemas básicos de control y son [Rtc06 ]:

Control Independiente
Control Centralizado
Control Distribuido en Red

1.1 Domótica con control independiente

Se llama control independiente al sistema donde los propios dispositivos

incorporan los elementos de control y este control se realiza al margen del resto
de componentes.

1.2 Domótica con control centralizado

El control centralizado se caracteriza por el autómata programable o PLC como

elemento más común para realizar este control. Se articula en torno a un elemento
de mando central, donde todas las señales de información, tanto de entradas
como de salidas, llegan o salen del mando central.

1.3 Domótica con control distribuido en red

Es en esta tecnología donde más prod uctos y sistemas están apareciendo. Un

control distribuido en red para domótica, es un sistema de dispositivos
independientes, unidos por un soporte físico, generalmente un cable conductor

15
llamado BUS, con el fin de controlar automáticamente otro sistema s uperior,
teniendo cada dispositivo de la red una o varios tareas específicas.

El Bus de Instalación Europeo EIB es un control de este tipo, otro de los sistemas
característicos de control distribuido en red es el X10, creado para facilitar la
instalación domótica en viviendas antiguas.

16
 2. TECNOLOGÍA BLUETOOTH

La tecnología inalámbrica Bluetooth es un sistema de comunicaciones de corto

alcance, cuyo objetivo es eliminar los cables en las conexiones entre dispositivos
electrónicos, tanto portátiles como fijos, manteniendo altos niveles de seguridad.
Las características principales de esta tecnología son su fiabilidad, bajo consumo
y mínimo coste. La especificación Bluetooth establece una organización uniforme
para que un amplio abanico de dispositivos pueda conectarse y comunicarse entre
sí [BLUE08].

El nombre “Bluetooth” surgió en homenaje a un rey vikingo del siglo X llamado

Harald Blatand o Harald Bluetooth (en inglés). Este rey unificó partes de Noruega,
Suecia y Dinamarca tal como la tecnología Bluetooth está diseñada para permitir
la interacción entre diferentes industrias tales como la computación, telefonía móvil
y mercados automotrices.

El logo de Bluetooth mostrado en la figura 2 nació de la combinación entre las

letras H y B del alfabeto Fulthark Escandinavo ( + ) en honor a las iniciales del
rey danés y como una muestra de la importancia de los países nórdicos en la
tecnología de comunicaciones.

Figura 2. Logo Bluetooth

Fuente: Tomado de [http://www.bluetooth.com].

17
En Febrero de 1998, se fundó el Bluetooth Special Interest Group (SIG) o Grupo
de Interés Especial de Bluetooth, creado con el fin de ofrecer soporte para la
nueva tecnología. Actualmente, más de mil compañías lo integran y trabajan
conjuntamente por un estándar abierto para el concepto Bluetooth.

2.1 Forma de operación

Bluetooth es el nombre que se le da al estándar industrial IEEE 802.15.1, que

utiliza ondas electromagnéticas para comunicar equipos electrónicos que lo
soporten.

Cuando dos dispositivos desean comunicarse deben establecer una gran cantidad
de parámetros entre ellos antes de poder hacer alguna transmisión, deben acordar
cómo van a comunicarse, por medio de cables o sin ellos usando alguna forma de
ondas electromagnéticas, después deben especificar cuanta información enviarán
a la vez y que significado tendrán los bits que usarán, para garantizar que el
mensaje recibido sea fiel al original. Bluetooth provee una solución al problema y
elimina la necesidad de que el usuario intervenga en el proceso de configurar
todas estas opciones.

La transmisión es por medio de ondas electromagnéticas de muy bajo poder,

aproximadamente 1 miliwatt, un teléfono celular, en comparación, a su máxima
potencia puede transmitir señales de hasta 3 Watts. Bluetooth no necesita una
línea de visión para comunicar dos aparatos, como es el caso de una televisión y
un control remoto que utilizan luz infrarroja para comunicarse. Estas ondas de
bajo consumo de energía, limitan el alcance que puede tener a aproximadamente
10 metros, lo cual ayuda a prevenir que provoque interferencia a otros dispositivos
que operen en la misma frecuencia, y permite a los dispositivos que funcionan con
baterías operar por largos períodos de tiempo, estas ondas no son generalmente

18
bloqueadas por obstáculos que se muevan entre los dispositivos, lo cual resulta
conveniente para conectar varios aparatos (8 como máximo) simultáneamente.

Bluetooth utiliza también una técnica llamada “Salto de Frecuencia en un Espectro

Determinado (“Spread Spectrum Frecuenc y Hopping”) para evitar interferencia
entre dos dispositivos, esta consiste en cambiar al azar la frecuencia en la que los
transmisores envían señales, alrededor de 1600 veces por segundo, lo cual hace
muy poco probable que dos transmisores decidan transmitir en exactamente la
misma frecuencia al mismo tiempo y de haber una colisión esta durará una
fracción de segundo (1/1600 segundos) y pueden resolver el conflicto por medio
de software creado para corrección de errores [EBLU09].

Bluetooth utiliza 79 canales de radiofrecuencia con un ancho de banda de 1 MHz

cada uno y una rata máxima de símbolos de 1 MSímbolo/s. Después de que cada
paquete es enviado en una determinada frecuencia de transmisión, ésta cambia a
otra de las 79 frecuencias. El rango típico de operación de Bluetooth es menor a
10 m, sin embargo se pueden alcanzar distancias de hasta 100 m con el uso de
amplificadores [Maya03].

2.2 Seguridad

Quienes deseen usar la tecnología Bluetooth en sus productos tienen distintas

opciones para implementar seguridad. El fabricante de cada producto determina el
modo de seguridad. Los dispositivos y servicios tienen diferentes niveles de
seguridad. Para los dispositivos, hay dos niveles: “Dispositivo confiable” y
“Dispositivo no confiable”. Un dispositivo confiable ya ha sido vinculado con otro
dispositivo y tiene acceso ilimitado a todos los servicios.

Los servicios tienen tres niveles de seguridad:

19
 o Servicios que requieren autorización y autenticación.
o Servicios que requieren autenticación solamente.
o Servicios que están abiertos a todos los dispositivos.

Existe cierta confusión y desinformación acerca de la seguridad en relación con la

tecnología inalámbrica Bluetooth. Lo cierto es que el cifrado de las
especificaciones Bluetooth es seguro. Esto aplica no solo para teléfonos móviles
que usen esta tecnología, sino también dispositivos como ratones y teclados que
se conecten a un PC, un celular en sincronización con un PC y una PDA que use
un teléfono móvil como módem, por nombrar algunos casos. De llegarse a
presentar un problema como el de acceso inapropiado a funcionalidades de
teléfonos celulares (Bluejacking, Bluesnarfing, Bluebugging, Bluetoothing) vía
Bluetooth, es debido a una incorrecta implementación [BLUE08].

2.2.1 BlueJacking. Es el envío de mensajes sin permiso a través de dispositivos

con Bluetooth como celulares, PDAs, portátiles y algunos PCs, enviando una
vCard, una Nota o un contacto que usualmente contiene un mensaje a otro
dispositivo Bluetooth a través del protocolo OBEX.

El nombre fue originado por un usuario llamado AJACK, quien estando en un

banco, buscó algún dispositivo Bluetooth encendido y al encontrar un Nokia 7650,
le envió un mensaje diciendo “Compra Sony Ericsson”. El lo llamó bluejacking y
así se ha hecho desde entonces.

Algunos piensan que el término bluejacking viene de la palabra Bluetooth y la

palabra hijacking. Esto sonaría lógico, pero un bluejacker no hace
hijack(secuestro) con nada. Un bluejacker no está en la capacidad de tomar
control de un teléfono o de robar información personal.

20
Usualmente un bluejacker solo envía un mensaje de texto, pero con los teléfonos
modernos es posible hasta enviar imágines o sonidos también.

Esto del Bluejacking ha sido usado para técnicas de marketing en algunos centros
comerciales quienes se hacen publicidad por este medio.

2.2.2 BlueSnarfing. Es el robo de información de un dispositivo inalámbrico por

medio de una conexión Bluetooth, ya sea entre teléfonos, portátiles o PDAs. Esto
permite acceso al calendario, la lista de contactos, correos y mensajes de texto.
Bluesnarfing es mucho más serio en relación al Bluejacking, pero ambos
“explotan” otros dispositivos Bluetooth sin su conocimiento.

Cualquier dispositivo que tenga encendido el Bluetooth y este se encuentre en

Modo descubierto (o sea que puede ser encontrado por otros dispositivos en el
rango) puede ser atacado. Apagando esta opción puede protegerse de la
posibilidad de ser “Bluesnarfiado”. Siendo esto una invasión de la privacidad, el
Bluesnarfing es ilegal en algunos países.

Dentro de este rango de herramientas se encuentra el BT Info (Super Bluetooth

Hack), el BT File Manager, el BT Explorer, Miyux y otra gran variedad de
utilidades.

2.2.3 BlueBugging. Alguna gente considera el BlueBugging como una forma de

Bluesnarfing. Pero la naturaleza de este es muy diferente. BlueBugging fue
inventado en 2004, más o menos un año después de que empezara el
Bluesnarfing. Mientras el Bluesnarfing se trata de robar cosas o archivos del
dispositivo de la víctima, el BlueBugging hace un trabajo diferente; toma el control
del móvil de la víctima, y por medio de comandos hace lo que el BlueBugger
desee (dentro de este rango tenemos al BT Info o Super Bluetooth Hack). En otras

21
palabras, significa que el BlueBugger toma el control de tu teléfono, y lo usa para
enviar mensajes o para hacer una llamada.

Mientras al principio el BlueBugging requería que el Bugger (literalmente) usara un

dispositivo previamente acomodado, las nuevas herramientas del BlueBugging
han hecho la mayor parte del trabajo, lo que significa que cualquiera con el
conocimiento y la herramienta adecuada puede tomar control de tu teléfono.
Las posibilidades y consecuencias de esto, están a la Imaginación.

2.2.4 BlueTiming o Toothing. Podría decirse que es una variante del

BlueJacking, la cual se dice, es para promover encuentros del tipo sexual (citas,
encuentros y esas cosas) mediante la cual un dispositivo Bluetooth es usado para
“descubrir” otros dispositivos Bluetooth en el rango, y les envía un mensaje
sugestivo, algo así como: ¿Hablamos? ¿Dónde nos vemos?

Se crea una red de encuentros furtivos con otros dispositivos Bluetooth,

generalmente en áreas con mucha afluencia de público como Centros
Comerciales y parecidos, la cual no solo es para encuentros y charlas, sino
también para compartir cosas, lo que ha logrado que se desarrollen aplicaciones
dentro de la categoría MoSoSo (Software para sociabilidad móvil, Mobile Social
Software en Inglés.) dentro de las cuales se pueden nombrar el Mobiluck, el
Bluejack, y los recientes Chat2u o Bluetooth Messenger. También está aquí el
“Sensor” de Nokia.

2.3 PILA DE PROTOCOLOS BLUETOOTH

La pila o stack de protocolos Bluetooth, como se puede observar en la figura 2.1,

se basa en el modelo de referencia OSI (Open System Interconnect) de ISO
(Internacional Standard Organization) para interconexión de sistemas abiertos. La
especificación Bluetooth utiliza una arquitectura de protocolos que divide las

22
diversas funciones de red en un sistema de niveles. En conjunto, permiten el
intercambio transparente de información e ntre aplicaciones diseñadas de acuerdo
con dicha especificación y fomentan la interoperabilidad entre los productos de
diferentes fabricantes.

Figura 2.1 Pila de protocolos Bluetooth

Fuente: Tomado de [More04]

La pila de protocolos Bluetooth se divide en dos zonas, cada una de las cuales se
implementa en distintos procesadores:

o El módulo Bluetooth (hardware), encargado de las tareas relacionadas con

el envío de información a través del interfaz de radiofrecuencia.

23
 o El host Bluetooth (software), encargado de la parte relacionada con las
capas superiores de enlace y aplicación.

Ambas zonas están comunicadas por el Interfaz de Controlador de Host (HCI).

Sobre la capa de protocolos específicos de Bluetooth, cada fabricante puede
implementar su capa de protocolos de aplicación propietarios. De esta forma, la
especificación abierta de Bluetooth expande enormemente el número de
aplicaciones que pueden beneficiarse de las capacidades que ofrece esta
tecnología inalámbrica. Sin embargo, la especificación Bluetooth exige que, a
pesar de la existencia de diferentes pilas de protocolos de aplicación propietarios,
se mantenga la interoperabilidad entre dispositivos que implementen diferentes
pilas.

Las pilas de protocolos Bluetooth más conocidas son Widcomm, Toshiba

Bluetooth Stack, Microsoft Windows XP Bluetooth y IVT BlueSoleil Stack. Linux
dispone de las pilas de protocolos Bluetooth BlueZ, OpenBT y Affix, de Nokia
[More09].

24
2.3.1 Radio. La capa física de radio (RF) Bluetooth opera en la banda de 2.4 GHz
libre para ISM (banda de frecuencia industrial, científica y médica). El sistema
emplea un transmisor de salto de frecuencia para contrarrestar las interferencias y
la pérdida de intensidad, y cuenta con gran número de portadoras de espectro
ensanchado por salto de frecuencia (FHSS). Para minimizar la complejidad del
transmisor, se utiliza una modulación de frecuencia binaria. La tasa de
transferencia de símbolos es de 1 MS/s (megasímbolos por segundo), que admite
una velocidad de transmisión de 1 Megabit por segundo (Mbps) en el modo de
transferencia básica y una velocidad de transmisión aérea total de 2 a 3 Mbps en
el modo de transferencia mejorada. Estos modos se conocen como transferencia
básica y transferencia de datos mejorada, respectivamente.

Canal de radio. Normalmente, varios dispositivos sincronizados por un reloj

y una secuencia de salto de frecuencia comparten el mismo canal físico de radio.

2.3.2 Banda Base. La banda base Bluetooth es la parte del sistema Bluetooth
que especifica o introduce los procedimientos de acceso de medios y capa física
entre dispositivos Bluetooth. Su función principal es permitir el enlace físico por
radiofrecuencia (RF) entre unidades Bluetooth de ntro de una piconet realizando
tareas de modulación y demodulación de los datos en señales RF que se
transmiten por el aire.

Piconets y Scatternets. Dos o más dispositivos que comparten el mismo

canal físico forman una piconet. Solo un dispositivo Bluetooth actúa como maestro
de la piconet, y los demás dispositivos actúan como esclavos. Una piconet puede
constar de hasta siete dispositivos activos. Los esclavos en una piconet solo
pueden tener enlaces al maestro, por esta razón, no pueden enviarse datos entre
ellos; de hecho el maestro actúa como switch para la piconet y todo el tráfico debe
pasar a través de él.

25
Un conjunto de dos o más piconets interconectadas forman scatternets. La figura
2.2 muestra una ilustración de estos dos tipos de redes. Un dispositivo Bluetooth
puede ser esclavo en varias piconets, pero solo puede ser maestro en una. Los
dispositivos que participan en más de una red, pueden actuar como puerta de
enlace, reenviando información de una piconet a otra.

Aunque los dispositivos pueden participar en varias piconets, solo pueden estar
activos en una de ellas, dividiendo el tiempo entre estas [Dide04].

Figura 2.2 Piconets y Scatternets

Fuente: Tomado de [Dide04]

26
 ¤ Reloj Bluetooth

Todos los dispositivos Bluetooth cuentan con un reloj nativo que debe derivarse de
un reloj del sistema de libre funcionamiento. Para la sincronización con otros
dispositivos los esclavos de una piconet usan la dirección Bluetooth del maestro y
su reloj para determinar la secuencia de saltos de frecuencia.
¤ Dirección de dispositivos Bluetooth

A cada dispositivo Bluetooth se le asigna una dirección de dispositivo Bluetooth

única de 48-bit (BD_ADDR) proporcionada por la autoridad reguladora de IEEE.

¤ Códigos de acceso

En el sistema Bluetooth, todas las transmisiones que se realizan a través del canal
físico se inician con un código de acceso. Se definen tres códigos diferentes,
código de acceso del dispositivo (DAC), código de acceso del canal (CAC), código
de acceso de consulta (IAC)

Canales físicos. Los canales físicos se definen mediante una secuencia de

saltos pseudo aleatorios en los canales RF, la sincronización de los paquetes
(ranuras) y un código de acceso. La secuencia de saltos se determina a partir de
la dirección del dispositivo Bluetooth y de la secuencia de saltos seleccionada. La
fase de la secuencia de saltos se determina mediante el reloj Bluetooth. Todos los
canales físicos se subdividen en ranuras de tiempo cuya longitud depende del
canal físico.

27
 ¤ Canal físico básico de la piconet

La definición del canal físico básico de la piconet corresponde al maestro de la

piconet. El maestro controla el tráfico del canal físico de la piconet mediante una
secuencia de consultas.

Por definición, el dispositivo que inicia una conexión mediante una b úsqueda de
terminales hace las veces de maestro. Una vez establecida la piconet, es posible
intercambiar las funciones de maestro y esclavo.
El canal físico básico de la piconet se divide en ranuras de tiempo de 625 μs de
duración cada una.

2.3.3 Link Manager Protocol (LMP) o Protocolo de Gestión de Enlace. Es el

responsable de la autenticación, encriptación, control y configuración del enlace.
El LMP también se encarga del manejo de los modos y consumo de potencia,
además soporta los procedimientos necesarios para establecer un enlace SCO.

2.3.4 Host Controller Interface (HCI) o Interfaz del Controlador de Enlace.

Brinda un método de interfaz uniforme para acceder a los recursos de hardware
de Bluetooth. Éste contiene una interfaz de comando para el controlador banda
base y la gestión de enlace y para acceder al hardware.

2.3.5 Logical Link Control and Adaptation Protocol (L2CAP). También

conocido como Protocolo de Control y Adaptación de Enlace Lógico. Corresponde
a la capa de enlace de datos. Ésta brinda servicios de datos orientados y no
orientados a la conexión a capas superiores. L2CAP multiplexa los protocolos de
capas superiores con el fin de enviar varios protocolos sobre un canal banda base.
Con el fin de manipular paquetes de capas superiores más grandes que el má ximo
tamaño del paquete banda base, L2CAP los segmenta en varios paquetes banda
base. La capa L2CAP del receptor reensambla los paquetes banda base en

28
paquetes más grandes para la capa superior. La conexión L2CAP permite el
intercambio de información referente a la calidad de la conexión, además maneja
grupos, de tal manera que varios dispositivos pueden comunicarse entre sí.

2.3.6 Sevice Discovery Protocol (SDP) o Protocolo de Descubrimiento de

Servicio. El descubrimiento de servicios hace referencia a la capacidad de buscar
y encontrar servicios disponibles en dispositivos Bluetooth. A través de los
servicios, dos dispositivos pueden ejecutar aplicaciones comunes e intercambiar
datos.

El protocolo SDP (Service Discovery Protocol) permite a una aplicación cliente

obtener información sobre servidores SDP disponibles en otros dispositivos
Bluetooth cercanos, enumerar los servicios que ofrecen y las características de
dichos servicios. Después de haber localizado los servicios disponibles en un
dispositivo, el usuario puede elegir aquel de ellos que resulte más apropiado para
el tipo de comunicación que desea establecer.

Un servicio es cualquier entidad que puede ofrecer información, ejecutar una

acción o controlar un recurso. Un servicio puede estar implementado como
hardware, software o una combinación de hardware y software.

Búsqueda de dispositivos y servicios. Debido a la naturaleza de las

redes Bluetooth, los dispositivos remotos entran y salen de la red debido a su
alcance. Los dispositivos Bluetooth poseen la habilidad de descubrir otros
dispositivos que están cerca y descubrir también cuales son los servicios que esos
dispositivos pueden ofrecer [Klin04].

Durante el proceso de búsqueda de dispositivos, el dispositivo que está buscando

recibirá direcciones Bluetooth junto con las frecuencias de los dispositivos

29
encontrados. De esta forma, ese dispositivo podrá identificar todos los dispositivos
encontrados por sus direcciones Bluetooth.

Es posible encontrar dispositivos cuando estos entran en modo inquiry scan. En

ese modo, un dispositivo permanecerá un periodo de tiempo más largo de lo
normal en cada canal. Esto aumenta la posibilidad de ser encontrado por los
dispositivos que están buscando. Los dispositivos descubiertos hacen uso del IAC
(Inquiry Access Code) ó Código de Acceso de Búsqueda. Existen dos tipos de
IAC, el GIAC (General Inquiry Access Code) y el LIAC (Limited Inquiry Access
Code). El primero es usado cuando la búsqueda es hecha por un periodo
indefinido de tiempo, el segundo a su vez, por un periodo de tiempo limitado
[Cava07].

Servicios Bluetooth. Diferentes dispositivos Bluetooth pueden ofrecer

diferentes servicios. Después de ser encontrado el dispositivo remoto, se podrá
hacer una búsqueda de los servicios que ofrece o de alguno específico. Estos
servicios permiten a otros dispositivos conectarse a otro vía Bluetooth y efectuar
alguna operación. Por ejemplo el servicio Bluetooth OBEX Object Push permite a
otros conectarse al dispositivo y transferir archivos.

2.3.7 Protocolo RFCOMM (Radio Frequency Communication). Ofrece

emulación de puertos seriales sobre el protocolo L2CAP. RFCOMM emula
señales de control y datos RS-232 sobre la banda base Bluetooth. Éste ofrece
capacidades de transporte a servicios de capas superiores (por ejemplo OBEX)
que usan una línea serial como mecanismo de transporte. RFCOMM soporta dos
tipos de comunicación, directa entre dispositivos actuando como endpoints y
dispositivo-modem-dispositivo, además tiene un esquema para emulación de null
modem.

30
 Protocolos Específicos

¤ Control de telefonía – Comandos AT.

Bluetooth soporta un número de comandos AT para el control de telefonía a través

de emulación de puerto serial (RFCOMM).
¤ Protocolo Punto-a-Punto (PPP).

El PPP es un protocolo orientado a paquetes y por lo tanto debe usar su

mecanismo serial para convertir un torrente de paquetes de datos en una corriente
de datos seriales. Este protocolo corre sobre RFCOMM para lograr las conexiones
punto-a-punto.

¤ Protocolos UDP/TCP – IP.

Los estándares UDP/TCP e IP permiten a las unidades Bluetooth conectarse, por

ejemplo a Internet, a través de otras unidades conectadas. Por lo tanto, la unidad
puede actuar como un puente para Internet. La configuración TCP/IP/PPP está
disponible como un transporte para WAP.

¤ Protocolo OBEX.

OBEX es un protocolo opcional de nivel de aplicación diseñado para permitir a las

unidades Bluetooth soportar comunicación infrarroja para intercambiar una gran
variedad de datos y comandos. Éste usa un modelo cliente-servidor y es
independiente del mecanismo de transporte y del API (Application Program
Interface) de transporte. OBEX usa RFCOMM como principal capa de transporte.

31
También permite a las aplicaciones operar en la pila de protocolos de la tecnología
Bluetooth y en la pila de la tecnología de infrarrojos. En los dispositivos Bluetooth,
sólo se admiten conexiones OBEX para el intercambio de objetos. Se han
desarrollado tres perfiles de aplicaciones basadas en el protocolo OBEX: SYNC,
FTP y OPP.

2.4 PERFILES BLUETOOTH

Para que un dispositivo pueda utilizar la tecnología inalámbrica Bluetooth, debe

saber interpretar los perfiles Bluetooth, que describen las distintas aplicaciones
posibles. Estos perfiles son guías que indican los procedimientos por los que los
dispositivos equipados con tecnología Bluetooth se comunican entre sí. Existe un
amplio abanico de perfiles que detallan los diferentes tipos de uso y aplicaciones
de la tecnología inalámbrica Bluetooth. Al seguir las directrices proporcionadas en
las especificaciones Bluetooth, los desarrolladores pueden crear aplicaciones
compatibles con otros dispositivos que se ajusten a este estándar [BLUE08].

Cada perfil incluye, como mínimo, información sobre las siguientes cuestiones:

o Dependencia de otros perfiles

o Propuestas de formato de interfaz de usuario

o Características concretas de la pila de protocolos Bluetooth utilizada por el

perfil. Para realizar su función, cada perfil se sirve de ciertas opciones y
parámetros en cada capa de la pila. También se puede incluir un breve
resumen de los servicios requeridos si resulta necesario.

32
La figura 2.3 muestra los diferentes perfiles Bluetooth.

Figura 2.3 Perfiles Bluetooth

Generic Access Profile TCS-BIN Based Profiles

Audio/Video Remote Control Corless Telephony Profile

Profile
Intercom Profile

Ext. Servi ce Discovery Profile (1)

Ha rdcopy Cable Repla cement Profile
Common ISDN Access Profile
Generic Audio/Video Distribution Profile
Servi ce Dis covery App. Profile
Adv. Audio Dis tribution Profile
PAN Profile

ESDP (2) Video Dis tribution Profile

Serial Port Profile

SIM Access Profile
Hea dset Profile

Generic Object Exchange Profile

Ha nds-Free Profile
File Transfer Profile
Dial-Up Networking Profile
Object Push Profile
Fa x Profile
Synchroni za tion Profile
LAN Profile
Basi c imaging Profile
ESDP (3)
Basi c Printing Profile

Fuente: Tomado de [http://www.palowireless.com/infotooth/tutorial/profiles.asp]

Los dispositivos no necesitan implementar todos los perfiles. Un dispositivo solo

necesita implementar los que necesite para soportar sus aplicaciones. Una
excepción, es el Perfil Genérico de Acceso (GAP), el cual se requiere en todos los
dispositivos.

33
2.4.1 Perfil Genérico de Acceso (GAP). Este perfil define los procedimientos
generales para el descubrimiento y establecimiento de conexión entre dispositivos
Bluetooth. El GAP maneja el descubrimiento y establecimiento entre unidades
que no están conectadas y asegura que cualquier par de unidades Bluetooth, sin
importar su fabricante o aplicación, puedan intercambiar información a través de
Bluetooth para descubrir qué tipo de aplicaciones soportan las unidades.

Esencialmente, este perfil describe como son usadas las capas bajas (LMP y
Banda Base), junto con algunas capas superiores.

2.4.2 Perfil de Puerto Serial (SPP). El perfil de puerto serial define los
requerimientos para dispositivos Bluetooth necesarios para establecer conexiones
de cable serial usando RFCOMM entre dos dispositivos semejantes. Este perfil
define los protocolos y procedimientos que se usarán por dispositivos que utilizan
Bluetooth para emulación de cable serial RS232 (o similar).

2.4.3 Perfil Genérico de Intercambio de Objetos (GOEP). Este perfil define

protocolos y procedimientos usados por aplicaciones para ofrecer características
de intercambio de objetos. Los usos pueden ser, por ejemplo, sincronización,
transferencia de archivos o modelo Object Push. Los dispositivos más comunes
que usan este modelo son agendas electrónicas, PDAs, teléfonos celulares y
teléfonos móviles. El GOEP es dependiente del perfil de puerto serial.

2.4.4 Perfil de Aplicación de Descubrimiento de Servicio (SDAP). Este perfil

define los protocolos y procedimientos para una aplicación en un dispositivo
Bluetooth donde se desea descubrir y recuperar información relacionada con
servicios localizados en otros dispositivos. El SDAP es dependiente del GAP.

34
2.5 PROCESO DE CONEXIÓN

Antes de que cualquier dispositivo pueda conectarse a otro, inicialmente debe

buscar dispositivos a los que se pueda conectar y formar entre ellos una piconet, a
este proceso se le conoce como Proceso de Búsqueda (Inquiry Process).

2.5.1 Proceso de Búsqueda. Los dispositivos Bluetooth utilizan procedimientos

de búsqueda para detectarse entre sí dentro de su radio de alcance. Este
procedimiento de búsqueda es asimétrico. Por una parte, el dispositivo Bluetooth
que realiza la búsqueda (Dispositivo A) será el dispositivo de detección y enviará
activamente solicitudes (paquetes de búsqueda) a tal efecto. Por otra, los
dispositivos Bluetooth que son susceptibles de ser detectados, recibirán la
solicitud de búsqueda y responderán enviando un paquete FHS (Frequency Hop
Synchronization) el cual contiene toda la información necesaria para que el
dispositivo que ejecuta la búsqueda se pueda conectar a él, incluyendo la
dirección Bluetooth del dispositivo y clase de dispositivo. Todos los dispositivos
que responden a la búsqueda son reportados al Controlador de Enlace (Host
Controller) del dispositivo A.

Este procedimiento de búsqueda emplea un canal físico especial para las

solicitudes y respuestas y no hace uso de las capas de arquitectura superiores al
canal físico, si bien podría aparecer un enlace físico transitorio durante el
intercambio de información entre el dispositivo receptor y emisor.

Hasta este momento, el dispositivo A conoce qué dispositivos se encuentran en el

rango de conexión y con la información obtenida de la búsqueda, este puede
averiguar qué servicios ofrece cada uno de ellos en busca de uno en particular.

2.5.2 Búsqueda de servicios. El descubrimiento de servicios sigue el modelo

cliente-servidor, de este modo, para encontrar los servicios que ofrece el servidor,

35
el dispositivo A (cliente) envía paquetes de paginación preguntándole si posee un
servicio definido por un registro de servicios (service record). Un dispositivo
disponible para la conexión (Dispositivo B) responderá retornando el registro de
servicios al cliente si posee uno con los atributos especificados y un vínculo de
Banda Base se establece entre ambos dispositivos.

Si se desea por ejemplo una conexión de perfil Dial-up Networking (DUN) entre
ambos dispositivos, primero se establece una conexión L2CAP antes de que
puedan intercambiar información de servicio, la cual será manejada por el
Protocolo de Descubrimiento de Servicios (SDP). Si el dispositivo B responde
indicando que posee el servicio necesitado por el dispositivo A, entonces se puede
establecer una conexión RFCOMM a través del vínculo L2CAP existente. Por
último la conexión Dial-up Networking se establece sobre la conexión RFCOMM.
La figura 2.4 ilustra el establecimiento de este tipo de conexión.

Figura 2.4 Establecimiento de una conexión

Fuente: Tomado de [Dide04]

36
 Registro de Servicios (Service Record). Los registros de servicios
contienen información adicional que no se encuentra en los registros de la clase
de dispositivo. Este es el encargado de responder a las preguntas ¿Qué tipo de
sevicio ofrece esta aplicación? ¿Cómo se conecta un cliente a este servicio?

Los registros de servicios para acceso LAN, sincronización y transferencia de

archivos entre otros servicios estándares están definidos en los perfiles Bluetooth.

Base de Datos para el Descubrimiento de Servicios SDDB (Service

Discovery DataBase). Los servidores utilizan una SDDB para almacenar los
registros de servicios. Cuando un servidor recibe una petición de búsqueda de
servicios, este busca en la SDDB por un registro de servicios con los atributos
especificados que lo describen.

Figura 2.5 Service Discovery DataBase

Fuente: Tomado de [Orti04]

Las responsabilidades de un servidor son:

¤ Crear el registro de servicio describiendo el servicio ofrecido por la

aplicación.

37
 ¤ Añadir el registro de servicios a la SDDB.
¤ Registrar las medidas de seguridad asociadas al servicio.
¤ Aceptar conexiones de clientes solicitando el servicio.
¤ Actualizar la SDDB si el servicio cambia.
¤ Remover o deshabilitar el registro de servicios en la SDDB.

Atributos de Servicios. Los atributos son representados por números

hexadecimales llamados identificadores de atributo. La tabla 1 muestra algunos
identificadores de atributos comúnmente utilizados.

Tabla 1. Identificadores de servicios más comunes y su tipo

Attribute Name Attribute ID Attribute Value Type

ServiceRecordHandle 0x0000 Entero de 32 bits sin signo
ServiceClassIDList 0x0001 DATASEQ de UUIDs
ServiceRecordState 0x0002 Entero de 32 bits sin signo
ServiceID 0x0003 UUID
DATASEQ de DATASEQ de
ProtocolDescriptorList 0x0004
UUIDs y parámetros opcionales
BrowseGroupList 0x0005 DATASEQ de UUIDs
LanguageBasedAttributeIDList 0x0006 DATASEQ de tríos de DATASEQ
ServiceInfoTimeToLive 0x0007 Entero de 32 bits sin signo
ServiceAvailability 0x0008 Entero de 8 bits sin signo
BluetoothProfileDescriptorList 0x0009 DATASEQ de pares de DATASEQ
DocumentationURL 0x000A URL
ClientExecutableURL 0x000B URL
IconURL 0x000C URL
DATASEQ de enteros de 16 bits
VersionNumberList 0x0200
sin signo
ServiceDatabaseState 0x0201 Entero de 32 bits sin signo

Fuente: Tomado de [Cava07]

38
Distintos atributos contienen valores de varios tipos y tamaños, que son
almacenados por un elemento de datos. Un elemento de datos está conformado
por dos partes: La primera es un descriptor del tipo de elemento y la segunda es
un campo de datos. El descriptor de tipo de elemento contiene información sobre
el tipo y tamaño del dato, en cuanto que el campo de datos contiene el dato en sí.
Por lo tanto, un dispositivo remoto siempre sabrá cual es el tipo de dato y su
tamaño cuando esté buscando un determinado atributo.

Identificador Único Universal UUID (Universally Unique Identifier). El

UUID es un tipo de información utilizado para identificar los servicios, protocolos,
perfiles, etc. Los UUIDs son identificadores de 128 bits que garantizan ser únicos
a través del tiempo y el espacio. La tecnología Bluetooth utiliza diferentes
variaciones de UUIDs como grandes y pequeños. Fueron creados con la intención
de reducir eventual almacenamiento y transferencias innecesarias de valores de
UUIDs de 128 bits. La tabla 2 provee una corta lista de los UUIDs más comunes.

Tabla 2. UUIDs más comunes

Name Value Size

Base UUID Value (Used in promoting 16- 0x00000000000010008000
128-bit
bit and 32-bit UUIDs to 128-bit UUIDs) 00805F9B34FB
SDP 0x0001 16-bit
RFCOMM 0x0003 16-bit
OBEX 0x0008 16-bit
HTTP 0x000C 16-bit
L2CAP 0x0100 16-bit
BNEP 0x000F 16-bit
Serial Port 0x1101 16-bit
ServiceDiscoveryServerServiceClassID 0x1000 16-bit
BrowseGroupDescriptorServiceClassID 0x1001 16-bit
PublicBrowseGroup 0x1002 16-bit

39
OBEX Object Push Profile 0x1105 16-bit
OBEX File Transfer Profile 0x1106 16-bit
Personal Area Networking User 0x1115 16-bit
Network Access Point 0x1116 16-bit
Group Network 0x1117 16-bit

Fuente: Tomado de [http://www.bluetooth.org/assigned -numbers/sdp.htm]

2.6 CARACTERÍSTICAS

Gracias a su gran aceptación, un dispositivo Bluetooth puede conectarse con casi

cualquier otro dispositivo compatible que se halle en las proximidades, eliminando
las fronteras en cualquier parte del mundo. Los dispositivos electrónicos
equipados con tecnología Bluetooth pueden conectarse y comunicarse de forma
inalámbrica mediante redes ad hoc de corto alcance denominadas piconets. Cada
dispositivo puede conectarse simultáneamente con hasta otros siete dentro de una
misma piconet. Un dispositivo puede pertenecer a varias piconets al mismo
tiempo. Las piconets se establecen de forma dinámica y automática cuando los
dispositivos Bluetooth se encuentran en el mismo radio de acción.

Una de las principales ventajas de la tecnología inalámbrica Bluetooth es su

capacidad para gestionar simultáneamente tanto transmisiones de voz como de
datos. Esto permite a los usuarios disfrutar de una gran variedad de soluciones
innovadoras, tales como el uso de manos libres para atender llamadas, funciones
de impresión y fax, o la sincronización de aplicaciones entre PDA, ordenadores y
móviles, entre otras muchas.

2.6.1 Composición de las especificaciones. A diferencia de otros estándares

inalámbricos, la especificación Bluetooth otorga a las empresas de desarrollo

40
 definiciones para la capa de enlace y de aplicaciones, lo que permite que sea
compatible con soluciones de voz y datos.

2.6.2 Espectro. La tecnología Bluetooth opera en una banda de frecuencia

industrial, científica y médica (ISM) que no requiere licencia y que se encuadra,
concretamente, entre 2.4 y 2.485 GHz. Utiliza una señal bidireccional en un
espectro ensanchado por salto de frecuencia a una velocidad nominal de 1600
saltos/segundo. La banda ISM de 2.4 GHz está disponible en casi todos los países
y no suele requerir licencia.

2.6.3 Interferencias. La función de salto adaptable de frecuencia (AFH) de la

tecnología inalámbrica Bluetooth se diseñó expresamente para reducir las
interferencias de las tecnologías inalámbricas que comparten el espectro de
2.4 GHz. La función AFH utiliza la frecuencia disponible dentro del espectro. Para
ello, detecta los dispositivos conectados y descarta las frecuencias que éstos
estén utilizando. Este salto adaptable permite unas transmisiones más eficaces
dentro del espectro, por lo que se mejora el funcionamiento del dispositivo, incluso
si el usuario utiliza otras tecnologías al mismo tiempo. La señal salta entre 79
frecuencias en intervalos de 1 MHz para tener un alto grado de tolerancia a las
interferencias.

2.6.4 Alcance. El alcance depende de la clase del dispositivo:

o Los radios de clase 3 suelen tener un alcance de entre uno y tres metros.
o Las radios de clase 2 son habituales de los dispositivos portátiles y tienen
un alcance de diez metros.
o Las radios de clase 1 se utilizan principalmente en el sector industrial y
logran un alcance de cien metros.

41
2.6.5 Potencia. Las radios más utilizadas son las de clase 2, con una potencia de
2,5 mW. La tecnología Bluetooth se ha diseñado para minimizar el consumo de
energía. Para ello, la especificación cambia las radios al modo de ahorro de
energía cuando no están activas.

42
 3. TELÉFONO CELULAR

Las tecnologías inalámbricas han tenido mucho auge y desarrollo en estos últimos
años, una de las que ha tenido un gran desarrollo ha sido la telefonía celular.
Desde sus inicios a finales de los 70 ha revolucionado enormemente las
actividades que realizamos diariamente. Los teléfonos celulares se han convertido
en una herramienta primordial para la gente común y de negocios haciéndolas
sentir más seguras y más productivas.

A pesar de que la telefonía celular fue concebida estrictamente para la voz, la

tecnología celular de hoy es capaz de brindar otro tipo de servicios, como datos,
audio y video con algunas limitaciones. Sin embargo, la telefonía inalámbrica del
mañana hará posible aplicaciones que requieran un mayor consumo de ancho de
banda [Jime05].

3.1 CÓMO FUNCIONAN LOS TELÉFONOS CELULARES

La gran idea del sistema celular es la división de la ciudad en pequeñas células o

celdas. Esta idea permite la re-utilización de frecuencias a través de la ciudad, con
lo que miles de personas pueden usar los teléfonos al mismo tiempo. En un
sistema típico de telefonía análoga de los Estados Unidos, la compañía recibe
alrededor de 800 frecuencias para usar en cada ciudad. La compañía divide la
ciudad en celdas. Cada celda generalmente tiene un tamaño de 26 kilómetros
cuadrados. Las celdas son normalmente diseñadas como hexágonos (figuras de
seis lados), en una gran rejilla de hexágonos como se muestra en la figura 3.

43
Figura 3. Red de Celdas de telefonía Celular

Fuente: Tomado de
[http://www.yucatan.com.mx/especiales/celular/comofunciona.asp ].

Cada celda tiene una estación base que consiste de una torre y un pequeño
edificio que contiene el equipo de radio.
Cada celda en un sistema análogo utiliza un séptimo de los canales de voz
disponibles. Eso es, una celda, más las seis celdas que la rodean en un
arreglo hexagonal, cada una utilizando un séptimo de los canales disponibles
para que cada celda tenga un grupo único de frecuencias y no haya
colisiones:

o Un proveedor de servicio celular típicamente recibe 832

radiofrecuencias para utilizar en una ciudad.

o Cada teléfono celular utiliza dos frecuencias por llamada, por lo que
típicamente hay 395 canales de voz por portador de señal. (las 42
frecuencias restantes son utilizadas como canales de control).

o Por lo tanto, cada celda tiene alrededor de 56 canales de voz

disponibles.

44
En otras palabras, en cualquier celda, pueden hablar 56 personas en sus
teléfonos celulares al mismo tiempo. Con la transmisión digital, el número de
canales disponibles aumenta. Por ejemplo el sistema digital TDMA puede
acarrear el triple de llamadas en cada celda, alrededor de 168 canales
disponibles simultáneamente.
Los teléfonos celulares tienen adentro transmisores de bajo poder. Muchos
teléfonos celulares tienen dos intensidades de señal: 0.6 watts y 3.0 watts (en
comparación, la mayoría de los radios de banda civil transmiten a 4 watts.) La
estación central también transmite a bajo poder. Los transmisores de bajo
poder tienen dos ventajas:

o Las transmisiones de la base central y de los teléfonos en la misma

celda no salen de ésta. Por lo tanto, cada celda puede re-utilizar las
mismas 56 frecuencias a través de la ciudad.

o El consumo de energía del teléfono celular, que generalmente funciona

con baterías, es relativamente bajo. Una baja energía significa baterías
más pequeñas, lo cual hace posibles los teléfonos celulares.

La tecnología celular requiere un gran número de bases o estaciones en una

ciudad de cualquier tamaño. Una ciudad grande puede llegar a tener cientos
de torres. Cada ciudad necesita tener una oficina central la cual maneja todas
las conexiones telefónicas a teléfonos convencionales, y controla todas las
estaciones de la región [Yuca01].

3.2 DIFERENCIAS ENTRE LOS TELÉFONOS CELULARES Y LOS RADIOS

DE BANDA CIVIL

Una buena manera de entender la sofisticación del teléfono celular es compararlo

con los radios de banda civil o los walkie-talkies.

45
Figura 4. Celular vs. Radio

Fuente: Tomado de
[http://www.yucatan.com.mx/especiales/celular/bandacivilVscelular.asp]

3.2.1 Simplex Vs. Dúplex. Los radios de banda civil y los walkie talkies son
dispositivos simplex. Eso significa que cuando dos personas se comunican,
utilizan la misma frecuencia, por lo que sólo una persona puede hablar al mismo
tiempo. Un teléfono celular es un dispositivo dúplex. Eso significa que utiliza una
frecuencia para hablar y otra para recibir, de esa manera dos personas pueden
platicar al mismo tiempo.

3.2.2 Canales. Un walkie-talkie tiene usualmente un canal, y un radio de banda

civil tiene 40 canales. Un teléfono celular típico puede comunicar en 1,664 canales
o más.

3.2.3 Rango. Un walkie-talkie puede transmitir hasta alrededor de 1.5 kms de

distancia utilizando un transmisor de .25 watts. Un radio de banda civil, debido a
que es más poderoso, puede transmitir hasta alrededor de 7 y medio kilómetros
con un transmisor de 5 watts. Los teléfonos celulares trabajan dentro de celdas, y
pueden cambiar de celda al vuelo. Las celdas le dan a los teléfonos celulares un
rango increíble. Alguien que utilice un teléfono celular puede manejar cientos de
kilómetros y mantener una conversación todo el tiempo debido a que cambia de
celdas [Yuca01].

46
3.3 SOFTWARE PARA DISPOSITIVOS MÓVILES

Lo primero a tener en cuenta es que un dispositivo móvil no es solo un celular y

que el software a desarrollar, puede ser, tanto un sitio Web, como una aplicación
para el dispositivo.

Los celulares no son los únicos dispositivos móviles para los cuales se pueden
hacer desarrollos, también se puede hacer para otros aparatos como Palm o
Pocket PC, dispositivos de mano pequeños con ciertamente una gran potencia.

Hay que tener en cuenta varios aspectos tanto para elegir el dispositivo correcto,
como la tecnología a usar, para ello es necesario conocer cuáles son las
necesidades, tanto presentes como futuras, las capacidades del dispositivo que se
elija, el conocimiento actual o la facilidad de adquirir este conocimiento sobre el
software de desarrollo, entre otras.

Algunos de los lenguajes más usados para el desarrollo de software de

dispositivos móviles son .NET, Java, BREW entre otros.

47
 4. JAVA

La empresa Sun Microsystems lanzó a mediados de los años 90 el lenguaje de

programación orientado a objetos Java, que aunque en un principio fue diseñado
para generar aplicaciones que controlarían electrodomésticos como lavadoras,
frigoríficos, etc, debido a su gran robustez e independencia de la plataforma donde
se ejecutase el código, finalmente se utilizó para la creación de componentes
interactivos integrados en páginas Web y programación de aplicaciones
independientes. Estos componentes se denominaron applets y casi todo el trabajo
de los programadores se dedicó al desarrollo de éstos. Con los años, Java ha
progresado enormemente en varios ámbitos como servicios HTTP, servidores de
aplicaciones y acceso a bases de datos (JDBC). Como se puede observar Java se
ha ido adaptando a las necesidades tanto de los usuarios como de las empresas
ofreciendo soluciones y servicios tanto a unos como a otros [Galv03].

Debido a la explosión tecnológica de estos últimos años Java ha desarrollado

soluciones personalizadas para cada ámbito tecnológico.

En 1999, Sun Microsystems reconoció que “con un único tamaño no es posible

abarcarlo todo” y decidió reagrupar la tecnología JAVA en varias ediciones. De
esta manera, JAVA se ha redistribuido en tres ramas:

¤ Java 2 Platform, Standard Edition (J2SE)

Esta edición de Java es la que en cierta forma recoge la iniciativa original del
lenguaje Java. Tiene las siguientes características:

o Inspirado inicialmente en C++, pero con componentes de alto nivel, como

soporte nativo de strings y recolector de basura.

48
 o Código independiente de la plataforma, precompilado a bytecodes
intermedio y ejecutado en el cliente por una JVM (Java Virtual Machine).

o Modelo de seguridad tipo sandbox proporcionado por la JVM.

o Abstracción del sistema operativo subyacente mediante un juego completo

de APIs de programación.

Esta versión de Java contiene el conjunto básico de herramientas usadas para

desarrollar Java Applets, así cómo las APIs orientadas a la programación de
aplicaciones de usuario final: Interfaz gráfica de usuario, multimedia, redes de
comunicación, etc.

¤ Java 2 Platform, Enterprise Edition (J2EE)

Esta versión está orientada al entorno empresarial. El software empresarial tiene

unas características propias marcadas: está pensado no para ser ejecutado en un
equipo, sino para ejecutarse sobre una red de ordenadores de manera distribuida
y remota mediante EJBs (Enterprise Java Beans). De hecho, el sistema se monta
sobre varias unidades o aplicaciones. En muchos casos, además, el software
empresarial requiere que se sea capaz de integrar datos provenientes de entornos
heterogéneos. Esta edición está orientada especialmente al desarrollo de servi cios
web, servicios de nombres, persistencia de objetos, XML, autenticación, APIs para
la gestión de transacciones, etc. El cometido de esta especificación es ampliar la
J2SE para dar soporte a los requisitos de las aplicaciones de empresa.

¤ Java 2 Platform, Micro Edition (J2ME)

Esta versión de Java está enfocada a la aplicación de la tecnología Java en

dispositivos electrónicos con capacidades computacionales y gráficas muy

49
reducidas, tales como teléfonos móviles, PDAs o electrodomésticos inteligentes.
Esta edición tiene unos componentes básicos que la diferencian de las otras
versiones, como el uso de una máquina virtual denominada KVM (Kilo Virtual
Machine, debido a que requiere sólo unos pocos Kilobytes de memoria para
funcionar) en vez del uso de la JVM clásica, inclusión de un pequeño y rápido
recolector de basura

Figura 5. Arquitectura de la plataforma Java 2 de SUN

Fuente: Tomado de [Galv03]

La separación dada por Sun permite que cada edición evolucione por sí sola y se
adapte mejor al conjunto de dispositivos para el cual fue diseñada; sin embargo,
las diferentes ediciones se traslapan.

50
Aunque Sun Microsystems es la máxima autoridad en lo que respecta al futuro de
Java, otras corporaciones o empresas pueden participar en la definición y revisión
de la plataforma Java a través del Java Community Process (JCP), entre ellas:
Motorola, Nokia, Sony, Phillips, Siemens, Palm, IBM, Ericsson, Cisco Systems,
Samsung, Oracle, Texas Instruments, NEC, Symbian, Hitachi, Panasonic.

4.1 J2ME

J2ME (Java 2 Micro Edition) está enfocado para ser usado en dispositivos con
recursos limitados. Tiene una sola parte de las clases de J2SE, las necesarias
para poder manejar los recursos de un teléfono celular. La tecnología J2ME se ha
difundido ampliamente en los últimos años en más de 110 operadores telefónicos
alrededor del mundo, tanto GSM como CDMA, gracias a que es independiente de
la estructura de red o de un modelo de negocios determinado. Además, existe una
gran base de programadores Java, que sin mucho esfuerzo dan el salto a J2ME.

Debido a la gran variedad de marcas y modelos de teléfonos, SUN definió el MIDP

(Mobile Information Device Profile) para establecer los requisitos con los cuales las
compañías productoras de dispositivos deben cumplir para poder ser catalogados
como dispositivos que soportan J2ME.

En una primera etapa se definió MIDP 1.0, el cual era muy general y por eso no
incluía algunas características de los teléfonos más recientes. Debido a esto,
compañías como Nokia y Samsung, lanzaron clases propias para sacar mayor
provecho de los recursos de sus teléfonos, no contemplados en la versión MIDP
1.0.

Posteriormente se definió a través del JCP (Java Community Process), la versión

2.0 del MIDP, que contiene más clases para utilizar los recursos del teléfono.
Además de las clases estándar del MIDP, existen “clases opcionales” que

51
permiten ocupar más recursos de los dispositivos actuales, como son: multimedia,
graficación 3D, manejo de los archivos del teléfono, envío y recepción de
mensajes de texto y multimedia, implementar web services, entre otros.

Existen herramientas de desarrollo gratuitas que pueden ser descargadas del

portal de Sun Microsystems. Además, compañías como Nokia, Motorola, Sony-
Ericsson, entre otras, cuentan con sitios para desarrolladores, donde es posible
descargar especificaciones técnicas, emuladores y herramientas de desarrollo
[Mart05].

Como se puede observar en la figura 6, J2ME contiene una mínima parte de las
APIs de Java. Esto es debido a que la edición estándar de APIs de Java ocupa
aproximadamente 20 Mb, y los dispositivos pequeños disponen de una cantidad
de memoria mucho más reducida. En concreto, J2ME usa 37 clases de la
plataforma J2SE provenientes de los paquetes java.lang, java.io, java.util [Galv03].

Se puede concluir que J2EE es un superconjunto de J2SE y que J2ME es un

subconjunto de la versión Standard excepto por un paquete de clases adicionales
llamado javax.microedition, como ilustra la figura 6.

Figura 6. Relación entre las APIs de la plataforma Java

javax.microedition

Fuente: Tomado de [Galv03]

52
4.1.1 Configuraciones. Una configuración define las funcionalidades mínimas
para dispositivos con características semejantes. Por lo tanto, más
específicamente, define las características en cuanto a máquina virtual y el
conjunto de clases derivadas de la plataforma Java SE.

Actualmente, existen dos tipos de configuraciones definidas en Java ME, la

Configuración para Dispositivos con Conectividad Limitada CLDC (Connected
Limited Device Configuration) y la Configuración para Dispositivos Conectados
CDC (Connected Device Configuration).

CLDC. Es la más pequeña de las dos configuraciones, diseñada para

dispositivos con conexiones de red intermitentes, procesadores lentos y memoria
limitada, por ejemplo los teléfonos móviles y las PDAs. Una implementación de
CLDC generalmente incluye una pequeña máquina virtual de kilobytes KVM (Kilo
Virtual Machine), especialmente diseñada para dispositivos con memoria
restringida.

CDC. Esta configuración está diseñada para dispositivos de nivel superior

que poseen más memoria, procesadores más rápidos y mayor ancho de banda de
red, tales como TV set-top boxes, sistemas telemáticos de vehículos y PDAs de
gama alta. CDC incluye una máquina virtual completa y una mayor
implementación de la plataforma Java SE.

Como se muestra en la figura 6.1 CLDC es un subconjunto de CDC.

53
Figura 6.1 Relación entre CDC y CLDC

Fuente: Tomado de [Cava07]

4.1.2 Perfiles. Un perfil proporciona las librerías para que el programador pueda
desarrollar aplicativos para un determinado dispositivo. Un perfil podría ser
considerado como las características de un dispositivo que pertenece a una familia
y está representando un tipo de configuración.

MIDP (Mobile Information Profile). El perfil MIDP está diseñado

específicamente para dispositivos portátiles, como celulares y PDAs (de bajo
desempeño); MIDP combinado con CLDC ofrece manejo del ciclo de vida de la
aplicación, componentes de interfaz de usuario, conectividad de red y
almacenamiento de datos locales. Las aplicaciones MIDP se llaman MIDlets al
igual que la clase MIDlet definida en MIDP y es la superclase para todas las
aplicaciones MIDP.
4.1.3 Paquetes opcionales. La plataforma Java ME puede ser extendida
combinando paquetes opcionales con CLDC y su perfil correspondiente. Estos
paquetes son creados para satisfacer requerimientos de mercado específicos y
ofrecen APIs estándar para usar tanto las tecnologías existentes y las que
recientemente surgen como Bluetooth, servicios WEB, mensajería inalámbrica,
multimedia y conectividad a base de datos. Al ser modulares estos paquetes, es

54
decisión de los fabricantes implementarlos o no de acuerdo a las necesidades y
capacidades de cada dispositivo [Hole09].

4.1.4 APIs Java para Bluetooth (JSR-82 / JABWT). El JCP (Java Community
Process) es el hogar de la comunidad desarrolladora internacional que tiene como
objetivo desarrollar y evolucionar las especificaciones de la tecnología Java. El
proceso JCP conlleva el uso de JSR (Java Specification Request) los cuales son
documentos formales que describen las especificaciones y tecnologías propuestas
para que sean añadidas a la plataforma Java. Las revisiones públicas formales de
JSRs son controladas antes de que los JSR se conviertan en final y sean votados
por el Comité Ejecutivo JCP. Un JSR final suministra una implementación de
referencia la cual da una implementación libre de la tecnología en código fuente y
un Kit de Compatibilidad de Tecnología para verificar la especificación de la API.

JSR-82 ó JABWT (Java Apis for Bluetooth Wireless Technology) es un API que
está dividida en dos partes: el paquete javax.bluetooth y el paquete javax.obex.
Los dos paquetes son totalmente independientes. El primero de ellos define clases
e interfaces básicas para el descubrimiento de dispositivos, descubrimiento de
servicios, conexión y comunicación. La comunicación a tra vés de javax.bluetooth
es a bajo nivel: mediante flujos de datos o mediante la transmisión de arrays de
bytes.

Por el contrario el paquete javax.obex permite manejar el protocolo de alto nivel

OBEX (OBject EXchange). Este protocolo es muy similar a HTTP y es utilizado
sobre todo para el intercambio de archivos. El protocolo OBEX es un estándar
desarrollado por IrDA y es utilizado también sobre otras tecnologías inalámbricas
distintas de Bluetooth.

55
La plataforma principal de desarrollo del API JSR-82 es J2ME. El API ha sido
diseñada para depender de la configuración CLDC. Sin embargo existen
implementaciones para poder hacer uso de este API en J2SE [Gime04].

JSR-82 revela la pila de software Bluetooth a los desarrolladores que trabajan

sobre la plataforma Java. De especial interés está el Protocolo de Descubrimiento
de Servicios (SDP), el Perfil de Puerto Serial RFCOMM para emulación serial y el
Perfil L2CAP, los cuales proveen servicios de datos orientados a conexión con
protocolos de capas superiores.

Javax.bluetooth. En una comunicación Bluetooth existe un dispositivo que

ofrece un servicio (servidor) y otros dispositivos acceden a él (clientes).
Dependiendo de qué parte de la comunicación se deba programar, se realizarán
una serie de acciones diferentes.

Un cliente Bluetooth deberá realizar las siguientes acciones:

o Búsqueda de dispositivos. La aplicación realizará una búsqueda de los

dispositivos Bluetooth a su alcance que estén en modo conectable.

o Búsqueda de servicios. La aplicación realizará una búsqueda de servicios

por cada dispositivo.

o Establecimiento de la conexión. Una vez encontrado un dispositivo que

ofrece el servicio deseado se conectará a él.

o Comunicación. Ya establecida la conexión se podrá leer y escribir en ella.

Por otro lado, un servidor Bluetooth deberá hacer las siguientes operaciones:

o Crear una conexión servidora

56
 o Especificar los atributos de servicio

o Abrir las conexiones clientes

¤ Clase LocalDevice (Dispositivo Local). La clase LocalDevice proporciona

acceso a datos del dispositivo utilizado. Esta clase tiene un constructor privado
que impide crear un objeto LocalDevice nuevo, por lo que solo se podrá obtener
una referencia del mismo con el método LocalDevice.getLocalDevice(), este
método puede lanzar una excepción BluetoothStateException si no funciona
correctamente el sistema Bluetooth.

Una vez obtenido este objeto se pueden conseguir datos importantes del teléfono
celular. Para obtener la dirección del dispositivo local (no el remoto), se usa el
método getBluetoothAddress(), para el nombre GetFriendlyName(), el tipo de
método de descubrimiento se obtiene con getDiscoverable(), este último retorna
unas constantes que están incluidas de modo estático en el objeto
DiscoveryAggent. Para modificarlo podremos usar la función setDiscoverable(),
peró puede dar un BluetoothStateException en caso de Error.

La clase LocalDevice tiene un método llamado getProperty() para obtener

información adicional, aunque es recomendable usarlo de forma estática. Este
método es parecido al System.getProperty de J2SE, y algunas de estas
propiedades son [Oran06]:

o Máximo número de dispositivos conectados

(bluetooth.connected.devices.max)

o Versión de JABWT soportada (bluetooth.api.version)

57
 o Máximo número de atributos por servicio (bluetooth.sd.attr.retrievable.max)

o Posibilidad de recibir inquirys cuando se está conectando con otro

dispositivo (bluetooth.connected.inquiry.scan)

o Posibilidad de realizar inquirys cuando se está conectando con otro

dispositivo (Bluetooth.conected.inquiry)

¤ Clase DiscoveryAgent. Las búsquedas de dispositivos y servicios

Bluetooth se realizarán a través de un objeto DiscoveryAgent. Este objeto es único
y se obtendrá a través del método getDiscoveryAgent() del objeto LocalDevice.

A través de DiscoveryAgent se tiene la posibilidad de obtener un arreglo (array) de

dispositivos que el usuario haya especificado como "ya conocidos" (PREKNOWN,
quizá una lista de dispositivos "favoritos") o un arreglo de dispositivos descubiertos
en búsquedas anteriores (CACHED). Esto se hará llamando al método
retrieveDevices() pasándole DiscoveryAgent.PREKNOWN o
DiscoveryAgent.CACHED respectivamente. Este método no devolverá un arreglo
vacío si no encuentra dispositivos que coincidan con el criterio especificado, en
vez de ello devolverá null. El arreglo devuelto por este método es de objetos
RemoteDevice, los cuales, representan dispositivos remotos.

¤ Clase RemoteDevice. Permite obtener la dirección Bluetooth del

dispositivo que representa (dispositivo remoto) a través del método
getBluetoothAddress() en forma de String. También se podrá obtener el "friendly-
name" del dispositivo a través del método getFriendlyName(). Este último método
requiere un argumento de tipo booleano que permite especificar si se debe forzar
a que se contacte con el dispositivo para preguntar su "friendly-name" (true) o bien
se puede obtener un "friendly-name" que tuvo en una ocasión previa (false). El

58
método getFriendlyName() puede lanzar una java.io.IOException en caso de que
no se pueda contactar con el dispositivo o este no provea un "friendly-name".

¤ Clase UUID. La clase UUID (universally unique identifier) representa

identificadores únicos universales. Se trata de enteros de 128 bits que identifican
protocolos y servicios. En la documentación de la clase UUID se puede encontrar
una tabla con los protocolos y servicios más comunes y sus UUIDs asignadas. Se
puede crear un objeto UUID a partir de un String o de un entero largo.

¤ Interfaz DiscoveryListener. Esta interfaz le permite a la aplicación recibir

eventos de descubrimiento de dispositivos y servicios. Esta interfaz provee cuatro
métodos, dos para descubrir dispositivos y dos para descubrir servicios.

o deviceDiscovered() es llamado cada que se descubre un nuevo dispositivo

durante una búsqueda.
o inquiryCompleted() es invocado cuando una búsqueda de dispositivos ha
finalizado.
o servicesDiscovered() es llamado cada que se descubre un servicio Nuevo
durante una búsqueda de servicios.
o serviceSearchCompleted() es invocado cuando una b úsqueda de servicios
ha finalizado.

o Conexión. El API javax.bluetooth permite usar dos mecanismos de

conexión: SPP (RFCOMM) y L2CAP. Mediante SPP se obtendrán datos
orientados a streams de tipo InputStream y OutputStream, mientras que en L2CAP
se enviarán y recibirán arrays de bytes. Para abrir cualquier tipo de conexión se
hará uso de la clase javax.microedition.io.Connector, en concreto se usará el
método estático open() que está sobrecargado; su versión más sencilla requiere
un parámetro que es un String el cual contendrá la URL con los datos necesarios

59
para realizar la conexión. La URL será diferente dependiendo si se desea ser
cliente o servidor de una conexión L2CAP o SPP.

Para la creación de un nuevo servicio, en caso de que se desee ser un servidor, lo

único que se debe hacer es llamar al método open() de un objeto Connection
proporcionando como parámetro una URL con características determinadas. Al
llamar la función open() esta retornará un objeto Notifier, al que se le aplicará un
interfaz determinado dependiendo del protocolo. Una vez obtenido el objeto
Notifier se ha creado el servicio, pero no se ha guardado en la SDDB ni publicado,
para ello se llama a la función acceptandOpen del objeto Notifier. Esta función
retornará un objeto Connection que usará otro interfaz dependiendo del protocolo.

Las diferentes interfaces a utilizar así como la línea de la URL que define el
protocolo, están indicadas en la tabla 3.

Tabla 3. Protocolos de comunicación Bluetooth

Protocolo Diferencia en URL Notifier Connector

RFCOMM btspp: StreamConnectionNotifier StreamConnection

L2CAP btl2cap: L2CAPConnectionNotifier L2CAPConnection

OBEX btgoep: SessionNotifier SessionConnection

Fuente: Tomado de [Oran06]

Aplicaciones Bluetooth. Una aplicación Bluetooth puede ser tanto un

servidor como un cliente (un productor de servicios o un consumidor).

60
Figura 7. Caso de uso específico de una aplicación Bluetooth

Inicializ a 1

Descubre
Dispositivos
cercanos y servicios Cliente

2
Utiliza los Servicios
descubiertos

Ofrece servicio

Espera por client es

y los maneja Servidor
3

Deja de ofrecer
servicio

Fuente: Tomado de [Orti04]

Estos casos de uso se pueden resumir de la siguiente forma:

o Inicialización: Todas las aplicaciones Bluetooth deben inicializar primero la

pila Bluetooth.
o Cliente: Un cliente consume servicios remotos. Primero descubre
dispositivos cercanos, entonces por cada dispositivo descubierto b usca
servicios de interés.

61
 o Servidor: Un servidor pone servicios a disposición de los clientes. Los
registra en la Base de Datos de Descubrimiento de Servicios (SDDB), en
efecto publicándolos. Luego espera por conexiones entrantes, las acepta a
medida que van entrando y sirve a los clientes que las realizan. Finalmente
cuando el servicio no se necesita más, la aplicación lo remueve de la
SDDB.

La figura 8 ilustra los elementos que componen una aplicación Bluetooth típica, en
este caso un MIDlet.

Figura 8. Elementos que componen típicamente un MIDlet Bluetooth.

Javax.microedition.midlet::MIDlet Javax.bluetooth::DiscoveryListener

Javax.bluetooth::DiscoveryAgent 1 Javax.microedition.io::
1 * StreamConnection
Mi MIDlet 1
Javax.microedition.io::
Javax.bluetooth::LocalDevice 1 1 Bluetooth *
StreamConnectionNotifier
1
1 1 1 *
Javax.bluetooth::RemoteDevice *
Javax.bluetooth::L2CAPConnection

Javax.bluetooth::ServiceRecord * * Javax.bluetooth::
L2CAPConnectionNotifier

Fuente: Tomado de [Orti04]

62
 5. MICROCONTROLADORES

Recibe el nombre de controlador el dispositivo que se emplea para el gobierno de

uno o varios procesos. Por ejemplo, el controlador que regula el funcionamiento de
un horno dispone de un sensor que mide constantemente su temperatura interna
y, cuando traspasa los límites prefijados, genera las señales adecuadas que
accionan los efectores que intentan llevar el valor de la temperatura dentro del
rango estipulado.

Aunque el concepto de controlador ha permanecido invariable a través del tiempo,

su implementación física ha variado frecuentemente. Hace tres décadas, los
controladores se construían exclusivamente con componentes de lógica discreta,
posteriormente se emplearon los microprocesadores, que se rodeaban con chips
de memoria y E/S sobre una tarjeta de circuito impreso. En la actualidad, todos los
elementos del controlador se han podido incluir en un chip, el cual recibe el
nombre de microcontrolador. Realmente consiste en un sencillo pero completo
computador contenido en el corazón (chip) de un circuito integrado.

Un microcontrolador es un circuito integrado de alta escala de integración que

incorpora la mayor parte de los elementos que configuran un controlador. Dispone
normalmente de los siguientes componentes:

o Procesador o UCP (Unidad Central de Proceso).

o Memoria RAM para Contener los datos.
o Memoria para el programa tipo ROM/PROM/EPROM.
o Líneas de E/S para comunicarse con el exterior.
o Diversos módulos para el control de periféricos (temporizadores, Puertas
Serie y Paralelo, CAD: Conversores Analógico/Digital, CDA: Conversores
Digital/Analógico, etc.).

63
Figura 9. Microcontrolador

µC

PERIFÉRICOS
µP

PERIFÉRICOS
E/S
E/S
UC

Memoria

Fuente: [Propia]

5.1 Recursos comunes a todos los microcontroladores.

Al estar todos los microcontroladores integrados en un chip, su estructura

fundamental y sus características básicas son muy parecidas. Todos deben
disponer de los bloques esenciales Procesador, memoria de datos y de
instrucciones, líneas de E/S, oscilador de reloj y módulos controladores de
periféricos. Sin embargo, cada fabricante intenta enfati zar los recursos más
idóneos para las aplicaciones a las que se destinan preferentemente.

En este apartado se hace un recorrido de todos los recursos que se hallan en

todos los microcontroladores describiendo las diversas alternativas y opciones que
pueden encontrarse según el modelo seleccionado.

5.1.1 Arquitectura básica. Aunque inicialmente todos los microcontroladores

adoptaron la arquitectura clásica de von Neumann, en el momento presente se
impone la arquitectura Harvard. La arquitectura de von Neumann se caracteriza
por disponer de una sola memoria principal donde se a lmacenan datos e

64
instrucciones de forma indistinta. A dicha memoria se accede a través de un
sistema de buses único (direcciones, datos y control).

La arquitectura Harvard dispone de dos memorias independientes una, que

contiene sólo instrucciones y otra, sólo datos. Ambas disponen de sus respectivos
sistemas de buses de acceso y es posible realizar operaciones de acceso (lectura
o escritura) simultáneamente en ambas memorias como se puede observar en la
figura 9.1

Figura 9.1 Arquitectura HARVARD

MEMORIA DE UCP MEMORIA DE

INSTRUCCIONES DATOS
CONTROL CONTROL
UNIDAD DE
DIRECCIONES CONTROL DIRECCIONES
INSTRUCCIONES INSTRUCCIONES DE DATOS DATOS

UNIDAD
INSTRUCCIONES DATOS
OPERATIVA

Fuente: Tomado de [Hena02]

Los microcontroladores más populares se encuentran, sin duda, entre las mejores
elecciones:

o 8048 (Intel). Es el padre de los microcontroladores actuales, el primero de

todos. Su precio, disponibilidad y herramientas de desarrollo hacen que
todavía sea muy popular.
o 8051 (Intel y otros). Es sin duda el microcontrolador más popular. Fácil de
programar, pero potente. Está bien documentado y posee cientos de
variantes e incontables herramientas de desarrollo.

65
 o 80186, 80188 y 80386 EX (Intel). Versiones en microcontrolador de los
populares microprocesadores 8086 y 8088. Su principal ventaja es que
permiten aprovechar las herramientas de desarrollo para PC.
o 68HC11 (Motorola y Toshiba). Es un microcontrolador de 8 bits potente y
popular con gran cantidad de variantes.
o 683xx (Motorola). Surgido a partir de la popular familia 68k, a la que se
incorporan algunos periféricos. Son microcontroladores de altísimas
prestaciones.
o PIC (Microchip). Familia de microcontroladores que gana popularidad día a
día. Fueron los primeros microcontroladores RISC.

Es preciso resaltar en este punto que existen innumerables familias de

microcontroladores, cada una de las cuales posee un gran número de variantes.

66
 6. DISEÑO E IMPLEMENTACIÒN

El desarrollo de este proyecto debió dividirse en dos grandes bloques, por un lado
el Software desarrollado para el dispositivo móvil, en este caso un teléfono celular,
y el hardware encargado de recibir las órdenes enviadas desde el celular y
ejecutarlas.

Figura 10. Diagrama de bloques del sistema BLUELIGHT

Dispositivo
móvil (SW)

Bluetooth Bluetooth Microcontrolador Carga

(Load)

Fuente: [Propia]

6.1 METODOLOGÍA DE DESARROLLO

Debido al corto plazo y la complejidad del proyecto, se decidió adoptar algunas

prácticas de metodologías de desarrollo ágiles tanto para el software del celular
como el del microcontrolador, específicamente la Programación Extrema (XP).
Una de las características de XP, es que el cliente o un representante de él hace
parte del equipo de desarrollo, y aunque este proyecto no fue desarrollado para un
cliente en particular, de hecho cualquier persona puede ser un posible cliente, se
contó constantemente con las observaciones y sugerencias hechas por ingenieros
y posibles usuarios del sistema.

67
Tal vez la única característica de la metodología XP que no hizo parte en el
desarrollo del proyecto fue la programación en parejas, debido a que el desarrollo
fue hecho por una sola persona.
La metodología XP fue bastante adecuada para este desarrollo, ya que permite
fácilmente hacer cambios a los requerimientos al considerar ciclos iterativos
menores de desarrollo, además se pretende ir agregando cada vez más
funcionalidades tanto a la aplicación como al hardware, de hecho, esta versión de
Bluelight es la segunda de una serie de aplicaciones que permiten hacer control
domótico desde un teléfono celular. La versión 1.0 fue dada a conocer en la
semana universitaria y permitía enviar las órdenes de encender una luz, un
ventilador y abrir una puerta a un PC que las ejecutaba haciendo uso del puerto
paralelo. La base del programa del celular es la misma usada en Bluelight Versión
2.0 lo cual demuestra una evolución del código sin perder la esencia.

6.2 SOFTWARE BLUELIGHT

El software desarrollado para el teléfono celular fue desarrollado en J2ME debido

a la gran cantidad de dispositivos móviles que la integran. A medida que se fue
desarrollando, se fueron integrando nuevas funcionalidades producto de las
sugerencias ofrecidas por posibles usuarios del sistema.

Figura 10.1 Diagrama de bloques del software Bluelight V2.0

Bienvenida Ingreso Búsqueda de Búsqueda de Control

dispositivos servicios de cargas

Bluetooth

Fuente: [Propia]

68
La aplicación consta de tres clases que la hacen completamente funcional y
modular, permitiéndole agregar más funciones a futuro para hacerla más amigable
y robusta.

La clase principal es BTMidlet (Ver figura 10.1.1), la cual es heredera de MIDlet e

implementa las interfaces CommandListener,ItemStateListener y
ConnectionListener. Es en esta clase donde se crean todas las pantallas del
sistema con las que interactúa el usuario.

Figura 10.1.1 Clase BTMidlet

Fuente: [Propia]

HiloConexión (Ver figura 10.1.2) es una clase heredera de Thread e implementa la

interfaz DiscoveryListener. Aquí ocurre todo el proceso de conexión del dispositivo

69
con el hardware, desde la búsqueda de dispositivos y servicios Bluetooth hasta el
envío de órdenes por medio del objeto HiloConexion creado en la clase BTMidlet.

Figura 10.1.2 Clase HiloConexion

Fuente: [Propia]

La clase Registro (Ver figura 10.1.3) fue implementada para una funcionalidad que
no estaba planeada al inicio del proyecto, pero que debido a las sugerencias de
posibles usuarios a medida que se desarrollaba el software permitió agregársela.
Lo que se hace por medio de esta clase es guardar en una pequeña “base de
datos” el estado actual de las luces lo cual permite establecer una intensidad para
cada luz y en caso de que alguien más modifique su estado, se podrán restablecer
de nuevo las intensidades que se guardaron en el celular.

70
Figura 10.1.3 Clase Registro

Fuente: [Propia]

La clase LocalDevice (Ver figura 10.1.4) hace referencia al dispositivo Bluetooth

local y proporciona acceso a datos del o propiedades del mismo.

public LocalDevice dispositivoLocal;

dispositivoLocal = LocalDevice.getLocalDevice();

LocalDevice provee métodos para recibir información acerca del dispositivo local y
para tener acceso al gestor Bluetooth.

o getBluetoothAddress() retorna la dirección Bluetooth.

o getDeviceClass() retorna la clase de dispositivo.
o getFriendlyName() retorna el nombre (friendly name) del dispositivo
Bluetooth.

71
 o getRecord() retorna uno de los registros de servicios para la conexión
Bluetooth especificada.
o updateRecord() actualiza el registro de servicio SDDB para el
ServiceRecord.
o getDiscoverable() retorna el estado de descubrimiento del dispositivo.
o setDiscoverable() Pone el estado de descubrimiento del dispositivo.
o getDiscoveryAgent() retorna una referencia de DiscoveryAgent.
o getProperty() retorna una de las propiedades del dispositivo.

Figura 10.1.4 Clase LocalDevice

Fuente: [Orti04]

La clase DiscoveryAgent (Ver figura 10.1.5) es la que permite realizar la búsqueda

de dispositivos y servicios Bluetooth. Este objeto es único y se obtendrá a través
del método getDiscoveryAgent() del objeto LocalDevice.

public DiscoveryAgent da;

da = dispositivoLocal.getDiscoveryAgent();

72
Las aplicaciones cliente que deseen ser notificadas cuando un dispositivo o
servicio ha sido encontrado deberán implementar y registrar la interfaz
DiscoveryListener.

La clase que implemente DiscoveryListener deberá implementar los métodos

propios de la interfaz. Para el descubrimiento de dispositivos son:

public void deviceDiscovered(RemoteDevice dispRemoto, DeviceClass claseDisp)

public void inquiryCompleted(int motivoFinalización)

Cada vez que se descubre un dispositivo se llama al método deviceDiscovered()

junto con dos argumentos, el primero es un objeto de la clase RemoteDevice que
representa al dispositivo encontrado; el segundo argumento permitirá determinar
el tipo de dispositivo encontrado.

inquiryCompleted() es llamado cuando la búsqueda de dispositivos ha finalizado

junto con un argumento entero indicando el motivo de la finalización. Este
argumento podrá tomar los valores: DiscoveryListener.INQUIRY_COMPLETED si
la búsqueda ha concluido con normalidad, DiscoveryListener.INQUIRY_ERROR si
se ha producido un error en el proceso de búsqueda, o
DiscoveryListener.INQUIRY_TERMINATED si la búsqueda fue cancelada.

Para el descubrimiento de servicios los dos métodos son:

servicesDiscovered(int transID, ServiceRecord[] servRecord)

serviceSearchCompleted(int transID, int respCode)

Cada que se descubre un servicio se llama a servicesDiscovered() con dos

argumentos; el primero (transID) identifica el proceso de búsqueda para saber cuál
fue la que lo invocó ya que se pueden hacer búsquedas simultáneas y el segundo

73
(servRecord) es un arreglo de objetos ServiceRecord. Un objeto ServiceRecord
describe las características de un servicio Bluetooth, en otras palabras es el
servicio como tal.

serviceSearchCompleted() es llamado cuando termina la búsqueda de servicios.

Consigo vienen dos argumentos que indican cual fue el proceso de búsqueda que
finalizó (transID) y el motivo (respCode) por el cual terminó.

Para comenzar una nueva búsqueda de dispositivos se debe llamar al método

startInquiry() del objeto DiscoveryAgent. Este método requiere dos argumentos, el
primero es un entero que especifica el modo de conectividad que deben tener los
dispositivos a buscar; este valor deberá ser DiscoveryAgent.GIAC o bien
DiscoveryAgent.LIAC, el segundo argumento es un objeto que implemente
DiscoveryListener. A través de este último objeto serán notificados los dispositivos
que se vayan descubriendo. Para cancelar la búsqueda se puede usar el método
cancelInquiry() [Gime04].

da.startInquiry(int modoConectividad, DiscoveryListener claseQueEscucha);

Para comenzar una nueva búsqueda de servicios se llamará al método

searchServices() del objeto DiscoveryAgent. Este método requiere cuatro
argumentos, el primero es un arreglo (array) de enteros con el que se
especificarán los atributos de servicio en los que se está interesado; en la interfaz
ServiceRecord, los servicios son descritos a través de atributos que son
identificados numéricamente, este arreglo contendrá los ID de estos atributos. El
segundo argumento es un arreglo de identificadores de servicio que permite
especificar los servicios que se requieren. El tercer argumento es el dispositivo
remoto sobre el que se va a realizar la búsqueda. Por último se pasará un objeto
que implemente DiscoveryListener que será usado para notificar los eventos de
búsqueda de servicios.

74
 da.searchServices(int[] attrSet, UUID[] uuidSet, RemoteDevice dispRemoto,
DiscoveryListener claseQueEscucha)

Cada servicio tiene varios atributos como nombre, descripción, etc., y si se está
interesado en conocer uno o más de ellos, se tendrán que especificar en la
búsqueda agregándolos en el arreglo attrSet, de lo contrario se podrá usar null
teniendo en cuenta que si luego se desea saber por ejemplo el nombre del servicio
indicando su atributo, arrojará un NullPointerException ya que en la búsqueda no
se especificó.

75
Figura 10.1.5 Clase DiscoveryAgent e interfaz DiscoveryListener

Fuente: [Orti04]

Una instancia de la clase RemoteDevice (Ver figura 10.1.6) representa un

dispositivo Bluetooth remoto y sus métodos son similares a los que provee
LocalDevice, algunos de estos son:

76
 o getBluetoothAddress() retorna la dirección Bluetooth.
o getFriendlyName() retorna el nombre (friendly name) del dispositivo
Bluetooth.
o getRemoteDevice() retorna el RemoteDevice que corresponde a la
conexión Bluetooth especificada.

Figura 10.1.6 Clase RemoteDevice

Fuente: [Orti04]

Para la conexión, la aplicación Bluelight V2.0 deberá ser cliente ya que el módulo
BlueSMIRF será quien ofrezca el servicio de puerto serie. El protocolo a usar será
el de emulación de puerto serie RS-232.

Para un cliente será necesario crear un objeto de tipo StreamConnection y de ser

necesario la recepción y envío de datos se crearán también objetos de tipo
InputStream y OutputStream.

77
 StreamConnection conexion;
InputStream is;
OutputStream os;

Las conexiones deberán ejecutarse en otro hilo (Thread) para no afectar la

aplicación. Un cliente se crea llamando a Connector.open() con el String apropiado
para la conexión cliente. Este String empieza con el prefijo de protocolo “btspp://”.
Un objeto de tipo StreamConnection es retornado cuando se abre una conexión
cliente (Cuando se hace la petición al servidor).

conexion = (StreamConnection)
Connector.open("btspp://direcciónServidor:canalServicio");

Cuando se crea la conexión, los objetos OutputSteam e InputStream pueden

usarse para enviar y recibir datos del servidor con los métodos write() & read().

os = conexion.openOutputStream();
is=conexion.openInputStream();

La figura 10.1.7 muestra el diagrama de clases del software del celular.

78
 Figura 10.1.7 Diagrama de clases del software Bluelight

<<interface>>
MIDlet
CommandListener <<interface>>
ItemStateListener
<<interface>>
ItemStateListener

BTMidlet
<<interface>>
DiscoveryListener
1
* Thread
1
Registro
*
HiloConexion

1
LocalDevice 1
1
1 1 1 *
StreamConnection
1
DiscoveryAgent
* *
RemoteDevice StreamConnectionNotifier

*
ServiceRecord

Fuente: [Propia]

El programa inicia mostrando una pantalla de Bienvenida por medio de una

pantalla de Alerta (Alert) durante 2 segundos.

Figura 10.1.8 Pantalla de bienvenida

79
Fuente: [Propia]

Pasados los 2 segundos, se muestra un formulario (Form) con una marquesina

(Ticker) desplazándose en la parte superior, dos campos de texto (TextField) para
el nombre de usuario y la contraseña y dos comandos (Command), 1 para salir de
la aplicación y otro para validarse en el sistema.

Figura 10.1.9 Formulario de ingreso

Fuente: [Propia]
Si la contraseña es incorrecta, se mostrará una alerta (Alert) con un mensaje de
error indicando que el nombre de usuario y/o la contraseña son inválidos. Esta

80
alerta no estará por un tiempo determinado, sino que permanecerá en pantalla
hasta que se presione el comando Done para que regrese al formulario de
ingreso.

Figura 10.1.10 Alerta de Error por nombre de usuario y/o contraseña no válidos

Fuente: [Propia]

Si por el contrario, el nombre de usuario y la contraseña fueron ingresados

correctamente, se iniciará la búsqueda de dispositivos Bluetooth que se
encuentren en un radio de entre 10 y 15 metros aproximadamente. Se debe tener
en cuenta que solo se encontrarán los dispositivos que tengan su Bluetooth
activado y detectable. Durante la búsqueda, se muestra en pantalla una Alerta
(Alert) por 20 segundos. Este tiempo puede variar si la búsqueda tarda más de lo
estipulado como sucede en algunos móviles que dedican más tiempo que otros
buscando dispositivos.

81
Figura 10.1.11 Pantalla de búsqueda de dispositivos

Fuente: [Propia]

Si durante la búsqueda no se encuentra ningún dispositivo Bluetooth, se mostrará

una alerta (Alert) indicándolo, este mensaje permanecerá hasta que se presione el
comando Done que regresará al usuario al formulario de ingreso.

Figura 10.1.12 Alerta de Error si no se encuentran dispositivos

Fuente: [Propia]

82
Una vez se empieza a buscar dispositivos, los nombres (Friendly Names) de estos
se van adicionando a una pantalla de tipo Lista (List) a medida que van siendo
encontrados y cuando se termina la búsqueda, esta se muestra como una lista
exclusiva, o sea que solo se podrá elegir un elemento de ella.

Figura 10.1.13 Lista de Dispositivos encontrados

Fuente: [Propia]

De los dispositivos mostrados en la lista, el usuario debe elegir el dispositivo cuyo

nombre sea BLUELIGHT ya que este es el nombre (Friendly Name) que se le ha
dado al Bluetooth del módulo BlueSMIRF para ser identificado en una red, por
último debe presionar el comando (Command) Conectar para iniciar una
búsqueda, esta vez de servicios que ofrece BLUELIGHT, específicamente el
servicio de puerto serie identificado con el UUID 0x1101. Durante la búsqueda se
muestra una alerta (Alert) durante 20 segundos máximo indicándole al usuario que
la búsqueda está en proceso.

83
Figura 10.1.14 Pantalla de búsqueda de servicios

Cuando el servicio sea encontrado, se mostrará una alerta indicando que se ha

encontrado el servicio de puerto serie y que intentará establecer la conexión
Bluetooth cliente con el módulo, para lo cual el celular solicitará la confirmación del
usuario para realizarla.

Figura 10.1.15 Pantalla de servicio encontrado

Fuente: [Propia]

84
Figura 10.1.16 Pantalla de confirmación para establecer conexión cliente

Fuente: [Propia]

Mientras se realiza la conexión, una Alerta le indicará al usuario que espere

mientras se establece la conexión.

Figura 10.1.17 Mensaje de espera mientras se establece la conexión

Fuente: [Propia]

85
Si por algún motivo no se puede establecer conexión ya sea porque el celular y el
módulo se alejan demasiado o si BLUELIGHT está desactivado en ese momento,
aparecerá una pantalla de Error durante 3 segundos indicándole al usuario que
BLUELIGHT puede estar apagado.

Figura 10.1.18 Pantalla de error en la conexión con BLUELIGHT

Fuente: [Propia]

Si finalmente se realiza la conexión con el módulo, aparecerá una pantalla de tipo

Lista múltiple en la que se podrá seleccionar una, dos o las tres luces para reg ular
la intensidad de cada una de ellas. Dentro de los comandos posibles de esta
pantalla, está el de Salir para finalizar la aplicación, OK para mostrar la pantalla
con los controles de intensidad de las luces seleccionadas y finalmente Último
Estado para seleccionar como su nombre lo indica el estado en que quedaron las
luces la última vez que se ejecutó la aplicación.

86
Figura 10.1.19 Pantalla de selección de luces

Fuente: [Propia]

Cualquiera de las dos opciones para controlar la intensidad (OK y Último Estado)
llevará a la pantalla de control en la que aparecerán unos controles (Gauges) que
permitirán seleccionar en un rango de 0 a 30 la intensidad deseada de cada una
de las luces seleccionadas. En el ejemplo de la figura 9.1.17 se ha escogido una
intensidad de 15 (mitad de la intensidad) para la luz exterior, de 30 (intensidad
máxima) para la luz de la sala principal, y una intensidad de 1 para la luz del baño.

87
Figura 10.1.20 Pantalla de control de luces

Fuente: [Propia]

Con el comando atrás se retornará a la lista de luces disponibles para controlar.

Si en algún momento de la aplicación se presiona el Comando Salir, se mostrará

una alerta solicitando al usuario si desea guardar el estado en el que dejó las
luces para que la próxima vez que ejecute la aplicación pueda seleccionar esas
mismas intensidades con el comando Último Estado.

88
Figura 10.1.21 Pantalla de petición para guardar el estado actual de las luces

Fuente: [Propia]

Por último, se muestran los créditos con los nombres de los desarrolladores.

Figura 10.1.22 Créditos del software Bluelight

Fuente: [Propia]

89
6.3 HARDWARE

Los elementos centrales del hardware son el módulo Bluetooth y el

microcontrolador; el primero se encarga de recibir vía Bluetooth la información
enviada por el usuario desde el celular (orden), y entregársela al módulo USART
del microcontrolador por medio del protocolo RS-232 para que este la procese y la
ejecute manejando la etapa de potencia que permite el control sobre la carga, en
este caso las luminarias.

Figura 10.2 Diagrama de bloques del hardware Bluelight

Cruce
por cero

Módulo Microcontrolador Etapa de

Bluetooth potencia

Fuente: [Propia]

Figura 10.2.1 Hardware Bluelight

Fuente: [Propia]

90
6.3.1 PIC16F876A

El PIC16F876A es un microcontrolador de 8 bits empaquetado en un integrado de

28 pines y es compatible con los dispositivos PIC16C5X, PIC12CXXX y
PIC16C7X. Este dispositivo es ideal para el sistema Bluelight pues cuenta con 22
pines de entrada/salida suficientes para manejar las señales provenientes del
módulo Bluetooth por medio de su módulo USART, el detector de cruce por cero y
controlar 3 diferentes cargas. El sistema puede ser aún más robusto si se hiciera
uso de otras características propias del PIC como su módulo conversor
análogo/digital.

Figura 10.2.2 PIC16F876A

Fuente [http://www.microchip.com]

o Características
o Tipo de memoria FLASH
o Memoria de programa de 14KB
o 368 Bytes de RAM
o 256 bytes de memoria EEPROM
o Conversor análogo/digital

91
 o Módulo USART
o Set de 35 instrucciones
o 3 temporizadores

6.3.2 Módulo Bluetooth BlueSMIRF Silver V2. El BlueSMIRF Silver V2 es un

módulo Bluetooth inalámbrico serial de la empresa SprkFun Electronics. Este
módem trabaja como un puente serial RS-232 (RX/TX). Cualquier flujo de datos
serial (Stream) de 9600 a 115200bps puede ser enviado directamente por el
microcontrolador hacia dispositivo objetivo. La unidad puede ser alimentada de
3.3V hasta 6V y todos sus pines de señal toleran estos voltajes.

Figura 10.2.3 Módulo BlueSMIRF Silver V2

Fuente: Tomado de [http://www.sparkfun.com]

Especificaciones
o Módem de Radio Bluetooth de clase 1 aprobado por la FCC.
o Compatible con todos los productos Bluetooth que soporten SPP.
o Vinculación robusta tanto en integridad como en distancia de transmisión
(30m).
o Bajo consumo de corriente: 25mA aprox.
o Esquema de salto de frecuencia resistente – Opera en severos ambientes
de RF como WiFi, 802.11g y Zigbee.

92
 o Conexión encriptada.
o Frecuencia: 2.4 ~ 2.524 GHz.
o Voltaje de operación: 3.3V – 6V.
o Comunicaciones serial: 2400-115200bps.
o Temperatura de operación: -40 ~ +70ºC.
o Antena integrada.

Dimensiones
o 51.5x15.8x5.6mm

6.3.3 Detector de Cruce x cero. El detector de cruce por cero le permite al

microcontrolador saber cuándo hay un cambio de ciclo en la señal de línea, para
así calcular en qué momento deberá ser disparado cada uno de los Triacs que
controlan las tres cargas. F ue creado fácilmente usando la interrupción por cambio
de estado en el pin RB7 del microcontrolador PIC y solo un componente externo,
una resistencia, para limitar la corriente en el PIC. En Colombia el voltaje de línea
eficaz Vrms=116.2VAC, y el voltaje pico de línea es 164.3V. Al seleccionar una
resistencia de 5MΩ, la corriente pico Ipeak=164.3V/5MΩ=32.86µA lo cual está
bien para la capacidad de corriente de un pin E/S del microcontrolador PIC.

Diodos de protección a la entrada (diseñados dentro de los pines del PIC) regulan
cualquier voltaje mayor a Vdd o menos a Vss. De esta forma, cuando el voltaje AC
se encuentra en el ciclo negativo, el pin RB7 se mantendrá con un voltaje entre
Vss – 0.6V. Esto se interpretará como un cero lógico. Cuando el voltaje AC se
eleva por encima del valor de alimentación del PIC, el valor lógico en RB7 será „1‟.

93
Figura 10.2.4 Señal de cruce por cero a la entrada del microcontrolador

Fuente: [Propia]

6.3.4 Etapa de potencia. Esta etapa está conformada por un optoacoplador

MOC3010 encargado de aislar las señales de corriente alterna del
microcontrolador quien por medio de este disparará un Triac que conducirá cierta
parte de cada semi-ciclo de corriente alterna que alimenta la carga dependiendo
de la intensidad deseada.

6.3.5 Descripción del software del microcontrolador. Una vez el

microcontrolador es energizado, este configura su módulo Receptor/Transmi sor
Síncrono/Asíncrono Universal (USART) y habilita la interrupción por recepción en
USART para que espere hasta que se reciba el primer dato enviado desde el
celular.

94
 INICIO

Configurar puertos
y módulo USART

Habilitar Interrupción por

recepción en USART

No ¿Buffer de
recepción lleno?

Si
Leer Buffer

START bank1
movlw b'10000101' ;Rate de 64 para TMR0
movwf OPTION_R
movlw b'10000000' ;RB7 entrada para Interrupción por
;cambio de estado en cruce por cero
movwf PORTB
bsf PIE_1,5 ;Habilita interrupción por recepción en
;USART (RCIE = 1)
bcf TXSTA_,4 ;Configura USART para operación
;asíncrona (SYNC = 0)
bsf TXSTA_,2 ;High Baud Rate (BRGH = 1)
movlw .64 ;BAUD RATE = 19200
movwf SPBRG_
bank0
bsf RCSTA,7 ;Habilita USART (SPEN = 1) configura
;RC7 como IN (RX) y RC6 como OUT (TX)

95
 bsf RCSTA,4 ;Habilita recepción continua en USART
;(CREN = 1)
movlw 0C0h ;Habilita GIE y PEIE Para primera
;interrupción por recepción en USART
movwf INTCON

askAgain btfss PIR1,5 ;¿Recepción en USART? Buffer de

;recepción lleno?
goto $-1 ;No
call readBuffer ;Si: Lee Buffer de recepción
goto askAgain

Una vez se recibe esta información y se genera la interrupción, se lee el buffer del
USART por medio del registro RCREG y se deshabilita la interrupción por
recepción en el módulo serial para dejar habilitada solo la interrupción por cambio
de estado la cual será producida por el detector de cruce por cero.

Interrupción

No ¿Buffer de Si
recepción lleno?
Atender Leer Buffer
Interrupción de
cruce por cero
Deshabilitar interrupción de
recepción en USART

Habilitar interrupción por

cambio de estado en PORTB

Retorne

96
 ORG 4h ;Vector de interrupciones
btfss PIR1,5 ;¿Recepción en USART?
goto ZERO_CROSS ;No: Interrupción de cruce por cero
call readBuffer ;Si: Lee Buffer
INT btfsc INTflags,0 ;¿Primera interrupción por
;recepción en USART?
goto ZERO_CROSS ;No: Fue interrupción por cambio de
;estado
bsf INTflags,0 ;Si: Pone un 1 en bandera de
;recepción por USART
Movlw 088h ;Habilita interrupción por cambio de
;estado y deshabilita interrupción
;por recepción de USART
movwf INTCON
retfie ;Retorna de la interrupción

Cuando ocurre una interrupción de cruce por cero el microcontrolador espera un

tiempo mínimo que tarda el Triac en empezar a conducir tanto en el ciclo positivo
(0.5mS) como en el negativo (0.8mS). Debe tenerse en cuenta que el triac
tampoco conducirá si se dispara próximo al siguiente cruce por cero (menos de
0.88mS en el ciclo positivo y 1.1mS en el negativo antes del cruce) por lo que este
tiempo también debe considerarse. Después de este tiempo, se leen tres registros
que indican si cada una de las luces debe ser encendida y a que intensidad. De
acuerdo a estos datos, el microcontrolador esperará el tiempo necesario antes de
disparar cada uno de los Triacs y así manejar diferentes intensidades en cada luz.

97
 Interrupción de
cruce por cero

No ¿Semi-ciclo Si
negativo?
Espere 0,5µS Espere 0,8µS

Carga temporizador para que se Carga temporizador para que se

desborde en 231,4µS desborde en 205,6µS

Habilita de nuevo Interrupción

por cambio de estado

No ¿Porcentaje de Si
luz exterior es 0?
Poner en 1 bandera
¿Es tiempo de No de luz exterior
disparar Triac?

Si

Poner en 1 bandera
de luz exterior

Encender luz ¿Porcentaje de

exterior luz sala es 0?

98
ZERO_CROSS clrf LIGHTS ;Limpia banderas de luces
btfsc PORTB,7 ;¿Ciclo negativo?
goto up ;No: Flanco de subida
call _0.8mS ;Si: Tiempo que tarda el Triac
;en conducir en ciclo negativo

movlw .240
movwf TMR0 ;Carga TMR0 para que se
;desborde en 205.6uS

goto goON

up call _0.5mS ;Tiempo que tarda el Triac en

;conducir en ciclo positivo

movlw .238
movwf TMR0 ;Carga TMR0 para que se
;desborde en 231.4uS

goON movfw PORTB

movlw 88h
movwf INTCON ;Habilita interrupción por
;cambio de estado

movlw .30
movwf ciclo

ask decfsz light0,0 ;¿Cero porcentaje de luz exterior?

goto ilumine0 ;No: Vaya a encender luz exterior

99
 bsf LIGHTS,0 ;Si: Ponga en uno bandera de luz
;exterior indicando que no se hará
;nada más con esa luz

goto zero1 ;Vaya a preguntar por luz sala

ilumine0 decf light0,0 ;Mueve valor de light0 a W

xorwf ciclo,0
btfss STATUS,2 ;¿Listo para disparar el Triac?
goto zero1 ;No: Pregunte por la luz sala
btfsc LIGHTS,0 ;Si: ¿Ya lo disparó antes?
goto zero1 ;No: Pregunte por la luz sala
bsf LIGHTS,0 ;Si: Ponga en uno bandera de luz
;exterior indicando que no se hará
;nada más con esa luz

bsf PORTB,0 ;Encienda luz exterior

movlw .50
call _uS ;Tiempo de pulso del Gate
bcf PORTB,0 ;Termine el disparo del Triac

zero1 decfsz light1,0 ;¿Cero porcentaje de luz sala?

goto ilumine1 ;No: Vaya a encender luz sala
bsf LIGHTS,1 ;Ponga en uno bandera de luz1
;indicando que no se hará nada
;más con esa luz

goto zero2 ;Vaya a preguntar por luz baño

100
La cantidad de intensidades posibles son 30, por lo tanto, cada semiciclo debió ser
dividido en este número para hallar el tiempo de cada intensidad, esto se logró de
acuerdo a los siguientes cálculos:

Tciclo=8.34mS (Tiempo de cada semi-ciclo de la señal de AC)

TdisPos=0.5mS (Tiempo de espera mínimo antes de disparar el triac en el ciclo

positivo)

TdisNeg=0.8mS (Tiempo de espera mínimo antes de disparar el triac en el ciclo

negativo)

TproPos=0.88mS (Tiempo prohibido de disparo del triac antes del próximo cruce
en el ciclo positivo)

TproNeg=1.1mS (Tiempo prohibido de disparo del triac antes del próximo cruce en
el ciclo negativo)

ValorInt (Valor de la intensidad entre 0 y 30)

ThabilPos=Tciclo-(TdisPos+TproPos)=8.34mS-(0.5mS+0.88mS)=6.96mS (Tiempo
habilitado para el control de las intensidades en el ciclo positivo)

ThabilNeg=Tciclo-(TdisNeg+TproNeg)=8.34mS-(0.8mS+1.1mS)=6.44mS (Tiempo
habilitado para el control de las intensidades en el ciclo negativo)

TminIntPos=ThabilPos/30=6.96mS/30=232µS (Tiempo de conducción de la

mínima intensidad en el ciclo positivo)

101
TminIntNeg=ThabilNeg/30=6.44mS/30=214.6µS (Tiempo de conducción de la
mínima intensidad en el ciclo negativo)

TintPos=ValorInt*TminIntPos (Tiempo total de la intensidad deseada en ciclo

positivo)

TintNeg=ValorInt*TminIntNeg (Tiempo total de la intensidad deseada en ciclo

negativo)

En la figura 10.2.5 se observa el ciclo positivo divido en 30 sin tener en cuenta el

TdisPos (Tiempo de espera mínimo antes de disparar el triac en el ciclo positivo) y
el TproPos (Tiempo prohibido de disparo del triac antes del próximo cruce en el
ciclo positivo).

102
Figura 10.2.5 División de tiempos de la señal de línea

Fuente: [Propia]

Si se deseara por ejemplo una intensidad de 7, el disparo del Triac deberá

hacerse en el TintPos (Tiempo total de la intensidad deseada en ciclo positivo) y
TintNeg (Tiempo total de la intensidad deseada en ciclo negativo).

103
Figura 10.2.6 Control de una luz a una intensidad de 7.

Fuente: [Propia]

104
6.4 PRUEBAS Y AJUSTES

Durante las primeras pruebas del módulo Bluetooth BlueSMIRF, se logró hacer
una conexión entre este y una dongle Bluetooth USB conectada al computador
desde bluesoleil e hyperterminal, pero cuando se intentó enviar el comando AT
+++ para configurarlo, no se recibía la respuesta OK por parte del módulo. Esto se
debía a que el módulo solo puede ser configurado con comandos AT enviados
directamente por el puerto RS-232 y no vía Bluetooth.

Una vez configurado el BlueSMIRF, se realizó una búsqueda de dispositivos

desde el computador y desde el celular y ambos lo detectaron. Hecho esto, se
decidió hacer una pequeña aplicación en para el celular que buscara dispositivos
Bluetooth y se conectara al servicio de puerto serie que ofrece el módulo.

Después de lograr conectarse desde el celular al módulo, se desarrolló otra

aplicación que enviara datos desde el móvil al BlueSMIRF por medio de un
Gauge, los datos iban del 0 al 10, además se conectó el módulo al puerto serial
del computador y se hizo una conexión al COM1 desde el hyperterminal para
recibir los datos enviados desde el celular y mostrarlos en pantalla.

Se debe tener en cuenta a la hora de hacer la petición de conectarse al módulo, si

no se usa la URL de servicio retornada por el servidor sino que se hace
directamente usando la dirección del dispositivo Bluetooth, se debe especificar el
canal al cual hará la petición de conectarse. En cuanto al computador, la
aplicación que vaya a recibir la información enviada debe conectarse al COM con
el que se estableció la conexión para poder leer los datos recibidos.

Se decidió recibir estos datos en un microcontrolador haciendo uso del USART del
mismo, por lo cual se desarrolló un programa en ensamblador que muestra por un
puerto el dato recibido serialmente desde el módulo BlueSMIRF. No confundir el

105
funcionamiento de los pines RX y TX del módulo, el primero recibe datos para
enviar vía Bluetooth y el segundo transmite datos recibidos por el módulo vía
Bluetooth.

Por último, se probó el dimmer con un bombillo de 110VAC y un Triac, logrando

variar la intensidad con cambios un poco bruscos, por lo cual se decide aumentar
la cantidad de posibles intensidades de 10 a 30. Uno de los problemas
encontrados es que el Triac tarda mucho tiempo en poder conducir, razón por la
cual se consiguió un Triac de compuerta sensible que disminuye el ángulo de
disparo del mismo.

Uno de los grandes problemas encontrados durante las pruebas, es el envío de

datos desde el microcontrolador al celular, pues estos variaban en ocasiones al
parecer por la distancia y los obstáculos, incluso llegaron a un puto de quedarse
en ciclos infinitos al no quedar sincronizados para el envío y recepción de la
información.

A última hora se le agregó una nueva función a la aplicación del celular, la cual
permite crear un nuevo usuario si es la primera vez que se ejecuta el programa y
una vez creado, los datos del nombre usuario y su contraseña quedarán
guardados en una pequeña base de datos del celular.

106
 RESULTADOS FINALES

Se desarrollaron dos versiones del software Bluelight para el celular

completamente funcionales, la versión 1.0 permite ejercer control on/off desde un
celular a un hardware conectado a un computador por medio de su puerto
paralelo, específicamente una cantonera, un bombillo y un ventilador. La
aplicación del computador que lleva como nombre BluePC fue desarrollada en C#
debido a que al ser un lenguaje orientado a componentes facilitó su desarrollo y la
interacción con periféricos y puertos virtuales.

La versión 2.0 permite enviar órdenes directamente al hardware gobernado por un

microcontrolador PIC que regula la intensidad de tres lámparas incandescentes de
acuerdo al nivel seleccionado por el usuario desde su dispositivo móvil. El
lenguaje usado para la programación del microcontrolador fue ensamblador
haciendo uso de la herramienta de desarrollo MPLAB.

Se desarrollaron dos tarjetas para el hardware de cada una de las

aplicaciones ya que para la segunda versión se suprimió el uso del computador
por un microcontrolador y aunque el control también es on/off, la regulación de
intensidad se hace controlando la cantidad tiempo durante la cual las cargas (las
lámparas) reciben alimentación de voltaje.

Se implementó y modificó el diseño de una fuente de 5 voltios sin

transformador para la alimentación del hardware integrada en la misma tarjeta de
todo el sistema.

107
 CONCLUSIONES

El desarrollo de este proyecto abre las puertas a nuevas tecnologías e

ideas para el desarrollo de dispositivos domóticos, ya que es el primero de su tipo
desarrollado en la Institución Universitaria Antonio José Camacho fusionando
áreas como las telecomunicaciones haciendo uso del protocolo Bluetooth, la
electrónica y el desarrollo de software, específicamente para dispositivos móviles.

Para mejorar el corto alcance del Bluetooth Clase 2 del celular que es de
aproximadamente 10 metros, debió usarse un módulo Bluetooth Clase 1 de la
empresa SparkFun que permite hacer control a una distancia de 25 metros con
línea de vista.

El uso del protocolo RFCOMM hizo aún más fácil la comunicación con el
microcontrolador pues este emula el protocolo de puerto serie RS-232.

Para un mejor control de las luces y un mayor número de intensidades, es

necesario usar un Triac de compuerta (gate) sensitiva, ya que se puede disparar
en un ángulo de disparo menor.

El uso de la tecnología Bluetooth no genera ningún tipo de costo al usuario

debido a que se usa una banda de frecuencia sin licencia para aplicaciones
médicas, científicas e industriales.

La aplicación Bluelight V2.0 solo podrá ser ejecutada en equipos móviles

con soporte Java perfil MIDP 2.0, configuración CLDC 1.1 y que posean
conectividad Bluetooth.

108
 Los entornos de desarrollo usados para el desarrollo del software del celular
y del microcontrolador son el NetBeans IDE 6.5 y el MPLAB 8.30 respectivamente.
Por un lado el NetBeans provee librerías para el desarrollo de aplicaciones en
J2ME, además de la herramienta Sun Java(TM) Wireless Toolkit 2.5.2 for CLDC
que es una plataforma de emulación de dispositivos inalámbricos. Por otro lado, el
MPLAB es un software provisto por la empresa Microchip y permitió hacer la
depuración del software junto con el hardware por medio del programador ICSP.
Una ventaja en común es que ambas aplicaciones son de libre distrib ución, por lo
cual no se requiere ningún tipo de licencia.

109
 BIBLIOGRAFÍA

[Arph06] ARPHEAN, Nih. Tutorial para aplicaciones móviles J2ME con NetBeans y
Mobility Pack. [En línea]. Publicado en Abril de 2006. Disponible en:
<http://wainu.ii.uned.es:8081/WAINU/canal-programacion/tutoriales/java/tutorial-
j2me.pdf> [Consultado el 10 de Junio de 2008].

[BLUE08] Bluetooth SIG, Inc. Bluetooth, Descripción general. [En línea]. 2008.
Disponible en: <http://spanish.bluetooth.com> [Consultado el 12 de Mayo de
2008].

[Borc04] BORCHES Juzgado, Pedro. JAVA 2 Micro Edition Soporte Bluetooth. [En
línea]. 2004. Disponible en:
<http://www.it.uc3m.es/celeste/docencia/j2me/tutoriales/bluetooth/EstudioTecnolog
ico1_0.pdf> [Consultado el 20 de Mayo de 2008].

[Buen07] BUENAVENTURA, P; Perdomo, C. Sistema de control lumínico para una

vivienda por acceso remoto. Proyecto de grado. Institución Universitaria Antonio
José Camacho. Santiago de Cali, 2007.

[Cava07] CAVALER Ghisi, Bruno. Marge: Framework para integración de

aplicaciones JAVA vía Bluetooth. [En línea]. 2007. Disponible en:
<https://marge.dev.java.net/source/browse/*checkout*/marge/trunk/docs/pt-BR/tcc-
marge.pdf?rev=180> [Consultado el 05 de Agosto de 2008].

[Dide04] DIDELES, Myra. Bluetooth: A Technical Overview. [En línea]. 2004.

Disponible en: < http://www.acm.org/crossroads/xrds9-4/blue.html> [Consultado el
26 de Marzo de 2009]

110
[EBLU09] EXPLÍCAME, “Explícame: Qué significa Bluetooth”. [En línea].
Disponible en: < http://www.explicame.org/content/view/25/1/1/0/> [Consultado el
19 de Marzo de 2009]

[Flor07] FLÓREZ Aristizábal, Leandro. Diseño e implementación de un sistema

para el control de la iluminación del hogar por medio de Teledomótica. Proyecto de
grado. Institución Universitaria Antonio José Camacho. Santiago de Cali, 2007.

[Galv03] GÁLVEZ Rojas, Sergio; Ortega Díaz, Lucas. JAVA a Tope. Java 2 Micro
Edition. [En línea]. Disponible en: < http://www.lcc.uma.es/~galvez/J2ME.html>
[Consultado el 11 de Julio de 2008].

[Gime04] GIMENO BRIEBA, Alberto. JSR-82: Bluetooth desde Java. 2004. [En
línea] <http://www.javahispano.org/contenidos/archivo/150/tooth.zip> Consultado
el 05 de Febrero de 2009.

[Guer04] GUERRERO, Fabio y otros. Diseño de hardware semi-embebido para la

operación de una red inalámbrica Bluetooth. Revista Ingeniería y Competitividad,
Volumen 5: No. 2: Artículo 6. Universidad del Valle. Santiago de Cali, 2004.

[Hena02] HENAO, David. Introducción a los microcontroladores. [En línea].

Publicado en Noviembre de 2002. Disponible en:
<http://www.monografias.com/trabajos12/microco/microco.shtml> [Consultado el
05 de Marzo de 2009]

[Hole09] HOLE, Kjell J. BLUETOOTH. [En línea]. Publicado en Febrero de 2009.

Disponible en: <http://www.kjhole.com/Standards/BT/BTdownloads. html>
[Consultado el 10 de Marzo de 2009]

111
[Iaco05] IACONO, Matías. Desarrollo para dispositivos móviles. [En línea].
Publicado en Febrero de 2005. Disponible en:
<http://www.netveloper.com/contenido2.aspx?IDC=166_0> [Consultado el 08 de
Mayo de 2008].

[Jime05] JIMÉNEZ, José Juan. Evolución e historia de la telefonía celular. [En

línea]. Publicado en Marzo de 2005. Disponible en:
<http://www.monografias.com/trabajos14/celularhist/celularhist.shtml> [Consultado
el 09 de Mayo de 2008].

[Klin04] KLINGSHEIM, André N. J2ME Bluetooth Programming. 2004. Tesis de

Maestría. University of Bergen, Bergen, 2004.

[Lina04] LINARES, R; Quijano, J. Implementación del protocolo Bluetooth para la

conexión inalámbrica de instrumentos electrónicos programables. [En línea]. 2004.
Disponible en: < http://ohm.utp.edu.co/bluetooth/ > [Consultado el 05 de Abril de
2008].

[Mata07] MATA Ramírez, Pablo. “Bluetooth”. [En línea]. 2007. Disponible en

<http://www.monografias.com/trabajos43/tecnologia-bluetooth/tecnologia-
bluetooth.shtml> [Consultado el 04 de Abril de 2008].

[Mart05] MARTÍNEZ, Ulises y otros. Software para teléfonos celulares. Una

realidad. [En línea]. Publicado en Septiembre de 2005. Disponible en:
<http://www.sg.com.mx/content/view/575/> [Consultado el 08 de Mayo de 2008].

[Maya03] MAYA Coral, Ricardo Andrés y otros. Implementación de una red

inalámbrica Bluetooth. [En línea]. 2003
<www.univalle.edu.co/~telecomunicaciones/trabajos_de_grado/informes/tg_Oscar
Rodriguez_RicardoMaya.pdf> [Consultado el 14 de Febrero de 2008].

112
[More09] MORENO Tablado, Alberto. Arquitectura de protocolos Bluetooth. [En
línea]. 2009. <[http://www.seguridadmobile.com/bluetooth/especificacion-
bluetooth/arquitectura-de-protocolo/index.html> [Consultado el 25 de Marzo de
2009].

[Oran06] ORANTOS Rodrigo, Jesús. Implementación de una aplicación para

sistemas móviles con recursos limitados. [En línea]. 2006.
<https://projectes.lafarga.cat/projects/btbattler/downloads/docs/view/35 >
[Consultado el 09 de Marzo de 2009]

[Orti04] Ortiz, C. Enrique. Using the Java APIs for Bluetooth WirelessTechnology.
[En línea]. Publicado en Diciembre de 2004.
<http://developers.sun.com/mobility/apis/articles/bluetoothintro/> [Consultado el 31
de Mayo de 2009].

[Rtc06] © Regulació Tècnica i Control, S.A. Definición de Domótica. [En línea].

Publicado en Febrero de 2006. Disponible en:
<http://www.rtcmollet.es/novedades_domotica.htm> [Consultado el 13 de Marzo
de 2008].

[Vera03] VERA, Alexánder y otros. Aplicación de las comunicaciones inalámbricas

a la Domótica. Revista Ingeniería y Competitividad, Volumen 5: No. 2: Artículo 7.
Universidad del Valle. Santiago de Cali, 2004.

[Yuca01] Compañía Tipográfica Yucateca, S.A. de C.V. Telefonía Celular. [En

línea]. Publicado en Julio de 2001. Disponible en:
<http://www.yucatan.com.mx/especiales/celular> [Consultado el 08 de Mayo de
2008].

113
ANEXO A – Programa del microcontrolador

LIST P=16F876a
INCLUDE <P16F876a.INC>

bank0 MACRO
bcf STATUS,6
bcf STATUS,5
ENDM

bank1 MACRO
bcf STATUS,6
bsf STATUS,5
ENDM

bank2 MACRO
bsf STATUS,6
bcf STATUS,5
ENDM

RX equ .7
TX equ .6
PIE_1 equ 0ch
IOCB_ equ 16h
TXSTA_ equ 18h
SPBRG_ equ 19h
OPTION_R equ 1h
OSCCON_ equ 0fh
ANSELH_ equ 9h

114
 cblock 20h
DATA_RCVD
PDel0
PDel1
luz
light0
light1
light2
LIGHTS
INTflags
cien
ciclo
endc

ORG 0
GOTOSTART
;*********************************************************************************************
; VECTOR DE INTERRUPCIONES PARA CADA CRUCE POR CERO
;*********************************************************************************************
ORG 4
btfss PIR1,5
goto ZERO_CROSS
call readBuffer
INT btfsc INTflags,0
goto ZERO_CROSS
bsf INTflags,0
movlw 088h
movwf INTCON
sleep

115
ZERO_CROSS clrf LIGHTS
clrf PORTB
bcf INTCON,2

btfsc PORTB,7
goto up
call _0.8mS
bcf INTCON,2
movlw .240
movwf TMR0
goto goON

up call _0.5mS
bcf INTCON,2
movlw .238
movwf TMR0

goON movfw PORTB

bcf INTCON,0
movlw 88h
movwf INTCON

movlw .30
movwf ciclo
ask decfsz light0,0
goto ilumine0
bsf LIGHTS,0
goto zero1

ilumine0 decf light0,0

116
 xorwf ciclo,0
btfss STATUS,2
goto zero1
btfsc LIGHTS,0
goto zero1
bsf LIGHTS,0
bsf PORTB,0
movlw .50
call _uS
bcf PORTB,0

zero1 decfsz light1,0

goto ilumine1
bsf LIGHTS,1
goto zero2

ilumine1 decf light1,0

xorwf ciclo,0
btfss STATUS,2
goto zero2
btfsc LIGHTS,1
goto zero2
bsf LIGHTS,1
bsf PORTB,1
movlw .50
call _uS
bcf PORTB,1

zero2 decfsz light2,0

goto ilumine2

117
 bsf LIGHTS,2
goto no1
ilumine2 decf light2,0
xorwf ciclo,0
btfss STATUS,2
goto no1
btfsc LIGHTS,2
goto no1
bsf LIGHTS,2
bsf PORTB,2
movlw .50
call _uS
bcf PORTB,2

;*********************************************************************************************
no1 btfss INTCON,2
goto no1
bcf INTCON,2

btfsc PORTB,7
goto up2
movlw .10
call _uS
movlw .240
movwf TMR0
goto clear

up2 movlw .238

movwf TMR0
clear clrf PORTB

118
decre decf ciclo,1
verify movlw 07h
xorwf LIGHTS,0
btfss STATUS,2
goto ask

espere goto espere

;*********************************************************************************************
; RUTINA PARA LEER DATO RECIBIDO Y VACIAR BUFFER
;********************************************************************************************
readBuffer movfw RCREG
movwf DATA_RCVD
movlw b'00001000'
xorwf PORTC,1
swapf DATA_RCVD,0
andlw 0fh
movwf luz
rrf luz,1
bcf luz,7
btfss luz,0
goto jmp
movlw 1fh
andwf DATA_RCVD,0
movwf light1
incf light1,1
return

jmp btfss luz,1

goto jmp2

119
 movlw 1fh
andwf DATA_RCVD,0
movwf light2
incf light2,1
return

jmp2 movlw 1fh

andwf DATA_RCVD,0
movwf light0
incf light0,1
return

;*********************************************************************************************
; INICIO DE PROGRAMA
;*********************************************************************************************
START bank1
movlw b'10000101' ;Rate de 64 -> TMR0 para generar 820uS
movwf OPTION_R
;movlw b'00001000'
movlw b'10000000'
movwf PORTB
bsf PIE_1,5
bcf TXSTA_,4
bsf TXSTA_,2 ;High Baud Rate (BRGH = 1)
movlw .64 ;BAUD RATE = 19200
movwf SPBRG_
clrf PORTC
;bsf IOCB_,3
bsf PORTC,7
bank0

120
 clrf LIGHTS
movlw 1h
movwf light0
movwf light1
movwf light2
clrf DATA_RCVD
clrf luz
clrf INTflags
bsf RCSTA,7
bsf RCSTA,4
clrf PORTB
clrf PORTC
bcf PIR1,5
clrf RCREG

movlw 0C0h
movwf INTCON
askAgain btfss PIR1,5
goto $-1
goto $-2

;*********************************************************************************************
; RUTINA PARA GENERAR uS
;*********************************************************************************************
_uS movwf PDel0 ;1 |
PLoop0 nop ; 1 delay
decfsz PDel0, 1 ; 1 + (1) es el tiempo 0 ?
goto PLoop0 ; 2 no, loop
nop
return ; 2+2 Fin.

121
cienmili movlw .50
movwf cien
oh call dosmili
decfsz cien,1
goto oh
return

dosmili movlw .100

movwf TMR0
revisa btfss INTCON,2
goto revisa
bcf INTCON,2
return

_0.5mS movlw .218

Movwf TMR0
revisa2 btfss INTCON,2
goto revisa2
bcf INTCON,2
return

_0.8mS movlw .194

movwf TMR0
revisa3 btfss INTCON,2
goto revisa3
bcf INTCON,2
return

END

122
ANEXO B – SOFTWARE DEL CELULAR (Clase BTMidlet)

import java.io.IOException;
import javax.microedition.midlet.*;
import javax.microedition.lcdui.*;

public class BTMidlet extends MIDlet implements

CommandListener,ItemStateListener,ConnectionListener{

Display pantalla;//Instancia del Display

Alert alertMessages;//Muestra alertas o SplashScreen
Form formLogin;//Formulario de ingreso
Form formSignUp;//Formulario de ingreso de nuevo usuario
List listLights;//Pantalla con Menu de luces
List listDevices;
Form formControl;//Pantalla para Dimmer
TextField txtUsername;//Campo de texto para nombre de usuario
TextField txtPassword;//Campo de texto para contraseña
TextField txtnewUsername;//Campo de texto para nombre de usuario
TextField txtnewPassword;//Campo de texto para contraseña
TextField txtRePassword;
Ticker marquesina;
Command cmdLogin;//Comando Login
Command cmdExit;//Comando Exit
Command cmdOk;//Comando OK
Command cmdCancel;
Command cmdSS;//Search Services
Command cmdBack;//Comando Back
Command cmdLast;//Último estado de las luces
Gauge[] Intensity;//Control de intensidad

123
 int QtyLights;
boolean[] Quantity;
HiloConexion hilo;
short i,x=0;
int[] gauges;//Arreglo con la intensidad de cada Gauge
Registro RMS;
boolean numUsuarios;

public BTMidlet(){//Constructor
cmdExit=new Command("Salir", Command.EXIT, 1);
cmdLogin=new Command("Ingresar", Command.OK, 1);
txtUsername=new TextField("Usuario ", null, 10, TextField.ANY);
txtPassword=new TextField("Contraseña", null, 10, TextField.PASSWORD);
txtnewUsername=new TextField("Usuario ", null, 10, TextField.ANY);
txtnewPassword=new TextField("Contraseña", null, 10,
TextField.PASSWORD);
txtRePassword=new TextField("Contraseña", null, 10,
TextField.PASSWORD);

alertMessages=new Alert("Bienvenid@","BIENVENIDO A
BLUELIGHT",null,AlertType.INFO);
alertMessages.setTimeout(2000);

formLogin=new Form("Ingreso");
formLogin.addCommand(cmdExit);
formLogin.addCommand(cmdLogin);
formLogin.append(txtUsername);
formLogin.append(txtPassword);
formLogin.setCommandListener(this);

124
cmdOk=new Command("OK",Command.OK,1);
formSignUp=new Form("Nuevo Usuario");
formSignUp.addCommand(cmdExit);
formSignUp.addCommand(cmdOk);
formSignUp.append(txtnewUsername);
formSignUp.append(txtnewPassword);
formSignUp.append(txtRePassword);
formSignUp.setCommandListener(this);

marquesina=new Ticker("BLUELIGHT V2.0");

cmdCancel=new Command("Cancelar",Command.CANCEL,1);
cmdLast=new Command("Último Estado",Command.OK,1);
listLights=new List("Luces", List.MULTIPLE);
listLights.addCommand(cmdExit);
listLights.addCommand(cmdOk);
listLights.addCommand(cmdLast);
listLights.append("Luz exterior", null);
listLights.append("Luz Sala Principal", null);
//listLights.append("Living Room 2 Light", null);
listLights.append("Luz Baño", null);
listLights.setCommandListener(this);

cmdSS=new Command("Conectar",Command.OK,1);
listDevices=new List("Dispositivos", List.EXCLUSIVE);
listDevices.addCommand(cmdExit);
listDevices.addCommand(cmdSS);
listDevices.setCommandListener(this);

125
 formControl=new Form("Control");
cmdBack=new Command("Atrás", Command.BACK, 1);
formControl.setItemStateListener(this);
formControl.setCommandListener(this);
//Intensity=new Gauge[4];
Intensity=new Gauge[3];
QtyLights=0;
//Quantity=new boolean[4];
Quantity=new boolean[3];
gauges=new int[3];
i=0;
for(i=0;i<3;i++)
gauges[i]=0;
hilo=new HiloConexion(this);
RMS=new Registro();
numUsuarios=RMS.getNumUsuarios();
}
public void startApp() {
marquesina.setString("BLUELIGHT Versión 2.0");
formLogin.setTicker(marquesina);
pantalla=Display.getDisplay(this);
if(numUsuarios)
pantalla.setCurrent(alertMessages,formLogin);//Empieza con mensaje
else{
marquesina.setString("Nuevo Usuario");
formSignUp.setTicker(marquesina);
pantalla.setCurrent(alertMessages,formSignUp);
}
hilo.refMidlet(this);
}

126
 public void pauseApp() {
}

public void destroyApp(boolean unconditional) {

alertMessages.setTitle("BLUELIGHT");
alertMessages.setString("Creado por:\n\n*Leandro Flórez Aristizábal\n*Alexis
Ramírez Orozco");
alertMessages.setTimeout(4000);
alertMessages.setType(AlertType.INFO);
marquesina.setString("BLUELIGHT Versión 2.0");
alertMessages.setTicker(marquesina);
pantalla.setCurrent(alertMessages);
try {
Thread.sleep(4000);
} catch (InterruptedException ex) {
ex.printStackTrace();
}
}

public void commandAction(Command cmd, Displayable display) {

String nombre = new
String(RMS.leerRegistros(1,"Usuarios"),0,RMS.leerRegistros(1,"Usuarios").length);
String pass = new
String(RMS.leerRegistros(2,"Usuarios"),0,RMS.leerRegistros(2,"Usuarios").length);
if(display==formLogin){
if(cmd==cmdLogin){
if(txtUsername.getString().equals(nombre)
&& txtPassword.getString().equals(pass)){
//Si el nombre de usuario y contraseña son correctos
/*hilo=new HiloConexion(this);//Se instancia el hilo antes de start()

127
 //para que inicie más de 1 vez
hilo.refMidlet(this);
hilo.start();
pantalla.setCurrent(listLights);*/
listDevices.deleteAll();
hilo.searchDevices();
}
else{
alertMessages.setTitle("Error");
alertMessages.setString("Usuario y/o Contraseña inválidos");
alertMessages.setTimeout(Alert.FOREVER);
alertMessages.setType(AlertType.ERROR);
marquesina.setString("BLUELIGHT Versión 2.0");
alertMessages.setTicker(marquesina);
txtPassword.setString("");
pantalla.setCurrent(alertMessages,formLogin);
}
}
else if(cmd==cmdExit){
destroyApp(true);
notifyDestroyed();
}
}

if(display==formSignUp){
if(cmd==cmdOk){
if(txtnewPassword.getString().equals(txtRePassword.getString())){

RMS.guardarRegistros(txtnewUsername.getString(),txtnewPassword.getString(),
"Usuarios");

128
 pantalla.setCurrent(formLogin);
}
else{
alertMessages.setTitle("Error");
alertMessages.setString("Contraseñas para
"+txtnewUsername.getString()+" no concuerdan");
alertMessages.setTimeout(Alert.FOREVER);
alertMessages.setType(AlertType.ERROR);
marquesina.setString("BLUELIGHT Versión 2.0");
alertMessages.setTicker(marquesina);
txtnewPassword.setString("");
txtRePassword.setString("");
pantalla.setCurrent(alertMessages,formSignUp);
}
}
else if(cmd==cmdExit){
destroyApp(true);
notifyDestroyed();
}
}

else if(display==listLights){
if(cmd==cmdOk){
hilo.searchServices("Bluelight");
i=0;
formControl.addCommand(cmdBack);
QtyLights=listLights.getSelectedFlags(Quantity);
do{
if(Quantity[i]==true){

129
 Intensity[i]=new Gauge("Intensidad "+listLights.getString(i), true, 30,
gauges[i]);
formControl.append(Intensity[i]);
}
i++;
}
while(i<3);
//while(i<4);
marquesina.setString("INTENSIDAD DE LUCES");
formControl.setTicker(marquesina);
pantalla.setCurrent(formControl);
}
else if(cmd==cmdLast){
formControl.addCommand(cmdBack);
QtyLights=listLights.getSelectedFlags(Quantity);
try {
for(i=0;i<3;i++){
if(Quantity[i]==true){
gauges[i]=Integer.parseInt(new
String(RMS.leerRegistros(i+1,"Intensidades"),0,RMS.leerRegistros(i+1,"Intensidad
es").length));
Intensity[i]=new Gauge("Intensidad "+listLights.getString(i), true,
30, gauges[i]);
formControl.append(Intensity[i]);
if(i==0)
hilo.os.write(Intensity[0].getValue());
if(i==1)
hilo.os.write(Intensity[1].getValue()|32);
if(i==2)
hilo.os.write(Intensity[2].getValue()|64);

130
 }
}
marquesina.setString("INTENSIDAD DE LUCES");
formControl.setTicker(marquesina);
pantalla.setCurrent(formControl);
} catch (IOException ex) {
ex.printStackTrace();
}
}
else if(cmd==cmdExit){
alertMessages.setTitle("Guardar");
alertMessages.setString("¿Desea guardar el estado de las luces?");
alertMessages.setTimeout(Alert.FOREVER);
alertMessages.addCommand(cmdOk);
alertMessages.addCommand(cmdCancel);
alertMessages.setType(AlertType.CONFIRMATION);
alertMessages.setCommandListener(this);
pantalla.setCurrent(alertMessages);
}
}

else if(display==listDevices){
if(cmd==cmdSS){

if(listDevices.getString(listDevices.getSelectedIndex()).equals("BLUELIGHT")){
hilo.searchServices("Bluelight");
}
else{
alertMessages.setTitle("Error");

131
 alertMessages.setString("El dispositivo seleccionado no es
BLUELIGHT");
alertMessages.setTimeout(3000);
alertMessages.setType(AlertType.ERROR);
marquesina.setString("BLUELIGHT Versión 2.0");
alertMessages.setTicker(marquesina);
pantalla.setCurrent(alertMessages,formLogin);
}
}
else if(cmd==cmdExit){
destroyApp(true);
notifyDestroyed();
}
}

else if(display==formControl){
if(cmd==cmdBack){
i=0;
formControl.deleteAll();
//for(i=0;i<4;i++)
for(i=0;i<3;i++){
if(Intensity[i]!=null)
gauges[i]=Intensity[i].getValue();//Guarda las intensidades
Intensity[i]=null;
}
pantalla.setCurrent(listLights);
}
}

if(display==alertMessages){

132
 if(cmd==cmdOk){
RMS.guardarRegistros(gauges, "RegIntensidades");//Guarda el estado
de luces en la BD
destroyApp(true);
notifyDestroyed();
}
else{
destroyApp(true);
notifyDestroyed();
}
}
}

public void itemStateChanged(Item item) {

if(item==Intensity[0]){
System.out.println("El Gauge outside requiere " + Intensity[0].getValue());
gauges[0]=Intensity[0].getValue();
try {
x=(short)Intensity[0].getValue();
hilo.os.write(x);
} catch (IOException ex) {
ex.printStackTrace();
}
}
else if(item==Intensity[1]){
System.out.println("El Gauge LR1 requiere "+Intensity[1].getValue());
gauges[1]=Intensity[1].getValue();
try {
x=(short)Intensity[1].getValue();
x=(short)(x | 32);

133
 hilo.os.write(x);
} catch (IOException ex) {
ex.printStackTrace();
}
}
else if(item==Intensity[2]){
System.out.println("El Gauge LR2 requiere "+Intensity[2].getValue());
gauges[2]=Intensity[2].getValue();
try {
x=(short)Intensity[2].getValue();
x=(short)(x | 64);
hilo.os.write(x);
} catch (IOException ex) {
ex.printStackTrace();
}
}
}

public void connectionAction(String result, int type) {

int y;
if(result.equals("OK") && type==0){
marquesina.setString("LUCES");
listLights.setTicker(marquesina);
pantalla.setCurrent(listLights);
}
else if(result.equals("BAD") && type==0){
alertMessages.setTitle("Error");
alertMessages.setString("Bluelight parece estar apagado");
alertMessages.setTimeout(3000);
alertMessages.setType(AlertType.ERROR);

134
 marquesina.setString("BLUELIGHT Versión 2.0");
alertMessages.setTicker(marquesina);
pantalla.setCurrent(alertMessages,formLogin);
}
}
}

135
ANEXO C - SOFTWARE DEL CELULAR (Clase HiloConexion)

import javax.microedition.io.*;
import java.io.*;
import javax.bluetooth.*;
import java.util.*;
import javax.microedition.lcdui.*;

public class HiloConexion extends Thread implements DiscoveryListener{

ConnectionListener listener;
StreamConnection conexion;
InputStream is;
OutputStream os;
BTMidlet BTMidlet;
LocalDevice dispositivoLocal;
DiscoveryAgent da;
Vector dispositivosEncontrados=new Vector();
Vector serviciosEncontrados=new Vector();

public HiloConexion( ConnectionListener l ) {

listener = l;
}

public void escribir( String mensaje ) {

if( os != null ) {
try {
os.write( mensaje.getBytes() );
} catch( IOException ioe ) {
}

136
 }
}

public void refMidlet(BTMidlet m){

BTMidlet=m;
}
public void searchServices(String dev){
RemoteDevice dispositivo_remoto =
(RemoteDevice)dispositivosEncontrados.elementAt(BTMidlet.listDevices.getSelect
edIndex());

try{
BTMidlet.alertMessages.setTitle("Servicios...");
BTMidlet.alertMessages.setString("Buscando servicios...");
BTMidlet.alertMessages.setTimeout(Alert.FOREVER);
BTMidlet.alertMessages.setType(AlertType.INFO);
BTMidlet.marquesina.setString("BLUELIGHT Versión 2.0");
BTMidlet.alertMessages.setTicker(BTMidlet.marquesina);
BTMidlet.pantalla.setCurrent(BTMidlet.alertMessages);
da.searchServices(null,new UUID[]{new
UUID(0x1101)},dispositivo_remoto,this);
}
catch(BluetoothStateException be){
BTMidlet.alertMessages.setTitle("Error...");
BTMidlet.alertMessages.setString("Excepción buscando servicios...");
BTMidlet.alertMessages.setTimeout(Alert.FOREVER);
BTMidlet.alertMessages.setType(AlertType.INFO);
BTMidlet.marquesina.setString("BLUELIGHT Versión 2.0");
BTMidlet.alertMessages.setTicker(BTMidlet.marquesina);
BTMidlet.pantalla.setCurrent(BTMidlet.alertMessages);

137
 }
}
public void searchDevices(){
BTMidlet.alertMessages.setTitle("Dispositivos...");
BTMidlet.alertMessages.setString("Buscando dispositivos...");
BTMidlet.alertMessages.setTimeout(Alert.FOREVER);
BTMidlet.alertMessages.setType(AlertType.INFO);
BTMidlet.marquesina.setString("BLUELIGHT Versión 2.0");
BTMidlet.alertMessages.setTicker(BTMidlet.marquesina);
BTMidlet.pantalla.setCurrent(BTMidlet.alertMessages);
dispositivosEncontrados.removeAllElements();

try{
dispositivoLocal = LocalDevice.getLocalDevice();
dispositivoLocal.setDiscoverable(DiscoveryAgent.GIAC);
da = dispositivoLocal.getDiscoveryAgent();
da.startInquiry(DiscoveryAgent.GIAC,this);
}
catch(BluetoothStateException be){
}
}
public void run() {
ServiceRecord sr = (ServiceRecord)serviciosEncontrados.elementAt(0);
String url =
sr.getConnectionURL(ServiceRecord.NOAUTHENTICATE_NOENCRYPT,
false);

try{
BTMidlet.alertMessages.setTitle("Conectando...");

138
 BTMidlet.alertMessages.setString("Espere, Bluelight está estableciendo
conexión");
BTMidlet.alertMessages.setTimeout(Alert.FOREVER);
BTMidlet.alertMessages.setType(AlertType.INFO);
BTMidlet.marquesina.setString("BLUELIGHT Versión 2.0");
BTMidlet.alertMessages.setTicker(BTMidlet.marquesina);
BTMidlet.pantalla.setCurrent(BTMidlet.alertMessages);
conexion = (StreamConnection) Connector.open( url );
is = conexion.openInputStream();
os = conexion.openOutputStream();
listener.connectionAction( "OK", 0 );
}
catch (IOException ex) {
ex.printStackTrace();
listener.connectionAction( "BAD", 0 );
}finally {
if( conexion != null ){
try {
conexion.close();
} catch (IOException ex) {
ex.printStackTrace();
}
}
}
}

public void deviceDiscovered(RemoteDevice btDevice, DeviceClass cod) {

dispositivosEncontrados.addElement(btDevice);
}

139
 public void servicesDiscovered(int transID, ServiceRecord[] servRecord) {
for(int i=0;i<servRecord.length;i++){
ServiceRecord record = servRecord[i];
serviciosEncontrados.addElement(record);
}
}

public void serviceSearchCompleted(int transID, int respCode) {

if(serviciosEncontrados.size()>0){
BTMidlet.alertMessages.setTitle("Servicios encontrados...");
BTMidlet.alertMessages.setString("Intentaré conectar");
BTMidlet.alertMessages.setTimeout(Alert.FOREVER);
BTMidlet.alertMessages.setType(AlertType.INFO);
BTMidlet.marquesina.setString("BLUELIGHT Versión 2.0");
BTMidlet.alertMessages.setTicker(BTMidlet.marquesina);
BTMidlet.pantalla.setCurrent(BTMidlet.alertMessages);
run();
}
else{
BTMidlet.alertMessages.setTitle("Servicios no encontrados...");
BTMidlet.alertMessages.setString("Error");
BTMidlet.alertMessages.setTimeout(Alert.FOREVER);
BTMidlet.alertMessages.setType(AlertType.INFO);
BTMidlet.marquesina.setString("BLUELIGHT Versión 2.0");
BTMidlet.alertMessages.setTicker(BTMidlet.marquesina);

BTMidlet.pantalla.setCurrent(BTMidlet.alertMessages,BTMidlet.listDevices);
}
}

140
 public void inquiryCompleted(int discType) {
for(int i=0;i<dispositivosEncontrados.size();i++)
{
try{
RemoteDevice dispositivoRemoto = (RemoteDevice)
dispositivosEncontrados.elementAt(i);

BTMidlet.listDevices.append(dispositivoRemoto.getFriendlyName(true),null);
BTMidlet.pantalla.setCurrent(BTMidlet.listDevices);
}catch(Exception e){
}
}
if(dispositivosEncontrados.size()==0){
BTMidlet.alertMessages.setTitle("Error...");
BTMidlet.alertMessages.setString("No se encontraron dispositivos
Bluetooth");
BTMidlet.alertMessages.setTimeout(Alert.FOREVER);
BTMidlet.alertMessages.setType(AlertType.INFO);
BTMidlet.marquesina.setString("BLUELIGHT Versión 2.0");
BTMidlet.alertMessages.setTicker(BTMidlet.marquesina);
BTMidlet.pantalla.setCurrent(BTMidlet.alertMessages,BTMidlet.formLogin);
}
}
}

141
ANEXO D – SOTWARE DEL CELULAR (Clase Registro)

import javax.microedition.rms.RecordStore;
import javax.microedition.rms.RecordStoreException;
import javax.microedition.rms.RecordStoreNotOpenException;

public class Registro {

private RecordStore rs;

public boolean numUsuarios;

public Registro(){
numUsuarios=false;
rs = null;
crearRegistros("Intensidades");
crearRegistros("Usuarios");
}

public boolean getNumUsuarios(){

return numUsuarios;
}
public void crearRegistros(String DB){
try {
rs = RecordStore.openRecordStore( DB, true );
} catch( Exception e ) {}
try {
if (DB.equals("Usuarios") && rs.getNumRecords() > 0) {
numUsuarios=true;
}
} catch (RecordStoreNotOpenException ex) {

142
 ex.printStackTrace();
}
try {
rs.closeRecordStore();
} catch (Exception ex) {
ex.printStackTrace();
}

}
public void abrirRegistros(String DB) {
try {
rs = RecordStore.openRecordStore( DB, true );
} catch( Exception e ) {}
}

public void guardarRegistros(int data[], String DB) {

byte [] registro;
deleteRegistros(DB);
abrirRegistros(DB);
try {
for( int i = 0; i < data.length; i++ ) {
registro = String.valueOf(data[i]).getBytes();
rs.addRecord(registro, 0, registro.length );
System.out.println( "+" + data[i] );
}
System.out.println( " Número de registros: " + rs.getNumRecords() );
} catch( Exception e ) {}
try {
rs.closeRecordStore();
} catch (Exception ex) {

143
 ex.printStackTrace();
}
}

public void guardarRegistros(String dataUser,String dataPass, String DB) {

byte [] registro;
deleteRegistros(DB);
abrirRegistros(DB);
try {
registro = dataUser.getBytes();
rs.addRecord(registro, 0, registro.length );
registro = dataPass.getBytes();
rs.addRecord(registro, 0, registro.length );
System.out.println( " Número de registros: " + rs.getNumRecords() );
} catch( Exception e ) {}
try {
rs.closeRecordStore();
} catch (Exception ex) {
ex.printStackTrace();
}
}

public byte[] leerRegistros(int x, String DB) {

byte[] reg={0,0,0};
abrirRegistros(DB);
try {
int num = rs.getNumRecords();
System.out.println( " Total de registros: " + num );
for( int i = 1; i <= num; i++ ) {
byte[] registro = new byte[rs.getRecordSize( i )];

144
 rs.getRecord( i, registro, 0 );
System.out.println( " +" + new String( registro, 0, registro.length ) );
}
byte[] registros = new byte[rs.getRecordSize( x )];
rs.getRecord( x, registros, 0 );
return registros;
} catch( Exception e ) {
System.out.println( " Eror en la lectura" );
}
try {
rs.closeRecordStore();
} catch (Exception ex) {
ex.printStackTrace();
}
return reg;
}
public void cerrarRegistros() {
try {
rs.closeRecordStore();
} catch( Exception e ) {}
}

public void deleteRegistros(String DB) {

try {
rs.deleteRecordStore( DB );
} catch( Exception e ) {}
}
}

145