Saltar al contenido principal

11 publicaciones etiquetados con "Meshtastic"

Guías, configuraciones y despliegue de nodos utilizando el protocolo Meshtastic para redes de radio de largo alcance.

Ver Todas las Etiquetas

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

· 11 min de lectura

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 de lectura

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 de lectura

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 de lectura

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 de lectura

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 de lectura

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 de lectura
¡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 de lectura

¿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.

Nos fuimos de compras: Nuestra primera experiencia adquiriendo dispositivos Meshtastic

· 11 min de lectura

En el camino hacia la implementación de redes de comunicación descentralizadas para combatientes del fuego, la teoría y la planificación deben dar paso a la acción concreta. Después de un riguroso análisis de las funciones y especificaciones técnicas ideales para nuestros nodos Meshtastic, llegó el momento decisivo: el proceso de adquisición. Esta etapa, aparentemente sencilla, se transformó en una verdadera aventura logística y económica.

Este artículo detalla nuestra primera experiencia de compra de dispositivos Meshtastic a nivel internacional, una inmersión forzosa en la dinámica del e-commerce global. Nuestro objetivo no solo era obtener el hardware necesario para iniciar talleres de formación y pruebas de campo, sino también evaluar los desafíos logísticos que enfrentará cualquier implementador en Argentina. A continuación, desglosamos cuáles fueron los dispositivos elegidos, el intrincado proceso de compra, los variados métodos de envío, los precios finales y los tiempos, tanto estimados como reales, de entrega. Esta guía está diseñada para convertir nuestra curva de aprendizaje en un camino más llano para futuros proyectos.

¿Cuáles son y por qué elegimos estos dispositivos?

Nuestro objetivo fue intentar abarcar la mayor cantidad de dispositivos que, a nuestro juicio, los combatientes pueden sacarle partido para poder llevar a cabo talleres de formación y prubas de campo. La elección sobre qué dispositivos se iban a adquirir no fue sencilla, pues hicimos un equilibrio entre la función que pueden desempeñar y sus especificaciones técnicas, sin dejar afuera a ningún fabricante (tenga en cuenta que fabricante y ensamblador NO son lo mismo y aquí puede ver la diferencia).

Si bien existe una gran cantidad de dispositivos en el mercado, luego de un análisis riguroso, los dispositivos y las cantidades que decidimos adquirir, son las siguientes:

ModeloMarcaTipoCantidad
N37MeshnologyPortable c/pantalla6
MeshPocket Qi2HeltecPowerbank6
SenseCAP P1-ProSeedStudioFijo2
VoyagerSpec5Fijo p/Vehículo1
ThinkNode M1ElecrowPortable c/pantalla6
ThinkNode M6ElecrowFijo2
WisMesh TagRAKTarjeta6

Proceso de elección

ADVERTENCIA:

Nuestra elección de dispositivos y cantidades están dirigidas a los combatientes del fuego, a las situaciones que deben afrontar y a nuestras creencias sobre las necesidades que deben estar cubiertas.

Si hablamos de los dispositivos portables, adquirimos 6 de c/u (N37 y M1) y 6 MeshPocket. Aunque estos últimos son powerbanks (de 10.000mAh en el modelo elegido), también pueden desempeñarse como los dos anteriores. Es de nuestro intrés saber cómo trabajan estos dispositivos en entornos donde los dispositivos son homogéneos, para luego evaluarlos en escenarios mixtos, y contrastar los resultados obtenidos, ya que este último posiblemente se aproxime más a la realidad.

La elección de los portables tuvo varios aspectos en cuenta. Desde un inicio se decidió NO contar con los procesadores ESP32, debido a su alto consumo de energía. La disponibilidad fue otra arista a evaluar, ya que modelos como el Nano G2 Ultra no se encuentran en stock. El precio también fue un factor, por lo que modelos como el WisMesh Pocket V2 quedaron fuera, pues en comparación a los elegidos, no ofrecía, bajo nuestro criterio, algo que justificara pagar la diferencia. El T-Echo de LilyGo no se tuvo en cuenta, ya que, contamos con 2 unidades y decidimos probar nuevas opciones, (no obstante,en un futuro próximo se publicará una reseña de este modelo y de todos los que se adquieran). Por ello elegimos al ThinkNode M1 y al N37 (basado en un WioTracker L1 de SeedStudio).

