DISPOSITIVO DE COMUNICACIONES INALÁMBRICO PORTATIL … · Diagrama de funcionamiento de aplicación móvil Bluetooth. 72 ... transmisión de voz y datos entre distintos dispositivos

DISPOSITIVO DE COMUNICACIONES INALÁMBRICO PORTATIL DE MEDIANO ALCANCE Y BAJO CONSUMO DE ENERGÍA PARA SITUACIONES

DE EMERGENCIA O PÉRDIDA DE COBERTURA DE LA RED CELULAR

HECTOR HERNAN VINASCO RAMIREZ - 2147227 JOSE RICARDO MARTINEZ DIAZ - 2130516

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERÍA

DEPARTAMENTO DE AUTOMÁTICA Y ELECTRÓNICA PROGRAMA INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES

SANTIAGO DE CALI 2020

DISPOSITIVO DE COMUNICACIONES INALÁMBRICO PORTATIL DE MEDIANO ALCANCE Y BAJO CONSUMO DE ENERGÍA PARA SITUACIONES

DE EMERGENCIA O PÉRDIDA DE COBERTURA DE LA RED CELULAR

HECTOR HERNAN VINASCO RAMIREZ JOSE RICARDO MARTINEZ DIAZ

Pasantía de investigación para optar al título de Ingeniero Electrónico y de Telecomunicaciones

Director

HELMUT ALEXANDER RUBIO Mg. Sistemas Inalámbricos Y Tecnologías Relacionadas

Co-Director

FARUK FONTHAL RICO PhD. Ingeniería Electrónica

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE

FACULTAD DE INGENIERÍA DEPARTAMENTO DE AUTOMÁTICA Y ELECTRÓNICA

PROGRAMA INGENIERÍA ELECTRÓNICA Y TELECOMUNICACIONES SANTIAGO DE CALI

2020

Nota de aceptación:

Aprobado por el Comité de Grado en cumplimiento de los requisitos exigidos por la Universidad Autónoma de Occidente para optar al título de Ingeniero Electrónico y de Telecomunicaciones Zeida María Solarte Astaiza Jurado

Santiago de Cali, 03 de febrero de 2020

4

AGRADECIMIENTOS

Primero, agradezco a Dios por darme la salud y sabiduría, para enfrentar esta prueba y permitirme culminar mis estudios universitarios, por guiarme y darme la fortaleza para siempre seguir adelante y cumplir con mis metas propuestas.

A mis padres Héctor Fabio Vinasco y Rosa María Ramírez porque nunca dudaron de mí, porque siempre me motivaron a seguir adelante siendo una persona responsable, porque me apoyaron siempre y nunca dudaron en darme lo que fuera necesario para lograr ser un profesional. Por todo su amor y sacrificio. Gracias.

A mi hermana, Francy Vinasco, que, aunque lejos, siempre se acuerda de mí, para darme un consejo, motivación y ayuda de todas las formas posibles. Porque me ha dado ejemplo, amor y es una de las personas que más admiro.

A mi director de trabajo de grado, Helmut Alexander Rubio por su ayuda, apoyo y confianza que deposito en nosotros, por estar pendiente y permitirnos realizar un buen trabajo.

A mis profesores, que fueron guía y ejemplo durante mi recorrido por la universidad, a mis amigos que compartieron tantas experiencias conmigo, que tampoco dudaron de mí, por el contrario, me brindaron su apoyo y cariño, siempre acompañado de unas buenas risas y optimismo que permitía lograr lo que nos propusiéramos.

HÉCTOR HERNÁN VINASCO RAMIREZ.

5

Primero, doy gracias a Dios por la vida, por permitirme la bendición de tener salud y darme la sabiduría para mi recorrido por esta hermosa universidad, por darme la guía para enfrentar la adversidad y darme la paciencia cuando esta me falto.

A mis padres Ricardo Martínez y Haydee Patricia Díaz que han sido quienes siempre han creído en mí y mi potencial en todo momento, gracias les doy por darme la vida, su conocimiento, su concejo, por darme sabiduría y fortaleza en mis momentos de debilidad, a los dos los amo con todo mi corazón.

Le doy gracias a mi director de trabajo de grado, Helmut Alexander Rubio por toda la dedicación, apoyo y confianza que deposito en nuestro trabajo, por guiarnos y corregirnos en momentos de estancamiento.

A mi compañero de tesis Héctor Hernán Vinasco por su paciencia y dedicación a este proyecto.

A todos mis profesores, quienes no me permitieron rendirme y me enseñaron a amar mi carrera a amar el estudio y guiarme en mi camino, a mis compañeros por todos los momentos de risa y apoyo, las horas de estudio compartidas y los momentos de estrés y felicidad compartidas.

JOSE RICARDO MARTINEZ DIAZ.

6

CONTENIDO pág.

GLOSARIO 14

RESUMEN 16

INTRODUCCIÓN 18

1. PLANTEAMIENTO DEL PROBLEMA 20

2. JUSTIFICACIÓN 21

3. OBJETIVOS 23

3.1 OBJETIVO GENERAL 23

3.2 OBJETIVOS ESPECÍFICOS 23

4. ANTECEDENTES 24

5. MARCO TEORICO 28

5.1 PROTOCOLO DE COMUNICACIONES ZIGBEE 28

5.1.1 Topología de Zigbee 29

5.1.2 Módulo Xbee 30

5.1.3 Modo de operación trama API (Application Programming Interface) 32

5.1.4 Seguridad y cifrado 38

5.1.5 Protocolo IEEE 802.15.4 39

5.1.6 Métodos de redes 39

5.2 PROTOCOLO DE COMUNICACIONES BLUETOOTH 40

7

5.2.1 Características de Bluetooth 41

5.2.2 Pila de Protocolos Bluetooth 41

5.3 ANTENA 43

5.4.1 Características 43

5.4 BANDAS DE FRECUENCIA 45

5.4.1 Banda Sub 1 GHz 46

5.4.2 Marco regulatorio en Colombia 47

5.5 NORMAS DE DISEÑO PARA CARCASA DEL DISPOSITIVO 49

6. METODOLOGIA 53

6.1 ETAPAS DEL PROYECTO 53

6.1.1 Diseño a nivel conceptual. 53

6.1.2 Diseño a nivel de sistema. 53

6.1.3 Diseño detallado. 54

6.1.4 Implementación física (Prototipo). 54

6.1.5 Validación. 55

7. DESARROLLO DEL SISTEMA DE COMUNICACIONES (DISEÑO A NIVEL CONCEPTUAL) 56

7.1 SISTEMA DE COMUNICACIONES 56

7.2 COMPONENTES HARDWARE (DISEÑO A NIVEL DE SISTEMA) 57

7.2.1 Modulo Interfaz 57

7.2.2 Módulo de procesamiento 58

7.2.3 Modulo Transceptor 60

7.3 CONFIGURACION DE LOS MODULOS (DISEÑO DETALLADO) 62

7.3.1 Configuración inicial XBEE XSC S3B PRO 900 MHz 62

8

7.3.2 Configuración inicial de Raspberry pi 3+ 67

7.4 IMPLEMENTACIÓN SOFTWARE 71

7.4.1 Desarrollo aplicación móvil 71

7.4.2 Algoritmo del protocolo de comunicaciones 73

7.5 IMPLEMENTACIÓN HARDWARE (IMPLEMENTACIÓN FISICA) 76

7.6 DISEÑO CARCASA DEL DISPOSITIVO 77

8. VALIDACION DEL SISTEMA DE COMUNICACIÓN 79

8.1 TOPOLOGIA PUNTO A PUNTO (DOS NODOS) 79

8.1.1 Medición de radio propagación con XCTU 80

8.1.2 Simulación de radio propagación 83

8.2 TOPOLOGIA EN MALLA (TRES NODOS) 85

8.3 TOPOLOGIA EN MALLA EN INTERIORES 85


8.3.2 Análisis de distancia con estimador de Texas Instruments 88

8.4 TOPOLOGIA EN MALLA EN EXTERIORES 89


8.4.1 Simulación de radio propagación 93

8.5 CONSUMO DE ENERGIA 98

9. CONCLUSIONES 100

10. RECOMENDACIONES Y TRABAJO FUTURO 101

BIBLIOGRAFÍA 102

ANEXOS 105

9

LISTA DE FIGURAS

Pág.

Figura 1. Dispositivo de goTenna 24

Figura 2. Dispositivo de Sonnet. 25

Figura 3. Etiqueta RFID activa. 26

Figura 4. Pila de protocolo Zigbee. 29

Figura 5. Topologías ZigBee. 30

Figura 6. Ejemplo de comunicación en modo de operación API. 33

Figura 7. Direccionamiento de tramas. 40

Figura 8. Pila de protocolos Bluetooth. 41

Figura 9. Comparativo patrón de radiación omnidireccional y direccional. 43

Figura 10. 900MHz Dipolo Antena Datasheet. 44

Figura 11. Antena omnidireccional AU09G8-HQ de Altelix. 45

Figura 12. Nomenclatura CEI 60529 50

Figura 13. Diagrama de bloques de los dispositivos de comunicación. 56

Figura 14. Ejemplo teclado qwerty y pantalla para el dispositivo. 58

Figura 15. XCTU parámetros MAC/PHY. 64

Figura 16. Nodos Digi Mesh. 65

Figura 17. XCTU parámetros de red y direccionamiento. 66

Figura 18. XCTU parámetros de interfaz serial. 67

Figura 19. Script de ejecución de inicio automático. 70

Figura 20. Diagrama de funcionamiento de aplicación móvil Bluetooth. 72

Figura 21. Diagrama macro de funcionamiento del código. 73

10

Figura 22. Diagrama de flujo del hilo Bluetooth. 74

Figura 23. Diagrama de flujo del hilo Modulo. 75

Figura 24. Componentes hardware del dispositivo de comunicación. 76

Figura 25. Funcionamiento del sistema. 76

Figura 26. Modelo 3D Carcasa 78

Figura 27. Distancia entre nodos para topología punto a punto. 79

Figura 28. Diagrama de enlace de módulos Xbee punto a punto. 80

Figura 29. Análisis de intensidad de la señal (topología punto a punto). 81

Figura 30. Condiciones del terreno (topología punto a punto). 82

Figura 31. Intensidad de la señal con línea de vista entre antenas (topología punto a punto). 83

Figura 32. Zona de cobertura de antena punto a punto. 84

Figura 33. Enlace entre antenas punto a punto. 84

Figura 34. Diagrama de enlace de módulos Xbee en malla (indoor). 85

Figura 35. Intensidad de señal entre Nodo R1 y nodo R3. 86

Figura 36. Intensidad de señal entre Nodo R2 y nodo R3. 87

Figura 37. Estimador de distancia e intensidad de señal de Texas Instruments. 88

Figura 38. Distancia máxima de recorrido en malla (Outdoor). 89

Figura 39. Módulo Xbee pro sin conector SMA ni antena. 90

Figura 40. Diagrama de enlace de módulos Xbee en malla (outdoor). 91

Figura 41. Distancia máxima entre dos nodos (Outdoor). 92

Figura 42. Distancia máxima entre tres nodos (Outdoor). 93

Figura 43. Zona de cobertura de Nodo 1 en topología malla (Outdoor). 94

Figura 44. Enlace entre Nodo 1 y Nodo 2 en topología malla (Outdoor). 95

11



Figura 47. Consumo en Amperios del módulo de comunicación. 98

12

LISTA DE TABLAS pág.

Tabla 1. Comparativa modo API y modo Transparente. 31

Tabla 2. Trama de comunicación modo API. 33

Tabla 3. Modo de configuración AP. 34

Tabla 4. Campos de trama modo API 2. 34

Tabla 5. Modo de operación API 2 con carácter de escape. 36

Tabla 6. Modo de operación API 2 – API ID. 36

Tabla 7. Ejemplo de trama API para calcular el campo checksum. 37

Tabla 8. Distribución de espectro para banda de aficionados. 46

Tabla 9. Primer digito protección IP. 50

Tabla 10. Segundo digito protección IP. 51

Tabla 11. Dígitos de protección IK. 52

Tabla 12. Criterios de evaluación para seleccionar interfaz de usuario. 57

Tabla 13. Criterios de evaluación para seleccionar placa de prototipado. 59

Tabla 14. Aspectos técnicos de ordenadores de placa reducida. 60

Tabla 15. Criterios de evaluación para seleccionar Tecnología de comunicaciones. 61

Tabla 16. Tabla de canales de frecuencia por regiones. 63

Tabla 17. Opciones de configuración de potencia de transmisión. 64

13

LISTA DE ANEXOS

pág.

Anexo A. Código Python para módulo de comunicación. 105

Anexo B. Diseño de aplicación móvil. 111

Anexo C. Datasheet Xbee Pro S3B 900 MHz. 111

Anexo D. Tabla Comparativa de módulos de comunicación ZigBee. 112

Ver adjuntos en el repositorio

14

GLOSARIO

BLUETOOTH1: es una especificación tecnológica para redes inalámbricas que permite la transmisión de voz y datos entre distintos dispositivos mediante una radiofrecuencia segura (2,4 GHz). HARDWARE2: conjunto de elementos físicos o materiales que constituyen un sistema informático. PYTHON3: es un lenguaje de scripting independiente de plataforma y orientado a objetos, preparado para realizar cualquier tipo de programa, desde aplicaciones Windows a servidores de red o incluso, páginas web. Es un lenguaje interpretado, lo que significa que no se necesita compilar el código fuente para poder ejecutarlo, lo que ofrece ventajas como la rapidez de desarrollo e inconvenientes como una menor velocidad. RASPBERRY PI4: es un mini ordenador de pequeñas dimensiones y precio destinado principalmente al desarrollo de pequeños prototipos y a estimular la enseñanza de las ciencias de la computación en los centros educativos. Desarrollado en hardware libre cuenta con sistemas operativos GNU/Linux como Raspbian aunque podemos encontrar otros sistemas operativos optimizados para el hardware de la Raspberry Pi. SOCKET5: un socket o enchufe, es un método para la comunicación entre un programa del cliente y un programa del servidor en una red. SOFTWARE6: conjunto de programas y rutinas que permiten a un sistema informático realizar determinadas tareas.

1 Definición.de. Definición de Bluetooth. [en línea] en: definición.de [Consultado el 23 de enero de 2020]. Disponible en internet: https://definicion.de/bluetooth/

2 Significados. Significado de Hardware. [en línea] en: significados.com [Consultado el 23 de enero de 2020]. Disponible en internet: https://www.significados.com/hardware/

3 Desarrolloweb. Qué es Python. [en línea] en: desarrolloweb.com [Consultado el 23 de enero de 2020]. Disponible en internet: https://desarrolloweb.com/articulos/1325.php

4 Programo ergo sum. ¿Qué es raspberri? [en línea] en: programoergosum.com [Consultado el 23 de enero de 2020]. Disponible en internet: https://www.programoergosum.com/cursos-online/raspberry-pi/232-curso-de-introduccion-a-raspberry-pi/que-es-raspberry-pi

5 Masadelante. ¿Qué es un Socket? - Definición de Socket. [en línea] masadelante.com [Consultado el 23 de enero de 2020]. Disponible en internet: https://www.masadelante.com/faqs/socket

6 Significados. Significado de Software. [en línea] en: significados.com [Consultado el 23 de enero de 2020]. Disponible en internet: https://www.significados.com/software/

15

TRANSCEPTOR7: el transceptor es un aparato compuesto por un transmisor y un receptor a la vez. El transmisor y el receptor comparten circuitos comunes como fuente de alimentación, oscilador de portadora, frecuencia intermedia, algunas acciones y una única carcasa. XBEE8: es la marca de una familia de módulos de radio basados en el estándar IEEE 802.15.4 -2003 diseñado para comunicaciones punto a punto y en estrella. ZIGBEE9: es el nombre de la especificación de un conjunto de protocolos de alto nivel de comunicación inalámbrica para su utilización con radiodifusión digital de bajo consumo, basada en el estándar IEEE 802.15.4 de redes inalámbricas de área personal (wireless personal area network, WPAN).

7 EcuRed. Transceptor. [en línea] en: ecured.cu [Consultado el 23 de enero de 2020]. Disponible en internet: https://www.ecured.cu/Transceptores_de_radio

8 DIGI. ¿Qué es Xbee? [en línea] en: xbee.cl [Consultado el 23 de enero de 2020]. Disponible en internet: https://xbee.cl/que-es-xbee/

