msgbartop
Lasciate ogne speranza, voi ch’intrate
msgbarbottom

07 ene 24 Sistema de telemetría 2.0, basado en ESP32

Hace ya algunos años, cuando aún vivíamos en Irlanda, desarrollé un sistema de telemetría casero para el Mercedes C180 Sportcoupe que teníamos allí, basado en una Raspberry Pi y un receptor GPS, junto con un conector OBD-II por Bluetooth para leer datos de la centralita del coche. Fue un sistema que estuvo funcionando estupendamente bien, pero que dejé de utilizar, por razones que no vienen al caso.

En fechas recientes me he decidido a revivirlo (también por razones que no vienen al caso), pero quería darle una vuelta de tuerca al sistema, para cambiar algunas características que -estando bien- no se amoldaban del todo a mis necesidades. La principal de ella es que el sistema original dependía de una conexión Bluetooth con un teléfono móvil que hiciera de módem sobre este medio, a fin de proporcionar conectividad al exterior. Buscaba que la nueva versión del entorno tuviera conectividad independiente, a fin de poder hacer seguimiento del coche de manera más sencilla. Mi primera idea fue conectar un modem USB a la Raspberry Pi, pero se trata de un modelo 2 de la RPi, que sólo dispone de 2 conexiones USB, y ambas estaban en uso: una para el receptor GPS, y otra para el dongle Bluetooth que se necesita para conectar con la centralita del coche. Pensé en portar todo a una RPi más moderna, pero fue aquí cuando entró en danza el siguiente artilugio:

LilyGO TTGO T-A7670G

LilyGO TTGO T-A7670G

Se trata de un dispositivo LilyGO TTGO T-A7670G. Se trata de un ESP-32 que proporciona, de manera simultánea, conectividad Bluetooth, zócalo para tarjetas de telefonía 4G, receptor GPS, e incluso un zócalo para conectar una batería 18650, todo ello en una sola placa. Ya tenía experiencia trabajando con ESP-32 en Arduino, lo cual era una gran ventaja para mí, además de trabajar con estos componentes por separado, pero nunca lo había hecho con una placa de fabricante que proporcionara todos estos elementos de manera integrada. Mucho mejor que tener que ir montando componentes por separado.

El fabricante, además, proporciona un repositorio en GitHub donde acceder a librerías, ejemplos de código, documentación, e incluso esquemáticos de carcasas, lo que ha hecho que haya podido imprimir una caja para el dispositivo:

TTGO con carcasa 3D y receptor GPS

TTGO con carcasa 3D y receptor GPS

Con todo esto, he podido realizar una nueva versión del sistema de telemetría, con las siguientes características:

  • Hago uso de una tarjeta de datos 4G española, de tipo MicroSIM, con un funcionamiento excelente. El sistema apenas consume sobre 2-3 MB de datos, haciendo envío de información cada 10 segundos a la plataforma.
  • La conectividad, como en el caso original, está basada en el envío de datos en formato JSON a un servidor MQTT. Posteriormente esa información es consumida de diversas maneras, tanto para proporcionar ubicación en tiempo real, como para realizar analítica de datos sobre el viaje. A diferencia del caso original, el envío de información se hace directamente al MQTT remoto, en vez de componer un MQTT local que se sincroniza con el remoto, cosa que se hacía para preservar el envío de información en caso de pérdida de conectividad. En este caso, he podido comprobar que no se producen pérdidas de datos significativas, por lo que he preferido simplificar.
  • El sistema hace uso del GPS integrado para recibir información GPS. Este es un punto importante en el caso de esta placa. Existen diversas variantes de la misma, con cobertura GPS regional, global, o sin cobertura GPS. En mi caso, hago uso de la placa “A7670G R2 With GPS”, que es el que proporciona cobertura GPS global, y más compatibilidad con sistemas de telefonía, pero tiene el detalle de que el módulo GPS no está integrado en la placa, sino como módulo anexo, en la trasera de la misma, junto al zócalo de la batería 18650. Esto implica que el modo de uso del GPS es distinto, haciendo uso de la librería GPSShield, en vez del ejemplo convencional que indica el fabricante. Esto me tuvo un tiempo dando vueltas, hasta que me di cuenta de ello.

    Tabla comprarativa de versiones A7670X

    Además, la placa viene con una antena GPS pasiva. Esto está bien si el dispositivo se encuentra directamente al aire libre, pero era problemático si estaba dentro de una casa o de un coche, ya que apenas tenía cobertura. Para solucionar este inconveniente tuve que hacer uso de una antena GPS activa con conector SMA, y hacer uso de un pigtail UFL/U.FL/IPX a RP-SMA/SMA. Nada grave, pero sí un poco molesto. Ahora bien, en cuanto dispuse de esta antena activa el sistema pasó a ser capaz de detectar señal GPS incluso en interiores. Todo una diferencia, y sin necesidad de reprogramar.

  • La telemetría OBD-II es algo que no he conseguido hacer funcionar aún del todo. Si bien la placa es capaz de conectar correctamente con mi conector OBD-II por Bluetooth, no es capaz de extraer correctamente los datos de la centralita. Hago uso para ello de la librería ELMduino, que conocía desde hace algunos años, pero con la que no he tenido resultados muy buenos hasta ahora. Antes hacía uso de un ESP-32 convencional, y esperaba que con esta placa funcionara mejor, pero no ha sido el caso. Puede ser tema del dongle Bluetooth, que es de los baratillos. He encargado otro, para probar, así que espero mejoras al respecto.

