Cómo viaja un mensaje en Meshtastic

Publicado el 30 de agosto de 2026 · Pilar: Aprende

Ya vimos cómo funciona una red mesh y qué papel cumplen las regiones, los presets y los canales. Ahora seguiremos un mensaje desde que tocas Enviar hasta que aparece en otro dispositivo.

El recorrido parece instantáneo, pero incluye varios pasos:

1. La aplicación entrega el texto al nodo local.
2. El nodo crea el paquete y aplica el cifrado correspondiente.
3. La radio espera una oportunidad para transmitir.
4. Otros nodos pueden escucharlo y retransmitirlo.
5. El nodo de destino o los miembros del canal procesan el paquete.
6. La aplicación receptora muestra el contenido.
7. En algunos casos, una confirmación intenta regresar al emisor.

AplicaciónEscribe y envía

→

BASECrea y transmite

→

RELÉRetransmite si hace falta

→

MOBiRecibe y descifra

La idea más importante de este artículo es:

Enviar, recibir y confirmar no son el mismo evento.

1. El mensaje comienza en la aplicación

Cuando escribes desde Android, iPhone, web o una computadora, el teléfono todavía no está transmitiendo por LoRa.

Primero, la aplicación se comunica con el nodo mediante Bluetooth, wifi o USB. En nuestro ejemplo:

Celular → BASE

La aplicación entrega al nodo el texto, el canal seleccionado y, si corresponde, el destinatario. BASE se encarga de convertir esa intención en un paquete apto para la red Meshtastic.

Si el teléfono pierde conexión con BASE antes de completar este paso, el mensaje ni siquiera ha entrado a la malla. Este fallo es diferente a que LoRa no consiga llegar a MOBi.

2. El nodo crea un paquete

Un paquete contiene más que el texto visible. También incluye información necesaria para que la red lo procese, como:

• un identificador de paquete;
• el nodo de origen;
• un destino específico o la dirección de difusión;
• el tipo de información transportada;
• el canal utilizado;
• el límite de saltos;
• datos de control para el protocolo.

El método de cifrado depende del tipo de mensaje:

• Mensajes de canal: el contenido usa AES256-CTR con la PSK de ese canal.
• Mensajes directos entre nodos compatibles desde firmware 2.5: utilizan criptografía de clave pública cuando el intercambio de claves ya ocurrió. El nodo de destino usa su clave privada para descifrarlos.

El encabezado necesario para transportar el paquete no se cifra. Por eso otros nodos pueden retransmitir tráfico cuyo contenido no pueden leer.

El identificador permite reconocer copias del mismo paquete. Esto es fundamental porque, dentro de una malla, más de un nodo puede escuchar una transmisión.

3. El nodo no transmite necesariamente en el mismo instante

LoRa utiliza un medio compartido. BASE no debe actuar como si tuviera una frecuencia exclusiva.

Antes de transmitir, Meshtastic utiliza CSMA/CA. La radio realiza Channel Activity Detection (CAD): si detecta el canal ocupado, espera; cuando queda libre, añade una espera aleatoria basada en la utilización del canal para reducir la posibilidad de que varios nodos transmitan simultáneamente.

Este mecanismo reduce colisiones, pero no las elimina. Por eso dos mensajes enviados bajo condiciones aparentemente iguales no siempre siguen exactamente el mismo recorrido ni tardan lo mismo.

El tiempo de aire importa: los presets más lentos, los paquetes repetidos y una malla congestionada mantienen el canal ocupado durante más tiempo.

4. La primera transmisión

Cuando llega su oportunidad, BASE emite el paquete por LoRa.

Todos los nodos físicamente capaces de escuchar esa señal y configurados con parámetros de radio compatibles pueden detectarla. Sin embargo, no todos harán lo mismo:

• MOBi puede ser el destinatario.
• Un nodo RELÉ puede considerar una retransmisión.
• Otro nodo puede reconocer que ya procesó ese paquete.
• Un nodo sin la clave correcta puede no descifrar el contenido.
• Un equipo fuera de alcance no sabrá que la transmisión ocurrió.

La radio no dibuja una ruta fija antes de comenzar. El recorrido surge de los enlaces disponibles en ese momento.

5. Comunicación directa o retransmitida

Si MOBi escucha directamente a BASE, el paquete llega sin retransmisiones:

