msgbartop
Venga, alégrame el día
msgbarbottom

01 sep 20 Gateway LoRaWAN: Alimentación eléctrica

Esta entrada es la parte 2 de 7 de la serie Gateway LoRaWAN

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.

IMG_20200901_095500574.jpg

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.

IMG_20200901_112254805_HDR.jpg

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.

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , , , ,

01 sep 20 Gateway LoRaWAN: Introducción

Esta entrada es la parte 1 de 7 de la serie Gateway LoRaWAN

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.

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , ,

28 ago 20 Adaptación a IoT de un difusor de aceites esenciales TENSWALL con control remoto IR

Seguimos con las adaptaciones a IoT. Otra de las que he realizado recientemente es la integración en mi sistema de domótica basado en Home Assistant de un difusor de aceites esenciales controlado por infrarrojos. A principio de verano le regalamos uno de estos difusores a mis cuñados para su casa, pero como también nos gustó para la nuestra, nos decidimos a comprar uno. Elegimos un modelo en Amazon con iluminación y control remoto por infrarrojos, un Tenswall de 500 ml.

Difusor de aceites Tenswall de 500 ml y control por infrarrojos

Difusor de aceites Tenswall de 500 ml y control por infrarrojos

Por lo que he podido averiguar, es un modelo bastante estandarizado vendido bajo multitud de marcas y fabricantes: se basa en el uso de frecuencias ultrasónicas para producir una vaporización del agua y los aceites esenciales a ella añadidos, generando una niebla que esparce las esencias, pero sin calentar el agua colocada en el depósito. Existen otros modelos más avanzados que integran capacidad WiFi y controlable desde una aplicación en el teléfono móvil, basado -por lo que recuerdo- en un ESP8266, pero el modelo que nosotros adquirimos tan sólo cuenta con capacidad IR. En realidad, una ventaja para lo que estaba buscando. El modelo que nosotros adquirimos tiene las siguientes funciones:

  • Encendido/apagado
  • Funcionamiento en modo intermitente (varios segundos generando niebla, varios segundos sin generarla)
  • Funcionamiento en modo continuo
  • Temporizador de funcionamiento a 60, 120 o 180 minutos, o bien en continuo
  • Funcionamiento con mucha niebla o poca niebla
  • Encendido de luces led, en modo carrusel, o 16 posiciones posibles
  • Apagado de las luces led

