Resumen

En esta tesis se presenta el desarrollo de un sistema de iluminación mediante la técnica

de control por ángulo de fase (dimmer) con el objetivo de llevar a cabo la atenuación
de las lámparas (AC) a través de un mando a distancia establecido por el diseño de
una aplicación en un dispositivo móvil con S.O. Android haciendo uso del protocolo de
comunicación IEEE 802.15 (Bluetooth).

iii
iv
Abstract

This thesis presents the development of a lighting system using the technique of phase
angle control (dimmer) in order to carry out the attenuation of the lamps (AC) through
a remote control set by the design an application on a mobile device with SO Android
using the communication protocol IEEE 802.15 (Bluetooth).

v
vi
Índice General

Resumen III

Abstract V

Índice de General VII

Índice de Figuras XI

Objetivo XV

Justificación XVII

Introducción XIX

1. Iluminación Eficiente 1
1.1. Introducción a la Iluminación Eficiente . . . . . . . . . . . . . . . . . . . . 1
1.1.1. Ahorro de energı́a en el hogar . . . . . . . . . . . . . . . . . . . . . 1
1.1.2. Iluminación en el hogar . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Sistemas Innovadores de Iluminación . . . . . . . . . . . . . . . . . . . . . 2
1.2.1. Sistemas de Control de Iluminación . . . . . . . . . . . . . . . . . . 3
1.3. Estructura del Sistema de Control de Iluminación: La Potencia . . . . . . . 4
1.4. Introducción a los Dimmers . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1. Dimmers diseñados con tiristores . . . . . . . . . . . . . . . . . . . 6
1.4.2. Dimmer controlado remotamente por tiristor . . . . . . . . . . . . . 7
1.4.3. Circuitos dimmer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5. Control de la Iluminación . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6. Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7. Hipótesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

vii
viii ÍNDICE GENERAL

1.8. Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.9. Organización de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2. Bluetooth 15
2.1. Descripción general de la Tecnologı́a Bluetooth . . . . . . . . . . . . . . . . 15
2.1.1. Protocolos Especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2. RFCOMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3. Perfiles Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1. Perfil Genérico de Acceso (GAP) . . . . . . . . . . . . . . . . . . . 21
2.3.2. Perfil de Puerto Serial . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3. Perfil de Aplicación de Descubrimiento de Servicio (SDAP) . . . . . 22
2.3.4. Perfil Genérico de Intercambio de Objetos (GOEP) . . . . . . . . . 22
2.4. Dispositivo Bluetooth Roving Networks . . . . . . . . . . . . . . . . . . . . 22
2.4.1. Estableciendo una conexión Bluetooth . . . . . . . . . . . . . . . . 23
2.4.2. Modos de Operación . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.3. Configuración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3. Android 29
3.1. Historia de Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2. ¿Qué es Android? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.1. Caracterı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2. Arquitectura de Android . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3. Aplicaciones Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1. Fundamentos de una aplicación . . . . . . . . . . . . . . . . . . . . 38
3.3.2. Componentes de una aplicación . . . . . . . . . . . . . . . . . . . . 39
3.4. Desarrollando aplicaciones Android . . . . . . . . . . . . . . . . . . . . . . 43
3.4.1. Entornos de Desarrollo Android . . . . . . . . . . . . . . . . . . . . 44
3.5. Estructura Básica de APP Inventor . . . . . . . . . . . . . . . . . . . . . . 48
3.5.1. Ventana de Diseño . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5.2. Editor de Bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.6. Instalación y distribución de Aplicaciones (Android Market) . . . . . . . . 69
3.6.1. Bajar Aplicaciones desde Android Market . . . . . . . . . . . . . . 69
3.6.2. Subir Aplicaciones desde Android Market . . . . . . . . . . . . . . . 70
ÍNDICE GENERAL ix

4. Aplicación ATOM y Prototipo 73

4.1. Construcción y Programación de un Dimmer . . . . . . . . . . . . . . . . . 73
4.1.1. Propuesta y explicación de Hardware . . . . . . . . . . . . . . . . . 74
4.1.2. Programa del microcontrolador y explicación . . . . . . . . . . . . . 76
4.2. Construcción y Programación de Receptor Bluetooth . . . . . . . . . . . . 76
4.2.1. Propuesta y explicación de Hardware . . . . . . . . . . . . . . . . . 77
4.2.2. Programa del microcontrolador y explicación . . . . . . . . . . . . . 78
4.3. Estableciendo Comunicación Bluetooth . . . . . . . . . . . . . . . . . . . . 79
4.3.1. Arreglo de Hardware para la prueba . . . . . . . . . . . . . . . . . . 80
4.3.2. Pruebas de conexión con HyperTerminal . . . . . . . . . . . . . . . 82
4.4. Diseño y Desarrollo de la aplicación ATOM . . . . . . . . . . . . . . . . . 84
4.4.1. Propuesta y descripción de la aplicación . . . . . . . . . . . . . . . 85
4.4.2. Desarrollo y esquema de la aplicación . . . . . . . . . . . . . . . . . 86
4.4.3. Prueba y depuración con HyperTerminal en la PC . . . . . . . . . . 87
4.5. Integración de todas las etapas del sistema . . . . . . . . . . . . . . . . . . 87
4.5.1. Diseño del hardware conjunto . . . . . . . . . . . . . . . . . . . . . 88

Pruebas y Resultados 91

Conclusiones 95
4.6. Conclusiones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
4.7. Trabajos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

Referencias 97

Apéndice 98

99
x ÍNDICE GENERAL
Índice de Figuras

1.1. Esquema de un dimmer analógico. . . . . . . . . . . . . . . . . . . . . . . . 7

1.2. Diagrama a bloques de dimmer controlado remotamente por tiristores. . . 9
1.3. Diagrama a bloques de un dimmer profesional. . . . . . . . . . . . . . . . . 10
1.4. Interfaz entre el operador y el sistema de iluminación. . . . . . . . . . . . . 11

2.1. Compañı́as que forman parte del SIG. . . . . . . . . . . . . . . . . . . . . . 15

2.2. Bluetooth Special Interest Group. . . . . . . . . . . . . . . . . . . . . . . . 16
2.3. Stack de Protocolo Bluetooth. . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4. Modelo de referencia OSI y Bluetooth. . . . . . . . . . . . . . . . . . . . . 20
2.5. RFCOMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.6. Varios puertos seriales emulados mediante RFCOMM . . . . . . . . . . . . 22
2.7. Los Perfiles Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.8. Módulo Bluetooth Roving Networks . . . . . . . . . . . . . . . . . . . . . . 24

3.1. Andy Rubin creador de Android. . . . . . . . . . . . . . . . . . . . . . . . 30

3.2. Arquitectura de S.O. Android. . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3. Capa del Kernel de Linux. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4. Capa de la maquina virtual Dalvik. . . . . . . . . . . . . . . . . . . . . . . 33
3.5. Capa de todas las Librerias. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.6. Librerias Abstractas de Hardware. . . . . . . . . . . . . . . . . . . . . . . . 36
3.7. Capa de Aplicaciones Framework. . . . . . . . . . . . . . . . . . . . . . . . 37
3.8. Última Capa de Aplicaciones. . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.9. Conjunto de Activities. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.10. Servicios en Segundo Plano. . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.11. Ejemplo de Proveedor de Contenido. . . . . . . . . . . . . . . . . . . . . . 41
3.12. Notificación de Broadcast. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

xi
xii ÍNDICE DE FIGURAS

3.13. Ejemplo 1 de Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.14. Ejemplo 2 de Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.15. Ejemplo 3 de Intent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.16. Entorno de Desarrollo Ecplipse. . . . . . . . . . . . . . . . . . . . . . . . . 45
3.17. APP Inventor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.18. APPInventor Learn. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.19. Estructura de APP Inventor. . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.20. Crear el primer Proyecto en App Inventor. . . . . . . . . . . . . . . . . . . 51
3.21. Ventana de Diseño. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.22. Paleta de Componentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.23. Componentes Básicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.24. Componentes Multimedia. . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.25. Componentes Animados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.26. Componentes Social. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.27. Componentes de Sensores. . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.28. Componentes de Organización. . . . . . . . . . . . . . . . . . . . . . . . . 57
3.29. Componentes de LEGO MINDSTORMS. . . . . . . . . . . . . . . . . . . . 58
3.30. Otros Componentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.31. Not Ready for Prime Time. . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.32. Descripción de Componentes. . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.33. Area de Trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.34. Seccion de Componentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.35. Seccion de Propiedades. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.36. Barra de Herramientas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.37. Boton para abrir Editor de Bloques. . . . . . . . . . . . . . . . . . . . . . . 64
3.38. Editor de Bloques. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.39. My Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.40. Build-In. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.41. Advanced. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.42. Área de Trabajo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.43. Barra de Herramientas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.44. Emulador Android. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.45. Android Market. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.46. Aplicacion Android Market. . . . . . . . . . . . . . . . . . . . . . . . . . . 70
ÍNDICE DE FIGURAS xiii

4.1. Microcontrolador para Dimmer. . . . . . . . . . . . . . . . . . . . . . . . . 74

4.2. Circuito Propuesto. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3. Placa PCB con Elementos, Pistas y Puentes. . . . . . . . . . . . . . . . . . 75
4.4. Microcontrolador para Receptor Bluetooth. . . . . . . . . . . . . . . . . . . 77
4.5. Hardware minimo para operar PIC18F4550. . . . . . . . . . . . . . . . . . 78
4.6. Placa PCB con Elementos y Pistas . . . . . . . . . . . . . . . . . . . . . . 79
4.7. Modulo Bluetooth adaptado por Sparkfun. . . . . . . . . . . . . . . . . . . 80
4.8. Módulo Bluetooth BlueSMiRF 01. . . . . . . . . . . . . . . . . . . . . . . . 81
4.9. Módulo Bluetooth BlueSMiRF 02. . . . . . . . . . . . . . . . . . . . . . . . 81
4.10. Conexión de de Módulos 01 y 02. . . . . . . . . . . . . . . . . . . . . . . . 81
4.11. Ventanas de Configuración HyperTerminal. . . . . . . . . . . . . . . . . . . 83
4.12. Módulo BT en modo comando HyperTerminal. . . . . . . . . . . . . . . . . 84
4.13. Ventanas Principal de la Aplicación. . . . . . . . . . . . . . . . . . . . . . . 85
4.14. Area de Trabajo en el Desarrollo de la Aplicación. . . . . . . . . . . . . . . 86
4.15. Editor de Bloques de la Aplicación. . . . . . . . . . . . . . . . . . . . . . . 87
4.16. Pruebas y Depuración de Comunicación. . . . . . . . . . . . . . . . . . . . 88
4.17. Propuesta de Hardware Conjunto . . . . . . . . . . . . . . . . . . . . . . . 88
4.18. Diagrama Eléctrico del Sistema Completo . . . . . . . . . . . . . . . . . . 89
4.19. Placa PCB del Sistema Completo . . . . . . . . . . . . . . . . . . . . . . . 90

4.20. Tabla de Conexión . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.21. Tabla de Envio de Datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.22. Tabla de Comparación de Lámparas. . . . . . . . . . . . . . . . . . . . . . 93
4.23. Tabla de Comparación de Lámparas. . . . . . . . . . . . . . . . . . . . . . 93
xiv ÍNDICE DE FIGURAS
Objetivo

Diseñar e implementar un sistema de control de iluminación para regular la intensidad

de lámparas de bajo consumo de energı́a por medio de dispositivos dimmer, a partir de
una aplicación para el S.O Android y el protocolo de comunicación Bluetooth.

Derivados del objetivo general se plantean los siguientes objetivos especı́ficos:

Desarrollar un receptor con comunicación Bluetooth basado en un microcontrolador

PIC18F4550.

Construir un dimmer basado en un microcontrolador PIC16F648A y una etapa de

potencia con tiristores que son disparados por la técnica de control por ángulo de
fase.

Diseñar una aplicación basada en el Entorno de Desarrollo App Inventor para el

S.O Android.

Establecer una comunicación inalámbrica mediante el protocolo IEEE 802.15 (Blue-

tooth).

Contribuir con una opción más para el ahorro de la energı́a eléctrica.

xv
xvi OBJETIVO
Justificación

No es posible concebir el mundo actual sin el uso de la iluminación artificial. Recordan-

do que la energı́a eléctrica, particularmente en México, proviene de la quema del petróleo
en más del 70 %; dada la importancia que la iluminación representa en el consumo de la
electricidad y el avance tecnológico en la materia, la justificación de este trabajo recae
sobre el ahorro de la energı́a eléctrica a través del desarrollo e innovación de la ciencia y
la tecnologı́a.

xvii
xviii JUSTIFICACIÓN
Introducción

Conforme la tecnologı́a avanza a pasos agigantados, y los sistemas embebidos se en-

cuentran en cualquier rincón al que volteemos siendo parte de nuestra vida cotidiana,
vemos como la tecnologı́a “inquieta” ante muchas posibilidades, es cada vez más sor-
prendente y busca integrar una cantidad inmensa de subsistemas en un simple pero a la
vez complejo artefacto, que mejor ejemplo de esto que los teléfonos celulares que en un
principio su objetivo y funcionalidad era simplemente hacer llamadas; posteriormente se
sumo los mensajes de texto, ¿recuerdan esas interfaces planas y con un solo tono de color
en pantalla?; haciendo un brinco no tan grande en el tiempo a nuestra actualidad, estos
dispositivos hacen prácticamente todo lo que el usuario exige; a tal grado de llamarse
Smartphone o teléfonos inteligentes.

En estos dispositivos podemos encontrar sistemas operativos bastante complejos que

se encargan de ejecutar y administrar tareas y hardware, tales como cámaras de HD, gra-
bador de voz, antenas de red Wifi, Bluetooth, radio, reproductores mp3, redes sociales,
contactos, GPS, procesar imágenes y videos de alta definición, programar alarmas, abrir
archivos, navegar por la web; en fin una variedad inmensa de aplicaciones que pueden ser
ejecutados desde estos equipos.

De aquı́ nace la inquietud de desarrollar este proyecto, viendo la tendencia de la tec-

nologı́a a la integración de muchas tareas en un solo dispositivo pensamos ¿Por qué no
sumergir a estos Smartphone a un entorno de control para Smart-home? La siguiente pre-
gunta en cuestión fue ¿A qué rubro seria dedicado; al ahorro de energı́a, a la seguridad,
a la comodidad o una mezcla de estos? Teniendo estas cuestiones en la mente decidimos
enfocarlo a la comodidad y al ahorro de energı́a que hoy en dı́a es un tema del cual nos
debemos de ocupar seriamente.

xix
xx INTRODUCCIÓN

Ası́ después de muchas ideas se pudo consolidad y delimitar claramente las carac-
terı́sticas del proyecto. Se enfoca al control de un sistema de iluminación mediante una
aplicación en el Sistema Operativo Android para móviles. Y en ¿Dónde está el ahorro de
energı́a y la comodidad? El primer aspecto se cubre al utilizar DIMMERS y Lámparas
Fluorescentes Compactas Dimmeables (o Lámparas LED Dimmeables con entrada E27)
que consumen un mı́nimo de energı́a; en cuanto al aspecto de la comodidad, abarca el
hecho de que, mientras este mandando mensajes o checando sus mail en el Smartphone,
pueda apagar, encender o regular la intensidad de la luz de cualquier habitación.
Capı́tulo 1

Iluminación Eficiente

1.1. Introducción a la Iluminación Eficiente

Eficiencia energética es la relación entre la cantidad de energı́a consumida y los produc-

tos y servicios finales obtenidos. Se puede mejorar mediante la implantación de diversas
medidas tecnológicas, de gestión y de hábitos de consumo.

Los individuos y las organizaciones que son consumidores directos de la energı́a de-
berı́an desear ahorrar energı́a para reducir costos energéticos y promover la sostenibilidad
económica y ambiental. Los usuarios industriales y comerciales suelen desear aumentar
eficacia y maximizar ası́ su beneficio.

1.1.1. Ahorro de energı́a en el hogar

Los usos y costumbres diarios habituales que se hacen en la vivienda puede conllevar
a un ahorro considerable de energı́a si se cambian las actitudes y se es consciente del
consumo real y del necesitado. En la mayorı́a de los casos basta con la elección de un elec-
trodoméstico de bajo consumo, o de una racionalización del consumo de la calefacción,
del aire acondicionado y del agua caliente.

Los electrodomésticos tienen mucha importancia en el ahorro de energı́a doméstico.

1
2 CAPÍTULO 1. ILUMINACIÓN EFICIENTE

1.1.2. Iluminación en el hogar

Es importante seguir una serie de consejos básicos, como son: utilizar bombillas de
bajo consumo en aquellas dependencias de la vivienda que tengan que permanecer mucho
tiempo encendidas; siempre que sea posible aprovechar la iluminación natural; usar la
luz solo cuando se necesite y no dejar luces encendidas en habitaciones que no se estén
utilizando.

Además hay que tener en cuenta que las lámparas halógenas consumen mucha más
energı́a que otros tipos de bombillas y disipan más calor, los tubos fluorescentes duran
hasta 10 veces más que las bombillas tradicionales y son muy eficientes energéticamente,
por lo que si se va a tener una lámpara fluorescente apagada menos de 20 minutos, es
mejor dejarla encendida. El empleo de bombillas de bajo consumo supone un ahorro de
hasta un 80 % respecto a las convencionales.

Existen nuevas tecnologı́as de luminarias como los diodos emisores de luz (LED),
ası́ como diversas tecnologı́as de control de la iluminación: regulación de potencia, sensores
de proximidad, combinación luz natural - luz artificial, doble iluminación e iluminación
selectiva que producen ahorros considerables.

1.2. Sistemas Innovadores de Iluminación

Con el nombre de Sistemas Innovadores se engloba una serie de dispositivos concebi-
dos para mejorar la eficiencia y las condiciones de servicio en instalaciones de alumbrado,
mediante la introducción de nuevas funciones, haciéndolas más flexibles, confortables y
atractivas. Innovador hace referencia a aquello distinto de lo convencional y que aún no
se ha generalizado para las instalaciones corrientes.

Los sistemas innovadores comprenden una diversidad de dispositivos que van desde lu-
minarias, equipos auxiliares y sistemas de control, hasta ventanas inteligentes, lumiductos
y colectores de luz solar. Una clasificación general permite diferenciar inicialmente entre
los sistemas innovadores del alumbrado artificial y los sistemas innovadores del alumbrado
natural. Aunque muchos de ellos aún se hallan en etapa experimental y de perfecciona-
miento, las expectativas que generan sobre eficiencia y mejoramiento en la calidad de
1.2. SISTEMAS INNOVADORES DE ILUMINACIÓN 3

servicio de las instalaciones de alumbrado permiten vaticinar que en un futuro cercano

no podrán estar ausentes en ningún tipo de instalación de luz. Estas circunstancias, y la
insuficiente información disponible, justifican la importancia de una mayor y más objetiva
divulgación de ellos.

1.2.1. Sistemas de Control de Iluminación

