Medida de cobertura y envío de datos de sensores ambientales a través de LoRa en contexto internet de las cosas

Proyecto Fin de Carrera Ingeniería de Telecomunicación Formato de Publicación de la Escuela Técnica Superior de Ingeniería Autor: F. Javier Payán Somet Tutor: Juan José Murillo Fuentes Dep. Teoría de la Señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2013 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Medida de Cobertura y Envío de Datos de Sensores Ambientales a través de LoRa en Contexto Internet de las Cosas Autor: Pedro Rivero Lobo Tutor: Juan Antonio Becerra González Dpto. Teoría de la señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 Trabajo Fin de Grado Grado en Ingeniería de las Tecnologías de Telecomunicación Medida de Cobertura y Envío de Datos de Sensores Ambientales a través de LoRa en Contexto Internet de las Cosas Autor: Pedro Rivero Lobo Tutor: Juan Antonio Becerra González Profesor Ayudante Doctor Dpto. Teoría de la señal y Comunicaciones Escuela Técnica Superior de Ingeniería Universidad de Sevilla Sevilla, 2021 Trabajo Fin de Grado: Medida de Cobertura y Envío de Datos de Sensores Ambientales a través de LoRa en Contexto Internet de las Cosas Autor: Pedro Rivero Lobo Tutor: Juan Antonio Becerra González El tribunal nombrado para juzgar el trabajo arriba indicado, compuesto por los siguientes profesores: Presidente: Vocal/es: Secretario: acuerdan otorgarle la calificación de: El Secretario del Tribunal Fecha: Agradecimientos Este trabajo jamás habría visto la luz si no fuera por un gran número de personas que han estado en mi vida desde que empecé la carrera. En primer lugar quería dar las gracias a mi familia, pero, sobre todo, a mi padre José Pedro y a mi madre María José, quienes se han privado de todo para que tanto mi hermana María como yo tuviéramos estudios universitarios. Muchas gracias papá, muchas gracias mamá, la educación que me habéis dado es lo más valioso que tengo. A mi abuela Mari y a mi abuela Loli, quienes me han ayudado en los exámenes encendiendo una vela y se han alegrado más que yo por los aprobados. Gracias a todos mis amigos, amigas, compañeros y compañeras de clase, con quienes he reído, llorado y sufrido durante exámenes, con quienes he compartido horas de estudio en la biblioteca y con quienes he celebrado tanto mis aprobados como los suyos. Hago mención especial a Mercedes, con quien además de compartir muchísimas horas de biblioteca y lágrimas, he conservado una bonita amistad desde prácticamente el primer año a pesar de estudiar diferentes especialidades. También, agradecerle a mi gran amiga y eterna compañera de clase Esther, su amistad, ayuda y profesionalidad en todos los trabajos y prácticas que hemos estado juntos, además de su ayuda en los exámenes que nos hemos preparado juntos. Agradecerle a mi pareja, Paula, el estar conmigo en mis peores momentos. Ha sido un apoyo fundamental en el transcurso del peor año de mi vida respecto a dificultad académica, siempre ha estado cuando lo he necesitado. También agradecerle a mi tutor Juan Antonio Becerra su tiempo, paciencia, dedicación, comprensión, flexibilidad y rapidez, ya que, sin él, habría resultado imposible realizar este trabajo. Y, por último, quería dedicar este proyecto a la memoria de mi abuelo Juan, quien por un año no pudo verme terminar la carrera. Pedro Rivero Lobo Sevilla, 2021 I Resumen Es te proyecto consiste en la implementación de un sensor IoT (internet de las cosas, del inglés, Internet of Things) de temperatura y humedad relativa ambientales. Para ello se conectarán dos placas STM32WL55JC mediante LoRa, un tipo de modulación basada en la modulación CSS (modulación de espectro ensanchado chirp), con mucho alcance y bajo consumo de energía. Las placas son del fabricante STMicroelectronics y se caracterizan principalmente por su módulo integrado que utilizaremos para usar la modulación LoRa. Además estas placas necesitan una baja potencia para su funcionamiento. Una de estas placas, actuando como transmisor, estará conectada a un sensor SHT20, el cual permite obtener medidas ambientales a través de las variables de humedad ambiental y temperatura. Este sensor tomará las medidas oportunas para enviarlas a la otra placa, que actúa como receptor, el cual estará conectado a un puerto UART de una computadora donde podremos recibir toda la información procedente del sensor. Una vez interconectadas las placas, se harán dos tipos de experimentos; en uno se tomarán medidas de la temperatura y humedad relativa cada 5 minutos durante 24 horas; y en el otro se determinará la cobertura de la conexión de las placas mediante los parámetros de RSSI y SNR, que son el indicador de intensidad recibida y la relación señal-ruido, respectivamente. Con esto, se comprobará que al aumentar el parámetro Spreading Factor de la modulación, se obtiene una mayor cobertura. III XÍndice 3.5 Redes de área amplia de bajo consumo: LPWAN. 16 3.6 LoRaWAN. 18 3.6.1 Packet forwarder (reenviador de paquetes). 18 3.7 Ejemplo de conexión. 18 3.8 Atributos de LoRa/LoRaWAN 19 3.9 Clases de dispositivos (nodos). 19 3.10 Frecuencias LoRaWAN. 20 4 Inter Integrated Circuits (I2C) 21 4.1 Características del I2C. 21 4.2 Conexión a nivel físico. 22 4.3 Nivel de enlace. 22 5 Materiales 25 5.1 Hardware. 25 5.1.1 Placa de desarrollo STM32WL55JC [16]. 25 5.1.2 Sensor de temperatura y humedad SHT20. 28 5.2 Software. 29 5.2.1 Entorno de desarrollo integrado para STM32: STM32CubeIDE. 29 5.2.2 CoolTerm. 30 6 Metodología y Desarrollo 31 6.1 Versión 0: Estudio y entendimiento del ejemplo proporcionado por STM- CubeMX. 31 6.1.1 Función void MX_SubGHz_Phy_Process(void) 32 6.1.2 Función void MX_SubGHz_Phy_Init(void) 32 6.2 Versión 1: Conexión UART. 32 6.3 Versión 2: Conexión con SHT20. 33 6.4 Versión 3: Implementación de retardos. 34 6.5 Versión 4: Conexión entre placas. 35 6.6 Versión 5: Diferenciación de placas. 37 7 Experimentos y resultados 39 7.1 Toma de temperatura y humedad relativa en el tiempo. 39 7.1.1 Toma de temperatura y humedad relativa en Sevilla. 39 7.1.2 Toma de temperatura y humedad relativa en Guadalcanal. 39 7.1.3 Conclusiones del experimento. 40 7.2 Prueba de cobertura. 41 7.2.1 Spreading Factor = 7. 41 7.2.2 Spreading Factor = 12. 42 7.2.3 Conclusiones del experimento. 42 8 Conclusiones y líneas futuras 43 8.1 Líneas futuras. 43 Apéndice A Código utilizado para la programación de la placa 45 A.1 Transmisor de la temperatura. 45 A.1.1 Función main. 45 A.1.2 Librería para el sensor SHT20. 46 Índice XI A.1.3 Funciones de subghz_phy_app.c creadas/modificadas. 50 A.2 Receptor de la temperatura. 52 A.2.1 Función main. 52 A.2.2 Función de subghz_phy_app.c modificada. 53 Apéndice B Secciones de datasheets utilizadas 55 Índice de Figuras 69 Índice de Tablas 71 Bibliografía 73 1 Introducción Ad ía de hoy, el internet de las cosas cada vez evoluciona más rápido y cada día aumenta el número de dispositivos conectados a internet. El tipo de dispositivo que ocupa un mayor porcentaje de la totalidad del internet de las cosas son los dispositivos inteligentes como los smartphones, tablets o notebooks, pero la idea es que con el paso de los años todo esté conectado a internet, incluso nuestro propio cuerpo. En este documento veremos un ejemplo de aplicación del concepto del internet de las cosas, donde monitorizaremos en tiempo real las variables físicas de la temperatura y la humedad relativa del sitio donde coloquemos nuestro sensor, tal y como se verá en el capítulo 7. En esta ocasión, usaremos la modulación LoRa ® para comunicar nuestro transmisor y nuestro receptor, de manera que donde queramos leer las variables físicas mencionadas, será donde coloquemos nuestro transmisor. A continuación se definen los objetivos, el alcance y la estructura de este trabajo. 1.1 Objetivos. El objetivo principal de este trabajo es desarrollar un dispositivo IoT que medirá la temperatura y la humedad relativa del ambiente en el lugar donde esté situado y enviará dicha información a través de LoRa. Como objetivo adicional, se elaborará una memoria teórica que incluya los conceptos básicos de teoría que preceden al trabajo técnico realizado. 1.2 Alcance. Este trabajo recoge todos los pasos necesarios y el procedimiento requerido para montar sensor IoT donde se obtengan los valores de la humedad y la temperatura. Para ello, se usarán dos placas de desarrollo STM32WL55JC, las cuales serán programadas para transferirse entre ellas la información correspondiente a la temperatura y la humedad del entorno donde se coloque la placa transmisora. Posteriormente se harán dos experimentos donde se ponga a prueba las especificaciones del trabajo realizado. 1 2Capítulo 1. Introducción 1.3 Estructura. Tras la introducción pasaremos a una sección teórica, compuesta por los capítulos 2, 3 y 4, donde se dará una noción básica de la teoría necesaria para entender la parte experimental y donde se verán algunos ejemplos y utilidades del IoT y LoRa. Después pasaremos al capítulo 5, donde se dará paso a un capítulo de materiales en el que hablaremos de todos los dispositivos y herramientas relevantes de los que hemos hecho uso para conformar este proyecto. Tras terminar el capítulo de materiales se pasará al capítulo 6, donde se desarrolla el proyecto y el trabajo más práctico, que consistirá en el montaje del circuito, desarrollo del código y explicación de las diferentes versiones por las que ha pasado el proyecto. Posteriormente, en el capítulo 7, veremos un par de experimentos donde pondremos en práctica el proyecto desarrollado y también veremos algunos parámetros de la comunicación, como la cobertura que tendrá dicho proyecto. A continuación del capítulo de experimentos, nos encontramos con el capítulo 8, donde hablaremos de las conclusiones finales y algunas posibles líneas futuras que podría tomar el proyecto, tales como algunas modificaciones o incorporaciones. En la última parte del documento se encuentra apéndice A, donde encontramos la información referida a los códigos usados; y el apéndice B, con los datasheets de los componentes utilizados. 2 Internet de las cosas: IoT Hoy día, son muchos los objetos electrónicos que están conectados a internet, tales como teléfonos o computadoras. IoT (del inglés, Internet of things/internet de las cosas) hace referencia a la interconexión de todos los tipos de objetos electrónicos. Se trata de una arquitectura emergente basada en el Internet global. Esta da pie al intercambio de bienes y servicios entre redes de suministro. Además, posee un gran papel en la seguridad y privacidad de los actores involucrados [1]. En 1999 Kevin Ashton fue quien usó por primera vez el término de IoT, pero se considera que el IoT nació entre 2008 y 2009 [2]. El IoT introducirá beneficios en la gestión y el seguimiento en tiempo real de los activos y productos, ya que nos permitirá aumentar la cantidad de datos y la mejora de equipos y el uso de recursos, lo que podría ahorrar costes. Esta arquitectura nos traerá un gran cambio en la vida cotidiana gracias a la posibilidad de acceso a servicios de educación, asistencia sanitaria, datos o transporte. Por otro lado, las empresas podrían aumentar su productividad gracias a los nuevos servicios personalizados de sus dispositivos inteligentes. 2.1 Aplicaciones. En este apartado se hablará de las principales aplicaciones que puede tener el mundo del IoT. En resumidas cuentas, se podría decir que IoT está formada por un conjunto de sensores y actuadores que proporcionan y reciben información digital que se coloca en la red, de manera que se puedan transmitir los datos para su procesamiento [4]. A un mismo dispositivo se le pueden unir varios sensores, pudiendo así medir una gran cantidad de variables físicas para luego transmitirlas a la nube. Hoy en día, todo tipo de dispositivos electrónicos tales como televisores o neveras tienen capacidad para la comunicación y la detección, las cuales irán creciendo con la incorporación de nuevas herramientas de detección. Los sistemas IoT tienen una arquitectura que se puede seccionar en cuatro capas [5]: •Detección de objetos : El IoT incorpora esta capa reduciendo así los requisitos de la capacidad de los dispositivos, lo que permite su interconexión. •Intercambio de datos : Esta capa es la responsable de la transmisión transparente de datos a través de las redes de comunicación. •Integración de la información : Esta capa es la responsable de la comunicación y las transacciones. Gracias a ella los sensores se intercomunican con otros o propietarios de estos. 3 4Capítulo 2. Internet de las cosas: IoT •Servicios de aplicaciones : En esta capa se da servicio de contenido a todos los usuarios de la red. Figura 2.1 Perspectivas del internet de las cosas [11]. A modo de ejemplo, tenemos algunas aplicaciones y servicios que tiene el IoT en las tablas 2.1, 2.2 y 2.3. Estos ejemplos se han obtenido directamente de [12]. 2.1 Aplicaciones. 5 Tabla 2.1 Aplicaciones y servicios de ejemplo de IoT (PARTE 1/3)[12]. APLICACIÓN/SERVICIO EJEMPLOS Ciudades y transportes Integración de los servicios de seguridad. inteligentes Optimización del transporte Sensores de aparcamiento Gestión de aparcamientos y tráfico en tiempo real Gestión de semáforos Localización de los coches Las redes energéticas inteligentes Seguridad Administración del Agua Riego de parques y jardines Contenedores de basura inteligentes Controles de contaminación y movilidad Sistemas de Votación Monitoreo de accidentes Edificios inteligentes Las mejoras en la eficiencia Mejoras de seguridad (sensores y alarmas) Aplicaciones domóticas Los servicios de salud y educación en el hogar Control remoto de los tratamientos para los pacientes Servicios de cable / satélite Sistemas de almacenamiento / generación de energía Apagado automático de la electrónica cuando no esté en uso Termostatos inteligentes Los detectores de humo y alarmas Aplicaciones de control de acceso Cerraduras inteligentes Seguridad para todos los miembros de la familia. Electrónica de consumo Teléfonos inteligentes Televisión inteligente Laptops, computadoras y tabletas Refrigeradores, lavadoras y secadoras inteligentes Sistemas de cine en casa inteligentes Aparatos inteligentes Sensores para el collar del animal doméstico Personalización de la experiencia del usuario El funcionamiento del producto autónomo Localizadores personales Gafas inteligentes Salud Monitoreo de las enfermedades crónicas Mejora de la atención y calidad de vida de los pacientes Trackers de Actividad Diagnóstico remoto Pulseras conectadas Cinturones interactivos Deporte y monitoreo de actividades de fitness Etiquetas inteligentes para fármacos Seguimiento del uso de drogas Los biochips Interfaces cerebro-ordenador Monitoreo de los hábitos alimenticios 6Capítulo 2. Internet de las cosas: IoT Tabla 2.2 Aplicaciones y servicios de ejemplo de IoT (PARTE 2/3)[12]. APLICACIÓN/SERVICIO EJEMPLOS Educación Vinculación de aulas virtuales y físicas Servicios de acceso a bibliotecas Intercambio de informes y resultados en tiempo real El aprendizaje permanente Aprendizaje de idiomas extranjeros Gestión de la asistencia Automoción Control de tráfico Avanzar en la información sobre lo que está roto Monitoreo inalámbrico de los neumáticos del coche La gestión inteligente de la energía y el control Auto diagnóstico Los acelerómetros Sensores de posición, de presencia y de proximidad Análisis de la mejor manera de ir en tiempo real a un sitio Localización por GPS Control de la velocidad del vehículo Vehículos autónomos que utilizan los servicios de del IoT. Agricultura y medio Medición y control de la contaminación ambiente Pronosticar cambios climáticos Las etiquetas RFID pasivas en productos agrícolas Sensores en palets de productos Gestión de residuos Cálculos de Nutrición. Servicios de energía Datos precisos sobre el consumo de energía La medición inteligente Redes inteligentes Análisis de consumo energético Pronosticar las tendencias futuras de energía Redes de sensores inalámbricos La producción de energía y el reciclaje Fabricación Gas y sensores de flujo Sensores inteligentes de variables físicas Visión de máquinas Detección acústica y de vibraciones Aplicaciones compuestas Control inteligente de robots Control y optimización de fabricación Reconocimiento de patrones Aprendizaje automático El análisis predictivo Logística móvil Gestión de almacenes Prevenir la sobreproducción Logística eficiente 2.2 Nuevas tecnologías. 7 Tabla 2.3 Aplicaciones y servicios de ejemplo de IoT (PARTE 3/3)[12]. APLICACIÓN/SERVICIO EJEMPLOS Conectividad inteligente Gestión de datos y prestación de servicios Medios de comunicación social y las redes sociales La comunicación de grupo interactiva En streaming en tiempo real Juegos interactivos Realidad aumentada Supervisión de la seguridad de la red Interfaces de usuario disponibles La computación afectiva Métodos de autenticación biométrica Telemática de consumo Servicios de comunicación M2M Análisis de grandes datos Realidad virtual Servicios de computación en nube Computación ubicua Visión por computador Antenas inteligentes Compras Compras inteligentes RFID y otras etiquetas electrónicas y lectores Los códigos de barras en el comercio minorista Inventarios Control de la procedencia geográfica de productos Control de calidad de los alimentos y de la seguridad 2.2 Nuevas tecnologías. IoT es posible gracias al desarrollo de las nuevas tecnologías. A continuación veremos las más relevantes [6] [7]. 2.2.1 Energía. Necesitamos tecnología que pueda generar energía de alta densidad de potencia que, al usarse en la nanoelectrónica de baja potencia, nos permita fabricar un dispositivo que se autoalimente basado en sensores inteligentes inalámbricos. 2.2.2 Sensores. Los sensores son una parte fundamental del IoT. Estos pueden ser de cualquier tipo y se pueden colocar prácticamente en cualquier parte, tales como debajo de la piel, carteras, etc. Pueden ser tan pequeños del orden de milímetros y enviar información a kilómetros de distancia. Los sensores son muy utilizados en la industria, desde la construcción hasta la salud y se pueden anticipar a las necesidades humanas basándose en la información recogida. Siguiendo la Ley de Moore, los factores de forma de los chips de silicio son diseñados cada vez más pequeños y con mejor eficiencia y rendimiento. 14 Capítulo 3. Long Range (LoRa) Figura 3.4 Barrido entre las dos frecuencias (descendente y ascendente en frecuencia) [13]. Spreading Factor (SF) [17] El Spreading Factor es el factor de difusión de la modulación LoRa y es un parámetro clave en la transmisión.Encontrar el SF adecuado es crucial para lograr un buen rendimiento a largo plazo. Este nos indica cuántos chirps por segundo se envían desde el transmisor. Se clasifica entre 7 y 12 en función de las condiciones ambientales entre el transmisor y el receptor. Esto supondrá que la función ADR (Adaptive Data Rate) esté activada, lo que se recomienda para los dispositivos que estarán en un lugar fijo. Cuanto menor sea el SF más chirps se enviarán por segundo, lo que se traduce en codificar más datos por segundo. Por otro lado, cuanto mayor sea el SF menor será el número de chirps por segundo, siendo menor el número de datos a codificar. Para una misma cantidad de datos a enviar, cuanto mayor sea el SF mayor será el tiempo de transmisión, conocido como tiempo aire. Esto se traduce en un mayor tiempo de funcionamiento y por tanto un mayor consumo de energía. Se podría pensar que es conveniente tener un SF bajo, pero el hecho de tener un SF alto tiene sus ventajas. Un SF alto supone un mayor tiempo de aire, lo que da más tiempo al receptor para muestrear la potencia de la señal, lo que se traduce en una mejor sensibilidad. Una mejor sensibilidad se traduce en que se puede recibir la señal desde una distancia mayor, lo que implica una mejor cobertura. En teoría, por cada unidad de incremento en el SF se duplica el tiempo de transmisión para una misma cantidad de información. 3.2 Aplicaciones LoRa. 15 Coding Rate (CR) [18] El Coding Rate (CR) es la tasa de codificación que se refiere a la proporción de bits transmitidos que realmente transportan información.Esto se hace como técnica para agregar bits redundantes (de paridad) a la transmisión para que los errores se puedan recuperar en la recepción. Puede tomar los valores de 6/8, 4/6, etc. De manera que, si CR = 4/8, estamos transmitiendo el doble de bits que los que contienen información. Ancho de banda (Bw) [19] Ya hemos comentado que LoRa utiliza una modulación de espectro ensanchado. Este codifica la señal base con una señal de alta frecuencia que propaga la señal a través de un mayor ancho de banda, reduce el consumo energético y además aumenta las interferencias electromagnéticas. También se ha comentado que el SF es variable. Para un ancho de banda disponible, mientras haya un mayor SF menor será la tasa de bits, de manera que aumentará el tiempo de transmisión y reducirá la batería del dispositivo transmisor. La tasa de bits depende del ancho de banda y el spreading factor, siguiendo la ecuación: Tasadebit =SF ∗ BW 2SF (3.1) LoRa permite 3 anchos de banda diferentes, 125KHz, 250KHz y 500KHz, los cuales están establecidos por las agencias reguladoras, que también regulan el SF. 3.2 Aplicaciones LoRa. LoRa es adecuado para construir canales de comunicación de largo alcance que requieran bajas velocidades de datos. Las redes de sensores inalámbricos LoRa se pueden utilizar para crear una amplia gama de aplicaciones. Algunos ejemplos son [13]: •Procesamiento agrícola •Seguimiento de la contaminación del aire •Seguimiento de activos •Seguimiento de ganado •Gestión energética y sostenibilidad •Detección de caídas •Detección de fuego •Gestión de flotas •Seguimiento de flotas •Seguridad de casa •Gestión de la calidad del aire interior •Gestión de la temperatura industrial •Detección de presencia de líquidos •Localización de vehículos y carga robados •Supervisión de refrigeradores médicos •Gestión de aparcamientos •Agricultura de precisión •Mantenimiento predictivo •Detección de fugas de radiación •Calidad del envío •Seguimiento de activos domésticos inteligentes 16 Capítulo 3. Long Range (LoRa) •Riego inteligente •Iluminación inteligente •Estacionamiento inteligente •Monitoreo de flujo de tanques •Gestión de residuos •Monitoreo de flujo de agua •Gestión y protección del agua •Monitorización inalámbrica del nivel de gas 3.3 Cobertura. Una sola puerta de enlace puede cubrir toda la cobertura de una ciudad entera o muchos kilómetros cuadrados. La cobertura depende en gran medida de los obstáculos que pueda haber tales como edificios o árboles, el medio ambiente y de factores técnicos como las interferencias provocadas por antenas de radio. Veamos un ejemplo del uso de LoRa y el ahorro que supondría en costes: supongamos que tenemos una flota de vehículos con un sistema de seguimiento mediante rastreadores GPS. Cada vehículo transmite su ubicación periódicamente a un servidor GPS a través de la red móvil. Cada rastreador tiene un plan de datos. Si tuviéramos 100 vehículos, tendríamos que contratar 100 planes de datos móviles. Pero, si reemplazamos cada rastreador GPS con un nodo de sensor LoRa y algunas puertas de enlace LoRa, solo necesitaremos planes de datos móviles para las puertas de enlace, que podrían ser 10 por ejemplo (dependiendo de la expansión geográfica que queramos alcanzar). Por lo que con esta implementación se reduciría el costo de datos móviles. 3.4 Arquitectura de una red LoRa. La arquitectura de la red está basada en: •Nodos : dispositivos finales que envían y reciben datos. Se les pueden conectar sensores, etc. •Gateway (puerta de enlace) : dispositivo intermedio que actúa como plataforma entre la red LoRa e internet, permitiendo conectar los nodos con el Network Server. Se pueden considerar como convertidores o puntos de acceso. Cuentan con una dirección IP para enviar los datos a la Network. •LoRaWAN Network Server : gestiona y administra los distintos dispositivos, así como las comunicaciones y permite la integración con los terceros. En la figura 3.5 podemos ver un ejemplo de arquitectura de una red LoRa. 3.5 Redes de área amplia de bajo consumo: LPWAN. Las redes LoRa se consideran redes de área amplia y de baja potencia (LPWAN). Los nodos pueden funcionar con batería cuya vida útil ronda los 10 años. Los nodos transmiten los datos en pequeñas cantidades a largas distancias y en algunas ocasiones varias veces por hora. 3.5 Redes de área amplia de bajo consumo: LPWAN. 17 Figura 3.5 Esquema de la arquitectura de una red LoRa [19]. LPWAN (Low Power Wide Area: gran rango y bajo consumo) es una tecnología de red de área amplia inalámbrica que está especializada para dispositivos de interconexión con conectividad de baja tasa de datos, centrándose en el alcance y la eficacia energética. Por características de penetración de las ondas electromagnéticas mayormente se trabaja en el espectro subGHz: 433, 868 y 915 MHz para LoRa. LoRa es una tecnología inalámbrica LPWAN con gran alcance geográfico (kilómetros) y con un bajo consumo eléctrico. La ventaja es que consume mucho menos y tiene una gran distancia. LoRaWAN es un protocolo de red que utiliza LoRa en las redes LPWAN. Su función es la de realizar comunicación y administración a los dispositivos LoRa. En la figura 3.6 podemos ver un esquema de lo que serían las capas de la arquitectura de una red LoRa. Figura 3.6 Esquema de las capas de la arquitectura de una red LoRa [19]. 18 Capítulo 3. Long Range (LoRa) 3.6 LoRaWAN. Long Range Wide Area Network (LoRaWAN) es el protocolo de comunicación y la arquitectura del sistema para la red, mientras que la capa física LoRa habilita el enlace de comunicación de largo alcance. LoRaWAN influye en lo siguiente: •Vida útil de la batería del nodo •Capacidad de la red •Calidad de servicio •Seguridad •Aplicaciones atendidas por la red LoRaWAN consta de dispositivos finales, gateways, un servidor de red y servidores de aplicaciones. En una red LoRaWAN los datos transmitidos por un nodo final generalmente son recibidos por múltiples puertas de enlace. Cuando se reciben los datos, el Gateway reenviará el paquete recibido al servidor de red a través de la red móvil, Ethernet, Wi-Fi o satélite. El software que se ejecuta en los Gateway es responsable de enviar cualquier paquete de datos entrante al servidor de red. Este software se conoce como reenviador de paquetes (packet forwarder). Posteriormente, el servidor de red envía y recibe mensajes LoRaWAN desde y hasta dispositivos y se comunica con los servidores de aplicaciones descendentes. El servidor de aplicaciones es el destino de los datos de la aplicación del dispositivo enviados como carga útil en los mensajes LoRaWAN. 3.6.1 Packet forwarder (reenviador de paquetes). El packet forwarder es un software que se ejecuta en la puerta de enlace (gateway) LoRa. Permite que el concentrador LoRa transmita y reciba paquetes LoRa para enlaces ascendentes y descendentes desde los nodos finales a los servidores de red y desde los servidores de red a los nodos finales (bidireccional). Existen packets forwarders de un solo canal o multicanal, siendo estos últimos los únicos compatibles con LoRaWAN. Un packet forwarder se encargará de reenviar los paquetes LoRa recibidos por el módulo LoRa al servidor de red a través del enlace IP/UDP y emite paquetes LoRa que envía el servidor de red. 3.7 Ejemplo de conexión. El sensor va conectado normalmente a un host (Arduino, STM32, PIC, etc) y después a través de una conexión UART/SPI se conecta al dispositivo radio el cual hace la transmisión de la información. Se envía la información y se conecta al host que hace de gateway. LoRa permite que se conecten dispositivos entre sí sin necesidad de gateway (el gateway será necesario para conectarlo a internet). En la figura 3.7 tenemos un ejemplo de conexión. 3.8 Atributos de LoRa/LoRaWAN 19 Figura 3.7 Ejemplo de conexión de la arquitectura de una red LoRa [19]. 3.8 Atributos de LoRa/LoRaWAN Algunos atributos que tiene LoRaWAN son: •La comunicación entre nodos LoRa y gateway utiliza una modulación CSS. • La red es de largo alcance. Generalmente es de unos 10 Km, pero se pueden hacer distancias más largas. •El rendimiento se adapta al alcance, ancho de banda y velocidad de datos. • La velocidad rondará de 0.25 kbps a 11kbps, afectando al alcance y al tamaño de los paquetes. • La velocidad está relacionada con el spreading factor (SF), que como ya hemos dicho influye en la cantidad de datos redundantes existentes. • Los dispositivos solo se comunican cuando hay datos para ser enviados. Esto hace que LoRaWAN sea de bajo consumo. • LoRa puede operar su propia red de radio LoRaWAN sin necesidad de pagar espacio aéreo, por lo que hay un bajo costo. • LoRaWAN es un protocolo seguro. La capa de seguridad de la red garantiza la autenticidad del nodo en la red. La seguridad de la capa de aplicación maneja el cifrado de datos entre los nodos y el servidor de la aplicación para que los mensajes no puedan leerse o interferirse en tránsito. • Este protocolo no sirve para la navegación web, está diseñado para pequeñas cantidades de datos de dispositivos simples como sensores, luego solo se transmitirá una baja tasa de datos. 3.9 Clases de dispositivos (nodos). En LoRaWAN diferenciamos 3 tipos de nodos dependiendo de su funcionamiento: •Clase A : es el tipo más soportado por casi todos los dispositivos. Entra en modo escucha solo después de enviar un dato al gateway, por lo que es el que tiene un mayor ahorro de energía. Gracias a esto, es ideal para dispositivos que usan una batería. 20 Capítulo 3. Long Range (LoRa) •Clase B : en esta clase, los tramos de recepción son establecidos en unos tiempos determinados. •Clase C : esta clase de dispositivos tienen su radio encendida la mayor parte del tiempo, de manera que puede recibir información siempre menos cuando está transmitiendo un mensaje. Este tipo de dispositivos está diseñado para dispositivos alimentados por la red eléctrica. 3.10 Frecuencias LoRaWAN. LoRa Alliance define perfiles de frecuencia regionales para operar LoRaWAN para diferentes regiones regulatorias en todo el mundo. En la tabla 3.1 se enumeran las diferentes frecuencias permitidas en algunos países. Tabla 3.1 Frecuencias LoRa por país [13]. País Banda/Canal Plan de canales EEUU 902-928 MHz US902-928, AU915928 Reino Unido 433.05-434.79 MHz EU433 863-873 MHz EU863-870 918-921 MHz otro Canadá 902-928 MHz US902-928, AU915-928 Australia 915-928 MHz AU915-928, AS923 India 865-867 MHz IN765-867 Francia 433.05-434.79 MHz EU433 863-873 MHz EU863-870 Sri Lanka 433.05-434.79 MHz EU433 España 863-873 MHz EU863-870 4 Inter Integrated Circuits (I2C) En este proyecto, para conectarnos al sensor de temperatura y humedad, tendremos que hacer uso del protocolo I2C. El bus Inter Integrated Circuits (I2C) es usado para la interconexión de dispositivos mediante un bus serie. Fue desarrollado por Philips ® a principios de los 80 para conectar periféricos con una CPU. Se pretendía simplificar las conexiones entre los periféricos y aumentar la protección frente al ruido [14]. 4.1 Características del I2C. Las características principales del I2C son: • Se trata de un bus de comunicaciones síncrono el cual está formado por 2 hilos: Serial Data Line (SDA) para los datos y Serial Clock Line (SCL) para el reloj de sincronización. • La velocidad de transmisión standard es de hasta 100kbits/s, pero, en modo fast, puede alcanzar los 400Kbits/s. Si fuera necesario, también existe el modo high-speed que alcanza una velocidad de hasta 3.4Mbits/s •Cada dispositivo que esté conectado al bus I2C tiene una dirección única. • La distancia y el número de dispositivos que se pueden conectar está limitada por la capacidad del bus. • El protocolo seguido para acceder al bus es el Master-Slave, pudiendo ser multimaestro. Si se diera la situación de que hubiera varios maestros en el bus, se hará un arbitraje que asegura que en cada instante sólo hay un dominante. 21 22 Capítulo 4. Inter Integrated Circuits (I2C) 4.2 Conexión a nivel físico. Para una correcta conexión todos los dispositivos tienen que estar conectados a las mismas líneas SDA y SCL. Figura 4.1 Esquema de conexión física [15]. 4.3 Nivel de enlace. Para el intercambio de información, a nivel de enlace usaremos el protocolo de acceso al medio maestro-esclavo. En este protocolo, el maestro controla toda la comunicación, de manera que genera la señal de reloj del bus SCL, inicia y termina la comunicación, da direcciones a los esclavos y establece en qué sentido será la comunicación. En este protocolo, se necesita que por cada byte enviado se confirme la recepción por parte del destinatario. Los datos irán por la línea SDA, de manera que por cada bit de datos será necesario un ciclo de SCL. Cabe destacar que los datos sólo pueden cambiar cuando SCL está a nivel bajo. Figura 4.2 Ejemplo de comunicación I2C [14]. 4.3 Nivel de enlace. 23 La unidad básica de transmisión será el byte, de modo que por cada byte enviado necesitaremos una confirmación (ACK) por parte del destinatario. Para el ACK, el destinatario mantiene la línea SDA a nivel bajo durante el tiempo equivalente a 1 bit (1 ciclo de reloj). En el caso de que no fuera así, sería un NACK (no recibido). Figura 4.3 Ejemplo de envío de datos en I2C [14]. Para iniciar la transmisión, el maestro dará un flanco de bajada en SDA con SCL a nivel alto, tal y como se muestra en la figura 4.4. Figura 4.4 Ejemplo del inicio de la comunicación en I2C [14]. Y, para finalizar la transmisión, el maestro da un flanco de subida en SDA con SCL a nivel alto, como podemos ver en la figura 4.5. Figura 4.5 Ejemplo del fin de la comunicación en I2C [14]. 30 Capítulo 5. Materiales 5.2.2 CoolTerm. CoolTerm es el software que hemos utilizado como terminal de puerto serie. Se utiliza principalmente para proyectos donde se necesita intercambiar datos con hardware conectado a puertos serie, como es nuestro caso. Permite guardar configuraciones de los puertos para la posterior inicialización, permitiendo así una conexión más rápida. También permite la captura de contenido, de este modo podemos guardar todo lo que va sucediendo en un fichero. Haremos uso de esto para guardar un registro de temperaturas y humedades relativas de un mismo día, pudiendo además indicar la fecha y la hora del momento. En nuestro proyecto nos ha permitido estar controlando en todo momento qué sucedía en nuestras placas cuando se estaban comunicando, pudiendo corregir errores y depurar código eficientemente. Figura 5.5 Ventana de inicio del software CoolTerm. 6 Metodología y Desarrollo Este capítulo recoge todo el proceso que se ha llevado a cabo para la elaboración de nuestro proyecto, desde el estudio previo hasta llegar a la versión final en pleno funcionamiento. Hablaremos de toda la metodología utilizada, las decisiones tomadas y haremos pequeñas menciones a código (en el apéndice A se incluirá archivos de código más completos para su posible consulta). Se ha seguido un método iterativo, de manera que cada versión trataba de agregar una nueva funcionalidad al proyecto hasta alcanzar finalmente lo deseado. Tras la definición del objetivo final, hemos dividido el problema en pequeñas modificaciones previas hasta cumplir el objetivo. Los pasos intermedios (versiones) del proyecto, han sido: •Versión 0: Estudio y entendimiento del ejemplo proporcionado por STMCubeMX. •Versión 1: Conexión UART. •Versión 2: Conexión con SHT20 (sensor de temperatura y humedad relativa). •Versión 3: Implementación de retardos. •Versión 4: Conexión entre placas. •Versión 5: Diferenciación de códigos entre placas. Por otro lado, dentro de cada versión, hemos seguido los siguientes pasos: • Paso 1: Planteamiento de la modificación del proyecto. Nos hemos basado en las versiones previas que hemos elegido. • Paso 2: Estudio y búsqueda de información. Hemos realizado búsquedas por la web para encontrar información relevante sobre cada modificación para poder llevarla a cabo. • Paso 3: Aplicación y adaptación de la información disponible. Tras cada búsqueda hemos incorporado las consecuentes modificaciones a nuestro proyecto. • Paso 4: Comprobación y depuración de errores. Cada vez que hemos incorporado/modificado código hemos tenido que depurarlo y confirmar el correcto funcionamiento. • Paso 5: Puesta a punto. Una vez conseguido la modificación, hemos comprobado su correcto funcionamiento y hecho los correspondientes comentarios para su explicación en el código. 6.1 Versión 0: Estudio y entendimiento del ejemplo proporcionado por STM- CubeMX. Como se mencionó en el capítulo de materiales, tras elegir la placa en STMCubeMX se descargan una serie de drivers y proyectos de ejemplo. 31 32 Capítulo 6. Metodología y Desarrollo En nuestro caso, tras seleccionar la placa STM32WL55JC se nos descargan una series de proyectos ejemplo, entre ellos destaca el proyecto SubGHz_Phy_PingPong. A grandes rasgos, este proyecto interconecta las dos placas que posean el código gracias a su módulo de antena. Lo hace bien a través de una modulación LoRa o mediante una modulación FSK. Viene configurada la modulación LoRa de manera predeterminada, por lo que no tendremos que tocar el proyecto en ese aspecto. Su funcionamiento está basado en tres funciones que se invocan desde la función principal "main" (apéndice A). Las veremos a continuación. 6.1.1 Función void MX_SubGHz_Phy_Process(void) Esta función está dentro del bucle infinito while(1) y no tiene nada en su interior que nos pueda interesar para llegar a nuestro objetivo. 6.1.2 Función void MX_SubGHz_Phy_Init(void) Esta función es invocada junto con las demás funciones para iniciar los periféricos de la placa. Si nos introducimos dentro de ella, podremos encontrar que se hace nuevamente uso de dos funciones. Estas son SystemApp_Init() y SubghzApp_Init() , de las cuales sólo nos interesa la segunda, ya que en su interior se hace uso de la función PingPong_Process() , función que será la que modificaremos posteriormente para adaptarla a nuestro objetivo. PingPong_Process() es una función situada en el archivo subghz_phy_app.c (apéndice A). En ella, inicialmente se reparte la función de maestro (Master) y esclavo (Slave) entre las placas. El Master será quien envíe la cadena de caracteres "PING" y recibirá la cadena de caracteres "PONG". Una vez recibida la cadena "PONG" volverá a mandar la cadena "PING" y así de manera indefinida. De la misma manera pero al contrario, el Slave en cuanto reciba la cadena "PING", enviará la cadena "PONG" y así de manera indefinida. Nada más arrancar el programa se asume por defecto el papel de master y se genera un retraso aleatorio denominado random_delay . Tras una serie de iteraciones del programa, cada placa va alternando su función de Slave y de Master, pero cada placa con un retraso diferente. Gracias a esto, llegará un punto en el que una placa sea Master y mande la cadena "PING" y la otra sea Slave y reciba dicha cadena. En ese preciso instante se realizará la conexión y se entrará de manera indefinida en el bucle de envío y recepción de "PING" y de "PONG", donde una placa hace la función de Master y otra la función de Slave. 6.2 Versión 1: Conexión UART. Esta versión surge de la necesidad de poder analizar la información que se transmite y depurar el código desde una consola, en este caso en CoolTerm. Para ello, haremos uso del UART. UART son las siglas de Universal Asynchronous Receiver-Transmitter y es el componente que permite la comunicación serie de la placa con el ordenador. Antes de empezar y para facilitar las modificaciones, comentaremos las funciones implicadas con la conexión LoRa hasta la versión 4, de esta manera nada procedente con la conexión interferirá en lo que añadamos. Una vez hecho esto, modificaremos la configuración conveniente en el elemento " SubGHz_- Phy_PingPong.ioc " del proyecto dentro del STM32CubeIDE y posteriormente generaremos el código. De esta manera, se crea la variable UART_HandleTypeDef huart2 y se inicializa todo lo necesario con la función MX_USART2_UART_Init(void) . 6.3 Versión 2: Conexión con SHT20. 33 Antes de dar por finalizar la versión, hacemos una serie de pruebas de su correcto funcionamiento. Figura 6.1 Muestra de la salida por consola del UART: Ejemplo "Hola, mundo!". Se hace uso del software CoolTerm. A partir de ahora, con solo usar la función HAL_UART_Transmit pasándole los parámetros adecuados (entre ellos huart2 ) podremos transmitir información por el UART. 6.3 Versión 2: Conexión con SHT20. A continuación se comenzó con la integración del sensor de temperatura y humedad SHT20 de sensirion ® . Si observamos el datasheet de dicho sensor [B], podemos ver que utiliza una comunicación I2C. Lo primero que hacemos es configurar los pines necesarios para poder usar dicha comunicación. Nuevamente, nos vamos al elemento " SubGHz_Phy_PingPong.ioc " y en conectividad configuramos los pines necesarios. En esta ocasión, asignamos el pin PA10 a I2C1_SDA y PA9 a I2C1_SCL, de manera que, como su propio nombre indica, las líneas SDA y SCL de la comunicación I2C irán por el pin PA10 y por el pin PA9, respectivamente. Generamos el código y obtenemos (de manera similar a como pasaba con el UART) la declaración de I2C_HandleTypeDef hi2c1 y la inicialización del periférico I2C de la placa mediante MX_- I2C1_Init(). Ya está lista nuestra placa para el uso del sensor, a continuación se presenta el uso de dichas funciones. Tras una búsqueda por repositorios web, hemos encontrado unas librerías [A] que resultan útiles para el uso de dicho sensor, de manera que solamente tendremos que hacer una adaptación a lo que nos interesa. En dichas librerías, trataremos los datos recibidos por el sensor en función de las indicaciones del datasheet y los transformaremos en datos legibles para nosotros. Destacaremos el uso de las siguientes funciones: •uint16_t SHT2x_GetRaw(uint8_t cmd) : Encargada de enviar el comando adecuado al sensor y leer un valor bruto de 16 bits del mismo. •float SHT2x_GetTemperature(uint8_t hold) : La cual nos devuelve la temperatura en grados centígrados (hace uso de SHT2x_GetRaw). •float SHT2x_GetRelativeHumidity(uint8_t hold) : Nos devolverá la humedad relativa en tanto por ciento (también haciendo uso de SHT2x_GetRaw ). 34 Capítulo 6. Metodología y Desarrollo Con todo lo anterior, tras probarlo y conectar el sensor a sus correspondientes pines tal y como se muestra en la figura 6.2, podemos obtener el valor de la temperatura y la humedad relativa correctamente. Solo falta comunicarlo por el UART y podremos verlo en consola. Figura 6.2 Esquema de conexiones de la placa con el sensor SHT20. Figura 6.3 Salida del UART que muestra la temperatura y la RH en tiempo real. Se hace uso del software CoolTerm. Como podemos observar en la figura 6.3, el sensor está tomando una temperatura de 33.5 º C y una humedad relativa de 50.7%. 6.4 Versión 3: Implementación de retardos. Una vez que tenemos funcionando correctamente los sensores, nuestra intención es hacer una medición en intervalos de tiempo, de manera que sólo se envíe la información pasado el intervalo de tiempo que hayamos programado. 6.5 Versión 4: Conexión entre placas. 35 Sin hacer cambios, ahora mismo la temperatura y la humedad relativa se transmiten en tiempo real y nuestro objetivo es que se vayan transmitiendo cada cinco minutos. Para eso bastará con hacer uso de la función HAL_Delay(tiempo*1000) , de esta manera bastará con pasarle como parámetro el tiempo (en segundos) que queramos que esté pausado el programa. Aunque lo dejemos así, no funcionará, ya que el proyecto SubGHz_Phy_PingPong trae por defecto la función HAL_Delay( )sobrescrita en el fichero "sys_app.c". Para solucionarlo, basta con comentar dicha función en ese fichero y ya automáticamente toma su funcionamiento habitual de la librería "HAL". Figura 6.4 Salida del UART que muestra la temperatura y la RH para tiempo igual a 5 segundos. Se hace uso del software CoolTerm. Figura 6.5 Salida del UART que muestra la temperatura y la RH para tiempo igual a 1 segundo. Se hace uso del software CoolTerm. Como podemos ver en las figuras 6.4, 6.5 y 6.6, tras modificar varias veces el intervalo de tiempo, comprobamos que los retardos funcionan correctamente. 6.5 Versión 4: Conexión entre placas. Lo siguiente que tenemos que hacer es interconectar las placas mediante LoRa. Para ello, en principio bastaría con quitar los comentarios puestos en las funciones que comentamos en la versión 1 (Punto 6.2), es decir, void MX_SubGHz_Phy_Init(void)yvoid MX_SubGHz_Phy_Init(void). Tras realizar las pruebas de conexión y comprobar un correcto funcionamiento del envío de las cadenas "PING" y "PONG" del proyecto, podemos confirmar que nuestras modificaciones no han hecho efecto en el funcionamiento del proyecto inicial. 36 Capítulo 6. Metodología y Desarrollo Figura 6.6 Salida del UART que muestra la temperatura y la RH para tiempo igual a 30 segundos. Se hace uso del software CoolTerm. Ahora es el turno de cambiar el mensaje a enviar. Para ello , creamos una función propia denominada void send_temp(char temp_y_hum[100], int size) en el directorio subghz_phy_app.c donde pasaremos la cadena de caracteres con información de la temperatura y la humedad relativa. Cada vez que la llamemos desde el main.c, se introducirá la información en la variable que posteriormente se enviará por LoRa. A partir de ahora, cada vez que recibamos la palabra "PING", si estamos en la primera interacción enviaremos "PONG" a modo de confirmación de conexión y en las siguientes interacciones en vez de enviar "PONG" responderemos con la temperatura y la humedad relativa. Se experimentaron una serie de errores con la información que se recibía del sensor en la placa transmisora, de manera que no se recibía ninguna temperatura y humedad relativa. Esto se debía a que no se inicializaba correctamente los periféricos relacionados con el sensor, por lo que hemos incluido en el while(1) del main.c las funciones de inicialización necesarias para el sensor, solucionando así los problemas y recibiendo perfectamente la temperatura y la humedad relativa en la placa receptora. Figura 6.7 Salida del UART que muestra la temperatura y la RH recibida en el receptor y los mensajes de temperatura enviada en el transmisor. Se hace uso del software CoolTerm. 6.6 Versión 5: Diferenciación de placas. 37 6.6 Versión 5: Diferenciación de placas. Como se indicaba en la versión 0 (capítulo 6.5), se elige quién es el transmisor y quién es el receptor de manera aleatoria al arrancar las placas, de manera que no podíamos elegir quién era cada cual. Para solucionar esto, hemos hecho una diferenciación de códigos, de manera que en uno de los códigos, la placa que posea dicho código, siempre será Master y no habrá posibilidad de que sea Slave (Transmisor). Como el Slave es el transmisor, será el que tenga conectado el sensor SHT20 y, por tanto, no tocaremos el código respecto a la versión anterior, solamente haremos que siempre sea Slave y que no haya posibilidad de cambio a Master. En el caso del Master, debido a que será el receptor de la temperatura, no tendrá conectado el sensor y solamente será el encargado de recibir la información, luego nos sobra todo lo relacionado con las funciones para la lectura del sensor. Además, modificaremos el código para que siempre sea Master y no exista la posibilidad de que se le asigne el papel de Slave. Una vez hecha estas modificaciones, introducimos el código correspondiente a la placa que hará de receptor (Master) y el que hará de transmisor (Slave). Con todo esto, el proyecto estaría en pleno funcionamiento a falta de modificar a nuestro interés el intervalo de tiempo de las medidas. En la siguiente figura podemos ver que el intervalo de tiempo es de 5 minutos. Figura 6.8 Salida del UART que muestra la temperatura y la RH recibida en el receptor y los mensajes de temperatura enviada en el transmisor cada 5 minutos. Se hace uso del software CoolTerm. 7 Experimentos y resultados Una vez completado el proyecto, empezaremos con unas series de experimentos, con los que queremos poner a prueba su capacidad de funcionamiento, como por ejemplo indicar qué alcance tiene. 7.1 Toma de temperatura y humedad relativa en el tiempo. Este experimento consistirá en realizar medidas en la temperatura y la humedad relativa de manera periódica durante un intervalo de tiempo. El objetivo de este experimento es comprobar un correcto funcionamiento del proyecto durante un tiempo prolongado de tiempo. Para ello, hemos configurado nuestro transmisor para que transmita la temperatura y la humedad relativa cada 5 minutos, durante 24 horas seguidas, obteniendo así 288 muestras para un mismo día. Este experimento se ha realizado en dos escenarios. Uno de ellos en Sevilla capital entre el 9 y 10 de Agosto de 2021 y otro en Guadalcanal (Sevilla) entre el 14 y 15 de Agosto de 2021. 7.1.1 Toma de temperatura y humedad relativa en Sevilla. Sevilla es considerada la capital de provincia más cálida de la península ibérica, de manera que en los meses de Julio y Agosto se suele superar los 33-40 º C. Respecto a la humedad, la provincia de Sevilla tiene registrado un clima árido o seco, siendo la capital donde se registran los índices de humedad anual más altos. Sabiendo esto, hemos colocado el sensor en el barrio de la Macarena, en la cocina de un tercer piso y hemos registrado 288 muestras de temperatura y humedad relativa en 24 horas, obteniendo una gráfica como la de la figura 7.1. 7.1.2 Toma de temperatura y humedad relativa en Guadalcanal. Guadalcanal está situada al norte de la provincia de Sevilla, concretamente en la Sierra Norte, a una altura de 662 metros sobre el nivel del mar. En Guadalcanal, la temperatura máxima promedio diaria es más de 28 º C desde el 16 de junio al 11 de septiembre. Respecto a la humedad, Guadalcanal suele tener una humedad relativa menor que la de Sevilla capital. Teniendo en cuenta que las medidas fueron tomadas en plena ola de calor, se tomó una muestra cada 5 minutos durante 24 horas con el sensor colocado en plena calle, donde el sol podía darle de manera directa. La gráfica resultante es la mostrada en la figura 7.2. 39 46 Capítulo A. Código utilizado para la programación de la placa /* Infinite loop */ /* USER CODE BEGIN WHILE */ while (1) { /* -------- APLICACIÓN DE LECTURA DEL SENSOR SHT --------*/ /* Retraso que añadimos */ //HAL_Delay(seg_1); /* USER CODE END WHILE */ MX_SubGHz_Phy_Process(); /* USER CODE BEGIN 3 */ /* Inicializamos en cada ejecución las librerías del sensor y de la comunicación I2C*/ MX_I2C1_Init(); SHT2x_Init(&hi2c1); SHT2x_SetResolution(RES_14_12); float cel = SHT2x_GetTemperature(1); float rh = SHT2x_GetRelativeHumidity(1); char temperatura_y_humedad[100] = { 0 }; sprintf(temperatura_y_humedad, "%d.%do ¯C %d.%d%% RH\n\r", SHT2x_GetInteger(cel), SHT2x_GetDecimal(cel, 1), SHT2x_GetInteger(rh), SHT2x_GetDecimal(rh, 1)); send_temp(temperatura_y_humedad, sizeof(temperatura_y_humedad)); } /* USER CODE END 3 */ } A.1.2 Librería para el sensor SHT20. /* An STM32 HAL library written for the SHT2x temperature/humidity sensor series. */ /* Libraries by @eepj www.github.com/eepj */ #include "sht2x_for_stm32_hal.h" #include "main.h" #ifdef __cplusplus extern "C"{ #endif I2C_HandleTypeDef *_sht2x_ui2c; A.1 Transmisor de la temperatura. 47 /** * @brief Initializes the SHT2x temperature/humidity sensor. * @param hi2c User I2C handle pointer. */ void SHT2x_Init(I2C_HandleTypeDef *hi2c) { _sht2x_ui2c = hi2c; } /** * @brief Performs a soft reset. */ void SHT2x_SoftReset(void){ uint8_t cmd = SHT2x_SOFT_RESET; HAL_I2C_Master_Transmit(_sht2x_ui2c, SHT2x_I2C_ADDR << 1, &cmd, 1, SHT 2x_TIMEOUT); } /** * @brief Gets the value stored in user register. * @return 8-bit value stored in user register, 0 to 255. */ uint8_t SHT2x_ReadUserReg(void) { uint8_t val; uint8_t cmd = SHT2x_READ_REG; HAL_I2C_Master_Transmit(_sht2x_ui2c, SHT2x_I2C_ADDR << 1, &cmd, 1, SHT 2x_TIMEOUT); HAL_I2C_Master_Receive(_sht2x_ui2c, SHT2x_I2C_ADDR << 1, &val, 1, SHT2 x_TIMEOUT); return val; } /** * @brief Sends the designated command to sensor and read a 16-bit raw value. * @param cmd Command to send to sensor. * @return 16-bit raw value, 0 to 65535. */ uint16_t SHT2x_GetRaw(uint8_t cmd) { uint8_t val[3] = { 0 }; HAL_I2C_Master_Transmit(_sht2x_ui2c, SHT2x_I2C_ADDR << 1, &cmd, 1, SHT 2x_TIMEOUT); HAL_I2C_Master_Receive(_sht2x_ui2c, SHT2x_I2C_ADDR << 1, val, 3, SHT2x _TIMEOUT); return val[0] << 8 | val[1]; } 48 Capítulo A. Código utilizado para la programación de la placa /** * @brief Measures and gets the current temperature. * @param hold Holding mode, 0 for no hold master, 1 for hold master. * @return Floating point temperature value. */ float SHT2x_GetTemperature(uint8_t hold) { uint8_t cmd = (hold ? SHT2x_READ_TEMP_HOLD : SHT2x_READ_TEMP_NOHOLD); return -46.85 + 175.72 * (SHT2x_GetRaw(cmd) / 65536.0); } /** * @brief Measures and gets the current relative humidity. * @param hold Holding mode, 0 for no hold master, 1 for hold master. * @return Floating point relative humidity value. */ float SHT2x_GetRelativeHumidity(uint8_t hold) { uint8_t cmd = (hold ? SHT2x_READ_RH_HOLD : SHT2x_READ_RH_NOHOLD); return -6 + 125.00 * (SHT2x_GetRaw(cmd) / 65536.0); } /** * @brief Sets the measurement resolution. * @param res Enum resolution. * @note Available resolutions: RES_14_12, RES_12_8, RES_13_10, RES _11_11. * @note RES_14_12 = 14-bit temperature and 12-bit RH resolution, etc. */ void SHT2x_SetResolution(SHT2x_Resolution res) { uint8_t val = SHT2x_ReadUserReg(); val = (val & 0x7e) | res; uint8_t temp[2] = { SHT2x_WRITE_REG, val }; HAL_I2C_Master_Transmit(_sht2x_ui2c, SHT2x_I2C_ADDR << 1, temp, 2, SHT 2x_TIMEOUT); } /** * @brief Converts degrees Celsius to degrees Fahrenheit. * @param celsius Floating point temperature in degrees Celsius. * @return Floating point temperature in degrees Fahrenheit. */ float SHT2x_CelsiusToFahrenheit(float celsius) { return (9.0 / 5.0) * celsius + 32; } /** * @brief Converts degrees Celsius to Kelvin. * @param celsius Floating point temperature in degrees Celsius. * @return Floating point temperature in Kelvin. */ float SHT2x_CelsiusToKelvin(float celsius) { return celsius + 273; } A.1 Transmisor de la temperatura. 49 /** * @brief Gets the integer part of a floating point number. * @note Avoids the use of sprinf floating point formatting. * @param num Floating point number. * @return Integer part of floating point number. */ int32_t SHT2x_GetInteger(float num) { return num / 1; } /** * @brief Gets the decimal part of a floating point number. * @note Avoids the use of sprinf floating point formatting. * @param num Floating point number. * @return Decimal part of floating point number. */ uint32_t SHT2x_GetDecimal(float num, int digits) { float postDec = num - SHT2x_GetInteger(num); return postDec * SHT2x_Ipow(10, digits); } /** * @brief Integer equivalent of pow() in math.h. * @param base Base. * @param power Power. * @return */ uint32_t SHT2x_Ipow(uint32_t base, uint32_t power) { uint32_t temp = base; for (uint32_t i = 1; i < power; i++) temp *= base; return temp; } #ifdef __cplusplus } #endif 50 Capítulo A. Código utilizado para la programación de la placa A.1.3 Funciones de subghz_phy_app.c creadas/modificadas. /* USER CODE BEGIN PrFD */ /*Función que introducirá la temperatura y humedad en el buffer de envío . * Será llamada desde el main.c, donde habremos leído previamente la temperatura y la humedad*/ void send_temp(char temp_y_hum[100], int size) { for(int j=0;j<size;j++) { temperatura_y_humedad_TX[j] = temp_y_hum[j]; } } static void PingPong_Process(void) { Radio.Sleep(); switch (State) { case RX: if (RxBufferSize > 0) { if (inicio == 1) //Si es la primera ejecución del código { if (strncmp((const char *)BufferRx, PING, sizeof(PING) - 1) == 0) //Si hemos recibido un ping { inicio = 0; UTIL_TIMER_Stop(&timerLed); /* switch off red led */ BSP_LED_Off(LED_RED); /* slave toggles green led */ BSP_LED_Toggle(LED_GREEN); /* Add delay between RX and TX */ HAL_Delay(Radio.GetWakeupTime() + RX_TIME_MARGIN); /*Mensaje inicial para indicar que somos el transmisor de la temperatura y la humedad */ APP_LOG(TS_ON, VLEVEL_L, "Soy el TRANSMISOR de la temperatura\n\r "); /*slave sends PONG*/ APP_LOG(TS_ON, VLEVEL_L, "PONG" "\n\r"); memcpy(BufferTx, PONG, sizeof(PONG) - 1); //Aquí mandamos el mensaje PONG Radio.Send(BufferTx, PAYLOAD_LEN); } A.1 Transmisor de la temperatura. 51 else /* valid reception but not a PING as expected */ { /* Set device as master and start again */ //isMaster = true; Radio.Rx(RX_TIMEOUT_VALUE); } } if (inicio == 0) { if (strncmp((const char *)BufferRx, PING, sizeof(PING) - 1) == 0)//Si somos el transmisor { UTIL_TIMER_Stop(&timerLed); /* switch off red led */ BSP_LED_Off(LED_RED); /* slave toggles green led */ BSP_LED_Toggle(LED_GREEN); /* Add delay between RX and TX */ HAL_Delay(Radio.GetWakeupTime() + RX_TIME_MARGIN); char temperatura_y_humedad__transmitida[100] = {0}; //Variable donde guardaremos la temperatura y la humedad medida /* Igualamos las tablas recibidas y la que vamos a transmitir */ for(int j=0;j<sizeof(temperatura_y_humedad_TX);j++) { temperatura_y_humedad__transmitida[j] = temperatura_y_ humedad_TX[j]; } /* Copiamos en la variable BufferTx el valor de la temperatura y la humedad medida */ memcpy(BufferTx, temperatura_y_humedad__transmitida, sizeof( temperatura_y_humedad__transmitida) - 1); Radio.Send(BufferTx, PAYLOAD_LEN); //Enviamos la temperatura por el canal APP_LOG(TS_ON, VLEVEL_L,"Temperatura enviada""\n\r"); } else /* valid reception but not a PING as expected */ { Radio.Rx(RX_TIMEOUT_VALUE); } } } break; case TX: Radio.Rx(RX_TIMEOUT_VALUE); break; 52 Capítulo A. Código utilizado para la programación de la placa case RX_TIMEOUT: case RX_ERROR: if (isMaster == true) { HAL_Delay(Radio.GetWakeupTime() + RX_TIME_MARGIN + random_delay); /* master sends PING*/ memcpy(BufferTx, PING, sizeof(PING) - 1); Radio.Send(BufferTx, PAYLOAD_LEN); } else { Radio.Rx(RX_TIMEOUT_VALUE); } break; case TX_TIMEOUT: Radio.Rx(RX_TIMEOUT_VALUE); break; default: break; } } /* USER CODE END PrFD */ /******** (C) COPYRIGHT STMicroelectronics *****END OF FILE****/ A.2 Receptor de la temperatura. Las secciones siguientes irán dirigidas a la placa que se encargará de recibir la temperatura y la humedad relativa medida. A.2.1 Función main. int main(void) { /* Reset of all peripherals, Initializes the Flash interface and the Systick. */ HAL_Init(); /* Configure the system clock */ SystemClock_Config(); /* Initialize all configured peripherals */ MX_SubGHz_Phy_Init(); /* USER CODE BEGIN 2 */ MX_USART2_UART_Init(); //Para la comunicación UART /* USER CODE END 2 */ /* Infinite loop */ /* USER CODE BEGIN WHILE */ A.2 Receptor de la temperatura. 53 while (1) { /* USER CODE END WHILE */ MX_SubGHz_Phy_Process(); /* USER CODE BEGIN 3 */ } /* USER CODE END 3 */ } A.2.2 Función de subghz_phy_app.c modificada. static void PingPong_Process(void) { Radio.Sleep(); switch (State) { case RX: if (RxBufferSize > 0) { if (inicio == 1) //Primera vez que se ejecuta el código { if (strncmp((const char *)BufferRx, PONG, sizeof(PONG) - 1) == 0) //Si lo que hemos recibido es un PONG { inicio = 0; UTIL_TIMER_Stop(&timerLed); /* switch off green led */ BSP_LED_Off(LED_GREEN); /* master toggles red led */ BSP_LED_Toggle(LED_RED); /* Add delay between RX and TX */ HAL_Delay(Radio.GetWakeupTime() + RX_TIME_MARGIN); /*Mensaje inicial para indicar que somos el receptor de la temperatura*/ APP_LOG(TS_ON, VLEVEL_L, "Soy el RECEPTOR de la temperatura\n\r") ; //Modificación para la versión 3 /* master sends PING*/ APP_LOG(TS_ON, VLEVEL_L, "PING" "\n\r"); memcpy(BufferTx, PING, sizeof(PING) - 1); //Aquí mandamos el mensaje PING inicial Radio.Send(BufferTx, PAYLOAD_LEN); } 54 Capítulo A. Código utilizado para la programación de la placa else /* valid reception but neither a PING or a PONG message */ { /* Set device as master and start again */ isMaster = true; Radio.Rx(RX_TIMEOUT_VALUE); } } if (inicio == 0) //ahora pasamos a la comunicación de información { UTIL_TIMER_Stop(&timerLed); /* switch off green led */ BSP_LED_Off(LED_GREEN); /* master toggles red led */ BSP_LED_Toggle(LED_RED); /* Add delay between RX and TX */ HAL_Delay(Radio.GetWakeupTime() + RX_TIME_MARGIN); APP_LOG(TS_ON, VLEVEL_L,(const char *)BufferRx); //Aquí mostramos por consola el valor recibido de la temperatura memcpy(BufferTx, PING, sizeof(PING) - 1); Radio.Send(BufferTx, PAYLOAD_LEN); } } } break; case TX: Radio.Rx(RX_TIMEOUT_VALUE); break; case RX_TIMEOUT: case RX_ERROR: HAL_Delay(Radio.GetWakeupTime() + RX_TIME_MARGIN + random_delay); /* master sends PING*/ memcpy(BufferTx, PING, sizeof(PING) - 1); Radio.Send(BufferTx, PAYLOAD_LEN); else { Radio.Rx(RX_TIMEOUT_VALUE); } break; case TX_TIMEOUT: Radio.Rx(RX_TIMEOUT_VALUE); break; default: break; } } Apéndice B Secciones de datasheets utilizadas 55 DS13293 Rev 1 51/145 STM32WL55/54xx Pinouts, pin description and alternate functions 60 Notes Unless otherwise specified by a note, all I/Os are set as analog inputs during and after reset. Pin functions Alternate functions Functions selected through GPIOx_AFR registers Additional functions Functions directly selected/enabled through peripheral registers Table 18. Legend/abbreviations used in the pinout table (continued) Name Abbreviation Definition Table 19. STM32WL55/54xx pin definition Pin number Pin name (function after reset) Pin type I/O structure Notes Alternate functions Additional functions UFQFPN48 WLCSP59 UFBGA73 - E10 - VSS S - - - - 1D11C1 PB3 I/OFT_a- JTDO/TRACESWO, TIM2_CH2, SPI1_SCK, RF_IRQ0, USART1_RTS, DEBUG_RF_DTB1, CM4_EVENTOUT COMP1_INM, COMP2_INM, ADC_IN2, TAMP_IN3/WKUP3 2D9C2 PB4 I/OFT_fa- NJTRST, I2C3_SDA, SPI1_MISO, USART1_CTS, DEBUG_RF_LDORDY, TIM17_BKIN, CM4_EVENTOUT COMP1_INP, COMP2_INP, ADC_IN3 3-D2 PB5 I/OFT_a- LPTIM1_IN1, I2C1_SMBA, SPI1_MOSI, RF_IRQ1, USART1_CK, COMP2_OUT, TIM16_BKIN, CM4_EVENTOUT - - F7 E3 VSS S - - - - - F11 E2 VDD S - - - - 4 - E1 PB6 I/O FT_f - LPTIM1_ETR, I2C1_SCL, USART1_TX, TIM16_CH1N, CM4_EVENTOUT - 5-C3 PB7 I/OFT_f- LPTIM1_IN2, TIM1_BKIN, I2C1_SDA, USART1_RX, TIM17_CH1N, CM4_EVENTOUT - 6-D3 PB8 I/OFT_f- TIM1_CH2N, I2C1_SCL, RF_IRQ2, TIM16_CH1, CM4_EVENTOUT - Pinouts, pin description and alternate functions STM32WL55/54xx 52/145 DS13293 Rev 1 --C4 PB9 I/OFT_f- TIM1_CH3N, I2C1_SDA, SPI2_NSS/I2S2_WS, IR_OUT, TIM17_CH1, CM4_EVENTOUT - - - F2 PC0 I/O FT_f - LPTIM1_IN1, I2C3_SCL, LPUART1_RX, LPTIM2_IN1, CM4_EVENTOUT - - - F1 PC1 I/O FT_f - LPTIM1_OUT, SPI2_MOSI/I2S2_SD, I2C3_SDA, LPUART1_TX, CM4_EVENTOUT - --D4 PC2 I/OFTLPTIM1_IN2, SPI2_MISO, CM4_EVENTOUT - --D5 PC3 I/OFTLPTIM1_ETR, SPI2_MOSI/I2S2_SD, LPTIM2_ETR, CM4_EVENTOUT - - - F3 PC4 I/O FT - CM4_EVENTOUT - - - E4 PC5 I/O FT - CM4_EVENTOUT - - - G2 PC6 I/O FT - I2S2_MCK, CM4_EVENTOUT - 7H11D6 PA0 I/OFT_a- TIM2_CH1, I2C3_SMBA, I2S_CKIN, USART2_CTS, COMP1_OUT, DEBUG_PWR_REGLP1S, TIM2_ETR, CM4_EVENTOUT TAMP_IN2/WKUP1 8 G10 G3 PA1 I/O FT_a - TIM2_CH2, LPTIM3_OUT, I2C1_SMBA, SPI1_SCK, USART2_RTS, LPUART1_RTS, DEBUG_PWR_REGLP2S, CM4_EVENTOUT - 9F9H2 PA2 I/OFT_a- LSCO, TIM2_CH3, USART2_TX, LPUART1_TX, COMP2_OUT, DEBUG_PWR_LDORDY, CM4_EVENTOUT LSCO 10 C8 H1 PA3 I/O FT_a - TIM2_CH4, I2S2_MCK, USART2_RX, LPUART1_RX, CM4_EVENTOUT - - E6 G5 VSS S - - - - Table 19. STM32WL55/54xx pin definition (continued) Pin number Pin name (function after reset) Pin type I/O structure Notes Alternate functions Additional functions UFQFPN48 WLCSP59 UFBGA73 DS13293 Rev 1 53/145 STM32WL55/54xx Pinouts, pin description and alternate functions 60 11 K11 H5 VDD S - - - - 12 J10 J1 PA4 I/O FT - RTC_OUT2, LPTIM1_OUT, SPI1_NSS, USART2_CK, DEBUG_SUBGHZSPI_ NSSOUT, LPTIM2_OUT, CM4_EVENTOUT - 13 H9 J2 PA5 I/O FT - TIM2_CH1, TIM2_ETR, SPI2_MISO, SPI1_SCK, DEBUG_SUBGHZSPI_ SCKOUT, LPTIM2_ETR, CM4_EVENTOUT - 14 G8 F4 PA6 I/O FT - TIM1_BKIN, I2C2_SMBA, SPI1_MISO, LPUART1_CTS, DEBUG_SUBGHZSPI_ MISOOUT, TIM16_CH1, CM4_EVENTOUT - 15 E8 H3 PA7 I/O FT_fa - TIM1_CH1N, I2C3_SCL, SPI1_MOSI, COMP2_OUT, DEBUG_SUBGHZSPI_ MOSIOUT, TIM17_CH1, CM4_EVENTOUT - 16 L10 J3 PA8 I/O FT_a - MCO, TIM1_CH1, SPI2_SCK/I2S2_CK, USART1_CK, LPTIM2_OUT, CM4_EVENTOUT - 17 K9 E5 PA9 I/O FT_fa - TIM1_CH2, SPI2_NSS/I2S2_WS, I2C1_SCL, SPI2_SCK/I2S2_CK, USART1_TX, CM4_EVENTOUT - - - H4 PB10 I/O FT_f - TIM2_CH3, I2C3_SCL, SPI2_SCK/I2S2_CK, LPUART1_RX, COMP1_OUT, CM4_EVENTOUT - --G4 PB11 I/OFT_f- TIM2_CH4, I2C3_SDA, LPUART1_TX, COMP2_OUT, CM4_EVENTOUT - 18 J8 F5 NRST I/O FT - - - 19 H7 J5 PH3-BOOT0 I/O FT - CM4_EVENTOUT BOOT0 -L8- VDD S - - - - Table 19. STM32WL55/54xx pin definition (continued) Pin number Pin name (function after reset) Pin type I/O structure Notes Alternate functions Additional functions UFQFPN48 WLCSP59 UFBGA73 Pinouts, pin description and alternate functions STM32WL55/54xx 54/145 DS13293 Rev 1 - K7 - VSS S - - - - - J6 H6 VSSRF S - - - - - H5 G6 VSSRF S - - - - 20 L6 J6 RFI_P I RF - - - 21 K5 H7 RFI_N I RF - - - - G4 G7 VSSRF S - - - - - J4 - VSSRF S - - - - 22 L4 J8 RFO_LP O RF - - - - - G8 VSSRF S - - - - 23 K3 J9 RFO_HP O RF - - - - H3 - VSSRF S - - - - 24 L2 H9 VR_PA S - - - - 25 H1 H8 VDDPA S - - - - - K1 - VSSRF S - - - - 26 G2 G9 OSC_IN I RF - - - 27 F1 F8 OSC_OUT O RF - - - - F3 - VSSRF S - - - - 28 E2 E8 VDDRF S - - - - 29 D1 F7 VDDRF1V55 S - - - - - F5 D9 VSS S - - - - - - E9 VDD S - - - - 30 B1 F6 PB0-VDD_TCXO I/O TT - COMP1_OUT, CM4_EVENTOUT - - - E7 PB1 I/O FT_a - LPUART1_RTS_DE, LPTIM2_IN1, CM4_EVENTOUT COMP2_INP, ADC_IN5 31 - D8 PB2 I/O FT_a - LPTIM1_OUT, I2C3_SMBA, SPI1_NSS, DEBUG_RF_SMPSRDY, CM4_EVENTOUT COMP1_INP, COMP2_INM, ADC_IN4 32 - E6 PB12 I/O FT - TIM1_BKIN, I2C3_SMBA, SPI2_NSS/I2S2_WS, LPUART1_RTS, CM4_EVENTOUT - Table 19. STM32WL55/54xx pin definition (continued) Pin number Pin name (function after reset) Pin type I/O structure Notes Alternate functions Additional functions UFQFPN48 WLCSP59 UFBGA73 DS13293 Rev 1 55/145 STM32WL55/54xx Pinouts, pin description and alternate functions 60 - - D7 PB13 I/O FT_fa - TIM1_CH1N, I2C3_SCL, SPI2_SCK/I2S2_CK, LPUART1_CTS, CM4_EVENTOUT ADC_IN0 - - C6 PB14 I/O FT_fa - TIM1_CH2N, I2S2_MCK, I2C3_SDA, SPI2_MISO, CM4_EVENTOUT ADC_IN1 33 D3 C8 PA10 I/O FT_fa - RTC_REFIN, TIM1_CH3, I2C1_SDA, SPI2_MOSI/I2S2_SD, USART1_RX, DEBUG_RF_HSE32RDY, TIM17_BKIN, CM4_EVENTOUT COMP1_INM, COMP2_INM, DAC_OUT1, ADC_IN6 34 E4 B9 PA11 I/O FT_fa - TIM1_CH4, TIM1_BKIN2, LPTIM3_ETR, I2C2_SDA, SPI1_MISO, USART1_CTS, DEBUG_RF_NRESET, CM4_EVENTOUT COMP1_INM, COMP2_INM, ADC_IN7 35 D5 A9 PA12 I/O FT_fa - TIM1_ETR, LPTIM3_IN1, I2C2_SCL, SPI1_MOSI, RF_BUSY, USART1_RTS, CM4_EVENTOUT ADC_IN8 36 D7 B8 PA13 I/O FT_a - JTMS-SWDIO, I2C2_SMBA, IR_OUT, CM4_EVENTOUT ADC_IN9 - C2 B7 VSS S - - - - -A2A7 VDD S - - - - 37 - A8 VBAT S - - - - 38 - C7 PC13 I/O FT - CM4_EVENTOUT TAMP_IN1/ RTC_OUT1/RTC_TS/ WKUP2 39 B3 B6 PC14-OSC32_IN I/O FT - CM4_EVENTOUT OSC32_IN 40 A4 C5 PC15- OSC32_OUT I/O FT - CM4_EVENTOUT OSC32_OUT - - B5 VREF+ S - - - - 41 B5 A5 VDDA S - - - - - C4 - VSS S - - - - Table 19. STM32WL55/54xx pin definition (continued) Pin number Pin name (function after reset) Pin type I/O structure Notes Alternate functions Additional functions UFQFPN48 WLCSP59 UFBGA73 Pinouts, pin description and alternate functions STM32WL55/54xx 56/145 DS13293 Rev 1 42 C6 A4 PA14 I/O FT_a - JTCK-SWCLK, LPTIM1_OUT, I2C1_SMBA, CM4_EVENTOUT ADC_IN10 43 A8 B3 PA15 I/O FT_fa - JTDI, TIM2_CH1, TIM2_ETR, I2C2_SDA, SPI1_NSS, CM4_EVENTOUT COMP1_INM, COMP2_INP, ADC_IN11 - - B4 PB15 I/O FT_f TIM1_CH3N, I2C2_SCL, SPI2_MOSI/I2S2_SD, CM4_EVENTOUT - 44 A6 - VDD S - - - - - B7 - VSS S - - - - 49(1) G6 - VSS S - - - - 45 B9 B2 VFBSMPS S - - - - 46 A10 A2 VDDSMPS S - - - - 47 B11 B1 VLXSMPS S - - - - 48 C10 A1 VSSSMPS S - - - - 1. Pin 49 is an exposed pad that must be connected to VSS. Table 19. STM32WL55/54xx pin definition (continued) Pin number Pin name (function after reset) Pin type I/O structure Notes Alternate functions Additional functions UFQFPN48 WLCSP59 UFBGA73 Índice de Figuras 2.1 Perspectivas del internet de las cosas [11] 4 2.2 Circuito impreso en una etiqueta electrónica [20] 8 2.3 Visión del internet de las cosas (IoT) [10] 9 3.1 Modulación de la amplitud (AM) [13] 12 3.2 Modulación de la frecuencia (FM) [13] 12 3.3 Modulación por desplazamiento de frecuencia (FSK) [13] 13 3.4 Barrido entre las dos frecuencias (descendente y ascendente en frecuencia) [13] 14 3.5 Esquema de la arquitectura de una red LoRa [19] 17 3.6 Esquema de las capas de la arquitectura de una red LoRa [19] 17 3.7 Ejemplo de conexión de la arquitectura de una red LoRa [19] 19 4.1 Esquema de conexión física [15] 22 4.2 Ejemplo de comunicación I2C [14] 22 4.3 Ejemplo de envío de datos en I2C [14] 23 4.4 Ejemplo del inicio de la comunicación en I2C [14] 23 4.5 Ejemplo del fin de la comunicación en I2C [14] 23 4.6 Ejemplo del envío de dirección en I2C [14] 24 4.7 Esquema de envío de datos de máster a esclavo en I2C [14] 24 4.8 Esquema de envío de datos del esclavo al maestro en I2C [14] 24 5.1 Imagen física de la placa STM32WL55JC 16] 28 5.2 Vista física del sensor SHT20 28 5.3 Módulo utilizado para incorporar el sensor SHT20 a la placa 29 5.4 Vista general del entorno de desarrollo integrado STM32CubeIDE 29 5.5 Ventana de inicio del software CoolTerm 30 6.1 Muestra de la salida por consola del UART: Ejemplo "Hola, mundo!". Se hace uso del software CoolTerm 33 6.2 Esquema de conexiones de la placa con el sensor SHT20 34 6.3 Salida del UART que muestra la temperatura y la RH en tiempo real. Se hace uso del software CoolTerm 34 6.4 Salida del UART que muestra la temperatura y la RH para tiempo igual a 5 segundos. Se hace uso del software CoolTerm 35 6.5 Salida del UART que muestra la temperatura y la RH para tiempo igual a 1 segundo. Se hace uso del software CoolTerm 35 69 70 Índice de Figuras 6.6 Salida del UART que muestra la temperatura y la RH para tiempo igual a 30 segundos. Se hace uso del software CoolTerm 36 6.7 Salida del UART que muestra la temperatura y la RH recibida en el receptor y los mensajes de temperatura enviada en el transmisor. Se hace uso del software CoolTerm 36 6.8 Salida del UART que muestra la temperatura y la RH recibida en el receptor y los mensajes de temperatura enviada en el transmisor cada 5 minutos. Se hace uso del software CoolTerm 37 7.1 Temperatura y humedad relativa en Sevilla. Gráfica elaborada con el software Matlab®40 7.2 Temperatura y humedad relativa en Guadalcanal. Gráfica elaborada con el software Matlab®40 7.3 Cobertura en el barrio de la Macarena de Sevilla (SF = 7). Mapa creado con ayuda de Google MyMaps®41 7.4 Cobertura en el barrio de la Macarena de Sevilla (SF = 12). Mapa creado con ayuda de Google MyMaps®42 Índice de Tablas 2.1 Aplicaciones y servicios de ejemplo de IoT (PARTE 1/3)[12] 5 2.2 Aplicaciones y servicios de ejemplo de IoT (PARTE 2/3)[12] 6 2.3 Aplicaciones y servicios de ejemplo de IoT (PARTE 3/3)[12] 7 3.1 Frecuencias LoRa por país [13] 20 5.1 Conjunto de características más importantes de las placas STM32WL55JC agrupadas según su ámbito (TABLA 1/2) [16] 26 5.2 Conjunto de características más importantes de las placas STM32WL55JC agrupadas según su ámbito (TABLA 2/2)[16] 27 71