Para realizar la adaptación a IoT, lo primero fue capturar los códigos IR enviados por el mando a distancia. Para ello utilicé un receptor IR y una librería arduino que ya en su momento empleé para leer códigos del aire acondicionado. Capturé cada uno de los códigos asociados a los comportamientos indicados más arriba. Los adjunto por si a alguien más le sirvieran, en formato raw, y su equivalencia en protocolo NEC:

  • uint16_t rawDataOnOff[67] = {9040, 4466, 600, 532, 604, 530, 596, 538, 598, 536, 598, 534, 602, 532, 594, 538, 596, 536, 598, 1642, 598, 1642, 598, 1644, 598, 1644, 596, 1646, 596, 1644, 594, 1646, 594, 1646, 594, 538, 596, 536, 598, 560, 576, 558, 566, 568, 568, 564, 572, 562, 574, 560, 576, 1640, 602, 1640, 600, 1640, 600, 1640, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 600}; // NEC FF00FF
  • uint16_t rawDataIntermittent[67] = {9040, 4462, 592, 540, 594, 540, 596, 536, 598, 534, 602, 532, 592, 542, 594, 538, 598, 536, 600, 1640, 600, 1642, 600, 1642, 600, 1642, 598, 1644, 598, 1644, 596, 1646, 596, 1646, 594, 1646, 594, 540, 596, 538, 598, 536, 600, 534, 602, 532, 594, 540, 596, 538, 598, 536, 600, 1640, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 600, 1640, 600, 1642, 598}; // NEC FF807F
  • uint16_t rawDataContinuous[67] = {9032, 4466, 600, 532, 602, 530, 594, 538, 596, 536, 600, 534, 602, 530, 594, 540, 596, 538, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 600, 1642, 598, 534, 600, 1640, 600, 534, 592, 540, 594, 538, 598, 534, 600, 532, 592, 540, 596, 1644, 594, 538, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1644, 598, 1642, 598}; // NEC FF40BF
  • uint16_t rawDataTiming[67] = {9032, 4464, 602, 530, 594, 538, 598, 536, 600, 532, 602, 530, 596, 538, 598, 534, 600, 532, 602, 1638, 604, 1636, 594, 1646, 594, 1646, 594, 1644, 598, 1642, 598, 1642, 598, 1642, 598, 534, 600, 532, 604, 530, 596, 1644, 598, 534, 600, 534, 602, 532, 594, 540, 596, 1644, 596, 1642, 598, 1642, 598, 534, 602, 1638, 602, 1638, 602, 1638, 604, 1636, 604}; // NEC FF10EF
  • uint16_t rawDataBigSmall[67] = {9034, 4466, 600, 532, 602, 530, 594, 538, 596, 538, 598, 534, 602, 532, 594, 566, 570, 564, 570, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 1642, 598, 536, 600, 532, 602, 1638, 604, 530, 594, 538, 598, 536, 600, 534, 602, 532, 594, 1646, 594, 1646, 594, 540, 596, 1644, 596, 1644, 596, 1644, 598, 1644, 596}; // NEC FF906F
  • uint16_t rawDataLight[67] = {9040, 4462, 594, 538, 596, 536, 598, 536, 600, 532, 602, 532, 604, 530, 596, 538, 596, 538, 598, 1644, 596, 1644, 598, 1644, 596, 1644, 596, 1646, 594, 1646, 594, 1648, 602, 1640, 602, 530, 594, 1648, 602, 532, 594, 1646, 594, 540, 596, 538, 598, 536, 600, 534, 600, 1640, 600, 532, 592, 1648, 602, 530, 594, 1648, 592, 1648, 592, 1648, 592, 1650, 602}; // NEC FF50AF
  • uint16_t rawDataLightOff[3] = {9042, 2220, 596}; // NEC (Repeat) FFFFFFFFFFFFFFFF

Posteriormente pasé a crear un código arduino que se suscribe a un topic MQTT específico con el que se interactúa con el difusor. La idea es crear en Home Assistant un objeto que implemente las funciones del mando a distancia, y mapear los comandos enviados desde Home Assistant a los códigos IR anteriores. En Home Assistant, basta con crear un objeto de tipo luz, que implemente las funciones anteriormente descritas:


light:
- platform: mqtt
schema: json
name: Oil Diffuser & Light
state_topic: "<topic>"
command_topic: "<topic>/set"
brightness: true
rgb: false
effect: true
effect_list: [intermittent,continuous,timing,big/small,stopLight,lightOff]

…lo que genera una entidad con el siguiente aspecto:

Entidad generada en Home Assistant

Entidad generada en Home Assistant

Posteriormente, es necesario crear en Arduino un código que sea capaz de suscribirse al topic definido en Home Assistant, y reacciones a la información JSON enviada por éste. En realidad, todos los casos posibles son bastante sencillos. El caso que más complejidad tiene es el correspondiente a la luz, ya que el mismo botón/código sirve para encender la luz LED (que siempre empieza en carrusel de colores) y para rotar entre los 16 colores disponibles. En mi caso opté por mapear el deslizador de brillo definido (sin hacer uso de la paleta cromática) para escoger entre las 16 opciones de iluminación, más el modo continuo. En mi caso, opté por lo siguiente:

  • En el caso de recibir “1″ como valor de brillo (valor mínimo): Apagar la luz LED
  • En el caso de recibir “255″ como valor de brillo (valor máximo): Encender en el primer modo, correspondiente a la rotación de colores
  • Para el resto de valores: Calcular en cuál de los 16 tramos de luz se encuentra el deslizador (dividiendo el valor por 16), enviar el código de apagado (que consiste en simular una pulsación continua del botón de control de la luz durante 2 segundos), enviar el código de luz para entrar en el modo de rotación de colores, enviar de nuevo el código para detener la rotación de colores, y posteriormente tantas veces el código de luz como el tramo en el que nos hallemos (ya que este es el funcionamiento del dispositivo).

