Continuamos con las entradas anteriores: en la primera se explica como fabricar una placa compatible con Arduino para conectarse a las redes LoRaWAN y en la segunda como instalar las herramientas de desarrollo para programar la placa. En esta tercera entrada vamos a explicar como conectar la placa a una red LoRaWAN para hacer un dispositivo que nos mida la temperatura y la humedad, y poder visualizar las medidas en una página web.

Los dispositivos LoRa se comunican con los gateways que se encargan de subir los datos de los dispositivo a internet, el gateway los sube al servidor de red que le indiquemos y aquí tenemos dos opciones: mandarlos a un servidor privado o a un servidor de terceros. En estas entradas vamos a programar la placa LoRa para mandar los datos al servidor de red de Helium y al de The Things Network, comenzamos con Helium debido a que tiene muchos más gateways en España que de The Things Network.

Helium es un proyecto que ha tenido un crecimiento enorme en los últimos dos años, la idea de Helium es crear una red de gateways en la que cualquier persona puede instalar un gateway (llamado hotspot en Helium) en su casa y ganar dinero por cada dato que este gateway suba a internet. Cantidad de dinero que puede ser significativa si en un futuro vivimos rodeados de dispositivos LoRa haciendo uso masivo de la red.

El reto al que se enfrentó Helium fue cómo hacer que la gente instale gateways que ahora mismo no van a tener casi tráfico de datos porque todavía la tecnología LoRa no se está apenas usando. Tuvieron la brillante idea de crear una criptomoneda, el HNT,  y pagar con esa criptomoneda a los usuarios que instalen gateways. Los gateways de Helium se comunican unos con otros, y por ese intercambio de mensajes entre gateways sus propietarios reciben criptomoneda HNT como recompensa.

Esa idea de dar criptomoneda tuvo un gran éxito (antes del debacle de todas las criptomonedas a principios del 2022) y en un periodo de entre uno y dos años se han vendido e instalado casi un millón de gateways de Helium en el mundo. Si nos vamos al mapa de las gateways de Helium podemos ver si en nuestra zona tenemos gateways, estando cubiertas de gateways muchas ciudades.

En esta entrada del blog vamos a conectar un sensor de temperatura y humedad a nuestra placa LoRa, con la que mandaremos las lecturas del sensor a la red de Helium y podremos visualizar estas en una página web.

Sensor de temperatura-humedad.

Como sensor de temperatura-humedad vamos a usar un SHT21, se conecta en la placa por bus I2C como se puede ver en la siguiente imagen.

Para hacer la conexión conectamos el pin SCL del sensor con el pin D3 de la placa (SCL del microcontrolador) y el pin SDA del sensor con el pin D2 de la placa (SDA del microcontrolador). La tensión a la que puede alimentarse el sensor está comprendida entre 3.6V y 2.1V por lo que encaja perfectamente en el rango de alimentación que vamos a tener con 2 pilas AAA.

Cuando el sensor duerme nos dice en el datasheet que va a consumir 0.15 uA, por lo que no aumenta casi el consumo del dispositivo y lo podemos dejar así. Si quisiéramos que consumiese menos (0.15 uA es ya muy poco) podríamos proporcionarle alimentación a través de un MOSFET (en este caso también podríamos proporcionarle alimentación a través de un GPIO del microcontrolador). Encenderíamos el MOSFET desde la placa para proporcionar alimentación al sensor cuando lo vayamos a usar y apagaríamos el MOSFET quitándole la alimentación cuando no lo estemos usando. De esta forma reduciríamos el consumo de corriente de la electrónica conectada a la placa, pero en este caso estamos hablando de un consumo muy bajo por lo que no hay necesidad de añadir el MOSFET externo (que también tendría su corriente de fuga entre puerta y fuente).

Este sería nuestro dispositivo físico, ahora tendríamos que crear su equivalente en los servidores de internet que van a recoger la información que nuestra placa envía.

Dispositivo en los servidores de internet.

