You are on page 1of 176

INSTITUTO POLITECNICONACIONAL

ESCUELA SUPERIOR DE INGENIERIA MECANICA Y ELECTRICA


UNIDAD PROFESIONAL "ADOLFO LOPEZ MATEOS"
TEMA DE TESIS
QUE PARA OBTENER EL TITULO DE INGENIERO EN COMUNICACIONES Y ELECTRNICA

POR LA OPCION DE TITULACION TESIS COLECTIVA Y EXAMEN ORAL INDIVIDUAL


DEBERA(N)DESARROLLAR C. SANDRAALATORRE TERAN
C. JUAN RAYMUNDO CARBAJAL PEA

"DISEO E IMPLEMENTACIN DE UN SISTEMA DE CONTROL VA BLUETOOH PARA LA


ILUMINACIN DE UN HOGAR BASADO EN l;JNA APLICACIN DEL S.O. ANDROID"

DISEAR E IMPL~MENTAR UN SISTEMA BE <:;08.~0L, DE ILUMINACIN PARA REGULAR LA


INTENSIDAD DE LAMPKRA$. DE BAJO CONSUMO DE ENERBIA P0R MEDIO DE DISPOSITIVOS DIMMER,
A PARTIR DE UNA AJ!LIGACI'N PARA EL S.Q. AJ'.IDROID Y EL PROTOCOLO DE COMUNICACIN
BLUETOOTH .

ANDROID

CONCLUSIONES
REFERENCIAS
APNDICE

MXICO D.F. A 29 DE AGOSTO DE 2012.

M. ENC. DA
JEFE DEL DE f\.R
INGENIERA EN C
Resumen

En esta tesis se presenta el desarrollo de un sistema de iluminacion mediante la tecnica


de control por angulo de fase (dimmer) con el objetivo de llevar a cabo la
atenuacion
de las lamparas (AC) a traves de un mando a distancia establecido por el diseno
de una aplicacion en un dispositivo movil con S.O. Android haciendo uso del protocolo
de comunicacion IEEE 802.15 (Bluetooth).

iii
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
Indice
General

Resumen III

Abstract V

Indice de General
VII

Indice de Figuras

XI Ob jetivo

XV Justificacion

XVII Introduccion

XIX

1. Iluminacion Eficiente 1
1.1. Introduccion a la Iluminacion Eficiente . . . . . . . . . . . . . . . . . . . . 1
1.1.1. Ahorro de energa en el hogar . . . . . . . . . . . . . . . . . . . . . 1
1.1.2. Iluminacion en el hogar . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. Sistemas Innovadores de Iluminacion . . . . . . . . . . . . . . . . . . . . . 2
1.2.1. Sistemas de Control de Iluminacion . . . . . . . . . . . . . . . . . . 3
1.3. Estructura del Sistema de Control de Iluminacion: La Potencia . . . . . . . 4
1.4. Introduccion a los Dimmers . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4.1. Dimmers disenados con tiristores . . . . . . . . . . . . . . . . . . 6
1.4.2. .Dimmer controlado remotamente por tiristor . . . . . . . . . . . . . 7
1.4.3. Circuitos dimmer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.5. Control de la Iluminacion . . . . . . . . . . . . . . . . . . . . . . . . . . 10
.
1.6. Planteamiento del Problema . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.7. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

vii
888 INDICE
GENERAL
1.8. Metodologa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.9. Organizacion de la Tesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2. Bluetooth 15
2.1. Descripcion general de la Tecnologa Bluetooth . . . . . . . . . . . . . . . . 15
2.1.1. Protocolos Especficos . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2. RFCOMM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.3. Perfiles Bluetooth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3.1. Perfil Generico de Acceso (GAP) . . . . . . . . . . . . . . . . . . . 21
2.3.2. Perfil de Puerto Serial . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3. Perfil de Aplicacion de Descubrimiento de Servicio (SDAP) . . . . . 22
2.3.4. Perfil Generico de Intercambio de Objetos (GOEP) . . . . . . . . . 22
2.4. Dispositivo Bluetooth Roving Networks . . . . . . . . . . . . . . . . . . . . 22
2.4.1. Estableciendo una conexion Bluetooth . . . . . . . . . . . . . . . . 23
2.4.2. Modos de Operacion . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.4.3. Configuracion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3. Android 29
3.1. Historia de Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2. Que es Android? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.1. Caractersticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.2.2. Arquitectura de Android . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3. Aplicaciones Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.3.1. Fundamentos de una aplicacion . . . . . . . . . . . . . . . . . . . . 38
3.3.2. Componentes de una aplicacion . . . . . . . . . . . . . . . . . . . . 39
3.4. Desarrollando aplicaciones Android . . . . . . . . . . . . . . . . . . . . . . 43
3.4.1. Entornos de Desarrollo Android . . . . . . . . . . . . . . . . . . . . 44
3.5. Estructura Basica de APP Inventor . . . . . . . . . . . . . . . . . . . . . . 48
3.5.1. Ventana de Diseno . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.5.2. Editor de Bloques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.6. Instalacion y distribucion de Aplicaciones (Android Market) . . . . . . . . 69
3.6.1. Bajar Aplicaciones desde Android Market . . . . . . . . . . . . . . 69
3.6.2. Subir Aplicaciones desde Android Market . . . . . . . . . . . . . . . 70
INDICE GENERAL ix

4. Aplicacion ATOM y Prototipo 73


4.1. Construccion y Programacion de un Dimmer . . . . . . . . . . . . . . . . . 73
4.1.1. Propuesta y explicacion de Hardware . . . . . . . . . . . . . . . . . 74
4.1.2. Programa del microcontrolador y explicaci . . . . . . . . . . . . . 76
4.2. on
Construccion y Programacion de Receptor Bluetooth . . . . . . . . . . . . 76
4.2.1. Propuesta y explicacion de Hardware . . . . . . . . . . . . . . . . . 77
4.2.2. Programa del microcontrolador y explicaci . . . . . . . . . . . . . 78
4.3. on
Estableciendo Comunicacion Bluetooth . . . . . . . . . . . . . . . . . . . . 79
4.3.1. Arreglo de Hardware para la prueba . . . . . . . . . . . . . . . . . . 80
4.3.2. Pruebas de conexion con HyperTerminal . . . . . . . . . . . . . . . 82
4.4. Diseno y Desarrollo de la aplicacion ATOM . . . . . . . . . . . . . . . . 84
.4.4.1. Propuesta y descripcion de la aplicacion . . . . . . . . . . . . . . 85
.4.4.2. Desarrollo y esquema de la aplicacion . . . . . . . . . . . . . . . . . 86
4.4.3. Prueba y depuracion con HyperTerminal en la PC . . . . . . . . . . 87
4.5. Integracion de todas las etapas del sistema . . . . . . . . . . . . . . . . . . 87
4.5.1. Diseno del hardware conjunto . . . . . . . . . . . . . . . . . . . . 88
.
Pruebas y Resultados 91

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

Referencias 97

Apendice 98

99
Indice de Figuras

1.1. Esquema de un dimmer analogico. . . . . . . . . . . . . . . . . . . . . . . . 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 iluminacion. . . . . . . . . . . . . 11

2.1. Companas que forman parte del . . . . . . . . . . . . . . . . . . . . 15


SIG. .
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. Modulo 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. U 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. Notificacion de Broadcast. . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

xi
12 INDICE 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 Diseno. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
.3.22. Paleta de Componentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.23. Componentes Basicos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Organizacion. . . . . . . . . . . . . . . . . . . . . . . . . 57
3.29. Componentes de LEGO MINDSTORMS. . . . . . . . . . . . . . . . . . . . 58
3.30. Otros Componentes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.31. Not Ready for Prime Time. . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.32. Descripcion 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. A rea de jo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Traba
3.43. Barra de Herramientas. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.44. Emulador Android. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.45. Android Market. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.46. Aplicacion Android Market. . . . . . . . . . . . . . . . . . . . . . . . . . . 70
INDICE 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. Modulo Bluetooth BlueSMiRF 01. . . . . . . . . . . . . . . . . . . . . . . . 81
4.9. Modulo Bluetooth BlueSMiRF 02. . . . . . . . . . . . . . . . . . . . . . . . 81
4.10. Conexion de de Modulos 01 y 02. . . . . . . . . . . . . . . . . . . . . . . 81
.
4.11. Ventanas de Configuracion HyperTerminal. . . . . . . . . . . . . . . . . . . 83
4.12. Modulo BT en modo comando HyperTerminal. . . . . . . . . . . . . . . . 84
.4.13. Ventanas Principal de la Aplicacion. . . . . . . . . . . . . . . . . . . . . . . 85
4.14. Area de Trabajo en el Desarrollo de la Aplicacion. . . . . . . . . . . . . . . 86
4.15. Editor de Bloques de la Aplicacion. . . . . . . . . . . . . . . . . . . . . . . 87
4.16. Pruebas y Depuracion de Comunicacion. . . . . . . . . . . . . . . . . . . . 88
4.17. Propuesta de Hardware Conjunto . . . . . . . . . . . . . . . . . . . . . . . 88
4.18. Diagrama Electrico del Sistema . . . . . . . . . . . . . . . . . . 89
Completo
4.19. Placa PCB del Sistema Completo . . . . . . . . . . . . . . . . . . . . . . . 90

4.20. Tabla de Conexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92


.4.21. Tabla de Envio de Datos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
4.22. Tabla de Comparacion de Lamparas. . . . . . . . . . . . . . . . . . . . . 93
.4.23. Tabla de Comparacion de Lamparas. . . . . . . . . . . . . . . . . . . . . 93
.
Ob jetivo

Disenar e implementar un sistema de control de iluminacion para regular la


intensidad de lamparas de bajo consumo de energa por medio de dispositivos dimmer,
a partir de una aplicacion para el S.O Android y el protocolo de comunicacion
Bluetooth.

Derivados del objetivo general se plantean los siguientes objetivos especficos:

Desarrollar un receptor con comunicacion 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 tecnica de control por angulo
de
fase.

Disenar una aplicacion basada en el Entorno de Desarrollo App Inventor para


el
S.O Android.

Establecer una comunicacion inalambrica mediante el protocolo IEEE 802.15 (Blue-


tooth).

Contribuir con una opcion mas para el ahorro de la energa electrica.


xv
xvi OBJETIVO
Justificacion

No es posible concebir el mundo actual sin el uso de la iluminacion artificial. Recordan-


do que la energa electrica, particularmente en Mexico, proviene de la quema del
petroleo en mas del 70 %; dada la importancia que la iluminacion representa en el
consumo de la electricidad y el avance tecnologico en la materia, la justificacion de
este trabajo recae sobre el ahorro de la energa electrica a traves del desarrollo e
innovacion de la ciencia y la tecnologa.

xvii
xviii JUSTIFICACIO N
Introduccion

Conforme la tecnologa avanza a pasos agigantados, y los sistemas embebidos se


en- cuentran en cualquier rincon al que volteemos siendo parte de nuestra vida
cotidiana, vemos como la tecnologa inquieta ante muchas posibilidades, es cada
vez mas 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 telefonos
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 practicamente todo lo que el usuario exige; a tal
grado de llamarse Smartphone o telefonos inteligentes.

En estos dispositivos podemos encontrar sistemas operativos bastante complejos que


se encargan de ejecutar y administrar tareas y hardware, tales como camaras de HD, gra-
bador de voz, antenas de red Wifi, Bluetooth, radio, reproductores mp3, redes sociales,
contactos, GPS, procesar imagenes y videos de alta definicion, 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-


nologa a la integracion de muchas tareas en un solo dispositivo pensamos Por que
no sumergir a estos Smartphone a un entorno de control para Smart-home? La siguiente
pre- gunta en cuestion fue A que rubro seria dedicado; al ahorro de energa, 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 energa que hoy en da es un tema
del cual nos debemos de ocupar seriamente.

xix
xx INTRODUCCIO N

As despues de muchas ideas se pudo consolidad y delimitar claramente las


carac- tersticas del proyecto. Se enfoca al control de un sistema de iluminacion
mediante una aplicacion en el Sistema Operativo Android para moviles. Y en Donde est
a el ahorro de energa y la comodidad? El primer aspecto se cubre al utilizar
DIMMERS y Lamparas Fluorescentes Compactas Dimmeables (o Lamparas LED
Dimmeables con entrada E27) que consumen un mnimo de energa; 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 habitacion.
Captulo 1

Iluminacion Eficiente

1.1. Introduccion a la Iluminacion Eficiente

Eficiencia energetica es la relacion entre la cantidad de energa consumida y los


produc- tos y servicios finales obtenidos. Se puede mejorar mediante la implantacion de
diversas medidas tecnologicas, de gestion y de habitos de consumo.

Los individuos y las organizaciones que son consumidores directos de la energa


de- beran desear ahorrar energa para reducir costos energeticos y promover la
sostenibilidad economica y ambiental. Los usuarios industriales y comerciales suelen
desear aumentar eficacia y maximizar as su beneficio.

1.1.1. Ahorro de energa en el hogar

Los usos y costumbres diarios habituales que se hacen en la vivienda puede conllevar
a un ahorro considerable de energa si se cambian las actitudes y se es consciente
del consumo real y del necesitado. En la mayora de los casos basta con la eleccion de un
elec- trodomestico de bajo consumo, o de una racionalizacion del consumo de la
calefaccion, del aire acondicionado y del agua caliente.

