Estación meteorológica LoRaWANlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo...La base de las...

MAESTRÍA ENSISTEMAS EMBEBIDOS

MEMORIA DEL TRABAJO FINAL

Estación meteorológica LoRaWAN

Autor:Esp. Ing. Christian Yánez Flores

Director:Dr. Ing. Pablo Gomez (FIUBA)

Jurados:Mg. Ing. Iván Andrés León (FIUBA)

Dr. Mariano Llamedo Soria (UTN-FRBA)Ing. Marcelo Romero (UNSAM)

Este trabajo fue realizado en la Ciudad Autónoma de Buenos Aires,entre marzo de 2019 y abril de 2020.

III

Resumen

La presente memoria describe el diseño y construcción de un prototipo deestación meteorológica autónoma que transmite datos mediante tecnología

LoRa. El diseño de la estación prioriza el bajo consumo, el bajo costo y nace apartir de una solicitud de la empresa XnCompany.

El sistema está conformado por módulos de adquisición y procesamiento dedatos, comunicación mediante radiofrecuencia, telemetría, alimentación y

gestión de energía.

Para la realización de este trabajo se aplicaron conocimientos relacionados asistemas operativos, procesamiento de señales, sistemas embebidos distribuidos

y gestión de la tecnología.

V

Agradecimientos

Agradezco infinitamente el apoyo y colaboración de mis profesores y compañe-ros.

VII

Índice general

Resumen III

1. Introducción General 11.1. Descripción técnica y sustentación teórica . . . . . . . . . . . . . . . 1

1.1.1. Estaciones meteorológicas . . . . . . . . . . . . . . . . . . . . 11.1.2. LoRa y LoRaWAN . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Estaciones meteorológicas de referencia . . . . . . . . . . . . . . . . 31.3. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.4. Objetivos y alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.4.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . 51.4.2. Objetivos específicos . . . . . . . . . . . . . . . . . . . . . . . 51.4.3. Alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2. Introducción Específica 72.1. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2. Visión general de los elementos constitutivos . . . . . . . . . . . . . 82.3. Descripción funcional y estructural . . . . . . . . . . . . . . . . . . . 82.4. Análisis de viabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3. Diseño e Implementación 133.1. Desarrollo del hardware . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1. Procesamiento y comunicación . . . . . . . . . . . . . . . . . 133.1.2. Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.3. Gestión y control de energía . . . . . . . . . . . . . . . . . . . 173.1.4. Diseño del circuito impreso . . . . . . . . . . . . . . . . . . . 23

3.2. Desarrollo del firmware . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.1. Sistema general . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2.2. Módulo de control . . . . . . . . . . . . . . . . . . . . . . . . 263.2.3. Módulo de adquisición . . . . . . . . . . . . . . . . . . . . . 273.2.4. Módulo de estado . . . . . . . . . . . . . . . . . . . . . . . . 293.2.5. Módulo de comunicación . . . . . . . . . . . . . . . . . . . . 29

4. Ensayos y Resultados 374.1. Pruebas funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 374.2. Pruebas de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.3. Pruebas de consumo . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4. Pruebas de alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.5. Detalle de costos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

5. Conclusiones 495.1. Objetivos alcanzados . . . . . . . . . . . . . . . . . . . . . . . . . . . 495.2. Próximos pasos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Bibliografía 51

IX

Índice de figuras

1.1. Ilustración de la conexión típica de una EMA. . . . . . . . . . . . . . 21.2. Estructura de la red LoRaWAN1. . . . . . . . . . . . . . . . . . . . . 31.3. Diagrama de bloques del sistema implementado. . . . . . . . . . . . 5

2.1. Diagrama de bloques detallado del sistema. . . . . . . . . . . . . . . 92.2. Esquema modular del sistema. . . . . . . . . . . . . . . . . . . . . . 92.3. Diagrama de secuencia de funcionamiento. . . . . . . . . . . . . . . 10

3.1. Versiones utilizadas del módulo XDOT. . . . . . . . . . . . . . . . . 153.2. Anemómetro de paletas. . . . . . . . . . . . . . . . . . . . . . . . . . 153.3. Veleta (Relación dirección-ángulo). . . . . . . . . . . . . . . . . . . . 163.4. Pluviómetro. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163.5. Disposición de los sensores sobre la estructura. . . . . . . . . . . . . 173.6. Módulo comercial BME 280. . . . . . . . . . . . . . . . . . . . . . . . 173.7. Celda li-ion 18650. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.8. Panel solar. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213.9. Cargador regulador de batería li-ion 18650. . . . . . . . . . . . . . . 223.10. Regulador de voltaje MCP1700. . . . . . . . . . . . . . . . . . . . . . 223.11. Placa de prueba versión 1. . . . . . . . . . . . . . . . . . . . . . . . . 233.12. Placa de prueba versión 2. . . . . . . . . . . . . . . . . . . . . . . . . 233.13. Modelo 3D versión final. . . . . . . . . . . . . . . . . . . . . . . . . . 243.14. Arquitectura de firmware sobre Mbed OS2. . . . . . . . . . . . . . . 253.15. Diagrama de flujo del sistema implementado. . . . . . . . . . . . . . 263.16. Arquitectura del firmware implementado. . . . . . . . . . . . . . . . 263.17. Diagrama de estados y transiciones general para las tareas imple-

mentadas3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273.18. Diagrama de clases para el módulo de control. . . . . . . . . . . . . 273.19. Máquina de estados genérica implementada. . . . . . . . . . . . . . 283.20. Stack de datos formado para la transmisión. . . . . . . . . . . . . . . 293.21. Diagrama de flujo implementado para el módulo de adquisición. . 303.22. Diagrama de clase para el módulo de adquisición. . . . . . . . . . . 313.23. Diagrama de clase para el módulo de estado. . . . . . . . . . . . . . 313.24. Ventanas de recepción para dispositivos de clase A. . . . . . . . . . 313.25. Trama implementada para la recepción de datos. . . . . . . . . . . . 323.26. Diagrama de flujo implementado para el módulo de comunicación. 333.27. Diagrama de flujo implementado para la subrutina de recepción. . 343.28. Diagrama de clases para el módulo de comunicación. . . . . . . . . 35

4.1. Esquema de conexión para el banco de ensayos de las pruebas fun-cionales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

4.2. Banco de ensayos para las pruebas funcionales. . . . . . . . . . . . 384.3. Salida de respuesta del módulo de adquisición . . . . . . . . . . . . 394.4. Salida de respuesta del módulo de estado. . . . . . . . . . . . . . . . 39

X

4.5. Configuración del módulo de comunicación. . . . . . . . . . . . . . 404.6. Respuesta del módulo de comunicación - transmisión. . . . . . . . . 404.7. Respuesta del módulo de comunicación transmisión thingpark. . . 414.8. Planilla correspondiente al caso de prueba “CP01”. . . . . . . . . . 424.9. Planilla correspondiente al caso de prueba “CP02”. . . . . . . . . . 434.10. Planilla correspondiente al caso de prueba “CP03”. . . . . . . . . . 444.11. Banco de ensayos para pruebas de consumo. . . . . . . . . . . . . . 444.12. Forma de onda de corriente. . . . . . . . . . . . . . . . . . . . . . . . 464.13. Ubicación de puntos de prueba para registro de calidad de señal. . 47

XI

Índice de Tablas

1.1. Variables atmosféricas comunes . . . . . . . . . . . . . . . . . . . . . 11.2. Clasificación de estaciones . . . . . . . . . . . . . . . . . . . . . . . . 21.3. Comparación entre EMA . . . . . . . . . . . . . . . . . . . . . . . . . 4

3.1. Características de XDOT . . . . . . . . . . . . . . . . . . . . . . . . . 143.2. BME280 características . . . . . . . . . . . . . . . . . . . . . . . . . . 163.3. Consumo de energía por sensor . . . . . . . . . . . . . . . . . . . . . 183.4. Consumo de energía módulo LoRa . . . . . . . . . . . . . . . . . . . 193.5. Consumo de energía placa nodo . . . . . . . . . . . . . . . . . . . . 193.6. Consumo de energía total . . . . . . . . . . . . . . . . . . . . . . . . 193.7. Símbolos para dirección del viento . . . . . . . . . . . . . . . . . . . 29

4.1. Matriz de trazabilidad . . . . . . . . . . . . . . . . . . . . . . . . . . 454.2. Consumo final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3. Pruebas de alcance . . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.4. Detalle de costos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

XIII

Dedicado a Martha Flores

1

Capítulo 1

Introducción General

En este capítulo se abordan los conceptos básicos, características y relevancia delas estaciones meteorológicas y tecnología LoRa. Además, se presenta la motiva-ción, los objetivos y el alcance que establecen los lineamientos del desarrollo.

1.1. Descripción técnica y sustentación teórica

1.1.1. Estaciones meteorológicas

Una estación meteorológica se define como una instalación destinada a la medi-ción y registro de variables atmosféricas y ambientales[1].

Los datos obtenidos por las estaciones meteorológicas son posteriormente anali-zados y su estudio permite la caracterización espacial y temporal de los fenóme-nos atmosféricos, así como la realización de diagnósticos y proyecciones.

La base de las observaciones radica en las variables atmosféricas a ser registradasy los instrumentos utilizados para tal registro. La tabla 1.1 muestra las principalesvariables adquiridas por estaciones meteorológicas, el instrumento utilizado y launidad de medida relacionada.

Una estación meteorológica puede disponer de varios de los instrumentos citadosu otros adicionales que definen su aplicación, tamaño y costo.

TABLA 1.1: Variables atmosféricas comúnmente registradas.

Variable meteorológica Instrumento de medida Unidad de medida

Temperatura Termómetro CPresión atmosférica Barómetro hPaPrecipitación Pluviómetro l/m2

Humedad relativa Higrómetro %Evaporación Evaporímetro mmVelocidad del viento Anemómetro m/s− km/hDirección del viento Veleta

Horas de sol Heliógrafo hRadiación Radiómetro W/m2

Las variables requeridas dependen del propósito para el que serán utilizadas;por ejemplo, pronóstico del tiempo, caracterización y zonificación agroclimática,monitoreo y predicción de la producción, determinación de alertas tempranas,

2 Capítulo 1. Introducción General

entre otras. La tabla 1.2 muestra la clasificación de las estaciones meteorológicassegún varios criterios[2].

TABLA 1.2: Clasificación de las estaciones meteorológicas.

Criterio Clasificación

Finalidad

ClimatológicasAgrícolasEspeciales

Aeronáuticas

Número de variablesPrincipales (desde diez variables)Ordinarias (desde dos variables)