9 Zigbee alliance. Zigbee. [en línea] en: zigbeealliance.org [Consultado el 23 de enero de 2020]. Disponible en internet: https://zigbeealliance.org/es/

16

RESUMEN

El presente trabajo hace parte de la temática de “Tecnologías para situaciones de emergencia”, propuesto por el semillero de telecomunicaciones de la universidad Autónoma de Occidente y muestra el diseño e implementación de un dispositivo de comunicaciones portátil de mediano alcance para situaciones de emergencia o perdida de cobertura de la red wifi o telefónica. Este dispositivo es complementario al teléfono inteligente o dispositivo móvil y se conecta al nodo utilizando la tecnología bluetooth, permitiendo así enviar información o datos desde el celular en la banda de los 900 MHz a través del módulo.

Para el diseño del hardware o parte física del dispositivo se hace uso de una plataforma robusta y de rápido prototipado como lo es la Raspberry, permitiendo la interacción con el usuario al soportar un sistema operativo, además de presentar puertos seriales y conexión bluetooth, facilitando la conexión con múltiples dispositivos. Por otra parte, se emplea un módulo Xbee PRO encargado de la difusión y recepción de mensajes y como sistema de alimentación, un módulo de batería, el cual le suministra la energía necesaria al dispositivo para su funcionamiento.

Para el protocolo de comunicación se desarrolla un script en código Python encargado de crear el socket Bluetooth y codificar y decodificar los mensajes de los módulos recibidos por serial, permitiendo así la comunicación bidireccional entre nodos de comunicación y visualización de mensajes a través de dispositivos móviles.

Una vez construido el dispositivo, se procede a realizar simulaciones y pruebas de campo entre dos y tres nodos, evaluando su correcto funcionamiento y el alcance máximo al cual se puede mantener un enlace de comunicación, además de medir el consumo de energía para tener un estimado de duración de funcionamiento y dar algunas recomendaciones para continuar desarrollando y mejorando el proyecto al interior del semillero.

Palabras clave: Bluetooth, Hardware, Nodo de comunicación, Puerto serial, Python, Raspberry, Xbee.

17

ABSTRACT

This work is part of the theme of "Technologies for emergency situations", proposed by the telecommunications hotbed of the Autónoma de Occidente University and it shows the design and implementation of a medium-range portable communications device for emergencies or lost coverage of the Wi-Fi or telephone network. This device is complementary to the smartphone or mobile device and connects to the node using bluetooth technology, thus allowing information or data to be sent from the cell phone in the 900 MHz band through the module.

For the design of the hardware or physical part of the device, a robust and rapid prototyping platform such as the Raspberry is used, allowing interaction with the user to support an operating system, in addition to presenting serial ports and Bluetooth connection facilitating the connection with multiple devices. On the other hand, an Xbee PRO module in charge of the diffusion and reception of messages is used, and as supply system a battery module, which supplies the necessary energy to the device for its operation.

For the communication protocol, a Python code script is developed to create the Bluetooth socket and encode and decode the messages of the modules, thus allowing bidirectional communication between communication nodes and message display through mobile devices.

Once the device is built, simulations and field tests are carried out between two and three nodes, evaluating its correct operation and the maximum range to which a communication link can be maintained, in addition for measuring energy consumption in order to have an estimate of duration of operation and give some recommendations to continue developing and improving the project inside the hotbed.

Keywords: Bluetooth, Hardware, Communication node, Serial port, Python, Raspberry, Xbee.

18

INTRODUCCIÓN

Durante los últimos años, las redes inalámbricas han tenido un gran impacto en la sociedad, ya que no fue hasta el año 1971 cuando un grupo de investigadores bajo la dirección de Norman Abramson, en la Universidad de Hawaii, crearon el primer sistema de conmutación de paquetes mediante una red de comunicación por radio (ALOHA). Gracias a este avance tecnológico, se logra satisfacer en la actualidad la necesidad de conectividad, flexibilidad de comunicación (a través de medios no guiados), escalabilidad, atención de emergencias, entre otros. Las redes inalámbricas tienen diversas aplicaciones en la vida cotidiana de las personas, una de ellas está orientada hacia la preservación de la vida del ser humano cuando ocurren todo tipo de catástrofes ambientales. “El continuo cambio climático y la constante expansión poblacional en zonas remotas son algunos de los temas que aumentan la probabilidad de que una persona se vea involucrada en una zona de desastre natural, y es ahí cuando el mayor contacto con la tecnología que tienen nuestras vidas debe ser aprovechado.” 10

Los desastres naturales, además de los generados por el mismo hombre, han deteriorado el desarrollo sostenible de la humanidad. Como consecuencia, la pérdida de vidas humanas, la destrucción parcial o total de las zonas afectadas, y la escasez de medios de subsistencia, son las secuelas que dejan los países con alto índice de desastres como huracanes, inundaciones, tormentas, incendios, derrumbes, terremotos o conflictos bélicos. Las cifras resultantes de afectados son alarmantes, ya que anualmente más de 300 millones de personas se ven afectados por dichos desastres, de los cuales 175 millones aproximadamente son niños. 11 Además, cuando sucede una emergencia donde la vida de las personas se encuentra en riesgo, las comunicaciones en una zona de desastre deben restablecerse lo más rápido posible con un servicio básico como texto o voz, lo cual se puede dificultar cuando la infraestructura física de la red se daña a raíz de la emergencia, tomando mucho tiempo en cuanto a reparaciones.

La facilidad de comunicación que ofrece una ciudad desarrollada es muy grande; se asume que está siempre estará disponible para nuestro uso. Pero es un error subestimar la complejidad e importancia de la misma, ya que en cualquier momento

10 PEREIRA, Matías, GAGGERO, Leonardo, DRABENCHE, Alejandro. La tecnología en situaciones climáticas extremas [en línea] en: Palermo.edu. Facultad de Ingeniería, Universidad de Palermo. Argentina: Editorial Universitaria. [Consultado el 22 de febrero de 2018]. Disponible en internet: http://www.palermo.edu/

11 Unicef. Desastres naturales: más de la mitad de los afectados son niños. [en línea] en: unicef.es [Consultado el 07 de agosto de 2018]. Disponible en internet: https://www.unicef.es/noticia/desastres-naturales-mas-de-la-mitad-de-los-afectados-son-ninos

19

los cables pueden dañarse o el suministro eléctrico de las centrales puede agotarse debido a los múltiples siniestros, dejando a miles de usuarios incomunicados. A esto se le suma que generalmente los sistemas de comunicación (ya sea de telefonía o de red) no están diseñados para soportar el flujo de datos de todos los usuarios al mismo tiempo, por lo cual los canales se pueden saturar haciendo imposible la comunicación.

Este trabajo presenta el diseño y la implementación de una herramienta de comunicaciones de baja frecuencia y bajo consumo de energía que permite el intercambio de mensajes de texto en situaciones de emergencia, sin necesidad de la cobertura de red telefónica móvil, aprovechando al máximo la tecnología mediante un dispositivo capaz de transmitir datos en una banda de frecuencia media (no licenciada).

20

1. PLANTEAMIENTO DEL PROBLEMA

El acceso a la información y comunicaciones es primordial en toda fase de una emergencia, siendo tan vital como la disponibilidad de agua potable, alimento o refugio en situaciones de grandes catástrofes si lo que se desea es salvar vidas. Por lo tanto, las tecnologías de comunicación deben dar cumplida respuesta a las necesidades de información que requieran las situaciones de emergencia (victimas, rescatistas, organizaciones humanitarias, entre otros).

Las nuevas tecnologías se hacen presentes principalmente durante y después de los desastres, resultando favorable para el auxilio de vidas humanas ya que el éxito de las tareas de rescate depende en gran parte de la disponibilidad de información actualizada sobre el desarrollo de la situación. Dependiendo de la gravedad del desastre las redes de información terrestres pueden sufrir graves daños impidiendo las comunicaciones de rescate vitales para salvar vidas humanas.

Ante esa situación, es de vital importancia analizar una nueva alternativa de comunicación descentralizada, idónea para situaciones de emergencia, es decir, un sistema de mensajería que no dependa de una infraestructura de telecomunicaciones fija que puede quedar por fuera de servicio durante un desastre natural. Por lo tanto, se plantea la siguiente pregunta de investigación: ¿Cómo se debe diseñar y construir un dispositivo inalámbrico portátil que permita realizar envío y recepción de mensajes de texto en situaciones donde la red de telefonía celular falla o no brinda cobertura?

21

2. JUSTIFICACIÓN

A nivel nacional, uno de los últimos desastres ocurridos ha sido la tragedia de Mocoa en el año 2017. Como consecuencia de las lluvias presentadas el 31 de marzo de 2017 en horas de la noche en la zona, se desbordaron los ríos Mocoa, Sangoyaco y Mulata; generando una avalancha en el municipio de Mocoa, capital del departamento de Putumayo. Este desastre generó más de 300 muertos, aproximadamente 400 heridos, un gran número de desaparecidos y en total más de 1000 afectados. 12 El desastre también causó el colapso de las telecomunicaciones, daños en calles e incomunicación de Mocoa con otras zonas del departamento del Putumayo, departamento del Huila y el resto del país dados los múltiples derrumbes que también generaron el daño de las redes eléctricas y afectó la generadora hidroeléctrica local, dejando sin energía a otras zonas del departamento por varias semanas.

En Colombia, por sus características geológicas y tectónicas, así como por sus condiciones climáticas, se presentan eventualmente fenómenos catastróficos de origen geológico (terremotos, erupciones volcánicas, deslizamientos), hidro-meteorológico (tormentas, inundaciones, sequías) y mixtos (remoción en masa, avalanchas, entre otros). Estos eventos pueden ser poco frecuentes, pero con grandes impactos, como el terremoto de Popayán (31 de marzo de 1983), la erupción del volcán Nevado del Ruiz y la avalancha que destruyó Armero (13 de noviembre de 1985), los sismos del Atrato Medio (17 y 18 de octubre de 1992), el terremoto de Páez (6 de junio de 1994), el sismo del Eje Cafetero (25 de enero de 1999), el desbordamiento Giron (2005), el desbordamiento Belalcazar (2008), la tragedia de Mocoa (2017), entre otros de menor magnitud. 13

12 Cruz Roja Colombiana. Emergencia Mocoa – Putumayo, reporte de situación. [en línea] en: reliefweb.int. Abril de 2017. [Consultado el 08 de julio de 2018]. Disponible en internet: https://reliefweb.int/sites/reliefweb.int/files/resources/CO-CRCol3_EMERGENCIA_MOCOA.pdf

13 Comisión de regulación de comunicaciones. Regulación para promover el desarrollo e implementación del sistema nacional de telecomunicaciones de emergencias en Colombia [en línea] en: crcom.gov. Mayo de 2016. [Consultado el 17 de octubre de 2018]. Disponible en internet: https://www.crcom.gov.co/recursos_user/2016/Actividades_regulatorias/SNTE/DocSoporte_SNTE_publicar.pdf

22

Según se expresa en los documentos elaborados por la UIT14, las telecomunicaciones son decisivas en todas las etapas de la gestión de una emergencia o catástrofe, ya que cumplen con la obligación de prevenir y comunicar el estado del sector afectado.

Con base en estos antecedentes, surge la necesidad de un sistema de red inalámbrica que sea capaz de proveer su propio modo de comunicación que no dependa de infraestructuras de telecomunicaciones terrestres fijas o móviles. Además, es necesario que el sistema sea portable, de fácil uso, que soporte un tiempo de uso prudencial y principalmente que pueda estar funcionando en cualquier parte del mundo.

14 Unión internacional de telecomunicaciones. La UIT en las telecomunicaciones de emergencia [en línea] en: mintic.gov. Octubre de 2017. [Consultado el 17 de octubre de 2018]. Disponible en internet: https://www.mintic.gov.co/2do_foro_multisectorial/668/articles-60293_memorias_sesin601.pdf

23

3. OBJETIVOS

3.1 OBJETIVO GENERAL

Diseño y construcción de un dispositivo inalámbrico de comunicaciones portátil de mediano alcance y bajo consumo de energía que permite enviar y recibir mensajes de texto, en situaciones de emergencia o pérdida de cobertura de la red de telefonía celular.

3.2 OBJETIVOS ESPECÍFICOS

Construir un par de prototipos electrónicos configurables de bajo consumo de potencia que permitan realizar la transmisión y recepción de datos en banda libre y soporten topologías de red multisalto.

Diseñar e implementar un algoritmo de comunicación que permita a un usuario realizar intercambio de mensajes de texto empleando los dispositivos construidos.

Integrar los dispositivos electrónicos construidos con el algoritmo de comunicaciones y realizar pruebas de intercambio de mensajes de texto para validar el cumplimiento del sistema completo.

24

4. ANTECEDENTES

Los medios de comunicación han tenido un impulso notable gracias al desarrollo de las nuevas tecnologías, pasando de redes de transmisión punto a punto a topologías de red en malla donde todos los nodos se encuentran conectados, ofreciendo múltiples caminos para llevar la información.

En noviembre del 2012, surgió la empresa goTenna en Nueva York, Estados Unidos. Una organización encargada de diseñar y desarrollar tecnologías para comunicaciones descentralizadas y fuera de la red. Los dispositivos de goTenna son compatibles con dispositivos móviles inteligentes y a través de protocolos de red ad hoc, permiten a los usuarios enviar mensajes de texto y compartir ubicaciones sin recurrir a infraestructura de comunicaciones centralizada.

Figura 1. Dispositivo de goTenna

Fuente: goTenna [en línea] en: gotenna.com [Consultado: 18 de marzo de 2018]. Disponible en Internet: https://www.gotenna.com/

El dispositivo de goTenna (ver figura 1) surgió después de un desastre natural (huracán Sandy), el cual destruyó el 25 por ciento de las torres de telefonía celular y genero cortes de los servicios de internet en 10 estados de la costa este. 15

15 GOLDMAN, David. Sandy Knocks out 25% of Cell Service in Its Path [En linea] en money.cnn.com. 2012 [Consultado el 9 de marzo de 2018]. Disponible en internet: http://money.cnn.com/2012/10/31/technology/mobile/sandy-cell-service-outages/index.html

25

GoTenna se incorporó oficialmente en abril de 2013 y su principal objetivo es “construir sistemas de comunicación entre pares basados en las personas, reduciendo la dependencia de torres de telefonía móvil y los enrutadores wifi, brindando a todos, la capacidad de crear una red en sus términos”. 16 En septiembre de 2016 goTenna presentó un dispositivo de segunda generación: goTenna Mesh, la primera red de malla para el consumidor. Cabe resaltar que la transmisión de datos del goTenna Mesh se da en frecuencias UHF permitiendo un alcance mínimo de 0.8 km y máximo de 6.4 km según las condiciones del terreno.

Por otra parte, se encuentra el dispositivo de la empresa Sonnet Labs Inc. (ver figura 2), desarrollado desde el año 2017 como un método de comunicación de respaldo cuando tanto el WiFi como la red celular son inaccesibles. Utiliza un protocolo inalámbrico especial de largo alcance para transmitir mensajes, grabaciones de audio, imágenes y coordenadas de GPS en un rango de hasta 15 km de distancia. Con la adición de redes de malla, puede transmitir datos a una distancia teóricamente ilimitada, siempre que hallan suficientes nodos. 17

Figura 2. Dispositivo de Sonnet.

Fuente: SONNET [en línea] en: sonnetlabs.com. [Consultado: 18 de marzo de 2018]. Disponible en Internet: https://www.sonnetlabs.com/

16 goTenna [en línea] en: gotenna.com. [Consultado: 18 de marzo de 2018]. Disponible en Internet: https://www.gotenna.com/

17 SONNET device. [en línea] en sonnetlabs.com. [Consultado: 18 de marzo de 2018]. Disponible en Internet: https://www.sonnetlabs.com/

26

El Sonnet opera en la frecuencia de 917 MHz. Esta frecuencia se denomina banda ISM (Industrial, Científica y Médica) y tiene un alcance de hasta 5 km según las condiciones del terreno. Al igual que los canales de 2,4 y 5 GHz que ejecuta un enrutador, la banda ISM de 915 MHz está disponible para uso público sin licencia, por lo cual no se necesita pagar una tarifa de suscripción para usarla y no requiere ningún proveedor.

En la parte académica, en cuanto a estudios y proyectos, se presenta un “Sistema de atención de emergencia que utiliza técnicas RFID (identificación por radio frecuencia) y Zigbee” (Ver figura 3).18 Desarrollado por estudiantes de la St. John’s University en la ciudad de Nueva York con el fin de ayudar al personal de atención médica con guardias de barrio y enfermería a fin de aumentar la eficiencia de la gestión y reducir los errores descuidados causados por los humanos.

