Sistema de control y gestión utilizando la tecnología GSM basado en comandos AT

utilizando la tecnolog´ıa GSM basado

en comandos AT

Heiner Jesid G´

omez Cubides

Sergio David Herrera Moreno

Ingenier´ıa Electr´

onica

Director:

Leonardo Plazas Nossa

Universidad Distrital Francisco Jose de Caldas

Facultad de ingenier´ıa

Dedicatoria

Dedico principalmente este proyecto a mis padres quienes siempre han estado a mi lado para guiarme, aconsejarme y apoyarme durante todo este proceso. Gracias por ser un ejem-plo de constancia y dedicaci´on, por inculcarme valores de respeto y responsabilidad en todo momento.

Agradezco tambi´en, a todos los maestros que hicieron parte de este proceso de aprendizaje, quienes con sus conocimientos y experiencias contribuyeron a un crecimiento personal y profesional.

Heiner Jesid G´omez Cubides

Dedico mi trabajo en este proyecto principalmente a mis padres quienes son los pilares fun-damentales de mi vida personal y acad´emica. Gracias a mi familia, compa˜neros y profesores que me acompa˜naron en todo este proceso y me apoyaron infinitamente para poder crecer profesional y personalmente, sin ellos todo este camino no podr´ıa haber llegado a un feliz termino.

Agradecimientos

Los autores expresan sus agradecimientos a:

Al ingeniero Leonardo Plazas Nossa, director y tutor del proyecto de grado, qu´e con sus conocimientos supo guiarnos en el desarrollo del proyecto, nos brind´o herramientas, m´etodos y consejos que fueron de gran ayuda para llevar a cabo el cumplimiento de los objetivos planteados al iniciar el proyecto.

Resumen

Este trabajo describe el proceso de desarrollo e implementaci´on de un prototipo para un sistema de control y gesti´on de sensores y actuadores utilizando la tecnolog´ıa GSM, que tenga la capacidad de capturar temperatura del medio y enviar mensajes de texto (alertas de temperatura) mediante la red GSM a una interfaz de usuario en la cual se controlar un dispositivo actuador (ventilador), que se enciende y apaga remotamente cuando el usuario lo requiera. Inicialmente se realiza la investigaci´on pertinente enfocada a los distintos coman-dos AT y protocolos necesarios para establecer una comunicaci´on v´ıa mensajes de texto por medio de la red GSM, en los operadores nacionales de telefon´ıa. Por medio de un controla-dor PSoC se realiza la medici´on de temperatura y se hace la conexi´on por puerto serial que permite escribir los comandos AT en el m´odulo GSM que se encarga de enviar los mensajes de texto. Se programa una interfaz de usuario en lenguaje C#, debido a su facilidad en el manejo de la conexi´on a puerto serial de la m´aquina en la que la interfaz sea utilizada, esta interfaz controla el actuador (ventilador) que se encarga de regular la temperatura.

Se llevan a cabo una serie de pruebas que permiten evaluar el desempe˜no del sistema proto-tipo, para esto se env´ıan y se reciben mensajes en cuanto a tiempo de respuesta. Durante el desarrollo del proyecto se realizaron distintas pruebas enviando y recibiendo mensajes con la intenci´on de medir la disponibilidad de la red GSM. Despu´es de tener los resultados de las pruebas individuales, tanto del m´odulo transmisor y del m´odulo receptor se integran ambas partes, por un lado se tiene el m´odulo que est´a conectado al sensor y el actuador, y por otro lado el m´odulo que se conecta a la interfaz gr´afica. A temperatura ambiente el sistema captura la temperatura y la presenta en una pantalla LCD de tama˜no 16x2. Una vez la temperatura supera los 35 o_{C, el dispositivo se encarga de enviar un mensaje de alerta al}

m´odulo conectado a la interfaz gr´afica y adem´as se env´ıa un mensaje de texto a un tel´efono m´ovil que posee el usuario en donde tambi´en se notifica que la temperatura ha sobrepasado el valor esperado.

Lista de figuras 1

1 Introducci´on 3

2 Planteamiento del problema 4

3 Justificaci´on 5

4 Objetivos 6

4.1 Objetivo general . . . 6

4.2 Objetivos espec´ıficos . . . 6

5 Marco referencial 7 5.1 RED GSM . . . 7

5.1.1 Est´andares sistema GSM . . . 7

5.1.2 Servicios y aplicaciones . . . 8

5.1.3 Arquitectura red GSM . . . 8

5.1.4 M´odulo de identificaci´on del abonado . . . 9

5.2 COMANDOS AT . . . 10

5.2.1 Historia . . . 11

5.2.2 Comandos . . . 13

5.2.3 Descripci´on . . . 13

5.2.4 Definiciones sint´acticas . . . 14

5.2.5 Comandos AT para un m´odem GSM . . . 15

5.2.6 Ejemplo de sesi´on . . . 16

5.3 ESTANDAR RS-232 . . . 17

5.3.1 Historia . . . 17

5.3.2 Caracter´ısticas de la se˜nal el´ectrica . . . 17

5.3.3 Caracter´ısticas mec´anicas . . . 19

5.3.4 Cableados t´ıpicos para el RS-232 . . . 20

5.4 SENSOR DE TEMPERATURA (LM35) . . . 22

5.5 VENTILADOR NMB 1004KL-01W-B30 . . . 23

5.6 DIAGRAMA DE BLOQUES . . . 24

6 Metodolog´ıa 27

6.1 Fase 1 - Identificaci´on del sistema GSM y los comandos AT . . . 27

6.1.1 Sistema GSM . . . 27

6.1.2 Comandos AT . . . 28

6.2 Fase 2 - Selecci´on y prueba del modulo para la comunicaci´on de equipos . . . 30

6.2.1 Prueba configuraci´on y envi´o de mensaje . . . 32

6.3 Fase 3 - Selecci´on y prueba del sensor y/o actuador . . . 35

6.3.1 Sensor Temperatura . . . 35

6.3.2 Actuador-Ventilador . . . 35

6.3.3 Prueba Sensor LM35 y ventilador . . . 35

6.4 Fase 4 - Desarrollo de una interfaz gr´afica de control para actuadores y/o sensores gen´ericos . . . 38

6.5 Fase 5 - Implementaci´on y pruebas . . . 44

6.5.1 Interacci´on elementos software y hardware . . . 44

6.5.2 Pruebas interfaz gr´afica y conexi´on con PSoC . . . 46

6.5.3 Prueba tiempos recepci´on mensajes. . . 50

6.5.4 Operaci´on completa del prototipo. . . 51

7 An´alisis de resultados 56 7.1 Prueba interfaz gr´afica y conexi´on PSoC . . . 56

7.2 Prueba tiempos recepci´on mensajes . . . 57

8 Conclusiones 58

5-1. Arquitectura red GSM. [3] . . . 10

5-2. Ejemplos comandos AT [11] . . . 15

5-3. Ejemplos comandos AT [11] . . . 16

5-4. Velocidad de transmisi´on dependiente de la longitud del cable. [15] . . . 18

5-5. Transmisi´on bits letra W. . . 19

5-6. Conector D 9 terminales.W. . . 20

5-7. Cableado RS-232 . . . 21

5-8. Conexi´on dos DTE . . . 22

5-9. Dimensiones del ventilador nmb 1004KL-01W-B30. [28] . . . 23

5-10.Curvas caracter´ısticas ventilador nmb1004KL-01W-B30.[28] . . . 23

5-11.Diagramas de bloques del sistema.[23] . . . 24

6-1. Frecuencia operaci´on est´andar GSM para operadores m´oviles . [29][30] . . . . 27

6-2. Cantidad abonados por operador. [30] . . . 27

6-3. Cobertura operadores m´oviles. [31] . . . 28

6-4. PSoC CY8C5888LTI-LPO97. . . 31

6-5. Modulo GSM/GPRS A6. . . 31

6-6. Bloque UART. . . 32

6-7. Configuraci´on y envi´o mensaje PSoC creator. . . 33

6-8. Envi´o del mensaje usando modulo A6 . . . 33

6-9. Recepci´on en dispositivo m´ovil y envi´o de respuesta. . . 34

6-10.Recepci´on del mensaje usando el modulo A6. . . 34

6-11.Sensor de temperatura LM35. . . 35

6-12.Bloques implementaci´on sensor temperatura. . . 36

6-13.Medici´on digital temperatura. . . 36

6-14.Visualizaci´on LCD temperatura medida. . . 37

6-15.Circuito encendido ventilador. . . 37

6-16.Dise˜no de la interfaz de usuario en C Sharp. . . 38

6-17.Importar Librer´ıa IO.Ports. . . 39

6-18.Programaci´on de interrupci´on. . . 40

6-19.Programaci´on de bot´on buscar puertos. . . 40

6-20.Programaci´on de botones conectar y desconectar. . . 41

6-22.Programaci´on bot´on apagar. . . 42

6-23.Programaci´on de alertas para dato recibido. . . 43

6-24.Integraci´on componentes fase 2 y 3. . . 44

