de control y monitoreo de a través de Internet con USB”

Ingeniería en Comunicaciones y Electrónica IPN

Instituto Politécnico Nacional

Escuela Superior de Ingeniería Mecánica y EléctricaZacatenco

“Sistema de control y monitoreo de dispositivos a través de Internet con

USB”

T E S I S

Q U E P A R A O B T E N E R E L T Í T U L O D E :

INGENIERO EN COMUNICACIONES Y ELECTRÓNICA

P R E S E N T A N

Edgar Moreno Segura Jesús Jovanni Victoria Corona

Asesores:

Ing. Armando Mancilla León

M. en C. Roberto Galicia Galicia

MÉXICO, D.F. 2009

Sistema de control y monitoreo de dispositivos a través de Internet con USB 2009

Agradecimientos

Agradecimientos

A mis padres Jesús y Cecilia por el gran apoyo que siempre me han proporcionado, en las buenas y en las malas. Gracias, por todos sus esfuerzos y consejos los cuales me han guiado hacia este camino en el que he logrado el primer gran paso de mi vida. Espero que este logro también lo consideren de ustedes. Gracias papás por tener todas esas actitudes que me dan el ánimo de continuar superándome, y resolver cualquier problema que se me presente.

A los profesores el M. en C. Roberto Galicia Galicia y el Ing. Armando Mancilla León, por su constante asesoría y apoyo en la realización de este trabajo.

Jesús Jovanni Victoria Corona

A mis padres, porque gracias a su incondicional apoyo logré realizar uno de mis grandes sueños.

Al profesor M. en C. Roberto Galicia Galicia y el Ing. Armando Mancilla León que no dudaron en ofrecernos todos sus conocimientos a la hora de realizar este trabajo.

Edgar Moreno Segura


i

Índice

Índice

Objetivos ....................................................................................................................................................... v

Descripción general. .................................................................................................................................... vi

Justificación ................................................................................................................................................. vii

Panorama general del trabajo ................................................................................................................... viii

Capítulo 1 Control de periféricos .................................................................................................................. 1

1.1 Conexión de periféricos ...................................................................................................................... 1

1.1.1 Interfaz serie ................................................................................................................................ 2

1.2 Microcontroladores .......................................................................................................................... 10

Capítulo 2 Envío de datos a través de la red ............................................................................................... 12

2.1 Introducción a Internet ..................................................................................................................... 12

2.2 Protocolos de comunicación ............................................................................................................. 13

2.2.1 Modelo de referencia OSI .......................................................................................................... 13

2.2.2 Protocolo TCP/IP ........................................................................................................................ 15

2.2.3 Protocolo UDP ............................................................................................................................ 17

2.3 Puertos .............................................................................................................................................. 18

2.4 Direcciones IP .................................................................................................................................... 19

2.4.1 Direcciones IP públicas y privadas ............................................................................................. 22

2.4.2 Asignación estática y dinámica de una dirección IP .................................................................. 23


ii

Índice

2.5 Dominios y DNS ................................................................................................................................. 24

2.6 Paradigma Cliente – Servidor ............................................................................................................ 25

2.7 Sockets .............................................................................................................................................. 25

2.8 Control Winsock ............................................................................................................................... 28

2.8.1 Propiedades ............................................................................................................................... 28

2.8.2 Métodos ..................................................................................................................................... 30

2.8.3 Eventos ....................................................................................................................................... 30

Capítulo 3 Materiales .................................................................................................................................. 32

3.1 Software de desarrollo ...................................................................................................................... 32

3.1.1 Visual Studio C# 2008 ................................................................................................................. 32

3.1.2 Compilador CCS .......................................................................................................................... 32

3.1.3 WinPic800 .................................................................................................................................. 33

3.1.4 LiveWire y PCB Wizard ............................................................................................................... 33

3.2 Hardware de desarrollo. ................................................................................................................... 33

3.2.1 Programador GTP USB Lite ........................................................................................................ 33

3.3 Microcontrolador PIC 18F2550 ................................................................................................... 34

3.4 Cámara IP .................................................................................................................................... 35

Capítulo 4 Desarrollo de las aplicaciones Cliente y Servidor ...................................................................... 36

4.1 Instalación del Servidor ..................................................................................................................... 37

4.2 Comunicación entre nuestras aplicaciones ...................................................................................... 39


iii

Índice

4.3 Descripción de la aplicación Cliente .................................................................................................. 41

4.3.1 Panel de conexión ...................................................................................................................... 43

4.3.2 Panel de controles ..................................................................................................................... 44

4.3.3 Panel de ubicación de dispositivos ............................................................................................ 51

4.4 Clase AplicacionCliente, ................................................................................................................ 52

4.5 Descripción de la aplicación Servidor ............................................................................................... 54

4.5.1 Panel de datos del Servidor ................................................................................................ 55

4.5.2 Panel de Mensajes ..................................................................................................................... 56

4.5.3 Estado de la conexión ................................................................................................................ 57

4.5.4 Panel de Conexión ..................................................................................................................... 58

4.6 Comunicación USB ............................................................................................................................ 59

4.6 Conexión con el Servidor .................................................................................................................. 64

4.7 Envío de datos ................................................................................................................................... 66

4.8 Recepción de datos ........................................................................................................................... 68

Capítulo 5 .................................................................................................................................................... 70

Sistema electrónico de comunicaciones ..................................................................................................... 70

5.1 Introducción ...................................................................................................................................... 70

5.2 Sistema electrónico de comunicaciones ........................................................................................... 74

5.2.1 Comandos de control y comandos de monitoreo ..................................................................... 76

5.2.2 Módulo de control ..................................................................................................................... 80


iv

Índice

5.2.3 Módulo de monitoreo .............................................................................................................. 131

5.2.4 Diseño de las antenas utilizadas en las comunicaciones inalámbricas .................................... 153

Estudio económico .................................................................................................................................. 156

Pruebas y resultados ................................................................................................................................. 161

Conclusiones ............................................................................................................................................. 163

Apéndice A. Librería para USB: MPUSBAPI.DLL ....................................................................................... 167

Apéndice B. Códigos, aplicaciones Cliente y Servidor .............................................................................. 172

Apéndice C. Circuitos impresos ................................................................................................................ 192

BIBLIOGRAFÍA ........................................................................................................................................ 199

Índice de figuras .................................................................................................................................. 2000

Glosario ................................................................................................................................................... 2055

v

Objetivos

Objetivos

General:

Desarrollar un sistema que permita a un usuario controlar y monitorear dispositivos a distancia.

Particulares:

• Enviar información de control entre dos equipos (Cliente y Servidor) a través de Internet, que permita manipular dispositivos.

• Explotar las funciones de un microcontrolador para lograr transmitir y recibir datos a través de la interfaz USB.

• Lograr la comunicación inalámbrica (RF) entre el Servidor y los dispositivos controlados y monitoreados.

• Hacer uso del programa Visual Studio 2008 para desarrollar aplicaciones capaces de comunicarse a través de una red.


vi

Descripción general

Descripción general.

El proyecto consiste, en un sistema que permitirá el control y monitoreo de dispositivos, a través de una

red, por medio de una aplicación para Windows. Es decir, como se muestra en la figura 1.1, el cliente

podrá controlar dispositivos, como demostración, en este proyecto únicamente se utilizaron focos, sin

embargo, pueden controlarse diversos dispositivos. También el usuario, a través de una aplicación

Windows llamada Cliente, podrá saber cuál es el estado de los dispositivos que está controlando, si

éstos se encuentran encendidos o apagados. Por otra parte, también se podrán monitorear ciertos

dispositivos, como puede observarse en la figura 1.1, en donde se ilustran algunos tipos de detectores,

sin embargo en nuestro proyecto, no se implementaron estos dispositivos, sino que éstos, serán

solamente simulados, por medio de interruptores.

Figura 1 Diagrama del general del proyecto


vii

Justificación

Justificación

Se decidió realizar este proyecto, pues día con día, crece más la necesidad de tener el control a

distancia de algún sistema, por ejemplo en el área de domótica, en el área industrial, en robots,

etcétera. Así el sistema que desarrollamos, puede ser implementado en varios sistemas,

particularmente enfocamos el proyecto al área de domótica, pues en la actualidad, debido a

que las personas están menos tiempo en el hogar, ya sea por que se encuentra de viaje o por

cuestiones de trabajo, surge la necesidad de tener un control sobre ciertos dispositivos, sin

tener que estar presentes.

Si tenemos un control a distancia de iluminación, por ejemplo, se podrá dar la impresión de que

en nuestro hogar se encuentra alguien, y así nuestro hogar no será tan vulnerable a un robo. Un

ejemplo que podemos dar aplicado al monitoreo de dispositivos es, que cuando se active la de

intrusión, se le indique al usuario inmediatamente y se active una alarma, esto puede ayudar, a

prevenir robos.

Así es posible dar varios ejemplos, de las distintas aplicaciones que se le pueden dar al sistema

desarrollado para este proyecto, lo que le da gran versatilidad, ya que puede ser ajustado según

las necesidades que se tengan.


viii

Panorama general del trabajo


A continuación, se presenta un resumen de cada uno de los capítulos que conforman el presente

trabajo, con el fin de tener un panorama general del sistema que se pretende desarrollar.

Capítulo 1 Control de periféricos

Este capítulo sirve de introducción teórica a los dispositivos periféricos, se habla sobre la interfaz serial,

el modo en que se transmite la información hacia los periféricos, se describen las características del Bus

Serie Universal USB y por último son mencionadas las características de los microcontroladores y como

éstos sirven para conectar periféricos a la PC.

Capítulo 2 Envío de datos a través de la red

Las dos aplicaciones Windows (Cliente y Servidor) desarrolladas en este proyecto bajo el paradigma

Cliente – Servidor, transmiten datos a través de una red trabajando con el protocolo TCP. Este capítulo

tiene la intención de dar las bases teóricas para comprender la forma en cómo la información es

transmitida a través de la red y los protocolos que son utilizados según los requerimientos de los

sistemas. Además se habla de los sockets y el control Winsock (que es utilizado para el desarrollo del

proyecto), dos herramientas que los programadores utilizan para el desarrollo de aplicaciones que

intercambien datos en una red.

Capítulo 3 Materiales

Se da una descripción del material tanto de software como de hardware que es utilizado para realizar el

proyecto, este capítulo es por lo tanto, dividido en: software de desarrollo, en donde se describen los

paquetes software usados para el proyecto, hardware de desarrollo, que habla sobre las herramientas

físicas, el microcontrolador PIC 18F2550 junto con sus características y la cámara IP utilizada para el

monitoreo de los dispositivos.


ix


Capítulo 4 Desarrollo de las aplicaciones Cliente y Servidor

En este capítulo se describen las dos aplicaciones Windows desarrolladas para transmitir los datos, la

programación utilizada para su elaboración, cómo es transmitida la información entre ellas, las

interfaces de cada una de ellas y la forma en cómo el usuario podrá interactuar con las aplicaciones.

Capítulo 5 Sistema electrónico de comunicaciones

Aquí se hace una completa descripción del funcionamiento de los circuitos de transmisión y recepción

inalámbrica. Los microcontroladores son usados como codificadores y decodificadores de señales y al

mismo tiempo para el control y monitoreo de los dispositivos.


1

Capítulo 1: Control de periféricos

Capítulo 1 Control de periféricos

En este capítulo, se expondrán las bases teóricas relativas a los dispositivos periféricos. Se hablará sobre

los estándares más importantes utilizados, para conectar dispositivos periféricos a un equipo, de la

importancia que tienen los microcontroladores en el desarrollo de periféricos, y además de la utilización

de sensores para la adquisición de datos.

1.1 Conexión de periféricos

Un equipo de cómputo, debe tener una comunicación con el mundo exterior, para así poder interpretar

y procesar datos que provengan de él. Es por ello, que los equipos cuentan con un sistema formado por

varios dispositivos periféricos, conocido como subsistema de Entrada/Salida. Este subsistema, hace

posible el intercambio de datos con el exterior, comunicándose con el procesador a través de una serie

de módulos, llamados de E/S. Estos módulos cuentan con controladores, que se encargan del

funcionamiento de los dispositivos periféricos.

Los módulos de E/S no conectan directamente al periférico con el bus del sistema, sino que lo hacen a

través de un conjunto de reglas que se conocen como interfaces, que permiten conectarse con el CPU y

la memoria, a través del bus del sistema y a la vez conectarse con los dispositivos periféricos, mediante

de enlaces dedicados para datos.

Las razones por las que los módulos E/S no conectan directamente al periférico con el bus, son:

1. No todos los dispositivos periféricos utilizan el mismo método de operación, y sería un problema

para el CPU el tener que manejar cada uno de los modos de operación, de la infinidad de

dispositivos que existen.


2


2. En la mayoría de los casos, la velocidad de transferencia que utilizan los dispositivos periféricos,

es menor que la que tiene el procesador para comunicarse con la memoria, por esto, no sería

conveniente usar el bus del sistema de alta velocidad, para comunicarse directamente con los

dispositivos.

3. Los periféricos pueden utilizar formatos y longitudes de palabra de datos, diferentes a los que

utiliza el procesador.

Como se mencionó anteriormente, se utilizan interfaces para comunicar al periférico con el procesador,

estas interfaces pueden ser de dos tipos, principalmente:

• Interfaz serie: En este tipo de interfaz, sólo se utiliza una sola línea para la transmisión de

datos.

• Interfaz paralela: Con esta interfaz se pueden trasmitir múltiples bits de forma simultánea,

debido a que se usan varias líneas de datos para la transmisión.

A continuación, se describirá más a fondo a la interfaz serie, ya que es con la que se trabaja en el

proyecto y se verán ejemplos de los estándares que hacen uso de ella.

1.1.1 Interfaz serie

Este tipo de interfaz es utilizada en los equipos, para conectar múltiples dispositivos como módems,

ratones, impresoras, etc.

La transmisión de los datos se da a través de un solo canal y es bit por bit, esto puede ser de manera

síncrona o asíncrona.

Si se utilizan señales adicionales (reloj o señales de petición y reconocimiento), para indicar cuándo el bit

siguiente es válido, entonces se dice que la transmisión se realiza de forma síncrona. La principal ventaja

de este tipo de transferencias, es que el receptor puede funcionar a varias frecuencias de reloj (siempre

que no sobrepase su frecuencia máxima de funcionamiento). En las transferencias asíncronas, por el

contrario, tanto el receptor como el transmisor deben funcionar a la misma frecuencia. En este caso, se

envía también información de sincronización a través de la línea de datos, un bit de comienzo (bit de


3


start), que indica el comienzo de una unidad de datos, un bit de fin (bit de stop), indicando su

finalización y, opcionalmente, un bit de paridad para controlar los posibles errores.

1.1.1.1 Interfaz RS232

RS‐232, es el nombre del interfaz de comunicación serie más utilizado del mundo. La norma serie está

disponible en prácticamente el 99% de los ordenadores. La norma RS‐232, fue originalmente diseñada

para conectar terminales de datos con dispositivos de comunicación, como módems. Desde un principio,

fue también utilizada para conectar casi cualquier dispositivo imaginable. Los usos de la RS‐232 en el

entorno doméstico son muchos y ampliamente conocidos. Desde la conexión del ratón, el módem/fax,

agendas electrónicas de bolsillo, impresoras serie, grabadores de memoria, etc.

El estándar define voltajes que oscilan entre + [3‐15] V para el nivel alto y – [3‐15] V para el nivel bajo.

Debido a la gran diferencia de voltaje que existe entre los niveles altos y bajos, se permiten tasas de

transferencia de hasta 115.200 baudios si la longitud del cable es de unas pocas decenas de metros.

1.1.1.2 Bus Serie Universal: USB

Para entender el funcionamiento del USB, es necesario estudiar la especificación de este bus. Los

fabricantes involucrados en la norma, crearon un documento que constituye la referencia. Aunque en

estos momentos se está creando la versión 3.0 del bus, en el presente capítulo se va a tratar la versión

2.0, ya que es la más rápida y es la que posee la familia de PICs 18Fxx5x.

El USB se trata de un estándar (1995), que define un bus utilizado para la conexión de periféricos al

ordenador. La conexión es muy sencilla, ya que se utiliza un único conector para conectar a través de un

bus serie todos los dispositivos. Se implementa una topología especial tipo estrella para conectar hasta

127 dispositivos, e implementa protocolos que permiten la detección y configuración automática de los

dispositivos que son conectados.


4


USB 1.0 puede trabajar con dos tasas de transferencia diferentes, una baja de 1.5 Mbps para la conexión

de dispositivos lentos (joysticks, ratones), y otra alta de hasta 12 Mbps, para dispositivos que requieren

un mayor ancho de banda (Discos Duros o CD‐ROMS).

La especificación de este estándar, ha sido respaldada por las empresas líderes mundiales en el campo

de la informática: Intel, IBM, DEC, Microsoft, Compac y NEC, empresas que garantizan su continuidad y

utilización.

A mediados del año 2000, aparece la versión 2.0, ésta fue creada por un conjunto de compañías, entre

ellas y además de las arriba mencionadas, se encuentran: Hewlett Packard, Lucent y Philips. USB 2.0,

multiplica la velocidad del bus por un factor de 30 o 40, esto hace que pueda alcanzar una velocidad de

480 Mbps. Esta versión, es compatible con su antecesora y utiliza el mimo tipo de cable y conectores,

únicamente se necesitan nuevos hubs que soporte esta versión. Estos hubs, son más complejos que los

anteriores, ya que tienen que manejar el tráfico de datos de tres velocidades diferentes, sin ser

excluyentes entre ellas.

Anteriormente los periféricos, se conectaban mapeados directamente en direcciones de E/S, se les

asignaba una dirección específica y en algunos casos un canal DMA (Acceso Directo a Memoria). Esta

situación causaba conflictos a la hora de la asignación de estos recursos. Además, cada dispositivo podía

tener su propio puerto de conexión y usaba cables específicos, esto incrementaba el costo de los

mismos. Debido a que a cada dispositivo se le tenían que asignar ciertos recursos, la detección del

mismo, debía hacerse a la hora de arrancar el sistema y nunca se podía incorporar un nuevo dispositivo,

cuando el sistema ya estaba trabajando.

Los dos aspectos fundamentales que motivaron la creación del estándar USB, fueron la necesidad de

que la configuración de los periféricos fuese más sencilla, y la necesidad de aumentar el número de

puertos disponibles.

Como se mencionó anteriormente, el estándar USB define una topología de conexión en estrella, en la

figura 1.1 se muestra por medio de la incorporación de varios concentradores (hubs), conectados en


5


serie esta conexión. Esta topología permite a muchos dispositivos, conectarse a un único bus lógico, sin

que los dispositivos que se encuentran más abajo en la pirámide sufran retardo.

Figura 1. 1 Topología de la conexión USB

El sistema USB consta de tres componentes, principalmente:

1. Controlador

El Controlador reside dentro del PC y es responsable de las comunicaciones entre los periféricos USB y la

CPU del PC. Es también responsable de la admisión de los periféricos dentro del bus, tanto si se detecta

una conexión, como una desconexión. Para cada periférico añadido, el controlador determina su tipo y

le asigna una dirección lógica, para utilizarla siempre con el mismo periférico. Si se producen errores

durante la conexión, el controlador lo comunica a la CPU, que a su vez, lo transmite al usuario. Una vez

que la conexión se ha realizado correctamente, el controlador asigna al periférico, los recursos del

sistema que éste precise para su funcionamiento.

El controlador también es responsable, del control de flujo de datos entre el periférico y la CPU.

2. Concentradores o hubs


6


Cada concentrador se conecta por un lado al equipo y por el otro se conecta a un dispositivo o a un

concentrador. Es posible encontrar dispositivos periféricos que vengan con conectores USB

incorporados, para así añadir nuevos dispositivos, en total se pueden tener hasta 127 dispositivos

conectados y todos pueden funcionar al mismo tiempo. La función principal de los concentradores, es la

de permitir ampliar el número de dispositivos conectados a un equipo. El concentrador tiene la

capacidad de detectar, cuando un dispositivo es conectado o desconectado de uno de sus puertos, y

esto lo notifica al controlador de USB. Igualmente un concentrador, sirve de acoplamiento entre

dispositivos que no tengan la misma velocidad.

3. Periféricos

USB soporta periféricos de baja y media velocidad. Empleando dos velocidades para la transmisión de

datos, que pueden ser de 1.5 y 12 Mbps. Los periféricos de baja velocidad tales como teclados, ratones,

joysticks, y otros periféricos para juegos, no requieren 12 Mbps, empleando para ellos 1.5 Mbps, con

esto se pueden dedicar más recursos del sistema a periféricos, tales como monitores, impresoras,

módems, scanner, equipos de audio, etc., que precisan de velocidades más altas para transmitir mayor

volumen de datos.

A nivel eléctrico, el cable USB transfiere la señal y la alimentación sobre cuatro hilos. Dos líneas para la

transmisión de datos y otras dos para transmitir potencia (ver figura 1.2). Los cables de datos (D+ y D‐)

son un par trenzado para reducir el ruido y las interferencias.

Figura 1. 2 Líneas en cable USB

A nivel de señal, se trata de un par tranzado con una impedancia característica de 90Ω. La velocidad

puede ser de 480Mbps, 12Mbps ó 1.5Mbps. La señal se transmite de manera codificada, para esto se

utiliza un código auto reloj de no retorno a cero invertido (NRZI), lo que permite transmitir junto con los

datos, la información de sincronización.


7


A nivel de alimentación, el cable proporciona la tensión nominal de 5V. Es necesario definir bien el

diámetro del hilo, con el fin de que no se produzca una caída de tensión demasiado importante en el

cable. Una resistencia de terminación instalada en la línea de datos, permite detectar el puerto y

conocer su configuración (1.5Mbps ó 12Mbps), si no lleva resistencia, indica 480Mbps.

Existen dos tipos de conectores (A y B), con el fin de evitar la configuración en bucle. El tipo A es plano y

rectangular, mientras que el tipo B es cuadrado. La base para el tipo A se encuentra en el PC o hub y en

el periférico, una base de tipo B. Los cables son de tipo A‐B. En la figura 1.3 se muestran estos dos tipos

de conectores, junto con su configuración.

Figura 1. 3 Tipos de conector USB

Para comenzar la transferencia, el controlador USB envía un paquete que identifica al dispositivo. El protocolo soporta cuatro tipos de transferencia:

• Tipo Control

Los datos de control, sirven para configurar al periférico en el momento en que éste es conectado al

USB. Algunos drivers específicos, pueden utilizar este enlace para transmitir su propia información de

control.

• Tipo Bulk

Este modo se utiliza para la transmisión de cantidades importantes de información. La banda de paso

otorgada a este tipo de transmisión, depende de los demás periféricos, siendo la menos prioritaria. Este

tipo de transferencia es utilizada por scanners e impresoras.


8


• Tipo Interrupción

Este tipo de transmisión, garantiza la transferencia de pequeñas cantidades de datos. El tiempo de

respuesta no puede ser inferior al valor especificado por la interfaz. El ratón o cualquier otro dispositivo

apuntador, es una aplicación típica de este modo de transmisión.

• Tipo Isócrona

Utilizado para la transmisión de información con ancho de banda y latencia grantizados, necesario para

aplicaciones como audio, telefonía y video. Permite una comunicación periódica y continua entre el

sistema y el dispositivo.

1.1.1.3 FireWire, estándar IEEE 1394

Apple y Sony inventaron el FireWire a mediados de los 90, y lo desarrollaron hasta convertirlo en el

estándar multiplataforma IEEE 1394. FireWire, es una tecnología para la entrada/salida de datos en serie

a alta velocidad, y la conexión de dispositivos digitales como videocámaras o cámaras fotográficas

digitales, que ha sido ampliamente adoptado por fabricantes de periféricos digitales como Sony, Canon,

JVC y Kodak.

FireWire es uno de los estándares de periféricos más rápidos que se han desarrollado, característica

que lo hace ideal para su uso con periféricos del sector multimedia (como cámaras de vídeo), y otros

dispositivos de alta velocidad como, por ejemplo, lo último en unidades de disco duro e impresoras. Se

ha convertido en la interfaz preferida de los sectores de audio y vídeo digital, ya que reúne numerosas

ventajas, entre las que se encuentran la elevada velocidad, la flexibilidad de la conexión y la capacidad

de conectar un máximo de 63 dispositivos. Además de cámaras y equipo de vídeo digital, la amplia gama

de productos FireWire, comprende reproductores de vídeo digital, sistemas domésticos para el ocio,

sintetizadores de música, escáneres y unidades de disco duro.


9


Con un ancho de banda 30 veces mayor que el conocido estándar de periféricos USB 1.1, el FireWire 400

se ha convertido en el estándar más respetado para la transferencia de datos a alta velocidad. Apple fue

el primer fabricante de ordenadores, que incluyó FireWire en toda su gama de productos. Una vez más,

Apple ha vuelto a subir las apuestas, duplicando la velocidad de transferencia con su implementación

del estándar IEEE 1394b o FireWire 800.

La velocidad sobresaliente del FireWire 800, frente al USB 2.0, convierte al primero en un medio mucho

más adecuado, para aplicaciones que necesitan mucho ancho de banda, como las de gráficos y vídeo,

que a menudo consumen cientos o incluso miles de megabytes de datos por archivo.

Algunas de las características más importantes del FireWire, son:

• Flexibles opciones de conexión. Admite un máximo de 63 dispositivos con cables de hasta 4.25

metros.

• Distribución en el momento. Fundamental para aplicaciones de audio y vídeo, donde un

fotograma que se retrasa o pierde la sincronización, arruina un trabajo.

• Alimentación por el bus. Mientras el USB 2.0 permite la alimentación de dispositivos sencillos

que consumen un máximo de 2.5 W, como un ratón, los dispositivos FireWire pueden

proporcionar o consumir hasta 45 W, más que suficiente para discos duros de alto rendimiento

y baterías de carga rápida.

• Es conectable/desconectable en uso. Lo que significa que no se necesita desactivar un

dispositivo para conectarlo o desconectarlo, y que no es necesario reiniciar el ordenador.

• Funciona tanto con Mac como con PC. Lo que garantiza la compatibilidad con una larga lista de

productos con FireWire, a precios razonables


10


1.2 Microcontroladores

Un microcontrolador, es un circuito integrado programable, que se utiliza para el gobierno de uno o

varios procesos. Una vez programado y configurado el microcontrolador, éste solamente sirve para

controlar la tarea, para la que fue programado.

Dentro de un microcontrolador, se tienen encapsulados todos los componentes que hay en una

computadora: procesador, memoria de datos y memoria de instrucciones, oscilador de reloj interno,

módulos de entrada/salida. Las líneas de entrada/salida, soportan la conexión de los sensores y

actuadores del dispositivo que se desea controlar.

Además de los elementos que se mencionaron anteriormente, existen una serie de recursos especiales

que los fabricantes algunas veces ofrecen, por ejemplo: ampliar las capacidades de las memorias, otros

incorporan nuevos recursos y hay quienes reducen las prestaciones al mínimo, para aplicaciones muy

simples. Algunos de los principales recursos, que un fabricante puede ofrecer, son:

Conversores AD y DA.

Comparadores analógicos.

Estado de bajo consumo.

Puertos de E/S digital.

Temporizadores (Timers).

Protección frente a fallo de alimentación (Brown‐out).

Perro guardián (Watchdog).

Modulador de anchura de pulsos PWM.

Puertos de comunicación: serie, USB, I2C, UART, etc.

En la actualidad, el uso del microcontrolador cada vez se ha hecho más popular, pues son utilizados en

teclados, ratones, electrodomésticos, sistemas de alarmas, en sistemas de comunicaciones, en la

industria, en automóviles, teléfonos celulares, etc. En la figura 1.4 se muestra una gráfica comparativa

del uso del microcontrolador en diversas áreas.


11


Figura 1. 4 Principales usos del microcontrolador

Los principales fabricantes de microcontroladores, son: Microchip, Motorola, Nacional Semiconductor,

Atmel, Siemens, Philips, Intel, Hitachi, entre otros. En este proyecto, se utilizarán microcontroladores, de

la familia PIC, de Microchip.

Principales usos del microcontrolador

33%

25%

16%

16%

10%Periféricos

Electrodomésticos

Comunicaciones

Industria

Automóviles


12

Capítulo 2: Envío de datos a través de la red

Capítulo 2 Envío de datos a través de la red

Para nuestro proyecto, pretendemos realizar un software de comunicación que constará de dos

aplicaciones Windows, una que actuará como Servidor y la otra que será el Cliente, por lo tanto es

importante que se comprendan aspectos teóricos, como los protocolos de comunicación TCP/IP y UDP,

lo que son las direcciones IP, el concepto de dominio, el servicio DNS, cómo se da la comunicación a

través de Internet y por último los métodos utilizados por los programadores para implementar

aplicaciones que se comuniquen a través de una red, como lo son los sockets y el control Winsock.

Entonces, este capítulo nos ayudará a comprender la forma en que los paquetes viajan de un equipo a

otro, ya sea a través de una red local o a través de la red de redes, que es Internet.

El conjunto de conceptos que a continuación se explican, es muy importante manejarlos para

comprender la comunicación, que pretendemos hacer entre un equipo que esté en nuestro hogar, y

otro que se localice en cualquier parte del mundo.

2.1 Introducción a Internet

Internet, se puede ver como una red gigante formada por redes más pequeñas, que están conectadas

unas con otras, esta conexión permite la comunicación a grandes distancias, ya que actualmente existen

redes distribuidas en todo el mundo. En cada una de estas redes, hay una computadora que el usuario

utiliza para introducirse a ese gigantesco mundo que es Internet.

Una conexión a Internet depende de otros parámetros, tanto para realizarla como para mantenerla, si

alguno de estos parámetros dejara de funcionar, la conexión no sería correcta, estos parámetros son:


13


1. La conexión física. Nos referimos con esto a la conexión que la PC tiene con la red, mediante un

cable y la tarjeta de red o un módem.

2. La conexión lógica. Aquí entran los protocolos, que son reglas establecidas para la comunicación

entre dispositivos dentro de una red. Para Internet, el protocolo usado es TCP/IP, del cual

hablaremos más adelante.

3. Aplicaciones. Es a través de las aplicaciones, que el usuario puede visualizar la información que

fue procesada, y trabajan junto con los protocolos, para lograr la transmisión y recepción de

datos a través de Internet.

2.2 Protocolos de comunicación

Hablando específicamente en términos de Tecnologías de la Información (IT), un protocolo1 es un

conjunto de reglas que determina los procedimientos que deben seguirse, para transmitir o recibir

información. Se puede decir que un protocolo es un lenguaje usado, para lograr que dos computadoras

puedan entenderse una con otra. Haciendo una analogía con el mundo real, es como cuando dos

personas de diferentes países tratan de comunicarse, si no hablan el mismo idioma, entonces no podrán

entenderse y por lo tanto, no habrá intercambio de información.

Para poder entender cómo es que trabajan los protocolos, hay que hablar un poco de lo que es el

modelo OSI, esto a su vez nos guiará al conjunto de protocolos TCP/IP, que tienen gran relación con el

modelo OSI.

2.2.1 Modelo de referencia OSI

Si queremos saber cómo es que trabajan las comunicaciones en las redes, debemos comenzar por

entender este tema. El problema es que muchas personas no saben el por qué de la existencia de este

modelo, ni cómo es que trabaja.

1 Del griego protocollon, que era una hoja de papel que describía el contenido de un manuscrito al cual venía pegado.


14


Cuando las redes de computadoras comenzaban a surgir, sólo una compañía se encargaba de

manufacturar toda la tecnología para las redes. Esto impedía que equipos de diferentes marcas

pudieran comunicarse entre sí.

Para solucionar este problema la Organización Internacional de Estándares (ISO), desarrolló un modelo

de referencia llamado OSI (Open Systems Interconnection), este modelo permitiría a todos los fabricantes

tener un conjunto de protocolos a seguir, y contar con un solo “lenguaje” para la comunicación a través

de las redes.

Este modelo puede usarse para visualizar, cómo la información, o paquetes de datos, viajan desde las

aplicaciones (hojas de cálculo, documentos, etc.), por un medio de red (por ejemplo los cables), hasta

otras aplicaciones que estén ubicadas en otra computadora de la red, aunque el emisor y el receptor

tengan diferentes tipos de medios de red.

Dos aplicaciones diferentes pueden ser compatibles, siempre y cuando sigan el modelo de referencia

OSI, haciendo los procesos correspondientes en el mismo orden. Esto permite a los desarrolladores de

software, comprender más fácilmente cómo es que trabajan.

El modelo OSI está formado por siete capas, cada una ilustrando una función de red en particular. La idea básica del modelo de referencia OSI, es ésta: cada capa está encargada de hacer cierto proceso, y sólo puede comunicarse con las capas inmediatamente superior e inferior, por ejemplo, la capa cuatro solo se puede comunicar con las capas cinco y tres.

Para que los paquetes de datos viajen desde un origen hasta el destino, cada capa del modelo OSI del

origen, debe comunicarse con la misma capa del destino. A este mecanismo de comunicación se le llama

comunicación de igual a igual (peer‐to‐peer). La información que es intercambiada durante este

proceso, recibe el nombre de unidad de datos del protocolo (PDU, Protocol Data Unit).

Cuando una computadora transmite datos a través de la red, la capa correspondiente recibe los datos

de una capa superior, los procesa, le agrega información de comunicación, y envía el paquete con la

nueva información añadida a la capa de abajo.


15


Cuando la computadora recibe datos, ocurre el proceso contrario: la capa recibirá los datos de una capa

inferior, procesa lo que está recibiendo, elimina el control de información que le corresponde, y envía el

nuevo paquete a la capa superior.

En la figura 2.1, se observa la posición de las capas del modelo de referencia OSI. Los programas sólo se

comunican con la séptima capa, la capa de aplicación, es la capa más cercana al usuario. En nuestro

proyecto, estos programas serán las aplicaciones cliente y servidor, mediante las cuales el usuario

controlará los periféricos.

Figura 2. 1 Capas del modelo OSI

2.2.2 Protocolo TCP/IP

Para la realización de nuestro proyecto, debemos tomar en cuenta un conjunto de reglas para nuestro

programa de comunicación, este conjunto de reglas forman a un protocolo. El protocolo que es la base

de Internet es TCP/IP (Transmission Control Protocol/Internet Protocol), este protocolo garantiza que

una PC que emplea un programa de comunicaciones bajo TCP/IP, se pueda comunicar con otro

ordenador de diferente marca que también lo haga.

Internet es una red informática estructurada, lo que quiere decir que la comunicación a través de ella,

requiere de varias capas, y en cada parte de la comunicación se emplea un protocolo distinto. A TCP/IP

lo integran dos protocolos distintos:


16


• TCP (Protocolo de control de Transmisión), es el protocolo de transporte, y su función es

mantener la conexión entre los ordenadores, de manera que ésta no se pierda, todo esto a nivel