Dentro del universo de dispositivos portables que no poseen una pantalla, elegimos a los tipo tarjeta. Estos dispositivos son un buen punto de partida para personas que no estén interesadas tanto en recibir mensajes, sino en transmitir su ubicación y ser repetidores, pensado más para personas que tienen menos exposición a la tecnología. Evaluaremos si este aparato cumple con esta función, cómo lo hará y si cumple con las expectativas, o por el contrario, necesitamos un aparato más robusto. Con esto en mente, elegimos al WisMesh Tag ya que hacía un gps lock en menor tiempo que su similar de seedstudio, mientras que el M3 de Elecrow no fue tomado en cuenta por su falta de stock.

Para los dispositivos fijos, el P1 y el M6 fueron los elegidos. En cuanto a las prestaciones había mucha paridad, por lo que el aspecto económico, en este caso, fue más determinante que en las elecciones anteriores. Pero también se eligió el P1 sobre su versión Pro por varios aspectos: uno fue el envío, debido a que no incluye baterías es más fácil de gestionar su entrega con un courier, ya que hay empresas (como FedEx) que no hacen envíos cuyos productos poseen baterías. Consume menos energía, al no tener GPS integrado y por último, pero no menos importante, debido a que no posee baterías ni GPS, en comparación a sus similares del mercado, su precio es el más bajo.

En el caso de del Spec5 Voyager, su compra fue un hecho aún más experimental, sumado a su precio, se decidió solamente adquirir una única unidad. Principalmente creemos que es importante saber dónde se encuentran todos los vehículos que participan del combate contra el fuego, pero también pueden contribuir a expandir la red ubicándose en puntos estratégicos. Esta función podrá desempeñarse por un largo tiempo debido al panel solar que incluye.

Se decidió inicialmente conformar un kit de 4 nodos portátiles, 2 tipo tarjeta y 1 nodo fijo. Creemos que es suficiente para una brigada pequeña, al menos en un inicio. No obstante, está sujeto a modificaciones, ya que aún no se realizaron pruebas de campo junto a los combatientes.

Otros factores que influyeron en la decisión fueron la necesidad de testear al menos un dispositivo de cada una de las empresas manufactureras (que si te genera curiosidad saber cuales son aquí puedes verlas). También fue de nuestro interés usar distintos lugares de compra (sitio web propietario de la empresa, o sitios externos de reventa, como AliExpress o Amazon) con el fin de conseguir dispositivos en stock, comparar precios, costos(de envío, impuestos o algún otro costo extra), tiempos estimados de llegada, así como tiempos reales y cotejar los diferentes couriers disponibles (FedEx, DHL, UPS, etc.).

Proceso de compra

Se definieron en primer lugar, los sitios de compra. Posteriormente algunos tuvieron que variar por su falta de stock o por errores nuestros al intentar armar la ingeniería de envío, dándonos cuenta al momento de la compra que el sitio web NO hace envíos a Argentina. Errores de los cuales nos hemos reído y aprendido.

También se definieron las cantidades de cada producto por envío. Esto fue limitado a 3 debido a la modalidad de pequeños envíos, la ley de importación que usamos/usaron los couriers para entrar nuestros paquetes a Argentina. La misma, permite importar productos para uso personal, sin fines comerciales, con un tope de hasta USD 3.000 por vuelo y 50 kg por paquete a un máximo de 3 unidades iguales de la misma especie por envío.

