LoRa no es LoRaWAN: dónde encaja Meshtastic

Dos radios LoRa que no se entienden

Imagina que tienes sobre la mesa dos pequeñas placas electrónicas. Las dos incorporan un transceptor LoRa. Las dos están preparadas para trabajar en la banda utilizada habitualmente en Europa. Incluso podrían llevar el mismo modelo de chip y una antena muy parecida.

En una instalas Meshtastic. En la otra, un programa para enviar medidas a una red LoRaWAN. Las enciendes, las colocas una junto a otra y esperas que se comuniquen. No lo hacen.

¿Se ha estropeado alguna? No necesariamente. Lo que ocurre es que utilizar la misma tecnología de radio no significa utilizar el mismo protocolo de comunicación. Y entender esa diferencia evita muchas compras equivocadas, configuraciones inútiles y expectativas que ninguna de las dos redes puede cumplir.

En la primera pieza de esta colección, «Meshtastic: mensajes sin cobertura móvil ni Internet», vimos qué problema resuelve la mensajería sin infraestructura. Ahora vamos a situarla en el mapa de las comunicaciones LoRa.

Lo que vas a descubrir

• Qué es realmente LoRa y qué parte de la comunicación resuelve.
• Por qué LoRaWAN necesita una arquitectura de red, pero no necesariamente una operadora ni Internet público.
• Cómo Meshtastic utiliza LoRa para comunicar nodos entre sí, incluso mediante saltos intermedios.
• Por qué un gateway LoRaWAN no es un repetidor Meshtastic.
• Qué tecnología tiene sentido según el problema que quieras resolver.

1. LoRa: cómo viajan los bits por el aire

LoRa —de long range, largo alcance— es una tecnología de modulación de radio desarrollada por Semtech. Dicho sin tecnicismos innecesarios, la modulación es la manera de representar información mediante cambios controlados de una señal de radio para que otro equipo pueda recuperarla.

En concreto, LoRa utiliza una técnica de espectro ensanchado basada en señales cuya frecuencia varía a lo largo del tiempo, conocidas como chirps. Esa forma de transmitir permite trabajar con señales débiles y favorece enlaces de largo alcance a cambio de un caudal de datos reducido. El alcance final, por supuesto, también depende de la antena, el entorno, la potencia y los parámetros de radio.

Pero aquí está la frontera esencial: LoRa no decide por sí sola quién puede participar, a quién va dirigido un mensaje, cómo se identifica un dispositivo ni qué debe ocurrir cuando un paquete llega a su destino.

Piensa en dos personas que pueden producir y escuchar sonidos. Eso no garantiza que compartan idioma, reglas de conversación o una forma de organizar los mensajes. La capacidad física de transmitir es solo una parte del sistema.

Por eso es posible construir sobre LoRa diferentes formas de comunicación: un enlace directo entre dos placas con un protocolo propio, una red de sensores LoRaWAN o una red de mensajería Meshtastic. No es LoRa quien impone la topología de la red.

Para ir más hondo — ¿LoRa es una red?

No. En sentido estricto, LoRa designa la tecnología de radio o capa física; una red necesita además reglas para identificar dispositivos, formar paquetes, gestionar el acceso al canal y entregar la información. LoRaWAN define esas reglas dentro de un estándar para redes de gran alcance y bajo consumo. Meshtastic emplea reglas propias para una finalidad distinta.

2. LoRaWAN: conectar dispositivos con una red de datos

Imagina un sensor de humedad instalado en una finca. Cada cierto tiempo envía una medida breve. El agricultor no necesita mantener una conversación con el sensor: necesita recibir sus datos, almacenarlos y consultarlos.

Ese es uno de los escenarios donde encaja LoRaWAN, un protocolo de comunicación estandarizado por la LoRa Alliance para redes de dispositivos de bajo consumo y gran cobertura.

La arquitectura habitual se denomina estrella de estrellas. El nombre puede intimidar, pero la idea es sencilla:

1. Un dispositivo final, como un sensor, transmite por radio utilizando la capa física LoRa.
2. Uno o varios gateways LoRaWAN pueden recibir esa misma transmisión.
3. Los gateways hacen de puente entre el enlace de radio y una red de datos IP, por la que envían los paquetes hacia un servidor de red.
4. La infraestructura de red procesa los mensajes y los entrega, a través de los componentes correspondientes, a la aplicación que va a utilizarlos.

El tráfico de respuesta, cuando lo hay, sigue el recorrido inverso y las reglas que establece LoRaWAN. No todos los detalles caben aquí; activación, clases de dispositivos y gestión de mensajes tendrán sus piezas específicas.