Figura 3. Etiqueta RFID activa.

Fuente: Horng-Lin Shieh, Chi-Chang Huang. Sistema de atención de emergencia que utiliza técnicas RFID y Zigbee. IEEE Xplore. [en línea] en: ieeexplore.ieee.org. [Consultado: 18 de marzo de 2018]. Disponible en Internet: https://ieeexplore.ieee.org/document/7545137/

Este proyecto usa la etiqueta RFID, la tecnología ZigBee y la comunicación inalámbrica de largo alcance para construir un sistema de atención de emergencia.

18 HORNG, Lin, HUANG, Chi-Chang. Sistema de atención de emergencia que utiliza técnicas RFID y Zigbee. IEEE Xplore. [en línea] en: ieeexplore.ieee.org. [Consultado: 18 de marzo de 2018]. Disponible en Internet: https://ieeexplore.ieee.org/document/7545137/

27

El modelo diseñado consta de una etiqueta RFID activa, un lector de posicionamiento RFID-ZigBee activo (incluido el enrutador) y un módulo de red inalámbrica. Como se muestra en la figura 3, los dispositivos operan en la banda de frecuencias de 2.4Ghz con un rango de transmisión de 60m (debido a la longitud de onda pequeña) y un consumo de 200 mA por año.

Todos estos dispositivos tienen en común el uso de una topología de red en malla, en donde todos los nodos están conectados entre sí, ofreciendo múltiples caminos para el envío y recepción de datos entre dispositivos; característica principal que busca el semillero al pensar en el diseño de un dispositivo para estados de emergencia, donde lo más importante es poder alertar o mantener la comunicación con la mayor cantidad de personas, facilitando la atención a las personas y zonas afectadas.

28

5. MARCO TEORICO

Para el presente proyecto se han determinado unas características principales que deben cumplir los dispositivos, tales como bajo consumo de energía, baja transmisión de datos y uso de frecuencias medias, por lo que, para cumplir con estas especificaciones, es necesario conocer las diferentes opciones para la implementación tanto de hardware como software.

5.1 PROTOCOLO DE COMUNICACIONES ZIGBEE

ZigBee es el nombre de la especificación de un conjunto de protocolos de alto nivel de comunicación inalámbrica. Esta especificación define una solución para comunicaciones inalámbricas de bajo coste y consumo. El principal objetivo que pretende satisfacer una red de comunicación Zigbee es la de comunicar aplicaciones que requieren comunicaciones seguras, con baja tasa de envío y maximización de la vida útil de sus baterías.19

Aprovecha el poder de la malla para conectar cada producto a cualquier otro producto, permitiendo la comunicación entre dispositivos sin interrupciones en caso de que un nodo falle.

Teniendo presente las diferentes topologías y protocolos que ofrece dicho modelo (ver figura 4), ZigBee no solo se emplea en la parte sensorial y domótica, sino también en las comunicaciones entre personas.

19 BARNEDA FAUDOT, Iván. ZigBee aplicado a la transmisión de datos de sensores biomédicos [en línea] en: ddd.uab.cat. Facultad de Ingeniería, Universidad Autónoma de Barcelona. España: Editorial Universitaria. [Consultado el 12 de marzo de 2018]. Disponible en internet: https://ddd.uab.cat/pub/trerecpro/2008/hdl_2072_13081/PFC_Ivan_Barneda.pdf

29

Figura 4. Pila de protocolo Zigbee.

Fuente: DIGNANI, Jorge. Analisis del protocolo Zigbee [En línea] en: https://postgrado.info.unlp.edu.ar. Facultad de Informática, Universidad Nacional de La Plata. [Consultado el 12 de marzo de 2018]. Disponible en internet: https://postgrado.info.unlp.edu.ar/wp-content/uploads/2014/07/Dignanni_Jorge_Pablo.pdf

5.1.1 Topología de Zigbee

ZigBee usa las topologías de IEEE 802.15.4 para transferencia de datos y agrega las topologías de árbol y de malla (ver figura 5). Debido al poco alcance de cada nodo, frecuentemente un paquete debe ser retransmitido varias veces por intermedio de enrutadores. Lo destacable es que el ruteo en cualquier topología usada se hace en la capa de red y entonces no es necesaria ninguna programación adicional en la capa de aplicación. 20

20 DIGNANI, Pablo. Análisis de protocolo zigbee. Universidad Nacional de La Plata. 2011. [en línea] en: postgrado.info.unlp.edu.ar [Consultado el 8 de septiembre de 2018]. Disponible en internet: https://postgrado.info.unlp.edu.ar/wp-content/uploads/2014/07/Dignanni_Jorge_Pablo.pdf

30

Figura 5. Topologías ZigBee.

Fuente: DIGNANI, Pablo. Análisis de protocolo Zigbee. Universidad Nacional de La Plata. 2011. [En línea] en: postgrado.info.unlp.edu.ar. [Consultado el 8 de septiembre de 2018]. Disponible en internet: https://postgrado.info.unlp.edu.ar/wp-content/uploads/2014/07/Dignanni_Jorge_Pablo.pdf

Como parte importante del proyecto es lograr la mayor distancia posible para enviar el mensaje se presenta un elemento adicional, ya que los dispositivos tranceivers que utilizan el protocolo de comunicaciones de Zigbee se les puede conectar una antena la cual permita aumentar su rango de trabajo, mejorando la potencia con que se puede enviar el mensaje y su direccionamiento, para este caso se utilizara una antena omnidireccional dado que el dispositivo no tendrá una única dirección para enviar el mensaje sino que se transmitirá en 360 grados.

5.1.2 Módulo Xbee

Los dispositivos de XBee se comunican entre sí de manera inalámbrica enviando y recibiendo mensajes, estos no pueden crear o modificar datos que se envíen o gestionar datos recibidos, para ello se comunican con otros dispositivos a través de su interfaz serial, recibiendo los datos del dispositivo conectado y posteriormente trasmitiéndolos cuando se vaya a enviar o viceversa, así, trasmitiendo cualquier dato recibido al puerto serial. Los microcontroladores o PC tienen la tarea de controlar que envían y como se gestionan los mensajes de los dispositivos XBee.

Para lo anterior, existen dos modos de operación que se pueden implementar para el envío y recepción de datos, esto dependiendo a que lo que se ajuste a las necesidades y requerimientos del proyecto, los cuales son:

31

Modo Transparente (Aplicación transparente). La radio pasa la información tal cual la recibe por el puerto serie. Este modo tiene funcionalidades limitadas, pero es la forma más sencilla de comenzar.

Modo API (Aplicación de programación). En este caso un protocolo determina la forma en que los datos son intercambiados. Este modo permite hacer una red de comunicaciones más grande.

Cada uno de estos posee sus ventajas y desventajas (Tabla 1), y dependiendo de la aplicación que se desee se puede utilizar un modo u otro, o la combinación de las dos.

Tabla 1. Comparativa modo API y modo Transparente.

Modo de operación Transparente

Modo de operación Trama API

Cuando se utiliza

Provee una interfaz simple que facilita la puesta en marcha de los dispositivos XBee.

Envía datos a múltiples destinos por medio inalámbrico

Se pueden configurar los módulos en la red de forma remota.

Ventajas

Soporte sobre aplicación sencillo; el dato que se envía es el mismo dato que otro modulo recibe y viceversa.

Funciona muy bien en una comunicación full dúplex entre dos módulos.

Puede trasmitir datos a uno o varios destinos; esto es mucho más veloz que el modo transparente donde se tiene que reconfigurar el modulo si se requiere enviar datos a otro destino.

El paquete de datos recibido incluye la dirección del transmisor.

El paquete de datos recibido incluye detalles de trasmisión y determina si el paquete llego o no a su destino.

32

Tabla 1. (Continuación)

Modo de operación Transparente

Modo de operación Trama API

Desventajas

No se puede configurar de forma remota el modulo en la red.

Debe ser reconfigurado en caso de que se quiera establecer una nueva conexión con un destinatario diferente.

El dato recibido no incluye información detallada en caso de que se reciba o no el dato.

No puede identificar el origen del dato recibido ya que el dato no incluye la dirección del remitente.

La interfaz es mucho más compleja que en el modo transparente, ya que, los datos se estructuran en paquetes con un formato específico.

La transmisión está estructurada en paquetes que necesitan se traducidos en el caso de los paquetes recibidos o creados para los paquetes de trasmisión, esto hace que el soporte sea mucho más complejo que en el modo trasparente.

Los paquetes de datos enviados y recibidos no son iguales; los paquetes de datos recibidos incluyen información extra de control.

Fuente: DIGI. Comparison of transparent and API modes. [En línea] en: digi.com. [Consultado el 10 de octubre de 2019]. Disponible en internet: https://www.digi.com/resources/documentation/Digidocs/90001456-13/Default.htm#concepts/c_xbee_comparing_at_api_modes.htm%3FTocPath%3DHow%2520XBee%2520devices%2520work%7CWireless%2520communication%7CSerial%2520communication%7C_____2

5.1.3 Modo de operación trama API (Application Programming Interface)

A diferencia del modo transparente, el modo API hace que espere una secuencia específica de bytes que le indican que tipo de operación deberá realizar, cada una de estas secuencias se le llama paquete de datos con los cuales se establece una comunicación compleja entre módulos sin tener que definir un protocolo propio.

Los datos enviados en el modo API se encuentran estructurados en una trama, estos se envían a través de la interfaz serial.

33

Figura 6. Ejemplo de comunicación en modo de operación API.

Fuente: DIGI. Ilustración de transmisión de datos en modo de operación trama API [En línea] en: digi.com. [Consultado el 10 de octubre de 2019]. Disponible en internet: https://www.digi.com/resources/documentation/Digidocs/90001942-13/concepts/c_api_mode_detailed.htm?TocPath=XBee%20API%20mode%7C_____1

Tabla 2. Trama de comunicación modo API.

Fuente: DIGI. Frame Data [En línea] en: digi.com. [Consultado el 10 de octubre de 2019]. Disponible en internet: https://www.digi.com/resources/documentation/Digidocs/90001456-13/Default.htm#concepts/c_api_frame_structure.htm%3FTocPath%3DXBee%2520API%2520mode%7C_____2

Para configurar el modo de operación API se debe tener en cuenta que este propone dos funcionamientos, el primer modo API 1 el cual es una trama sin caracteres de escape se basa únicamente en el delimitador de inicio y la longitud de los bytes para diferenciar las tramas, si los bytes en un paquete se pierden, la cuenta de bytes será incorrecta y el siguiente paquete también se perderá; en el segundo modo API 2 implica secuencias de caracteres de escape en una trama para mejorar la fiabilidad especialmente en entornos ruidosos.

34

Tabla 3. Modo de configuración AP.

Fuente: Zigbee. Xbee modos de configuración AP [En línea] en: aprendiendoarduino.wordpress.com. [Consultado el 10 de octubre de 2019]. Disponible en internet: https://aprendiendoarduino.wordpress.com/tag/xctu/

Para la estructura de la trama del modo API 2 todos los bytes excepto el delimitador de inicio deben estar separados por una bandera de escape, así, una trama no se confundirá con otra cuando esta incluya los siguientes valores en el campo data (ver tabla 4).

Tabla 4. Campos de trama modo API 2.

Fuente: DIGI. XBee-PRO 900HP/XSC RF Modules [En línea] en: digi.com. [Consultado el 10 de octubre de 2019]. Disponible en internet: https://www.digi.com/resources/documentation/digidocs/pdfs/90002173.pdf

0x7E: Delimitador de inicio

0x7D: Carácter de escape

0x11: XON

0x13: XOFF

35

Como ejemplo de lo anterior, se tiene la siguiente trama 0x7E 0x00 0x02 0x23 0x11 0xCB, en este caso el dato 0x11 al ser un valor que puede generar interferencia con el siguiente paquete de datos requiere una bandera de carácter de escape, por consecuente el resultado de la trama adicionando el carácter de escape será el siguiente, 0x7E 0x00 0x02 0x23 0x7D 0x31 0xCB, como se puede observar el dato 0x11 se le adiciona una bandera de carácter de escape y al siguiente dato se realiza una operación XOR con 0x20. Adicional a lo anterior cabe destacar que el campo longitud no incluye los caracteres de escape y el campo checksum es calculado con los datos no escapados.21

Delimitador de inicio

Este es el primer byte en la trama de datos que consiste en una secuencia especial de bits que indica el comienzo de la trama de datos. Este valor siempre es 0x7E y se utiliza para detectar fácilmente cualquier nuevo dato entrante.

Longitud

El campo longitud especifica el número total de bytes incluidos en la trama de datos excluyendo de este valor los campos como el delimitador de inicio, la longitud (tanto el byte más significativo como el menos significativo) y el checksum.

Tipo de paquete de dato (Frame Data)

Este campo contiene la información del tipo de dato que el dispositivo recibe o transmite, la estructura de la trama en el campo de datos puede cambiar en función del tipo de identificador de tipo de dato, también dependiendo de si es una trama entrante o saliente.

21 Digi International. XBee-PRO 900HP/XSC RF Modules S3 and S3B User Guide. [en línea] en: Digi International Inc. junio de 2019. [Consultado el 10 de octubre de 2019]. Disponible en internet: https://www.digi.com/resources/documentation/digidocs/pdfs/90002173.pdf

36

Tabla 5. Modo de operación API 2 con carácter de escape.


Tabla 6. Modo de operación API 2 – API ID.


Calculo y verificación de campo checksum

Ahora bien, este es el último byte de la trama que ayuda a verificar la integridad de la trama de datos. Esta se calcula realizando la suma de hash de todos los datos de la trama API que se encuentren antes de este campo excluyendo los primeros tres

37

bytes (el delimitador de inicio y la longitud de la trama). Se deben realizar los siguientes pasos para calcular el campo cheksum.22

- Realizar la suma de todos los bytes excluyendo los tres primeros bytes.

- Del resultado de la suma tomar únicamente los 8 bits menos significativos.

- Al resultado obtenido restarlo a 0xFF.

Como ejemplo de los pasos anteriores se realizará el cálculo para el campo checksum de la siguiente trama.

Tabla 7. Ejemplo de trama API para calcular el campo checksum.

Fuente: DIGI. API Frame Structure [En línea] en: digi.com. [Consultado el 10 de octubre de 2019]. Disponible en internet: https://www.digi.com/resources/documentation/Digidocs/90001456-13/Default.htm#concepts/c_api_frame_structure.htm%3FTocPath%3DXBee%2520API%2520mode%7C_____2

Siguiendo los pasos anteriores el proceso será el siguiente.

Se realiza la suma de todos los bytes antes del checksum excluyendo el delimitador de inicio y la longitud de trama: 17 + 01 + 00 + 13 + A2 + 00 + 40 + AD + 14 + 2E + FF + FE + 02 + 44 + 42 = 481.

22 Digi, Digi International. API Frame Structure [en línea] en: Digi International Inc. 09 de septiembre de 2019. [Consultado el 10 de octubre de 2019]. Disponible en internet: https://www.digi.com/resources/documentation/Digidocs/90001456-13/Default.htm#concepts/c_api_frame_structure.htm%3FTocPath%3DXBee%2520API%2520mode%7C_____2

38

Del resultado tomar únicamente los 8 bits menos significativos: 81.

Al resultado obtenido restarlo a 0xFF: FF- 81 = 7E.

En este ejemplo 0x7E es el valor de checksum de la trama, al coincidir con el valor del delimitador de inicio se debe realizar la modificación del valor adicionando la bandera con carácter de escape (ver tabla 7).

Para realizar la verificación del checksum de un paquete de datos se deben seguir los siguientes pasos.

Realizar la suma de todos los datos de la trama solamente excluyendo el delimitador de inicio y la longitud de la trama.

La verificación del checksum será correcta solo si, los 8 bits menos significativos del resultado son 0xFF.

Usando el ejemplo anterior se procede a realizar la suma de todos los datos siguiendo los pasos la diferencia con el ejemplo anterior donde el resultado fue 481, aquí se incluye el valor del checksum para verificar si la verificación es correcta. 17 + 01 + 00 + 13 + A2 + 00 + 40 + AD + 14 + 2E + FF + FE + 02 + 44 + 42 + 7E = 4FF.

