ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI)

DESARROLLO DE UN CONTROLADOR DOMOTICO X10

Autor: Roberto Gonzalez Celma Director: Juan Luis Zamora Macho

Madrid Julio 2014

DESARROLLO DE UN CONTROLADOR DOMOTICO X10

Roberto Gonzalez Celma

AUTORIZACIÓN PARA LA DIGITALIZACIÓN, DEPÓSITO Y DIVULGACIÓN EN ACCESO ABIERTO ( RESTRINGIDO) DE DOCUMENTACIÓN

1º. Declaración de la autoría y acreditación de la misma. El autor D. _____________________________________ , como _______________ de la UNIVERSIDAD PONTIFICIA COMILLAS (COMILLAS), DECLARA que es el titular de los derechos de propiedad intelectual, objeto de la presente cesión, en relación con la obra_________________________________________________________________________ _____________________________________________________________1, que ésta es una obra original, y que ostenta la condición de autor en el sentido que otorga la Ley de Propiedad Intelectual como titular único o cotitular de la obra. En caso de ser cotitular, el autor (firmante) declara asimismo que cuenta con el consentimiento de los restantes titulares para hacer la presente cesión. En caso de previa cesión a terceros de derechos de explotación de la obra, el autor declara que tiene la oportuna autorización de dichos titulares de derechos a los fines de esta cesión o bien que retiene la facultad de ceder estos derechos en la forma prevista en la presente cesión y así lo acredita. 2º. Objeto y fines de la cesión. Con el fin de dar la máxima difusión a la obra citada a través del Repositorio institucional de la Universidad y hacer posible su utilización de forma libre y gratuita ( con las limitaciones que más adelante se detallan) por todos los usuarios del repositorio y del portal e-ciencia, el autor CEDE a la Universidad Pontificia Comillas de forma gratuita y no exclusiva, por el máximo plazo legal y con ámbito universal, los derechos de digitalización, de archivo, de reproducción, de distribución, de comunicación pública, incluido el derecho de puesta a disposición electrónica, tal y como se describen en la Ley de Propiedad Intelectual. El derecho de transformación se cede a los únicos efectos de lo dispuesto en la letra (a) del apartado siguiente. 3º. Condiciones de la cesión. Sin perjuicio de la titularidad de la obra, que sigue correspondiendo a su autor, la cesión de derechos contemplada en esta licencia, el repositorio institucional podrá: 1

Especificar si es una tesis doctoral, proyecto fin de carrera, proyecto fin de Máster o cualquier otro trabajo que deba ser objeto de evaluación académica

1

(a) Transformarla para adaptarla a cualquier tecnología susceptible de incorporarla a internet; realizar adaptaciones para hacer posible la utilización de la obra en formatos electrónicos, así como incorporar metadatos para realizar el registro de la obra e incorporar “marcas de agua” o cualquier otro sistema de seguridad o de protección. (b) Reproducirla en un soporte digital para su incorporación a una base de datos electrónica, incluyendo el derecho de reproducir y almacenar la obra en servidores, a los efectos de garantizar su seguridad, conservación y preservar el formato. . (c) Comunicarla y ponerla a disposición del público a través de un archivo abierto institucional, accesible de modo libre y gratuito a través de internet.2 (d) Distribuir copias electrónicas de la obra a los usuarios en un soporte digital. 3

4º. Derechos del autor. El autor, en tanto que titular de una obra que cede con carácter no exclusivo a la Universidad por medio de su registro en el Repositorio Institucional tiene derecho a: a) A que la Universidad identifique claramente su nombre como el autor o propietario de los derechos del documento. b) Comunicar y dar publicidad a la obra en la versión que ceda y en otras posteriores a través de cualquier medio. c) Solicitar la retirada de la obra del repositorio por causa justificada. A tal fin deberá ponerse en contacto con el vicerrector/a de investigación ([email protected]). d) Autorizar expresamente a COMILLAS para, en su caso, realizar los trámites necesarios para la obtención del ISBN.

2

En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría redactado en los siguientes términos: (c) Comunicarla y ponerla a disposición del público a través de un archivo institucional, accesible de modo restringido, en los términos previstos en el Reglamento del Repositorio Institucional

3

En el supuesto de que el autor opte por el acceso restringido, este apartado quedaría eliminado.

2

d) Recibir notificación fehaciente de cualquier reclamación que puedan formular terceras personas en relación con la obra y, en particular, de reclamaciones relativas a los derechos de propiedad intelectual sobre ella. 5º. Deberes del autor. El autor se compromete a: a) Garantizar que el compromiso que adquiere mediante el presente escrito no infringe ningún derecho de terceros, ya sean de propiedad industrial, intelectual o cualquier otro. b) Garantizar que el contenido de las obras no atenta contra los derechos al honor, a la intimidad y a la imagen de terceros. c) Asumir toda reclamación o responsabilidad, incluyendo las indemnizaciones por daños, que pudieran ejercitarse contra la Universidad por terceros que vieran infringidos sus derechos e intereses a causa de la cesión. d) Asumir la responsabilidad en el caso de que las instituciones fueran condenadas por infracción de derechos derivada de las obras objeto de la cesión. 6º. Fines y funcionamiento del Repositorio Institucional. La obra se pondrá a disposición de los usuarios para que hagan de ella un uso justo y respetuoso con los derechos del autor, según lo permitido por la legislación aplicable, y con fines de estudio, investigación, o cualquier otro fin lícito. Con dicha finalidad, la Universidad asume los siguientes deberes y se reserva las siguientes facultades: a) Deberes del repositorio Institucional: - La Universidad informará a los usuarios del archivo sobre los usos permitidos, y no garantiza ni asume responsabilidad alguna por otras formas en que los usuarios hagan un uso posterior de las obras no conforme con la legislación vigente. El uso posterior, más allá de la copia privada, requerirá que se cite la fuente y se reconozca la autoría, que no se obtenga beneficio comercial, y que no se realicen obras derivadas. - La Universidad no revisará el contenido de las obras, que en todo caso permanecerá bajo la responsabilidad exclusiva del autor y no estará obligada a ejercitar acciones legales en nombre del autor en el supuesto de infracciones a derechos de propiedad intelectual derivados del depósito y archivo de las obras. El autor renuncia a cualquier reclamación frente a la Universidad por las formas no ajustadas a la legislación vigente en que los usuarios hagan uso de las obras. - La Universidad adoptará las medidas necesarias para la preservación de la obra en un futuro. 3

b) Derechos que se reserva el Repositorio institucional respecto de las obras en él registradas: - retirar la obra, previa notificación al autor, en supuestos suficientemente justificados, o en caso de reclamaciones de terceros.

Madrid, a ……….. de …………………………... de ……….

ACEPTA

Fdo……………………………………………………………

4

Desarrollo de un Controlador Domótico X10

--

González Celma, Roberto. Director de proyecto: Zamora Macho, Juan Luis.

Entidad Colaboradora: E.T.S.I. (ICAI).

RESUMEN DEL PROYECTO Tenemos la suerte de estar viviendo una época que seguramente se recordará como el comienzo de la era del “Internet of things” y de las “Smart grids” , conceptos que poco a poco van modelando un futuro hacia el que caminamos a grandes zancadas, en el que todo estará conectado, registrado y podrá controlarse. Si se quieren pruebas de que estamos contemplando el mencionado desarrollo tecnológico, sólo hay que fijarse en las empresas más rentables a nivel mundial, todas tienen una cosa en común, que se dedican al mundo de la electrónica de consumo y de internet. En los últimos años, varias nuevas categorías de productos de dichos campos nos han hecho estar cada vez más conectados, más “online”, los últimos de ellos, los Smartphones y las Smart TV, productos que ya sobradamente se han creado su mercado propio. Al ritmo que van las cosas, dentro de poco la lavadora también será “Smart”, la nevera, el lavaplatos, etc. Y así hasta que nuestras propias casas se vuelvan inteligentes, tema sobre el que trata el proyecto presentado en estas páginas. Las “Smart Home” o las casas que tienen un sistema domótico completo instalado, cuentan con una serie de sensores, actuadores e interfaces de usuario cuya actividad está gobernada por un Controlador, estructura que podemos apreciar en la siguiente figura:

Por lo tanto, el Controlador se presenta como el cerebro de cualquier sistema domótico, es el elemento que gestiona los datos y da las órdenes a los actuadores en base a las técnicas de control aplicadas. El propósito de este proyecto es el desarrollo de un Controlador domótico de tales características. Como ya se mencionó, la llegada de las casas automatizadas al gran público

se encuentra más cerca de lo que creemos, por lo que este proyecto brinda una gran oportunidad para trabajar e indagar sobre un tema tecnológico muy actual. Sin embargo, no debemos perder de vista que al mismo tiempo, este proyecto, como proyecto de fin de Grado, no deja de ser un trabajo académico cuyo principal objetivo es el aprendizaje; así que podemos afirmar coherentemente que las principales características de este proyecto debido a su carácter académico serán el bajo coste y la búsqueda de aprendizaje, prevaleciendo esta sobre otros posibles objetivos. El desarrollo del Controlador domótico de este proyecto se traduce en la programación del microcontrolador que actuará como tal. Dicha programación busca que el microcontrolador cuente con los drivers de comunicaciones necesarios para interactuar con sus respectivos sensores y actuadores, y al mismo tiempo, el micro tiene también programadas las técnicas de control necesarias para dar las órdenes adecuadas a los actuadores. El sistema domótico elaborado para este proyecto con el microcontrolador como cerebro, tiene como sensores medidores de temperatura, y como actuadores radiadores eléctricos para controlar la temperatura. Por lo tanto, los drivers de comunicaciones programados permitirán al microcontrolador leer la temperatura en tiempo real y actuar en consecuencia para controlarla.

Microcontrolador

Actuador

Sistema térmico (estancia)

Sensor

En la elección del equipo se ha intentado seguir la filosofía expuesta del bajo coste. Ello se hace patente en la elección del microcontrolador a programar y en la elección del protocolo de comunicaciones que sincronizará al controlador y a los actuadores. El Arduino Mega 2560 se eligió como microcontrolador a programar. Arduino ya es de sobra famoso por el hardware libre que elabora y por la gran comunidad de usuarios que lo respalda, algo que resulta de gran ayuda en los momentos de bloqueo que surgen a lo largo del proyecto, pues siempre hay algún artículo o foro en el que investigar. A su vez el Arduino Mega 2560 se encuentra entre el hardware de bajo coste para el que Simulink cuenta con librerías. Esto último resulta muy útil ya que en este proyecto el sistema

domótico se diseña a través de bloques de Simulink, de manera que las tareas que giren en torno al mismo concepto se encapsulan en un bloque de Simulink. Ello nos permite que una vez el sistema este completado, sea Simulink el que se encargue de compilar y cargar el código en el microcontrolador, de manera que no debemos preocuparnos excesivamente por el código de bajo nivel embebido en el microcontrolador. Por último, mencionar que se eligió el Arduino Mega 2560 en detrimento del Arduino Uno debido a que el Arduino Mega es un micro que cuenta con una mayor memoria de programa y un mayor número de puertos. Respecto al protocolo de comunicaciones entre micro y actuadores, se eligió el protocolo X10 por contar con algunos de los dispositivos más baratos del mercado y porque actualmente en el mundo de la domótica sigue siendo de los protocolos más usados, sino el que más. El protocolo X10 permite la comunicación entre el Controlador y sus actuadores a través del cableado de la red eléctrica existente en cualquier vivienda, es decir, aprovecha la instalación eléctrica ya disponible para enviar información mediante pequeños pulsos de 120 Khz que representan las tramas de bits. La información digital o las tramas de bits constituyen las órdenes que el micro envía a sus actuadores, los cuales deben estar conectados a dispositivos receptores capaces de interpretar el protocolo X10. Dichos receptores, que se conectan a la red eléctrica de la vivienda, cuentan con un detector de paso por cero capaz de apreciar con cierta holgura el momento en que la senoidal de 50 hz del cableado eléctrico alterna su valor positivo con el negativo o al revés. Según el protocolo X10, es en esos momentos cuando se debe detectar la presencia o ausencia del pulso de 120 Khz. Su interpretación nos lleva a obtener la trama de bits. El protocolo X10 define el 1 y el 0 binarios como se aprecia en la siguiente imagen:

Actualmente existen otros protocolos de comunicaciones utilizados en entornos domóticos que no requieren la realización de obras para su uso, tanto del tipo que aprovechan la red eléctrica como del tipo que funcionan por radiofrecuencia. En la RF tenemos algunos como Zigbee o Z-wave, pero quizá el protocolo denominado INSTEON sea el que se esté

imponiendo, al combinar red eléctrica y RF. El protocolo INSTEON resuelve varios de los problemas de fiabilidad que el X10 muestra en algunos casos, pues es común que aparezcan problemas de atenuación cuando el receptor se encuentra muy lejos del emisor X10. Aun así, dado el carácter académico de este proyecto, el X10 se presenta como la mejor alternativa en términos económico como ya hemos remarcado. Además otro punto a su favor, es que la comunidad de Arduino ya contaba con librerías testadas que garantizaban su buen funcionamiento con el microcontrolador elegido. Las librerías del X10 mencionadas sólo abarcaban la parte cableada del protocolo (red électrica), las librerías para RF, opción de recepción con la que actualmente también cuenta el X10, fueron realizadas por el proyectista.

El sensor de temperatura usado en el proyecto es un sensor de interiores de la empresa Oregon Scientific, en concreto, el Oregon Scientific THGR810. El sensor mide temperatura y humedad, aunque la lectura que nos interesa es la de temperatura.

El sensor utiliza un protocolo OOK (on-off-keying) con una codificación Manchester para transmitir por radiofrecuencia una trama de bits que contiene la información de la temperatura. La onda portadora de la RF es de 433.92 Mhz, la misma que en la RF del X10, ya que es uno de los estándares europeos en RF. Existen diferentes versiones del protocolo utilizado por este tipo de sensores Oregon, el sensor del proyecto usa el Oregon 3.0. El protocolo del sensor exigió la programación de otro driver de comunicación para decodificar la transmisión RF del Oregon; de esta manera, el microcontrolador puede a través de un receptor RF de 433 Mhz leer la temperatura en tiempo real. Llegados a este punto, es fácil apreciar que los drivers de comunicaciones se llevan la mayor parte de programación en este proyecto. Como se ha podido observar, se necesitaron principalmente tres drivers:  Driver Oregon 3.0  Driver X10 cableado  Driver X10 RF

Cada uno de estos drivers se traduce en un bloque de Simulink cuyas características han sido personalizadas, a este tipo de bloques se les suele denominar en dicho entorno DriverBlocks. Simulink nos permite agrupar los distintos drivers y elaborar los controles que deseemos para interactuar con ellos. Luego, gracias a la librería de Simuliunk para el Arduino Mega 2560 mencionada, sólo tenemos que cargar el programa compilador por Simulink en el micro para ver nuestro modelo domótico en funcionamiento. El modo externo de Simulink nos permite probar nuestros modelos en tiempo real. Para finalizar, de cara a clarificar la estructura del modelo domótico realizado, se adjunta una figura descriptiva del mismo: Fase

Neutro

433 Mhz

EMISOR COMANDOS X10

Arduino Mega 2560

Receptor RF

Oregon Sensor de temperatura

Emisor RF

433 Mhz

Rele

TM13 Receptor RF X10 Radiador