Lugar de observaciónTerrestre

AéreaMarítima

Por otra parte, se define estación meteorológica automática (EMA) a la estaciónque realiza automáticamente la medición y transmisión o registro de las variablesmeteorológicas.

Los datos registrados por una EMA se transmiten a un receptor por diferentesmedios, como telefonía celular, transmisión satelital o radiofrecuencia. Posterior-mente los datos son enviados a servidores y plataformas digitales mediante co-nexiones como Ethernet, donde son tratados y analizados para finalmente sermostrados en diversas aplicaciones finales a los clientes. La figura 1.1 muestra elesquema básico de conexión de una EMA.

FIGURA 1.1: Ilustración de la conexión típica de una EMA.

1.1.2. LoRa y LoRaWAN

El nombre LoRa proviene de la expresión Long Range mediante la que se identificaa un tipo de modulación utilizada para transmitir datos por radiofrecuencia. Estatecnología fue patentada por la empresa SEMTECH [3].

Algunas de las características más importantes de esta tecnología son [4]:

1.2. Estaciones meteorológicas de referencia 3

Bajo consumo.

Largo alcance.

Baja transferencia de datos (hasta 255 bytes).

Comunicación bidireccional.

Alta tolerancia a las interferencias.

Las características mencionadas hacen que esta tecnología sea apropiada paraconexiones a grandes distancias, redes de internet de las cosas (IoT), redes desensores y actuadores, entre otras.

LoRaWAN es un protocolo de red que usa la modulación LoRa para adminis-trar y comunicar dispositivos que trabajen con esta tecnología [4]. Se destacan lassiguientes características del protocolo:

Trabaja con topología en estrella.

Soporta tres clases de nodos (A, B, C).

Usa encriptación AES 128 [5].

Posibilita trabajar con redes públicas y privadas.

La figura 1.2 muestra la representación de la estructura de red LoRaWAN.

FIGURA 1.2: Estructura de la red LoRaWAN1.

1.2. Estaciones meteorológicas de referencia

Existen diversos modelos comerciales y desarrollos académicos de estaciones me-teorológicas. A continuación se presentan varios modelos referenciales.

1Imagen tomada de https://lora-alliance.org

https://lora-alliance.org


AcuRite.

Diseñado para interiores, muestra las condiciones ambientales de hasta cua-tro áreas y utiliza hasta tres sensores. Monitorea las condiciones de tempe-ratura y humedad de forma remota, ofrece posibilidades de control desdela aplicación o el sitio web My AcuRite [6].

NetAtmo.

Permite medir temperatura, humedad, presión y ruido. Ofrece posibilida-des de control desde la aplicación móvil o mediante los servicios de ALEXAde AMAZON [7].

Make.

Permite capturar datos de presión, temperatura, lluvia y humedad del sueloy aire. Es un diseño basado en el uso de herramientas libres. No brindaningún servicio web o aplicación móvil [8].

Sparkfun.

Permite capturar datos de temperatura, humedad, nivel de luz, lluvia y ve-locidad del viento. Es un diseño basado en el uso de herramientas libres.Actualmente no brinda ningún servicio web o aplicación móvil [9].

La tabla 1.3 muestra un resumen de las prestaciones de los modelos citados.

TABLA 1.3: Comparación de prestaciones entre diversas EMA.

NombreTipo de Bajo Integración Sistema Integración

comunicación consumo de sensores escalable de servicios

AcuRite Wi-Fi/Ethernet No No No SíNetAtmo Wi-Fi/Ethernet Sí No No SíMake N/A No Sí Sí NoSparkfun Wi-Fi/Ethernet No Sí Sí No

1.3. Motivación

Dada la complejidad de las formas productivas agrícolas y su vulnerabilidadfrente a fenómenos climatológicos, y siendo la agricultura un eje de desarrolloregional, la empresa XnCompany determina la necesidad de ofrecer productos yservicios que proporcionen información climatológica.

Además, considerando que las características de las estaciones meteorológicas co-mo las presentadas en la sección 1.2 no solucionan necesidades como integraciónde sensores de terceros, funcionalidades escalables, integración de servicios, ba-jos costos, bajo consumo y nuevas tecnologías de comunicación para zonas rura-les, la empresa decide desarrollar un prototipo que pueda cubrir las necesidadesmencionadas patrocinando el desarrollo de este trabajo.

Por otro lado, existe el interés personal de desarrollar productos que puedan sercomercializados a futuro, utilizando para tal propósito los conocimientos recibi-dos durante la carrera.

1.4. Objetivos y alcance 5

1.4. Objetivos y alcance

1.4.1. Objetivo general

Diseñar e implementar un prototipo de estación meteorológica automática basa-da en un sistema microprocesado y comunicación en radio frecuencia mediantela tecnología LoRa.

1.4.2. Objetivos específicos

Para cumplir con el objetivo general, el trabajo se divide en los siguientes objeti-vos específicos:

Realizar un diseño basado en el bajo consumo.

Diseñar un sistema modular y escalable.

Priorizar el uso de herramientas abiertas y de libre acceso para el desarrollo.

La figura 1.3 muestra el diagrama de bloques del sistema implementado en el quese muestran las principales partes constitutivas y la disposición de la red generalsobre la que funciona el dispositivo diseñado.

El sistema cuenta con un microprocesador central encargado del control del sis-tema y un módulo LoRa transceiver destinado a la transmisión de datos. Además,un bloque de interfaces de comunicación que concentra los distintos canales parala conexión de los diferentes sensores utilizados.

El módulo de alimentación está encargado de proporcionar la energía necesariapara el funcionamiento del sistema; forman parte de este módulo el circuito derecarga de baterías, regulación de voltaje y panel solar. Por otro lado, el bloque deindicadores de estado corresponde a diodos LED que informan diferentes estadosdel sistema.

La estación meteorológica tiene la capacidad de comunicarse con un gateway so-bre la red para el envío y recepción de datos. Los datos transmitidos son final-mente mostrados en una aplicación final de usuario.

FIGURA 1.3: Diagrama de bloques del sistema implementado.

1.4.3. Alcance

El desarrollo de este trabajo incluye el diseño de hardware y software de un nodode transmisión de radio frecuencia con tecnología LoRa. La transmisión de datos


se realiza mediante el protocolo LoRaWAN con períodos de envío programablesremotamente.

El nodo permite realizar la lectura y transmisión de las siguientes variables at-mosféricas: temperatura, humedad relativa, presión, precipitación, velocidad ydirección del viento. Además, el sistema es capaz de enviar el porcentaje de cargade la batería como parte de su telemetría interna.

El sistema incorpora electrónica y diseño que prioriza el bajo consumo, de formatal que permite sostener la alimentación por medio de baterías en el largo plazo.

El proyecto no incluye la configuración o diseño de la red de gateways, configura-ción o vinculación de red de nodos, y tampoco contempla la recolección y análisisde los datos en la nube.

7

Capítulo 2

Introducción Específica

En este capítulo se presenta y describe la estructura principal del sistema, los ele-mentos que lo constituyen, las características de funcionamiento y los principaleslineamientos de diseño.

2.1. Requerimientos

A continuación se listan los requerimientos en base a los cuales se desarrolló elprototipo. Estos surgieron del análisis de las necesidades del cliente.

1. Requerimientos funcionales.

1.1. El sistema deberá ser capaz de realizar la lectura de diversos sensoresde variables ambientales.

1.2. El sistema deberá implementar el protocolo de radio frecuencia LoRa.

1.3. El sistema deberá transmitir los valores captados mediante la imple-mentación del protocolo de red LoRaWAN.

1.4. El sistema implementará un diseño modular.

1.5. El sistema deberá enviar la telemetría interna de este.

1.6. El sistema incorporará diseño y elementos que aseguren bajo consumode energía.

1.7. El sistema permitirá sostener la alimentación mediante baterías en ellargo plazo.

1.8. Se dispondrá de un sistema de recarga de baterías.

1.9. El sistema se enfocará en un diseño para sistemas desatendidos.

1.10. Se podrá identificar situaciones especiales, como errores de comunica-ción, asociación, batería baja, entre otros, mediante el uso de indicado-res de estado visuales.

2. Requerimientos no funcionales.

2.1. El sistema contará con una placa que contenga los diferentes elementosconstitutivos del nodo.

2.2. El sistema proveerá las interfaces de comunicación y alimentación re-queridas.

8 Capítulo 2. Introducción Específica

2.3. El sistema contará con una placa de desarrollo embebida comercial pa-ra implementar el protocolo de comunicación.

2.4. El sistema utilizará sensores disponibles comercialmente para la ad-quisición de las variables ambientales.

2.5. El sistema priorizará el uso de herramientas libres.

2.6. Se confeccionará documentación de respaldo del diseño completo.

2.7. Se evaluarán los resultados del proyecto dentro de un ambiente simu-lado.

2.8. Se realizarán pruebas de alcance de transmisión.

2.9. Se realizarán pruebas de consumo.

2.2. Visión general de los elementos constitutivos

Con el objetivo de cubrir los requerimientos planteados se diseñó un sistema conlos siguientes módulos constitutivos:

Panel solar: corresponde a un panel solar monocristalino de silicio que estáencargado de suministrar energía al bloque de almacenamiento de energía.

Controlador de carga de baterías: debido a que el flujo de energía prove-niente del panel solar es variable, este bloque está destinado a obtener lamayor eficiencia del panel. Según la aplicación, la complejidad de este blo-que aumenta al igual que la importancia de su implementación.

Circuito de protección de baterías: este bloque está encargado de controlarel voltaje de carga y de descarga para resguardar el sistema de baterías yaumentar su vida útil.

Batería li-ion: corresponde a una batería de ion de litio, de gran capacidadenergética y resistencia a la descarga, brinda un alto rendimiento en el al-macenamiento de energía.

Conversor DC/DC: este bloque está encargado de establecer la tensión no-minal de trabajo del circuito de control, comunicación y sensores.

MCU: elemento microprocesado encargado del control general del sistema.

Módulo LoRa: elemento encargado de la comunicación mediante radio fre-cuencia implementando la tecnología LoRa.

Sensores: instrumentos necesarios para la recolección de las variables me-teorológicas.

La figura 2.1 muestra el diagrama de bloques detallado del sistema, donde sediferencian el flujo y distribución de energía e información.

2.3. Descripción funcional y estructural

Con el fin de lograr un diseño adaptable, se construyó un sistema modular cen-tralizado con un módulo principal de control y diferentes módulos secundarios

2.3. Descripción funcional y estructural 9

FIGURA 2.1: Diagrama de bloques detallado del sistema.