Los electrodomesticos tienen mucha importancia en el ahorro de energa dom


estico.

1
2 CAPITULO 1. ILUMINACIO N
EFICIENTE
1.1.2. Iluminacion en el hogar

Es importante seguir una serie de consejos basicos, 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 iluminacion natural; usar
la luz solo cuando se necesite y no dejar luces encendidas en habitaciones que no se est
en utilizando.

Ademas hay que tener en cuenta que las lamparas halogenas consumen mucha mas
energa que otros tipos de bombillas y disipan mas calor, los tubos fluorescentes
duran hasta 10 veces mas que las bombillas tradicionales y son muy eficientes energ
eticamente, por lo que si se va a tener una lampara 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 tecnologas de luminarias como los diodos emisores de luz


(LED), as como diversas tecnologas de control de la iluminacion: regulacion de
potencia, sensores de proximidad, combinacion luz natural - luz artificial, doble
iluminacion e iluminacion selectiva que producen ahorros considerables.

1.2. Sistemas Innovadores de Iluminacion


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 introduccion de nuevas funciones, haciendolas mas flexibles, confortables
y atractivas. Innovador hace referencia a aquello distinto de lo convencional y que aun
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 clasificacion general permite diferenciar inicialmente entre
los sistemas innovadores del alumbrado artificial y los sistemas innovadores del alumbrado
natural. Aunque muchos de ellos aun 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 ILUMINACIO N
3

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


no podran estar ausentes en ningun tipo de instalacion de luz. Estas circunstancias, y
la insuficiente informacion disponible, justifican la importancia de una mayor y mas
objetiva divulgacion de ellos.

1.2.1. Sistemas de Control de Iluminacion


En un sistema de control proporcional, la senal de control determina cual es la
propor- cion de atenuacion del flujo luminoso de las lamparas, disminuyendoles su
potencia. La relacion directa entre flujo luminoso y potencia, denominada eficiencia
luminosa, puede modificarse con la regulacion del flujo luminoso de la lampara. Si se
realiza la regulacion a un tubo fluorescente con un dispositivo que no provoque
distorsiones en la forma de corriente de alimentacion de la lampara, la eficacia
puede aumentar hasta en un 12 %. Equipos de mala calidad no solo empeoran la
eficacia luminosa con la atenuacion, sino que pueden afectar la duracion de la lampara.
No todas las lamparas son aptas para la regulacion de su flujo luminoso sin que
experimenten algun tipo de inconvenientes. Re- cientes desarrollos electronicos permiten
hacer funcionar tubos fluorescentes en regmenes de baja potencia, por lo tanto, no hay
limitaciones en el grado de atenuacion que puede realizarse, desde el 100 % a valores tan
bajos como 1 %, sin parpadeos.

Algunos fabricantes han desarrollado lneas especiales de lamparas con capacidad


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

Limitaciones

Como toda tecnologa de innovacion, 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 tecnologico, sobre los que el
disenador o proyectista debe tomar las precauciones necesarias son:

Carencia de metodos apropiados para el diseno de instalaciones.

Dificultad en la prediccion del ahorro que es posible lograr.

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


luces.
4 1.4. INTRODUCCIO N A LOS CAPITULO 1. ILUMINACIO N 4
DIMMERS EFICIENTE
Dificultad de especificaciones y calidad de los equipos.

Reaccion adversa de los ocupantes a este tipo de instalacion.

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 electronicos.
Polucion electromagnetica, prematuro envejecimiento de lamparas y fallas
catastroficas son algunos de los problemas que se pueden presentar debido a la mala
calidad de dim- mers o sensores ocupacionales. Podra argumentarse que este es un
problema que puede solucionarse con apropiados estandares de calidad, lo cual es
cierto. Sin embargo, no es facil la normalizacion de dispositivos de relativamente nuevo
diseno.

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


La mayora de los componentes de los sistemas de control se hallan aun sin
normalizacion.

Las reacciones adversas, de los ocupantes de locales equipados con sistemas de control,
parecen ser el punto mas limitante de esta tecnologa. Afortunadamente la mayora 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 comento anteriormente.

1.3. Estructura del Sistema de Control de Ilumina-


cion: La Potencia
La funcion del Dimmer es regular la tension. Es decir, la capacidad de hacer llegar
a una lampara una cantidad menor de energa 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 lampara le llegaran aproximadamente 55V
y la misma
emitir la mitad de luz de su capacidad. As, la potencia trabajar comodamen-
permitir
te con la energa, regularla, dividirla o agruparla en canales. Generalmente la Potencia
est desarrollada a traves de los Racks o Paquetes de Dimmers.
5 1.4. INTRODUCCIO N A LOS CAPITULO 1. ILUMINACIO N 5
Los Dimmers se clasifican segun la cantidad
DIMMERS de canales y por la capacidad de
EFICIENTE
fuerza total por cada canal. Se los puede encontrar en 1000W, 2000W, 2500W, 4000W,
6000W,
etc. Cada grupo de luces estar conectado al mismo canal, y encenderan juntas. Si se
quisiera que las seis lamparas encendieran en diferentes intensidades al mismo
tiempo debere 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 multiplos 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 Analogicos, pero
los dimmers son siempre analogos.

1.4. Introduccion a los Dimmers


Los dimmers son dispositivos electronicos especializados capaces de regular la intensi-
dad de fuentes electricas de luz aplicando la tecnica de conmutacion. Los dimmers
fueron inventados en 1890, por Glanville Woods para evitar los incendios en los teatros ya
que los metodos utilizados para controlar la intensidad de las lamparas eran peligrosos y
frecuen-
temente causaban incendios [Smith, 2005], Woods busc un metodo economico y
efectivo
para regular la intensidad de las luces y as la primera version del dimmer moderno,
cre el cual fue la resistencia variable.

Con la invencion del tiristor, los dimmers se transformaron en pequenos,


economicos y eficientes. Los tiristores se usaron en el control de la iluminacion en la
primera parte de de la decada de los 60s y durante mas de 40 anos han formado la base
de control de iluminacion profesional, ya que son mas robustos y tienen la capacidad de
soportar altas corrientes repentinas causadas por los fallos en el filamento de las lamparas
de tungsteno. Los dimmers profesionales usualmente estan construidos sobre un
principio modular. Ca- da modulo representa uno o dos canales de Dimmer. Los m
odulos son independientes, y estan disenados para ser reemplazados facilmente, ya sea
por conexion de enchufe o por terminales de facil conexion. 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 tecnicas para limitar el
flujo
de corriente en las lamparas, los cuales son:

Variacion de voltaje.

Variacion en el intervalo de tiempo, en el cual la corriente fluye durante cada


ciclo corriente alterna.

En la siguiente seccion se presenta la segunda tecnica por ser la mas difundida y


es la que se aplica en el presente trabajo.

1.4.1. Dimmers disenados con tiristores


Todos los circuitos dimmer sobre la base de tiristores requieren que el dispositivo se
dispare en algun punto predeterminado despues que la senal sinusoidal cruza por
cero. La tecnica es conocida como control por angulo de fase, la cual consiste en
controlar el tiempo de disparo o de conduccion del tiristor, para regular la corriente que
se entrega a la carga (o lampara) 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 traves de la carga. El triac es disparado cuando una senal de
baja energa se aplica en su terminal G (Gate). El semiciclo positivo de la senal de
CA pa-
sar por el triac siempre que G sea activo, de esta manera, la corriente circulara 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 senal de disparo
en la entrada G, de esta manera la corriente circulara de abajo hacia arriba (terminal
MT1).

El dispositivo que proporciona la senal G en ambas direcciones de la corriente


es conocido como diac. El diac es un diodo bidireccional que unicamente 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 transicion
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 angulo de disparo y se representa por beta . Los rangos de beta varan de
0 (maxima potencia) hasta 180 (mnima o nula potencia). Controlando el angulo
de disparo, el voltaje rms
7 1.4. INTRODUCCIO N A LOS CAPITULO 1. ILUMINACIO N 7
DIMMERS EFICIENTE
suministrado a la carga cambia y por lo tanto, la intensidad de las luces tambien
cambia
(Fig.1.1).

Figura 1.1: Esquema de un dimmer analogico.

Cuando la corriente alterna cambia su direccion, 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
ampara 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.
El diagrama es el mismo sin tener en cuenta si el circuito final es digital, analogico
o hbrido. 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 lnea cruza por cero. Para controles de fase esto es la informacion de
temporizacion 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 senal de entrada, y dispara los tiristores despues del retardo de fase
apropiado.

3. Un circuito de control. Este puede ser unicamente un circuito de voltaje de


referen- cia, que permita al dimmer analogico ser controlado por una senal
analogica de 0-10
V. Mientras que en un dimmer analogico automatico, el circuito incluye circuitos de
tiempo tipo rampa para producir desvanecimiento automaticos 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-
tacion de la corriente y la anti-simetra de los disparos del Triac genera ruido, armonicos
e interferencia electromagnetica. El ruido del circuito dimmer ser transmitido en
podr
circuitos de potencia y causar problemas. Los armonicos pueden estar en la gama de
los MHz dependiendo de los niveles de potencia del sistema y del numero de fases en
el mismo, y puede causar calentamiento en los transformadores y conductores. Ademas
si se usan microprocesadores para el control del circuito dimmer, las interferencias
pueden afectar severamente el desempeno del sistema digital. Ademas el flujo del campo
magneti- co tambien causa vibraciones en la estructura del foco el cual se podra
danar. El circuito dimmer debe contener filtros de alta frecuencia para remover algunos
de los armonicos y ruido en el circuito [Simpson, 2003].
Figura 1.2: Diagrama a bloques de dimmer controlado remotamente por tiristores.

1.4.3. Circuitos dimmer.


Un microcontrolador (MCU) proporciona un metodo sencillo y economico de imple-
mentar la funcionalidad de un dimmer [Gadre, 2001]. Este puede procesar casi simult
anea- mente las entradas de cualquiera de las senales 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 angulo de la fase.


Para
ello su firmware debe ejecutar dos tareas: calcular el retraso entre el cruce por cero y el
encendido del triac, conectandolo 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 tendran


un rendimiento equivalente.

Permite la supervision constante en la intensidad de la corriente y de otras


senales de control de las luces
Simplifica el uso de un control tipo multplex.

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 diseno basado en un microprocesador o microcontrolador. El dimmer en este


est
diseno todava 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 Iluminacion


La parte central de toda instalacion de iluminacion es el sistema de control o
consola de iluminacion. Por medio de este, se logra la regulacion 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 envan las
senales de control para cada uno de los dimmers, que a su vez regulan la intensidad
de
11 CAPITULO 1. ILUMINACIO N
1.6. PLANTEAMIENTO DEL PROBLEMA 11
EFICIENTE

Figura 1.4: Interfaz entre el operador y el sistema de iluminacion.

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 tecnologa crece desmesuradamente y al mismo
tiem- po los recursos energeticos y naturales disminuyen, por lo que el enfoque de estos
avances tecnologicos ha volteado la mirada y enfocado su atencion a las alternativas de los
recursos energeticos y a proponer medidas para ahorrar dichos recursos.

La energa electrica es uno de los recursos en escases donde se busca nuevas


formas de generarla y por consiguiente formas de como ahorrarla, en este contexto, es
posible detectar que las alternativas y propuestas de ahorro en diferentes ambitos son
muy bastas y extensas. En cuanto a lo que a la iluminacion concierne, existen muchas
estrategias e instrumentos de control para ahorrar y optimizar tanto la iluminacion
como la energa.

Estas estrategias se advierten claramente en algunos hogares y establecimientos en


donde sin duda alguna muestran resultados significativos. Cabe preguntarnos entonces si
es factible disenar un control de iluminacion con mando a distancia, en donde el control
remoto pueda ser un dispositivo de uso general con mucho mas funcionalidad que un sim-
ple mando convencional, como una alternativa innovadora de ahorro y comodidad; para
este caso, el mando a control propuesto es un telefono inteligente.

En la formacion de este proyecto aborda diferentes interrogantes tales como la


forma de establecer la comunicacion, el diseno de la aplicacion que fungira como
control remoto y la programacion de los circuitos integrados para el desarrollo del
hardware. Para eso utilizaremos tecnicas mixtas de recoleccion de la informacion como
el analisis de contenido, exploracion bibliografica, consultas electronicas y foros.

1.7. Hipotesis
Se cree que el desarrollo de un sistema de control de iluminacion brinda una alternativa
que contribuye en el ahorro de la energa electrica en gran medida, del mismo modo
se pretende que este ofrezca una mayor comodidad para los usuarios; ademas de verlo
como una forma de fomentar el auge de nueva tecnologa para dispositivos moviles que
cuenten con el Sistema Operativo Android, que si bien es relativamente nuevo ha
alcanzado un gran crecimiento en los ultimos anos.

1.8. Metodologa
La metodologa que se implemento para el desarrollo de la investigacion abarca
los siguientes puntos:

Obtencion de la justificacion y objetivos del proyecto.

Recoleccion de datos e informacion tecnica.

Delimitacion de datos tecnicos.

Elaboracion del proyecto teorico.

Elaboracion del proyecto fsico.

Diseno y programacion de los dimmers.


Pruebas del funcionamiento de los dimmers.

Diseno y programacion del hardware receptor.


1.9. ORGANIZACIO N DE LA TESIS
13

Pruebas de comunicacion Bluetooth.

Diseno y programacion de la Aplicacion.

Realizacion de los diagramas PCB y las placas correspondientes.