6-25.Interrupci´on encendido/apagado actuador. . . 45

6-26.Ning´un puerto detectado. . . 46

6-27.Lista de puertos. . . 46

6-28.Click en bot´on encender. . . 47

6-29.Click en bot´on apagar. . . 47

6-30.Interrupci´on para la subida de temperatura. . . 47

6-31.Interrupci´on para la bajada de temperatura. . . 48

6-32.Esquema para el manejo de dos UART. . . 48

6-33.Recepci´on de alerta. . . 49

6-34.Resultados tiempo recepci´on mensaje alerta en PC. . . 50

6-35.Resultados tiempo recepci´on mensaje activaci´on actuador. . . 50

6-36.Resultados tiempo recepci´on mensaje enviado desde dispositivo m´ovil. . . 51

6-37.mensaje de configuraci´on. . . 51

6-38.Circuito de conexi´on interfaz gr´afica. . . 52

6-39.Medici´on temperatura ambiente. . . 52

6-40.Alerta LCD aumento temperatura. . . 53

6-41.Mensaje enviado m´ovil del usuario por aumento temperatura. . . 53

6-42.LED amarillo testigo que muestra que la alerta lleg´o correctamente. . . 53

6-43.LED verde testigo que muestra que la instrucci´on de encendido lleg´o correc-tamente. . . 54

6-44.Alerta ventilador-ON en LCD. . . 54

6-45.Alerta LCD disminuci´on temperatura. . . 55

6-46.Mensaje enviado m´ovil del usuario por disminuci´on temperatura. . . 55

En la actualidad los sistemas de control y gesti´on son de gran importancia ya que permi-ten el funcionamiento ´optimo de alg´un sistema, estos son altamente empleados en distintos entornos, desde hogares hasta empresas y han ido evolucionando de controles e indicadores neum´aticos a sistemas electr´onicos con el fin de facilitar y garantizar el cumplimiento de una tarea espec´ıfica que puede variar desde encender un bombillo hasta otras de mucha m´as complejidad [1].

El sistema global para las comunicaciones m´oviles GSM es considerado por su velocidad de transmisi´on y otras caracter´ısticas un est´andar de segunda generaci´on 2G. Es el est´andar en telecomunicaciones m´oviles m´as extendido en el mundo, con un 82 % de los terminales mundiales en uso [2]. La telefon´ıa m´ovil GSM adopt´o por est´andar los comandos AT como lenguaje para la comunicaci´on entre terminales, de este modo los tel´efonos m´oviles GSM poseen comandos que sirve para configurar y proporcionar instrucciones a los terminales.

El prop´osito de este proyecto es reunir y aplicar los conocimientos que se han adquirido en el desarrollo de las diferentes asignaturas de la carrera, tales como telecomunicaciones, telem´atica, control y electr´onica en general, con el fin de desarrollar un prototipo de un sistema de control y gesti´on GSM basado en comandos AT, el cual permita tener el manejo de dispositivos desde sensores hasta actuadores que puedan ejercer acciones como lo desee el usuario mediante un entorno gr´afico. Este prototipo no ha sido implementado dentro de la Universidad Distrital motivo por el cual es importante el desarrollo del mismo como avance e integraci´on de diferentes elementos tecnol´ogicos.

Otro elemento importante a destacar es que con el desarrollo de este prototipo se pretende dejar elementos que sirvan a la comunidad acad´emica, en especial a la Universidad Distrital y a los estudiantes de los diferentes proyectos curriculares que puedan ser utilizados en las diferentes asignaturas anteriormente mencionadas adem´as es un buen proyecto para incenti-var a los compa˜neros de ingenier´ıa electr´onica de la Universidad Distrital Francisco Jos´e De Caldas a profundizar en las comunicaciones GSM basadas en comandos AT.

4.1.

Objetivo general

Implementar un prototipo de un sistema de control y gesti´on GSM basado en comandos AT.

4.2.

Objetivos espec´ıficos

Comprender el sistema y utilizaci´on de comandos AT en la tecnolog´ıa GSM con el fin de realizar la comunicaci´on entre dos puntos extremos.

Comprender el sistema de conexiones en un radio de la tecnolog´ıa GSM para realizar el proceso de comunicaci´on desde y hacia un equipo terminal de datos.

Determinar un sistema de control remoto mediante los comandos AT para la gesti´on de sensores y actuadores on/off gen´ericos.

5.1.

RED GSM

Formalmente conocida como ”Group Special Mobile”(GSM, Grupo Especial M´ovil) aunque tambi´en llamada Global System for Mobile communications (Sistema Global para las Co-municaciones M´oviles),es un est´andar mundial para tel´efonos m´oviles digitales creado por la CEPT y posteriormente desarrollado por el ETSI como un est´andar para los tel´efonos m´oviles europeos, con la intenci´on de desarrollar una normativa que fuera adoptada mun-dialmente[5]. GSM es un sistema de comunicaciones m´oviles digital que constituye la segunda generaci´on de sistemas m´oviles. Puede ser caracterizado como un sistema m´ovil celular di-gital de telefon´ıa por radio [3].

GSM tiene cuatro versiones principales basadas en las bandas: 850, 900, GSM-1800 y GSM-1900. GSM-900 (900 MHz) y GSM-GSM-1800 (1,8 GHz) son utilizadas en la mayor parte del mundo, salvo en Estados Unidos, Canad´a y el resto de Am´erica Latina, lugares en los que se utilizan las bandas de GSM-850 y GSM-1900 (1,9 GHz) [5].

El ´unico servicio ofrecido por GSM y que no se encuentra en los sistemas anal´ogicos m´as antiguos, es el servicio de mensajes cortos o SMS (Short Message Service). SMS es un servicio bidireccional para mensajes alfanum´ericos cortos (hasta 160 bytes) [5].Un elemento impor-tante del sistema GSM es su sistema de identificaci´on basado en la tarjeta ´unica de abonado llamada SIM (Subscriber Identity Module) [3].

5.1.1.

Est´

andares sistema GSM

En GSM las aplicaciones b´asicas operan en la banda de 900 MHz. El incremento del tr´afico de datos dio lugar al desarrollo de otras versiones con m´ultiples bandas de frecuencia. As´ı pues, hay tres est´andares, que difieren principalmente en el rango de frecuencia utilizado y en el n´umero de canales asignados [3]:

GSM 900 – banda de frecuencias de 900 MHz, capacidad m´axima de 2 x 124 canales, ancho de banda de 2 x 25 MHz.

GSM 1900 – banda de frecuencias de 1900 MHz, capacidad m´axima de 2 x 298 canales, ancho de banda de 2 x 75 MHz.

5.1.2.

Servicios y aplicaciones

El sistema GSM permite la prestaci´on de servicios de telecomunicaciones (servicios a distan-cia) y servicios de transmisi´on (servicios portadores). Los servicios GSM est´an aumentando continuamente y la lista de servicios implantados depende del operador de red (proveedor) [3].

Entre los servicios se pueden encontrar:

Telefon´ıa (incluyendo llamadas de emergencia, llamadas mediante itinerancia y tambi´en en todas las otras redes).

Servicios de mensajes, tales como SMS (Short Message Services) con la posibilidad de enviar un m´aximo de 160 caracteres entre dos puntos o con la capacidad de enviar un mensaje a todas las estaciones m´oviles en la celda (como informes de tr´afico o de clima) mediante el servicio de difusi´on CBS (Cell Broadcast Service).

Correo de voz (voicemail).

E-mail (servicio vinculado al correo electr´onico de Internet). Servicios bancarios.

Servicios de informaci´on, etc.

5.1.3.

Arquitectura red GSM

Se puede dividir en tres partes fundamentales: subsistema de estaci´on base, subsistema de conmutaci´on de red y subsistema de soporte de operaci´on.

Subsistema de estaci´on base (BSS)

Subsistema de Conmutaci´on de red (NSS, Network Switching Subsystem)

Es el componente que realiza las funciones de portar y administrar las comunicaciones entre los tel´efonos m´oviles y la Red Conmutada de Telefon´ıa para una red GSM. Dicho subsistema permite a los tel´efonos m´oviles establecer comunicaci´on unos a otros dentro y/o fuera de su propia red. Su arquitectura tecnol´ogica est´a muy relacionada con las centrales telef´onicas tradicionales (Redes de Telefon´ıa Fija), sin embargo, hay funciones adicionales que son ne-cesarias ya que los tel´efonos no se encuentran fijos en una ´unica ubicaci´on.

Estas funciones son [3]:

HLR(Home Location Register): Mantiene un registro de todos los participantes en el ´

area. Almacena los datos est´aticos m´as significativos relativos al abonado m´ovil cuando ´

este se registra en ella, as´ı como los datos variables asociados a su movilidad [4].

VLR (Visitor Location Register): Almacena temporalmente la informaci´on m´as re-ciente sobre la situaci´on de un terminal m´ovil en el rango de su MSC (centro de conmutaci´on de servicios m´oviles). El VLR solicita y obtiene datos del HLR y si el terminal m´ovil abandona la zona visitada sus datos se eliminan del VLR [3].