En un sistema de control proporcional, la señal de control determina cuál es la propor-
ción de atenuación del flujo luminoso de las lámparas, disminuyéndoles su potencia. La
relación directa entre flujo luminoso y potencia, denominada eficiencia luminosa, puede
modificarse con la regulación del flujo luminoso de la lámpara. Si se realiza la regulación
a un tubo fluorescente con un dispositivo que no provoque distorsiones en la forma de
corriente de alimentación de la lámpara, la eficacia puede aumentar hasta en un 12 %.
Equipos de mala calidad no sólo empeoran la eficacia luminosa con la atenuación, sino
que pueden afectar la duración de la lámpara. No todas las lámparas son aptas para la
regulación de su flujo luminoso sin que experimenten algún tipo de inconvenientes. Re-
cientes desarrollos electrónicos permiten hacer funcionar tubos fluorescentes en regı́menes
de baja potencia, por lo tanto, no hay limitaciones en el grado de atenuación que puede
realizarse, desde el 100 % a valores tan bajos como 1 %, sin parpadeos.

Algunos fabricantes han desarrollado lı́neas especiales de lámparas con capacidad de

ser atenuadas, para ser usadas con balastos de alta frecuencia preferentemente en insta-
laciones que posean regulación de flujo.

Limitaciones

Como toda tecnologı́a de innovación, corresponden mencionarse limitaciones e incon-

venientes derivados de ella, con el objeto de evitar que se vea desprestigiada. Los incon-
venientes, todos superables desde el punto de vista tecnológico, sobre los que el diseñador
o proyectista debe tomar las precauciones necesarias son:

Carencia de métodos apropiados para el diseño de instalaciones.

Dificultad en la predicción del ahorro que es posible lograr.

Funcionamiento no deseado de las instalaciones, sea en el encendido o apagado de

luces.
4 CAPÍTULO 1. ILUMINACIÓN EFICIENTE

Dificultad de especificaciones y calidad de los equipos.

Reacción adversa de los ocupantes a este tipo de instalación.

Un tema importante es el de la calidad de los equipos y confiabilidad de las insta-

laciones, especialmente cuando los sistemas de control incluyen dispositivos electrónicos.
Polución electromagnética, prematuro envejecimiento de lámparas y fallas catastróficas
son algunos de los problemas que se pueden presentar debido a la mala calidad de dim-
mers o sensores ocupacionales. Podrı́a argumentarse que éste es un problema que puede
solucionarse con apropiados estándares de calidad, lo cual es cierto. Sin embargo, no es
fácil la normalización de dispositivos de relativamente nuevo diseño.

No existe por el momento norma para atenuadores (dimmers) a nivel internacional.

La mayorı́a de los componentes de los sistemas de control se hallan aún sin normalización.

Las reacciones adversas, de los ocupantes de locales equipados con sistemas de control,
parecen ser el punto más limitante de esta tecnologı́a. Afortunadamente la mayorı́a de las
quejas se originan principalmente en el mal funcionamiento de estos equipos, ya sea porque
incurren en apagados incorrectos o bien incluyen operaciones frecuentes y distractivas, tal
como se comentó anteriormente.

1.3. Estructura del Sistema de Control de Ilumina-

ción: La Potencia
La función del Dimmer es regular la tensión. Es decir, la capacidad de hacer llegar a
una lámpara una cantidad menor de energı́a que el total: Desde 110V como intensidad
final o Full, hasta el apagado total o “cero volts” medido en porcentajes. Por ende, si
regulo un dimmer al 50 % a la lámpara le llegarán aproximadamente 55V y la misma
emitirá la mitad de luz de su capacidad. Ası́, la potencia permitirá trabajar cómodamen-
te con la energı́a, regularla, dividirla o agruparla en canales. Generalmente la Potencia
está desarrollada a través de los Racks o “Paquetes” de Dimmers.

Los Dimmers se clasifican según la cantidad de canales y por la capacidad de fuerza

total por cada canal. Se los puede encontrar en 1000W, 2000W, 2500W, 4000W, 6000W,
1.4. INTRODUCCIÓN A LOS DIMMERS 5

etc. Cada grupo de luces estará conectado al mismo canal, y encenderán juntas. Si se
quisiera que las seis lámparas encendieran en diferentes intensidades al mismo tiempo
deberé colocar cada artefacto en un canal distinto.

Como ya mencionamos anteriormente, los Racks son equipos de varios canales de

Dimmer. Tratando de estandarizarlos, generalmente se presentan en múltiplos de 6 o 12
canales. Entonces, un Sistema de Potencia se selecciona por cantidad de canales y por
“capacidad” (watts por canal).

Con frecuencia se escucha hablar sobre Dimmers Digitales y Dimmers Analógicos, pero
los dimmers son siempre análogos.

1.4. Introducción a los Dimmers

Los dimmers son dispositivos electrónicos especializados capaces de regular la intensi-
dad de fuentes eléctricas de luz aplicando la técnica de conmutación. Los dimmers fueron
inventados en 1890, por Glanville Woods para evitar los incendios en los teatros ya que los
métodos utilizados para controlar la intensidad de las lámparas eran peligrosos y frecuen-
temente causaban incendios [Smith, 2005], Woods buscó un método económico y efectivo
para regular la intensidad de las luces y ası́ creó la primera versión del dimmer moderno,
el cuál fue la resistencia variable.

Con la invención del tiristor, los dimmers se transformaron en pequeños, económicos

y eficientes. Los tiristores se usaron en el control de la iluminación en la primera parte
de de la década de los 60s y durante más de 40 años han formado la base de control de
iluminación profesional, ya que son más robustos y tienen la capacidad de soportar altas
corrientes repentinas causadas por los fallos en el filamento de las lámparas de tungsteno.
Los dimmers profesionales usualmente están construidos sobre un principio modular. Ca-
da módulo representa uno o dos canales de Dimmer. Los módulos son independientes, y
están diseñados para ser reemplazados fácilmente, ya sea por conexión de enchufe o por
terminales de fácil conexión. Los dimmers profesionales pueden resistir ciertas perturba-
ciones producidas por variaciones en la frecuencia de la fuente [Simpson, 2003].

Todos los sistemas dimmers operan sobre la base de dos técnicas para limitar el flujo
6 CAPÍTULO 1. ILUMINACIÓN EFICIENTE

de corriente en las lámparas, los cuales son:

Variación de voltaje.

Variación en el intervalo de tiempo, en el cual la corriente fluye durante cada ciclo

corriente alterna.

En la siguiente sección se presenta la segunda técnica por ser la más difundida y es la

que se aplica en el presente trabajo.

1.4.1. Dimmers diseñados con tiristores

Todos los circuitos dimmer sobre la base de tiristores requieren que el dispositivo se
dispare en algún punto predeterminado después que la señal sinusoidal cruza por cero.
La técnica es conocida como control por ángulo de fase, la cual consiste en controlar el
tiempo de disparo o de conducción del tiristor, para regular la corriente que se entrega a
la carga (o lámpara) y de esta manera, controlar la potencia que consume.

Un triac es una forma de tiristor que permite que ambos semiciclos de la corriente
alterna (CA) fluyan a través de la carga. El triac es disparado cuando una señal de baja
energı́a se aplica en su terminal G (Gate). El semiciclo positivo de la señal de CA pa-
sará por el triac siempre que G sea activo, de esta manera, la corriente circulará de arriba
hacia abajo (terminal MT2) como se muestra en el circuito de la Figura 1.10. Mientras que
en el semiciclo negativo pasará por el triac siempre y cuando exista una señal de disparo
en la entrada G, de esta manera la corriente circulará de abajo hacia arriba (terminal
MT1).

El dispositivo que proporciona la señal G en ambas direcciones de la corriente es

conocido como diac. El diac es un diodo bidireccional que únicamente permite disparar
el flujo de corriente o voltaje cuando este ha encontrado un cierto nivel preestablecido.
El diac controla el voltaje en la entrada G del triac y permite la transición de prendido a
apagado de manera suave. El intervalo de tiempo (retraso) a partir del cruce por cero de
la corriente alterna hasta el tiempo en el cual el triac se dispara se conoce como ángulo
de disparo y se representa por beta . Los rangos de beta varı́an de 0◦ (máxima potencia)
hasta 180◦ (mı́nima o nula potencia). Controlando el ángulo de disparo, el voltaje rms
1.4. INTRODUCCIÓN A LOS DIMMERS 7

suministrado a la carga cambia y por lo tanto, la intensidad de las luces también cambia
(Fig.1.1).

Figura 1.1: Esquema de un dimmer analógico.

Cuando la corriente alterna cambia su dirección, el triac se apaga; esto hace que la
corriente en la carga sea cero en cada semiciclo de CA. Por lo tanto, para que la lámpara
se active continuamente, el triac necesita dispararse durante ambos semiciclos de la onda
sinusoidal CA; para asegurar que la carga promedio de la corriente no sea cero.

1.4.2. Dimmer controlado remotamente por tiristor

En la (Fig.1.2) se muestra el diagrama a bloques de un dimmer controlado remota-
mente por tiristores.
8 CAPÍTULO 1. ILUMINACIÓN EFICIENTE

El diagrama es el mismo sin tener en cuenta si el circuito final es digital, analógico o

hı́brido. Los circuitos de control consisten de tres partes principales:

1. Un detector de cruce por cero, que identifica el momento en el cual la corriente

alterna de la lı́nea cruza por cero. Para controles de fase esto es la información de
temporización esencial, ya que el disparo de los tiristores es medido desde este punto.

2. Un circuito de disparo, que compara el momento en que se detecta el cruce por cero
con la señal de entrada, y dispara los tiristores después del retardo de fase apropiado.

3. Un circuito de control. Este puede ser únicamente un circuito de voltaje de referen-

cia, que permita al dimmer analógico ser controlado por una señal analógica de 0-10
V. Mientras que en un dimmer analógico automático, el circuito incluye circuitos de
tiempo tipo rampa para producir desvanecimiento automáticos a niveles programa-
dos.

El aislamiento entre el circuito de disparo y el tiristor es logrado correctamente en

el momento de disparo. Antes de la llegada de opto-aisladores confiables de voltaje alto.
En la actualidad el disparo se realiza usando tiristores opto aislados (para disparo de
tiristores) o triacs opto aislados (para disparo de triacs) (Fig.1.2).
Como con todos los circuitos de potencia, los problemas se incrementan cuando los
voltajes o corrientes se conmutan a velocidades muy altas. Las altas velocidades de conmu-
tación de la corriente y la anti-simetrı́a de los disparos del Triac genera ruido, armónicos
e interferencia electromagnética. El ruido del circuito dimmer podrá ser transmitido en
circuitos de potencia y causar problemas. Los armónicos pueden estar en la gama de
los MHz dependiendo de los niveles de potencia del sistema y del número de fases en el
mismo, y puede causar calentamiento en los transformadores y conductores. Además si
se usan microprocesadores para el control del circuito dimmer, las interferencias pueden
afectar severamente el desempeño del sistema digital. Además el flujo del campo magnéti-
co también causa vibraciones en la estructura del foco el cual se podrı́a dañar. El circuito
dimmer debe contener filtros de alta frecuencia para remover algunos de los armónicos y
ruido en el circuito [Simpson, 2003].
1.4. INTRODUCCIÓN A LOS DIMMERS 9

Figura 1.2: Diagrama a bloques de dimmer controlado remotamente por tiristores.

1.4.3. Circuitos dimmer.

Un microcontrolador (MCU) proporciona un método sencillo y económico de imple-
mentar la funcionalidad de un dimmer [Gadre, 2001]. Este puede procesar casi simultánea-
mente las entradas de cualquiera de las señales de control requeridas en las luminarias, y
controla la potencia para cada uno de los canales individuales.

La tarea principal del MCU es controlar en tiempo real el ángulo de la fase. Para
ello su firmware debe ejecutar dos tareas: calcular el retraso entre el cruce por cero y el
encendido del triac, conectándolo en el punto apropiado en el ciclo de CA [Couedic, 2000],
[Microchip, 1997].

El funcionamiento digital del dimmer profesional introduce varios beneficios entre los
que se encuentran:

Asegura que el rendimiento en un dimmer muti-canal, todos los dimmers tendrán

un rendimiento equivalente.

Permite la supervisión constante en la intensidad de la corriente y de otras señales

de control de las luces
10 CAPÍTULO 1. ILUMINACIÓN EFICIENTE

Simplifica el uso de un control tipo multı́plex.

Se muestra el diagrama a bloques de un dimmer profesional. El diagrama es repre-

sentativo y muestra una gama de funciones. No todos los dimmers incluyen todas las
mostradas y algunos dimmers pueden incluir funciones que no se incluyen aquı́.

Este diseño está basado en un microprocesador o microcontrolador. El dimmer en este

diseño todavı́a requiere de tiristores y circuitos de disparo aislados y un detector de cruce
por cero (Fig.1.3).

Figura 1.3: Diagrama a bloques de un dimmer profesional.

1.5. Control de la Iluminación

La parte central de toda instalación de iluminación es el sistema de control o consola
de iluminación. Por medio de éste, se logra la regulación de los dimmers que a su vez
regulan la intensidad de las luminarias para obtener un cierto nivel de brillantez y de esta
manera producir el efecto visual deseado (Fig.1.4).
El estado de cada dimmer se establece por el operador desde la consola, se envı́an las
señales de control para cada uno de los dimmers, que a su vez regulan la intensidad de
1.6. PLANTEAMIENTO DEL PROBLEMA 11

Figura 1.4: Interfaz entre el operador y el sistema de iluminación.

las luces. La consola se comunica con los dimmers para que las luces adquieran el efecto
deseado por el operador [Scott, 1996].

1.6. Planteamiento del Problema

En la actualidad, el avance de la tecnologı́a crece desmesuradamente y al mismo tiem-
po los recursos energéticos y naturales disminuyen, por lo que el enfoque de estos avances
tecnológicos ha volteado la mirada y enfocado su atención a las alternativas de los recursos
energéticos y a proponer medidas para ahorrar dichos recursos.

La energı́a eléctrica es uno de los recursos en escases donde se busca nuevas formas
de generarla y por consiguiente formas de cómo ahorrarla, en este contexto, es posible
detectar que las alternativas y propuestas de ahorro en diferentes ámbitos son muy bastas
y extensas. En cuanto a lo que a la iluminación concierne, existen muchas estrategias e
instrumentos de control para ahorrar y optimizar tanto la iluminación como la energı́a.

Estas estrategias se advierten claramente en algunos hogares y establecimientos en

donde sin duda alguna muestran resultados significativos. Cabe preguntarnos entonces si
es factible diseñar un control de iluminación con mando a distancia, en donde el control
remoto pueda ser un dispositivo de uso general con mucho más funcionalidad que un sim-
12 CAPÍTULO 1. ILUMINACIÓN EFICIENTE

ple mando convencional, como una alternativa innovadora de ahorro y comodidad; para
este caso, el mando a control propuesto es un teléfono inteligente.

En la formación de este proyecto aborda diferentes interrogantes tales como la forma

de establecer la comunicación, el diseño de la aplicación que fungirá como control remoto
y la programación de los circuitos integrados para el desarrollo del hardware. Para eso
utilizaremos técnicas mixtas de recolección de la información como el análisis de contenido,
exploración bibliográfica, consultas electrónicas y foros.

1.7. Hipótesis
Se cree que el desarrollo de un sistema de control de iluminación brinda una alternativa
que contribuye en el ahorro de la energı́a eléctrica en gran medida, del mismo modo se
pretende que éste ofrezca una mayor comodidad para los usuarios; además de verlo como
una forma de fomentar el auge de nueva tecnologı́a para dispositivos móviles que cuenten
con el Sistema Operativo Android, que si bien es relativamente nuevo ha alcanzado un
gran crecimiento en los últimos años.

1.8. Metodologı́a
La metodologı́a que se implementó para el desarrollo de la investigación abarca los
siguientes puntos:

Obtención de la justificación y objetivos del proyecto.

Recolección de datos e información técnica.

Delimitación de datos técnicos.

Elaboración del proyecto teórico.

Elaboracion del proyecto fı́sico.

• Diseño y programación de los dimmers.

• Pruebas del funcionamiento de los dimmers.

• Diseño y programación del hardware receptor.

1.9. ORGANIZACIÓN DE LA TESIS 13

• Pruebas de comunicación Bluetooth.

Diseño y programación de la Aplicación.

Realización de los diagramas PCB y las placas correspondientes.

Integracion de todos los subsistemas

Pruebas finales.

Exposición de resultados y conclusiones.

Presentación del Proyecto.

1.9. Organización de la Tesis

Con base en los objetivos planeados, este trabajo se ha organizado de la siguiente
manera:

En el capı́tulo 1, se presenta una postura téorica sobre la iluminación eficiente,ası́ co-

mo conceptos que abordan tematicas relacionadas al ahorro de energı́a, bajo consumo
de energı́a y sistemas inovadores de iluminación; dentro de los cuales se encuentran los
sitemas de control de iluminación. Abarca teoria sobre los tipos y partes que integran
dichos sitemas de iluminación, profundizando en la técnica de control por ángulo de fase
o cruce por cero para la construcción de los dimmers que son dispositivos electrónicos
especializados capaces de regular la intensidad de fuentes eléctricas de luz.

En el capı́tulo 2, se presenta una breve introducción a la tecnologı́a Bluetooth ası́ como

las partes que lo constituyen y algunos perfiles significativos para el desarrollo del proyec-
to. De la misma manera se trata el manejo del módulo de Bluetooth Roving Networks,
la forma en como establecer una conexión con otro dispositivo Blurtooth, y los distintos
modos con los que se puede trabajar dentro de éste.

En el capı́tulo 3, se abordan los aspectos históricos del Sistema Operativo Android, de

la misma forma las caracterı́sticas y arquitectura que lo conforman. Describe los funda-
mentos y componentes básicos de una aplicación para dicho Sistema Operativo, ası́ como
los diferentes Entornos de Desarrollo Integral en los que se programan las aplicaciones,se
14 CAPÍTULO 1. ILUMINACIÓN EFICIENTE

enfoca profundamente en App Inventor describiendo la estructura y caracterı́sticas que

posee. Por último desarrolla los pasos y requerimientos a seguir para la distribución de
aplicaciones en el Android Market.

En el capı́tulo 4, se establece la descripción de los aspectos fı́sicos del proyecto; como

la programación y construcción de los dimmers; el diseño, la programación y construcción
del hardware receptor, la forma de como establecer la comunicación con un módulo de
Bluetooth y la HyperTerminal; los test de prueba y error de comunicación. Presenta la
propuesta de diseño y desarrollo de la aplicación ası́ como la integración de todos los
subsistemas formados anteriormente.

En el capı́tulo 5, Pruebas y Resultados, muestra como los diferentes subsistemas ...

Capı́tulo 2

Bluetooth

2.1. Descripción general de la Tecnologı́a Bluetooth

La tecnologı́a inalámbrica Bluetooth ofrece una forma de remplazar cables y enlaces
infrarrojos que interconectan dispositivos por un enlace de radio universal de corto alcan-
ce, con capacidad de crear pequeñas radio LANs.

En 1994, Ericsson Mobile Telecommunications comenzó un estudio para investigar la

viabilidad de un interfaz de radio de baja potencia y bajo coste entre teléfonos móviles
y sus accesorios. El estudio era parte de un proyecto más amplio que investigaba cómo
diferentes dispositivos de comunicaciones se podrı́an conectar a la red celular a través del
teléfono móvil. A medida que progresaba el proyecto se hizo evidente que las aplicaciones
de un enlace de radio de corto alcance eran ilimitadas. El trabajo de Ericsson en esta área
atrajo la atención de compañı́as como IBM, Intel, Nokia y Toshiba (Fig.2.1).