Tras realizar la suma se obtiene como resultado 4FF, como dice la regla si se toman los dos dígitos menos significativos y estos son 0xFF entonces la verificación del checksum será positiva y así el modulo no descartará el dato.

5.1.4 Seguridad y cifrado

Los módulos Xbee pueden ser configurados para comunicación segura mediante claves de cifrado, para ello se hace uso de AES (Advanced Encryption Standard) el cual es un algoritmo de criptografía simétrica, este cifrado es de 128 bits. Los datos son cifrados antes de ser enviados y posteriormente son descifrados para poder usarlos. Al activar la seguridad en una red XBee podría presentar un ligero aumento en la latencia y tamaño de los paquetes enviados.

Para habilitar la comunicación segura entre módulos se deben configurar los paramentos.

EE=1: Habilitar encriptado AES.

KY: Llave de encriptado AES, esta debe ser un string de 32 caracteres hexadecimales, la cual una vez configurada es imposible de recuperar el valor.

39

5.1.5 Protocolo IEEE 802.15.4

Los módulos XBee son soluciones integradas que brindan un medio inalámbrico para la interconexión y comunicación entre dispositivos. Estos módulos utilizan el protocolo de red llamado IEEE 802.15.4 para crear redes POINT-TO-MULTIPOINT (punto a multipunto); o para redes PEER-TO-PEER (punto a punto). Fueron diseñados para aplicaciones que requieren de un alto tráfico de datos, baja latencia y una sincronización de comunicación predecible. Por lo que básicamente XBee es una implementación de Digi basada en el protocolo Zigbee. En términos simples, los XBee son módulos inalámbricos fáciles de usar.23

5.1.6 Métodos de redes

La capa PHY define las características físicas y eléctricas de la red. Es responsable de administrando el hardware que modula y demodula los bits de RF. La capa MAC es responsable de enviar y recibir tramas de RF. Como parte de cada paquete, hay un encabezado de datos de capa MAC que tiene información de direccionamiento, así como opciones de paquetes. Esta capa implementa acuses de recibo de paquetes (ACK), seguimiento de paquetes para eliminar duplicados, etc.

- Cuando un dispositivo está transmitiendo, no puede recibir paquetes. - Cuando un dispositivo no está durmiendo, está recibiendo o transmitiendo. - No hay requisitos de balizas o maestro / esclavo en el diseño de MAC / PHY.

El módulo RF XBee-PRO 900HP utiliza un método patentado para escanear y encontrar una transmisión. Cuando un dispositivo transmite, envía un patrón de preámbulo repetido, un encabezado MAC, opcionalmente un encabezado de red, seguido de paquete de datos. Un dispositivo receptor puede escanear todos los canales para encontrar una transmisión durante el preámbulo.24

Cada paquete de RF contiene información de direccionamiento que los dispositivos receptores usan para filtrar los datos de RF entrantes. Los dispositivos receptores

23 DIGI. ¿Que es Xbee? [en línea] en: xbee.cl. [Consultado el 23 de septiembre de 2019]. Disponible en internet: https://xbee.cl/que-es-xbee/

24 DIGI. XBee-PRO 900HP/XSC RF Modules. User Guide [en línea] en: digi.com. [Consultado el 23 de septiembre de 2019]. Disponible en internet: https://www.digi.com/resources/documentation/digidocs/pdfs/90002173.pdf

40

inspeccionan la identificación del preámbulo (parámetro HP), el número de identificación del proveedor (parámetro ID) y la dirección de destino (parámetro DT) en cada paquete de RF. Un dispositivo receptor descarta todos los datos que no pasan a través de las tres capas de seguridad de red.

En la figura 7 se ilustran las capas de direccionamiento en el encabezado del paquete RF.

Figura 7. Direccionamiento de tramas.

Fuente: DIGI. Modulos Xbee-PRO 900 HP RF Module. Direccionamiento [En línea] en: digi.com. [Consultado el 18 de octubre de 2019]. Disponible en internet: https://www.digi.com/resources/documentation/digidocs/90002173/Default.htm#concepts/c_addressing.htm%3FTocPath%3DNetwork%2520configurations%7CAddressing%7C_____0

5.2 PROTOCOLO DE COMUNICACIONES BLUETOOTH

La tecnología define un estándar de comunicaciones inalámbricas de corto alcance mediante señales de radiofrecuencia la cual trabaja en la banda ISM de 2.4 GHz que permite la transmisión de datos y voz, aunque en la actualidad existan diferentes y variadas tecnologías de corto alcance, creadas para cubrir las deficiencias de unas a otras, la tecnología Bluetooth presenta grandes ventajas frente a otras como confiabilidad en la transmisión de datos, baja interferencia, alto alcance de transmisión a baja potencia, bajo costo y permite el intercambio de voz y datos.

41

5.2.1 Características de Bluetooth

El hardware que compone el dispositivo está compuesto por dos partes, el transceptor quien es el encargado de modular, transmitir y recibir la señal; y el controlador digital el cual está compuesto por una CPU, un procesador de señales digitales llamado Link Controller (control de enlace) y las interfaces con el dispositivo anfitrión.

5.2.2 Pila de Protocolos Bluetooth

La pila de protocolos se basa en el modelo para interconexión de sistemas abiertos OSI. La arquitectura de protocolos divide las funciones de red en un sistema de niveles las cuales permiten el intercambio transparente de información (figura 8).

Figura 8. Pila de protocolos Bluetooth.

Fuente: Aplicaciones de controlador Bluetooth. Capítulo 4: Bluetooth [En línea] en: http://bibing.us.es/. [Consultado el 10 de octubre de 2019]. Disponible en internet: http://bibing.us.es/proyectos/abreproy/11526/fichero/Aplicaciones+de+un+controlador+Bluetooth+en+Rob%C3%B3tica+%252FCapitulo+4.+Bluetooth.pdf

42

Capa de protocolo de gestión de enlace (LMP).

Este protocolo es el responsable de la configuración y control de enlace entre dispositivos Bluetooth, realizando también la tarea de controlar la negociación del tamaño de los paquetes de banda base.

El funcionamiento del protocolo LMP gestiona el uso de canales con los que Bluetooth cuenta, estos son 79 canales, separados entre sí por 1MHz; cuando dos dispositivos establecen comunicación, primero se comunican mediante una frecuencia predefinida conocida como canal de control (Control Channel), usando este canal establecen el orden en el cual utilizaran todos los canales hasta terminar y volver a establecer una secuencia.

Capa de interfaz de controlador de host (HCI)

Esta capa actua como frontera entre las capas de protocolo relativas al hardware y software. Proporciona una interfa de comandos para la comunicacion entre el dispositivo y el firmware del modulo y permite disponer de una capa de acceso homogenea para todos los modulos Bluetooth de banda base, aunque sean de distintos fabricantes.

Capa de protocolo de adaptación y control de enlace lógico (L2CAP)

Este protocolo es el encargado de la multiplexacion de otros protocolos, ya que el protocolo de banda base no soporta un campo para identificar el protocolo de nivel superior al que requiera transmitir la informacion, por ejemplo SDP, RFCOMM y TCS.

L2CAP dispone de 32767 puertos disponibles para que las aplicaciones los utilicen al comunicarse mediante Bluetooth. Con estos, define una serie de puertos que se pueden utilizar para mandar y recibir datos mediante las capas de abajo, es decir, define una forma en la que varias aplicaciones pueden enviar datos y recibir datos utilizando las ondas de radios de Bluetooth.

Capa de protocolo de descubrimiento de servicios (SDP)

El protocolo SDP permite a un dispositivo descubrir servicios que ofrecen otros dispositivos y sus parametros asociados. Una vez el dispositivo tiene una lista de los dispositivos cercanos, puede consultar que servicios proveen dichos dispositivos.

43

5.3 ANTENA

En los diferentes dispositivos de transmisión de datos, la antena es un periférico que permite mejorar el alcance de la transmisión de datos. Existen diferentes tipos, las cuales se diferencian según su patrón de radiación, forma y dimensiones, las cuales pueden ser direccionales u omnidireccionales como se muestra en la figura 9. Figura 9. Comparativo patrón de radiación omnidireccional y direccional.

Fuente: Universidad politécnica de Cataluña. Diseño y Medición de una Antena Wearable [En línea] en: upcommons.upc.edu. [Consultado el 26 de febrero de 2020]. Disponible en internet: https://upcommons.upc.edu/bitstream/handle/2117/106668/mohamed.el.bouchti_119201.pdf?sequence=1&isAllowed=y

5.4.1 Características 25

El patrón o diagrama de radiación de una antena es una representación de la distribución de potencia de la radiación recibida o irradiada por la antena en

25 Antena VHF marina y antenas GPS, WiFi, TDT, TV y satelitales. [en línea] en: www.eltrinauta.com [Consultado el 8 de septiembre de 2018]. Disponible en internet: http://www.eltrinauta.com

44

diferentes regiones del espacio. Se suele representar en función de ángulos de dirección centrados en la antena.26

La ganancia se define como la relación entre la densidad de potencia radiada en una dirección y la densidad de potencia que radiaría una antena isotrópica (antena ideal que radia la misma intensidad de radiación en todas las direcciones del espacio), a igualdad de distancias y potencias entregadas a la antena. Normalmente la ganancia se refiere a la dirección de máxima radiación de la antena, aunque en casos particulares puede referirse a una polarización concreta.

Para la banda de los 900 MHz se encuentran diferentes antenas, por ejemplo, una antena dipolo de 900 MHz como se muestra a continuación.

Figura 10. 900MHz Dipolo Antena Datasheet.

Fuente: 902 MHz – 928 MHz Dipole 2dBi Antenna for Reverse Polarity SMA [En línea] en: co.mouser.com. [Consultado el 2 de julio de 2019]. Disponible en internet: https://co.mouser.com/datasheet/2/986/001-0002-Datasheet-1628371.pdf

26 Ermanno, Rob. Antenas y Líneas de Transmisión. International Centre for Theoretical Physics. 2010. [Consultado el 8 de septiembre de 2018]. [En línea]. Disponible en internet: http://www.eslared.org.ve/walc2012/material/track1/03-Antenas_y_Lineas_de_Transmision-es-v3.0-notes.pdf

45

Existen diferentes tipos de antena omnidireccionales con mayor ganancia según el tipo de antena y sus dimensiones, sin embargo, esto puede afectar la portabilidad del dispositivo al aumentar el tamaño.

Figura 11. Antena omnidireccional AU09G8-HQ de Altelix.

Fuente: Altelix HQ-PRO9 Series 900 MHz Omni [En línea] en: docs.altelix.com. [Consultado el 2 de julio de 2019]. Disponible en internet: http://docs.altelix.com/datasheets/DS_HQ-PRO9_SERIES.pdf

5.4 BANDAS DE FRECUENCIA

Las bandas de frecuencia se definen como una pequeña sección de frecuencias del espectro radioeléctrico utilizado para comunicaciones por radio, y es utilizado para permitir el uso eficiente del espectro radioeléctrico y evitar así interferencias con aplicaciones similares para diferentes bandas de frecuencia.

Por lo anterior, existen divisiones importantes en el espectro de frecuencias, las bandas particulares, las bandas licenciadas y las bandas libres. Estos grupos de frecuencias varían en diferentes países debido a las regulaciones locales, pero están homologadas y se regulan a través de un organismo supranacional llamado UIT (Unión internacional de Telecomunicaciones).

46

Las bandas particulares son bandas de uso privativo normalmente compradas al organismo nacional regulador de las telecomunicaciones y solamente su dueño puede usarlas. Un ejemplo típico son las frecuencias de telefonía móvil (en rangos de 900 y 1800 MHz) donde las compañías tienen el uso exclusivo de estas bandas para dar el servicio requerido. Las bandas no licenciadas se definen en las frecuencias de libre utilización las cuales son aquellas donde cualquier persona puede transmitir sin necesidad de tener un permiso, estas son las bandas comprendidas entre 2,4 GHz y 5 GHz.

5.4.1 Banda Sub 1 GHz

En base al documento Cuadro Nacional de Atribución de Bandas de Frecuencia (CNABF) de la Agencia Nacional del Espectro (ANE), se encuentra que existe un rango en las frecuencias medias entre 902 Mhz y 928 Mhz que es permitido como banda libre compartida (aficionados), el uso de esta banda resulta mucho mejor que la banda de 2,4 GHz dado que se encuentra menos saturada de aplicaciones y usuarios por lo tanto posee menor interferencia, por su longitud de onda más grande permite un mayor alcance.

Tabla 8. Distribución de espectro para banda de aficionados.

Fuente: Elaboración propia.

47

5.4.2 Marco regulatorio en Colombia

Para lograr acceder al espacio radioeléctrico en Colombia se debe tener en cuenta las leyes y agencias que regulan el espectro que se quiere utilizar. Actualmente, la norma que regula las bandas de frecuencia de libre utilización dentro del territorio nacional es la resolución 689 DE 21 DE ABRIL DE 2004 (actualmente derogada por la resolución 711 DE 11 DE OCTUBRE DE 2016 cambiando parte de la norma) del ministerio de comunicaciones. Estableciendo que:

Articulo 5.- BANDAS DE FRECUENCIA: Se atribuyen dentro del territorio nacional, a título secundario, para operación sobre una base de no-interferencia y no protección de interferencia, los siguientes rangos de frecuencia radioeléctricas, para su libre utilización por sistema de acceso inalámbrico y redes inalámbricas de área local, que empleen tecnologías de espectro ensanchado y modulación digital, de banda ancha y baja potencia, en las condiciones establecidas por esta resolución.

a) Banda de 902 a 928 MHz b) Banda de 2400 a 2483,5 MHz c) Banda de 5150 a 5250 MHz d) Banda de 5250 a 5350 MHz e) Banda de 5470 a 5725 MHz f) Banda de 725 a 5850 MHz Articulo 6.- CONDICIONES OPERATIVAS EN LAS BANDAS DE 902 A 928 MHz, 2400 A 2483,5 MHz y DE 5725 A 5850 MHz: Son condiciones operativas para los sistemas de espectro ensanchado por salto de frecuencia y de modulación digital, en las bandas de 902 a 928 MHz, de 2400 a 2483,5 MHz, y de 5725 a 5850 MHz, las siguientes: A.1. Los sistemas de salto de frecuencia tendrán frecuencias portadoras por canal de intercalamiento separadas como mínimo por el mayor valor entre 25 KHz y el ancho de banda del canal a 20 dB. El sistema saltará a los canales de frecuencias que son seleccionados, de una lista de frecuencias de salto ordenada seudoaleatoriamente. Cada frecuencia se debe utilizar igualmente en promedio, por cada transmisor. Los receptores del sistema harán coincidir sus anchos de banda de entrada con los anchos de banda del canal de salto de sus transmisores correspondientes y cambiarán frecuencias en sincronización con las señales transmitidas. A.2. Los sistemas de salto de frecuencia en la banda de 902 a 924 MHz deben operar de la siguiente forma: si el ancho de banda del canal de salto a 20 dB es menor que 250 KHz, el sistema utilizará por lo menos 50 frecuencias de salto y el tiempo medio de la ocupación de cualquier frecuencia no será mayor a 0.4

48

segundos dentro de un período de 20 segundos. Si el ancho de banda del canal de salto a 20 dB es de 250 KHz o mayor, el sistema utilizará por lo menos 25 frecuencias de salto y el tiempo medio de la ocupación de cualquier frecuencia no será mayor a 0.4 segundos dentro de un período de 10 segundos. El ancho de banda máximo permitido del canal de saltos, a 20 dB, es 500 KHz. A.5. Los sistemas que utilizan técnicas de modulación digital pueden operar en las bandas de 902 a 928 MHz, de 2400 a 2483,5 MHz, y de 5725 a 5850 MHz. El ancho de banda mínimo a 6 dB debe ser de por lo menos 500 kHz; B. Potencia. La potencia de salida máxima del transmisor no excederá de lo siguiente: B.2. Para sistemas de saltos de frecuencia que funcionan en la banda de 902 a 928 MHz: Para los sistemas que emplean por lo menos 50 canales de saltos de frecuencia: 1 vatio. Para los sistemas que emplean menos de 50 canales de saltos de frecuencia, pero por lo menos 25 canales, según lo permitido bajo el numeral A.2 de este artículo: 0.25 vatios. B.3. Para sistemas que utilicen modulación digital en las bandas de 902 a 928 MHz, de 2400 a 2483,5 MHz, y de 5725 a 5850 MHz: 1 Vatio. B.4. Si se emplean antenas de transmisión de ganancia direccional mayor a 6 dBi, la potencia pico de salida de un transmisor debe ser reducida por debajo de los valores establecidos en los numerales B1, B2 y B3 de este artículo, como sea apropiado, por la cantidad en dB que la ganancia direccional de la antena exceda los 6 dBi. B.5. Los sistemas deben ser operados de tal forma que se asegure que el público no sea expuesto a niveles de energía de radiofrecuencia que excedan las normas que expida el Ministerio de Comunicaciones o el organismo estatal pertinente. C.1. En cualquier ancho de banda de 100 kHz fuera de la banda de frecuencias en la cual está operando el transmisor de espectro ensanchado o de modulación digital, la potencia de radiofrecuencia que es producida por el transmisor deberá ser al menos 20 dB menor que en los 100 KHz de ancho de banda dentro de la banda que contiene el más alto nivel de la potencia deseada, basado en una medición de RF bien sea conducida o radiada. D.1. Para sistemas modulados digitalmente, la densidad espectral de potencia conducida desde el transmisor a la antena no debe ser mayor a 8 dBm en cualquier segmento de 3 kHz durante cualquier intervalo de tiempo de transmisión continua.