Como se ha expuesto, el micro puede enviar sus órdenes por cable a través de la red eléctrica o por radiofrecuencia. A su vez, el micro sólo recibe información por radiofrecuencia; aunque, si dispusiéramos de sensores que incorporaran el protocolo X10, la librería insertada en el driver de comunicación X10 también permite la recepción de comandos X10, es decir, el micro podría leer la información digital entregada por ese sensor.

Project Summary We are fortunate to be living in a time that will surely be remembered as the beginning of the era of the "Internet of things" and "Smart Grids", concepts that are slowly shaping a future toward which walked with long strides in that everything will be connected, registered and can be controlled. If you are looking at evidence that the above mentioned technological development they want, only to focus on the most profitable companies in the world, they all have one thing in common, they are devoted to the world of consumer electronics and the Internet. In recent years, several new product categories such fields have us be ever more connected, more "online", the last of them, Smartphones and Smart TV products that are already well established its own market. At the rate things are going, soon the machine will also be "Smart" refrigerator, dishwasher, etc.. And so to our own homes become intelligent subject on which the project is presented in these pages. The "Smart Home" or houses which have a complete home automation system installed, have a number of sensors, actuators and user interfaces whose activity is governed by a controller structure that we see in the following figure:

Therefore, the controller is presented as the brain of any automation system, it is the element that manages the data and gives orders to the actuators based on the techniques of applied control. The purpose of this project is to develop a home automation controller such features. As already mentioned, the arrival of the automated public houses is closer than we think, so this project provides a great opportunity to work and investigate a current technological

issue. However, we must not forget that while this draft, draft final project, it remains an academic paper whose main objective is learning; so we can say consistently that the main features of this project because of its academic nature will be the low cost and the pursuit of learning, this prevailing over other potential targets. The development of this project automation controller results in programming the microcontroller to act as such. This program seeks to tell the microcontroller with the communications necessary drivers to interact with their respective sensors and actuators, and at the same time, the micro has also programmed control techniques necessary to give appropriate orders to the actuators. The automation system developed for this project with the microcontroller as the brain, is measuring temperature sensors, and actuators such as electric heaters to control the temperature. Therefore, scheduled communications drivers allow the microcontroller to read the temperature in real time and to control it to act accordingly.

Microcontrolador

Actuador

Sistema térmico (estancia)

Sensor

In choosing the team has tried to follow the philosophy of low cost exposed. This is evident in the choice of microcontroller programming and choice of communication protocol to synchronize the controller and the actuators. The Arduino Mega 2560 microcontroller was chosen as programming. Arduino is already famous for spare hardware that makes the free and the large user community that supports it, which is a great help in times of lock that arise throughout the project, for there is always an article or forum to investigate. In turn, the Arduino Mega 2560 is among the low-cost hardware which has Simulink libraries. The latter is useful in this project because the automation system is designed by Simulink blocks, so that tasks that revolve around the same concept is encapsulated in a Simulink block. This allows us that once the system is completed, whether Simulink which is responsible to compile and load the code into the microcontroller, so we should not overly worry about the low-level code embedded in the microcontroller.

Finally, note that the Arduino Mega 2560 was elected to the detriment of the Arduino Uno because the Arduino Mega is a micro that has a larger program memory and a larger number of ports.

Regarding the communication protocol between micro-actuator, the X10 protocol was chosen because it has some of the cheapest devices in the market and because currently in the world of home automation is still the most commonly used protocols, but the most. The X10 protocol allows communication between the controller and the actuators through the wiring of the mains voltage in any house, i.e. it uses the wiring already available to send information by small pulses of 120 Khz representing bit patterns. The digital information bits or frames are the orders that sent his micro actuators, which must be connected to receiving devices able to interpret the X10 protocol. These receptors, which are connected to the mains of the house, have a zero crossing detector able to appreciate some slack when the sine of 50 Hz alternating electrical wiring of your positive value to negative or vice versa. According to the X10 protocol is in those moments when to detect the presence or absence of pulse 120 kHz. His interpretation leads us to get the bitstream. The X10 protocol defines the binary 1 and 0 as shown in the following image:

Currently there are other communications protocols used in automation environments that do not require the use of works for both the type that leverage the power grid as the type operated by radio frequency. In the RF have some as Zigbee or Z-wave, but perhaps the INSTEON protocol called than the one being imposed by combining grid and RF. The INSTEON protocol solves many of the reliability issues that the X10 shown in some cases, it is common for attenuation problems appear when the receiver is far from the X10 transmitter. Still, given the academic nature of this project, the X10 is presented as the best alternative in economic terms as already remarked. Also another point in its favor is that the community of Arduino libraries already had tested guaranteeing smooth operation with the microcontroller chosen. The X10 libraries mentioned only covered the wired part of the

protocol (mains), libraries for RF reception option which now also has the X10, were made by the designer.

The temperature sensor used in the project is a sensor inside the company Oregon Scientific, namely, the Oregon Scientific THGR810. The sensor measures temperature and humidity, though the reading that interests us is the temperature.

The sensor uses a OOK (on-off-keying) Manchester coding protocol with a radio frequency to transmit a frame of bits that contains the temperature information. The RF carrier wave is 433.92 MHz, the same as the X10 RF because it is one of Europe standards in RF. There are different versions of the protocol used by this type of Oregon sensors; the sensor uses the Oregon Project 3.0. The protocol required sensor scheduling another communication driver to decode the RF transmission of Oregon; in this way, the microcontroller can through an RF receiver 433 Mhz read real time temperature.

At this point, it is easy to see that the communication drivers most programming takes on this project. As has been observed, mainly needed three drivers:  Driver Oregon 3.0  Driver X10 wiring  Driver RF X10

Each of these drivers results in a Simulink block whose characteristics have been customized; such blocks are often called Driver-Blocks in that environment.

Simulink allows us to group the various drivers and develop controls that we want to interact with them. Then, thanks to the library for the Arduino Mega Simuliunk 2560 mentioned, we only have to load the compiler program in Simulink micro automation to see our working model. Simulink external mode allows us to test our models in real time.

Finally, in order to clarify the structure of the automation model created, you attach a descriptive figure of the same: Fase

Neutro

433 Mhz

EMISOR COMANDOS X10

Arduino Mega 2560

Receptor RF

Oregon Sensor de temperatura

Emisor RF

433 Mhz

Rele

TM13 Receptor RF X10 Radiador

As discussed, the micro can send your orders by wire through the mains or by radio frequency. In turn, the microprocessor receives information only ablation; though, if we had sensors that incorporate the X10 protocol, the library inserted into the communication driver X10 also allows receiving X10 commands, i.e. the micro could read the digital information provided by the sensor.

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

ÍNDICE DE LA MEMORIA

Índice de la memoria

Parte I

Memoria .......................................................................................... 2

Capítulo 1

Introducción ................................................................................... 3

1.1

Estado de la Cuestión: ..................................................................................... 4

1.2

Motivación: .................................................................................................... 14

Capítulo 2

Desarrollo y recursos .................................................................... 15

2.1

Objetivos del proyecto: ................................................................................. 15

2.2

Metodología de trabajo ................................................................................. 16

2.3

Recursos a emplear: ...................................................................................... 16

Capítulo 3

SIMULINK ................................................................................... 18

3.1

Entorno de simulación conocido .................................................................. 18

3.2

Run on target hardware................................................................................ 19

Capítulo 4

ARDUINO..................................................................................... 20

4.1

Contexto Arduino: ......................................................................................... 20

4.2

Historia reciente Arduino: ............................................................................ 22

4.3

AVR: ............................................................................................................... 23

4.4

Arduino mega 2560 ....................................................................................... 23

4.4.1 Alimentación y memoria: ............................................................................................. 25 4.4.2 Input y output: .............................................................................................................. 27 4.4.3 Comunicación: ............................................................................................................. 30 4.4.4 Programación: .............................................................................................................. 31

Capítulo 5

DRIVER-BLOCK ......................................................................... 33

I

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

ÍNDICE DE LA MEMORIA 5.1

Tipos de driver blocks:.................................................................................. 35

5.2

Pestañas más importantes de cara a escribir el código C del bloque: ...... 37

5.3

Ejecutables creados por el bloque al darle a build: .................................... 41

5.4

Simulación vs ejecución en hardware: ........................................................ 43

Capítulo 6

Oregon........................................................................................... 46

6.1

Especificaciones técnicas ............................................................................... 46

6.2

Decodificando el oregon 3.0 .......................................................................... 47

6.2.1 I'm OOK. You're OOK? ............................................................................................... 48 6.2.2 Codificación manchester .............................................................................................. 49 6.2.3 Protocolo Oregon versión 3.0 ...................................................................................... 50

Capítulo 7

X10 ................................................................................................ 52

7.1

Historia del x10:............................................................................................. 52

7.2

Tecnología X10: ............................................................................................. 58

7.3

Estructura de las tramas de bits: ................................................................. 63

7.4

Enfoque trifásico: .......................................................................................... 68

7.5

Resumen códigos X10: .................................................................................. 70

7.6

X10 RF ............................................................................................................ 71

Capítulo 8 8.1

Resultados ..................................................................................... 73

Los tres Driver-blocks ................................................................................... 73

8.1.1 Driver-block Oregon .................................................................................................... 73 8.1.2 Driver-Block X10 ........................................................................................................ 74 8.1.3 Driver-Block X10 RF ................................................................................................... 75

8.2

Display oregon ............................................................................................... 76

8.3

Capturas osciloscopio x10 rf ......................................................................... 76

8.3.1 cero binario .................................................................................................................. 77 8.3.2 uno binario ................................................................................................................... 78 8.3.3 inicio trama .................................................................................................................. 79 8.3.4 Silencio de inicio de trama ........................................................................................... 80

Capítulo 9

Componentes hardware ................................................................ 81 II

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

ÍNDICE DE LA MEMORIA Capítulo 10

Futuros desarrollos ...................................................................... 91

10.1

Driver-block oregon ...................................................................................... 91

10.2

SPI ................................................................................................................... 91

Bibliografía 92 Parte II

Estudio económico........................................................................ 94

Capítulo 1

Estudio económico........................................................................ 95

Parte III

Código fuente ................................................................................ 98

Capítulo 1

Oregon......................................................................................... 100

1.1

Osv3decoder.h.............................................................................................. 100

1.2

osv3decoder.cpp ........................................................................................... 101

Capítulo 2

X10 .............................................................................................. 104

2.1

x10.h .............................................................................................................. 104

2.2

x10constants.h .............................................................................................. 105

2.3

x10.cpp .......................................................................................................... 106

Capítulo 3

x10 RF ......................................................................................... 115

3.1

x10rf.h........................................................................................................... 115

3.2

x10rfconstants.h ........................................................................................... 115

3.3

x10rf.cpp....................................................................................................... 116

Parte IV

Planos .......................................................................................... 118

Capítulo 1

planos explicativos ...................................................................... 119

1.1

Arquitectura general sistema domótico..................................................... 119

1.2

Conexiones pines Arduino .......................................................................... 120

Parte V

Datasheets ................................................................................... 121

Capítulo 1

Datasheet 1.................................................................................. 122

1.1

OREGON Thermo-Hygro .......................................................................... 122

III

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

ÍNDICE DE LA MEMORIA 1.2

MARMITEK CM11 .................................................................................... 124

1.3

MARMITEK XM10FL ............................................................................... 126

1.4

MARMITEK Transceiver Module ............................................................ 126

1.5

marmitek appliance module ....................................................................... 128

1.6

Marmitek lamp module .............................................................................. 130

1.7

Arduino mega .............................................................................................. 132

1.8

Cebek emisor c-0503 ................................................................................... 132

1.9

CEBEK receptor C-0504N.......................................................................... 133

1.10

LCD keypad ................................................................................................. 134

IV

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

ÍNDICE DE FIGURAS

Índice de figuras Ilustración 1: Funciones del sistema domótico (Web) Ilustración 2: Esquema de dispositivos integrados (Web) Ilustración 3: Termostato inteligente Nest (Web) Ilustración 4; Detector de humos Nest (Web) Ilustración 5: Hub domótico Revolv (Web) Ilustración 6: Belkin WeMo (Web) Ilustración 7: AT&T Digital (Web) Ilustración 8: ADT Pulse Ilustración 9: Savant SmartSystems (Web) Ilustración 10: Vista placa ARDUINO (Web) Ilustración 11: Vista placa ARDUINO MEGA (Web) Ilustración 12: Esquema I/O ARDUINO (Web) Ilustración 13: Esquema conexiones pull-up y pull-down (Web) Ilustración 14: HardCopy programación ARDUINO Ilustración 15: Bloque programación SIMULINK Ilustración 16: HardCopy interfaz programación SIMULINK Ilustración 17: HardCopy tipos de Driver.Blocks en SIMULINK Ilustración 18: Activación del tiempo de muestreo en SIMULINK Ilustración 19: SIMULINKSolapa DiscreteUpdate Ilustración 20 SIMULINKSolapa Outputs Ilustración 21 SIMULINKSolapa Libraries

V

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

ÍNDICE DE FIGURAS Ilustración 22: Sketch (ARDUINO) vs Drivers-Block (SIMULINK) (Web) Ilustración 23: SIMULINK Solapa Build Info Ilustración 22: Sketch (ARDUINO) vs Drivers-Block (SIMULINK) (Web) Ilustración 23: SIMULINK Solapa Build Info Ilustración 28: Empresa “Pico Electronics Ltd” en Escocia (Web) Ilustración 29:Portada de la revista Radio Electronics de 1980 (Web) Ilustración 30: Articulo de la revista Radio Electronics (Web) Ilustración 31: Articulo de la revista Radio Electronics (gráfico) (Web) Ilustración 32: Articulo de la revista Radio Electronics (gráfico y texto I) (Web) Ilustración 34: Articulo de la revista Radio Electronics (gráfico y texto III) (Web) Ilustración 35:Sincronización de los módulos X10 (Web) Ilustración 36: Ventana de búsqueda de señal (Web) Ilustración 37: Gráfico de pulso y holgura (Web) Ilustración 35:Sincronización de los módulos X10 (Web) Ilustración 36: Ventana de búsqueda de señal (Web) Ilustración 37: Gráfico de pulso y holgura (Web) Ilustración 38: Holgura máxima de 200 microsegundos (Web) Ilustración 39: Gráfico de presencias y ausencias de pulsos (Web) Ilustración 40: Patron de inicio de trama X10 (Web) Ilustración 41: Ejemplo de niblle (Web) Ilustración 42: Direccionamiento dispositivos X10 (Web) Ilustración 43: Las tramas se envían dos veces en el estándar X10 (Web) Ilustración 44: 6 ceros limpios entre tramas con distinto contenido (Web) Ilustración 45: Nibble de comando y código binario típico (Web) Ilustración 46: Envío duplicado de tramas (Web) Ilustración 47: Comando “All-Lights-ON” (Web) Ilustración 49: Envío de 3 pulsos – continuación- (Web)

VI

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

ÍNDICE DE FIGURAS Ilustración 50: Tabla de direcciones y comandos X10 (Web) Ilustración 51: Tabla de direcciones y comandos X10 – detalle (Web) Ilustración 61: OREGON Thermo-Hygro Ilustración 62: MARMITEX Transceiver Module y Mando a distancia Ilustración 64: MARMITEK CM11 y XM10FL Ilustración 65: MARMITEK CM11 y XM10FL (parte posterior) Ilustración 66MARMITEK Appliance Module Ilustración 67: MARMITEK Lamp Module Ilustración 69: Placa ARDUINO MEGA y LCD Keypad Ilustración 70: CEBEK emisor (C-0503) y receptor (C-0504N)