con funciones específicas. En este caso concreto se implementaron los siguientesmódulos.

Control: módulo encargado de aplicar la logística principal entre los módu-los secundarios y el entorno general.

Estado: módulo encargado de gestión de la telemetría interna del nodo.

Adquisición: módulo encargado de la recolección, tratamiento y almacena-miento temporal de los datos obtenidos desde los diferentes sensores de lasvariables meteorológicas.

Comunicación: módulo encargado de la transmisión y recepción de datosmediante el protocolo de radio frecuencia seleccionado.

La figura 2.2 muestra el diagrama modular implementado.

FIGURA 2.2: Esquema modular del sistema.

Al inicio del proceso el módulo de control envía una señal al módulo de sensorespara comenzar la adquisición. Los datos adquiridos y procesados son almacena-dos temporalmente hasta ser requeridos para la transmisión.

10 Capítulo 2. Introducción Específica

Luego, el sistema envía una señal al módulo de estado para adquirir señales rela-cionadas al estado del nodo. Estos datos también son almacenados para su pos-terior uso.

Tras obtener los datos necesarios y previamente almacenados por los procesosanteriores, se envía la señal de inicio de transmisión al módulo de comunicaciónencargado del manejo del transmisor.

Luego de completar el envío de datos, se abre la ventana de recepción en cuyatrama se encuentra, de ser el caso, el nuevo tiempo de inicio del próximo ciclo.

Finalmente, el nodo entra en modo de bajo consumo esperando a ser reiniciadouna vez que termina el tiempo establecido.

La figura 2.3 muestra la secuencia funcional del sistema.

FIGURA 2.3: Diagrama de secuencia de funcionamiento.

2.4. Análisis de viabilidad

El análisis de viabilidad del proyecto se basa en cinco puntos tomados del modelode negocio Canvas, los cuales se describen a continuación.

1. Actividades principales.

A continuación se citan las acciones más importantes del trabajo las que secentran en ofrecer soluciones nuevas a problemas puntuales.

Diseño y construcción de hardware y software adaptable para ofrecerversatilidad y variedad a posibles clientes.

Soporte y respaldo técnico ofrecido a los clientes gracias al patrociniode XnCompany.

Innovación tecnológica gracias a la implementación de nuevas tecno-logías de IoT en el campo de la meteorología.

2.4. Análisis de viabilidad 11

2. Recursos clave.

A continuación se presentan los activos y capacidades más relevantes quesumarán probabilidad de éxito.

Red IoT de gran cobertura ya que el proyecto será incorporado sobreuna estructura probada y de gran escala que se encuentra en funciona-miento.

Talento humano de primer nivel que formó parte del desarrollo y for-mará parte del respaldo posterior.

3. Red de socios.

A continuación se presentan las alianzas identificadas que permitirán, me-diante su participación, reducir riesgos y adquirir recursos y capacidades.

XnCompany, empresa de gran experiencia y trayectoria en el campotecnológico.

Gobiernos municipales, provinciales y nacionales interesados en la im-plementación de soluciones técnicas para el fortalecimiento en la in-dustria agropecuaria.

LoRa Alliance, red de diversas empresas de gran importancia que desa-rrollan productos y servicios relacionados con la tecnología LoRa.

FIUBA, que gracias a iniciativas como la vinculación de estudiantesy empresas brinda la posibilidad de generar y aplicar conocimientos,experiencia y seguimiento en el desarrollo de nuevos productos.

4. Propuestas de valor.

A continuación se listan las propuestas de valor destacadas en el proyecto.

Sistema de bajo consumo de energía.

Gran alcance de conectividad inalámbrica.

Bajo costo.

Sistema adaptable.

Seguridad en el manejo de datos.

5. Segmentos de clientes.

La seguridad de los productos agrícolas es importante desde una etapa ini-cial. La protección contra los ataques de plagas, así como el impacto de fe-nómenos ambientales es fundamental para orientar los procesos de produc-ción.

Por tanto, los potenciales clientes a quienes va dirigido el producto son losrelacionados al sector agropecuario, que es uno de los ejes de la economíade la región.

Del análisis de los puntos anteriores se concluye que, al existir un mercado de-mandante y creciente al cual se busca ofrecer un producto de calidad y de bajocosto que permita cubrir una necesidad específica, las probabilidades de éxitocomercial son altas.

13

Capítulo 3

Diseño e Implementación

En este capítulo se presenta la arquitectura del firmware, la estructura modulardiseñada, la descripción de cada módulo implementado y el fundamento de se-lección de los componentes de hardware utilizados.

3.1. Desarrollo del hardware

El principal criterio de selección de componentes es el bajo consumo de energía,lo que permitió desarrollar un sistema desatendido con autonomía energética;asimismo, se prioriza el bajo costo de los elementos.

Por otro lado, en base a la clasificación de las estaciones meteorológicas visto en elcapítulo 1, los objetivos planteados y los diseños de las estaciones referenciales, sediseñó una estación meteorológica automática ordinaria-climatológica-terrestreque permite registrar la temperatura ambiente, humedad, presión atmosférica,dirección del viento, velocidad del viento y precipitación.

3.1.1. Procesamiento y comunicación

Para el desarrollo del prototipo se utilizó el módulo XDOT [10] desarrollado porla empresa MULTITECH [11].

La principal motivación para el uso de este módulo es la existencia de traba-jos precedentes que el cliente ha desarrollado con excelentes resultados, lo quele permite contar con una base operacional y de respaldo técnico. Sin embargo,parte de este trabajo consiste en concluir si sus prestaciones cumplen con los re-querimientos planteados o es necesario un cambio de plataforma.

XDOT es un dispositivo compacto de bajo consumo de energía y de montajesuperficial que integra un transmisor LoRa y un procesador ARM Cortex-M3STM32L151CCU6 [12] compatible con software diseñado especialmente para IoT.La tabla 3.1 muestra las principales características del módulo.

Otra de las ventajas del módulo seleccionado es que permite trabajar medianteun kit de desarrollo XDOT-DK [13], diseñado para ser utilizado como dispositivoPlug and Play que se puede configurar, programar y conectar de manera fácil ydirecta haciendo mínimas las limitaciones de hardware, y de esta forma agilizarel desarrollo de la estación.

La primera parte de la realización del trabajo se desarrolló con la versión XDOT-DK para comprobar la factibilidad técnica. La figura 3.1 muestra las versiones delmódulo utilizado.

14 Capítulo 3. Diseño e Implementación

TABLA 3.1: Principales características del módulo XDOT.

Categoría Descripción

Compatibilidad de red LoRaWAN

Interfaces

19 I/O digitales10 entradas analógicas

2 salidas DACI2CSPI

UARTPWMJTAG

CPU 32 MHzFlash 256 kBEEPROM 8 kBSRAM 32 kBConector RF UFLVoltaje de operación 2,4 V a 3,57 VFlash 256 kB

Corriente<15 mA en modo activo

<2 uA en modo sleepBandas ISM 902 MHz a 928 MHzPotencia max Tx 19 dBmSensibilidad max Rx -130 dBm

3.1.2. Sensores

1. Kit estación meteorológica SEN-15901 [14].

El kit comercial producto de la empresa SPARKFUN [15] es una alternativamuy utilizada en proyectos académicos y de desarrollo. Está compuesto porsensores para medir la velocidad y dirección del viento, así como un plu-viómetro de cubo basculante. Los sensores no contienen electrónica activa yse encuentran protegidos para uso en la intemperie, lo que los hace idóneospara uso en exteriores. La descripción de los sensores provistos por el kitmeteorológico se describen a continuación.

Anemómetro: es un instrumento rotativo de cubetas hemisféricas usa-do para medir la velocidad horizontal del viento. La tasa de rotaciónde las cubetas es lineal respecto al rango de medidas. El sensor codi-fica la velocidad a través del cierre de un contacto que se acciona conla rotación de las cubetas y permite que a una velocidad de 2,4 km/hel contacto se cierre cada segundo. Utiliza un conector RJ11 para sufuncionamiento [14].

Para realizar la lectura del sensor el sistema implementa una interrup-ción asociada a un pin genérico, posteriormente se cuenta el númerode accionamientos del contacto y se calcula la velocidad. La figura 3.2muestra el anemómetro utilizado.

Veleta: es un instrumento que permite medir la dirección del viento.

3.1. Desarrollo del hardware 15

FIGURA 3.1: Versiones utilizadas del módulo XDOT.

FIGURA 3.2: Anemómetro de paletas.

El sensor registra la dirección del viento en grados en sentido horarioa partir de un punto fijo denominado norte verdadero. Para el registroutiliza una combinación de resistencias internas. El movimiento de laveleta cierra dos contactos simultáneamente permitiendo dieciséis di-ferentes valores de resistencia correspondientes a dieciséis ángulos dedirección [14].

Para realizar la lectura del sensor es necesario utilizar una resistenciaexterna para formar un divisor de voltaje, posteriormente este valorserá registrado mediante un conversor analógico digital (ADC) del sis-tema.

La figura 3.3 muestra el sensor utilizado, su configuración de resisten-cias internas y la relación correspondiente al ángulo de ubicación de laveleta y la dirección del viento.

Pluviómetro: es un instrumento utilizado para medir la precipitacióncaída en un lugar y un tiempo determinado.

El sensor permite que por cada 0,2794 mm de lluvia un contacto se cie-rre temporalmente. Utiliza un conector RJ11 para su funcionamiento[14].

Para realizar la lectura del sensor el sistema implementa una interrup-ción asociada a un pin genérico, posteriormente se cuenta el númerode accionamientos del contacto y se calcula la precipitación. La figura3.4 muestra el instrumento utilizado.

Finalmente el kit meteorológico ofrece una estructura funcional paraensamblaje de los diferentes sensores, brindando una ventaja en laconstrucción del prototipo. La figura 3.5 muestra la disposición finalde los diferentes sensores del kit sobre la estructura de montaje.


FIGURA 3.3: Veleta (Relación dirección-ángulo).

FIGURA 3.4: Pluviómetro.

2. Sensor de humedad, presión y temperatura (BME 280).

Para el registro de las variables mencionadas existen distintas opciones co-merciales que ofrecen diferentes rangos de medida, interfaces y precios. Sinembargo, el sensor seleccionado agrupa excelentes prestaciones técnicas encuanto a consumo, precisión y rango; también es muy económico y permitemediante un solo sensor la adquisición de las tres variables simultáneamen-te. La tabla 3.2 muestra las principales características del sensor [16].

TABLA 3.2: Características del sensor BME 280.

Categoría Descripción

Interfaz digital I2C, SPIVoltaje de alimentación 1,71 V a 3,6 V

