Skip to main content
Pablo Acosta Cuestas
Fullstack en Python
View all authors

¿Qué tan usable es Meshtastic para personas que no provienen del mundo tecnológico?

· 11 min read

Toda tecnología nueva requiere un proceso de aprendizaje. Sin embargo, algunas herramientas resultan más intuitivas que otras y pueden incorporarse a las tareas cotidianas con mayor facilidad.

Esto nos llevó a plantearnos una pregunta sencilla: ¿qué tan usable es Meshtastic?

Antes de responder, es importante aclarar que la interacción con Meshtastic puede realizarse a través de tres elementos diferentes:

  • El propio dispositivo LoRa que ejecuta el firmware Meshtastic.
  • La aplicación móvil para Android o iOS.
  • El cliente web oficial.

Cada uno de estos componentes ofrece una experiencia de uso distinta y presenta ventajas, limitaciones y desafíos propios. Por este motivo, analizaremos la usabilidad de Meshtastic desde cada una de estas perspectivas.

Para este artículo únicamente tendremos en cuenta las herramientas oficiales del proyecto. Existen clientes desarrollados por terceros, pero su evaluación excede el alcance de este trabajo.

Dispositivo LoRa

Atención

Los nodos de los que se hablará en esta sección son dispositivos comerciales que están listos para su uso, fabricados y distribuídos por marcas especializadas. No se incluirán placas o kits orientados al armado o modificación por parte del usuario (DIY).

La usabilidad del firmware de Meshtastic está fuertemente condicionada por el hardware sobre el cual se ejecuta. A diferencia de otras aplicaciones, donde la experiencia de uso suele ser relativamente uniforme, en Meshtastic dos dispositivos pueden ofrecer formas de interacción muy diferentes aun ejecutando exactamente el mismo firmware.

De manera general, podemos dividir los nodos en dos grandes grupos: dispositivos sin pantalla y dispositivos con pantalla.

Los dispositivos sin pantalla incluyen tanto a los repetidores como a muchos nodos tipo card. En estos casos, la interacción directa con el equipo es limitada y suele reducirse a algunos botones físicos, indicadores luminosos y, en determinados modelos, alertas sonoras.

Esto hace que su funcionamiento diario resulte relativamente sencillo, pero también implica una fuerte dependencia de la aplicación móvil o de un computador para realizar configuraciones, consultar información o acceder a funciones avanzadas.

La experiencia de uso puede variar significativamente entre modelos. Algunos dispositivos comunican de manera clara su estado mediante luces, sonidos o vibraciones, mientras que en otros casos puede resultar más difícil interpretar qué está ocurriendo si no se conoce previamente el significado de cada indicador. Por este motivo, la consulta de los manuales de uso continúa siendo importante para aprovechar correctamente las capacidades de cada nodo.

Desde nuestro punto de vista, los dispositivos sin pantalla presentan una curva de aprendizaje baja para las tareas básicas de uso cotidiano, pero dependen casi por completo de la aplicación móvil para acceder a la mayor parte de las funcionalidades que ofrece Meshtastic.

Los nodos con pantalla presentan una experiencia de uso diferente. Aunque todos ejecutan Meshtastic, existen diferencias importantes entre modelos, ya sea por el tipo de pantalla utilizada, la cantidad de botones disponibles o la interfaz implementada por cada fabricante.

En líneas generales, estos dispositivos ofrecen un mayor grado de independencia respecto del teléfono o la computadora. Es posible consultar mensajes, modificar configuraciones básicas, habilitar o deshabilitar funciones como Bluetooth o GPS e incluso navegar por diferentes menús directamente desde el nodo.

La facilidad de uso depende en gran medida de cómo se haya implementado la interfaz. Factores como el idioma disponible, la organización de los menús, el tamaño de la pantalla y la cantidad de botones influyen directamente en la experiencia del usuario.

Por ejemplo, algunos dispositivos disponen de varios botones dedicados a la navegación, mientras que otros utilizan un único botón para recorrer los menús y ejecutar acciones, lo que puede requerir una adaptación inicial por parte del usuario.

A pesar de estas diferencias, nuestra experiencia indica que la mayoría de los nodos con pantalla resultan relativamente sencillos de utilizar para las tareas básicas. Con un breve período de práctica es posible familiarizarse con las funciones más habituales, incluso cuando la interfaz se encuentra únicamente en inglés.

Sin embargo, aunque estos dispositivos permiten operar de forma autónoma en determinadas situaciones, siguen sin ofrecer el mismo nivel de comodidad, velocidad y cantidad de opciones que la aplicación móvil. Por este motivo, consideramos que la pantalla del nodo debe entenderse como un complemento útil y no como un reemplazo completo de la aplicación.

Durante nuestras pruebas también llegamos a una conclusión que consideramos importante desde el punto de vista de la usabilidad: no siempre disponer de más opciones implica una mejor experiencia de uso.

En contextos donde el usuario debe concentrarse en una tarea principal, como ocurre durante el combate de incendios, creemos que resulta conveniente que exista un único camino claramente definido para realizar cada acción.

Por este motivo, nuestra tendencia actual es utilizar el nodo principalmente como dispositivo de transmisión y recepción, mientras que la configuración, lectura y redacción de mensajes se realizan desde la aplicación móvil. Esta separación reduce la posibilidad de errores y simplifica el proceso de aprendizaje para nuevos usuarios.

App móvil

Si tuviéramos que señalar cuál es el componente más accesible de todo el ecosistema Meshtastic, probablemente sería la aplicación móvil.

Uno de sus principales puntos a favor es que se encuentra traducida al español en gran parte de su interfaz, algo que reduce considerablemente la barrera de entrada para nuevos usuarios. Además, la aplicación organiza sus funciones en apartados relativamente claros: conversaciones, contactos, mapa, ajustes y conexiones.

La navegación general resulta sencilla y, en líneas generales, las funciones más utilizadas suelen encontrarse donde el usuario espera encontrarlas. Particularmente, creemos que las últimas versiones han mejorado la organización de muchas opciones de configuración, facilitando la localización de parámetros que anteriormente resultaban más difíciles de encontrar.

Sin embargo, no todas las modificaciones recientes han mejorado la experiencia de uso.

Uno de los apartados que consideramos menos intuitivos es el de Conexiones, generando confusión es la selección de dispositivos Bluetooth. La aplicación mantiene visibles los nodos a los que el usuario se conectó anteriormente, independientemente de que se encuentren encendidos o disponibles en ese momento.

Técnicamente es posible distinguir los dispositivos disponibles observando el valor RSSI, ya que únicamente los nodos detectados activamente mostrarán este parámetro. Sin embargo, esta información puede pasar desapercibida para usuarios sin experiencia o para quienes desconocen el significado de dicho indicador. A medida que aumenta la cantidad de nodos almacenados, puede resultar difícil identificar rápidamente cuál es el dispositivo al que se desea conectar.

A pesar de estas observaciones, consideramos que la aplicación móvil posee una curva de aprendizaje relativamente baja. La mayoría de los usuarios logra familiarizarse con sus funciones principales en poco tiempo y, una vez comprendida la lógica general de funcionamiento, el resto de las opciones suele descubrirse de manera progresiva.

Como posible mejora, creemos que sería interesante incorporar un sistema de ayuda inicial o un modo de asistencia para primeros usuarios. Una serie de explicaciones breves o consejos contextuales podría facilitar enormemente la adopción de la herramienta sin necesidad de consultar documentación externa.

Por último, aunque existen diferencias visuales y de organización entre las versiones para Android e iOS, no consideramos que esto represente un problema significativo de usabilidad. La mayoría de los usuarios aprenderá a utilizar una única plataforma y, en caso de cambiar posteriormente de sistema operativo, gran parte del conocimiento adquirido seguirá siendo aplicable.

Cliente Web oficial

El cliente web oficial de Meshtastic es, probablemente, el componente menos maduro de los tres que analizamos en este artículo. Aunque comparte gran parte de las funcionalidades presentes en la aplicación móvil, la experiencia general todavía transmite la sensación de encontrarse en una etapa de desarrollo más temprana.

Uno de los problemas más notorios que encontramos está relacionado con la gestión de dispositivos conectados. Durante nuestras pruebas observamos que, si un nodo se reinicia o se apaga, es frecuente encontrarse con errores al intentar reconectarlo. En algunos casos aparece el mensaje:

Failed to execute 'open' on 'SerialPort': Failed to open serial port.

Si bien el problema puede resolverse reconectando el dispositivo o volviendo a autorizar el puerto, desde el punto de vista de la usabilidad resulta una situación confusa para usuarios sin experiencia técnica.

La gestión de dispositivos guardados también presenta inconvenientes. Es posible almacenar múltiples veces un mismo nodo utilizando el mismo puerto serial e incluso asignándole distintos nombres. Además, si una conexión deja de funcionar, el registro permanece guardado sin ningún tipo de advertencia. Esto puede provocar situaciones donde varios perfiles parecen estar conectados simultáneamente cuando en realidad corresponden al mismo dispositivo físico.

Otro aspecto que consideramos mejorable es la persistencia de la información. Al recargar la página se pierde gran parte del contexto de trabajo, incluyendo los mensajes intercambiados durante la sesión. Esto obliga al usuario a reconstruir parte de la información cada vez que vuelve a abrir el cliente.

Un aspecto positivo es la existencia de soporte para múltiples idiomas. La infraestructura parece estar preparada para futuras traducciones, algo que valoramos especialmente. Sin embargo, al momento de realizar esta evaluación el español todavía no se encuentra disponible, lo que puede representar una barrera adicional para nuevos usuarios.

En términos generales, la organización de las opciones resulta familiar para quienes ya utilizan la aplicación móvil. La mayoría de las configuraciones mantienen una lógica similar, aunque algunas funciones se encuentran ubicadas en lugares diferentes. Por ejemplo, compartir un código QR con la configuración de canales se realiza desde la sección de conversaciones en Android, mientras que en el cliente web esta opción se encuentra dentro de la configuración de canales.

La gestión de canales es funcional y permite generar claves automáticamente o seleccionar distintos niveles de longitud para las mismas. Sin embargo, observamos que cierta información relacionada con la seguridad de los canales no resulta tan visible como en otras interfaces, algo que podría ayudar a los usuarios a comprender mejor las implicancias de participar en determinados canales públicos o privados.

También valoramos la presencia de un buscador de configuraciones. A medida que Meshtastic incorpora nuevas funcionalidades, localizar rápidamente una opción específica se vuelve cada vez más importante y esta herramienta simplifica considerablemente dicha tarea.

Por otra parte, encontramos algunas limitaciones funcionales. Durante nuestras pruebas no encontramos la posibilidad de crear o compartir puntos de interés desde el mapa, una característica que sí consideramos especialmente útil en la aplicación móvil. Dado que el cliente web suele utilizarse en pantallas considerablemente más grandes, creemos que podría ser un entorno muy adecuado para trabajar con información geográfica de forma más cómoda y detallada.

Respecto a la conectividad, la experiencia puede variar según el sistema operativo y el navegador utilizado. En nuestro caso, utilizando una Lenovo ThinkPad T470s con Linux Mint Cinnamon, no fue posible utilizar conexiones Bluetooth debido a que el navegador indicaba que Web Bluetooth no estaba soportado. Esto no necesariamente constituye una limitación de Meshtastic, pero sí afecta la experiencia general de uso del cliente web.

Tampoco encontramos una opción equivalente a la función de compartir la ubicación del teléfono presente en la aplicación móvil. Aunque probablemente no sea una necesidad habitual en equipos de escritorio o portátiles, sí creemos que podría resultar útil disponer de mecanismos más simples para establecer o actualizar ubicaciones desde esta interfaz.