Figura 2.1: Compañı́as que forman parte del SIG.

En Febrero de 1998, se fundó el Bluetooth Special Interest Group (SIG), 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
(Fig.2.2).
Bluetooth es un sistema de radio que opera en la banda de frecuencia libre de 2.4 GHz,

15
16 CAPÍTULO 2. BLUETOOTH

Figura 2.2: Bluetooth Special Interest Group.

esta banda de frecuencia está disponible en la mayor parte del mundo. Bluetooth utiliza
79 canales de radio frecuencia con un ancho de banda de 1 MHz cada uno y una rata
máxima de sı́mbolos de 1 M Sı́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 [3]. El
rango tı́pico de operación de Bluetooth es menor a 10 m, sin embargo se pueden alcanzar
distancias de hasta 100 m.

Como se puede observar, la comunicación sobre Bluetooth se divide en varias capas.

A continuación se presenta una breve descripción de algunas de ellas (Fig.2.3).
Una de las capas de comunicación más bajas es llamada Banda Base. Esta capa imple-
menta el canal fı́sico real. Emplea una secuencia aleatoria de saltos a través de 79 frecuen-
cias de radio diferentes. Los paquetes son enviados sobre el canal fı́sico, donde cada uno
es enviado en una frecuencia de salto diferente. La Banda Base controla la sincronización
de las unidades Bluetooth y la secuencia de saltos en frecuencia, además es la responsable
de la información para el control de enlace a bajo nivel como el reconocimiento, control
de flujo y caracterización de carga útil y soporta dos tipos de enlace: sı́ncrono orientado
a la conexión (SCO), para datos y ası́ncrono no orientado a la conexión (ACL), princi-
palmente para audio. Los dos pueden ser multiplexados para usar el mismo enlace RF.
Usando ancho de banda reservado, los enlaces SCO soportan tráfico de voz en tiempo real.

El 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 procedi-
2.1. DESCRIPCIÓN GENERAL DE LA TECNOLOGÍA BLUETOOTH 17

Figura 2.3: Stack de Protocolo Bluetooth.

mientos necesarios para establecer un enlace SCO.

El 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.

El Logical Link Control and Adaptation Protocol (L2CAP) o 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 paque-
tes 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ı́.

El Sevice Discovery Protocol (SDP) o Protocolo de Descubrimiento de Servicio define

18 CAPÍTULO 2. BLUETOOTH

cómo actúa una aplicación de un cliente Bluetooth para descubrir servicios disponibles
de servidores Bluetooth, además de proporcionar un método para determinar las carac-
terı́sticas de dichos servicios.

El protocolo RFCOMM 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.

El control de telefonı́a binario (TCS binario) es un protocolo que define la señaliza-

ción de control de llamadas, para el establecimiento y liberación de una conversación o
una llamada de datos entre unidades Bluetooth. Además, éste ofrece funcionalidad para
intercambiar información de señalización no relacionada con el progreso de llamadas.

La capa de Audio es una capa especial, usada sólo para enviar audio sobre Bluetooth.
Las transmisiones de audio pueden ser ejecutadas entre una o más unidades usando mu-
chos modelos diferentes. Los datos de audio no pasan a través de la capa L2CAP, pero
sı́ directamente después de abrir un enlace y un establecimiento directo entre dos unidades
Bluetooth.

2.1.1. 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.
2.2. RFCOMM 19

Wireless Aplication Protocol (WAP) o Protocolo de Aplicación Inalámbrica. WAP

es una especificación de protocolo inalámbrica que trabaja con una amplia varie-
dad de tecnologı́as de red inalámbricas conectando dispositivos móviles a Internet.
Bluetooth puede ser usado como portador para ofrecer el transporte de datos entre
el cliente WAP y su servidor de WAP adyacente. Además, las capacidades de red
de Bluetooth dan a un cliente WAP posibilidades únicas en cuanto a movilidad
comparada con otros portadores WAP. Un ejemplo de WAP sobre Bluetooth serı́a
un almacén que transmite ofertas especiales a un cliente WAP cuando éste entra en
el rango de cobertura.

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 inter-
cambiar 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.

La Figura (Fig.2.4) muestra una comparación del stack Bluetooth con el modelo de
referencia estándar Open Systems Interconect, OSI, para stacks de protocolo de comuni-
caciones. A pesar de que Bluetooth no concuerda exactamente con el modelo, esta compa-
ración es muy útil para relacionar las diferentes partes del stack Bluetooth con las capas
del modelo OSI. Dado que el modelo de referencia es un stack ideal y bien particionado,
la comparación sirve para resaltar la división de funciones en el stack Bluetooth.

2.2. RFCOMM
El protocolo RFCOMM brinda emulación de puertos seriales sobre el protocolo L2CAP.
La capa RFCOMM es una simple capa de transporte provista adicionalmente de emula-
ción de circuitos de puerto serial RS-232. El protocolo RFCOMM soporta hasta 60 puertos
emulados simultáneamente. Dos unidades Bluetooth que usen RFCOMM en su comuni-
cación pueden abrir varios puertos seriales emulados, los cuales son multiplexados entre
sı́. La (Fig.2.5) muestra el esquema de emulación para varios puertos seriales (Fig.2.6).
Muchas aplicaciones hacen uso de puertos seriales. El RFCOMM está orientado a hacer
más flexibles estos dispositivos, soportando fácil adaptación de comunicación Bluetooth.
Un ejemplo de una aplicación de comunicación serial es el protocolo punto-a-punto (PPP).
20 CAPÍTULO 2. BLUETOOTH

Figura 2.4: Modelo de referencia OSI y Bluetooth.

El RFCOMM tiene construido un esquema para emulación de null modem y usa a L2CAP
para cumplir con el control de flujo requerido por alguna aplicación.

2.3. Perfiles Bluetooth

El estándar Bluetooth fue creado para ser usado por un gran número de fabricantes
e implementado en áreas ilimitadas. Para asegurar que todos los dispositivos que usen
Bluetooth sean compatibles entre sı́ son necesarios esquemas estándar de comunicación
en las principales áreas. Para evitar diferentes interpretaciones del estándar Bluetooth
acerca de cómo un tipo especı́fico de aplicación deberı́a ser implementado, el Bluetooth
Special Interest Group (SIG), ha definido modelos de usuario y perfiles de protocolo. Un
perfil define una selección de mensajes y procedimientos de las especificaciones Bluetooth
y ofrece una descripción clara de la interfaz de aire para servicios especı́ficos. Un perfil
puede ser descrito como una “rebanada” completa del stack de protocolo.

Existen cuatro perfiles generales definidos, en los cuales están basados directamente
algunos de los modelos de usuario más importantes y sus perfiles. Estos cuatro modelos
son Perfil Genérico de Acceso (GAP), Perfil de Puerto Serial, Perfil de Aplicación de
Descubrimiento de Servicio (SDAP) y Perfil Genérico de Intercambio de Objetos (GOEP).
A continuación se hace una breve descripción de estos y algunos otros perfiles Bluetooth.
2.3. PERFILES BLUETOOTH 21

Figura 2.5: RFCOMM

La (Fig.2.7)muestra el esquema de los perfiles Bluetooth. En ella se puede observar la

jerarquı́a de los perfiles, como por ejemplo que todos los perfiles están contenidos en el
Perfil Genérico de Acceso (GAP).

2.3.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 estableci-
miento 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.

2.3.2. Perfil de Puerto Serial

Este perfil define los requerimientos para dispositivos Bluetooth, necesarios para es-
tablecer una conexión de cable serial emulada usando RFCOMM entre dos dispositivos
similares. Este perfil solamente requiere soporte para paquetes de un slot. Esto significa
que pueden ser usadas ratas de datos de hasta 128 kbps. El soporte para ratas más altas es
opcional. RFCOMM es usado para transportar los datos de usuario, señales de control de
modem y comandos de configuración. El perfil de puerto serial es dependiente del GAP.
22 CAPÍTULO 2. BLUETOOTH

Figura 2.6: Varios puertos seriales emulados mediante RFCOMM

2.3.3. 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.

2.3.4. 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. Dispositivo Bluetooth Roving Networks

Para programar los dispositivos Roving Networks se necesita una PC con tecnologı́a
Bluetooth (ya sea integrado o mediante un adaptador Bluetooth USB dongle). Sólo un
dispositivo se puede programar a la vez. Una vez que se ha programado y configura-
do, los ajustes del dispositivo permanecerán, (independiente de su bajo uso) hasta que
literalmente son modificados o restaurados a la configuración de fábrica (Fig.2.8).
Antes de empezar con la alimentación del dispositivo y la vinculación con la PC. Los
dispositivos de Bluetooth de Roving Networks, pueden ser programados a través de un
enlace Bluetooth o a través de una interfaz serie. Para programar el dispositivo, debe de
2.4. DISPOSITIVO BLUETOOTH ROVING NETWORKS 23

Figura 2.7: Los Perfiles Bluetooth

conectarse al puerto COM asignado por el dispositivo a través de una interfaz Bluetooth
o puerto serie.

Los dispositivos Bluetooth RN se han programado con un lenguaje simple de comandos

ASCI, que es similar al estándar industrial de protocolos Hayes AT. El set de comandos
configura el módulo y recibe comandos eco de la configuración actual. Los ajustes de la
configuración modificada con el set de comandos, no surtirán efecto hasta que el módulo
de Bluetooth sea reiniciado, a pesar de que el comando GET podrı́a mostrar lo contrario.

2.4.1. Estableciendo una conexión Bluetooth

Por defecto, el dispositivo de RN aparece en el directorio del buscador de Bluetooth

como Serial Port Profile (SPP) Servicio “FireFly-ABCD” , donde “Firefly” es el tipo
de dispositivo de RN y “ABCD” son los últimos cuatro nibbles de la dirección MAC
Bluetooth. El nombre del dispositivo local se puede cambiar. Se tendrá que emparejar
con el dispositivo haciendo doble clic en el nombre de éste y siguiendo el menú. El firm-
ware almacena automáticamente hasta 8 parejas de máquinas remotas en una primera vez.

Si el dispositivo Bluetooth remoto no requiere autenticación, una conexión puede ocu-

rrir sin el proceso de emparejamiento. Sin embargo, la especificación Bluetooth establece
24 CAPÍTULO 2. BLUETOOTH

Figura 2.8: Módulo Bluetooth Roving Networks

que si cualquiera de los dispositivos que participan en el proceso de emparejamiento re-

quiere autenticación, el otro dispositivo debe participar para garantizar un vı́nculo seguro.
El modo por defecto de los módulos de RN es un modo ABIERTO, de tal manera que el
módulo NO requiere autenticación. Sin embargo la mayorı́a de PC’s si lo requieren.

La clave de paso es una cadena de caracteres alfa- numéricos, de 1 a 16 caracteres

de longitud. Durante el proceso de emparejamiento inicial, el código se introduce en am-
bos lados de la conexión Bluetooth, y debe coincidir para completar la vinculación. Esta
clave se utiliza para crear una clave de enlace seguro, que luego se almacena en ambos
dispositivos. Tras los intentos de conexión posterior, el vı́nculo clave se compara y debe
coincidir antes que la conexión pueda continuar. La clave de acceso por defecto es “ 1234” .

Para conectarse a FireFly, busque en los servicios que ofrece, deberı́a ver: El perfil
“SPP” con un puerto COM virtual asignado. Abrir este puerto virtual COM para crear
una conexión Bluetooth. Una vez conectado, el dispositivo estará en modo de datos que
permitirá el flujo de datos en ambas direcciones, como si el puerto serie estuviera conec-
tado fı́sicamente (cable) a la PC. El dispositivo debe estar en modo comando para la
configuración y programación. Para entrar en modo comando teclee “$$$” (tres signos de
pesos), ya sea con el control remoto Bluetooth o la conexión local del puerto serie. Se
debe entrar en el modo de comandos dentro de los primeros 60 segundos (configurable
por el ajuste del config-timer).

NOTA: Sólo un cliente puede hacer la conexión esclavo FireFly a la vez. Como maestro,
2.4. DISPOSITIVO BLUETOOTH ROVING NETWORKS 25

es posible realizar múltiples conexiones de Firefly, pero sólo en un punto a punto, en

serialized fashion. En este momento los dispositivos RN no son compatibles con el modo
de múltiples puntos maestros.

2.4.2. Modos de Operación

Los modos de operación se pueden ajustar con el comando SM.

Comando de modo Esclavo (SM, 0):Este es el modo por defecto, con el que otros
dispositivos Bluetooth pueden descubrir y conectarse al dispositivo.

Comando de modo Maestro (SM, 1):Este modo es útil cuando el dispositivo quiere
iniciar conexiones (y no recibirlas). En este modo, el dispositivo NO será visible o
conectable.

Disparador Modo Maestro (SM, 2):En este modo, el dispositivo se conectará au-
tomáticamente a la dirección anterior configurada como esclavo cuando un carácter
(o caracteres) se reciben en el local UART. La conexión permanece abierta hasta
que un temporizador de inactividad configurable (1 a 255 segundos), expire sin datos
recibidos, o se vea un carácter de interrupción (BREAK) configurable.

Conexión automática (modo maestro) (SM, 3): Si se selecciona este modo, el dis-
positivo iniciará una conexión a la dirección remota previamente almacenada inme-
diatamente después de encender el aparato. En este modo, los datos se pasan sin
que sean interpretados por el BluePort (alta velocidad), por lo tanto, la conexión
no se puede romper a través de comandos. Si se produce desconexión, el dispositivo
intentará volver a conectar hasta que lo consiga.

Conexión automática (modo DTR) (SM, 4):Este modo se debe establecer con el
set de comandos. Este modo funciona como conexión automática al modo Master,
excepto que la conexión y desconexión están controladas por los 3 dipswitch externos
en el FireFly (no incluido en todos los módulos de Bluetooth).

Conexión automática a cualquier modo (SM, 5):Este modo se debe establecer con
el set de comandos. Este modo funciona como el modo de DTR Auto-conexión,
excepto que cada vez que el switch / PIO está prendido, se realiza una búsqueda y
al encontrar el primer dispositivo se conecta. La dirección almacenada NO se utiliza,
y la dirección que se encuentran nunca se almacena.
26 CAPÍTULO 2. BLUETOOTH

2.4.3. Configuración
Modo Comando vs Modo Dato

Al encender el dispositivo estará en el modo de datos. Para entrar en modo de comando,

se teclea los caracteres “$$$” a través del puerto serial o del mando a distancia Bluetooth.
El dispositivo responderá con “CMD”. Para salir del modo de comando, mande “—”Ėl
dispositivo responderá con “END” .En el modo de comando, el dispositivo acepta bytes
ASCII como comandos. Una revisión rápida para ver si está en modo de comando es
el de escribir los comandos “D” y “E” después de entrar en modo de comando. Esto le
mostrará los parámetros, tales como el nombre de Bluetooth, la clase de dispositivos y
configuración de puerto serie. Para acceder a la configuración, el dispositivo debe estar
en modo de comandos mediante la emisión de “$$$” . Se debe entrar en el modo de
comandos con la ventana de configuración de 60 segundos o el módulo entrará en el modo
rápido de datos donde todos los caracteres son ignorados incluyendo “$$$” . Si expira el
temporizador de configuración mientras está en modo comando el dispositivo no entrará en
el modo rápido de datos después de salir del modo de comandos.No se puede entrar en
modo comando desde el mando a distancia con Bluetooth si el dispositivo está en modo
maestro.

Configuración Local (a través del puerto serie)

El uso de la norma RS-232 pasa a través del cable de PC para enviar caracteres
ASCII a través de la terminal al dispositivo de RN. La configuración del puerto serie debe
coincidir con la configuración del puerto serie RN. Por defecto, estos se establecen en:

Velocidad de transmisión 115 200 bps

8 bits

Sin paridad

1 bit de paro

Herramientas de control de flujo activado

La Configuración local funciona en cualquier momento en que el dispositivo no dispone

de una conexión Bluetooth, y también trabaja bajo ciertas condiciones. Si el dispositivo
está en modo de configuración y se produce una conexión, el dispositivo saldrá del modo
2.4. DISPOSITIVO BLUETOOTH ROVING NETWORKS 27

de configuración y los datos se pasan de ida y vuelta desde el dispositivo remoto.

Ejecutar el emulador de terminal preferido, el programa HyperTerminal u otro. Te-

cleamos “$$$” en la pantalla. Debemos de ver “CMD” . Esto comprueba que el cable, la
comunicación y los ajustes son correctos. A los comandos válidos devolverá un “AOK” co-
mo respuesta, y los no válidos volverá “ERR” . Para salir del modo de comandos, escriba
“—” . (Tres signos menos).

Configuración Remota (Vı́a Bluetooth)

A menudo es útil para poder realizar la configuración remota a través de una cone-
xión Bluetooth. Para ello, conectamos el dispositivo a través de Bluetooth, y utilizando
el emulador de terminal.

NOTA: Sólo se puede entrar en el modo de comandos de forma remota a través de

Bluetooth si ha hecho una conexión y se enviaron los “$$$” en el “contador de tiempo de
configuración” de la ventana después de activarlo. Esto se puede modificar, el temporiza-
dor de configuración por defecto caduca a los 60 segundos después del encendido.

El temporizador se puede ajustar a cualquier valor entre 0 (desactivar la configura-

ción remota) a 255 decimal, lo que permite conexión continua (sin tiempo de espera) de
configuración.
28 CAPÍTULO 2. BLUETOOTH
Capı́tulo 3

Android

Antes de pasar al desarrollo de la aplicación de Android que nos compete para el

control de la iluminación, nos detenemos un momento a preguntarnos; ¿Qué es Android?,
¿Cómo surgió?, ¿Cómo o para que se usa? Estas cuestiones sumadas a la descripción del
desarrollo de la aplicación son aspectos que se abordaran en este capı́tulo.

Android es un sistema operativo basado en el núcleo Linux diseñado originalmente

para dispositivos móviles, tales como teléfonos inteligentes, pero que posteriormente se
expandió su desarrollo para soportar otros dispositivos tales como tablet, reproductores
MP3, netbook, PC, televisores, lectores de e-book e incluso, se han llegado a ver en el
CES , microondas y lavadoras.

3.1. Historia de Android

El sistema operativo más usado en Smartphones actualmente en el mundo no es una
idea que se le ocurrió a alguien un dı́a y tuvo un camino fácil para empezar a funcionar,
sino que surge poco a poco y vive diferentes etapas hasta que el primer Android ve la luz.
Sus comienzos. La cuna de lo que hoy conocemos como un Android adolescente, al que aún
le queda por madurar mucho, pero del que ya vemos y disfrutamos sus mejores cualidades.

Si queremos hablar de la historia de Android no nos queda más que hablar un hombre.
Ese hombre es Andy Rubin (Fig. 3.1) quien fundó en 2003, Android Inc.No fue hasta el 5
de Noviembre de 2007 que Google presentó Android, un sistema operativo para móviles
que revolucionarı́a el mercado, aunque fue un año después, en Octubre de 2008 cuando lo

29
30 CAPÍTULO 3. ANDROID

vimos por primera vez funcionando en un HTC Dream.

Figura 3.1: Andy Rubin creador de Android.

Desde entonces Android ha sufrido muchos cambios, novedades y actualizaciones,(Ver

apendice) en el mundo de la tecnologı́a.

3.2. ¿Qué es Android?