físico.

• IP (Protocolo de Internet), es el protocolo de encaminamiento, encargado de depositar los

paquetes de datos en las direcciones correspondientes, de la manera más eficiente posible.

También se ocupa de segmentar y reagrupar los datos que componen cada paquete

transmitido2.

En la figura 2.2, se comparan las arquitecturas del modelo OSI y la de TCP/IP, como podemos ver, TCP/IP

solo cuenta con cuatro capas. En la capa de Aplicación podemos encontrar varios protocolos, como son:

SMTP (para e‐mail), FTP (para transferencia de datos) y HTTP (para buscadores web). Cada programa se

comunica con un protocolo diferente, ya que no todos realizan la misma función.

Figura 2. 2 Comparación entre modelo OSI y TCP/IP

Una vez que la información es procesada, el protocolo usado en la capa de Aplicación se comunica con

la siguiente capa, que es la de Transporte, específicamente con el protocolo TCP. En esta capa se forman

2 Internet, La Biblia Edición 2006, Oscar Rodríguez Fernández EtAl. Ed. ANAYA


17


paquetes de información que son enviados a la capa de Internet, o si se está recibiendo, se encarga de

ordenar los paquetes y verificar que no tengan errores.

El protocolo de Internet (IP), se encuentra en la capa de Internet, en donde a los paquetes se les agregan

las direcciones virtuales de la computadora que envía, y de la que recibirá la información, estas

direcciones son conocidas como direcciones IP, de las cuales hablaremos en nuestro siguiente tema. Los

paquetes formados son enviados a la siguiente capa, la capa de red, en donde los paquetes ya son

llamados datagramas.

La capa de red envía los paquetes a través de la red, o los recibe en el caso de que la computadora sea la

receptora. Lo que hay dentro de esta capa, va a depender del tipo de red que se esté usando, el tipo de

red que más se utiliza hoy en día, es Ethernet.

Internet cuenta además con una capa en su nivel más alto, que es la capa de Aplicación, en ella están

definidos los servicios que le han dado la importancia que tiene la red: HTTP, FTP, WWW, E‐Mail, etc.

Cuando se quiere revisar un e‐mail, se hace una petición al servidor que los almacena, esta tarea es

llevada a cabo por la capa de Aplicación, específicamente usando el protocolo SMTP. Cuando en nuestro

navegador escribimos “www”, para buscar alguna página, el navegador (Internet Explorer, Fire Fox,

Google Chrome, etc.), deja ésta tarea a la capa de aplicación, en donde se hará uso del protocolo HTTP.

Hablemos un poco más de la capa de Aplicación, ya que en ella se llevan a cabo muchas tareas que

tienen estrecha relación con nuestro proyecto, y que nos ayudarán a comprender mejor, conceptos que

se manejan durante el desarrollo de nuestro software de comunicación.

2.2.3 Protocolo UDP

Hay otro protocolo llamado UDP (User Data Protocol, protocolo de datos de usuario), que igualmente

trabaja en la capa de Transporte, pero que a diferencia de TCP, éste no establece una conexión previa

con el otro extremo para transmitir, los paquetes pueden llegar desordenados, duplicados e incluso con

errores, por tales motivos, las aplicaciones deben ser programadas de manera que actúen como el

protocolo TCP, ya que los paquetes pueden llegar en forma incorrecta.


18


Al igual que TCP, los puertos en UDP sirven para identificar los puntos terminales de las máquinas origen

y destino. Muchas aplicaciones utilizan UD, para evitarse el establecer y luego liberar una conexión con

esto, la transmisión es más rápida. UDP sólo trabaja con las funciones básicas, debido a que se preocupa

más por que los datos se transfieran rápidamente. Tiene la desventaja de que carece de mecanismos de

seguridad, como los del protocolo TCP, poniendo en riesgo la transmisión de paquetes entre origen y

destino.

2.3 Puertos

La capa de aplicación, se va a comunicar con la capa de transporte a través de un puerto. Ciertas

aplicaciones utilizan siempre un mismo puerto para comunicarse, por ejemplo, el protocolo SMTP

siempre utiliza el puerto 25, HTTP utiliza siempre el puerto 80 y FTP el 20 para la transmisión de datos y

el 21 para control. En el siguiente capítulo, en el que se habla del desarrollo de nuestras aplicaciones

cliente y servidor, se volverá a tocar este tema, ya que nuestras aplicaciones también utilizan un puerto

para comunicarse.

Pero, ¿por qué es necesario el uso de puertos?, pues es gracias a ellos que el protocolo de transporte

TCP, sabe el tipo de contenido del paquete que se está enviando y así determinar, del lado de la

recepción, cuál protocolo de Aplicación se va a utilizar. Por ejemplo, si se recibe un paquete por el

puerto 25, el protocolo TCP sabrá que se trata de información que debe ser manejada utilizando el

protocolo SMTP, que a su vez entregará los datos al programa que lo requiera, en este caso el programa

que maneja e‐mail.


19


Figura 2. 3 Aplicaciones y sus puertos

Anteriormente se mencionó que el protocolo TCP en la capa de Transporte, cuando se están recibiendo

datos, éste ordena los paquetes provenientes de la capa de Internet (ya que pueden venir fuera de

orden), y además verifica que el contenido del paquete no tenga errores, una vez hecho esto, envía una

señal al transmisor, para que éste sepa que el paquete fue recibido satisfactoriamente, en caso de que

esta señal no sea enviada, ya sea porque el paquete no llegó a su destino o porque TCP encontró errores

en la información, el transmisor deberá reenviar el paquete.

2.4 Direcciones IP

En una red TCP/IP, cada computadora debe tener un identificador único, para que pueda comunicarse

con el resto de las computadoras de la red. Este identificador es conocido como dirección IP. Una

dirección IP es una secuencia de 32 bits, compuesta por unos y ceros, para nosotros los seres humanos

sería difícil trabajar de manera directa con este tipo de secuencias, así que para facilitar las cosas, son

escritas como cuatro números decimales entre cero y 255, separados por un punto.

Los números que conforman a la dirección IP son conocidos como octetos, y la forma de representarlos

se conoce como formato decimal con puntos. En la figura 2.4 se muestra una dirección IP (192.168.1.8)

representada en forma binaria y en forma decimal.


20


Figura 2. 4 Formato de una dirección IP

Una dirección IP está compuesta de dos partes, una parte nos dice la dirección de red y otra la dirección

host, en la figura 2.5 se muestra una dirección IP que tendría como dirección de red los dos primeros

bytes y los dos bytes restantes para la dirección host.

Figura 2. 5 Estructura de una dirección IP

Las direcciones IP están divididas en cinco clases, la clase a la que pertenece una determinada IP, va a

depender del bit o secuencia de bit al principio de cada dirección.

Direcciones Clase A

Este tipo de direcciones, son usadas para cuando se tienen muy pocas subredes y una gran cantidad de

host, esto debido a que sólo el primer octeto es utilizado para subred, y los tres restantes como parte

del host.

Cualquier dirección que comience con un número entre 1 y 126, es una dirección Clase A. En la figura 2.6

se muestra el formato de una dirección de este tipo.


21


Figura 2. 6 Dirección IP de Clase A

Direcciones Clase B

Las direcciones Clase B, se utilizan para redes de tamaño moderado a grande. Los dos primeros bits de

este tipo de direcciones siempre son 10, por lo tanto, el número más pequeño sería 128 y el más grande

191.Cualquier dirección que comience con un número que esté entre 128 y 191, es de Clase B. En la

figura 2.7 se muestra su formato.

Figura 2. 7 Dirección IP Clase B

Direcciones Clase C

Son utilizadas para muchas subredes con pocos equipos y son las que más se usan actualmente. Una

dirección Clase C tiene como primeros tres bits a 110, esto quiere decir, que si una dirección comienza

con un número entre 192, que sería el más pequeño que podría representarse y 223 que sería el más

grande, entonces pertenece a esta Clase. En la figura 2.8 se muestra su formato.

Figura 2. 8 Dirección IP Clase D

Direcciones Clase D y Clase E

Las direcciones de clase D son un grupo especial que se utiliza para dirigirse a grupos de máquinas. Estas

direcciones son muy poco utilizadas. Los cuatro primeros bits de una dirección de clase D, son 1110.


22


Las direcciones Clase E están reservadas por el Grupo de Ingeniería de Internet (IETF), para

investigaciones, por lo que no pueden ser utilizadas para Internet. Los primeros cuatro bits de estas

direcciones siempre son unos, por lo que su primer octeto siempre es un número entre 11110000 y

11111111, o entre 240 y 255.

2.4.1 Direcciones IP públicas y privadas

El organismo encargado de asignar las direcciones IP públicas, necesarias para comunicarse en Internet,

es la Autoridad de Números Asignados de Internet (IANA, Internet Assigned Numbers Authority). Una

empresa puede solicitar una o varias direcciones públicas con un proveedor de servicios Internet (ISP), a

quien le fue asignado cierto intervalo de direcciones IP. Las direcciones públicas son únicas, globales y

están normalizadas.

El número de direcciones IP públicas no es infinito, y debido a que éste tipo de direcciones son usadas

para poder comunicarse a través de Internet, resultaría un problema tener que asignar una dirección

por cada equipo conectado. Una de las soluciones a este problema, son las direcciones privadas, las

cuales son utilizadas para redes privadas que no están conectadas a Internet (esto no significa que no lo

puedan hacer). Las direcciones IP privadas están establecidas en la RFC 1918, en la que se reservan tres

bloques de direcciones IP, una dirección Clase A, un intervalo de direcciones Clase B y otro intervalo de

direcciones Clase C.

• 10.0.0.0 con la máscara de subred 255.0.0.0



Una IP privada puede utilizarse por ejemplo, para una red casera, y en caso de que ésta red se conecte a

Internet, estas direcciones privadas deben convertirse en públicas, esta conversión se denomina

Conversión de direcciones de red (NAT, Network Address Translation), y es ejecutada normalmente por

un router.


23


2.4.2 Asignación estática y dinámica de una dirección IP

Hay dos método básicos para poder asignar la dirección IP a un equipo: direccionamiento estático y

direccionamiento dinámico.

Cuando el administrador de la red asigna a cada dispositivo una dirección única para que sea

identificado, se habla de un direccionamiento estático, ya que ésta dirección asignada nunca cambia

para ese dispositivo. Un ejemplo sería un servidor web, el cual debe mantener su misma dirección IP,

para que las páginas que aloja estén disponibles todo el tiempo, ya que si esta dirección cambiara cada

vez que el servidor fuese encendido, los usuarios no podrían acceder a él.

Otros ejemplos de dispositivos que deben mantener una dirección estática, son las impresoras de red,

los servidores de aplicaciones y los routers.

Si la dirección de IP de un dispositivo cambia cada determinado tiempo, entonces el tipo de asignación

es dinámico. El Protocolo de configuración dinámica del host (DHCP), permite al host obtener una

dirección dinámicamente. Para poder usar DHCP se necesita un servidor DHCP, el cual debe contener un

cierto rango de direcciones a asignar. Cuando un host desea conectarse, hace una petición al servidor

DHCP, para que se le asigne una dirección IP que lo identifique, el servidor selecciona una dirección y la

asigna a ese host.

Un ejemplo de DHCP lo podemos encontrar en nuestro hogar, cada vez que encendemos nuestra

máquina e intentamos conectarnos a Internet, puede ser que nuestra dirección IP no sea la misma que

teníamos un día anterior, esto se debe a que el proveedor de Internet para no utilizar una IP fija por

cada cliente, realiza una asignación dinámica, lo que hace que se cuente con una IP durante cierto

tiempo y cambie después, sucede lo mismo, si apagamos el router (que es el dispositivo que

generalmente tenemos en nuestros hogares) y lo encendemos, la IP cambiará.


24


2.5 Dominios y DNS

Los dispositivos o equipos que se conectan a Internet, deben ser identificados como ya dijimos por una

dirección IP, sin embargo, memorizar este tipo de direcciones, resultaría complicado para las personas.

Un dominio de Internet es un “representante” de una dirección IP, que facilita al usuario el poder tener

acceso a algún recurso dentro de Internet.

Para una persona es mucho más fácil recordar la dirección www.google.com y teclearla en su

navegador, que aprenderse la dirección 74.125.45.147. Es posible comprobar lo anterior haciendo un

ping a la dirección web, esto nos regresará su equivalente en dirección IP.

En Internet, hay una gran cantidad de dominios (más de 200), como por ejemplo:

• .gt, para servicios de Guatemala

• .mx, para servicios de México

• .cl, para servicios de Chile

• .co, para servicios de Colombia

• .cn, para servicios de China

• .edu, para servicios de Educación

• .eu, la región de Europa

• .gob, para Gobierno y Entidades Públicas

• .info, para Información

• .net, para Infraestructura de red

• .org, para organizaciones

DNS es un sistema utilizado en Internet para asociar nombres de domino a direcciones IP. Cuando un

cliente en una red introduce un nombre de domino, el servidor DNS responde a la petición y traduce

este dominio en su correspondiente dirección IP, una vez que hace esto, regresa el resultado al cliente.


25


2.6 Paradigma Cliente – Servidor

En una red cliente – servidor, hay un equipo especial en donde se almacenan todos los servicios de la

red, este equipo atiende las solicitudes de otros equipos, que pueden ser archivos, impresiones,

aplicaciones y otros servicios, los primeros son llamados servidores, y los que hacen las peticiones son

los clientes.

Un servidor debe estar continuamente esperando por solicitudes de los clientes, por lo que se debe de

tratar con un equipo con características especiales, como más poder de procesamiento, memoria y

software especializado, esto también depende de los procesos que realice, pues podemos contar con un

servidor con características no tan poderosas, pero que puede servir como un servidor web, por

ejemplo.

Para que haya una comunicación, los servidores deben contar con una IP fija y deben estar

“escuchando” a través de sus puertos, para que el cliente sabiendo estos parámetros, se pueda conectar

a él. Una vez que el cliente hace la petición a través de un puerto del servidor, éste realiza el servicio

requerido y devuelve los resultados en forma de una respuesta (Figura 2.9).

Figura 2. 9 Interacción Cliente ‐ Servidor

2.7 Sockets

Junto con Internet, surgió la necesidad de comunicar aplicaciones a través de esta red, esta necesidad

dio origen a los sockets. Un socket es el punto final de una conexión. Un socket se utiliza como un


26


método de comunicación entre las aplicaciones cliente y un servidor, que intercambian datos en forma

fiable y ordenada, son un componente básico de comunicación, ya que proporcionan una comunicación

de dos vías, punto a punto entre dos procesos.

Se requieren tres elementos para poder crear un socket:

1. Un protocolo de comunicaciones

2. Una dirección IP

3. Un número de puerto

Funcionamiento

Una aplicación servidor utiliza un socket con un número de puerto específico. La aplicación cliente debe

conocer el nombre del equipo servidor (hostname) o dirección IP, y el puerto a través del cual está

escuchando la aplicación servidor.

Cuando la aplicación cliente hace una petición al servidor para conectarse y éste acepta, la aplicación

servidor debe abrir un nuevo socket con un puerto diferente, para poder atender otras peticiones

mientras atiende al cliente actual. Una vez conectados, las dos aplicaciones pueden comunicarse

leyendo o escribiendo en sus respectivos sockets.

A continuación se mostrará en forma general cómo serían un programa cliente y uno servidor con TCP y

utilizando el lenguaje C# que es el que será usado para diseñar nuestras aplicaciones del proyecto.

Para programar un servidor sencillo con sockets, se requieren cinco pasos. Primero hay que crear un

objeto de la clase TcpListener del espacio de nombres System.Net.Sockets, esta clase se usa para crear

un socket a través del cual nuestro servidor estará escuchando de forma indefinida por peticiones del

cliente, lo anterior se escribiría como sigue:

TcpListener ObjServidor = new TcpListener (direcciónIP, puerto)


27


Como segundo paso hay que hacer que nuestro objeto creado en el paso anterior empiece a escuchar,

esto se hace llamando al método Start de TcpListener. Cuando el servidor recibe una petición del

cliente, este crea una conexión mediante el método AcceptSocket de la clase TcpListener el cual

devuelve un objeto Socket al momento de la conexión.

Socket Conexion = ObjServidor.AcceptSocket();

El tercer paso consiste en establecer el flujo de la información entre el cliente y el servidor utilizando un

objeto NetworkStream que a su vez utiliza al objeto Conexion para realizar el envío y la recepción de

datos.

Con el objeto NetworkStream podemos crear un BinaryWriter y un BinaryReader, que son usados para

enviar y recibir información entre los programas cliente y servidor.

El cuarto paso consiste en la comunicación entre el cliente y el servidor mediante la conexión

establecida en el paso anterior.

El quinto paso es la terminación de la conexión mediante la utilización del método Close de

BinaryReader, BinaryWriter, NetworkStream y Socket para dar fin a la conexión.

Para la programación del cliente se deben seguir cuatro pasos básicos. El primero de ellos es crear un

objeto de la clase TcpClient y con este objeto llamamos al método Connect de TcpClient para establecer

la conexión, esto sería como sigue:

TcpClient ObjCliente = new TcpClient();

ObjCliente.Connect( disreccionServidor, puertoServidor );

El Segundo paso consiste usar el método GetStream mediante el uso del objeto ObjCliente, para obtener

un objeto NetworkStream, para que pueda haber operaciones de lectura y escritura con el servidor. Al

igual que del lado del cliente, debemos crear un objeto BinaryWriter y un objeto BinaryReader para

poder enviar información hacia el servidor y recibir información desde el servidor.


28


El tercer paso es el de procesamiento, en donde se utiliza el método Write de BinaryWriter y el método

ReadString de BinaryReader para realizar la comunicación. Por último paso tenemos que cerrar la

conexión llamando al método Close de BinaryReader, BinaryWriter, NetworkStream y TcpClient.

2.8 Control Winsock

El control Winsock (su nombre proviene de Windows Sockets), permite conectar dos aplicaciones a

través de una red, ya sea en una red LAN o como en nuestro caso, a través de Internet. Este control

puede funcionar con el protocolo UDP o con TCP, ambos pueden ser usados para desarrollar

aplicaciones cliente‐servidor.

El control Winsock no tiene una interfaz visible en tiempo de ejecución, esto es, cuando nuestras

aplicaciones se estén ejecutando, el usuario no verá el ícono del control.

El control Winsock, al igual que cualquier otro control, cuenta con una serie de propiedades, métodos y

eventos que hacen mucho más fácil la programación, a diferencia de programar aplicaciones utilizando

sólo sockets, ya que no es necesario establecer el tamaño de los paquetes o formar los encabezados. A

continuación se describen las propiedades, métodos y eventos más importantes de este control, y con

los cuales trabajaremos para programar nuestras aplicaciones cliente y servidor.

2.8.1 Propiedades

LocalIP

Esta propiedad nos devuelve la dirección IP de la máquina, en donde se está ejecutando nuestra

aplicación.

LocalHostName

Muestra el nombre que tiene la máquina en donde se ejecuta la aplicación, ya sea el nombre del

servidor o del cliente.


29


RemoteHost

Con esta propiedad se establece el equipo remoto con el que se quiere llevar a cabo una conexión.

LocalPort

Establece el puerto a través del cual se estarán escuchando peticiones entrantes, por lo tanto, esta

propiedad es utilizada en la aplicación servidor.

RemotePort

Esta propiedad es programada del lado del cliente, ya que mediante ella se establece el puerto por el

cual el cliente se conectará el servidor.

LocalPort y RemotePort deben ser exactamente iguales, pues como vimos en el capítulo anterior, es a

través del puerto, que el servidor sabe a qué aplicación dirigirse luego de recibir una petición a través de

él.

State

Nos informa del estado del control Winsock, si este está siendo utilizado o no.

Para poder hacer uso de las propiedades del control Winsock, debemos crear un objeto del mismo, y a

través de éste acceder a la propiedad y por último asignarle un valor. La sintaxis es mostrada a

continuación:

Objeto.Propiedad = Valor

Nota: EL objeto puede ser el nombre del control Winsock, que siempre es WinSock1, este nombre es el

que utilizamos en nuestras aplicaciones.

Por ejemplo, si quisiéramos saber la IP de nuestra máquina y mostrarla en una etiqueta (Label1), en

nuestra aplicación, el código sería el siguiente:


30


Label1.Text = WinSock1.LocalIP

2.8.2 Métodos

Accept

Sólo se utiliza para aplicaciones servidor que se basen en TCP, y es usada para aceptar una conexión

entrante en un evento ConnectionRequest.

GetData

Obtiene el dato que fue enviado a la aplicación, ya sea al cliente o al servidor, este método nos es de

gran utilidad en nuestras aplicaciones, pues nos permitirá procesar los datos que enviemos.

Listen

Con este método lo que se hace, es crear un socket que esté en modo de escucha, para que el servidor

se ponga a escuchar por peticiones de los clientes.

SendData

Gracias a este método podemos enviar nuestros datos al equipo remoto.

2.8.3 Eventos

Ahora pasaremos a describir los eventos más importantes que utilizamos para nuestras aplicaciones.

ConnectionRequest

Sin este evento la comunicación entre nuestras aplicaciones no se podría llevar a cabo, ya que éste se

produce cuando el equipo remoto solicita una conexión.

Connect


31


Se produce cuando el equipo local se conecta con el remoto, para establecer una comunicación.

Close

Se produce cuando el equipo remoto cierra la conexión. Es importante que nuestras aplicaciones cierren

las conexiones TCP, una vez que dejan de transmitir información, para que posteriormente otras

conexiones sean hechas.

DataArrival

Este evento se produce cuando llegan datos nuevos y es importante, ya que aquí es donde vamos a

decidir qué hacer con la información que estamos recibiendo. En nuestro caso, esta información es

enviada a la interfaz USB del servidor, para que sea procesada por el Microcontrolador.

En la figura 2.10, se muestran las propiedades, métodos y eventos, que de manera general se utilizan

para programar aplicaciones cliente y servidor, sin embargo, en el proyecto hay métodos y eventos que

se utilizan, tanto del lado del cliente como del servidor.

Figura 2. 10 Propiedades, Métodos y Eventos del control Winsock


32

Capítulo 3: Materiales

Capítulo 3 Materiales

En este capítulo, se describirán brevemente los materiales utilizados para el desarrollo del proyecto, esto incluye tanto herramientas de software, como material hardware.

3.1 Software de desarrollo

Las herramientas de desarrollo que se utilizan, son: Visual Studio C# 2008, el compilador de C para PICs

PCW versión 4.65.4.13 de CCS, WinPic800, LiveWire y PCB Wizard. A continuación, se dará una breve

explicación de la utilidad de estas herramientas, y sus principales características.

3.1.1 Visual Studio C# 2008

Microsoft Visual C# 2008, proporciona un editor de código avanzado, permite diseñar interfaces de

usuario de forma rápida y sencilla, además cuenta con un depurador integrado y muchas herramientas,

que hacen más fácil el desarrollo de aplicaciones basadas en la versión 2.0 del lenguaje C#, y en .NET

Framework.

Juntos, Visual Studio y .NET Framework reducen la necesidad de código, los tiempos de desarrollo y

permiten al desarrollador, concentrarse en el diseño de la aplicación.

3.1.2 Compilador CCS

Es un compilador de lenguaje C que fue desarrollado por CCS Inc., para hacer posible la reducción del

tiempo de desarrollo de algún programa, ya que este software cuenta con bibliotecas y métodos, para

funciones específicas del microcontrolador PIC (conversión A/D, entrada y salida, configuración de

timers, etc.).


33


Incluye también el código fuente de numerosos programas de ejemplo, para módulos LCD, teclados,

conversores A/D, etc.

El compilador CCS, soporta una gran cantidad de microcontroladores, uno de ellos y el utilizado en este

proyecto, el PIC18F2550 de Microchip. Una característica muy importante, que además incluye, es la

función de crear un archivo del programa compilado, en formato HEX. Este archivo HEX, es utilizado

para programar el microcontrolador usando WinPic800.

3.1.3 WinPic800

Se trata de un software gratuito de programación de dispositivos. WinPic800 admite multitud de

circuitos programadores, e incluso permite fácilmente la configuración de nuevos circuitos

programadores, aunque se recomienda su uso combinado con el programador GTP USB, que es el que

se utiliza para este proyecto.

3.1.4 LiveWire y PCB Wizard

LiveWire, es una herramienta que permite el diseño de diagramas eléctricos de circuitos, con una

función que permite pasar de un diagrama eléctrico de un circuito, al diseño de lo que será su circuito

impreso, esto se logra, en conjunto con el programa PCB Wizard.

3.2 Hardware de desarrollo.

En cuanto al hardware que se requirió para hacer posible la realización del proyecto, se utilizó, una PC

con procesador Intel Pentium IV a 2.2 GHz, con 760 Mb en memoria RAM, y sistema operativo Windows

XP Home Edition.

3.2.1 Programador GTP USB Lite

GTP USB Lite, se trata de un programador que con ayuda de la herramienta WinPic800, hace posible

grabar programas dentro de un microcontrolador PIC, e incluso memorias EEprom. Este programador se


34


comunica por medio del USB, a la PC, esto evita la necesidad de contar con alimentación externa, y

aumenta la velocidad de grabación.

3.3 Microcontrolador PIC 18F2550

Este microcontrolador, se desprende de la familia de microcontroladores PIC, de Microchip, es un

microcontrolador que entra de la clasificación de microcontroladores de 8 bits, pues realiza sus

operaciones con registros de 8 bits.

La principal característica por la que elegimos usar este microcontrolador PIC18F2550, es su función de

conectividad con la interfaz USB, que puede funcionar a baja velocidad (1.5 Mbps), o a alta velocidad (12

Mbps). Además, este microcontrolador tiene las siguientes características que serán utilizadas en el

proyecto:

Tiene 24 terminales que pueden ser configuradas como terminales de Entrada/Salida digital.

Posee 3 temporizadores (temporizador 0,1 y 2).

Es posible configurar hasta de 4 maneras distintas sus fuentes de reloj

• XT. Oscilador o cristal de cuarzo (Crystal/Resonator)

• HS. Oscilador o cristal de cuarzo de alta velocidad (High‐Speed Crystal/Resonator), se

utiliza cuando el microcontrolador necesita de una alta frecuencia.

• EC. Reloj externo (External Clock).

• INT. Oscilador interno (Internal Oscillator).

Las terminales de Entrada/Salida, serán utilizadas, para encender LEDs, para controlar los circuitos de

potencia, y así encender o apagar dispositivos controlados, o también, algunas de las terminales se

podrían utilizar para codificar (generar señales banda base), o para decodificar (interpretar señales

banda base).

Los temporizadores principalmente, serán utilizados de apoyo para codificar (generar señales banda

base), o decodificar información (interpretar señales banda base).


35


En los microcontroladores usados en el proyecto, se utilizan los modos de oscilador HS para el

microcontrolador que es conectado por USB, e INT, para el microcontrolador que no se conecta por

USB.

3.4 Cámara IP

Una cámara IP, realiza las funciones de la cámara analógica y el servidor de vídeo, en una sola

unidad, es decir, digitaliza y comprime el vídeo, para ser enviado a través de un puerto

Ethernet, que comunica a una red IP. Entonces, el vídeo es transmitido desde la cámara IP,

hacia los conmutadores de red, para que finalmente llegue y se grabe en una PC, con el

software de gestión de vídeo. Este sistema de vídeo, finalmente es totalmente digital, y ofrece

las siguientes ventajas:

Cámaras de alta resolución (megapíxel).

Alimentación eléctrica a través de Ethernet y funcionalidad inalámbrica

Funciones de movimiento Vertical/Horizontal y Zoom, transmisión de audio, entradas y

salidas digitales a través de IP, junto con el vídeo.

Flexibilidad y escalabilidad completas.

Figura 3. 1 Diagrama de conexión de una cámara IP

La cámara IP utilizada para este proyecto,es la IP606W, esta cámara puede ser usada de manera

alámbrica o inalámbrica, tiene movimiento motorizado y además puede grabar en la oscuridad. Posee

todas las características de una cámara IP mencionadas anteriormente, y es una de las cámaras IP de

bajo precio encontradas en el mercado.


36

Capítulo 4: Desarrollo de las aplicaciones Cliente y Servidor

Capítulo 4

Desarrollo de las aplicaciones Cliente y Servidor

Con este capítulo, entramos ya a lo que es el desarrollo de nuestro proyecto, y comenzamos por

describir las aplicaciones Cliente y Servidor, que son la base de nuestro trabajo, pues serán las

encargadas de lograr la comunicación a través de Internet.

El lenguaje de programación utilizado para el desarrollo de nuestras aplicaciones, es Visual C#, que es

orientado a objetos y se utilizó Microsoft Visual Studio 2008 como entorno de desarrollo. Visual C#,

permite crear aplicaciones que se ejecutan en .NET Framework para sistemas operativos Windows.

Para establecer la comunicación entre nuestras aplicaciones, utilizaremos un control basado en sockets,

este control es llamado Winsock, y es utilizado por los programadores para desarrollar aplicaciones

cliente – servidor, ya que su implementación es sencilla y ahorra mucho código, a diferencia de los

sockets, además puede trabajar utilizando el protocolo TCP, lo que asegura que nuestra información

llegará a su destino en forma correcta.

Debemos mencionar que el protocolo TCP/IP, hace todo el trabajo que tiene que ver con la transmisión

de la información, que ésta llegue bien a su destino y en forma ordenada, sin embargo, este protocolo

no se encarga de decidir, cuándo ni cómo es que se establece la comunicación entre las aplicaciones

cliente y servidor, esta tarea es obligación del programador de las aplicaciones.

Para poder realizar nuestras aplicaciones, debemos basarnos en el modelo cliente – servidor, entonces

diseñaremos una aplicación, que se ejecute y que espere indefinidamente a través de un puerto, esta


37


aplicación será el servidor, la otra aplicación que debemos diseñar, es el cliente, y ésta se debe conectar

con el servidor, utilizando una IP y un puerto.

4.1 Instalación del Servidor

Para comunicarnos a través de la Internet con los dispositivos que se encuentren en nuestro hogar, es

necesario crear un servidor casero. Un servidor debe tener una IP estática, ya que sería un problema si

esta cambiara, pues no podríamos tener acceso al servidor, y por lo tanto sería imposible controlar

nuestros dispositivos.

El primer problema con el que nos encontramos al realizar nuestro proyecto, es que no contamos con

una IP estática, y es difícil que en algún hogar de México se cuente con una. Nuestro proyecto es

enfocado al control de dispositivos en el hogar, como son la iluminación, control de alarmas, control de

cerrojos, etc., por lo tanto, era importante hallar una solución a este problema.

Nuestro proveedor de Internet no proporciona IPs estáticas, a menos que paguemos por una, lo cual

aumentaría considerablemente el costo de nuestro proyecto. La mayoría de la población en México que

cuenta con servicio de Internet, tiene una IP dinámica, como nuestro caso. Afortunadamente en nuestra

búsqueda de soluciones, encontramos que hay servicios que permiten asignar un subdominio al equipo

que queremos convertir en servidor, quiere decir que aunque nuestra dirección IP cambie, nosotros

tendremos acceso a nuestro servidor por medio de este subdominio. Los servicios que encontramos

para obtener un subdominio, son No‐IP y DynDNS.

Tanto el servicio de No‐IP como el de DynDNS nos pueden servir, ya que ambos ofrecen dominios de

forma gratuita y sin publicidad. Para el servidor que usamos en el proyecto, optamos por el servicio de

no‐ip, que cuenta con un programa que informa cada cierto tiempo de las actualizaciones de nuestra IP,

de forma que la correspondencia nombre de dominio ‐ dirección IP sea la correcta.

Lo primero que debemos hacer, es dirigirnos a la página del servicio mencionado que es www.no‐

ip.com, para registrarnos en ella. Para poder crear nuestra cuenta, se nos pide que proporcionemos

cierta información, como email, una contraseña, nuestro nombre y código postal entre otros.


38


Una vez que creamos nuestra cuenta, recibiremos un email al correo especificado en el registro de la

cuenta, en el que viene un enlace para activar el servicio. Una vez que terminamos todo este proceso, ya

podemos entrar a la página de no‐ip e ingresar a nuestra cuenta, en donde se nos mostrará una interfaz,

desde la que podremos administrar la correspondencia entre el subdominio que hayamos creado, y su

dirección IP. Aquí igualmente podemos agregar nuestro nuevo dominio, en la figura 4.1, se muestra una

captura de pantalla para este proceso.

Figura 4. 1 Registro del dominio en el servicio No‐ip

Ya que introducimos nuestra información, damos click al botón de crear Host y el sistema nos informa

que esperemos alrededor de 5 minutos, para que el subdominio se añada al servidor DNS, y por lo tanto,

antes de que el subdominio pueda ser resuelto a nuestra IP.

En nuestro caso, fue necesario descargar un cliente que se encarga de notificar al servicio de no‐ip,

cuando nuestra IP cambie, pues recordemos que esta puede cambiar al momento de que apaguemos

nuestro equipo, y lo volvamos a encender.

En este punto, nos encontramos con el problema de que no podíamos tener acceso aún a nuestro

servidor, al momento de teclear el dominio en nuestro navegador, esto se debía a que no teníamos

habilitado un puerto en nuestro ruteador para nuestro servicio.


39


Es claro que los pasos a seguir para abrir un puerto en el router, varían en función al router que las

compañías proveedoras de Internet proporcionen, pero es necesario especificarle al router el puerto a

través del cual puede dejar pasar cierta información, ya que si el puerto no es habilitado, la información

será rechazada.

4.2 Comunicación entre nuestras aplicaciones

Para que nuestras aplicaciones Cliente y Servidor puedan comunicarse, hicimos uso del control Winsock,

trabajando con el protocolo TCP. Como ya dijimos, este control también se puede implementar con el

protocolo UDP, sin embargo, nuestro proyecto requiere que los datos que enviamos lleguen de forma

correcta, sin error alguno, ya que una mala transmisión de los datos, podría provocar un mal

funcionamiento de los dispositivos que intentamos controlar, con TCP aseguramos una buena

transmisión de nuestros datos.

Ahora se explicará de manera general, el procedimiento que seguirán nuestras aplicaciones para

establecer una conexión, y transmitir datos entre ellas utilizando los métodos, propiedades y eventos

del control Winsock, en la siguiente sección se verán aspectos más particulares de cada una de ellas.

Como ya se mencionó anteriormente, el proyecto está basado en el paradigma Cliente‐Servidor,

entonces, debemos tener una aplicación Cliente y una aplicación Servidor.

Primero que nada, debemos tener a nuestra aplicación Servidor, escuchando a través de un puerto, lo

cual se logra usando la propiedad LocalPort y llamando al método Listen, de este modo el Servidor

queda a la espera de una petición de conexión por parte del Cliente, cuando esto sucede, se produce en

el Servidor el evento ConnectionRequest, en el que se hace una llamada al método Accept para