VII

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

INDICE DE TABLAS

Índice de tablas

Tabla 1: Comparativa de las principales tecnologías (Web) Tabla 2: Comparativa del resto de tecnologías (Web) Tabla 3: Características técnicas ARDUINO Tabla 4: Valores Bit Función

-1-

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Parte I MEMORIA

-2-

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 1 INTRODUCCIÓN Tenemos la suerte de estar viviendo una época que seguramente se recordará como el comienzo de la era del “Internet of things” [1] y de las “Smart grids” [2], conceptos que poco a poco van modelando un futuro hacia el que caminamos a grandes zancadas, en el que todo estará conectado, registrado y podrá controlarse.

Si se quieren pruebas de que estamos contemplando el mencionado desarrollo tecnológico, sólo hay que fijarse en las empresas más rentables a nivel mundial, todas tienen una cosa en común, que se dedican al mundo de la electrónica de consumo y de internet [3]. En los últimos años, varias nuevas categorías de productos de dichos campos nos han hecho estar cada vez más conectados, más “online”, los últimos de ellos, los Smartphones y las Smart TV, productos que ya sobradamente se han creado su mercado propio. Al ritmo que van las cosas, dentro de poco la lavadora también será “Smart”, la nevera, el lavaplatos, etc. Y así hasta que nuestras propias casas se vuelvan inteligentes, tema sobre el que trata el proyecto presentado en estas páginas.

Nuestras industrias ya están de sobra automatizadas, pero dicha automatización, a la par que eficaz, también es muy costosa; por lo tanto es normal que tales gastos sólo los asuma una empresa que sabe que se rentabilizaran. Según esto, por qué motivo alguien querría automatizar su casa?

Pues por el mismo motivo que usa un Smartphone, porque hace su vida más cómoda. Pero claro, para ello, como pasó con estos teléfonos en su momento, los sistemas de control domóticos tendrían que abaratarse y facilitar su implementación y uso.

-3-

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO Conociendo nuestro mercado actual, sabemos que los productos domóticos no son ningún producto “mainstream” como pueden ser los Iphones de Apple o los Android de Google; sin embargo, en los últimos días, la mencionada Google ha comprado una empresa por 3.2 billones de dólares que se dedica precisamente a hacer termostatos y detectores de humo inteligentes (y cuando digo inteligentes me refiero a conectados a internet y con capacidad de control) [4]. Parece que una nueva categoría de mercado aparecerá en la electrónica de consumo en poco tiempo, y las empresas se están preparando para ofrecer con ella todo un ecosistema de productos. De esa categoría, que podemos denominar “Smart home”, los controladores domóticos serán los productos más importantes sobre los que se desarrollarán los demás.

Este proyecto tiene el objetivo de llevar a cabo uno de esos controladores, con el bajo coste y la fácil implementación como sus principales características, algo que hoy en día todavía no podemos encontrar en el mercado.

1.1 ESTADO DE LA CUESTIÓN:

El conjunto de técnicas y conocimientos hasta ahora desarrollados con el fin de automatizar nuestros hogares se engloban bajo el concepto conocido como “domótica”, que en el mundo anglosajón se conoce como “home automation”. El origen etimológico de la palabra “domótica” resulta interesante de conocer pues clarifica el concepto: la palabra procede de la unión de “domus”, que significa casa en latín, y tica, de automática, palabra griega que significa que algo funciona por sí solo [5].

Las funcionalidades principales de un sistema domótico se pueden agrupar en 4: Confort, Seguridad, Comunicaciones y Gestión energética.

-4-

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 1: Funciones del sistema domótico (Web)

Los sistemas domóticos aportan confort permitiendo el control de la iluminación, de la climatización, de los electrodomésticos y otros aparatos presentes en nuestra vida diaria que se encuentran conectados a la red eléctrica de la casa.

A su vez los sistemas domóticos también son capaces de controlar tanto las alarmas de intrusión como las alarmas de fallo técnico (detectores de humo, detectores de gas, escapes de agua, etc.), permitiendo así un control global e integrado de la seguridad de la propia casa como de sus habitantes.

La instalación de un sistema domótico permite una monitorización constante de nuestros hábitos energéticos, y aunque no siempre es un objetivo inherente al sistema, lo cierto es que la domótica puede llevarnos a un ahorro energético al darnos el poder de planificar nuestro consumo.

Como ya hemos mencionado, hoy en día cada vez tenemos más aparatos que nos permiten estar más conectados a la red de redes, algo especialmente apreciable en el campo de la multimedia. Un sistema domótico puede convertirse en nuestra manera de centralizar todas esas conexiones, gestionando la distribución de todo tipo de ficheros entre nuestros distintos dispositivos electrónicos. Además los sistemas domóticos actuales siempre cuentan con unas comunicaciones que nos

-5-

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO permiten controlarlos desde distintas interfaces digitales y a distancia, es decir, por poner un ejemplo, podríamos revisar la iluminación o temperatura de nuestra casa desde nuestro Smartphone o desde una página web mientras estamos en la oficina.

El uso de la domótica en los hogares actuales puede ir desde el uso de un único dispositivo domótico para controlar una determinada tarea (como un termostato inteligente o un control de iluminación), hasta un sistema domótico completo. Estos últimos suelen estar integrados por los siguientes dispositivos: Controladores, Actuadores, Sensores, Bus de Comunicaciones e Interfaces. En el siguiente esquema puede apreciar cómo se estructuran los mismos:

Ilustración 2: Esquema de dispositivos integrados (Web)

El cerebro del sistema viene a ser el controlador, y este proyecto tiene como objetivo principal desarrollar uno de ellos a la par que se gestionan los protocolos

-6-

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO de comunicación entre dicho controlador y sus actuadores y sensores. La gestión de la interfaz del sistema domótico con el usuario queda a cargo de otro proyecto desarrollado paralelamente al proyecto de controlador domótico que aquí se está presentando.

Terminada la breve definición de sistema domótico, repasemos también brevemente su desarrollo histórico.

Las primeras noticias que tenemos de un proyecto domótico llevado acabo datan de 1966, donde un ingeniero de la Westinghouse Electric llamado Jim Sutherland desarrollo un sistema de automatización del hogar llamado “ECHO IV”. El proyecto aunque de gran calidad nunca llegó a comercializarse debido a sus altos costes. Por lo tanto el desarrollo de los sistemas domóticos, como en un principio pasó con los ordenadores personales, quedó a cargo de entusiastas que trabajaban en ello como hobby. No sería hasta 1975 cuando se dio un gran avance en el campo de la domótica al aparecer el estándar X10, un protocolo que hoy en día sigue siendo el usado en las casas consideradas automatizadas.

A pesar del éxito que ha tenido el X10 y sigue teniendo, los productos desarrollados bajo este protocolo no tienen nada que hacer con otros productos de la electrónica de consumo como los Smartphone o las Smart TV, en términos de volumen de mercado y posibles compradores. Quizá, esto se deba a que la mayoría de los hogares que cuentan con sistemas domóticos hoy en día, son las casas de entusiastas que se han servido de la fácil implementación del X10 para automatizarlas sin tener que hacer ningún tipo de obra, tan sólo sirviéndose de la ya existente red eléctrica. Dicho esto, es fácil entender que los productos domóticos todavía no son para el gran público, pero como ya mencioné al situar el contexto de este proyecto, esto está cambiando rápidamente, y ya sea porque las empresas buscan beneficios monopolizando una nueva categoría de mercado, o porque los gobiernos empiecen a subvencionar o a impulsar este tipo de

-7-

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO tecnologías (ya que las casas automatizadas suponen un gran ahorro de energía a sus propietarios), parece que la era de las “Smart home” cada vez está más cerca.

Descrita brevemente la situación histórica de la domótica, vamos a hacer también un breve inventario de las principales tecnologías domóticas de comunicación y de las soluciones que actualmente nos ofrecen las empresas del sector cuando les preguntamos por un controlador domótico.

Hemos hablado del X10, pues es el estándar domótico que se usará en este proyecto y el que más años lleva en activo. Sin embargo el X10 no está libre de problemas, y esta situación ha hecho que surgieran otras iniciativas privadas que intentarán dar con el estándar domótico universal. Todavía ninguna de estas tecnologías prevalece sobre las demás y cada una tiene sus propios nichos de mercado (por ejemplo el X10 es más para quien se instala su propio sistema, INSTEON y Z-Wave son más usados en la instalación profesional). Esta situación es otra de las lacras que arrastra la industria de la domótica, pues el carecer de un estándar de facto para cualquier instalación no ayuda al desarrollo del mercado de los productos domóticos.

A continuación se referencia una tabla comparativa de las mencionadas tecnologías,

su

realización

pertenece

al

“learning

center”

de

www.Smarthome.com, una de las webs líderes en la compra de artículos domóticos [6].

-8-

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Tabla 1: Comparativa de las principales tecnologías (Web)

Tabla 2: Comparativa del resto de tecnologías (Web)

Como ya habrá apreciado, a la hora de instalar productos domóticos en nuestra casa, tenemos dos opciones, hacerlo nosotros mismos (DIY, el llamado “Do it yourself”) o llamar a unos profesionales. Por supuesto, la primera opción hoy en día sigue siendo la más popular por ser mucho más bajo su coste. A continuación se presentan los principales controladores que nosotros mismos podemos instalar:

-9-

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO 

Termostato inteligente de Nest:

Ilustración 3: Termostato inteligente Nest (Web)

Quizá actualmente el producto domótico más famoso debido a la repercusión mediática que ha tenido la compra por parte Google de la empresa Nest. Se dice de él que es un producto artístico digital capaz de controlar la temperatura de tu casa, algo entendible si sabemos que fue diseñado por las personas que crearon el Ipod de Apple. Tiene una tarjeta WI-FI de red, por lo que nos permite controlar la temperatura desde nuestro Smartphone, PC o Tablet. Su precio es de 250 $. 

Detector de humos y monóxido de carbono de Nest:

Ilustración 4; Detector de humos Nest (Web)

Producto de la misma empresa con un precio de 129 $. La interacción con el detector se realiza a través de un software instalado en nuestro teléfono. - 10 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO 

Hub domótico de Revolv:

Ilustración 5: Hub domótico Revolv (Web)

Hemos señalado que el protocolo X10 es el estándar más extendido en los productos domóticos, pero existen muchos otros como ZigBee, Z-Wave, Insteon o el propio WI-FI. Esto a veces es problemático pues aunque el X10 sea el dominante no siempre es el más adecuado. Revolv pretende resolver el problema con un Hub capaz de entender y distribuir señales de múltiples protocolos. Además cuenta con un app para Smart pone, y su precio es de 299$. 

Belkin WeMo:

Ilustración 6: Belkin WeMo (Web)

- 11 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Belkin ha desarrollado una línea de productos llamada WeMo que utiliza el WI-FI para comunicarse. Ofrece interruptores de luz por 50$, sensores de movimiento por 80$, controladores por 50$ y hasta monitores de cuidado de bebes por 80$; todo ello pudiéndose controlar desde un app instalada en tu Smartphone.

Ahora, hablemos un poco de los controladores que nos instalaría un profesional: 

AT&T Digital life:

Ilustración 7: AT&T Digital (Web)

El gigante de telecomunicaciones americano lleva ofreciendo en unas pocas ciudades desde el año pasado un servicio de instalación llamado “Digital Life”. La instalación consiste en terminales y paneles de control para la monitorización de tu casa, así como de una alarma de seguridad, todo ello por 150$. A ese coste habría que añadir 30$ al mes por contar con el servicio de monitorización, o 40$ si además queremos monitorizar la casa desde nuestro Tablet, teléfono o PC.

Además ofrece paquetes adicionales para la instalación de cámaras, controladores de energía eléctrica y de agua. 

ADT Pulse:

- 12 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 8: ADT Pulse

ADT es una empresa líder en seguridad del hogar que ofrece un servicio denominado “Pulse”. Resulta destacable, porque su servicio ya no se limita sólo a la monitorización de nuestra casa para seguridad, sino que también ofrece control, permitiéndonos cosas como activar o desactivar la alarma o controlar el termostato. Sus sistemas están basados en el protocolo Z-Wave. 

Savant SmartSystems:

Ilustración 9: Savant SmartSystems (Web)

Destaco esta empresa por ser una de las que pertenece a la categoría de lujo en el sector de la domótica. Sus productos son de gran calidad y muy fáciles de usar, pero con un precio de instalación muy elevado en comparación con el ofrecido por el resto de empresas comentadas. De hecho, esta empresa se hizo famosa por

- 13 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO implementar sistemas domóticos en casas de lujo tan sólo controlados desde productos de Apple.

1.2 MOTIVACIÓN:

Recordando el apartado anterior, vemos que la diversidad de ofertas en el mercado de la domótica no es poca, y muchas empresas tienen su porción de tarta: empresas de electrónica, empresas de automatización, empresas de domótica, empresas de telecomunicaciones, empresas de seguridad, empresas de internet, y así un largo etc. Sin embargo por qué este sector todavía no cuenta con la rentabilidad que otros sectores de la electrónica de consumo sí demuestran.

Si revisa las ofertas de productos descritos, todas tienen uno de estos dos defectos: coste excesivo o implementación no apta para el gran público. Así que si esta industria quiere prosperar para entrar en las casas de todos nosotros, uno de los pasos lógicos sería tender al desarrollo de sistemas domóticos de bajo coste e interfaz amigable para el usuario común de Smartphone y ordenadores. Hacia estas líneas de desarrollo tiende nuestro proyecto, que parte de la idea de llevar a cabo un controlador de bajo coste acompañado de un sistema que pueda instalarse en cualquier casa que cuente con una red eléctrica; pues si revisamos el mercado de controladores con protocolos X10, todavía no podemos dar con uno de estas características.

- 14 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 2 DESARROLLO Y RECURSOS En este apartado se ofrece un primer vistazo a los objetivos primordiales del proyecto, así como una descripción de las claves metodológicas y el material necesario para lograrlos.

2.1 OBJETIVOS DEL PROYECTO:

Los objetivos del proyecto que nos ocupa se pueden resumir en tres: 1. Medición: en un principio, empezaremos a medir en tiempo real la temperatura de la casa mediante el uso de cuatro sensores Oregon. Más adelante, dependiendo de cómo marche el desarrollo del proyecto, podremos introducir medidas de otros parámetros. 1. Actuación: el controlador domótico dará órdenes a sus actuadores, en un principio 4 radiadores eléctricos, según la información de medición que reciba o según las órdenes que se le manden desde un servidor web. Las órdenes emitidas por el controlador discurrirán a través de la red eléctrica de la casa siguiendo el estándar X10. 2. Comunicación con servidor web: esta comunicación se realizará a través de una Raspberry Pi conectada a nuestro microcontrolador Arduino de bajo coste, la interfaz con el usuario mediante el servidor web será otro proyecto a realizar paralelamente al proyecto que aquí se describe.

- 15 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

2.2 METODOLOGÍA DE TRABAJO