Integracion de todos los subsistemas

Pruebas finales.

Exposicion de resultados y conclusiones.

Presentacion del Proyecto.

1.9. Organizacion de la Tesis


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

En el captulo 1, se presenta una postura teorica sobre la iluminacion eficiente,as


co- mo conceptos que abordan tematicas relacionadas al ahorro de energa, bajo
consumo de energa y sistemas inovadores de iluminacion; dentro de los cuales se
encuentran los sitemas de control de iluminacion. Abarca teoria sobre los tipos y
partes que integran dichos sitemas de iluminacion, profundizando en la tecnica de
control por angulo de fase o cruce por cero para la construccion de los dimmers que
son dispositivos electronicos especializados capaces de regular la intensidad de fuentes el
ectricas de luz.

En el captulo 2, se presenta una breve introduccion a la tecnologa 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 modulo de Bluetooth Roving
Networks, la forma en como establecer una conexion con otro dispositivo Blurtooth, y
los distintos modos con los que se puede trabajar dentro de este.

En el captulo 3, se abordan los aspectos historicos del Sistema Operativo Android,


de la misma forma las caractersticas y arquitectura que lo conforman. Describe los
funda- mentos y componentes basicos de una aplicacion para dicho Sistema Operativo, as
como los diferentes Entornos de Desarrollo Integral en los que se programan las
aplicaciones,se
14 CAPITULO 1. ILUMINACIO N
EFICIENTE
enfoca profundamente en App Inventor describiendo la estructura y caractersticas
que posee. Por ultimo desarrolla los pasos y requerimientos a seguir para la distribuci
on de aplicaciones en el Android Market.

En el captulo 4, se establece la descripcion de los aspectos fsicos del proyecto;


como la programacion y construccion de los dimmers; el diseno, la programacion y
construccion del hardware receptor, la forma de como establecer la comunicacion con
un modulo de Bluetooth y la HyperTerminal; los test de prueba y error de comunicaci
on. Presenta la propuesta de diseno y desarrollo de la aplicacion as como la
integracion de todos los subsistemas formados anteriormente.

En el captulo 5, Pruebas y Resultados, muestra como los diferentes subsistemas ...


Captulo 2

Bluetooth

2.1. Descripcion general de la Tecnologa


Bluetooth
La tecnologa inalambrica 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 pequenas 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 telefonos m
oviles y sus accesorios. El estudio era parte de un proyecto mas amplio que investigaba
como diferentes dispositivos de comunicaciones se podran conectar a la red celular a
traves del telefono movil. 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 area atrajo la atencion de companas como IBM, Intel, Nokia y
Toshiba (Fig.2.1).

Figura 2.1: Companas 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 tecnologa. Actualmente, mas de mil companas
lo integran y trabajan conjuntamente por un estandar 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 CAPITULO 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
maxima de smbolos de 1 M Smbolo/s. Despues de que cada paquete es enviado en
una determinada frecuencia de transmision, esta cambia a otra de las 79 frecuencias
[3]. El rango tpico de operacion de Bluetooth es menor a 10 m, sin embargo se pueden
alcanzar distancias de hasta 100 m.

Como se puede observar, la comunicacion sobre Bluetooth se divide en varias capas.


A continuacion se presenta una breve descripcion de algunas de ellas (Fig.2.3).
Una de las capas de comunicacion mas bajas es llamada Banda Base. Esta capa imple-
menta el canal fsico real. Emplea una secuencia aleatoria de saltos a traves de 79
frecuen- cias de radio diferentes. Los paquetes son enviados sobre el canal fsico, donde
cada uno es enviado en una frecuencia de salto diferente. La Banda Base controla la
sincronizacion de las unidades Bluetooth y la secuencia de saltos en frecuencia, ademas
es la responsable de la informacion para el control de enlace a bajo nivel como el
reconocimiento, control de flujo y caracterizacion de carga util y soporta dos tipos de
enlace: sncrono orientado a la conexion (SCO), para datos y asncrono no orientado a
la conexion (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
trafico de voz en tiempo real.

El Link Manager Protocol (LMP) o Protocolo de Gestion de Enlace es el


responsable de la autenticacion, encriptacion, control y configuracion del enlace. El LMP
tambien se encarga del manejo de los modos y consumo de potencia, ademas soporta
los procedi-
2.1. DESCRIPCIO N GENERAL DE LA TECNOLOGIA 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


metodo de interfaz uniforme para acceder a los recursos de hardware de Bluetooth. E
ste contiene una interfaz de comando para el controlador banda base y la gestion de
enlace y
para acceder al hardware.

El Logical Link Control and Adaptation Protocol (L2CAP) o Protocolo de Control


y Adaptacion de Enlace Logico, corresponde a la capa de enlace de datos. E sta
brinda servicios de datos orientados y no orientados a la conexion 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 mas grandes que el maximo tamano 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 mas grandes para la capa superior. La conexion
L2CAP permite el intercambio de informacion referente a la calidad de la conexion,
ademas 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 CAPITULO 2.
BLUETOOTH
como actua una aplicacion de un cliente Bluetooth para descubrir servicios
disponibles de servidores Bluetooth, ademas de proporcionar un metodo para
determinar las carac- tersticas de dichos servicios.

El protocolo RFCOMM ofrece emulacion de puertos seriales sobre el protocolo


L2CAP. RFCOMM emula senales de control y datos RS-232 sobre la banda base
Bluetooth. E ste ofrece capacidades de transporte a servicios de capas superiores (por
ejemplo OBEX) que usan una lnea serial como mecanismo de transporte. RFCOMM
soporta dos tipos de comunicacion, directa entre dispositivos actuando como endpoints
y dispositivo-modem- dispositivo, ademas tiene un esquema para emulacion de null
modem.

El control de telefona binario (TCS binario) es un protocolo que define la


senaliza- cion de control de llamadas, para el establecimiento y liberacion de una
conversacion o una llamada de datos entre unidades Bluetooth. Ademas, este ofrece
funcionalidad para intercambiar informacion de senalizacion no relacionada con el
progreso de llamadas.

La capa de Audio es una capa especial, usada solo para enviar audio sobre Bluetooth.
Las transmisiones de audio pueden ser ejecutadas entre una o mas unidades usando
mu- chos modelos diferentes. Los datos de audio no pasan a traves de la capa
L2CAP, pero s directamente despues de abrir un enlace y un establecimiento directo
entre dos unidades Bluetooth.

2.1.1. Protocolos Espec


ficos
Control de telefona - Comandos AT. Bluetooth soporta un numero de comandos
AT para el control de telefona a traves de emulacion 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 estandares UDP/TCP e IP permiten a las


unidades Bluetooth conectarse, por ejemplo a Internet, a traves de otras unidades
19 CAPITULO 2.
conectadas. Por lo tanto, la unidad puede actuar como un puente para Internet. La
BLUETOOTH
configuracion TCP/IP/PPP esta disponible como un transporte para WAP.
2.2. RFCOMM 19

Wireless Aplication Protocol (WAP) o Protocolo de Aplicacion Inalambrica. WAP


es una especificacion de protocolo inalambrica que trabaja con una amplia varie-
dad de tecnologas de red inalambricas conectando dispositivos moviles a Internet.
Bluetooth puede ser usado como portador para ofrecer el transporte de datos entre
el cliente WAP y su servidor de WAP adyacente. Ademas, las capacidades de
red
de Bluetooth dan a un cliente WAP posibilidades unicas en cuanto a
movilidad
comparada con otros portadores WAP. Un ejemplo de WAP sobre Bluetooth ser
a un almacen que transmite ofertas especiales a un cliente WAP cuando este
entra en el rango de cobertura.

Protocolo OBEX. OBEX es un protocolo opcional de nivel de aplicacion


disenado para permitir a las unidades Bluetooth soportar comunicacion infrarroja
para inter-
cambiar una gran variedad de datos y comandos. E 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 comparacion del stack Bluetooth con el modelo de
referencia estandar Open Systems Interconect, OSI, para stacks de protocolo de comuni-
caciones. A pesar de que Bluetooth no concuerda exactamente con el modelo, esta compa-
racion es muy util 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 comparacion sirve para resaltar la division de funciones en el stack
Bluetooth.

2.2. RFCOMM
El protocolo RFCOMM brinda emulacion de puertos seriales sobre el protocolo L2CAP.
La capa RFCOMM es una simple capa de transporte provista adicionalmente de emula-
cion de circuitos de puerto serial RS-232. El protocolo RFCOMM soporta hasta 60 puertos
emulados simultaneamente. Dos unidades Bluetooth que usen RFCOMM en su comuni-
cacion pueden abrir varios puertos seriales emulados, los cuales son multiplexados entre
s. La (Fig.2.5) muestra el esquema de emulacion para varios puertos seriales (Fig.2.6).
Muchas aplicaciones hacen uso de puertos seriales. El RFCOMM esta orientado a
hacer mas flexibles estos dispositivos, soportando facil adaptacion de comunicacion
Bluetooth. Un ejemplo de una aplicacion de comunicacion serial es el protocolo punto-a-
punto (PPP).
20 2.3. PERFILES BLUETOOTH CAPITULO 2. 20
BLUETOOTH

Figura 2.4: Modelo de referencia OSI y Bluetooth.

El RFCOMM tiene construido un esquema para emulacion de null modem y usa a L2CAP
para cumplir con el control de flujo requerido por alguna aplicacion.

2.3. Perfiles Bluetooth


El estandar Bluetooth fue creado para ser usado por un gran numero de
fabricantes e implementado en areas ilimitadas. Para asegurar que todos los
dispositivos que usen Bluetooth sean compatibles entre s son necesarios esquemas est
andar de comunicacion
en las principales areas. Para evitar diferentes interpretaciones del estandar Bluetooth
acerca de como un tipo especfico de aplicacion debera ser implementado, el Bluetooth
Special Interest Group (SIG), ha definido modelos de usuario y perfiles de protocolo. Un
perfil define una seleccion de mensajes y procedimientos de las especificaciones Bluetooth
y ofrece una descripcion clara de la interfaz de aire para servicios especficos. Un
perfil puede ser descrito como una rebanada completa del stack de protocolo.

Existen cuatro perfiles generales definidos, en los cuales estan basados directamente
algunos de los modelos de usuario mas importantes y sus perfiles. Estos cuatro modelos
son Perfil Generico de Acceso (GAP), Perfil de Puerto Serial, Perfil de Aplicacion
de Descubrimiento de Servicio (SDAP) y Perfil Generico de Intercambio de Objetos
(GOEP). A continuacion se hace una breve descripcion de estos y algunos otros perfiles
Bluetooth.
Figura 2.5: RFCOMM

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


jerarqua de los perfiles, como por ejemplo que todos los perfiles estan contenidos en el
Perfil Generico de Acceso (GAP).

2.3.1. Perfil Generico de Acceso


(GAP)

Este perfil define los procedimientos generales para el descubrimiento y establecimiento


de conexion entre dispositivos Bluetooth. El GAP maneja el descubrimiento y estableci-
miento entre unidades que no estan conectadas y asegura que cualquier par de unidades
Bluetooth, sin importar su fabricante o aplicacion, puedan intercambiar informacion a
traves de Bluetooth para descubrir que 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 conexion 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 mas altas es opcional. RFCOMM es usado para transportar los datos de usuario,
senales de control de modem y comandos de configuracion. El perfil de puerto serial es
dependiente del GAP.
Figura 2.6: Varios puertos seriales emulados mediante RFCOMM

2.3.3. Perfil de Aplicacion de Descubrimiento de Servicio (SDAP)


Este perfil define los protocolos y procedimientos para una aplicacion en un dispositivo
Bluetooth donde se desea descubrir y recuperar informacion relacionada con servicios
localizados en otros dispositivos. El SDAP es dependiente del GAP.

2.3.4. Perfil Generico de Intercambio de Ob jetos (GOEP)


Este perfil define protocolos y procedimientos usados por aplicaciones para ofrecer
caractersticas de intercambio de objetos. Los usos pueden ser, por ejemplo,
sincronizacion, transferencia de archivos o modelo Object Push. Los dispositivos mas
comunes que usan este modelo son agendas electronicas, PDAs, telefonos celulares y
telefonos moviles. 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 tecnologa
Bluetooth (ya sea integrado o mediante un adaptador Bluetooth USB dongle). Solo un
dispositivo se puede programar a la vez. Una vez que se ha programado y configura-
do, los ajustes del dispositivo permaneceran, (independiente de su bajo uso) hasta que
literalmente son modificados o restaurados a la configuracion de fabrica (Fig.2.8).
Antes de empezar con la alimentacion del dispositivo y la vinculacion con la PC. Los
dispositivos de Bluetooth de Roving Networks, pueden ser programados a traves de
un enlace Bluetooth o a traves de una interfaz serie. Para programar el dispositivo,
debe de
23 CAPITULO 2.
2.4. DISPOSITIVO BLUETOOTH ROVING NETWORKS 23
BLUETOOTH

Figura 2.7: Los Perfiles Bluetooth

conectarse al puerto COM asignado por el dispositivo a traves 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 estandar industrial de protocolos Hayes AT. El set de comandos
configura el modulo y recibe comandos eco de la configuracion actual. Los ajustes de la
configuracion modificada con el set de comandos, no surtiran efecto hasta que el modulo
de Bluetooth sea reiniciado, a pesar de que el comando GET podra mostrar lo
contrario.

2.4.1. Estableciendo una conexion 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 ultimos cuatro nibbles de la direccion
MAC
Bluetooth. El nombre del dispositivo local se puede cambiar. Se tendr que emparejar
con el dispositivo haciendo doble clic en el nombre de este y siguiendo el menu. El
firm- ware almacena automaticamente hasta 8 parejas de maquinas remotas en una
primera vez.
24 2.4. DISPOSITIVO BLUETOOTH ROVING NETWORKS CAPITULO 2. 24
Si el dispositivo Bluetooth remoto no requiere autenticacion,
BLUETOOTH una conexion puede
ocu- rrir sin el proceso de emparejamiento. Sin embargo, la especificacion Bluetooth
establece
Figura 2.8: Modulo Bluetooth Roving Networks

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


quiere autenticacion, el otro dispositivo debe participar para garantizar un vnculo
seguro. El modo por defecto de los modulos de RN es un modo ABIERTO, de tal manera
que el modulo NO requiere autenticacion. Sin embargo la mayora de PCs si lo
requieren.

La clave de paso es una cadena de caracteres alfa- numericos, de 1 a 16


caracteres de longitud. Durante el proceso de emparejamiento inicial, el codigo se
introduce en am- bos lados de la conexion Bluetooth, y debe coincidir para completar
la vinculacion. Esta clave se utiliza para crear una clave de enlace seguro, que luego se
almacena en ambos dispositivos. Tras los intentos de conexion posterior, el vnculo
clave se compara y debe coincidir antes que la conexion pueda continuar. La clave de
acceso por defecto es 1234 .

Para conectarse a FireFly, busque en los servicios que ofrece, debera ver: El perfil
SPP con un puerto COM virtual asignado. Abrir este puerto virtual COM para crear
una conexion Bluetooth. Una vez conectado, el dispositivo en modo de datos que
estar
permitir el flujo de datos en ambas direcciones, como si el puerto serie estuviera conec-
tado fsicamente (cable) a la PC. El dispositivo debe estar en modo comando para la
configuracion y programacion. Para entrar en modo comando teclee $$$ (tres signos de
pesos), ya sea con el control remoto Bluetooth o la conexion 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: Solo un cliente puede hacer la conexion esclavo FireFly a la vez. Como maestro,
es posible realizar multiples conexiones de Firefly, pero solo en un punto a punto,
en serialized fashion. En este momento los dispositivos RN no son compatibles con el
modo de multiples puntos maestros.

2.4.2. Modos de Operaci


on
Los modos de operacion 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 util 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 conectara au-
tomaticamente a la direccion anterior configurada como esclavo cuando un car
acter (o caracteres) se reciben en el local UART. La conexion permanece abierta
hasta que un temporizador de inactividad configurable (1 a 255 segundos), expire sin
datos
recibidos, o se vea un caracter de interrupcion (BREAK)
configurable.

Conexion automatica (modo maestro) (SM, 3): Si se selecciona este modo, el dis-
positivo iniciar una conexion a la direccion remota previamente almacenada
inme-
diatamente despues de encender el aparato. En este modo, los datos se pasan
sin que sean interpretados por el BluePort (alta velocidad), por lo tanto, la
conexion no se puede romper a traves de comandos. Si se produce desconexion, el
dispositivo intentara volver a conectar hasta que lo consiga.

Conexion automatica (modo DTR) (SM, 4):Este modo se debe establecer con
el set de comandos. Este modo funciona como conexion automatica al modo
Master, excepto que la conexion y desconexion estan controladas por los 3 dipswitch
externos
en el FireFly (no incluido en todos los modulos de Bluetooth).

Conexion automatica 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
on, excepto que cada vez que el switch / PIO esta prendido, se realiza una bu
squeda y al encontrar el primer dispositivo se conecta. La direccion almacenada NO
se utiliza, y la direccion que se encuentran nunca se almacena.
2.4.3. Configuracion
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 traves del puerto serial o del mando a distancia Bluetooth.
El dispositivo responder con CMD. Para salir del modo de comando, mande E l

dispositivo responder con END .En el modo de comando, el dispositivo acepta bytes
ASCII como comandos. Una revision rapida para ver si est en modo de comando es
el de escribir los comandos D y E despues de entrar en modo de comando. Esto le
mostrar los parametros, tales como el nombre de Bluetooth, la clase de dispositivos y
configuracion de puerto serie. Para acceder a la configuracion, el dispositivo debe
estar en modo de comandos mediante la emision de $$$ . Se debe entrar en el
modo de
comandos con la ventana de configuracion de 60 segundos o el modulo en el modo
entrar
rapido de datos donde todos los caracteres son ignorados incluyendo $$$ . Si expira el
temporizador de configuracion mientras esta en modo comando el dispositivo no entrar en
el modo rapido de datos despues 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.

Configuracion Local (a traves del puerto serie)

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

Velocidad de transmision 115 200 bps

8 bits

Sin paridad

1 bit de paro

Herramientas de control de flujo activado


La Configuracion local funciona en cualquier momento en que el dispositivo no dispone
de una conexion Bluetooth, y tambien trabaja bajo ciertas condiciones. Si el
dispositivo
est en modo de configuracion y se produce una conexion, el dispositivo del modo
saldr
27 2.4. DISPOSITIVO BLUETOOTH ROVING NETWORKS CAPITULO 2. 27
BLUETOOTH
de configuracion 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
comunicacion y los ajustes son correctos. A los comandos validos un AOK co-
devolver
mo respuesta, y los no validos volvera ERR . Para salir del modo de comandos, escriba
. (Tres signos menos).

Configuracion Remota (Va Bluetooth)

A menudo es util para poder realizar la configuracion remota a traves de una


cone- xion Bluetooth. Para ello, conectamos el dispositivo a traves de Bluetooth, y
utilizando el emulador de terminal.

NOTA: Solo se puede entrar en el modo de comandos de forma remota a traves


de Bluetooth si ha hecho una conexion y se enviaron los $$$ en el contador de tiempo
de configuracion de la ventana despues de activarlo. Esto se puede modificar, el
temporiza- dor de configuracion por defecto caduca a los 60 segundos despues del
encendido.

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


cion remota) a 255 decimal, lo que permite conexion continua (sin tiempo de espera) de
configuracion.
Captulo 3