Por último, es necesario cargar el código en un ESP8266, equipado con un emisor IR. Dado que el difusor de aceites que yo escogí dispone de abundante espacio, es bastante sencillo colocarlo. En mi caso, el difusor se alimenta con un transformador de 24v en continua, que no se puede utilizar directamente para alimentar al ESP8266. En mi caso, opté por utilizar un buck converter DC-DC de 24v a 3.3v, con lo que queda solventado el problema de la diferencia de voltaje. ¡Y listo! Con todo esto es posible controlar un difusor de aceites simple desde la domótica de la casa.

VN:F [1.9.20_1166]
Rating: 10.0/10 (2 votes cast)

Etiquetas: , , , , , , ,

25 ago 20 Adaptación a IoT de un robot de limpieza Dirt Devil e integración en Home Assistant

Estos días he estado juegueteando un poco con un viejo robot de limpieza doméstico del Lidl, un Dirt Devil. Es un robot de limpieza bastante básico, con algo ya de tiempo a sus espaldas. No dispone de ninguna capacidad de integración con sistemas de domótica, ni nada que se le parezca. Es más, ni siquiera tiene WiFi. Pero tiene algo interesante: su funcionamiento se basa en el uso de un chip etiquetado como RV285R, que controla toda una placa de circuitos integrados para realizar las funciones del robot: movimiento de los cepillos, ventilador de succión, detección de golpes, sensores de vacío para que no se caiga por escaleras… El caso es que buscando un poco por Internet, encontré un par de páginas sumamente interesantes sobre cómo reemplazar este chip por un sistema Arduino. Así que aprovechando que sigo de vacaciones, no podía menos que dedicar algo de tiempo al asunto.

De acuerdo a la información compartida por Paijmans, el chip RV285R trabaja a 5 voltios, por lo que es posible hacerlo funcionar directamente en dispositivos Arduino. Con un trabajo de ingeniería inversa, fue capaz de obtener la información de a qué se dedican los pines del chip:

rv285r-pinout

Yo he podido refinarlo un poco más, distinguiendo las funcionalidades de los pines:

  • P50: Led azul, o de encendido
  • P67: Detector de colisión (bumper)
  • P66: Zumbador interno
  • VDD: 5 voltios
  • P65: Nada
  • P64: Ventilador
  • P63: Nada (Etiquetado como Reset por el fabricante)
  • P51: Led rojo, o de indicación de batería baja
  • P52: Motor de rueda izquierda, funcionamiento hacia delante
  • P63: Motor de rueda izquierda, funcionamiento hacia atrás
  • VSS: Tierra
  • P60: Nada (aunque sospecho que es detector de depósito lleno del robot)
  • P61: Motor de rueda derecha, funcionamiento hacia delante
  • P62: Motor de rueda derecha, funcionamiento hacia atrás

Una vez identificados los elementos del chip, era hora de abrir el robot. Se puede apreciar el chip en la parte central de la placa:

IMG_20200824_103439438

Aunque en Paijmans indican que es posible puentear cada una de las patas del chip y conectarlas directamente al arduino (ya que éste tiene más fuerza en las señales que las que pasa el chip), en mi caso he optado por desoldarlo, y conectarle cables de prototipado. Aunque en un principio parecía una buena idea, al poner de nuevo las carcasas del robot, en mi caso saltaron un par de soldaduras de sus pistas, por lo que tuve que hacer trabajo extra de soldadura. Recomiendo soldar directamente al cable:

IMG_20200824_185905184