En las redes LoRaWAN hay 2 servidores en los que tenemos que asociar/replicar el dispositivo físico que vayamos a usar: en el servidor de red y en el servidor de aplicación.

El gateway manda los datos de nuestra placa al servidor de red y este servidor de red mandaría los datos al servidor de aplicación que le digamos, en el servidor de aplicación daremos uso a los datos recibidos. Por ejemplo, en el servidor de aplicación tendríamos una base de datos con todas las medidas recibidas del sensor de temperatura de nuestra placa en el último año, y las herramientas necesarias para representarlas de forma visual en una página web.

Si quieres saber más sobre como funcionan las redes LoRaWAN y los distintos elementos que la componen es recomendable hacer este curso gratuito de Semtech.

Servidor de red.

Para crear nuestro dispositivo en el servidor de red nos vamos a la siguiente dirección de Helium: https://console.helium.com/ y nos registramos para crear una cuenta.

Esta es la consola de pruebas de Helium que nos permite registrar hasta 10 dispositivos, para registrar un nuevo dispositivo primero pulsamos en “Devices” (flecha roja en la imagen superior) para acceder a la ventana de dispositivos.

Añadimos un nuevo dispositivo pulsando en “Add New Device” (flecha roja imagen superior) y se nos abrirá la siguiente ventana.

En ella para registrar el dispositivo solo tenemos que darle el nombre que queramos y pulsar “Save Device”. Con esto ya habríamos creado nuestro dispositivo en la red de Helium y nos aparecerá en la ventana de Devices de la consola, para cada dispositivo se generan 3 números (rectángulo en rojo de la imagen) que identifican a este, volveremos a ellos más adelante cuando hagamos el programa para el microcontrolador.

Servidor de aplicación.

Para almacenar los datos enviados por la placa LoRa y hacer algo con ellos tenemos que usar lo que se denomina en las redes LoRaWAN un servidor de aplicación. Aquí como con el servidor de red podemos usar uno propio o uno de terceros, vamos a usar el servidor de Cayenne Mydevices que nos permite registrar hasta 10 dispositivos (si recuerdo bien) de manera gratuita, para ellos nos vamos a  cayenne.mydevices.com donde al registramos se nos abrirá la siguiente ventana.

Para registrar nuestro dispositivo en Cayenne pulsamos “Add new…” y “Device/Widget” como se ve en las flechas de la imagen superior, y pasamos a la siguiente venta.

En ella como se muestra en la imagen superior pulsamos en “LoRa”, en “Helium” y buscamos y pulsamos en “Cayenne LPP” pasando a la siguiente ventana.

En la ventana superior para crear el dispositivo solo tenemos que añadir el DevEUI de nuestro dispositivo y darle a “Add device”, dejando el resto de opciones como están. El DevEUI de nuestro dispositivo lo encontramos en el paso anterior del servidor de red, dentro de la consola de Helium vamos a “Devices” y pulsamos en el nombre del dispositivo que hemos registrado anteriormente para ver el DevEUI que tenemos que copiar.

El DevEUI (Device EUI) lo podemos encontrar en la imagen superior, pulsamos en el botón de copiar DevEUI (flecha en rojo de la imagen supeior) y lo pegamos en el campo para el DevEUI que encontrabamos en Cayenne.

Una vez añadido el dispositivo en Cayenne lo encontramos como “Cayenne LPP”, por lo que en Cayenne podemos pulsar en el nombre del dispositivo e ir a “Configure” para cambiarlo a uno que sea más fácil de identificar, por ejemplo lo podemos dar el mismo nombre que hemos dado al dispositivo en la consola de Helium.

Conectando el servidor de red con el servidor de aplicación.

Ya hemos registrado el dispositivo en el servidor de red (Helium) y en el servidor de aplicación (Cayenne). Ahora hace falta decirle al servidor de red que todos los datos que le lleguen del dispositivo (nuestra placa LoRa) a través de los gateways que los recogen los mande al servidor de aplicación (Cayenne). Para ello tenemos que crear en la consola de Helium lo que denomina una integración, hacemos lo siguiente.