En definitiva, cualquier usuario familiarizado con la aplicación móvil podrá adaptarse relativamente rápido al cliente web. La lógica general de funcionamiento es similar y la curva de aprendizaje no resulta particularmente elevada. Sin embargo, también es el componente donde más margen de mejora encontramos. Actualmente cumple adecuadamente para tareas de configuración y administración, pero todavía presenta aspectos de usabilidad que podrían refinarse para ofrecer una experiencia más sólida y consistente con el resto del ecosistema Meshtastic.

Conclusión

La usabilidad de Meshtastic no depende exclusivamente del firmware o de la aplicación móvil, sino de la interacción entre ambos. Un mismo firmware puede ofrecer experiencias muy diferentes según el hardware utilizado.

Actualmente consideramos que la aplicación móvil constituye la interfaz más madura y accesible del ecosistema, mientras que el nodo cumple principalmente el rol de proporcionar conectividad LoRa.

Desde nuestra perspectiva, la experiencia de uso más consistente se obtiene cuando cada componente cumple una función claramente definida: el nodo como medio de comunicación y la aplicación como interfaz principal de interacción.

Como toda tecnología en evolución, Meshtastic todavía presenta oportunidades de mejora. Sin embargo, el nivel de desarrollo alcanzado actualmente permite que usuarios sin conocimientos técnicos avanzados puedan aprender a utilizarla y beneficiarse de sus capacidades con un período de adaptación relativamente breve.

El problema de flashear nodos ubicados en posiciones estratégicas

· 11 min read

El proceso de actualización del firmware es importante para todos los nodos y, en dispositivos portátiles, suele ser relativamente sencillo de realizar. Sin embargo, la situación cambia cuando hablamos de nodos instalados en puntos estratégicos y elevados con el objetivo de ampliar la cobertura de la red.

Dejar un nodo con la última versión disponible del firmware al momento de instalarlo es relativamente sencillo. El problema aparece cuando necesitamos actualizarlo después de su instalación, ya que acceder físicamente al dispositivo puede requerir desplazarse hasta el lugar donde se encuentra e incluso realizar tareas de ascenso.

Actualmente, tampoco consideramos necesario realizar este procedimiento cada vez que aparece una nueva versión. Hasta el momento, ninguna de las versiones estables que hemos utilizado nos ha impedido comunicar nodos que ejecutan versiones anteriores. Desde que comenzamos nuestras pruebas, hemos trabajado principalmente con las versiones estables 2.6.9, 2.7.15 y 2.7.26, siendo esta última la que utilizamos actualmente.

Aun así, consideramos que la actualización de nodos instalados en ubicaciones de difícil acceso es un problema que merece ser estudiado. Por este motivo, hemos evaluado dos posibles alternativas para realizar el procedimiento sin necesidad de retirar el nodo de su ubicación: Bluetooth y conexión serial.

Alcance de las pruebas

Todos los procedimientos de flasheo descritos en este artículo fueron realizados y comprobados utilizando dispositivos Android. Los procedimientos mediante iOS no han sido probados por nuestro equipo, por lo que no podemos asegurar su funcionamiento en este sistema operativo.

Flasheo vía Bluetooth

Nivel avanzado

El contenido de este apartado requiere conocimientos técnicos adicionales a los procedimientos habituales de actualización. Si no estás familiarizado con el modo DFU y el funcionamiento del flasheo OTA, recomendamos utilizar el procedimiento vía serial explicado más adelante.

El flasheo OTA (Over-The-Air) permite actualizar el firmware de determinados dispositivos de forma inalámbrica, utilizando Bluetooth Low Energy (BLE), sin necesidad de conectar físicamente el nodo a una computadora.

Para explorar esta posibilidad tuvimos en cuenta dos alternativas: la última versión de la aplicación Meshtastic para Android, obtenida desde el repositorio oficial de GitHub de la aplicación, y la aplicación nRF Connect, desarrollada por Nordic Semiconductor, fabricante de los microcontroladores nRF52 utilizados por algunos de los nodos que forman parte de nuestras pruebas, como el SenseCAP Solar Node P1 y el ThinkNode M6.

Aplicación Meshtastic

Con el flasheo desde la aplicación de Meshtastic no hemos obtenido buenos resultados. La primera vez que intentamos utilizar esta opción, hace aproximadamente ocho meses, lo hicimos debido a nuestra inexperiencia y sin conocer las limitaciones del procedimiento. Como consecuencia, tuvimos que desmontar el dispositivo, desconectar la batería, realizar el flasheo mediante otra vía y volver a ensamblarlo.

Decidimos repetir la experiencia utilizando la última versión de la aplicación disponible desde GitHub. En esta ocasión observamos una diferencia importante respecto de aquella primera experiencia: la aplicación consigue colocar el nodo en modo DFU, pero posteriormente no logra completar el proceso.

Nuestra hipótesis es que, una vez que el nodo entra en modo DFU, se pierde la conexión Bluetooth y la aplicación deja de poder comunicarse con el dispositivo, impidiendo que el proceso de actualización continúe.

Sin embargo, este comportamiento nos permitió encontrar una alternativa que resultó útil para continuar el procedimiento: una vez que el nodo se encuentra en modo DFU, es posible conectarlo a una computadora y continuar el proceso desde el Web Flasher de Meshtastic, como si se hubiera puesto el dispositivo en DFU mediante el procedimiento habitual.

Al finalizar el procedimiento, el nodo vuelve a funcionar con normalidad. No obstante, no podemos afirmar que este haya sido el comportamiento que observamos durante nuestro primer intento, ya que aquella experiencia no fue registrada adecuadamente y nuestros recuerdos de ese momento, sumados a la poca experiencia que teníamos entonces, no son suficientes para establecer una conclusión.

Aplicación nRF Connect

La segunda alternativa que estamos evaluando consiste en realizar el proceso mediante nRF Connect, una herramienta de Nordic Semiconductor.

El procedimiento es diferente al utilizado mediante la aplicación de Meshtastic, principalmente porque requiere trabajar con un archivo de firmware en formato .zip. Esto también implica una diferencia respecto del procedimiento de actualización mediante Web Flasher que hemos utilizado habitualmente, donde para los dispositivos nRF52 trabajamos con archivos .uf2.

Para realizar esta prueba es necesario obtener el archivo correspondiente a la versión estable del firmware desde el repositorio de GitHub de Meshtastic. En nuestro caso, descargamos el archivo firmware-nrf52840-2.7.26.54e0d8d.zip y, dentro de este archivo, buscamos el firmware correspondiente al dispositivo que estamos utilizando.

Como la prueba se está realizando con un WioTracker L1 Pro, el archivo correspondiente es:

firmware-seeed_wio_tracker_L1-2.7.26.54e0d8d-ota

Con todos los elementos necesarios preparados, nos enlazamos desde la aplicación con el nodo. Luego nos dirigimos a la configuración y ajustamos la cantidad de paquetes a 8, ya que lo más probable es que esta opción aparezca configurada en 10.

Es importante destacar que esta no es una sugerencia propia. Al buscar información sobre el procedimiento, encontramos un blog de MeshCore que realiza esta recomendación y, además, en conversaciones con la comunidad de Discord recibimos la misma sugerencia.

Luego nos dirigimos a nuestro dispositivo y veremos, en la parte superior de la pantalla, una opción que dice DFU. Al seleccionarla aparecerá un menú con cuatro opciones. En este caso utilizaremos Distribution packet (ZIP), que suele estar seleccionada por defecto.

Después de presionar OK, la aplicación nos permitirá buscar el archivo de firmware. Una vez localizado y seleccionado, comenzará el proceso de actualización, que puede demorar varios minutos. Durante este tiempo podremos observar el progreso y la velocidad a la que se realiza el proceso.

Una vez finalizado, el nodo se reiniciará y volverá a conectarse automáticamente con la aplicación.

Podremos comprobar si el proceso se realizó correctamente de dos maneras. Si el nodo cuenta con pantalla, al iniciarse mostrará la versión del firmware que tiene instalada. También podemos comprobarlo desde la aplicación, ingresando en Device Information → Firmware Revision String, donde se mostrará la versión del firmware instalada.

Es importante aclarar que el flasheo de dispositivos mediante OTA es posible, pero existen varias advertencias respecto de este procedimiento, ya que un fallo durante la actualización podría brickear el nodo.

Nuestros resultados no fueron esos. A través de la aplicación de Meshtastic, el proceso simplemente quedó detenido en el modo DFU, situación que pudimos resolver con facilidad conectando posteriormente el nodo a una PC y continuando el proceso de actualización. En cambio, mediante la aplicación nRF Connect pudimos completar el procedimiento correctamente.

A pesar de estos resultados, por el momento no creemos que valga la pena asumir el riesgo de realizar una actualización mediante alguna de estas dos vías. Entendemos que mantener actualizado el firmware es importante, pero no consideramos que sea imprescindible realizarlo mediante OTA.

Por este motivo, recomendamos utilizar el procedimiento que explicamos en el siguiente apartado o recurrir al Meshtastic Web Flasher. Si aún así se decide realizar la actualización mediante OTA, es importante hacerlo teniendo en cuenta los riesgos asociados al procedimiento.

Si en el futuro encontramos mejoras significativas en alguno de estos procesos, las documentaremos y compartiremos los resultados en una nueva actualización.

Flasheo vía serial

La conexión serial es, hasta el momento, la alternativa que consideramos más práctica para actualizar un nodo instalado en una ubicación de difícil acceso. Sin embargo, creemos que no es necesario realizar este procedimiento cada vez que aparece una nueva versión estable del firmware.

Nuestra recomendación inicial es evaluar la necesidad de actualizar el nodo y, salvo que exista un motivo concreto para hacerlo antes, considerar la actualización cada dos o tres versiones estables. Esto podría representar aproximadamente una o dos intervenciones por año, aunque la frecuencia dependerá de la evolución del firmware y de las necesidades de cada instalación.

Esta recomendación busca reducir la cantidad de intervenciones necesarias sobre los nodos instalados en lugares de difícil acceso. Cada organización podrá, naturalmente, establecer una frecuencia diferente si considera necesario mantener sus equipos permanentemente actualizados.

Existe, además, una excepción importante: cuando una nueva versión introduce cambios incompatibles (breaking changes) que impiden la comunicación con otros nodos de la red, o cuando incorpora una funcionalidad que resulte especialmente necesaria para la operación. En esos casos, puede estar justificado realizar la actualización independientemente del intervalo establecido.

Nuestra propuesta es evitar, siempre que sea posible, desmontar el nodo o trasladarlo hasta una computadora para realizar el procedimiento. En los dispositivos compatibles, el objetivo es llevar el firmware hasta el lugar donde se encuentra instalado el nodo y realizar allí la actualización utilizando un teléfono.

El procedimiento que hemos planteado es el siguiente. Antes de desplazarse hasta el nodo, recomendamos llevar un nodo portátil adicional que permita comprobar la comunicación con el repetidor una vez finalizada la actualización. De esta manera, no será necesario depender únicamente de la información que muestra el propio dispositivo para verificar que el nodo volvió a integrarse correctamente en la red.

  1. Identificar el nodo que debe actualizarse y descargar previamente en el teléfono el archivo de firmware correspondiente en formato .uf2.
  2. Llevar un cable USB-C a USB-C que permita la transferencia de datos. Es recomendable comprobar su funcionamiento antes de desplazarse hasta el nodo.
Recomendación