EIR (Equipment Identity Register):Almacena informaci´on acerca de los terminales m´oviles, encarg´andose de controlar el acceso a la red evitando el uso de equipos m´oviles no autorizados [3][4].

Subsistema de Soporte a la Operaci´on (OSS Operation Support Subsystem)

El OSS es responsable de la operaci´on de BSS y NSS. Contiene principalmente un bloque de supervisi´on, ADC (Administrative Centre), que se encarga de las tareas administrativas (por ejemplo, informe de participaci´on, facturaci´on, etc.), y un bloque de gesti´on global del flujo de informaci´on en la red NMC (Network Management Centre), y un bloque de operaci´on y mantenimiento OMC (Operation and Maintenance Centre), que se encarga del mantenimiento y explotaci´on de la red [3].

5.1.4.

M´

odulo de identificaci´

on del abonado

Figura 5-1: Arquitectura red GSM. [3]

excepciones: las llamadas de emergencia se pueden realizar sin la tarjeta SIM. Un aspecto importante que impide que un usuario no autorizado pueda escuchar una comunicaci´on es el hecho que las transmisiones van cifradas [3].

5.2.

COMANDOS AT

Los comandos AT son instrucciones codificadas que conforman un lenguaje de comunicaci´on entre el hombre y un terminal modem. En un principio, el juego de comandos AT fue desa-rrollado en 1977 por Dennis Hayes como un interfaz de comunicaci´on con un modem para as´ı poder configurarlo y proporcionarle instrucciones, tales como marcar un n´umero de tel´efono. M´as adelante, con el avance del baudio, fueron las compa˜n´ıas Microcom y US Robotics las que siguieron desarrollando y expandiendo el juego de comandos hasta universalizarse. Los comandos AT se denominan as´ı por la abreviatura de attention .

t´ecnica de los terminales GSM y permite acciones tales como realizar llamadas de datos o de voz, leer y escribir en la agenda de contactos y enviar mensajes SMS, adem´as de muchas otras opciones de configuraci´on del terminal [6].

5.2.1.

Historia

Antes de la introducci´on del sistema de tabla de anuncios (BBS), los m´odems normalmente operaban en l´ıneas telef´onicas de marcaci´on directa que siempre comenzaban y terminaban con un m´odem conocido en cada extremo. Los m´odems funcionaban en los modos “originar” o responder”, alternando manualmente entre dos conjuntos de frecuencias para la transferen-cia de datos. En general, el usuario que realizaba la llamada cambiaba su m´odem a “originar” y luego marcaba el n´umero manualmente. Cuando el m´odem remoto contestaba, ya estaba configurado en modo de respuesta”, el auricular del tel´efono se apagaba y las comunicaciones continuaban hasta que la persona que llamaba se desconectaba manualmente.

Cuando se requer´ıa automatizaci´on, com´unmente solo se necesitaba en el lado de la res-puesta, por ejemplo, un banco podr´ıa necesitar recibir llamadas de varias sucursales para el procesamiento al final del d´ıa. Para cumplir esta funci´on, algunos m´odems incluyen la capacidad de levantar el tel´efono autom´aticamente cuando estaba en modo de respuesta y borrar la l´ınea cuando el otro usuario se desconecta manualmente. La necesidad de marca-ci´on autom´atica saliente era considerablemente menos com´un, y se manejaba a trav´es de un dispositivo perif´erico separado, un “marcador”. Esto normalmente se conectaba a un puerto de entrada / salida separado en la computadora (generalmente un puerto RS-232) y se pro-gramaba por separado desde el propio m´odem.

Este m´etodo de operaci´on funcion´o satisfactoriamente en la d´ecada de 1960 y principios de la de 1970, cuando los m´odems generalmente se usaban para conectar dispositivos ton-tos como terminales de computadora (marcaci´on) con computadoras centrales inteligentes (contestador). Sin embargo, la revoluci´on del microordenador de la d´ecada de 1970 condujo a la introducci´on de m´odems de bajo costo y la idea de un enlace semi-dedicado punto a punto ya no era apropiada. Hab´ıa potencialmente miles de usuarios que quer´ıan marcar a cualquiera de los otros miles de usuarios, y la ´unica soluci´on en ese momento era hacer que el usuario marcara manualmente.

hard-ware en el est´andar RS-232. Sin embargo, muchas implementaciones del puerto RS-232 en microcomputadoras fueron extremadamente b´asicas, y algunas eliminaron muchos de estos pines como una medida de ahorro de costos.

La soluci´on de Hayes

Hayes Communications introdujo una soluci´on en su Smartmodem 1981 mediante la reutili-zaci´on de los pines de datos existentes sin modificaciones. En cambio, el m´odem en si mismo podr´ıa cambiarse entre uno de dos modos:

Modo de datos en el que el m´odem env´ıa los datos al m´odem remoto. (Un m´odem en modo de datos trata todo lo que recibe de la computadora como datos y lo env´ıa a trav´es de la linea telef´onica)..

Modo de comandoen el que los datos se interpretan como comandos para el m´odem local (comandos que el m´odem local deber´ıa ejecutar).

Para pasar del modo de datos al modo de comando, las sesiones enviaron una cadena de secuencia de escape de tres signos mas (“+++”) seguida de una pausa de aproximadamente un segundo. La pausa al final de la secuencia de escape era necesaria para reducir el proble-ma causado por la se˜nalizaci´on dentro de banda: si se recib´ıa cualquier otro dato dentro de un segundo de los tres signos mas, no era la secuencia de escape y se enviar´ıa como datos. Para volver atr´as, enviaron el comando en linea, O. En el uso real, muchos de los comandos cambiaron autom´aticamente al modo en linea despu´es de su finalizaci´on, y es raro que un usuario use el comando en linea expl´ıcitamente.

5.2.2.

Comandos

El conjunto de comandos Hayes incluye comandos para varias manipulaciones de linea te-lef´onica, marcaci´on y colgado, por ejemplo. Tambi´en incluye varios controles para configurar el m´odem, incluido un conjunto de comandos de registro que permiten al usuario establecer directamente las diversas ubicaciones de memoria en el m´odem Hayes original. El conjunto de comandos fue copiado casi textualmente, incluyendo el significado de los registros, por casi todos los primeros fabricantes de 300 baudios, de los cuales hab´ıa bastantes.

La expansi´on a 1200 y 2400 baudios requiri´o la adici´on de un peque˜no conjunto de nuevos comandos, algunos de ellos con el prefijo ampersand (“&”) para designar aquellos dedica-dos a nuevas funcionalidades. Hayes se vio obligado a introducir r´apidamente un modelo de 2400 baudios poco despu´es de su 1200, y los conjuntos de comandos eran id´enticos a un me todo de ahorro de tiempo[8]. Esencialmente por accidente, esto permiti´o a los usuarios de los m´odems de 1200 baudios existentes utilizar los nuevos modelos Hayes 2400 sin cambiar su software. Esto reforz´o el uso de las versiones Hayes de estos comandos. A˜nos despu´es, la Asociaci´on de la Industria de Telecomunicaciones (TIA) / Alianza de Industrias Electr´ oni-cas (EIA) elevo el conjunto de comandos de 2400 baudios a un est´andar formal con el titulo Sistemas y equipos de transmisi´on de datos - Marcaci´on y control autom´aticos as´ıncronos en serie, TIA / EIA-602.

Sin embargo, Hayes Communications se movi´o solo lentamente hacia velocidades mas altas o el uso de compresi´on, y otras tres compa˜n´ıas lideraron el camino hasta aqu´ı: Microcom, U.S. Robotics y Telebit. Cada uno de estos tres utilizo sus propios conjuntos de comandos adicionales en lugar de esperar a que Hayes marcara el camino. A principios de la d´ecada de 1990, hab´ıa cuatro conjuntos principales de comandos en uso, y varias versiones basadas en uno de estos. Las cosas volvieron a ser mas simples durante la introducci´on generalizada de los m´odems de 14,4 y 28,8 kbit/s a principios de los a˜nos noventa. Poco a poco, un conjunto de comandos basados en gran medida en el conjunto extendido Hayes original utilizando los comandos “&”se hizo popular, y luego universal. Solo otro conjunto de comandos se ha mantenido popular, el conjunto de US Robotics de su popular linea de m´odems.

5.2.3.

Descripci´

on

El conjunto de comandos AT puede subdividirse en cuatro grupos:

Conjunto de comandos b´asicos: un car´acter de may´usculas seguido de un d´ıgito. Por ejemplo, M1.

Conjunto de comandos propietario - Generalmente comienza con una barra diagonal inversa (“\”) o con un signo de porcentaje (“ %”); estos comandos var´ıan ampliamente entre los fabricantes de m´odem.

Comandos de registro - Sr = n donde r es el n´umero del registro que se va a cambiar, y n es el nuevo valor que se le asigna.