Según developer.android.com , Android is a software stack for mobile devices that in-
cludes an operating system, middleware and key applications. The Android SDK (software
development kit) provides the tools and APIs necessary to begin developing applications
on the Android platform using the Java programming language.

“ Android es una pila de software para dispositivos móviles que incluye un sistema
operativo, middleware y aplicaciones clave. El SDK de Android proporciona las herramien-
tas y APIs necesarias para comenzar a desarrollar aplicaciones en la plataforma Android
usando el lenguaje de programación Java” .

3.2.1. Caracterı́sticas
Las caracterı́sticas que posee la plataforma Android, se mencionan a continuación y
posteriormente se desglosara su explicación.

Es libre, código abierto y plataforma de software totalmente personalizable y un

sistema operativo para dispositivos móviles.

Basado en el kernel de Linux.

3.2. ¿QUÉ ES ANDROID? 31

Permite escribir código Java.

La aplicación de Framework permite la reutilización y sustitución de componentes.

Posee una maquina virtual Dalvik que optimiza el rendimiento en los dispositivos
móviles.

Integra un Navegador basado en el motor de código abierto de Webkit.

Poder de optimización de gráficos mediante una biblioteca de gráficos 2D persona-

lizado y gráficos 3D basados en la especificación OpenGL ES 1.0 (aceleración de
hardware opcional).

SQLite para el almacenamiento de datos estructurados.

Soporta archivo multimedia de imagen, video y audio (MPEG4, H.264, MP3, AAC,
AMR, JPG, PNG, GIF).

GSM de telefonı́a (Dependiendo de Hardware).

Bluetooth, EDGE, 3G y WiFi (Dependiendo de hardware).

Cámara, GPS, brújula y el acelerómetro (Dependiendo de hardware).

Entorno de desarrollo incluyendo un emulador de dispositivo, herramientas para la

depuración, la memoria y de perfiles de rendimiento, y un plugin para el IDE de
Eclipse (actualmente nuevo entorno de desarrollo App Inventor).

3.2.2. Arquitectura de Android

Para adentrarnos en los conceptos clave dentro de la arquitectura y caracterı́sticas

de operación de Android, es fundamental visualizar de forma gráfica la estructura del
Software Stack Android (Fig.3.2).
32 CAPÍTULO 3. ANDROID

Figura 3.2: Arquitectura de S.O. Android.

Kernel de Linux

Android se basa en la versión 2.6 de Linux para los servicios del núcleo del sistema
como la seguridad, la gestión de memoria, gestión de procesos, la pila de red, y el modelo
de controlador (Fig.3.3). El núcleo también actúa como una capa de abstracción entre el
hardware y el resto de la pila de software.

Figura 3.3: Capa del Kernel de Linux.

Android es construido sobre el kernel de Linux, pero Android no es de Linux.

3.2. ¿QUÉ ES ANDROID? 33

No incluye el conjunto de utilidades completas estándar de Linux.

Parches de ’mejoramiento de kernel’ para soportar Android.

Android escogió el kernel de Linux como soporte básico de su sistema, por varias
razones importantes:

Gran memoria y gestión de procesos.

Modelo de seguridad basado en permisos.

Soporta las bibliotecas compartidas.

Es de código abierto.

Dalvik

Dalvik es la máquina virtual que utiliza la plataforma para dispositivos móviles An-
droid. Dalvik ha sido diseñada por Dan Bornstein con contribuciones de otros ingenieros
de Google (Fig.3.4).

Figura 3.4: Capa de la maquina virtual Dalvik.

Dalvik está optimizada para requerir poca memoria y está diseñada para permitir
ejecutar varias instancias de la máquina virtual simultáneamente, delegando en el sistema
operativo subyacente el soporte de aislamiento de procesos, gestión de memoria e hilos.

Proporciona la portabilidad de las aplicaciones y consistencia en el tiempo de eje-

cución.

Ejecuta el formato de archivo optimizado (.dex) y bytecodec Dalvik.

Los archivos java.class/.jar los convierte a .dex en tiempo de ejecución.

34 CAPÍTULO 3. ANDROID

Librerı́as Nativas

Las librerı́as nativas de la arquitectura de Android se dividen en cuatro grupos prin-

cipales que conforman todo el bloque de dicho nivel (Fig.3.5):

Bionic Libc.

Bibliotecas de Funciones.

Servicios Nativos.

Hardware Librerı́as Abstractas.

Figura 3.5: Capa de todas las Librerias.

Bionic Libc

En Linux Libc se encuentran tareas fundamentales, dentro de las cuales se mencionan

algunas:

La asignación de memoria virtual y la paginación.

Manejo de caracteres.

Cadenas y matrices de utilerı́as.

Búsqueda y clasificación.

Flujo de entradas y salidas.

Bajo nivel de entradas y salidas.

Archivos de interfaz del sistema.

3.2. ¿QUÉ ES ANDROID? 35

Matemáticas.

Funciones aritméticas.

Fecha y hora.

Al tener claro las funcionalidades de Libc, nos queda preguntarnos ¿Qué es Bionic?
Es la implementación de estas herramientas de Libc personalizadas y optimizadas para
su uso integrado (uso en sistemas embebidos).

Bibliotecas de funciones

Dentro de estas bibliotecas se encuentran las librerı́as tales como:

WebKit.

Hace que las paginas (de escritorio) se vean en su totalidad.

Soporta ccs, javascript, dom y ajax.

Soporta la representación y adaptación de vista de una sola columna.

Media Framework.

Soporta audio y video estándar, además de formatos en fotogramas.

Soporta códec plug-ins para software y hardware.

SQLite.

Peso ligero de almacenamiento de datos transaccionales.

Back-End para la mayorı́a de plataformas de almacenamiento de datos.

Servicios Nativos

Surface Manager

Proporciona todo el sistema de superficie ’compositor’, maneja toda la repre-

sentación de la superficie de dispositivo.

Puede combinar superficies 2D, 3D y superficies para múltiples aplicaciones.

36 CAPÍTULO 3. ANDROID

Audio Manager
Gestiona todas las salidas de audio del dispositivo.
Procesa múltiples flujos de audio a la salida por diversos caminos.
Maneja enrutamiento de audio para varias salidas.

Hardware Librerı́as Abstractas

Espacio usado para la capa de biblioteca C/C++.

Define la interfaz que Android requiere (hardware) para implementar ”drivers”.

Separa la plataforma lógica de Android de la interfaz de hardware (Fig.3.6).

Figura 3.6: Librerias Abstractas de Hardware.

Aplicación Framework

En esta “Plataforma de Servicios Básicos” están localizadas los servicios para el

teléfono celular (Fig.3.7).

Gestor de actividades.

Gestor de paquetes.

Gestor de ventanas.

Gestor de recursos.

Proveedores de contenido.

Vista del sistema.

Dentro de esta clasificación de “Plataforma de Servicios Básicos” , encontramos de

igual manera servicios que atienden el funcionamiento básico de hardware, tales como:

Servicios de telefonı́a.
3.3. APLICACIONES ANDROID 37

Servicio de ubicación.

Servicio de Bluetooth.

Servicio Wifi.

Servicios de USB.

Servicios de sensores (acelerómetros y giroscopios)

Figura 3.7: Capa de Aplicaciones Framework.

La última capa dentro de la arquitectura de Android que pertenece a las Aplicaciones

como tal. Puesto que este tema es de suma importancia tendrá un desarrollo más detallado
en una sección aparte. Para poder visualizar la arquitectura del Sistema Android con todos
sus componentes expuestos (véase ápendice A).

3.3. Aplicaciones Android

Los dispositivos de Android incluyen un conjunto de aplicaciones básicas, como un
cliente de correo electrónico, programa de SMS, calendario, mapas, navegador, contactos,
y otros. Todas las aplicaciones se escriben usando el lenguaje de programación Java . Estas
aplicaciones se encuentran en la última capa de la arquitectura del software de Android
(Fig.3.8).

Figura 3.8: Última Capa de Aplicaciones.

38 CAPÍTULO 3. ANDROID

3.3.1. Fundamentos de una aplicación

Las aplicaciones Android están escritas en el lenguaje de programación Java. Las he-
rramientas de Android SDK compilan el código, junto con los datos y archivos de recursos
en un paquete de Android, con esta compilación se genera un archivo con extensión apk.
Todo el código se guarda en un único archivo, y es lo que se considera como una aplica-
ción, éste archivo es el que Android utiliza para instalarlo dentro del dispositivo.

Una vez instalado en un dispositivo, cada aplicación Android vive en su propia segu-
ridad sandbox:

El sistema operativo Android es un sistema multi-usuario en el que cada aplicación

es un usuario diferente.

Por defecto, el sistema asigna a cada solicitud un único ID de usuario de Linux

(el ID es utilizado sólo por el sistema y se desconoce en la aplicación). El sistema
establece permisos para todos los archivos en una aplicación, para que sólo el ID de
usuario asignado a esa aplicación puede acceder a ellos.

Cada proceso tiene su propia máquina virtual (VM), por lo que el código de una
aplicación se ejecuta de manera aislada de otras aplicaciones.

Por defecto, cada aplicación se ejecuta en su propio proceso de Linux. Android inicia
el proceso cuando alguno de los componentes de la aplicación necesita ser ejecutado,
y luego cierra el proceso cuando ya no se necesita o cuando el sistema debe recuperar
la memoria para otras aplicaciones.

De esta manera, el sistema Android aplica el principio de privilegios mı́nimos. Es decir,

cada aplicación, por defecto, sólo tiene acceso a los componentes que necesita para hacer
su trabajo y nada más. Esto crea un ambiente muy seguro en el que una aplicación no
puede acceder a partes del sistema para el cual no se le da permiso.

Sin embargo, hay maneras para que una aplicación pueda compartir datos con otras
aplicaciones y de una aplicación se pueda acceder a los servicios del sistema:

Es posible disponer de dos aplicaciones que comparten el mismo ID de usuario de

Linux, en cuyo caso pueden acceder a los demás archivos. Para ahorrar recursos del
3.3. APLICACIONES ANDROID 39

sistema, las aplicaciones con el mismo ID de usuario también pueden hacer arreglos
para ejecutar en el mismo proceso de Linux y comparten la misma máquina virtual
(las solicitudes deben estar firmadas con el mismo certificado).

Una aplicación puede solicitar permiso para acceder a los datos del dispositivo,
tales como los contactos del usuario, los mensajes SMS, el almacenamiento externo
(tarjeta SD), cámara, Bluetooth, y mucho más. Todos los permisos de la aplicación
debe ser concedidos por el usuario durante la instalación.

3.3.2. Componentes de una aplicación

Los componentes de una aplicación Android, son los bloques esenciales para la cons-
trucción de la misma. Cada componente es un punto diferente a través del cual el sistema
puede entrar en su aplicación. No todos los componentes son verdaderos puntos de entra-
da para el usuario, algunos dependen de otros; pero cada uno existe como una entidad
propia y desempeña un papel especı́fico, cada uno es una pieza única que ayuda a definir
el comportamiento general de la aplicación.

Hay cuatro tipos de componentes diferentes en una aplicación. Cada tipo tiene un
propósito distinto y tiene un ciclo vital distinto que define cómo el componente se crea y
se destruye.

Estos son los cuatro tipos de componentes de la aplicación:

Activities (Actividades)

Un activity representa una pantalla única con una interfaz de usuario. Por ejemplo, en
una aplicación de correo electrónico, puede haber una activity que muestra una lista de
correos electrónicos nuevos, otra activity para enviar un correo electrónico, ası́ como otra
activity para la lectura de mensajes de correo electrónico. Aunque las activities trabajan
para formar una experiencia coherente en la aplicación de correo electrónico, cada una es
independiente de las otros. Como tal, una aplicación puede ingresar a cualquiera de estas
activities (si la aplicación de correo electrónico lo permite). Por ejemplo, una aplicación
de cámara puede adentrarse a la activity en la aplicación de correo electrónico que envı́a
nuevos mensajes de correo, para que el usuario pueda compartir una imagen (Fig.3.9).
40 CAPÍTULO 3. ANDROID

Figura 3.9: Conjunto de Activities.

Services (Servicios)

Un service es un componente que se ejecuta en segundo plano para realizar opera-

ciones de larga duración o para realizar un trabajo de procesos remotos. Un service no
proporciona una interfaz de usuario. Por ejemplo, un service puede reproducir música en
segundo plano mientras el usuario está en una aplicación diferente, o puede obtener los
datos por la red sin la interacción del usuario con el bloqueo de una actividad. Otros
componentes, tales como las activities, pueden iniciar el service y se deja correr o se unen
a ella con el fin de interactuar con él (Fig.3.10).

Content Providers (Proveedores de contenido)

Un content provider maneja un conjunto compartido de datos de aplicación. Puede

almacenar los datos en el sistema de archivos, en una base de datos SQLite, en la web, o
cualquier otro lugar de almacenamiento permanente en donde la aplicación puede tener
acceso. A través del content provider, otras aplicaciones pueden consultar o modificar in-
cluso los datos (si el content provider lo permite). Por ejemplo, el sistema Android ofrece
un content provider que gestiona la información de contactos del usuario. Por lo tanto,
cualquier aplicación con los permisos adecuados puede hacer una consulta por parte del
content provider para leer y escribir información sobre una persona en particular.

Los content providers también son útiles para la lectura y escritura de datos que son
3.3. APLICACIONES ANDROID 41

Figura 3.10: Servicios en Segundo Plano.

privados en una aplicación y no se comparten. Por ejemplo, el Bloc de Notas, esta simple
aplicación utiliza un content provider para guardar notas (Fig.3.11).

Figura 3.11: Ejemplo de Proveedor de Contenido.

Broadcast Receivers (Receptores de radiodifusión)

Un receptor de radiodifusión es un componente que responde a los anuncios de difusión

en todo el sistema. Muchas emisiones se originan en el sistema, por ejemplo, una emisión
que anuncia que la pantalla se ha apagado, la baterı́a está baja, o una imagen fue cap-
42 CAPÍTULO 3. ANDROID

turada. Las solicitudes también pueden iniciar las emisiones, por ejemplo, para permitir
que otras aplicaciones sepan que algunos datos han sido descargados en el dispositivo y
está disponible para que los utilicen. A pesar de que los receptores de radiodifusión no
se muestran como una interfaz de usuario, pueden crear una notificación en la barra de
estado para alertar al usuario cuando un evento de difusión se produce. Sin embargo, un
receptor de radiodifusión es más común como una ’puerta’ a otros componentes y tiene
la intención de hacer una mı́nima cantidad de trabajo (Fig.3.12).

Figura 3.12: Notificación de Broadcast.

Activación de componentes

Se debe de aclara un par de puntos sobre un sistema Android, los cuales nos llevarán
a la activación de componentes mediante los Itent.

Una aplicación no puede activar directamente un componente de otra aplicación.

El sistema Android se encarga de activar esos componentes.

Los intents (intenciones) es un mensaje asincrónico que se une a los componentes in-
dividuales entre sı́. Los intents son una descripción abstracta de una operación a realizar.

Se piensa en ellos como los mensajeros de la solicitud de una acción de otros compo-
nentes, si el componente pertenece a la aplicación o a otra. El Intent es crear un objeto,
que defina un mensaje para que se active un componente especı́fico. Las Activities, Ser-
vices y Broadcast Receivers son activados por medio de las Intents.

A continuación veremos esquemas que ilustran las diferentes formas en las que un
Intent trabaja.
3.4. DESARROLLANDO APLICACIONES ANDROID 43

Intent explı́cita enviada a una Activity2 definida(Fig.3.13).

Figura 3.13: Ejemplo 1 de Intent

El usuario tendrá que seleccionar entre Actividad2 y Actividad3 (Fig.3.14).

Figura 3.14: Ejemplo 2 de Intent

Un Intent mandado por una Activity1 a otra Activity2, y esta segunda manda un
Intent a la Activity1 primaria como respuesta Fig.3.15.

Figura 3.15: Ejemplo 3 de Intent

3.4. Desarrollando aplicaciones Android

Como se mencionó en la definición de Android anteriormente expuesta, para que un
desarrollador pueda realizar, diseñar y compilar sus aplicaciones es necesario que cuente
con el SDK de Android. En este apartado se explicará las herramientas para instalar un
entorno de desarrollo Android ası́ como los requerimientos mı́nimos, las alternativas de
desarrollo, la forma de instalación y la introducción a la programación de una aplicación
Android.
44 CAPÍTULO 3. ANDROID

3.4.1. Entornos de Desarrollo Android

Cabe aclarar que al referirnos a un IDE, nos referimos en realidad a un Entorno de
Desarrollo Integrado IDE (por sus siglas en ingles Integrated Development Environment).

Según el diccionario de términos técnicos , se define un Entorno de Desarrollo In-

tegrado como un programa informático compuesto por un conjunto de herramientas de
programación. Puede dedicarse en exclusiva a un sólo lenguaje de programación o bien,
poder utilizar varios de ellos.

Un IDE es un entorno de programación que ha sido empaquetado como un programa

de aplicación, es decir, consiste en un editor de código, un compilador, un depurador y
un constructor de interfaz gráfica (GUI). Los IDEs pueden ser aplicaciones por sı́ solas o
pueden ser parte de aplicaciones existentes. El lenguaje Visual Basic, por ejemplo, puede
ser usado dentro de las aplicaciones de Microsoft Office, lo que hace posible escribir sen-
tencias Visual Basic en forma de macros para Microsoft Word.

Los IDE proveen un marco de trabajo amigable para la mayorı́a de los lenguajes de
programación tales como C++, Python, Java,C#, Delphi, Visual Basic, etc. En algunos
lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecución, en donde
se permite utilizar el lenguaje de programación en forma interactiva, sin necesidad de
trabajo orientado a archivos de texto, como es el caso de Smalltalk u Objective-C.

Es posible que un mismo IDE pueda funcionar con varios lenguajes de programación.
Este es el caso de Eclipse, al que mediante plugins se le puede añadir soporte de lenguajes
adicionales.

Android SDK y Eclipse

Como acertadamente se mencionó, Eclipse es una IDE que tiene la capacidad de fun-
cionar con varios lenguajes de programación. Es por esto que este Entorno de Desarrollo
Integrado fundado por la empresa que lleva su nombre; Eclipse Foundation, es apropiada
para desarrollar aplicaciones Android bajo un entorno de Java, con la simpleza de des-
cargar e instalar el Plugin de Android ADT con lenguaje Java y el Android SDK para
3.4. DESARROLLANDO APLICACIONES ANDROID 45

ejecutar las Máquinas Virtuales(Fig.3.16).

Figura 3.16: Entorno de Desarrollo Ecplipse.

Al tener el entorno de desarrollo de Android sobre el IDE Eclipse, podemos comenzar

a desarrollar aplicaciones para los dispositivos Android. La explicación a detalle de las
pantallas de Eclipse y la introducción básica para empezar a programar aplicaciones en
este entorno, se encuentran en la página de desarrolladores de Android , y que por no ser
el Entorno de Desarrollo que nos compete, vamos a omitir en este escrito.

APP Inventor

La segunda alternativa como Entorno de Desarrollo Android, es App Inventor; en la

cual nos enfocamos para el desarrollo del proyecto; por lo que ahondaremos de una manera
más detallada todas sus caracterı́sticas y herramientas.

