msgbartop
Que no cunda el pánico
msgbarbottom

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: , , , , , , , , , , , ,

31 jul 20 Acceso a través de OpenVPN a equipos de la red local del servidor VPN

La configuración por defecto de OpenVPN permite acceder sólo al equipo servidor de VPN cuando estableces la conexión desde el cliente. Sin embargo, es posible extender el acceso al resto de equipos de la red local de dicho servidor, en caso de necesitar acceso a otras máquinas. La receta es la siguiente:

  • Configurar el servidor para que advierta al cliente de las rutas a las que puede acceder: Para que el cliente sepa que se puede conectar a más redes además de al propio servidor de VPN es preciso advertirle de ello. Se puede hacer fácilmente añadiendo la directiva “push” en el fichero de configuración del servidor. Para permitir acceso a una red de tipo 192.168.0.0/24, bastaría con lo siguiente: push “route 192.168.0.0 255.255.255.0″, y reiniciar el servicio.
  • Permitir que nuestro servidor haga forwarding de paquetes: Se habrá de modificar el fichero /etc/sysctl.conf, y quitar el comentario de la línea # net.ipv4.ip_forward=1. Posteriormente habrá que reiniciar el servicio con sudo sysctl -p.
  • Activar el enmascaramiento de paquetes en nuestro servidor: Este último paso va en función de nuestra arquitectura. Si nuestro servidor de OpenVPN no es la puerta de enlace por defecto de nuestra red, dado que las peticiones de los clientes OpenVPN llegarán al servidor de destino con una IP del tipo 10.8.0.x (o como sea que lo tengamos configurado en nuestro servidor OpenVPN), a la hora de responder a dichas peticiones, enviarán las respuestas a la puerta de enlace por defecto, con lo que se perderán las respuestas, ya que la puerta de enlace por defecto no tendrá constancia de la emisión de las mismas (enrutado asimétrico), y éstas no llegarán al cliente OpenVPN (este problema no se daría con el servidor OpenVPN actuando como puerta de enlace, ya que tendría constancia de los paquetes, y podría enrutarlos adecuadamente). Para evitar el problema, es posible activar el enmascaramiento de paquetes. Bastaría con añadir la siguiente regla a nuestro iptables: iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE… siempre que la interfaz de la red sea la eth0, y que nuestra red de clientes OpenVPN sea la 10.8.0.0/24 (si no, hay que modificar estos valores según correspondan). Para hacer que la configuración sea persistente, recomiendo usar el servicio iptables-persistent, existente en Debian y otras distribuciones.

Referencias:

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

Etiquetas: , , , ,

29 jul 20 Canción del día (XL)

Lo de hoy es algo que me he encontrado en Youtube, cuando programaba en Arduino un software para acceder por Bluetooth a los códigos OBD-II del coche (esa otra historia de la que hablaré a su debido tiempo):


The War On Drugs – Thinking Of A Place

Además del tema en sí, me ha llamado la atención este comentario, de un tal Lacerta:

fun fact: the first time i heard this song was on a roadtrip along the west coast of ireland on the only channel that had signal.
we were all quiet and just listened to it. honestly, that was a feeling i still have no words for.

Apropiado, ¿verdad?

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

Etiquetas: , ,

07 jul 20 Uso de diskpart para eliminar particiones en Windows 10

¿Nunca te ha pasado que, tras utilizar una memoria USB para realizar una instalación de Linux, quieres volver a formatearla en Windows para darle otro uso distinto, y sólo te aparece una pequeña partición que apenas es una fracción del espacio que realmente tiene la memoria? Es algo bastante fastidioso, ya que Windows no tiene una buena capacidad para gestionar particiones de otros sistemas operativos. Por supuesto, este problema no se da en Linux, donde se puede resolver el problema fácilmente con GParted o similar, eliminando las particiones existentes, y creando una nueva partición FAT32. Pero con el administrador de discos de Windows el realizar esta tarea se hace poco menos que imposible.

Sin embargo, para casos como este tenemos la interfaz de línea de comandos en Windows 10, con una interesante aplicación llamada “diskpart”. Permite crear, extender o eliminar particiones, pero yo me voy a centrar en el caso del borrado. Los pasos para eliminar todas las particiones serían los siguientes:

  • En una ventana de comandos, teclear diskpart.exe.
  • En diskpart teclear list disk
  • Seleccionar el disco del que queremos eliminar la partición (por ejemple, el 1): select disk 1
  • Introducir el comando clean all para eliminar todas las particiones.
  • Salir del programa con el comando exit

¡Y listos! Una vez terminado, Windows detectará una nueva unidad sin particiones, y nos ofrecerá la posibilidad de formatear la memoria USB, creando una nueva partición que haga uso de todo el espacio de la misma.

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

Etiquetas: , , ,

03 jul 20 Cómo encontrar la clave de una WiFi guardada en Windows 10

Este pequeño tutorial viene muy bien para encontrar la clave de una WiFi a la que nos hemos conectado en Windows 10, pero de la que no recordamos la clave: Find the WiFi Password in Windows 10 Using CMD. En español, la receta:

  • Abrir una ventana de comando con “cmd”
  • Obtener la lista de conexiones WiFi almacenadas en el sistema operativo: “netsh wlan show profile”
  • Una vez identificada la WiFi en cuestión, obtener la contraseña: “netsh wlan show profile <nombrewifi> key=clear”
Captura de clave de WiFi

Captura de clave de WiFi

…y de esta manera, nos aparecerá la clave de la WiFi seleccionada.

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

Etiquetas: , , ,