Un registro representa una ubicaci´on f´ısica especifica en la memoria. Los m´odems tienen peque˜nas cantidades de memoria a bordo. El cuarto conjunto de comandos sirve para ingresar valores en un registro particular (ubicaci´on de la memoria). El registro almacenara un valor particular (informaci´on alfanum´erica) que el m´odem y el software de comunicaciones pueden utilizar. Por ejemplo, S7 = 60 instruye al m´odem a “Establecer el registro n.7 al valor de 60”. Aunque la sintaxis del conjunto de comandos define la mayor´ıa de los comandos mediante una combinaci´on de letras y n´umeros (L0, L1, etc.), el uso de un cero es opcional. En este ejemplo, “L0” equivale a una simple “L” [9].

5.2.4.

Definiciones sint´

acticas

Se aplican las siguientes definiciones sint´acticas:

<CR>Car´acter de retorno de carro, es la l´ınea de comando y el car´acter de terminaci´on del c´odigo de resultado, cuyo valor, en ASCII decimal entre 0 y 255, se especifica en el registro S3. El valor predeterminado es 13.

<LF>Car´acter de avance de linea, es el car´acter reconocido como car´acter de avance de linea. Su valor, en ASCII decimal entre 0 y 255, se especifica en el registro S4. El valor predeterminado es 10. El car´acter de avance de l´ınea se emite despu´es del car´acter de retorno de carro si se utilizan c´odigos de resultado 13 detallados (se usa la opci´on V1); de lo contrario, si se usan c´odigos de resultado de formato num´erico (se usa la opci´on V0), no aparecer´a en los c´odigos de resultado.

<...> El nombre entre corchetes angulares es un elemento sint´actico. No aparecen en la l´ınea de comando.

5.2.5.

Comandos AT para un m´

odem GSM

El ETSI GSM 07.07 (3GPP TS 27.007) especifica comandos de estilo AT para controlar un tel´efono o m´odem GSM. El ETSI GSM 07.05 (3GPP TS 27.005) especifica comandos de estilo AT para gestionar la funci´on del servicio de mensajes cortos (SMS) de GSM.

Ejemplos de comandos GSM:

Figura 5-2: Ejemplos comandos AT [11]

Los m´odems GSM / 3G soportan t´ıpicamente las extensiones de conjunto de comandos ETSI GSM 07.07 / 3GPP TS 27.007 AT, aunque la cantidad de comandos implementados varia.

5.2.6.

Ejemplo de sesi´

on

5.3.

ESTANDAR RS-232

5.3.1.

Historia

En la d´ecada de los a˜nos 60 la EIA desarrollo una interfaz com´un de comunicaci´on con el objetivo principal del intercambio de datos a trav´es de lineas telef´onicas de voz que por ende requer´ıan de un dispositivo traductor de se˜nales (an´alogo-digital y digital-an´alogo), el protocolo de la norma utiliza un modo as´ıncrono en el cual, el emisor y el receptor manejan su propio reloj, donde ambos deben tener la misma frecuencia. El est´andar se ha desarrollado por mas de cuarenta (40) a˜nos durante los cuales la EIA ha publicado tres (3) modificaciones, la mas reciente llamada EIA-232F introducida en 1997. El nombre del est´andar paso de RS-232 a EIA-232 al igual que otros elementos de la norma original han cambiado su denominaci´on. Los diferentes para metros de la transmisi´on son programables, un caso es la velocidad que puede variar entre 50 y 19.200 baudios[15].

5.3.2.

Caracter´ısticas de la se˜

nal el´

ectrica

La conexi´on RS-232-C define su propio entorno el´ectrico, el cual utiliza el rango -15 a +15 voltios.

Tensiones en las lineas

La conexi´on serie RS-232-C utiliza varias lineas para realizar la comunicaci´on. Unas lineas son entradas y otras son salidas. No existen lineas bidireccionales, por tanto las conexiones entre las lineas siempre han de ir de una entrada a una salida. Las lineas que son entradas tienen una tensi´on pr´acticamente cero frente la patilla de tierra, aunque no todas las lineas que tengan tensi´on cero son entradas, ya que las lineas no utilizadas (sin conectar) tambi´en tienen tensi´on cero. Las lineas de salida pueden ser de dos tipos, bien de transmisi´on o bien de control de la comunicaci´on. Ambas se caracterizan por tener tensi´on diferente de cero. La linea de transmisi´on esta normalmente a tensi´on negativa, cuando no transmite. Las lineas de control pueden estar tanto a tensi´on negativa como positiva[16].

Niveles l´ogicos

de tensiones de -15 a +15 voltios, en vez del habitual de +5 a 0 voltios, que habr´ıa dado menos margen de tolerancia.

Margen de ruidos

Se conoce como margen de ruido a la amplitud m´axima de la perturbaci´on que puede pro-ducirse en la salida de una se˜nal sin que afecte en la entrada del siguiente circuito. Para medir este para metro se toma el caso mas desfavorable. En la conexi´on serie RS-232-C, el caso mas desfavorable se dar´ıa cuando la salida esta emitiendo con el valor mas critico, que es 5 voltios (un “0”). Como la entrada lee un “0” hasta 3 voltios, entonces el margen de ruido para esta conexi´on es de 2 voltios. Esto quiere decir que es inmune a ruidos de 2 voltios, e incluso mayores en los casos mas normales de utilizaci´on. Esta caracter´ıstica es extremadamente valiosa cuando los cables han de pasar cerca de dispositivos que generan in-terferencias el´ectricas: lineas de alta tensi´on, motores el´ectricos, alumbrado fluorescente etc. Adem´as, el margen de ruido tambi´en da un margen de seguridad frente a ca´ıdas de voltaje por la resistencia ´ohmnica del cable, aunque estas en general no suelen ser significativas[17].

Longitud de la linea de transmisi´on

La EIA (Asociaci´on de Industrias Electr´onicas) recomienda que la capacidad total del cable no exceda los 2500 picofaradios. Como los cables de transmisi´on de datos tienen un valor de entre 120 a 150 picofaradios por metro, entonces 150 metros seria la longitud m´axima que podr´ıa tener. Sin embargo, tal vez nos sea mas ´util el siguiente experimento realizado por Joe Campbell, un experto en comunicaciones serie y autor de numerosos libros sobre el tema. Para realizar la experiencia, se utilizaron rollos de cable de 80 metros sin apantallar,del tipo 22 AWG, que se iban empalmando para formar el cable de la longitud deseada, el cual conectaba la puerta serie RS-232-C de dos ordenadores convencionales. En uno de ellos se ejecuto un programa simple que transmit´ıa la letra “U” y el otro ordenador la recib´ıa y detectaba si hab´ıa habido alg´un error. Se eligi´o la letra “U” porque tiene el c´odigo ASCII “01010101”, que al tener bits alternativos es el que mas frecuencia puede dar.

Orden de los bits en la linea

El orden de transmisi´on de los bits por la linea es el siguiente: se comienza con el bit de start que siempre es un “0”, luego se transmite el menos significativo (el que esta mas a la derecha) y as´ı sucesivamente hasta llegar al mas significativo (el que esta mas a la izquierda). Despu´es va el bit de paridad en el caso de que se utilice, y por ultimo los bits de stop, que pueden ser 1, 1.5 o 2. El valor 1.5 indica que la linea toma el valor “1” durante un periodo y medio de un bit de tiempo. En la figura se presenta la transmisi´on de la letra “w” cuyo c´odigo ASCII es 87 y en binario “01010111”. Se utiliza paridad par y un bit de stop[17].

Figura 5-5: Transmisi´on bits letra W.

5.3.3.

Caracter´ısticas mec´

anicas

La comunicaci´on serial mediante el est´andar RS-232 puede ser directa cuando se realiza sobre banda base digital y/o mediante un m´odem cuando la transmisi´on se realiza en banda base an´aloga modulando la portadora. Cuando se transmite a trav´es de un m´odem la norma define un conjunto de 22 se˜nales divididas en se˜nal de datos y se˜nal de control distribuidas en un conector de tipo D de 25 terminales, sin embargo, no todas las se˜nales de control son imprescindibles para establecer la comunicaci´on entre dos equipos, es por eso que en muchas ocasiones se utiliza un conector macho tipo D de 9 terminales [18]. La versi´on europea se regula bajo la norma CCITT V.24 y se especifica para una distancia m´axima del enlace de 15 m y una velocidad de transmisi´on de m´aximo 20 Kbps [19]. Los tipos de se˜nales de la especificaci´on RS-232 (CCITT V.24) son los siguientes:

Masa: GND para aislamiento del conector con enlace al chasis de la terminal; SG Se˜nal sobre la que se establece la tensi´on de las dem´as se˜nales del conector.

Canal Principal: Conjunto de se˜nales de datos y control, TxD y RxD lineas de trans-misi´on y recepci´on respectivamente; RTS, CTS, DSR y DCD se˜nales b´asicas, DTR y RI se˜nales conmutadas y SQ, CH y CI se˜nales de calidad y canales.

Terminales sin Asignaci´on Fija: para utilizarse por aplicaci´on formando dos (2) bucles de corriente en caso de ser requeridas [20].