Una vez soldados los cables, el siguiente paso es el dispositivo Arduino. He optado por hacer uso de un Wemos D1 Mini Pro, de la familia de los ESP8266, ya que proporciona capacidades WiFi, y viene sin los bornes para los cables de prototipado, por lo que podía soldar directamente los cables para ahorrar espacio. Para la lógica del mismo me he basado en la creada por Conrad Vassallo (Converting a cheap Vacuum Robot into IoT) en su proyecto de domotización, ya que está preparado para integrar directamente en un sistema de domótica Home Assistant.

IMG_20200824_185913934_HDR

Algunos comentarios:

  • He tenido que hacer algunas modificaciones al trabajo de Conrad, ya que en el código que comparte faltaba la parte de conectar a la red WiFi el ESP8266. También he eliminado algunas librerías de las que no se hacía uso (EEPROM, Wire). Además he tenido que adaptar los valores de detección de batería baja (más en el siguiente punto) para que se amoldara a mi caso.
  • Conrad ha añadido al proyecto base una idea interesante: un detector de voltaje de la batería de 16v del robot. Usa para ello el pin A0 del ESP8266, que tiene capacidad para medir voltajes. Sin embargo, es necesario utilizar un conversor de voltaje para no quemar el disposito. Un simple divisor de voltaje con dos resistencias funcionará bien, y esta información estará disponible para Home Assistant.
  • Carga el código antes de soldar los pines provenientes de la placa. Una vez soldados, ya no es posible cargar código al Wemos a través del puerto microUSB, ya que el pin D4 mete ruido. En mi caso, tuve que desoldar. Para evitar este problema sería interesante añadir actualización OTA, pero me temo que eso quedará para una nueva versión.
pinout-wemos-mini-d1

Esquema de conexiones del D1 Mini Pro. Atención al uso del pin D4 para el envío de datos como puerto serie desde el Arduino IDE

Por último, queda la parte de Home Assistant. Con añadir el siguiente código a la configuración, el sistema estará preparado para interactuar con el robot:

vacuum:
- platform: mqtt
command_topic: "vacuum/command"
battery_level_topic: "vacuum/state"
battery_level_template: "{{ value_json.battery_level }}"
charging_topic: "vacuum/state"
charging_template: "{{ value_json.charging }}"
cleaning_topic: "vacuum/state"
cleaning_template: "{{ value_json.cleaning }}"
docked_topic: "vacuum/state"
docked_template: "{{ value_json.docked }}"
error_topic: "vacuum/state"
error_template: "{{ value_json.error }}"

El intercambio de información entre el robot y Home Assistant se realiza mediante MQTT. A continuación se puede ver una captura de los datos intercambiados:

mqtt-capture

¿Y el resultado? Espectacularmente bueno. Dejo un par de vídeos. El primero, con el robot aún abierto, y con una Victorinox haciendo de contrapeso, ya que si no, los sensores de vacío entran en funcionamiento:

…y el segundo, ya con las carcasas colocadas, y probando algunas funcionalidades adicionales, como la limpieza específica en un punto concreto:

Fuentes:

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , , , , ,

23 ago 20 Pruebas de comunicación LoRaWAN: conseguido enlace de 7,2 km

Estos días he estado de vacaciones en Galicia, donde he podido seguir con las pruebas de alcance con tecnología LoRa. Estas pruebas consistieron en la repetición de la efectuada en Santiponce el pasado mes de mayo, pero sustituyendo la orografía prácticamente plana de Sevilla por una zona montañosa de las cercanías de Pontevedra.

IMG_20200812_174934627_HDR

Vehículo y entorno de pruebas. Nótese la antena LoRa en la parte frontal del techo del vehículo