49

G.1. Los sistemas del espectro ensanchado por saltos de frecuencia no requieren emplear todos los canales disponibles durante cada transmisión. Sin embargo, el sistema debe diseñarse conforme las normas de la presente resolución si el transmisor se presenta como una corriente continua de datos o información. Además, un sistema que emplee cortas ráfagas de transmisión debe cumplir con la definición de un sistema de saltos de frecuencia y debe distribuir sus transmisiones sobre el número mínimo de canales de salto especificado en esta resolución. H.1. Es permitida la incorporación de inteligencia dentro de un sistema de espectro ensanchado por saltos de frecuencia que posibilite al sistema reconocer a otros usuarios dentro de la banda del espectro de modo que elija y adapte individual e independientemente sus puntos de salto para evitar caer en los canales ocupados. La coordinación de sistemas de salto de frecuencia de cualquier otra forma, con el propósito expreso de evitar que múltiples transmisores ocupen simultáneamente frecuencias individuales de salto, no es permitida.27

5.5 NORMAS DE DISEÑO PARA CARCASA DEL DISPOSITIVO

Con el fin de proteger el dispositivo de factores ambientales o externos y teniendo en cuenta el usuario final del mismo, se realiza el diseño de la carcasa o cubierta que se podrá implementar a futuro, siguiendo las normas de diseño de dispositivos electrónicos como lo son los grados de protección IP, IK y aislamiento eléctrico.

Protección IP: El grado de protección IP hace referencia a la norma internacional CEI 60529 Degrees of Protection utilizado con mucha frecuencia en los datos técnicos de equipamiento eléctrico o electrónico. El sistema de clasificación IP proporciona un medio alfanumérico para evaluar el grado de protección de sólidos (como polvo) y líquidos (como agua) que los dispositivos electrónicos deben tener según su función.

27 Ministerio de comunicaciones. República de Colombia. Resolución número 000689 de 21 de abril de 2004 [en línea] en: http://legal.legis.com.co/. [Consultado el 20 de septiembre de 2018]. Disponible en internet: http://legal.legis.com.co/document/Index?obra=legcol&document=legcol_75992041f192f034e0430a010151f034

50

Figura 12. Nomenclatura CEI 60529

Fuente: CMATIC. Grado de protección IP. [En línea] en: https://www.cmatic.net/. [Consultado el 31 de enero de 2020]. Disponible en internet: https://www.cmatic.net/que-es-el-grado-ip-de-un-producto/

Tabla 9. Primer digito protección IP.

Fuente: NUOPLANET. Grados de protección IP [En línea] en: nuoplanet.com. [Consultado el 31 de enero de 2020]. Disponible en internet: https://nuoplanet.com/blog/grados-de-proteccion-ip/

51

Tabla 10. Segundo digito protección IP.

Fuente: NUOPLANET. Grados de protección IP [En línea] en: nuoplanet.com. [Consultado el 31 de enero de 2020]. Disponible en internet: https://nuoplanet.com/blog/grados-de-proteccion-ip/

Protección IK: El código IK es un sistema de codificación para indicar el grado de protección proporcionado por la envolvente contra los impactos mecánicos nocivos, salvaguardando así los materiales o equipos en su interior. Este código se designa con un número graduado de cero (0) a diez (10), a medida que va aumentando indica que la energía del impacto mecánico sobre la envolvente es mayor.

52

Tabla 11. Dígitos de protección IK.

Fuente: Ministerio de ciencia y tecnología. Significado y explicación de los códigos IP, IK [En línea] en: f2i2.net. [Consultado el 31 de enero de 2020]. Disponible en internet: http://www.f2i2.net/documentos/lsi/rbt/guias/guia_bt_anexo_1_sep03R1.pdf

Aislamiento eléctrico: El aislamiento eléctrico es un material cuyas cargas eléctricas internas no pueden moverse libremente; causando una escasa magnitud de corriente bajo la influencia de un campo eléctrico. A diferencia de los materiales conductores y semiconductores, que conducen fácilmente una corriente eléctrica. La característica fundamental que distingue a los materiales aislantes es su alta resistividad comparada con los semiconductores y conductores.28

28 SCELECTA. Aislamiento eléctrico. [en línea] en: scelecta.com. [Consultado el 31 de enero de 2020]. Disponible en internet: https://scelecta.com/que-es-el-aislamiento-electrico/

53

6. METODOLOGIA

Para la elaboración del plan detallado de la implementación del proyecto, se tomó como base una metodología de diseño estructurado y concurrente llamada DIP/IPP comprendida por 8 etapas, de las cuales se emplean 5, correspondientes a la planeación (ya que las otras etapas comprenden producción y comercialización del producto, por lo cual no son necesarias para este proyecto), tomando como referencia las siguientes etapas: desarrollo del concepto, diseño detallado, diseño a nivel de sistema, prototipos y la validación.

6.1 ETAPAS DEL PROYECTO

6.1.1 Diseño a nivel conceptual.

En esta etapa de la metodología, se definen los requerimientos del sistema y se obtiene la parte teórica que fundamenta el proyecto, con el fin de establecer la mejor alternativa que dé una solución al problema planteado. Para dicha etapa, se propusieron una serie de tareas correspondientes a temas como la transmisión de los datos, topologías de red, dispositivos de transmisión, entre otros.

Obtener material bibliográfico proveniente de fuentes confiables, que permitan definir el modelo o arquitectura que tendrá el dispositivo para el correcto envío y recepción de datos.

Analizar y comprender la topología de red en malla para transmitir datos de forma inalámbrica.

Establecer y analizar las características, ventajas y desventajas de la transmisión de datos digitales en banda de onda media. Estudiar los niveles definidos por el estándar IEEE 802.15.4 específico para conexiones inalámbricas con tasas bajas de transmisión de datos.

6.1.2 Diseño a nivel de sistema.

En esta etapa, se establecieron criterios para seleccionar componentes, módulos y datos necesarios para el proyecto.

54

Analizar las características de los posibles dispositivos a utilizar y comparar su funcionamiento con respecto a los dispositivos empleados en los otros medios de transmisión de datos.

Seleccionar componentes a emplear en el proyecto como microcontroladores, módulos transmisores y antenas con respecto a sus características establecidas en la hoja del fabricante (Datasheet).

6.1.3 Diseño detallado.

En esta etapa, se especificó detalladamente la parte hardware y software del proyecto, además de la parte algorítmica e interconexión entre funciones.

Hardware

Especificar funcionamiento y utilidad de los componentes físicos utilizados en el desarrollo del dispositivo.

Listar los componentes y/o partes del sistema hardware.

Software

Diseñar la arquitectura del programa mediante diagramas de flujo, identificando los módulos del programa y las características.

Definir la configuración y funciones de los dispositivos a emplear.

6.1.4 Implementación física (Prototipo).

En esta etapa se desarrolló el prototipo, siguiendo una serie de pasos con el fin de verificar el diseño y correcto funcionamiento del proyecto.

55

Implementar la parte lógica o algorítmica en los circuitos micro-controlados, analizando y evaluando el comportamiento en cuanto a adquisición y procesamiento de datos (prueba unitaria).

Integrar la parte hardware con el software, conectando el circuito micro-controlado con el módulo de transmisión, fuente de alimentación, entre otros componentes necesarios (prueba de integración).

6.1.5 Validación.

En esta etapa del proyecto se realizaron pruebas del correcto funcionamiento del sistema y se corrigieron algunos problemas de ejecución.

Evaluar el desempeño del sistema, teniendo en cuenta la adquisición de información, consumo energético y correcto envío y recepción de datos entre dispositivos.

Realizar pruebas de transmisión y recepción de datos entre dispositivos a una distancia corta, media y larga.

Analizar la respuesta del sistema ante diferentes parámetros generados por el entorno como lluvia u obstáculos en el camino.

56

7. DESARROLLO DEL SISTEMA DE COMUNICACIONES (DISEÑO A NIVEL CONCEPTUAL)

Para el presente proyecto se han determinado algunos requerimientos principales que debe cumplir el dispositivo, tales como:

- Portabilidad. - Bajo consumo de energía. - Baja tasa de transmisión de datos. - Uso de frecuencias medias (literal 5.4.2 Marco regulatorio en Colombia). - Soportar una topología de red en malla. - Permitir una comunicación bidireccional. - Rápido procesamiento (programación concurrente).

Por tal motivo, se indagó en diversas fuentes bibliográficas y se estableció la arquitectura base del dispositivo, teniendo en cuenta las diferentes opciones para su implementación a nivel hardware y software.

7.1 SISTEMA DE COMUNICACIONES

Con el fin de presentar un panorama amplio del sistema, en esta sección se muestra el diagrama de bloques general del sistema (teniendo en cuenta la estructura de un sistema de transmisión bidireccional común) donde se observan las componentes hardware y software principales.29

Figura 13. Diagrama de bloques de los dispositivos de comunicación.


29 J. E. Briceño. Principios de las comunicaciones. Edición digital lll. Venezuela: ULA, 2012.

57

Cabe resaltar que cada dispositivo estará conectado entre sí, formando una topología de red en malla como se presenta en el literal 5.1.1 (Topología de Zigbee) por lo tanto, se realiza un análisis de los posibles dispositivos físicos a utilizar.

7.2 COMPONENTES HARDWARE (DISEÑO A NIVEL DE SISTEMA)

7.2.1 Modulo Interfaz

Inicialmente se pensó realizar un dispositivo completo, el cual contaría con una pantalla y un teclado propio, en este caso un teclado qwerty miniatura y una pantalla led en la cual observar las acciones de entrada realizadas por medio del teclado (ver figura 14). Al tener en cuenta diferentes criterios como portabilidad, costo, peso, programación y diseño, se procede a proponer otras opciones y determinar cuál sería la más viable para este dispositivo, para ello se incluyeron otras dos opciones las cuales fueron una pantalla táctil OLED y el uso de una aplicación sobre un dispositivo móvil. Para la evaluación de los criterios se realiza una tabla donde se exponen las propuestas contra los criterios a los cuales se les da un peso diferente basado en la importancia que tendrá en el dispositivo.

Tabla 12. Criterios de evaluación para seleccionar interfaz de usuario.

Nota: Los criterios de evaluación son subjetivos teniendo en cuenta especificaciones técnicas de los dispositivos. Para este caso la programación cuenta con un valor de 30% debido al fácil diseño y prototipado que se busca del dispositivo; seguido por el costo, peso y portabilidad pensado en el usuario final a nivel comercial. Se presenta un intervalo de evaluación entre 1 y 5 siendo 1 la menor calificación y 5 la calificación más elevada.

58

Figura 14. Ejemplo teclado qwerty y pantalla para el dispositivo.

Fuente: Teclado qwerty Arduino [En línea] en: es.banggood.com. [Consultado el 10 de octubre de 2018]. Disponible en internet: https://es.banggood.com/M5Stack-CardKB-Mini-Keyboard-Module-MEGA328P-GROVE-I2C-USB-ISP-Programmer-for-ESP32-Arduino-Development-Board-STEM-Python-p-1539693.html?cur_warehouse=CN

Tras evaluar los criterios se determinó que emplear un dispositivo móvil o teléfono inteligente que ejecute una aplicación de mensajería sería mucho más económica y versátil, ya que se presta como interfaz hombre-máquina dándole mayor portabilidad al dispositivo y facilitando la interacción con el dispositivo por parte del usuario.

7.2.2 Módulo de procesamiento

Al iniciar el desarrollo del dispositivo y por el enfoque del proyecto, se pensó en utilizar Arduino como microcontrolador por razones de precio, compatibilidad con el teclado qwerty y la fácil programación de este y la pantalla, pero al avanzar en el desarrollo se encontró que esta plataforma permite el trabajo secuencial de su programación y para la realización de tareas paralelas se requiere del uso de interrupciones externas, las cuales son pocas en cuestión del uso y como se mencionaba anteriormente el dispositivo debe presentar versatilidad al momento de programar sus funcionalidades (hilos de procesamiento), por ende, se establecen criterios de selección tales como procesamiento, programación, consumo energético, costo, periféricos.

59

Tabla 13. Criterios de evaluación para seleccionar placa de prototipado.

Procesamiento (20%)

Programación (30%)

Consumo Energético

(20%)

Costo (20%)

Periféricos (10%)

Total (100%)

Arduino 2 3 4 4 2 3,1

Raspberry 5 5 2 3 4 3,9

Beaglebone 4 5 2 1 3 3,2

Nota: Los criterios de evaluación son subjetivos teniendo en cuenta especificaciones técnicas de los dispositivos. Para este caso la programación cuenta con un valor de 30% debido al fácil diseño y prototipado en la elaboración del dispositivo; seguido por el costo, procesamiento y consumo energético pensado en el usuario final brindándole comodidad y accesibilidad. Se presenta un intervalo de evaluación entre 1 y 5 siendo 1 la menor calificación y 5 la calificación más elevada.

Al avanzar en el proyecto se dio prioridad a los ordenadores de placa reducida teniendo en cuentas sus características más relevantes, facilitando la programación del dispositivo y optimizando el procesamiento de los datos enviados y recibidos.

60

Tabla 14. Aspectos técnicos de ordenadores de placa reducida.

Al revisar los criterios de evaluación el peso más importante lo tiene la programación del dispositivo en el cual al observar con detenimiento Raspberry y Beaglebone tienen la misma puntuación, esto se debe a que las dos son ordenadores de placa reducida y se puede ejecutar en ellos un sistema operativo que permite gran versatilidad al momento de escoger que lenguaje de programación se utilizara, pero en otros criterios como el procesamiento, aunque muy parejos, la mejor placa es la Raspberry gracias a su capacidad de memoria RAM, además de su costo, ya que una placa de Beaglebone puede tener un valor hasta dos veces más alto que una Raspberry.

7.2.3 Modulo Transceptor

Para el último y más importante elemento del dispositivo, se selecciona el modulo transceptor teniendo en cuenta la capa 1 (capa física) y la capa 2 (capa de enlace de datos) del modelo OSI. Capas encargadas de la topología de red – conexiones y direccionamiento y control de flujo respectivamente.

A continuación, se presenta una tabla de selección considerando los criterios establecidos en los objetivos, teniendo en cuenta las frecuencias de banda libre (900 MHz), alcance medio y bajo consumo energético, evaluando la tecnología de enlace inalámbrico a utilizar.

61

Tabla 15. Criterios de evaluación para seleccionar Tecnología de comunicaciones.

Frecuencia

(10%)

Consumo energético

(15%)

Alcance (30%)

Programación (25%)

Topología en Malla (20%)

Total (100%)

Z-Wave 4 3 3 2 5 3,5

ZigBee 5 4 5 4 5 4,6

Bluetooth 1 4 3 3 3 2,9

Teniendo en cuenta la funcionalidad del dispositivo final y considerando que existen otras tecnologías para el envío y recepción de datos, fueron descartados otros dispositivos para la evaluación ya que estos no cuentan con algún protocolo que permita generar una red multisalto, además de trabajar en frecuencias de 2,4 GHz la cual es una banda con poco alcance y se encuentra bastante saturada de diferentes aplicaciones de uso diario. Las tecnologías que se tuvieron en cuenta para el diseño finalmente fueron ZigBee y Bluetooth debido a que, si permiten una topología de red en malla, y adicionalmente se analizan otros aspectos importantes.