En estos días he estado haciendo algunas pruebas, y al margen de la captura de datos de la centralita, el resultado es bastante bueno. Espero poder seguir haciendo mejor al respecto en las próximas semanas.

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

Etiquetas: , , , , , , , , ,

07 may 21 Una webcam con Arduino: el ESP32-Cam

No voy a descubrir nada nuevo si afirmo que los sistemas Arduino son pequeñas maravillas. Se pueden hacer con ellos cosas increíbles en el ámbito de la domótica, e incluso con sistemas IoT y transmisión de radiofrecuencia. El problema habitual que suelen tener es que tienen unos recursos ciertamente limitados, pero para su ámbito de actuación, son más que correctos. Sin embargo, existen placas específicas que tienen algo más de potencia y capacidades, y que permiten dar un paso más allá: es el caso de las placas basadas en el ESP32. Ya he hablado de ellas en otro ámbito, en concreto en lo que se refiere a capacidades LoRa y LoRaWAN, pero hay un desarrollo específico, basado en el ESP32, que da bastante juego: las cámaras web. Y pensando en esto fue para lo que nació la ESP32-Cam.

Placa ESP32-CAM

Placa ESP32-CAM

La placa fue originalmente desarrollada por Espressif, y se compone de un micro ESP32-S, una cámara VO2640, y varios GPIOs que permiten conectar periféricos. Dispone de capacidad Bluetooth, así como conector microSD para utilizar tarjetas de memoria. Y todo ello por un precio ridículo, inferior a los 8€ (menos aún en el caso de las placas clónicas que se pueden encontrar en Aliexpress). De lo que no dispone es de un conector microUSB ni miniUSB, lo que implica que para programarlo es preciso utilizar un programador FTDI, pero no es nada tampoco cosa del otro mundo.

Diagrama de conexionado ESP32-CAM-Programador FTDI

Diagrama de conexionado ESP32-CAM-Programador FTDI

Desde el punto de vista físico, hay que alimentar el dispositivo utilizando los pines de 5v y GND del programador, interconectar los puertos UOR-TX y OUT-RX, y para iniciar el dispositivo en formato de grabación, puentear el GPIO0 y el GND de la propia placa. Una vez conectado de esta manera, se puede conectar el programador al PC, e iniciar la subida del firmware.

Comentaba antes que la placa es un desarrollo de Espressif, y ellos mismos proporcionan el código para subir un servidor de video en streaming a la ESP32-Cam. Este código es interesante, pues -entre otras funcionalidades- incorpora una funcionalidad de detección de rostros y detección de intrusos basado en las caras registradas.

Reconocimiento facial con el ESP32-CAM

Reconocimiento facial con el ESP32-CAM

El código es interesante, pero tiene algunos defectos. Entre ellos, que no permite hacer uso del pequeño LED que trae incorporado para hacer las veces de flash. Tras buscar un poco, encontré otro desarrollo que incorpora una serie de mejoras sobre el código original.. Tras haber utilizado ambos, recomiendo de manera clara este último.

Y para cerrar, comentar que es posible hacer uso de este servidor web dentro de HomeAssistant. Basta con crear una entrada de tipo cámara genérica, apuntando a la URL de captura de imágenes estáticas:

camera
– platform: generic
name: ESP32-Cam
still_image_url: http://192.168.0.XXX/capture?_cb.png
verify_ssl: false