En realidad, se realizaron dos pruebas distintas: una de corto alcance, y una de largo alcance. En ambos casos se utilizaron los siguientes elementos y escenario:

  • Escenario de pruebas: La prueba consistió en la transmisión de datos de un pulsómetro Bluetooth LE a un servidor MQTT, donde se volcarían las pulsaciones registradas, junto con el RSSI de la transmisión, para su posterior consumo por terceros sistemas. Para ello, se hacía uso de un emisor Heltec Lora 32, con capacidad BLE y LoRa, que sería el encargado de recibir la información del pulsómetro, cifrarla y transmitirla vía LoRa al gateway LoRaWAN. Éste último recibiría la señal del emisor, la decodificaría, calcularía el RSSI e inyectaría la información resultante en formato JSON en un servidor MQTT. Por último, se preparó un servidor Grafana para representar gráficamente la información de las pulsaciones recibidas.
  • Dispositivo emisor: Como se ha comentado, consiste en un conjunto de sensor de pulsaciones BLE, que envía la información al dispositivo Heltec Lora 32 a 433 MHz. Para mejorar el alcance del dispositivo, se le ha dotado de una antena de 7 dBi, ubicada en el techo de un coche para poder realizar pruebas en movilidad. La información se envía codificada en hexadecimal para necesitar menos bytes a la hora de poner los datos en el aire.
    IMG_20200812_174537088
  • Dispositivo receptor: El dispositivo receptor consiste en un segundo Heltec Lora 32, que recibe la información enviada por el emisor, decodifica la información, calcula el RSSI -que nos da información sobre la calidad del enlace realizado- compone un JSON con ambos parámetros, e inyectar el mismo en un servidor MQTT. Como en el caso del emisor, se ha reemplazado la antena de fábrica por una antena de 7 dBi, emplazada para las pruebas en una ubicación en altura.
    20200812_162258
  • Cliente MQTT: Para obtener una primera verificación de los datos obtenidos, se utiliza un cliente MQTT en un teléfono Android, suscrito al topic en el que se vuelcan los datos por parte del gateway. Un ejemplo de la visualización de los datos se puede observar en la siguiente imagen:
    Screenshot_20200812-184803
  • Visualización de datos en Grafana: Además de la primera visualización de datos en el cliente MQTT, se preparó un servidor Grafana para visualizar los datos volcados en el MQTT, y representar una gráfica con los datos de las pulsaciones. Esta representación, además de proporcionar de una manera gráfica en un solo vistazo el histórico de datos recibidos, permitió también dilucidar -a posteriori- si algunos problemas de falta de recepción de datos en el cliente MQTT se debían a carencia de enlace LoRa o a falta de conexión de datos desde el cliente MQTT. Para nuestra sorpresa, estos problemas se debieron a lo segundo, y no a lo primero. Una muestra de la visualización de datos obtenida:
    Screenshot_20200812-194236

Éste sería un esquema de los dispositivos implicados y las comunicaciones entre ellos:

diagrama-comunicaciones

Una vez definido el escenario y elementos de prueba, pasé a definir las pruebas propiamente dichas. Estimé conveniente realizar una primera prueba de corto alcance en las cercanías, y en caso de obtener éxito en la misma, pasar a una segunda de largo alcance.

Prueba de corto alcance. 3,08 km

La prueba de corto alcance consistió en un enlace de una distancia estimada de unos 3 kms, desde una casa situada en la aldea de Vilarchán -Puente Caldelas- hasta el monte de La Fracha, donde se encuentran una serie de antenas y repetidores de radio y televisión. La idea era observar cómo de fiable era la transmisión en este entorno de montaña, con visibilidad directa desde el emisor al receptor, pero con obstáculos consistentes en otras viviendas, zonas arboladas y, en determinados tramos, la propia mole rocosa de la montaña.

la-fracha

Lúa saíndo polo monte da Fracha (Pontevedra), cortesía de Pintafontes

EL objetivo de esta prueba era calibrar el impacto esperable de la diferencia de orografía entre Santiponce y Vilarchán, para determinar el impacto de la misma en la transmisión. Hay que tener en cuenta que en el caso de Santiponce se había observado que se podía obtener, con el mismo equipo de pruebas, un enlace confiable de 4,5 km, y hasta 5,3 km de manera esporádica.