Android

Antes de pasar al desarrollo de la aplicacion de Android que nos compete para


el control de la iluminacion, nos detenemos un momento a preguntarnos; Que es
Android?,
Como surgio?, Como o para que se usa? Estas cuestiones sumadas a la descripcion
del desarrollo de la aplicacion son aspectos que se abordaran en este captulo.

Android es un sistema operativo basado en el nucleo Linux disenado


originalmente para dispositivos moviles, tales como telefonos 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 mas usado en Smartphones actualmente en el mundo no es una
idea que se le ocurri a alguien un da y tuvo un camino facil 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 au
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 mas 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
oviles
que revolucionara el mercado, aunque fue un ano despues, en Octubre de 2008 cuando
lo

29
30 3.2. QUE ES CAPITULO 3. 31
ANDROID? 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 tecnologa.

3.2. Que es Android?


Segun 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 moviles 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 programacion Java .

3.2.1. Caractersticas
Las caractersticas que posee la plataforma Android, se mencionan a continuacion
y posteriormente se desglosara su explicacion.

Es libre, codigo abierto y plataforma de software totalmente personalizable y un


sistema operativo para dispositivos moviles.

Basado en el kernel de Linux.


Permite escribir codigo Java.

La aplicacion de Framework permite la reutilizacion y sustitucion de


componentes.

Posee una maquina virtual Dalvik que optimiza el rendimiento en los dispositivos
moviles.

Integra un Navegador basado en el motor de codigo abierto de Webkit.

Poder de optimizacion de graficos mediante una biblioteca de graficos 2D


persona- lizado y graficos 3D basados en la especificacion OpenGL ES 1.0
(aceleracion 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 telefona (Dependiendo de Hardware).

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

Camara, GPS, brujula y el acelerometro (Dependiendo de hardware).

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


depuracion, 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 operacion de Android, es fundamental visualizar de forma grafica la
estructura del Software Stack Android (Fig.3.2).
Figura 3.2: Arquitectura de S.O. Android.

Kernel de Linux

Android se basa en la version 2.6 de Linux para los servicios del nucleo del
sistema como la seguridad, la gestion de memoria, gestion de procesos, la pila de red, y el
modelo de controlador (Fig.3.3). El nucleo tambien actua como una capa de
abstraccion 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.


33 3.2. QUE ES CAPITULO 3. 33
ANDROID? ANDROID
No incluye el conjunto de utilidades completas estandar de Linux.

Parches de mejoramiento de kernel para soportar Android.


Android el kernel de Linux como soporte basico de su sistema, por
escogio varias
razones importantes:

Gran memoria y gestion de procesos.

Modelo de seguridad basado en permisos.

Soporta las bibliotecas compartidas.

Es de codigo abierto.

Dalvik

Dalvik es la maquina virtual que utiliza la plataforma para dispositivos moviles


An- droid. Dalvik ha sido disenada por Dan Bornstein con contribuciones de otros
ingenieros de Google (Fig.3.4).

Figura 3.4: Capa de la maquina virtual Dalvik.

Dalvik esta optimizada para requerir poca memoria y esta disenada para
permitir ejecutar varias instancias de la maquina virtual simultaneamente, delegando en
el sistema operativo subyacente el soporte de aislamiento de procesos, gestion de
memoria e hilos.

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


cucion.

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

Los archivos java.class/.jar los convierte a .dex en tiempo de ejecucion.


Libreras Nativas

Las libreras 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 Libreras 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 asignacion de memoria virtual y la paginacion.

Manejo de caracteres.

Cadenas y matrices de utileras.

Busqueda y clasificacion.

Flujo de entradas y salidas.

Bajo nivel de entradas y salidas.

Archivos de interfaz del sistema.


35 3.2. QUE ES CAPITULO 3. 35
ANDROID? ANDROID
Matematicas.

Funciones aritmeticas.

Fecha y hora.

Al tener claro las funcionalidades de Libc, nos queda preguntarnos Que es


Bionic? Es la implementacion 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 libreras tales como:

WebKit.

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

Soporta ccs, javascript, dom y ajax.

Soporta la representacion y adaptacion de vista de una sola columna.

Media Framework.

Soporta audio y video estandar, ademas de formatos en

fotogramas. Soporta codec plug-ins para software y hardware.

SQLite.

Peso ligero de almacenamiento de datos transaccionales.

Back-End para la mayora de plataformas de almacenamiento de datos.

Servicios Nativos

Surface Manager

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


sentacion de la superficie de dispositivo.

Puede combinar superficies 2D, 3D y superficies para multiples aplicaciones.


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

Hardware Libreras Abstractas

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

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

Separa la plataforma logica de Android de la interfaz de hardware (Fig.3.6).

Figura 3.6: Librerias Abstractas de Hardware.

Aplicacion Framework

En esta Plataforma de Servicios Basicos estan localizadas los servicios para el


telefono 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 clasificacion de Plataforma de Servicios Basicos , encontramos de


igual manera servicios que atienden el funcionamiento basico de hardware, tales como:

Servicios de telefona.
37 3.3. APLICACIONES ANDROID CAPITULO 3. 37
ANDROID
Servicio de ubicacion.

Servicio de Bluetooth.

Servicio Wifi.

Servicios de USB.

Servicios de sensores (acelerometros y giroscopios)

Figura 3.7: Capa de Aplicaciones Framework.

La ultima capa dentro de la arquitectura de Android que pertenece a las


Aplicaciones como tal. Puesto que este tema es de suma importancia tendra un desarrollo
mas detallado en una seccion aparte. Para poder visualizar la arquitectura del Sistema
Android con todos sus componentes expuestos (vease apendice A).

3.3. Aplicaciones Android


Los dispositivos de Android incluyen un conjunto de aplicaciones basicas, como un
cliente de correo electronico, programa de SMS, calendario, mapas, navegador, contactos,
y otros. Todas las aplicaciones se escriben usando el lenguaje de programacion Java . Estas
aplicaciones se encuentran en la ultima capa de la arquitectura del software de Android
(Fig.3.8).

Figura 3.8: U ltima Capa de


Aplicaciones.
3.3.1. Fundamentos de una aplicacion
Las aplicaciones Android estan escritas en el lenguaje de programacion Java. Las he-
rramientas de Android SDK compilan el codigo, junto con los datos y archivos de
recursos en un paquete de Android, con esta compilacion se genera un archivo con
extension apk. Todo el codigo se guarda en un unico archivo, y es lo que se considera
como una aplica- cion, este archivo es el que Android utiliza para instalarlo dentro del
dispositivo.

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

El sistema operativo Android es un sistema multi-usuario en el que cada aplicacion


es un usuario diferente.
Por defecto, el sistema asigna a cada solicitud un unico ID de usuario de Linux
(el ID es utilizado solo por el sistema y se desconoce en la aplicacion). El sistema
establece permisos para todos los archivos en una aplicacion, para que solo el ID
de usuario asignado a esa aplicacion puede acceder a ellos.

Cada proceso tiene su propia maquina virtual (VM), por lo que el codigo de una
aplicacion se ejecuta de manera aislada de otras aplicaciones.

Por defecto, cada aplicacion se ejecuta en su propio proceso de Linux. Android inicia
el proceso cuando alguno de los componentes de la aplicacion 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 mnimos. Es


decir, cada aplicacion, por defecto, solo tiene acceso a los componentes que necesita para
hacer su trabajo y nada mas. Esto crea un ambiente muy seguro en el que una
aplicacion no puede acceder a partes del sistema para el cual no se le da permiso.

Sin embargo, hay maneras para que una aplicacion pueda compartir datos con otras
aplicaciones y de una aplicacion 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 demas archivos. Para ahorrar recursos del
39 3.3. APLICACIONES ANDROID CAPITULO 3. 39
ANDROID
sistema, las aplicaciones con el mismo ID de usuario tambien pueden hacer
arreglos para ejecutar en el mismo proceso de Linux y comparten la misma m
aquina virtual
(las solicitudes deben estar firmadas con el mismo certificado).

Una aplicacion puede solicitar permiso para acceder a los datos del
dispositivo, tales como los contactos del usuario, los mensajes SMS, el
almacenamiento externo (tarjeta SD), camara, Bluetooth, y mucho mas. Todos los
permisos de la aplicacion debe ser concedidos por el usuario durante la instalacion.

3.3.2. Componentes de una aplicacion

Los componentes de una aplicacion Android, son los bloques esenciales para la cons-
truccion de la misma. Cada componente es un punto diferente a traves del cual el
sistema puede entrar en su aplicacion. 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 desempena un papel especfico, cada uno es una pieza unica que
ayuda a definir el comportamiento general de la aplicacion.

Hay cuatro tipos de componentes diferentes en una aplicacion. Cada tipo tiene un
proposito distinto y tiene un ciclo vital distinto que define como el componente se crea y
se destruye.

Estos son los cuatro tipos de componentes de la aplicacion:

Activities (Actividades)

Un activity representa una pantalla unica con una interfaz de usuario. Por ejemplo,
en una aplicacion de correo electronico, puede haber una activity que muestra una lista
de correos electronicos nuevos, otra activity para enviar un correo electronico, as como
otra activity para la lectura de mensajes de correo electronico. Aunque las activities
trabajan para formar una experiencia coherente en la aplicacion de correo electronico,
cada una es independiente de las otros. Como tal, una aplicacion puede ingresar a
cualquiera de estas activities (si la aplicacion de correo electronico lo permite). Por
ejemplo, una aplicacion de camara puede adentrarse a la activity en la aplicacion de
correo electronico que enva nuevos mensajes de correo, para que el usuario pueda
compartir una imagen (Fig.3.9).
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 duracion o para realizar un trabajo de procesos remotos. Un service no
proporciona una interfaz de usuario. Por ejemplo, un service puede reproducir musica
en
segundo plano mientras el usuario est en una aplicacion diferente, o puede obtener los
datos por la red sin la interaccion 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 el (Fig.3.10).

Content Providers (Proveedores de contenido)

Un content provider maneja un conjunto compartido de datos de aplicacion. 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 aplicacion puede tener
acceso. A traves 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 informacion de contactos del usuario. Por lo tanto,
cualquier aplicacion con los permisos adecuados puede hacer una consulta por parte del
content provider para leer y escribir informacion sobre una persona en particular.

Los content providers tambien son utiles para la lectura y escritura de datos que son
Figura 3.10: Servicios en Segundo Plano.

privados en una aplicacion y no se comparten. Por ejemplo, el Bloc de Notas, esta


simple aplicacion utiliza un content provider para guardar notas (Fig.3.11).

Figura 3.11: Ejemplo de Proveedor de Contenido.

Broadcast Receivers (Receptores de radiodifusion)

Un receptor de radiodifusion es un componente que responde a los anuncios de


difusion en todo el sistema. Muchas emisiones se originan en el sistema, por ejemplo, una
emision
que anuncia que la pantalla se ha apagado, la batera baja, o una imagen fue cap-
est
turada. Las solicitudes tambien 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 radiodifusion no
se muestran como una interfaz de usuario, pueden crear una notificacion en la barra de
estado para alertar al usuario cuando un evento de difusion se produce. Sin embargo,
un receptor de radiodifusion es mas comun como una puerta a otros componentes y
tiene la intencion de hacer una mnima cantidad de trabajo (Fig.3.12).

Figura 3.12: Notificacion de Broadcast.

Activacion de componentes

Se debe de aclara un par de puntos sobre un sistema Android, los cuales nos llevar
an a la activacion de componentes mediante los Itent.

Una aplicacion no puede activar directamente un componente de otra aplicacion.

El sistema Android se encarga de activar esos componentes.

Los intents (intenciones) es un mensaje asincronico que se une a los componentes in-
dividuales entre s. Los intents son una descripcion abstracta de una operacion a
realizar.

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

A continuacion veremos esquemas que ilustran las diferentes formas en las que un
Intent trabaja.
43 3.4. DESARROLLANDO APLICACIONES ANDROIDCAPITULO 3. 43
ANDROID
Intent explcita 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 menciono en la definicion de Android anteriormente expuesta, para que
un desarrollador pueda realizar, disenar y compilar sus aplicaciones es necesario que
cuente con el SDK de Android. En este apartado se explicara las herramientas para
instalar un entorno de desarrollo Android as como los requerimientos mnimos, las
alternativas de desarrollo, la forma de instalacion y la introduccion a la programacion
de una aplicacion 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).