completar la conexión.

Ahora hablando del lado del Cliente, éste debe conocer la dirección IP o el dominio del Servidor y el

puerto por el cual está escuchando, ya que estos parámetros son establecidos, se debe hacer una

llamada al método Connect, que requiere a estos dos parámetros. Es en este momento, en que el

Cliente hace la petición de conexión al Servidor y sucede lo descrito en el párrafo anterior.


40


La dirección IP del Servidor, puede conocerse del lado del Cliente gracias a la propiedad RemoteHost,

también el puerto por el cual está escuchando mediante la propiedad RemotePort.

Ya que se ha establecido la conexión entre el Cliente y el Servidor, las aplicaciones pueden enviar y

recibir datos. Para enviar datos, se utiliza el método SendData. Cuando se recibe algún dato, ya sea del

lado del Cliente o del Servidor, se produce el evento DataArrival, dentro del cual se hace una llamada al

método GetData, para recuperar los datos recibidos y almacenarlos en alguna variable.

El procedimiento anteriormente descrito, es el que se seguirá para establecer una comunicación entre

nuestras aplicaciones Cliente y Servidor programadas, sin embargo, cada una de ellas hace uso de

muchos más recursos para su funcionamiento, en la figura 4.2, se presenta el diagrama de actividad

UML del procedimiento descrito.


41


Figura 4. 2 Diagrama de actividad para la comunicación Cliente ‐ Servidor

4.3 Descripción de la aplicación Cliente

Ahora se describirá más a fondo la estructura que tiene la aplicación Cliente. Nuestras aplicaciones son

proyectos del tipo Windows Form, que es la tecnología utilizada en Visual C# para crear aplicaciones

gráficas basadas en Windows, que se ejecutan en .NET Framework. Para crear un proyecto de este tipo,

se utiliza el diseñador de Windows Form de Visual Studio, mediante el cual se crea la interfaz de

usuario, la cual puede contener botones, cuadros de texto, etiquetas, imágenes, etc.

Las dos aplicaciones deben contener al control Winsock, para poder hacer uso de sus métodos,

propiedades y eventos, este control es el componente principal para nuestras dos aplicaciones.


42


En la figura 4.3, se puede apreciar la interfaz de usuario para nuestra aplicación Cliente, la interfaz está

formada por elementos gráficos, que facilitan la interacción entre la aplicación y el usuario.

Figura 4. 3 Interfaz gráfica de la aplicación Cliente

En la figura 4.4 se muestra el diagrama de caso‐uso para la aplicación Cliente.


43


Figura 4. 4 Diagrama caso ‐ uso de la aplicación Cliente

El usuario, mediante la aplicación Cliente, podrá conectarse con el Servidor remoto, controlar los

dispositivos a distancia, como un foco, una bomba de agua, seguros de puertas, etc., monitorear el

estado de los mismos, esto es, saber si el foco realmente está encendido, si alguna alarma fue activada o

si el seguro de la puerta está puesto, y podrá tener acceso a la cámara IP utilizada, ya sea para vigilancia

o para complementar el monitoreo de dispositivos.

Se propusieron tres áreas principalmente en la interfaz gráfica de la aplicación, con el fin de que el

usuario localizara de manera fácil, las diversas tareas que se pueden hacer con la aplicación, estas áreas

son:

4.3.1 Panel de conexión

Es el panel, en el que el usuario introduce la IP y el puerto del Servidor al cual quiere conectarse. El

proceso de conexión es descrito completamente más adelante, ya que se trata de un proceso

importante en el proyecto. En la figura 4.5 se muestra este panel.


44


Figura 4. 5 Panel de conexión de la aplicación Cliente

4.3.2 Panel de controles

Se trata de un tabControl, que es una colección de paneles, en los cuales se pueden colocar más

controles. Como puede apreciarse en la figura 4.6, hay tres paneles: Controles, Estado de dispositivos y

Mensajes.

Figura 4. 6 Panel de control en la aplicación Cliente

4.3.2.1 Controles

En la figura 4.7. Se muestra el diagrama caso‐uso para el panel de Controles, que a su vez contiene otros

controles como botones, TextBox, contenedores y etiquetas (Labels).


45


Figura 4. 7 Diagrama caso‐uso del panel de control de la aplicación Cliente

El usuario podrá establecer un horario en el que quiera que las luces sean encendidas, o podría también

utilizarse para establecer la hora en que cierto dispositivo debe de accionarse. Esta es una gran ventaja,

ya que remotamente se pueden variar los periodos en que un dispositivo está en funcionamiento.

Pensemos, por ejemplo, que la persona que manipula algún dispositivo, debe hacer alguna otra tarea

que le consuma cierto tiempo, y esto le impida el poder accionar o apagar el dispositivo, haciendo uso

de esta capacidad de la aplicación, podría establecer el periodo de funcionamiento del dispositivo y éste

funcionaría cuando tuviese que hacerlo.

En nuestro caso, lo que se controla es la iluminación, el usuario puede establecer la hora en que se

deben encender o apagar las luces de su casa, por ejemplo, antes de salir del trabajo, puede programar

esta función para que cuando llegue al hogar se encuentre con todo iluminado. Esto, además de ser una

comodidad, resulta en un ahorro de energía.

Para programar esta función, fue utilizado el control Timer de Visual Studio, que sirve para provocar

eventos temporales, es decir, que si habilitamos este control, cada cierto intervalo de tiempo, ocurrirá

un evento, en este evento podemos poner instrucciones de control.

Las propiedades más importantes de este control, son:

Enabled: Indica si el Timer debe funcionar o no. (Envía eventos o no lo hace).

Interval: Es el tiempo que debe transcurrir entre evento y evento, está en milisegundos.


46


El evento que se produce cada cierto tiempo, es el evento del Timer, Timer_Tick(), por ejemplo, si

quisiéramos que la hora actual se mostrara en un label llamado HoraTxt, tendríamos que establecer la

propiedad Enabled en True, y el intervalo a 1000 (1 segundo), el evento del Timer quedaría de la

siguiente forma:

private void Hora_Tick(object sender, EventArgs e)

HoraTxt.Text = DateTime.Now.ToString("hh:mm:ss");

En nuestra aplicación, lo que se hace es: comparar Hora.Txt.Text con el contenido de alguna de las

TextBox, en donde el usuario establece una hora, y si son iguales, se envía el dato correspondiente al

Servidor, para que éste active el dispositivo. En la figura 4.8 se muestra el diagrama de actividad para

este proceso.

Figura 4. 8 Diagrama de actividad, horario de encendido

En este mismo panel se pueden observar los botones siguientes:

• Encendido general: dentro del evento de este botón, se habilita un Timer llamado Retardos3, en

el evento de este Timer, que sucede cada segundo, se va incrementando de uno en uno el valor


47


de una variable llamada conteo, que sirve de contador, el valor de esta variable se compara con

una serie de números (1,2,3,etc.),con cada condición cumplida, se enciende un foco, esto quiere

decir que, cada segundo un foco será encendido, al terminar de encender todos los focos,

Retardos3 es deshabilitado. En la figura 4.9 se muestra el diagrama de actividad simplificado

para este proceso.

Figura 4. 9 Diagrama de actividad, encendido general

La razón de implementar este procedimiento es debido a que le tenemos que dar cierto tiempo al

envío de cada dato para que nuestro microcontrolador, a la hora de recibir los datos del Servidor,

sea capaz de procesarlos en forma adecuada, ya que si enviamos todos los datos de manera

simultánea, el sistema no funciona adecuadamente pues el microcontrolador no sería capaz de

procesarlos. En el capítulo 5 se habla más ampliamente del microcontrolador, y se tocan temas

como éste.

• Apagado general: realiza la misma función que el botón anterior, pero en este caso, se envía un

dato al Servidor para que realice el proceso de apagar todos los focos.


48


• Simular presencia: con este botón, se establece una secuencia de encendido y apagado de

luces, de manera que desde el exterior parezca que hay gente dentro de la casa. Esta función

resulta muy importante cuando se habla de seguridad en el hogar.

• Cámara IP: mediante este botón, se podrá tener acceso a la aplicación de la cámara IP, a través

de la cual se monitorean los dispositivos.

• Reproductor: será utilizado para que el usuario pueda visualizar videos grabados por la cámara

IP. Para este propósito, fue creada una aplicación Windows dentro del mismo proyecto, esta

aplicación contiene un control Windows Media Player, y un botón que permite abrir un archivo

de video, que esté almacenado en el Servidor.

• Los dos botones restantes que se observan, envían un dato al servidor para activar o desactivar

algún dispositivo extra.

4.3.2.2 Estado de los dispositivos

El siguiente panel es el de “Estado Dispositivos”, en la figura4.10 se pueden observar su diagrama de caso‐uso y la interfaz gráfica.

Figura 4. 10 Diagrama caso‐uso e interfaz gráfica del panel Estado de dispositivos

Este panel permite al usuario, asegurarse que el estado del dispositivo es el correcto, el

Microcontrolador será el que envíe datos, a través del Servidor, al Cliente indicando sobre el estado real

de los dispositivos. El Microcontrolador encargado de encender o apagar los dispositivos, hará un


49


barrido a su puerto de salida, para conocer el estado de cada una de sus terminales, si la terminal está

en alto, significa que el dispositivo conectado a ésta, está encendido; si la terminal está en bajo, significa

que el dispositivo está apagado. Conforme se va conociendo el estado de cada terminal, se envía un

dato al Cliente, el cual actualizará el panel del que estamos hablando, mostrando así, si realmente está

funcionando el dispositivo. Aunque la aplicación Cliente permite al usuario ver el estado, por ejemplo,

de un foco, a través de una imagen en su interfaz gráfica, esto no aseguraría que el estado real del

dispositivo es el mostrado, ya que estas imágenes cambian en función del evento que controla a ese

dispositivo, es por eso que se implementó, el procedimiento de conocer el estado de las terminales del

puerto de salida del Microcontrolador, ya que podría suceder que alguna terminal no funcionara bien, y

sin embargo, el usuario vería lo contrario en la aplicación. El Cliente a través del evento DataArrival del

control Winsock, procesa los datos que le llegan del Servidor, este proceso es descrito con más detalle

en la sección 4.8 y en el capítulo 5, se habla más sobre el barrido que hace el microcontrolador, para

conocer el estado de sus terminales y enviar esta información al Cliente. En la figura 4.11 Se muestra el

diagrama de actividad de este proceso.

Figura 4. 11 Diagrama de actividad, estado de los dispositivos

Adicionalmente, se implementó un sistema de alarmas, esto con el fin de detectar mediante sensores,

por ejemplo, si alguien entró a nuestra casa, la aplicación Cliente mostraría una señal de alerta (figura


50


4.12), avisando al usuario sobre alguna intrusión. Igualmente se podría implementar este mismo

mecanismo, para avisar si algún dispositivo dejó de funcionar, por ejemplo, una máquina en una fábrica,

el supervisor no tendría que estar presente para detectar alguna falla, sino que el sistema le avisaría en

el momento que esto ocurriera.

Figura 4. 12 Señal de alarma

El procedimiento para implementar esta función, es similar al que se sigue para actualizar el estado de

los dispositivos, el Microcontrolador recibirá una señal a la entrada de una de sus terminales cuando

algún sensor sea activado, e inmediatamente enviará un dato al Servidor por el puerto USB, para que

éste a su vez envíe este dato al Cliente, y el usuario visualice la señal de alarma. Igualmente, en el

capítulo 5, se hablará más sobre este proceso en el Microcontrolador.

4.3.2.3 Mensajes

Mediante este panel, el usuario podrá consultar la información que se está intercambiando entre el

Cliente y el Servidor. Cada vez que el Cliente envíe un dato al Servidor, éste será mostrado en el cuadro

de texto que se aprecia en la figura 4.13, de la misma manera, los datos recibidos provenientes del

Servidor, serán registrados aquí.


51


Figura 4. 13 Panel de mensaje de la aplicación Cliente

Este panel permite, conocer realmente la información que se está intercambiando entre las

aplicaciones, y en caso de algún error en el funcionamiento del sistema, poder determinar si la falla fue

producida por la aplicación o el problema está en la parte electrónica.

4.3.3 Panel de ubicación de dispositivos

En esta sección de la aplicación Cliente, el usuario podrá visualizar la ubicación de los dispositivos que

está controlando, en este proyecto, se utilizó el plano de una casa para ubicar los focos, para la

iluminación, el cerrojo de la puerta y la cámara IP. Además, se pueden controlar aquí mismo los

dispositivos, y visualizar inmediatamente el cambio de estado de los mismos. En la figura 4.14 Se

muestra esta sección.

Figura 4. 14 Panel de ubicación de los dispositivos


52


Como se puede observar, los focos, cerrojo y cámara IP, se representan mediante un botón con una

imagen, que describe el estado de cada uno de ellos (apagado o encendido), al presionar un botón que

representa un foco, un dato es enviado al Servidor para que éste indique al Microcontrolador,

dependiendo del estado del foco en que fue presionado el botón, si debe apagarlo o encenderlo.

Igualmente, si el botón que representa al cerrojo es presionado, éste manda un dato al Servidor para

indicarle qué acción tomar y además, se cambia la imagen del botón para representar el nuevo estado

que tiene dicho dispositivo. En caso de que el botón de la cámara IP sea presionado, se abrirá la

aplicación que sirve para controlar dicha cámara. En la figura 4.15 Se muestran los estados que pueden

tomar cada uno de los dispositivos.

Figura 4. 15 Estado de los dispositivos

4.4 Clase AplicacionCliente,

Para desarrollar la aplicación Cliente, se creó una clase llamada AplicacionCliente, dentro de la cual

encontramos a todos los métodos, eventos y propiedades necesarios para el funcionamiento de la

aplicación. En la figura 4.16, se presenta el diagrama UML de esta clase, este diagrama es generado por

Visual Studio automáticamente en el proyecto.


53


Figura 4. 16 Clase AplicacionCliente

Como se puede observar en la figura 4.16, la clase creada es muy completa, cumpliendo así con una de

las reglas de la programación orientada a objetos, que dice que una clase es mucho más rica entre

mayores tareas se puedan realizar con ella.


54


4.5 Descripción de la aplicación Servidor

La aplicación Servidor, está desarrollada al igual que la aplicación Cliente en la tecnología Visual C#. Esta

aplicación tiene funciones muy importantes, como la de transmitir los datos enviados desde el Cliente

hacia el Microcontrolador, a través de la interfaz USB y la de comunicar al Cliente sobre los estados que

tienen los dispositivos, que estamos controlando.

La interfaz gráfica que se desarrolló para la aplicación Servidor se muestra en la figura 4.17, se observa

que es más sencilla que la interfaz del Cliente, esto se debe a que su función se concentra únicamente a

esperar por peticiones de conexión por parte del Cliente, recibir los datos que el Cliente envía y enviar

datos al Cliente.

Figura 4. 17 Interfaz de la aplicación Servidor

En la figura 4.18 Se muestra el diagrama de caso‐uso para el Servidor.


55


Figura 4. 18 Diagrama caso‐uso para la aplicación Servidor

La interacción por parte del usuario con el Servidor es menor que con la aplicación Cliente, sin embargo,

internamente el Servidor es más completo, ya que además de tener control sobre la comunicación

remota a través del control Winsock, debe transmitir y recibir datos a través de la interfaz USB, por lo

que contiene más código que le permite interactuar con ésta.

La interfaz del Servidor está compuesta por cuatro paneles, tres de ellos informan sobre el estado de la

conexión, datos del servidor y la información que se transmite, el otro panel es con el que el usuario

interactúa directamente.

4.5.1 Panel de datos del Servidor

El usuario podrá visualizar los datos del Servidor, que son: el nombre del equipo en el que se está

corriendo la aplicación y la dirección IP del mismo. El que el usuario conozca estos datos, permite correr

la aplicación en cualquier red, ya que si el control de dispositivos se aplicara en una red local, sería fácil

establecer al Servidor y conocer rápidamente la dirección IP, a la que el Cliente tendría que conectarse.

En la figura 4.19, se muestra este panel.


56


Figura 4. 19 Panel, datos del Servidor

Para conocer el nombre del equipo en donde se está corriendo la aplicación Servidor, se hace uso de la

propiedad LocalHostName del control Winsock, para esto se le asigna esta propiedad, a la propiedad

Text de un control Label (etiqueta), como sigue:

lblHost.Text = axWinsock1.LocalHostName;

en donde lblHost es el nombre del control Label.

La dirección IP se puede conocer haciendo uso de la propiedad LocalIP:

lblIPlocal.Text = axWinsock1.LocalIP;

4.5.2 Panel de Mensajes

En esta sección, se visualizan los datos que se están transmitiendo entre el Cliente y el Servidor, esto con

el objetivo de visualizar si los datos que están siendo intercambiados entre ambas aplicaciones, son los

correctos. En la figura 4.20, se muestra esta parte de la aplicación.


57


Figura 4. 20 Panel de mensajes de la aplicación Servidor

Este panel fue de gran ayuda durante el desarrollo del proyecto, debido a que a la hora de hacer las

pruebas de comunicación, podíamos visualizar qué datos se estaban transmitiendo, o saber si realmente

se estaban transmitiendo los datos.

Además, el usuario podrá visualizar la información que se va almacenado en esta caja de texto, una vez

que llegue al lugar en donde se ha instalado el Servidor, así podrá saber qué movimientos se estuvieron

realizando y a qué hora fueron hechos.

4.5.3 Estado de la conexión

Este panel sirve para conocer en qué estado se encuentra el Servidor, si está conectado o desconectado.

Para esto, se utilizaron dos imágenes que cambian según el estado y un control Label (etiqueta), para

especificar el puerto por el cual se está escuchando por peticiones. En la figura 4.21, se muestra la

apariencia de este panel, tanto en el estado de escucha como en el de desconectado. De manera

adicional, se muestra la hora local del Servidor.


58


Figura 4. 21 Estados del Servidor

4.5.4 Panel de Conexión

El Servidor debe de saber por cuál puerto escuchar las peticiones del Cliente, este parámetro, será

asignado por el usuario a la propiedad LocalPort del control Winsock, a través de un cuadro de texto en

donde escribirá el valor. Para lo anterior, se creó un panel llamado Conexión, que se muestra en la figura

4.22. En este panel, el usuario dispone de una caja de texto y dos botones, uno para poner a escuchar a

la aplicación Servidor, por el puerto especificado en la caja de texto, y el otro para desconectar al

Servidor.

Figura 4. 22 Panel de conexión de la aplicación Servidor

Para que el Servidor comience a escuchar por un puerto, se hace uso del método Listen, éste crea un

socket que esté en modo de escucha. El diagrama de actividad que se muestra en la figura 4.23, muestra

el proceso de conexión del Servidor, una vez que el usuario ha especificado el puerto y presionado el

botón “Escuchar”, acción que nos lleva al método de este botón.


59


Figura 4. 23 Diagrama de actividad para el proceso de conexión

4.6 Comunicación USB

Para lograr que la aplicación Servidor pudiera enviar y recibir datos a través de la interfaz USB, se utilizó

una API (Interfaz de Programación de Aplicaciones) de Windows llamada mpusbapi.dll, proporcionada

por Microchip (ver Apéndice ), que permite leer y escribir en un dispositivo USB. Esta DLL está escrita en

lenguaje C++, por esta razón se tuvo que crear una clase que importara las funciones de mpusbapi.dll, y

así poder implementarlas en leguaje C#, esto es lo que permite la interoperabilidad en los sistemas.

La clase PicUSBAPI, es la encargada de importar las funciones básicas contenidas en la DLL mpusbapi.dll,

las funciones que serán utilizadas son las siguientes:

_MPUSBOpen(DWORD instance, string pVID_PID, string pEP, DWORD dwDir,

DWORD dwReserved)

_MPUSBRead(void* handle, void* pData, DWORD dwLen, DWORD* pLength, DWORD

dwMilliseconds)

_MPUSBClose(void* handle)


60


La primera función, permite establecer una tubería, pasándole como parámetros el identificador de

vendedor VID y producto PID, el punto final con el que nos queremos comunicar y la dirección de los

datos.

VID y PID, son esenciales para todo dispositivo, VID es el identificador de la empresa, cada empresa

tiene un identificador, el cual puede vender diferentes productos a los que se les incluye el ID (PID). Por

esta razón, un dispositivo tendrá un VID y PID fijos que lo hace único, y evitando incompatibilidad con

otros dispositivos.

La segunda función lo que nos permite hacer, es leer los datos provenientes de la interfaz USB. Y la

tercera función cerrará la tubería. En el Apéndice A, se pueden consultar estas y otras funciones con más

detalle, en este Apéndice se hace una descripción más detallada de cada uno de los parámetros que

utilizan estas funciones.

Para poder declarar un método que esté dentro de una DLL, se hace uso del atributo DLLImport, el cual

permite especificar el nombre de la DLL que contiene el método. Luego, se debe declarar el método con

las palabras clave static y extern de C#. Lo habitual es dar el mismo nombre al método de C# que al

método exportado. Por ejemplo, en nuestra clase PicUSBAPI, para poder importar la función

_MPUSBClose de la DLL, se hace lo siguiente:

[DllImport("mpusbapi.dll")] private static extern bool _MPUSBClose(void* handle);

Lo mismo se hace para importar las otras funciones contenidas dentro de la mpusbapi.dll.

En la figura 4.24, se muestra el diagrama de Clase de nuestra Clase genérica PicUSBAPI.


61


Figura 4. 24 Diagrama UML de la clase PicUSBAPI

Para tener más claro el significado de las variables utilizadas en la clase, se recomienda leer el Apéndice

A, en el que se describen con más detalle. A continuación, nos enfocaremos a la descripción de los

métodos:

• OpenPipes

• ClosePipes

• RecivePacket

• SendPacket

• Controles

• DetectroAlarma


62


OpenPipe

Este método, nos permitirá abrir la conexión con el microcontrolador PIC, a continuación se muestra el

código para este método:

public void OpenPipes() DWORD selection = 0; myOutPipe = _MPUSBOpen(selection, vid_pid_norm, out_pipe, 0, 0); myInPipe = _MPUSBOpen(selection, vid_pid_norm, in_pipe, 1, 0);

Observamos DWORD selection = 0, esto significa que estamos usando un solo microcontrolador,

entonces, si tuviésemos otro microcontrolador en el proyecto, el segundo éste sería seleccionado con

DWORD selection = 1, tomando en cuenta que, para usar el mpusbapi.dll con dos microcontroladores

PIC, tendríamos que crear dos clases, una que contenga el PID&VID del primer PIC con el DWORD

selection=0, y otra clase que contenga el otro PID&VID del segundo PIC con el DWORD selection =1.

ClosePipes

Este método cierra la conexión entre la PC y el microcontrolador.

RecivePacket y SendPacket

Estos métodos, nos permiten enviar bytes desde la PC hacia el microcontrolador y recibir

bytes del microcontrolador a la PC.

RecivePacket, hace uso del método _MPUSBRead,el cual permite leer la información que llega a

través de la interfáz USB, proveniente del microcontrolador.

SendPacket, utiliza el método _MPUSBWrite,que permite enviar información a través de la interfaz

USB, la cual llegará al microcontrolador.


63


Controles

Este método tiene como objetivo, enviar los códigos que indican al microcontrolador qué dispositivo

debe encender o apagar, según sea el caso. Estos códigos son los que la aplicación Servidor recibe en su

método DataArrival del control Winsock, que es el encargado de recibir los datos que envía el Cliente.

Los datos son enviados al microcontrolador a través de USB, con ayuda del método SendPacket, como

sigue:

SendPacket(send_buf, 2);

En donde, send_buf, es un arreglo que contiene dos valores de un byte cada uno, el primer valor

(send_buf[0]), le indicará al microcontrolador, el modo al que debe ingresar (hay dos modos, el de

encendido 0 y el de apagado 1),y el segundo valor (send_buf[1]), indicará cuál dispositivo debe ser

activado o desactivado. En el capítulo 5, se trata más a detalle este proceso del lado del

microcontrolador.

Para decidir el modo (encender o apagar), se implementó un método, mediante el cual, si queremos

encender algún dispositivo, se envían desde el Cliente, valores mayores a 100, y para apagar el

dispositivo se envían valores menores a 100. De esta forma, si queremos encender el dipositivo 1, se

envía el valor 101, pero si lo que queremos es apagarlo, enviamos el 01.

En la figura 4.25 Se muestra el diagrama UML de actividad para este método.


64


Figura 4. 25 Diagrama de actividad para el método Controles

DetectorAlarma

Este método realiza la función de leer los datos que llegan del microcontrolador, y que pueden

indicarnos el estado de los dipositivos periféricos, ya sea una alarma o para saber si un foco está

realmente encendido.

Para leer los datos que llegan del microcontrolador, este método hace uso del método ReceivePacket,

éste recibe el dato que llega a través de la USB y guarda el valor en una variable. Cuando se hace una

llamada al método DetectorAlama, éste regresa el valor que recibió del paquete transmitido por USB, y

este mismo dato es el que se envía hacia la aplicación Cliente,para informar al usuario sobre el estado

de algún dispositivo.

4.6 Conexión con el Servidor

Para que el usuario se conecte con el Servidor, se creó un panel llamado “Conexión al Servidor”

(mostrado en la figura 4.5), en el cual tenemos dos cajas de texto y dos botones, este panel sirve para

que el usuario escriba la dirección IP, y el puerto del Servidor al cual se va a conectar.


65


Una vez que estos dos parámetros son establecidos, se presiona el botón de Conectar (btnConectar),

con lo cual se hace una llamada al evento de este botón (btnConectar_Click).

De manera general lo que hace este evento, es hacer la petición de conexión al Servidor, mediante el

método Connect del control Winsock, que requiere de los parámetros IP y puerto establecidos, en las

dos cajas de texto correspondientes (IPTxt y PuertoText respectivamente). También se establece el valor

de la variable de instancia isConnected a true, esta variable sirve para tener un control sobre el estado

de la conexión entre Cliente y Servidor. Además se utiliza un arreglo try – catch, para el manejo de

excepciones durante la ejecución de la aplicación, si ocurre alguna, ésta se muestra en una caja de texto

en el panel de mensajes dentro de la aplicación.

Para que el Cliente se desconecte del Servidor, se hace uso del botón Desconectar (btnDesconec), cuyo

evento (btnDesconectar_Click), contiene a su vez al evento Close del control Winsock, para cerrar la

conexión.

Hay que mencionar, que se omiten instrucciones que tienen que ver con el comportamiento de los

componentes de la interfaz gráfica, por ejemplo, el que aparezca una etiqueta que indique que se

realizó con éxito la conexión, o que la imagen de conexión cambie. Lo anterior debido a que el propósito

del trabajo, es describir el proceso principal, en este caso el de conexión y no tanto el comportamiento

de los controles, ya que esto puede variar de acuerdo a la aplicación que se esté implementando.


66


Figura 4. 26 Diagrama de actividad para los procesos de conexión y desconexión

Una vez que el Cliente y el Servidor se han conectado, puede haber intercambio de datos entre las dos

aplicaciones. Es mediante este intercambio de datos, que se logra tener un control sobre los

dispositivos, ya sea que el Cliente envíe al Servidor un comando, que indique que determinado

dispositivo debe ser activado o desactivado, o que el Servidor envíe al Cliente un comando que le

indique el estado del dispositivo.

4.7 Envío de datos

Para el envío de los datos, tanto del Cliente como del Servidor, fue creado un método llamado

Envio_Dato, que es invocado cada vez que se presiona un botón que controla algún dispositivo, este

método requiere un parámetro de tipo entero llamado “dato”. Envio_Dato, se encarga de hacer una

llamada al método SendData del control Winsock, mediante el cual se envía el valor asignado al

parámetro dato al Servidor. En la figura 4.27, se muestra el diagrama de actividad, en donde se describe

el procedimiento que se sigue, a partir de que el usuario presiona un botón de control.


67


Figura 4. 27 Diagrama de actividad para el envío de un dato

Por ejemplo, un botón presionado podría enviar el dato 101 que sirve para encender algún dispositivo,

esto se haría como sigue:

Envio_Dato(101);

Envio_Dato, recibe este parámetro y lo pasa como argumento al método SendData del control Winsock:

SendData(101);

Al recibir este dato, el Servidor por medio de condiciones, sabrá qué dispositivo activar.

Como ya se dijo anteriormente, además de enviarse un código, cuando un botón es presionado, se

modifican aspectos visuales de la interfaz gráfica, ya que es importante que el usuario perciba los

cambios que se hacen en el dispositivo, además, se hace un manejo de excepciones, para controlar los

errores que puedan presentarse.


68


4.8 Recepción de datos

Ahora es momento de describir cómo es que los datos son recibidos, este proceso es el mismo tanto en

la aplicación Cliente, como en la aplicación Servidor, solo que la forma de manipular los datos que llegan

es diferente.

Del lado de la aplicación Cliente, lo que estaremos recibiendo, serán datos que tienen que ver con

alarmas activadas y el estado de los dispositivos, del lado de la aplicación Servidor, se recibirán datos

que a su vez serán pasados al Microcontrolador a través de USB,para controlar a los dispositivos.

Cuando un dato llega a la aplicación, el evento DataArrival del control Winsock se activa y recibe el dato

enviado, esto lo hace mediante el método GetData, este método trabaja con variables de tipo object, lo

que le permite recibir valores de cualquier tipo, esto nos permite trabajar tanto con valores de carácter

(char), como valores enteros (int).

El argumento del método GetData, está referenciado, esto quiere decir, que cualquier cambio que sufra

el parámetro dentro del método, se verá reflejado en la variable que haya sido referenciada a ese

parámetro, dentro del método que realizó la llamada. El siguiente ejemplo, ayuda a comprender la

forma en cómo trabaja el método GetData.

Supongamos el siguiente método:

static void Metodo(ref int i)

i = 44;

Veamos ahora qué sucede cuando se hace una llamada a ese método con referencia:

static void Main()

int valor = 0;

Metodo(ref valor);


69


La variable definida como valor, tomaría el valor de 44.


70

Capítulo 5: Sistema electrónico de comunicaciones

Capítulo 5

Sistema electrónico de comunicaciones

5.1 Introducción

Un sistema de comunicación se compone de distintos dispositivos, que en conjunto nos va a

permitir el intercambio de información de un punto a otro, en este caso hablamos de una

comunicación tipo digital, debido a que la información que vamos a transmitir y recibir, será

información binaria, es decir, 1’s y 0’s.

En la figura 5.1.1 se muestra el diagrama a bloques del sistema de comunicaciones digital, para

lograr la comunicación inalámbrica.

Tabla 5.1.1 Diagrama a bloques del sistema de comunicaciones inalámbrica.

Es importante mencionar, que este sistema de comunicaciones inalámbricas, está compuesto

de dos módulos: módulo de control y módulo de monitoreo. Los dos módulos, son los que


71


estarán utilizando comunicación inalámbrica, la cual se lleva a cabo con módulos de Radio

Frecuencia. Para evitar interferencia entre la comunicación del módulo de control y el módulo

de monitoreo, éstos se comunican a distintas frecuencias; es decir, la comunicación

inalámbrica en el módulo de control, se llevará a cabo con un módulo de RF transmisor y un

módulo de RF receptor, que transmiten a 433.92 MHz; la comunicación inalámbrica en el

módulo de monitoreo, tendrá igualmente un módulo de RF transmisor y uno receptor, pero

éstos transmitiendo a 315 MHz.

En la figura 5.1.1, se observan los elementos fuente y destino de cada módulo; es decir, para el

módulo de control (en amarillo), son: microcontrolador USB y dispositivos a monitorear,

respectivamente. Para el módulo de monitoreo, la fuente son los dispositivos a monitorear, y

el destino es el microcontrolador USB. Estos dos módulos, posteriormente serán vistos de

forma más detallada.

A continuación se describirá de manera general, la función de cada elemento del sistema.

Fuentes de información

Las fuentes de información de nuestro sistema de comunicaciones inalámbricas, son aquellas

que proporcionan la información binaria que deseamos enviar.

La información a transmitir a través del sistema de comunicaciones inalámbricas, serán

palabras de 12 bits, y pueden ser de tres tipos: código de mando, palabra de estado de los

dispositivos a monitorear o palabra de estado de los dispositivos a controlar, cada una de

estas palabras tienen distinta función, y se utilizan específicamente, en un sólo módulo.

Como se observa en la figura 5.1.1, las fuentes de información del sistema, pueden ser dos, ya

sea el microcontrolador USB en el módulo de control, o los dispositivos a monitorear en el

módulo de monitoreo. El destino de la información, de igual forma pueden ser dos: los

dispositivos a controlar en el módulo de control, o el microcontrolador USB en módulo de

monitoreo. (Véase figura 5.2.1).


72


Transmisor inalámbrico

Esta parte del sistema, será la encargada de codificar la información digital de la fuente, y

modularla, para ser transmitida, en este sistema de comunicaciones, como ya se mencionó, se

transmitirán palabras de 12 bits.

Tabla 5.1.2 Diagrama a bloques del transmisor inalámbrico usado.

El proceso de codificación de nuestro sistema, será realizado siempre por un microcontrolador;

por lo tanto, a la salida de una de sus terminales digitales, se obtendrá una señal en banda

base, a la cual se le aplicó un código de línea. El código de línea, se utiliza para pasar valores

digitales, en niveles de voltaje, es decir, representar el 1 y el 0 binario, con alguna señal

eléctrica (véase sección Proceso de codificación).

Una señal en banda base, es una señal que aún no está modulada, las señales en banda base,

que se estarán generando en nuestro sistema, serán digitales, es decir, tendrán amplitudes de

nivel bajo de voltaje y de nivel alto de voltaje. En donde el nivel bajo de voltaje, serán 0 Volts,

y el nivel alto de voltaje serán 5 Volts.

En la figura 5.1.3, se observa un ejemplo de señal en banda base, que será utilizada en nuestro

sistema, esta señal contiene la información de una palabra de 12 bits. Una señal de este tipo,

está lista para ser modulada y transmitida, por el transmisor.

Tabla 5.1.3 Ejemplo de señal digital en banda base.


73


Después de tener la señal digital en banda base, se procede a modular y transmitir la

información. Este proceso es realizado por un módulo de RF (Radio Frecuencia) transmisor.

Canal

El canal, es el medio por el cual se transmite una o más señales, por lo tanto, como este

sistema, tiene comunicación inalámbrica, el canal será el aire.

Receptor

Como su nombre lo dice, éste será el encargado de recibir la información, y así obtener la

información digital que fue transmitida.

Tabla 5.1.4 Diagrama a bloques del receptor inalámbrico usado.

El proceso de recepción, es realizado primeramente por un módulo de RF, receptor, quien se

encarga de recibir inalámbricamente la señal que fue transmitida, y después la demodula, es

decir, recupera la señal digital en banda base, esta señal, es enviada al decodificador, quien se

encargara de interpretarla, para obtener información binaria, recuperando la palabra de 12