Si el acceso al nodo requiere desplazarse por zonas elevadas, pendientes o terrenos irregulares, recomendamos utilizar una correa, cordón o sistema similar para asegurar el teléfono. Esto permite mantener las manos libres y reduce el riesgo de que el dispositivo se caiga durante el procedimiento.

  1. Una vez en el lugar donde se encuentra instalado el nodo, acceder al dispositivo.
  2. Poner el nodo en modo DFU presionando dos veces consecutivas el botón RST (Reset).
  3. Conectar el cable USB al nodo.
  4. Conectar el otro extremo del cable al teléfono. Dependiendo del modelo y del sistema operativo, puede ser necesario habilitar o autorizar la transferencia de datos mediante USB. El nodo debería aparecer como una unidad de almacenamiento.
  5. Buscar el archivo de firmware descargado previamente y copiarlo a la unidad correspondiente al nodo.
  6. Esperar a que el nodo complete el proceso y se reinicie. Una vez iniciado nuevamente, conectarse a él mediante la aplicación Meshtastic, ya sea por conexión serial o Bluetooth, y comprobar que funciona correctamente.
  7. Si el procedimiento se completó correctamente, puede retirarse del lugar. Si no fue posible actualizarlo, puede intentarse nuevamente. Si el segundo intento tampoco resulta exitoso, recomendamos retirar el nodo y realizar el procedimiento mediante una computadora.
El proceso no funciona en todos los Andriod

Durante nuestras pruebas pudimos completarlo correctamente utilizando un Xiaomi POCO X6 Pro 5G, mientras que no fue posible realizarlo con un Samsung Galaxy S21 FE.

Por este motivo, recomendamos probar previamente el procedimiento con un nodo en un entorno controlado, antes de intentar actualizar un nodo instalado en una ubicación de difícil acceso. De esta manera, podrá comprobar si el teléfono reconoce correctamente algún dispositivo LoRa con chip nRF52 en modo DFU y permite copiar el archivo de firmware.

No recomendamos realizar la primera prueba directamente sobre un nodo instalado en altura o en un lugar de difícil acceso.

Conclusiones

Actualizar el firmware de un nodo instalado en una ubicación de difícil acceso presenta desafíos que no existen en los dispositivos portátiles. Por este motivo, consideramos importante evaluar alternativas que permitan realizar el procedimiento sin necesidad de desmontar el equipo.

Las pruebas realizadas nos permitieron comprobar que existen alternativas para actualizar un nodo de forma inalámbrica mediante Bluetooth, aunque por el momento consideramos que el riesgo asociado al proceso OTA no justifica su utilización como método habitual. En cambio, la actualización mediante conexión serial nos resulta una alternativa más práctica para los dispositivos compatibles, ya que permite trasladar el procedimiento hasta el lugar donde se encuentra instalado el nodo.

También consideramos importante no convertir la actualización del firmware en una tarea rutinaria. Mientras las versiones continúen siendo compatibles entre sí, creemos que tiene más sentido evaluar la necesidad de actualizar y realizar el procedimiento cuando exista un motivo concreto para hacerlo.

Este proceso de experimentación todavía no está cerrado. Continuaremos evaluando las distintas alternativas y, a medida que obtengamos nuevos resultados o encontremos mejoras en los procedimientos, publicaremos nuevas experiencias.

Guía de Meshtastic para el combate contra el fuego

· 2 min read

A partir del trabajo de investigación, las pruebas realizadas y las experiencias compartidas junto a brigadas de combate de incendios forestales, desarrollamos una guía orientada a quienes quieran conocer y comenzar a utilizar Meshtastic en este tipo de contextos.

Una guía para comenzar

El material reúne desde los conceptos básicos sobre Meshtastic y los dispositivos compatibles hasta la configuración inicial de los nodos, el uso de la aplicación móvil, la gestión de canales, el intercambio de ubicaciones, la actualización del firmware y los distintos roles que pueden cumplir los dispositivos dentro de una red.

El objetivo no es presentar una configuración única para todas las situaciones, sino brindar un punto de partida que permita comprender la tecnología, experimentar con ella y evaluar de qué manera puede complementar las herramientas de comunicación utilizadas en el terreno.

Descargar la guía

La guía se encuentra disponible en formato PDF para su consulta y descarga.

📄Descargar la Guía de Meshtastic para el combate contra el fuego (PDF)

Esta guía refleja el estado actual de nuestras pruebas y conocimientos. Meshtastic continúa evolucionando, por lo que algunos procedimientos o configuraciones pueden cambiar con el tiempo.

El PDF se mantendrá actualizado a medida que avancemos con nuevas pruebas, descubramos nuevos usos o sea necesario modificar los procedimientos documentados. Nuestro objetivo es que esta guía se convierta en una fuente de referencia que acompañe el desarrollo y las futuras actualizaciones de nuestro trabajo con Meshtastic.

¿Cómo implementar Meshtastic en el combate de incendios?

· 11 min read

La tecnología Meshtastic junto al protocolo LoRa tiene muchas potencialidades. Sin embargo, una vez superado el entusiasmo inicial, surge una pregunta fundamental:

¿Cómo implementamos esta tecnología en un contexto real de combate de incendios?

La respuesta parece sencilla hasta que comenzamos a profundizar en el problema. ¿Qué dispositivos deberían utilizarse? ¿Quiénes van a utilizarlos? ¿Qué funciones debería cumplir cada uno? ¿Cómo se integra esta tecnología con los métodos de trabajo ya existentes?

En este artículo compartiremos parte del proceso que nos llevó a replantear varias de nuestras ideas iniciales y a formular nuevas preguntas que todavía estamos intentando responder.

Ilustración del problema de implementación de Meshtastic

****

Nuestra postura inicial

En un principio creíamos que cada combatiente debía portar un nodo Meshtastic. La idea parecía lógica: permitir que todos pudieran comunicarse entre sí y, al mismo tiempo, conocer la ubicación de cada integrante de la brigada ante cualquier eventualidad.

También asumimos que el dispositivo ideal debía contar con pantalla. De esta forma, cada combatiente podría leer mensajes y enviar respuestas predefinidas directamente desde el propio nodo.

Otra de nuestras preocupaciones era el uso de los equipos con guantes. Considerábamos que un combatiente no debería verse obligado a quitarse elementos de protección para utilizar una herramienta de comunicación. Bajo esa premisa, nos preguntábamos si este tipo de dispositivos serían realmente prácticos durante una intervención.

Con el tiempo descubrimos que algunas de estas suposiciones eran correctas y otras no tanto.

La charla con una brigada de combatientes del fuego

La conversación con la brigada de Chiviquín resultó reveladora.

Nos permitió obtener un panorama mucho más cercano a la realidad operativa y contrastar varias de nuestras ideas con la experiencia de quienes efectivamente combaten incendios.

Por ejemplo, descubrimos que los combatientes no siempre mantienen colocados los guantes durante toda la operación. Aunque desde el punto de vista de la seguridad esto no sea lo ideal, la realidad es que muchas tareas requieren interactuar con herramientas y aplicaciones que ya forman parte de su trabajo cotidiano.

También observamos que aplicaciones como WhatsApp u OruxMaps forman parte de las herramientas que utilizan para coordinar actividades, compartir información y orientarse en el terreno.

Esta conversación nos ayudó a comprender que el problema no debía analizarse únicamente desde las características técnicas del hardware, sino también desde las prácticas reales de quienes lo utilizarían.

Cambiando de perspectiva

Para ese momento ya habíamos adquirido y probado gran parte de los dispositivos que inicialmente habíamos considerado para el proyecto.

A medida que acumulábamos experiencia con diferentes modelos y contrastábamos nuestras observaciones con la realidad operativa de los brigadistas, comenzamos a cuestionar otra de nuestras ideas iniciales: la necesidad de que todos los combatientes utilizaran nodos con pantalla.

Si bien las pantallas ofrecen ventajas evidentes, los dispositivos tipo tarjeta comenzaron a parecer una alternativa más adecuada dentro de las opciones disponibles actualmente en el mercado. Son más compactos, livianos, simples de transportar y, en algunos casos, cuentan con certificaciones de protección que resultan especialmente interesantes para entornos exigentes.

También comenzamos a considerar que, independientemente del nodo utilizado, resulta difícil evitar por completo el uso del teléfono móvil. Sin embargo, creemos que Meshtastic tiene el potencial de reducir la cantidad de aplicaciones necesarias durante una operación.

Actualmente muchos combatientes recurren a herramientas como WhatsApp para la comunicación y OruxMaps para la navegación y visualización de información geográfica. En teoría, Meshtastic reúne parte de estas capacidades en una única aplicación, permitiendo intercambiar mensajes y utilizar un mapa compartido dentro de la misma plataforma.

No obstante, todavía observamos algunas limitaciones importantes. Por ejemplo, actualmente Meshtastic no permite intercambiar imágenes ni mensajes de voz, recursos que suelen utilizarse con frecuencia durante las operaciones. Del mismo modo, aunque las capacidades de mapa resultan muy útiles, todavía existen herramientas y funcionalidades presentes en aplicaciones especializadas como OruxMaps que podrían complementar significativamente la experiencia de uso.

Por este motivo, más que considerar a Meshtastic como un reemplazo completo de estas herramientas, lo vemos como una tecnología con un enorme potencial y un amplio margen de evolución para adaptarse mejor a las necesidades del terreno.

Sin embargo, esta conclusión vino acompañada de otra observación importante: creemos que ninguno de los dispositivos disponibles actualmente fue diseñado específicamente para el combate de incendios.

Desde nuestra perspectiva, todavía existen necesidades que el hardware actual no cubre completamente. Algunas de ellas podrían resolverse con pantallas más grandes, botones físicos de mayor tamaño, sistemas de ingreso de texto más eficientes o diseños mejor adaptados al uso con elementos de protección personal.

Naturalmente, un cambio de hardware de este tipo también requeriría adaptaciones en el firmware para aprovechar adecuadamente las nuevas capacidades.

Nuestra conclusión actual

Luego de las pruebas realizadas, de las conversaciones con brigadistas y de la experiencia acumulada utilizando diferentes dispositivos, hemos llegado a algunas conclusiones que, aunque todavía pueden cambiar con futuras pruebas, hoy orientan nuestra forma de pensar esta tecnología.

La primera es que no creemos que exista un kit universal para el combate de incendios. Cada brigada opera en terrenos diferentes, con necesidades distintas y bajo condiciones que pueden variar enormemente de una región a otra.

Particularmente, creemos que el relieve del terreno tiene una influencia determinante en el desempeño de las comunicaciones LoRa. Nuestra experiencia hasta el momento indica que la presencia de elevaciones, quebradas o montañas afecta mucho más a las comunicaciones que la vegetación. Por este motivo, no consideramos adecuado definir una cantidad fija de nodos repetidores para todas las situaciones.

Creemos que cada brigada debería estudiar el territorio donde opera habitualmente y planificar la cantidad y ubicación de los repetidores en función de ese análisis. Desde nuestra perspectiva, la infraestructura de la red debe adaptarse al terreno y no al revés.

También consideramos que la información de posición tiene un enorme valor operativo. Aunque algunas brigadas nos han manifestado que sus integrantes rara vez se separan durante una intervención, creemos que las situaciones imprevistas forman parte de cualquier emergencia. Poder conocer la última ubicación reportada por un combatiente puede aportar información valiosa cuando las cosas no salen según lo planificado.

Por este motivo, actualmente nos inclinamos por la idea de que cada combatiente disponga de su propio nodo. Dentro de las opciones disponibles hoy en el mercado, los dispositivos tipo card son los que mejor se adaptan a esta función debido a su tamaño, peso y simplicidad de uso.

Al mismo tiempo, no creemos que Meshtastic deba asumir hoy el rol de sistema principal de comunicaciones. La tecnología todavía presenta limitaciones importantes y no consideramos prudente depender exclusivamente de ella en situaciones donde la seguridad de las personas está en juego.

Sin embargo, sí creemos que puede convertirse en una herramienta complementaria de enorme valor. La posibilidad de compartir ubicaciones, mensajes y otra información operativa puede mejorar significativamente la conciencia situacional de los equipos y aportar capacidades que los sistemas tradicionales de comunicación no ofrecen de forma nativa.

Quizás la pregunta de ahora en adelante sea cómo integrar esta tecnología dentro de los procedimientos existentes para aprovechar sus fortalezas sin ignorar sus limitaciones.

Por el momento, esa es la dirección que consideramos más prometedora y sobre la cual continuaremos realizando pruebas, desarrollando materiales de capacitación y dialogando con brigadas que nos ayuden a seguir aprendiendo.