En la Figura 4. se ilustra un conector D de 9 terminales con especificaci´on de se˜nales por terminal para comunicar dos sistemas [21].

Figura 5-6: Conector D 9 terminales.W.

5.3.4.

Cableados t´ıpicos para el RS-232

A pesar de la gran difusi´on de la norma RS-232-C no existe un ´unico modelo est´andar de cable que permita la interconexi´on de dos dispositivos RS-232-C cualquiera, sino que varia dependiendo de dos factores:

El genero de dispositivo. Si se trata de dos dispositivos de distinto genero la conexi´on es la natural, es decir se conectan entre si la patillas con el mismo n´umero. Sin embargo si el genero es el mismo es necesario intercambiar algunas patillas con el fin de mantener las entradas unidas con las salidas.

Adem´as de estos factores hay una complicaci´on adicional, las lineas auxiliares de control no tienen, como ya se menciono , ning´un efecto sobre el hardware que realiza la comunicaci´on, sino que el software debe regular esta de acuerdo con el estado de dichas lineas. Esta libertad ha llevado a muchos fabricantes a emplear estas lineas de control para prop´ositos distintos a los que se se˜nalan en la norma RS-232-C. La conexi´on natural del est´andar RS-232-C es entre un DTE, por ejemplo un PC, y un DCE, como un m´odem. Si el control de flujo es por hardware las se˜nales de control cobran mayor importancia. El m´odem debe saber si el PC esta listo antes de contestar autom´aticamente a una llamada, y el PC debe saber si el m´odem esta encendido y si esta recibiendo la se˜nal de transmisi´on del sistema remoto. La forma adecuada de unir un DTE con un DCE es conectar los pines cuyos n´umeros son iguales, es decir el 1 del DTE con el 1 del DCE, el 2 con el 2... y as´ı hasta la linea 25. En el caso de que la conexi´on sea so lo as´ıncrona, basta con conectar las nueve lineas que son necesarias (2, 3, 4, 5, 6, 7, 8, 20 y 22). Si adem´as el control de flujo de datos entre el DTE y el DCE se realiza mediante software (utilizando un protocolo como el Hayes para los m´odems) solo es necesario unir tres lineas (2, 3, y 7) ya que las utilizadas para el control de flujo por hardware ya no serian necesarias[22].

Figura 5-7: Cableado RS-232

Figura 5-8: Conexi´on dos DTE

Un cable de tres hilos es suficiente, y funcionara con la mayor´ıa de los programas (los que emplean control de flujo de la comunicaci´on software), pero no con todos. Algunos programas inspeccionan las lineas CTS, DSR y DCD y no funcionara n a no ser que alguna o todas estas se˜nales sean 0 l´ogico u ON (control de flujo hardware). No obstante se puede enga˜nar al programa conectando adecuadamente entre si las lineas de control de los dos DTE. Existen muchos ejemplos de estos tipos de cableados, dependiendo normalmente su configuraci´on del software de comunicaciones empleado. Se observa que en las configuraciones anteriores se conectan las lineas del mismo n´umero en dispositivos con distinto genero, mientras que si son del mismo genero las patillas 2 y 3 han de cruzarse, as´ı como algunas lineas de control si es necesario. En el caso de conexi´on de dos DCE, por ejemplo dos m´odems, se realizara la conexi´on interconectando las lineas 2 con la 3 de ambos equipos como en el caso de m´odem nulo. El resto de las lineas de control han de conectarse de forma que se unan las se˜nales complementarias[17].

5.4.

SENSOR DE TEMPERATURA (LM35)

La serie LM35 es un circuito integrado de precisi´on de temperatura con una tensi´on de salida lineal proporcional a la temperatura cent´ıgrado. El dispositivo tiene una ventaja sobre los sensores de temperatura lineal calibrados en Kelvin, como el usuario no esta obligado a res-tar una tensi´on constante grande de la salida para obtener la escala cent´ıgrado conveniente. El dispositivo LM35 no requiere ninguna calibraci´on o recorte externo para proporcionar exactitudes t´ıpicas de± 1

4

o_{C a temperatura ambiente y±} 3 4

o_{C en un rango de temperatura} completo de -55 o_{C a 150} o_{C [27].}

5.5.

VENTILADOR NMB 1004KL-01W-B30

Este actuador fabricado por NMB Technologies hace parte de la categor´ıa de ventiladores tangenciales de corriente continua, las dimensiones del marco son 25 mm Lx10mm W x 25 mm H,el voltaje de alimentaci´on en plena operaci´on es de 5V de corriente directa, Corriente de 0,065 A, potencia de 0.33W, cuenta con una circulaci´on de 1,2 pies c´ubicos por minuto y un peso de 7,5 gramos adem´as que esta fabricado con pl´astico negro [28].

Figura 5-9: Dimensiones del ventilador nmb 1004KL-01W-B30. [28]

5.6.

DIAGRAMA DE BLOQUES

El sistema esta compuesto en dos partes, la primera consta de un computador conectado a un modulo GSM mediante el puerto RS-232 el cual sera el encargado de mediante una in-terfaz gr´afica de usuario recibir y enviar mensajes de texto SMS mediante los comandos AT para controlar remotamente el estado (on/off) de un actuador que a su vez esta conectado a otro modulo GSM que se encarga de recibir y enviar mensajes de texto dependiendo de las condiciones del sistemas medidas por el sensor.

Figura 5-11: Diagramas de bloques del sistema.[23]

5.7.

ANTECEDENTES

A continuaci´on, se muestran tres proyectos en los cuales se utilizaron diferentes m´etodos para hacer la comunicaci´on punto a punto usando comunicaci´on m´ovil GSM para ciertos sistemas de control.

La selecci´on de estos art´ıculos se hizo en base a las similitudes que tienen respecto a es-te proyecto para poder evidenciar las facilidades y complicaciones que se tuvieron, as´ı como sentar una base respecto a los alcances y limitaciones.

Comunicaci´on punto a punto v´ıa M´odem GSM

esto se opto por usar el servicio de mensajes cortos (SMS). Para la metodolog´ıa de envi´o y recepci´on de diferentes tramas se implemento el uso de Comandos AT correspondientes a cada instrucci´on a ejecutar mas los diferentes caracteres de control.

Posteriormente trataron las respuestas que el m´odem enviaba tras recibir las instrucciones conforme a los resultados esperados, como dichas respuestas vienen en diferentes formatos se realizo un tratamiento especial a cada respuesta. La interacci´on con el m´odem se realizo mediante el puerto serie (RS232). Para la implementaci´on de la comunicaci´on se desarrollo una interfaz gr´afica mediante VISUAL BASIC, en el cual el usuario a partir de los diferentes controles empleados puede ejecutar los diferentes sistemas de comunicaci´on sin necesidad de conocer el funcionamiento de los comandos AT. Tras la implementaci´on concluyen que la aplicaci´on del proyecto puede ser empleada en el control remoto de procesos, tanto a nivel inform´atico como a nivel de actuaci´on o en el seguimiento peri´odico de una serie de datos que pueda ser brindados por un sensor que capta desde alg´un lugar donde no exista una red telef´onica convencional [24].

Sistema de control de temperatura a de arduino y la tecnolog´ıa GPRS/GSM

Como proyecto de grado en la Escuela T´ecnica Superior de Ingenier´ıa y Sistemas de Te-lecomunicaci´on en Madrid se desarrollo un sistema de control de temperatura a trav´es de arduino y GPRS. Se tuvieron en cuenta dos fases, la primera fue el dise˜no de una plataforma para el control de la temperatura de modo local con el apoyo de un PC y el envi´o/recepci´on de SMS para el control de todo el sistema y una segunda fase en la cual se integrara una aplicaci´on android para llevar a cabo la gesti´on de funcionalidad.

Sistema de control y supervisi´on remota basada en telefon´ıa m´ovil GSM

El departamento de ingenier´ıa electr´onica de la Universidad Polit´ecnica de Catalunya desa-rrollo un sistema de control y supervisi´on remota basada en telefon´ıa m´ovil GSM mediante el envi´o y recepci´on de mensajes cortos de textos SMS los cuales pod´ıa ser redireccionados a distintos n´umeros de tel´efono seg´un los protocolos establecidos por la aplicaci´on, mediante el uso de PLC (controlador l´ogico programable) se generan alarmas o respuestas a demandas de informaci´on desde el operador. Para la implementaci´on del sistema se uso : PLC, m´odem GSM, tel´efono un PC para realizar la programaci´on y puesta a punto de todos los elementos.

6.1.

Fase 1 - Identificaci´

on del sistema GSM y los

comandos AT

6.1.1.

Sistema GSM

Para el desarrollo de esta fase se inicia hacienda la investigaci´on de los principales operadores m´oviles presentes en Colombia que usan el Sistema GSM, teniendo en cuenta la frecuencia de operaci´on y los servicios prestados sobre la misma, a partir de esto se encontraron los siguientes resultados.

Figura 6-1: Frecuencia operaci´on est´andar GSM para operadores m´oviles . [29][30]