Razón por la cual, en Heltec, por ejemplo, hicimos dos compras de 3 unidades. En Amazon encontramos una buena oferta de los N37: dos unidades a 99 U$D. Sin embargo, no sabíamos si era posible comprar 2 packs (4 unidades en total), por cómo lo tomaría la aduana, por lo que probaremos y también estaremos comunicando nuestros resultados (a cruzar los dedos para que no lo retenga la aduana 🤞).

Con respecto a los envíos, páginas como RAK y Heltec no nos dieron tiempos estimados de entrega, suponemos que, mientras está siendo procesado, no habrá una fecha, y seguramente nos la comunicarán una vez que hayan despachado nuestro paquete. Spec5 es una de las páginas que NO hace envíos a Argentina, de hecho, es muy limitado el número de países a los que sí envía. ¿Cómo resolvimos esto? Comprando en la tienda oficial, pero con la dirección de los depósitos de AeroBox en Estados Unidos. La finalidad es que ellos lo traigan hasta Argentina. Posteriormente, nosotros lo retiraremos en sus depósitos de nuestro país o pagaremos el envío al interior; aún no lo definimos. Lo que si queríamos comentar que el envío más económico de Spec5 dentro de USA demora aproximadamente 12 días, lo cual es llamativo para tratarse de un envío dentro del mismo país, ya que hemos pagado envíos, con diferencias menores a 6U$D que en ese tiempo, supuestamente, lo trae hasta nuestra casa en ese mismo tiempo.

Creemos que Amazon nos ha brindado la experiencia más gratificante de compra, con buen precio y facilidad de envío. El gran problema aquí es que no tienen variedad en los dispositivos Meshtastic. Pierde mucho en este aspecto con Rockland, que si posee variedad en aparatos de RAK, Heltec o LilyGo, pero pierde mucho en el envío, ya que no los hace a Argentina y comprar allí para que luego Aerbox lo importe, no tenía sentido desde lo económico y logístico. Tiendamía es un servicio similar a AeroBox, pero con un funcionamiento diferente. Ellos te efectúan la compra desde Amazon, eBay ó AliExpress y te lo importan. El problema es que no funcionó bien con los enlaces de compras de AliExpress y, al no manejar stock y variedad de las tiendas alojadas en EEUU (Amazon o eBay, ya que en Rockland hasta el momento no se puede) no pudimos efectuar compras por esta vía, aunque sigue siendo una posibilidad para una futura adquisición.

AliExpress tiene diferentes formas de envío, stock en la mayoría de productos, marcas con su tienda oficial ahí (como SeedStudio o Elecrow), precios competentes pero... Y este es un GRAN PERO, no puedes hacer compras sucesivas con la misma tarjeta, al menos en nuestra experiencia. Esto es debido al método que poseen de antifraude, lo cual es positivo, pero no hay información previa de lo que puede ocurrir y dicho suceso hemos visto, han sufrido otras personas que han usado el sitio. Razón por la cual, solo compramos 3 WisMesh Tag y no pudimos hacer la compra de los otros 3 con un envío diferente. Intentamos cambiar de día y de perfil, pero aún así no pudimos.

Esto contribuyó a que SeedStudio, fuera un auténtico dolor de cabeza, ya que desde su página oficial no tiene casi stock de nada, muchos de sus productos estan en back order, otros sin stock y algunos con stock o bajo orden pero solo en USA o EU Entonces ustedes se preguntarán, ¿cuál es el problema?, si a esta altura del partido ya habían hecho compras en Estados Unidos y no existían motivos para no importar desde la Unión Europea. Bueno, la cuestión es que el warehuse que hace envíos a todo el mundo es China, los otros dos solo venden donde residen. De todas formas, conseguimos productos en stock en AliExpress, aquí el problema, era que no podíamos usar la tarjeta. A esta altura, las esperanzas se desvanecen, pero hubo un guiño del destino, luego de aproximadamente 3 semanas, conseguimos al P1 en stock, nostros ni lentos ni perezosos efectuamos nuestra compra, completando así toda la lista.