La forma de crear aplicaciones para Android con App Inventor es prácticamente fácil
con un navegador web. Y tan sencillo como crear un diseño y seleccionar las acciones a
realizar, tan dinámico como un puzzle (Fig.3.17).
Los pasos necesarios a considerar para comenzar a trabajar con App Inventor son:
46 CAPÍTULO 3. ANDROID

Figura 3.17: APP Inventor.

1. Configurar el Equipo.

Requisitos de Sistema.

Ordenador y Sistema Operativo.

Macintosh (con procesador Intel): Mac OS X 10.5, 10.6
Windows: Windows XP, Windows Vista, Windows 7
GNU / Linux: Ubuntu 8 +, Debian 5 +

Navegador.
Mozilla Firefox 3.6 o superior
Apple Safari 5.0 o superior
Google Chrome 4.0 o superior
Microsoft Internet Explorer 7 o superior

Poner a prueba la configuración de Java

El equipo tiene que ejecutar Java 6 (también conocido como Java 1.6). Puede des-
cargar Java desde: www.java.com.

a) Podemos visitar la página de prueba de Java para comprobar si se ha insta-

lado correctamente . Al términar podremos observar un mensaje de que Java
está funcionando y que la versión es Java 1.6 o superior.
3.4. DESARROLLANDO APLICACIONES ANDROID 47

b) Antes de poder utilizar el entorno de desarrrollo App Inventor, es necesario

instalar un software en su ordenador ( Paso 2 ).

2. Instalación de las librerı́as App Inventor.

Windows XP,Windows Vista, Windows 7:

Recomendamos que realice la instalación desde una cuenta que tenga pri-
vilegios de administrador en su equipo. Esto instalará el software para todos
los usuarios de la máquina. Si usted no tiene privilegios de administrador, la
instalación deberı́a funcionar, pero la aplicación de App Inventor sólo podrá uti-
lizarse a partir de la cuenta que se usó cuando instaló el software.

a) Descargar y ejecutar este instalador ( No modificar la ruta de instalación

) : AppInventor Setup Installer v 1 1.exe (9̃2 MB).
b) Si una vez instalado, y al comenzar a utilizar App Inventor Web, Java le
pregunta la ubicación del software, esta se localiza la dirección:
• 32 bits: C:/Archivos de programa/Appinventor/comandos para la Ap-
pinventor.
• 64 bits: C:/Archivos de programa(x86)/Appinventor/comandos para
la Appinventor.
Mac OS X:
• Descargar y ejecutar este instalador ( No modificar la ruta de instalación
): AppInventor Setup Installer v 1 1.dmg (9̃2 MB)
GNU/Linux:
• Descargar y ejecutar este instalador ( No modificar la ruta de instalación
): AppInventor Setup Installer v 1 1 all.deb(9̃2 MB)
• Si no es posible instalar el .deb se descarga y ejecuta el siguiente este insta-
lador ( No modificar la ruta de instalación ): AppInventor Setup Installer v 1 1.tar.gz
(9̃2 MB)

3. Una vez instalado todo los requerimientos del sistema para trabajar con App Inven-
tor solo necesitamos iniciar sesión en la cuenta de Google y escribir en el buscador:
http://appinventor.googlelabs.com, esta página te llevara al entorno de desarrollo
el cual se explicará a detalle más adelante.
48 CAPÍTULO 3. ANDROID

Para accesar a los links de cada descarga para las librerias de APP Inventor, puede
conultar la pagina oficial de Google, que es: http://www.appinventorbeta.com/about/,
ahı́ podra encontrar los links de descarga ası́ como una explicacion mas detallada en caso
de que se desee instalar en MacOS o en LINUX (Fig.3.18).

Figura 3.18: APPInventor Learn.

3.5. Estructura Básica de APP Inventor

Antes de comenzar con la explicación para desarrollar una aplicación en APP Inventor,
vale la pena mencionar las ventajas y desventajas que existen al utilizar este entorno en
comparación con Eclipse.

Ventajas:
3.5. ESTRUCTURA BÁSICA DE APP INVENTOR 49

Se requiere de conocimientos mı́nimos de programación en C, Java, o semejantes.

Su entorno es totalmente gráfico, y se requiere de un mı́nimo de escritura.

Las funciones de cada herramienta son de igual manera gráficas.

Se hace la relación entre códigos mediante una conexión gráfica tipo Puzzle (literal-
mente).

No requiere mayor instalación de software especializado.

Es posible desarrollar aplicaciones en cualquier navegador, por lo que te da libertad

de desarrollar en cualquier equipo con un mı́nimo de requerimientos.

Permite ver en tiempo real las modificaciones que se hacen en el entorno con tu
celular conectado.

Las aplicaciones que se realizar se alojan en la Web, por lo se puede tener acceso a
ellos desde cualquier equipo con internet.

Desventajas:

Las herramientas que tiene son limitadas a comparación del Entorno de Eclipse.

La aplicación terminada generalmente ocupa mayor espacio en memoria que una

hecha bajo programación clásica (escrita).

Si no se cuenta con conexión a internet, es imposible desarrollar aplicaciones.

Requiere forzosamente de una cuenta de correo de la empresa Google.

Limita la creatividad del desarrollador a unas cuantas herramientas.

Anteriormente quizá su mayor desventaja era que no se podı́a utilizar App Inventor
a menos que se recibiera una invitación a su correo de Google.

Para poder subir las aplicaciones al Market se requiere de otro software para hacer
compatible la aplicación con los requerimientos de Android Market, sin en cambio
Eclipse no requiere de este software extra.
50 CAPÍTULO 3. ANDROID

La estructura básica de APP Inventor está conformada por 4 partes, las cuales son
fundamentales para el funcionamiento correcto de esta aplicación (Fig. 3.19).

Figura 3.19: Estructura de APP Inventor.

Google App Inventor Server.

App Inventor Ventana de Diseño.

App Inventor Editor de Bloques.

App Inventor Android Emulador o Teléfono.

La primer parte de este esquema; Google App Inventor Server, es simplemente el

servidor de Google que nos proporciona lo necesario para diseñar una aplicación, y este
estará activo indirectamente siempre que haya internet y este dentro de la pagina de
desarrollo.
3.5. ESTRUCTURA BÁSICA DE APP INVENTOR 51

3.5.1. Ventana de Diseño

Para visualizar esta ventana en donde se seleccionaran los componentes de la aplica-
ción, primero debe de crear un nuevo proyecto, para esto una vez dentro de App Inventor
(Fig. 3.20); tener en cuenta que en esta ventana de My Project es donde tendremos al-
macenadas todas las aplicaciones que desarrollemos, por lo que es aquı́ donde podremos
acceder para modificar, borrar o crear más proyectos.

Figura 3.20: Crear el primer Proyecto en App Inventor.

Para poder llevar acabo la creación del primer proyecto, damos clic en el botón de
New y a continuación le asignamos un nombre. Automáticamente después de presionar
ok nos mostrara la Ventana de Diseño (Fig. 3.21).
La Ventana de Diseño está conformada por cinco partes escenciales:

Paleta de Componentes

Vista Previa del Diseño

Componentes de la aplicación

Propiedades de los componentes

Barra de Herramientas

Paleta de componentes

En la Paleta de componentes se encuentran todos los componentes que podemos uti-

lizar para empezar a diseñar nuestra aplicación en el aspecto visual. La forma en que
52 CAPÍTULO 3. ANDROID

Figura 3.21: Ventana de Diseño.

podemos hacer uso de estos, es simplemente seleccionando y arrastrando con el mouse

hacia la Ventana de Diseño para observar la vista previa del diseño (Fig. 3.22).

Figura 3.22: Paleta de Componentes.

3.5. ESTRUCTURA BÁSICA DE APP INVENTOR 53

Esta paleta nos muestra los componentes de acuerdo a una clasificación especı́fica,
estos componentes pueden ser de dos tipos haciendo referencia a la forma de visualizarlos,
si los componentes se pueden observar en la aplicación final, se denotaran como visuales;
si son componentes que ejecutan tareas pero no se ven en la aplicación final, se denotaran
en la redacción como no visuales:

1. Componentes Básicos (Fig. 3.23).

Button: Permite colocar el componente de botón en la aplicación que estamos

desarrollando (visual).

Canvas: Permite colocar el componente para trabajar con pixeles y coordenadas

(dibujos, rayas, cı́rculos) en la aplicación que estamos desarrollando(visual).

CheckBox: Permite colocar el componente de cajas de selección en la aplicación

que estamos desarrollando (visual).

Clock: Permite colocar el componente de reloj en la aplicación que estamos

desarrollando para temporizadores (no visual).

Image: Permite colocar el componente de insertar imagen en la aplicación que

estamos desarrollando (visual).

Label: Permite colocar el componente de Etiqueta en la aplicación que estamos

desarrollando (visual).

ListPicker: Permite colocar el componente de Lista de opciones en la aplicación

que estamos desarrollando (visual).

PaswordTextBox: Permite colocar el componente de Caja de texto para con-

traseñas en la aplicación que estamos desarrollando (visual).

TextBox: Permite colocar el componente de Caja de texto en la aplicación que

estamos desarrollando (visual).

TinyDB: Permite colocar el componente para el manejo de Base de Datos en

la aplicación que estamos desarrollando (no visual).
54 CAPÍTULO 3. ANDROID

Figura 3.23: Componentes Básicos.

2. Componentes Multimedia (Fig. 3.24).

Camera: Permite colocar el componente para acceso a propiedades y funciones

de la cámara en la aplicación que estamos desarrollando (no visible).

ImagePicker: Permite colocar el componente de imágenes interactivas en la

aplicación que estamos desarrollando (visible).

Player: Permite colocar el componente de reproducción multimedia en la apli-

cación que estamos desarrollando (no visible).

Sound: Permite colocar el componente para agregar sonidos en la aplicación

que estamos desarrollando (no visible).

VideoPlayer: Permite colocar el componente para el manejo de videos en la

aplicación que estamos desarrollando (visible).
3.5. ESTRUCTURA BÁSICA DE APP INVENTOR 55

Figura 3.24: Componentes Multimedia.

3. Componentes Animados (Fig. 3.25).

Ball: Permite colocar el componente para un balón con animación en la aplica-

ción que estamos desarrollando, se podrá meter a la aplicación si y solo si esta
dentro de un componente Canvas (visible).

ImageSprite: Permite colocar el componente para una imagen con animación

en la aplicación que estamos desarrollando, se podrá meter a la aplicación si y
solo si esta dentro de un componente Canvas (visible).

Figura 3.25: Componentes Animados.

4. Componentes Sociales (Fig. 3.26).

ContactPicker: Permite colocar el componente para buscar un contacto en la

aplicación que estamos desarrollando (visible).

EmailPicker: Permite colocar el componente para buscar o introducir un email

en la aplicación que estamos desarrollando (visible).

PhoneCall: Permite colocar el componente para las propiedades de llamada a

un teléfono en la aplicación que estamos desarrollando (no visible).
56 CAPÍTULO 3. ANDROID

PoneNumberPicker: Permite colocar el componente para introducir un numero

telefónico en la aplicación que estamos desarrollando (visible).

Texting: Permite colocar el componente para acceso a modo texto en la apli-

cación que estamos desarrollando (no visible).

Twitter: Permite colocar el componente para las propiedades de publicación

en twitter dentro de la aplicación que estamos desarrollando (no visible).

Figura 3.26: Componentes Social.

5. Componentes de Sensores (Fig. 3.27).

AccelerometerSensor: Permite colocar el componente para hacer uso de las fun-

ciones de acelerómetro en la aplicación que estamos desarrollando (no visible).

LocationSensor: Permite colocar el componente para hacer uso de las funciones

de gps en la aplicación que estamos desarrollando (no visible).

OrientationSensor: Permite colocar el componente para hacer uso de las fun-

ciones de orientacion en la aplicación que estamos desarrollando (no visible).

Figura 3.27: Componentes de Sensores.

3.5. ESTRUCTURA BÁSICA DE APP INVENTOR 57

6. Componentes de Organización de Pantalla (Fig. 3.28).

HorizontalArrangement: Permite colocar el componente para organizar hori-

zontalmente dentro de sı́ mas componentes en la aplicación que estamos desa-
rrollando (visible).
TableArrangement: Permite colocar el componente para organizar en tablas
dentro de sı́ mas componentes en la aplicación que estamos desarrollando (vi-
sible).
VerticalArrangement: Permite colocar el componente para organizar vertical-
mente dentro de sı́ mas componentes en la aplicación que estamos desarrollando
(visible).

Figura 3.28: Componentes de Organización.

7. Componentes de LEGO MINDSTORMS (Dedicado especialmente para el Robot

MindStorms) (Fig. 3.29).

NxtColorSensor: Permite colocar el componente para el sensor de color (no

visible).
NxtDirectCommand: Permite colocar el componente para comandos directos
(no visible).
NxtDriver: Permite colocar el componente para los drivers (no visible).
NxtLightSensor: Permite colocar el componente para el sensor de luz (no visi-
ble).
NxtSoundSensor: Permite colocar el componente para el sensor de sonido (no
visible).
NxtTouchSensor: Permite colocar el componente para el sensor touch (no visi-
ble).
58 CAPÍTULO 3. ANDROID

NxtUltrasonicSensor: Permite colocar el componente para el sensor ultrasonico

(no visible).

Figura 3.29: Componentes de LEGO MINDSTORMS.

8. Otros Componentes (todos estos componentes al igual que los anteriores son: no
visibles)(Fig. 3.30).

ActivityStarter: Permite colocar el componente para editar la actividad de

arranque de la aplicación.
BarCodeScanner: Permite colocar el componente para leer y procesar códigos
de barras en la aplicación que estamos desarrollando.
BluetoothClient: Permite colocar el componente para manipular todos los ser-
vicios de Bluetooth como cliente en la aplicación que estamos desarrollando.
BluetoothServer: Permite colocar el componente para manipular todos los ser-
vicios de Bluetooth como servidor en la aplicación que estamos desarrollando.
Notifier: Permite colocar el componente para mostrar avisos y notificaciones
personalizadas en la aplicación que estamos desarrollando.
SpeechRecognizer: Permite colocar el componente para identificar comandos
de voz en la aplicación que estamos desarrollando.
TextToSpeech: Permite colocar el componente para utilizar la escritura por voz
en la aplicación que estamos desarrollando.
TinyWebDB: Permite colocar el componente para la manipulación de Bases de
Datos en la Web en la aplicación que estamos desarrollando.
3.5. ESTRUCTURA BÁSICA DE APP INVENTOR 59

Web: Permite colocar el componente para manipular todos los servicios de web
en la aplicación que estamos desarrollando.

Figura 3.30: Otros Componentes.

9. No está listo para su lanzamiento(Fig. 3.31).

FusiontableControl

GameClient

SoundRecorder

Voting

WebViewer

Figura 3.31: Not Ready for Prime Time.

60 CAPÍTULO 3. ANDROID

Para obtener una descripción más detallada de cada componente en la misma paleta,
cada componente está acompañado de un signo de interrogación en el cual podrá dar clic
para desplegar una ventana de información correspondiente al mismo (Fig. 3.32).

Figura 3.32: Descripción de Componentes.

Viewer

Esta sección de la ventana de diseño será la que nos permitirá visualizar el diseño de
nuestra aplicación al momento de estarla desarrollando, es en esta parte donde se jalan
los componentes con los que desea trabajar.

Ya que esta área de trabajo nos muestra una pantalla que emula un dispositivo móvil,
podremos ver la apariencia que tendrá al momento de estar ejecutándose en el dispositivo.

En esta sección, seremos capaces de ver los componentes no visibles en la parte inferior
y fuera de la pantalla emulada del dispositivo (Fig. 3.33).

Components

Esta sección dentro de la ventada de diseño, nos permite ver los componentes que
hemos elegido para desarrollar la aplicación en forma de árbol; en esta parte se incluyen
los componentes no visibles en la misma jerarquı́a que los visibles.
3.5. ESTRUCTURA BÁSICA DE APP INVENTOR 61

Figura 3.33: Area de Trabajo.

Los componentes que van dentro de un Canvas o una Caja de orden, ya sea vertical,
horizontal o de tabla se muestran en otra jerarquı́a (Fig. 3.34).

Esta sección nos permite cambiar el nombre que por defecto proporciona App Inventor
a cada componente, para facilitar la identificación a la hora de trabajar en el editor de
bloques; de igual forma nos permite borrar un componente que ya no nos sea útil y por
último en la parte inferior tenemos la posibilidad de cargar las imágenes que deseamos
ocupar dentro de nuestra aplicación (el nombre de la imagen no debe de tener caracteres
especiales para ser reconocida).

Properties

La sección de propiedades dentro de la Ventana de Diseño nos permite modificar las

propiedades que tiene cada uno de los componentes que estén en nuestra área de trabajo
(Fig. 3.35).

Estas propiedades son diferentes dependiendo del componente seleccionado, para men-
62 CAPÍTULO 3. ANDROID

Figura 3.34: Seccion de Componentes.

cionar algunas de ellas haremos referencia a las propiedades que salen por defecto al cargar
nuestra área de trabajo que corresponden al Screen o pantalla principal, estas propiedades
son:

BackgroundColor: Nos permite seleccionar el color que deseamos en la pantalla

principal de nuestra aplicación.

BackgroundImage: Nos permite colocar una imagen de fondo que previamente ha-
yamos cargado en la sección de componentes.

Icon: Permite cambiar el icono de la aplicación que se genera por default; cargándolo
previamente en la sección de componentes.

ScreenOrientation: Se elige la orientación que deseemos que tenga nuestra aplicación;

vertical, horizontal o que dependa de la posición del dispositivo móvil.

Scrollable: Coloca una barra deslizadora en caso de que nuestra aplicación se mas
grande que la pantalla de nuestro dispositivo.
3.5. ESTRUCTURA BÁSICA DE APP INVENTOR 63

Title: Podemos poner un nombre personalizado al tı́tulo de la pantalla principal.

Figura 3.35: Seccion de Propiedades.

Barra de Herramientas

Esta sección es la que se localiza en la parte superior y nos permite estar navegando
por nuestros proyectos (aplicaciones) que tengamos y poder editarlas, nos da la opción de
guardar la aplicación que se encuentre actualmente en el área de trabajo, guardar con otro
nombre la misma aplicación usando el botón:“Guardar Como ” ; nos permite establecer
un punto de recuperación con el Checkpoint,abrir el Editor de Bloques y por último, da
la opción de descargar nuestras aplicaciones ya sea en el teléfono, en la PC o generar el
BarCode para el link de descarga de nuestra aplicación (Fig. 3.36).

Figura 3.36: Barra de Herramientas.

64 CAPÍTULO 3. ANDROID

3.5.2. Editor de Bloques

Para poder trabajar con esta herramienta es necesario que se encuentre abierta la
Ventana de Diseño, ya que en ella está el botón que nos permite accesar al Editor de
Bloques; este botón se localiza en la parte superior derecha de la Ventana de Diseño (Fig.
3.37).

Figura 3.37: Boton para abrir Editor de Bloques.

Hay que tomar en cuenta que para poder trabajar en este editor, previamente se
debió de agregar componentes en la Ventana de Diseño, ya que es donde se reúnen los
bloques de programa que especifican cómo deben comportarse los componentes. Estas
acciones y configuraciones se programan montando y ensamblando bloques de código
semejantes a un rompecabezas (Fig. 3.38).

Figura 3.38: Editor de Bloques.