¿Por dónde comenzar?

A lo largo de este artículo hemos argumentado que no creemos que exista un kit universal para el combate de incendios. Las necesidades de cada brigada dependen del terreno, la cantidad de personal disponible, el área de cobertura requerida y los procedimientos de trabajo propios de cada organización.

Sin embargo, también entendemos que quienes se acercan por primera vez a esta tecnología necesitan un punto de partida. Por ese motivo, proponemos dos configuraciones iniciales que pueden servir como referencia para comenzar a experimentar y adquirir experiencia operativa.

Kit mínimo

Pensado para brigadas que desean realizar las primeras pruebas de campo con la menor inversión posible.

  • 1 nodo portátil tipo tarjeta por cuadrilla.
  • 1 nodo portátil tipo tarjeta para la base de operaciones.
  • 1 nodo repetidor.

En este escenario, el nodo portátil de cada cuadrilla sería utilizado por su responsable para intercambiar mensajes y compartir información operativa, mientras que el nodo asignado a la base permitiría mantener la coordinación entre las distintas cuadrillas. El repetidor tendría como objetivo extender la cobertura y mejorar la conectividad de la red.

Esta configuración no permite conocer la ubicación individual de todos los integrantes, pero sí brinda una primera aproximación al funcionamiento de Meshtastic en un entorno real.

Kit máximo

Pensado para brigadas que buscan obtener el mayor beneficio posible de las capacidades actuales de la tecnología.

  • 1 nodo portátil tipo tarjeta por combatiente.
  • 1 nodo portátil adicional de reserva.
  • 1 nodo portátil tipo tarjeta para la base de operaciones.
  • La cantidad de repetidores necesaria para cubrir el área de operación habitual.
  • 1 repetidor adicional de reserva.

En este modelo, cada combatiente puede transmitir su posición, mientras que el encargado de participar de la red sigue siendo el responsable de las comunicaciones de la cuadrilla, mejorando la conciencia situacional del equipo y permitiendo disponer de información más detallada sobre el despliegue en el terreno.

La cantidad exacta de repetidores no puede definirse de forma general, ya que depende directamente de las características geográficas de la zona. Por este motivo, consideramos indispensable realizar un estudio previo del terreno para determinar cuántos repetidores son necesarios y dónde deberían ubicarse.

Por ejemplo, si una brigada opera habitualmente en una zona donde un único repetidor proporciona cobertura suficiente para una cuadrilla de cinco combatientes, una configuración máxima podría estar compuesta por:

  • 6 nodos portátiles tipo tarjeta (5 operativos y 1 de reserva).
  • 2 repetidores (1 operativo y 1 de reserva).
Propuestas de kits

Nuestra primera experiencia

La propuesta de kit máximo presentada en este artículo representa la dirección hacia la que actualmente creemos que deberían orientarse las futuras implementaciones. Sin embargo, durante nuestra primera capacitación práctica todavía no disponíamos de la cantidad de dispositivos necesaria para equipar a las brigadas siguiendo esa propuesta.

Por este motivo, decidimos adaptar el equipamiento disponible sin perder de vista los objetivos del proyecto. Más que intentar replicar el kit que proponemos, buscamos validar los criterios sobre los cuales fue pensado y seguir obteniendo información que nos permita confirmar o replantear nuestras hipótesis.

Cada una de las tres brigadas recibió un conjunto de dispositivos compuesto por un RAK WisMesh Tag, un Seeed Studio SenseCAP T1000-E, un Meshnology N37 y un Elecrow ThinkNode M1, acompañados por un Seeed Studio SenseCAP Solar Node P1 utilizado como repetidor.

La selección respondió a dos criterios. El primero fue la disponibilidad de equipamiento del proyecto, que todavía no nos permitía entregar un nodo tipo tarjeta a cada combatiente ni disponer de equipos de reserva para cada brigada. El segundo fue la necesidad de continuar evaluando distintos formatos de hardware. Incorporar dispositivos con características diferentes nos permitió contrastar nuestras hipótesis con la experiencia de los combatientes y obtener observaciones sobre aspectos como la portabilidad, la facilidad de uso y la interacción con cada tipo de nodo.

Creemos que este tipo de experiencias son fundamentales para el desarrollo del proyecto. Nuestro objetivo no es validar un dispositivo en particular, sino construir criterios que nos permitan comprender qué características resultan realmente valiosas para el combate de incendios y, a partir de ello, seguir mejorando nuestras recomendaciones sobre cómo implementar esta tecnología en el terreno.


Creemos que este tipo de experiencias son fundamentales para el desarrollo del proyecto. En esta etapa no buscamos validar dispositivos, sino validar criterios que nos permitan comprender qué características resultan realmente valiosas para el combate de incendios.

Todavía nos queda mucho por aprender. Este artículo refleja únicamente el estado actual de nuestras pruebas y conclusiones, por lo que no debe interpretarse como un resultado definitivo. Con el tiempo continuaremos publicando nuevas experiencias, compartiendo los avances del proyecto y actualizando aquellas recomendaciones que la evidencia nos invite a replantear.

Capacitación práctica junto a brigadas de combate del fuego

· 4 min read

El domingo 2 de agosto de 2026 nos reunimos a la ribera del río, en San Isidro (Santa María, Córdoba, Argentina), junto a las brigadas de combatientes del fuego de La Chilca, Chiviquín e Inchín. También contamos con el acompañamiento del equipo de Urgente Cine, quienes registraron la jornada.

El objetivo del encuentro fue brindar una capacitación práctica sobre el uso de dispositivos LoRa con firmware Meshtastic y, al mismo tiempo, conocer las impresiones y necesidades de quienes podrían utilizar esta tecnología en futuras intervenciones.

La capacitación fue organizada en dos encuentros. En este artículo compartiremos la experiencia correspondiente a la primera jornada, que tuvo una duración aproximada de seis horas.

Foto con los asistentes

Participantes de la primera jornada de capacitación práctica de Meshtastic, realizada junto a brigadas de combatientes del fuego en San Isidro, Santa María, Córdoba.

Comenzamos alrededor de las 10:00 con una ronda de presentaciones entre todos los participantes. Luego, junto a Nico, contamos brevemente cómo surgió el proyecto, el recorrido que nos llevó hasta aquí y realizamos una introducción a Meshtastic y a las posibilidades que ofrece esta tecnología.

Posteriormente entregamos una guía impresa y distintos dispositivos para que los participantes pudieran experimentar directamente con ellos. Entre el equipamiento utilizado se encontraban un N37, un SenseCAP Solar Node P1 (con cuatro baterías 18650 Li-Ion), un SenseCAP T1000-E, un ThinkNode M1 y un WisMesh Tag. A cambio, les pedimos que compartieran sus opiniones, dudas y experiencias de uso, ya que una parte importante del proyecto consiste en evaluar la tecnología desde la perspectiva de quienes realmente podrían utilizarla en el terreno.

A continuación nos dividimos en dos grupos para realizar las configuraciones básicas necesarias para comenzar a utilizar la red. Durante esta etapa trabajamos sobre la configuración de la región, la creación y distribución de canales, el intercambio de mensajes privados y por canal, el uso de la ubicación del teléfono y la creación de puntos de interés en el mapa.

Después del almuerzo realizamos una breve experiencia práctica. Uno de nosotros se desplazó hacia una zona sin cobertura de telefonía móvil o Meshtastic, mientras un dron elevó un nodo repetidor, permitiéndonos observar cómo se comportaba la red en una situación similar a la que podría presentarse durante una operación real.

Para finalizar, realizamos una puesta en común donde respondimos preguntas, escuchamos las impresiones de los participantes y debatimos posibles aplicaciones de la tecnología en el contexto del combate de incendios.

Consideramos que fue una experiencia muy enriquecedora para todos los involucrados. Además de transmitir los conocimientos previstos, pudimos recopilar observaciones, sugerencias y necesidades concretas que nos ayudarán a orientar las próximas etapas del proyecto y las futuras capacitaciones.

Sin embargo, quizás el aprendizaje más importante haya sido otro. Esta fue la primera vez que el proyecto salió del laboratorio, de la documentación y de las pruebas internas para llegar a las manos de quienes podrían utilizar esta tecnología durante una emergencia. En cierto modo, sentimos que fue el momento en que Ñandé tocó tierra.

Sabemos que todavía queda un largo camino por recorrer y tenemos claro que el domingo no validamos una tecnología, sino que comenzamos a construirla junto a quienes algún día podrían necesitarla.

La segunda jornada profundizará en el uso y la configuración de la red, y la capacitación quedará disponible para quienes no puedan asistir o deseen revisar los contenidos en el futuro. Pero, más allá de lo aprendido ese día, creemos que esta experiencia marcó el verdadero comienzo del proyecto.

Una conversación con la Brigada Chiviquín

· 5 min read

En Ñandé creemos que es muy importante identificar las tecnologías necesarias para la comunicación en territorios afectados por incendios a partir de la experiencia de quienes enfrentan este tipo de situaciones todos los días.

Como parte del proceso de investigación del proyecto realizamos una entrevista con integrantes de la Brigada Comunitaria Chiviquín de Córdoba, Argentina. El objetivo era comprender cómo se comunican durante un incendio forestal, qué herramientas utilizan, cuáles son las principales dificultades que encuentran en el terreno y cómo una red de malla podría integrarse a sus prácticas sin modificar aquello que ya funciona, sino complementarlo.

La conversación permitió comprender que, para las brigadas, la comunicación no es solamente una cuestión de coordinación, sino una herramienta fundamental para mantener la seguridad de las personas durante las misiones.

La seguridad como prioridad

Durante toda la entrevista apareció la idea de que la prioridad absoluta es la seguridad de las cuadrillas.

Las comunicaciones permiten saber dónde se encuentra cada grupo, conocer si hubo algún cambio en el comportamiento del fuego, informar accidentes o solicitar apoyo. Incluso cuando no ocurre ninguna novedad, las brigadas establecen un plan de comunicación antes de salir al terreno, definiendo cada cuánto tiempo deberían reportar su estado a la base media.

Cuando ese contacto no puede establecerse, el objetivo pasa a ser recuperar la comunicación lo antes posible, incluso si eso implica detener parcialmente el trabajo para que uno o dos combatientes suban una loma en busca de señal.

Una red de comunicaciones mucho más compleja de lo que parece

Lejos de utilizar un único canal de comunicación, las brigadas trabajan con varias tecnologías en paralelo.

El handy (VHF/UHF) sigue siendo el medio principal durante el combate porque puede utilizarse con una sola mano, funciona sin infraestructura telefónica y permite comunicaciones inmediatas entre cuadrillas y con la base media.

Cuando existe cobertura celular, aparecen nuevas posibilidades tales como compartir ubicaciones, fotografías, videos, mensajes de voz y archivos cartográficos mediante distintas aplicaciones. Esta información resulta especialmente útil para quienes coordinan la operación desde la base o para las cuadrillas que todavía están en camino.

El celular es indispensable, pero tiene limitaciones

Uno de los aspectos que más nos llamó la atención fue el papel que ocupa el teléfono celular.

Aunque durante el combate directo resulta difícil utilizarlo porque requiere ambas manos, obliga a quitarse los guantes y depende de la cobertura, éste concentra una enorme cantidad de funciones, como mapas offline, navegación GPS, seguimiento de recorridos, consulta meteorológica, imágenes satelitales, intercambio de archivos KMZ, fotografías, videos y mensajería.

En otras palabras, el celular es una herramienta de información además de comunicativa, mientras que el handy continúa siendo la herramienta principal para la comunicación inmediata.

Esta combinación evidencia una oportunidad para incorporar herramientas que complementen las capacidades del teléfono y ayuden a superar algunas de sus limitaciones en contextos donde la cobertura celular no está disponible o el territorio dificulta las comunicaciones. Cada tecnología cumple un rol diferente y ninguna reemplaza completamente a las demás.