bits que se transmitió.

Destino

El destino, es el elemento del sistema que va a recibir la información binaria, para que pueda

ser utilizada por éste. Como se tienen dos módulos (uno de control y uno de monitoreo)

comunicándose, se tienen también dos destinos; y como se observa en la figura 5.1.1, para el

módulo de control, el destino son los dispositivos a monitorear (en amarillo); y para el módulo

de monitoreo, el destino es el microcontrolador USB (en azul).


74


5.2 Sistema electrónico de comunicaciones

Antes de comenzar a hablar acerca del funcionamiento de los dispositivos electrónicos,

debemos conocer, cómo está integrado el sistema de comunicaciones, es decir, por medio de

qué dispositivos se transmite la información, y en qué dirección se envía. En la Fig. 5.2.1, se

puede apreciar el trayecto que sigue la información, tanto para el módulo de control (flechas

naranja), como para el módulo de monitoreo (flechas azules); estos trayectos se mencionarán

más a detalle en secciones posteriores.

Figura 5.2.1 Diagrama a bloques del sistema de control a distancia y el sistema de comunicaciones. Las

direcciones del flujo de la información están indicadas por la flecha naranja, para el módulo de control y azul,

para el módulo de monitoreo.

En la figura 5.2.1, se observa el diagrama a bloques del sistema de control a distancia a través

de internet, en donde nuestro sistema electrónico de comunicaciones, está compuesto por: el

módulo de control, el módulo de monitoreo y el microcontrolador USB. Si recordamos los

objetivos de éste sistema, están enfocados hacia el control de dispositivos, tales como focos,


75


bombas de agua, cerrojos eléctricos, puertas eléctricas, etcétera; también se desea monitorear

dispositivos, como son sensores de presencia, sensores de humo, sensores de gas, etcétera.

Cada elemento del sistema completo, tiene su función específica.

• Cliente: Es el ordenador desde donde se estarán controlando y monitoreando los

dispositivos, a través de lo que llamamos “aplicación cliente”, el control se realizará,

enviando lo que denominamos comandos de control, y el monitoreo se hará,

recibiendo los comandos de monitoreo, que posteriormente, se hablará más a detalle

de éstos.

• Internet: Es la red, por la cual se van a comunicar el servidor y el cliente. Cabe

mencionar, que no necesariamente se debe utilizar el internet, ya que el control y

monitoreo de dispositivos, se puede realizar a través de alguna red local.

• Servidor: Es el ordenador, que recibe los comandos de control generados por la

aplicación cliente, y se los envía al microcontrolador USB. Y también envía hacia el

cliente los comandos de monitoreo, que recibe del microcontrolador USB.

• Módulo USB: Está compuesto por el microcontrolador USB, y los módulos de RF (Radio

Frecuencia) transmisor y receptor. En la figura 5.2.1, se puede observar que su función

es lograr la comunicación entre los dispositivos, y que además el módulo USB, es parte

también, de los módulos de control y de monitoreo.

• Microcontrolador USB: Su función principal, es la de tener comunicación entre los

módulos de control y monitoreo, ya que éste recibe los comandos de control y genera

comandos de monitoreo. Este microcontrolador, forma parte del módulo de control y

del módulo de monitoreo.

• Módulos de control: Se encarga de llevar a cabo la comunicación desde el

microcontrolador USB, hasta lograr encender o apagar los dispositivos a controlar, los

cuales pueden ser focos, bombas de agua, cerrojos eléctricos, puertas, etc.


76


• Módulo de monitoreo: Su función es la de informar al microcontrolador USB, cuál es

el estado de los dispositivos a monitorear, que pueden ser sensores de presencia,

sensores de humo, sensores de gas, etcétera; de igual forma, este módulo, será el

encargado de verificar el estado de los dispositivos a controlar (encendido o apagado),

lo cual se logra, con la comunicación existente entre el módulo de control y el módulo

de monitoreo, a través de sus microcontroladores correspondientes (véase fig. 5.2.1);

está comunicación es de tipo paralela, terminal a terminal de los microcontroladores, y

el microcontrolador decodificador enviará hacia el microcontrolador codificador, un

nivel de 0 Volts, para indicar que algún dispositivo a controlar está apagado, y un nivel

de 5 Volts, para indicar que algún dispositivo está encendido.

5.2.1 Comandos de control y comandos de monitoreo

La información que se maneja fuera y dentro de lo que es nuestro sistema electrónico de

comunicaciones, son los comandos de control y los comandos de monitoreo, que viajan en

direcciones distintas, y son originados de distintas maneras (véase fig. 5.2.1).

Los comandos de control, son utilizados, para encender o apagar algún dispositivo, y son

enviados desde el cliente, hasta el servidor (véase fig. 5.2.2). Estos comandos son números

enteros (de 1 byte), que son generados por la aplicación cliente, y recibidos por la aplicación

servidor, la cual también es encargada de enviar el comando de control hacia el

microcontrolador, a través del USB.

Se tienen dos tipos de comandos de control:

Comandos de encendido de dispositivo: Son comandos enviados desde el cliente, hacia

el servidor, con el fin de indicar, que un dispositivo se debe encender.

Comandos de apagado de dispositivo: Estos comandos igualmente son enviados desde

el cliente, hacia el servidor, pero, estos indican que un dispositivo debe ser apagado.


77


Una vez, que el comando de control es recibido por el servidor, éste lo envía al

microcontrolador USB, quien a su vez se encargará de codificarlo, y generar una señal en

banda base, para ser enviada a través del módulo de RF transmisor, hacia el módulo de RF

receptor del microcontrolador decodificador.

Los comandos de control que serán utilizados, aparecen en la tabla 5.2.1.

Comandos de control

Dispositivo Comando de encendido

Comando de apagado

Comando de actualización de estados

‐‐‐ ‐‐‐ ‐‐‐ 100 *

Dispositivo 1 101 1

Dispositivo 2 102 2

Dispositivo 3 103 3

Dispositivo 4 104 4

Dispositivo 5 105 5

Dispositivo 6 106 6

Dispositivo 7 107 7

Dispositivo 8 108 8

Dispositivo 9 109 9

Dispositivo 10 110 10

Tabla 5.2.1 Tabla de comandos de control conocidos, usados en el sistema.

En donde por ejemplo, el comando 101, enciende el Dispositivo 1, y el comando 1, apaga el

mismo dispositivo.


78


Internet Cliente

Comando de controlPor ejemplo: 101

Microcontrolador USB Servidor

Figura 5.2.2 Ejemplo de comando de control.

En la figura 5.2.2, se observa que el comando de control 101, es enviado desde el cliente,

hasta el microcontrolador USB. Este comando de control, es generado en la aplicación cliente,

al dar clic al botón de encendido del dispositivo 1; posteriormente este comando será

codificado por el microcontrolador USB, y se enviará inalámbricamente, por el módulo de

control, hasta que finalmente se encienda el dispositivo 1 (véase sección 5.2.2).

En el caso particular del comando de actualización de estados, éste no va a encender o apagar

algún dispositivo, si no que por medio de éste, será posible, la actualización manual de los

estados de los dispositivos, es decir, manualmente, será pedido al microcontrolador USB,

enviar cuáles detectores están activos e inactivos, y qué dispositivos a controlar se encuentran

encendidos y apagados.

Los comandos de monitoreo, son enviados desde el servidor hacia el cliente (véase figura

5.2.3), tienen la función de indicar cuál es el estado de los dispositivos a monitorear (activo o

inactivo), y de los dispositivos a controlar (encendido o apagado); igualmente, son números

enteros (de 1 byte), pero estos comandos serán originados por el microcontrolador USB, según

el estado de los dispositivos monitoreados.

El microcontrolador USB, podrá tener información del estado de los dispositivos monitoreados

y de los dispositivos a controlar, ya que el módulo de monitoreo, será el encargado de

transmitirle esta información.

Los comandos de monitoreo, se dividen y se subdividen de la siguiente manera:

Comandos de alarmas: Utilizados exclusivamente para los dispositivos a monitorear, es

decir, los detectores. Estos comandos a su vez se subdividen en:


79


‐ Comandos de alarma activa: Éstos indican que algún sensor ha detectado cambios

en el medio, por ejemplo, que un sensor de humo, ha detectado humo.

‐ Comandos de alarma inactiva: Estos comandos, indican que algún sensor no

detecta cambios en el medio, o ya deje de detectarlos (en caso de que haya estado

activo).

Comandos de estado de dispositivos: Éstos son utilizados para indicar el estado de los

dispositivos a controlar, es decir, sí están encendidos, o sí están apagados, y se

subdividen en:

‐ Comando de dispositivo encendido: Indican que algún dispositivo a controlar, está

encendido.

‐ Comando de dispositivo apagado: Indican que algún dispositivo a monitorear, está

apagado.

Los comandos de monitoreo que serán utilizados en el sistema, son los siguientes:

Comandos de alarma

DISPOSITIVO Comando de alarma activa

Comando de alarma inactiva

Sensor 1 31 21

Sensor 2 32 22

Sensor 3 33 23

Sensor 4 34 24

Tabla 5.2.2 Tabla de comandos de alarma usados en el sistema.


80


En donde, por ejemplo sí el comando 31, es enviado del microcontrolador al servidor, y del

servidor hacia el cliente, el cliente interpretará que el sensor 1 está activo, y si el cliente recibe

el comando 21, éste interpretará que el sensor 1 no tiene actividad.

Internet Cliente

Comando de monitoreo Por ejemplo: 31

ServidorMicrocontrolador USB

Figura 5.2.3 Ejemplo de comando de monitoreo.

La figura 5.2.3, muestra el ejemplo del comando 31 generado por el microcontrolador USB,

quien lo envía al servidor, y éste a su vez lo envía al cliente. Recordemos que este comando de

alarma, fue recibido de manera inalámbrica a través del módulo de monitoreo y del

microcontrolador USB (véase sección 5.2.2).

5.2.2 Módulo de control

En la sección anterior se mencionó a grandes rasgos, el funcionamiento del módulo de control;

sin embargo, ahora se verá cómo está integrado, y el funcionamiento de cada elemento que lo

compone.

En la figura 5.2.4, se puede observar el diagrama a bloques del módulo de control, el cual se

encargará de tener la comunicación entre el servidor y los dispositivos a controlar. Las flechas

color naranja, indican el sentido en el que viaja la información.

El módulo de control, se compone de los siguientes elementos:

Microcontrolador USB: En este módulo, el microcontrolador es utilizado para recibir

los comandos de control que le envía el servidor, y después los codifica. La

codificación de un comando, se hace de tal forma que se genera una señal en banda


81


base, la cual lleva una palabra de 12 bits llamada código de mando (véase sección

5.2.2.5 Proceso de codificación).

Módulo de RF, transmisor: Es un módulo de Radio Frecuencia, que modulará la señal

en banda base, generada por el microcontrolador USB, aplicándole la modulación ASK

(modulación por desplazamiento de amplitud), y transmitiendo a una frecuencia de

433.92 MHz.

Módulo de RF, receptor: Este módulo de RF, se encarga de recibir y demodular la

señal emitida por el transmisor que trabaja a su misma frecuencia (433.92 MHz), de

esta manera, obtenemos la señal en banda base, que fue generada por el

microcontrolador USB, logrando así la obtención de la palabra de 12 bits (código de

mando).

Microcontrolador decodificador: Es el encargado de interpretar la señal en banda

base, obtenida del receptor de RF; de esta forma el microcontrolador, encenderá o

apagará algún dispositivo, según el código de mando recibido. Para encender un

dispositivo, el microcontrolador en sus terminales de salidas digitales, envía un nivel

de voltaje a los circuitos de electrónica de potencia, manda 0 Volts para apagar un

dispositivo, y 5 Volts para encender un dispositivo.

Dispositivos a controlar: Como ya se mencionó, los dispositivos a controlar, pueden

ser focos, bombas de agua, cerrojos eléctricos, puertas eléctricas, etc. Sin embargo en

nuestro sistema, se simulará que los dispositivos a controlar, son los mostrados en la

tabla 5.2.3.


82


Aplicación

Dispositivo 1 Iluminación







Dispositivo 8 Bomba de agua

Dispositivo 9 Cerrojo eléctrico

Dispositivo 10 Puerta eléctrica

Tabla 5.2.3 Tabla de dispositivos a controlar

Figura 5.2.4 Diagrama a bloques del módulo de control.

En las siguientes secciones, se tratará todo lo que corresponde a la comunicación inalámbrica

en el módulo de control.


83


Primeramente, se explicará qué es un código de mando, cuáles son sus funciones, y cómo son

utilizados en el módulo de control; todo esto se hace, debido a que estos códigos son muy

utilizados en éste módulo.

5.2.2.2 Códigos de mando

Un código de mando es una palabra de 12 bits, que será utilizada en el módulo de control,

para encender o apagar algún dispositivo deseado; cada dispositivo tiene asignado un código

de mando para encender, y un código de mando para apagar, estos códigos están relacionados

con los comandos de control de encendido y los comandos de control de apagado,

respectivamente.

Los códigos de mando de encendido y de apagado, llegarán al microcontrolador decodificador

(véase fig. 5.2.5). Cuando un código de mando de encendido llega al microcontrolador

decodificador, éste interpreta el código, manteniendo un nivel de voltaje alto (5 V), en la

terminal donde se tiene conectado el circuito de potencia del dispositivo a encender. Cuando

un código de mando de apagado llega al microcontrolador decodificador, éste mantiene un

nivel bajo de voltaje (0V), en la terminal donde se tiene conectado el circuito de potencia del

dispositivo a apagar.

En la tabla 5.2.4, se observan los códigos de mando (en base hexadecimal), que tiene asignado

cada dispositivo para que éste sea encendido, así también se tiene su comando de control con

el que se relaciona.

Se dice que existe una relación entre un código de mando y un comando de control, ya que el

código de mando es generado por el microcontrolador USB, en respuesta a la petición de que

el cliente quiere encender o apagar algún dispositivo. Así, cuando el cliente quiere encender

algún dispositivo, éste envía hacia el servidor un comando de control de encendido de

dispositivo, el servidor envía este comando al microcontrolador USB.


84


Códigos de mando para encender dispositivos

Dispositivo Código de mando Comando de control

relacionado

Dispositivo 1 0x801h 101









Dispositivo 10 0x80Ah 110

Tabla 5.2.4 Relación de códigos de mando para encender dispositivos; que serán utilizados en el sistema, y sus

comandos de control relacionados.

El microcontrolador USB, recibe el comando de control y lo convierte en un código de mando

(palabra de 12 bits), después el mismo microcontrolador, crea una señal banda base, que

contiene el código de mando; la señal banda base es creada con el fin de ser transmitida

inalámbricamente, y así pueda ser recibida por el módulo de RF receptor, quien finalmente

entrega la señal banda base al microcontrolador decodificador, y éste a su vez, es el encargado

de decodificar la señal banda base, para obtener el código de mando, al reconocer el código de

mando, el microcontrolador decodificador, mantendrá un nivel de voltaje (0 Volts ó 5 Volts)

por alguna salida digital, en la que esté conectado el dispositivo a controlar. Todo este proceso

descrito, puede observarse en la figura 5.2.5.

Como ya se mencionó, los códigos de mando para apagar los dispositivos, también tienen

asignados ciertos comandos de control, la razón es, porque estos códigos pasan por el mismo

proceso que se mencionó anteriormente, es decir, el que se muestra en la figura 5.2.5.


85


La relación entre dispositivos, códigos y comandos para apagar algún dispositivo, se muestra

en la tabla 5.2.5.

Códigos de mando para apagar dispositivos

Dispositivo Código de mando Comando de control

relacionado










Dispositivo 10 0x81Ah 10

Tabla 5.2.5 Relación de códigos de mando para apagar dispositivos; que serán utilizados en el sistema, y sus

comandos de control relacionados.

5.2.2.3 Proceso de comunicación en el módulo de control

Debido a que el cliente será quien manipule los dispositivos; éste será quien tendrá que enviar

ciertos comandos, hacia el enlace de control, estos comandos o instrucciones son los que

llamamos comandos de control.

Para poder llevar a cabo el proceso de control de los dispositivos, primeramente, se debe

tener establecida la conexión entre el servidor y el cliente; de esta manera va a ser posible la

comunicación entre el módulo de control y el cliente, que como ya se mencionó, éste será

quien envíe los comandos de control para manipular los dispositivos.

1. El cliente deberá dar clic al botón de encendido o apagado del dispositivo a controlar;

así la aplicación cliente enviará un comando a través de Internet, hacia el servidor.


86


2. El servidor recibirá este comando por medio de la aplicación servidor, quien a su vez lo

enviará hacia el microcontrolador USB, a través de USB.

3. El microcontrolador USB recibirá el comando de control y lo interpretará, generando

un código de mando, es decir, una palabra de 12 bits (código para encender o apagar

dispositivo). Cada comando de control, tiene un correspondiente código de mando

(véase tablas 5.2.4 y 5.2.5).

4. El código de mando será codificado por el microcontrolador, creando una señal digital

en banda base; esta señal saldrá por una terminal de salida digital, y será enviada al

módulo de RF, transmisor.

5. La señal en banda base, recibida por el módulo transmisor de RF, es modulada y

transmitida a 433.92 MHz, por este módulo de RF.

6. La señal de RF, es recibida de manera inalámbrica, por el módulo de RF, receptor, y es

demodulada por éste mismo, obteniendo así la señal en banda base mencionada en el

paso 4; es decir, la señal que se generó en base a los 12 bits que componen el código

de mando.

7. La señal banda base que fue obtenida por el módulo receptor de RF, es enviada por

este módulo, hacia el microcontrolador decodificador.

8. La señal banda base es recibida y decodificada por el microcontrolador decodificador,

reconociendo así, el código de mando que fue enviado. Existe una relación de lo que

debe hacer el microcontrolador decodificador, de acuerdo al código de mando que

haya recibido; esta relación, se puede observar en las tablas 5.2.4 y 5.2.5. La acción

que puede tomar el microcontrolador decodificador, al reconocer el código de mando,

es mantener un nivel de voltaje en alguna de sus terminales de salida digital, este nivel

de voltaje puede ser: alto (para encender dispositivo) o bajo (para apagar dispositivo).

En la terminal de salida, en la que mantendrá el nivel de voltaje mencionado, se tendrá


87


conectado un circuito de potencia, de algún dispositivo. Para saber cuál es el circuito

de potencia, al que se le estará suministrando el voltaje, se tiene la información en las

tablas 5.2.4 y 5.2.5.

9. El circuito de potencia, será quien suministre la alimentación del dispositivo que se

desee encender o apagar. Para encender el dispositivo, deberá estar entrando un nivel

alto de voltaje (5 Volts), al circuito de potencia, y para apagar el dispositivo, deberá

estar entrando un nivel bajo de voltaje (0 Volts).

Con el fin de reafirmar el proceso que se mencionó en los puntos anteriores, veamos un

ejemplo real, que utilizamos en nuestro sistema. Una vez establecida la conexión entre cliente

y servidor, se realiza el proceso mostrado en la figura 5.2.5.


88


Figura 5.2.5 Ejemplo de comunicación en el enlace de control.

5.2.2

El tran

microc

USB, es

3. El m

frecue

velocid

ser alim

es que

nos pro

Sistema

2.4 Transmis

smisor inalám

controlador U

s el encargad

módulo de RF T

ncia de 433

dad de transm

mentado des

e se incremen

oporciona el

Fig

a de control y

Capítulo 5

sor inalámb

mbrico utiliza

USB y el mód

o de generar

TWS‐BS‐3, se

.92 MHz, y

misión de dato

de 3 V, hasta

nta el alcance

USB, esto es,

ura 5.2.6 Diagra

y monitoreo

5: Sistema ele

rico para el

do para el en

dulo de RF T

r y codificar la

e encarga de t

en modulac

os de 4 Kbps

a 12 V; la ven

e; en nuestro

5 Volts.

ama eléctrico de

de dispositiv

ctrónico de c

módulo de c

nlace de cont

TWS‐BS‐3(Rad

a información

transmitir ina

ción ASK (de

(Kilo bits por

ntaja que se t

caso, lo alim

el módulo USB c

vos a través

comunicacion

control

trol, físicame

dio Frecuenc

n, para así env

alámbricamen

esplazamient

r segundo); es

iene al alime

mentaremos c

con Tx y Rx inalá

de Internet c

nes

nte, está form

cia). El micro

viarla al módu

nte la informa

to de amplit

ste módulo d

entar a un ma

con el mismo

ámbricos.

con USB 2

89

mado por el

controlador

ulo TWS‐BS‐

ación, a una

tud), a una

e RF, puede

ayor voltaje,

voltaje que

009


90


En la figura 5.2.6, se muestra el diagrama eléctrico de lo que llamaremos módulo USB, este

módulo es el que conectamos al puerto USB del servidor. El módulo USB, permite la

comunicación entre Servidor/microcontrolador USB, y también incluye el módulo de RF,

transmisor, TWS‐BS‐3 y el módulo de RF, receptor, RWS‐374‐3, quien se encarga de recibir la

señal, demodularla y enviarla al microcontrolador USB, para su decodificación, sin embargo,

por el momento no prestaremos mucha importancia a la recepción de información, ya que

será vista, en la sección Receptor inalámbrico, para el módulo de control.

Las figuras 5.2.7, 5.2.8 y 5.2.9, muestran los diagramas de flujo del programa principal del

microcontrolador USB; dentro de este programa, se declara el vector recibe [2], se configura el

oscilador el oscilador que va a ser utilizado, en este caso, el microcontrolador USB, usará el

oscilador interno, a una frecuencia de 8 MHz, sin embargo, para lograr la comunicación con el

USB, utiliza una frecuencia de 48 MHz, que logra, con apoyo del cristal de cuarzo.

Después de configurar el oscilador a utilizar, se configuran las terminales digitales de

entrada/salida digital, para decidir cuales serán entradas, y cuales salidas digitales; después se

inicializan las salidas digitales, generalmente todas en nivel de voltaje bajo; se inicializa y se

configura el USB.

Posteriormente, se verifica que el oscilador interno se encuentre funcionando de manera

estable, esto se hace por medio de un bloque de decisión (if), y se verifica que se tenga un 1

lógico en el bit 2 del registro OSCCON (el cual se encuentra en la dirección 0x0FD3h); entonces

hasta que se tenga un 1 lógico en éste bit, el oscilador interno se encontrará estable, de lo

contrario, el oscilador interno, estará inestable. Una vez que se haya verificado que el oscilador

interno se encuentra estable, se podrá proseguir, a habilitar las interrupciones que se

utilizarán, es decir, la interrupción externa y las interrupciones del temporizador 2. La

interrupción externa será activada por flanco de elevación, es decir cuando exista una

transición de nivel de voltaje bajo a alto.

El bucle de la estructura while (TRUE), se estará ejecutando continuamente. Por lo tanto,

continuamente, el microcontrolador USB, estará comprobando si está numerado por el

ordenador al que está conectado (en este caso, el servidor), esto lo hace por medio de la

función usb_enumerated(), que devuelve un cero, cuando no está numerado.


91


Nota: El microcontrolador USB estará numerado, cuando haya sido reconocido por el

ordenador, al que se encuentra conectado.

Además, por medio de la función usb_kbhit(1), el microcontrolador estará verificando si se le

ha enviado algún dato desde el servidor, por el USB; la función usb_kbhit(1), devuelve un cero,

cuando no se ha mandado algún dato.

En caso, de que se haya enviado algún dato del servidor, al microcontrolador, entonces se

procede a invocar la función usb_get_packet(1, recibe, 3), quien se encarga de recibir el dato, y

lo guarda en el vector recibe. Las componentes del vector recibe, en el programa son llamados:

modo, para recibe [0] y param1, para recibe [1]. Esto se declara al principio del programa por

medio de:

#define modo recibe[0]

#define param1 recibe[1].

Recordando lo ya visto en la sección 5.2.2.3 Proceso de comunicación en el módulo de control.

En el proceso de comunicación del módulo de control, el cliente envía un comando de control,

que llega hasta el microcontrolador USB, el microcontrolador USB se da cuenta que le llegan

datos, debido a que continuamente se encuentra verificando si le ha llegado información.

Entonces, cuando llega información al microcontrolador, ésta es almacenada en el vector

recibe; que es lo mismo que guardar la información en las variables modo, y param1.

Como ya se mencionó, la aplicación servidor, se encarga de enviar el comando de control

hacia el microcontrolador USB, y lo envía de la siguiente manera:

Si el comando de control, es mayor o igual a 100; entonces modo=0, de lo contrario,

modo=1. Cuando modo=0, se tiene un comando de control de encendido de

dispositivo, y cuando modo=1, se tiene un comando de control de apagado de

dispositivo.

El valor que toma param1, está dado de la siguiente manera: Si el comando de

control, es mayor o igual a 100, param1=comando de control‐100; de lo contrario, el

comando de control será la misma cantidad que es éste sea.


92


Por ejemplo, si se recibió el comando de control 3; por lo tanto modo=1, y param1=3. Si

observamos la tabla 5.2.6, el comando 3, es un comando de control para apagar el dispositivo

3. En otro ejemplo; si se recibe el comando de control 103; por lo tanto modo=0, y param1=3.

Si observamos la tabla 5.2.6, el comando 3, es un comando de control para encender el

dispositivo 3.

Una vez obtenidos, los valores de modo y param1, el microcontrolador USB prosigue a, realizar

una serie de comparaciones, por medio de la instrucción if, y de esta forma, sólo hasta que se

cumplan las condiciones que se tienen, se sabrá que realizar, según los valores contenidos en

modo y param1.

En la tabla 5.2.6, se tiene la relación de las acciones que va a realizar el microcontrolador USB,

al recibir determinado valor de modo y param1, también se observa, el comando de control,

que el cliente envía al servidor, para que este último envíe los correspondientes valores de

modo y param1. Por ejemplo, si el cliente envía al servidor el comando de control 110, según

la tabla, el microcontrolador estará recibiendo los valores de: modo=0 y param1=10, y

posteriormente, cuando se cumpla la condición modo=0 y param1=10, el microcontrolador

USB iniciará la codificación del código de mando, para encender el dispositivo 10 (véase figura

5.2.5).

El caso especial, en el que se reciben los valores de modo=0 y param1=0 (véase tabla 5.2.6),

sucede cuando en la aplicación cliente se dió clic, al botón de “Actualizar manualmente” , de

esta manera, la aplicación cliente, envía hacia el servidor, el comando de control 100; el

servidor recibe este comando, y envía esta información, al microcontrolador USB, de la manera

en que ya fue explicada; es decir, se tiene el comando 100, por lo tanto modo=0, y

param1=comando de contol‐100, así obtenernos param1=0. Teniendo estas condiciones de

modo=0 y param1=0, lo que hace el programa, es inicializar en cero, las cuatro variables

comando_alarmaX_a (donde X es 1,2,3,4), y también inicializa las diez variables

comando_dispY_a (donde Y es 1,2,3,4,5,6,7,8,9,10), esto puede observarse en el diagrama de

flujo que muestra la figuras 5.2.7, 5.2.8 y 5.2.9. De esta manera se logrará actualizar

manualmente, los estados de las alarmas y los estados de los dispositivos controlados (véase

sección Verifica).


93


Valor de las

variables

Código de mando

que fue enviado

desde el cliente

Acción que el microcontrolador realiza

modo param1

0

0 100 Inicializa variables para que se actualicen los estados de los dispositivos.

1 101 Inicia la codificación del código de mando para encender el dispositivo 1.










1

1 1 Inicia la codificación del código de mando para apagar el dispositivo 1.










Tabla 5.2.6 Relación de las acciones que el microcontrolador USB realiza, de acuerdo a los valores de las variables

modo y param1.


94


Como se observa en el diagrama de flujo de las figuras 5.2.7 y 5.2.8, todos los demás casos,

que se tienen en las comparaciones, ya son muy similares; y lo que hace cada uno, es iniciar el

proceso de codificación. (Véase sección 5.2.2.5 “Proceso de codificación”)

El microcontrolador USB, continuamente se encuentra decodificando la información recibida

del módulo RF, receptor. El microcontrolador no va a decodificar y codificar información al

mismo tiempo. Por lo tanto para codificar, es necesario detener el proceso de decodificación

en el microcontrolador. De esta manera, el microcontrolador será capaz de dedicarse

únicamente al proceso de codificación.

Condiciones de codificación para el microcontrolador USB

Todos los casos, en donde se inicie algún proceso de codificación (véase tabla 5.2.6), detienen

el proceso de decodificación, y ponen las condiciones para que la información deseada, pueda

ser codificada. Lo que se menciona en este párrafo, se logra teniendo las siguientes

condiciones de codificación, que pueden observarse en cada caso del diagrama de flujo de las

figuras 5.2.7, 5.2.8 y 5.2.9:

Deshabilitar las interrupciones externas. Debido a que éstas son utilizadas para

decodificar la información, y nuestro sistema, solamente es capaz de hacer una cosa a

la vez, es decir, o codifica, o decodifica. Por lo tanto de esta manera, se evita el hecho

de estar decodificando las señales proporcionadas por el módulo de RF receptor.

Limpiar la bandera INT0IF. La bandera INT0IF, se pone en 1, cuando sucede una

interrupción externa (en nuestro caso por flanco de elevación), esta bandera debe ser

limpiada (puesta a cero) manualmente, y lo hacemos, para que posteriormente, las

interrupciones externas, estén listas para ejecutarse. Se logra limpiar la bandera

INT0IF, con la instrucción bit_clear(*0x0FF2,1); la cual pone en cero el bit 1 del registro

que esta en la dirección 0x0FF2h, que es la correspondiente al registro INTCON.

Poner en 1 la variable tx_pend. Esta variable, es utilizada, para indicar que se tiene

una transmisión pendiente, es decir, que se requiere codificar información; cuando


95


tx_pend=1, las interrupciones del temporizador 2, no son utilizadas para decodificar,

sino para codificar (véase sección Interrupción del temporizador 2).

Guardar el código de mando en la variable info_tx. Se deberá guardar el código de

mando (de encendido o de apagado), el cual es una palabra de 12 bits. La variable

info_tx, siempre tendrá la información que va a ser codificada.

Indicar el número de palabras que van a ser enviadas. Es decir, debemos indicar el

número de veces, que se va a codificar la palabra de 12 bits contenida en info. En el

programa, se asigna de la siguiente manera: npalabras_tx=tpalabras; y se hace de esta

manera, ya que la variable tpalabras, nunca cambia de valor, y está inicializada con el

valor de 28. En este programa se codificará 28 veces la misma palabra, con el fin de

enviar redundancia, y así, si existió algún error en la transmisión, el receptor podrá

corregir los errores detectados, (véase sección Verifica).

Inicializar variables nciclos, nbits y periodo_osc. Estas variables son vistas con mayor

profundidad en la sección 5.2.2.5 Proceso de codificación.

Configurar el temporizador 2. El temporizador 2, debe ser ajustado para lograr, la

frecuencia a la que estaremos codificando, en este caso es de 3.5 Khz. Por lo tanto el

temporizador 2, deberá estar produciendo interrupciones cada 1/3.5Khz ≈ 285.71 µs;

obtener este valor exactamente, no se logra, el valor mas cercano es de 286 µs, y se

consigue con la instrucción: setup_timer_2(T2_DIV_BY_4,143,1).

Habilitar las interrupciones del temporizador 2. Finalmente se habilitan las

interrupciones del temporizador 2, es decir, cada 286 µs, se estará ejecutando la rutina

de servicio del temporizador 2, por medio de esta rutina, se estará codificando la

información.


96


Figura 5.2.7 Diagrama de flujo del programa principal del microcontrolador USB.


97




98



Entonces, por ejemplo, si el cliente envía al servidor, el comando de control 101; el servidor,

enviará al microcontrolador USB los valores de: modo=0 y param1=1 (véase tabla 5.2.6), que si

verificamos, en el diagrama de flujo de la figura 5.2.7 y 5.2.8; se iniciará la codificación del

código de mando 0x0801h, el cual enciende el dispositivo 1 (véase tabla 5.2.4).

Como ya se mencionó, se inicia el proceso de codificación, cuando se habilitan las

interrupciones del temporizador 2, esta última acción va a permitir que cada vez que el

temporizador llegue a su tiempo programado, se ejecute la rutina de servicio del temporizador

2, que realizará el proceso de codificación. Como resultado de esta codificación, vamos a

obtener un tren de pulsos (señal en banda base), que va a tener un determinado formato; la

señal codificada, saldrá por la terminal RA0 (del microcontrolador USB), hacia la entrada de


99


datos del módulo TWS‐BS‐3, como se muestra en la figura 5.2.5; de esta manera estaremos

transmitiendo una señal, de manera inalámbrica.

5.2.2.5 Proceso de codificación

Hasta ahora, solamente hemos hablado de datos binarios, es decir, se mencionó cómo es que

el microcontrolador USB reconoce un comando de control. También se vio, cómo es que este

microcontrolador interpreta estos datos binarios, asignando a la variable info, el código de

mando de 12 bits, es decir, un código de mando de encendido, o apagado, del dispositivo

correspondiente. Como podemos observar en el diagrama a bloques del transmisor, antes de

modular la información, tenemos un código de línea. (Véase fig. 5.1.2).

El código de línea será necesario aplicarlo a la información, ya que su función de este, es

convertir información binaria, en este caso, 12 bits (código de mando de encendido o

apagado), en niveles de voltaje o corriente, con el objetivo de generar una señal en banda

base, lista para ser enviada al módulo TWS‐BS‐3 (véase fig. 5.2.5), a este procedimiento le

llamaremos proceso de codificación, el microcontrolador USB será quien realice esta función

de codificación, por medio de la rutina de servicio del temporizador.

Una vez que el comando de control haya sido reconocido por el microcontrolador USB (como

ya se mencionó en la sección anterior), entonces se consiguen las condiciones, para comenzar

el proceso de codificación, y por medio de las interrupciones producidas cada determinado

tiempo, se va a llevar a cabo este proceso.

Para comprender cómo se lleva a caso este proceso de codificación, primero debemos

entender lo que se quiere realizar en la codificación, y de que manera se va a hacer.

La codificación utilizada en este proceso, está basada en la codificación que realiza el

dispositivo HT12E, el cual es un codificador de la marca Holtek.


100


Figura 5.2.10 Estructura de la información codificada por el HT12E.

En la figura 5.2.10, se muestra como está compuesta la información ya codificada. Se puede

observar que antes de la palabra de 12 bits (8 bits de dirección y 4 bits de datos), tenemos un

tiempo en el que no se envía información, este tiempo existe entre cada palabra de 12 bits

codificada, con ayuda de este tiempo sin transmisión, será más fácil de identificar cuando

empieza la palabra. La duración del periodo sin transmisión, equivale al tiempo que

tardaríamos en transmitir 12 bits, es decir, 12 bits x 3 ciclos (1/3.5KHz) = 10.285 ms