Consumo de corriente3,6 uA (adquiriendo)

0,1 uA (sleep)Tiempo de respuesta 1 s

Para una mayor facilidad de construcción del prototipo, se utilizó el módulocomercial que contiene el sensor mencionado y la circuitería necesaria parasu funcionamiento. La figura 3.6 muestra el módulo utilizado.


FIGURA 3.5: Disposición de los sensores sobre la estructura.

FIGURA 3.6: Módulo comercial BME 280.

3.1.3. Gestión y control de energía

A continuación se presentan los criterios de selección de los elementos que brin-dan a la estación autonomía y estabilidad de energía.

1. Batería: el módulo de batería tiene la función de ser la principal fuente deenergía del sistema. Los parámetros más importantes a considerarse son: elcosto, la capacidad de almacenamiento, el tiempo de vida útil, la resistenciaa la descarga y el tamaño.

Los tipos de batería más comunes para aplicaciones similares son las basa-das en litio, especialmente las de iones de litio (li-ion), que tienen gran capa-cidad de almacenamiento, alto rendimiento, elevada densidad de energía ybaja tasa de autodescarga [17].

Como desventajas se tiene que disminuyen su eficiencia en temperaturasbajo cero, necesitan circuitos para controlar los procesos de carga y descar-ga ya que pueden ser susceptibles a explosiones y son más costosas quebaterías con otras tecnologías.

Con el objetivo de que el sistema opere continuamente se decidió incluirla conexión de un panel solar. En consecuencia, es esencial que el consumode energía no exceda la generación de energía obtenida del panel solar enun período determinado ya que el módulo de batería actúa como un bufferentre el flujo de generación y el consumo de energía.

Por lo tanto, considerando un día como período de trabajo se tiene que [18]:

Pgen(t) − Pcon(t) =dEbat(dt))

dt(3.1)


∫ T

0Pgen(t) − Pcon(t)(dt)) = Ebat(T ) (3.2)∫ T

T−24Pgen(t) − Pcon(t)(dt)) = Ebat(T ) ≥ 0 (3.3)

Donde “Pgen” es la energía generada, “Pcon” es la energía consumida y“Ebat” es la energía almacenada por la batería. Considerando un períodode tiempo de 24 horas y trabajando con valores medios de los valores deenergía en lugar de valores instantáneos, la integral se reduce a [18]:

24 ∗ (Pgenmed− Pconmed) = Ebat(T ) ≥ 0 (3.4)

Donde “Pgenmed” y “Pconmed” corresponden a los valores medios de lasenergías de generación y consumo respectivamente.

Bajo estas condiciones, el tamaño de la batería debe ser capaz de almacenarel valor correspondiente a “24horas ∗ Pgenmed” vatios por hora (Wh) [18].

Así, para dimensionar la capacidad de la batería es necesario hacer unaaproximación del consumo del sistema considerando siempre la peor con-dición de diseño. La tabla 3.3 muestra el consumo de cada sensor en modoactivo y en modo inactivo; además, una media de consumo considerandoun período de transmisión del nodo de cinco minutos (peor condición dediseño) y la potencia correspondiente al ciclo de transmisión.

En el caso del sensor BME 280, los valores de consumo (activo/inactivo)respectivos se toman de la hoja de datos [16]; para el caso del anemómetroy el pluviómetro, si bien son sensores pasivos, se considera como parte desu consumo la potencia demandada por las resistencias de pull up utilizadaspara establecer los niveles alto y bajo que activan la interrupción relaciona-da a su funcionamiento.

Para la veleta, al ser un divisor de tensión de consumo variable se tomanlos valores máximo y mínimo posibles según las diferentes combinacionesresistivas.

TABLA 3.3: Detalle de consumo de energía por sensor.

SensorI activo I inactivo Media Potencia

(uA) (uA) (uA) (mW)

BME 280 3,6 0,1 33,5 0,110Anemómetro – – 330 1,1Veleta 308,7 25 166,87 0,55Pluviómetro – – 330 1,1

Total 2,86

La tabla 3.4 muestra los diferentes valores de consumo del módulo de ra-diofrecuencia en los diferentes estados de transmisión en base a la hoja dedatos respectiva [10].

Para establecer un consumo aproximado del módulo LoRa se consideraque, si bien la transmisión es el estado de mayor consumo, este corresponde


TABLA 3.4: Detalle de consumo de energía del módulo LoRa.

Estado Consumo (mA) Potencia (mW)

Envío 120 396Inactivo 11 36,63Sleep 0,0021 0,00693

a un proceso muy corto en comparación al proceso de adquisición y espe-ra de la estación en una relación 1/100 [18]. Por lo tanto, se establece lasiguiente aproximación:

PLoRa = 0,01 ∗ (Penvio) + 0,99 ∗ (Pinactivo) (3.5)

PLoRa = 0,01 ∗ (396) + 0,99 ∗ (36,63) (3.6)

PLoRa = 40,22 mW (3.7)

Para el caso del consumo de la placa final y elementos asociados a esta,se consideran tres cargas importantes relacionadas a: el diodo emisor deluz empleado para mostrar el estado de la placa, el diodo emisor de luzutilizado para indicar la energización del nodo y el circuito utilizado parael sensado del nivel de voltaje de la batería. La tabla 3.5 muestra los valoresde consumo de los subsistemas mencionados.

TABLA 3.5: Detalle de consumo de subsistemas generales.

Subsistema Consumo (mA) Potencia (mW)

LED estado 0,33 1,1LED encendido 0,012 0,0040Estado de batería 0,0021 0,54

Total 1,64

Finalmente, la tabla 3.6 muestra el resumen de las estimaciones de consumoplanteadas y el total de estas, y en base al resultado obtenido se realiza unaestimación de consumo en 24 horas:

TABLA 3.6: Detalle de consumo de energía total estimado

Subsistema Potencia (mW)

Sensores 2,86Módulo LoRa 40,22Placa (Nodo) 1,64Total (Ptotal) 44,72

Pest = 24 ∗ Ptotal (3.8)


Pest = 1,1 Wh/dia (3.9)

Donde “Pest” es el consumo de energía diario esperado de la estación.

Por otro lado, con el objetivo de maximizar la vida útil de la batería, seseleccionan un factor mínimo de descarga DoD (depth of discharge) menor al10 % y un factor de estado de carga SoC (state of charge) mayor al 90 % loscuales deben ser evitados [18].

Finalmente, el tamaño de la batería está dado por [18]:

Ebat =100 %

SoC −DoD∗ Pest (3.10)

Ebat =100 %

90 % − 10 %∗ 1,1 Wh/dia (3.11)

Ebat = 1,4 Wh/dia (3.12)

En base al resultado de la ecuación 3.12 y para cubrir la demanda de energía,se selecciona la batería mostrada en la figura 3.7, cuyas principales caracte-rísticas son:

Capacidad típica: 2600 mAh.

Voltaje nominal: 3,7 V.

Voltaje máximo: 4,2 V.

Voltaje mínimo: 2,75 V.

FIGURA 3.7: Celda li-ion 18650.

2. Panel solar: su principal función es brindar una fuente de alimentación deenergía renovable y alternativa. La captación, transformación, almacena-miento y posterior uso de la energía solar permiten mantener al sistemaoperando continuamente, lo que es ideal en los sistemas desatendidos. De-be considerarse que implementar este tipo de módulos encarece el diseñode la estación, por lo que su uso debe ser justificado.

Los paneles solares son construidos principalmente por dos tipos de celdasfotovoltaicas: las monocristalinas y las policristalinas. Estos tipos se definenpor la pureza del silicón con que se forman. El tipo seleccionado para eldiseño es el panel de celdas monocristalinas.

Por su proceso de fabricación, las células monocristalinas tienen mayor ni-vel de pureza. Esto desemboca en mayor eficiencia de los paneles con este


tipo de células; por tanto, a mayor eficiencia se reducen sus dimensiones.Como factor negativo se establece que son más costosos y su produccióntiene mayor impacto ecológico.

Para dimensionar el panel se considera como peor condición el día con me-nor incidencia de sol u horas de luz en el año; este dato es obtenido defuentes estadísticas meteorológicas según la región. Para el año 2020, el díacon menos incidencia de luz en la ciudad de Buenos Aires es el 20 de juniocon 9 horas y 50 minutos de luz natural [19].

Con esta consideración, el pico de potencia “Wp” entregado por el panelsolar está dado por [18]:

Wp =Pest

horas de sol(3.13)

Wp =1,1 Wh

9,5 h(3.14)

Wp = 0,11 W (3.15)

Donde “Pest” es el consumo de energía diario estimado de la estación y fuecalculado en la ecuación 3.9.

En base al resultado de la ecuación 3.15, se selecciona el panel comercialmostrado en la figura 3.8. Las principales características son sus reducidasmedidas y su bajo costo, así como las siguientes:

Potencia: 0,5 W.

Dimensiones: 70 mm x 50 mm x 3 mm.

Voltaje: 5 V.

Corriente: 100 mA.

Voltaje en circuito abierto: 8,2 V.

Voltaje de carga máximo: 6,4 V.

FIGURA 3.8: Panel solar.

3. Módulo controlador de carga y protección de baterías: con el objetivo de cu-brir los bloques de carga y protección de baterías necesarios para el diseño,se utiliza un dispositivo comercial que integra los módulos mencionados.Este ha sido utilizado en proyectos similares desarrollados por la empresay dio excelentes resultados.


El módulo comercial utilizado está diseñado especialmente para trabajarcon la batería seleccionada; permite su carga a través de un conector microUSB (Universal Serial Bus) y terminales para conectar el panel solar, posee elcircuito de protección para sobrevoltaje y descarga mínima.

La figura 3.9 muestra el módulo utilizado, cuyas principales característicasson:

Corriente de carga ajustable hasta 1 A.

Precisión de carga: 1,5 A.

Voltaje de entrada: 4,5 V - 5 V.

Implementación del circuito integrado DW01G para protección de lacelda.

Uso del circuito integrado TP4056 para control de carga de la celda.

FIGURA 3.9: Cargador regulador de batería li-ion 18650.

4. Conversor DC/DC: para la implementación del bloque conversor DC/DCse utiliza el elemento MCP1700 [20], que es un regulador de voltaje de bajoconsumo. La figura 3.10 muestra el elemento utilizado, cuyas principalescaracterísticas son:

Voltaje de salida: 3,3 V.

Corriente de salida: 250 mA.

Corriente de consumo: 1,6 uA.

FIGURA 3.10: Regulador de voltaje MCP1700.


3.1.4. Diseño del circuito impreso