En la consola de Helium pulsamos en “Integrations” y en “Add New Integration” abriéndose la siguiente ventana.

Donde pulsamos en el icono “myDevices Cayenne”.

En la ventana pulsamos en “+ Add integration”.

Y por último le damos el nombre que queramos a la integración que vamos a crear y al botón “Add Integration”.

Una vez creada la integración tenemos que conectar el dispositivo que hemos creado anteriormente en la consola de Helium con la integración.

Para ello en la imagen superior primero pinchamos en “Flows”, “Nodes” y “Devices” donde seleccionamos el dispositivo que hemos creado y pinchando en él sin soltar el ratón lo arrastramos al centro de la ventana.

De igual forma pulsamos sobre “Integrations” y pinchando en la integración que hemos creado sin soltar el ratón la arrastramos al centro de la pantalla.

Por último y para terminar, unimos de manera gráfica el dispositivo con la integración, para ello pinchamos con el ratón en el círculo del dispositivo (dentro de la circunferencia roja en la imagen superior) y sin soltar lo arrastramos hasta el círculo de la integración, ambos quedarán unidos por una línea continua.

Con esto terminamos la configuración del servidor de red y del servidor de aplicación, hemos realizado los siguientes pasos:

• Hemos creado un dispositivo en el servidor de red (Helium) que representa a nuestra placa.
• Hemos creado un dispositivo en el servidor de aplicación (Cayenne) que también representa a nuestra placa.
• Y hemos dicho en Helium que todos los datos que le lleguen de nuestra placa (identificada dentro del servidor de Helium por el dispositivo que creamos en este) desde los gateways los mande al servidor de aplicación de Cayenne (donde hay otro dispositivo creado en Cayenne que recogerá los datos representando a nuestra placa). Para vincular el dispositivo en Helium con el servidor de Cayenne hemos creado una integración, que indica que todos los datos que Helium reciba de ese dispositivo se manden al servidor de Cayenne. Si tuviéramos más dispositivos que quisiéramos que mandasen datos a Cayenne, los arrastraríamos en la ventana de “Flows” y los conectaríamos a la misma integración de Cayenne creada para conectar el dispositivo inicial.
  

  Varios dispositivos mandando datos a Cayenne. La flecha discontinua significa que hay flujo actual de datos.

   

Terminadas las configuraciones en los servidores, ahora vamos a ver el código que tenemos que grabar en nuestra placa para que mande los datos de la lectura del sensor de tempertura al servidor de red de Helium (el servidor de red ya se encarga de redirecionar los datos al servidor de aplicación donde les daremos un uso, para la placa el servidor de aplicación no existe, ella solo se comunica con el de red).

Código de Arduino para conectar la placa LoRa a la red de Helium.

El código necesario para estra entrada del blog lo encontramos en este repositorio.

Para escribir el código utilizado para conectar nuestra placa LoRa a la red de Helium lo primero es instalar las librerías necesarias en PlatformIO, añadimos las librerías de la siguiente imagen.

Los pasos para instalar una librería se vieron en la entrada anterior del blog, seguimos las flechas rojas de izquierda a derecha en la imagen superior, buscamos y añadimos al proyecto las siguientes librerías:

• SHT2x by Rob Tillaart: necesaria para integrar en el proyecto el sensor de temperatura y humedad.
• MCCI LoRaWAN LMIC library by IBM (4.1.1): librería que usaremos para utilizar la radio y comunicarnos con la red de Helium.
• Rocket Scream LowPowerAVRZero by Rocket Scream Electronics: la usamos para poner al microcontrolador a dormir.
• CayenneLPP by Electronic Cats: la utilizamos para mandar al servidor de Cayenne los datos en el formato que espera recibirlos. Al añadir esta librería se añade la librería ArduinoJson que aparece en la imagen,