(posteriormente será explicado como se obtienen estos valores).

En esta misma figura vemos también, el pulso de sincronización, que como su nombre lo dice,

permitirá al dispositivo receptor, sincronizarse, es decir, ajustar su señal de reloj, para que esté

en fase con la frecuencia del oscilador del transmisor. Este pulso de sincronización tiene una

duración de un periodo de la fOSC, es decir, (1/3.5KHz) = 285.714 µs.

La manera en que está codificada la palabra de 12 bits, se puede observar en la siguiente

figura.

Figura 5.2.11 Codificación de datos binarios.


101


En la figura 5.2.11, podemos observar que para codificar, se utiliza un oscilador, que en

nuestro sistema, utilizamos una frecuencia de oscilador (fOSC) de 3.5KHz, también notamos que

para codificar cada bit, se requieren 3 periodos de la señal del oscilador; por lo tanto, el

tiempo que se utiliza para transmitir un bit, es de:

31

3.5 857.142

En cuanto a la manera de codificar los datos (véase Fig. 5.2.11), se hace de la siguiente manera:

para el caso del bit uno codificado, los dos primeros periodos están en nivel bajo y el tercero

está en nivel alto; en el caso del bit cero codificado, el primer periodo de la señal del oscilador

está en nivel bajo, y los últimos dos periodos, están en alto. De esta manera, vamos a distinguir

bit uno del bit cero.

Veamos el ejemplo de la estructura de una palabra codificada, lista para ser enviada al módulo

TWS‐BS‐3. La palabra a codificada puede ser utilizada en el transmisor inalámbrico del enlace

de control, o en el del enlace de monitoreo.

Para el enlace de control, puede ser un código de encendido o un código de apagado; en el

enlace de control, sería un código de activación.

La palabra a codificar es 0xAAAh, es decir, 101010101010 en binario; en el programa

codificador del microcontrolador USB, esta palabra sería guardada en la variable info. El

microcontrolador USB, cuando codifique esta información, estaría saliendo por la terminal

RA4, y la señal obtenida en esta señal, sería como la mostrada en la figura 5.2.12.


102


Es importante recordar, que cuando se quiera enviar inalámbricamente algún código de

mando (código de encendido o apagado), el microcontrolador USB estará enviando 28

palabras de 12 bits, iguales (códigos de mando), una tras otra, con una separación de

aproximadamente 10.28 ms, como se muestra en la figura anterior. La finalidad de enviar 28

palabras, es la de agregar redundancia, y así reducir la probabilidad de tener algún bit erróneo.

Estas 28 palabras, son las que serán enviadas hacia la entrada de datos del módulo TWS‐BS‐3,

quien se encargará de modular y amplificar la señal para ser transmitida a través de la antena.

5.2.2.6 Programa codificador

Cabe mencionar, que tanto en el módulo de control, como en el módulo de monitoreo, la

parte de codificación es similar; la única diferencia, radica, en el origen de los datos, ya que en

el módulo de control, los datos a codificar, se eligen a partir de los datos enviados por el

servidor, y en el módulo de control, los datos a codificar, se eligen a partir del estado de los

dispositivos a monitorear (detectores), y del estado de los dispositivos controlados.

En esta sección se explicará el funcionamiento del programa que realiza el proceso de

codificación, en el módulo de control. Y se va a partir, de que ya se sabe el funcionamiento del

programa que representan los diagramas de flujo de las figuras 5.2.7, 5.2.8 y 5.2.9 (programa

Figura 5.2.12 Ejemplo de una palabra en banda base para transmisión inalámbrica.


103


principal del microcontrolador USB). En este programa, continuamente se verifica, si el

servidor ha enviado algún comando de control. Cuando algún comando de control, fue

reconocido, se consiguen las condiciones de codificación (véase sección 5.2.2.4 “Transmisor

inalámbrico para el módulo de control”), éstas son:

Deshabilitar las interrupciones externas.

Limpiar la bandera INT0IF.

Poner en 1 la variable tx_pend.

Guardar el código de mando en la variable info_tx.

Indicar el número de palabras que van a ser enviadas.

Inicializar variables nciclos, nbits y periodo_osc.

Configurar el temporizador 2.

Habilitar las interrupciones del temporizador 2.

Antes de continuar, con la función que tienen las interrupciones del temporizador 2, se va a

explicar cómo se configura el temporizador 2, y cómo se habilitan y deshabilitan las

interrupciones del temporizador2.

Configuración del temporizador 2.

Para configurar el temporizador 2, se tiene la instrucción setup_timer_2(T2_DIV_BY_4,143,1),

por medio de esta instrucción, el oscilador se ajusta a una frecuencia cercana a la del oscilador

usado en el proceso de codificación, es decir, fosc 3.5KHz (véase fig. 5.2.11 ó fig. 5.2.12).

Cuando se configura el temporizador, se ajusta el lapso de tiempo que debe transcurrir para

que se produzca una interrupción del temporizador 2, y en consecuencia de esta interrupción,

se ejecutará la rutina de servicio de la interrupción del temporizador 2.

Nota: El temporizador 2, funciona en base a Fosc/4, en donde Fosc, es la frecuencia del oscilador

que esté utilizando el microcontrolador; nuestro sistema, estará utilizando el oscilador interno

a 8MHz, por lo tanto Fosc/4=2MHz.

La instrucción para configurar el temporizador 2, tiene la siguiente estructura:


104


setup_timer_2(mode, period, postscale)

En donde:

mode: Indica entre que valor queremos dividir la frecuencia que utiliza el temporizador 2,

es decir, mode, indica el valor entre el que deseamos sea dividido Fosc/4. Así el

temporizador, va a funcionar en base a la frecuencia indicada; por ejemplo se usó

T2_DIV_BY_4; de esta forma indicamos que la frecuencia que se estará utilizando para el

temporizador 2, es f=2MHz/4=500 KHz.

period: Es un número comprendido entre 1 y 255, que indica el valor en el que el

temporizador, se inicializa en cero. Esto es, porque cada vez que el temporizador empiece a

funcionar, tiene con contador interno que iniciará en cero, e incrementará su valor cada

que haya transcurrido un periodo de la frecuencia ajustada en mode. En nuestro caso

entonces tenemos el número 223, por lo tanto, cada vez que la cuenta del temporizador

llegue a 223, éste se inicializará en cero.

postscale: Es un número que puede tener valores de 1‐15, y nos indica el número de veces

que el temporizador se inicializa en cero, antes de la interrupción. Entonces por ejemplo, si

tenemos el número 1, quiere decir que sólo habrá una cuenta de 0 a 223 en el

temporizador, y entonces existirá una interrupción.

Con lo que ya se explicó, se puede proceder a realizar el cálculo del lapso de tiempo que debe

transcurrir, para que exista una interrupción.

Como nos basaremos en una f 500KHz, entonces se calcula su periodo:

T 1500KHz 1.25µs

Como el period = 223, se realizarán cuentas desde 0 hasta 223. El tiempo que tarda en hacer

esta cuenta entonces, es de:

T 143500KHz 286µs


105


Finalmente postscale = 1, por lo tanto sólo existirá una cuenta de 0 a 223. Y el lapso de tiempo

que existe desde que el temporizador se inicializa en cero y se produce la interrupción del

temporizador, es de:

ó143

500KHz 1 286µs

De lo anterior, se puede obtener la fórmula para el cálculo de cualquier ó :

óperiod postscale

f /4 /T2_DIV_BY_X4 period postscale T2_DIV_BY_X

f

Ecuación 5‐1

Hasta ahora, ya hemos configurado el temporizador, para que produzca interrupciones cada

286 µs, el cual, si calculamos su frecuencia, tenemos el siguiente valor:

ó1

2863.496

Y se observa que logramos una frecuencia muy próxima a los 3.5 KHz, requeridos para

codificar. Hasta ahora, solamente logramos ajustar a la frecuencia deseada; sin embargo, para

que el temporizador comience a funcionar, es necesario permitir todas las interrupciones y

además habilitar la interrupción del temporizador 2.

Para permitir todas las interrupciones, se utiliza la instrucción enable_interrupts(GLOBAL). Ya

con el permiso de que existan interrupciones, será necesario habilitar las interrupciones

requeridas, de manera individual. Entonces, para habilitar las interrupciones del temporizador

2, se usa la instrucción enable_interrupts(INT_TIMER2).

Rutina de servicio del temporizador 2.

Ahora se verá qué es lo que hace la rutina de servicio que ejecutada cada vez que se produce

una interrupción del temporizador 2, ya que por medio de esta rutina se va a codificar la

información. El diagrama de flujo mostrado en la figura 5.2.12, muestra la rutina de servicio del

temporizador 2, que se ejecuta cada 286 µs.


106


Figura 5.2.13 Diagrama de flujo de la rutina de servicio del temporizador 2, del microcontrolador USB.

Por medio la variable tx_pend, se elige la utilidad del temporizador 2 del microcontrolador

USB, que puede ser: para codificar o para decodificar. Cuando tx_pend=1, por medio del

temporizador 2, se codifica, en otro caso por medio del temporizador 2, se decodifica (véase

figura 5.2.13). tx_pend=1, indica que existe una transmisión pendiente, por lo tanto es

necesario codificar; por lo tanto tx_pend=0, indica que no existe transmisión pendiente, y no

es necesario codificar.

Supongamos que el microcontrolador ha recibido un comando de control conocido (véase

tabla 5.2.1 ”Tabla de comandos de control conocidos, usados en el sistema”), por lo tanto, el

microcontrolador procederá a lograr tener las condiciones de codificación. De estas

condiciones, retomemos que se inician las interrupciones del temporizador 2, y que

tx_pend=1, por lo tanto mientras tx_pend mantenga el valor de 1, cada vez que se produzca

una interrupción:

Se va a llamar a la función CODIFICA.

Se limpiará la bandera TMR2F (es el bit 1 del registro PIR1, localizado en la dirección

0xF9Eh), que se pone a uno, cada vez que es producida una interrupción del

temporizador 2.

Se apagará el led conectado en la terminal RA3.


107


Función CODIFICA

El diagrama de flujo de la función CODIFICA, se muestra en la figura 5.2.14.

Figura 5.2.14 Diagrama de flujo de la función que codifica palabras de 12 bits, para generar una señal en banda

base.

Nota: La señal banda base codificada, sale por la terminal RA4 del microcontrolador.

Lo que realiza esta función, es la de codificar 28 veces la misma palabra de 12 bits, que está

almacenada en la variable info_tx.


108


La terminal A2, es utilizada como salida digital, y se tiene conectado un LED, a esta terminal,

por medio de este led, se indicará cuando se inicia y cuando se termina la transmisión de las 28

palabras de 12 bits, que deseamos codificar.

Las variables y constantes usadas en la función CODIFICA, son nbits, tpalabras, npalabras_tx,

info_tx, info_tempo_tx, a continuación se menciona a grandes rasgos su uso:

nbits: Esta variable, va a tomar valores entre 0 y 13, esto es debido a que indicará el

número del bit de la palabra (de 12 bits) en que nos encontramos; de esta forma,

cuando nbits tiene un valor de 0, se estará indicando que estamos en el inicio de la

codificación de una palabra, lo cual es un pulso de sincronización (véase figura 5.2.12),

una vez creado el pulso de sincronización, nbits se incrementa, y toma el valor de 1,

esto indica que nos encontramos en el bit D0 (primer bit) de la palabra, una vez

codificado este bit, se incrementa nbits tomando el valor de 2, ahora indicando que

estamos en el bit D1 (bit 2) de la palabra; y así sucesivamente se indica en qué bit de

la palabra, nos encontramos; finalmente, cuando nbits tome el valor de 13, ya hemos

codificado una palabra, por lo tanto es necesario, dejar de codificar información

durante un tiempo de aproximadamente 10.296 ms, lo cual se realiza con la función

T_12BITS(), (véase sección “Función T_12BITS”).

tpalabras: Es una constante utilizada, para que su valor sea asignado a la variable

npalabras_tx. La variable tpalabras, es inicializada fuera del programa principal del

microcontrolador (main), y su valor constante es 28.

npalabras_tx: Esta variable indica el número de palabras que se han enviado

codificadas, por esta razón, toma valores de 3 a 0, cuando tiene valor de 3, se está

codificando la primer palabra, cuando toma el valor de 2, se codifica la segunda, y así

sucesivamente, hasta que toma el valor de 0, que es cuando se indica que ya se

transmitieron las 3 palabras.

info_tx: Como ya se había mencionado, la variable info_tx tendrá almacenados los 12

bits que deseamos codificar y transmitir, por facilidad de uso, se asignan valores a

info_tx, de forma hexadecimal.


109


info_tempo_tx: Va a ser una variable auxiliar, ya que cuando se esté realizando la

codificación, se va a utilizar un desplazamiento hacia la izquierda de un bit,

modificando el valor de ésta variable.

Dentro de la función CODIFICA, se tienen tres funciones: COD_BIT_UNO, COD_BIT_CERO y

T_12BITS. Cabe mencionar, que la función CODIFICA, es la misma función que la rutina de

servicio, para el microcontrolador codificador, del módulo de monitoreo.

Uso de la variable nciclo en las funciones COD_BIT_UNO, COD_BIT_CERO.

Tanto en la función COD_BIT_UNO, como en la función COD_BIT_CERO, se utiliza la variable

nciclo, la cual es utilizada para contar el número de periodos del oscilador usado para codificar,

dentro del periodo de bit (véase Fig. 5.2.15), es decir, su valor estará cambiando idealmente

cada T 1/3.5KHz 285.71μs y tomará valores de 1,2 ó 3 ciclos, según el periodo del

oscilador en el que se encuentre. El tiempo real en el que los valores de nciclo estarán

cambiando, será, el tiempo existente entre cada interrupción (véase sección “Configuración del

temporizador 2”), es decir cada 286 µs, por lo tanto, estaremos considerando que:

3.496 .

En la figura 5.2.15, se ejemplifica, cómo es que nciclo lleva la cuenta, del número de ciclo en el

que se encuentre.

Figura 5.2.15 Ejemplo del funcionamiento de la variable nciclo.


110


Función COD_BIT_UNO.

La función COD_BIT_UNO, es llamada, cuando en la función CODIFICA encuentra que es

necesario codificar un uno lógico, es decir, cuando es verdadera la condición info_tempo_tx &

0x800; la cual hace la operación AND, del valor de la variable info_tempo_tx, con el valor

hexadecimal 0x800, es decir, 0x800 en binario es 1000 000 0000.

Para aclarar esta operación, veamos el ejemplo, en el que se tiene que el valor de

info_tempo_tx = 0x0AAA.

INFORMACIÓN HEXADECIMAL INFORMACIÓN BINARIA

info_tempo_tx 0AAAh 0000 1010 1010 1010

‐‐‐ 800h 0000 1000 0000 0000

info_tempo_tx & 0x800 0AAA&0800 = 0800h 0000 1000 0000 0000

Tabla 5.2.7 Ejemplo en el que se requiere codificar un bit de valor 1 lógico.

Si observamos el resultado, en la parte inferior derecha, de la tabla 5.2.7, se tiene un valor que

no es cero, por lo tanto, la condición se vuelve verdadera, y es necesario codificar, un bit de

valor 1 lógico.

La función COD_BIT_UNO, saca la señal correspondiente a un bit uno, codificado, a través de la

terminal RA4 del microcontrolador. Para recordar la manera en que se codifica el bit de valor 1

lógico, véase la figura 5.2.11 ó 5.2.15, ya que este proceso lo realiza la función COD_BIT_UNO,

que se muestra en diagrama de flujo, en la figura 5.2.16.


111


Figura 5.2.16 Diagrama de flujo de la función COD_BIT_UNO.

Nota: La función info_tempo_tx<<=1, hace un desplazamiento de un bit hacia la izquierda, a la

variable info_tempo_tx.

Nota: Los ciclos de reloj son referidos, a los ciclos que transcurren tomando en cuenta que se

está codificando con un oscilador de 3.496 (configuración del temporizador 2).

Función COD_BIT_CERO.

La función COD_BIT_CERO, es invocada, cuando la función CODIFICA, encuentra, que es

necesario codificar un bit de valor 0 lógico, es decir, cuando es falsa la condición

info_tempo_tx & 0x800; la cual hace la operación AND, del valor de la variable info_tempo_tx

con el valor hexadecimal 0x800, es decir, 0x800 en binario es 1000 000 0000.

Para aclarar está operación, tomemos como referencia el ejemplo que se ve en la tabla 5.2.7,

en el que se tenía que el valor de info_tempo_tx = 0x0AAAh; pero ahora vamos a suponer que

a la variable info_tempo_tx, se le hizo un desplazamiento hacia la izquierda de un bit, es

decir, se le aplicó la operación info_tempo_tx<<=1, por lo tanto después del corrimiento,


112


info_tempo_tx = 0x1555h. Por lo tanto, la operación de info_tempo_tx & 0x800, queda, de la

siguiente manera:

INFORMACIÓN HEXADECIMAL INFORMACIÓN BINARIA

info_tempo_tx 1555h 0001 0101 0101 0101

‐‐‐ 800h 0000 1000 0000 0000

info_tempo_tx & 0x800 0AAA&0800 = 0800h 0000 0000 0000 0000

Tabla 5.2.8 Ejemplo en el que se requiere codificar un bit de valor 0 lógico.

Observando el resultado, en la parte inferior derecha, de la tabla 5.2.8, se tiene un valor igual a

cero, por lo tanto, la condición es falsa, y es necesario codificar, un bit de valor 0 lógico.

La función COD_BIT_CERO, saca la señal del bit cero codificado, a través de la terminal RA4 del

microcontrolador. Para recordar la manera en que se codifica el bit de valor 0 lógico, véase la

figura 5.2.11 ó 5.2.15, ya que este proceso lo realiza la función COD_BIT_CERO, mostrada en

diagrama de flujo, en la figura 5.2.17.

Figura 5.2.17 Diagrama de flujo de la función COD_BIT_CERO.


113


Nota: La función info_tempo_tx<<=1, hace un desplazamiento de un bit hacia la izquierda, a la

variable info_tempo_tx.

Nota: Los ciclos de reloj son referidos, a los ciclos que transcurren tomando en cuenta que se

está codificando con un oscilador de 3.496 (configuración del temporizador 2).

Función T_12BITS.

La función T_12BITS, es la encargada de mantener en nivel bajo (sin transmisión), por un

tiempo equivalente a transmitir 12 bits, a la terminal RA4 del microcontrolador.

Para obtener el valor del tiempo equivalente a transmitir 12 bits, es necesario recordar que

por cada bit codificado, se requieren tres ciclos del oscilador (véase fig. 5.2.15), entonces el

periodo de bit= 3(286µs)=858µs; pero se quiere encontrar el tiempo en que se transmiten 12

bits, por lo tanto, periodo de 12 bits=12*periodo de bit=10.296 ms.

De una manera muy similar a la anterior, podemos obtener el valor de 10.296 ms, y ésta es,

realizando la siguiente operación: periodo de 12 bits=12*3*286 µs =36*286 µs=10.296 ms ;

recordemos que 286 µs, es el tiempo que existe entre cada interrupción del temporizador 2.

Por lo tanto, la función T_12BITS, va a mantener en nivel bajo 10.296 ms; y este tiempo sin

transmisión es generado entre palabra y palabra de 12 bits, véase figuras 5.2.10 y 5.2.12.

Cabe mencionar que la variable periodo_osc toma valores de 0 a 36; es utilizada únicamente

en la función T_12BITS, y se va a encargar de llevar la cuenta de los periodos del oscilador, que

han transcurrido durante el tiempo de 10.296 ms (tiempo en que no se codifica información).

El valor periodo_osc =0, indica que nos encontramos en el primer periodo del oscilador usado

para codificar (tiempo entre cada interrupción del temporizador 2), cuando periodo_osc vale 1,

se indica que ha transcurrido solo un periodo, y así sucesivamente, hasta que periodo_osc

tenga el valor de 36, es entonces, cuando ya transcurrieron 10.296 ms, y se procederá a

codificar otra vez la palabra, o terminar de codificar, si ya se terminaron de codificar las 28

palabras (npalabras_tx=0), que ya han sido mencionadas.


114


En la figura 5.2.18, se observa el diagrama de flujo de la función T_12BITS.

Figura 5.2.18 Diagrama de flujo de la función T_12BITS.

5.2.2.7 Receptor inalámbrico usado en el módulo de control.

El receptor inalámbrico usado en el módulo de control, es el encargado de recibir e interpretar

las señales de Radio Frecuencia, que fueron transmitidas por el módulo de RF transmisor TWS‐

BS‐3. El diagrama a bloques de este receptor inalámbrico, se muestra en la figura 5.2.19, como

puede observarse, el receptor inalámbrico se compone únicamente del modulo de RF

Receptor y un microcontrolador.

El módulo de RF utilizado, es el RWS‐374‐6, el cual es un circuito que puede demodular señales

que estén a una frecuencia de 433.92 MHz y moduladas por medio de ASK. Este módulo se

alimenta con 5 Volts, y la velocidad de datos a la que recibe, es de 4800 bps.


115


Figura 5.2.19 Diagrama a bloques del receptor inalámbrico utilizado para el módulo de control.

El diagrama eléctrico, del receptor inalámbrico, se muestra en la figura 5.2.20.

En el diagrama de la figura 5.2.20, se pueden observar las terminales en donde será conectado

algún circuito de potencia de un dispositivo a controlar. Para saber la relación de la terminal y

el circuito de potencia que debe ser conectado a ésta, se muestra la información en la tabla

5.2.9.

Sistema

Figura 5.2.20

Circ

DispDisp

DispDispDispDispDispDisp

DispDisp

Tabl

a de control y

Capítulo 5

0 Diagrama eléct

cuito de pot

positivo 1 positivo 2

positivo 3 positivo 4 positivo 5 positivo 6 positivo 7 positivo 8

positivo 9 positivo 10

a 5.2.9 Relación

y monitoreo

5: Sistema ele

trico del recepto

encia del:

n de terminales

de dispositiv

ctrónico de c

or inalámbrico,

Terminal dedecodificadRA2 RA3

RA4 RA5RA6 RC0RC1 RC2

RC4 RC5

y circuitos de po

vos a través

comunicacion

utilizado en el m

el microcontdor

otencia correspo

de Internet c

nes

módulo de cont

trolador

ondientes.

con USB 2

116

rol.

009

5.2.2

Nuestr

los dis

encend

decir 0

al micr

aislado

son ali

El diag

observ

interna

encuen

estos r

TRIAC

que el

Observ

la entr

ella y e

valores

son 1.2

Sistema

2.8 Circuito d

ro circuito de

spositivos a

dido algún di

0 Volts. El uso

rocontrolado

o físicamente

mentados po

grama eléctr

va, la entrada

amente tiene

ntre funciona

rayos, produc

es disparado

dispositivo co

vamos en el d

ada del MOC

el LED infrar

s típicos, mos

2 V a 5 mA. Po

a de control y

Capítulo 5

de potencia.

potencia, es

controlar, ya

spositivo, co

o de este circ

r, ya que por

de la carga, e

or 120 Volts d

Figura 5.2.

ico del circu

a de voltaje

e un LED infra

ando, éste le

cirá una pequ

o, este cierra

ontrolado enc

diagrama de

C3011, ésta si

rojo del MOC

strados en su

or lo tanto, e

y monitoreo

5: Sistema ele

la interfaz ex

a que por m

n tan solo 5

uito de poten

r medio del M

en este caso,

e corriente a

.21 Diagrama el

ito de poten

se encuentra

arrojo y un fot

va a hacer in

ueña corrient

el circuito q

cienda.

la figura 5.2.

rve para divid

C3011, de es

u hoja de esp

l valor de la r

de dispositiv

ctrónico de c

xistente, entre

medio de es

Volts, y será

ncia, se hace

MOC3011, el

la carga son

lterna.

léctrico del circu

ncia, es mos

a en el MOC

to transistor,

ncidir rayos in

e, que será c

que alimenta

21, una resis

dir el voltaje

sta manera e

pecificaciones

esistencia qu

vos a través

comunicacion

e el microcon

ste circuito d

apagado, en

con la finalid

microcontro

los dispositiv

uito de potencia

strado en la

C3011, esto e

de tal mane

nfrarrojos al f

capaz de disp

al dispositiv

tencia que se

de salida del

ste LED, pod

. Los valores

ue se mencion

de Internet c

nes

ntrolador dec

de potencia,

n ausencia de

dad también

olador queda

os a controla

a.

figura 5.2.2

es porque el

ra que cuand

fototransistor

arar al TRIAC

o controlado

e encuentra c

microcontro

drá ser alimen

típicos de al

nó, será:

con USB 2

117

odificador y

, podrá ser

e voltaje, es

de proteger

totalmente

r, los cuales

1, como se

l MOC3011,

do el LED, se

r, quien con

C. Cuando el

o, y provoca

conectada a

lador, entre

ntado a sus

imentación,

009


118


í5 1.25

760Ω

El valor de una R= 760 Ω, sería para obtener los valores de alimentación típicos para el LED,

pero éste tiene valores de alimentación máximos, que son 1.5 V a 10 mA, si calculamos una

resistencia, para obtener estos valores de alimentación, obtendremos un valor de resistencia

mínima y será:

í5 1.510 350Ω

De los dos valores calculados anteriormente, se observa que R puede tomar valores que se

encuentren en el rango de Rmínima<R<Rtípica, es decir, 350Ω < R < 760Ω.

5.2.2.9 Proceso de decodificación

El proceso de decodificación, en nuestro sistema de comunicaciones, es realizado por algún

microcontrolador, para el caso del módulo de control, este proceso es realizado por el

microcontrolador decodificador, véase figura 5.2.5.

El proceso de decodificación, consiste en interpretar la señal en banda base que proviene del

módulo de RF receptor, es decir, recuperar la información binaria que está codificada en la

señal en banda base. Este proceso, sucede de manera inversa, al proceso de codificación, para

saber cómo lo hace nuestro sistema, veamos un ejemplo de señal en banda base (palabra de

12 bits codificada), y el proceso que se lleva a cabo con este tren de pulsos.

Observemos la figura 5.2.15, que muestra dos señales, una es la señal del “oscilador” utilizado,

ya que cada ciclo del “oscilador”, es una interrución del temporizador 2. La otra señal, es una

palabra de 12 bits codificada en una señal en banda base, en ella se observa, lo que es el pulso

de sincronización al inicio del tren de pulsos, y después se observan los 12 bits codificados, de

la manera en que se muestra en la figura 5.2.15.

5.2.2.10 Programa decodificador

En el microcontrolador USB, la decodificación se estará realizando continuamente, mientras no

exista información que deba ser transmitida, es decir, mientras se mantenga la condición


119


tx_pend!=1. En cambio en el microcontrolador decodificador, se estará realizando el proceso

de decodificación continuamente sin interrupción.

Rutina de servicio de la interrupción externa 0.

El proceso de decodificación, se inicia con la detección de un flanco de elevación producido en

la terminal de entrada digital RB0, se hace a partir de detectar este flanco, debido a que es

necesario tener sincronizado, el “reloj” (temporizador 2) del receptor (microcontrolador), con

la señal que se está recibiendo.

A partir de detectar el flanco de elevación, se produce una interrupción provocada por el

flanco de elevación, lo que ocasiona que sea ejecutada la rutina de servicio correspondiente, a

lo que es llamada interrupción externa 0, pues es la que le corresponde a la terminal RB0.

En la figura 5.2.22, se observa el diagrama de flujo de la rutina de servicio de la interrupción

externa 0, que se estará ejecutando mientras se encuentren habilitadas estas interrupciones.

Es decir, por medio de esta rutina de servicio, se encuentra el inicio de una palabra de 12 bits

codificada.

Figura 5.2.22 Rutina de servicio de la interrupción externa 0.

Como se observa, en el diagrama de flujo de la rutina de servicio de la interrupción externa 0,

lo que realiza es deshabilitar estas interrupciones, y también configura y habilita las

interrupciones del temporizador 2, por lo tanto, lo que procederá, es que se ejecute la rutina


120


de servicio del temporizador 2, al transcurrir 142 µs, para encontrar este tiempo, recurrimos a

la ecuación 5‐1, de la sección “Configuración del temporizador 2”, sustituyendo los valores de

la instrucción setup_timer_2(T2_DIV_BY_4,71,1), tenemos:

ó4 period postscale T2_DIV_BY_X

f

4 71 1 48MHz

142μ

La rutina de servicio del temporizador 2, ya fue vista en la sección denominada “Interrupciones

del temporizador 2”, si observamos su correspondiente diagrama de flujo en la figura 5.2.13,

se puede observar que para el caso de que se cumpla tx_pend!=1, entonces, será ejecutada la

función DECODIFICA.

Función DECODIFICA.

Recordemos que únicamente la condición tx_pend==1, se cumple, cuando se requiere codificar

y transmitir información, por lo tanto, la función DECODIFICA, continuamente se estará

ejecutando, mientras no se codifique información. La información que el microcontrolador

USB estará decodificando, será, la proveniente del microcontrolador codificador del módulo de

monitoreo, (véase figura 5.2.32 ó 5.2.33).

En las figuras 5.2.23 y 5.2.24, se puede observar el diagrama de flujo correspondiente a la

función decodifica.

A grandes rasgos, la función DECODIFICA, interpreta la señal banda base codificada recibida

por el modulo RF receptor, y almacena 7 veces la misma palabra, para que al final comparen

todas las palabras y se puedan corregir algunos posibles errores que puedan existir.


121


Figura 5.2.23 Diagrama de flujo de la función DECODIFICA (parte 1).


122


Figura 5.2.24 Diagrama de flujo de la función DECODIFICA (parte 2).


123


El funcionamiento de la función DECODIFICA, se basa en la verificación de los niveles de voltaje

(tomar muestras) en ciertos puntos, que nos dan información, acerca de la palabra que está

codificada en la señal banda base que se está recibiendo. En la primera vez que se ejecuta la

función DECODIFICA, el valor de nmuestra es cero, este valor se va incrementando, cada vez

que sea producida una interrupción del temporizador 2, es decir, cada 286 µs, ya que cuando

nmuestra=0, el temporizador 2, es configurado para que las interrupciones sean producidas

cada 286 µs, esto, se hace por medio de la instrucción setup_timer_2(T2_DIV_BY_4,143,1).

La variable nmuestra tendrá el valor de 37, cuando ya se hayan tomado todas las muestras que

se requieren para decodificar la palabra, esto se ilustra en la figura 5.2.27.

Ahora veamos cuál es el comportamiento de la variable nsubmuestra, cuando se encuentra

decodificando la señal banda base correspondiente de una palabra de 12 bits codificada. En la

figura 5.2.25, se ilustra que un periodo de bit, nsubmuestra, toma valores de 0,1 y 2; y esto

mismo sucede para todos los 12 periodos de bit, correspondientes de la palabra de 12 bit.

Para que el microcontrolador reconozca lo que representa la señal banda base, se van a tomar

muestras unicamente, cuando nsubmuestra tiene valor de 1 y cuando nsubmuestra tiene valor

de 2; cuando nsubmuestra tiene el valor de 0, no se toma una muestra debido a que, por la

manera en que está codificada la información, se sabe que el nivel de voltaje, siempre va a ser

nivel bajo.

Figura 5.2.25 Comportamiento de las variable nsubmuestra, cuando se está decodificando.


124


La variable n_alto se encargará de contar los niveles de voltaje altos, que existen en un

periodo, tomando en cuenta que se tomarán dos muestras en cada periodo de bit (cuando

nsubmuestra=1, y cuando nsubmuesta=2). Esto es, por ejemplo para un bit de valor 0 lógico,

n_altos, deberá tener el valor de 2, ya que si observamos la figura 5.2.25, cuando se toman las

dos muestras, en las dos muestras, se tienen dos niveles altos de voltaje. Pero ahora si se tiene

un bit de valor 1 lógico, se tendría entonces que n_altos=1, pues, si verificamos en la figura

5.2.25, cuando se toman las dos muestras, solamente tenemos un nivel alto.

En la figura 5.2.27, se observan, los lugares de la señal banda base en donde se toman las

muestras; estos lugares, están indicados, por flechas que apuntan hacia arriba, y son los

lugares, en donde la variable nsubmuestra, toma los valores de 1 y 2.

Y es asi, que cuando nsumbuestra=2, el microcontrolador, ya puede saber, qué valor lógico es

el bit que representa una porción de la señal que está se examinando; de manera que va

guardando y recorriendo el valor de este bit, a una variable, hasta encontrar el valor de los 12

bits.

Al final, cuando la variable nmuestra toma el valor de 37, se han tomado todas las muestras,

para reconocer el valor de la palabra de 12 bits, y es en este momento, cuando las

interrupciones del temporizador 2 son detenidas, pues ya se ha recibido una palabra completa.

Entonces, el valor de la palabra es asignado a un elemento del vector info, empezando por el

elemento info[1].

Después, se vuelve a habilitar la interrupción externa, con lo que está esperando recibir otra

palabra, y pasará por el mismo proceso, y se almacenará en el elemento del vector info[2], y

así sucesivamente, hasta llegar a almacenar la palabra en el vector info[7]. Entonces, al final

tendremos la misma palabra, almacenada 7 veces, es decir, una palabra en cada elemento del

arreglo info, desde el elemento info[1],al elemento info[7].

Función VERIFICA.

Una vez que se tienen almacenadas las 7 palabras, en el arreglo info, se procede a llamar a la

función VERIFICA, la cual se encargará de corregir posibles errores que se hayan tenido en la


125


transmisión, almacenando la palabra de 12 bits corregida, en el elemento info[0], con este

elemento, se harán una serie de comparaciones, para encontrar qué es lo que el

microcontrolador debe de hacer, de acuerdo a la información contenida, en la palabra

recibida.

Las acciones que debe realizar el microcontrolador USB, son, enviar comandos de control,

cuando sea necesario, veáse el diagrama de flujo de la función VERIFICA, que es mostrado en

la figura 5.2.26.

Corrección de errores

La función VERIFICA, comienza inicializando los elementos bits_info[1] al bits_info[12], después

se verifica el número de bits de valor 1 lógico, en cada elemento del vector info; para entender

esto, veamos un ejemplo, en el que vamos a suponer que se tienen almacenados los valores

mostrados en la tabla 5.2.10, la cual muestra una simulación, en donde se transmitió la palabra

0xC07h, y se han recibido palabras con algunos errores.

Elemento del

arreglo

Palabra almacenada

Hexadecimal Binario

D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0

info[1] 0x061 0 0 0 0 0 1 1 0 0 0 0 1

info[2] 0x816 1 0 0 0 0 0 0 1 0 1 1 0

info[3] 0xC07 1 1 0 0 0 0 0 0 0 1 1 1

info[4] 0xD09 1 1 0 1 0 0 0 0 1 0 0 1

info[5] 0x863 1 0 0 0 0 1 1 0 0 0 1 1