Lo importante es observar dónde se toman las decisiones de red. En LoRaWAN, la función central del servidor es fundamental: el gateway recibe y reenvía tramas, pero no sustituye al servidor de red ni se comporta como un participante de una malla Meshtastic. Un gateway LoRaWAN habitual utiliza un concentrador capaz de atender varios canales y transmisiones de radio, no simplemente una placa que escucha una única configuración.

LoRaWAN no significa «The Things Network»

The Things Network (TTN) es una red comunitaria y un servicio concreto que utiliza LoRaWAN mediante The Things Stack. No es el protocolo en sí mismo.

También existen redes LoRaWAN privadas, con sus propios gateways y servidores. Una organización puede alojar su servidor en sus instalaciones y conectar los gateways mediante una red IP local, sin depender necesariamente de Internet público. La infraestructura sigue existiendo, aunque no esté en la nube.

De modo que estas tres frases significan cosas diferentes:

• «Uso LoRa»: describe la tecnología de radio.
• «Uso LoRaWAN»: identifica el protocolo y la arquitectura de red.
• «Uso TTN»: indica una de las redes o plataformas posibles sobre LoRaWAN.

Hay una precisión adicional para quien avance más: el estándar incluye una función opcional denominada LoRaWAN Relay, con la que un equipo compatible puede extender la cobertura hacia la red. No convierte LoRaWAN en una malla general entre sensores como Meshtastic; la comunicación sigue orientada a la infraestructura LoRaWAN.

3. Meshtastic: otra forma de organizar esas mismas radios

Ahora cambiemos de problema. En vez de un sensor que informa a una aplicación, piensa en tres personas que caminan por una zona sin cobertura móvil. Quieren intercambiar mensajes cortos y posiciones. Quizá las dos más alejadas no puedan oírse directamente, pero una tercera está situada en un punto alto entre ambas.

Meshtastic es un proyecto abierto que utiliza radios LoRa para crear un sistema de mensajería descentralizado. No habla LoRaWAN: dispone de sus propios paquetes, canales y mecanismos de retransmisión.

El recorrido de un mensaje puede ser tan sencillo como nodo A → nodo B. Y, cuando las condiciones lo permiten, puede ampliarse mediante un nodo intermedio: A → C → B. No hace falta que ese tráfico pase primero por un gateway LoRaWAN ni que exista un servidor que organice toda la conversación.

Eso tampoco significa que cualquier nodo repita siempre cualquier paquete. Meshtastic emplea mecanismos de difusión gestionada y límites de saltos para evitar retransmisiones innecesarias. Desde la versión 2.6 del firmware, además, el tratamiento de mensajes directos tiene particularidades propias. La explicación detallada merece otra pieza; basta por ahora con recordar que la malla tiene reglas y una capacidad limitada: cada retransmisión vuelve a ocupar el mismo canal de radio que comparten todos los nodos.

En el uso más común, el teléfono actúa como pantalla y teclado, conectado por Bluetooth al nodo cercano. El teléfono no envía por LoRa: lo hace la radio del nodo. Y los nodos pueden continuar participando en la red aunque no haya un teléfono enlazado en cada momento.

¿Y MQTT? ¿No conecta Meshtastic a Internet?

Puede hacerlo, pero es una extensión opcional, no una condición para que funcione la malla local.

Un nodo Meshtastic con una conexión IP disponible —propia, por wifi o Ethernet, o la del teléfono enlazado— puede utilizar MQTT para intercambiar tráfico con un servidor y, según su configuración, conectar redes separadas geográficamente. En ese escenario hay una infraestructura adicional, y esa parte sí depende de conectividad IP.

Sin embargo, al apagar esa extensión, los nodos que se alcanzan por radio siguen pudiendo intercambiar mensajes locales. MQTT no convierte Meshtastic en LoRaWAN, igual que conectar un ordenador a Internet no lo convierte en un teléfono móvil.

4. Dos arquitecturas, dos propósitos

La tabla no pretende declarar un ganador. Ambos enfoques aprovechan la radio LoRa, pero están diseñados para resolver problemas distintos.

LoRaWAN facilita organizar muchos dispositivos finales dentro de una red con servicios de gestión y aplicaciones. Meshtastic prioriza una comunicación distribuida que puede continuar funcionando localmente sin esa infraestructura. Ninguno escapa de los límites de capacidad, propagación e interferencias propios del medio radioeléctrico.

5. Entonces, ¿por qué no puedo comunicar un equipo con el otro?

Volvamos a las dos placas del comienzo. Compartir un transceptor LoRa no basta.