Segun el diccionario de terminos tecnicos , se define un Entorno de Desarrollo


In- tegrado como un programa informatico compuesto por un conjunto de
herramientas de programacion. Puede dedicarse en exclusiva a un solo lenguaje de
programacion o bien, poder utilizar varios de ellos.

Un IDE es un entorno de programacion que ha sido empaquetado como un programa


de aplicacion, es decir, consiste en un editor de codigo, un compilador, un depurador y
un constructor de interfaz grafica (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 mayora de los lenguajes de
programacion tales como C++, Python, Java,C#, Delphi, Visual Basic, etc. En algunos
lenguajes, un IDE puede funcionar como un sistema en tiempo de ejecucion, en donde
se permite utilizar el lenguaje de programacion 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 programacion.
Este es el caso de Eclipse, al que mediante plugins se le puede anadir soporte de
lenguajes adicionales.

Android SDK y Eclipse

Como acertadamente se menciono, Eclipse es una IDE que tiene la capacidad de fun-
cionar con varios lenguajes de programacion. 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
ejecutar las Maquinas 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 explicacion a detalle de
las pantallas de Eclipse y la introduccion basica para empezar a programar aplicaciones
en este entorno, se encuentran en la pagina 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
mas detallada todas sus caractersticas y herramientas.

La forma de crear aplicaciones para Android con App Inventor es practicamente f


acil con un navegador web. Y tan sencillo como crear un diseno y seleccionar las
acciones a realizar, tan dinamico como un puzzle (Fig.3.17).
Los pasos necesarios a considerar para comenzar a trabajar con App Inventor son:
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 configuracion de Java

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

a ) Podemos visitar la pagina de prueba de Java para comprobar si se ha


insta- lado correctamente . Al terminar podremos observar un mensaje de
que Java
est funcionando y que la version es Java 1.6 o superior.
b) Antes de poder utilizar el entorno de desarrrollo App Inventor, es necesario
instalar un software en su ordenador ( Paso 2 ).

2. Instalacion de las libreras App Inventor.

Windows XP,Windows Vista, Windows 7:


Recomendamos que realice la instalacion desde una cuenta que tenga pri-
vilegios de administrador en su equipo. Esto instalar el software para todos
los usuarios de la maquina. Si usted no tiene privilegios de administrador, la
instalacion debera funcionar, pero la aplicacion de App Inventor solo uti-
podr lizarse a partir de la cuenta que se uso cuando instalo el
software.

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


on
) : AppInventor Setup Installer v 1 1.exe (92 MB).
b) Si una vez instalado, y al comenzar a utilizar App Inventor Web, Java
le pregunta la ubicacion del software, esta se localiza la direccion:
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 instalacion
): AppInventor Setup Installer v 1 1.dmg (92 MB)
GNU/Linux:
Descargar y ejecutar este instalador ( No modificar la ruta de instalacion
): AppInventor Setup Installer v 1 1 all.deb(92 MB)
Si no es posible instalar el .deb se descarga y ejecuta el siguiente este insta-
lador ( No modificar la ruta de instalacion ): AppInventor Setup Installer v 1 1.tar.gz
(92 MB)

3. Una vez instalado todo los requerimientos del sistema para trabajar con App Inven-
tor solo necesitamos iniciar sesion en la cuenta de Google y escribir en el buscador:
http://appinventor.go oglelabs.com, esta pagina te llevara al entorno de desarrollo
el cual se explicar a detalle mas adelante.
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/ab out/,
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 Basica de APP Inventor


Antes de comenzar con la explicacion para desarrollar una aplicacion en APP
Inventor, vale la pena mencionar las ventajas y desventajas que existen al utilizar este
entorno en comparacion con Eclipse.

Ventajas:
49 3.5. ESTRUCTURA BA SICA DE APP CAPITULO 3. 49
INVENTOR ANDROID
Se requiere de conocimientos mnimos de programacion en C, Java, o semejantes.

Su entorno es totalmente grafico, y se requiere de un mnimo de escritura.

Las funciones de cada herramienta son de igual manera graficas.

Se hace la relacion entre codigos mediante una conexion grafica tipo Puzzle
(literal-
mente).

No requiere mayor instalacion de software especializado.

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


de desarrollar en cualquier equipo con un mnimo 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 comparacion del Entorno de Eclipse.

La aplicacion terminada generalmente ocupa mayor espacio en memoria que una


hecha bajo programacion clasica (escrita).

Si no se cuenta con conexion 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 poda utilizar App
Inventor
a menos que se recibiera una invitacion a su correo de Google.

Para poder subir las aplicaciones al Market se requiere de otro software para hacer
compatible la aplicacion con los requerimientos de Android Market, sin en cambio
Eclipse no requiere de este software extra.
La estructura basica de APP Inventor est conformada por 4 partes, las cuales son
fundamentales para el funcionamiento correcto de esta aplicacion (Fig. 3.19).

Figura 3.19: Estructura de APP Inventor.

Google App Inventor Server.

App Inventor Ventana de Diseno.

App Inventor Editor de Bloques.

App Inventor Android Emulador o Telefono.

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


servidor de Google que nos proporciona lo necesario para disenar una aplicacion, y
este
estar activo indirectamente siempre que haya internet y este dentro de la pagina de
desarrollo.
3.5.1. Ventana de Diseno
Para visualizar esta ventana en donde se seleccionaran los componentes de la aplica-
cion, 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 mas proyectos.

Figura 3.20: Crear el primer Proyecto en App Inventor.

Para poder llevar acabo la creacion del primer proyecto, damos clic en el boton
de New y a continuacion le asignamos un nombre. Automaticamente despues de
presionar ok nos mostrara la Ventana de Diseno (Fig. 3.21).
La Ventana de Diseno conformada por cinco partes escenciales:
est

Paleta de Componentes

Vista Previa del Diseno

Componentes de la aplicacion

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 disenar nuestra aplicacion en el aspecto visual. La forma en
que
Figura 3.21: Ventana de Diseno.

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


hacia la Ventana de Diseno para observar la vista previa del diseno (Fig. 3.22).

Figura 3.22: Paleta de Componentes.


Esta paleta nos muestra los componentes de acuerdo a una clasificacion especfica,
estos componentes pueden ser de dos tipos haciendo referencia a la forma de visualizarlos,
si los componentes se pueden observar en la aplicacion final, se denotaran como
visuales; si son componentes que ejecutan tareas pero no se ven en la aplicacion final, se
denotaran en la redaccion como no visuales:

1. Componentes Basicos (Fig. 3.23).

Button: Permite colocar el componente de boton en la aplicacion que


estamos
desarrollando (visual).

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


(dibujos, rayas, crculos) en la aplicacion que estamos desarrollando(visual).

CheckBox: Permite colocar el componente de cajas de seleccion en la aplicaci


on
que estamos desarrollando (visual).

Clock: Permite colocar el componente de reloj en la aplicacion que estamos


desarrollando para temporizadores (no visual).

Image: Permite colocar el componente de insertar imagen en la aplicacion que


estamos desarrollando (visual).

Label: Permite colocar el componente de Etiqueta en la aplicacion que estamos


desarrollando (visual).

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


on
que estamos desarrollando (visual).

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


trasenas en la aplicacion que estamos desarrollando (visual).

TextBox: Permite colocar el componente de Caja de texto en la aplicacion que


estamos desarrollando (visual).

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


la aplicacion que estamos desarrollando (no visual).
Figura 3.23: Componentes Basicos.

2. Componentes Multimedia (Fig. 3.24).

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


de la camara en la aplicacion que estamos desarrollando (no visible).

ImagePicker: Permite colocar el componente de imagenes interactivas en la


aplicacion que estamos desarrollando (visible).

Player: Permite colocar el componente de reproduccion multimedia en la apli-


cacion que estamos desarrollando (no visible).

Sound: Permite colocar el componente para agregar sonidos en la aplicacion


que estamos desarrollando (no visible).

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


aplicacion que estamos desarrollando (visible).
Figura 3.24: Componentes Multimedia.

3. Componentes Animados (Fig. 3.25).

Ball: Permite colocar el componente para un balon con animacion en la


aplica- cion que estamos desarrollando, se podra meter a la aplicacion si y
solo si esta
dentro de un componente Canvas (visible).

ImageSprite: Permite colocar el componente para una imagen con animacion


en la aplicacion que estamos desarrollando, se podra meter a la aplicacion 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