Al momento de decidir que operador m´ovil se usara para el desarrollo del prototipo se debe tener en cuenta la cantidad de usuarios que tiene cada operador puesto que esto puede ser un ´ındice de calidad de servicio y as´ı mismo la capacidad que tiene el operador para prestar los servicios requeridos en este caso el servicio de mensajer´ıa. Para el t´ermino del segundo trimestre de 2018, el n´umero de abonados en el servicio de telefon´ıa m´ovil en Colombia alcanz´o un total de 62.912.914, la distribuci´on de acuerdo a los operadores que usan el est´andar GSM se encuentra as´ı:

Otro aspecto relevante es el nivel de cobertura que puede brindar los operadores dado que el prototipo puede ser empleado en cualquier regi´on del pa´ıs, de acuerdo a un mapa de cobertura de la red m´ovil, el cual tiene en cuenta los principales operadores se pude notar que el operador que posee mayor cobertura es Claro seguido por movistar.

Figura 6-3: Cobertura operadores m´oviles. [31]

6.1.2.

Comandos AT

Para realizar la configuraci´on y el envi´o de mensajes de texto se requiere el uso de comandos AT, en este caso se deben usar en especifico los comandos extendidos GSM AT los cuales comienzan por “+”. Se debe tener en cuenta que el inicio de “AT” es el prefijo que informa al modem sobre el inicio de una l´ınea de comando. De acuerdo con la investigaci´on son requeridos cuatro comandos con el fin de enviar y recibir mensajes los cuales son:

AT

AT

El es mas simple de los comandos, sin embargo es uno de los mas importantes cuando se estan empleando modulos externos. Su funci´on es verificar el estado del modulo, si este esta funcionando bien va a obtener una respuesta “OK” necesaria para seguir con al configuraci´on del modulo.[33]

AT+CMGF

El comando AT + CMGF (command name in text: Message Format) se usa para seleccionar el modo de operaci´on del m´odem GSM o del tel´efono m´ovil. Requiere la asignaci´on de par´ametro que puede tomar los valores de 0 y 1. Si el valor del par´ametro es 0 se usara el modo SMS PDU en el cual solo se env´ıan valores num´ericos mientras que si es 1 que se configura el modo de texto SMS lo cual permitir´a el uso de cadenas de texto.. Si este no es configurado por defecto implementara el valor 0. [33]

AT+CMGS

El comando AT + CMGS (command name in text: Send Message) se usa configurar el numero destinatario del mensaje de texto a enviar. Este comando tambi´en cuenta con la ventaja que toma puede tomar el mensaje SMS como un par´ametro. Se debe tener en cuenta que para poder usar este comando antes debe haberse configurado AT + CMGF con un valor de 1. [33]

AT+CNMI

El comando AT + CNMI (command name in text: New Message Indications) se utiliza para especificar c´omo deben manejarse los mensajes SMS reci´en llegados. Puede indicar al m´odem GSM o al tel´efono m´ovil que reenv´ıe los mensajes SMS reci´en llegados directamente a la PC, o guardarlos en el almacenamiento de mensajes y luego notificar a la PC su ubicaci´on en el almacenamiento de mensajes. Para el desarrollo de el prototipo como es necesario ver los mensajes recibidos por serial se debe configurar AT+CNMI=2,2,0,0,0. [32][33]

+CIEV

6.2.

Fase 2 - Selecci´

on y prueba del modulo para la

comunicaci´

on de equipos

El objetivo de esta fase es realizar la investigaci´on y selecci´on en primera medida del modulo con capacidad para envi´o y recepci´on de mensajes de texto, este modulo debe cumplir con ciertas caracter´ısticas.

Capacidad de ser controlado por comandos AT. Comunicaci´on serial a trav´es del Puerto UART. Dispositivo de bajo consumo.

En esta etapa se realizar´an las primeras pruebas de configuraci´on para envi´o y recepci´on de mensajes de texto.

Microcontrolador

Se debe tener un microcontrolador el cual estar´a encargado de la configuraci´on del modulo enviando los comandos AT por comunicaci´on serial a trav´es de UART, as´ı mismo este debe ser capaz de interpretar los mensajes recibidos y realizar las respectivas acciones.Se decidi´o usar la PSoC CY8C5888LTI-LPO97, el cual es un sistema que ofrece novedosas capacidades integradas en un solo chip, con un moderno m´etodo de adquisici´on, procesamiento y control de se˜nales y una excelente precisi´on.

Los dispositivos PSoC integran circuitos digitales y anal´ogicos configurables, controlados por un microcontrolador interno, de modo que proveen tanto una capacidad mejorada para la revisi´on de los dise˜nos como la disminuci´on del n´umero de componentes usados. Dentro de las caracter´ısticas necesarias para el desarrollo del prototipo el psoc cuenta con m´odulos UART as´ı como de conversores anal´ogicos digitales de 12 bits.

Modulo A6

Es un m´odulo de comunicaci´on GSM/GPRS que tiene la capacidad de enviar y recibir SMS, datos GPRS y llamadas telef´onicas, cuenta con la ventaja que es compatible con cualquier plataforma de desarrollo de microcontroladores. Se comunica con el microcontrolador a trav´es del puerto UART. Este permite mediante comandos AT configurar la comunicaci´on de datos v´ıa remota desde cualquier punto con se˜nal GSM.

Entre las especificaciones principales se tiene:

Voltaje de funcionamiento: 4.5 5.5V DC. Temperatura de operaci´on: -30oC a 80oC.

Figura 6-4: PSoC CY8C5888LTI-LPO97.

6.2.1.

Prueba configuraci´

on y envi´

o de mensaje

Para realizar la comunicaci´on entre el modulo A6 con la PSoC, se usara el software PSoC Creator en su versi´on 4.2, una ventaja de usar este IDE es que permite el uso de bloques de los elementos necesarios as´ı como un f´acil manejo y configuraci´on de los pines a usar. Lo primero que se debe realizar debe ser la configuraci´on de los bloques necesarios en la PSoC, en este caso el ´unico necesario es el bloque UART el cual proporciona comunicaciones as´ıncronas com´unmente denominadas RS232, necesarias para la comunicaci´on con el m´odulo GSM A6. Este bloque se debe configurar para que pueda trabajar de manera bidireccional es decir que funcione como transmisor y receptor, otra configuraci´on importante es la tasa de bits la cual se le da una valor 9600 bps. Seguido a esto se le deben asignar una interrupci´on en el receptor para que cada vez que detecte alg´un dato este pueda ser manejado.

Figura 6-6: Bloque UART.

Figura 6-7: Configuraci´on y envi´o mensaje PSoC creator.

Para verificar las repuesta del parte del modulo en cuanto al estado y el envi´o del mensaje se uso el software HTerm el cual permite conectarse al puerto serial para verificar en el transmisor del modulo A6 como se puede ver a continuaci´on:

Figura 6-8: Envi´o del mensaje usando modulo A6 .

Como se puede apreciar, al momento de hacer la configuraci´on del modulo A6 usando los comandos “AT” y “AT+CMGF=1”, este responde a ambos comandos con un “OK”, si el modulo llegase a enviar alguna respuesta diferente la configuraci´on seria defectuosa y el men-saje no podr´ıa ser enviado.

Figura 6-9: Recepci´on en dispositivo m´ovil y envi´o de respuesta.

Figura 6-10: Recepci´on del mensaje usando el modulo A6.

6.3.

Fase 3 - Selecci´

on y prueba del sensor y/o actuador

6.3.1.

Sensor Temperatura

Para la selecci´on del sensor de temperatura se debe tener en cuenta que sea un dispositivo de precisi´on con bajo consumo, dado esto se opto por usar el LM35, circuito integrado de precisi´on que act´ua como un sensor de temperatura calibrado directamente en grados cent´ıgrados que a diferencia de otros dispositivos como los termistores en los que la medici´on de temperatura se obtiene de la medici´on de su resistencia el´ectrica el LM35 es un integrado con su propio circuito de control que proporciona una salida de voltaje proporcional de 10 mV por cada grado cent´ıgrado medido. Una de las ventajas que posee es la facilidad con la que puede medir la temperatura dado que no es necesario de microcontrolador para medir la temperatura dado que es un sensor anal´ogico basta con medir a la salida del sensor.

Figura 6-11: Sensor de temperatura LM35.

6.3.2.

Actuador-Ventilador

Para la implementaci´on de el prototipo se utilizara como actuador un ventilador, este debe tener como caracter´ıstica principal ser un elemento de bajo consumo el cual pueda trabajar con 5V dado que la alimentaci´on de este depender´a de la PSoC y esta solo puede brindar este voltaje. Dada esta condici´on se opta usar el ventilador NMB 1004KL-01W-B30, el cual posee dimensiones que de adaptan perfecto al prototipo.

6.3.3.

Prueba Sensor LM35 y ventilador