Instaladas las librerías pasamos a comentar los aspectos más importantes de los distintos archivos de código que tenemos en el proyecto.

platformio.ini: enlace al fichero.

Este archivo se explicó en la entrada anterior. Se han añadido solas las líneas de las librerías que hemos añadido al proyecto. En build_flags pasamos opciones para compilar el código que están relacionadas con la librería LMIC, donde especificamos características del módulo de radio LoRa que estamos usando y deshabilitamos los ping y beacons de la librería, ya que nuestra placa LoRa va a ser un dispositivo de clase A.

Para más información sobre las distintas clases de dispositivos en una red LoRaWAN y como funcionan es recomendable hacer el curso grauito de Semtech.

configuracion.h: enlace al fichero.

En este fichero definimos opciones de funcionamiento del programa.

MINUTOS_ENVIO configura cada cuanto tiempo la placa realiza un envío a la red de Helium, cuantos más envíos realice la placa más energía consume y menos durarán las baterías.

DEBUG activa o desactiva los mensajes que la placa manda por su puerto serie para comunicarse con un monitor serie de PlatformIO, lo utilizamos para observar el funcionamiento del código. Cuando la placa no esté conectada a PlatformIO comentaremos la línea de DEBUG, no querremos ningún mensaje por el puerto serie ya que esto aumenta el tiempo que el microcontrolador está despierto y por tanto el consumo de energía.

El programador tiene 3 modos de funcionamiento: UPDI, UART y Auto. Para programar seleccionamos el modo UPDI, para comunicarnos por el puerto serie lo conectamos en modo UART, abrimos un monitor serie en PlatfotmIO y damos alimentación a la placa para ver todos los mensajes que ocurren desde el inicio del progrma.

Para que funcione el modo Auto del programador y no estar conmutando entre UPDI y UART, según me comenta Ricardo (la persona que lleva el taller de Arduino en la Asociación Maker de Alicante) hay que actualizar la versión del avr-gcc dentro de PlatformIO, así lo han tenido ellos funcionando durante el taller, lo que resulta mucho más cómodo.

dispositivos.h: enlace al fichero.

En este fichero añadimos las claves e identificadores que genera Helium para cada dispositivo que creamos en el servidor de red, aquí vinculamos un dispositivo físico (como nuestra placa LoRa) con un dispositivo del servidor de red.

Cada dispositivo que creemos en Helium tiene 3 parámetros: el DEVEUI, APPEUI (identifica a la red Helium, es el mismo para todos) y el APPKEY, parámetros que debemos añadir a nuestro código para asignar a un dispositivo físico otro del servidor. En este archivo tendremos 3 líneas por cada dispositivo creado en Helium y que vayamos a programar usando este programa.

Estos parámetros los encontramos en la ventana de “Devices” de la consola de Helium.

Vamos a Devices y pulsamos sobre el nombre del dispositivo que queremos vincular con la placa física, para copiar cada identificador/clave del dispositivo y llevarlos al programa lo hacemos pulsando los botones que se ven en la imagen superior con un 1, 2 y 3.

• Con el botón 1 ponemos la secuencia de números en formato hexadecimal (0xFF) separando por una coma cada byte.
• Con el botón 2 ponemos la secuencia en formato lsb o msb, el Device EUI y App EUI tenemos que copiarlos en formato lsb, y el App Key en formato msb (si no vemos el App Key le damos al ojo junto a su nombre para mostrarlo).
• Con el botón 3 copiamos la secuencia de número y la pegamos en el programa en su #define correspondiente.

Es más fácil tener todas las claves en un fichero.h y cada vez que queramos programar (o reprogramar) un dispositivo solo tenemos que cambiar el nombre de este en el main.cpp.

Los ficheros: pines.h, pines.cpp, adc.h y adc.cpp se explican en la entrada anterior del blog.

main.cpp: enlace al fichero.