Las tres tareas principales mencionadas, se dividen a su vez en varias subtareas. Estas subtareas, suelen seguir un patrón común que se deberá realizar varias veces adaptándolo a cada objetivo final. Es decir, como vamos a usar el microcontrolador Arduino programado desde Simulink, la metodología para trabajar con estos recursos suele repetirse: 1. Estudiar el protocolo de comunicaciones del elemento que se va comunicar con el Arduino, ver que librerías dispone el microcontrolador sobre dicho protocolo y encontrar sus pines adecuados para la conexión. 2. Realizar el driver Block en Simulink que será el encargado de programar el microcontrolador para que este pueda realizar la comunicación y gestionar la información que le está llegando o que el micro está enviando. 3. Realizar una prueba de la conexión entre Arduino y sensor o actuador antes de pasar a otra tarea.

2.3 RECURSOS A EMPLEAR:

En un principio, como nos centraremos en el control de temperatura, sólo describiré los recursos necesarios para ello. 

Hardware: 

Microcontrolador Arduino Mega 2560



Sensor de temperatura inalámbrico 433 Mhz Oregon



2 Transceptores 433 Mhz acoplado al micro



CM11 X10 (conexión serie)



Actuadores X10



TM13 X10 (conexión por radio frecuencia) - 16 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO  

Cable de conexión SPI

Software: 

Matlab y Simulink



Librerías de Arduino necesarias

- 17 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 3 SIMULINK 3.1 ENTORNO DE SIMULACIÓN CONOCIDO

Simulink® es una herramienta muy potente y versátil que poco a poco hemos ido descubriendo a lo largo del Grado, sobre todo a la hora de cursar asignaturas como Regulación Automática y Control Digital. Simulink consiste en un entorno de desarrollo que nos permite diseñar sistemas complejos mediante diagramas de bloques, tal y como lo haríamos con papel y lápiz, y a su vez, nos permite ajustar las características técnicas de los distintos modelos que diseñemos y realizar simulaciones de los mismos.

Por lo tanto, una de las grandes ventajas de Simulink con la que nos encontramos nada más empezar a trabajar con él, es esa interfaz gráfica (GUI, graphical user interface) mencionada. Dicha interfaz, nos permite trabajar de manera amigable con modelos que resultarían mucho más difíciles de tratar si careciéramos de este enfoque gráfico. Agrupar los algoritmos o características técnicas necesarias en cada bloque ofrece una forma de trabajar encapsulada que favorece la gestión de un sistema complejo, y facilita la aplicación de técnicas de control al mismo.

Las facilidades expuestas, permiten apreciar por qué el uso de Simulink resulta ventajoso para desarrollar el presente proyecto. Para entenderlo, sólo tenemos que pensar en los diagramas de bloques. En el caso de este proyecto, los bloques más importantes podrían definirse como drivers de comunicaciones entre el microcontrolador usado y el hardware externo necesario. Simulink nos ofrece un entorno en el que diseñar y desarrollar cada uno de estos bloques, y lo que es más importante, nos ofrece un entorno en el que posteriormente podremos operar con

- 18 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO los bloques conjuntamente. Como ya hemos mencionado, esto último resulta muy favorable a la hora de aplicar técnicas de control al sistema que conformen nuestros bloques, ya que tenemos un entorno en el que pueden interactuar todos a la vez.

3.2 RUN ON TARGET HARDWARE

Por si fuera poco, Simulink cuenta con características adicionales que lo hacen aún más atractivo como herramienta de desarrollo. Una de ellas y quizá la más importante para este proyecto, es que Simulink permite cargar y correr los modelos que diseñemos como software embebido en hardware y plataformas de bajo coste, tales como Arduino, LEGO MINDSTORMS robots y Raspberry Pi. En este proyecto se hace uso de un Arduino Mega 2560, por lo que Simulink nos permitirá cargar directamente en el microcontrolador un complejo sistema formado por varios drivers de comunicaciones y controles sin tener que preocuparnos excesivamente por la programación de bajo nivel del micro. En el fondo, Simulink lo que hace es convertir nuestro modelo descrito gráficamente mediante bloques en un código que se cargará al microcontrolador para su ejecución.

- 19 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 4 ARDUINO Arduino se define como una plataforma de hardware libre, constituida por placas con microcontroladores de la familia Atmel AVR y un entorno de desarrollo para su programación. Ambos, placas y entorno de desarrollo, se encuentran diseñados para facilitar el uso de la electrónica en entornos multidisciplinares.

4.1 CONTEXTO ARDUINO:

Antiguamente, cuando los microcontroladores ya existían pero internet no era más que una pequeña comunidad de usuarios distribuidos a lo largo del mundo, cuando el correo más común seguía siendo el epistolar y cuando todavía no existían los puertos USB en los ordenadores, los consultores de la electrónica debían contar con una serie de habilidades para elaborar sus proyectos con las que quizá no están tan familiarizados los denominados “entusiastas” o “aficionados” a la electrónica de hoy en día. Se identificaba a esos antiguos trabajadores en muchos casos por el aspecto de sus manos acostumbradas a trabajar numerosas horas con el cautín o soldador eléctrico, por sus ropas salpicadas con el ácido característico de la fabricación de los PCB, y por su vista cansada de enrutar minúsculas vías en las placas mencionadas. A su vez, la mayoría de la programación practicada por estos trabajadores en los microcontroladores era en código ensamblador, aunque paulatinamente con la irrupción del lenguaje C los micros pasaron a programarse en este lenguaje mayoritariamente. Analizando la situación descrita, podemos apreciar que antes cada investigador electrónico armaba sus prototipos de la mejor forma que podía, intentando encontrar la estructura óptima que cumplimentara mejor los requisitos de su

- 20 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO proyecto, es decir, no existía un patrón estructural para los proyectos con microcontroladores y placas protoboard. La aparición de Arduino y hardware libre similar como Raspberry Pi, aparcó en cierta manera la necesidad de conocimiento detallado de hardware con la que contaban los antiguos consultores de la electrónica, y abrió el mundo de los proyectos electrónicos a una comunidad mucho más amplia desarrollada gracias a internet, la del “aficionado” que tiene como hobby la electrónica, y que parece saber más de programación que de electrónica. Estos nuevos consultores ya no tenían que preocuparse por el hardware y por como estructurarlo y ensamblarlo, pues las placas Arduino ya vienen hechas y se encuentran de sobra testeadas; dichas placas son de “plug & play”, y para trabajar con ellas sólo se exige al usuario que sepa programarlas y manejar algo de hardware periférico. De esta manera, el trabajo se centró en la programación, y gracias a Arduino, enseguida aparecieron complejos proyectos y aplicaciones desarrollados por personas que parecían más expertos en programación, que en ingeniería de hardware.

Hay que destacar que el éxito de Arduino no habría tenido cabida sin la existencia de internet. Desde su aparición, las posibilidades de desarrollo que esta placa prefabricada ofrecía corrieron como la pólvora en la red de redes. Arduino permitía llevar a cabo realizaciones increíbles a gente con conocimientos de programación. Dichas creaciones, como hemos expuesto, en un tiempo pasado estaban reservadas a los mejores ingenieros electrónicos. Así que en resumen, el proyecto Arduino, con la ayuda de internet, había creado un nuevo entorno de desarrollo para programadores con múltiples posibilidades, y en el que cualquier persona en cuestión de dos tutoriales, podía empezar a escribir sus programas. Si bien es cierto, que las creaciones más complicadas, al final, además de saber programar, en muchos casos también requieren que el proyectista tenga nociones serias de hardware, y también de programación del microcontrolador a bajo nivel, es decir, registros de menoria, registros de timers, registros de interrupciones, registros de conversores A/D, etc.

- 21 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

La llegada de este ecosistema “online” de Arduino benefició en gran medida a los que tienen como hobby la electrónica, pero no es un atrevimiento afirmar que también ayudó y sigue ayudando a los estudiantes de electrónica, y también a los estudiantes de lenguajes de programación. Los estudiantes agradecen que esos códigos que escriben a partir de diagramas de flujo, por fin, puedan verlos ejecutarse en un hardware cuyas conexiones de pines o puertos han realizado ellos mismos. Por lo tanto, Arduino ha contribuido a que los estudiantes vean de primera mano las consecuencias reales de los códigos que escriben, y no tengan que conformarse con correr sus programas en un emulador o en un simulador instalado en el ordenador. Con el tiempo, esos estudiantes se convertirán en ingenieros electrónicos, y recordarán los proyectos que realizaban con Arduino, que se les quedan pequeños en comparación con las nuevas tareas que deben afrontar en el mundo profesional de la electrónica. Por ello, quizá no esté tan mal eso de introducirse en la electrónica gracias a programar una “caja negra” como es Arduino para el usuario que no tiene conocimientos de hardware de microcontroladores o de diseño de tarjetas; es un hecho que Arduino está ayudando mucho en el aprendizaje de futuros ingenieros, tanto en software como en hardware.

4.2 HISTORIA RECIENTE ARDUINO:

En 2005 nació un proyecto llevado por estudiantes y profesores del Instituto IVREA de tecnología, situado en Ivrea (Italia). El proyecto tenía como principal objetivo sustituir los microcontroladores usados por los estudiantes en aquella época, que se consideraban demasiado costosos. El proyecto fue bautizado con el nombre del bar frecuentado por uno de los fundadores del proyecto que más famoso se hizo en los posteriores años, Massimo Banzi. El Bar se llamaba “bar di Re Arduino”, que literalmente significa “bar del Rey Arduino”. Arduino fue - 22 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO marqués de Ivrea y se proclamó rey de Italia en el 1002 d.c. , y actualmente aparte del Bar la familia de famosos microcontroladores también lleva su nombre.

4.3 AVR:

El hardware de Arduino está basado en la familia de microcontroladores de 8 bits Atmel AVR. Atmel es una empresa de semiconductores que fabrica y diseña arquitecturas de microcontroladores, la AVR entre ellas, la cual es una arquitectura de fabricación propia de Atmel. La arquitectura AVR se basa en las arquitecturas RISC para microcontroladores. RISC significa “Reduced Instruction Set Computer”, nombre que se le dio para contraponerse

a

la

otra

arquitectura

dominante,

la

CISC,

“Complex Instruction Set Computer”. RISC sigue una filosofía de diseño que marca que las instrucciones de la CPU sean de tamaño fijo y tengan un reducido número de formatos, y que sólo las instrucciones de carga y almacenamiento puedan acceder a la memoria de datos. La memoria de datos en el AVR se entiende al modo de la arquitectura de Harvard para computación, en la que la memoria de datos se diferencia de la memoria de programa o memoria de instrucciones.

4.4 ARDUINO MEGA 2560

La placa Arduino elegida para este proyecto monta el microcontrolador AVR ATmega2560. Sus principales características a destacar son las siguientes: 

54 pins digitales input/output, de los cuales 15 pueden usarse como salidas PWM.



16 pins de inputs analógicos.



4 UARTs - 23 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO 

Oscilador de cristal de 16 MHz. Este oscilador es el reloj de la CPU del micro y marca los tiempos de ciclo en los que se ejecutan instrucciones.



Conexión USB que nos sirve para alimentar el micro y al mismo tiempo para cargarle código.



Conexión Jack para alimentación.



Cabecera ICSP.



Botón de reset.

Ilustración 10: Vista placa ARDUINO (Web)

- 24 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

4.4.1 ALIMENTACIÓN Y MEMORIA:

Un resumen de sus características de memoria y límites de intensidad y voltaje de sus pines se encuentra en la siguiente tabla:

Microcontrolador

ATmega2560

Voltaje de operación

5V

Límites de voltaje de entrada

6-20V

Voltaje de entrada recomendado

7-12V

Pines digitales I/O

54 (15 con salida PWM)

Inputs analógicos

16

Corriente DC por I/O pin

40 mA

Corriente DC por 3.3 V pin

50 mA

Memoria flash

256 KB (8 KB usados por el bootloader)

SRAM

8KB

EEPROM

4KB

Frecuencia reloj

16 Mhz Tabla 3: Características técnicas ARDUINO

Mirando la tabla, podemos observar que la placa puede operar con una fuente de alimentación externa que entregue entre 6 y 20 V. Sin embargo, si se le entrega a la placa menos de 7 V, el pin de 5V podría entregar menos de este voltaje, y en ciertos casos, la actuación de la placa podría volverse inestable e impredecible.

- 25 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO Por otra parte, si la placa se alimenta con más de 12 V, el regulador de voltaje podría calentarse demasiado y dañar la placa. Por lo tanto, como se dice en la tabla, si vamos a usar una fuente de alimentación externa que no sea el ordenador el rango de voltaje recomendado es de 7 a 12 V. En el desarrollo de este proyecto no se tiene este problema ya que durante la programación del micro siempre se alimenta con los 5 V del USB del ordenador; pero estas limitaciones para fuente de alimentación externa resultan importantes a la hora de dejar al micro ejecutando sus programas autónomamente, es decir, sin estar conectado al ordenador y trabajando sólo alimentado por una fuente externa.

Respecto a la memoria, destacan los 256 KB de memoria flash, que serán utilizados como memoria de programa, excepto los 8 KB exigidos por el bootloader. Este tamaño de memoria, junto con el hecho de que el Arduino mega 2560 tiene más I/O pins, mas puertos serie y más timers, fueron las razones para elegir esta placa en lugar de la placa Arduino estándar, el Arduino Uno. El Arduino Uno es más barato y físicamente más pequeño, tiene menos puertos y pines, una flash de 32 KB y una RAM de 2 KB. Por ello, aunque el Arduino Mega sea más caro y más grande, se eligió precisamente por sus características más ambiciosas, cuenta con más pines y con más memoria.

Ilustración 11: Vista placa ARDUINO MEGA (Web)

- 26 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

4.4.2 INPUT Y OUTPUT:

Ilustración 12: Esquema I/O ARDUINO (Web)

- 27 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO Cada uno de los 54 pines digitales del Arduino Mega pueden ser usados como input u output. Operan a 5 V y pueden entregar una corriente máxima de 40 mA. Además hay que destacar que cada uno de ellos tiene instalada una resistencia interna en conexión pull-up, que puede usarse mediante la función “pinMode()”. En la siguiente figura pueden verse las típicas conexiones pull-up y pull-down con resistencias y pulsadores:

Ilustración 13: Esquema conexiones pull-up y pull-down (Web)

El Arduino Mega también cuenta con 16 pines de entrada analógicos, cada uno de ellos con 10 bits de resolución, es decir 210 =1024 valores posibles. Por defecto, los pines analógicos miden desde GND a 5 V, aunque es posible cambiar el límite superior del rango mediante el AREF pin y la función “analogReference()”.

- 28 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO Para finalizar con los pines de entrada y salida del Arduino, destacaremos algunos de los 54 pines digitales que tienen alguna función especial que fue de utilidad al desarrollar el proyecto: 

Pines puerto serie: (RX es receiver y TX transceiver) o Serial 0: 0(RX) y 1(TX) o Serial 1: 19(RX) y 18(TX) o Serial 2: 17(RX) y 16(TX) o Serial 3: 15(RX) y 14(TX) De todos estos pines que sirven para recibir y transmitir datos en serie TTL, los pines 0 y 1 son los más importantes por estar conectados al conversosr USB-TTL, es decir, a través de ellos se cargan los programas escritos en el ordenador y que descargamos en el micro mediante el USB.