documentaci´on de CYPRESS que recomienda este valor cuando se est´an usando sensores de precisi´on. Para el uso de la LCD solo se debe seleccionar el bloque respectivo el cual no debe ser configurado. Dado que se necesitan acoplar impedancias se debe usar un amplificador operacional en modo seguidor, PSoC creator nos permite usar un bloque para esto evitando la implementaci´on f´ısica del seguidor.Se deben utilizar don pines, uno an´alogo para la entrada del sensor y el otro como una salida digital para activar el actuador.

Figura 6-12: Bloques implementaci´on sensor temperatura.

En cuanto a la codificaci´on para la medici´on y posterior visualizaci´on de la temperatura lo primero a realizar se debe inicializar la conversi´on del ADC y posteriormente guardar en una variable los resultados que ha obtenido del sensor LM35. A esta variable que almacena continuamente el valor se le debe realizar la conversi´on de su valor entero a milivoltios una vez convertido se podr´a dividir sobre 10 mV para obtener la respectiva temperatura medida.

Para poder visualizarla en la LCD se debe realizar la conversi´on de la variable en donde se realizo la conversi´on de la temperatura a char para poder posteriormente imprimirla. El resultado de esto se puede ver a continuaci´on:

Figura 6-14: Visualizaci´on LCD temperatura medida.

Para probar el correcto funcionamiento del ventilador, se agrega una condicional en la cual si la temperatura supera los 28oC se activara el pin digital asignado a este. Para poder obtener la corriente necesaria para encenderlo se debe utilizar un transistor en configuraci´on de emisor com´un con una resistencia de base 330 Ω para amplificar la corriente que provee el puerto digital.

6.4.

Fase 4 - Desarrollo de una interfaz gr´

afica de control

para actuadores y/o sensores gen´

ericos

Se dise˜na una interfaz gr´afica de usuario para el control de sensores y actuadores gen´ericos y en caso de la implementaci´on especifica del proyecto descrito en este documento, el control de un sensor de temperatura LM35 y un ventilador.

El lenguaje de programaci´on utilizado para el desarrollo de dicha interfaz es C# dada su flexibilidad para manejar el componente de comunicaci´on (UART) utilizado para enviar y recibir datos provenientes del controlador.

La interfaz gr´afica cuenta con los siguientes componentes:

1 Formulario 2 Combo Box 3 Botones

Figura 6-16: Dise˜no de la interfaz de usuario en C Sharp.

La interfaz gr´afica cuenta con un bot´on de encender y apagar, este bot´on se encarga de escribir en el puerto serial un dato para que el controlador escriba el comando AT en el m´odulo A6 y sea enviado un mensaje de encender o apagar. El texto de este bot´on cambia de acuerdo a un click, es decir si el texto se encuentra en “encender” y el usuario da click, inmediatamente el texto es cambiado a “apagar” de igual manera si el usuario da click de nuevo el texto regresa a ser “encender”.

A continuaci´on se explicar´a el c´odigo fuente desarrollado en la herramienta Visual Studio Community 2017:

Comenzando es necesario importar las librer´ıas necesarias para el correcto funcionamien-to de los elemenfuncionamien-tos que hacen parte de la interfaz de usuario, resaltando la importancia de la libre IO.Ports que permite utilizar el puerto serial de la m´aquina que desplegar´a la aplicaci´on.

Figura 6-17: Importar Librer´ıa IO.Ports.

Figura 6-18: Programaci´on de interrupci´on.

Se programa el evento click del bot´on para buscar puertos; la aplicaci´on se encarga de buscar los puertos que est´an disponibles para realizar la conexi´on en la m´aquina en la cual es desplegada, a trav´es de la funci´on GetPortNames. Los puertos disponibles al momento de hacer click en el bot´on son guardados en un Combobox y de esta manera la aplicaci´on permite escoger el puerto para realizar la conexi´on. En el c´odigo se valida el n´umero de puertos encontrados y en caso de que este n´umero sea igual a cero, la aplicaci´on advertir´a que no existen puertos disponibles para la conexi´on.

Se programa el evento click del bot´on “Conectar”, la aplicaci´on configura la conexi´on con sus par´ametros tales como BaudRate, Bits, Paridad, Bits de parada, Handsahke y el nombre del puerto al cual se conectar´a la aplicaci´on que es tomado de el ComboBox de puertos. Una vez la conexi´on es exitosa el texto de este bot´on es cambiado a “desconectar” y al realizar click en el bot´on “desconectar” la aplicaci´on cierra la conexi´on al puerto y el texto del bot´on es cambiado nuevamente a “conectar”. Las excepciones son manejadas por c´odigo en un try catch que en caso de ocurrir alg´un error en el proceso se encargar´a de emitir una alerta en el aplicativo con el mensaje de error correspondiente.

Figura 6-20: Programaci´on de botones conectar y desconectar.

Figura 6-21: Programaci´on bot´on encender.

Finalmente se programa el m´etodo DatoRecibido que se ejecuta mediante la interrupci´on, este m´etodo se encarga de leer la variable strBufferIn y de acuerdo al texto que tenga el btnEncender se muestra alerta de aumento de temperatura o regulaci´on de la temperatura. De esta manera el usuario ser´a notificado de cualquier cambio de temperatura abrupto y cuando sea regulada nuevamente.

6.5.

Fase 5 - Implementaci´

on y pruebas

El objetivo de esta fase se divide en varias partes: la primera es realizar la integraci´on de el envi´o de mensaje como alertas cuando la temperatura llegue a un valor predeterminado, la segunda parte es realizar pruebas a la interfaz gr´afica y su comunicaci´on con la PSoC. La tercera es realizar diferentes pruebas al prototipo como la comunicaci´on entre m´odulos usando la interfaz gr´afica y el tiempo de recepci´on de mensajes de texto desde diferentes operadores m´oviles.

6.5.1.

Interacci´

on elementos software y hardware

En primer medida, se hace la integraci´on de las fases 2 y 3, con el fin de enlazar la medici´on de la temperatura junto con el env´ıo de mensajes de texto usando el modulo A6. Para implementar esta, se realiza la uni´on de los bloques correspondientes a cada componente, usados en la PSoC, de ambas fases junto con la entrada anal´ogica y la salida digital, todo esto se observa a continuaci´on:

Figura 6-24: Integraci´on componentes fase 2 y 3.

Se debe agregar una interrupci´on, para que cuando el m´odulo reciba un mensaje de texto con cierto car´acter realice el encendido y apagado del actuador, por lo tanto se decidi´o usar caracteres, como los elementos que recibe el m´odulo, dado que PSoC Creator brinda el m´etodo GetChar para recibirlos y para una cadena de String no se tiene un m´etodo definido. Se usan condicionales en los cuales, cuando se reciba una “X” por parte del m´odulo conectado al PC o por parte del m´ovil del usuario, se encender´a el actuador activando el puerto digital de salida, y si se recibe una “Y” se desactivara el puerto digital apagando el actuador.

6.5.2.

Pruebas interfaz gr´

afica y conexi´

on con PSoC

Se realizaron pruebas de la interfaz gr´afica con ayuda de el software Hterm y VSPE. Con VSPE se logra simular una conexi´on al puerto serial de la m´aquina d´onde es desplegada la interfaz gr´afica.

Como primer paso en la interfaz gr´afica se da click en el bot´on buscar puertos para ele-gir el puerto al que se va a conectar la interfaz, en caso de no encontrar ning´un puerto disponible, la aplicaci´on mostrar´a un mensaje de alerta c´omo se muestra a continuaci´on.

Figura 6-26: Ning´un puerto detectado.

los puertos que se encuentren disponibles en el momento de hacer la b´usqueda se listan en un ComboBox y el bot´on encender se encuentra deshabilitado hasta que no se realice la conexi´on exitosa a alg´un puerto serial, inmediatamente despu´es de conectarse a un puerto serial se habilita el bot´on encender.

Figura 6-27: Lista de puertos.

Figura 6-28: Click en bot´on encender.

De igual manera si el usuario da click en el bot´on apagar se debe escribir la letra “Y” en el puerto serial conectado y el texto del bot´on volver´a a ser encender.

Figura 6-29: Click en bot´on apagar.

Para realizar pruebas de interrupci´on y alertas se debe escribir la letra “T” en el puerto serial conectado, el software Hterm nos permite escribir en el puerto simulado. El mensaje de alerta depende el texto en el que se encuentre el bot´on para encender y apagar.

Si llega una “T” y el texto en el bot´on es encender se muestra la siguiente alerta.

Figura 6-30: Interrupci´on para la subida de temperatura.

Figura 6-31: Interrupci´on para la bajada de temperatura.

Despu´es de verificar el correcto funcionamiento de la interfaz gr´afica se debe conectar el aplicativo al controlador PSoC, se decidi´o hacer esta conexi´on mediante un m´odulo UART conectado al puerto serial de la m´aquina d´onde se desplegar´a el aplicativo.

Figura 6-32: Esquema para el manejo de dos UART.

Se configura una interrupci´on en el terminal receptor del m´odulo UART de la PSOC, dentro de esta interrupci´on se valida si el dato que recibe del serial es la letra “X” o la letra “Y” (as´ı el sistema interpretar´a si debe apagar o encender el ventilador), para la comunicaci´on con el m´odulo A6 se configura otro m´odulo UART este ser´a el encargado de enviar los comandos AT al m´odulo A6 para que sea posible el env´ıo y la recepci´on de mensajes.