Para recibir correctamente una transmisión deben coincidir parámetros físicos relevantes: la frecuencia, el ancho de banda, el factor de dispersión y otros ajustes de radio. Pero, aunque dos dispositivos pudieran demodular una señal físicamente compatible, seguiría faltando entender su formato de paquete, sus identificadores, sus reglas de acceso y sus procedimientos de comunicación.

Meshtastic y LoRaWAN no hablan el mismo protocolo. Por ello, un gateway LoRaWAN convencional no recibe y entrega automáticamente mensajes Meshtastic a su servidor como si fueran tramas LoRaWAN, ni un nodo Meshtastic se incorpora a TTN por estar cerca de un gateway.

Lo mismo sucede a la inversa: un nodo Meshtastic no se convierte en un gateway LoRaWAN porque incorpore un transceptor compatible con LoRa. Un gateway LoRaWAN habitual tiene capacidades de recepción, concentrador y software orientadas a ese estándar; un nodo Meshtastic tiene otras funciones.

¿Y si utilizo la misma placa física?

Puede ser posible utilizar una placa compatible en proyectos distintos, cargando el firmware apropiado y respetando sus limitaciones de hardware. Eso no implica que pueda hablar simultáneamente ambos protocolos ni que cualquier placa admita cualquier firmware. La compatibilidad concreta se comprueba modelo por modelo.

6. Tres situaciones para elegir con criterio

Situación A · Un grupo de excursionistas. Quieren enviarse mensajes cortos y posición en una zona donde no hay cobertura móvil. Pueden llevar nodos LoRa compatibles con Meshtastic y, si hace falta, aprovechar retransmisiones entre ellos. Para esa comunicación local no necesitan TTN ni un gateway LoRaWAN. El resultado dependerá del terreno, las antenas y la configuración.

Situación B · Sensores en un invernadero. Hay que recoger periódicamente temperatura y humedad, conservar las medidas y visualizarlas en una aplicación. Una red LoRaWAN con gateway y servidor puede encajar bien. Esos componentes pueden pertenecer a una plataforma comunitaria, a un proveedor o a una instalación privada.

Situación C · Un edificio sin conexión a Internet. Se quiere registrar la lectura de varios sensores y verla en un ordenador local. Puede desplegarse una red LoRaWAN privada con gateway, servidor y aplicación en la red interna. No disponer de Internet no obliga a utilizar Meshtastic; lo determinante es qué arquitectura necesita el proyecto.

En todos los casos, si se trabaja en España, los equipos y su configuración deben respetar las condiciones radioeléctricas aplicables a la banda y al uso previsto. Emplear LoRa no concede permiso para transmitir con cualquier potencia, frecuencia o tiempo de ocupación. La regulación merece un tratamiento específico antes de cualquier práctica.

7. Errores frecuentes que conviene desterrar

• «LoRa y LoRaWAN son lo mismo». No. Una es la tecnología de radio; el otro, un protocolo de red que la utiliza.
• «Para usar LoRa necesito TTN». No. Puedes usar LoRa con Meshtastic, con protocolos propios o con una red LoRaWAN privada.
• «LoRaWAN siempre depende de Internet». No. Depende de una infraestructura de red, que puede funcionar en una instalación privada con conectividad IP local.
• «LoRaWAN es una malla como Meshtastic». No. La arquitectura habitual es estrella de estrellas; su función opcional de relay no equivale a la malla de Meshtastic.
• «Un gateway LoRaWAN amplía automáticamente la cobertura Meshtastic». No. Compartir tecnología de radio no hace compatibles los protocolos.
• «Si Meshtastic usa MQTT, entonces usa LoRaWAN». No. MQTT es una integración IP opcional e independiente del protocolo de radio utilizado.

Qué permite y qué no permite concluir esta pieza

Ahora puedes distinguir qué corresponde a la radio y qué corresponde a la red, leer con criterio la descripción de un equipo y evitar confundir una red de sensores con una malla de mensajería.

Este artículo no demuestra que un sistema alcance más distancia que otro ni compara su autonomía experimental. Tampoco es una guía de montaje: no hemos medido cobertura, consumo ni pérdidas de paquetes en esta pieza. Esas conclusiones requieren configuraciones concretas y ensayos documentados, no deducciones a partir de los nombres de las tecnologías.

Siguiente lectura

La teoría se vuelve mucho más clara cuando puedes ver un paquete llegar a otra radio. El siguiente paso previsto en la colección es «Montamos una red Meshtastic con dos nodos»: identificaremos el hardware, configuraremos los equipos y comprobaremos la comunicación directa.

Para profundizar después, desarrollaremos por separado «Anatomía de una red LoRaWAN» y «¿Cómo puede LoRa llegar tan lejos consumiendo tan poco?».