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
19 sep 20 El gateway LoRa*. Hardware y software
Seguimos haciendo progresos con mi gateway LoRaWAN. En este caso, en el ámbito del gateway en sí. El lector avispado habrá notado que he encabezado este artículo con Lora* en vez de con LoRaWAN. Y es que en este punto lo que tengo implementado es más bien un gateway LoRa que actúa de pasarela a un servidor MQTT, y no un gateway LoRaWAN propiamente dicho. ¿Cuál es la diferencia? Es sutil, pero importante. A estas alturas lo que he implementado es un gateway, sí, entre dispositivos, y terceros servidores, pero no realizo aún control de acceso, identificadores de equipos en la red, ni nada por el estilo. Así que no puedo -en realidad- considerarlo un gateway LoRaWAN completo. Pero de momento, para el propósito que manejo, basta y sobra.
Ya he hablado con anterioridad del dispositivo que estoy utilizando para construir el gateway: se trata de una placa Heltec Lora 32, que proporciona capacidad de conexión LoRa, WiFi y Bluetooth, incluyendo la variante Low Energy. Con anterioridad he estado haciendo pruebas con la variante de 433 MHz, pero para este proyecto en cuestión he optado por respetar la normativa radioeléctrica europea, y desplegarlo con la variante de 868 MHz, de la que disponía de un dispositivo que hasta ahora no había hecho un gran uso (en parte porque vino con la pantalla OLED quebrada, y ésta funciona bastante mal). Otro elemento de la configuración es la antena de recepción y el adaptador eléctrico, pero estos elementos quedarán para otro artículo.
En lo referente al software, he desarrollado un software con las siguientes características:
- La base del sistema son las librerías de Heltec que permiten implementar comunicaciones LoRa. Los aspectos principales de la configuración ha sido establecer los parámetros de conexión adecuados para comunicarse adecuadamente con los dispositivos cliente, en este caso unos Heltec CubeCell. En concreto, los siguientes aspectos son los que hay que configurar:
LoRa.setSpreadingFactor(8);
LoRa.setSignalBandwidth(125E3);
LoRa.setCodingRate4(4);
LoRa.setPreambleLength(8);
LoRa.setSyncWord(0×12); - El siguiente punto de importancia es la implementación de un sistema de configuración de la conexión del cliente WiFi mediante un AP provisional: IotWebConf. Con esta librería, válida para dispositivos ESP8266 y ESP32, se puede levantar un portal web y un AP para realizar la configuración de la WiFi en el dispositivo. La idea es sencilla: cuando el dispositivo no tiene configurada una conexión WiFi, levanta un punto de acceso con un portal web de configuración, al que se puede conectar para establecer los parámetros de la WiFi (así como otro tipo de parámetros configurables, como el servidor MQTT, por ejemplo). Una vez establecidos, el sistema almacena estos parámetros en la EEPROM de la placa, reinicia, y conecta a la WiFi proporcionada. También permite introducir una nueva configuración WiFi en caso de que se mueva el dispositivo a una ubicación en la que la WiFi configurada no tenga alcance. La principal ventaja es que no hay que preconfigurar en código los parámetros de conexión, pudiendo hacerlo en tiempo de ejecución. A continuación se puede ver una captura de la interfaz web que se levanta:
- Otro aspecto adicional de esta librería es que permite realizar la actualización de firmware On-The-Air: la interfaz web proporciona una vía para cargar el software precompilado de Arduino en la placa, sin tener que conectar la misma a un PC mediante cable, además de incluir un sistema de seguimiento de versiones de firmware. Sumamente útil, teniendo en cuenta que el gateway va a estar ubicado, en mi caso, en lo alto del tejado.
- Por último, he realizado algunos ajustes adicionales en optimización de la transmisión de datos entre dispositivo y gateway. La principal (en el caso de transmisión de valores numéricos) es la utilización de codificación hexadecimal, para transmitir menos bytes y optimizar el tiempo de vuelo de los datos.
En cuanto a la recepción de datos, ha sido sumamente exitosa. En el código de ejemplo utilizado en el cliente, se envía una trama compuesta de dos valores en hexadecimal, que son inyectados en un topic MQTT, junto con el valor del RSSI de la transmisión, a fin de controlar la calidad de la misma. El servidor MQTT se encuentra completamente ajeno al sistema, siendo un servidor multifunción que utilizo para diversos proyectos.
El resultado es, hasta ahora, bastante bueno. En próximos capítulos hablaré de otros elementos del sistema.
Etiquetas: arduino, cubecell, firmware, fota, gateway, heltec, lora, lorawan, mqtt, on-the-air
Medidor de entropía