El territorio condiciona la comunicación

Otro aprendizaje importante fue comprender hasta qué punto la geografía determina las comunicaciones.

Las quebradas, laderas y montañas bloquean tanto la señal de telefonía como las comunicaciones por radio. Es frecuente que una cuadrilla tenga que desplazarse hasta una zona elevada únicamente para poder enviar un mensaje indicando que todo está bien.

Por eso, antes de cada salida se prepara la información offline que consiste en mapas, senderos, cursos de agua, zonas con cobertura conocida y pronósticos meteorológicos. La posibilidad de acceder a estos datos sin conexión es considerada una necesidad básica para el trabajo en terreno.

Brigadas comunitarias y toma de decisiones distribuida

La entrevista también mostró una diferencia interesante entre las brigadas comunitarias y otros modelos de organización más jerárquicos. En Chiviquín, las cuadrillas cuentan con un grado importante de autonomía para interpretar la situación y tomar decisiones en el terreno. Eso significa que necesitan acceder constantemente a información sobre el incendio, el relieve, el clima y el comportamiento del fuego. Esta forma de trabajo refuerza la importancia de contar con herramientas que permitan compartir información entre equipos sin depender exclusivamente de infraestructura externa.

¿Qué significa todo esto para nuestro proyecto?

La entrevista permitió contrastar varias de las hipótesis con las que veníamos trabajando y reforzó algunas de las líneas que ya considerábamos prioritarias.

Nuestro proyecto no busca reemplazar las herramientas existentes. Por el contrario, busca complementar el ecosistema de comunicación que las brigadas ya utilizan.

Los aprendizajes obtenidos refuerzan algunas prioridades del proyecto:

  • Encontrar herramientas que funcionen completamente offline.
  • Facilitar el intercambio de ubicación e información entre cuadrillas.
  • Reducir la dependencia de la cobertura celular.
  • Priorizar siempre la simplicidad y la seguridad por sobre la incorporación de nuevas funciones. Escuchar a quienes combaten incendios forestales nos permitió comprender que la tecnología resulta útil cuando respeta la forma en que las personas ya trabajan. Este es uno de los principios centrales que atraviesan el desarrollo de nuestro proyecto.

Agradecimientos

Queremos agradecer especialmente a todas las personas de la Brigada Chiviquín que se tomaron el tiempo para compartir su experiencia, sus prácticas de trabajo y los desafíos que enfrentan durante el combate de incendios. La generosidad con la que compartieron conocimientos construidos a partir de años de trabajo en el territorio fue fundamental para comprender mejor las necesidades reales de comunicación en contextos de emergencia y para orientar el desarrollo de este proyecto. Gracias por su tiempo, su compromiso y por el trabajo indispensable que realizan cuidando los territorios y las comunidades.

Guía de configuración inicial paso a paso para tu dispositivo Meshtastic

· 19 min read
¡Atención!

Este artículo fue creado en mayo de 2026. Podés consultar aquí la fecha de su última actualización. Tené en cuenta que Meshtastic evoluciona constantemente, por lo que algunas opciones o procedimientos pueden cambiar con el tiempo.

En esta sección vas a aprender a configurar tu primer nodo Meshtastic y dejarlo operativo. A lo largo de un proceso simple, vamos a cubrir tres aspectos principales:

  • Configuración inicial: Cómo encender el dispositivo, vincularlo a tu teléfono mediante la app Meshtastic (Bluetooth) y establecer las configuraciones necesarias para comenzar a operar.
  • Parámetros de comunicación: Cómo definir la región, el canal y otras configuraciones clave para poder comunicarte con otros nodos.
  • Primeros pasos en la red: Cómo integrarte a la malla y comenzar a utilizar el sistema de mensajería.

El objetivo es que, en pocos minutos, puedas tener tu nodo funcionando y listo para integrarse a la malla.

Obtención de un dispositivo

Existe un gran variedad de dispositivos y el que hayas de elegir dependerá de su función, también hay una gran variedad de marcas que se dedican al universo Meshtastic. Nosotros no usaremos uno en particular para esta guía porque el proceso es similar para todos.

Conexión

¡Importante!

Antes de encender cualquier equipo LoRa, conectá la antena al dispositivo. De lo contrario, podrías dañarlo.

¡Atención!

Si el nodo que adquiriste ya viene con Meshtastic instalado, podés comenzar directamente con la configuración. En caso contrario, dirígite al apartado de firmware y luego continúa con esta sección.

Podés enlazar tu nodo Meshtastic a un teléfono o computadora de dos formas: por USB (serial) o mediante Bluetooth.

  • Conexión por USB (serial): Simplemente conecta el dispositivo a través de un cable USB. La app lo reconocerá automáticamente.
  • Conexión por Bluetooth: Al encender el nodo, podrás vincularlo desde tu teléfono o PC como cualquier otro dispositivo Bluetooth.
    • Si el nodo tiene pantalla, mostrará un código de emparejamiento que deberás ingresar en el dispositivo desde el cual te estás conectando.
    • Si el nodo no tiene pantalla, el código de emparejamiento por defecto es 123456.

Este código se utiliza únicamente la primera vez para establecer la conexión.

Preparación del dispositivo

Configuraciones de radio

Es importante saber que estas configuraciones vienen predefinidas con el fin de aliviar la tarea de quien opera los equipos y que funcionan muy bien ya que los hemos probado. No obstante, si usted posee los conocimientos necesarios puede NO usarlos y hacer una configuración completamente personalizada.

Región

información

Estas configuraciones están pensadas para Argentina. Si te encuentras en otro país, es posible que debas elegir una región diferente, aunque el procedimiento es el mismo.

La configuración de la región es esencial para poder comunicarte con otros dispositivos, ya que define los parámetros de radio esenciales para la comunicación.

Podés configurarla de tres maneras: desde el dispositivo, desde la app del celular o mediante Meshtastic CLI (Command Line Interface). En este artículo no se abordará el uso de esta última herramienta.

  • Desde el dispositivo (si tiene pantalla):
    • Al iniciar, antes de vincularlo con un teléfono (en firmware igual o superior a 2.7.15), se te solicitará configurar la región. Deberás elegir ANZ (Australia/Nueva Zelanda).
    • También podés hacerlo desde el menú: LoRa Info → LoRa Region, donde deberás seleccionar ANZ.
  • Desde la app:
    • Luego de la vinculación, si el dispositivo no tiene región configurada, aparecerá una opción para definirla. Allí deberás seleccionar Australia/Brasil/Nueva Zelanda.
    • También podés modificarla en cualquier momento desde Ajustes → LoRa.

Esto se debe a que en estos países, al igual que en Argentina, se utilizan frecuencias entre 902 y 928 MHz (comúnmente referidas como banda de 915 MHz). Estas frecuencias son de uso libre y no requieren una licencia especial para operar.

Radio presets

Los radio presets son un conjunto de tres parámetros preconfigurados: SF (Spreading Factor), BW (Bandwidth) y CR (Coding Rate). En conjunto, estos definen cómo se transmite la señal, afectando directamente el alcance, la velocidad de transmisión y la tolerancia a errores.

De forma simplificada, cuanto mayor alcance se busca, menor será la velocidad de transmisión y mayor la robustez de la señal.

Por defecto, el dispositivo viene configurado en LongFast, por lo que no es necesario modificarlo para un uso general. Podrás comunicarte con cualquier nodo que tenga configurada la misma región y el mismo radio preset.

En caso de necesitar ajustarlo, podés elegir entre los siguientes presets: LongSlow, LongMedium, LongFast, MediumFast, MediumSlow, ShortSlow, ShortFast y ShortTurbo.

Podés modificar esta configuración desde:

  • Dispositivo (con pantalla): LoRa → Radio Preset
  • App móvil: Ajustes → LoRa

Firmware

Si el nodo que adquiriste ya viene con Meshtastic instalado, podés comenzar a utilizarlo completando las configuraciones anteriores. No obstante, dado que se trata de una tecnología en constante evolución, es recomendable mantener el firmware actualizado.

En caso de que el dispositivo no tenga Meshtastic instalado, el proceso de instalación y actualización es el mismo, sólo sigue estos pasos y tendrás tu dispositivo listo para su uso.

¡Atención!

Existen dos métodos para hacerlo: vía BLE (Bluetooth Low Energy) o mediante conexión USB.

Desde este espacio, no recomendamos el uso de BLE (al menos a la fecha de publicación de este artículo), ya que durante las pruebas el proceso resultó inestable y puede dejar el dispositivo en un estado no funcional, requiriendo intervención manual para recuperarlo.

El método por USB, en cambio, es más estable y confiable, por lo que es el recomendado.

El procedimiento varía según el tipo de hardware del nodo (nRF52 o ESP32). A continuación, se detallan los pasos para cada caso:

  1. Ingresá a la herramienta de flasheo.
  2. Seleccioná el dispositivo que vas a utilizar. Si no lo encontrás fácilmente, podés filtrar por marca. En caso de dispositivos ensamblados o DIY(ensamblados por uno mismo), deberás identificar el modelo de la placa base (en nuestro blog, podrá identificar qué marcas son fabricantes y ensambladores*). Por ejemplo un Meshnology N37 corresponde a un Wio Tracker L1. Para saber qué placa lleva, lee bien la descripción del dispositivo que vayas a comprar. En nuestro caso particular ya sabíamos qué placa traía, pero como había que armarlo, en la caja que venía la placa también especificaba esta importante información.
  3. Seleccioná la versión de firmware.
    • Alpha: inestable
    • Beta: estable
      Se recomienda utilizar la última versión beta disponible.
  4. Conectá el dispositivo por USB. Ten en cuenta que:
    • Podés hacerlo en cualquier momento del proceso.
    • Usar cable USB de datos (NO sólo carga).
    • NO desconectar durante el proceso.
  5. Ingresá el dispositivo en modo DFU (Device Firmware Update):
    • Oprima dos veces el botón de reset.
    • El dispositivo aparecerá como una unidad de almacenamiento en el sistema.
  6. Recomendación de instalación según el tipo de pantalla del dispositivo:

Se recomienda descargar el archivo de extensión .uf2 en la carpeta del dispositivo. El proceso es similar a cuando descarga cualquier otro archivo y lo ubica en la capeta que desea de su computador. Esto aplica para todos los SO (Linux, MacOS y Windows).

También puedes descargarlo en cualquier carpeta del equipo y luego copiar o mover dicho archivo a la carpeta a la del dispositivo.

flash_nRF52_1

Oprima "Descargar UF2"

flash_nRF52_2

Elija la carpeta de descarga


¿Cada cuánto es recomendable actualizar el firmware? Aún no definimos una métrica recomendable que permita asegurar cuánto debe usted actualizar el firmware. Sí recomendamos que haga este procedimiento apenas haya adquirido el producto, aunque no es necesario que lo haga antes de conectarlo al celular por primera vez.

Configuraciones adicionales

Aquí se mostrarán las modificaciones que, quizás, no son tan esenciales pero que nosotros hemos llevado a cabo.

Zona horaria

Es posible que esta se ajuste automáticamente al vincular el dispositivo con el teléfono. Sin embargo, puede haber diferencias entre la configuración del nodo y la del celular, por lo que conviene verificar manualmente.

En caso de que no aparezca Argentina en la lista, deberás seleccionar una zona horaria equivalente. Para Argentina, se recomienda utilizar “Brasilia”, porque posee el mismo huso horario.

Este proceso puede realizarse tanto desde el teléfono como desde el nodo (si este cuenta con pantalla).

  • Celular: Ir a Ajustes → Dispositivo → Zona horaria. Es una de las últimas opciones dentro del menú “Dispositivo”. Allí podés optar por usar la zona horaria del teléfono o configurar una manualmente.
  • Nodo: Ir a Reloj → Clock Action → Timezone y seleccionar “BR/Brasilia” (en caso de estar en Argentina). Si te encontrás en otra región, deberás elegir la zona horaria correspondiente.