Este es el fichero donde usamos la librería LMIC para establecer la comunicación por LoRA con el servidor de Helium, leemos el sensor de temperatura-humedad y mandamos datos cada X minutos al servidor de Helium. Es un ejemplo básico de comunicación con lo mínimo para hacer llegar los datos a Helium usando el formato de datos que espera recibir el servidor de Cayenne, no estamos guardando contadores de LoRa en la EEPROM ya que no los necesitamos para este ejemplo.

Para entender como funciona la librería LMIC lo suyo es leerse su documentación, todas las partes de este archivo están comentadas. Vamos a ver las partes principales del código que hay que tocar para alterar la funcionalidad de este programa de muestra.

En esta parte del código añadimos el nombre de los #defines que hicimos en dispositivos.h, vinculamos nuestra placa física con un dispositivo creado en la red de Helium.

Siempre que ocurra un evento en la comunicación LoRaWAN se llamará a esta función, por ejemplo cuando nos conectemos a la red por primera vez por OTAA nos imprimirá por el puerto serie (si tenemos habilitado la opción de DEBUG) las llaves que se han generado para la sesión, si no nos podemos conectar nos imprimirá el mensaje correspondiente, etc…

Podemos usar esta función para que nuestro programa tome decisiones en función del evento que ocurra en la comunicación LoRaWAN, en este caso prestamos atención a este evento para saber cuando poder poner el microcontrolador a dormir.

En el programa el microcontrolador se despierta y si han pasado los minutos suficientes desde la última transmisión a Helium lee la batería, el sensor de temperatura y humedad y realiza un nuevo envío. Hasta que el nuevo envío no finalice no podemos poner el microcontrolador a dormir, cada vez que la librería LMIC finalice el envío llamará al evento EV_TXCOMPLETE, cambiando el valor de una variable cuando sucede este evento podemos saber cuando podemos poner el microcontrolador a dormir en el bucle principal.

Al iniciarse el programa el microcontrolador intenta comunicarse con Helium para recibir las claves de sesión, si no hubiese una gateway escuchando el microcontrolador continua intentando conectar sin ponerse a dormir, por lo que si no queremos quedarnos sin batería podemos activar el modo DEBUG y ver por el monitor serie de PlatformIO conectado a la placa que eventos suceden en el caso anterior, para poner el microcontrolador a dormir después de X intentos y que no se quede sin batería si no hay cobertura de Helium, y ya lo volverá a intentar cuando se despierte X minutos después. También hay que decir que según va haciendo intentos de conexión sin éxito el microcontrolador va cambiando el “spread factor” de la transmisión, con el cambio esta tiene mayor alcance a cambio de que los mensajes tarden más en enviarse.

Recordar cuando usamos una radio LoRa estamos sujetos a las restricciones del uso de la frecuencia de cada país, teniendo una limitación de la cantidad de tiempo que la radio puede emitir y que depende de nuestro programa.

La función do_send inicia la transmisión de un mensaje a la red de Helium, en ella se forma el mensaje con los datos que queremos transmitir al servidor de Cayenne usando el formato de datos que espera recibir dicho servidor.

Para dar formato a los datos que queremos enviar a Cayenne usamos la librería CayenneLPP que hemos añadido al proyecto. Para usar esta librería al principio del programa tenemos que definir el tamaño del “Payload” de nuestro mensaje, es decir cual va a ser la cantidad de Bytes que van a ocupar los datos (temperatura, humedad y batería) que vamos a mandar al servidor de aplicación (Cayenne), siguiendo los criterios que podemos ver en este enlace.

Definimos el tamaño del payload al principio del programa cuando hacemos la instancia de Cayenne.

Cada dato que mandemos a Cayenne ocupa 2 Bytes + n Bytes, dependiendo el tamaño de n del tipo de dato que sea. Por ejemplo si queremos mandar la lectura de un sensor digital, mirando el enlace anterior vemos que un sensor digital ocupa 3 Bytes (2 Bytes + 1 Byte), un sensor analógico ocupa 4 Bytes (2 Bytes + 2 Bytes), etc… En nuestro caso vamos a mandar 3 sensores analógicos (batería, temperatura y humedad) que ocuparían 12 Bytes.