Aunque Z-wave y Zigbee tienen aplicaciones muy similares y permiten una topología de red en malla como se requiere, Zigbee tiene un rango de alcance mucho mayor (kilómetros) en comparación a los 100 metros que ofrecen los dispositivos de Z-wave, además de que los módulos de Zigbee (Xbee) son mucho más comerciales y permiten una fácil configuración, mientras que los dispositivos Z-wave al ser propiedad de Silicon Labs presentan parámetros más complejos para generar un enlace entre dispositivos Z-wave.

Por tal motivo, se determinó que el módulo a utilizar seria el XBEE S3B PRO 900 MHz. este módulo se ajusta a las necesidades del proyecto ya que en esta versión se reduce el consumo de energía por medio de un sistema de rápido encendido y apagado llamado Sleep Mode en el cual disminuye su consumo a 2,5 uA cuando no se encuentra realizando alguna tarea, posee un alcance de hasta 24 km teóricos con una antena de alta ganancia y de hasta 14 km con una antena dipolo (ver Anexo C). En comparación con la serie 2, la serie 3 cuenta con mejoras tales como su alcance, que pasó de metros a kilometros, disminución en el consumo de energía y uso de diferentes bandas de frecuencia a la banda ISM de 2,4GHZ como el rango de 902 – 928 MHz (ver Anexo D).

62

7.3 CONFIGURACION DE LOS MODULOS (DISEÑO DETALLADO)

7.3.1 Configuración inicial XBEE XSC S3B PRO 900 MHz

Para la configuración inicial del dispositivo se utilizó el programa DIGI XCTU el cual permite ejecutar comandos para modificar la actuación del módulo Xbee, empleando para este proyecto el módulo Xbee XSC S3B PRO 900 MHz. Se configuraron los siguientes parámetros siguiendo las especificaciones y criterios para el desarrollo e implementación del dispositivo. Cabe destacar que los campos de configuración que no están especificados se mantendrán en los valores por defecto que proporciona el programa.

Mascara de canal (CM)

Estos modulos XBee funcionan en un rango de frecuencia de 902,400 Mhz a 927,600 Mhz, estos se encuentran separados en 64 canales numerados de 0 al 63, estos canales de frecuencia se encuentran distribuidos cada uno con una diferencia de 400 KHz.

Adicional a lo anterior, existen módulos separados por regiones lo que bloquea de forma física ciertos canales esto por consideraciones de uso de frecuencia de ciertos países (ver tabla 16). Se destaca esto, ya que al realizar la compra de los primeros dos módulos estos podían trabajar en todas las frecuencias ya que comprendían la región EEUU/Canadá, pero el tercer módulo al realizar la compra no se tuvo el cuidado verificar la región de trabajo, por ello hubo que realizar modificaciones en este campo para que todos los módulos se lograran comunicar en los mismos canales de frecuencia como se muestra en la figura 15.

63

Tabla 16. Tabla de canales de frecuencia por regiones.


Identificador de red (Network ID)

Cada módulo que se quiera comunicar en la misma red requiere tener el mismo identificador para asi reconocer que pertenece a esa red, si algún dispositivo tiene un valor diferente en este apartado no podrá comunicarse en otra red, para este proyecto toda la red se identificó como 1206 (ver figura 15).

Nivel de poder de transmisión (PL - TX Power Level)

En este campo se puede configurar el nivel de potencia que se quiera utilizar en el módulo, este cuenta con cinco distintos niveles de potencia (ver tabla 17), para este proyecto se configuro en la potencia más alta ya que para el funcionamiento se requiere que el mensaje recorra la mayor distancia posible de un dispositivo a otro.

64

Tabla 17. Opciones de configuración de potencia de transmisión.


Figura 15. XCTU parámetros MAC/PHY.


Node Messaging Options (CE).

En este campo se configura el modo en que se va a utilizar el modulo, este cuenta con tres diferentes modos, estos son modo coordinador, enrutador o dispositivo

65

final, esta configuración se utiliza mucho más en una distribución de red en malla tradicional, el dispositivo debe dejarse en la configurado como coordinador ya que se optó por no utilizar una distribución DigiMesh (ver figura 16) el cual permite que todos los dispositivos puedan funcionar en todos los modos sin ninguna jerarquía padre-hijo lo cual permite una mayor flexibilidad para expandir la red y mayor fiabilidad ya que los dispositivos pueden desaparecer de la red sin interferirla o dañarla.

Figura 16. Nodos Digi Mesh.

Fuente: Electrónica diseño. Wireless Mesh Networking ZigBee vs. DigiMesh [En línea] en: hqwertyuiop.blogspot.com. [Consultado el 10 de octubre de 2019]. Disponible en internet: http://hqwertyuiop.blogspot.com/2015/10/wireless-mesh-networking-zigbee-vs.html

Identificador de nodo (NI)

Este es el nombre que se le proporciona al dispositivo como nombre o descripción del mismo para reconocerlo dentro de la red. Este campo puede ser llenado hasta con 20 caracteres ASCII.

66

Figura 17. XCTU parámetros de red y direccionamiento.


Modo AP

En este campo se configura el modo en el cual el modulo va a trabajar, en este caso se configuro en el modo dos el cual es el modo de operación API con caracteres de escape.

67

Figura 18. XCTU parámetros de interfaz serial.


7.3.2 Configuración inicial de Raspberry pi 3+

Para la configuración inicial de la Raspberry se debe instalar un sistema operativo para el cual fue seleccionado Raspbian, este es un OS basado en Linux diseñado para el ordenador de placa reducida (SBC) seleccionada para el proyecto, para ello se requiere de una memoria SD de mínimo 8 GB de espacio para instalar la imagen del OS, esta se descarga de la página web oficial de Raspberry, en la misma se explica cómo instalar la imagen en la memoria para proceder a insertarla en la ranura física del SBC.

Ya teniendo el sistema operativo instalado, se procede a realizar las configuraciones iniciales esto basado en el diseño inicial del dispositivo y en otros requerimientos al momento de programar las funciones de la implementación. Para programar todas las funciones de comunicación que se verán más adelante se requiere la instalación de ciertos programas y paquetes que permitan el funcionamiento completo de todo el programa. Este acondicionamiento de sistema se realiza sobre la interfaz de línea de comandos CLI.

68

Paso 1: Instalación de librerías Python.

Para el desarrollo del script de funciones del dispositivo, se instala la librería de conexión serial al compilador de Python, ya que el transceptor estará conectado por puerto serial al ordenador de placa reducida (Raspberry). Para la instalación de estas librerías se procede a introducir la siguiente línea sobre el CLI.

- sudo apt-get install python-serial

Ya que la se optó por la utilización de una aplicación móvil se definió el uso de un medio inalámbrico para conectarse al celular desde la Raspberry haciendo uso de los periféricos que nos ofrece esta plataforma en este caso el modulo bluetooth, para poder utilizarlo sobre el compilador se instala la siguiente libreria.

- sudo apt-get install python-bluetooth

Paso 2: Librería bluetooth para lectura de socket.

Antes de iniciar cualquier software para la configuración de comunicación bluetooth en la Raspberry Pi se debe actualizar el sistema completo con los siguientes comandos.

- sudo apt-get update

- sudo apt-get upgrade

Tras finalizar la actualización del sistema, se instala BlueZ el cual es un programa de código abierto que hace parte de kernel oficial Linux que utiliza un grupo de protocolos todos soportados sobre los protocolos base de bluetooth. Se instala con la siguiente línea en el CLI, por último, se procede a reiniciar el dispositivo.30

30 Circuit digest. “Controlling Raspberry Pi GPIO using Android App over Bluetooth.” [en línea] en: circuitdigest.com. [Consultado el 10 de octubre de 2019]. Disponible en internet:

69

- sudo apt-get install bluetooth blueman bluez

Paso 3: Modificación de archivo bluetooth para abrir y escuchar puerto.

Después de instaladas las librerías para el funcionamiento del socket, se debe modificar el archivo de configuración del servicio para que pueda ser utilizado en el compilador de python libremente, se abre el archivo con cualquier editor de texto de Linux en este caso vim

- sudo vim /etc/systemd/system/dbus-org.bluez.service

Al abrir el archivo se debe agregar la bandera de compatibilidad ‘-C’ al finalizar la línea de comando ‘ExecStart=’, luego de esto se agrega una línea de comando con el SDP (Support Diagnostics Platform).

- ExecStart=/usr/lib/bluetooth/bluetoothd –C

- ExecStartPost=/usr/bin/sdptool add SP

Por último, se guarda y cierra el archivo para proceder al paso final para que se pueda conectar una aplicación externa y esta sea leída por el puerto bluetooth abierto por medio del compilador de Python con su librería PySerial.31

- sudo rfcomm watch hci0

Paso 4: Configuración de inicio automático para script.

Ya que se requiere que el sistema sea completamente autónomo por lo cual las configuraciones que realizara el usuario final serán mínimas, y entre estas el inicio del script de comunicaciones debe arrancar cuando se encienda el dispositivo y así

https://circuitdigest.com/microcontroller-projects/controlling-raspberry-pi-gpio-using-android-app-over-bluetooth

31 Raspberrypi.org. “Use app to Connect to pi via Bluetooth” [en línea] en: raspberrypi.org. [Consultado el 10 de octubre de 2019]. Disponible en internet: https://www.raspberrypi.org/forums/viewtopic.php?p=947185#p947185

70

activar todas las funciones programadas en este, para ello se debe realizar lo siguiente.

Se abre una ventana de terminal de comandos y se ingresa a la carpeta inid.d en ella se crea un archivo llamado detector-init, con el siguiente comando y se agrega el código de la figura 19.

- sudo vim /etc/init.d/detector-init

Figura 19. Script de ejecución de inicio automático.

Fuente: Cómo ejecutar un programa automáticamente al arrancar la Raspberry Pi [En línea] en: nideaderedes.urlansoft.com. [Consultado el 10 de octubre de 2019]. Disponible en internet: https://nideaderedes.urlansoft.com/2013/12/20/como-ejecutar-un-programa-automaticamente-al-arrancar-la-raspberry-pi/

La única modificación que se le realiza al código es en una parte de la línea 20 en donde se debe modificar la ubicación del programa que se requiere arranque automáticamente. La sección que se modifica es “/home/pi/detector.py”, siendo “home” la carpeta de usuario, las secciones centrales (donde esta “pi”) se modifican dependiendo de las subcarpetas en donde se encuentre el script y por ultimo

71

“detector.py” se cambia por el nombre del script que se requiera iniciar de forma automática.

Ahora que se tiene el script modificado, se procede a brindarle permisos de ejecución al archivo y darle inicio al script.

sudo chmod 755 /etc/init.d/detector-init

sudo /etc/init.d/detector-init start

Como último paso y para que el sistema inicie de forma automática el programa se debe modificar el archivo de arranque de la maquina incluyendo el script en los archivos de arranque por defecto de la siguiente forma.

sudo update-rc.d detector-init defaults

Como anotación para remover un programa del inicio automático se emplea la siguiente línea sobre la ventana de comandos.

sudo update-rc.d -f apache2 remove

7.4 IMPLEMENTACIÓN SOFTWARE

7.4.1 Desarrollo aplicación móvil

Para el desarrollo del terminal bluetooth o aplicación móvil que permite la conexión entre el dispositivo de comunicación para emergencias y el celular, se hace uso de un repositorio de GitHub llamado SimpleBluetoothTerminal 32.

32 MORICH, Kai. Simple Bluetooth Terminal [en línea] en: github. (2019). [Consultado el 10 de octubre de 2019]. Disponible en internet: https://github.com/kai-morich/SimpleBluetoothTerminal

72

Este repositorio ofrece un código fuente realizado en Android Studio el cual permite la conexión entre el celular y otro dispositivo (en este caso, el nodo de comunicación) a través de un socket Bluetooth. Este aplicativo modificado según los requerimientos del proyecto.

A continuación, se presenta el diagrama de flujo que describe el funcionamiento de la aplicación y los aspectos más importantes del código (este se podrá encontrar en su totalidad en los anexos digitales):

Figura 20. Diagrama de funcionamiento de aplicación móvil Bluetooth.


73

7.4.2 Algoritmo del protocolo de comunicaciones

Para el desarrollo del protocolo de comunicación implementado en los dispositivos se hizo uso de dos hilos de procesamiento desarrollados en código Python. A continuación, se presenta un esquema macro donde se presentan los procesos que se ejecutan en el código a nivel general.

Figura 21. Diagrama macro de funcionamiento del código.


Como se observa en la figura 21, el modulo Bluetooth se encarga de la recepción del mensaje enviado por el dispositivo móvil y construcción de la trama API para enviarla a través del módulo Xbee como se presenta detalladamente a continuación en la figura 22.

74

Figura 22. Diagrama de flujo del hilo Bluetooth.


Por otra parte, el hilo de procesamiento “Modulo” se encarga del proceso inverso al hilo “Bluetooth” es decir, recibe las tramas enviadas, las decodifica y las envía a través del socket Bluetooth para que el usuario pueda visualizar los mensajes en su dispositivo móvil. En la sección de Anexos se presenta el código implementado en Python para el correcto funcionamiento de los dispositivos de comunicación.

75

Figura 23. Diagrama de flujo del hilo Modulo.


76

7.5 IMPLEMENTACIÓN HARDWARE (IMPLEMENTACIÓN FISICA)

El dispositivo o nodo de comunicación está compuesto por los elementos previamente mencionados en el literal 7.2 (Componentes hardware) como se muestra a continuación en la figura 24:

Figura 24. Componentes hardware del dispositivo de comunicación.


Se realiza la conexión entre la raspberry y el módulo Xbee (junto con la antena) a través de un cable con terminales USB y mini USB, estableciendo la comunicación serial entre dichos componentes. Por otra parte, se conecta un cable entre el terminal USB del módulo de batería y el terminal micro USB de la raspberry para alimentar la placa y poder ejecutar el script que permite la comunicación entre nodos y dispositivos móviles. A continuación, se presenta una ilustración del funcionamiento de los nodos en una comunicación punto a punto (figura 25).

Figura 25. Funcionamiento del sistema.


77

7.6 DISEÑO CARCASA DEL DISPOSITIVO

Siguiendo todas las recomendaciones presentadas en el literal 5.5 (Normas de diseño para carcasa del dispositivo), se presenta el diseño de una carcasa de acrílico o plástico tipo ASA (Acrylonitrile Styrene Acrylate) para el dispositivo de comunicaciones inalámbricos debido a su resistencia mejorada a la intemperie 33 garantizando una protección IK04 para caídas como máximo de un metro de distancia con respecto al suelo tolerando una energía de impacto de 0,5J teniendo en cuenta el peso del dispositivo (que no supera 1kg) y una protección IP45, ya que aunque el dispositivo no se encuentra completamente cubierto porque tiene puertos abiertos como se muestra en la figura 36 este cuenta con protectores para los puertos, permitiendo el sellado completo del envolvente. Por otra parte, el tipo de material está certificado por el estándar IEC 60093 con una resistencia eléctrica de 10^14 Ohm.34 Los planos de la carcasa del dispositivo y el archivo cad con dimensiones se presentan en el anexo del repositorio institucional.

33 OKW. ASA VS ABS: ¿QUÉ PLÁSTICO ES EL MEJOR? OKW [en línea] en: okw.co.uk. [Consultado el 31 de enero de 2020]. Disponible en internet: https://www.okw.co.uk/en/news/blog/1806-asa-vs-abs-plastic-enclosures.htm

34 OKW. CAJAS IP65 / IP66 / IP67 [en línea] en: okw.com. [Consultado el 31 de enero de 2020]. Disponible en internet: https://www.okw.com/es/Productos/Cajas-IP65-IP66-IP67.htm

78

Figura 26. Modelo 3D Carcasa

(a) Vista Frontal, Lateral Derecha

(b) Vista frontal, lateral izquierda


79

8. VALIDACION DEL SISTEMA DE COMUNICACIÓN

Para probar el correcto funcionamiento de los dispositivos se realizan pruebas de comunicación entre dos y posteriormente tres nodos para medir el alcance máximo de envío y recepción de datos, además de validar la topología de red en malla.

8.1 TOPOLOGIA PUNTO A PUNTO (DOS NODOS)

Se realizaron pruebas con los dispositivos en campo abierto (Zona sur de Cali - Pangola) con el objetivo de observar la distancia máxima que existe entre un nodo y otro sin perder comunicación, teniendo en cuenta obstáculos urbanos como árboles, postes y algunos vehículos.

Figura 27. Distancia entre nodos para topología punto a punto.