ESP32-CAM integrada con HomeAssistant. Vista de mi patio

ESP32-CAM integrada con HomeAssistant. Vista de mi patio

Las pegas principales de la cámara son dos: la primera es que el módulo de la cámara no es ninguna maravilla. Sin embargo, al ser de un tipo estandarizado, es bastante sencillo encontrar mejores módulos, con cable más largo, y lentes ojo de pez, entre otras flipadas. La segunda es que no dispone de ninguna carcasa. Tampoco es problema, es posible encontrar bastantes diseños en Thingiverse para imprimir una carcasa en 3D.

Referencias:

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

Etiquetas: , , ,

19 sep 20 Los nodos LoRaWAN. Hardware y software

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

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.

IMG_20200919_183904_1.jpg

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.

ab01pinout-1024x531

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.
VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)

Etiquetas: , , , , , ,

14 may 20 Más allá de LoRa: LoRaWan

Llevo ya un par de artículos sobre las pruebas que he estado efectuando con enlaces soportados con tecnología LoRa, y no podía postergar más el hablar sobre una tecnología que va un paso más alla: LoRaWan. LoRaWan, en líneas generales, es un protocolo de comunicaciones que, haciendo uso de tecnología LoRa, permite proporcionar conectividad a múltiples dispositivos que se basan en LoRa. La idea básica es que LoRa proporciona los enlaces punto a punto, mientras que LoRaWan proporciona una red de comunicaciones. Para ello se apoya en la definición de dos tipos de dispositivos, los nodos y los gateways. Los primeros son los dispositivos individuales -por lo general IoT- que actúan como clientes, enviado y recibiendo información de la red. Los segundos, por su lado, conforman la infraestructura que enlaza los clientes individuales con el resto del sistema, actuando como pasarela con redes convencionales como puede ser Internet.

Estructura de una red LoRaWan

Estructura de una red LoRaWan

En toda esta introducción la palabra importante es red. Mientras que en mis pruebas anteriores hacía uso de un par de dispositivos enlazados, aquí se trata de dar un paso más allá. ¿Y cómo haces uso de una red? Bueno, hay dos maneras: o la construyes, o usas una ya existente. La primera opción es viable en el caso de querer construir una red privada, para algún cliente o un proyecto concreto, pero en la mayoría de los casos no es un escenario realista. Pero en cuanto a la segunda, es esta la parte realmente interesante de los sistemas LoRaWan. Existen redes, tanto públicas como privadas, a las que es posible conectarse y hacer uso de las mismas. Y una de las redes abiertas más conocidas a nivel mundial es The Things Network, también conocida como TTN.

Cuando, de nuevo hace ya un par de años largos, adquirí mis dispositivos LoRa, cometí un error de novato. Pedí un dispositivo de 868 MHz y otro de 433. Algo que hacía perfectamente inútiles los intentos de comunicación entre ellos. Esa fue la razón para adquirir un segundo dispositivo de 433 MHz para mis pruebas de enlace punto a punto. ¿Pero qué hacer con el kit de 868 MHz? Podía comprar un segundo y hacer lo mismo, pero fue entonces cuando tuve noticias de TTN. Una red LoRaWan que permite el acceso gratuito a la misma para la transmisión y recepción de mensajes (aunque con límites de capacidad -fair use-), pero que para una transmisión de pruebas de un sistema IoT era más que sobrado. La pregunta es: ¿existía un despliegue de esa red en Sevilla? Y la respuesta es que sí.

TTN - Cobertura en Sevilla

TTN – Cobertura en Sevilla

Como se puede ver en el mapa de gateways, hay un buen nivel de cobertura de la red TTN en Sevilla capital y el Aljarafe… salvo en Santiponce. En efecto, hice algunas pruebas en casa, con resultados completamente infructuosos. Pero en la Isla de La Cartuja, donde está mi oficina, había cobertura teórica, y dos gateways en las inmediaciones, a unos 1500 y 1700 metros de distancia. Cerca del límite teórico del alcance de los Heltec, y más dentro de un edificio. Pero era cuestión de hacer la prueba. Así que aprovechando un día, al comienzo del confinamiento, en que tuve que desplazarme a la oficina por razones de continuidad de negocio, aproveché para hacer algunas pruebas de conexión.

Dispositivo LoRa Heltec ESP32 a 868 MHz

Dispositivo LoRa Heltec ESP32 a 868 MHz