gmaps1-fracha

Recorrido en Google Earth de la prueba efectuada

Salimos de Vilarchán con el emisor funcionando, y pronto se perdió la señal, apenas al llegar a la carretera de Pontevedra a Puente Caldelas. Durante todo el trayecto, pasando por el polígono de La Reigosa y la subida a la Fracha, hasta las cercanías del polvorín, no se recibió señal alguna. Una primera decepción. Bajamos del coche y empezamos a andar, camino de las antenas, por la parte de la montaña contraria a la casa. Y ahí, sorpresa, empezamos a recibir datos, si bien con un RSSI muy débil, de -131. Una primera medición de distancia nos dio 3,01 km de distancia en línea recta al emisor, pero con toda la ladera del monte obstaculizando la señal. Proseguimos el ascenso hasta las antenas, sin perder recepción de datos en ningún momento, y con la calidad de la señal mejorando a medida que salíamos de la sombra de la montaña, y ganábamos en línea de visión directa hacia el emisor.

20200812_171838-editada

Vista desde las antenas de la zona de pruebas, con la zona aproximada del receptor marcada

Realizamos el ascenso a las antenas por la ladera que daba hacia la zona de la casa. Al llegar a las mismas, siempre sin perder la señal, obtuvimos un enlace de 3,08 km, con un mejor RSSI de -111. Como valor comparativo, en la misma casa y a unos 5 metros de distancia, el RSSI rondaba los -85. En cuanto a la visibilidad, se puede considerar casi directa, y el casi es porque hay algunas edificaciones que se interponen entre el punto donde estaba ubicado el receptor, y el punto donde nos encontrábamos.

Screenshot_20200812-171110_OruxMaps-1

Captura de pantalla de la distancia observada con Oruxmaps entre nuestra posición a la ubicación del receptor

Tras verificar durante un rato de la estabilidad de la conexión, y disfrutar un poco de las vistas, emprendimos el descenso hasta el vehículo, si bien esta vez por la ladera opuesta, que dispone de un camino que facilitaba la bajada, y que además nos permitía determinar en qué punto la mole del monte obstaculizaba la señal hasta que ésta se perdiera.

20200812_172055

Vistas de la Ría de Pontevedra desde La Fracha

Durante un buen rato de descenso se mantuvo la recepción de la señal, si bien con deterioros del RSSI paulatinos. Perdimos la señal a una distancia de 2,81 km del receptor, si bien con toda la ladera interpuesta entre nosotros y el gateway receptor. Sin embargo, al llegar al coche, volvimos a recuperar la señal, que ya no volvimos a perder en todo el trayecto de vuelta hasta la casa, en gran contraste con la observación realizada a la ida, donde pronto se perdió la señal. Posteriormente, y tras analizar los datos reflejados en Grafana, pudimos ver que en realidad el en trayecto de ida nunca se llegó a perder la señal LoRa entre emisor y receptor, sino que habíamos tenido un problema de falta de datos en el teléfono con el cliente MQTT, que había provocado una desconexión con el servidor MQTT -y una aparente pérdida de datos-. Es decir: que salvo en un punto muy localizado de La Fracha, habíamos tenido enlace LoRa casi de manera constante y sin pérdida de datos, pese a las dificultades del terreno, zonas boscosas y construcciones interpuestas. Una primera prueba sumamente satisfactoria.

Prueba de largo alcance. 7,2 km

La segunda prueba era la verdaderamente significativa: intentar un enlace directo con un grupo de antenas de radio, ubicadas a una distancia aproximada de 7 kilómetros, con línea directa de visión, en torno a un 60% más de distancia que las pruebas efectuadas en Santiponce.

IMG_20200812_194815559_1

Vista desde la antena del receptor, con la zona prevista del emisor marcada