aplicacion que estamos desarrollando (visible).

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


en la aplicacion que estamos desarrollando (visible).

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


un telefono en la aplicacion que estamos desarrollando (no visible).
PoneNumberPicker: Permite colocar el componente para introducir un numero
telefonico en la aplicacion que estamos desarrollando (visible).

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


cacion que estamos desarrollando (no visible).

Twitter: Permite colocar el componente para las propiedades de publicacion


en twitter dentro de la aplicacion 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 acelerometro en la aplicacion que estamos desarrollando (no visible).

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


de gps en la aplicacion que estamos desarrollando (no visible).

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


ciones de orientacion en la aplicacion que estamos desarrollando (no visible).

Figura 3.27: Componentes de Sensores.


6. Componentes de Organizacion de Pantalla (Fig. 3.28).

HorizontalArrangement: Permite colocar el componente para organizar hori-


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

Figura 3.28: Componentes de Organizacion.

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 3.5. ESTRUCTURA BA SICA DE APP CAPITULO 3. 58
INVENTOR 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 aplicacion.
BarCodeScanner: Permite colocar el componente para leer y procesar codigos
de barras en la aplicacion que estamos desarrollando.
BluetoothClient: Permite colocar el componente para manipular todos los ser-
vicios de Bluetooth como cliente en la aplicacion que estamos desarrollando.
BluetoothServer: Permite colocar el componente para manipular todos los ser-
vicios de Bluetooth como servidor en la aplicacion que estamos
desarrollando.
Notifier: Permite colocar el componente para mostrar avisos y notificaciones
personalizadas en la aplicacion que estamos desarrollando.
SpeechRecognizer: Permite colocar el componente para identificar comandos
de voz en la aplicacion que estamos desarrollando.
TextToSpeech: Permite colocar el componente para utilizar la escritura por
voz en la aplicacion que estamos desarrollando.
TinyWebDB: Permite colocar el componente para la manipulacion de Bases de
Datos en la Web en la aplicacion que estamos desarrollando.
Web: Permite colocar el componente para manipular todos los servicios de web
en la aplicacion 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 3.5. ESTRUCTURA BA SICA DE APP CAPITULO 3. 60
INVENTOR ANDROID
Para obtener una descripcion mas detallada de cada componente en la misma paleta,
cada componente esta acompanado de un signo de interrogacion en el cual dar clic
podra
para desplegar una ventana de informacion correspondiente al mismo (Fig. 3.32).

Figura 3.32: Descripcion de Componentes.

Viewer

Esta seccion de la ventana de diseno la que nos permitira visualizar el diseno de


ser
nuestra aplicacion al momento de estarla desarrollando, es en esta parte donde se
jalan los componentes con los que desea trabajar.

Ya que esta area de trabajo nos muestra una pantalla que emula un dispositivo movil,
podremos ver la apariencia que tendr al momento de estar ejecutandose en el dispositivo.

En esta seccion, 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 seccion dentro de la ventada de diseno, nos permite ver los componentes que
hemos elegido para desarrollar la aplicacion en forma de arbol; en esta parte se
incluyen los componentes no visibles en la misma jerarqua que los visibles.
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 jerarqua (Fig. 3.34).

Esta seccion nos permite cambiar el nombre que por defecto proporciona App Inventor
a cada componente, para facilitar la identificacion a la hora de trabajar en el editor de
bloques; de igual forma nos permite borrar un componente que ya no nos sea util y por
ultimo en la parte inferior tenemos la posibilidad de cargar las imagenes que deseamos
ocupar dentro de nuestra aplicacion (el nombre de la imagen no debe de tener caracteres
especiales para ser reconocida).

Properties

La seccion de propiedades dentro de la Ventana de Diseno nos permite modificar


las propiedades que tiene cada uno de los componentes que esten en nuestra area de
trabajo (Fig. 3.35).

Estas propiedades son diferentes dependiendo del componente seleccionado, para men-
Figura 3.34: Seccion de Componentes.

cionar algunas de ellas haremos referencia a las propiedades que salen por defecto al cargar
nuestra area 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 aplicacion.

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

Icon: Permite cambiar el icono de la aplicacion que se genera por default; cargandolo
previamente en la seccion de componentes.

ScreenOrientation: Se elige la orientacion que deseemos que tenga nuestra aplicacion;


vertical, horizontal o que dependa de la posicion del dispositivo movil.

Scrollable: Coloca una barra deslizadora en caso de que nuestra aplicacion se mas
grande que la pantalla de nuestro dispositivo.
Title: Podemos poner un nombre personalizado al ttulo de la pantalla principal.

Figura 3.35: Seccion de Propiedades.

Barra de Herramientas

Esta seccion 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 opcion de
guardar la aplicacion que se encuentre actualmente en el area de trabajo, guardar con
otro nombre la misma aplicacion usando el boton:Guardar Como ; nos permite
establecer un punto de recuperacion con el Checkpoint,abrir el Editor de Bloques y por
ultimo, da la opcion de descargar nuestras aplicaciones ya sea en el telefono, en la PC
o generar el BarCode para el link de descarga de nuestra aplicacion (Fig. 3.36).

Figura 3.36: Barra de Herramientas.


3.5.2. Editor de Bloques
Para poder trabajar con esta herramienta es necesario que se encuentre abierta la
Ventana de Diseno, ya que en ella esta el boton que nos permite accesar al Editor
de Bloques; este boton se localiza en la parte superior derecha de la Ventana de Diseno
(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 Diseno, ya que es donde se reunen
los
bloques de programa que especifican como deben comportarse los componentes. Estas
acciones y configuraciones se programan montando y ensamblando bloques de c
odigo semejantes a un rompecabezas (Fig. 3.38).

Figura 3.38: Editor de Bloques.

El Editor de Bloques al igual que la Ventana de Diseno consta de varias


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

Seccion de Bloques
65 3.5. ESTRUCTURA BA SICA DE APP CAPITULO 3. 65
INVENTOR ANDROID
A rea de trabajo

Barra de herramientas

Seccion de bloques

En esta seccion se encuentran los bloques de accion correspondientes a los


componentes que elegimos en la Ventana de Diseno, tambien encontramos bloques de
construccion de programa y bloques avanzados.

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


contiene cada componente, por ejemplo un componente boton tiene la accion 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 codigo que ya estan definidos por el Editor de Blo-
ques, nos ayudan a realizar operaciones logicas, condiciones, definir variables, reali-
zar programacion de control, editar textos y cambiar colores entre otras funciones
(Fig. 3.40).
Figura 3.40: Build-In.

Avanzado: Son bloques de codigo mas especializados sobre los componentes que
definimos anteriormente en la Ventada de Diseno (Fig. 3.41).

Figura 3.41: Advanced.


A rea de traba jo

Este es evidentemente el espacio que tenemos en blanco para poder arrastrar los blo-
ques de programacion y empezar a armar la logica de nuestro programa, en a
esta rea
de trabajo se encuentra un bote de basura , en donde podemos arrastrar las piezas de
codigo que ya no nos sirvan (Fig. 3.42).

Figura 3.42: A rea de


Trabajo.

En el area 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 area de
trabajo cuenta con un zoom grafico en la parte superior derecha con la que podemos
explorar todos nuestros bloques de codigo que hemos armado en el area de trabajo.

Esta area de trabajo puede expandirse de acuerdo con las necesidades del
programador, si requiere mas espacio para programar, automaticamente se lo proporciona
esta area.

Barra de Herramientas
Las herramientas con las que cuenta son: salvar o guardar la programacion de bloques
hecha, ir a un estado anterior, ir a un estado posterior, cargar un emulador para correr la
aplicacion, conectarse a un dispositivo y un zoom de barra deslizable (Fig. 3.43).
Figura 3.43: Barra de Herramientas.

La importancia de estas herramientas es fundamental, y mas 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 aplicacion; es posible
visualizar el comportamiento final de la aplicacion en desarrollo,permite ver errores de
ejecucion para corregirlos. Esta opcion esta en caso de que no se cuente con un dispositivo
Android en el momento de programar y se desee ver como se comporta la aplicacion en
tiempo de ejecucion.

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


programamacion de la aplicacion, har que se consuma mas recursos de memoria; ya que
el cargar este emulador equivale basicamente a estar corriendo el sistema operativo de un
celular con las funciones basicas al mismo tiempo que corre el Sistema Operativo, y
las aplicaciones que se tengan en el equipo de computo (Fig. 3.44).

Figura 3.44: Emulador Android.

La segunda herramienta nos permite conectarnos a un dispositivo fsico o en su defec-


70 3.6. INSTALACIO N Y DISTRIBUCIO N DE APLICACIONES CAPITULO (ANDROID
3.
MARKET)69 ANDROID
to al emulador que se cargo previamente; si es que se cuenta con un dispositivo Android
conectado por USB al equipo de computo, y este dispositivo est configurado dentro de
desarrollo con la depuracion USB, posible que el Editor de Bloques reconozca el
ser
dispositivo, se conecte para enviarle la aplicacion y que se ejecute en tiempo real de pro-
gramacion.

Esta opcion da un panorama acertado de como se vera la aplicacion ejecutandose


en el dispositivo, y se podra ver las modificaciones tanto del Editor de Bloques como de
la Ventana de Diseno en tiempo real.

3.6. Instalacion y distribucion de Aplicaciones


(An- droid Market)
Para la distribucion 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 estan dentro del market estrictamente, simplemente dando el permiso de Origen
Desconocido desde Configuracion/Aplicaciones/Origen Desconocido, en tu celular, podras
instalar aplicaciones fuera del Market.

Figura 3.45: Android Market.

3.6.1. Ba jar Aplicaciones desde Android Market


Para poder bajar aplicaciones del Android Market, debes de contar con la aplicaci
on del mismo en tu dispositivo movil, el cual en la mayora de los casos viene por
default, cuando abres por primera vez el market desde el movil, te pide una cuenta de
Google con la que sera 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).
Figura 3.46: Aplicacion Android Market.

Si descargas desde otros sitios y desde tu computadora puedes guardar el archivo apk
y despues pasarlo al dispositivo movil a traves del cable USB a la tarjeta de memoria
del dispositivo, una vez almacenada, buscas la aplicacion con algun 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-
tinuacion se describiran:

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 aplicacion .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
podras
72 3.6. INSTALACIO N Y DISTRIBUCIO N DE APLICACIONES
CAPITULO
(ANDROID
3.
MARKET)71 ANDROID
borrarlas de tu panel de control.

Pasos para firmar una aplicacion desde eclipse:


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

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

Pasos para firmar una aplicacion desde App Inventor:

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


poder subir una aplicacion al market, se debe pasar por un proceso de conversion 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 validos para subirlos
al Android Market.

AppToMarket v2.3
Archivo comprimido formato ZIP [32.9 MB]

2. Descomprimes el archivo.

3. Y procedes a la conversion de la aplicacion generada en App Iventor.

Pasos para subir tu App estando en la Pagina de Android Market y con


tu cuenta activa

1. Clic al boton Upload Application .

2. Te saldra un formulario que tendras que llenar

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

4. Si estas seguro que todo es correcto, dale clic a Publish .


5. Las Apps que publiques se mostraran instantaneamente en el Market, sin ningu
n tipo de aprobacion.

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


activa aparecer una lista que mostrara las aplicaciones plublicadas.
Captulo 4

Aplicacion ATOM y Prototipo

Este proyecto implica desarrollar una aplicacion compatible con el Sistema Operativo
Android para dispositivos moviles que sea capaz de comunicarse a distancia mediante
Bluetooth a un receptor que procesa la informacion recibida y a su vez ordena a un
con- junto de dimmers que ejecuten tareas especficas e independientes para la regulaci
on de las lamparas.

En el desarrollo de este captulo se llevara a cabo el diseno y construccion de cada


uno de los sistemas que componen este proyecto.

4.1. Construccion y Programacion de un Dimmer


En primera instancia para este proyecto, se considero que era necesaria y
fundamen- tal la construccion de una serie de dimmers para hacer el control de la
iluminacion en las lamparas. Estos dimmer deben de tener ciertas caractersticas que
permitan ser con- trolados mediante pulsos, voltaje o corriente, por lo que la fabricaci
on de un dimmer convencional a con resistancia variable quedo descartado desde el
comienzo.

Se analiz la posibilidad de utilizar un microcontrolador para gestionar las ordenes de


atenuacion 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 tecnica de deteccion de cruce por cero.

73
74 CAPITULO 4. APLICACIO N ATOM Y
PROTOTIPO
4.1.1. Propuesta y explicacion de Hardware
Existe gran cantidad de aplicaciones donde se requiere la regulacion de la corriente
alterna, entre ellas, el control de velocidad de motores, la soldadura electrica y el flujo
en la iluminacion.

La presente etapa tiene como proposito mostrar la regulacion de potencia electrica


uti- lizando el PIC16F648A (Fig.4.1) y agregando como hardware adicional un
optoacoplador que asla a este del circuito de potencia constituido por un Triac. La t
ecnica se basa en que la potencia de salida puede variarse regulando la fase de
conduccion del Triac tanto en el semiciclo positivo como en el semiciclo negativo de la
onda sinosoidal.

Figura 4.1: Microcontrolador para Dimmer.

Teora de Operacion

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 operacion del software. El pin RA4 es utilizado como salida de los
pulsos que disparan el optoacoplador. Dos pulsadores (se eliminaran 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 disenado 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 lamparas
ahorradoras y dimeables). El Pin MCLR el cual es activo bajo, se configura como
entrada y es usado
4.1. CONSTRUCCIO N Y PROGRAMACIO 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 tension aplicada a la carga.