El Editor de Bloques al igual que la Ventana de Diseño consta de varias secciones

especializadas en alguna tarea; en este caso esas secciones son:

Sección de Bloques
3.5. ESTRUCTURA BÁSICA DE APP INVENTOR 65

Área de trabajo

Barra de herramientas

Sección de bloques

En esta sección se encuentran los bloques de acción correspondientes a los componentes

que elegimos en la Ventana de Diseño, también encontramos bloques de construcción de
programa y bloques avanzados.

Mis Bloques: Se encuentran las condiciones de acciones y propiedades generales que

contiene cada componente, por ejemplo un componente botón tiene la acción de ser
presionado, presionado por largo tiempo, visibilidad, que este activado o desactivado
y propiedades como texto, color de fondo; entre otros (Fig. 3.39).

Figura 3.39: My Blocks.

Build In: Contienen bloques de código que ya están definidos por el Editor de Blo-
ques, nos ayudan a realizar operaciones lógicas, condiciones, definir variables, reali-
zar programación de control, editar textos y cambiar colores entre otras funciones
(Fig. 3.40).
66 CAPÍTULO 3. ANDROID

Figura 3.40: Build-In.

Avanzado: Son bloques de código más especializados sobre los componentes que
definimos anteriormente en la Ventada de Diseño (Fig. 3.41).

Figura 3.41: Advanced.

3.5. ESTRUCTURA BÁSICA DE APP INVENTOR 67

Área de trabajo

Este es evidentemente el espacio que tenemos en blanco para poder arrastrar los blo-
ques de programación y empezar a armar la lógica de nuestro programa, en esta área
de trabajo se encuentra un “bote de basura” , en donde podemos arrastrar las piezas de
código que ya no nos sirvan (Fig. 3.42).

Figura 3.42: Área de Trabajo.

En el área de trabajo, podemos dar clic en un espacio limpio de bloques, para con-
vocar a las funciones correspondientes a Built In de forma directa. Esta área de trabajo
cuenta con un zoom gráfico en la parte superior derecha con la que podemos explorar
todos nuestros bloques de código que hemos armado en el área de trabajo.

Esta área de trabajo puede expandirse de acuerdo con las necesidades del programador,
si requiere más espacio para programar, automáticamente se lo proporciona esta área.

Barra de Herramientas

Las herramientas con las que cuenta son: salvar o guardar la programación de bloques
hecha, ir a un estado anterior, ir a un estado posterior, cargar un emulador para correr la
aplicación, conectarse a un dispositivo y un zoom de barra deslizable (Fig. 3.43).
68 CAPÍTULO 3. ANDROID

Figura 3.43: Barra de Herramientas.

La importancia de estas herramientas es fundamental, y más si nos enfocamos a las

dos herramientas centrales: New emulator y Connect to Device. La primer herramienta
nos permite cargar un emulador donde se podrá ejecutar nuestra aplicación; es posible
visualizar el comportamiento final de la aplicación en desarrollo,permite ver errores de
ejecución para corregirlos. Esta opción esta en caso de que no se cuente con un dispositivo
Android en el momento de programar y se desee ver cómo se comporta la aplicación en
tiempo de ejecución.

Se debe considerar que al cargar un emulador en el equipo donde se lleva acabo la

programamación de la aplicación, hará que se consuma más recursos de memoria; ya que
el cargar este emulador equivale básicamente a estar corriendo el sistema operativo de un
celular con las funciones básicas al mismo tiempo que corre el Sistema Operativo, y las
aplicaciones que se tengan en el equipo de cómputo (Fig. 3.44).

Figura 3.44: Emulador Android.

La segunda herramienta nos permite conectarnos a un dispositivo fı́sico o en su defec-

3.6. INSTALACIÓN Y DISTRIBUCIÓN DE APLICACIONES (ANDROID MARKET)69

to al emulador que se cargo previamente; si es que se cuenta con un dispositivo Android

conectado por USB al equipo de cómputo, y este dispositivo está configurado dentro de
desarrollo con la depuración USB, será posible que el Editor de Bloques reconozca el
dispositivo, se conecte para enviarle la aplicación y que se ejecute en tiempo real de pro-
gramación.

Esta opción da un panorama acertado de cómo se verá la aplicación ejecutándose en

el dispositivo, y se podrá ver las modificaciones tanto del Editor de Bloques como de la
Ventana de Diseño en tiempo real.

3.6. Instalación y distribución de Aplicaciones (An-

droid Market)
Para la distribución de aplicaciones Android, existen sitios oficiales para subir y bajar
dichas aplicaciones si eres un desarrollador, en el caso de Android está el Android Market
(Fig. 3.45). Al no ser este un sistema operativo cerrado, te permite instalar aplicaciones
que no están dentro del market estrictamente, simplemente dando el permiso de Origen
Desconocido desde Configuración/Aplicaciones/Origen Desconocido, en tu celular, podrás
instalar aplicaciones fuera del Market.

Figura 3.45: Android Market.

3.6.1. Bajar Aplicaciones desde Android Market

Para poder bajar aplicaciones del Android Market, debes de contar con la aplicación
del mismo en tu dispositivo móvil, el cual en la mayorı́a de los casos viene por default,
cuando abres por primera vez el market desde el móvil, te pide una cuenta de Google con
la que será registrado tu equipo, una vez hecho este registro gozaras de los beneficios de
descargas de aplicaciones gratis y algunas con un costo nada excesivo (Fig. 3.46).
70 CAPÍTULO 3. ANDROID

Figura 3.46: Aplicacion Android Market.

Si descargas desde otros sitios y desde tu computadora puedes guardar el archivo apk
y después pasarlo al dispositivo móvil a través del cable USB a la tarjeta de memoria del
dispositivo, una vez almacenada, buscas la aplicación con algún explorador y procedes a
instalarla (para poder instalar aplicaciones que no son de market recuerda dar el permiso
antes mencionado).

3.6.2. Subir Aplicaciones desde Android Market

Para subir aplicaciones al Android Market, se requiere una serie de pasos que a con-
tinuación se describirán:

Requisitos

Tener una cuenta google por ejemplo la de gmail y tenerla asociada a google chec-
kout.

Para entrar en el programa de desarrolladores de android tienes que pagar US$25,00.

Importante

Al exportar la aplicación .apk revisa sobretodo el paso de firmar la app antes de

publicarla, ya que al no estar bien firmada, no se va a poder instalar y lo peor, no podrás
3.6. INSTALACIÓN Y DISTRIBUCIÓN DE APLICACIONES (ANDROID MARKET)71

borrarlas de tu panel de control.

Pasos para firmar una aplicación desde eclipse:

1. Al exportar te pedirá crear o usar una keystore existente, si no tienes ninguna creada
introduce un nombre y contraseña.

2. Luego tienes que crear una key única para cada app, aquı́ no utilices el mismo login
de la keystore.

Pasos para firmar una aplicación desde App Inventor:

Como se menciono anteriormente en las ventajas y desventajas de App Inventor, para

poder subir una aplicación al market, se debe pasar por un proceso de conversión para la
compatibilidad de los requerimientos exigidos por Android Market.

Pasos para poder transformar nuestros .apk para poder subirlos al android market.

1. Lo primero que tenemos que hacer es descargar el archivo AppToMarket. Programa

para transformar los archivos .apk de App Inventor en archivos válidos para subirlos
al Android Market.

AppToMarket v2.3

Archivo comprimido formato ZIP [32.9 MB]

2. Descomprimes el archivo.

3. Y procedes a la conversión de la aplicación generada en App Iventor.

Pasos para subir tu App estando en la Página de Android Market y con tu

cuenta activa

1. Clic al botón “Upload Application” .

2. Te saldrá un formulario que tendrás que llenar

3. Dentro del formulario se solicita subir algunas capturas de tu App.

4. Si estás seguro que todo es correcto, dale clic a “Publish” .

72 CAPÍTULO 3. ANDROID

5. Las Apps que publiques se mostrarán instantáneamente en el Market, sin ningún

tipo de aprobación.

6. Una vez se haya creado y subido la aplicación, en la ventana principal de la cuenta

activa aparecerá una lista que mostrara las aplicaciones plublicadas.
Capı́tulo 4

Aplicación ATOM y Prototipo

Este proyecto implica desarrollar una aplicación compatible con el Sistema Operativo
Android para dispositivos móviles que sea capaz de comunicarse a distancia mediante
Bluetooth a un receptor que procesa la información recibida y a su vez ordena a un con-
junto de dimmers que ejecuten tareas especı́ficas e independientes para la regulación de
las lámparas.

En el desarrollo de este capı́tulo se llevará a cabo el diseño y construcción de cada uno

de los sistemas que componen este proyecto.

4.1. Construcción y Programación de un Dimmer

En primera instancia para este proyecto, se consideró que era necesaria y fundamen-
tal la construcción de una serie de dimmers para hacer el control de la iluminación en
las lámparas. Estos dimmer deben de tener ciertas caracterı́sticas que permitan ser con-
trolados mediante pulsos, voltaje o corriente, por lo que la fabricación de un dimmer
convencional a con resistancia variable quedó descartado desde el comienzo.

Se analizó la posibilidad de utilizar un microcontrolador para gestionar las órdenes de

atenuación que son mandadas a la etapa de potencia correspondiente, esta propuesta fue
simplemente adoptada para el proyecto. La forma en la que el microcontrolador regula
los disparos del triac es mediante la técnica de detección de cruce por cero.

73
74 CAPÍTULO 4. APLICACIÓN ATOM Y PROTOTIPO

4.1.1. Propuesta y explicación de Hardware

Existe gran cantidad de aplicaciones donde se requiere la regulación de la corriente
alterna, entre ellas, el control de velocidad de motores, la soldadura eléctrica y el flujo en
la iluminación.

La presente etapa tiene como propósito mostrar la regulación de potencia eléctrica uti-
lizando el PIC16F648A (Fig.4.1) y agregando como hardware adicional un optoacoplador
que aı́sla a éste del circuito de potencia constituido por un Triac. La técnica se basa en
que la potencia de salida puede variarse regulando la fase de conducción del Triac tanto
en el semiciclo positivo como en el semiciclo negativo de la onda sinosoidal.

Figura 4.1: Microcontrolador para Dimmer.

Teorı́a de Operación

El circuito contiene un transformador de corriente alterna cuya salida es conectada

al pin RA0 del PIC16F648A a fin de sensar el cruce por cero de la onda sinosoidal y
poder sincronizar la operación del software. El pin RA4 es utilizado como salida de los
pulsos que disparan el optoacoplador. Dos pulsadores (se eliminarán al implementar en el
sistema conjunto) conectados a los pines RB0 y RB1 son utilizados para elevar y bajar
respectivamente la potencia suministrada a la carga.

Hardware

El hardware diseñado para este proyecto se muestra en la (Fig.4.2). Este circuito

puede manejar cargas de 120 VAC de hasta 150W (ideal para 4 a 5 lámparas ahorradoras
y dimeables). El Pin MCLR el cuál es activo bajo, se configura como entrada y es usado
4.1. CONSTRUCCIÓN Y PROGRAMACIÓN DE UN DIMMER 75

como Reset del microcontrolador. La frecuencia de trabajo es de 4MHz y todo el circuito

es alimentado con +5 voltios. Los pulsadores son utilizados para incrementar y disminuir
la tensión aplicada a la carga.

Figura 4.2: Circuito Propuesto.

Una vez propuesto el circuito. Con ayuda de un software para el diseño de placas PCB
(PCB Wizard), se realizó el diagrama correspondiente (Fig. 4.3).

Figura 4.3: Placa PCB con Elementos, Pistas y Puentes.

76 CAPÍTULO 4. APLICACIÓN ATOM Y PROTOTIPO

4.1.2. Programa del microcontrolador y explicación

El desarrollo del código para el microcontrolador encargado de controlar las funciones
del Dimmer, se elaboró en el software oficial de Microchip: MPLAB IDE 7.5, y con el
compilador gratuito CC5X.

La idea y la estructura básica del código se retomó de una propuesta de Scott Fink
Microchip 1997(ver Apéndice:PICREF-4), y fue adaptada para operar en el microcontro-
lador PIC16F648A, en este código se establece:

Detección de cruce por cero.

Estabilización de la tensión mediante la detección de cruce por cero.

Sincronización en la fase de lı́nea.

Tiempo preciso en el que se le manda el pulso al optoacoplador.

Rutina para regular la intensidad de la luz mediante push botón.

Reset del programa en ejecución.

Estos aspectos que se mencionan, se pueden ver descritos en el código de programa

adaptado (ver Apéndice:Código Dimmer Adaptado).

4.2. Construcción y Programación de Receptor Blue-

tooth
En segunda instancia se pensó en el diseño de un receptor el cual darı́a las instruccio-
nes a los dimmers para atenuar, apagar o encender las lámparas; este receptor recibe la
información de forma inalámbrica mediante Bluetooth. Al igual que la construcción de los
dimmers, se propusó trabajar con un microcontrolador con las caracterı́sticas necesarias
para manipular una serie de dimmers y recibir información a través de un módulo de
Bluetooth por el puerto USART.

El microcontrolador propuesto para esta tarea es el PIC18F4550 (Fig. 4.4), el cuál

cuenta con 40 pines, 5 puertos, dos puertos de comunicación USART, soporta la conexión
4.2. CONSTRUCCIÓN Y PROGRAMACIÓN DE RECEPTOR BLUETOOTH 77

USB y tiene una frecuencia de trabajo máxima de 48MHz, complementada con un cristal
de 20MHz.

Figura 4.4: Microcontrolador para Receptor Bluetooth.

4.2.1. Propuesta y explicación de Hardware

Para el diseño del hardware de esta segunda etapa se propuso hacer un circuito en
la que el microcontrolador PIC18F4550 esté operando con una frecuencia de trabajo
de 48MHz por lo que el cristal fı́sico debe de ser de 20MHz. Sin contar los pines de
alimentación, RESET, osciladores, comunicación USB y los pines TX y Rx del USART,
podemos contar con 28 pines libres para usarlos en la comunicación con los dimmer
anteriormente desarrollados (Fig. 4.5).
Los dos pulsadores que son utilizados en los dimmer propuestos anteriormente, serán
sustituidos por pulsos enviados por el micorcontrolador descrito en esta sección. Se pre-
tende que este receptor sea capaz de mandar instrucciones a 14 dimmers independientes,
teniendo en cuenta que cada dimmer puede atenuar un total de 4 a 5 lámparas simulta-
neas, nos da un total de 56 lámparas (para el caso de 4 lámparas por dimmer) controladas
en 14 bloques.

En los pines de transmisión y de recepción se colocará un módulo de Bluetooth (RN41),

con el que se podrá hacer la comunicación y tendrá un alcance de 100 mts. (ideales y bajo
lı́nea de vista).

Una vez propuesto el circuito de hardware minimo. Con ayuda de un software para el
78 CAPÍTULO 4. APLICACIÓN ATOM Y PROTOTIPO

Figura 4.5: Hardware minimo para operar PIC18F4550.

diseño de placas PCB (PCB Wizard), se realizá el diagrama correspondiente. Para esta
parte del proyecto se agregó al circuito una fuente de 5 VCD con la que se alimenta tanto
al microcontrolador como al módulo de Bluetooth (Fig. 4.6).

4.2.2. Programa del microcontrolador y explicación

El desarrollo del código para el microcontrolador encargado de controlar los Dimmers
y recibir los datos vı́a Bluetooth, se elaboró en el software oficial de Microchip: MPLAB
IDE 8.7, y con el compilador gratuito CC8X.

La idea y la estructura básica del código es un diseño propio, por lo que se hizo
especialmente para el microcontrolador PIC18F4550, en este código se establece:

Activación de la comunicación USART.

4.3. ESTABLECIENDO COMUNICACIÓN BLUETOOTH 79

Figura 4.6: Placa PCB con Elementos y Pistas

Configuración adecuada de todos los Registros y de la frecuencia de trabajo.

Estableces la velocidad de transmisión en bps.

Lectura de los datos entrantes por el puerto USART.

Comparación de datos y designación de tareas para los Dimmer.

Reset del programa en ejecución.

Estos aspectos que se mencionan, se pueden ver descritos en el código de programa

(ver Apéndice:Código Receptor).

4.3. Estableciendo Comunicación Bluetooth

En tercera instancia se debe de atender el problema de la comunicación Bluetooth,
para esto se propone utilizar el módulo de Bluetooth RN41 distribuido por Rovinson
80 CAPÍTULO 4. APLICACIÓN ATOM Y PROTOTIPO

Network y adaptado por Sparkfun, este módulo tiene la capacidad de transmitir y recibir
datos vı́a Bluetooth de forma serial (Fig. 4.7).

Figura 4.7: Modulo Bluetooth adaptado por Sparkfun.

Ya que este módulo esta especialmente hecho para trabajar con microcontroladores
mediante una conexión serial, su trabajo será acoplado con el PIC18F4550, para que
mande al microcontrolador los datos que reciba a través del Bluetooth.

4.3.1. Arreglo de Hardware para la prueba

Para realizar pruebas de comunicación Bluetooth con este módulo, gracias a la adap-
tación hecha por Sparkfun, es posible alimentar con un rango de voltaje entre 3 y 5 VCD,
la placa en la que se encuentra montado este módulo te da acceso a las terminales de
VCC, GND, Rx, Tx, CTS y RTC, de las cuales nosotros hacemos uso sólo de las primeras
cuatro terminales.

Dependiendo de la variante que se tenga en la placa de BlueSMiRF (nombre de la dis-

tribución adaptada de Sparkfun Fig. 4.8), es como debe de colocar el módulo de Bluetooth
en una protoboard para hacer las conexiones y pruebas pertinentes; y poder cerciorarse
de que el dispositivo este en buen estado.

Para alimentar el módulo requiere de una fuente de 5 VDC o 3 VDC, conectada

respectivamente en los señalamientos que vienen en la BlueSMiRF para VCC y GND, en
cuanto a las terminales Tx y Rx se cortocircuitaron para que de esta manera al momento
de hacer el test, se pueda comprobar si los datos que se mandan vı́a Bluetooth, los recibe
4.3. ESTABLECIENDO COMUNICACIÓN BLUETOOTH 81

Figura 4.8: Módulo Bluetooth BlueSMiRF 01.

Figura 4.9: Módulo Bluetooth BlueSMiRF 02.

el receptor (Rx) del módulo, y a su vez es capaz de mandar por el transmisor (Tx)(Fig.
4.10).

Figura 4.10: Conexión de de Módulos 01 y 02.

82 CAPÍTULO 4. APLICACIÓN ATOM Y PROTOTIPO

4.3.2. Pruebas de conexión con HyperTerminal

Para realizar las pruebas pertinentes que demostráran si el módulo de Bluetooth fun-
ciona correctamente, es necesario contar con un equipo de cómputo el cual debe de contar
con Bluetooth ya sea integrado o en su defecto externo mediante un adaptador Dongle
USB y como software una HyperTerminal, que en caso de tener Windows XP viene por de-
fault en la ruta: Inicio/Todos los Programas/Accesorios/Comunicaciones/HyperTermnal;
si el Sistema Operativo es uno más actual o de otro distribuidor, es posible bajarlo de la
Web.