Cada vez que hacemos un nuevo envío formamos el Payload con los últimos valores de batería, temperatura y humedad.

lpp.reset() resetaría el payload, lpp.add*(x,x) va construyendo el payload con los datos que queremos mandar, la variable que queremos mandar va en el segundo parámetro de esta función, mientras que el primer parámetro indica el canal o número de sensor al que corresponde la variable enviada (es decir la posición que toman sus datos en el payload que formamos). LMIC_set pone el mensaje en cola para ser enviado al servidor de RED.

Cada vez que el timer genera el pulso de Wake (como se explica en la entrada anterior) se ejecuta la interrupción asociada con este, el código de la interrupción sería el siguiente:

La ISR del timer es muy sencilla, en ella encontramos variables globales que controlan el flujo del programa en el bucle principal. b_pulsoDone se pone a 1 para que en el bucle principal se genere el pulso de DONE. Cuando hemos entrado x veces en la ISR (la ISR ocurre una vez por minuto) b_iniciarEnvio se pone a 1 para que en el bucle principal se realice un nuevo envío a Helium, b_envioEnCurso también se pondrá a 1 cuando se va a iniciar un nuevo envío y no se pondrá a 0 hasta que el envío termine, indicando al microcontrolador que ya se puede ir a dormir.

Comentar en esta parte que cuando declaramos variables globales que se usan en las ISR hay que hacerlo con la palabra volatile delante, ya que esta variable puede cambiar en el flujo del programa principal o en el de la interrupción y no queremos que el compilador ponga copias de estas variables en más de una dirección de memoria (como podría ser en los registros de acceso rápido de la CPU), queremos evitar por ejemplo el caso de que la interrupción use la variable de una dirección de memoria mientras el bucle principal esta utilizando la misma variable pero en otra dirección de memoria distinta (pudiendo contener cada una valor distinto). Con volatile delante de la declaración de la variable evitamos acciones de optimización del compilador sobre esta.

Por último vamos a ver el código que hemos añadido respecto a la entrada anterior en el bucle principal.

Si han pasado x minutos desde el último envío a Helium b_inciarEnvio se pone a 1 satisfaciendo la condición del if y ejecutando el código de este, donde leemos el sensor de temperatura, de humedad, leemos la batería y almacenamos sus lecturas en las variables globales que hemos declarado para ello. Posteriormente se llama a os_setCallback que inicia el trabajo de transmitir los datos a Helium y acabará llamando a la función do_send donde formábamos el payload y poníamos el envío de datos en cola.

La parte de código que nos queda por ver del bucle principal es la siguiente:

No he mirado como está implementada la librería LMIC internamente (no es una librería sencilla de hacer) entiendo que os_runloop_once() es la función que ejecuta todos los procesos que tienen lugar para la realización de un envío a Helium, cuando hay un envío en curso esta función se tiene que llamar con la mayor frecuencia que podamos, es decir que no debemos poner un delay(1000); justo debajo de esta línea de código, ya que este retraso podría afectar al funcionamiento de la librería LMIC.

Una vez que el envío se ha completado la variable b_envioEnCurso toma el valor 0 y el microcontrolador ya ha realizado todas las tareas para las que se había despertado, por lo que entramos en el if donde está la instrucción de poner a dormir al microcontrolador.

Probando el código.

Compilamos el código y si no nos da ningún error lo descargamos en nuestra placa. Si tenemos un gateway de la red Helium cerca, accedemos a la consola de Helium y nos vamos a Devices pulsando sobre el nombre de nuestro dispositivo y deberíamos ver lo siguiente.

En la consola de Helium podemos ver todas las transmisiones que llegan de los dispositivos y salen desde el servidor hasta estos, cada una representada por un punto en esa gráfica.