Pines de interrupciones externas: digamos que existen en Arduino y en los microcontroladores varios tipos de interrupción, en concreto, las interrupciones externas son eventos que tienen lugar cuando se produce algún cambio en los pines que tienen asignados dichas interrupciones. La mayoría de las placas Arduino tienen dos interrupciones externas, la número 0 en el pin digital 2, y la número 1 en el pin digital 3. El Arduino Mega tiene otras cuatro interrupciones externas, la números 2 en el pin 21, la número 3 en el pin 20, la número 4 en el pin 19 y la número 5 en el pin 18. En el proyecto, en la realización del driver del sensor de temperatura Oregon, se configuró la interrupción 1 del pin 3 con la función “attachInterrupt()”. Se configuró de manera que el programa en curso interrumpiera su ejecución e hiciera una llamada a la rutina de interrupción cuando se detectara un cambio en el pin 3; un cambio en dicho pin se traducía en la llegada de un nuevo mensaje de RF emitido por el sensor que el driver realizado decodificaría.



PWM: los pines del 2 al 13, y del 44 al 46, proporcionan una salida PWM de 8 bits. Dicho PWM puede modificarse con el API del Arduino

- 29 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO mediante la función “analogWrite”, o puede modificarse directamente mediante los registros del micro destinados al PWM. Se mencionan los PWM porque al realizar el driver de comunicación para radiofrecuencia X10, se pensó en usar el PWM para dar lugar a la onda portadora necesaria para la transmisión en RF. Sin embargo, la RF del X10 sigue el estándar europeo de los 433 Mhz, y conseguir esa frecuencia con un micro de estas características no es posible. Para 433 Mhz se necesita un componente específico con un oscilador para emitir a esa frecuencia. Por lo tanto, se procedió a la compra de un emisor de RF en 433 Mhz para que fuera el encargado de dar lugar a la portadora de esa frecuencia. Entonces, con el micro, ya sólo había que enviar las señales adecuadas para modular dicha portadora de cara a enviar la información correctamente. 

SPI pins: 50 (MISO), 51 (MOSI), 52 (SCK), 53 (SS). Estos pines permiten la comunicación SPI usando la librería SPI existente para Arduino. De este apartado se hablará más en el apartado Futuros Desarrollos, pero aquí simplemente mencionar que la comunicación SPI es importante en este proyecto porque habría sido la forma de comunicar el Arduino con la Rasberry Pi del proyecto paralelo. La Raspberry se encargaba de realizar la interfaz de usuario del Controlador del proyecto expuesto en esta memoria.

4.4.3 COMUNICACIÓN:

Como hemos mencionado con los pines que actúan de puerto serie, el Arduino Mega tiene bastantes formas de comunicarse con un ordenador. La placa incorpora el chip ATmega16U2, que permite que el Arduino pueda verse como un puerto virtual COM en Windows con la ayuda de un archivo .inf, y en OSX y Linux, el ordenador lo reconoce como puerto COM automáticamente. Esto es una gran ventaja, pues como se ha remarcado, permite cargar programas en el micro por el puerto USB.

- 30 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO Además, el software de Arduino incluye el monitor serial, que permite la comunicación en tiempo real durante la ejecución de un programa en el microcontrolador entre este y el ordenador. Esta comunicación resulta de gran ayuda en el “debugging” de un programa, al permitir enviar mensajes de error en tiempo real desde el micro. Por otra parte, en el proyecto se usó mucho el monitor serial al programar el driver del sensor, ya que a través de dicho monitor el micro mostraba la temperatura que le enviaba el sensor, y en un principio, era la única forma de comprobar si el driver estaba haciendo su trabajo.

4.4.4 PROGRAMACIÓN:

El Arduino Mega como todas las placas Arduino puede programarse desde el IDE de Arduino. El lenguaje de programación se parece mucho al C y tiene muchas funciones propias que facilitan y agilizan en gran medida la programación del micro. Aun así, para programar ciertas tareas, no será suficiente con las funciones del API de Arduino y se deberá recurrir a la programación de bajo nivel de registros; para ello siempre hizo falta la ayuda del datasheet del micro ATmega2560.

Respecto a la estructura de los programas es siempre la misma. En la captura podemos apreciar que existe un setup() que contiene el código de inicialización, y un loop() que contiene el código de ejecución continua. Tanto setup() como loop() se consideran funciones independientes, por lo que las variables definidas en una no podrán usarse en la otra. Para trabajar con variables que puedan usarse en todo el programa o variables “globales”, se deben definir fuera de ambas funciones, tal y como se hace en el ejemplo de la captura. Esta manera de estructurar los programas del API de Arduino busca simplificar el int main (void) típico de los programas para micros, diferenciando claramente entre código de inicialización y código de ejecución continua. El código de ejecución continua de los loop() de Arduino es el mismo que nos encontraríamos en los while(1) de los programas en C para micros. - 31 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 14: HardCopy programación ARDUINO

El lenguaje de Arduino también tiene cierto parecido con C++, sobre todo a la hora de programar bibliotecas. Las bibliotecas de Arduino trabajan con los conceptos de clases y constructores de C++. Durante el proyecto, se realizaron dos bibliotecas, la del driver del sensor de temperatura y la del driver del X10 por RF. La librería del X10 cableado ya existía como tal y sólo hubo que familiarizarse con su uso.

- 32 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 5 DRIVER-BLOCK El Driver-Block es la esencia de este proyecto, la creación de estos bloques customizables de Simulink son la tarea principal que se persigue. Los DriverBlocks una vez creados, actúan de interfaz entre el microcontrolador y un sensor, o un actuador, todo ello dentro del entorno de Simulink; en el fondo, son drivers de comunicaciones entre el micro y otros elementos. El hecho de que se creen con Simulink, posteriormente nos da la posibilidad de poder crear interrelaciones entre ellos y nos permite aplicarles técnicas de control. Además, como Simulink cuenta con librerías de Arduino, el modelo final que diseñemos con todos los drivers podremos cargarlo directamente en la placa desde Simulink, ya que Simulink se encargará de compilar el código global del modelo, que luego se convertirá en ejecutable, y se cargará en el micro como software embebido.

Simulink viene teniendo esta opción de cargar los ejecutables de modelos diseñados en él en hardware soportado desde la versión de Matlab R2012a. Sin embargo, aunque con cada nueva versión de Matlab la gente de Mathworks siguen añadiendo nuevo hardware soportado y mayores posibilidades con el ya soportado, siempre existe la posibilidad de que quieras hacer algo con tu hardware que no se encuentre entre los paquetes de soporte, es decir, necesitas unos drivers que no están soportados. Esto es exactamente lo que viene pasando en este proyecto, tenemos el hardware del Arduino Mega 2560 soportado por Simulink, pero sin embargo, no contamos con drivers del paquete de soporte para la comunicación con el sensor Oregon, ni tampoco para el protocolo X10, tanto en su forma cableada como en RF. Simulink nos ofrece los Driver-Blocks para enfrentarnos a estas situaciones, sino esta hecho ya el driver que necesitamos, nos da la opción de crearlo mediante uno de sus bloques customizables, el S-Function Builder.

- 33 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 15: Bloque programación SIMULINK

El S-Function Builder, como su nombre indica, nos permite crear S-Functions a partir del código C que escribamos y de las especificaciones que configuremos. Como es un bloque a crear por el usuario, Simulink lo ubica en su librería de “User-Defined Functions”. Esos S-Functions son los mencionados Driver-Blocks customizables. Los menús que desplegamos al clicar en este bloque, contienen pestañas que debemos rellenar con código en lenguaje C, para así programar la actuación del bloque como driver.

Ilustración 16: HardCopy interfaz programación SIMULINK

- 34 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

5.1 TIPOS DE DRIVER BLOCKS:

Entendiendo que todos los S-Functions creados en este proyecto funcionan como drivers, se puede afirmar que hay dos tipos de Driver-Blocks, el Input DriverBlock y el Output Driver-Block.

Ilustración 17: HardCopy tipos de Driver.Blocks en SIMULINK

En general, estos dos drivers se diferencian en la manera que tienen de recoger datos de entrada, y en la manera que tienen de responder ante esos estímulos.

Un Input Driver-Block es un driver que suele actuar de sensor desde el punto de vista del hardware que se está programando (el Arduino Mega 2560), y en su salida entrega los valores de medidas obtenidos. Así, el micro mediante este Driver-Block puede disponer de los resultados de medida de un sensor para procesarlos, el bloque es tan sólo la interfaz digital entre el micro y el sensor. El Driver-Block creado para el sensor de temperatura Oregon es de este tipo de bloques.

Por otra parte, el Output Driver-Block es un driver que tras leer su señal de entrada, realiza algún tipo de tarea con el hardware que se está programando. La

- 35 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO señal de entrada es el aviso que necesita el bloque para llevar a cabo su tarea, la cuál puede ser de naturaleza digital o analógica. Los dos Driver-Blocks realizados para el protocolo X10, uno para la comunicación cableada y el otro para la RF, son ejemplos de Output Driver-Blocks, ya que ante un cambio en su señal de entrada, reaccionan haciendo enviar al micro un comando X10.

Existe otro tipo de Driver-Block usado en el proyecto que podemos definir como bloque de los “includes”. Más adelante lo trataremos con más profundidad, pero básicamente es un Driver-Block cuya función es agregar a su entorno de Simulink archivos fuente de librerías que se vayan a usar, en concreto, agrega los archivos fuente CPP.

Tiempo de muestro:

Ilustración 18: Activación del tiempo de muestreo en SIMULINK

- 36 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Estos bloques, como otros de la librería de Simulink, tienen un tiempo de muestreo que puede modificarse para cambiar su periodo de ejecución. La forma de ejecutarse de estos bloques se asemeja a cómo trabaja una máquina de estados, el output del bloque se actualiza según el tiempo de muestreo definido. Todo esto es cierto teniendo en cuenta que en este proyecto, el diseño de tales bloques siempre se realizará en el modo discreto, lo que obliga al bloque a tener estados discretos cuya transición de uno a otro se produce según el tiempo de muestreo estipulado. En la mayoría de los casos, tan sólo nos hará falta un estado que ejecutaremos en bucle eternamente, al modo del loop() del Arduino o del while(1) típico de los programas ejecutados por microcontroladores. Para elegir el modo discreto, debemos elegir el muestreo discreto en la pestaña de inicialización del bloque y especificar los estados discretos que queremos. Los valores de dichos estados se almacenan en una matriz. Para referirnos a los estados de esa matriz el S-Function Builder nos ofrece un puntero a la misma, el puntero “xD”. De esta manera, con xD podemos referirnos a los estados discretos en el código que escribamos en las otras pestañas del bloque.

5.2 PESTAÑAS MÁS IMPORTANTES DE CARA A ESCRIBIR EL CÓDIGO C DEL BLOQUE:

Se ha hablado de la pestaña de inicialización al tratar el tiempo de muestreo, pero como se puede apreciar en las capturas, el bloque cuenta con varias pestañas más para su configuración. Ahora, vamos a describir las pestañas que hay que tener en mente cuando se escribe el código en C que programará la actuación del driver. Pero antes de ello, es prudente aclarar que las pestañas que contienen código trabajan como “funciones de C” independientes entre sí, es decir, si se define una

- 37 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO variable en una pestaña no se podrá acceder a ella desde otra. Si necesitamos variables globales para todas las pestañas deberán definirse en el cuadro “Includes” de la pestaña “Libraries”. 

Pestaña de “Discrete Update”: esta pestaña sólo se usa cuando se trabaja con estados discretos, como es el caso de todos los Driver-Blocks realizados en este proyecto. El código escrito en esta pestaña se ejecuta para actualizar dichos estados discretos. Si nos fijamos en el código de la captura, al terminar la estructura “if”, xD toma el valor de uno, por lo tanto, ese mismo “if” no volverá a ejecutarse. El código está escrito de manera que la actualización del estado sólo se produzca una vez, es decir, es un código de inicialización del estado. Enfocar así el código de esta pestaña busca crear un espacio para la inicialización parecido al del setup() de los programas de Arduino, o asemejarse al código de inicialización que está fuera del while (1) en cualquier programa escrito para un microcontrolador.

Ilustración 19: SIMULINKSolapa DiscreteUpdate

- 38 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO



Pestaña de “Outputs”: siguiendo con la analogía con los programas para Arduino y otros micros en general, el código recogido en esta pestaña es equivalente al que se escribe en el loop() de Arduino o en el while (1) de los otros micros. El código de esta pestaña configura la tarea que realiza el bloque en cada uno de sus periodos de ejecución. De nuevo, si nos fijamos en el código de la captura, vemos que sólo se accede a la estructura del “if” si xD ya tiene el valor de 1, lo que se traduce en que la inicialización ya debe haber sido hecha. Por lo tanto, el código de esta pestaña sólo se ejecutará una vez se haya terminado con el código de la “Discrete Update”. Como en el caso anterior, con esta forma de programar se busca parecerse a la estructura típica de los programas para microcontroladores.

Ilustración 20 SIMULINKSolapa Outputs

- 39 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO 

Pestaña de “Libraries”: esta pestaña presenta varios cuadros para su configuración, sin embargo, lo más simple es sólo modificar el cuadro de “Includes”. En este cuadro se deben incluir las librerías externas que use el código escrito en las otras pestañas. Además, en este cuadro, deben definirse las variables y funciones que tengan un carácter global. Las variables y funciones definidas de esta manera podrán usarse en el resto de pestañas del bloque. . Estas variables y funciones en un programa típico de Arduino se situarían fuera del setup() y del loop(). Recuérdese que las pestañas tienen las características de “una función de C”, y si queremos trabajar en varias de ellas con la misma variable o con la misma función, debemos definir estas últimas en el cuadro descrito para que así sean globales.

Ilustración 21 SIMULINKSolapa Libraries

- 40 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO En la siguiente figura se hace referencia a las comparaciones que se vienen haciendo entre la estructura de programación de un sketch de Arduino y las pestañas de un Driver-Block. Programa Arduino

Driver-Block

Setup()

Discrete Update pane

Loop()

Output pane

Global functions &Variables

Includes pane

Ilustración 22: Sketch (ARDUINO) vs Drivers-Block (SIMULINK) (Web)

5.3 EJECUTABLES CREADOS POR EL BLOQUE AL DARLE A BUILD:

En la siguiente captura se muestra el resultado de haber pulsado el botón “Build” del bloque:

Ilustración 23: SIMULINK Solapa Build Info

- 41 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Si todo va bien, pulsar el botón “Build” supone la creación de 6 ficheros por parte de Simulink. Los ficheros se crean en la misma carpeta de trabajo que Matlab esté usando en ese momento. Los ficheros creados son los 6 siguientes: 

Un archivo wrapper con extensión de código fuente de C, un wrapper.c



Un archivo S-Function sólo para simulación, también con .c



Un archivo MEX (Matlab Executable) sólo para simulación, con extensión .mexw32



Dos archivos de configuraciones, un rtwmakecfg.m y un SFB.mat



Y un archivo TLC, con extensión .tlc

De todos estos archivos creados al generar la S-Function, sólo habrá que revisar y modificar manualmente el archivo wrapper. Este archivo contiene informaciones de cabeceras y funciones con el código introducido en las pestañas del DriverBlock, ya que las pestañas del bloque se caracterizaban como funciones de C. Tal y como se ha venido explicando, en los Driver-Blocks creados en este proyecto, de cara a escribir código, sólo eran importantes tres pestañas, la de “Discrete update”, la de “Output” y el cuadro de “Includes” de la pestaña “Libraries”. Por lo tanto, estas tres pestañas con su contenido en código serán las que aparezcan en el archivo wrapper.