Para ello hice uso de una librería específica que Heltec ha desarrollado para las conexiones LoraWan, además de registrar -paso obligado- mi dispositivo para obtener una licencia de uso de Heltec. Además de esto, es necesario registrarse en TTN y configurar una aplicación para poder hacer uso de la red, además de registrar tu dispositivo a fin de obtener una serie de identificadores únicos para los dispositivos que se habrán de conectar a la red. Se pueden seguir los pasos en el siguiente artículo: Heltec ESP32 Board + The Things Network. Y tras algunas pruebas, ajustes y apretar -metafórico- de tuercas…

Datos enviados a TTN

Datos enviados a TTN

…conseguí establecer de manera exitosa sendos enlaces con dos de los gateways cercanos a la Isla de La Cartuja. En concreto, a los ubicados en la Alameda de Hércules y la Plaza de la Encarnación, con una distancia máxima de algo más de 1700 metros desde mi ubicación, como se puede apreciar en la siguiente imagen:

Alcance de enlaces LoRaWan realizados

Alcance de enlaces LoRaWan realizados

La prueba no dio para mucho más, ya que tenía otros menesteres de los que ocuparme en la oficina, pero sirvió para demostrar que era posible trabajar con TTN y dispositivos Heltec, incluso haciendo uso de la antena de fábrica en condiciones adversas. En fechas posteriores, visto el éxito de la prueba en la oficina, realicé algunas nuevas pruebas de larga distancia desde Santiponce, tanto con antenas de fabricación propia (hasta la base está sacada con la impresora 3D)…

Antena de fabricación propia de 868 MHz

Antena de fabricación propia de 868 MHz

…como con antenas fabricadas por terceros:

Antena de 868 MHz

Antena de 868 MHz

En ninguno de los casos logré un enlace con ninguna de las redes de TTN en Sevilla o el Aljarafe. No es sorprendente, ya que la más cercana se encuentra a 7 km. de distancia de mi domicilio, y obstaculizadas por la orografía del terreno, y edificios que se interponen en la línea de visión directa. Además, en todos los casos he usado antenas omnidireccionales. Queda por realizar una prueba con antenas direccionales (estoy pensando en una tipo yagi), pero antes de eso, aún tengo que hacer pruebas con línea directa de visión y las antenas de las que actualmente dispongo. El lugar perfecto es el cerro de Santa Brígida, en Camas. Estoy deseando que podamos realizar más deplazamientos para acercarme con la bici y hacer estas pruebas. :mrgreen:

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

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

02 may 20 Comunicación de larga distancia de dispositivos IoT: Heltec LoRa 32

En estas semanas en las que el coronavirus nos ha trastornado la vida a todos, he aprovechado para retomar algunos viejos proyectos que por diversas razones había dejado aparcados hasta mejor ocasión. Uno de estos proyectos (ya habrá tiempo para hablar de otros) era el de lograr un sistema que permitiera recibir información de sensores distribuidos en zonas abiertas. En pocas palabras, sensorización IoT en el ámbito rural. No es exactamente una idea nueva, y era algo que me rondaba la cabeza cuando volví de Irlanda. Ya en su momento me hice con un par de dispositivos Heltec LoRa 32, que disponen de pantalla OLED incorporada, para hacer mis pinitos con ellos. Unos cacharros bastante interesantes, ESP32, con conectividad WiFi y Bluetooth Low Energy además de LoRa. Y aquí la parte importante es LoRa. LoRa (Long Range) es un protocolo de comunicación de larga distancia (WAN) y bajo consumo energético, que haciendo uso de frecuencias libres, permite crear enlaces de datos entre distintos dispositivos, o bien establecer redes de datos completas (cuando ya hablamos de LoRaWAN). Las principales características del protocolo LoRa son las siguientes:

  • Capacidad de trabajo en modo unidireccional, bidireccional o multidifusión
  • Alta tolerancia a las interferencias
  • Alta sensibilidad para recibir datos (-168dB)
  • Basado en modulación “chirp“
  • Bajo Consumo (hasta 10 años con una batería)
  • Largo alcance 10 a 20km
  • Baja transferencia de datos (hasta 255 bytes)
  • Conexión punto a punto
  • Frecuencias de trabajo: 868 Mhz en Europa, 915 Mhz en América, y 433 Mhz en Asia