Previo al diseño final del circuito impreso, se trabajó con dos versiones previasconstruidas en placas perforadas. La primera versión corresponde a todos los ele-mentos de sensado seleccionados y controlados mediante el XDOT-DK, alimen-tación y comunicación mediante puerto USB. La figura 3.11 muestra la primeraversión creada.

FIGURA 3.11: Placa de prueba versión 1.

La segunda versión que puede observarse en la figura 3.12, corresponde a todoslos elementos de hardware seleccionados; esta vez controlados con el móduloXDOT, alimentación mediante baterías, comunicación UART y conexión del pa-nel solar.

FIGURA 3.12: Placa de prueba versión 2.


Finalmente la figura 3.13 muestra el modelo 3D del diseño final. Por tratarse deun prototipo en desarrollo la empresa decide no producir el PCB y trabajar enadelante con la segunda versión construida.

FIGURA 3.13: Modelo 3D versión final.

3.2. Desarrollo del firmware

3.2.1. Sistema general

La implementación de sistemas de IoT demanda del firmware de los dispositivosembebidos herramientas para la conectividad, seguridad y administración de re-cursos, entre los más importantes. En respuesta a esta necesidad se han desarro-llado diferentes sistemas operativos que permiten, entre otras cosas, un desarro-llo acelerado, diversidad en el uso de hardware, soporte y escalabilidad. Para laimplementación del trabajo se utiliza el sistema operativo Mbed OS [21], cuyasprincipales características se describen a continuación.

Mbed OS es un sistema operativo libre, de código abierto especialmente diseñadopara IoT sobre dispositivos basados en microcontroladores ARM Cortex-M, queincluye herramientas de seguridad, conectividad, RTOS y diferentes controlado-res para sensores y periféricos.

Otra de sus ventajas fundamentales es la posibilidad de disponer de gran canti-dad de soporte en línea, que va desde manuales hasta todo un entorno de desa-rrollo integrado sobre la nube que ofrece bibliotecas precompiladas listas parausar. La figura 3.14 muestra la estructura de firmware ofrecida por Mbed OS.

El uso del sistema operativo se hace indispensable ya que ofrece una base detiempo precisa para los procesos de adquisición de datos, facilita la implementa-ción del contador de tiempo real necesario para establecer los tiempos de reportey brinda un alto grado de fiabilidad al proyecto.

1Imagen tomada de https://os.mbed.com/docs/mbed-os/v5.15/introduction/index.html

https://os.mbed.com/docs/mbed-os/v5.15/introduction/index.html

3.2. Desarrollo del firmware 25

FIGURA 3.14: Arquitectura de firmware sobre Mbed OS1.

Con el objetivo de crear un sistema modular, se implementa una estructura ba-sada en tareas (Threads); cada tarea cuenta con su espacio de memoria y priori-dad. Para establecer la comunicación entre las diferentes tareas se utilizan colas(Queues).

Cada tarea está asociada al desarrollo de un módulo específico y cuenta con bi-bliotecas y recursos propios.

A continuación se describen brevemente las tareas implementadas.

La tarea principal Main del módulo de control está encargada de la ges-tión de recursos compartidos y la inicialización del entorno y del proceso.Para esto, envía un mensaje “SIGNAL_INIT” al resto de las tareas para ha-bilitarlas y preparar sus procesos iniciales respectivos; luego de esto las ta-reas quedan bloqueadas en un nuevo estado esperando la llegada de unnuevo mensaje que las habilite nuevamente. Por ultimo envía el mensaje“SIGNAL_PROCESS” a la tarea de adquisición para que inicie el procesorespectivo.

La tarea Acquisition del módulo de adquisición realiza la lectura de todas lasvariables atmosféricas y almacena los datos respectivos; únicamente luegode terminado el proceso envía el mensaje “SIGNAL_PROCESS” a la tareade medición de parámetros internos de la estación.

La tarea Motestate del módulo de estado realiza la lectura del nivel de bateríadel nodo que, en primera instancia para ésta versión del prototipo, es laúnica medición respectiva al estado del nodo. Luego de almacenar el valorregistrado el módulo envía el mensaje “SIGNAL_PROCESS” a la tarea decomunicación.

La tarea Comunication del módulo de comunicación recoge los datos obte-nidos por las tareas anteriores, establece la comunicación con el gateway,transmite y recibe los datos, decodifica y ejecuta el mensaje, habilita el con-tador de tiempo para el próximo proceso y envía al nodo a modo sleep hastael nuevo ciclo de transmisión.


Finalmente, una vez cumplido el tiempo programado para el reporte “TIME_OUT”,se genera una interrupción que inicia un nuevo ciclo. La figura 3.15 muestra elflujo de trabajo del sistema diseñado, mientras que en la figura 3.16 se observa laarquitectura construida.

FIGURA 3.15: Diagrama de flujo del sistema implementado.

FIGURA 3.16: Arquitectura del firmware implementado.

3.2.2. Módulo de control

El módulo de control mediante la tarea principal se encarga de inicializar el siste-ma, generar las tareas secundarias con su prioridad y su tamaño, crear las colas,manejar las variables globales y las constantes, y enviar la señal de inicio para elproceso de adquisición.

Si bien este módulo no se diseñó como una máquina de estados, su funcionamien-to se basa en las transiciones y niveles con los cuales el sistema operativo manejalas tareas. La figura 3.17 muestra el diagrama básico y genérico de operación deeste módulo y todas las tareas implementadas para el sistema.

Finalmente, la figura 3.18 explicita, mediante un diagrama de clases, las principa-les variables y funciones implementadas.

2Imagen modificada de https://os.mbed.com/docs/mbed-os/v5.15/apis/rtos.html

https://os.mbed.com/docs/mbed-os/v5.15/apis/rtos.html


FIGURA 3.17: Diagrama de estados y transiciones general para lastareas implementadas2.

FIGURA 3.18: Diagrama de clases para el módulo de control.

3.2.3. Módulo de adquisición

A diferencia del módulo de control, este y los posteriores módulos se basan enuna máquina de estados básica y genérica mostrada en la figura 3.19. La descrip-ción de las funciones de los diferentes estados se realiza a continuación.

El estado “INIT” está destinado a la inicialización de los elementos necesariospara el proceso activo; en este caso, se inicializa las interrupciones asociadas alos pines que registran la actividad del pluviómetro y anemómetro, se configurael conversor analógico digital (ADC) que registrará la actividad de la veleta y seconfigura la comunicación con el sensor BME280 responsable de la adquisiciónde la temperatura, presión y humedad.

Por su parte, el estado “IDLE” está destinado a la realización del proceso comotal. Como primer paso se toman las medidas del sensor triple configurado previa-mente para trabajo en modo forced [16] para garantizar bajo consumo. El sensortrabaja con valores en tipo float, por lo tanto es necesaria una conversión a punto


FIGURA 3.19: Máquina de estados genérica implementada.

fijo y estandarización a bytes de cada variable medida para su posterior almace-namiento temporal.

Posteriormente, para medir la velocidad del viento se requiere establecer un pe-ríodo fijo (T) de registro de actividad del anemómetro. Los eventos registrados eneste período se consideran para el cálculo de la velocidad, que está dado por [15]:

V elocidad del viento =Numero de eventos

T∗ Constante de velocidad (3.16)

Donde la constante de velocidad es propia del sensor y su valor es 2,4 Km/h [15].

La ecuación 3.16 corresponde al cálculo de la velocidad instantánea del viento sise considera T = 3 s [22]. El valor obtenido es convertido, estandarizado y alma-cenado posteriormente.

Como siguiente paso se realiza el cálculo del nivel de lluvia, para esto se conta-bilizan los eventos registrados por el pluviómetro y dicho valor es multiplicadopor la constante de volumen según la siguiente ecuación [15]:

Nivel de lluvia = Numero de eventos ∗ Constante de volumen (3.17)

Donde la constante de volumen es propia del sensor y su valor es 0,2794 mm [15].

El valor obtenido es convertido, estandarizado y almacenado posteriormente.

Por otro lado, para medir la dirección del viento se registran los diferentes valoresde voltaje correspondientes a cada una de las dieciséis posibles combinaciones deresistencias internas del sensor. Los valores obtenidos son asociados a un símbo-lo que es enviado. La tabla 3.7 muestra la relación entre resistencia, dirección ysímbolo correspondiente a la dirección de viento.

La figura 3.20 muestra el stack formado con los datos adquiridos de los sensoresluego de ser convertidos; cada recuadro corresponde a 1 byte, lo que da un totalde 17 bytes de datos para la transmisión. Se incluyen además los datos correspon-dientes a la medida del nivel de batería y 2 bytes de reserva denominados Statepara uso futuro.

La figura 3.21 muestra el diagrama de flujo correspondiente al proceso realizadopor el módulo de adquisición.

Finalmente, la figura 3.22 muestra mediante un diagrama de clases las principalesvariables y funciones implementadas.


TABLA 3.7: Relación de resistencia y símbolo para la dirección deviento.

Dirección () Resistencia (kΩ) Símbolo Dirección

0 33 0 N22,5 6,57 1 NNE45 8,2 2 NE67,5 0,891 3 ENE90 1 4 E112,5 0,688 5 ESE135 2,2 6 SE157,5 1,41 7 SSE180 3,9 8 S202,5 3,14 9 SSW225 16 10 SW247,5 14,12 11 WSW270 120 12 W292,5 42,12 13 WNW315 64,9 14 NW337,5 21,88 15 NNW

FIGURA 3.20: Stack de datos formado para la transmisión.

3.2.4. Módulo de estado

Este módulo fue pensado para recoger diferentes datos correspondientes al esta-do del nodo. Para la presente versión del proyecto únicamente se recoge infor-mación sobre el nivel de voltaje de la batería; sin embargo, el diseño modularconstruido y basado en la máquina de estado genérica permitirán una fácil im-plementación de nuevos procesos.

Para comenzar el procedimiento, el módulo es inicializado en el estado “INIT”,lo que corresponde a la configuración del ADC.

Posteriormente, en el estado “IDLE” el módulo queda en espera de la señal deproceso válida; un vez recibida dicha señal, se realiza la adquisición. El valorobtenido es convertido, estandarizado y almacenado posteriormente. La figura3.23 muestra mediante un diagrama de clases las funciones implementadas.

3.2.5. Módulo de comunicación

Este módulo tiene la función de establecer la comunicación con el gateway, enviarlos valores de las medidas de los sensores y recibir datos que utiliza la estación


FIGURA 3.21: Diagrama de flujo implementado para el módulo deadquisición.