A su vez, los códigos del archivo wrapper están referenciados tanto en al archivo MEX como en el archivo TLC. El archivo MEX se genera únicamente para simulación, mientras que el archivo TLC se utiliza para generar un ejecutable, el cuál posteriormente permitirá cargar el Driver-Block en el micro como software embebido. Como ya se ha expuesto, sólo hará falta trabajar con el archivo wrapper, sin embargo, no está de más conocer la función de cada uno de los ficheros generados, en especial, de uno tan importante como el TLC, imprescindible para que el micro ejecute el código del Driver-Block.

- 42 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

5.4 SIMULACIÓN VS EJECUCIÓN EN HARDWARE:

Desgraciadamente, la potencia que el entorno de Simulink ofrece para tareas de simulación no podrá ser aprovechada en este proyecto. Si se trata de realizar una simulación con un Driver-Block, Simulink llama al archivo MEX generado cuando se creó, y ejecuta el modelo dentro del ordenador. Dicha ejecución es realizada por el motor de Simulink como una parte de los procesos de Matlab. Sin embargo, no se obtendrá ningún resultado de esa simulación. Esto se debe a que en general, un Driver-Block no actúa en condiciones de simulación, es un bloque creado para comportarse como interfaz con el hardware real, es decir, su respuesta a un estímulo supone alguna actuación con el hardware real, algo que no puede reproducirse tal cual en el entorno de Simulink. Por lo tanto, puede afirmarse que en la mayoría de los casos no se pueden realizar simulaciones con Driver-Blocks.

Por otra parte, si en lugar de simular nuestro modelo con Driver-Blocks, lo cargamos en el microcontrolador, Simulink generará a partir del archivo TLC mencionado un ejecutable del modelo. El ejecutable cargado en el micro nos permitirá ver en tiempo real las reacciones del hardware, y aquí sí podremos comprobar si nuestros Driver-Blocks están operando correctamente. Las diferencias descritas entre simulación y ejecución en el hardware debemos tenerlas muy en cuenta en la programación de las pestañas del Driver-Block. De hecho, la instrucción presentada en la siguiente imagen, ilustra sobre cómo se tiene en cuenta la simulación al escribir el código.

- 43 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO # ifndef es una instrucción condicional de compilación, cuya función en este caso es prevenir de que el código que encierra sea incluido en la compilación del archivo para simulación MEX. De esta manera, podemos evitar que líneas de código típicas para ejecución en el hardware real, sean incluidas por el compilador a la hora de crear el ejecutable MEX para simulación. Librerías Externas: La mejor forma de programar los Driver-Blocks es a través de librerías externas a Simulink, que ofrecen el soporte necesario para programar los drivers como deseamos. En este proyecto, al trabajar con Arduino, las librerías externas usadas se creaban primero para el microcontrolador, para así poder comprobar su correcto funcionamiento. Dichas comprobaciones se realizaban a través del IDE de Arduino, viendo que las librerías eran aceptadas por el IDE, y que programas que las usaban se ejecutaban correctamente. El problema es que las librerías de Arduino se escriben en lenguaje C++. Estas librerías están formadas como mínimo por dos archivos: un archivo de cabecera .h y un código fuente .cpp Para asegurarse de que el compilador de Matlab sabe cómo interoperar los archivos en C que genera con los archivos fuente C++ de las librerías, se deben realizar las siguientes modificaciones al archivo wrapper .c generado al compilar la S-Function: 1. Localizar en el wrapper las dos funciones que representan a las pestaña “Discrete Update” y “Output”. Justo delante de la definiciónde las dos funciones, delante del “void”, debe incluirse lo siguiente: extern ‘C’ 2. Guardamos el archivo wrapper y lo renombramos con extensión .cpp Tras este proceso, el ejecutable de nuestro modelo podrá generarse correctamente.

Bloques includes: En muchos casos al intentar incluir todos los archivos que componen una librería externa en un mismo Driver-Block, nos encontraremos con que el driver no funciona correctamente. Para poder agregar la librería externa con éxito a nuestro

- 44 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO modelo, la mejor forma es dividir los incliudes a los archivos que las componen entre dos Driver-Blocks. El Driver-Block principal, el que contiene el código de programación, tendrá en su include sólo el archivo de cabecera. Por su parte, el código fuente .cpp, será incluido por otro Driver-Block que crearemos exclusivamente para ello. En la siguiente imagen se observa un modelo como el descrito. En ella podemos ver la presencia de los dos mencionado Driver-Blocks. El driver que incluye el .cpp se le suele denominar Driver-Block de includes.

Problemas con la version2013 b: El proyectista usa la versión de Matlab R2013b. Esta versión presenta graves problemas al compilar los Driver-Blocks. Sin embargo, la situación puede arreglarse sustituyendo un archivo de los instalados por Matlab. Las instrucciones para arreglar el “bug” con éxito se encuentran en el siguiente enlace: http://www.mathworks.com/support/bugreports/1006532

- 45 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 6 OREGON

6.1 ESPECIFICACIONES TÉCNICAS

Oregon Scientific es una empresa famosa por manufacturar productos electrónicos orientados a la medida de condiciones medio ambientales. El sensor de temperatura usado en este proyecto es uno de los productos de dicha empresa. El sensor de temperatura elegido fue el Oregon Scientific THGR810, un sensor diseñado para realizar medidas en interiores. El sensor es capaz de medir temperatura y también el índice de humedad, y cuenta con 10 canales de transmisión de RF a 433Mhz para transmitir las medidas realizadas a otros equipos. De hecho, Oregon Scientific lo concibe como el complemento ideal de las estaciones meterelógcas que ofrecen, tales como la WMR80 o la WMR100. Además, el dispositivo cuenta con un display LCD donde podemos comprobar las medidas realizadas y el canal operante.

Ilustración 24: Sensor de temperatura Oregon

- 46 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

El rango de alcance de sus transmisiones RF es de unos 100 metros, sin tener en cuenta posibles obstáculos a la propagación. Respecto a su rango de temperaturas medibles, en condiciones de exteriores soporta desde los -30 Cº hasta los 60 Cº. El límite inferior de dicho rango de temperaturas, está estipulado considerando que el sensor está usando pilas de litio en lugar de las típicas pilas alcalinas AAA. Ello se debe a que las pilas alcalinas contienen una significativa cantidad de agua, y por lo tanto, en una situación de bajas temperaturas es muy probable que se congelen alrededor de los -12Cº. Las pilas de litio tienen un umbral de congelación mucho más bajo estimado en los -30 Cº. Los productos que son compatibles con la transmisión en RF de este sensor llevan el logo del protocolo Oregon 3.0

6.2 DECODIFICANDO EL OREGON 3.0

Hasta aquí las explicaciones a nivel de usuario, ahora lo que interesa de cara a programar el Driver-Block que hará de interfaz con este sensor, es el protocolo que utiliza en la transmisión de RF de sus medidas. El sensor transmite a la frecuencia estándar europea para estas aplicaciones, aquella en que la onda portadora es de 433 Mhz. Pero la información que transmite se encuentra codificada según un protocolo OS (Oregon system). La transmisión RF es de carácter digital, del tipo OOK (ON-OFF-Keying), con una codificación Manchester. La misión del Driver-Block es ejecutar un programa capaz de decodificar el Manchester, y luego, organizar la información según el protocolo OS que sigue este sensor. Es decir, es importante diferenciar el Manchester del protocolo Oregon, una cosa es como se codifican los bits, los unos y los ceros (Manchester), y otra como se codifica la información una vez sabes que unos y ceros tienes (protocolo Oregon).

- 47 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO Por lo tanto, el enfoque de la escritura del código que realizará las anteriores tareas será encapsulado. Para explicar esto hay que tener en mente el concepto de “clase” de C++. Lo primero, sería elaborar una clase cuya función sea decodificar el Manchester, que sería nuestra clase base. De esta clase base se obtendría un código binario que habría que interpretar según el protocolo Oregon. Para programar esa interpretación, lo adecuado es crear una clase que use las funciones de la clase anterior, una especie de subclase, que en C++ se denomina clase derivada. Las clases derivadas heredan los miembros de datos y las funciones de su clase base (excepto los constructores y destructores). Este concepto de herencia, junto con el enfoque de encapsulamiento mostrado con las clases jerarquizadas, son ideas propias de programación orientada a objetos, como la del lenguaje C++. De esta manera, se consigue un código conformado por clases capaz de decodificar los mensajes de RF enviados por el sensor de temperatura. En los siguientes apartados, se procede a describir más en profundidad tanto la codificación binaria Manchester como el protocolo Oregon usado por el sensor, así como el método OOK de transmisión en RF.

6.2.1 I'M OOK. YOU'RE OOK? “Amplitude shift keying” o ASK es una popular técnica de modulación usada en la comunicación de información digital en un gran número de aplicaciones de baja radiofrecuencia. En su forma más simple, la técnica ASK consiste en que la fuente transmite una portadora de gran amplitud cuando quiere enviar un 1 binario, y una portadora de pequeña amplitud cuando quiere enviar un 0 binario, como si fuera una especie de AM digital. Una simplificación mayor del método ASK es la modulación digital OOK (On-OFF-Keying), en la que un 0 binario consiste en simplemente no enviar ninguna portadora, dejando de emitir. ASK y OOK se usan comúnmente en aplicaciones “Wireless” de corto alcance, como es el caso del sensor de temperatura del proyecto. OOK es especialmente popular en dispositivos operados por baterías portables o pilas, ya que dichos - 48 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO dispositivos pueden ahorrar energía mientras están enviando 0s binarios. El OOK en aplicaciones cableadas usa portadoras de unos 2Mhz, mientras que en aplicaciones “Wireless” como la del Oregon, lo típico son 433 Mhz, frecuencia adecuada a la banda pública ISM.

Ilustración 25: OOK

6.2.2 CODIFICACIÓN MANCHESTER

El Manchester es un método de codificación que combina las señales de datos y reloj en una única señal capaz de autosincronizar el flujo de datos. Cada bit codificado por este método tiene una transición entre los dos niveles de la señal en la mitad del intervalo de duración del bit. Las transiciones representarán un 1 o un 0 dependiendo de la polaridad elegida para la ocasión.

- 49 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO La principal ventaja del Manchester es su mencionada autosincronización, que permite obtener la señal del reloj en cualquier bit codificado, lo que a su vez se traduce en una sincronización precisa del flujo de datos. Sin embargo, posee la desventaja de consumir el doble de ancho de banda que una transmisión asíncrona. La codificación Manchester aparte de ser usada por el sensor del proyecto, hoy en día se utiliza en muchos estándares de telecomunicaciones, como por ejemplo en el protocolo Ethernet. En la siguiente figura puede observar ejemplos de codificación Manchester representados junto a la señal de datos y a la señal del reloj.

Ilustración 26: Manchester

6.2.3 PROTOCOLO OREGON VERSIÓN 3.0

El THGR810 para organizar la información que transmite por RF utiliza el protocolo de Oregon 3.0. Los sensores que usan dicho protocolo transmiten bits a un bit rate de 1024 Hz. El formato de las tramas de bis enviados según este protocolo se presenta en la siguiente imagen.

- 50 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 27: Trama Oregon

La trama consta de 4 partes principales: 1. El preámbulo consiste en 6 nibbles (un nibble son 4 bits) formados por 1s binarios. 2. Un nibble de sincronización que es “0101” en el orden de la transmisión. 3. La parte más importante, la información digital entregada por el sensor que representa las medidas realizadas. Su formato puede apreciarse en la anterior imagen. 4. La trama se suele finalizar con dos nibbles cuyo contenido sigue siendo desconocido. Recordemos que el protocolo Oregon es un estándar de una empresa privada, los datos aquí recogidos están sacados de documentación elaborada por entusiastas que han sido capaces de decodificar el protocolo. La duración de la mayoría de los mensajes con protocolo v3.0 es de unos 100ms.

- 51 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 7 X10 El X10 es un estándar o protocolo de comunicación que aprovecha la red eléctrica de una vivienda para transmitir información a través de la misma. El protocolo, que viene siendo muy usado en los entornos domóticos, comunica los emisores con los receptores mediante pequeños pulsos de RF que se envían sincronizados con la senoidal de la red eléctrica. Esos pequeños pulsos representan la información digital.

Entre los numerosos protocolos domóticos actualmente existentes, el X10 a pesar de su antigüedad sigue siendo de los dominantes. Ello se debe al bajo coste de los productos compatibles y a su facilidad de instalación, al ser la mayoría de los módulos X10 dispositivos de “plug & play”.

7.1 HISTORIA DEL X10:

La tecnología digital empezó a llegar al gran público en forma de productos de consumo en los años 70. En esta época, muchas tecnologías avanzaron a pasos agigantados para alimentar el creciente mercado de productos digitales y electrónica de consumo que se estaba gestando. Una de esas tecnologías que dio un gran paso, fue la de los dispositivos de control remoto.

Cerca de Nueva York, a finales de los 70, el sistema “X-10 Powerhouse” demostró una nueva forma de control remoto de dispositivos. El sistema proponía algo hasta entonces muy novedoso, usar la red eléctrica existente en un edificio como canal de comunicaciones entre dispositivos con carácter “plug-in”, es decir,

- 52 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO dispositivos de fácil conexionado a la red eléctrica (normalmente, a través de un enchufe). Ello ofrecía un gran abanico de posibilidades, ya que según esa filosofía, los típicos dispositivos domésticos podían ser controlados remotamente al conectarlos a módulos X10.

La tecnología X10 fue desarrollada por una empresa escocesa llamada “Pico Electronics Ltd”. La empresa fue fundada a principios de los años 70 en la localidad escocesa de Glenrothes.

Ilustración 28: Empresa “Pico Electronics Ltd” en Escocia (Web)

Pico Electronics se fundó con la idea de desarrollar circuitos integrados para competir en el creciente mercado de calculadoras electrónicas. Los ingenieros de Pico creían que un único circuito integrado podía diseñarse para soportar todas las posibles operaciones realizadas por una calculadora portable. Hasta entonces, lo común era usar tres circuitos integrados, uno para la interfaz con los botones, otro para el driver del display, y por supuesto, un último para realizar los cálculos requeridos. Pico Electronics bautizaba sus proyectos simplemente con un número; los proyectos del 1 al 8 se centraron en desarrollar circuitos integrados cada vez más complejos para calculadoras.

- 53 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO En el proyecto 9 se cambió de temática. La BSR (British Sound Reproduction) solicitó el diseño de un circuito integrado que operara un “programmable record changer”, dispositivo que consistía en un fonógrafo programable, capaz de realizar una selección automática de canciones. En poco tiempo, la BSR solicitó otro proyecto a Pico Electronics, buscaban una respuesta electrónica para obtener un control remoto sin cables de su equipo de trabajo. Este proyecto fue el experimento 10 de Pico Electronics, o para acortar, el proyecto “X10”.

Los dispositivos concebidos para el proyecto se denominaron “BSR System X10”. Sin embargo, su nombre cambiaría al de “X10 Powerhouse”, pues el potencial de estos dispositivos pronto se proyectó más allá del equipamiento de audio para el que habían sido concebidos originalmente. Los ingenieros de Pico se dieron cuenta de que los dispositivos que habían creado tendrían futuro comercial en un mercado como el estadounidense, así que en 1978, decidieron visitar la ciudad de Nueva York para dar a conocer sus nuevos dispositivos; alquilaron una casa cerca de la ciudad, y en poco tiempo consiguieron contratos con Radio Shack y con Sears, dos empresas que venden productos electrónicos y que siguen siendo prosperas hoy en día. Sin embargo, hay que mencionar que actualmente ninguna de las dos empresas sigue vendiendo productos X10. El X10 es una tecnología barata que se decidió usar para este proyecto, pero ahora mismo las empresas ya lo consideran un protocolo domótico obsoleto.