Como decía, adquirí los dispositivos, pero luego nunca tuve tiempo para ponerme a dedicarme a ello. Hasta estas semanas, que han coincidido varias circunstancias que me hicieron volver a dedicarle tiempo al proyecto: el confinamiento por coronavirus, unas iniciativas en el trabajo a las que esta tecnología podría aplicar, y que he dedicado algo más de tiempo a investigar con sistemas ESP32 que con los convencionales ESP8266. Así que tocó desempolvar los viejos Heltec LoRa que tenía guardados, y ponerlos a funcionar.

Pareja de Heltec LoRa 32 con carcasa impresa en 3D

Pareja de Heltec LoRa 32 con carcasa impresa en 3D

Heltec proporciona una librería bastante interesante para el IDE de Arduino que permite hacer funcionar de una manera bastante sencilla a una pareja de dispositivos. Como decía más arriba, los Heltec pueden funcionar en modo unidireccional (una unidad emisora y otra receptora), bidireccional (intercambio en ambos sentidos para cada dispositivo) o bien en multidifusión (un mensaje es recibido por todos los dispositivos que estén en su rango de alcance). La manera más simple de empezar es con un emisor y un receptor, sin hacer uso de direcciones de dispositivo. Simple y efectivo, la librería viene con ejemplos de funcionamiento de este tipo, y en cuestión de minutos puedes tener un enlace LoRa funcionando. En mi caso, los dispositivos de que dispongo funcionan a 433 MHz, y pude tener comunicación en toda la casa, y en campo abierto pude llegar a establecer sin muchos problemas enlaces de 300 metros con las antenas que traen los dispositivos.

Bien, 300 metros no es gran cosa cuando según el protocolo podemos llegar a decenas de kilómetros. Con estas primeras pruebas pude aprender algunas cosas interesantes:

  • 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.
  • La cantidad de información que transmites importa. Tanto o más que todo lo anterior. A mayor mensaje que trates de enviar, más problemas tendrás para que llegue, debido a posibles interferencias durante el tiempo que estés transmitiendo. Además de esto, pude observar que el RSSI (indicador de fuerza de la señal recibida) se resentía a mayor longitud del mensaje. Así que nada de enviar elegantes datagramas JSON, o largos paquetes de datos. Empaqueta en hexadecimal, transmite los mínimos bytes posibles, y notarás una gran mejora en el rango de alcance de tus sistemas.
  • Optimiza los parámetros de los enlaces en función de lo que busques. Existe la posibilidad de ajustar diversos parámetros de la transmisión. Simplificando mucho, la velocidad de transmisión y el factor de propagación (spreading factor). A una velocidad de transmisión más baja y mayor factor de propagación, más confiable será la entrega del paquete (realizando un símil algo burdo, es como hablar muy despacio y alargando mucho los sonidos), pero necesitarás más tiempo para enviar la misma cantidad de información, por lo que perjudicarás la vida de la batería, y harás más uso de tiempo de señal (lo que en redes LoRa públicas o privadas puede tener su impacto). En mi caso, como se trata de un enlace punto a punto entre dos dispositivos que controlo yo, no tengo que preocuparme demasiado por estos aspectos. Otro parámetro ajustable es la intensidad de la señal emitida (sólo para el emisor), que se puede ajustar hasta 20 dBm, sobre un valor estándar de 14 dBm. De nuevo, a costa de penalizar la duración de la batería.

