01 sep 20 Gateway LoRaWAN: Introducción
Durante los últimos meses he estado haciendo algunos pinitos con la tecnología LoRa, como he ido relatando en este sitio. Me lo he pasado bastante bien trabajando con esta tecnología, y sobre todo, he disfrutado enormemente haciendo algunas pruebas de campo. Es por ello que he decidido dar un paso más en la secuencia, y estoy decidido a implantar un gateway LoRaWAN en casa, a fin de poder realizar estos experimentos de una manera más consolidada. Sin embargo, esta idea de implementar el gateway LoRaWAN no se queda sólo en la realización técnica del dispositivo, sino que tiene una serie de derivadas, que me permitirán explorar otras líneas tecnológicas en las que llevo tiempo pensando y -en algunos casos- años interesado.
Por ello, he decidido crear una nueva serie en esta bitácora, dedicada específicamente a la planificación, diseño, implementación y pruebas de mi gateway LoRaWAN. Sirva este breve artículo como introducción.
01 sep 20 Gateway LoRaWAN: Alimentación eléctrica
Una de las primeras cosas que tuve clara cuando me decidí a instalar un gateway LoRaWAN en casa es que el proyecto tendría que estar sostenido por energías renovables. Mi intención es colocar la antena del dispositivo en el punto más alto de la casa, en la chimenea de evacuación de gases de los cuartos de baño, y eso implica que esa ubicación no dispone de toma eléctrica. Sería posible hacer uno de un cable largo para llevar la conexión de la antena a un punto donde disponga de alimentación eléctrica, o bien sacar una derivación de la alimentación del aire acondicionado que tengo en la buhardilla. Pero seamos sinceros: no es tan interesante como plantearse un sistema de alimentación renovable (y en el primer caso, nos enfrentamos a una más que posible caída de la eficiencia de la antena, por el solo hecho de utilizar un cable más largo del estrictamente necesario). Y en este caso, el sistema elegido ha sido la energía solar.
No es este -bien lo sabrá quien me haya seguido a lo largo de los años- un proyecto estrictamente nuevo para mí. Hace ya años que tuve la idea de montar un aerogenerador en el tejado, con el que estuve haciendo una serie de pinitos en casa. Pero la verdad sea dicha, no fueron unas pruebas demasiado exitosas. Tuve durante un tiempo la iluminación de la casa alimentada por energía eólica, apoyada por un panel solar, pero fue un intento demasiado prematuro: la iluminación que teníamos por aquel entonces era principalmente de lámparas electrónicas, y en la práctica la cantidad de aire en Santiponce no bastaba para generar la energía suficiente como para que el aerogenerador produjera la corriente necesaria. Aquel proyecto quedó abandonado cuando nos fuimos a Irlanda, pero me dejó algunos componentes que he podido reaprovechar.
El principal es un panel solar de 100W que adquirí como sistema de apoyo para el aerogenerador. Éste sí que funcionaba espectacularmente bien. Incluso tuve durante un tiempo conectado un portátil al sistema de baterías que utilizaba, haciendo uso de un inversor. Pero en la práctica, el sistema tenía bastantes ineficiencias, y el portátil apenas aguantaba unas cuantas horas encendido antes de drenar completamente la batería. En su momento, para colocarlo en el tejado, me hice construir un bastidor metálico que anclé al lateral del tejado. En su día desmantelé el panel y lo guardé en Córdoba, pero el bastidor se quedó colocado (estaba fijado con pernos y tacos químicos, como para quitarlo de ahí), y allí estuvo durmiendo el sueño de los justos. Pero lo he traído de vuelta para este proyecto. Ha sido toda una sorpresa ver el bastidor, que seguía en perfectas condiciones en el tejado.
El segundo elemento, cómo no, ha sido el controlador de carga y la batería. El controlador es el proveniente de mi instalación eólica. En su momento adquirí un controlador dual, capaz de gestionar la carga proveniente de un aerogenerador trifásico en alterna y de un panel solar de 12 voltios en continua. Como es obvio, no estoy haciendo -ni lo voy a hacer- uso del aerogenerador, pero sí de la parte solar. Tras 5 años desconectado, tenía mis dudas de si seguiría funcionando. Pero lo hace, y perfectamente.
Por último, la batería: es una batería convencional de coche, de 12 voltios, proveniente de mi añorado Alfa 33. Estaba nueva cuando el coche se vendió en 2017, y estaba igualmente criando polvo en Córdoba. Ha sido necesario someterla a un ciclo de carga, pero de momento parece que está bien. He colocado tanto el controlador como la batería en una caja -ejem- estanca, con la idea de protegerlos de la lluvia. Me preocupa en cierta medida el posible calentamiento al que puedan estar sometidos, pero se han tirado varios días al sol, probando el nivel de calentamiento, y el resultado ha sido satisfactorio. En cualquier caso, este es un proyecto experimental, con idea de probar precisamente estas cosas.
EL sistema, por tanto, trabaja a 12 voltios en continua. Dado que voy a utilizar como elemento base para el gateway un dispositivo Heltec con Arduino, que trabajan a 5 voltios en continua, tendré que incorporar un elemento para convertir el voltaje. Probablemente haga uso de un buck converter DC-DC de 24v a 5v, regulable, como el que utilicé en el proyecto del difusor de aceites. Pero eso ya quedará para otro capítulo.
Etiquetas: aerogenerador, arduino, batería, buck converter, conversor, heltec, lora, lorawan, panel solar
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
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
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
Medidor de entropía