info[6] 0xC07 1 1 0 0 0 0 0 0 0 1 1 1

info[7] 0xC07 1 1 0 0 0 0 0 0 0 1 1 1

Tabla 5.2.10 Simulación de palabras que se han recibido con errores.

Entonces en la función VERIFICA, se va a contar el número de bits de valor 1 lógico, de

acuerdo a la posición de cada bit, es decir, se van a contar el número de 1’s, que hay en la

posición de D0, D1, D2, D3, D4, D5, D6, D7, D8, D9, D10, D11; el valor de esta cuenta, es almacenado


126


en cada elemento del arreglo bits_info, desde el bits_info[1] hasta el bits_info[12],

respectivamente.

Entonces los elementos del arreglo bits_info, tendrán almacenada la información, mostrada en

la tabla 5.2.11.

Elemento

Valor almacenado en el elemento del arreglo bits_info

Posición de bit correspondiente

Valor del bit, de acuerdo a su posición

bits_info[1] 6 Bit 0 1 bits_info[2] 5 Bit 1 1 bits_info[3] 4 Bit 2 1 bits_info[4] 1 Bit 3 0

bits_info[5] 1 Bit 4 0 bits_info[6] 2 Bit 5 0 bits_info[7] 2 Bit 6 0 bits_info[8] 0 Bit 7 0 bits_info[9] 1 Bit 8 0 bits_info[10] 0 Bit 9 0 bits_info[11] 4 Bit 10 1

bits_info[12] 6 Bit 11 1 Palabra

obtenida info[0] ‐‐‐ ‐‐‐ 1100 0000 0111

Tabla 5.2.11 Valores de los elementos del arreglo bits_info, para el ejemplo de la tabla 5.2.10.

De acuerdo al valor que se tenga almacenado en cada elemento del arreglo bits_info; será el

valor que será asignado al bit correspondiente, de cada elemento. Esto se hace primeramente

basándonos, en que el número de palabras que se tienen almacenadas (en el arreglo info), son

7, de tal forma, que si se encontraron en una posición de bit, la cantidad de 4 o más bits con

valor 1 lógico, al bit localizado en esa posición, le corresponde el valor de 1 lógico, en caso de

que se encontrarán menos de 4 bits con valor 1 lógico, al bit localizado en esa posición, le

corresponde un valor de 0 lógico. Siguiendo estas reglas, veamos los resultados del ejemplo

que se viene describiendo, véase en la tabla 5.2.11.


127


De esta manera, se logran corregir correctamente, hasta 3 errores por posición de bit, es decir,

se pueden corregir correctamente, hasta 12x3=36 errores, ya que se tienen 12 posiciones de

bit.

Figura 5.2.26 Diagrama de flujo de la función VERIFICA.

Identificación de códigos.

La identificación de códigos, también se realiza, en la función VERIFICA, en el diagrama de

flujo, comienza a partir del número 1.

Primeramente, se verifica la dirección que tiene la palabra que se recibió, y se pueden tener

dos direcciones la 0x0C00h, ó la 0x0800h. La dirección de 0x0C00h, es utilizada exclusivamente

para los palabra de estado de los dispositivos controlados (Véase sección 5.2.3.2), es decir,

como su nombre lo dice, nos van a proporcionar información acerca de los estados de los

dispositivos controlados (si están encendidos o apagados).


128


La dirección 0x0800h, se utiliza únicamente para los palabras de estadode los dispositivos

monitoreados (Véase sección 5.2.3.1), y estos códigos, proporcionan información acerca de los

estados de los dispositivos monitoreados, es decir, si los detectores están activos, o inactivos.

Una vez identificada, el tipo de dirección recibida, si se recibió una dirección de palabra de

estado de los dispositivos controlados (0x0C00h), se verifica el valor de los bits 0, 1, 2, 3, 4, 5,

6, 7, 8 y 9. Cada bit está asignado al estado de un dispositivo en específico, esto se explica en la

sección 5.2.3.2. Si el valor del bit verificado, es un 1 lógico, quiere decir que el dispositivo

controlado está encendido, y si es un 0 lógico, entonces, el dispositivo controlado está

apagado. Después de verificar cada bit, el microcontrolador, decide si enviar o no, un comando

de monitoreo, ya que este comando, es únicamente enviado, cuando el estado del dispositivo

ha cambiado, es decir, si estaba apagado, y el dispositivo fue encendido, entonces envía un

comando de monitoreo, indicando al cliente que el dispositivo fue encendido, y sucede algo

similar, cuando el dispositivo se encontraba encendido y fue apagado. Por ejemplo, entonces si

se recibe la palabra 0xE6Fh = 1110 0110 11112; el microcontrolador primero identifica que esta

palabra tiene la dirección 0xC00, que pertenece a la dirección de palabras de estado de los

dispositivos monitoreados. Una vez que se sabe que se ha recibido un palabra de estado de

los dispositivos monitoreados, se procede a verificar el estado de los dispositivos

monitoreados, es decir, verificar el valor lógico de los bits 0, 1, 2, 3, 4, 5, 6, 7, 8 y 9. Entonces el

microcontrolador, se dará cuenta que los dispositivos que se encuentran encendidos, son los

dispositivos: 1, 2, 3, 4, 6, 7 y 10, y por lo tanto, los dispositivos que se encuentran apagados,

son los dispositivos: 5, 8 y 9.

En el otro caso, es decir, cuando se haya recibido una dirección de palabra de estado de los

dispositivos monitoreados (0x0800h), se verifica el valor de los bits 0, 1, 2 y 3. Sucede algo

similar que en el caso anterior para estos códigos, pues también cada bit es asignado al estado

de cada dispositivo a monitorear, y de igual forma, si el valor de cada bit verificado es un 1

lógico, el dispositivo monitoreado, está activo, y si se tiene un 0 lógico, entonces el dispositivo

monitoreado, está inactivo. De igual forma después de verificar cada bit, el microcontrolador,

decide si es necesario enviar un comando de monitoreo al cliente, pues sólo es enviado,

cuando el estado del dispositivo monitoreado cambia, como se explicó para el caso de los

estados de los dispositivos controlados. Entonces por ejemplo, cuando se reciba la palabra


129


0x803h = 1000 0000 0011, el microcontrolador identifica que los detectores que están activos,

son los detectores 1 y 2.

Ejemplo de palabra decodificada.

Finalmente, en la figura 5.2.27, se tiene un ejemplo de señal en banda base, con los valores

que toman algunas variables, cuando se está decodificando esta señal; también, en esta figura

se muestran los puntos, en donde se verifica el nivel de voltaje que se tiene, estos puntos

están indicados con las flechas que apuntan hacia arriba; si se observa la figura 5.2.27, cuando

se toma una muestra, y el nivel de voltaje es alto, la variable n_alto se incrementa en uno, es

decir, la variable n_alto, cuenta el número de niveles de voltaje alto, que hay en cada periodo

de bit.


130


Figura 5.2.27 Ejemplo de palabra codificada en banda base, y los puntos en donde se toman muestras para su decodificación.

Periodo de bit


131


5.2.3 Módulo de monitoreo

El módulo de monitoreo, como ya se mencionó, es el encargado, de informar al

microcontrolador USB, acerca del estado de los dispositivos a monitorear (activo o inactivo) y

del estado de los dispositivos a controlar (encendido o apagado), este informe se hace

inalámbricamente, como se muestra en la figura 5.2.28. El proceso de informar acerca del

estado de los dispositivos monitoreados, y el estado de los dispositivos controlados, se hace

enviando alternadamente e inalámbricamente, desde el microcontrolador codificador, una

palabra de estado de los dispositivos monitoreados, y una palabra de estado de los

dispositivos controlados, el mismo microcontrolador codificador, será el encargado de

codificar estas palabras de 12 bits, y generar sus señales en banda base correspondientes.

En la figura 5.2.28, se tiene el diagrama a bloques del módulo de monitoreo, y las flechas

indican el sentido en el que viaja la información, en la sección 5.2.3.3 “Proceso de

comunicación en el módulo de monitoreo”, se darán más detalles acerca del recorrido que

hace la información.

Figura 5.2.28 Diagrama a bloques del módulo de monitoreo.


132


El módulo de monitoreo se compone de los siguientes elementos:

Microcontrolador decodificador: Su única función de éste, es la de informar al

microcontrolador codificador, cuál es el estado de los dispositivos a controlar (apagado

o encendido), para ello se utiliza una comunicación paralela es decir, que se utiliza un

cable para cada dispositivo a controlar. Las terminales de salidas digitales, del

microcontrolador decodificador proporcionan al microcontrolador codificador, un

nivel de voltaje de 0 Volts, para indicar un dispositivo apagado, y un nivel de voltaje de

5 Volts para un dispositivo encendido.

Dispositivos a monitorear: Son circuitos detectores, tales como detectores de

presencia, de humo, de gas, etcétera. Estos circuitos, proporcionarán individualmente,

un nivel de voltaje a alguna terminal del microcontrolador (configurada como entrada

digital) de 0 Volts, para indicar que el detector no tiene actividad alguna (no esta

activo), o un nivel de 5 Volts, para indicar que el detector está activo (se ha detectado

algún cambio en el medio).

Microcontrolador codificador: Su función es la de verificar, el estado de los

dispositivos a monitorear (sensores), y el estado de los dispositivos a controlar. Una

vez que el microcontrolador verificó el estado de los dispositivos mencionados, esté va

a codificar esta información en dos palabras diferentes, de 12 bits. Una palabra de 12

bits, será utilizada para transmitir la información del estado de los dispositivos a

monitorear, esta palabra la llamaremos palabra de estado de los dispositivos a

monitorear. La otra palabra de 12 bits, será utilizada para transmitir la información del

estado de los dispositivos a controlar, y la llamaremos palabra de estado de los

dispositivos a controlar. Una vez que codifica alguna de estas dos palabras, éste

mismo microcontrolador, también genera la señal en banda base, que tiene ésta

información (palabra de 12 bits).

Módulo de RF, transmisor: Éste módulo de Radio Frecuencia, es un circuito de

matricula TWS‐BS‐6, el cual se encargará de modular y transmitir, la señal en banda

base que fue generada por el microcontrolador codificador. Modulando en ASK, a una


133


frecuencia de 315 MHz; con el fin de que la comunicación no se interfiera, con la

comunicación que se tiene en el módulo de control.

Módulo de RF, receptor: Su función es la de recibir y demodular la señal emitida por el

transmisor, y de esta manera, obtener la señal en banda base que generó el

microcontrolador codificador. Este modulo de RF, trabaja a una frecuencia de 315

MHz.

Microcontrolador USB: Éste microcontrolador tiene la función de interpretar la señal

en banda base proveniente del receptor de RF, de esta manera, obtiene la palabra de

12 bits generada por el microcontrlolador codificador. Ésta palabra de 12 bits, puede

ser el palabra de estado de los dispositivos a monitorear, o el palabra de estado de

los dispositivos a controlar. Una vez que el microcontrolador USB reconoce la palabra

12 bits, éste, puede interpretar la información, identificando el estado de los

dispositivos (a monitorear o a controlar), y así comunicarle al servidor, cuál es el

estado de estos dispositivos. Para informar, al servidor, cuál es el estado de los

dispositivos, el microcontrolador USB, enviará algún comando de monitoreo, según

sea necesario.


134


5.2.3.1 Palabra de estado de los dispositivos a monitorear.

La palabras de estado de los dispositivos a monitorear, es una palabra de 12 bits, utilizada en

el módulo de monitoreo, su función es la de indicar al microcontrolador USB, cuál es el estado

de los dispositivos a monitorear, es decir, sí algún detector se ha activado, o no.

Estas palabras son generadas por el microcontrolador codificador, en función del estado de los

dispositivos detectores, pues cada detector tiene asignada una terminal de entrada digital del

microcontrolador, como se muestra en la tabla 5.2.12.

Detector al que se

verifica su estado

Terminal del microcontrolador

codificador

Detector 1 RB0

Detector 2 RB1

Detector 3 RB2

Detector 4 RB3

Tabla 5.2.12 Asignación de las terminales del microcontrolador codificador, de acuerdo al detector, del que cada

una verifica su estado.

De acuerdo al nivel de voltaje que entra a su terminal, el microcontrolador codificador, lo

interpretará de la siguiente manera:

1. Mientras esté entrando un nivel de voltaje bajo en la terminal del microcontrolador,

éste interpreta, que el detector se encuentra activo (detecta algo).

2. Mientras esté entrando un nivel de voltaje alto en la terminal del microcontrolador,

éste interpreta, que el detector se encuentra inactivo (no detecta algo).

Es decir, que si entra un nivel de voltaje bajo a la terminal RB3, el microcontrolador

interpretará que el Detector 4 se encuentra activo, y los demás están inactivos.

Se dice que un detector esta activo, cuando haya detectado algún cambio en el medio, como

puede ser que el detector de presencia por ejemplo, haya detectado la presencia de alguien;


135


en consecuencia, se dice que el detector esta inactivo, cuando no haya detectado algún

cambio en el medio.

La estructura de las palabras de estado de los dispositivos a monitorear, es la mostrada en la

figura 5.2.29.

Figura 5.2.29 Estructura de la palabra de estado de los dispositivos a monitorear

Observando la figura 5.2.29, se puede notar que el bit 11 contiene un bit 1 lógico y que el bit

10 contiene un 0 lógico, estos valores, son utilizados como dirección, por lo tanto, todas las

palabras en el módulo de monitoreo, que contengan esta dirección, serán palabras de estado

de los dispositivos a monitorear.

También en la figura 5.2.29, se observa que los bits 0, 1, 2, 3, muestran el estado de los

detectores, y no tienen un valor asignado, sino una “X”, lo cual nos indica que puede tomar

cualquier valor lógico (0 ó 1 lógico); un 0 lógico indica que el detector está inactivo, es decir,

que no hay presencia de algo; en cambio un 1 lógico indica que el detector ha encontrado algo

(presencia, humo, gas, etc.). Los bits restantes del bit 4, al bit 9, no son utilizados, sin embargo

pueden ser usados para más dispositivos detectores.

5.2.3.2 Palabra de estado de los dispositivos a controlar.

La palabra de estado de los dispositivos a controlar, es una palabra de 12 bits, que se utiliza

en el módulo de monitoreo, y su función es la de indicar al microcontrolador USB, cuál es el

estado de los dispositivos controlados, es decir si algún dispositivo se encuentra encendido o

apagado. Como ya se vio en la sección 5.2.2 “Módulo de control”, los dispositivos controlados,

pueden ser de iluminación, bombas de agua, cerrojos eléctricos, etc.

La palabra de estado de los dispositivos a controlar, es generada por el microcontrolador

codificador, en función de los niveles de voltaje que el microcontrolador decodificador (del


136


módulo de control) envía al microcontrolador codificador, ya que a través de estos niveles de

voltaje, es posible saber cuál es el estado de los dispositivos controlados.

Nota: Los niveles de voltaje que envía el microcontrolador decodificador, provienen de la

misma línea que alimenta al circuito de potencia de los dispositivos a controlar, como se

observa en la figura 5.2.36.

Cada terminal del microcontrolador, tiene asignada verificar el estado de cierto dispositivo

controlado, esto se hace como lo muestra la tabla 5.2.13.

Dispositivo al que se verifica su estado

Terminal del microcontrolador codificador

Dispositivo 1 RA2 Dispositivo 2 RA3 Dispositivo 3 RA4

Dispositivo 4 RA5 Dispositivo 5 RC0Dispositivo 6 RC1 Dispositivo 7 RC2Dispositivo 8 RC4 Dispositivo 9 RC5Dispositivo 10 RC6

Tabla 5.2.13 Asignación de las terminales del microcontrolador codificador, de acuerdo al dispositivo, del que

cada una verifica su estado.

El microcontrolador codificador, interpretará los niveles de voltaje que entran a estas

terminales, de la siguiente manera:

1. Mientras se esté inyectando un nivel de voltaje bajo en la terminal del

microcontrolador, éste interpreta, que el dispositivo está apagado.

2. Mientras se esté inyectando un nivel de voltaje alto, a la terminal del

microcontrolador, éste interpreta que el dispositivo está encendido.

Entonces, si se recibe un nivel de voltaje alto en las terminales RC1 y RC6, y en las demás

terminales, se recibe un nivel de voltaje bajo, el microcontrolador codificador, interpretará que

los dispositivos 6 y 10, se encuentran encendidos, y los demás están apagados.


137


La estructura de la palabra de estado de los dispositivos a controlar, se muestra en la figura

5.2.30.

Figura 5.2.30 Estructura de la palabra de estado de los dispositivos a controlar.

Si observamos la figura 5.2.30, nos daremos cuenta que los bits 10 y 11, son bits de dirección y

tienen un valor fijo de 1 lógico, lo cuál quiere decir, que todas las palabras en el módulo de

monitoreo, que empiecen con estos valores de bits, serán identificadas como palabra de

estado de los dispositivos a controlar.

También en la figura 5.2.30, se observa que los bit 0, 1, 2, 3, 4, 5, 6, 7, 8 y 9, son utilizados,

para mostrar el estado de los dispositivos 1, 2, 3, 4, 5, 6, 7, 8, 9 y 10, respectivamente; y en la

figura 5.2.30, no se tiene algún valor lógico asignado, sino que se tiene una “X”, lo cual quiere

decir que estos bits, pueden tomar cualquier valor lógico, es decir 0 ó 1; un 0 lógico, indica que

el dispositivo, se encuentra apagado, y un 1 lógico, indica que el dispositivo se encuentra

encendido.

5.2.3.3 Proceso de comunicación en el módulo de monitoreo

El proceso de comunicación inalámbrico en el módulo de monitoreo, comienza desde que el

microcontrolador codificador, verifica los estados, de los detectores y de los dispositivos

controlados, como ya se mencionó en la secciones 5.2.3.1 y 5.2.3.2. Después de haber

verificado estos estados, el microcontrolador codificador, primeramente se crean y se

codifican en señales banda base, 28 palabras de estado de los dispositivos a monitorear, una

tras otra, y se envían estas señales banda base, hacia el módulo de RF transmisor.

Una vez transmitidas, las 28 palabras de estado de los dispositivos a monitorear, se crean y se

codifican 28 palabras de estado de los dispositivos a controlar, igualmente, esto se realiza una

tras otra, y así como van siendo codificadas en su señal banda base, son enviadas hacia el

módulo de RF transmisor.


138


Entonces, el microcontrolador codificador, estará enviando alternadamente 28 palabras de

estado de los dispositivos a monitorear, y 28 palabras de estado de los dispositivos a

controlar.

Proceso de comunicación para el envío de las palabras de estado de los

dispositivos a monitorear.

Anteriormente se mencionó que el microcontrolador codificador, es quien genera la palabra

de estado de los dispositivos a monitorear, pero aún no se ha dicho, cuál es el procedimiento

para hacer esto. Este procedimiento, se muestra en la figura 5.2.32, y a continuación se

describe el proceso que se lleva a cabo en cada paso. Los detectores individualmente tendrán

que mantener un nivel de voltaje dependiendo de su estado, el nivel de voltaje puede ser alto

(5 V) ó bajo (0 V). Mientras no detectan algún cambio en el medio (humo, gas, presencia,

etcétera), deberán mantener un nivel de voltaje alto, y mientras los detectores perciben algún

cambio en el medio (humo, gas, presencia, etcétera), deberán mantener un nivel de voltaje

bajo. En la figura 5.2.32, se observa, que cada detector individualmente, envía éstos niveles de

voltaje, hacia las entradas digitales del microcontrolador codificador.

1. Debido a que se tienen cuatro detectores, se usan cuatro entradas digitales del

microcontrolador, es decir, una entrada digital para cada detector, y es en estas

terminales, en donde se va a inyectar el nivel de voltaje proporcionado por los

detectores. De esta manera, el microcontrolador codificador, podrá reconocer, cuáles

detectores se han activado, y cuales aún no detectan cambios en el medio.

2. Una vez que el microcontrolador reconoce el estado de los detectores, es capaz de

generar la palabra de estado de los dispositivos a monitorear, la cual ya se vio su

estructura anteriormente. Y en la figura 5.2.32, se genera la palabra 0x803h, o su

equivalente en binario 1000 0000 0011. La palabra 0x803h es generada, con éste valor,

ya que se está suponiendo que los detectores 1 y 2, están activos (mantienen un nivel

de voltaje bajo a su salida), los detectores 3 y 4, no están en activos, y los valores de


139


los bits 4 al 9, tienen valores de cero lógico, debido a que no se tiene asignado estos

bits, al estado de algún detector.

Figura 5.2.31 Ejemplo de palabra de estado de los dispositivos a monitorear

3. Ahora que el microcontrolador ya sabe, el valor de la palabra de estado de los

dispositivos a monitorear, esté va a codificarla, generando una señal en banda base,

que será enviada por una terminal de salida digital hacia el módulo de RF transmisor.

Esta codificación, se hace, en base a lo que se menciona, en la sección 5.2.2.5 “Proceso

de codificación”.

4. La señal en banda base que fue enviada por el microcontrolador, es inyectada a la

entrada del módulo de RF transmisor, quién se encarga de modular y transmitir esta

señal por medio de Radio Frecuencia.

5. La señal de Radio Frecuencia que fue transmitida, es recibida y demodulada por el

módulo de RF receptor, de esta manera, el módulo de RF, recupera la señal en banda

base, que se menciona en el paso 4.

6. La señal en banda base, es enviada desde el módulo de RF, hacia una terminal

configurada como entrada digital, del microcontrolador USB.

7. El microcontrolador USB, decodifica la señal banda base, y la interpreta como la

palabra de estado de los dispositivos a monitorear, que fue enviada, es decir 0x803h.

Este proceso de decodificación, funciona de manera similar, al visto en la sección

5.2.2.9 “Proceso de decodificación”.


140


8. Ya que se obtuvo la palabra de estado de los dispositivos a monitorear, el

microcontrolador USB, podrá identificar cuál es el estado de los detectores y así

decidir, cuáles son los comandos de alarma que debe enviar hacia el servidor. Una vez

identificados cuáles son los comandos de alarma que van a ser enviados, éstos serán

enviados uno tras otro, a través del USB. Sin embargo, es importante mencionar, que

no siempre se van a enviar los comandos de alarma; solamente serán enviados,

cuando algún dispositivo monitoreado haya cambiado de estado, es decir, cuando

pasa de un estado inactivo a un estado activo, o cuando el detector haya pasado de un

estado activo a un estado inactivo.

9. La aplicación servidor recibe el(los) comando(s) de alarma y lo(s) reenvía al cliente, a

través de internet.

10. La aplicación cliente recibe el(los) comando(s) de alarma enviados por el servidor, y

lo(s), a través de ésta aplicación se podrá saber, cuál es el estado de los dispositivos

monitoreados.

Proceso de comunicación para el envío de las palabras de estado de los

dispositivos a controlar.

El proceso que se lleva a cabo, para la generación y codificación en señales banda base, de las

palabras de estado de los dispositivos a controlar, se muestra en la figura 5.2.33, el proceso

es muy similar al que se menciona en la sección 5.2.3.3, en el subtema “Proceso de

comunicación para el envío de las palabras de estado de los dispositivos a monitorear”. La

única diferencia, es que ahora serán verificados los estados de los dispositivos a controlar.


141


Figura 5.2. 32 Ejemplo de comunicación para el monitoreo de los detectores, desde la aplicación cliente.


142


Figura 5.2.33 Ejemplo de comunicación para el monitoreo de los dispositivos a controlar, desde la aplicación cliente.

5.2.3.4

El transm

dispositiv

enviadas,

estructura

Como se

de un mic

Nota: las

DD2, DD3

Sistema de

Transmisor

misor inalámb

vos a monitor

hacia el rec

a física del tra

muestra en e

crocontrolado

Figura 5.2.34

terminales D

3, DD4, respe

e control y m

Capítulo

r inalámbric

brico, será el

rear y las pala

ceptor de RF

ansmisor inal

el diagrama e

or, y un módu

4 Diagrama a elé

DD1, DD2, DD

ectivamente,

monitoreo de

o 5: Sistema e

co usado en e

encargado e

abras de esta

F, del módu

ámbrico para

léctrico de la

ulo de RF, tran

éctrico del trans

D3, DD4 de l

de la figura

dispositivos

electrónico de

el enlace de

enviar inalám

ado de los dis

ulo USB. Está

a el enlace de

figura 5.2.34

nsmisor.

smisor inalámbr

a figura 5.2.3

5.2.35. Y las

s a través de

e comunicacio

monitoreo.

mbricamente

spositivos con

á sección, se

e monitoreo.

4, el transmis

rico usado en el

34, están con

terminales R

Internet con

ones

las palabras

ntrolados; es

erá enfocada

or inalámbric

módulo de mon

nectadas a lo

RA2, RA3, RA

n USB 200

de estado d

stas palabras

únicamente

co está comp

nitoreo.

os terminales

A4, RA5, RA6,

09

143

de los

serán

e a la

uesto

DD1,

, RC0,


144


RC1, RC2, RC4, RC5 de la figura 5.2.34, están conectadas a las terminales RA2, RA3, RA4, RA5, RA6, RC0,

RC1, RC2, RC4, RC5, respectivamente, de la figura 5.2.20.

La función del microcontrolador codificador, es la de verificar los niveles de voltaje que son enviados

desde los detectores y desde el microcontrolador decodificador, de esta manera, el microcontrolador

codificador podrá generar y codificar las palabras de 12 bits, en señales banda base. Al mismo tiempo

que se están generando las señales en banda base, éstas son enviadas al módulo transmisor de RF, que

es el circuito TWS‐BS‐6, cuya función es la de modular y transmitir la señal banda base, a una frecuencia

de 315 MHz, modulada por medio de ASK.

Nota: Cabe recordar, que el microcontrolador decodificador, estará enviando por cada cable (véase

figura 5.2.36), el estado de sus dispositivos controlados (véase sección 5.2.2 “Módulo de control”)

El circuito TWS‐BS‐6, se puede alimentar desde 1.5 V hasta 12 V, proporcionando un mayor alcance, a

mayor voltaje de alimentación.

Como se puede observar, este transmisor, es más simple que el usado en el enlace de control (véase

figura 5.2.6), ya que ahora no se tiene conexión USB, y por lo tanto, tampoco necesitamos de un

oscilador externo, que nos ayudaba a alcanzar los 48 MHz, necesarios para lograr la conexión USB; será

suficiente con usar el oscilador interno, que puede ser configurado desde 32 KHz hasta 8 MHz. Para el

microcontrolador codificador, se utilizará la frecuencia de 8 MHz, así el microcontrolador funcionará de

una manera rápida y además, esto nos permitirá lograr frecuencias más cercanas a las deseadas, pues

para codificar se utilizaran el temporizador 1 y 2.

El funcionamiento de este transmisor, es muy similar al que ya se describió en la sección 5.2.2.4

“Transmisor inalámbrico para el módulo de control”, pero ahora al microcontrolador utilizado en el

módulo de monitoreo, no le llegarán comandos de control, sino que ahora, la información será

producida, a partir de los niveles de voltaje enviados por los dispositivos de monitoreo (detectores), y

por los niveles de voltaje enviados desde el microcontrolador decodificador (del módulo de control).

Como ya se mencionó pueden ser 2 niveles de voltaje distintos: nivel alto (5 V) y nivel bajo (0 V).


145


Estas señales de voltaje, serán inyectadas en las terminales de entrada de información digital del

microcontrolador codificador (véanse figuras 5.2.32 y 5.2.32). Cada terminal está asignada para verificar

el estado de un dispositivo de monitoreo, o para verificar el estado de un dispositivo a controlar, es

decir, para nuestro sistema, se están utilizando 14 entradas digitales, 4 son asignadas para los

dispositivos a monitorear (detectores), y las otras 10, para verificar el estado de los dispositivos

controlados.

Entonces, la conexión de los dispositivos a monitorear que vamos a simular, es la que se muestra en la

figura 5.2.35.

Figura 5.2.35 Diagrama de conexión supuesta, entre dispositivos a monitorear y las terminales DD.

Nota: Por razones económicas, el sistema realizado no cuenta con los detectores mostrados en la figura

5.2.35, en lugar de estos detectores, se colocaron interruptores tipo push button, para así simular la

activación de un detector, cada vez que se presiona el botón.

La conexión para verificar el estado de los dispositivos a controlar, es la que se muestra en la figura

5.2.36.

Sistem

Figura 5

ma de control y

5.2.36 Diagrama de l

monitoreo de di

Cap

a conexión entre el m

ispositivos a trav

pítulo 5: Sistema

microcontrolador de

vés de Internet c

electrónico de co

ecodificador y el mic

con USB 200

omunicaciones

crocontrolador codifi

09

icador, para el monittoreo de dispositivo

146

os.


147


5.2.3.5 Programa del microcontrolador codificador.

El diagrama de flujo del programa del microcontrolador codificador, se muestra en la figura 5.2.37, se

puede observar al final de esta figura, que se tiene un ciclo en el que siempre estará entrando (un bucle

while(TRUE)), por medio de este ciclo, alternadamente (aprox. cada 1.04 s) se estarán realizando, las

acciones 1 y 2, que se muestran a continuación.

1. Verificar el estado de los dispositivos monitoreados (verificar niveles de voltaje en las terminales

correspondientes), guardar la palabra de estado de los dispositivos monitoreados, en la

variable info. Finalmente activar el temporizador 2, para que comience la codificación de la

palabra guardada en info. Por medio de la rutina de servicio del temporizador 2, será realizada

28 veces la codificación de la palabra info, generando señales en banda base, listas para ser

transmitidas por el módulo de RF transmisor.

2. Verificar el estado de los dispositivos a controlar (verificar niveles de voltaje en las terminales

correspondientes), guardar la palabra de estado de los dispositivos a controlar, en la variable

info. Finalmente activar el temporizador 2, para que comience la codificación de la palabra

guardada en info. Por medio de la rutina de servicio del temporizador 2, será realizada 28 veces

la codificación de la palabra info, generando señales en banda base, listas para ser transmitidas

por el módulo de RF transmisor.

De esta manera, cada 1.04 s, primero se codificarán 28 palabras de estado de los dispositivos

monitoreado, y después de 1.04 s, se enviarán 28 palabra de estado de los dispositivos a controlar. El

tiempo de 1.04 segundos, se debe a que cada 1.04 segundos existe permiso de transmitir, este permiso,

es dado por la rutina de servicio del temporizador 1.


148


Figura 5.2.37 Diagrama de flujo del programa del microcontrolador codificador.


La rutina de servicio, será ejecutada cada vez que ocurra un desbordamiento en el temporizador 1, es

decir, el temporizador llevará una cuenta en sus registros de 8 bits TMR1L y TMR1H; TMR1L es la parte

baja y TMR1H es la parte alta, por lo tanto, se puede decir que se tiene un registro de 16 bits para el

temporizador 1. Cuando se haya llegado al número 0xFFh en TMR1L, y 0xFFh en TMR1H, será que los


149


registros vuelvan a iniciar en ceros, y existirá un desbordamiento, por lo tanto, será ejecutada la rutina

de servicio del temporizador 1. Entonces el temporizador 1, estará llevando la cuenta desde 0x0000h

hasta 0xFFFFh, lo que en base decimal es desde 0 hasta 65535.

La cuenta en el registro del temporizador 1 (suponiendo que TMR1L y TMR1H, es un solo registro de 16

bits), se incrementará en uno, cada 1/250KHz = 4µs, ya que así fue configurado el temporizador 1 en el

programa principal del microcontrolador decodificador. Por lo tanto, el tiempo que transcurre desde

que el registro del temporizador se inicia en 0 hasta 65535, es

65536 4 262.144

Nota: Se hace el producto, por el número 65535+1, ya que el desbordamiento sucede cuando el registro

del temporizador 1 se incrementa del número 65535+1, y el registro del temporizador 1, vuelve a ceros.

En la figura 5.2.38, se observa el diagrama de flujo de la rutina de servicio del temporizador 1.

Figura 5.2.38 Diagrama de flujo de la rutina de servicio del temporizador 1.


150



La rutina de servicio del temporizador 2, será la encargada de generar las señales en banda base, que

tienen codificada, a la palabra de 12 bits, que se encuentre guardada en la variable info. Como ya se

mencionó, esta rutina de servicio, codificará 28 palabras iguales, ya sean 28 palabras de estado de los

dispositivos monitoreado ó 28 palabras de estado de los dispositivos a controlar. Mientras la rutina de

servicio, se encuentre en el proceso de codificación, la variable info no va a ser modificada y mantendrá

su valor, para que se haga posible 28 veces, la codificación de la palabra almacenada, en la variable info.

El diagrama de flujo, de la rutina de servicio del temporizador 2, se muestra en la figura 5.2.39.

Realmente, esta rutina de servicio funciona de una manera muy similar a la función CODIFICA, vista en la

sección 5.2.2.6.

Figura 5.2.39 Diagrama de flujo de la rutina de servicio del temporizador 2.


151


Las funciones COD_BIT_UNO, COD_BIT_CERO y T_12BITS, son las mismas, que se ven en la sección

5.2.2.6 “Programa codificador”, en los subtemas “Función COD_BIT_UNO”, ”Función COD_BIT_CERO”,

”Función T_12BITS”.

5.2.3.6 Receptor inalámbrico usado en el módulo de monitoreo.

Como puede observarse en la figura 5.2.40, el receptor inalámbrico está integrado por el módulo de RF,

receptor, y el microcontrolador USB.

El módulo de RF receptor que se utiliza, es el circuito RWS‐374‐3, que se encarga de recibir y demodular

señales de RF, que se encuentren en la frecuencia de 315 MHz y moduladas por medio de ASK; con una

tasa de velocidad de datos de 4.8 Kbps.

Al igual que el en el receptor inalámbrico usado en el módulo de control, el microcontrolador USB

interpretará las señales banda base que el módulo RWS‐374‐3 le inyecta.

Figura 5.2.4

5.2.3.7 P

El proceso

monitoreo

En este ca

cuando, e

ver, en e

5.2.41.

Sistema de

40 Diagrama elé

Proceso de d

o de decodif

o, es el mism

aso, la decod

el microcontr

l diagrama d

e control y m

Capítulo

ctrico del módu

decodificació

ficación que

o que el visto

dificación, la e

olador USB, n

e flujo de la

monitoreo de

o 5: Sistema e

ulo USB, el cual i

ón y program

se lleva a ca

o en la secció

estará realiza

no se encuen

rutina de se

dispositivos

electrónico de

incluye el recept

ma decodifi

bo, en el rec

n 5.2.2.9 “Pro

ando continua

ntre transmiti

ervicio del te

s a través de

e comunicacio

tor inalámbrico

cador

ceptor inalám

oceso de deco

amente el mi

iendo inform

mporizador 2

Internet con

ones

del módulo de

mbrico usado

odificación”.

icrocontrolad

ación; esta c

2, que se mu

n USB 200

monitoreo.

o en el módu

dor USB, siem