Figura 4.2: Circuito Propuesto.

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

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


76 CAPITULO 4. APLICACIO N ATOM Y
PROTOTIPO
4.1.2. Programa del microcontrolador y explicacion
El desarrollo del codigo para el microcontrolador encargado de controlar las funciones
del Dimmer, se elaboro en el software oficial de Microchip: MPLAB IDE 7.5, y con
el compilador gratuito CC5X.

La idea y la estructura basica del codigo se de una propuesta de Scott Fink


retom
Microchip 1997(ver Apendice:PICREF-4), y fue adaptada para operar en el
microcontro- lador PIC16F648A, en este codigo se establece:

Deteccion de cruce por cero.

Estabilizacion de la tension mediante la deteccion de cruce por cero.

Sincronizacion en la fase de lnea.

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

Rutina para regular la intensidad de la luz mediante push boton.

Reset del programa en ejecucion.

Estos aspectos que se mencionan, se pueden ver descritos en el codigo de


programa adaptado (ver Apendice:Codigo Dimmer Adaptado).

4.2. Construccion y Programacion de Receptor


Blue- tooth
En segunda instancia se penso en el diseno de un receptor el cual dara las
instruccio- nes a los dimmers para atenuar, apagar o encender las lamparas; este receptor
recibe la informacion de forma inalambrica mediante Bluetooth. Al igual que la
construccion de los
dimmers, se propus trabajar con un microcontrolador con las caractersticas necesarias
para manipular una serie de dimmers y recibir informacion a traves de un modulo de
Bluetooth por el puerto USART.

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


al cuenta con 40 pines, 5 puertos, dos puertos de comunicacion USART, soporta la
conexion
4.2. CONSTRUCCIO N Y PROGRAMACIO N DE RECEPTOR BLUETOOTH
77

USB y tiene una frecuencia de trabajo maxima de 48MHz, complementada con un


cristal de 20MHz.

Figura 4.4: Microcontrolador para Receptor Bluetooth.

4.2.1. Propuesta y explicacion de Hardware


Para el diseno del hardware de esta segunda etapa se propuso hacer un circuito
en la que el microcontrolador PIC18F4550 este operando con una frecuencia de
trabajo de 48MHz por lo que el cristal fsico debe de ser de 20MHz. Sin contar los
pines de alimentacion, RESET, osciladores, comunicacion USB y los pines TX y Rx del
USART, podemos contar con 28 pines libres para usarlos en la comunicacion con los
dimmer anteriormente desarrollados (Fig. 4.5).
Los dos pulsadores que son utilizados en los dimmer propuestos anteriormente, seran
sustituidos por pulsos enviados por el micorcontrolador descrito en esta seccion. 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
lamparas simulta- neas, nos da un total de 56 lamparas (para el caso de 4 lamparas por
dimmer) controladas
en 14 bloques.

En los pines de transmision y de recepcion se un modulo de Bluetooth (RN41),


colocar
con el que se podr hacer la comunicacion y tendra un alcance de 100 mts. (ideales y
lnea de vista). bajo

Una vez propuesto el circuito de hardware minimo. Con ayuda de un software para el
78 CAPITULO 4. APLICACIO
4.3. ESTABLECIENDO COMUNICACIO N N ATOM Y 78
BLUETOOTH PROTOTIPO

Figura 4.5: Hardware minimo para operar PIC18F4550.

diseno de placas PCB (PCB Wizard), se realiza 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 modulo de Bluetooth (Fig. 4.6).

4.2.2. Programa del microcontrolador y explicacion


El desarrollo del codigo para el microcontrolador encargado de controlar los Dimmers
y recibir los datos va Bluetooth, se elaboro en el software oficial de Microchip:
MPLAB IDE 8.7, y con el compilador gratuito CC8X.

La idea y la estructura basica del codigo es un diseno propio, por lo que se


hizo especialmente para el microcontrolador PIC18F4550, en este codigo se establece:

Activacion de la comunicacion USART.


Figura 4.6: Placa PCB con Elementos y Pistas

Configuracion adecuada de todos los Registros y de la frecuencia de trabajo.

Estableces la velocidad de transmision en bps.

Lectura de los datos entrantes por el puerto USART.

Comparacion de datos y designacion de tareas para los Dimmer.

Reset del programa en ejecucion.

Estos aspectos que se mencionan, se pueden ver descritos en el codigo de


programa
(ver Apendice:Codigo Receptor).

4.3. Estableciendo Comunicacion Bluetooth


En tercera instancia se debe de atender el problema de la comunicacion
Bluetooth, para esto se propone utilizar el modulo de Bluetooth RN41 distribuido
por Rovinson
Network y adaptado por Sparkfun, este modulo tiene la capacidad de transmitir y recibir
datos va Bluetooth de forma serial (Fig. 4.7).

Figura 4.7: Modulo Bluetooth adaptado por Sparkfun.

Ya que este modulo esta especialmente hecho para trabajar con microcontroladores
mediante una conexion serial, su trabajo ser acoplado con el PIC18F4550, para que
mande al microcontrolador los datos que reciba a traves del Bluetooth.

4.3.1. Arreglo de Hardware para la prueba


Para realizar pruebas de comunicacion Bluetooth con este modulo, gracias a la
adap- tacion 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 modulo te da acceso a las
terminales de VCC, GND, Rx, Tx, CTS y RTC, de las cuales nosotros hacemos uso solo
de las primeras cuatro terminales.

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


tribucion adaptada de Sparkfun Fig. 4.8), es como debe de colocar el modulo 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 modulo requiere de una fuente de 5 VDC o 3 VDC,


conectada respectivamente en los senalamientos 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 va
Bluetooth, los recibe
Figura 4.8: Modulo Bluetooth BlueSMiRF 01.

Figura 4.9: Modulo Bluetooth BlueSMiRF 02.

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

Figura 4.10: Conexion de de Modulos 01 y 02.


4.3.2. Pruebas de conexion con HyperTerminal
Para realizar las pruebas pertinentes que demostraran si el modulo de Bluetooth
fun- ciona correctamente, es necesario contar con un equipo de computo 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
mas actual o de otro distribuidor, es posible bajarlo de la Web.