una vez validados. Para lograr la comunicación se utiliza el concepto de la pro-gramación OTA (Over The Air) que se refiere al método mediante el cual se realizala configuración y el cifrado de los dispositivos dentro de la red LoRa [23].


FIGURA 3.22: Diagrama de clase para el módulo de adquisición.

FIGURA 3.23: Diagrama de clase para el módulo de estado.

Para trabajar con el mecanismo OTA, el entorno de programación de Mbed brin-da la posibilidad de trabajar con la biblioteca “ota_example”, que simplifica eldesarrollo.

Por otro lado, la estación es diseñada y configurada como un dispositivo claseA que es una de las tres posibles configuraciones con las que se puede trabajaren LoRa. La clase A es utilizada ya que es la opción que demanda menor con-sumo. Esta clase permite que el nodo reciba datos únicamente durante un breveperíodo de tiempo después de la transmisión. Luego de ésta, se abre una ventanade recepción RX1 en la misma frecuencia; una segunda ventana de transmisiónRX2 adicional puede ser configurada [23]. La figura 3.24 muestra las ventanas derecepción para los dispositivos de clase A.

FIGURA 3.24: Ventanas de recepción para dispositivos de clase A.

Para iniciar la comunicación el módulo es inicializado en el estado “INIT”, lo quecorresponde a la configuración del canal de comunicación, asignación de creden-ciales para el enlace, configuración de eventos de comunicación, establecimientode tiempos mínimos y constantes.

Posteriormente, en el estado “IDLE” el módulo queda en espera de la señal válidade proceso; un vez recibida dicha señal se restablecen los parámetros de comuni-cación y los eventos asociados a esta.


La estación envía la solicitud para la conexión; mientras esta no se establezca, seactiva una señal luminosa mediante un LED; la estación está programada con unnúmero limitado de diez intentos y el tiempo entre cada intento es de 60 segun-dos. En caso de agotar los intentos para establecer la comunicación la estaciónentra en modo sleep durante el tiempo programado en su última comunicación.

Si se establece la conexión, se actualiza el buffer de datos cargados por los módulosde adquisición y estado y se los envía al gateway; inmediatamente luego de latransmisión se abre la ventana RX1 para la recepción.

La captura de información enviada a la estación, se realiza mediante la asociaciónde un evento que permite tomar la trama recibida para su análisis. En esta ver-sión del proyecto únicamente se puede enviar como parámetro de configuraciónel tiempo de transmisión de la estación, es decir, cada cuánto tiempo se quiere re-cibir la lectura de los sensores; con esto se puede configurar remotamente el ciclode trabajo de la estación.

Para implementar la recepción de datos se diseñó una trama que permite iden-tificar un encabezado, un comando, el tamaño de los datos a recibir y los datoscomo tal, esto permitirá el envío de nuevos comandos para nuevas configuracio-nes internas. La figura 3.25 muestra el modelo de trama implementada.

FIGURA 3.25: Trama implementada para la recepción de datos.

De donde:

0XFF es el encabezado (1 byte).

0X01 es el comando relacionado al cambio de tiempo de reporte (1 byte).

0X02 es el tamaño en bytes del dato relacionado al comando respectivo (1byte).

Data son los bytes de datos correspondientes.

Si se recibe una trama y comando correcto, se verifica que el tiempo enviado parala configuración sea válido (positivo y mayor a 5 minutos); de ser el caso, el valorse guarda en la memoria no volátil (NVM) del dispositivo y se configura con estea la interrupción del contador de tiempo real (RTC), que activa un nuevo ciclo detrabajo. Finalmente se envía a la estación a modo de bajo consumo.

La figura 3.26 muestra el diagrama de flujo del estado “IDLE” del módulo decomunicación, mientras que en la figura 3.27 se expone el diagrama de flujo de lasubrutina de recepción de datos.

Finalmente, la figura 3.28 indica mediante un diagrama de clases las principalesvariables y funciones utilizadas.


FIGURA 3.26: Diagrama de flujo implementado para el módulo decomunicación.


FIGURA 3.27: Diagrama de flujo implementado para la subrutinade recepción.


FIGURA 3.28: Diagrama de clases para el módulo de comunica-ción.

37

Capítulo 4

Ensayos y Resultados

En este capítulo se presentan las pruebas realizadas para comprobación del co-rrecto funcionamiento del hardware y firmware de los módulos implementadosy del sistema general.

4.1. Pruebas funcionales

Las pruebas funcionales consisten en evaluar las diferentes funciones de los mó-dulos de adquisición, estado y comunicación comandados desde el módulo decontrol. Se realizaron pruebas de caja negra sobre los módulos mencionados y seregistraron los resultados mediante la interfaz serial.

Las condiciones de realización de las pruebas son:

Los módulos se prueban por separado.

La estación tiene habilitada la comunicación serial.

Se utiliza la placa de prueba versión 1 (XDOT-DK).

Se utiliza el emulador Tera Term [24].

Las pruebas se realizan dentro de un ambiente controlado.

La vinculación de la estación y el gateway a la red mediante ThingPark estapreviamente configurada y probada.

Las configuraciones de realización de las pruebas son:

Comunicación serial configurada a 9600,8,N,1.

Alimentación mediante puerto USB.

Intervalo de transmisión 40 segundos.

El banco de pruebas utilizado comprende una computadora personal, la placade desarrollo versión 1 y los sensores correspondientes. La figura 4.1 muestra elesquema de conexión del banco de pruebas y la figura 4.2 su implementaciónreal.

A continuación se describen las pruebas realizadas sobre cada módulo:

Módulo de adquisición.

38 Capítulo 4. Ensayos y Resultados

FIGURA 4.1: Esquema de conexión para el banco de ensayos de laspruebas funcionales.

FIGURA 4.2: Banco de ensayos para las pruebas funcionales.

La prueba inicia cuando el módulo central envía a la cola del módulo deadquisición la señal de inicio del proceso; se realiza la medición de tempe-ratura, presión y humedad mediante la biblioteca del sensor BME280. Pos-teriormente, se inicia el registro de la velocidad de viento, nivel de lluvia ydirección del viento.

En la consola serial se verifica el valor de las variables atmosféricas en sis-tema decimal, representación de punto fijo con dos decimales (Dec) y suequivalente en sistema hexadecimal (Hex) mediante el que serán transmiti-dos.

La figura 4.3 muestra los resultados obtenidos donde se aprecian los si-guientes parámetros:

• Temperatura de 24,62 C (2462 Dec; 0X099E Hex).

• Presión de 1004,40 hPa (100440 Dec; 0X018858 Hex).

• Humedad de 50,21 % (5021 Dec; 0X139D Hex).

4.1. Pruebas funcionales 39

• Velocidad del viento 7,2 km/h (720 Dec; 0X02D0 Hex).

• Nivel de lluvia 3,07 mm (307 Dec; 0X0133 Hex).

• Dirección del viento = Oeste (símbolo 12; 0X0C Hex).

FIGURA 4.3: Salida de respuesta del módulo de adquisición

Módulo de estado.

La prueba inicia cuando el módulo de adquisición envía a la cola del mó-dulo de estado la señal de inicio del proceso; posteriormente se realiza lamedición del nivel de voltaje de la batería.

En la consola serial se verifica el valor de la variable medida en las tresrepresentaciones esperadas. La figura 4.4 muestra el resultado obtenido.

FIGURA 4.4: Salida de respuesta del módulo de estado.

Módulo de comunicación.

La prueba inicia cuando el módulo de estado envía a la cola del módulode comunicación la señal de inicio del proceso; posteriormente, se realiza laconfiguración de la estación y se visualiza la misma en pantalla. La figura4.5 muestra los parámetros configurados en la estación.

Luego de configurada la estación se inicia el proceso de conexión a la red yenvío de datos. La figura 4.6 muestra los siguientes estados del proceso:

• Solicitud de conexión a la red (join request).


FIGURA 4.5: Configuración del módulo de comunicación.

• Ventana de recepción habilitada (Rx Window 1).

• Estado de la conexión (Network joined).

• Estado de la transmisión (successfully sent data to gateway).

• Paquete recibido (Rx data).

• Análisis de la trama recibida (No data available); este mensaje se des-pliega ya que el paquete recibido no cumple con la trama establecidapor ser un mensaje de sincronización del gateway y no un mensaje deconfiguración del usuario.

• Tiempo programado para el siguiente reporte (40 segundos).

FIGURA 4.6: Respuesta del módulo de comunicación - transmi-sión.

4.2. Pruebas de sistema 41

Finalmente, se realizó el proceso de verificación de datos desde la web. Lafigura 4.7 muestra la trama recibida en la interfaz wireless logger de Thing-Park [25]. Los valores recibidos corresponden a los 17 bytes de datos enformato hexadecimal obtenidos en el proceso de adquisición y ordenadossegún la trama establecida en el capitulo 3.

FIGURA 4.7: Respuesta del módulo de comunicación transmisiónthingpark.

4.2. Pruebas de sistema

Las siguientes pruebas evalúan el funcionamiento entre los distintos módulos yel sistema de control general. Se utiliza el modelo de casos de uso para planteardiferentes posibles escenarios de funcionamiento y evaluar la respuesta de la es-tación. Los casos planteados se diseñaron en concordancia con los requerimientosfuncionales y para su registro se utilizó el formato de plantilla diseñada por Pa-tricio Bos [26].

El primer caso de prueba identificado como “CP01” evalúa las principales fun-ciones del nodo, la adquisición y transmisión de variables meteorológicas. En lafigura 4.8 se muestra la planilla correspondiente al caso de prueba “CP01”.

El segundo caso de prueba identificado como “CP02”, evalúa la recepción de da-tos por parte de la estación, los datos recibidos son utilizados para modificar eltiempo de transmisión. En la figura 4.9 se muestra la planilla correspondiente alcaso de prueba “CP02”.

El tercer caso de prueba “CP03”, evalúa un caso de falla para comprobar el fun-cionamiento del indicador LED. En la figura 4.10 se muestra la planilla corres-pondiente al caso de prueba “CP03”.

Finalmente la tabla 4.1 muestra la matriz de trazabilidad de los requerimientosfuncionales para corroborar el cumplimiento de los mismos.

4.3. Pruebas de consumo

Para determinar que la estación está diseñada para trabajar en bajo consumo, yconsiderando que la principal fuente de alimentación es el módulo de batería, laspruebas se basan en medir el consumo de la estación y el calculo de la vida útilde la batería.


Proyecto: Estación meteorológica LoRaWANID Caso de prueba: CP01 Test diseñado por: Christian YanezNombre del caso: Medición de variables atmosféricas Fecha de diseño: 22/02/2020Versión del firmware: 1.9 Test ejecutado por: Christian Yanez

