21 sep 20 Alimentación eléctrica. Conversión DC-DC
El último elemento de la instalación eléctrica que es necesario considerar es el conversor DC-DC del que es necesario disponer para poder alimentar el gateway desde la instalación solar. Como se comentó al comienzo de esta serie, mi idea es alimentar el gateway haciendo uso de un panel solar que he reinstalado en el tejado, y del que ya disponía producto de un proyecto previo. El panel solar se encuentra conectado a un controlador, que usa una batería para almacenar energía, y del que se puede extraer una conexión en corriente continua a 12v. Un esquema general de la instalación sería el siguiente:
Llegados a este punto, es preciso alimentar el dispositivo Heltec LoRa 32 que constituye el componente central del gateway. De acuerdo al diagrama de conexionado proporcionado por el fabricante, el dispositivo se puede alimentar, bien mediante la entrada micro-USB disponible, mediante corriente de entrada a 5v utilizando el patillaje correspondiente:
Para este proyecto lo más sencillo es utilizar un conversor DC-DC que nos baje el voltaje de los 12v que proporciona el controlador a los 5v que necesita el dispositivo. En mi caso, estoy utilizando un convertidor variable, un HiLetGo MP1584EN, que es capaz de manejar voltajes de entrada de 4,8v a 28v, y proporcionar voltajes de salida desde 0,8v hasta 20v. El voltaje de salida se puede ajustar mediante un tornillo, que en nuestro caso giraremos para que nos proporcione 5v. Este módulo tiene como característica interesante adicional el que puede proporcionar hasta 3A de corriente de salida, lo que lo hace sumamente versátil para este tipo de instalaciones.
La instalación es sencilla. Es cuestión de conectar los bornes de entrada del módulo a los bornes correspondientes del controlador, respetando las polaridades, y los bornes de salida del módulo a los pines correspondientes del Heltec. Y a partir de ahí, a consumir energía solar del sistema. 
Etiquetas: controlador, conversor dc-dc, heltec, panel solar
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
15 sep 20 Reparación de una guantera con piezas impresas en 3D
El coche del que vengo haciendo uso desde hace algún tiempo tenía un pequeño problema con la guantera: desde antes de que llegara a mi poder alguien le había arrancado de cuajo la puerta de la guantera, partiéndole las guías y las bisagras que la sujetaban a la estructura. Como pensaba que iba a hacer un uso temporal de este vehículo, no pensé en reemplazársela ni repararla de ninguna manera. Sin embargo, tras algún tiempo con él, he acabado por pillarle el gusto al coche. Y como de motor está estupendamente bien, y tiene todo lo que necesito, parece que voy a utilizarlo durante algún tiempo. Dicho lo cual, el pasado fin de semana me decidí a reparar la puerta en cuestión.
Tras desmontar toda la guantera (algo sencillo en un Opel Astra, ya que son apenas seis tornillos lo que la sujetan al salpicadero), pude ver la magnitud del problema. De las dos guías de la guantera una había desaparecido completamente, y la que quedaba, estaba partida en dos piezas. En cuanto a las bisagras de plástico, éstas estaban partidas también.
Guantera en proceso de reparación
Así que tocaba ser imaginativo. Y con una impresora 3D en casa, la cosa estaba bastante clara. Saqué un molde en papel de la pieza restante, y con ese molde en papel realicé un modelo aproximado de la guía mediante un programa CAD. Tras una horita de impresión, ya tenía una pieza equivalente a la perdida. El siguiente paso consistía en reconstruir las guías y las bisagras. Hice uso de un pegamento especial para PVC rígido, utilizado en fontarnería. Los resultados iniciales fueron bastante prometedores.
Detalle de la pieza 3D
Las bisagras habían pegado bastante bien, la pieza impresa se había quedado bien adherida al anclaje de la puerta de la guantera, y la pieza reconstruida parecía aguantar el tipo. Tocaba volver a montar la guantera. Las primeras pruebas no fueron bien, ya que la pieza reconstruida se partió de nuevo a las primeras de cambio. Sin embargo, la pieza 3D y las bisagras aguantaban perfectamente bien.
Guía reconstruida que acabé reemplazando
Visto lo cual, opté por imprimir una segunda pieza en 3D, y reemplazar la guía original restante. Nada más que por una razón de simetría, valía la pena el cambio:
Guantera con ambas guías impresas en 3D
En cuanto a la usabilidad, mejor dejo que un vídeo dé una idea de cómo va ahora:
Un buen resultado, ¿no?
Etiquetas: guantera, impresora 3d, opel astra
Medidor de entropía