ondición se p

uestra en la f

09

152

ulo de

mpre y

puede

figura


153


Figura 5.2.41 Diagrama de flujo de la rutina de servicio del temporizador 2, del microcontrolador USB.

Ahora se va a suponer entonces, que existe una transmisión pendiente, es decir, que tx_pend=0, por lo

tanto será invocada la función DECODIFICA, que es la misma función que se ve en la el subtema “Función

VERIFICA” de la sección 5.2.2.10 “Programa decodificador”. Sin embargo, el proceso de decodificación

comienza desde la rutina de servicio de la interrupción externa 0, del mismo microcontrolador USB; se

sugiere, leer la sección 5.2.2.10 “Programa decodificador”, ya que el proceso de decodificación es muy

similar al que se menciona en esa sección, con la diferencia de que en lugar de poner en alto alguna

terminal del microcontrolador (encender un dispositivo), se enviarán comandos de monitoreo, como se

muestra en las figuras 5.2.32 y 5.2.33.

5.2.4 Diseño de las antenas utilizadas en las comunicaciones inalámbricas

Para lograr la comunicaciones inalámbricas, se estarán utilizando dos frecuencias distintas, una

frecuencia para cada módulo; es decir en el módulo de control, los dispositivos se comunican a 433.92

MHz, y en el módulo de monitoreo los dispositivos se comunican a 315 MHz, por esta razón, en cada

módulo se estarán usando antenas de distinta longitud.


154


Las antenas que serán utilizadas en el sistema, serán antenas tipo monopolo de λ/4, es decir, la antena

será un elemento conductor (alambre de cobre) que tendrá una longitud de λ/4, donde λ es la longitud

de onda de la señal por medio de la que se están comunicando los dispositivos.

Para encontrar la longitud de onda de una señal, se utiliza la ecuación 5‐2, en donde c es la constante de

la velocidad de la luz, que para usos prácticos utilizaremos el valor 3 10 m/s.

/

Ecuación 5‐2. Ecuación para calcular la longitud de onda de una señal.

Cálculo de las antenas utilizadas en el módulo de control

Primeramente se calcula la longitud de onda, para la señal de frecuencia de 433.92 MHz.

/ 3 10433.92 10

0.69137

Por lo tanto la antena tendrá una longitud.

40.69137

40.17284

El monopolo de λ/4 usado en el módulo de control, será de 17.28 cm.

Cálculo de las antenas utilizadas en el módulo de monitoreo

En el módulo de monitoreo, las señales transmitidas y recibidas tienen la frecuencia de 315 MHz, se

calcula la longitud de onda para esta señal.

/ 3 10315 10

0.95238

Por lo tanto la antena tendrá una longitud:


155


40.95238

40.23809

El monopolo de λ/4 usado en el módulo de monitoreo, será de 23.8 cm.


156

Estudio económico

Estudio económico

El presente apartado tiene por objetivo, el determinar el costo total del proyecto desarrollado, para esto, se hace un desglose del material utilizado para la construcción de los circuitos construidos, del material software y el costo de los recursos humanos.

Se seleccionó como referencia un sistema de control, para una casa habitación de tamaño medio. El escenario de tamaño medio es una referencia ideal para el estudio económico.

A continuación se enumeran los componentes electrónicos utilizados, divididos en varios módulos que son los que conforman la parte electrónica del proyecto, para posteriormente presentar su costo unitario y total.

En el módulo USB

> 1 microcontrolador PIC18F2550

> 1 Base para circuito integrado de 28 terminales.

> 1 cristal de cuarzo de 4 MHz

> 1 capacitor de 47 µF

> 1 capacitor de 100 nF

> 2 capacitores de 27 pF

> 1 resistencia de 10 KΩ

> 4 resistencias de 330 Ω

> 5 LEDs

> 1 módulo de RF transmisor TWS‐433

> 1 módulo de RF receptor RWS‐315

Para el control de dispositivos



157

Estudio económico


> 1 capacitor de 0.1 µF



> 2 LEDs

> 3 focos

> 3 optoacopladores MOC3011

> 3 TRIAC 2N6071

> 1 módulo de RF receptor RWS‐433

> Fuente de alimentación de 5 V de corriente directa de

Para el monitoreo de dispositivos



> 1 capacitor de 0.1 µF



> 2 LEDs

> 1 módulo de RF transmisor TWS‐315

> 4 interruptores tipo push‐button.

> Fuente de alimentación de 5 V de corriente directa de


158

Estudio económico

Componentes extra

> 1 cámara IP

> 1 Router inalámbrico 2wire

> Cables de datos de categoría Cat5e

> Placas fenólicas

> Programador GTP USB Lite

En la siguiente tabla se muestran los costos de los componentes, con esto obtendremos el costo total del proyecto en la cuestión electrónica.

Componente Cantidad Costo unitario Costo total

Microcontroladores 3 $100 $300 Base para C.I. de 18 terminales 3 $3 $9.00

Capacitor 6 $4 $24.00 Resistencia 14 $0.5 $7.00

LED 9 $1.5 $13.50 Módulo de RF TWS‐433 1 $95 $95.00 Módulo de RF RWS‐433 1 $95 $95.00 Módulo de RF TWS‐315 1 $95 $95.00 Módulo de RF TWS‐315 1 $95 $95.00

Cable Cat. 5 4 $8.00 p/metro $32.00 Focos 3 $30.00 $90.00

MOC3011 3 $14 $42.00 TRIAC 2N6071 3 $7 $21.00

Interruptor tipo push-button 7 $2 $14.00

Placa fenólica 1 $40 $40.00

Programador GTP USB Lite 1 $450 $450.00

Cámara IP 1 $1800 $1800.00

PC Servidor 1 $3000 $3000.00

TOTAL $6222.50


159

Estudio económico

Ahora se determinarán los costos que tienen que ver con las herramientas software así

como con los recursos humanos.

Licencias

Afortunadamente contamos con un convenio con la empresa Microsoft mediante el cual se nos proporciona de manera gratuita las licencias del software que vamos a utilizar en nuestro proyecto como es el caso de Visual Studio. Por lo anterior el costo por la licencias es nulo y no afectará al cálculo del estudio económico, sin embargo, a continuación se presenta una tabla con los precios de los paquetes de software utilizados.

Herramienta Precio

Visual Studio 2008 Edición Estándar $3931.85

Compilador CCS v. 3.235 $6750.00

WinPic 800 gratuito

TOTAL $10681.85

Los precios anteriores fueron calculados tomando el precio del dólar a $13.50 pesos.

Costos de programación

Según datos investigados, un programador cobra alrededor de $5000.00 mensuales. Considerando que el proyecto se desarrolló en tres meses, entonces, el costo por mano de obra sería de $15000.00. Para la parte del armado y diseño de los circuitos electrónicos, se considera necesario a un técnico en electrónica con un sueldo mensual de $8000.00, entonces, considerando igualmente que el proyecto se desarrolla en tres meses, en total se le pagaría $24000.00. Podemos calcular entonces, que el costo total por concepto de mano de obra sería de: $39000.00


160

Estudio económico

Costo total del proyecto

Para determinar el costo total del proyecto sumamos los costos totales obtenidos anteriormente.

Concepto Costo

Componentes electrónicos $6222.50

Licencias software $10681.85

Mano de obra $39000.00

TOTAL $55904.35


161

Estudio económico

Pruebas y resultados

El servicio de Internet que fue utilizado tanto en el ordenador que funciona como servidor, y en el

ordenador del usuario, es un servicio Internet de banda ancha, que utiliza la tecnología ADSL, cuya

velocidad de conexión entrante es de 2048 Kbps y la velocidad de conexión saliente es de 384 Kbps

(según el proveedor de servicios).

Para lograr la comunicación entre Cliente‐Servidor, a través de Internet, primeramente, se configuró el

ordenador en el que será ejecutada la aplicación Servidor, recordemos que este ordenador se encuentra

conectado a un router, en el cual fue necesario abrir algún puerto que estará “escuchando”, es decir, se

estará esperando una petición de conexión en ese puerto; para que después pueda ser establecida la

conexión. En las pruebas que fueron realizadas, se utilizó el puerto 5050 para la conexión, debido a que

éste puerto no está destinado a un uso en específico. Una vez abierto el puerto 5050, se ejecutó la

aplicación Servidor, y se ingresó el puerto que fue abierto (5050), posteriormente se presionó el botón

“Escuchar”, de esta manera la aplicación Servidor estará esperando una conexión entrante al puerto

5050.

Una vez que se configuró el servidor; en el ordenador del usuario que va a controlar y monitorear los

dispositivos, se ejecutó la aplicación Cliente y se ingresó la dirección IP de Internet, del servidor, así

como también se ingresó el puerto que se abrió en el router del servidor; y para realizar la conexión

entre Cliente‐Servidor, se presionó el botón “Conectar”.

Se comprobó la comunicación entre Cliente y Servidor, pues cuando se dio clic en algún botón de

encendido o apagado de algún dispositivo, un comando de control, era enviado hacia el servidor. Para

visualizar fácilmente que se haya enviado y recibido este comando, las aplicaciones (Cliente y Servidor),

cuentan con una pequeña ventana en la que se pueden ver todos los comandos que se han enviado

(para aplicación Cliente) ó recibido (para aplicación Servidor). Como se mencionó, las aplicaciones

Cliente y Servidor, se comunican gracias al control Winsock, y las primeras pruebas fueron hechas con

una simple comunicación entre aplicaciones, las cuales intercambiaban mensajes de texto, una vez que

esta comunicación se logró, es decir, que se recibieran y enviaran mensajes entre las dos aplicaciones,


162

Estudio económico

se adaptó el código correspondiente para que esos mensajes fuesen las instrucciones de control para los

dispositivos.

En el Servidor, también pudo probarse la comunicación USB, pues cuando se pulsa el botón de

encendido o apagado de algún dispositivo comenzaba la transmisión inalámbrica, y un LED, en el

módulo USB, indica que se está transmitiendo información. Cuando se transmite ésta información de

manera inalámbrica, en el lado del receptor, se puede observar cómo se enciende o apaga, el dispositivo

al que se ordenó hacerlo.

Con la comunicación inalámbrica exitosa, se logró corroborar que los microcontroladores, estaban

funcionando de manera adecuada, por una parte en el transmisor, el microcontrolador es un buen

codificador, y por otra parte, en el receptor, el microcontrolador es un buen decodificador.

El circuito utilizado en la etapa de potencia, funcionó de una manera muy adecuada, pues no hubo

problema alguno para encender o apagar algún dispositivo, por medio del circuito de potencia.

Para poder utilizar la cámara IP, se abrió otro puerto en el router que está del lado del servidor, fue

posible establecer comunicación con la aplicación que hace posible la manipulación de la cámara, para

este propósito, se agregó un botón a la aplicación Cliente cuyo evento se encarga de abrir el explorador

Web con la dirección IP correspondiente a la aplicación de la cámara. Primero, las pruebas con la cámara

fueron hechas en una red local, logrando establecer comunicación de manera fácil, una vez que

entendimos el funcionamiento de la aplicación de la cámara, haciendo pruebas localmente, se procedió

a probar la conexión a través de Internet.


163

Visión futura

Conclusiones

Se logró diseñar, desarrollar e implementar, un sistema de control a distancia que cumple con el objetivo de facilitar la manipulación de dispositivos sin tener que estar frente a los mismos y que hace uso de los beneficios que la tecnología ofrece actualmente como los son el Internet y la velocidad de transmisión de datos a dispositivos mediante la interfaz USB.

El proyecto desarrollado en este trabajo puede tener diversas aplicaciones para el hogar, podría ser adaptado para: activar electrodomésticos, activar bombas de agua, controlar seguros de puertas, controlar y verificar la temperatura, realizar vigilancia, monitorear el funcionamiento de dispositivos, verificar las condiciones de algunos dispositivos y diversas aplicaciones más que requieran el control y monitoreo a distancia. El proyecto, se enfoca a satisfacer la necesidad que tienen las personas de contar con dispositivos que le faciliten la vida.

Se cumplió con el objetivo general propuesto al inicio del presente trabajo, el cual era: “Implementar un sistema de control de dispositivos a través de Internet, usando la interfaz USB”, la parte de control a distancia a través de Internet, fue resuelta con el desarrollo de nuestras aplicaciones Cliente y Servidor y para el control de los dispositivos a través de la interfaz USB, se utilizó un microcontrolador que posee la característica precisamente de trasmitir datos a través de esta interfaz. En conjunto, nuestro sistema, es capaz de controlar un dispositivo a distancia, pues se consiguió transmitir información de control tanto dentro de una red local como a través de Internet.

Las pruebas que se llevaron a cabo durante el desarrollo del sistema, nos permitieron ir mejorando el diseño del mismo. En un principio, por ejemplo, se tenía pensado utilizar la interfaz paralela de la computadora para enviar información al microcontrolador o recibir información de él, sin embargo, actualmente son pocos los equipos que cuentan con este puerto, al grado de haberse vuelto casi obsoleto, por esta razón, se decidió utilizar la interfaz USB, pues ésta ha evolucionado bastante y cualquier equipo cuenta con una o varias de estas interfaces, aunque su implementación es más compleja, debido a que se requiere de un driver para el dispositivo que es conectado y las rutinas para transmitir y recibir información son más elaboradas, el fabricante del microcontrolador utilizado en este proyecto proporciona el controlador correspondiente y es necesario el uso de una biblioteca para trasmitir y recibir información a través de USB, agregada a la aplicación Servidor. Debido a que nos enfocamos más al diseño del sistema tanto de hardware como de software, no se tuvo el tiempo ya para personalizar el controlador, esto es, la edición del driver suministrado por Microchip de tal forma que apareciera en el Administrador de Dispositivos una nueva clase con un icono personalizado. Para esto era necesario crear una DLL que exportara ese icono y después compilarla con ayuda de la DDK (Development Driver Kit) de Microsoft.


164

Visión futura

El sistema tiene la capacidad de informar el estado de los dispositivos controlados mediante el chequeo del nivel de voltaje en las terminales del microcontrolador encargado de manipularlos, esto no asegura que el dispositivo se encuentra realmente encendido ya que éste puede presentar alguna falla sin que el sistema lo detecte, por ejemplo, un foco, podría estar fundido pero el sistema detectaría que la terminal del microcontrolador correspondiente al control de ese foco está activa y mostraría un estado de funcionamiento adecuado.

Para simular el monitoreo de dispositivos, fueron utilizados interruptores, pero al sistema se le pueden conectar detectores de presencia, de humo, de gas, etc.

Para la comunicación de nuestras aplicaciones a través de la red, se utilizó el control Winsock, esto nos ahorró mucho código y tiempo de programación, ya que la otra forma de hacerlo era con sockets. La implementación en el proyecto de este control, se facilitó debido a la gran cantidad de información que hay en Internet, la comunicación entre nuestras aplicaciones, tiene sus bases en uno de los ejemplos más comunes que se pueden encontrar sobre la utilización del Winsock, se trata de dos aplicaciones que intercambian mensajes de texto (chat), fue gracias a este ejemplo que se pudo estudiar el proceso de intercambio de información entre dos aplicaciones, y una vez que se logró implementar este ejemplo en una red local, se le adaptaron instrucciones al código, que permitieran enviar y recibir las instrucciones de control para los dispositivos.

Visión futura

Son muchas las aplicaciones que se le pueden dar a nuestro sistema, así como las mejoras que se le pueden hacer, a continuación se enuncian algunas propuestas, que creemos son importantes para implementaciones futuras:

1. Nuestra aplicación Servidor sólo atiende a un Cliente a la vez, se podría desarrollar un Servidor que sea capaz de atender a varios Clientes a la vez, mediante la implementación de subprocesamiento múltiple. Así, un dispositivo que posea varios módulos de funcionamiento, podría ser controlado por diferentes usuarios, localizados en distintos lugares.

2. Podría ser agregado a las aplicaciones Cliente y Servidor, un módulo de mensajes instantáneos, esto con el objetivo de permitir, que operadores en diferentes lugares puedan comunicarse, por ejemplo, para dar un informe del estado de algún dispositivo.

3. La parte de monitoreo de los dispositivos con la cámara IP, no se desarrolló del todo en el proyecto, por lo que se propone un sistema que trabaje con una base de datos, en la que se


165

Visión futura

vayan almacenando los eventos que van sucediendo, la fecha en que ocurren, el identificador del video correspondiente y una descripción de lo sucedido.

4. En el proyecto fueron utilizados tres microcontroladores para la comunicación inalámbrica, un microcontrolador (conectado al Servidor) ayuda a la transmisión y recepción, otro (colocado en el módulo de control) ayuda únicamente a la recepción y un tercero ayuda a transmitir las palabras de monitoreo. Sin embargo, es posible reducir el número de microcontroladores utilizados a sólo dos, uno conectado en el Servidor que ayude a la transmisión y recepción y otro para transmitir y recibir información de monitoreo y control.


166

Conclusiones


167

Apéndice A

Apéndice A. Librería para USB: MPUSBAPI.DLL

Para una mayor facilidad de desarrollo de aplicaciones basadas en el bus USB, Microchip ha creado un archivo dll en el que proporciona las funciones de acceso al puerto USB con un microcontrolador de la familia PIC18Fxx5x.

Para un funcionamiento correcto, se necesita el driver mchpusb.sys.

FUNCIONES

1.1. MPUSBGETDLLVERSION(VOID)

Lee el nivel de revisión del MPUSAPI.dll. Es un nivel de revisión de 32bits. Esta función no devuelve la versión del código, no realiza nada con el USB. Devuelve la versión de la dll en formato hexadecimal de 32bits.

MPUSBGetDLLVersion()

1.2. MPUSBGETDEVICECOUNT(PVID_PID)

Devuelve el número de dispositivo con VID_PID asignado.

pVID_PID: Input: cadena de caracteres del número de identificación asignado.

MPUSBGetDeviceCount(vid_pid) Documento creado por Slalen para Electronics Strange World

1.3. MPUSBOPEN(INSTANCE, PVID_PID, PEP, DWDIR, DWRESERVED)

Devuelve el acceso al pipe del Endpoint con el VID_PID asignado.

Todas las pipes se abren con el atributo FILE_FLAG_OVERLAPPED. Esto permite que MPUSBRead, MPUSBWrite y MPUSBReadInt tengan un valor de time‐out.

Nota: el valor del time‐out no tiene sentido en una pipe síncrona.

instance: Input: Un número de dispositivo para abrir. Normalmente, se utiliza primero la llamada de MPUSBGetDeviceCount para saber cuantos dispositivos hay.


168

Apéndice A

Es importante entender que el driver lo comparten distintos dispositivos. El número devuelto por el MPUSBGetDeviceCount tiene que ser igual o menor que el número de todos los dispositivos actualmente conectados y usando el driver genérico.

Ejemplo:

Si hay tres dispositivos con los siguientes PID_VID conectados:

Dispositivo tipo 0, VID 0x04d8, PID 0x0001



Si el dispositivo que nos interesa tiene VID=0x04d8 y PID=0x0002 el MPUSBGetDeviceCount devolverá un ‘1’.

Al llamar la función tiene que haber un mecanismo que intente llamar MPUSOpen() desde 0 hasta MAX_NUM_MPUSB_DEV. Se tiene que contar el número de llamadas exitosas. Cuando este número sea igual al número devuelto por MPUSBGetDeviceCount, hay que dejar de hacer las llamadas porque no puede haber más dispositivos con el mismo VID_PID.

pVID_PID: Input: String que contiene el PID&VID del dispositivo objetivo. El formato es “vid_xxxx&pid_yyyy”. Donde xxxx es el valor del VID y el yyyy el del PID, los dos en hexadecimal.

Ejemplo:

Si un dispositivo tiene un VID=0x04d8 y un PID=0x000b, el string de entrada es: “vid_0x04d8&pid_0x000b”.

pEP: Input: String con el número del Endpoint que se va a abrir. El formato es “\\MCHP_EPz” o “\MCHP_EPz” dependiendo del lenguaje de programación. Donde z es el número del Endpoint en decimal.

Ejemplo:

“\\MCHP_EP1” o “\MCHP_EP1”


169

Apéndice A

Este argumento puede ser NULL (nulo) para crear lazos con Endpoints de funciones no específicas. Las funciones específicas son: MPUSBRead, MPUSBWrite, MPUSBReadInt.

1.4. MPUSBREAD(HANDLE, PDATA, DWLEN, PLENGTH, DWMILLISECONDS)

handle: Input: Identifica la pipe del Endpoint que se va a leer. La pipe unida tiene que crearse con el atributo de acceso MP_READ.

pData: Output: Puntero al buffer que recibe el dato leído de la pipe.

dwLen: Input: Especifica el número de bytes que hay que leer de la pipe.

pLenght: Output: Puntero al número de bytes leídos. MPUSBRead pone este valor a cero antes de cualquier lectura o de chequear un error.

dwMilliseconds: Input: Especifica el intervalo de time‐out en milisegundos. La función vuelve si transcurre el intervalo aunque no se complete la operación. Si dwMilliseconds=0, la función comprueba los datos de la pipe y vuelve inmediatamente. Si dwMilliseconds es infinito, el intervalo de time‐out nunca termina.

MPUSBRead(myInPipe, VarPtr(s(0)), DatosDeseados, Datos, 1000)

1.5. MPUSBWRITE(HANDLE, PDATA, DWLEN, PLENGTH, DWMILLISECONDS)

handle: Input: Identifica la pipe del Endpoint que se va a escribir. La pipe unida tiene que crearse con el atributo de acceso MP_WRITE.

pData: Output: Puntero al buffer que contiene los datos que se van a escribir en la pipe.

dwLen: Input: Especifica el número de bytes que se van a escribir en la pipe.

pLenght: Output: Puntero al número de bytes que se escriben al llamar esta función. MPUSBWrite pone este valor a cero antes de cualquier lectura o de chequear un error.



170

Apéndice A

MPUSBWrite(myOutPipe, VarPtr(SendData(0)), bytes, VarPtr(bytes), 1000)

1.5.MPUSBREADINT(HANDLE, PDATA, DWLEN, PLENGTH, DWMILLISECONDS)

handle: Input: Identifica la pipe del Endpoint que se va a leer. La pipe unida tiene que crearse con el atributo de acceso MP_READ.

pData: Output: Puntero al buffer que recibe el dato leído de la pipe.

dwLen: Input: Especifica el número de bytes que hay que leer de la pipe.

pLenght: Output: Puntero al número de bytes leídos. MPUSBRead pone este valor a cero antes de cualquier lectura o de chequear un error.


MPUSBReadInt(myOutPipe, VarPtr(SendData(0)), bytes, VarPtr(bytes), 1000)

1.6. MPUSBCLOSE(HANDLE)

Cierra una determinada unión.

handle: Input: Identifica la pipe del Endpoint que se va a cerrar.

MPUSBClose (myOutPipe)

Interrupt: tipo interrupción

Isochronous: tipo síncrono

Nota: “Input” y “output” se refiere a los parámetros designados en las llamadas a estas funciones, que son lo opuesto a los sentidos comunes desde la perspectiva de una aplicación haciendo llamadas.

1.7. DECLARACIÓN DE LAS FUNCIONES

En el último punto de la librería, se comenta como incluir las funiones en varios lenguajes de programación.


171

Apéndice A

1.7.1. C#

Se declara con #include "_mpusbapi.h". Los datos devueltos son:

DWORD _MPUSBGetDLLVersion(void)

DWORD _MPUSBGetDeviceCount(PCHAR pVID_PID)

HANDLE _MPUSBOpen(DWORD instance, PCHAR pVID_PID, PCHAR pEP, DWORD dwDir, DWORD dwReserved);

BOOLEAN _MPUSBClose(HANDLE handle);

DWORD _MPUSBRead(HANDLE handle, PVOID pData, DWORD dwLen, PDWORD pLength, DWORD dwMilliseconds);

DWORD _MPUSBWrite(HANDLE handle, PVOID pData, DWORD dwLen, PDWORD pLength, DWORD dwMilliseconds);

DWORD _MPUSBReadInt(HANDLE handle, PVOID pData, DWORD dwLen, PDWORD pLength, DWORD dwMilliseconds);


172

Apéndice B. Códigos, aplicaciones Cliente y Servidor


En este apéndice se presentan los códigos de las aplicaciones Cliente y Servidor, las cuales fueron programadas utilizando el lenguaje C#. El código tiene comentarios para una mejor comprensión de las funciones que hay en el mismo.

Aplicación Cliente

using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; namespace AplicacionCliente public partial class AplicacionCliente : Form bool isConnected = false; static int conteo=0; static int conteo2 = 0; static int alarma = 0; public AplicacionCliente() InitializeComponent(); this.axWinsock1.Error += new AxMSWinsockLib.DMSWinsockControlEvents_ErrorEventHandler(this.axWinsock1_Error); this.axWinsock1.ConnectEvent += new System.EventHandler(this.axWinsock1_ConnectEvent_1); this.axWinsock1.DataArrival += new AxMSWinsockLib.DMSWinsockControlEvents_DataArrivalEventHandler(this.axWinsock1_DataArrival);


173


public void btnConectar_Click(object sender, EventArgs e) if (isConnected == false) //Con try catch, controlamos los errores try //Se cierra el control si está abierto axWinsock1.Close(); //Se llama al método Connect axWinsock1.Connect(txtIP.Text, txtPuerto.Text); //Establece la variable isConnected a true isConnected = true; lblEstado.Visible = true; lblEstado.Text = "Conectado por el puerto:" + txtPuerto.Text; lblEstado.ForeColor = Color.White; imgDesconec.Visible = false; imgConectado.Visible = true; txtMensajes.ForeColor = Color.Green; txtMensajes.Text = "Estas conectado"; btnConectar.Enabled = false; btnDesconec.Enabled = true; //Se muestran las Excepciónes ocurridas catch (System.Windows.Forms.AxHost.InvalidActiveXStateException g) ListBoxLog.Items.Add(g.ToString()); imgDesconec.Visible = true; imgConectado.Visible = false; txtMensajes.ForeColor = Color.Red; txtMensajes.Text = "Desconectado"; btnConectar.Enabled = true; btnDesconec.Enabled = false; isConnected = false; catch (Exception exce) ListBoxLog.Items.Add(exce.Message); imgDesconec.Visible = true; imgConectado.Visible = false; txtMensajes.ForeColor = Color.Red; txtMensajes.Text = "Desconectado"; btnConectar.Enabled = true; btnDesconec.Enabled = false; isConnected = false; private void btnDesconec_Click(object sender, EventArgs e)


174


try this.ListBoxLog.Items.Add("Desconectado..."); lblEstado.Visible = true; lblEstado.ForeColor = Color.WhiteSmoke; lblEstado.Text = "Desconectado"; imgDesconec.Visible = true; imgConectado.Visible = false; txtMensajes.ForeColor = Color.Red; txtMensajes.Text = "Desconectado"; btnConectar.Enabled = true; btnDesconec.Enabled = false; isConnected = false; axWinsock1.Close(); catch MessageBox.Show("Ocurrió un error,el puerto no esta abierto", "ERROR", MessageBoxButtons.OK, MessageBoxIcon.Error); //******************Funcion para enviar dato************************** public void Envio_Dato(int dato) try //si esta conectado puede enviar información if (isConnected) //esto se envía la información que tenga //textbox txtMsg hacia el servidor axWinsock1.SendData(dato); //con esto visualizamos en pantalla //el mensaje que se acaba de enviar ListBoxLog.Items.Add("Cliente- " + axWinsock1.LocalIP + ": " + dato); else MessageBox.Show("No se esta conectado con el servidor"); catch (AxMSWinsockLib.AxWinsock.InvalidActiveXStateException g) ListBoxLog.Items.Add(g.ToString()); catch (Exception ex) ListBoxLog.Items.Add(ex.Message);


175


void axWinsock1_Error(object sender, AxMSWinsockLib.DMSWinsockControlEvents_ErrorEvent e) ListBoxLog.Items.Add("Error : " + e.description); isConnected = false; imgDesconec.Visible = true; imgConectado.Visible = false; txtMensajes.ForeColor = Color.Red; txtMensajes.Text = "Desconectado"; btnConectar.Enabled = true; btnDesconec.Enabled = false; isConnected = false; //Evento DataArrival del control Winsock public void axWinsock1_DataArrival(object sender, AxMSWinsockLib.DMSWinsockControlEvents_DataArrivalEvent e) //creamos una variable para obtener //los datos que llegaron int data = 0; //creamos otra variable tipo object //porque el método que se utiliza para //recibir datos es object object dat = (object)data; //obtenemos la información que envió //el servidor en forma de object axWinsock1.GetData(ref dat); //hacemos un cast a esa variable //y la guardamos en la variable data data = (int)dat; Estados(data); //Método para conocer cuál alarma fue activada private void Estados(int alarma) ListBoxLog.Items.Add("Servidor - " + axWinsock1.RemoteHostIP + ": " + alarma); if (alarma == 14) MessageBox.Show("ALARMA ACTIVADA¡¡¡", "Alarma", MessageBoxButtons.OK, MessageBoxIcon.Warning); timerAlarmas.Enabled = true; if (alarma == 31) MessageBox.Show("ALARMA 1 ACTIVADA¡¡¡", "Alarma", MessageBoxButtons.OK, MessageBoxIcon.Warning);


176


if (alarma == 32) MessageBox.Show("ALARMA 2 ACTIVADA¡¡¡", "Alarma", MessageBoxButtons.OK, MessageBoxIcon.Warning); if (alarma == 33) MessageBox.Show("ALARMA 3 ACTIVADA¡¡¡", "Alarma", MessageBoxButtons.OK, MessageBoxIcon.Warning); //********Estado de los dispositivos (Encendidos)************ if (alarma == 61) btnRecamara1ON.Visible = true; btnRecamara1OFF.Visible = false; lblRec1.Text = "Recamara 1: Encendido"; if (alarma == 62) btnRecamara2ON.Visible = true; btnRecamara2OFF.Visible = false; lblRec2.Text = "Recamara 2: Encendiddo"; if (alarma == 63) btnRecamara3ON.Visible = true; btnRecamara3OFF.Visible = false; lblRec3.Text = "Recamara 3: Encendido"; if (alarma == 64) btnSalaOff.Visible = false; btnSalaOn.Visible = true; lblSala.Text = "Sala: Encendido"; if (alarma == 65) btnPasilloOn.Visible = true; btnPasilloOff.Visible = false; lblPasillo.Text = "Pasillo: Encendido"; if (alarma == 66) btnCocinaOn.Visible = true; btnCocinaOff.Visible = false; lblCocina.Text = "Cocina: Encendido"; if (alarma == 67)


177


btnExteriorOn.Visible = true; btnExteriorOff.Visible = false; lblComedor.Text = "Comedor: Encendido"; if (alarma == 68) btnCerraduraOn.Visible = true; btnCerraduraOff.Visible = false; label11.Text = "Cerradura: Abierta"; if (alarma == 69) btnBombaAgua.Text = "Apagar"; lblBomba2.Text = "Bomba: Encendida"; if (alarma == 70) btnBoiler.Text = "Apagar"; lblBoiler2.Text = "Boiler: Encendido"; //********Estado de los dispositivos (Apagados)***************** if (alarma == 41) btnRecamara1ON.Visible = false; btnRecamara1OFF.Visible = true; lblRec1.Text = "Recamara 1: Apagado"; if (alarma == 42) btnRecamara2ON.Visible = false; btnRecamara2OFF.Visible = true; lblRec2.Text = "Recamara 2: Apagado"; if (alarma == 43) btnRecamara3ON.Visible = false; btnRecamara3OFF.Visible = true; lblRec3.Text = "Recamara 3: Apagado"; if (alarma == 44) btnSalaOff.Visible = true; btnSalaOn.Visible = false; lblSala.Text = "Sala: Apagado"; if (alarma == 45) btnPasilloOn.Visible = false; btnPasilloOff.Visible = true; lblPasillo.Text = "Pasillo: Apagado";


178


if (alarma == 46) btnCocinaOn.Visible = false; btnCocinaOff.Visible = true; lblCocina.Text = "Cocina: Apagado"; if (alarma == 47) btnExteriorOn.Visible = false; btnExteriorOff.Visible = true; lblComedor.Text = "Comedor: Apagado"; if (alarma == 48) btnCerraduraOn.Visible = false; btnCerraduraOff.Visible = true; label11.Text = "Cerradura: Cerrada"; if (alarma == 49) btnBombaAgua.Text = "Encender"; lblBomba2.Text = "Bomba: Apagada"; if (alarma == 50) btnBoiler.Text = "Encender"; lblBoiler2.Text = "Boiler: Apagado"; public void axWinsock1_ConnectEvent_1(object sender, EventArgs e) ListBoxLog.Items.Add("Conectado con el servidor en: " + axWinsock1.RemoteHostIP); isConnected = true; //Eventos de los botones en la interfaz gráfica private void Recamara1OFF_Click(object sender, EventArgs e) Envio_Dato(101); btnRecamara1ON.Visible = true; btnRecamara1OFF.Visible = false; private void Recamara1ON_Click(object sender, EventArgs e) Envio_Dato(01);


179


btnRecamara1OFF.Visible = true; btnRecamara1ON.Visible = false; private void Recamara2ON_Click(object sender, EventArgs e) Envio_Dato(02); btnRecamara2ON.Visible = false; btnRecamara2OFF.Visible = true; private void Recamara2OFF_Click(object sender, EventArgs e) Envio_Dato(102); btnRecamara2OFF.Visible = false; btnRecamara2ON.Visible = true; private void CocinaOff_Click(object sender, EventArgs e) Envio_Dato(106); btnCocinaOff.Visible = false; btnCocinaOn.Visible = true; private void CocinaOn_Click(object sender, EventArgs e) Envio_Dato(06); btnCocinaOn.Visible = false; btnCocinaOff.Visible = true; private void PasilloOff_Click(object sender, EventArgs e) Envio_Dato(105); btnPasilloOff.Visible = false; btnPasilloOn.Visible = true; private void PasilloOn_Click(object sender, EventArgs e) Envio_Dato(05); btnPasilloOn.Visible = false; btnPasilloOff.Visible = true; private void SalaOff_Click(object sender, EventArgs e) Envio_Dato(104); btnSalaOff.Visible = false; btnSalaOn.Visible = true;


180


private void SalaOn_Click(object sender, EventArgs e) Envio_Dato(04); btnSalaOn.Visible = false; btnSalaOff.Visible = true; private void Recamara3ON_Click(object sender, EventArgs e) Envio_Dato(03); btnRecamara3ON.Visible = false; btnRecamara3OFF.Visible = true; private void Recamara3OFF_Click(object sender, EventArgs e) Envio_Dato(103); btnRecamara3OFF.Visible = false; btnRecamara3ON.Visible = true; private void ExteriorOff_Click(object sender, EventArgs e) Envio_Dato(107); btnExteriorOff.Visible = false; btnExteriorOn.Visible = true; private void ExteriorOn_Click(object sender, EventArgs e) Envio_Dato(07); btnExteriorOn.Visible = false; btnExteriorOff.Visible = true; private void Hora_Tick(object sender, EventArgs e) txtHora.Text = DateTime.Now.ToString("hh:mm:ss"); if (Hora1.Text == txtHora.Text) Retardos.Enabled = true; if (Hora2.Text == txtHora.Text) Retardos2.Enabled = true;