• Join Request: es una petición de unión que sale desde el dispositivo y llega al servidor de Helium.
• El Join Accept: es el envío de las claves que el dispositivo necesita para unirse a la red de Helium, se envían desde el servidor de Helium hacia el dispositivo.
• Y el Uplink: es un envío de datos (nuestras medidas de temperatura, humedad y batería) que salen desde nuestra placa y llegan al servidor de Helium. Posteriormente estos datos se enviarán al servidor de Cayenne que hemos indicado en la integración para este dispositivo.

Si solo vemos los eventos de “Join Request” y “Join Accept” que se repiten y no llegamos a ver un Uplink, significa que el gateway está recibiendo la comunicación de nuestro dispositivo, pero el envío de las claves que salen desde el gateway hacia nuestro dispositivo no le están llegando, por lo que para el dispositivo es como si ninguna gateway estuviera recibiendo sus transmisiones y lo sigue intentando.

Si no vemos nada o hemos puesto algo mal en el código, o no hay gateway de Helium cerca.

Si pinchamos sobre el símbolo “+” al lado del nombre de Uplink podemos ver información sobre la transmisión.

Prestando atención a los dos recuadros que he puesto en rojo:

• En Hotspot Name nos aparecerá algo como palabra-palabra-palabra, es el nombre que Helium asigna al gateway al que nos estamos conectando. Si nos vamos al explorador de Helium y metemos esas palabras separándolas por espacios en lugar de guiones, vemos la ubicación del gateway que está recibiendo nuestros datos.
• RSSI nos indica la fuerza de la señal con el gateway está recibiendo nuestro datos, cuanto mayor (el número más cercano a 0) sea el RSSI mejor será nuestra señal. Cuando veamos una RSSI comprendida entre -110 y -120 estamos cerca del límite de la distancia que nos podemos alejar del gateway para recibir datos de ella.

Si nos vamos a la consola de Cayenne deberíamos haber recibido los datos que han llegado de la placa al servidor de Helium, y al pinchar sobre nuestro dispositivo veríamos algo así:

Vemos los datos de la batería y los sensores según la posición en los que los hemos codificado en el payload, si pulsamos en el botón de la flecha en rojo podemos editar su nombre y darles un aspecto con el que sea fácil identificar a cada uno de ellos.

Luego en Cayenne si pulsamos en Data en la imagen superior tenemos un registro con todos los datos que han llegado del dispositivo en un periodo de tiempo, podemos visualizarlos en modo gráfico, establecer acciones con ellos: por ejemplo que cuando la temperatura baja de cierto valor nos mande un mensaje al teléfono o al correo, etc…

También podemos crear un panel donde visualizar los datos y compartirlos con un enlace, para que cualquiera pueda visualizarlos sin tener la necesidad de acceder a nuestra cuenta de Cayenne. Todos estos casos de uso podemos ir probándolos dentro de la consola de Cayenne.

Duración de la batería y coste de las transmisiones.

Una vez que tenemos nuestra placa funcionando vamos a ver cuanta batería va a consumir. Para ello usamos el Power Profiler Kit II presentado en la entrada anterior del blog, una herramienta de bajo coste que es imprescindible tener si vamos a trabajar con este tipo de dispositivos.

Vamos a capturar el consumo de batería cuando el dispositivo se despierta y hace un envío a Helium, cuando el dispositivo se despierta para atender al pulso de Wake del timer y cuando el dispositivo duerme.

Cuando el dispositivo se despierta y envía los datos a Helium vemos 3 picos en la gráfica, el más grande se corresponde cuando la radio emite datos y los 2 más pequeños cuando la radio habilita la recepción de datos. Consume una media de 3.94 mA durante 6.229 segundos.