Una vez iniciada la HyperTerminal, vendrán las ventanas de configuración (Fig. 4.11)
para establecer la comunicación serial. Para configurar estas ventanas, anteriormente se
emparejó el módulo de Bluetooth BlueSMiRF con nuestro equipo de cómputo, y este
último ya creó un puerto COM virtual para el módulo (la forma de establecer este puerto
COM, es mediante la disponibilidad de tu equipo y el software que se tenga para detectar
dispositivos Bluetooth), con obviedad recalco que para este proceso el módulo de BT
(Bluetooth) debe de estar alimentado y conectado como se especificó anteriormente.
En las ventanas de configuración se colocan los siguientes datos para poder continuar
y establecer la conexión:

Descripción de la Conexión

1. Nombre: Se puede poner cualquier nombre que se desee.

2. Icono: Se puede poner cualquier icono que se desee.

Conectarte a:

1. Conectar usando: Seleccionar el puerto COM virtual que el equipo de cómputo

le asignó al módulo BT.

Propiedades del puerto COM

1. Bits por segundo: Escoge los bps con los que quieres que trabaje la conexión,
preferente la primera vez escoger 9600 bps.

2. Bits de datos: Seleccione los bits de datos que estará mandando, colocar pre-
ferentemente 8.
4.3. ESTABLECIENDO COMUNICACIÓN BLUETOOTH 83

Figura 4.11: Ventanas de Configuración HyperTerminal.

3. Paridad: Establece si quiere una comunicación serial con paridad o sin paridad,
preferentemente la primera vez: None.
4. Bit de paro: Configura el bit de paro para la trama de caracteres a enviar,
preferentemente por primera vez: 1.
5. Control de flujo: Determina si desea que el control lo realice el hardware, para
la primera vez: Ninguno.

Una vez configurada la Hyperterminal nos mostrará la ventana principal donde po-
dremos hacer las pruebas pertinentes, como se especifica en el Capitulo 2 puede entrar a
modo comando con “$$$” y salir de modo comando con “—” ; dentro de modo coman-
do, para hacer las configuraciones necesarias; puede teclear: ’h’ y desplegara todos los
comandos soportados por el módulo de BT (Fig. 4.12). Enfocándonos a los comandos que
nos conciernen tecleamos el comando: ’d’ y nos desplegara las funciones principales del
84 CAPÍTULO 4. APLICACIÓN ATOM Y PROTOTIPO

módulo de BT, donde cambiaremos la velocidad de bits por segundo a 9600 bps con el
comando: ’su, 96’ (véase Apéndice).

Figura 4.12: Módulo BT en modo comando HyperTerminal.

Desde este momento, hemos comprobado que el módulo BT funciona correctamente,

pero para eliminar dudas, salimos de modo comando y ya fuera de este podemos teclear
cualquier carácter, si aparece en la pantalla se habrá tenido éxito ya que aunque parezca
que simplemente estas tecleando, en realidad lo que se hizo es mandar el carácter vı́a
Bluetooth al módulo BT que lo recibió, y como está en corto circuito lo que recibe (Rx)
con lo que transmite (Tx), significa que éste mando el carácter de vuelta a la terminal.
Es ası́ como se comprueba y se configura el módulo BT.

4.4. Diseño y Desarrollo de la aplicación ATOM

En esta sección se pretende explicar de una forma clara y sencilla el procedimiento
que se llevó acabo para el diseño y desarrollo de la aplicación correspondiente al Sistema
Operativo Android; de tal forma que permita establecer una conexión vı́a Bluetooth entre
el dispositivo móvil y el microcontrolador PIC18F4550 que será el encargado de regir una
serie de dipositivos dimmer para llevar acabo la regulación de las luminarias.
4.4. DISEÑO Y DESARROLLO DE LA APLICACIÓN ATOM 85

4.4.1. Propuesta y descripción de la aplicación

La aplicación debe de ser capaz de comunicarse vı́a Bluetooth con el circuito receptor
de forma que permita enviar datos de acuerdo a las órdenes que el usuario del dispositivo
móvil establezca.

Ésta aplicación tendrá una interfaz gráfica que permitirá al usuario escoger con quién
se establecerá la conexión dentro de una lista de dispositivos Bluetooth, su estructura
básica estará compuesta de 3 funciones de mando;dentro de éstas funciones se encuentra
MÍN-MÁX,será posible variar el nivel de flujo luminoso a un mı́nimo o máximo, ya sea
para hasta 14 lámparas de forma independiente o simultánea; la siguiente función es la
DIMMER que como su nombre lo indica, permite la atenuación de hasta 14 lámparas
de forma independiente o simultánea; por último se encuentra la función de ACELERO-
METRO, con ésta función es posible llevar acabo la atenuación de 14 lámparas de forma
simultánea haciendo uso de las propiedades que ofrece éste sensor (Fig.4.13).

Figura 4.13: Ventanas Principal de la Aplicación.

86 CAPÍTULO 4. APLICACIÓN ATOM Y PROTOTIPO

4.4.2. Desarrollo y esquema de la aplicación

En este apartado se procede a la explicación de los pasos que se llevaron a cabo para
la elaboración de la aplicación.

Como se mencionó en el capitulo anterior, la aplicación se desarrolló en App Inventor,

por lo que los pasos para crear un nuevo proyecto y la forma de agregar elementos a el
Área de Trabajo se omitirán en este apartado.

En el Área de trabajo incluimos por razones de comunicación el componente de Blue-

tooth Cliente y por razones de manipulación, el componente Sensor Acelerómetro, entre
otros como botones, organizadores, tablas, etiquetas e imágenes (Fig.4.14).

Figura 4.14: Area de Trabajo en el Desarrollo de la Aplicación.

En cuanto al Editor de Bloques se configuró la comunicación Bluetooth y se estable-

cieron las condiciones para enviar los datos al receptor, tanto de la función para mı́nimos
y máximos en las iluminarias, dimmers y acelerómetro (Fig.4.15). En el programa se en-
cuentra la funcionalidad de cada componente de la aplicación (ver Apéndice: Programa
en Editor de Bloques).
4.5. INTEGRACIÓN DE TODAS LAS ETAPAS DEL SISTEMA 87

Figura 4.15: Editor de Bloques de la Aplicación.

4.4.3. Prueba y depuración con HyperTerminal en la PC

Una vez finalizado el diseño y desarrollo de nuestra aplicación se procede a realizar las
pruebas necesarias para comprobar que su funcionamiento sea el adecuado; para ello es
necesario descargar e instalar la aplicación a nuestro celular, a continuación se lleva acabo
la configuración de la herramienta HyperTerminal como hemos visto anteriormente; de
forma que se pueda comprobar que exista una comunicación vı́a Bluetooth y a su vez,
ésta mande los datos establecidos en nuestra aplicación (Fig.4.16).

4.5. Integración de todas las etapas del sistema

Para llevar a cabo los objetivos planteados, y al haber hecho las pruebas necesarias de
todos los subsistemas descritos anteriormente, solo queda la culminación que se realizó in-
tegrando y enlazando todos los subsistemas para que al interactuar cumplieran con los
requerimientos establecidos en los objetivos. Por lado la aplicación logre comunicarse con
el receptor de Bluetooth y este a su vez se comunique con los Dimmers que controlaran
la intensidad de las luminarias.
88 CAPÍTULO 4. APLICACIÓN ATOM Y PROTOTIPO

Figura 4.16: Pruebas y Depuración de Comunicación.

4.5.1. Diseño del hardware conjunto

Debido a que la finalidad de nuestro proyecto es la de llevar a cabo un sistema de

control que permita la atenuación de las luminarias, es necesario integrar todas los subsis-
temas que en conjunto serán capaces de realizar dicha tarea, como es el caso del circuito
receptor Bluetooth que se encargará de regir una serie de dispositivos dimmer que a su
vez permitirán la atenuación de las lámparas con su respectiva etapa de potencia. Este
prototipo de Hardware permitirá al usuario contar con un receptor de Bluetooth y una
serie de dimmers integrados; contando de igual manera con la posibilidad de expandirse
mediante la utilización de módulos independientes de dimmers (Fig.4.17).

Figura 4.17: Propuesta de Hardware Conjunto

4.5. INTEGRACIÓN DE TODAS LAS ETAPAS DEL SISTEMA 89

Una vez propuesto el circuito de hardware para el sistema completo. Con ayuda de un
software para el diseño de diagramas eléctricos (Livewire), se realizá el diagrama corres-
pondiente al hardware conjunto(Fig. 4.18).

Figura 4.18: Diagrama Eléctrico del Sistema Completo

Una vez propuesto el circuito de hardware para el sistema completo. Con ayuda de un
software para el diseño de placas PCB (PCB Wizard), se realizá el diagrama correspon-
diente(Fig. 4.19).
90 CAPÍTULO 4. APLICACIÓN ATOM Y PROTOTIPO

Figura 4.19: Placa PCB del Sistema Completo

Pruebas y Resultados

Como resultado de la investigación realizada, el modelado del diagrama conjunto,

y de la aplicación desarrollada para el Sistema Operativo Android, el cuál integra las
especificaciones inı́ciales del sistema, detalladas en el contenido de la investigación. Debido
a que el sistema está formado por varios módulos y probado con diferentes modelos de
lámpara E27, a continuación se presentan los resultados de manera individual. Para las
pruebas experimentales se realizaron las siguientes mediciones:

Las pruebas de funcionalidad de la aplicación del mando a distancia fueron las

siguientes:

• Distancia máxima para la emisión de datos vı́a Bluetooth.

• Verificación de los datos emitidos por la aplicación.

• Pruebas de conexión con el módulo de Bluetooth.

• Funcionamiento correcto de acelerómetro.

Las pruebas de funcionamiento y comportamiento de los dispositivos dimmers que

se realizaron, fueron con las siguientes lámparas:

• Lámpara de LED dimmeable.

• Lámpara Fluorescente Compacta autobalstrada y dimmeable.

• Lámpara Incandescente.

Las pruebas relacionadas con el hardware construido fueron las siguientes:

• Prueba de dimmers individuales.

• Prueba de receptor de Bluetooth.

• Prueba de los subsistemas conjuntos.

91
92 PRUEBAS Y RESULTADOS

• Prueba de circuito de sistema completo.

Los resultados a detalle se describen a continuación en el orden que se mencionan en

las lı́neas superiores.

Distancias con las cuales se realizaron pruebas de conexión y verificación de los datos
enviados vı́a Bluetooth, para ello se consideraron las siguientes caracterı́sticas de la zona
de prueba (Tabla.4.20) :

Campo abierto.

Clima soleado (de dı́a).

Sin viento.

Sin obstáculos (Lı́nea de vista).

Tx = Celular Xperia X10 mini.

Rx = Módulo Bluetooth Roving Network.

Figura 4.20: Tabla de Conexión

El funcionamiento del sensor de acelerómetro se puso a prueba enviando datos Blue-

tooth tanto a la HyperTerminal, como al Módulo de Bluetooth (Tabla.4.21):
Al realizar la regulación de iluminación en las diferentes lámparas obtuvimos los re-
sultados que se muestran en la tabla (Tabla.4.22):
En cuanto a las pruebas relacionadas con el hardware propuesto se establecieron los
siguientes rubros al hacer las pruebas: Funcionamiento, Ruido, Acoplamiento y Recepción,
con el valor calificativo en porcentajes ( %)(Tabla.4.23):
 93

Figura 4.21: Tabla de Envio de Datos.

Figura 4.22: Tabla de Comparación de Lámparas.

Figura 4.23: Tabla de Comparación de Lámparas.

Nota: El circuito propuesto para el sistema completo el cual está formado por la parte
receptora y cuatro dimmers con salidas a tres lámparas (la suma de las tres lámparas
menores a 150 Watts) cada uno; en las pruebas su funcionamiento fue de 50 %, debido a
que la etapa de recepción de datos funciona correctamente; la falla está en la etapa de
potencia de los dimmers debido a un error en el diseño de la placa.
94 PRUEBAS Y RESULTADOS
Conclusiones y Recomendaciones
para Trabajos Futuros

4.6. Conclusiones
En cuanto a la recopilación de los datos podemos concluir de acuerdo con los objetivos
especı́ficos que fue posible cumplir con el diseño, la programación y la implementación
tanto de un receptor Bluetooth, un circuito Dimmer con un microcontrolador, en la pro-
puesta y el desarrollo de la aplicación en App Inventor para ser usado en dispositivos
móviles con Sistema Operativo Android, como mando a distancia. La comunicación Blue-
tooth mediante el módulo de Roving Network y el dispositivo móvil fue un éxito.

En materia de proponer e implementar un circuito que conjuntara tanto al receptor

como a varios Dimmers en su arquitectura fallo por causas de diseño, por lo que respecta
al objetivo global podemos concluir que se cumplió siempre y cuando se utilice los sub-
sistemas operando en conjunto; de esta forma si se logro el objetivo buscado.

Referente a contribuir a una opción más para el ahorro de energı́a; como dice la teorı́a
recabada en está investigación; es muy difı́cil medir cuantitativamente con precisión cuan-
to es el ahorro al utilizar una técnica y otro; de la misma forma al utilizar dispositivos
como lo son los dimmer, ya que aunque se considere un método para ahorro de energı́a
no existe una norma de lineamientos aun establecida que pueda regir y estandarizar estos
dispositivos. Pero se puede asegurar que el uso de lámparas ahorradoras mas el uso de
dispositivos que regulan la tensión nos ofrece un ahorro considerable y significativo, por
lo que concluimos que si existe un ahorro de cierta magnitud significativa.

Con respecto a la hipótesis planteada en el Capı́tulo 1, podemos hacer inferencia y

95
96 CONCLUSIONES

concluir que los aspecto de ahorro de energı́a, comodidad e innovación son validas al
termino de esta investigación, con lo que respecta al último aspecto de innovación se
recalca que la tecnologı́a de Android es prácticamente joven de no más de 4 años de edad,
por lo que se asienta que definitivamente es innovador el empleo de estas tecnologı́as en
los sistemas de iluminación eficiente.

4.7. Trabajos Futuros

Algunas sugerencias para futuros desarrollos que tomen como base al presente trabajo
son:

Realizar a parte de una conexión vı́a Bluetooth, realizar una conexión USB para
utilizar una PC como centro de mando.

Transmitir del Sistema receptor al transmisor los estados de cada Dimmer que se
están controlando ası́ como los porcentajes de iluminación que se están llevando a
cabo.

Separar la etapa de potencia de la etapa puramente digital para evitar ruidos de

cualquier naturaleza.

Introducir dentro del mismo microcontrolador receptor código de programa para

tener un juego de dimmers internos.

Realizar dimmers que controlen la frecuencia, para trabajar con lámparas de led
directamente, sin necesidad de ser E27 ni adaptadas para poder ser reguladas con
la tensión de AC común en casa.

Utilizar comando de voz para realizar las operaciones de intensidad lumı́nica médiate
la herramienta bastante nueva de identificador por voz, que Android desarrollo y
que actualmente está en español.
Referencias

J. Smith, J. Speakes, M. H. Rashid,“ An overview of the moderns light dimmer:

Design, Operation and Application IEEE 2005” .

R. Simpson, Lighting Control: Technology and Applications, Focal Press, ISBN-10:

0240515668, ISBN-13: 978-0240515663 May 2003.

D. V. Gadre, Programming and customizing the AVR microcontroller, Editorial

Mc Graw-Hill, 2001.

M. Couedic, Circuitos integrados para tiristores y triacs, Editorial Alfaomega Mar-

combo, Barcelona, España, 2000.

Microchip, Application Note: PICDIM Lamp Dimmer for the PIC12C508, Micro-
chip Technology Inc, 1997.

Carlos A. Narváez V., Regulación de la Potencia Eléctrica Aplicaciones Personales,

2002.

Assaf L. y Avellaneda de Wilde, M., 1985. “ Dispositivos electrónicos como equipos

auxiliares de fuentes luminosas” . Luminotecnia N◦ 19.

Badgery, J., 1989. “ Lighting controls systems practical experiences” . 35th IE-
SANZ National Convention, Auckland.

BRE, 1983. Lighting Controls and Daylight Use. BRE Digest No. 272, Building
Research Establishment,Department of Environment, United Kingdon.

Crisp, V., 1982. Lighting Controls to Save Energy PD 33/82, BRE (Building Re-
search Establishment), Dept. of Environment, Reino Unido.

Crisp, V., 1987. Lighting Research and Technology, Vol.10, No. 2.

Lamata, J, 1982. “ Control del consumo energético en instalaciones a través de

computadoras+ . Luminotecnia 34, Vol. XVI.

97
98 CONCLUSIONES

Roving Networks Bluetooth: Product User Manual, Version 4.77, 2009.

Bluetooth Special Interest Group., Disponible en Internet: URL:
http://www.bluetooth.com.
Bluetooth Special Interest Group., “ Bluetooth Core” , Specification of the Blue-
tooth System, Versión 1.1, 22 de Febrero de 2003. Disponible en Internet: URL:
http://www.bluetooth.com/dev/specifications.asp.
Bluetooth Special Interest Group., “ Bluetooth Profiles” , Specification of the
Bluetooth System, Versión 1.1, 22 de Febrero de 2003. Disponible en Internet:
URL: http:// www.bluetooth.com/dev/specifications.asp.
Developer Android, 28 de Septiembre de 2011. Disponible en Internet: URL:
http://developer.android.com/guide/basics/what-is-android.html.
The Android History, 05 de Noviembre de 2011. Disponible en Internet: URL:
http://www.xcubelabs.com/the-android-story.php# .
Página Oficial de Android, 05 de Noviembre de 2011. Disponible en Internet :
URL: http://www.android.com/.
Página Oficial para Desarrolladores en App Inventor con una cuenta de Google.
Disponible en Internet: URL: http://www.appinventorbeta.com/.
Apéndice

99
100 APÉNDICE
110 PRUEBAS Y RESULTADOS
Editor de Bloques
Editor de Bloques
Editor de Bloques
94 PRUEBAS Y RESULTADOS
Código Dimmer Modificado
#pragma bit Brtbut @ PORTB.0
#pragma bit Dimbut @ PORTB.1
#pragma bit LineInput @ PORTA.0
#pragma bit Salida @ PORTA.4
void Buttoncheck(void); //verificar los pulsadores
void Primer(void);
unsigned int PercentOn, Maxdim; //variables globales
unsigned int TestCheck, Outcount, TestCount;
unsigned int DelayCnt;
unsigned int LastBoth, FirstPass;
unsigned int Count;
unsigned int Maxbrt, NotInTest;