Fecha de ejecución: 23/02/2020

Pre condiciones:

Módulo BME280 conectado configurado a la interfaz I2C del XDOT.Anemómetro conectado al GPIO1 mediante resistencia de pull-up.Pluviómetro conectado al GPIO3 mediante resistencia de pull-up.Paleta de viento conectada al AI0 mediante divisor de tensión.Divisor de tensión desde la batería conectado a AI1.Terminal serie conectada en configuración 8N1 9600 UART-USB.Alimentación mediante el módulo de batería.Gateway y nodo configurados y registrados en la red de prueba.Interfaz web para recepción habilitada.

Post condiciones:

ÉXITO: Valores de temperatura, presión, humedad, lluvia, velocidad del viento, dirección del viento y batería registrados en pantalla en formato HEX y en la interfaz web de Think-Park según la trama establecida.FALLA: Registro de las variables vacío, incompleto o fuera de formato.

Resumen del Test:

Después de energizar el sistema, se inicializan los módulos, se envía la señal para inicio de la adquisición, se registran los valores, se acondicionan y guardan temporalmente. Luego de la adquisición se transmiten los datos. Se muestran los resultados en pantalla y la interfaz web.

Step# Descripción Resultado esperado Resultado obtenido

1 Energizar el sistema Mensaje de inicio ok

2 Inicialización de módulos Mensaje de inicialización ok

3 Adquisición de variables Variables en formato DEC y HEX ok

4 Inicio comunicación LoRa

Despliegue de la configuración de la comunicación y estado de conexión joined

ok

5 Transmisión de datos Mensaje de transmisión exitosa ok

6 Entrar en modo sleep Mensaje de confirmación ok

FIGURA 4.8: Planilla correspondiente al caso de prueba “CP01”.

Para el proceso de medición se utilizó el esquema de conexión del banco de prue-ba y metodología desarrollado por Rodrigo Tirapegui [27] destacando que para lamedición y captura de la forma de onda se usó el multímetro digital KEYSIGHTmodelo 34461a [28].

Las condiciones de realización de las pruebas son:

Los módulos se prueban de forma integrada.

Se utiliza la placa de prueba versión 2 (XDOT).

Las pruebas se realizan dentro de un ambiente controlado.

Alimentación mediante el módulo de batería únicamente.

La vinculación de la estación y el gateway a la red mediante ThingPark estapreviamente configurada y probada.

Las configuraciones para realización de las pruebas son:

Intervalo entre intentos de transmisión = 1 minuto.

4.3. Pruebas de consumo 43

Proyecto: Estación meteorológica LoRaWANID Caso de prueba: CP02 Test diseñado por: Christian Yanez

Nombre del caso: Configuración remota del tiempo de reporte Fecha de diseño: 22/02/2020

Versión del firmware: 1.9 Test ejecutado por: Christian YanezFecha de ejecución: 23/02/2020

Pre condiciones:

Conexión y configuración de sensores según el CP01Alimentación mediante el módulo de batería.Terminal serie conectada en configuración 8N1 9600 UART-USB.Gateway y nodo configurados y registrados en la red de prueba.Interfaz web para la transmisión habilitada.

Post condiciones: ÉXITO: Configuración de tiempo de reporte periódico válida todo t > t minFALLA: Tiempo de reporte constante o menor a tmin

Resumen del Test:Luego del proceso de transmisión se recibe la trama desde la web, se procesa y determina un dato válido, se configura el tiempo de reporte según corresponda. Se muestran los resultados en pantalla.



Despliegue de la configuración de la comunicación y estado de conexión joined

ok

2 Transmisión de datos Mensaje de transmisión exitosa ok

3 Recepción de trama Trama ok

4 Configuración del tiempo de reporte (TIMEOUT) si es un tiempo válido

Mensaje de estado de la configuración ok

5 Entrar en modo sleep Mensaje de confirmación ok

6 Reinicio del ciclo de adquisición luego de cumplido el TIMEOUT

Mensaje de inicio de adquisición ok


Número de intentos de enlace a la red = 10.

Intervalo de transmisión = 5 minutos.

La figura 4.11 muestra la implementación del banco de pruebas.

Luego de armado el banco de pruebas, se procedió a registrar el consumo de laestación. La figura 4.12 muestra la forma de onda de la corriente obtenida corres-pondiente a tres ciclos de transmisión. Puede diferenciarse claramente tres nivelescorrespondientes al estado estacionario, el estado transitorio o de transmisión yel estado denominado deep sleep [10] al cual entra la estación previo el proceso detransmisión. La tabla 4.2 muestra los valores obtenidos para cada estado.

Considerando que el mayor pico de consumo del nodo se registra durante el pro-ceso de transmisión, que a su vez es un proceso muy corto en comparación con eltiempo que la estación está en modo de bajo consumo, se decidió utilizar el valorde corriente media en el cálculo de vida útil.

Finalmente, la estimación de la vida útil de la batería se calcula mediante el mo-delo matemático [27]:

V idaUtilEsperada[h] =CapacidadNominalBateria[mA/h]]

CorrienteMedia[mA](4.1)


Proyecto: Estación meteorológica LoRaWANID Caso de prueba: CP03 Test diseñado por: Christian YanezNombre del caso: Condición de error de comunicación Fecha de diseño: 22/02/2020Versión del firmware: 1.9 Test ejecutado por: Christian Yanez

Fecha de ejecución: 23/02/2020

Pre condiciones:

Conexión y configuración de sensores según el CP01.Alimentación mediante el módulo de cargador de batería.Terminal serie conectada en configuración 8N1 9600 UART-USB.Gateway inhabilitado.Interfaz web para la transmisión habilitada.

Post condiciones: ÉXITO: Indicador LED encendido (condición de falla de comunicación) FALLA: Indicador LED apagado o intermitente.

Resumen del Test: Luego del proceso de adquisición se inicia la comunicación la cual no se establece, el nodo entra en modo de falla mostrando el estado mediante el indicador LED.



Despliegue de la configuración de la comunicación y estado de conexión failed

ok

2 Señal de control LED LED ON ok3 Intento de reconexión 1 Mensaje de estado ok

4 Espera para nuevo intento de reconexión Mensaje de estado ok


FIGURA 4.11: Banco de ensayos para pruebas de consumo.

Donde:

CorrienteMedia =Itransmision ∗ ttransmision

treporte+

Iestacionaria ∗ (treporte− ttransmision)

treporte(4.2)

4.3. Pruebas de consumo 45

TABLA 4.1: Matriz de trazabilidad de requerimientos funcionales.

Requerimiento CP01 CP02 CP03

El sistema debe ser capaz de realizar lalectura de diversos sensores de variablesambientales.

X X

El sistema deberá implementar el proto-colo de radio frecuencia LoRa.

X X X

El sistema deberá transmitir los valo-res captados mediante la implementacióndel protocolo de red LoRaWAN.

X X X

El sistema implementará un diseño mo-dular.

X X X

El sistema deberá enviar la telemetría in-terna del mismo.

X X

El sistema incorporará diseño y elemen-tos que aseguren bajo consumo de ener-gía.

X X X

El sistema permitirá sostener la alimenta-ción mediante baterías en el largo plazo.

X X

Se dispondrá de un sistema de recarga debaterías.

X

El sistema se enfocará en un diseño parasistemas desatendidos.

X X X

Se podrá identificar situaciones especia-les como, errores de comunicación, aso-ciación, batería baja entre otros, medianteel uso de indicadores de estado visuales.

X

TABLA 4.2: Detalle de consumo por estado medido.

Estado Tiempo(s) Corriente (mA)

Estacionario 300 14Transmisión 10 130deep sleep 60 5

En base a los valores de la tabla 4.2:

CorrienteMedia[mA] =130mA ∗ 11s

360s+

14mA ∗ (360s− 11s)

360s= 17, 54mA (4.3)

Finalmente:

V idaUtilEsperada[h] =2600[mA/h]]

17, 54[mA]= 148, 23h (4.4)


FIGURA 4.12: Forma de onda de corriente.

4.4. Pruebas de alcance

Las pruebas de alcance se realizaron en la ciudad autónoma de Buenos Aires. Sibien el lugar elegido presenta inconvenientes en cuanto a interferencias físicasy electromagnéticas, los resultados obtenidos garantizarán un mejor desempeñoen espacios abiertos dado que este entorno representa la peor condición para elambiente de pruebas.

El procedimiento consistió en determinar la mayor distancia a la que se realizaexitosamente la transmisión, considerando al gateway de ubicación fija y a laestación de ubicación variable.

El parámetro a registrar es el indicador de fuerza de señal recibida (RSSI) cuyorango está entre 0 dBm (valor ideal) y -120 dBm (valor mínimo) en aplicacionesLoRa [29].

La tabla 4.3 muestra el valor registrado de RSSI y su valoración de calidad [29] encinco puntos de prueba.

TABLA 4.3: Mediciones de calidad de señal LoRa.

Ubicación RSSI (-dBm) Calidad Distancia (m)

1 48 Fuerte 1452 57 Media 3903 64 Media 8004 70 Débil 6505 81 Débil 470

La figura 4.13 muestra la ubicación del gateway y de los puntos de prueba. Elmejor resultado se obtuvo en el punto tres que corresponde a la mejor calidad deseñal y mayor distancia, dicha ubicación corresponde también al punto con mejorlinea de vista.

4.5. Detalle de costos 47

FIGURA 4.13: Ubicación de puntos de prueba para registro de ca-lidad de señal.

4.5. Detalle de costos

La tabla 4.4 muestra el detalle de precios de los diferentes elementos utilizadospara la construcción del prototipo.

Los elementos que forman la lista de precios son seleccionados en base al análisisde precios de las estaciones de referencia vistas en el capitulo 1 y fueron escogidospara poder establecer una comparación equitativa con el prototipo creado.

Por tanto, no se consideran los costos operativos de la red, los costos de diseño,los costos de fabricación, los costos de construcción del gabinete ni los costos deimportaciones e impuestos.

TABLA 4.4: Detalle de costos de implementación.

Detalle Cantidad Costo (USD)

MTXDOT 1 27KIT SEN-08942 1 80BME 280 1 8Panel solar 1 2,7Batería 1 12Cargador de batería 1 2Componentes electrónicos – 25

Total 156,7

49

Capítulo 5

Conclusiones

En este capítulo se presentan los aspectos más relevantes del trabajo realizado yse mencionan los pasos a seguir.

5.1. Objetivos alcanzados

En el trabajo realizado se logró diseñar e implementar exitosamente un prototipode estación meteorológica automática basada en un sistema embebido y comu-nicación mediante la tecnología LoRa. Se destacan a continuación los aportes deltrabajo.