BASE → MOBi

Si no existe ese enlace, pero un nodo intermedio conecta ambos lados, el recorrido puede ser:

BASE → RELÉ → MOBi

Cada retransmisión consume parte del hop limit. Si el límite llega a cero antes de alcanzar un receptor útil, el paquete deja de propagarse.

Para mensajes de canal, Meshtastic utiliza managed flooding: los nodos esperan brevemente antes de retransmitir y pueden cancelar su copia si oyen que otro nodo ya la propagó. El tiempo de espera considera, entre otros factores, el SNR recibido.

Desde firmware 2.6, los mensajes directos pueden aprovechar next-hop routing. Después de aprender una ruta útil, cada salto puede preferir un relé concreto; si esa ruta deja de funcionar, el sistema vuelve a managed flooding en el último intento. Esto reduce transmisiones innecesarias sin convertir la entrega en una garantía.

6. Mensaje de canal y mensaje directo

Desde la aplicación, ambos parecen mensajes de texto, pero no tienen el mismo destino lógico.

Mensaje de canal

Se envía por difusión a los nodos que comparten ese canal. No existe un único receptor final: cualquier miembro compatible que lo reciba y posea la clave puede mostrarlo.

Es apropiado para:

• avisos a un grupo;
• coordinación comunitaria;
• conversaciones familiares compartidas;
• pruebas donde varios nodos deben observar el mismo paquete.

Mensaje directo

Se dirige a un nodo específico. La red puede usar retransmisiones intermedias, pero el destino lógico está identificado.

Es apropiado para:

• una conversación entre dos nodos;
• información destinada a una sola persona;
• situaciones donde interesa obtener una confirmación del destino.

Un mensaje directo no significa que exista un enlace de radio exclusivo entre ambos. Otros nodos todavía pueden ayudar a transportarlo.

Mensaje de canal

BASEDifusión

Nodo AMiembro del canal

Nodo BMiembro del canal

Mensaje directo

BASE

destino: MOBi

MOBi

7. Qué ocurre cuando el receptor obtiene el paquete

Al recibirlo, MOBi verifica y procesa el paquete. Si tiene la clave del canal correcta, puede descifrar el contenido y entregarlo a la aplicación conectada.

Aquí conviene separar otra vez dos enlaces:

• La radio de MOBi recibió el paquete por LoRa.
• El teléfono conectado a MOBi recibió la información del nodo.

El nodo puede recibir y descifrar paquetes sin que el teléfono esté conectado en ese instante. Sin embargo, no debes asumir que todo mensaje quedará almacenado indefinidamente para aparecer después: la entrega posterior a la aplicación depende de la plataforma, las colas disponibles y funciones específicas como store-and-forward.

Para comprobar una prueba de alcance, mantén un método de registro conocido en el receptor y no te limites a mirar la pantalla del emisor.

8. Hay confirmaciones explícitas e implícitas

En un mensaje directo que solicita entrega confiable, el destino puede enviar un ACK explícito de regreso al emisor. Ese ACK es otro paquete y debe completar su propio recorrido.

El proceso simplificado es:

1. BASE envía el mensaje.
2. MOBi recibe el mensaje.
3. MOBi genera la confirmación.
4. La confirmación intenta regresar.
5. BASE la recibe y actualiza el estado mostrado en la aplicación.

Observa el punto crítico: el paso 2 puede completarse aunque fallen los pasos 3, 4 o 5.

Los mensajes de canal funcionan de otra manera. Para evitar una tormenta de respuestas, el firmware elimina la solicitud de ACK explícito de los paquetes difundidos por radio. El emisor puede considerar la retransmisión que escucha desde otro nodo como un ACK implícito. Esto confirma que al menos un nodo retransmitió el paquete; no demuestra que cada miembro del canal lo recibió.

Los paquetes confiables que no obtienen ACK pueden ser retransmitidos por el firmware, hasta un máximo de tres reintentos según la documentación oficial.

Por eso:

La ausencia de ACK no prueba por sí sola que el mensaje original se perdió.

El enlace puede ser asimétrico. La orientación de una antena, una estructura, el ruido o el movimiento pueden permitir BASE → MOBi y dificultar MOBi → BASE.

En FS001 encontramos precisamente mensajes presentes en los registros del receptor aunque el emisor mostrara falta de confirmación.