void main()
{
TRISB = 0x03;
CMCON = 7;
Maxbrt = 0xf0; //brillo máximo
NotInTest = 3;
PercentOn = 0xd0; //periodo encendido
Maxdim = 0x70; //valor máximo Dim
TestCheck = 0;
Outcount = 0; //contador salida del modo test
TestCount = 0; //contador modo test
DelayCnt = NotInTest; //contador retardo
LastBoth = 0; //bandera ambos pulsadores presionados la ultima vez
FirstPass = 1;
Count = 0; //contador general
for(Count = 0; Count < 60; Count++) //estabilización tensión
{
while(LineInput == 1);
while(LineInput == 0);
clrwdt();
}
W = 0x5; //1:64 prescale, Pull-up activo
OPTION = W;
W = 0x11; //RA0, RA4 Entradas
TRISA = W;
PORTA = 0x10; //RA4 Latch high
W = 0x3; //RB0, RB1 Entradas
TRISB = W;
while(LineInput == 1) //Sincronización fase linea
clrwdt();
TMR0 = PercentOn;
while(TMR0 >= 3 && LineInput == 0) //retardo entrada punto apropiado
clrwdt();
while(1)
{
Count = 0;
while(Count < DelayCnt) //Verifica pulsadores
{ //cada DelayCnt cruce por cero
Count += 1;
if(LineInput == 1) //si línea AC esta en semiciclo
{ //positivo. incrementa Maxdin y
Maxdim +=15; //resincroniza con la línea
while(LineInput == 1);
while(LineInput == 0)
clrwdt();
}
else
{
while(LineInput == 0) //Espera el cruce por cero
clrwdt();
Maxdim = PercentOn - TMR0 + 2;
 }
if(FirstPass == 1) //Si es el primer pase Full Dim
{
FirstPass = 0;
PercentOn = Maxdim;
}
if(PercentOn < Maxdim)
PercentOn = Maxdim;
TMR0 = PercentOn;
while(TMR0 >= 3 && LineInput == 1)
clrwdt();
PORTA = 0x00; //RA4 Lach Alto
W = 0x01; //RA0 entrada, RA4 Salida
TRISA = W; //Dispara triac
#asm
nop //Retardo disparo del triac
nop
nop
nop
nop
nop
nop
#endasm
W = 0x11; //RA4, entrada
TRISA = W; //Fin señal disparo triac
clrwdt();
if(LineInput == 0) //línea AC en semiciclo negativo?
{
Maxdim +=15; //si es asi incrementa Maxdim
while(LineInput == 0); //y resincroniza con la línea
while(LineInput == 1)
clrwdt();
}
else
{
while(LineInput == 1) //espera cruce por cero
clrwdt();
Maxdim = PercentOn - TMR0 + 2; //compensa full Dim
}
if(PercentOn < Maxdim) //corrija brillo
PercentOn = Maxdim;
TMR0 = PercentOn; //Retardo
while(TMR0 >= 3 && LineInput == 0)
clrwdt();
PORTA = 0x00;
W = 0x01;
TRISA = W; //dispare triac
#asm
nop
nop //retardo señal disparo
nop
nop
nop
nop
nop
#endasm
W = 0x11;
TRISA = W; //Fin señal disparo
clrwdt();
}
Buttoncheck(); //verifica pulsadores
}
}

void Buttoncheck()
{
if(!Dimbut && !Brtbut) //si ambos estan presionados
{
if(LastBoth == 0)
{
 LastBoth = 1;//if(PercentOn == Maxdim)
PercentOn = Maxbrt;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
else
{
LastBoth = 0;
PercentOn = Maxdim;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
}
}
else
LastBoth = 0;
if(!Brtbut && Dimbut) //incrementa brillo
PercentOn++;
if(Brtbut && !Dimbut) //disminuye brillo
PercentOn--;
}
PRUEBAS Y RESULTADOS
Código de Receptor
#include <p18f4550.h>
#include <usart.h>
#include <delays.h>
#pragma config PLLDIV = 5 // (20 MHz crystal on PICDEM FS USB
board)
#pragma config CPUDIV = OSC1_PLL2
#pragma config USBDIV = 2 // Clock source from 96MHz PLL/2
#pragma config FOSC = HSPLL_HS
#pragma config FCMEN = OFF
#pragma config IESO = OFF
#pragma config PWRT = OFF
#pragma config BOR = ON
#pragma config BORV = 3
#pragma config VREGEN = ON //USB Voltage Regulator
#pragma config WDT = OFF
#pragma config WDTPS = 32768
#pragma config MCLRE = OFF //ON
#pragma config LPT1OSC = OFF
#pragma config PBADEN = OFF
#pragma config STVREN = ON
#pragma config LVP = OFF
#pragma config XINST = OFF // Extended Instruction Set
#pragma config CP0 = OFF
#pragma config CP1 = OFF
#pragma config CPB = OFF
#pragma config WRT0 = OFF
#pragma config WRT1 = OFF
#pragma config WRTB = OFF // Boot Block Write Protection
#pragma config WRTC = OFF
#pragma config EBTR0 = OFF
#pragma config EBTR1 = OFF
#pragma config EBTRB = OFF
void main(void)
{
char sh;
char ch;
OpenUSART(USART_TX_INT_OFF &
USART_RX_INT_OFF &
USART_ASYNCH_MODE &
USART_EIGHT_BIT &
USART_CONT_RX &
USART_BRGH_LOW,77);
TRISA=0X00;
TRISB=0X00;
TRISC=0XF8;
TRISD=0X00;
TRISE=0XF8;
PORTA=0XFF;
PORTB=0XFF;
PORTC=0X07;
PORTD=0XFF;
PORTE=0X07;
while(1)
{
if(DataRdyUSART())
{
ch = ReadUSART();
if(ch=='A')
{
LATBbits.LATB7 = 0;
LATBbits.LATB6 = 0;
Delay10KTCYx(100);
 LATBbits.LATB7 = 1;
LATBbits.LATB6 = 1;
}
else if(ch=='B')
{
LATBbits.LATB5 = 0;
LATBbits.LATB4 = 0;
Delay10KTCYx(100);
LATBbits.LATB5 = 1;
LATBbits.LATB4 = 1;
}
else if(ch=='C')
{
LATBbits.LATB3 = 0;
LATBbits.LATB2 = 0;
Delay10KTCYx(100);
LATBbits.LATB3 = 1;
LATBbits.LATB2 = 1;
}
.
.
.
.
else if(ch=='f')
{
LATBbits.LATB2 = 0;
Delay10KTCYx(500);
LATBbits.LATB2 = 1;
}
else if(ch=='g')
{
LATBbits.LATB1 = 0;
Delay10KTCYx(500);
LATBbits.LATB1 = 1;
}
else if(ch=='h')
{
LATBbits.LATB0 = 0;
Delay10KTCYx(500);
LATBbits.LATB0 = 1;
}
else if(ch=='i')
{
LATDbits.LATD7 = 0;
Delay10KTCYx(500);
LATDbits.LATD7 = 1;
}
else if(ch=='j')
{
LATDbits.LATD6 = 0;
Delay10KTCYx(500);
LATDbits.LATD6 = 1;
}
else if(ch=='-')
{
LATBbits.LATB7 = 0;
Delay10KTCYx(50);
LATBbits.LATB7 = 1;
}
else if(ch=='+')
{
LATBbits.LATB6 = 0;
Delay10KTCYx(50);
LATBbits.LATB6 = 1;
}
}
}
}
PRUEBAS Y RESULTADOS
PRUEBAS Y RESULTADOS
 RN-41
www.rovingnetworks.com DS-RN41-V3.1 8/4/2009

Class 1 Bluetooth® Module

Features
• Fully qualified Bluetooth 2.1/2.0/1.2/1.1
module
• Bluetooth v2.0+EDR support
• Postage stamp sized form factor, 13.4mm x Applications
25.8 mm x2mm • Cable replacement
• Low power (30mA connected,, <10mA sniff
• Barcode scanners
mode)
• Measurement and monitoring systems
• UART (SPP or HCI) and USB (HCI only)
data connection interfaces. • Industrial sensors and controls
• Sustained SPP data rates - 240Kbps (slave), • Medical devices
300Kbps (master) • Asset tacking
• HCI data rates - 1.5Mbps sustained, 3.0Mbps
burst in HCI mode
Description
• 8MB on board flash, HCI mode, or SPP/DUN
software stacks available. The RN41 is a small form factor, low power, highly
economic Bluetooth radio for OEM’s adding wireless
• Embedded Bluetooth stack profiles included capability to their products. The RN41 supports
(requires no host stack): GAP, SDP, multiple interface protocols, is simple to design in and
RFCOMM and L2CAP protocols, with SPP fully certified, making it a complete embedded
and DUN profile support. Bluetooth solution. With its high performance on chip
• Bluetooth SIG Qualified, End Product Listing antenna and support for Bluetooth® Enhanced Data
• Castellated SMT pads for easy and reliable Rate (EDR), the RN41 delivers up to 3 Mbps data
PCB mounting rate for distances to 100M. Designers can easily
customize their application using up to 8Mbits of flash
• Class 1 high power amplifier with on board memory. The RN41 is the perfect product for
ceramic RF chip antenna. engineers wanting to add wireless capability to their
o Certifications: FCC, ICS, CE product but don’t want to spend significant time and
o Environmentally friendly, RoHS money developing Bluetooth specific hardware and
compliant software.

Block Diagram
Crystal

VCC
GND

PIO4
RF CSR BlueCore-04 PIO5
PIO6
Switch External
PA BALUN USB
UART
PCM

Flash
Memory

809 University Avenue • Los Gatos, CA 95032 • Tel (408) 395-6539 • [email protected]
 DS-RN41-V3.1 8/4/2009

Overview
• Baud rate speeds: 1200bps up to 921Kbps, non-standard baud rates can be programmed.
• Class 1 radio, 330’ (100m) distance, 12dBm output transmitter, -80dBm typical receive sensitivity
• Frequency 2402 ~ 2480MHz,
• FHSS/GFSK modulation, 79 channels at 1MHz intervals
• Secure communications, 128 bit encryption
• Error correction for guaranteed packet delivery
• UART local and over-the-air RF configuration
• Auto-discovery/pairing requires no software configuration (instant cable replacement).
• Auto-connect master, IO pin (DTR) and character based trigger modes

Environmental Conditions

Parameter Value
o o
Temperature Range (Operating) -40 C ~ 85 C
o o
Temperature Range (Storage) -40 C ~ 85 C
Relative Humidity (Operating) ≤90%
Relative Humidity (Storage) ≤90%

Electrical Characteristics

Parameter Min Typ. Max. Unit

Supply Voltage (DC) 3.0 3.3 3.6 V
RX Supply Current 35 60 mA
TX Supply Current 65 100 mA
Average power consumption
Standby/Idle (default settings) 25 mA
Connected (normal mode) 30 mA
Connected (low power Sniff) 8 mA
Standby/Idle (Deep sleep enabled) 250uA 2.5 mA

Radio Characteristics

Freq. Bluetooth
Parameter Min Typ Max Units
(GHz) Specification
2.402 - -80 -86 dBm
Sensitivity @ 0.1%BER 2.441 - -80 -86 ≤ -70 dBm
2.480 - -80 -86 dBm
2.402 15.0 16.0 dBm
RF Transmit Power 2.441 15.0 16.0 ≤ 15 dBm
2.480 15.0 16.0 dBm
2.402 - 5 75 kHz
Initial Carrier Frequency
2.441 - 5 75 75 kHz
Tolerance
2.480 - 5 75 kHz
20dB bandwidth for modulated
- 900 1000 ≤ 1000 kHz
carrier
Drift (Five slots packet) - 15 - 40 kHz
Drift Rate - 13 - 20 kHz
2.402 140 165 175 kHz
∆f1avg Max Modulation 2.441 140 165 175 >140 kHz
2.480 140 165 175 kHz
2.402 140 190 - kHz
∆f2avg Min Modulation 2.441 140 190 - 115 kHz
2.480 140 190 - kHz

809 University Avenue • Los Gatos, CA 95032 • Tel (408) 395-6539 • [email protected]
 DS-RN41-V3.1 8/4/2009

Pin Description

27 25

1 24
2 23
3 22
4
5
RN41 21
20
6 19
7 18
8 17
9 16
10 15
11 14
12 13

35 34 32 28
29 33 31 30

Top view
Pin Name Description Default
1 GND
2 SPI MOSI Programming only No Connect
3 PIO6 Set BT master (HIGH=auto-master mode) Input to RN41with weak pulldown
Set Baud rate (HIGH = force 9600, LOW = 115K or
4 PIO7 firmware setting) Input to RN41 with weak pulldown
5 RESET Active LOW reset Input to RN41 with 1K pullup
6 SPI_CLK Programming only No Connect
7 PCM_CLK PCM interface No Connect
8 PCM_SYNC PCM interface No Connect
9 PCM_IN PCM interface No Connect
10 PCM_OUT PCM interface No Connect
11 VDD 3.3V regulated power input
12 GND
13 UART_RX UART receive Input Input to RN41
14 UART_TX UART transmit output High level output from RN41
15 UART_RTS UART RTS, goes HIGH to disable host transmitter Low level output from RN41
16 UART_CTS UART CTS, if set HIGH, disables transmitter Low level input to RN41
17 USB_D+ USB port Pull up 1.5K when active
18 USB_D- USB port
19 PIO2 Status, HIGH when connected, LOW otherwise Output from RN41
20 PIO3 Auto discovery = HIGH Input to RN41 with weak pulldown
21 PIO5 Status, toggles based on state, LOW on connect Output from RN41
22 PIO4 Set factory defaults Input to RN41 with weak pulldown
23 SPI_CSB Programming only No Connect
24 SPI_MISO Programming only No Connect
25 GND
26 NC RF pad keep all traces and planes clear.
27-29 GND
30 AIO0 Optional analog input Not Used
31 PIO8 Status (RF data rx/tx) Output from RN41
32 PIO9 IO Input to RN41 with weak pulldown
33 PIO10 IO (remote DTR signal) Input to RN41 with weak pulldown
34 PIO11 IO (remote RTS signal ) Input to RN41 with weak pulldown
35 AIO1 Optional analog input Not Used

809 University Avenue • Los Gatos, CA 95032 • Tel (408) 395-6539 • [email protected]
 DS-RN41-V3.1 8/4/2009

Digital I/O Characteristics

2.7V ≤ VDD ≤ 3.0V Min Typ. Max. Unit

Input logic level LOW -0.4 - +0.8 V
Input logic level HIGH 0.7VDD - VDD+0.4 V
Output logc level LOW - - 0.2 V
Output logic level HIGH VDD-0.2 - - V
All I/O’s (except reset) default to weakpull down +0.2 +1.0 +5.0 uA

Typical Application Circuit

809 University Avenue • Los Gatos, CA 95032 • Tel (408) 395-6539 • [email protected]
 DS-RN41-V3.1 8/4/2009

Module Dimensions

PCB LAYOUT MODULE DIMENSIONS

PAD SIZE = 0.8 X 1.30 mm

13.4 mm
3.2 mm
2.0 mm
5.8 mm

3.3 mm
27 25
1 24
2 23
3
4
RN41 22
21
RN41 25.8 mm

5 20 15.4 mm RN41
6 19
13.2 mm
7 18
8 1.2 mm 17
9 16
10 15 Antenna
11 14
12 13
2.8 mm 35 29 34 33 32 31 28 30

RF Shield

2.5 mm

3.5 mm
2.0 mm
4.8 mm
25.8 mm
6.0 mm

7.2 mm

8.4 mm
9.7 mm

10.7 mm

13.2 mm

809 University Avenue • Los Gatos, CA 95032 • Tel (408) 395-6539 • [email protected]
 DS-RN41-V3.1 8/4/2009

Design Concerns

1. Reset circuit. RN-41 contains a 1k pullup to VCC, the polarity of reset on the RN41 is ACTIVE LOW.
A power on reset circuit with delay is OPTIONAL on the reset pin of the module. It should only be required
if the input power supply has a very slow ramp, or tends to bounce or have instability on power up. Often
a microcontroller or embedded CPU IO is available to generate reset once power is stable. If not, there
are many low cost power supervisor chips available, such as MCP809, MCP102/121, and Torex XC61F.

2. Factory reset PIO4. It is a good idea to connect this pin to a switch, or jumper, or resistor, so it can be
accessed. This pin can be used to reset the module to FACTORY DEFAULTS and is often critical in
situations where the module has been mis-configured. To set Factory defaults start HIGH, then toggle
times.

3. Connection status. PIO5 is available to drive an LED, and blinks at various speeds to indicate status.
PIO2 is an output which directly reflects the connection state, it goes HIGH when connected, and LOW
otherwise.

4. HCI mode. The RN41 module must be loaded with special firmware to run in HCI mode. When in HCI
mode the standard SPP/DUN applications are disabled.

5. Using SPI bus for flash upgrade. While not required, this bus is very useful for configuring advanced
parameters of the Bluetooth modules, and is required for upgrading the firmware on modules. The
suggested ref-design shows a 6pin header which can be implemented to gain access to this bus. A
minimum-mode version could just use the SPI signals (4pins) and pickup ground and VCC from elsewhere
on the design.

6. Minimizing Radio interference. 1.5 mm 1.5 mm

When laying out the carrier board 13.2 mm
for the RN41 module the areas
under the antenna and shielding
7.0 mm
connections should not have
surface traces, GND planes, or 2.0 mm
27 25
exposed vias. (See diagram to right)
For optimal radio performance the ATTENTION:
Do not locate any 1 24
antenna end of RN41 module parts, surface 2 23 1.5 mm
ATTENTION:
should protrude 5mm past any traces, internal 3
Do not locate
22
4 21 25.8 mm
metal enclosure. traces or GND
5 vias or surface 20
plane under the 6 traces under 19
antenna area 7 shield 18
7. Soldering Reflow Profile. 8 connectors 17
9 1.5mm square 16
• Lead-Free Solder Reflow 10 15
• Temp: 230 degree C , 30-40 1.5 mm 11 14
12 13
seconds, Peak 250 degree C
maximum.
35 34 32 28
• Preheat temp: 165 +- 15 29 33 31 30
degree C, 90 to 120 seconds. 1.5 mm
• Time: Single Pass, One Time

809 University Avenue • Los Gatos, CA 95032 • Tel (408) 395-6539 • [email protected]
 DS-RN41-V3.1 8/4/2009

Compliance Information

Category Country Standard

Radio USA FCC CFR47 Part 15 C, para 15.247
FCC ID: T9J-R41-1

EUROPE EN 300 328-1

EN 300 328-2 2.4GHz

CANADA IC RSS-210 low power comm. device

IC Canada ID: 6514A-RN411

EMC USA FCC CFR47 Part 15 subclass B

EUROPE EN 55022 Class B radiated
EN61000-4-2 ESD immunity
EN61000-4-3 radiated field
EN61000-4-6 RF immunity
EN61000-4-8 power magnetic immunity

Bluetooth LISTED B013180

Environmental RoHS RoHS compliant

Ordering Information
Part Number Description
RN-41 Standard Application firmware (SPP/DUN Master and Slave)
RN-41-H HCI firmware (HCI over H4 UART)
RN-41-U USB firmware (HCI over USB port, slave device at 12Mbps rate)
For other configurations, contact Roving Networks directly.

Visit http://www.rovingnetworks.com/buynow.php for current pricing and a list of distributors carrying

our products.
Copyright © 2009 Roving Networks. All rights reserved.

The Bluetooth trademark and logo are registered trademarks and are owned by the Bluetooth SIG, Inc. All
other trademarks are property of their respective owners.

Roving Networks reserves the right to make corrections, modifications, and other changes to its products,
documentation and services at any time. Customers should obtain the latest relevant information before
placing orders and should verify that such information is current and complete.

Roving Networks assumes no liability for applications assistance or customer product design. Customers are
responsible for their products and applications using Roving Networks components. To minimize the risks
associated with customer products and applications, customers should provide adequate design and operating
safeguards.

Roving Networks products are not authorized for use in safety-critical applications (such as life support) where
a failure of the Roving Networks product would reasonably be expected to cause severe personal injury or
death, unless officers of the parties have executed an agreement specifically governing such use.

809 University Avenue • Los Gatos, CA 95032 • Tel (408) 395-6539 • [email protected]