m´aquina, debido a que un m´odulo UART puede recibir datos de varias fuentes pero enviar a una sola a la vez.

De esta manera cuando la interrupci´on del UART conectado al puerto serial de la m´aquina sea activada, esta se encargar´a de escribir los comandos AT en el UART conectado al m´odulo A6 y este env´ıa el mensaje de texto de encendido y apagado seg´un sea el caso.

Por ultimo se configura una interrupci´on en el puerto receptor del UART conectado al m´odulo para encender un LED que hace la labor de testigo en caso de que el m´odulo reciba un mensaje de texto con la letra “Z” y escribe en el UART conectado a la m´aquina la letra “T” para que sea mostrada la alerta en la interfaz gr´afica.

Figura 6-33: Recepci´on de alerta.

6.5.3.

Prueba tiempos recepci´

on mensajes.

La primera prueba realizada es la medici´on del tiempo que tarda en llegar la alerta cuando la temperatura llega a una temperatura de 35o_{C, en este momento se env´ıa un mensaje de}

texto al modulo conectado al PC. Para esta prueba se tiene en cuenta el uso de diferentes operadores con el fin de verificar el funcionamiento del modulo bajo las diferentes frecuencias en las que trabajan los operadores. Para cada operador se realizaron tres mediciones como se ve a continuaci´on:

Figura 6-34: Resultados tiempo recepci´on mensaje alerta en PC.

Igualmente se realizo la medici´on del tiempo que tarde la recepci´on del mensaje cuando fue enviado desde el modulo conectado al PC al modulo desde donde se esta realizando la medici´on de temperatura, desde la interfaz gr´afica se env´ıa la orden para encender y apagar el actuador igualmente usando diferentes operadores.

Figura 6-35: Resultados tiempo recepci´on mensaje activaci´on actuador.

Dado que el usuario puede enviar al modulo mensajes de texto como respuesta para en-cender o apagar el actuador, se realizaron pruebas en los cuales desde dispositivos m´oviles se enviaban mensajes al modulo donde se mide la temperatura, de acuerdo a las pruebas anteriores los operadores Claro y Movistar est´an en la capacidad de enviar y recibir mensajes usando el modulo A6, es por esto que se tomo la determinaci´on de usar el operador Claro como receptor. Para estas pruebas se tiene en cuenta la ubicaci´on del emisor para tener un estimado en distancia y tiempo de llegada al receptor.

Figura 6-36: Resultados tiempo recepci´on mensaje enviado desde dispositivo m´ovil.

Es de apreciar que la recepci´on de mensaje por parte del modulo A6 no tiene problema si el emisor es de cualquier operador, el ´unico inconveniente se presenta al tratar de usar un operador diferente a Claro o Movistar como operador receptor.

6.5.4.

Operaci´

on completa del prototipo.

Como preparaci´on para el m´odulo conectado a la interfaz gr´afica, se debe conectar el pro-gramador del controlador PSoC a los puertos definidos para el UART que va a leer y enviar datos desde y hacia la interfaz.

Una vez conectado el circuito que se encarga de prender y apagar el ventilador remotamente, se hace una prueba enviando un mensaje a un tel´efono celular y de esta manera verificar que el m´odulo est´a listo para enviar y recibir mensajes.

Se conecta la interfaz gr´afica al puerto serial que utiliza el controlador PSoC, en el caso de la m´aquina que se utiliz´o para realizar la prueba, el puerto serial es el COM3 (esto depende del puerto donde sea conectado el PSoC). Inmediatamente despu´es de conectarse al puerto, se debe habilitar el bot´on de encendido.

Figura 6-38: Circuito de conexi´on interfaz gr´afica.

El m´odulo y la interfaz ya se encuentran conectados a la espera de que sean enviadas las alertas de temperatura desde el otro dispositivo. El prototipo inicia la medici´on de la tempe-ratura ambiente mostrando su valor en la LCD, se ha definido un valor de tempetempe-ratura de 35 en la cual se enviaran las alertas al usuario y al modulo del PC. Al aumentar la temperatura este cambio se vera reflejado en la LCD, hasta que llega al valor determinado para la alerta, en este momento el mensaje de la LCD cambiara e indicara que se enviara la alerta del aumento de temperatura. Esta enviara dos mensajes de texto con lan letra “Z” al modulo conectado al PC con el fin de asegurar de que este llegue exitosamente, al m´ovil del usuario se enviara solo un mensaje indic´andole que la temperatura ha aumentado.

Figura 6-40: Alerta LCD aumento temperatura.

Figura 6-41: Mensaje enviado m´ovil del usuario por aumento temperatura.

Una vez llega el mensaje de texto al m´odulo se enciende un LED testigo durante 3 segundos y se muestra la alerta en la pantalla del computador d´onde se despliega la aplicaci´on.

Figura 6-42: LED amarillo testigo que muestra que la alerta lleg´o correctamente.

bot´on por 3 segundos y el m´odulo se encarga de enviar el mensaje con la se˜nal de encendido de ventilador, se˜nal que se defini´o como la letra “X”.

Figura 6-43: LED verde testigo que muestra que la instrucci´on de encendido lleg´o correctamente.

Al llegar el mensaje de texto al dispositivo donde se mide la temperatura se enciende un testigo y se muestra el mensaje “VENTILADOR-ON” en la LCD, en este momento se activa la salida digital activando el circuito presentado en la figura 6-15.Cuando la temperatura de nuevo disminuye hasta el valor de referencia la LCD muestra el mensaje “ALERTA DISMINUCION”, en este momento se envia dos mensaje al modulo conectando al PC y un mensaje al movil del usuario indicando que la temperatura ha disminuido, en este modulo nuevamente se enciende el LED testigo y la alerta es mostrada por la aplicaci´on.

Figura 6-45: Alerta LCD disminuci´on temperatura.

Figura 6-46: Mensaje enviado m´ovil del usuario por disminuci´on temperatura.

En este momento el usuario da click en el bot´on de apagar y el sistema se encarga de enviar el mensaje, se cuenta con un LED testigo que se enciende al momento de oprimir el bot´on por 3 segundos y el m´odulo se encarga de enviar el mensaje con la se˜nal de apagado de ventilador, se˜nal que se defini´o como la letra “Y”.

Los operadores de telefon´ıa movil en colombia manejan dos bandas de operaci´on en cuanto a la red GSM, movistar y claro trabajan con GSM-850 y otros operadores como ETB, Tigo y Une utilizan GSM-1900. Por tal motivo las coberturas y servicios dependen del operador escogido para la operaci´on de control, con base a esto, la evaluaci´on del funcionamiento del proyecto se realiz´o teniendo en cuenta como factor m´as importante el tiempo que tarda la comunicaci´on entre los m´odulos A6 por medio de los mensajes de texto en diferentes condicio-nes. Teniendo as´ı un conjunto de especificaciones para garantizar el correcto funcionamiento del sistema y que se espera una comunicaci´on ´optima y lo m´as r´apida posible para aplicar las acciones de control a tiempo. Para esto, se realizaron una serie de pruebas durante el desarrollo de proyecto y fueron las siguientes:

7.1.

Prueba interfaz gr´

afica y conexi´

on PSoC

Con base en las pruebas realizadas a la interfaz gr´afica con la conexi´on a la PSoC se en-contr´o la necesidad de usar dos m´odulos UART configurados en el controlador, debido a que el m´odulo tiene la capacidad de ser escrito por varias fuentes, sin embargo solo logra escribir en una fuente a la vez, para la aplicaci´on es necesario conectar el controlador tanto al puerto serial de m´aquina como al m´odulo A6 por medio de sus pines transmisor y receptor. De tal manera, con la implementaci´on de un ´unico m´odulo el sistema puede recibir datos desde el puerto serial y este env´ıa los comandos AT para configurar el A6 para posteriormente enviar el mensaje. El env´ıo se hace de manera exitosa, pero la recepci´on del mensaje no es interpretada por la interfaz gr´afica debido que las alertas son configuradas mediante una interrupci´on de recepci´on de datos en el puerto serial de la m´aquina donde es desplegada la aplicaci´on.

7.2.

Prueba tiempos recepci´

on mensajes

Con base en las pruebas realizadas en el envi´o y recepci´on de mensajes de texto entre m´ odu-los A6, no se encuentra una gran diferencia cuando este es enviado utilizando el mismo operador entre el emisor y el receptor o si alguno de estos es diferente, respecto a los tiempos de recepci´on si se alcanza a ver una diferencia de 4 segundos aproximadamente cuando el mensaje es enviado dese el modulo donde se mide la temperatura al que esta conectado con la interfaz gr´afica. Sin embargo el uso de operadores diferentes a Movistar o Claro arrojo resultados negativos, puesto que no es posible la configuraci´on del modulo y por tanto no se realizara el envi´o o recepci´on de los mensajes.