24 abr 21 Trazabilidad de activos en exterior con LoRaWAN, Chirpstack, Node-Red y una arquitectura de microservicios
Bonito combo el del título de este artículo, ¿verdad? A resultas de algunas actividades que estoy realizando en el trabajo relacionadas con redes IoT industriales, en mi tiempo libre le he dado una vuelta de tuerca al proyecto, para realizar un piloto de trazabilidad de activos en exterior. Cómo no, basado en el uso de LoRaWAN y Chirpstack, como contaba en un artículo anterior.
Arquitectura LoRaWAN
La cosa es que aprovechando que contaba con una pequeña infraestructura local de Chirpstack desplegada mediante microservicios, me hice con un dispositivo de Dragino bastante interesante, el LBT1:
Dragino LBT1
Este dispositivo es bastante interesante: integra un módulo GPS que permite obtener su ubicación precisa, que es trasmitida mediante LoRaWAN para ser posteriormente explotada. Pero cuenta con capacidad Bluetooth, para realizar ubicación en interiores mediante iBeacons; dispone de un acelerómetro, de tal manera que el dispositivo tiene capacidad de enviar la señal LoRaWAN cuando detecta movimiento y no de manera indiscriminada, con el consiguiente ahorro de batería; tiene una batería recargable de 1000 mAh (que he podido probar que da para más de una semana de actividad sin necesidad de recarga); y cuenta con un botón que -en su configuración por defecto- permite pasar al dispositivo a un modo de emergencia, de tal manera que pasa a emitir la señal de manera periódica (y no activada por el acelerómetro, como en el modo normal), y con una codificación del paquete de datos específica, de tal manera que es posible distinguirlo de una transmisión normal, y actuar en consecuencia.
Estas capacidades, junto con la característica de integración HTTP proporcionada por Chirpstack, permiten algo bastante interesante, y es realizar un sistema de monitorización de activos en exterior, si lo combinamos con un procesamiento en segundo plano. Para ello, en mi caso, he utilizado Node-Red.
Flujo Node-Red para trazabilidad de activos
La idea general es la siguiente: se establece un punto de entrada desde donde recibir los POST HTTP provenientes de Chirpstack, que nos harán llegar cada uno de los eventos provenientes de los dispositivos. Aquí realizamos un primer procesado para obtener información relevante de la señal transmitida (básicamente, latitud, longitud, identificador del dispositivo, cantidad de carga de la batería, y si se trata o no de una señal de emergencia). Con esta información realizamos dos acciones: representar cada objeto definido en la aplicación Chirpstack y que esté enviando señal en el mapa, bien con un icono verde si todo va bien, o con un icono rojo si se ha pulsado el botón de emergencia. Además de esto, se mantiene trazabilidad de los movimiento realizados creando una línea con las distintas ubicaciones GPS enviadas por el dispositivo. Todo ello se representa sobre un mapa, que permite definir zonas de calor, y filtrar por cada uno de los objetos que estén enviando señal. El resultado es algo como esto:
Mapa de ubicaciones resultante
El sistema, además, tiene capacidad para integrarse con sistemas de monitorización de terceros, así como con sistemas de alerta específicos. En mi caso he realizado un procesamiento adicional, que consiste en realizar persistencia de datos para su análisis posterior, en este caso, mediante una hoja de Google Spreadsheet, lo que es interesante de por sí, y puede dar para otro artículo.
Este ejemplo de aplicación tiene bastantes aplicaciones prácticas: realizar seguimiento de activos en una zona exterior de una empresa, seguimiento de personas mayores en zonas urbanas sin coste de transmisión de datos, y con la capacidad de que emitar una señal de emergencia en caso de necesidad, o el seguimiento de visitantes en parques naturales y zonas boscosas, ya que como demostré hace algún tiempo, es posible cubrir zonas muy amplias en entorno forestal con un despliegue de infraestructuras mínimo. E incluso, que es lo que tenía en mente, un sistema para seguimiento de ciclistas o senderistas de montaña en zonas de montaña.
Etiquetas: chirpstack, dragino, lora, lorawan, microservicios, node-red
13 mar 21 Despliegue de un servidor LoRaWAN libre con Chirpstack basado en contenedores
Estas semanas (en parte por afición y en parte por trabajo) he seguido avanzando con mis investigaciones con tecnología IoT basada en LoRaWAN. Ya había hablado anteriormente de comunicaciones básicas LoRa, uso de una red abierta LoRaWAN como es la red TTN, pero no había tocado el tema de disponer de un servidor LoRaWAN privado. Y es aquí donde entra en acción Chirpstack. Éste es un diseño basado en software libre que proporciona la capacidad de conectar dispositivos de campo LoRa y junto con los Gateway LoRaWAN permite constituir una red privada LoRaWAN. En este contexto, ChirpStack una solución que mediante una interfaz de usuario amigable permite gestionar dispositivos, usuarios, gateways, y que proporciona una interfaz de integración que permite interactuar con terceros sistemas.
Interfaz web de administración de Chirpstack
ChirpStack proporciona una serie de componentes que interactúan entre sí para proporcionar la infraestructura necesaria para recibir información de dispositivos y gateways LoRa, con el objeto de proporcionar capacidades de gestión de dichos dispositivos (por un lado) y de poner la información que envían los dispositivos a disposición de terceros sistemas para que la consuman. Esto se articula en base a los siguientes componentes:
- Dispositivos LoRa: Dispositivos de campo que envían por LoRa información de los sistemas que controlan (final de carrera, sensor de temperatura, el propio estado del dispositivo, etc…) a un Gateway, o bien que reciben información de este Gateway para realizar una acción (activar un relé, encender un led…).
- Gateway LoRaWAN: Elemento que recibe información de los dispositivos, y transforma un paquete LoRa en un paquete IP (bien TCP o UDP, aunque lo más común es lo primero), transfiriendo la información que proporciona el dispositivo hacia un servidor donde esta información es procesada. También tiene capacidad de enviar información o solicitud de acciones a los dispositivos por parte de este servidor. Junto con los dispositivos LoRa, constituyen los elementos de campo, y aunque no forman parte estrictamente hablando de ChirpStack, sí tienen una interacción muy cercana con él.
- Gateway Bridge: Es el primero de los componentes de ChirpStack, si seguimos el flujo de datos desde los dispositivos de campo hasta los servidores de computación. Su función es recibir la información de los gateways y procesarla, volcándola en un servidor MQTT de mensajería. Este bridge puede residir en el servidor donde se despliegue ChirpStack, en los propios gateways LoRa o estar instalado en un tercer componente aparte. Su función primordial, en pocas palabras, es volcar la información proveniente de la red LoRaWAN en el sistema de mensajería MQTT, donde será consumida por el resto de servicios de ChirpStack.
- Network Server: Segundo de los componentes de ChirpStack. Es el servidor de red LoRaWAN propiamente dicho. Se encarga de monitorizar el estado de la red, los dispositivos conectados a la misma, y administrar el acceso de nuevos dispositivos a la red. También se encarga, en el caso de redes con múltiples gateways, de resolver duplicidades de dispositivos (dado que un paquete enviado por un dispositivo puede ser recibido y procesado por más de un Gateway), consolidar la información, y ponerla a disposición del servidor de aplicaciones de ChirpStack. También se encarga de las siguientes funcionalidades: Autenticación de dispositivos; gestión de la capa mac LoRaWAN; gestionar el envío de mensajes desde ChirpStack a los dispositivos, haciendo uso del canal descendiente de comunicaciones.
- Application Server: Tercer componente de ChirpStack. Es corazón de la arquitectura. Permite crear “aplicaciones”, que en este contexto son grupos de dispositivos que envían una información del mismo tipo. Relaciona la información enviada por uno o varios dispositivos, almacenando un histórico, y la pone a disposición de terceros sistemas mediante diversos métodos de integración.
- Geolocation server: Componente opcional que permite dotar de mayores capacidades de geolocalización de los dispositivos, en caso de que el Gateway no proporcione esta información, o en el que queramos hacer un tratamiento personalizado de la misma.
- Broker MQTT: Utilizado como sistema de mensajería interna para el resto de componentes de ChirpStack y la comunicación con los gateways.
- Redis: Motor de base de datos en memoria, que gestiona la información que se intercambia entre los dispositivos y aplicaciones creadas en ChirpStack.
- Base de datos PostgreSQL: Almacena información de configuración de ChirpStack, organizaciones, aplicaciones, usuarios, etc… además de información histórica enviada por los dispositivos. Existen diversos mecanismos (HTTP, MQTT, InfluxDB, RabbitMQ, PostgreSQL, Azure Service Bus, AWS SNS, API REST).
Arquitectura de alto nivel de Chirpstack
El aspecto clave de ChirpStack hace referencia al modo en el que se procesa la información. ChirpStack hace uso de los componentes anteriores para componer y almacenar información estructurada proveniente de los dispositivos de campo, en un formato similar al siguiente:
{
“applicationID”: “123″,
“applicationName”: “temperature-sensor”,
“deviceName”: “garden-sensor”,
“devEUI”: “0202020202020202″,
“rxInfo”: [
{
"gatewayID": "0303030303030303",
"name": "rooftop-gateway",
"time": "2016-11-25T16:24:37.295915988Z",
"rssi": -57,
"loRaSNR": 10,
"location": {
"latitude": 52.3740364,
"longitude": 4.9144401,
"altitude": 10.5
}
}
],
“txInfo”: {
“frequency”: 868100000,
“dr”: 5
},
“adr”: false,
“fCnt”: 10,
“fPort”: 5,
“data”: “…”,
“object”: {
“temperatureSensor”: {“1″: 25},
“humiditySensor”: {“1″: 32}
},
“tags”: {
“key”: “value”
}
}
Otro aspecto interesante es que Chirpstack se puede desplegar de muy diversas maneras, al estar estructurado en una serie de componentes bien definidos que se comunican entre ellos mediante puertos e interfaces estandarizados. Permite tanto realizar un despliegue convencional en un único servidor, a desplegarse en un modelo de microservicios en un entorno Docker o Kubernetes. Para el caso en el que estoy trabajando, he optado por hacer un despliegue basado en contenedores Docker en una máquina virtual, aunque he realizado algunas pruebas con un despliegue más monolítico, y en el ámbito laboral estoy haciendo uso de un entorno Kubernetes.
El despliegue mediante Docker es tremendamente sencillo, ya que los propios desarrolladores de Chirpstack proporcionan una configuración de ejemplo con todos los elementos necesarios. Y una vez desplegado, es bastante sencillo añadir los componentes necesarios. En mi caso, he integrado un gateway Dragino LG308. La integración es tan sencilla como apuntar el servicio LoRaWAN del gateway al puerto 1700/UDP del servidor donde se encuentre levantado el componente Network de Chirpstack. Es posible desplegar un paquete software en el gateway Dragino para convertirlo en un Gateway Bridge de Chirpstack, pero si tenemos éste desplegado en otro sitio, no es necesario realizarlo.
Registro de un gateway en Chirpstack
Y en cuanto al registro de los dispositivos, tampoco supone mayor inconveniente. Es necesario definir de manera previa unos perfiles de configuración de dispositivos y la aplicación donde registramos estos últimos, y a partir de ahí, se puede crear la propia aplicación, y registrar los dispositivos, bien por OTAA o ABP, en función de nuestras preferencias. Con todo ello, se tiene una red privada LoRaWAN perfectamente funcional.
Ejemplo de recepción de datos de un dispositivo de campo (1)
Ejemplo de recepción de datos de un dispositivo de campo (2)
Etiquetas: chirpstack, contenedor, docker, dragino, kubernetes, lora, lorawan, microservicio
07 feb 21 Cómo registrar información de The Things Network en una hoja de cálculo de Google Spreadsheet
Llevo algún tiempo trabajando con redes LoRa y LoRaWAN, tanto en temas de trabajo, como finalmente desde el punto de vista profesional. En este último ámbito voy a tener que hacer un estudio de cobertura de una red LoRaWAN para uno de nuestros clientes: la idea es registrar una serie de parámetros de los equipos que se van a instalar en una planta de producción, para lo que es necesario determinar los puntos más adecuados para instalar los gateways que encaminarán la información de los dispositivos. Todo esto implica recorrerse la planta, realizando pruebas de ubicación de los mismos y registrar estos parámetros.
Para ello voy a utilizar, dado que la red LoRaWAN del cliente aún no está constituida, la red The Things Network, que ofrece toda la información que necesito. Sin embargo, la red TTN es una red de transporte, y aunque muestra la información que necesito, no la consolida. Al fin y al cabo se trata de eso, de transportar. El tema del almacenaje ha de realizarse por otro lado. Podría apuntar estos valores a mano, pero he encontrado una manera más divertida de realizarlo: registrar los parámetros y la información de la red con Google Spreadsheet. Ojo, este mecanismo está muy bien para pruebas preliminares y análisis como el que estoy buscando, pero no debe ser usado en un entorno en producción, ya que no se establecen (es más, se eliminan) mecanismos de seguridad de las comunicaciones o de la información alguno.
El artículo que enlazo explica perfectamente cómo hacerlo, pero dejo aquí los pasos generales:
- Crear una hoja de cálculo en Google Spreadsheet, y ponerle un nombre (ojo, tanto al documento como a la hoja en sí) descriptivo.
- Ir a Herramientas > Editor de secuencias de comandos, e introducir el código que se adjunta:
// 2017 by Daniel Eichhorn, https://blog.squix.org
// Inspired by https://gist.github.com/bmcbride/7069aebd643944c9ee8b
// Create or open an existing Sheet and click Tools > Script editor and enter the code below
// 1. Enter sheet name where data is to be written below
var SHEET_NAME = "Sheet1";
// 2. Run > setup
// 3. Publish > Deploy as web app
// - enter Project Version name and click 'Save New Version'
// - set security level and enable service (most likely execute as 'me' and access 'anyone, even anonymously)
// 4. Copy the 'Current web app URL' and post this in your form/script action
var SCRIPT_PROP = PropertiesService.getScriptProperties(); // new property service
// If you don't want to expose either GET or POST methods you can comment out the appropriate function
function doGet(e){
return handleResponse(e);
}
function doPost(e){
return handleResponse(e);
}
function handleResponse(e) {
var lock = LockService.getPublicLock();
lock.waitLock(30000); // wait 30 seconds before conceding defeat.
try {
// next set where we write the data - you could write to multiple/alternate destinations
var doc = SpreadsheetApp.openById(SCRIPT_PROP.getProperty("key"));
var sheet = doc.getSheetByName(SHEET_NAME);
// we'll assume header is in row 1 but you can override with header_row in GET/POST data
//var headers = sheet.getRange(1, 1, 1, sheet.getLastColumn()).getValues()[0];
var nextRow = sheet.getLastRow()+1; // get next row
var row = [];
var headerRow = [];
// loop through the header columns
var jsonData = JSON.parse(e.postData.contents);
headerRow.push("jsonData.app_id");
headerRow.push("jsonData.dev_id");
headerRow.push("jsonData.hardware_serial");
headerRow.push("jsonData.port");
headerRow.push("jsonData.counter");
headerRow.push("jsonData.payload_raw");
headerRow.push("jsonData.payload_decoded");
headerRow.push("jsonData.metadata.time");
headerRow.push("jsonData.metadata.frequency");
headerRow.push("jsonData.metadata.modulation");
headerRow.push("jsonData.metadata.data_rate");
headerRow.push("jsonData.metadata.coding_rate");
headerRow.push("jsonData.metadata.downlink_url");
for (var i = 0; i < jsonData.metadata.gateways.length; i++) {
var gateway = jsonData.metadata.gateways[i];
headerRow.push("gateway.gtw_id");
headerRow.push("gateway.timestamp");
headerRow.push("gateway.channel");
headerRow.push("gateway.rssi");
headerRow.push("gateway.snr");
headerRow.push("gateway.latitude");
headerRow.push("gateway.longitude");
headerRow.push("gateway.altitude");
}
sheet.getRange(1, 1, 1, headerRow.length).setValues([headerRow]);
row.push(jsonData.app_id);
row.push(jsonData.dev_id);
row.push(jsonData.hardware_serial);
row.push(jsonData.port);
row.push(jsonData.counter);
row.push(jsonData.payload_raw);
var raw = Utilities.base64Decode(jsonData.payload_raw);
var decoded = Utilities.newBlob(raw).getDataAsString();
row.push(decoded);
row.push(jsonData.metadata.time);
row.push(jsonData.metadata.frequency);
row.push(jsonData.metadata.modulation);
row.push(jsonData.metadata.data_rate);
row.push(jsonData.metadata.coding_rate);
row.push(jsonData.metadata.downlink_url);
for (var i = 0; i < jsonData.metadata.gateways.length; i++) {
var gateway = jsonData.metadata.gateways[i];
row.push(gateway.gtw_id);
row.push(gateway.timestamp);
row.push(gateway.channel);
row.push(gateway.rssi);
row.push(gateway.snr);
row.push(gateway.latitude);
row.push(gateway.longitude);
row.push(gateway.altitude);
}
// more efficient to set values as [][] array than individually
sheet.getRange(nextRow, 1, 1, row.length).setValues([row]);
// return json success results
return ContentService
.createTextOutput(JSON.stringify({"result":"success", "row": nextRow}))
.setMimeType(ContentService.MimeType.JSON);
} catch(e) {
// if error return this
return ContentService
.createTextOutput(JSON.stringify({"result":"error", "error": e}))
.setMimeType(ContentService.MimeType.JSON);
} finally { //release lock
lock.releaseLock();
}
}
function setup() {
var doc = SpreadsheetApp.getActiveSpreadsheet();
SCRIPT_PROP.setProperty("key", doc.getId());
}
- Ejecutar la función "setup" mediante Ejecutar > Ejecutar función > Setup. Indicar los permisos adecuados para acceder a la hoja de cálculo creada anteriormente.
- Publicar el script mediante Publicar > Implementar como aplicación web. Crear un nombre de versión descriptivo, indicar que el nivel de seguridad para ejecutar la aplicación será "Yo", e indicar que el acceso a la aplicación será para "Cualquiera, incluso anónimo" (a esto me refería con la seguridad de la información más arriba).
- Copiar la URL de la aplicación web que nos genera.
- Posteriormente, en la consola de TTN, será necesario añadir a nuestra aplicación una integración de tipo HTTP, creando un Process ID significativo, indicar la Access Key como "default", añadiendo la URL que hemos copiado anteriormente, e indicándo que el método HTTP a utilizar será "POST".
Y con esto, la información generada por nuestros dispositivos LoRaWAN registrados en TTN pasará a almacenarse de manera automática en nuestra hoja de cálculo:
Datos LoRaWAN en Google Spreadsheet
Etiquetas: google spreadsheet, lorawan, the things network
30 sep 20 Un gateway LoRaWAN de un canal. Trasteando con el protocolo
Comentaba en un artículo anterior de la serie que había implementado un gateway LoRa*. Y no me faltaba razón. Estaba haciendo uso del protocolo LoRa de enlace basado en 868 MHz para enviar señales de entre un nodo emisor y un receptor, y de este último a un servidor MQTT. ¿Cuál es la diferencia? La más importante es que no estaba realizando ningún tipo de verificación de nodos, sin ni siquiera molestarme en verificar cuál es el emisor y cuál el receptor. Y ni hablemos de cifrado de comunicaciones ni nada que se le parezca. Pero para las pruebas preliminares que venía efectuando, en lo que el aspecto importante era verificar alcance entre nodos, sobraba y bastaba. Por cierto, para ver más detalles de las diferencias entre LoRa y LoRaWAN, tengo otro artículo dedicado a tal efecto.
Pero para este proyecto necesitaba dar un paso más allá, e implementar un verdadero gateway LoRaWAN. Y eso implicaba hacer uso de una red LoRaWAN, que proporcione su servidor de procesado de tráfico de red, y te permita explotar los datos enviados desde los dispositivos. Cuando te enfrentas a esto, tienes dos posibilidades: o te implementas la red, o te conectas a una ya existente. Sobre la primera opción ya hablaremos más adelante, en un artículo al respecto, pero para salir rápidamente del paso hice uso de la segunda. Existe una red pública a la que puedes conectar gateways y dispositivos LoRaWAN, que es la red The Things Network, o TTN. Cuando te registras como usuario, puedes añadir a la red tanto dispositivos como gateways. Si haces lo primero, dependes de que haya algún gateway cercano a ti para que tus dispositivos envíen datos a la red. Pero si no tienes ningún gateway a tu alcance, no te queda otra que implementar un gateway, y conectarlo a la red. Que es precisamente de lo que va esta serie.
Tengo que decir algo desde un principio: estoy haciendo trampas. Una de las especificaciones del protocolo LoRaWAN es que a la hora de establecer un enlace entre dispositivo y gateway se puede utilizar de manera aleatoria cualquier canal de la banda que estés utilizando. En el caso de Europa, la banda es la de 868 MHz, y existen 9 canales dedicados a tal efecto (aunque en realidad son 8+1). La razón para ello es evitar la congestión en cualquiera de los canales, siendo la red la encargada de analizar esta circunstancia, y la responsable de tomar las medidas necesarias (cambio de canal) para solucionarlo. Para ello, la idea es que cuando se configura un nuevo gateway, tu hardware tiene que estar preparado para operar en estos canales. El problema, en mi caso, es que el hardware del que dispongo sólo es capaz de funcionar en un solo canal. ¿Y cuál es este hardware? Nuestro viejo amigo el Heltec LoRa 32.
Tras trastear un poco por Internet, encontré un proyecto bastante interesante de Things4U que consiste exactamente en eso: implementar un gateway de un solo canal. Por supuesto, es un proyecto experimental que no debe usarse en un sistema en producción, pero para mis propósitos de investigación basta y sobra. La instalación es bastante sencilla: tan simple como descargar el código (viene con todas sus librerías), y en el caso de Arduino, hacer lo siguiente:
- Crear un proyecto, y copiar al mismo el contenido del directorio ESP-sc-gway. Por otro lado, copiar el contenido del directorio lib en el directorio libraries de tu instalación de Arduino.
- Por otro lado, editar el contenido de los ficheros configGway.h y configNode.h, que permiten establecer los parámetros de red WiFi a la que conectarse, modelo de dispositivo utilizado (Heltec, en mi caso), banda a utilizar (868), y algunos elementos adicionales como a qué nodo de la red TTN conectarse.
- Compilar y listo. El dispositivo levanta una interfaz web que permite verificar el funcionamiento del mismo y cambiar algunos parámetros en tiempo de ejecución, y muestra información del comportamiento del dispositivo en la pantalla de cristal líquido.
Captura de pantalla de la web de administración del gateway
Si todo ha ido bien, tu gateway se conectará a la red TTN (donde es preciso configurar tu gateway, aunque por lo que he visto no parece interactuar demasiado bien con la información de estado del mismo), y es cuestión de encender un dispositivo, empezar a emitir, y ver entrar los paquetes en tu aplicación:
…sí claro. Ojalá. 
Y es que hay un pequeño problema. Con esto hemos configurado nuestro gateway para que trabaje en un solo canal, pero por defecto nuestro dispositivo trabajará en cualquier canal de la banda, de manera aleatoria. Y esto implica que sólo vamos a recibir, estadísticamente hablando, 1 de cada 9 paquetes enviados. Una tasa bastante baja. ¿Cuál es la solución? Obviamente, forzar al dispositivo a emitir en una sola banda. Existe un tutorial de Sparkfun que lo explica bastante bien, pero para el caso de los dispositivos Heltec LoRa es necesario trastear un poco más, y especificar los valores del dispositivo:
const lmic_pinmap lmic_pins = {
.nss = 18,
.rxtx = LMIC_UNUSED_PIN,
.rst = 14,
.dio = {26, 35, 33},
};
…y con eso, ¡listos! Bueno, casi. Para los Heltec LoRa 32 vale, pero por desgracia no para los Cube Cell que estoy empleando, ya que las implementaciones de la librería LMIC que he encontrado no parecen funcionar bien con estos dispositivos. ¿La solución? Ser un poco más imaginativo. En mi caso, he modificado los parámetros de la librería LoRaWan_APP del fabricante, para hacer que todas las definiciones de la banda de 868 MHz trabajen exactamente en la frecuencia del canal 0, que es que se utiliza por parte del servidor. En concreto, se trata de localizar el fichero RegionEU868.h (en el directorio packages\CubeCell\hardware\CubeCell\1.x.0\cores\asr650x\loramac\mac\region), y modificar lo siguiente:
#define EU868_LC1 { 868100000, 0, { ( ( DR_5 < < 4 ) | DR_0 ) }, 1 }
/*!
* LoRaMac default channel 2
* Channel = { Frequency [Hz], RX1 Frequency [Hz], { ( ( DrMax << 4 ) | DrMin ) }, Band }
*/
#define EU868_LC2 { 868100000, 0, { ( ( DR_5 < < 4 ) | DR_0 ) }, 1 }
/*!
* LoRaMac default channel 3
* Channel = { Frequency [Hz], RX1 Frequency [Hz], { ( ( DrMax << 4 ) | DrMin ) }, Band }
*/
#define EU868_LC3 {868100000, 0, { ( ( DR_5 < < 4 ) | DR_0 ) }, 1 }
#define EU868_LC4 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC5 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC6 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC7 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
#define EU868_LC8 { 868100000,0, { ( ( DR_5 < < 4 ) | EU868_TX_MIN_DATARATE ) }, 0 }
Sí, es una ñapa. Pero una ñapa que funciona. Una vez hecho esto y subido el código al Cube Cell, todo va como la seda. Y aprovechando que me encontraba en Córdoba, me decidí a hacer algunas pruebas adicionales de transmisión de datos: un verdadero (bueno, de aquella manera) gateway LoRaWAN conectado a la red TTN, y un dispositivo emitiendo de manera periódica una información sencilla (00 01 02 03). La idea era probar la transmisión en un entorno urbano, con orografía acusada, y sin visibilidad directa, y con el emisor haciendo uso de las antenas por defecto que proporciona el fabricante. Nada de antenas avanzadas. Y el resultado fue bastante mejor del esperado. EL sistema pudo cubrir sin interrupciones todo el parque de la Asomadilla con un único gateway, incluso en zonas donde la curvatura del terreno oculta de manera total el emisor del receptor.
Emisor en el punto más alejado del parque
Como comentaba, el sistema fue capaz de proporcionar cobertura en todo el Parque de la Asomadilla de Córdoba.
Imagen de la zona cubierta
Es de esperar que en una zona con una ubicación óptima (zona alta del parque) la zona de cobertura fuera muy superior. Pero eso ya quedará para otro día.
Etiquetas: 868 MHz, arduino, cubecell, heltec, lora, lorawan, the things network, ttn
19 sep 20 Los nodos LoRaWAN. Hardware y software
Para este proyecto estoy utilizando como nodos LoRaWAN unos dispositivos CubeCell de Heltec. En concreto estoy haciendo uso de las Dev-Board (HTCC-AB01), que integran el patillaje necesario para conectar de manera sencilla los CubeCell a un ordenador para cargarles el código necesario.
Estos dispositivos hacen uso de un chiop ASR6501, que integra una MCU PSoC de la serie 4000 (ARM® Cortex® M0+ Core), y el chip LoRA SX1272. La principal ventaja es que son completamente compatibles con Arduino, tienen capacidad para ser alimentados directamente por batería o un pequeño panel solar (desde 5.5 a 7v), y un consumo realmente bajo: 10 mA en modo recepción LoRa, 70 mA emitiendo a 10 dB, y apenas 3.5uA en modo Deep Sleep, lo que los hacen muy adecuados para entornos de muy bajo consumo energético. Además dispone de 8 puertos de E/S, UART, SPI e I2C, además de otras características bastante interesantes.
Sin embargo, y a pesar de que los dispositivos están bastante bien, tienen agún inconveniente con respecto a los Heltec LoRa 32. Los más importantes es que carecen de interfaz WiFi y de Bluetooth. No es demasiado grave, ya que no están pensados para ser dispositivos multiconexión -para eso están los LoRa 32 con su chip ESP32-, sino para priorizar el bajo consumo.
En cuanto a la programación, se puede realizar mediante el IDE de Arduino, como cualquier otro dispositivo. Hay que tener en cuenta, que su programación difiere ligeramente con respecto a los Heltec LoRa 32. Esto tiene un par de implicaciones: la primera es que no se hace uso de la librería Heltec, sino que se utiliza una librería específica (LoRaWan_APP), que la declaración del objeto LoRa es distinta, siendo necesario especificar manualmente determinados parámetros que en el caso de la librería Heltec ya vienen dados muchas veces por defecto, y que sólo es necesario declarar en caso de querer utilizar valores distintos.
#define RF_FREQUENCY 868000000 // Hz
#define TX_OUTPUT_POWER 14 // dBm
#define LORA_BANDWIDTH 0 // [0: 125 kHz,
// 1: 250 kHz,
// 2: 500 kHz,
// 3: Reserved]
#define LORA_SPREADING_FACTOR 8 // [SF7..SF12]
#define LORA_CODINGRATE 4 // [1: 4/5,
// 2: 4/6,
// 3: 4/7,
// 4: 4/8]
#define LORA_PREAMBLE_LENGTH 8 // Same for Tx and Rx
#define LORA_SYMBOL_TIMEOUT 0 // Symbols
#define LORA_FIX_LENGTH_PAYLOAD_ON false
#define LORA_IQ_INVERSION_ON false
#define RX_TIMEOUT_VALUE 1000
#define BUFFER_SIZE 30 // Define the payload size here
La segunda diferencia, como comentaba en el artículo anterior, es que es necesario definir también ciertas configuraciones específicas, precisamente relacionadas con estos parámetros, en la parte del gateway, para garantizar la compatibilidad de las comunicaciones entre ambos dispositivos. No es que haya sido un gran problema, pero me trajo un rato de cabeza hasta que encontré algo de documentación que me hizo la luz a este respecto.
Hay otros dos aspectos finales que quería comentar, también relativos al hardware:
- El primero es la existencia de un led multicolor que se puede controlar por la librería. Por lo general, se utiliza para distinguir cuándo el dispositivo está enviando o recibiendo paquetes LoRa. Por convenio se utiliza el color rojo para indicar envío, y el verde para recepción, pero esto es completamente configurable. Y muy práctico en el caso de andar enviando datos entre dos CubeCell.
- El segundo es la antena: el dispositivo viene con una pequeña antena que se conecta mediante un pigtail, pero en mi caso voy a reemplazarla por antenas un poco más elaboradas, para asegurar un mejor enlace.
Etiquetas: antena, arduino, cubecell, esp32, heltec, lora, lorawan
Medidor de entropía
