• No se han encontrado resultados

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

5.2   Sistema electrónico de comunicaciones 74

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

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. 

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

/

. .  

Por lo tanto la antena tendrá una longitud. 

.

.  

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. 

155  .

.  

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 cont inuación se enum eran los com ponent es elect rónicos ut ilizados, divididos en varios m ódulos que son los que conform an la part e elect rónica del proyect o, para post eriorm ent e present ar su cost o unit ario y t ot al.

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  

157  > 1 Base para circuito integrado de 28 terminales.    

> 1 capacitor de 0.1 µF   > 1 resistencia de 10 KΩ   > 5 resistencias de 330 Ω  > 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 microcontrolador PIC18F2550  

> 1 Base para circuito integrado de 28 terminales.   > 1 capacitor de 0.1 µF  

> 1 resistencia de 10 KΩ   > 2 resistencias de 330 Ω   > 2 LEDs   

> 1 módulo de RF transmisor TWS‐315   > 4 interruptores tipo push‐button.  

Componentes extra   > 1 cámara IP 

> 1 Router inalámbrico 2wire > Cables de datos de categoría Cat5e > Placas fenólicas

> Program ador GTP USB Lit e

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 

 

I nt errupt or t ipo push- but t on 7 $2 $14.00 Placa fenólica  1  $40  $40.00 

 

159   Ahora se det erm inarán los cost os que t ienen que ver con las herram ient as soft ware así com o con los recursos hum anos.

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.

Podem os calcular ent onces, que el cost o t ot al por concept o de m ano de obra sería de: $ 3 9 0 0 0 .0 0

Cost o t ot al del proyect o

Para det erm inar el cost o t ot al del proyect o sum am os los cost os t ot ales obt enidos ant eriorm ent e.

Concepto

 

Costo

 

Componentes electrónicos $6222.50

 

Licencias software

 

$10681.85 Mano de obra

 

$39000.00

TOTAL 

$55904.35

 

 

161 

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, 

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 

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. 

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.  

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

167 

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.  

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  

Dispositivo tipo 1, VID 0x04d8, PID 0x0002  

Dispositivo tipo 2, VID 0x04d8, PID 0x0003  

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.  

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

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.  

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 

Documento similar