Canales

Un canal en Meshtastic es básicamente un grupo de comunicación. Pensalo como un “grupo de WhatsApp”, pero sin internet.

Desde la app, entrás al apartado de Ajustes → Canales y verás un canal por defecto llamado “LongFast”. Este es el canal preconfigurado y su nombre está asociado al preset de radio que estés utilizando. Como de manera predeterminada viene configurado como “Long Range - Fast”, toma ese nombre. Si cambias el preset de radio, vas a notar que el nombre del canal también cambia.

Dentro de “Canales” verás un signo “+”, el cual debés oprimir para crear uno nuevo. Una vez dentro, elegís el nombre del canal y, en la parte de la clave, es recomendable usar el símbolo de recargar para generar automáticamente una clave segura (AES-256). También podés definir una manualmente, pero en ese caso debés asegurarte de que sea válida y compatible.

Una vez terminado, salís de esta ventana y envías los cambios al dispositivo. Este paso es muy importante: si no aplicas los cambios, el canal no se guardará y no tendrá efecto.

Crear_canales

Ubicación

Dentro de la configuración del canal, existe una opción para enviar la posición. Debés activarla y, una vez hecho esto, habilitar la opción de ubicación precisa.

Luego, guardás los cambios y los enviás al dispositivo para que tengan efecto.

Primer mensaje y validación de comunicación

Una vez configurado el dispositivo, el siguiente paso es verificar que puede comunicarse correctamente dentro de la red.

Envío de mensaje a un canal

La forma más simple de comprobar el funcionamiento es enviar un mensaje a un canal. Para ello, ingresá al canal en el que estés configurado (por ejemplo, el predeterminado), escribí un mensaje y envíalo.

Si hay otros nodos en la red con la misma configuración (región, canal y radio preset), estos deberían recibir el mensaje.

Es importante destacar que si no hay otros nodos en alcance, no recibirás respuesta y esto no necesariamente significa que tu dispositivo esté mal configurado.

Escribir_canales

Envío de mensaje a un nodo específico

Dirigite a la lista de nodos, seleccioná uno y utilizá la opción de enviar mensaje. La conversación aparecerá en la sección correspondiente, luego de enviar o recibir un primer mensaje.

Escribir_mensajes_particulares

Solo podrás comunicarte con nodos que hayan sido detectados previamente por la red. Para que esto ocurra, deben compartir la misma región y el mismo radio preset (o una configuración compatible).

Si el nodo no responde, puede estar fuera de alcance o sin conectividad en ese momento.

Es importante entender que Meshtastic no funciona como una red en tiempo real constante. Los mensajes pueden tardar en propagarse dependiendo de la distancia, la cantidad de nodos intermedios, el entorno y la configuración.

¿Cómo saber si está funcionando?

Al enviar mensajes, podrás ver indicadores de envío y recepción similares a aplicaciones de mensajería, aunque no tienen la misma precisión ni fiabilidad.

También podés utilizar el mapa: si otros nodos comparten su ubicación, podrás ver su posición aproximada y confirmar su presencia en la red.

Tené en cuenta que:

  • Ver un nodo no garantiza una comunicación estable. Al estar diseñado para ser una malla móvil, un nodo puede quedarse fuera de cobertura y dejar de “verte”, por ende, no puedes comunicarte con él.
  • La ausencia de respuesta no siempre indica un problema.

La mejor forma de validar el funcionamiento es contar con al menos dos nodos configurados correctamente y realizar pruebas entre ellos.


Con estas configuraciones ya podés empezar a utilizar Meshtastic y sacarle provecho en situaciones reales.

No son las únicas opciones disponibles: se trata de una herramienta potente y en constante evolución. Sin embargo, para un primer contacto, esta base es más que suficiente para comenzar a operar dentro de la red.

A medida que ganes experiencia, vas a poder ajustar parámetros y explorar configuraciones más avanzadas según tus necesidades.

El siguiente paso es ponerlo en práctica: probar en campo, validar alcances y entender cómo se comporta la red en tu entorno. ¡Buena suerte!

Explorando alternativas LoRa: Primer contacto con MeshCore

· 9 min read

¿Qué es MeshCore? ¿Y qué relación tiene con Meshtastic?

Si bien algo ya hemos mencionado en un artículo anterior, lo mencionaremos nuevamente: MeshCore es un sistema multiplataforma que permite comunicaciones off-grid (fuera de la red) basadas en texto, mediante hardware de radio LoRa (Long Range). Similar a Meshtastic hasta el momento, pero... ¿Qué los diferencia?

Comportamiento de la malla

La forma de enviar los mensajes es similar para ambos, ya que el mensaje recorre la red que estos dispositivos crean entre sí buscando a su destinatario. Pero MeshCore va más allá, ya que, una vez encontrado su destinatario, guarda la ruta de comunicación con dicho nodo. Debido a esto, cuando se vuelvan a comunicar entre ellos, el mensaje sólo se transmitirá a nodos que repitan el mensaje y que se encuentren en la ruta de comunicación entre ambos (siempre y cuando el camino siga funcionando para que el mensaje llegue). Haciendo un paralelismo, si usted quiere visitar a su amigo que vive a 4 cuadras, una vez que encuentre el recorrido más corto para llegar, probablemente lo repita cada vez que quiera visitarlo. Pero si luego se muda a 12 cuadras el camino que usaba para llegar a destino cambiará, por lo cual deberá encontrar un nuevo camino y luego usará el mismo para llegar. Esta cualidad contribuye a que las redes que se pueden crear con Meshcore puedan ser significativamente más grandes, llegando a los 64 saltos. En el caso de Meshtastic, el límite es de 7 saltos. Esta no es una limitación arbitraria, sino una decisión de diseño pensada para optimizar el funcionamiento en entornos urbanos.

Pero… ¿Qué es exactamente un “salto”?

Un salto ocurre cada vez que un nodo retransmite un mensaje para acercarlo a su destino. Es decir, cuando un dispositivo recibe un mensaje y lo vuelve a emitir para que otro nodo más lejano pueda captarlo. Una forma sencilla de entenderlo es imaginar una carrera de postas: cada corredor recorre un tramo y le pasa la posta al siguiente. De la misma manera, cada nodo transmite el mensaje al siguiente, hasta que finalmente llega al destinatario.

¿Cómo funciona?

Funciona de manera similar que Meshtastic y opera en los mismos dispositivos. Nosotros ya tenemos algunos de ellos adquiridos, por lo que no nos representa un costo extra probarla. Lo único que debemos hacer es flashear nuestros dispositivos con firmware MeshCore, y lo podremos hacer desde la siguiente página. El proceso es similar tanto para los dispositivos con nRF52, como con ESP32, pero si hay que hacer una gran salvedad en este apartado, los firmware de la gran mayoría de dispositivos, están pensado para cumplir una única función.

Me explico... En Meshtastic, es posible cambiar qué función va a desempeñar el aparato y puede usar todos los métodos de conexión a la pc o celular desde un mismo firmware, mientras que en MeshCore hay firmware dedicado para diferentes situaciones. Por ejemplo, existen 4 firmwares para el Elecrow ThinkNode M1, dependiendo de si el dispositivo que envía y recibe mensajes va a usar la conexión vía BLE o vía USB, si es repetidor exclusivo o si es un room server (depósito de mensajes para quien no haya podido recibirlos acceda y los pueda ver). Aunque, en la última versión del firmware, le permite a los nodos con una determinada configuración enviar y repetir, es una función limitada en comparación al funcionamiento de Meshtastic.

En nuestra primera experiencia, más a principio de año, se sufrieron fallas en la conexión USB y en el proceso de flasheo del dispositivo, dejando una sensación de fragilidad de dicho procedimiento. Pero con el paso del tiempo esto ha mejorado exponencialmente y en nuestras últimas pruebas con esta tecnología NO hemos experimentado fallo alguno. De manera similar surgieron problemas con la conexión Bluetooth en nuestros primeros contactos con esta tecnología, pero en las últimas pruebas han solucionado esto casi por completo dejando muy buenas sensaciones.

Ambos tienen app de celular, pero... Meshtastic tiene una plataforma traducida al Español casi en su totalidad, mientras que MeshCore está en Inglés. Hay que reconocer que en la última versión de la app se han agregado múltiples idiomas, sin embargo, el Español NO es uno de ellos. Esperamos que en próximas versiones sea incluído. Encontramos positivo que estén agregando más idiomas poco a poco.

El hecho de que el firmware de MeshCore esté directamente asociado a una forma de conexión o función intrínsecamente, limita la forma en la que podemos usar el dispositivo, mientras que con Meshtastic esto no sucede.

En cuanto al hardware en el que corre Meshtastic y MeshCore es el mismo, sin embargo podemos notar grandes diferencias en el firmware que se ejecuta en dicho hardware. Para empezar, ambos están en inglés para la gran mayoría de hardwares disponibles. La interfaz de usuario es notablemente mejor en el caso de Meshtastic y hace un mejor aprovechamiento del hardware que tiene a disposición el dispositivo en el que está instalado. Mientras que en MeshCore, se siente que es un firmware poco optimizado para un dispositivo en particular y se siente que ha sido porteado de uno en particular a los demás. Esto hace que no pueda adaptarse de forma óptima al hardware de todos los dispositivos en los que se instala. Al menos eso sucedió para todos nuestros dispositivos, a excepción del T-Deck, donde no realizamos pruebas con MeshCore aún.

MeshCore tiene características interesantes que nos gustaría resaltar:

Cuando configuras el nodo desde el celular, las configuraciones no reinician el dispositivo. Cosa que sí sucede para Meshtastic y que es un punto a favor de MeshCore. Es importantísimo aclarar que muchos de los cambios requieren de un reinicio al igual que en Meshtastic, pero si debes de hacer 10 cambios en éste, requerirán 10 reinicios. Mientras que en MeshCore se requiere sólo 1 luego de haber hecho todos los cambios necesarios, pero dicho reinicio deberás hacerlo de manera manual. Desde la app podés renombrar a los nodos que tengas en tu lista de contactos. Similar como cualquier contacto del teléfono para agendarlo como quieras. La configuración de la radio. No viene nada por default, puedes usar un preset de radio que te permita comunicarte con todos aquellos nodos que posean la misma configuración. O bien puedes configurar tú mismo una de manera particular y ambos tipos de configuraciones se pueden hacer de manera sencilla. Puede, al igual que Meshtastic, compartir la posición GPS del teléfono aumentando la precisión. Dentro de los canales, permite que ciertos participantes sólo puedan leer, pero no contestar, similar a un grupo de difusión de Whatsapp. Muy útil para dar directivas sin congestionar los canales de comunicación con las respuestas de todos los participantes. Siguiendo el hilo, permite ver los participantes de un canal, NO los integrantes. Me explico, si en un canal están 40 personas y en él sólo escriben 5 personas, habrá 40 integrantes, pero sólo podrás ver a los 5 participantes, los restantes 35 no sabrás quienes son a menos que interactúen en el canal.