Como se observa en la figura 27, el recorrido en línea recta es aproximadamente 1,9 km, distancia máxima a la cual los mensajes eran recibidos entre los módulos de comunicación. Las coordenadas de los puntos son:

80

- Punto inicial (Indicador rojo): Latitud: 3.271653, Longitud: -76.541161. - Punto final (Avenida sachamate): Latitud: 3.283301, Longitud: -76.528943.

8.1.1 Medición de radio propagación con XCTU

Inicialmente, se hace un análisis de canales, donde el módulo Xbee a través de mensajes de broadcast y comandos At remotos hace el reconocimiento de dispositivos cercanos que se encuentren en la misma red. Como se observa en la figura 28 el Modulo R3 reconoce al módulo R2 y establece el enlace para el intercambio de mensajes.

Figura 28. Diagrama de enlace de módulos Xbee punto a punto.


Se realizó un análisis de RSSI o fuerza de la señal recibida entre los dos dispositivos con el software XCTU a lo largo del recorrido como se muestra en la figura 29.

81

Figura 29. Análisis de intensidad de la señal (topología punto a punto).


El recorrido por carretera duró aproximadamente 2 minutos, tiempo que se muestra en el gráfico de la figura 29. Como se puede observar, la intensidad de la señal inicialmente entre los dos módulos es aproximadamente -86dBm y va mejorando a lo largo del recorrido ya que la distancia entre los dispositivos se va reduciendo, aunque aún no tienen línea de vista libre.

Se pueden apreciar dos instantes o intervalos de tiempo en los cuales la intensidad de la señal tiene cambios significativos. En el intervalo comprendido por 23:16:30 y 23:17:00 la señal tiene un pequeño decremento (Ver figura 30), esto se debe a las condiciones del terreno ya que por ese sector había mayor cantidad de árboles, además de un separador de lámina de acero a lo largo de la vía y durante la prueba había un camión estacionado en dicha curva.

82

Figura 30. Condiciones del terreno (topología punto a punto).


Por otra parte, el intervalo comprendido por el instante 23:17:00 en adelante se observa como la señal mejora instantáneamente con una intensidad de -40dBm; estos datos hacen alusión al momento en que se pasa la curva del recorrido y se entra a la línea recta de la vía como se observa en la figura 31, en ese instante la línea de visión entre las antenas de los dispositivos de comunicación es directa (sin ningún obstáculo en medio).

83

Figura 31. Intensidad de la señal con línea de vista entre antenas (topología punto a punto).


8.1.2 Simulación de radio propagación

Con el objetivo de tener un referente teórico, se simularon las mismas pruebas en el software Radio Mobile, teniendo en cuenta la frecuencia en la que transmiten los módulos Xbee (900 MHz), las condiciones del terreno, la ganancia de las antenas, la sensibilidad de los dispositivos, entre otros factores.

84

Figura 32. Zona de cobertura de antena punto a punto.


En la figura 32 se observan los dos módulos ubicados en las coordenadas antes expuestas; alrededor de ellos se observa el radio de cobertura de un nodo, mostrando el limite o alcance máximo al cual llega la señal con una intensidad de -101dBm (sensibilidad del cada nodo).

Figura 33. Enlace entre antenas punto a punto.


85

En la simulación del enlace de las antenas se obtiene una potencia de recepción de -88,2 dBm como se muestra en la figura 33, valor muy cercano al obtenido en las pruebas de campo realizado con los dispositivos (aproximadamente -86 dBm); estos valores varían poco ya que como se observa en la figura, se expone un enlace con línea de visión directa entre antenas, mientras que en las pruebas con los módulos habían muchos obstáculos como árboles, vehículos, separadores, entre otros, sin embargo, se establecieron algunas perdidas por obstrucciones y sector urbano haciendo más cercanos a la realidad los resultados.

8.2 TOPOLOGIA EN MALLA (TRES NODOS)

A continuación, se presentan diferentes tipos de pruebas (al aire libre y en entornos cerrados) de la topología en malla con el fin de analizar distancias e intensidad de señal de los dispositivos, validando así su funcionalidad y eficiencia.

8.3 TOPOLOGIA EN MALLA EN INTERIORES

Se realizó una prueba de la malla (específicamente el salto que hace el mensaje para llegar a un dispositivo fuera de alcance) en el sótano 2 de la universidad autónoma de Occidente donde se presentan múltiples obstáculos como paredes de concreto, puertas de vidrios, mesas, sillas, entre otros.

Figura 34. Diagrama de enlace de módulos Xbee en malla (indoor).


86

Los nodos estaban ubicados de la siguiente forma:

- R1: Sala 1 de simulación (al lado del laboratorio de electrónica) - R2: FabLab - R3: Laboratorio de telecomunicaciones

Como se observa en la figura 34 no hay conexión directa entre R2 y R3 por lo cual el mensaje debe realizar un salto en R1 para poder llegar a cada extremo.


Figura 35. Intensidad de señal entre Nodo R1 y nodo R3.


Como se observa en la figura 35 la intensidad de la señal recibida es de -70 dBm aproximadamente ya que el nodo del laboratorio de telecomunicaciones (figura 49)

87

no tiene una antena de conector SMA como los otros, por lo tanto, la intensidad de la señal es menor pero igualmente llegan todos los mensajes y no se pierde información a pesar de los obstáculos.

Figura 36. Intensidad de señal entre Nodo R2 y nodo R3.


Por otra parte, se hace una prueba de enlace entre R3 y R2 (extremo a extremo) pasando a través del nodo R1; como se observa en la figura 36 la intensidad de la señal recibida por el modulo remoto R2 es de -40 dBm, esto se debe a que este módulo tiene una antena con ganancia de 2.1 dBi al igual que el nodo R1, por tal

88

motivo, la comunicación entre R1 y R2 tiene una mayor intensidad de señal y el mensaje que llega desde R3 es propagado con una mayor potencia.

8.3.2 Análisis de distancia con estimador de Texas Instruments

Debido a la pequeña distancia que recorre el mensaje al interior del sótano por la cantidad de obstáculos presentes, además de no haber línea de vista entre antenas, se hace uso de una hoja de cálculo desarrollada por Texas instrumens 35 para estimar la distancia y la intensidad de señal recibida según las características del módulo y del terreno.

Figura 37. Estimador de distancia e intensidad de señal de Texas Instruments.


Como se observa en la figura 37 se tienen en cuenta la altura de los módulos, además de la potencia transmitida (se establece 26 dBm ya que el software no permite modificar ganancia de antenas por lo tanto se le suma la ganancia directamente) y factores atenuantes mencionados previamente; obteniendo resultados muy coherentes con la realidad ya que la distancia entre los módulos era 35 TI RF Range Estimator. [Consultado el 12 de octubre de 2019]. Disponible en internet: http://www.ti.com/tool/RF-RANGE-ESTIMATOR#descriptionArea

89

inferior a los 50 metros y la intensidad de señal recibida entre los modulos con antena era de -40 dBm, valor que coincide con el estimador de Texas Instruments.

8.4 TOPOLOGIA EN MALLA EN EXTERIORES

Para evaluar el correcto funcionamiento de los dispositivos, se realizaron pruebas con los tres nodos en campo abierto al igual que en la prueba punto a punto (Zona sur de Cali - Bochalema). Dichas pruebas permitieron conocer el área de cobertura entre los tres nodos, evaluar el salto entre los mismos al establecer una comunicación remota o enlace entre dos dispositivos pasando a través de un tercero, además de analizar el espectro o intensidad de la señal para tener una idea del alcance máximo al cual aún se puede establecer un enlace. Cabe resaltar que estas pruebas se realizaron en condiciones de precipitación (lluvia) y en un terreno forestalmente poblado (muchos árboles en la zona).

Figura 38. Distancia máxima de recorrido en malla (Outdoor).


90

Como se observa en la figura 38, el recorrido en línea recta de extremo a extremo es aproximadamente 2,8 km, distancia máxima que se logró entre módulos empleando la topología en malla; esto con el fin de evaluar el salto del mensaje a través de otro dispositivo (router) llegando a los módulos que estén fuera de alcance. Las coordenadas de los puntos son:

- Punto inicial (Nodo 1): Latitud: 3.368268, Longitud: -76.487749. - Punto intermedio (Nodo 2): Latitud: 3.364152, Longitud: -76.494894. - Punto final (Nodo 3): Latitud: 3.358108, Longitud: -76.510414.

En comparación a la prueba de la topología punto a punto, se puede observar que se logró aproximadamente un kilómetro más de distancia; esto se debe a que el Nodo 1 (ver figura 39) no dispone de una antena omnidireccional, sino que tiene soldado un cable que hace las veces de antena al no tener conector tipo SMA.

Figura 39. Módulo Xbee pro sin conector SMA ni antena.


91


Al igual que en la prueba de punto a punto, se hace un análisis de canales con el modulo para identificar los otros nodos que se encuentran en la red. Como se observa en la figura 40 los 3 nodos se encuentran conectados, pero R1 y R3 se comunican a través de R2 ya que no se encuentran en el área de cobertura.

Figura 40. Diagrama de enlace de módulos Xbee en malla (outdoor).


Inicialmente se hace el análisis de radio frecuencia entre el Nodo 1 y el Nodo 2 como se muestra en la figura 41 para encontrar la distancia máxima a la cual puede estar el router intermediario y posteriormente hacer el análisis de radio frecuencia entre el Nodo 1 y el Nodo 3 para documentar la distancia máxima de cobertura de toda la red.

92

Figura 41. Distancia máxima entre dos nodos (Outdoor).


La intensidad de la señal recibida es de -78 dBm a la máxima distancia, es decir a 900 m y se puede observar la disminución del porcentaje de éxito y la perdida de algunos paquetes, esto debido a que durante la prueba el modulo estaba en movimiento, por lo tanto, en un momento se excedió la máxima distancia (donde se observa el decremento de la curva gris del range test) y luego al retornar a dicha posición la intensidad de la señal intenta mejorar y se mantiene estable permitiendo la recepción de mensajes.

93

Figura 42. Distancia máxima entre tres nodos (Outdoor).


Por último, se realizó la prueba de enlace entre el Nodo 1 y el Nodo 3 validando que la malla funcione y el mensaje pueda llegar hasta el último destino a través de un intermediario. La potencia recibida por el Nodo 3 es de -78 dBm como se observa en la figura 42 y el porcentaje de éxito va disminuyendo ya que a esta distancia se comienzan a perder algunos paquetes debido a la curva de la carretera, haciendo que se presenten obstáculos (como edificaciones y más arboles) entre los nodos, por lo tanto, esta fue la distancia máxima seleccionada en la cual se puede mantener una conversación estable a través de los dispositivos.

8.4.1 Simulación de radio propagación

Con el objetivo de tener un referente teórico al igual que en la prueba de topología punto a punto, se simuló la misma prueba en el software Radio Mobile, teniendo en cuenta la posición de cada módulo y la frecuencia en la que transmiten, las condiciones del terreno, la potencia de transmisión, la ganancia de las antenas, la sensibilidad de los dispositivos, entre otros factores.

94

Figura 43. Zona de cobertura de Nodo 1 en topología malla (Outdoor).


En la figura 43 se observan los tres nodos en las coordenadas previamente expuestas; alrededor de ellos se observa el radio de cobertura del nodo 1, mostrando el limite o alcance máximo al cual llega la señal con una intensidad de -101dBm (sensibilidad de cada nodo). Este análisis de cobertura se realiza teniendo en cuenta una línea de vista directa entre antenas.

95

Figura 44. Enlace entre Nodo 1 y Nodo 2 en topología malla (Outdoor).


Como se observa en la figura 44, el nodo 2 tiene una potencia de recepción de -82,1 dBm, valor que difiere por -4 dBm al valor obtenido en las pruebas de campo realizado con los dispositivos; se debe tener en cuenta que estos valores varían debido a que las condiciones del entorno no son ideales y aunque hubiera la mayor línea de vista entre antenas, igualmente había algunos árboles en el camino y un poco de lluvia.

96



Al igual que en la simulación de radio Mobile para la prueba de topología punto a punto, se presenta el enlace entre los dos módulos con antenas de 2.1 dBi (ver figura 45), obteniendo una potencia de recepción de -87,2 dBm. Este valor difiere en -9 dBm al valor real obtenido (-78dBm) presentando una mejor potencia de recepción con los módulos reales.

97

Por último, se hace la simulación del enlace entre el nodo 1 y el nodo 3 (ver figura 46), observando que se tendría una potencia de recepción de 94,9 dBm muy cercana a la sensibilidad máxima del módulo (-101 dBm) pero esto ocurre cuando los módulos tienen línea de vista entre sus antenas; por tal motivo en la realidad a esta distancia debido a los árboles y demás factores del entorno (algunas construcciones) ya no se recibía el mensaje, por lo tanto, al poner un módulo intermedio se garantizaba la llegada de dicho mensaje a todos los dispositivos.



98

8.5 CONSUMO DE ENERGIA

Finalmente, se realizó la prueba de consumo de energía del dispositivo de dos formas. Para la primera se dejó el dispositivo encendido y funcionando, enviando un mensaje en intervalos de 5 minutos obteniendo la descarga completa de la batería en aproximadamente 10 horas y 20 minutos. En la segunda prueba se abrió el circuito de carga entre el módulo de la batería y el dispositivo, midiendo la corriente que consume el nodo obteniendo un valor constante de 310 mAh y aumenta a 320 mAh cuando se envía o recibe un mensaje como se muestra en la figura 47.

Figura 47. Consumo en Amperios del módulo de comunicación.


El módulo de batería es de 5Vdc y 3400 mAh y la tensión necesaria para alimentar el modulo completo es de 5Vdc por lo tanto se pueden despreciar las tenciones y calcular el número de horas de trabajo del dispositivo de la siguiente forma:

𝑁𝑢𝑚𝑒𝑟𝑜 𝑑𝑒 𝐻𝑜𝑟𝑎𝑠 𝐶𝑜𝑟𝑟𝑖𝑒𝑛𝑡𝑒 𝐻𝑜𝑟𝑎 𝑑𝑒 𝑙𝑎 𝑏𝑎𝑡𝑒𝑟𝑖𝑎𝐶𝑜𝑟𝑟𝑖𝑒𝑛𝑡𝑒 𝑞𝑢𝑒 𝑑𝑒𝑚𝑎𝑛𝑑𝑎 𝑙𝑎 𝑐𝑎𝑟𝑔𝑎

3.400 𝑚𝐴ℎ

320 𝑚𝐴 11 ℎ𝑜𝑟𝑎𝑠

99

El valor teórico obtenido es muy cercano al tiempo de funcionamiento que tuvo el dispositivo enviando mensajes durante intervalos de tiempo; tiempo que depende netamente de la batería, ya que al implementar una batería de mayor capacidad tendrá un mayor tiempo de vida el dispositivo.

100

9. CONCLUSIONES

El proyecto logró cumplir con los objetivos planteados satisfactoriamente, obteniendo como resultado final el dispositivo de comunicación portátil de mediano alcance para situaciones de emergencia o perdida de cobertura de la red wifi y telefónica, permitiendo además evaluar y cuestionar las tecnologías actuales de programación y radiocomunicación con el fin de pensar en mejoras a futuro.

El uso de un hardware para rápido prototipado como lo es la Raspberry, permitió realizar múltiples pruebas que conllevaron al diseño final del dispositivo, sin embargo, al ser una plataforma con tantos terminales y puertos que no se emplean (como lo es el caso del módulo wifi, algunos puertos USB, puerto ethernet, entre otros), genera un mayor consumo de energía y mayor tamaño.

El uso de los módulos Xbee permite un enlace a larga distancia, no solo por la banda de frecuencia en la que operan (900 MHz), sino también por la posibilidad de adaptarle una antena con ganancia que mejore la intensidad de la señal. Por otra parte, permiten un enlace punto – multipunto o malla gracias a las posibles configuraciones que presenta el dispositivo, estableciendo un enlace seguro por su tipo de modulación y modo de operación, accediendo al canal por medio de CSMA/CA, evitando colisiones entre los paquetes de datos.

Con el fin de evitar el uso de una interfaz embebida en el mismo dispositivo, se desarrolló un aplicativo móvil donde se crea un terminal Bluetooth para establecer un enlace entre el dispositivo móvil o celular del usuario y el dispositivo de comunicación o nodo. Esta aplicación se encuentra instalada en el dispositivo para que la persona la pueda descargar en una configuración inicial, sin embargo, se puede hacer uso de cualquier otro terminal Bluetooth, ya que estos son compatibles con el script ejecutado en el nodo.