El consumo que tiene el dispositivo cuando se despierta para atender al pulso de Wake, generar el pulso de Done y volver a dormirse lo observamos en la imagen superior. Estamos usando el PPK2 un dispositivo de bajo coste para medir, no sé como está diseñado por dentro pero cuando tiene que conmutar los circuitos de medida para abordar el rango dinámico, nos podría estar ocultando el primer pico de tensión (la placa también se alimenta de sus condensadores en este pulso). De todas formas este consumo es muy pequeño y va a ser prácticamente despreciable en el consumo global del dispositivo.

Podemos medir el consumo cuando el dispositivo duerme con el PPK2 pero si tenemos un multímetro adecuado para la tarea será más preciso hacerlo con este (aún así la precisión del PPK2 comparando con el multímetro es muy buena).

El consumo cuando el dispositivo está durmiendo es de 1.084 uA (con el sensor de temperatura-humedad incluido).

Por lo que con los datos anteriores podemos calcular el consumo total de corriente del dispositivo, y saber cuanto nos durarán las baterías AAA con las que alimentamos la placa.

Estamos midiendo temperatura y humedad ambiente, por lo que con mandar un par de medidas a la hora puede ser suficiente. Si no me equivoco sumando, restando y dividiendo (que después de lo largo que se ha hecho esta entrada y el tiempo que llevo hoy escribiendo es posible) el consumo total sería el siguiente:

Mandando 2 mensajes a la hora el dispositivo consume unos 14.71 microAmperios/hora, si suponemos que las baterías AAA van a tener una capacidad útil de 700 mA/h, estimamos que las baterías tendrán una duración de 5.4 años (si el PCB coge residuos, suciedad, humedad, etc.. incrementara su consumo de corriente).

Cada vez que mandamos un mensaje a Helium tenemos que pagar, si nuestra payload es menor de 24 Bytes (si recuerdo bien) cada mensaje consumirá 1 “data credit”. 100k data credits cuestan $1 en la consola de pruebas de Helium, luego nuestro dispositivo en su vida útil de 5.4 años pagará un total de $0.94 por transmitir cada 30 minutos las medidas durante ese tiempo.

Aunque el consumo es más que aceptable probablemente el consumo se pueda reducir mejorando el código en la parte que el microcontrolador realiza el envío, tanto en el mio (soy más de PCBs que de firmware) que solo he hecho un ejemplo rápido sin conocer Arduino (copiar y pegar los ejemplos que he visto en las librerías que hemos usado) para la entrada del blog, como el código de la librería de LMIC que no sé como está implementada, habría que ver si entre la ventana TX y las RXs se puede reducir el consumo del microcontrolador, ya que siempre permanece activo.

En el repositorio de la Asociación Maker de Alicante los que han participado en el taller de IoT probablemente suban código más probado que el mio.

Conclusiones.

En estas tres entradas del blog se muestra como hacer y usar un dispositivo para conectarse a redes LoRaWAN, con el que poder dar un taller o hacer proyectos a nivel de aficionado. Se han nombrado las cosas de forma muy rápida, ya que si no estas entradas serían muy largas, quien quiera aprender sobre redes LoRaWAN recomiendo hacer el curso gratuito de Semtech.

La red Helium se ha expandido gracias a la criptomoneda, y esperemos que aguante la caída que están teniendo en el último año y no desaparezca. El uso de LoRa diría que en los próximos años va a ser masivo, los casos de uso de esta tecnología son infinitos.

Arduino es una herramienta fantástica para hacer proyectos a nivel de aficionado, para aprender y dar los primeros pasos en la electrónica, programación, etc… pero para un producto muy seguro tienes que estar de las librerías de un tercero para usarlas.

Para completar estas entradas nos faltaría hacer una sobre The Things Network, donde nos conectaríamos por ABP en lugar de OTTA para ver los dos métodos, pero debido al poco número de gateways que hay en España no sé si merece la pena.

Me leería todo lo escrito antes de darle al botón de publicar del blog, pero son 5650 palabras y yo necesito hacer como el microcontrolador y ponerme a dormir…

Si has leído hasta aquí espero que te haya sido útil :).