Una vez iniciada la HyperTerminal, vendran las ventanas de configuracion (Fig. 4.11)
para establecer la comunicacion serial. Para configurar estas ventanas, anteriormente se
emparej el modulo de Bluetooth BlueSMiRF con nuestro equipo de computo, y este
ultimo ya creo un puerto COM virtual para el modulo (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
odulo de BT
(Bluetooth) debe de estar alimentado y conectado como se especific anteriormente.
En las ventanas de configuracion se colocan los siguientes datos para poder continuar
y establecer la conexion:

Descripcion de la Conexion

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


omputo le asigno al modulo BT.

Propiedades del puerto COM

1. Bits por segundo: Escoge los bps con los que quieres que trabaje la conexi
on, preferente la primera vez escoger 9600 bps.
2. Bits de datos: Seleccione los bits de datos que estar mandando, colocar pre-
ferentemente 8.
Figura 4.11: Ventanas de Configuracion HyperTerminal.

3. Paridad: Establece si quiere una comunicacion 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 mostrara 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 modulo de BT (Fig. 4.12). Enfocandonos a los comandos
que nos conciernen tecleamos el comando: d y nos desplegara las funciones principales
del
modulo de BT, donde cambiaremos la velocidad de bits por segundo a 9600 bps con el
comando: su, 96 (vease Apendice).

Figura 4.12: Modulo BT en modo comando HyperTerminal.

Desde este momento, hemos comprobado que el modulo BT funciona


correctamente, pero para eliminar dudas, salimos de modo comando y ya fuera de este
podemos teclear cualquier caracter, si aparece en la pantalla se habra tenido exito ya
que aunque parezca que simplemente estas tecleando, en realidad lo que se hizo es
mandar el caracter va
Bluetooth al modulo BT que lo recibio, y como est en corto circuito lo que recibe (Rx)
con lo que transmite (Tx), significa que este mando el caracter de vuelta a la
terminal. Es as como se comprueba y se configura el modulo BT.

4.4. Diseno y Desarrollo de la aplicacion ATOM


En esta seccion se pretende explicar de una forma clara y sencilla el
procedimiento que se llevo acabo para el diseno y desarrollo de la aplicacion
correspondiente al Sistema Operativo Android; de tal forma que permita establecer una
conexion va Bluetooth entre
el dispositivo movil y el microcontrolador PIC18F4550 que el encargado de regir una
ser
serie de dipositivos dimmer para llevar acabo la regulacion de las luminarias.
4.4. DISEN O Y DESARROLLO DE LA APLICACIO N ATOM
85

4.4.1. Propuesta y descripcion de la aplicacion

La aplicacion debe de ser capaz de comunicarse va Bluetooth con el circuito


receptor de forma que permita enviar datos de acuerdo a las ordenes que el usuario del
dispositivo movil establezca.

E sta aplicacion una interfaz grafica que permitira al usuario escoger con qui
tendr en
se establecera la conexion dentro de una lista de dispositivos Bluetooth, su
estructura basica estara compuesta de 3 funciones de mando;dentro de estas funciones
se encuentra
MIN-MA posible variar el nivel de flujo luminoso a un mnimo o maximo, ya
X,ser sea
para hasta 14 lamparas de forma independiente o simultanea; la siguiente funcion es
la DIMMER que como su nombre lo indica, permite la atenuacion de hasta 14
lamparas de forma independiente o simultanea; por ultimo se encuentra la funcion de
ACELERO- METRO, con esta funcion es posible llevar acabo la atenuacion de 14
lamparas de forma simultanea haciendo uso de las propiedades que ofrece este sensor
(Fig.4.13).

Figura 4.13: Ventanas Principal de la Aplicacion.


86 4.5. INTEGRACIO N DECAPITULO
TODAS LAS4.ETAPAS DEL N ATOM Y
APLICACIO 86
SISTEMA PROTOTIPO
4.4.2. Desarrollo y esquema de la aplicacion
En este apartado se procede a la explicacion de los pasos que se llevaron a cabo
para la elaboracion de la aplicacion.

Como se menciono en el capitulo anterior, la aplicacion se en App Inventor,


desarroll
por lo que los pasos para crear un nuevo proyecto y la forma de agregar elementos a el
A rea de Trabajo se omitiran en este apartado.

En el A rea de trabajo incluimos por razones de comunicacion el componente de


Blue- tooth Cliente y por razones de manipulacion, el componente Sensor Acelerometro,
entre otros como botones, organizadores, tablas, etiquetas e imagenes (Fig.4.14).

Figura 4.14: Area de Trabajo en el Desarrollo de la Aplicacion.


En cuanto al Editor de Bloques se configur la comunicacion Bluetooth y se estable-
cieron las condiciones para enviar los datos al receptor, tanto de la funcion para m
nimos y maximos en las iluminarias, dimmers y acelerometro (Fig.4.15). En el
programa se en- cuentra la funcionalidad de cada componente de la aplicacion (ver Ap
endice: Programa en Editor de Bloques).
Figura 4.15: Editor de Bloques de la Aplicacion.

4.4.3. Prueba y depuracion con HyperTerminal en la PC

Una vez finalizado el diseno y desarrollo de nuestra aplicacion se procede a realizar


las pruebas necesarias para comprobar que su funcionamiento sea el adecuado; para ello
es necesario descargar e instalar la aplicacion a nuestro celular, a continuacion se lleva
acabo la configuracion de la herramienta HyperTerminal como hemos visto
anteriormente; de forma que se pueda comprobar que exista una comunicacion va
Bluetooth y a su vez,
esta mande los datos establecidos en nuestra aplicacion (Fig.4.16).

4.5. Integracion 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 culminacion que se in-
realiz
tegrando y enlazando todos los subsistemas para que al interactuar cumplieran con los
requerimientos establecidos en los objetivos. Por lado la aplicacion logre comunicarse
con el receptor de Bluetooth y este a su vez se comunique con los Dimmers que
controlaran la intensidad de las luminarias.
Figura 4.16: Pruebas y Depuracion de Comunicacion.

4.5.1. Diseno del hardware conjunto

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


control que permita la atenuacion de las luminarias, es necesario integrar todas los subsis-
temas que en conjunto seran 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 permitiran la atenuacion de las lamparas con su respectiva etapa de potencia.
Este prototipo de Hardware permitira 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 utilizacion de modulos independientes de dimmers (Fig.4.17).

Figura 4.17: Propuesta de Hardware Conjunto


Una vez propuesto el circuito de hardware para el sistema completo. Con ayuda de un
software para el diseno de diagramas electricos (Livewire), se realiza el diagrama
corres-
pondiente al hardware conjunto(Fig. 4.18).

Figura 4.18: Diagrama Electrico del Sistema Completo

Una vez propuesto el circuito de hardware para el sistema completo. Con ayuda de un
software para el diseno de placas PCB (PCB Wizard), se el diagrama correspon-
realiz diente(Fig. 4.19).
Figura 4.19: Placa PCB del Sistema Completo
Pruebas y Resultados

Como resultado de la investigacion realizada, el modelado del diagrama


conjunto, y de la aplicacion desarrollada para el Sistema Operativo Android, el cual
integra las especificaciones inciales del sistema, detalladas en el contenido de la
investigacion. Debido a que el sistema esta formado por varios modulos y probado
con diferentes modelos de lampara E27, a continuacion se presentan los resultados de
manera individual. Para las pruebas experimentales se realizaron las siguientes
mediciones:

Las pruebas de funcionalidad de la aplicacion del mando a distancia fueron las


siguientes:

Distancia maxima para la emision de datos va Bluetooth.

Verificacion de los datos emitidos por la aplicacion.

Pruebas de conexion con el modulo de Bluetooth.

Funcionamiento correcto de acelerometro.

Las pruebas de funcionamiento y comportamiento de los dispositivos dimmers que


se realizaron, fueron con las siguientes lamparas:

Lampara de LED dimmeable.

Lampara Fluorescente Compacta autobalstrada y dimmeable.

Lampara 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 continuacion en el orden que se mencionan


en las lneas superiores.

Distancias con las cuales se realizaron pruebas de conexion y verificacion de los


datos enviados va Bluetooth, para ello se consideraron las siguientes caractersticas de
la zona de prueba (Tabla.4.20) :

Campo abierto.

Clima soleado (de da).

Sin viento.

Sin obstaculos (Lnea de vista).

Tx = Celular Xperia X10 mini.

Rx = Modulo Bluetooth Roving Network.

Figura 4.20: Tabla de Conexion

El funcionamiento del sensor de acelerometro se puso a prueba enviando datos Blue-


tooth tanto a la HyperTerminal, como al Modulo de Bluetooth (Tabla.4.21):
Al realizar la regulacion de iluminacion en las diferentes lamparas 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
on, con el valor calificativo en porcentajes ( %)(Tabla.4.23):
93

Figura 4.21: Tabla de Envio de Datos.

Figura 4.22: Tabla de Comparacion de L


amparas.

Figura 4.23: Tabla de Comparacion de L


amparas.
Nota: El circuito propuesto para el sistema completo el cual est formado por la parte
receptora y cuatro dimmers con salidas a tres lamparas (la suma de las tres l
amparas menores a 150 Watts) cada uno; en las pruebas su funcionamiento fue de 50
%, debido a
que la etapa de recepcion de datos funciona correctamente; la falla en la etapa de
est potencia de los dimmers debido a un error en el diseno de la placa.
Conclusiones y Recomendaciones
para Traba jos Futuros

4.6. Conclusiones
En cuanto a la recopilacion de los datos podemos concluir de acuerdo con los objetivos
especficos que fue posible cumplir con el diseno, la programacion y la
implementacion tanto de un receptor Bluetooth, un circuito Dimmer con un
microcontrolador, en la pro- puesta y el desarrollo de la aplicacion en App Inventor
para ser usado en dispositivos moviles con Sistema Operativo Android, como mando a
distancia. La comunicacion Blue- tooth mediante el modulo de Roving Network y el
dispositivo movil fue un exito.

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


como a varios Dimmers en su arquitectura fallo por causas de diseno, 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 opcion mas para el ahorro de energa; como dice la teor
a
recabada en est investigacion; es muy difcil medir cuantitativamente con precision
cuan-
to es el ahorro al utilizar una tecnica y otro; de la misma forma al utilizar
dispositivos como lo son los dimmer, ya que aunque se considere un metodo para
ahorro de energa no existe una norma de lineamientos aun establecida que pueda regir y
estandarizar estos dispositivos. Pero se puede asegurar que el uso de lamparas
ahorradoras mas el uso de dispositivos que regulan la tension nos ofrece un ahorro
considerable y significativo, por lo que concluimos que si existe un ahorro de cierta
magnitud significativa.

Con respecto a la hipotesis planteada en el Captulo 1, podemos hacer inferencia


y

95
96 CONCLUSIONES

concluir que los aspecto de ahorro de energa, comodidad e innovacion son validas al
termino de esta investigacion, con lo que respecta ultimo aspecto de innovacion se
al
recalca que la tecnologa de Android es practicamente joven de no mas de 4 anos de
edad, por lo que se asienta que definitivamente es innovador el empleo de estas tecnolog
as en los sistemas de iluminacion eficiente.

4.7. Traba jos


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

Realizar a parte de una conexion va Bluetooth, realizar una conexion USB para
utilizar una PC como centro de mando.

Transmitir del Sistema receptor al transmisor los estados de cada Dimmer que se
estan controlando as como los porcentajes de iluminacion que se estan 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 codigo de programa para


tener un juego de dimmers internos.

Realizar dimmers que controlen la frecuencia, para trabajar con lamparas de


led directamente, sin necesidad de ser E27 ni adaptadas para poder ser reguladas
con
la tension de AC comun en casa.

Utilizar comando de voz para realizar las operaciones de intensidad lumnica m


ediate la herramienta bastante nueva de identificador por voz, que Android
desarrollo y que actualmente esta en espanol.
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, Espana, 2000.

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

Carlos A. Narvaez V., Regulacion de la Potencia Electrica Aplicaciones


Personales,
2002.

Assaf L. y Avellaneda de Wilde, M., 1985. Dispositivos electronicos 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 energetico en instalaciones a traves


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, Version 1.1, 22 de Febrero de 2003. Disponible en Internet:
URL: http://www.bluetooth.com/dev/sp ecifications.asp.
Bluetooth Special Interest Group., Bluetooth Profiles , Specification of the
Bluetooth System, Version 1.1, 22 de Febrero de 2003. Disponible en
Internet: URL: http:// www.blueto oth.com/dev/sp ecifications.asp.
Developer Android, 28 de Septiembre de 2011. Disponible en Internet: URL:
http://develop er.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# .
Pagina Oficial de Android, 05 de Noviembre de 2011. Disponible en Internet :
URL: http://www.android.com/.
Pagina Oficial para Desarrolladores en App Inventor con una cuenta de Google.
Disponible en Internet: URL: http://www.appinventorbeta.com/.
Apndice

99
100 APNDICE
110
PRUEBAS Y RESULTADOS
Editor de Bloques

":_htn 111 Screen1.fnttialize


do eeu

Notifier 1.ShowMessageDialog
titl
""' Advertencia

but'lonText
""' Ok

set 111 btnConnect.Enabled to false


set to false
btdintn1er.Enabled

... btonoff.Enabled
to
false

'" btacel.Enabled
to e false

'" AccelerorneterSensor1.E11abled to false

Elif numbe1
o
u
o.:ill txt glob.al OENiceMAC ~
length >

then-do
El ifelse
.... call Olddress gtob.ll DE!lllceMAC
Bluet oothClierrt1.lsOevicePaired

stt a lstD<Mce.Text to global OeviceMAC

'"El btnConnect.Enabled
to true

eree-ee
D < M c e M A C
to r'
' text
-......~.... : : :: : :: :: : ::::..~_-~"""'.""""'
eeu Notlfler 1.Sil ow Alert occe
text Saved DEMce Is not Paired

-......----~
Editor de Bloques

~ ID 9ToonnoctDcrYIOO : ?. - MAC:iddtof9TDC!'Yioo

D~
1.Coo.noct -1!-~. OluC!loothClicl!lt Old- c. ..... MAC:idd.rofOTOCl'Yioo
1

- .. r.- 1
-
bt.nConnoc:t. Tcuct OJS00t1noc:t
lJ'uo
(!

--
btot1off.tn~
~ true
btd........
.Cn.M>b:I 1

'""'"''"""""
1 .,.. ]
-....

- -e:-1
~
Not:iffclr1..ShowAWt DCYiooCoonoctod
1

JJ
-5-
~AC

11

~ 11 BToonnoetDCMOC

- ..
--
YCK1ti-notsokictodllDCMOOT0Connoctlo\ll

botonOQ,pn9

" BluC!looUiCllont 1.D"'1lnoct

-
btnConnoc::t..Tttld \.. Connoct

btd.t'm'OCll',[rn1bkid r. .....

-
btonoffLn~bkld .....
~
bt~En.lod .....
-- C'. .... 0CFYJOO D.i5oonnoc:tod
HOUfl..ShowAbt
Editor de Bloques

,,.- e -
- 21-----,-.----l
Mooo1

Button.29..Cltdt

- 21---.-.-'--~ Btuotoot.hCiicnt 1..SOOdTut R


-
- -
>

-
AoooklromotorSonsorlXA.ooot

- -
C:inwis31.B:ic:kgtoU.nclCob - e: Yo- 't- ButtooXl.Click

- -
~ OtuGtoothC'licmt
LSondText s

- BtuGtoothCliont LSondTut

.... 40 -
AoocdclromalocSon''IXA.ooo1
' 5~ u 'f-' btOolloffd.Clidt
Defin... l Text

BtuotoottiCliont 1.SOOclT Cid o

t- lJ tstDC'YIOCl:.Bef~ing
BtuctoothCflont l t-' btonoff.Clic*
Vortica! 1
-s-s
1.D.l$00llnoct

-
Art:ingornent1.~
1 " ''"' 1
--
- - e :-
1
1 C'1noct
-....

-
btnCon.noeL Tut Vort.:a!Art:ingornent2.Visii4c
"" 1
- - s-
-....
-....
-1
tstDcrwoct.Ocmont.s ~ ~
".l. Btuotootl'IClicmt l.Add.fOSSC!
BluotoothCllcnt 1.SOOdT ext
1
SAnd:N:irms
btdflwnclr.Clic:k
t- 1J tstO~ftorPiclnng 1 t-' 1

ff
- D~AC

- -e:'"" 1

"
..,.....,.,. 11
'- r, tst.O~ion
1 --
-
V~ngomont1.Vidc
Editor de Bloques
V~ngomontl.Vidc
--u t5t0Cl'Y'OO..Tut
-5~ DcMooMAC
1
~

5 1

-
BlucitoothCliont 1 ' 1
- ..
tn io

SondTClld

---'11 bt.nCot1.noc::t..to.:11>tcid
-e 1 "" 1 -....
94 PRUEBAS Y RESULTADOS
Cdigo
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); //verifcar 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 mximo
NotInTest = 3;
PercentOn = 0xd0; //periodo encendido
Maxdim = 0x70; //valor mximo 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++) //estabilizacin tensin
{
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) //Sincronizacin fase linea clrwdt();


TMR0 = PercentOn;
while(TMR0 >= 3 && LineInput == 0) //retardo entrada punto apropiado
clrwdt();
while(1)
{
Count = 0;
while(Count < DelayCnt) //Verifca pulsadores
{ //cada DelayCnt cruce por cero
Count += 1;
if(LineInput == 1) //si lnea AC esta en semiciclo
{ //positivo. incrementa Maxdin y
Maxdim +=15; //resincroniza con la lnea
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
#as
m
nop //Retardo disparo del triac nop
nop
nop
nop
nop
nop
#endas
m
W = 0x11; //RA4, entrada
TRISA = W; //Fin seal disparo triac
clrwdt();
if(LineInput == 0) //lnea AC en semiciclo negativo?
{
Maxdim +=15; //si es asi incrementa Maxdim while(LineInput
== 0); //y resincroniza con la lnea 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
#as
m
nop
nop //retardo seal disparo nop
nop
nop
nop
nop
#endasm
W = 0x11;
TRISA = W; //Fin seal 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--;
else
{ PercentOn--;
PercentOn--;

LastBoth = 0;
PercentOn = Maxdim;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
PercentOn--;
} PercentOn--;
PercentOn--;
} PercentOn--;
else
PercentOn--;
LastBoth = 0;
if(!Brtbut && Dimbut) //incrementa brillo
PercentOn++;
if(Brtbut && !Dimbut) //disminuye brillo
PercentOn--;

}
PRUEBAS Y RESULTADOS
Cdigo 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=0X0
7;
PORTD=0XF
F;
PORTE=0X0
7;

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;
}
}
}
}
PRUEB
AS 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
Applications
Postage stamp sized form factor, 13.4mm x
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) Industrial sensors and controls
data connection interfaces.
Medical devices
Sustained SPP data rates - 240Kbps (slave),
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 The RN41 is a small form factor, low power, highly
software stacks available. economic Bluetooth radio for OEMs 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
RFCOMM and L2CAP protocols, with SPP and 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
Rate (EDR), the RN41 delivers up to 3 Mbps data
Castellated SMT pads for easy and reliable rate for distances to 100M. Designers can easily
PCB mounting 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 dont want to spend significant time and
money developing Bluetooth specific hardware and
o Environmentally friendly, RoHS software.
compliant

Block Diagram

Crystal

VCC
GND
CSR BlueCore-04 PIO4
RF External PIO5
Switch PA BALUN
PIO6

USB
UART
PCM

Flash
Memory

809 University Avenue Los Gatos, CA 95032 Tel (408) 395-6539 info@RovingNetworks.com
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 info@RovingNetworks.com
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 info@RovingNetworks.com
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/Os (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 info@RovingNetworks.com
Module Dimensions

PCB LAYOUT MODULE DIMENSIONS


PAD SIZE = 0.8 X 1.30 mm

13.4 mm
mm

mm
3.2 mm
5.8 mm
2.0 mm
mm
3.3 mm 27 25
24
1 23
2
RN41 22 RN41 25.8 mm
3
4
21
20 15.4 mm RN41
5
6
19
18
RN41
13.2 mm
7
1.2 mm 17
8 16
9
15 Antenna
10
14
11 13
12 29 33 31 30
35 34 32 28
2.8 mm

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

809 University Avenue Los Gatos, CA 95032 Tel (408) 395-6539 info@RovingNetworks.com
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 info@RovingNetworks.com

You might also like