Pero volviendo a la historia de este protocolo, en julio de 1979 se publicó el primer reportaje sobre la tecnología X10 en la revista “Radio Electronics”. El reportaje tenía algunos errores técnicos, pero publicitaba con éxito las ventajas que ofrecían los nuevos dispositivos X10 de control remoto. Para aquel entonces, los ingenieros de Pico habían fundado una nueva empresa con base en Nueva York, dedicada exclusivamente a los productos X10; la llamaron “Advance Electronics”.Un reportaje mejor sobre el X10 apareció en agosto del mismo año en la revista “Popular Science”, decía así: "Run your home with plug-in remote - 54 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO control". Ya se intuían los futuros usos domóticos que harían famoso al X10. El artículo de “Popular Science” descríbia los productos X10 y mencionaba que las señales de control que utilizaban viajaban a través de la red eléctrica, pero no hablaba de la tecnología digital que hacía posible la sincronización, y por tanto, la comunicación, entre dichos dispositivos.

El siguiente artículo que aparecería, sería por fin mucho más explicativo de cara a entender el funcionamiento de la tecnología X10. Lo publicó la ya mencionada Radio Electronics, en septiembre de 1980, con el título de "Plug-in Remote Control System", tal y como se aprecia en la imagen.

Ilustración 29:Portada de la revista Radio Electronics de 1980 (Web)

- 55 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 30: Articulo de la revista Radio Electronics (Web)

El artículo de 5 páginas explicaba de manera muy detallada cómo funcionaban los módulos X10, incluso mostraba esquemas de sus arquitecturas y de los circuitos electrónicos de su interior. Además, era el primer artículo publicado en el que se mencionaba que los productos X10 estaban disponibles para su compra en Radio Shack. En las siguientes imágenes se pueden observar algunas capturas de dicho artículo.

Ilustración 31: Articulo de la revista Radio Electronics (gráfico) (Web)

- 56 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 32: Articulo de la revista Radio Electronics (gráfico y texto I) (Web)

Ilustración 33: Articulo de la revista Radio Electronics (gráfico y texto II) (Web)

- 57 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 34: Articulo de la revista Radio Electronics (gráfico y texto III) (Web)

Para finalizar con el contexto histórico del X10, no está de más aclarar que hoy en día el término “X10” se utiliza para hacer referencia al protocolo de comunicaciones o a los dispositivos compatibles con él, no para referirse a la empresa que manufactura los productos X10. Ello es así, porque a pesar de que el X10 nació de una empresa privada, en cuanto se popularizó, muchas empresas empezaron a fabricar productos compatibles con el protocolo, por lo que la autoría de los dispositivos originales quedó difuminada, y ahora, hablar de X10 es hablar del protocolo, no de la empresa escocesa originaria.

7.2 TECNOLOGÍA X10:

El protocolo X10 intenta resolver la complicada situación de comunicar dos dispositivos que no cuentan con un cableado directo entre ellos. Los dispositivos, conectados a la red eléctrica, siempre tienen un posible canal de comunicación a través del cableado de la propia red, pero no es un canal directo. Así que la misión - 58 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO del protocolo es definir cuál será el formato de los mensajes binarios entre los dispositivos, como se enviarán dichos mensajes a través de la red, y como harán los dispositivos para mantenerse sincronizados y ser capaces de detectar los mensajes transportados por la red eléctrica. La forma de enviar los datos, que tienen formato binario, consiste en transmitir pequeños pulsos de 120 Khz y de 1 ms de duración justo en el momento en que la senoidal de la red pasa por cero. Conformar la trama binaria que un dispositivo envía a otro no es la parte complicada de este protocolo. La característica que lo hace remarcable, es el método para sincronizar los dispositivos conectados a la red eléctrica, y que así puedan enviar y entender correctamente las tramas binarias que viajan por ella. Todos los módulos X10 tienen un detector de paso por cero integrado que les permite saber el momento exacto en que la senoidal eléctrica alterna su valor positivo con su valor negativo, o viceversa. Ello permite sincronizarse a los módulos X10, los emisores saben cuándo enviar un bit y los receptores cuando puede llegarles uno, tan sólo deben esperar al paso por cero de la senoidal.

Ilustración 35:Sincronización de los módulos X10 (Web)

Debe destacarse que los módulos X10 no saben la diferencia entre alternancia de valor positivo a negativo, o alternancia de valor negativo a positivo, su detector de paso por cero tan sólo les permite saber lo que indica su nombre, el momento en

- 59 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO que la senoidal pasa por cero. Por otra parte, conocer como es la alternancia de la senoidal no es necesario para aplicar el protocolo, tan sólo importa detectar el paso por cero.

Si se tiene en cuenta que en Europa la senoidal eléctrica tiene una frecuencia de 50 hz, el periodo y el semiperiodo de dicha senoidal serán:

Estos datos son importantes porque nos dicen que un receptor X10 debería detectar el paso por cero cada 10 ms, por lo que cada 10 ms, el receptor está abierto a recibir posible información. En un periodo de la senoidal, el receptor se abriría dos veces, lo que significa que en 1 segundo lo está haciendo 100 veces. Así se podría seguir, en un minuto el receptor se abre 6000 veces, en una hora 360.000 veces, en un día 8.640.000 veces, en un año 3.153.600.000, y así…

Ilustración 36: Ventana de búsqueda de señal (Web)

Por lo tanto, cada 10 ms cuando el voltaje tiene valor nulo, los receptores buscan indicios de pequeños pulsos de RF con una holgura de 0.6 ms, es decir, dejan de - 60 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO buscar posibles pulsos tras pasar 0.6 desde la detección del paso por cero. Los emisores por su parte, están diseñados para enviar en el momento exacto del paso por cero los pulsos con una duración de 1ms como ya se mencionó. En la siguiente imagen se muestran el tiempo mencionado de un pulso y la máxima holgura posible del detector de paso por cero.

Ilustración 37: Gráfico de pulso y holgura (Web)

Por su parte, en esta imagen se muestran los 200 microsegundos que hay como máximo de holgura entre el detector de paso por cero del emisor y el detector del receptor.

- 61 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 38: Holgura máxima de 200 microsegundos (Web)

Respecto a la definición de los bits, el 1 y el 0 binarios se representan mediante presencias y ausencias de pulsos tal y como se aprecia en la siguiente figura:

Ilustración 39: Gráfico de presencias y ausencias de pulsos (Web)

El 1 binario se define como una presencia de pulso seguida por una ausencia de pulso, mientras que el 0 binario se define como una ausencia de pulso seguida por una presencia de pulso.

- 62 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

7.3 ESTRUCTURA DE LAS TRAMAS DE BITS:

Antes de empezar con la estructura de las tramas, es necesario aclarar que los módulos X10 cuentan con una dirección formada por una letra a la que se le añade un número. Tanto para la representación binaria de las letras, como para la representación binaria de los números, se disponen de 4 bits. Un conjunto de 4 bits suponen 16 posibilidades, por lo que tenemos 16 posibles letras, cada una englobando 16 posibles números. Esto nos da un total de 256 posibles direcciones para el protocolo X10.

Las tramas de bits que se describen en este apartado pueden ser de dos tipos: direccionamiento y comando. Las tramas de direccionamiento sirven para que el mensaje sea atendido sólo por el receptor deseado, mientras que los comando son las órdenes que debe aplicar dicho receptor.

Todas las tramas de bits X10 tienen un patrón de inicio que consiste en al menos 6 pasos por cero “limpios” (sin detección de pulsos), seguidos del código de inicio: pulso, pulso, pulso y ausencia de pulso.

Ilustración 40: Patron de inicio de trama X10 (Web)

Una vez se ha transmitido el código de inicio, se envía el primer nibble (un “nibble” son 4 bits o medio byte). Dicho nibble representa el código de letra de una unidad X10. - 63 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 41: Ejemplo de niblle (Web)

Si nos fijamos en los códigos binarios de las letras de la imagen veremos que no siguen el patrón lógico esperado, la A no es el primer código de una progresión binaria. Esto se debe a que se decidió reordenar aleatoriamente los códigos para no caer en un patrón predecible. Aun así, es fácil observar que el código de la letra M es el primero de una progresión binaria.

Siguiendo con la estructura de una trama de bits X10, el segundo nibble representaría la segunda parte de la dirección del módulo X10, un número. Recordemos que los dispositivos X10 se direccionan mediante una letra y un número.

Ilustración 42: Direccionamiento dispositivos X10 (Web)

Acompañando a este segundo nibble, siempre encontraremos un bit de más. Este bit se denomina bit de función, y cuando tiene valor 0 significa que el nibble que le precede representa un código de número, y por tanto, forma parte de la

- 64 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO dirección de un módulo X10. Por eso, si nos fijamos en los códigos binarios de los números de la imagen, el bit más significativo siempre es un 0. El estándar X10 obliga a que cada trama se envié dos veces, de esta forma se asegura que la trama llegue al receptor correctamente.

Ilustración 43: Las tramas se envían dos veces en el estándar X10 (Web)

Entre tramas de bits con contenido distinto o con propósitos distintos (por ejemplo una trama de direccionamiento y una trama de comando), siempre debe haber al menos 6 pasos por cero limpios. Estas 6 ausencias de pulsos el receptor los entiende como una secuencia de 6 ceros que le obligan a resetear sus registros de desplazamiento.

Ilustración 44: 6 ceros limpios entre tramas con distinto contenido (Web)

- 65 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO Respecto a las tramas de bits que representan comandos, los receptores están preparados para recibirlas una vez han procesado sus propias tramas de direccionamiento. Como en el caso de las tramas de direccionamiento, las tramas de comando deben empezar con un código de inicio similar al ya mencionado. Entonces, el primer nibble representa la letra del módulo X10, y el segundo nibble representa el comando. Este segundo nibble también es acompañado por un bit de función. Si antes en el direccionamiento el bit de función era un 0, aquí el bit de función siempre es un 1. Un bit de función de valor 1 indica que el nibble que le precede representa un código de comando X10. Por ello, todos los códigos binarios de comando acaban en 1. Bit función

Código

0

Direccionamiento

1

Comando Tabla 4: Valores Bit Función

En la siguiente figura se puede observar el nibble de comando y el código binario de los comandos X10 más típicos:

Ilustración 45: Nibble de comando y código binario típico (Web)

Como en el caso de la trama de direccionamiento, las tramas de comando también se envían dos veces. Todos los emisores X10 envían sus tramas dos veces. - 66 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 46: Envío duplicado de tramas (Web)

En la siguiente imagen, se muestra el ejemplo de una transmisión de dos tramas de bits, una de direccionamiento y otra de comando. Además, como siempre en el X10, cada trama se envía dos veces. La trama de ejemplo de la figura es la siguiente: A1 A1 A-ON A-ON.

La transmisión de las dos tramas junto con sus repeticiones requieren 47 periodos de la senoidal eléctrica de 50 hz, lo que hacen un total de 0.94 s, es decir, no llega al segundo. Por lo tanto, los receptores deberían reaccionar en menos de un segundo.

A veces, los receptores reaccionan incluso antes de los 0.94 s, pues recordemos que ese tiempo incluye las tramas que se envían por segunda vez, cuando muchas veces es suficiente con la primera trama para que el receptor reaccione. Además, también hay comandos que requieren menos tiempo que los 0.94 s para su transmisión, como por ejemplo, el comando “All-Lights-ON”, que no requiere direccionamiento.

- 67 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 47: Comando “All-Lights-ON” (Web)

Aun así, el tiempo de transmisión expuesto resulta lento en términos de protocolos de comunicaciones digitales. El protocolo X10, como otros protocolos domóticos tales como el Zigbee, no resulta muy veloz. Sin embargo, para las aplicaciones domóticas que se le dan, ello no supone un problema; al fin y al cabo, como acabamos de ver, nuestros actuadores van a reaccionar en menos de un segundo.

7.4 ENFOQUE TRIFÁSICO:

En los apartados anteriores al explicar las transmisiones sólo se hacía referencia a una senoidal, ya que para dar una explicación del protocolo, es más sencillo y fácil de entender si se hace en monofásico. Realmente, los módulos X10 para transmitir deben enviar 3 pulsos sincronizados con los pasos por ceros de las 3 senoidales trifásicas, tal y como se aprecia en la siguiente figura.

Ilustración 48: Envío de 3 pulsos (Web)

- 68 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 49: Envío de 3 pulsos – continuación- (Web)

De igual manera, los módulos también están preparados para detectar pulsos en los pasos por cero de las 3 senoidales. Este enfoque trifásico se tiene en cuenta en la librería de X10 usada para programar el microcontrolador Arduino, obligando al micro a producir pulsos para cada una de las fases. De esta forma, se consigue que nuestro controlador X10 funcione tanto cuando se le conecta a un cableado monofásico, como cuando el cableado es trifásico.

- 69 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

7.5 RESUMEN CÓDIGOS X10:

En las siguientes imágenes se encuentran resúmenes de las direcciones y comandos X10:

Ilustración 50: Tabla de direcciones y comandos X10 (Web)

- 70 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 51: Tabla de direcciones y comandos X10 – detalle (Web)

7.6 X10 RF

Existen productos compatibles con el protocolo X10 que también usan la radiofrecuencia, productos tales como el dispositivo TM13. La estructura del protocolo X10 de radiofrecuencia es la siguiente:

- 71 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 52: Trama RF X10

La trama de bits comienza con un pulso de inicio más largo que el resto. Los 0s y 1s se diferencian por tener un tiempo entre flancos de subida distinto, siendo más largo los de los 1s. Estas tramas de RF X10 se asemejan a las del protocolo NEC de infrarrojos, de hecho, los tiempos que aparecen en la imagen son del protocolo NEC, los de la RF X10 son un poco distintos:   

El pulso inicial del X10 es de 8.8 ms, seguido por un silencio de 4.4 ms. La distancia entre flancos de subida del 1 son 2.2 ms. La distancia entre flancos de subida del 0 son 1.1 ms.

La mayoría de los dispositivos X10 de RF repiten esta tramas en sus mensajes 5 veces con silencios de 40 ms entre ellas.

- 72 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 8 RESULTADOS 8.1 LOS TRES DRIVER-BLOCKS

8.1.1 DRIVER-BLOCK OREGON

Ilustración 53:Driver Oregon

- 73 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

8.1.2 DRIVER-BLOCK X10

Ilustración 54: Driver X10

- 74 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

8.1.3 DRIVER-BLOCK X10 RF

Ilustración 55: Driver X10 RF

- 75 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

8.2 DISPLAY OREGON

Ilustración 56: display Oregon

8.3 CAPTURAS OSCILOSCOPIO X10 RF

En las siguientes capturas de osciloscopio se pueden comprobar que se cumplen los tiempo descritos en el apartado de radiofrecuencia del X10.

- 76 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

8.3.1 CERO BINARIO

Ilustración 57: Cero RF

- 77 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

8.3.2 UNO BINARIO

Ilustración 58: Uno RF

- 78 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

8.3.3 INICIO TRAMA

Ilustración 59: Starter RF

- 79 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

8.3.4 SILENCIO DE INICIO DE TRAMA