Es importante destacar que no está diseñado para enviar la posición de manera autónoma y regular como lo hace Meshtastic. Esto al menos para nosotros, es un problema ya que saber cuál es la ubicación es fundamental para los combatientes. Pero no es que esta tecnología no tenga la capacidad, ya que apps particulares como MeshCore SAR lo han logrado, sin embargo desde la app de MeshCore oficial esta opción no está disponible. Otra diferencia importante está en la forma en que los nodos se comunican. En Meshtastic, si dos o más nodos comparten la misma configuración de radio y región, pueden comunicarse automáticamente en cuanto están dentro de alcance. En MeshCore, en cambio, el enfoque es distinto: para que dos nodos puedan comunicarse, deben ser contactos entre sí. Para lograrlo, es necesario agregarse mediante una clave pública, un código QR o a partir de un advert recibido. Pero… ¿Qué es un advert? ¿Y una clave pública? Un advert es un paquete de datos pequeño que un nodo emite para anunciar su presencia. Es, en esencia, una baliza ya que se utiliza para ver a la distancia la presencia de un objeto o persona. Es una forma de decir: “estoy acá y este soy yo”, permitiendo que otros nodos cercanos lo detecten e identifiquen. Una clave pública, por su parte, es una cadena de caracteres alfanuméricos que funciona como tu identidad digital. Permite que otros nodos te reconozcan y, además, habilita la comunicación segura, evitando que terceros puedan hacerse pasar por vos o leer mensajes privados. Como vemos, estas limitaciones vienen de la filosofía de diseño. Ya que en una ciudad no nos interesaría que todos nuestros contactos sepan nuestra ubicación todo el tiempo, ni que tampoco cualquiera nos escriba. Por ello, MeshCore te da la posibilidad de limitar a las personas con las que quieres compartir la telemetría (ubicación, batería, etc.). Esto no lo convierte en una tecnología inferior a Meshtatic, sino en una diferente. Es necesario destacar que MeshCore posee una gran diversidad de apps particulares potenciando esta tecnología u orientándola hacia una determinada dirección, denotando la activa comunidad que posee y la fé que la misma posee en esta tecnología.

Para finalizar, un dato de color... Si tienes las apps de Meshtastic y de MeshCore en tu teléfono móvil y dos nodos flasheados uno con Meshtastic y otro con MeshCore, podrás conectarte a dos nodos de manera simultánea desde el mismo celular. Pero la pregunta del millón... ¿Es útil? La verdad es que por el momento creemos que no, pero también creemos que abre una puerta a una futura colaboración entre ambas tecnologías.


Creemos que MeshCore es una tecnología interesante, digna de ser explorada y expandida. Creemos que las diferencias que posee respecto de Meshtastic se deben al tiempo en que salió al mundo uno respecto del otro. Además, explica también la diferencia entre el tamaño de las comunidades, ya que es mucho más grande que la de MeshCore.

Nos parece positivo que existan ambos firmwares porque creemos que ante sus diferencias los únicos beneficiados son los usuarios. Además consideramos que con el tiempo, los beneficios de uno son adoptados por el otro y viceversa.

Creemos que de momento seguiremos con Meshtastic porque creemos que es una tecnología un poco más robusta, que nos ayudará con el combate contra el fuego. No obstante, seguiremos de cerca a MeshCore considerándolo tanto como posible reemplazo, como un compañero de Meshtastic en el caso de que en un futuro ambas tecnologías puedan trabajar en conjunto, potenciando sus fortalezas y disminuyendo sus debilidades.

Prueba de campo Meshtastic con la brigada La Chilca: Alcance, bosques y desafíos de hardware

· 6 min read

En el diseño de redes de comunicación para emergencias, la teoría y la práctica suelen chocar de frente cuando salimos al terreno. Sabemos que las señales de los dispositivos Meshtastic (tecnología LoRa) pueden viajar cientos de kilómetros si hay línea de vista directa. ¿Pero qué pasa cuando le sumamos la realidad de nuestro entorno?

Junto a Sofi y Caro de la brigada forestal La Chilca, salimos a responder esta pregunta en José de la Quintana (Departamento Santa María, Provincia de Córdoba, Argentina).

El objetivo inicial era claro, determinar cuánto afecta la copa de los árboles a la señal de los dispositivos Meshtastic. Entender cómo los obstáculos regulares entorpecen la comunicación es vital para diseñar redes robustas. Además, veníamos de algunas pruebas de alcance fallidas y necesitábamos un escenario real para demostrar el verdadero potencial de esta tecnología.

Caminata con La Chilca

Ascendiendo al punto elevado donde ubicaremos nuestro nodo fijo, junto a Sofi y Caro

El Despliegue: Nodos, Sierras y Motos

Para esta prueba de alcance, preparamos cinco dispositivos con hardware totalmente distinto, todos configurados con la misma versión del firmware Meshtastic (2.7.15) y el preset de radio LongFast:

  • SenseCAP Solar Node P1 (Seeed Studio) - Nodo fijo.
  • Wio Tracker L1 (Seeed Studio) - Nodo móvil.
  • ThinkNode M1 (Elecrow) - Nodo móvil.
  • T-Deck (LilyGo) - Nodo móvil.
  • WisMesh Tag (RAK Wireless) - Llevado como repetidor para el dron, pero no se llegó a usar.
  • MeshPocket Qi2 (Heltec) - Sólo se usó como powerbank para poder mantener encendido el T-Deck.

Además, cada grupo fue equipado con una radio VHF y celulares para poder conectarse a un nodo vía Bluetooth. ¿La estrategia? Nos dividimos en dos equipos. Un equipo ascendió unos 20 minutos por una pendiente empinada hasta la parte más alta de la cuchilla para instalar el nodo solar (SenseCAP Solar Node P1) a pleno sol.

El otro equipo (Pablo) inició un recorrido en moto llevando los nodos móviles (T-Deck, Wio Tracker L1 y ThinkNode M1) para mapear la cobertura en la zona baja.

Área teórica de cobertura

Aquí podrá observar el área que estimada de cobertura según Meshtastic Site Planner

El misterio de los árboles y los resultados de cobertura

El recorrido en moto implicó más de dos horas de tiempo neto de prueba, cubriendo un trayecto extenso que culminó en Los Molinos.

Área de cobertura de la experiencia

Aquí podrá observar el área que estimamos habrá cobertura en base a los resultados de nuestra experiencia

El resultado de RF fue un éxito rotundo y nos dio una respuesta clara sobre la vegetación. La experiencia demostró que la copa de los árboles en el contexto de José de la Quintana (árboles de espinas, con follaje medio, no extremadamente densos) no afectó significativamente la señal. Los mensajes llegaron perfectos a través del monte.

Además, descubrimos un dato operativo excelente, la posición de la antena de los nodos móviles no influyó en la comunicación. Durante gran parte de la experiencia, la antena no estuvo en una posición vertical perfecta, y sin embargo, la transmisión de datos se dio de muy buena manera.

Lo que verdaderamente dictó las reglas del juego fue la topografía: la línea de vista es muy importante. El único momento en que la señal se bloqueó por completo fue yendo hacia Los Molinos, justo cuando dimos la vuelta a un monte y perdimos la línea de vista directa con la cuchilla. Apenas hay un desnivel de tierra o piedra que interrumpe la visual, se acaba la comunicación. Es absolutamente esencial la elección de puntos estratégicos y altos para instalar los nodos repetidores.

La realidad del hardware: No todo lo que brilla es oro

Si bien la red demostró su potencial, el hardware nos dio varias lecciones importantes:

  • Inestabilidad en el Nodo Solar (P1): El nodo debió ser reiniciado 3 o 4 veces a lo largo de toda la experiencia. No tenemos la certeza de si estos fallos se debieron a mantener un teléfono conectado por Bluetooth o a otra causa técnica. Lo que sí sabemos es que, en una experiencia anterior donde lo usamos puramente como repetidor (sin conexión Bluetooth), el P1 funcionó de manera impecable. Es un comportamiento que estamos investigando a fondo.
  • El fracaso del T-Deck: A los 500 metros de iniciado el recorrido, perdió la señal por completo y quedó "sordo". Debido a esto se decidió encender la función de Range Test y curiosamente los mensajes si llegaban con frecuencia al nodo fijo, pero el T-Deck sólo recibía mensajes si el Wio Tracker L1 actuaba como repetidor, a pesar de estar a la misma distancia del nodo principal. La conclusión es clara, el T-Deck queda fuera de nuestras pruebas operativas por ahora.
  • Dudas sobre Seeed Studio: Aunque el Wio Tracker L1 funcionó muy bien esta vez, los fallos recurrentes del P1 en esta prueba, sumados a cuelgues de otros L1 en el pasado, nos llevan a prestar atención a su confiabilidad. Por ello estamos investigando si es un problema de la marca o si es propio de los nodos cuyo procesador sea un nRF52.

El ejercicio cumplió su cometido, vimos el alcance real cruzando la vegetación local, comprobamos la robustez de la señal independientemente de la posición de la antena, y confirmamos que la topografía es el verdadero límite. También detectamos los eslabones débiles de nuestro equipamiento. Los próximos pasos son evaluar a fondo la inestabilidad de los nodos solares, descartar hardware problemático y seguir trabajando junto a las brigadas para que esta tecnología sea, muy pronto, una herramienta indispensable en su mochila.

Queda mucho aún por aprender y experimentar, pero este ejercicio nos dió buenas sensaciones devolviendonos parte de la esperanza que con los experimentos fallidos con anterioridad habíamos perdido.

Análisis de los dispositivos adquiridos en nuestra primera compra

· 22 min read

Este artículo se basa en nuestra experiencia personal con los nodos aquí citados, además fueron evaluados en el contexto del uso de un combatiente del fuego.

Por ende hay nodos que en este contexto, no son óptimos, pero fuera del mismo, puede que sea un gran dispositivo. Teniendo esto en cuenta lo que nosotros buscamos es:

  • Durabilidad en batería.
  • Certificación IP.
  • Fácil maniobrabilidad, sobre todo con guantes.
  • Independencia del teléfono.

Si te interesa conocer más sobre nuestra primera compra de dispositivo LoRa, podrás ver la primera y segunda parte de nuestro proceso.

Elecrow

Es una marca interesante que ofrece productos con una variedad de funcionalidades y microprocesadores, tienen cuestiones a mejorar pero creemos que van por buen camino además de que poseen precios accesibles. Sin duda si tiene pensado adquirir tecnología LoRa, esta es una marca que NO puede dejar pasar.

Es un nodo cómodo, con una buena terminación, liviano, con una batería aceptable. A su firmware lo podemos diferenciar según su interfaz (UI):

  • UI Estándar: Muestra al usuario bastante información a su usuario, permitiéndole hacer unas cuantas configuraciones desde el dispositivo, lo que le permite en cierto modo, tener un grado de independencia que la otra interfaz no posee.

  • InkHUD: Es más sencilla, más veloz, pero tiene casi una estricta dependencia del celular o pc. Lo positivo es que te permite rotar la pantalla, mejorando la manipulación del dispositivo, algo que con la otra interfaz es imposible.

Su parlante posee un volumen bajo, lo cual no es útil, debido a ello decidimos deshabilitarlo. El regulador de intensidad de la luz creemos que es poco útil, con un botón que encienda o apague se hubiera resuelto de una mejor manera. Y la duración de la batería nunca superó las 48hs en escenarios sin tráfico de radio, con Bluetooth y GPS encendidos, en ninguno de estos 6 nodos.

Creemos que es un buen nodo, pero no creemos que sea el definitivo, debería cumplir con estándares necesarios de los combatientes que hoy no los cumple, pero que quizás en un futuro, con unas mejoras, puede que lo haga.

Elecrow ThinkNode M1

ThinkNode M1

Heltec

El MeshPocket Qi2 es un nodo bonito, se ve profesional, caro, pero por sobre todas las cosas, endeble. Posee la pantalla de papel electrónico más barata del mercado, lo que trae problemas como el ghosting que es muy molesto. Tiene una menor resolución, que junto a un tamaño mayor (mayor que la del ThinkNode M1 o M5 Pro y T-Echo) da la sensación de mayor claridad en la pantalla, no es retroiluminada. Además no posee GPS, pero como hasta el momento, esta funcionalidad en Meshtastic no es de lo más preciso, hoy no creo que sea una pérdida, pero si este panorama cambia y el GPS empieza a aumentar su precisión, si será una gran falta.

