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
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
20 sep 20 Antenas de 868 MHz. Aspectos teóricos de transmisión y variedades a mi disposición
Uno de los elementos más importantes del proyecto de gateway LoRaWAN es la antena. En realidad, las antenas, ya que tenemos que tener en cuenta que vamos a tener dos: una de recepción y otra de emisión. En la práctica la afectación que vamos a tener en la calidad de la señal recibida es la misma por la parte emisora y la parte receptora, así que iré al grano en lo que se refiere a la descripción de las mismas. En un artículo anterior sobre LoRa hablé ya algo sobre la importancia de una buena antena, su ubicación, y sus características deseables. No hay nada nuevo en este artículo con respecto a lo comentado en su momento, que me permito recuperar:
- La ubicación de la antena importa. Mucho. Es extraordinariamente importante que las antenas, tanto de emisor como receptor, estén verticales. Solamente este factor es de una importancia enorme para lograr una buena transmisión de la señal entre dispositivos. Pero no es el único. La frecuencia de 433 MHz no se lleva especialmente bien con paredes de hormigón forjado, ni con mallazo metálico. Si puedes poner la antena en espacio abierto, mejor que mejor.
- Haz uso de una buena antena. Las que vienen con los dispositivos son extremadamente básicas. Hacen bien su función a distancias relativamente cortas, pero cuando intentas subir de nivel, la cosa cambia. Tanto es así, que el fabricante de los dispositivos da un rango de alcance de sus dispositivos de 2.8 km, frente a las decenas que soporta el protocolo. Sigue estando bastante bien para unos dispositivos que no llegan a los 20€ de precio, pero cuando intentas ir un poco más allá, es preciso invertir un poco más.
- El tipo de antena importa. Esto es de cajón. Podemos distinguir -de manera muy general- entre antenas omnidireccionales y antenas directivas. La diferencia entre una y otra es la siguiente: mientras que las omnidireccionales emite (o reciben) de cualquier dirección, las directivas enfocan su capacidad hacia una zona concreta, por lo que el alcance obtenido es mucho mayor, a costa de sacrificar versatilidad, ya que las antenas tienen que estar enfocadas hacia la dirección concreta en la que se trate de establecer el enlace. En mi caso, en todo momento estoy tratanto de antenas omnidireccionales, ya que pretendo hacer un uso lo más amplio posible del gateway, sin restringirme a una localización en concreto para el enlace.
¿Y cuál es la importancia de la antena en todo esto? Se puede entender muy bien en la imagen de más arriba. Para una descripción más detallada me remito a la página de la red LoRa relativa a las características físicas del enlace, pero ofreceré aquí un pequeño resumen: a la hora de medir la calidad, tenemos que tener en cuenta un parámetro ques el RSSI. Se puede definir en pocas palabras como el indicador de la fuerza de la señal recibida por un dispositivo, y está íntimamente relacionado con la sensibilidad del dispositivo en cuestión. Siempre se expresa en números negativos. Un RSSI de -1 dBm es una señal poco menos que perfecta, y en el caso de los dispositivos Heltec, éstos pueden captar con una calidad aceptable señales con un RSSI de -131 dBm. ¿Y cómo se calcula el RSSI? Es una fórmula resultado de sumar y restar los siguientes parámetros:
- Potencia de emisión por parte del emisor. Se mide en dBm y, en el caso de los Heltec, puede estar en un máximo de 20 dBm, siendo regulable en tramos. Obviamente, a más potencia de emisión, más alcance tendremos, pero también tendremos un mayor gasto energético.
- Pérdida del cable a la antena por parte del emisor. El cable que conecta el emisor a la antena provocará una pérdida, que será mayor o menor en función del grosor del cable y la longitud del mismo. Por eso es conveniente hacer uso de los cables más cortos posibles. En el caso del emisor, por razones de economía de espacio y materiales, suelen emplearse cables cortos y finos. Este parámetro se mide en dB.
- Ganancia de la antena en el caso del emisor. Cómo de buena es la antena a la hora de transmitir la señal. Una antena doméstica puede andar entre los 2 y los 10 dBi, pero es cuestión de invertir dinero para lograr mejores antenas.
- Pérdida por transmisión aérea (Free space losses). El hecho de viajar por el aire hace que la señal tenga pérdidas. Sin embargo, esta pérdida no es lineal, sino que va en función del logaritmo de la distancia y de la frecuencia de emisión, en base a la siguiente fórmula: L(fs) = 32,45 + 20*log(D) + 20*log(f), expresándose L(fs) en dB, D en km, y f en MHz. Como se puede apreciar, la mayor parte de la pérdida se produce por el mero hecho de poner la señal en el aire, atenuándose mucho la pérdida a medida que aumentan los kilómetros de distancia.
- Ganancia de la antena en el caso del receptor. Al igual que en el caso del emisor, cómo de buena es la antena a la hora de recibir la señal. Aparte de la señal en sí, importa mucho la ubicación, a ser posible en alto y sin obstáculos, a fin de mantener la zona fresnel lo más limpia posible.
- Pérdida del cable a la antena por parte del receptor. Igual que en el caso del emisor. El cable que conecta el emisor a la antena provocará una pérdida, que será mayor o menor en función del grosor del cable y la longitud del mismo. Por eso es conveniente hacer uso de los cables más cortos posibles. En el caso del receptor, por lo general se pueden hacer uso de cables más gruesos, pero por razones de ubicación suelen ser considerablemente más largos (varios metros) que en el caso del emisor. Este parámetro se mide en dB.
Llegados a este punto, y mediante sumas y restas sencillas, tenemos el RSSI en base a los parámetros anteriores. El último detalle a considerar es si nuestro RSSI es mayor o menor que la sensibilidad del receptor. Esto nos dirá si la señal que ha llegado al dispositivo puede ser interpretada por éste o no. En mis pruebas, con un RSSI de -131 dBm la señal es captada sin demasiados problemas por el receptor. A partir de ahí, se empiezan a experimentar pérdidas de datos.
En cuanto a las antenas que tengo para este proyecto, dispongo de los siguientes tipos (de izquierda a derecha en la imagen superior):
- Antena CubeCell: Es la antena que venía con el CubeCell. Como todas las de este artículo, es omnidireccional. No he encontrado información de la ganancia de la misma, pero debe de estar en torno a los 2 dBi. Se conecta al dispositivo directamente.
- Antena Heltec LoRa 32: Es la antena que venía con el Heltec LoRa 32. Tampoco tengo información del fabricante. La construcción es algo mejor, pero sospecho que debe de andar igualmente por los 2 dBi. En este caso, viene con conector SMA, y se conecta a la placa con un pigtail de unos 5 cm.
- Antena 5 dBi: Comprada en Aliexpress, declara 5 dBi. 30,1cm de longitud, viene equipada con base magnética, cable de 3m y un conector de tipo SMA. Necesita de un pigtail para conectarla a los dispositivos.
- Eightwood 868MHz: Adquirida en Amazon, declara 5 dBi. 30,1cm de longitud, viene equipada con un cable de 3m, la antena usa un conector de tipo TNC y el cable SMA, y dispone de base atornillable a una pared. Necesita de un pigtail para conectarla a los dispositivos.
- Antena 6 dBi: Comprada en Aliexpress, declara 6 dBi. 36cm de longitud, viene equipada con base magnética, cable de 2m y un conector de tipo SMA. Necesita de un pigtail para conectarla a los dispositivos.
En mi caso, he escogido como ubicación de la antena el punto más alto de la casa: la parte superior de la chimenea de ventilación de los cuartos de baño. He fijado en ella una pequeña placa metálica donde colocaré la antena, haciendo uso de su base magnética. Realizaré pruebas con las diversas antenas, para evaluar la eficiencia de las mismas, pero en principio, la antena a utilizar sería la de 6 dBi, ya que tiene la mejor calidad teórica, y hace uso del cable más corto.
Etiquetas: antena, cubecell, db, dbi, dbm, heltec, lora, rssi, sma, tma
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