Ilustración 60: Valle RF

- 80 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 9 COMPONENTES HARDWARE

Ilustración 61: OREGON Thermo-Hygro

- 81 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 62: MARMITEX Transceiver Module y Mando a distancia

- 82 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 63: MARMITEX Transceiver Module (parte posterior) y Mando a distancia

- 83 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 64: MARMITEK CM11 y XM10FL

- 84 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 65: MARMITEK CM11 y XM10FL (parte posterior)

- 85 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 66MARMITEK Appliance Module

- 86 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 67: MARMITEK Lamp Module

- 87 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 68: Placa ARDUINO MEGA

- 88 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 69: Placa ARDUINO MEGA y LCD Keypad

- 89 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Ilustración 70: CEBEK emisor (C-0503) y receptor (C-0504N)

- 90 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 10 FUTUROS DESARROLLOS 10.1 DRIVER-BLOCK OREGON

El driver del sensor Oregon nunca llegó a funcionar del todo. Tras varias indagaciones se llegó a la conclusión de que era un problema de timers generado por Simulink a la hora de cargar el ejecutable en el Arduino. Al parecer, el timer usado por Simulink a la hora de cargar el ejecutable, entraba en conflicto con el usado por una interrupción necesaria para el funcionamiento del driver. Se intentó sustituir el timer usado por la interrupción, pero aún así el Driver-Block seguía sin funcionar. Queda como futuro desarrollo averiguar el motivo por el que el driver no es capaz de actuar.

10.2 SPI

El SPI es un protocolo de comunicaciones. Se pensaba usar para comunicar el Arduino con la Raspberry Pi. Para ello, habría sido necesario un Driver-Block más que gobernara dicha comunicación.

- 91 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

BIBLIOGRAFÍA [1]

http://es.wikipedia.org/wiki/Internet_de_las_Cosas

[2]

http://en.wikipedia.org/wiki/Smart_grid

[3]

“Best global Brands” http://brandirectory.com/league_tables/table/global-5002013

[4]

“Google learn from previous failures on the smart home” http://www.ft.com/intl/cms/s/0/e37ff3f6-7ddb-11e3-b40900144feabdc0.html?siteedition=uk#axzz2sEeDTIMX

[5]

“Domótica” http://es.wikipedia.org/wiki/Dom%C3%B3tica

[6]

“Which Technology” http://www.smarthome.com/sh-learning-center-whattechnology.html

[7]

http://www.idobartana.com/hakb/

[8]

http://blog.oscarliang.net/arduino-timer-and-interrupt-tutorial/

[9]

http://jeelabs.net/projects/cafe/wiki/Decoding_the_Oregon_Scientific_V2_protoc ol#Validation

[10]

http://ucexperiment.wordpress.com/2012/03/16/examination-of-the-arduinomillis-function/

- 92 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO [11]

http://www.righto.com/2009/07/secrets-of-arduino-pwm.html

[12]

http://www.maximintegrated.com/en/app-notes/index.mvp/id/4439

[13]

Progrese con VISUAL C++ de David J. Kruglinski

- 93 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Parte II ESTUDIO ECONÓMICO

- 94 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 1 ESTUDIO ECONÓMICO Durante la implementación del proyecto se ha constatado la viabilidad técnica de la solución propuesta y su fiabilidad, por tanto, ahora nos focalizamos en el estudio de su rentabilidad económica. Partiendo de las siguientes premisas: 

Saber cuál ha de ser la inversión inicial del kit domótico o Coste HW para implementación

o Coste implementación

o Coste comercialización

- 95 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO 

Saber cuál va a ser el coste fijo anual



Saber cuál es el coste por kit domótico

Llegamos a las siguientes conclusiones: 

El proyecto global costaría de 3 fases: o Año 2014: Implementación y Verificación o Año 2015: Comercialización por internet o Año 2016 y sucesivos: Venta y distribución

Durante el primer año, se precisa hacer una inversión de 110.724,00 € Y, a partir de ahí, los costes medios anuales serían de unos 22.090 €.

- 96 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Como el coste medio del kit domótico es de 484 €

Aplicando un margen del 35,212% a cada kit, es decir, cobrando por cada kit domótico, 100€, habría que vender un mínimo de 2.000 kits en 3 años para cubrir los gastos fijos, tener 23.010,16 € de beneficio y recuperar la inversión realizada.

Por tanto el ROI (Return Of Investment) en este caso es positivo y aconseja totalmente realizar la operación de inversión lanzando al mercado este kit.

- 97 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Parte III CÓDIGO FUENTE

- 98 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

En esta parte de la memoria se presentan los códigos fuente de todas las librerías usadas para la programación de los 3 Driver-Blocks. Al haberse reciclado código principalmente de fuentes de habla inglesa, la mayoría de los comentarios están en inglés. Muchos de ellos son los comentarios originales, pues se mantuvieron ya que facilitaban en gran medida el entendimiento del código; otros de los comentarios han sido escritos por el proyectista, pero también se redactaron en inglés.

- 99 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

Capítulo 1 OREGON 1.1 OSV3DECODER.H

#ifndef OSV3Decoder_h #define OSV3Decoder_h #include "WConstants.h" class DecodeOOK { protected: byte total_bits, bits, flip, state, pos, data[25]; virtual char decode (word width); public: enum { UNKNOWN, T0, T1, T2, T3, OK, DONE }; DecodeOOK (); bool nextPulse (word width) bool isDone () const; const byte* getData (byte& count) const; void resetDecoder (); // add one bit to the packet data buffer virtual void gotBit (char value); // store a bit using Manchester encoding void manchester (char value); // move bits to the front so that all the bits are aligned to the end void alignTail (byte max =0); void reverseBits (); void reverseNibbles (); void done (); }; class OregonDecoderV3 : public DecodeOOK { public: OregonDecoderV3();

- 100 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO // add one bit to the packet data buffer virtual void gotBit (char value); virtual char decode (word width); }; #endif

1.2 OSV3DECODER.CPP

#include "WConstants.h" #include "OSV3Decoder.h"

char DecodeOOK::decode (word width) =0; DecodeOOK::DecodeOOK () { resetDecoder(); } bool DecodeOOK::nextPulse (word width) { if (state != DONE) switch (decode(width)) { case -1: resetDecoder(); break; case 1: done(); break; } return isDone(); } bool DecodeOOK::isDone () const { return state == DONE; } const byte* DecodeOOK::getData (byte& count) const { count = pos; return data; } void DecodeOOK::resetDecoder () { total_bits = bits = pos = flip = 0; state = UNKNOWN; } // add one bit to the packet data buffer void DecodeOOK::gotBit (char value) { total_bits++; byte *ptr = data + pos; *ptr = (*ptr >> 1) | (value = 8) { bits = 0; if (++pos >= sizeof data) { resetDecoder(); return; } } state = OK; } // store a bit using Manchester encoding void DecodeOOK::manchester (char value) { flip ^= value; // manchester code, long pulse flips the bit gotBit(flip); } // move bits to the front so that all the bits are aligned to the end void DecodeOOK::alignTail (byte max =0) { // align bits if (bits != 0) { data[pos] >>= 8 - bits; for (byte i = 0; i < pos; ++i) data[i] = (data[i] >> bits) | (data[i+1] Check_Rcvr(); } void x10_Parse_Frame_wrapper() { object->Parse_Frame(); }

void x10::init(int zeroCrossingPin, int dataPin, int rp, int led) { led_pin=led; rcve_pin = rp; if (led_pin>0) { pinMode(led_pin, OUTPUT); } this->zeroCrossingPin = zeroCrossingPin; // the zero crossing pin this->dataPin = dataPin; // the output data pin // Set I/O modes: pinMode(this->zeroCrossingPin,INPUT); // set 20K pullup (low active signal) pinMode(this->dataPin, OUTPUT); // for receive zcross_pin = zeroCrossingPin; if (rp>0) { pinMode(rcve_pin,INPUT); // receive X10 commands low = 1 - INPUT_PULLUP sets 20K pullup (low active signal)

- 107 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO pinMode(zcross_pin,INPUT); square wave

// zero crossing - 60 Hz

attachInterrupt(0,x10_Check_Rcvr_wrapper,CHANGE);// (pin 2) trigger zero cross X10BitCnt=0; // counts bit sequence in frame ZCrossCnt=0; // counts Z crossings in frame X10rcvd=false; // true if a new frame has been received _newX10=false; // both the unit frame and the command frame received } } x10::x10(int zeroCrossingPin, int dataPin, int rp, int led) { init(zeroCrossingPin,dataPin,rp,led); } x10::x10(int zeroCrossingPin, int dataPin, int rp) { init(zeroCrossingPin,dataPin,rp,0); } x10::x10(int zeroCrossingPin, int dataPin) { init(zeroCrossingPin,dataPin,0,0); } /* Writes an X10 command out to the X10 modem */ void x10::write(byte houseCode, byte numberCode, int numRepeats) { byte startCode = B1110; // every X10 command starts with this if (rcve_pin>0) { detachInterrupt(0); } // repeat as many times as requested: for (int i = 0; i < numRepeats; i++) { // send the three parts of the command: sendBits(startCode, 4, true); sendBits(houseCode, 4, false); sendBits(numberCode, 5, false); } // if this isn't a bright or dim command, it should be followed by // a delay of 3 power cycles (or 6 zero crossings): if ((numberCode != BRIGHT) && (numberCode != DIM)) { waitForZeroCross(this->zeroCrossingPin, 6); } if (rcve_pin>0) { attachInterrupt(0,x10_Check_Rcvr_wrapper,CHANGE); } // (pin 2) trigger zero cross } /* Writes a sequence of bits out. If the sequence is not a start code, it repeats the bits, inverting them. */

- 108 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO void x10::sendBits(byte cmd, byte numBits, byte isStartCode) { byte thisBit; // copy of command so we can shift bits // iterate the number of bits to be shifted: for(int i=1; izeroCrossingPin, 1); // shift off the last bit of the command: thisBit = !!(cmd & (1 dataPin, thisBit); delayMicroseconds(BIT_LENGTH); // clear the data pin: digitalWrite(this->dataPin, LOW); delayMicroseconds(BIT_DELAY); } // if this command is a start code, don't // send its complement. Otherwise do: if(!isStartCode) { // wait for zero crossing: waitForZeroCross(zeroCrossingPin, 1); for (int phase = 0; phase < 3; phase++) { // set the data pin: digitalWrite(this->dataPin, !thisBit); delayMicroseconds(BIT_LENGTH); // clear the data pin: digitalWrite(dataPin, LOW); delayMicroseconds(BIT_DELAY); } } } } /* waits for a the zero crossing pin to cross zero */ void x10::waitForZeroCross(int pin, int howManyTimes) { unsigned long cycleTime = 0; // cache the port and bit of the pin in order to speed up the // pulse width measuring loop and achieve finer resolution. calling // digitalRead() instead yields much coarser resolution. uint8_t bit = digitalPinToBitMask(pin); uint8_t port = digitalPinToPort(pin); for (int i = 0; i < howManyTimes; i++) { // wait for pin to change:

- 109 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO //Serial.println("wait for pin to change:"); if((*portInputRegister(port) & bit)){ //Serial.println("dentro if"); while((*portInputRegister(port) & bit)){ cycleTime++; } } else{ //Serial.println(" dentro else"); while(!(*portInputRegister(port) & bit)) { cycleTime++; } } } //Serial.println("waitForZeroCross acabada"); //Serial.println(cycleTime); } /* version() returns the version of the library: */ int x10::version(void) { Serial.print(this->zeroCrossingPin); Serial.print(" "); Serial.print(this->dataPin); Serial.print(" "); Serial.print(rcve_pin); Serial.print(" "); Serial.println(led_pin); return 4; } boolean x10::received(void) { return _newX10; } void x10::reset(void) { _newX10 = false; } byte x10::unitCode(void) { return _unitCode; } byte x10::houseCode(void) { return _houseCode; } byte x10::uc(void) { return _uc; }

- 110 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO byte x10::hc(void) { return _hc; } byte x10::cmndCode(void) { return _cmndCode; } void x10::Check_Rcvr(){ // ISR - called when zero crossing (on CHANGE) if (X10BitCnt == 0) { // looking for new frame delayMicroseconds(OFFSET_DELAY); // wait for bit if(digitalRead(rcve_pin)) return; // still high - no start bit - get out if (led_pin>0) { digitalWrite(led_pin, HIGH); } // indicate you got something rcveBuff = 0; mask = 0x1000; // bitmask with bit 12 set rcveBuff = rcveBuff | mask; // sets bit 12 (highest) mask = mask >> 1; // move bit down in bit mask X10BitCnt = 1; // inc the bit count ZCrossCnt = 1; // need to count zero crossings too return; } // Begins here if NOT the first bit . . . ZCrossCnt++; // inc the zero crossing count // after SC (first 4 bits) ignore the pariety bits - so only read odd crossings if (X10BitCnt < 5 || (ZCrossCnt & 0x01)){ // if it's an odd # zero crossing delayMicroseconds(OFFSET_DELAY); // wait for bit if(!digitalRead(rcve_pin)) rcveBuff = rcveBuff | mask; // got a 1 set the bit, else skip and leave it 0 mask = mask >> 1; // move bit down in bit mask X10BitCnt++; if(X10BitCnt == 13){

// done with frame after 13

bits for (byte i=0;i0) { digitalWrite(led_pin, LOW); } // indicate you got something X10BitCnt = 0; x10_Parse_Frame_wrapper(); // parse out the house & unit code and command } } }

- 111 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO #if 1 void x10::Parse_Frame() { // parses the receive buffer to get House, Unit, and Cmnd if(rcveBuff & 0x1){ // last bit set so it's a command _cmndCode = rcveBuff & 0x1F; // mask 5 bits 0 - 4 to get the command _newX10 = true; // now have complete pair of frames } else { // last bit not set so it's a unit _unitCode = rcveBuff & 0x1F; // mask 5 bits 0 - 4 to get the unit _uc = _unitCode; _newX10 = false; // now wait for the command for (byte i=0; i> 5; // shift the house code down to LSB _houseCode = rcveBuff & 0x0F; // mask the last 4 bits to get the house code _hc = _houseCode; for (byte i=0; i> 4; // shift the start code down to LSB startCode = rcveBuff & 0x0F; // mask the last 4 bits to get the start code X10rcvd = false; // reset status } #else // NEW VERSION - better error checking void Parse_Frame() { // parses the receive buffer to get House, Unit, and Cmnd // Remember this is called by ISR - so STILL IN ISR! - no delays or prints! byte rawCmndUnit; // Command or Unit portion of rcveBuff byte rawHouse; // House portion of rcveBuff byte foundMatch = false; // set when a match is found

- 112 -

UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO INDUSTRIAL

PROYECTO DE FIN DE GRADO

// break the rcveBuff into it's parts if(rcveBuff & 0x1) procCmnd = true; is a command (2nd) else procCmnd = false; (1st) rawCmndUnit = rcveBuff & 0x1F; the unit / command rcveBuff = rcveBuff >> 5; down to LSB rawHouse = rcveBuff & 0x0F; get the house code rcveBuff = rcveBuff >> 4; down to LSB X10.Start = rcveBuff & 0x0F; get the start code

. . . // last bit set so frame // else frame is a unit // mask 5 bits 0 - 4 get // shift the house code // mask the last 4 bits to // shift the start code // mask the last 4 bits to

// start with the House code - SB the same for both frames for (byte i=0; i