De manera similar que los ThinkNode M1 y M5 Pro, también posee dos versiones de un mismo firmware, dependiendo de la interfaz de usuario:

  • UI Estándar: A diferencia de los nodos de Elecrow ya mencionados... Pese a no poseer un parlante, tiene opciones de manipular sus funciones. El uso de todo el dispositivo recae en un único botón, pese a que posee 3. Su funcionamiento, a diferencia de InkHUD, es aún peor, porque la cantidad de menúes y funcionalidades que ofrece, pasarte por un click, puede convertir tu experiencia de usuario en algo que pasa de molesto a frustrante en muy poco tiempo.

  • InkHUD: Hace un buen aprovechamiento de la función de rotación de pantalla, incluso más que los otros dispositivos del mercado, esto se debe a que la pantalla es mucho más ancha que las demás. El uso completo del dispositivo con un único botón es malo, pero como ni siquiera puede enviar mensajes, su dependencia del teléfono, por lo que el mencionado aprovechamiento de la parte de lectura de mensajes, no sirve para nada. Haciendo que instalar esta interfaz en este dispositivo, no aporta en absolutamente en nada. Posiblemente sea mejor usar un WisMesh Tag, acompañado de una powerbank incluso más grande, por el mismo coste.

Creemos que es un aparato que sabe adornar sus faltas, pero son muchas y significativas, por lo que, al menos para el combate contra el fuego, no es de lo más recomendable.

Ya hablando de la marca, no queremos dejar pasar el mal servicio que nos ofrecieron en 2 oportunidades, siendo este el motivo por el cual se tomó la determinación de NO efectuar compras directamente a la marca y por ello adquirimos sus dispositivos a través de un revendedor (Muzi Works). Si te interesa saber más al respecto, aquí podrás ver toda nuestra experiencia con esta marca. Pese a esto la sensación que nos deja es que se sufrió demasiado por un hardware, que quizás, no estuvo a la altura de nuestro sufrimiento. Además mucho del hardware que han creado NO está listo para ser usado y además en su mayoría tiene un ESP32.

Todos estos sucesos han llevado al desinterés por la marca, no obstante la seguiremos de cerca para ver cuáles son sus avances, pero creemos que están por detrás de marcas como Elecrow o seed studio.

Heltec MeshPocket Qi2

MeshPocket Qi2

LilyGo

La consistencia en el control de calidad y la competitividad de sus precios frente a otras opciones del mercado han sido puntos debatibles. Para proyectos críticos de infraestructura, la confiabilidad de sus componentes sigue siendo un factor a evaluar cuidadosamente.

Es un aparato que no tiene coherencia de diseño. El teclado barato, junto a una distribución de sus teclas que hacen complejo su uso, el trackball que se ve aún más barato, que no funciona al 100% y una pantalla táctil que es de buen tamaño y que salva la usabilidad del dispositivo (con el display de Meshtastic UI). Además dicha pantalla se ve bien en cualquier escenario, lo cual es un aspecto positivo, independientemente de su interfaz de usuario, las cuales explicitamos a continuación:

  • UI Estándar: La misma que tienen todos los dispositivos que poseen una pantalla. Sólo ofrece dos funcionalidades extra, en comparación con las demás. Leerte un mensaje, función que está lejos de ser aceptable y 'aprovechar' el teclado para escribir un mensaje, sin embargo, no es intuitiva la manera de aprovechar esta funcionalidad. Desaprovecha por completo la pantalla táctil, por lo que debes recaer en el uso del trackball y el "enter" del teclado ya que el trackball, a veces sirve para seleccionar, pero a veces no y esto no habla de la calidad del trackball, que si es baja, sino a los permisos que se le otorgan en determinados menúes, volviendo aún más pobre su uso.

  • Meshtastic UI: Es un buen intento, pero necesita mejoras, como ignorar la funcionalidad del trackball, ya que complica de manera innecesaria la experiencia de usuario, porque el funcionamiento es bueno con la pantalla táctil. El uso del BLE, es lo más flojo de este display, ya que para poder usarlo primero debes de encontrar cómo encenderlo, cuya ubicación se encuentra junto al apagado y reinicio, lo que llevaría a uno a pensar que se han equivocado de lugar para poner esta funcionalidad y la peor es que la respuesta a esto es que no, no se encuentra mal ubicado. Esto es porque usar el BLE inhabilita el uso por completo del dispositivo, algo que también hace el dispositivo cuando lo apagas o reinicias. Debido a esto puedes usar el dispositivo sin BLE o conectarlo al teléfono, pero NO usar el dispositivo. Ante esto, uno pensaría que es una opción usar el puerto serie, algo que todos los nodos permiten y que funciona a grandísima velocidad y si es posible, pero la experiencia mala, la velocidad anteriormente mencionada no existe, ralentiza por demás al celular.

Uno de los tres dispositivos presenta problemas para cargar, sumado a que no dura mucho la batería. Otro problema que tuvimos fue cuando estaba operando Range Test fallando y teniendo que descartar una experiencia completa debido a estos fallos. Razón que nos llevó a descartarlos por completo.

Para cerrar diría que es un nodo que posee buenas intenciones pero que no concreta nada, no recomendaría este nodo para el combate del fuego ya que es muy endeble y no posee certificación IP alguna, seguido de que su firmware, independientemente de su display, necesita muchas mejoras.

LilyGo T-Deck

T-Deck

Meshnology

Su nodo, el N37 utiliza de hardware interno un Wio Tracker L1, por lo que no hablaremos del funcionamiento sino del "extra" que aporta este ensamblador en comparación al Wio Tracker L1 Pro. Y los diferencian dos cosas:

  • Batería: 3000mAh, posee 1000mAh que el L1 Pro, lo cual está bien, pero puede que sea un exceso.
  • Carcaza: No posee aspectos positivos.
    • Impresa en 3D, en un material endeble y que no puede ser expuesto al sol o calor.
    • Posee intersticios donde puede ingresar el polvo o humedad.
    • La cantidad de tornillos no alcanza para sellar bien el dispositivo.
    • En una caída de 75cm se rompió la parte que contiene la antena GPS.
    • El joystick imposibilita el uso del dispositivo.
    • Inestabilidad al estar en posición vertical.

No hay motivos para adquirir este producto, no solo en el contexto del combate del fuego, sino en cualquier contexto, ya que el Wio Tracker L1 Pro es mejor y más barato. Es importante que el ensamblador rediseñe esta carcasa y en un material fiable, ya que no se le pide que tenga una certificación IP, pero que al menos no empeore el funcionamiento del hardware.

Meshnology N37

N37

RAK

El WisMesh Tag, hasta el momento es el inesperado gran ganador de esta jornada de análisis. Posee un diseño sencillo, pero efectivo, posee dos botones uno de acción grande frontal y uno de reset en la parte posterior del dispositivo, que es muy difícil que lo aprietes por accidente, lo que se agradece.

Posee tres luces que indican el estado actual del dispositivo, lo cual es sencillo pero efectivo, posee una batería pequeña pero que nos ha durado más de dos días, viene con una correa para colgarlo del cuello y certificación IP66.

La única contra de este dispositivo es su cable de carga/datos, el cual tiene un pin particular, por lo que deberás cuidarlo de que no se rompa o extravíe. Es importante destacar que su funcionamiento es impecable, pero la contra viene del lado de la inexistencia de un reemplazo en el mercado local.

Por el momento puede que sea el estándar para los combatientes del fuego, pero quedan pruebas aún por hacer.

RAK WisMesh Tag

WisMesh Tag

seed studio

Es la marca más balanceada. Posee buenos precios, una entrega rapidísima de sus productos y los dispositivos que producen tienen coherencia de diseño, calidad. Aparte es la marca que aparenta estar en un constante innovación. Además es una de las pocas que te vende sus productos en un paquete, ya que como hemos mencionado, esto funciona en malla y mientras más nodos, mayor es la cobertura y su extensión, esto muestra la visión de la marca.

Es un nodo pequeño, cómodo, con una buena batería, que le permite superar las 72 hs en escenarios sin tráfico de radio, con Bluetooth y GPS encendidos. La pantalla, pese a ser LCD y consumir más que las de papel electrónico, tienen un botón para apagarlas, lo que baja enormemente el consumo, ya que solo estará encendida al momento de su uso, además es mucho más veloz que las pantallas de papel electrónico.

La carcasa parece impresa en 3D, pero se ve bien, posee un hueco por donde se puede pasar una correa a un dispositivo pero no posee estabilidad de manera vertical, no se queda parado en una mesa.

Que tenga un botón en el joystick con una función tan central, no creo que sea lo mejor, quizá invertir los roles con el botón que posee al lado, sea lo más óptimo, ya que este último solo sirve para ir hacia atrás o apagar/encender la pantalla. El botón de reset, pese a estar expuesto, no se aprieta con tanta facilidad, posee un interruptor de encendido/apagado del dispositivo.

Los problemas que experimentamos con el dispositivo es que la pantalla deja de funcionar, pero el dispositivo está operativo, que el dispositivo se trabe o que tenga desconexiones esporádicas del pc, pero todo esto se soluciona rápidamente con un reinicio. No obstante no creemos que sean problemas menores, pero analizaremos si fueron cuestiones aisladas o más bien si el hardware tiene problemas.

Si no fuera por los problemas mencionados anteriormente, diríamos que son los nodos más adecuados dentro de lo que hay en el mercado con pantalla.

SeedStudio WioTracker L1

WioTracker L1

Spec5

El Voyager es un modelo que presenta una idea interesante, aún nos queda por testear si realmente cumple con estas expectativas o no. Pero lo que podemos decir de este nodo es que posee un buen agarre con los 4 imanes que posee, la antena no destaca y la electrónica tiene una buena aislación, pero... ¿A qué costo? Económicamente a uno elevado, a nivel de diseño, fue uno aún más alto, porque no tenes puerto USB a menos que abras el dispositivo, no hay botones a menos que abras el dispositivo, no hay luces a menos que abras el dispositivo y no hay encendido/ apagado a menos que conectes/desconectes la batería y para ello también había que abrir el dispositivo.

Creo que falta trabajo de diseño y si la idea que este nodo representa te interesa, antes de adquirirlo, sugeriría que busques alternativas para imprimir en 3D dentro de la comunidad y armar un nodo custom basado en esta idea.

Hablando de la marca, pese a que tenemos un sólo dispositivo, es posiblemente la marca que mejor vea y entienda el mercado de la tecnología LoRa, sus precios son elevados y no podríamos hablar de la calidad de sus productos, pero ya sabe lo que pensamos sobre este único dispositivo que tenemos. No posee envíos a Argentina, por lo que si decides adquirir sus productos, necesitarás un importador, un gasto extra que debes tener en cuenta.

Spec5 Voyager

Voyager


El mercado si bien ofrece una cantidad interesante de nodos, bajo nuestra visión actual de lo que un nodo debe poseer, no hay uno que cumpla con estas expectativas, pero entendemos que es una tecnología joven, en constante desarrollo y que aún necesita mejoras. No obstante creemos que el WisMesh Tag posiblemente sea el nodo más adecuado en el escenario portable, mientras que el el aspecto de repetidor, el mejor es el SenseCAP Solar Node P1, en su versión base o Pro.

Haciendo un balance de todos los fabricantes y ensambladores creemos que hasta el momento existen dos marcas, seed studio y Elecrow, que están por delante de las demás, seguidos de cerca por RAK, los demás fabricantes no ofrecen grandes cosas, pero en los ensambladores hay movimientos cada vez más interesantes, que seguiremos de cerca.

Con respectos a las diferencias entre procesadores ESP32 y nRF52. Creemos que aún faltan pruebas concluyentes pero a grandes rasgos no hay diferencias significativas por las cuales descartar a uno u otro. La eficiencia de la batería de la batería no es lo suficientemente determinante como para ponerlo por encima de los ESP32 y en contrapartida no ofrece cualidades específicas determinantes que lo pongan por encima de los nRF52.

Creemos que esta tecnología va por buen camino, nosotros intentaremos contribuir también para sus mejoras, independientemente si esta es usada por Meshtastic o MeshCore.