Tras haber aprendido esto en una serie de pruebas sucesivas, pero en las que no podía verificar el alcance efectivo alcanzado debido al confinamiento, me preparé para hacer una verdadera prueba de campo, en cuanto tuviera la oportunidad. Y la oportunidad llegó hoy. Al haberse permitido salir a realizar actividades deportivas por la mañana, preparé un escenario de prueba que pudiera efectuar mientras -cómo no- saliera a dar una vuelta con la bici por los alrededores de mi domicilio. La prueba consistió en lo siguiente:

  • Preparar un emisor LoRa que pudiera colocar en la bici. Me aburrí bastante pronto de enviar simples secuencias numéricas desde el emisor al receptor. Y dado que los Heltec LoRa son ESP32, con capacidad BLE, desarrollé un aplicativo que permite leer de mi pulsómetro Bluetooth mi ritmo cardíaco, y cada 2 segundos enviarlo empaquetado en hexadecimal, con lo que se puede enviar haciendo uso de tan sólo 2 bytes de información. Para colocarlo cómodamente en la bicicleta, imprimí una carcasa con la impresora 3D que se puede atornillar al manillar. Complementé el emisor con una antena de 7 dBi para 433 MHz, que instalé en el transportín de la bici.
  • Bicicleta con antena y Heltec instalados

    Bicicleta con antena y Heltec instalados

  • Crear un gateway LoRa-MQTT como receptor. La otra mitad del sistema, el receptor, actúa como una pasarela LoRa-MQTT. Se conecta a la red WiFi de mi casa, y vuelca la información recibida por LoRa en mi servidor MQTT, en un topic específico. Además de la información LoRa (decodificada para ofrecer el ritmo cardíaco de nuevo en decimal), añade el RSSI del paquete recibido, para poder verificar de manera sencilla la calidad de la recepción de la señal. De acuerdo a la documentación de LoRa, cualquier cosa peor de -120 dBm implica recibir una señal débil, y por encima de -30 dBm es excelente (el máximo teórico es 0). En mis pruebas, observaba problemas para recibir paquetes cuando el RSSI caía por debajo de -125 dBm.
  • Colocar la antena del receptor en una buena ubicación. Como decíamos antes, la antena y su ubicación importan, también en el receptor. Mi casa se encuentra en el valle del Guadalquivir, en una zona que no es especialmente alta. Lo ideal sería colocarla en lo más alto del tejado, donde hay pocos elementos que bloqueen la vista, y por tanto puedas tener visión directa de los alrededores. Pero no andaba estos días con muchas ganas de andar triscando por los tejados, y de todas maneras tengo un inconveniente en forma de colinas. La colina de Itálica por un lado, que me bloquea gran parte de los campos cercanos por el oeste, y el cerro de Santiponce, al suroeste que hace lo mismo en esa dirección. Así que me he limitado a colocar la antena en la azotea, con vistas razonablemente limpias hacia el norte, este y sureste. No del todo limpias, porque el edificio de pisos que hay junto al teatro de Itálica bloquea gran parte de la visión directa de la ciudad de Sevilla (en otro artículo hablaremos de ello). Pero para pruebas de campo en los alrededores, más que suficiente.
  • Antena del gateway

    Antena del gateway

  • Disponer de un cliente MQTT para verificar la información recibida. Esta parte era sencilla. Un teléfono Android con un cliente MQTT convencional vale perfectamente. Junto con un soporte de móvil para bicicleta, basta para tener toda la información delante de tus ojos.
  • Heltec LoRa 32 con carcasa impresa en 3D

    Heltec LoRa 32 con carcasa impresa en 3D

  • Salir y empezar a rodar. Ironías de la vida, lo más complicado de todo, durante estas jornadas. Ha sido preciso esperar al 2 de mayo para poder hacer la prueba.
Bicicleta utilizada durante las pruebas

Bicicleta utilizada durante las pruebas

Los resultados de la prueba han sido espectaculares. En dirección norte he logrado un enlace de 5.3 km de distancia, sin visibilidad directa con Santiponce, debido a las ondulaciones del terreno. Esto representa casi el doble del alcance que indica el fabricante para este tipo de dispositivos. Si bien esta ha sido la mayor distancia que ha alcanzado un paquete, una señal confiable, sin pérdida apreciable de paquetes, la he conseguido a 4.5 km de distancia, igualmente sin visibilidad directa.

Enlace logrado hacia el norte

Enlace logrado hacia el norte

Hacia el sureste, he alcanzado de manera confiable los 4.2 km de distancia en el enlace, en el mismísimo puente de la SE-30 sobre la Guadalquivir, junto al Estadio Olímpico.

Enlace logrado hacia el sureste

Enlace logrado hacia el sureste

Es probable que la señal pudiera llegar más allá, pero por la configuración del terreno, y porque se alcanzaba el fin del horario establecido para hacer deporte por la mañana, me tocaba volver a casa. También es de reseñar que en esta dirección a gran parte de la zona se encontraba en una sombra de cobertura, ya que las edificaciones de Santiponce, además de los taludes de la autovía y la vía férrea a Huelva se interponían entre ambas antenas, bloqueando la línea directa de visión.

Mapa general de las pruebas

Mapa general de las pruebas

Pero visto lo visto, es bastante posible que a una altura elevada se pueda tener un nivel de recepción decente en la Isla de la Cartuja. Cuando tenga oportunidad, haré pruebas desde la azotea del edificio de GMV, ubicado a 5.2 km de mi receptor.

Durante las pruebas he realizado algunas grabaciones en puntos significativos del recorrido. He compilado las más interesantes en el siguiente vídeo

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

Etiquetas: , , , ,