La herramienta XCTU de Digi, propia de la empresa que fabrica y distribuye los módulos Xbee permite una fácil y rápida configuración de los dispositivos, además de ofrecer herramientas importantes para el análisis del espectro como el analizador de enlace e intensidad de señal o el estimador de paquetes perdidos durante la comunicación.

Finalmente se validó el correcto funcionamiento de los dispositivos y se logró estimar distancias máximas en la ciudad, lugar en el cual se realizaría el mayor uso de dichos nodos, cumpliendo con los objetivos establecidos.

101

10. RECOMENDACIONES Y TRABAJO FUTURO

Una vez realizadas todas las pruebas de funcionamiento del dispositivo y validar su correcto funcionamiento, se establecen nuevos objetivos o metas que logren complementar el dispositivo, dándole un enfoque más completo y comercial según las necesidades de los usuarios.

Optimización de dispositivo: Se puede cambiar la placa de diseño o microcontrolador en el cual se desarrolla el código de comunicación; esto con el fin de cambiar la placa de rápido prototipado, dejando solo los terminales que requiera el usuario y reducir el consumo energético del dispositivo y darle un mayor tiempo de funcionamiento o independencia.

Seguridad: Darle un enfoque punto a punto a los dispositivos, donde los mensajes ya no sean de difusión para todos los nodos, sino que se pueda establecer una comunicación direccionada, donde, aunque la información rebote entre todos los nodos, solo la pueda decodificar el destinatario.

Seccionar por canales: Con un enfoque más comercial o privado, se pueden modificar las máscaras e identificadores de Red para tener canales según el departamento o grupo de personas que lo vayan a utilizar (Por ejemplo, los diferentes departamentos de una empresa).

Localización y amplificación de la malla: Con el fin de ofrecer una mayor cobertura de comunicación entre dispositivos, se podrían disponer algunos nodos fijos (routers con antenas de alta ganancia) en lugares estratégicos como centros comerciales, hospitales, universidades, entre otros, que permitan el “rebote” de los mensajes, aumentando la cobertura de la señal.

102

BIBLIOGRAFÍA

Academia de Networking de Cisco System (2006). Fundamentos de Redes Inalámbricas. Madrid: Pearson Educación, S.A.

BARNEDA FAUDOT, Iván. ZigBee aplicado a la transmisión de datos de sensores biomédicos [En línea]. Facultad de Ingeniería, Universidad Autónoma de Barcelona. España: Editorial Universitaria. [Consultado el 12 de marzo de 2018]. Disponible en internet: https://ddd.uab.cat/pub/trerecpro/2008/hdl_2072_13081/PFC_Ivan_Barneda.pdf

BRICEÑO, José. Transmision de Datos. 3ra Ed. Mérida, Venezuela 2003. Taller de publicaciones de la Facultad de Ingeniería, ULA. 149 p.

CARDAMA, Angel. Antenas. 2da Ed. Ediciones UPC. 2002. ISBN 978-84-830-1990-0.

Comisión de regulación de comunicaciones. Regulación para promover el desarrollo e implementación del sistema nacional de telecomunicaciones de emergencias en Colombia [En línea]. Mayo de 2016. [Consultado el 9 de febrero de 2018]. Disponible en internet: https://www.crcom.gov.co/recursos_user/2016/Actividades_regulatorias/SNTE/DocSoporte_SNTE_publicar.pdf

Digi, XBee-PRO 900HP/XSC RF Modules. User Guide. [Consultado el 23 de septiembre de 2019]. [En línea]. Disponible en internet: https://www.digi.com/resources/documentation/digidocs/pdfs/90002173.pdf

Dignani, J. Pablo. Análisis de protocolo zigbee. Universidad Nacional de La Plata. 2011. [Consultado el 8 de septiembre de 2018]. [En línea]. Disponible en internet: https://postgrado.info.unlp.edu.ar/wp-content/uploads/2014/07/Dignanni_Jorge_Pablo.pdf

FUSARIO, Rubén. Técnicas de transmisión banda base aplicadas a redes LAN y WAN. Ciudad Autónoma de buenos aires, Argentina. Instituto Nacional de Educación Tecnológica. ISBN 950-00-0545-X.

103

GARCÍA, Armando. Calculo de Antenas. 4ta Ed. Marcombo. 2010 ISBN 978-84-267-1666-8.

GARRETA, Jordi, Historia y evolución de las redes wifi: de tecnología inalámbrica a aplicación ligera para retailers [En línea]. 2017. [Consultado el 22 de febrero de 2018]. Disponible en internet: http://pleasenetworks.com.

GOLDMAN, David. 2012. Sandy Knocks out 25% of Cell Service in Its Path [En linea]. CNNMoney. [Consultado el 9 de marzo de 2018]. Disponible en internet: http://money.cnn.com/2012/10/31/technology/mobile/sandy-cell-service-outages/index.html

Horng-Lin Shieh, Chi-Chang Huang. Sistema de atención de emergencia que utiliza técnicas RFID y Zigbee. IEEE Xplore. [en línea] en: /ieeexplore.ieee.org. [Consultado: 18 de marzo de 2017]. Disponible en Internet: https://ieeexplore.ieee.org/document/7545137/

IEEE Network <<802.15.4 Low Rate Wireless Personal Area Networks>>2006.

MARTINEZ, J. Ahrens, El huracán Irma golpea la costa de florida [En línea]. El País. [Consultado el 13 de septiembre de 2017]. Disponible en internet: https://elpais.com/internacional/2017/09/10/estados_unidos/1505074501_698095.html

MORENO, Javier. Informe Técnico: Protocolo ZigBee (IEEE 802.15.4).

PEREIRA, Matías, GAGGERO, Leonardo, DRABENCHE, Alejandro. La tecnología en situaciones climáticas extremas [En línea]. Facultad de Ingeniería, Universidad de Palermo. Argentina: Editorial Universitaria. [Consultado el 22 de febrero de 2018]. Disponible en internet: http://www.palermo.edu/

RIERA, Juan. ALABAU, Antonio. Teleinformática y redes de computadores. 2da ed. Marcombo 1984. ISBN 978-84-267-0539-6.

SONNET device. [en línea]. [Consultado: 18 de marzo de 2017]. Disponible en Internet: https://www.sonnetlabs.com/

104

STALLINGS, William. Comunicaciones y Redes de Computadores. 6ta ed. Prentice Hall, 2000. 30 p. ISBN 978-84-205-4110-5.

TOMASI, Wayne. Sistemas de Comunicaciones Electrónicas. 4ta Ed. México, Pearson Education. 2003. 615 p. ISBN 970-26-0316-1.

VELASCO, Nicolás. Microcontroladores [En línea]. Facultad de Ingeniería, Universidad de Sevilla. España: Editorial Universitaria. [Consultado el 9 de marzo de 2018]. Disponible en internet: http://bibing.us.es/proyectos/abreproy/11141/fichero/PFC%252F3+Microcontroladores.pdf

105

ANEXOS

Anexo A. Código Python para módulo de comunicación.

#! /usr/bin/env python # -*- coding: utf-8 -*- import serial import bluetooth import threading import time import sys import struct global ser # Lectura de modulo en puerto serial. try: ser = serial.Serial('/dev/ttyUSB0', 9600, timeout=1.0) print(ser.name) print 'Modulo Xbee conectado' # Se obtiene el SL del módulo Xbee (Solo para saberla - no se utiliza). ser.write(bytearray(b'\x7E\x00\x05\x09\x5B\x50\x4C\x04\xFB')) temp = ser.readline() ser.write(bytearray(b'\x7E\x00\x04\x09\x5C\x57\x52\xF1')) temp = ser.readline() ser.write(bytearray(b'\x7E\x00\x04\x09\x5D\x41\x43\x15')) temp = ser.readline() ser.write(bytearray(b'\x7E\x00\x04\x08\x01\x53\x4C\x57')) SL = ser.readline() incoming = '' longi = len(SL) at = '' for i in range(8,12): at= at+hex(ord(SL[i])) print ("SL MODULO XBEE: " +at) except: print ("Modulo Xbee no conectado") # Reporte para listeners (Algo a probar, actualmente no se esta usando). #ser.write(bytearray(b'\x7E\x00\x0F\x10\x00\x00\x00\x00\x00\x00\x00\xFF\xFF\xFF\xFE\x00\x00\xAE\x46')) # Creacion del socket Bluettoth para recibir mensajes desde dispositivo movil. server_socket=bluetooth.BluetoothSocket(bluetooth.RFCOMM) port = 1

106

server_socket.bind(('',port)) server_socket.listen(1) def bt(): global ser global client_socket client_socket, adress = server_socket.accept() # Asignacion de la direccion de dispositivo Bluetooth a variable. client_socket_pass, port_pass = client_socket.getpeername() print 'Dispositivo Bluetooth conectado' print (client_socket.getpeername()) while True: try: # Lectura de mensaje por puerto. data = client_socket.recv(1024) # Llama el metodo que construye la trama api con el dato recibido. trama_api = codificar(data) ser.write(trama_api) print("Trama enviada: ", trama_api) print 'Bluetooth: %s' %data except: print 'Se perdio la conexión' print 'Ultimo usuario conectado: %s' %client_socket_pass # Reconectar al dispositivo Bluetooth. client_socket, adress = server_socket.accept() def modulo(): global incoming global arreglo_api global client_socket global ser acks = 0 buffC = [] buffC2 = [] vacio = 0 inicio = 1 deci_deco = 0 while True: try: # Lectura de puerto serial (Modulo Xbee). incoming = ser.readline().strip() except:

107

print ("Modulo Xbee no conectado") # Volver a leer puerto serial. ser = serial.Serial('/dev/ttyUSB0', 9600, timeout=1.0) print(ser.name) print 'Modulo Xbee conectado' if inicio == 1: if incoming != '': # El caracter '~' es el indicador ASCII inicial de toda trama # por lo tanto, si llegan multiples tramas concatenadas # son separadas al identificar el caracter, suprimiendolo y # anexando cada trama al arreglo (buffC) como un elemento. buffC = incoming.split('~') # Elimina la primera posicion que esta vacia. buffC.pop(0) incoming = '' inicio = 0 if buffC != []: if incoming != '': # Se crea un segundo arreglo (buffC2) con el fin de que si # comienzan a llegar mas mensajes no se sobrepongan sobre el # arreglo buffC sin este aun estar vacio. buffC2 = incoming.split('~') buffC2.pop(0) # Por lo tanto, lo almacendo en este arreglo se anexa al final # del buffC sin borrar los datos anteriores. buffC.extend(buffC2) incoming = '' # Se visualizan todas las tramas que estan en el arreglo print ("Este es el buffC del hilo modulo: ", buffC) # El dato a decodificar sera siempre el que este en la primera # Posicion del arreglo dato = buffC[0] # La longitud se encuentra en la tercera posicion de la trama pero # al suprimir el primer caracter, la longitud se encuentra en la # segunda posicion. # Se le suma 5 ya que los bytes en 0 no los reconoce. longT = ord(dato[1])+3 deco = '' try: # Decodifica la trama donde el dato se encuentra a partir de # la posicion 15 hasta la longitud total menos 2 (por el check).

108

for i in range(14,longT-1): deco = deco+dato[i] print 'Xbee: %s' %deco # Identifica el entero del primer caracter del dato. deci_deco = ord(dato[14]) except: print ("Algo salio mal con el mensaje") client_socket.send("Algo salio mal con el mensaje") mac_ls = '' # En todo receive packet viene la direccion del modulo que envió el # mensaje, por lo tanto, se extrae la dirección del modulo para # responder con un ACK. try: for i in range(7,11): mac_ls = mac_ls+dato[i] except: print ("Error de MAC") # Se llama al metodo que construye la trama con la dirección del # modulo al que se le debe responder junto con el ACK. respuesta = respuesta_mac(mac_ls) #Mostrar mensaje por bluetooth #deci_deco = ord(dato[15]) # Si el mensaje recibido equivale en entero al caracter del ACK # se aumenta una variable para posteriormente notificar cuantos # dispositivos reciben el mensaje. if deci_deco == 169: print ("ACK") acks = acks + 1 elif deci_deco != 169 and acks != 0: ser.write(respuesta) #Enviar ACK try: # Muestra dispositivos en linea aunque el buff no este vacio client_socket.send("Su mensaje fue recibido por %d dispositivos" %acks) # Envia el mensaje recibido por el socket client_socket.send(deco) except: print ("Aun no hay dispositivo Bluetooth conectado") acks = 0 else: ser.write(respuesta) #Enviar ACK try:

109

client_socket.send(deco) except: print ("Aun no hay dispositivo Bluetooth conectado") incoming = '' ser.flush() buffC.pop(0) #Sale el primer mensaje y se corre posiciones if buffC == []: #Solo para no decir buffer vacio de primero vacio = 1 elif vacio == 1: if acks != 0: try: # Muestra dispositivos en linea aunque el buff este vacio. client_socket.send("Su mensaje fue recibido por %d dispositivos" %acks) except: print ("Aun no hay dispositivo Bluetooth conectado") print("El buffer esta vacio") vacio = 0 inicio = 1 acks = 0 t = threading.Thread(target=bt, name='bt') w = threading.Thread(target=modulo, name='modulo') t.start() w.start() # Metodo que construye la trama api con el dato para enviar por broadcast. def codificar(dato): arreglo_api = [126, 0, 14, 16, 0, 0, 0, 0, 0, 0, 0, 255, 255, 255, 254, 0, 0] checksum = 0 check_con = 255 check_trama = 1035 #-----------------------------ARMAR TRAMA--------------------------------- nDatos = len(dato)-2 #omitiendo \r y \n de dato enviado por terminal for letra in dato: if letra == "\r" or letra == "\n": break arreglo_api.append(ord(letra)) checksum = checksum + ord(letra) arreglo_api[2] = arreglo_api[2] + nDatos checksum = checksum + check_trama

110

checksum_hex = hex(checksum) ncheck = len(checksum_hex)-1 #Teniendo en cuenta que el arreglo comienza desde la posicion 0 checksum_hex8 = '0x' + checksum_hex[ncheck-1] + checksum_hex[ncheck] checksum_hex8D = int(checksum_hex8, 16) checksum_hex8D = check_con - checksum_hex8D arreglo_api.append(checksum_hex8D) #--------------------TRAMA API HEXADECIMAL------------- arreglo_api_hexa = [] for i in arreglo_api: valor_hexa = hex(i) arreglo_api_hexa.append(valor_hexa) trama_api = bytearray([int(x,0) for x in arreglo_api_hexa]) return trama_api # Metodo que construye la trama con la dirección del módulo destinatario. def respuesta_mac(ls): arreglo_api = [126, 0, 15, 16, 0, 0, 19, 162, 0, 0, 0, 0, 0, 255, 254, 0, 0, 169] checksum = 0 check_con = 255 check_trama = 875 #-----------------------------ARMAR TRAMA--------------------------------- #Respondera con un © = 0xa9 k = 9 for letra in ls: arreglo_api[k] = ord(letra) checksum = checksum + ord(letra) k = k+1 checksum = checksum + check_trama checksum_hex = hex(checksum) ncheck = len(checksum_hex)-1 #Teniendo en cuenta que el arreglo comienza desde la posicion 0 checksum_hex8 = '0x' + checksum_hex[ncheck-1] + checksum_hex[ncheck] checksum_hex8D = int(checksum_hex8, 16) checksum_hex8D = check_con - checksum_hex8D arreglo_api.append(checksum_hex8D) #--------------------TRAMA API HEXADECIMAL------------- arreglo_api_hexa = [] for i in arreglo_api: valor_hexa = hex(i) arreglo_api_hexa.append(valor_hexa) trama_api = bytearray([int(x,0) for x in arreglo_api_hexa]) return trama_api

111

Anexo B. Diseño de aplicación móvil.

Anexo digital en formato comprimido (.rar) el cual contiene los diseños o layouts y archivos .java, compatibles con el software Android Studio para la visualización de la aplicación o terminal Bluetooth para dispositivos móviles.

Anexo C. Datasheet Xbee Pro S3B 900 MHz.

112

Anexo D. Tabla Comparativa de módulos de comunicación ZigBee.

Documents

DISPOSITIVO DE COMUNICACIONES INALÁMBRICO PORTATIL … · Diagrama de funcionamiento de aplicación móvil Bluetooth. 72 ... transmisión de voz y datos entre distintos dispositivos