Se diseñó un modelo que prioriza el bajo consumo y garantiza la autonomíaenergética.

Se implementó un sistema modular que permite agregar fácilmente nuevasfuncionalidades.

Se identificaron las variables atmosféricas más relevantes para monitoreoclimático.

Se demostró el cumplimiento efectivo de los requerimientos funcionalesmediante la matriz de trazabilidad.

Se validaron las prestaciones y efectividad del módulo de procesamiento ycomunicación (XDOT).

Se mostró el alto potencial comercial del prototipo.

Se presentó la importancia del registro de variables atmosféricas medianteestaciones meteorológicas.

Se realizaron pruebas de consumo y alcance para validación de resultados.

Se implementó comunicación bidireccional para configuración remota de laestación.

Por otro lado, considerando las estaciones mostradas como referencia en el ca-pítulo 1 y luego del proceso de investigación, se puede establecer un costo pro-medio entre 200 USD a 500 USD para la construcción de estaciones similares. Enconsecuencia, se logra construir un prototipo con mejores prestaciones y de me-nor costo. Sin embargo, las cargas tributarias correspondientes a importacionese impuestos elevan el costo calculado en el capítulo 4 en un 80 %, lo que puedeperjudicar la comercialización del producto final.

50 Capítulo 5. Conclusiones

Cabe destacar que para llevar acabo el trabajo fue imprescindible aplicar los cono-cimientos aprendidos durante la carrera, destacando las asignaturas de: sistemasoperativos, sistemas embebidos distribuidos, procesamiento de señales y gestiónde la tecnología.

5.2. Próximos pasos

En esta sección se indican las lineas de acción inmediatas para continuar con eldesarrollo del producto.

Realizar pruebas de calibración de los sensores mediante un equipo patrón.

Optimizar el consumo de la estación eliminando cargas innecesarias comoel LED indicador de encendido.

Diseñar un gabinete que considere la protección de los efectos de radiacióny protecciones para trabajo en la intemperie.

Construir un sistema de anclaje o sujeción robusto.

Diseñar una aplicación de usuario que muestre el procesamiento y análisisestadístico de las lecturas tomadas.

Fabricar un nuevo PCB optimizado y compatible con el nuevo gabinete.

Realizar pruebas de alcance en zonas rurales.

Incorporar más opciones de configuración remota para la estación.

Implementar la actualización remota de firmware mediante la técnica de-nominada full OTA [23].

51

Bibliografía

[1] Wikipedia. Estación meteorológica.https://es.wikipedia.org/wiki/Estación_meteorológica. Nov. de 2013.(Visitado 07-03-2020).

[2] Organización Meteorológica Mundial. «Guía de prácticas climatológicas».En: OMM (2018).

[3] Semtech. DNA of IoT. https://www.semtech.com/lora. Ene. de 2020.(Visitado 01-01-2020).

[4] Sabas. Haciendo IoT con LoRa. https://medium.com/beelan/haciendo-iot-con-lora-capítulo-1-qué-es-lora-y-lorawan-8c08d44208e8. Jul. de 2017.(Visitado 18-03-2020).

[5] Wikipedia. Advanced Encryption Standard.https://es.wikipedia.org/wiki/Advanced_Encryption_Standard. Dic. de2019. (Visitado 07-03-2020).

[6] Acurite. Environment System.https://www.acurite.com/environment-system-with-indoor-temperature-and-indoor-humidity-and-multi-sensor-display.html.Mar. de 2020. (Visitado 18-03-2020).

[7] Netatmo. Station Météo Intelligente.https://www.netatmo.com/fr-fr/weather/weatherstation. Mar. de 2020.(Visitado 18-03-2020).

[8] Adrie Sentosa. Arduino Weather Station (AWS).https://www.instructables.com/id/Arduino-Weather-Station-AWS/.Mar. de 2017. (Visitado 18-03-2020).

[9] Nathan Seidle. Weather Station Wirelessly Connected to Wunderground.https://learn.sparkfun.com/tutorials/weather-station-wirelessly-connected-to-wunderground. Oct. de 2013. (Visitado 18-03-2020).

[10] MULTITECH. Multitech xDot.https://www.multitech.com/brands/multiconnect-xdot. Mar. de 2020.(Visitado 23-03-2020).

[11] MULTITECH. Welcome to the Industrial Internet of Things.https://www.multitech.com/. Mar. de 2020. (Visitado 23-03-2020).

[12] ST. Ultra-low-power 32-bit MCU ARM.https://www.st.com/resource/en/datasheet/stm32l151cc.pdf. Mar. de2020. (Visitado 23-03-2020).

[13] MULTITECH. MultiTech xDot Developer Kit.https://www.multitech.com/brands/micro-xdot-devkit. Mar. de 2020.(Visitado 23-03-2020).

[14] SPARKFUN. Weather Meter Kit.https://www.sparkfun.com/products/15901. Jul. de 2017. (Visitado23-03-2020).

[15] SPARKFUN. Sparkfun start something. https://www.sparkfun.com/.Mar. de 2020. (Visitado 18-03-2020).

https://es.wikipedia.org/wiki/Estacin_meteorolgica

https://www.semtech.com/lora

https://medium.com/beelan/haciendo-iot-con-lora-captulo-1-qu-es-lora-y-lorawan-8c08d44208e8

https://medium.com/beelan/haciendo-iot-con-lora-captulo-1-qu-es-lora-y-lorawan-8c08d44208e8

https://es.wikipedia.org/wiki/Advanced_Encryption_Standard

https://www.acurite.com/environment-system-with-indoor-temperature-and-indoor-humidity-and-multi-sensor-display.html

https://www.acurite.com/environment-system-with-indoor-temperature-and-indoor-humidity-and-multi-sensor-display.html

https://www.netatmo.com/fr-fr/weather/weatherstation

https://www.instructables.com/id/Arduino-Weather-Station-AWS/

https://learn.sparkfun.com/tutorials/weather-station-wirelessly-connected-to-wunderground

https://learn.sparkfun.com/tutorials/weather-station-wirelessly-connected-to-wunderground

https://www.multitech.com/brands/multiconnect-xdot

https://www.multitech.com/

https://www.st.com/resource/en/datasheet/stm32l151cc.pdf

https://www.multitech.com/brands/micro-xdot-devkit

https://www.sparkfun.com/products/15901

https://www.sparkfun.com/

52 Bibliografía

[16] BME280 Combined humidity and pressure sensor. 0273141185. Rev. 1.6. BoschSensortec. 2018.

[17] Wikipedia. Batería de ion de litio.https://es.wikipedia.org/wiki/Bater%C3%ADa_de_ion_de_litio. Mar. de2020. (Visitado 24-03-2020).

[18] Tesselaar Brasser Offerhaus. Desing of an Autonomous Wireless WeatherStation. Delft University of Technology, 2017.

[19] Weather Spark. El clima promedio en Buenos Aires.https://es.weatherspark.com/y/28981/Clima-promedio-en-Buenos-Aires-Argentina-durante-todo-el-a%C3%B1o. Mar. de 2020. (Visitado24-03-2020).

[20] Microchip. Low Quiescent Current LDO.http://ww1.microchip.com/downloads/en/DeviceDoc/20001826D.pdf.Mar. de 2020. (Visitado 24-03-2020).

[21] arm MBED. Mbed OS Features.https://www.mbed.com/en/platform/mbed-os/. Mar. de 2017. (Visitado24-03-2020).

[22] Nuestroclima. Qué es el viento instantáneo y la ráfaga.http://blog.nuestroclima.com/que-es-el-viento-instantaneo-y-la-rafaga/.Mar. de 2020. (Visitado 24-03-2020).

[23] Davíd García Fernandez. Diseño e implementación de actualizaciones Over theAir (OTA) para redes de sensores inalámbricas. Universidad Complutense deMadrid, 2019.

[24] Wikipedia. Tera Term. https://en.wikipedia.org/wiki/Tera_Term. Feb. de2020. (Visitado 28-03-2020).

[25] ThingPark. About ThingPark.https://partners.thingpark.com/en/about-thingpark. Mar. de 2020.(Visitado 28-03-2020).

[26] Patricio Bos. Sistema de control para estación autónoma marítima de monitoreode ruido ambiente. http://laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-MSE-Patricio-Bos-2018.pdf. Dic. de 2018. (Visitado02-04-2020).

[27] Rodrigo A. Tirapegui. Plataforma abierta para dispositivos (wearables).http://laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-MSE-Rodrigo-Alejandro-Tirapegui-2019.pdf. Dic. de 2019. (Visitado02-04-2020).

[28] Keysight Technologies. 34461A Digital Multimeter.https://www.keysight.com/en/pdx-2891615-pn-34461A/digital-multimeter-6-digit-truevolt-dmm?cc=AR&lc=eng. Mar. de 2020. (Visitado26-03-2020).

[29] Laura Dopazo Gonzáles. «Test y despliegue de tecnología decomunicaciones LoRa para aplicaciones de Internet of Things». En:ETSII-UPM (2019).

https://es.wikipedia.org/wiki/Bater%C3%ADa_de_ion_de_litio

https://es.weatherspark.com/y/28981/Clima-promedio-en-Buenos-Aires-Argentina-durante-todo-el-a%C3%B1o

https://es.weatherspark.com/y/28981/Clima-promedio-en-Buenos-Aires-Argentina-durante-todo-el-a%C3%B1o

http://ww1.microchip.com/downloads/en/DeviceDoc/20001826D.pdf

https://www.mbed.com/en/platform/mbed-os/

http://blog.nuestroclima.com/que-es-el-viento-instantaneo-y-la-rafaga/

https://en.wikipedia.org/wiki/Tera_Term

https://partners.thingpark.com/en/about-thingpark

http://laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-MSE-Patricio-Bos-2018.pdf

http://laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-MSE-Patricio-Bos-2018.pdf

http://laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-MSE-Rodrigo-Alejandro-Tirapegui-2019.pdf

http://laboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo-Final-MSE-Rodrigo-Alejandro-Tirapegui-2019.pdf

https://www.keysight.com/en/pdx-2891615-pn-34461A/digital-multimeter-6-digit-truevolt-dmm?cc=AR&lc=eng

https://www.keysight.com/en/pdx-2891615-pn-34461A/digital-multimeter-6-digit-truevolt-dmm?cc=AR&lc=eng

Estación meteorológica LoRaWANlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo...La base de las...

Documents

Transcript of Estación meteorológica LoRaWANlaboratorios.fi.uba.ar/lse/tesis/LSE-FIUBA-Trabajo...La base de las...