BASEEmisor

Mensaje recibido

ACK puede fallar

MOBiReceptor

9. Qué puede significar el estado que muestra la app

Las aplicaciones intentan resumir un proceso de radio complejo mediante iconos. El significado exacto puede variar entre versiones y plataformas, pero editorialmente conviene pensar en tres niveles de evidencia:

• Enviado al nodo local: la aplicación entregó el mensaje a BASE.
• Transmitido por radio: BASE intentó emitir el paquete.
• Confirmado: llegó un ACK explícito del destino o, en una difusión, se observó una retransmisión que funciona como ACK implícito.

Ninguno sustituye el registro del receptor cuando se quiere evaluar una prueba de campo.

Un signo de exclamación, un tiempo agotado o la ausencia de confirmación deben describirse como sin ACK o no confirmado, no automáticamente como “paquete perdido”.

El próximo artículo de Aprende explicará en detalle los ACK, el signo de exclamación y cómo interpretar esa evidencia.

10. Por qué un mensaje puede fallar

El paquete puede detenerse en diferentes puntos:

Antes de entrar a la malla

• la aplicación perdió conexión con el nodo;
• el nodo estaba apagado o reiniciándose;
• se seleccionó un canal incorrecto.

Durante la transmisión LoRa

• los nodos usan región, preset o frecuencia incompatibles;
• la señal queda bloqueada o demasiado débil;
• dos transmisiones colisionan;
• el canal está congestionado;
• el hop limit se agota;
• no existe un nodo intermedio con enlaces útiles.

Después de llegar al nodo

• el receptor no posee la clave correcta;
• el teléfono no está conectado;
• la aplicación todavía no actualizó la conversación;
• el ACK de regreso no encuentra un enlace útil.

Decir simplemente “no llegó” es insuficiente para diagnosticar. Hay que identificar en qué etapa se perdió la evidencia.

11. Cómo comprobar el recorrido con BASE y MOBi

Puedes realizar una prueba sencilla:

1. Confirma que BASE y MOBi comparten región, preset y canal.
2. Mantén ambos cerca y conecta un teléfono a cada uno.
3. Envía un mensaje de canal numerado: C-001.
4. Verifica la hora y el canal en MOBi.
5. Envía un mensaje directo numerado: D-001.
6. Anota el estado mostrado en BASE.
7. Comprueba directamente si D-001 aparece en MOBi.
8. Separa los nodos o introduce un obstáculo controlado.
9. Repite con C-002 y D-002.
10. Conserva capturas o exporta los registros disponibles.

Usar identificadores evita confundir mensajes repetidos. Registrar ambos extremos permite distinguir entre recepción real y confirmación de regreso.

No uses una sola transmisión para declarar que un enlace es confiable. Repite la prueba y documenta hora, ubicación general, orientación de antena, firmware y configuración.

Resumen

• La aplicación entrega el mensaje al nodo local antes de que exista una transmisión LoRa.
• El nodo crea, cifra e identifica el paquete.
• La radio comparte el canal y administra cuándo transmite.
• El paquete puede llegar directamente o mediante retransmisiones.
• Los identificadores y el hop limit ayudan a controlar duplicados y propagación.
• Un mensaje de canal se difunde a un grupo; uno directo identifica un destino.
• El receptor puede obtener el mensaje aunque el ACK de regreso no llegue.
• “Sin ACK” no equivale automáticamente a “mensaje perdido”.
• Para una prueba seria, compara la evidencia del emisor y del receptor.

Continúa la ruta Aprende

• Anterior: Canales, regiones y configuración básica en Meshtastic
• Siguiente: ¿Qué significa el signo de exclamación en Meshtastic? ACK y mensajes sin confirmar
• Repasa la malla: Cómo funciona una red mesh de Meshtastic
• Ponlo en práctica: Cómo configurar tu primer nodo Meshtastic
• Compara con evidencia real: FS001: terreno, estructuras y orientación de antena

Fuentes técnicas

• Descripción general de Meshtastic
• Algoritmo oficial: broadcasts, ACK, reintentos y next-hop routing
• Configuración LoRa y hop limit
• Cifrado oficial: canales AES256-CTR y mensajes directos con PKC
• API de Python: envío y recepción de paquetes

---

MeshHubPR — tecnología abierta, explicada desde Puerto Rico.