181


private void Encendido_General_Click(object sender, EventArgs e) Retardos3.Enabled = false; Retardos2.Enabled = false; Retardos.Enabled = true; private void Apagado_General_Click(object sender, EventArgs e) Retardos3.Enabled = false; Retardos.Enabled = false; Retardos2.Enabled = true; //Eventos de los controles Timer para generar retardos private void Retardos_Tick(object sender, EventArgs e) Retardos2.Enabled = false; Retardos3.Enabled = false; conteo = 1 + conteo; label4.Text = conteo.ToString(); if (conteo == 1) btnSalaOff.Visible = false; btnSalaOn.Visible = true; Envio_Dato(04); if (conteo == 2) btnExteriorOn.Visible = true; btnExteriorOff.Visible = false; Envio_Dato(07); if (conteo == 3) btnRecamara3ON.Visible = true; btnRecamara3OFF.Visible = false; Envio_Dato(03); if (conteo == 4) btnRecamara1ON.Visible = true; btnRecamara1OFF.Visible = false; Envio_Dato(01); if (conteo == 5) btnRecamara2ON.Visible = true; btnRecamara2OFF.Visible = false; Envio_Dato(02); if (conteo == 6) btnCocinaOn.Visible = true; btnCocinaOff.Visible = false; Envio_Dato(06); if (conteo == 7) btnPasilloOn.Visible = true; btnPasilloOff.Visible = false; Envio_Dato(05); if (conteo == 8) Retardos.Enabled = false; conteo = 0; private void Retardos2_Tick(object sender, EventArgs e) Retardos3.Enabled = false; Retardos.Enabled = false; conteo2 = conteo2 + 1; label4.Text = conteo2.ToString(); if (conteo2 == 1) btnSalaOff.Visible = true; btnSalaOn.Visible = false; Envio_Dato(104); if (conteo2 == 2) btnExteriorOn.Visible = false; btnExteriorOff.Visible = true; Envio_Dato(107); if (conteo2 == 3) btnRecamara3ON.Visible = false; btnRecamara3OFF.Visible = true; Envio_Dato(103); if (conteo2 == 4) btnRecamara1ON.Visible = false; btnRecamara1OFF.Visible = true; Envio_Dato(101);


182


if (conteo2 == 5) btnRecamara2ON.Visible = false; btnRecamara2OFF.Visible = true; Envio_Dato(102); if (conteo2 == 6) btnCocinaOn.Visible = false; btnCocinaOff.Visible = true; Envio_Dato(106); if (conteo2 == 7) btnPasilloOn.Visible = false; btnPasilloOff.Visible = true; Envio_Dato(105); if (conteo2 == 8) Retardos2.Enabled = false; conteo2 = 0; private void Retardos3_Tick(object sender, EventArgs e) conteo = conteo + 1; if (conteo == 1) btnSalaOn.Visible = true; btnSalaOff.Visible = false; Envio_Dato(04); if (conteo == 2) btnPasilloOn.Visible = true; btnPasilloOff.Visible = false; Envio_Dato(05); if (conteo == 3) btnCocinaOn.Visible = true; btnCocinaOff.Visible = false; Envio_Dato(06); if (conteo == 4) btnRecamara2ON.Visible = true; btnRecamara2OFF.Visible = false; Envio_Dato(02); if (conteo == 5) btnRecamara3ON.Visible = true; btnRecamara3OFF.Visible = false; Envio_Dato(03); if (conteo == 6) btnCocinaOn.Visible = false; btnCocinaOff.Visible = true; Envio_Dato(106); if (conteo == 7) btnSalaOn.Visible = false; btnSalaOff.Visible = true; Envio_Dato(104); if (conteo == 8) btnRecamara3ON.Visible = false; btnRecamara3OFF.Visible = true; Envio_Dato(103); if (conteo == 9) btnPasilloOn.Visible = false; btnPasilloOff.Visible = true; Envio_Dato(105); if (conteo == 10) btnRecamara2ON.Visible = false; btnRecamara2OFF.Visible = true; Envio_Dato(102); if (conteo == 11) conteo = 0; //Evento para el botón Simular Presencia private void Simulacion_Presencia_Click(object sender, EventArgs e) if (btnSimulacion_Presencia.Text == "Parar") btnSimulacion_Presencia.Text = "Simular Presencia"; Retardos3.Enabled = false; conteo = 0;


183


else btnSimulacion_Presencia.Text = "Parar"; Retardos.Enabled = false; Retardos2.Enabled = false; Retardos3.Enabled = true; conteo = 0; private void CamaraIP_Click(object sender, EventArgs e) System.Diagnostics.Process.Start("http://www.google.com/"); private void Camara_Click(object sender, EventArgs e) System.Diagnostics.Process.Start("http://www.google.com/"); private void BombaAgua_Click(object sender, EventArgs e) if (btnBombaAgua.Text == "Encender") Envio_Dato(09); btnBombaAgua.Text = "Apagar"; else Envio_Dato(109); btnBombaAgua.Text = "Encender"; private void Boiler_Click(object sender, EventArgs e) if (btnBoiler.Text == "Encender") Envio_Dato(10); btnBombaAgua.Text = "Apagar"; else Envio_Dato(110); btnBoiler.Text = "Encender"; private void CerraduraOff_Click(object sender, EventArgs e) Envio_Dato(108); btnCerraduraOn.Visible = true;


184


btnCerraduraOff.Visible = false; private void CerraduraOn_Click(object sender, EventArgs e) Envio_Dato(08); btnCerraduraOn.Visible = false; btnCerraduraOff.Visible = true; private void Reestablecer_Click(object sender, EventArgs e) Envio_Dato(100); private void BorrarMsg_Click(object sender, EventArgs e) ListBoxLog.Items.Clear(); private void VerVideos_Click(object sender, EventArgs e) ReproductorVideo ver = new ReproductorVideo(); ver.Show(); private void timerAlarmas_Tick(object sender, EventArgs e) if (alarma == 0) imgAlerta1.Visible = true; imgAlerta2.Visible=false; alarma=alarma+1; else imgAlerta2.Visible = true; imgAlerta1.Visible = false; alarma = 0; private void Paro_Alarma_Click(object sender, EventArgs e) alarma = 0; timerAlarmas.Enabled = false; imgAlerta2.Visible = false; imgAlerta1.Visible = false;


185


Aplicación Servidor

using System; using System.Collections.Generic; using System.ComponentModel; using System.Data; using System.Drawing; using System.Linq; using System.Text; using System.Windows.Forms; using System.Threading; namespace Servidor public partial class Servidor : Form PicUSBAPI usbapi = new PicUSBAPI(); bool isConnected = false; public Servidor() InitializeComponent(); lblHost.Text = axWinsock1.LocalHostName; lblIPlocal.Text = axWinsock1.LocalIP; this.axWinsock1.ConnectionRequest += new AxMSWinsockLib.DMSWinsockControlEvents_ConnectionRequestEventHandler(this.axWinsock1_ConnectionRequest); this.axWinsock1.DataArrival += new AxMSWinsockLib.DMSWinsockControlEvents_DataArrivalEventHandler(this.axWinsock1_DataArrival); //ConnectionRequest:cuando se hace una petición de conexión de parte de un cliente private void axWinsock1_ConnectionRequest(object sender, AxMSWinsockLib.DMSWinsockControlEvents_ConnectionRequestEvent e) if (isConnected == true) axWinsock1.Close(); //este comando acepta la conexión con el cliente axWinsock1.Accept(e.requestID); isConnected = true; ListBoxLog.Items.Add("Cliente Conectado: " + axWinsock1.RemoteHostIP);


186


private void axWinsock1_DataArrival(object sender, AxMSWinsockLib.DMSWinsockControlEvents_DataArrivalEvent e) //creamos una variable para obtener los //datos que llegaron int data = 0; //creamos otra variable tipo object ya que //el método que se utiliza para recibir //datos es tipo object object dat = (object)data; axWinsock1.GetData(ref dat); data = (int)dat; //Enviamos el dato recibido al microcontrolador usbapi.Controles(data); //mostraos la información ListBoxLog.Items.Add("Cliente : " + data + " Hora: " + lblHora.Text); void axWinsock1_Error(object sender, AxMSWinsockLib.DMSWinsockControlEvents_ErrorEvent e) ListBoxLog.Items.Add("Error : " + e.description); private void btnEscuchar_Click_1(object sender, EventArgs e) try int x = 0; if (txtPuerto.Text != "" && int.TryParse(txtPuerto.Text, out x)) //Se establece el puerto por el cuál se escucha axWinsock1.LocalPort = Int32.Parse(txtPuerto.Text); isConnected = true; //Método Listen del control Winsock axWinsock1.Listen(); lblEstado.ForeColor = Color.Green; lblEstado.Text = "Escuchando, puerto:" + txtPuerto.Text; imgConectado.Show(); imgDesconect.Hide(); ListBoxLog.Items.Add("Escuchando por el puerto: " + txtPuerto.Text); btnDesconectar.Enabled = true; btnEscuchar.Enabled = false; else


187


MessageBox.Show("Debe asignar un puerto para escuchar", "ERROR", MessageBoxButtons.OK, MessageBoxIcon.Information); catch MessageBox.Show("Ocurrió un error, lo mas probable es que el puerto seleccionado no este disponible"); //El siguiente método permite al Servidor conectarse automáticamente a un puerto específico al ejecutarse. private void Conectar() int puerto = 5061; try axWinsock1.LocalPort = puerto; isConnected = true; axWinsock1.Listen(); lblEstado.ForeColor = Color.Green; lblEstado.Text = "Escuchando, puerto:" + puerto; imgConectado.Show(); imgDesconect.Hide(); ListBoxLog.Items.Add("Escuchando por el puerto: " + puerto); btnDesconectar.Enabled = true; btnEscuchar.Enabled = false; catch MessageBox.Show("Ocurrió un error, lo mas probable es que el puerto seleccionado no este disponible"); private void buttonDesconectar_Click_1(object sender, EventArgs e) try //cierra la conexión con el cliente axWinsock1.Close(); this.ListBoxLog.Items.Add("Desconectado........."); btnEscuchar.Enabled = true; btnDesconectar.Enabled = false; lblEstado.Text = "Sin Escuchar ningún puerto"; lblEstado.ForeColor = Color.Red; imgDesconect.Show(); imgConectado.Hide();


188


catch MessageBox.Show("Ocurrió un error, el puerto no esta abierto", "ERROR", MessageBoxButtons.OK, MessageBoxIcon.Error); //****************Funcion para enviar dato************************** public void Envio_Dato(int dato) try //si esta conectado puede enviar información if (isConnected) //esto se envía la información que tenga //textbox txtMsg hacia el Cliente axWinsock1.SendData(dato); catch (AxMSWinsockLib.AxWinsock.InvalidActiveXStateException g) ListBoxLog.Items.Add(g.ToString()); catch (Exception ex) ListBoxLog.Items.Add(ex.Message); private void hora_Tick(object sender, EventArgs e) int val = 0; lblHora.Text = DateTime.Now.ToString("hh:mm:ss"); PicUSBAPI ir = new PicUSBAPI(); val = ir.DetectorAlarma(); Envio_Dato(val); if (val == 31) Envio_Dato(31); private void btnEnviar_Click(object sender, EventArgs e) Envio_Dato(14); private void Servidor_Load(object sender, EventArgs e) Conectar();


189


PicUSBAPI using System; using System.Collections.Generic; using System.Windows.Forms; using System.Runtime.InteropServices; // Clase para importar DLL using System.Threading; using PVOID = System.IntPtr; using DWORD = System.UInt32; namespace Servidor unsafe public class PicUSBAPI #region Definición de los Strings: EndPoint y VID_PID string vid_pid_norm = "vid_04d8&pid_0011"; string out_pipe = "\\MCHP_EP1"; string in_pipe = "\\MCHP_EP1"; #endregion #region Funciones importadas de la DLL: mpusbapi.dll [DllImport("mpusbapi.dll")] private static extern DWORD _MPUSBGetDLLVersion(); [DllImport("mpusbapi.dll")] private static extern DWORD _MPUSBGetDeviceCount(string pVID_PID); [DllImport("mpusbapi.dll")] private static extern void* _MPUSBOpen(DWORD instance, string pVID_PID, string pEP, DWORD dwDir, DWORD dwReserved); [DllImport("mpusbapi.dll")] private static extern DWORD _MPUSBRead(void* handle, void* pData, DWORD dwLen, DWORD* pLength, DWORD dwMilliseconds); [DllImport("mpusbapi.dll")] private static extern DWORD _MPUSBWrite(void* handle, void* pData, DWORD dwLen, DWORD* pLength, DWORD dwMilliseconds); [DllImport("mpusbapi.dll")] private static extern DWORD _MPUSBReadInt(void* handle, DWORD* pData, DWORD dwLen, DWORD* pLength, DWORD dwMilliseconds); [DllImport("mpusbapi.dll")] private static extern bool _MPUSBClose(void* handle); #endregion void* myOutPipe; void* myInPipe; public void OpenPipes() DWORD selection = 0; myOutPipe = _MPUSBOpen(selection, vid_pid_norm, out_pipe, 0, 0); myInPipe = _MPUSBOpen(selection, vid_pid_norm, in_pipe, 1, 0);


190


public void ClosePipes() _MPUSBClose(myOutPipe); _MPUSBClose(myInPipe); private void EnviarPaquete(byte* SendData, DWORD SendLength) uint SendDelay = 1000; DWORD SentDataLength; OpenPipes(); _MPUSBWrite(myOutPipe, (void*)SendData, SendLength, &SentDataLength, SendDelay); ClosePipes(); private void RecibirPaquete(byte* ReceiveData, DWORD *ReceiveLength) uint ReceiveDelay=1000; DWORD ExpectedReceiveLength = *ReceiveLength; OpenPipes(); _MPUSBRead(myInPipe, (void*)ReceiveData, ExpectedReceiveLength, ReceiveLength, ReceiveDelay); ClosePipes(); // Método para recibir los datos del USB public int DetectorAlarma() int alarm = 0; byte* receive_buf = stackalloc byte[1]; DWORD RecvLength = 1; RecibirPaquete(receive_buf, &RecvLength); alarm =receive_buf[0]; return alarm;


191


// Método para Enviar los datos por USB public void Controles(int dato) byte* send_buf = stackalloc byte[2]; // Si es mayor o igual a 100, se trata de un comando de encendido if (dato >= 100) dato = dat - 100; send_buf[0] = 0x00; send_buf[1] = (byte)dato; EnviarPaquete(send_buf, 2); // Si es menor a 100, se trata de un comando de apagado else send_buf[0] = 0x01; send_buf[1] = (byte)dato; EnviarPaquete(send_buf, 2);


192

Apéndice C. Circuitos impresos


En este apéndice se tienen los circuitos impresos que se utilizaron en el sistema, estos circuitos impresos, fueron diseñados con la ayuda de la aplicación PCB Wizard. Cabe mencionar, que los circuitos no se pudieron diseñar exactamente como debieran ser, ya que por ejemplo, en algunos componentes sobran agujeros de las terminales. Otra observación que es importante mencionar, es que no se logro la conexión total entre los dispositivos, por lo que fue necesario realizar estas conexiones manualmente, con ayuda de cable.

A continuación se mostrarán tres presentaciones distintas del mismo circuito, las últimas dos muestran con una línea delgada, una conexión con cable, que se requiere realizar.

Circuitos para el módulo USB.

Circuito impreso


193


Circuito impreso con conexiones extras

Vista superior del circuito


194


Circuitos para el módulo de control.

Circuito impreso



195



Circuitos para el módulo de monitoreo.

Circuito impreso


196





197


Circuito de potencia.

Circuito impreso



198




199

Bibliografía

BIBLIOGRAFÍA

Clayton Mat. Basic USB ‐ Using Microchip Stack and C#.Net – Hardware. Publicado el 26 de Febrero de 2006. http://www.piccoder.co.uk/content/view/42/26/.

Febian. Winsock with C#. Publicado el 8 de Marzo de 2007. http://www.go4expert.com/forums/showthread.php?t=3312.

Giovanni Z. Cómo crear un servidor Web con Prodigy Infinitum y el módemo 2Wire. Publicado el 3 de Marzo de 2007. http://bola8.erestlax.com/2007/03/03/como‐crear‐un‐servidor‐web‐con‐prodigy‐infinitum‐y‐el‐modem‐2wire/.

Harvey M. Deitel, Paul J. Deitel. C# Cómo programar, 2da Edición. Editorial: Prentice Hall.

Hersh Bhasin. ASP.NET, Proyectos Profesionales. Editorial: ANAYA.

Rodríguez Fernández Oscar, Troncoso Egea Roberto. Internet, La Biblia. Editorial: ANAYA.

Roy Blake. Sistemas de electrónicos de comunicaciones ,2da Edición. Editorial: Thomson.

Tutorial del control Winsock. Publicado el 23 de Junio de 2005. http://foro.elhacker.net/programacion_vb/tutorial_del_control_winsock‐t75832.0.html.

Wayne Tomasi. Sistemas de comunicaciones electrónicas, 2da Edición. Editorial: Pearson Educación.

Frenzel. Electrónica aplicada a los sistemas de las comunicaciones, 3era Edición. Editorial: Alfaomega


200

Índice de figuras

Índice de figuras

Capítulo 1

Figura 1. 1 Topología de la conexión USB ...................................................................................................................... 5

Figura 1. 2 Líneas en cable USB ..................................................................................................................................... 6

Figura 1. 3 Tipos de conector USB ................................................................................................................................. 7

Figura 1. 4 Principales usos del microcontrolador ....................................................................................................... 11

Capítulo 2

Figura 2. 1 Capas del modelo OSI ................................................................................................................................ 15

Figura 2. 2 Comparación entre modelo OSI y TCP/IP ................................................................................................... 16

Figura 2. 3 Aplicaciones y sus puertos ......................................................................................................................... 19

Figura 2. 4 Formato de una dirección IP ...................................................................................................................... 20

Figura 2. 5 Estructura de una dirección IP ................................................................................................................... 20

Figura 2. 6 Dirección IP de Clase A ............................................................................................................................... 21

Figura 2. 7 Dirección IP Clase B .................................................................................................................................... 21

Figura 2. 8 Dirección IP Clase D ................................................................................................................................... 21

Figura 2. 9 Interacción Cliente ‐ Servidor ..................................................................................................................... 25

Figura 2. 10 Propiedades, Métodos y Eventos del control Winsock ............................................................................ 31

Capítulo 3

Figura 3. 1 Diagrama de conexión de una cámara IP .................................................................................................. 35


201

Índice de figuras

Capítulo 4

Figura 4. 1 Registro del dominio en el servicio No‐ip ................................................................................................... 38

Figura 4. 2 Diagrama de actividad para la comunicación Cliente ‐ Servidor ............................................................... 41

Figura 4. 3 Interfaz gráfica de la aplicación Cliente ..................................................................................................... 42

Figura 4. 4 Diagrama caso ‐ uso de la aplicación Cliente ............................................................................................ 43

Figura 4. 5 Panel de conexión de la aplicación Cliente ................................................................................................ 44

Figura 4. 6 Panel de control en la aplicación Cliente ................................................................................................... 44

Figura 4. 7 Diagrama caso‐uso del panel de control de la aplicación Cliente .............................................................. 45

Figura 4. 8 Diagrama de actividad, horario de encendido ........................................................................................... 46

Figura 4. 9 Diagrama de actividad, encendido general ............................................................................................... 47

Figura 4. 10 Diagrama caso‐uso e interfaz gráfica del panel Estado de dispositivos .................................................. 48

Figura 4. 11 Diagrama de actividad, estado de los dispositivos .................................................................................. 49

Figura 4. 12 Señal de alarma ....................................................................................................................................... 50

Figura 4. 13 Panel de mensaje de la aplicación Cliente ............................................................................................... 51

Figura 4. 14 Panel de ubicación de los dispositivos ..................................................................................................... 51

Figura 4. 15 Estado de los dispositivos ........................................................................................................................ 52

Figura 4. 16 Clase AplicacionCliente ............................................................................................................................ 53

Figura 4. 17 Interfaz de la aplicación Servidor ............................................................................................................. 54

Figura 4. 18 Diagrama caso‐uso para la aplicación Servidor ....................................................................................... 55

Figura 4. 19 Panel, datos del Servidor ......................................................................................................................... 56

Figura 4. 20 Panel de mensajes de la aplicación Servidor ........................................................................................... 57


202

Índice de figuras

Figura 4. 21 Estados del Servidor ................................................................................................................................. 58

Figura 4. 22 Panel de conexión de la aplicación Servidor ............................................................................................ 58

Figura 4. 23 Diagrama de actividad para el proceso de conexión ............................................................................... 59

Figura 4. 24 Diagrama UML de la clase PicUSBAPI...................................................................................................... 61

Figura 4. 25 Diagrama de actividad para el método Controles ................................................................................... 64

Figura 4. 26 Diagrama de actividad para los procesos de conexión y desconexión .................................................... 66

Figura 4. 27 Diagrama de actividad para el envío de un dato ..................................................................................... 67

Capítulo 5

Figura 5.2.1 Diagrama a bloques del sistema de control a distancia y el sistema de comunicaciones. Las direcciones del flujo de la información están indicadas por la flecha naranja, para el módulo de control y azul, para el módulo de monitoreo. .............................................................................................................................................................. 74

Figura 5.2.2 Ejemplo de comando de control. ............................................................................................................. 78

Figura 5.2.3 Ejemplo de comando de monitoreo. ........................................................................................................ 80

Figura 5.2.4 Diagrama a bloques del módulo de control. ............................................................................................ 82

Figura 5.2.5 Ejemplo de comunicación en el enlace de control. .................................................................................. 88

Figura 5.2.6 Diagrama eléctrico del módulo USB con Tx y Rx inalámbricos. ............................................................... 89

Figura 5.2.7 Diagrama de flujo del programa principal del microcontrolador USB. .................................................... 96



Figura 5.2.10 Estructura de la información codificada por el HT12E. ........................................................................ 100

Figura 5.2.11 Codificación de datos binarios. ............................................................................................................ 100

Figura 5.2.12 Ejemplo de una palabra en banda base para transmisión inalámbrica. ............................................. 102


203

Índice de figuras

Figura 5.2.13 Diagrama de flujo de la rutina de servicio del temporizador 2, del microcontrolador USB. ................ 106

Figura 5.2.14 Diagrama de flujo de la función que codifica palabras de 12 bits, para generar una señal en banda base. .......................................................................................................................................................................... 107

Figura 5.2.15 Ejemplo del funcionamiento de la variable nciclo. .............................................................................. 109

Figura 5.2.16 Diagrama de flujo de la función COD_BIT_UNO. ................................................................................. 111

Figura 5.2.17 Diagrama de flujo de la función COD_BIT_CERO. ................................................................................ 112

Figura 5.2.18 Diagrama de flujo de la función T_12BITS. .......................................................................................... 114

Figura 5.2.19 Diagrama a bloques del receptor inalámbrico utilizado para el módulo de control. .......................... 115

Figura 5.2.20 Diagrama eléctrico del receptor inalámbrico, utilizado en el módulo de control. ............................... 116

Figura 5.2.21 Diagrama eléctrico del circuito de potencia. ....................................................................................... 117

Figura 5.2.22 Rutina de servicio de la interrupción externa 0. .................................................................................. 119

Figura 5.2.23 Diagrama de flujo de la función DECODIFICA (parte 1). ...................................................................... 121

Figura 5.2.24 Diagrama de flujo de la función DECODIFICA (parte 2). ...................................................................... 122

Figura 5.2.25 Comportamiento de las variable nsubmuestra, cuando se está decodificando. ................................. 123

Figura 5.2.26 Diagrama de flujo de la función VERIFICA. .......................................................................................... 127

Figura 5.2.27 Ejemplo de palabra codificada en banda base, y los puntos en donde se toman muestras para su decodificación. ........................................................................................................................................................... 130

Figura 5.2.28 Diagrama a bloques del módulo de monitoreo. .................................................................................. 131

Figura 5.2.29 Estructura de la palabra de estado de los dispositivos a monitorear .................................................. 135

Figura 5.2.30 Estructura de la palabra de estado de los dispositivos a controlar. .................................................... 137

Figura 5.2.31 Ejemplo de palabra de estado de los dispositivos a monitorear ......................................................... 139

Figura 5.2. 32 Ejemplo de comunicación para el monitoreo de los detectores, desde la aplicación cliente. ............. 141


204

Índice de figuras

Figura 5.2.33 Ejemplo de comunicación para el monitoreo de los dispositivos a controlar, desde la aplicación cliente. ....................................................................................................................................................................... 142

Figura 5.2.34 Diagrama a eléctrico del transmisor inalámbrico usado en el módulo de monitoreo. ........................ 143

Figura 5.2.35 Diagrama de conexión supuesta, entre dispositivos a monitorear y las terminales DD. ..................... 145

Figura 5.2.36 Diagrama de la conexión entre el microcontrolador decodificador y el microcontrolador codificador, para el monitoreo de dispositivos. ............................................................................................................................. 146

Figura 5.2.37 Diagrama de flujo del programa del microcontrolador codificador. ................................................... 148

Figura 5.2.38 Diagrama de flujo de la rutina de servicio del temporizador 1. ........................................................... 149

Figura 5.2.39 Diagrama de flujo de la rutina de servicio del temporizador 2. ........................................................... 150

Figura 5.2.40 Diagrama eléctrico del módulo USB, el cual incluye el receptor inalámbrico del módulo de monitoreo. ................................................................................................................................................................................... 152

Figura 5.2.41 Diagrama de flujo de la rutina de servicio del temporizador 2, del microcontrolador USB. ................ 153


205

Glosario

Glosario

ADSL: Es una tecnología de acceso a internet de banda ancha. ADSL son las siglas de Asymmetric Digital Subscriber Line ("Línea de Suscripción Digital Asimétrica"). ADSL es un tipo de línea DSL. Consiste en una transmisión de datos digitales (la transmisión es analógica), apoyada en el par simétrico de cobre que lleva la línea telefónica convencional o línea de abonado.

Aplicación cliente: Es el programa desde el cual se va a llevar a cabo el control y monitoreo de los dispositivos.

Aplicación servidor: Es el programa que permite la comunicación entre el módulo USB y la aplicación cliente.

ASK: Modulación por desplazamiento de amplitud.

Cable de datos de categoría Cat5e: es una de las cinco clases de cableado UTP que se describen en el estándar TIA/EIA‐568‐B. Puede transmitir datos a velocidades de hasta 1000 Mbps.

Cámara IP: Son videocámaras capaces de capturar y transmitir imágenes en tiempo real a través de una red IP, conectadas por medio de un router, switch, concentrador, etc., sin la necesidad de algún otro dispositivo extra.

Código de activación: En nuestro sistema, es un código de 12 bits que identifica a un dispositivo de monitoreo (sensor, detector, etc.) por medio de este código se informa que el dispositivo de monitoreo ha detectado algún cambio en el medio (p. ej. humo), éste código es utilizado en el enlace de monitoreo. (Véase Fig. 5.2.3)

Codigo de encendido: En nuestro sistema, es un código de 12 bits que indica el encendido de algún dispositivo a controlar. (Véase Fig. 5.2.2)

Código de línea: Los códigos de línea consisten en representar información digital, con una señal digital transportada respecto a su amplitud y respecto al tiempo, esta señal debe estar perfectamente sincronizada.

Código de mando: En nuestro sistema llamamos código de mando, a un código de 12 bits, que puede ser el código de encendido, código de apagado, ó código de activación.


206

Glosario

Comando de alarma: Un comando de alarma, es un número entero de 1 byte, que es enviado desde el servidor, hacia el cliente, para avisar que algún detector se ha activado.

Comando de control: Llamamos comando de control, a un número entero de 1 byte, que es enviado desde la aplicación cliente, hacia la aplicación servidor, con el fin de encender o apagar algún dispositivo. (También véase sección 5.2.1)

Comando de monitoreo: Llamamos comando de monitoreo, a un número entero de 1 byte, que es enviado desde la aplicación servidor, hacia la aplicación cliente, con el fin de monitorear los dispositivos, es decir informar a la aplicación cliente, cuáles detectores se han activado, o cuáles dispositivos se encuentran encendidos.

Concentrador o hub: Es un dispositivo que permite centralizar el cableado de una red y poder ampliarla. Esto significa que dicho dispositivo recibe una señal, y repite esta señal emitiéndola por sus diferentes puertos.

Conmutador de red: Un conmutador es un dispositivo de red que conecta segmentos de la red y que selecciona una ruta para enviar una unidad de datos a su próximo destino. En general, un conmutador es un mecanismo más sencillo y rápido que un router, que requiere conocimientos acerca de la red y de cómo determinar la ruta. Algunos conmutadores incluyen la función de router.

Demodulación: Proceso opuesto a modulación, es decir, recuperar la información que fue modulada.

Desplazamiento de bits: Es una operación que nos permite mover los bits, ya sea hacia la izquierda, o hacia la derecha. El desplazamiento puede ser de 1 bit, o de los bits que se requieran. El operador para desplazamiento y asignación hacia la izquierda es <<=; y el operador para desplazamiento hacia la derecha es >>=. Se utilizan de la siguiente manera:

variable<<=bits ó variable>>=bits

En donde bits, es el número de bits que se desean desplazar. Por ejemplo, en los programas se usó un desplazamiento hacia la izquierda de 1bit, esto es que si a la variable info_tempo = 0x000B, se le aplica un desplazamiento info_tempo<<=1. Entonces inicialmente info_tempo = 0000 0000 0000 1011; después de aplicarle el desplazamiento info_tempo<<=1, tenemos como resultado info_tempo=0000 0000 0001 0110.


207

Glosario

Disco duro (o rígido): Es un dispositivo de almacenamiento no volátil, que conserva la información aun con la pérdida de energía, que emplea un sistema de grabación magnética digital; es donde en la mayoría de los casos se encuentra almacenado el sistema operativo de la computadora.

E/S: Entrada/Salida

Endpoint o Device Endpoint: La porción direccionable de un dispositivo USB que es la fuente o el lugar de llegada de la comunicación entre el host y el dispositivo.

Flanco de elevación: Un flanco de elevación sucede, cuando existe un cambio de nivel de voltaje, desde un nivel de voltaje bajo, a un nivel de voltaje alto.

Int16: Por medio de esta instrucción, declaramos una variable tipo entera, de 16 bits.

Interrupción externa 0: Esta interrupción, en el PIC18F2550, es provocada por el cambio de nivel de voltaje en la terminal RB0 (en nuestro sistema por un cambio de nivel de voltaje de bajo, a alto).

LED: Proviene del acrónimo del inglés, Light‐Emitting Diode, que en español es, Diodo Emisor de Luz. El LED es un dispositivo semiconductor que emite luz.

Modulación: Proceso por medio del cual, se cambian parámetros como amplitud, frecuencia o fase, de una señal en banda base o señal de información.

Módulo de control: Es la unidad por medio de la cual se lleva a cabo el control de dispositivos (también véase sección 5.2.3).

Módulo de monitoreo: Es la unidad por medio de la cual se lleva a cabo el monitoreo de dispositivos (también véase sección 5.2.2).

Módulo USB: Es la unidad que tiene conexión a través del USB, con el servidor. Es un circuito compuesto por el microcontrolador USB, módulo de RF, transmisor TWS-BS-3 (433.92 MHz), y un módulo de RF, receptor RWS-374-3 (315 MHz). (Véase figura 5.2.6)

Multiplexor: Es un dispositivo que puede recibir varias entradas, y transmitirlas por un solo medio de transmisión. Una señal que está multiplexada debe ser demultiplexada en el otro extremo, para ser recuperada.


208

Glosario

Palabra de estado de los dispositivos a controlar: Llamamos así, a las palabras de 12 bits que se utilizan para informar acerca del estado de los detectores, estas palabras son las que se envían de manera inalámbrica en el módulo de monitoreo.

Palabra de estado de los dispositivos a monitorear: Llamamos así, a las palabras de 12 bits que son utilizadas para informar acerca del estado de los detectores, estas palabras son las que se envían de manera inalámbrica en el módulo de monitoreo.

Periodo de bit: Llamamos periodo de bit, al tiempo necesario para transmitir, es decir tres periodos de la señal de reloj utilizada para codificar, cuyo periodo es de 286 µs, por lo tanto un periodo de bit, dura aproximadamente 858 µs. (También véase figura 5.2.15).

Perro guardián: Consiste en un temporizador que, cuando se desborda y pasa por 0, provoca un reset automáticamente en el sistema, esto sucede siempre y cuando el programa falle o se bloquee.

Pipe: Una unión abstracta entre el Endpoint y el software del host.

Protocolo: Conjunto específico de reglas, procedimientos o conversaciones relacionadas con el formato y el tiempo de transmisión de datos entre dos dispositivos.

RF: Proviene de Radio Frecuencia, y ésta, es una porción del espectro electromagnético utilizada en las comunicaciones inalámbricas.

Router: Dispositivo que determina el siguiente punto de red, al que se debe reenviar un paquete en camino hacia su destino final. Un router crea y/o mantiene una tabla de enrutamiento especial, que almacena información sobre la mejor manera de llegar a ciertos destinos. A veces, se incluye un router como parte de un conmutador de red.

Rutina de servicio: Una rutina de servicio, es un programa que es ejecutado cuando haya ocurrido alguna interrupción (de algún temporizador, interrupción externa, etc.).

Señal digital en banda base: Es aquella señal digital que aún esta sin modular.

Señal en banda base: Es la señal de información, que aún esta sin modular, también suele llamársele señal moduladora.

Servidor: Un servidor, es un programa informático que proporciona servicios a otros programas informáticos, que se encuentran en el mismo ordenador o en otros ordenadores. También se


209

Glosario

denomina a menudo "servidor", a un ordenador en el que se ejecute un programa de servidor. En la práctica, el servidor puede contener una serie de programas de servidor y de cliente.

Sistema domótico: Es un sistema que integra distintas funciones desarrolladas, tanto en hardware y software, con el objetivo de automatizar las instalaciones habituales en un sistema habitacional o residencial.

USB: Proviene de las siglas Universal Serial Bus (bus universal en serie), y es un puerto que sirve para conectar periféricos a una computadora.

Webcam ó cámara web: Es una pequeña cámara digital que necesita estar conectada a un ordenador, para poder capturar imágenes y transmitirlas a través de Internet en directo.

de control y monitoreo de a través de Internet con USB”

Documents

Transcript of de control y monitoreo de a través de Internet con USB”