Si bien la distancia en línea recta entre ambas ubicaciones ronda los 7 km, es preciso realizar unos 13 km de recorrido para poder llegar de la una a la otra, debido a orografía del terreno y las vías de comunicación existentes, como se puede apreciar en el recorrido de etapa trazado en Google Earth:

gmaps1-penarada

Para esta segunda prueba movimos la ubicación del receptor a una ventana con visibilidad directa de la zona de pruebas, con el objetivo en mente de dirigirnos a una zona de repetidores ubicada en el Monte Catadoiro, cerca de Rebordela. La diferencia es que esta vez podríamos ir directamente con el coche hasta la zona escogida. Dicho y hecho, salimos en dirección Puente Caldelas. Y al igual que en la primera prueba, perdimos la recepción de datos justo al llegar a la carretera. Y al igual que en el caso anterior, estuvo motivada por la pérdida de datos del teléfono Android. Al llegar a las antenas, pudimos ver que el cliente MQTT se había desconectado. Y al volver a conectar… ¡éxito! Los paquetes llegaban sin pérdida, y con un RSSI espectacularmente bueno, de -115 en el mejor de los casos. Tras las pertinentes comprobaciones, verificamos que habíamos logrado un enlace de 7,23 km con línea directa de visión.

Screenshot_20200812-183019_MyMQTT

Primeros paquetes recibidos en el cliente MQTT una vez restablecida la conexión

Screenshot_20200812-183920

Captura de Oruxmaps en la que se aprecia la distancia alcanzada

IMG_20200812_184526000

En las antenas

Estuvimos un rato en las antenas, observando el comportamiento de los datos: sin pérdidas, y con un RSSI que hace pensar que es posible mantener distancias aún mayores de manera confiable. Si no pudimos ir más lejos fue porque la montaña ya no daba para más. :D Disfrutamos un rato de las vistas, y poco después emprendimos el regreso.

IMG_20200812_183845500_HDR

Vista de la zona aproximada del gateway, a través de unos prismáticos

IMG_20200812_184346134_HDR

Vista de la ría de Vigo, con el puente de Rande y las Islas Cíes al fondo

Y de nuevo la sorpresa vino en el trayecto de vuelta. Durante todo el recorrido, de casi 14 kilómetros, por zonas boscosas, sin visibilidad directa, con laderas, bosques y pueblos entre medias, no se perdió la señal en ningún momento, como pudimos verificar consultando Grafana. Esto incluye el paso por Puente Caldelas, en la más profundo del valle del Río Verdugo, y en un entorno completamente urbano y sin visibilidad directa, a más de 5,5 km de distancia desde el gateway; y también en la central hidroeléctrica de Hidrofreixa, a 5’3 km, aunque en este caso con visibilidad directa.

20200812_190719

Estación de bombeo de Hidrofreixa

Screenshot_20200812-191026_OruxMaps

Enlace desde Hidrofreixa, de 5,48 km

En lo referente a los datos de Grafana, en esta captura se ven las gráficas de pulsaciones:

captura-grafana-pruebas

Por cierto, que en realidad mis pulsaciones no son tan altas, sino que he observado que mientras no empiezo a sudar en serio el pulsómetro muestra exceso de pulsaciones al alza. :mrgreen: En cuanto a los huecos, el correspondiente a las 16:48 a las 16:57 es una de las zonas de sombra de La Fracha, lo mismo que el de pasadas las 17:30. El de las 17:46 a las 18:03 corresponde al tiempo entre prueba y prueba (con cambios de ubicación de antenas y resto de elementos), y los dos huecos posteriores a momentos en que el pulsómetro Bluetooth salió del rango de alcance del emisor LoRa.

Y para cerrar, tenemos ya planificadas nuevas pruebas de alcance: en este caso, a dos campos de aerogeneradores, ubicados a 15 y 25 km de distancia desde Vilarchán. Pero de eso ya hablaremos en otro momento…

VN:F [1.9.20_1166]
Rating: 10.0/10 (1 vote cast)

Etiquetas: , , , , , , , , , , , ,