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
14 may 20 Más allá de LoRa: LoRaWan
Llevo ya un par de artículos sobre las pruebas que he estado efectuando con enlaces soportados con tecnología LoRa, y no podía postergar más el hablar sobre una tecnología que va un paso más alla: LoRaWan. LoRaWan, en líneas generales, es un protocolo de comunicaciones que, haciendo uso de tecnología LoRa, permite proporcionar conectividad a múltiples dispositivos que se basan en LoRa. La idea básica es que LoRa proporciona los enlaces punto a punto, mientras que LoRaWan proporciona una red de comunicaciones. Para ello se apoya en la definición de dos tipos de dispositivos, los nodos y los gateways. Los primeros son los dispositivos individuales -por lo general IoT- que actúan como clientes, enviado y recibiendo información de la red. Los segundos, por su lado, conforman la infraestructura que enlaza los clientes individuales con el resto del sistema, actuando como pasarela con redes convencionales como puede ser Internet.
Estructura de una red LoRaWan
En toda esta introducción la palabra importante es red. Mientras que en mis pruebas anteriores hacía uso de un par de dispositivos enlazados, aquí se trata de dar un paso más allá. ¿Y cómo haces uso de una red? Bueno, hay dos maneras: o la construyes, o usas una ya existente. La primera opción es viable en el caso de querer construir una red privada, para algún cliente o un proyecto concreto, pero en la mayoría de los casos no es un escenario realista. Pero en cuanto a la segunda, es esta la parte realmente interesante de los sistemas LoRaWan. Existen redes, tanto públicas como privadas, a las que es posible conectarse y hacer uso de las mismas. Y una de las redes abiertas más conocidas a nivel mundial es The Things Network, también conocida como TTN.
Cuando, de nuevo hace ya un par de años largos, adquirí mis dispositivos LoRa, cometí un error de novato. Pedí un dispositivo de 868 MHz y otro de 433. Algo que hacía perfectamente inútiles los intentos de comunicación entre ellos. Esa fue la razón para adquirir un segundo dispositivo de 433 MHz para mis pruebas de enlace punto a punto. ¿Pero qué hacer con el kit de 868 MHz? Podía comprar un segundo y hacer lo mismo, pero fue entonces cuando tuve noticias de TTN. Una red LoRaWan que permite el acceso gratuito a la misma para la transmisión y recepción de mensajes (aunque con límites de capacidad -fair use-), pero que para una transmisión de pruebas de un sistema IoT era más que sobrado. La pregunta es: ¿existía un despliegue de esa red en Sevilla? Y la respuesta es que sí.
TTN – Cobertura en Sevilla
Como se puede ver en el mapa de gateways, hay un buen nivel de cobertura de la red TTN en Sevilla capital y el Aljarafe… salvo en Santiponce. En efecto, hice algunas pruebas en casa, con resultados completamente infructuosos. Pero en la Isla de La Cartuja, donde está mi oficina, había cobertura teórica, y dos gateways en las inmediaciones, a unos 1500 y 1700 metros de distancia. Cerca del límite teórico del alcance de los Heltec, y más dentro de un edificio. Pero era cuestión de hacer la prueba. Así que aprovechando un día, al comienzo del confinamiento, en que tuve que desplazarme a la oficina por razones de continuidad de negocio, aproveché para hacer algunas pruebas de conexión.
Dispositivo LoRa Heltec ESP32 a 868 MHz
Para ello hice uso de una librería específica que Heltec ha desarrollado para las conexiones LoraWan, además de registrar -paso obligado- mi dispositivo para obtener una licencia de uso de Heltec. Además de esto, es necesario registrarse en TTN y configurar una aplicación para poder hacer uso de la red, además de registrar tu dispositivo a fin de obtener una serie de identificadores únicos para los dispositivos que se habrán de conectar a la red. Se pueden seguir los pasos en el siguiente artículo: Heltec ESP32 Board + The Things Network. Y tras algunas pruebas, ajustes y apretar -metafórico- de tuercas…
Datos enviados a TTN
…conseguí establecer de manera exitosa sendos enlaces con dos de los gateways cercanos a la Isla de La Cartuja. En concreto, a los ubicados en la Alameda de Hércules y la Plaza de la Encarnación, con una distancia máxima de algo más de 1700 metros desde mi ubicación, como se puede apreciar en la siguiente imagen:
Alcance de enlaces LoRaWan realizados
La prueba no dio para mucho más, ya que tenía otros menesteres de los que ocuparme en la oficina, pero sirvió para demostrar que era posible trabajar con TTN y dispositivos Heltec, incluso haciendo uso de la antena de fábrica en condiciones adversas. En fechas posteriores, visto el éxito de la prueba en la oficina, realicé algunas nuevas pruebas de larga distancia desde Santiponce, tanto con antenas de fabricación propia (hasta la base está sacada con la impresora 3D)…
Antena de fabricación propia de 868 MHz
…como con antenas fabricadas por terceros:
Antena de 868 MHz
En ninguno de los casos logré un enlace con ninguna de las redes de TTN en Sevilla o el Aljarafe. No es sorprendente, ya que la más cercana se encuentra a 7 km. de distancia de mi domicilio, y obstaculizadas por la orografía del terreno, y edificios que se interponen en la línea de visión directa. Además, en todos los casos he usado antenas omnidireccionales. Queda por realizar una prueba con antenas direccionales (estoy pensando en una tipo yagi), pero antes de eso, aún tengo que hacer pruebas con línea directa de visión y las antenas de las que actualmente dispongo. El lugar perfecto es el cerro de Santa Brígida, en Camas. Estoy deseando que podamos realizar más deplazamientos para acercarme con la bici y hacer estas pruebas.
Etiquetas: 868 MHz, esp32, heltec, impresora 3d, lora, lorawan, santiponce, sevilla, the things network, ttn, yagi
Medidor de entropía