Este proceso de adquisición de hardware Meshtastic, más allá de llenar nuestro inventario, ha proporcionado una lección práctica e invaluable sobre la planificación logística internacional y las barreras de importación. Hemos confirmado que la implementación de redes de comunicación descentralizada en regiones con regulaciones aduaneras estrictas no depende únicamente de la tecnología, sino también de la ingeniería comercial y logística.

Nuestra experiencia ha revelado varios puntos críticos para cualquier proyecto similar:

  1. Flexibilidad de suministro: La dependencia de un único fabricante o plataforma (como la restricción de tarjetas de AliExpress o la falta de stock en sitios oficiales) es un riesgo operativo significativo. Fue esencial recurrir a múltiples canales (Amazon, couriers especializados como AeroBox, y tiendas oficiales) para asegurar la lista completa de dispositivos.

  2. Baterías: La restricción de envío de baterías por parte de couriers internacionales obliga a una planificación modular. Elegir dispositivos sin batería (como el P1) o utilizar servicios de importación indirecta (como con Spec5) añade complejidad, pero garantiza la llegada del hardware.

  3. Costo total de adquisición: El precio inicial del dispositivo es solo una parte. Los costos de envío internacional y los impuestos aduaneros, sumados a la necesidad de usar servicios de re-shipping (AeroBox) para fabricantes que no envían a Argentina, redefinen el verdadero costo del proyecto.

  4. Tiempos reales de entrega: La amplia dispersión en los tiempos de tránsito (desde envíos veloces de Amazon hasta las demoras en warehouses o la falta de fechas estimadas) subraya la necesidad de calendarios de implementación holgados y tolerantes al riesgo.

En conclusión, es una aventura la cual, aún no ha finalizado y nos estaremos viendo de nuevo en la segunda parte de esta experiencia, donde podrá ver los tiempos reales de entrega y demás observaciones pertinentes. ¡Hasta luego!

Explorando los ecosistemas de comunicación de bajo ancho de banda y larga distancia

· 5 min de lectura

Nuestra dependencia de las infraestructuras de comunicación centralizadas (desde las torres celulares hasta la fibra óptica) ha crecido exponencialmente. Esto ha traído una comodidad sin precedentes, pero también ha creado dependencias. Desastres naturales, fallos de infraestructura o la simple necesidad de operar en áreas remotas revelan que nuestra conectividad no es tan robusta como imaginamos. Esta fragilidad es la que afrontan los combatientes del fuego y nos ha impulsado en la búsqueda de una alternativa y así hemos arribado a la conectividad descentralizada.

Pero... ¿A qué nos referimos con una 'conectividad descentralizada'?

Se refiere a una red donde la información y el control no pasan a través de una única entidad o punto central (como un servidor principal, una torre celular o una autoridad de gobierno), sino que se distribuyen entre múltiples participantes, conocidos como nodos. Este enfoque puede aplicarse a través de tecnologías como redes de malla.

¿Y qué es una red mesh o red de malla?

Es un sistema de comunicación en donde los nodos trabajan juntos para crear una única red inalámbrica extendida, eliminando zonas sin cobertura. A diferencia de los routers tradicionales, que emiten una señal desde un solo punto, los sistemas mesh distribuyen la señal desde varios nodos interconectados. Esto permite una cobertura más amplia y estable.

Desde este espacio nos hemos propuesto explorar este ecosistema descentralizado y dentro del mismo, diferenciaremos dos grupos.

LoRa: Alcance extremo y resiliencia

El secreto detrás de las soluciones de larga distancia y bajo consumo energético como Meshtastic y Meshcore es la modulación LoRa (Long Range). Esta modulación es excepcionalmente robusta y le permite al receptor detectar la señal en condiciones muy adversas, otorgando un alcance extremo y una alta adaptabilidad ante las interferencias. Como contrapartida, LoRa se limita a un limitado ancho de banda, haciéndola ideal para la transmisión de pequeños paquetes de datos (texto, telemetría o coordenadas GPS).

Lo positivo de estas tecnologías es su bajo coste de implementación, ya que los nodos son económicos y con el conocimiento necesario, puedes armar uno propio, bajando aún más los costes. El firmware al ser software libre, es de público uso y modificación, además operan en bandas ISM, lo cual no requiere de una licencia de Radioaficionado para poder operarlas.

Dentro de este grupo, el firmware Meshtastic se ha establecido como la opción de código abierto por excelencia. Opera una Malla Nómada, donde cualquier nodo puede extender la cobertura de la red repitiendo los mensajes que escucha, y utiliza un protocolo de enrutamiento específico para que los mensajes encuentren el destino de forma automática. Esto lo logra enviando el mensaje a todos los dispositivos disponibles, saltando entre ellos, con el fin de encontrar el destinatario, pero esta capacidad de salto está a limitada a un máximo de 8.

Por otro lado Meshcore utiliza la misma modulación pero implementa una Malla Fija, donde solo algunos nodos designados, actúan como repetidores y el enrutamiento similar al anterior, envía el mensaje a todos los dispositivos disponibles, con el fin de encontrar la ruta más corta de llegada a un nodo, una vez logrado esto, guarda la ruta, haciendo que la comunicación sea más rápida y que un mensaje pueda saltar hasta 64 veces, mucho más que en Meshtastic.

RF Digital Licenciada: Agilidad y arquitectura propietaria

Las plataformas como goTenna y Beartooth optan por una modulación distinta a las tecnologías del bloque anterior. Poseen una mayor velocidad de datos relativa y una gestión de red que puede estar mejor optimizada para tareas específicas. Además estas tecnologías poseen un mejor soporte que las anteriormente mencionadas.

Ambas soluciones crean una red de malla, un concepto fundamental que describe una red formada de manera espontánea por dispositivos que se comunican directamente sin depender de una infraestructura central.

goTenna Mesh utiliza su propio protocolo propietario Aspen Grove para crear esta red mesh. Su diseño está optimizado para la mensajería de texto y GPS, ofreciendo una experiencia plug-and-play con un firmware cerrado que opera en bandas VHF (142-175 MHz) y UHF (445-480 MHz). Sumado a una potencia significativamente superior a las demás, logra un alcance superior, además de la calidad militar de sus componente, hacen que sorteen mejor la interferencia por ruido u obstáculos. Pero es y con diferencia, la tecnología más costosa de las aquí presentadas.

Beartooth, por su parte, se enfocó en paquetes de datos más grandes, como la Voz PTT (Push-to-Talk), aprovechando la mayor velocidad de datos. Se encuentra operada en bandas ISM, lo que le permite ser utilizado sin licencia. En cuanto al alcance está por detras de las demás tecnologías también permite trabajar con la ubicación GPS.


La exploración de los formatos de comunicación digital fuera de la red revela un panorama donde no existe una solución única, cada una tiene caractísticas particularmente únicas y positivas, así como también sus contras. Cada uno de estos sistemas puede complementar los medios de comunicación habitualmente usados, con el fin de satisfacer necesidades de comunicación específicas en contextos vulnerables.

Desde este espacio queremos resaltar que el futuro de la conectividad descentralizada no reside en la victoria de una tecnología sobre otra. Sin embargo, nosotros NO hemos definido una tecnología con la cual llevar adelante este proyecto, pero por el momento intentaremos utilizar la tecnología Meshtastic, aunque estamos abiertos al uso de una tecnología complementaria o a un cambio de tecnología en un futuro, de ser necesario.

Creemos que Meshtastic nos permite solucionar los mencionados problemas de comunicación a un costo asequible, además de brindar un panorama estable de partida con el cual empezar a trabajar. Somos conscientes que es una tecnología en desarrollo, que nos queda mucho por aprender y practicar, pero estamos dispuestos a ello para ayudar tanto a los combatientes y rescatistas, como al proyecto Meshtastic, así como su comunidad hispanoparlante.