¿Qué significa el signo de exclamación en Meshtastic?

Publicado el 3 de septiembre de 2026 · Pilar: Aprende

Envías un mensaje desde Meshtastic, esperas unos segundos y aparece un signo de exclamación: !.

La reacción natural es pensar: “el mensaje no llegó”. Pero esa conclusión puede ser incorrecta.

En el artículo anterior seguimos cómo viaja un mensaje en Meshtastic. Vimos que el mensaje original y la confirmación recorren trayectos separados. Ahora examinaremos qué evidencia ofrece cada estado y cómo verificar lo sucedido.

La regla principal es:

Sin confirmación no significa necesariamente sin recepción.

1. ¿Qué es un ACK?

ACK es la abreviatura de acknowledgment. Meshtastic utiliza dos mecanismos que conviene separar:

• ACK explícito: el nodo destinatario responde con un paquete de enrutamiento asociado al ID del mensaje directo.
• ACK implícito: en una difusión, el emisor oye que otro nodo retransmitió su mismo paquete.

En una comunicación directa simplificada:

1. BASE envía un mensaje dirigido a MOBi.
2. MOBi recibe el paquete.
3. MOBi genera una confirmación.
4. La confirmación intenta regresar a BASE.
5. BASE recibe el ACK y la aplicación actualiza el estado.

El ACK no viaja dentro del mensaje original. Es tráfico adicional y necesita completar su propio recorrido de regreso.

BASEEmisor

Mensaje recibido

ACK puede fallar

MOBiReceptor

Si el mensaje llegó en el paso 2, pero la respuesta falla en los pasos 3, 4 o 5, MOBi puede tener el texto mientras BASE sigue sin confirmación.

2. Entonces, ¿qué indica el signo de exclamación?

En términos prácticos, el signo ! indica que la aplicación o el nodo emisor no obtuvo la confirmación esperada dentro del proceso previsto.

No demuestra por sí solo cuál de estas situaciones ocurrió:

• el mensaje nunca salió correctamente;
• el paquete salió, pero no alcanzó el destino;
• el destino recibió el mensaje, pero no pudo devolver el ACK;
• el ACK salió, pero se perdió durante el regreso;
• el firmware agotó sus reintentos sin recibir un ACK que pudiera correlacionar con el ID original.

Por eso MeshHubPR clasifica ese resultado como sin ACK o no confirmado, no automáticamente como perdido. Según la documentación oficial, un paquete confiable puede ser reenviado hasta tres veces antes de que el nodo genere internamente un error por falta de confirmación.

Los símbolos exactos y el momento en que aparecen pueden variar entre Android, iOS, web y versiones de firmware. Siempre conviene interpretar el icono junto con la evidencia de ambos nodos.

3. Recibido y confirmado son resultados diferentes

Un mensaje puede caer en cuatro escenarios básicos:

Receptor: sí · ACK: síRecibido y confirmadoMayor evidencia en ambos extremos

Receptor: sí · ACK: noRecibido, sin ACKLa entrega ocurrió; faltó el regreso

Receptor: no observado · ACK: noNo confirmadoNo afirmar pérdida sin revisar límites del registro

Receptor: no revisado · estado favorableEvidencia parcialÚtil en uso diario, insuficiente para un ensayo

Recibido y confirmado

El receptor muestra el mensaje y el emisor obtiene la confirmación. Es el escenario con mayor evidencia visible desde ambos extremos.

Recibido, pero sin ACK

El receptor tiene el mensaje, pero el emisor muestra ! o un estado no confirmado. La entrega ocurrió; falló o no se observó la evidencia de regreso.

No observado en el receptor y sin ACK

No existe confirmación y tampoco aparece el mensaje en el registro revisado del destino. Es evidencia consistente con un fallo, aunque un registro incompleto todavía puede limitar la conclusión.

Estado positivo sin revisar el receptor

La aplicación del emisor muestra una señal favorable, pero no se inspeccionó el otro extremo. Para uso cotidiano puede ser suficiente; para una prueba técnica, sigue siendo mejor verificar ambos lados.

La interfaz ayuda al usuario, pero no sustituye una metodología de prueba.

4. Por qué puede fallar solo el trayecto de regreso

La radio no siempre funciona de forma simétrica.

Aunque BASE y MOBi usen equipos iguales, el entorno de cada uno puede ser distinto:

• una antena puede estar vertical y la otra inclinada;
• un nodo puede estar junto a metal o dentro de un vehículo;
• un extremo puede tener más ruido de radio;
• el cuerpo de una persona puede bloquear parcialmente una antena;
• un nodo puede estar más alto o tener mejor línea de vista;
• el recorrido de vuelta puede coincidir con otras transmisiones;
• un relé disponible durante la ida puede no participar de igual forma en el regreso.

Así, BASE → MOBi puede funcionar mientras MOBi → BASE falla.

Esto no viola ninguna regla de LoRa. Solo demuestra que un enlace útil en una dirección no garantiza las mismas condiciones en la otra.

5. Lo que observamos en FS001

Durante FS001: terreno, estructuras y orientación de antena, comparamos los registros de BASE y MOBi.

Encontramos casos donde:

• el transmisor mostraba !;
• no se había observado una confirmación en el emisor;
• el mismo mensaje sí aparecía en los datos del receptor.

Por tanto, clasificar todos los signos de exclamación como paquetes perdidos habría producido un resultado falso.

La etiqueta correcta fue Sin ACK. La recepción se determinó usando la evidencia del nodo receptor, no solamente el icono mostrado en el teléfono del transmisor.

Ese hallazgo es pequeño, pero metodológicamente importante: medir solo desde el emisor puede subestimar la entrega real.

6. Mensajes directos y mensajes de canal

No todos los mensajes producen la misma clase de confirmación.

Mensaje directo

Tiene un destino lógico específico. Cuando solicita entrega confiable, el destino devuelve un ACK explícito relacionado con el ID del paquete. Desde firmware 2.5, los DMs compatibles usan criptografía de clave pública cuando el intercambio de claves ya ocurrió; desde 2.6 pueden aprovechar rutas next-hop aprendidas. Si el ACK no regresa, el emisor puede mostrar el mensaje como no confirmado aunque el destino lo haya recibido.

Mensaje de canal

Se difunde a los miembros del canal. No existe un único destinatario responsable de confirmar que “todo el grupo” lo recibió.

Para evitar una tormenta de ACK, el firmware elimina la solicitud de confirmación explícita de los paquetes broadcast enviados por radio. En su lugar, si el emisor oye que otro nodo retransmitió el mismo paquete, genera localmente un ACK implícito.

Ese ACK implícito demuestra que al menos otro nodo lo recibió lo suficiente como para retransmitirlo. No demuestra que todos los miembros del canal lo hayan recibido, descifrado o leído.

Por eso no debes interpretar el mismo símbolo como una garantía universal para mensajes directos y mensajes de canal.

7. ACK no significa que una persona leyó el mensaje

Una confirmación pertenece al sistema de comunicaciones, no a la atención humana.

Un ACK puede indicar que el paquete llegó o fue procesado por el nodo correspondiente, pero no significa necesariamente que:

• el teléfono estaba en manos de la persona;
• la aplicación estaba abierta;
• apareció una notificación;
• el usuario leyó el contenido;
• la persona comprendió o actuó sobre el mensaje.

En una emergencia, utiliza frases breves que pidan una respuesta humana concreta:

RECIBIDO. RESPONDE OK Y TU UBICACIÓN GENERAL.

Esa respuesta escrita aporta evidencia diferente al ACK automático.

8. Cómo verificar un mensaje sin confirmación

Si aparece !, sigue este orden:

1. No lo declares perdido inmediatamente.
2. Anota la hora, el canal y el texto o identificador del mensaje.
3. Revisa si el receptor muestra exactamente ese mensaje.
4. Si haces una prueba formal, consulta el registro exportado del receptor.
5. Confirma que ambos nodos usaban la misma región, preset y canal.
6. Revisa batería, orientación de antena y posición física.
7. Repite con un mensaje numerado nuevo.
8. Prueba también la dirección contraria.
9. Registra por separado recepción y ACK.

Una tabla de campo puede usar estas columnas:

ID	Dirección	Receptor lo registra	Emisor obtiene ACK	Clasificación
D-001	BASE → MOBi	Sí	Sí	Recibido y confirmado
D-002	BASE → MOBi	Sí	No	Recibido, sin ACK
D-003	BASE → MOBi	No observado	No	No confirmado; recepción no observada

La frase no observado es más precisa que no llegó cuando la evidencia disponible no permite afirmarlo con certeza absoluta.

9. Qué hacer en el uso familiar

Para comunicación entre BASE y MOBi:

• numera mensajes importantes;
• pide una respuesta humana breve;
• evita enviar muchos mensajes repetidos de inmediato;
• mantén la antena vertical y alejada del cuerpo o metal cuando sea posible;
• cambia de posición si no recibes respuesta;
• prueba mensajes directos y el canal familiar;
• acuerda de antemano qué significa OK, AYUDA, ESPERA o CAMBIO DE PUNTO;
• no dependas de Meshtastic como único medio para solicitar servicios de emergencia.

Un protocolo familiar debe asumir que puede existir retraso, comunicación en una sola dirección o ausencia de confirmación.

10. Cómo registrar resultados correctamente

En una prueba de alcance, separa al menos estas métricas:

• Intentos de transmisión: mensajes que el emisor trató de enviar.
• Mensajes observados en el receptor: evidencia directa de entrega.
• Mensajes con ACK en el emisor: confirmaciones observadas.
• Mensajes recibidos sin ACK: entregas que el emisor no pudo confirmar.
• Mensajes no observados: sin evidencia en el registro receptor consultado.
• Dirección del enlace: BASE → MOBi o MOBi → BASE.

No calcules la tasa de entrega usando únicamente los iconos del emisor. Eso mezcla dos preguntas distintas:

1. ¿Llegó el mensaje?
2. ¿Regresó la confirmación?

1Intento localLa app entregó el mensaje al nodo

2TransmisiónEl nodo intentó usar LoRa

3Recepción observadaEl destino registra el mensaje

4ACK recibidoLa confirmación regresó al emisor

5Respuesta humanaLa persona contesta y confirma lectura

11. Diagnóstico rápido

Todos los mensajes muestran ! y ninguno aparece en el receptor

Revisa primero región, preset, frecuencia, canal, clave y distancia. Puede no existir un enlace útil.

Los mensajes aparecen en el receptor, pero frecuentemente muestran !

Investiga el trayecto de regreso: ubicación del receptor, antena, potencia disponible, obstáculos, congestión y posibles relés.

Una dirección funciona mejor que la otra

Documenta el enlace como asimétrico. Intercambia físicamente los equipos para separar el efecto del lugar del efecto del hardware.

Los mensajes de canal funcionan, pero los directos no se confirman

Verifica que la lista de nodos esté actualizada, que el destino seleccionado sea el correcto y que exista un trayecto de regreso.

El estado cambia entre pruebas idénticas

Repite suficientes muestras. LoRa comparte el medio y el entorno de radio cambia; una sola transmisión no representa la confiabilidad del enlace.

Resumen

• ACK significa confirmación, no lectura humana.
• El ACK es tráfico adicional que debe regresar al emisor.
• El signo ! indica falta de la confirmación esperada, no una prueba automática de pérdida.
• El receptor puede tener el mensaje aunque el emisor no reciba ACK.
• Los enlaces pueden ser asimétricos.
• Mensajes directos y mensajes de canal no ofrecen la misma evidencia.
• Para medir entrega, revisa el receptor.
• Para medir confirmación, revisa el emisor.
• En FS001 encontramos mensajes recibidos que aparecían sin ACK en el transmisor.
• Una prueba reproducible registra ambos extremos y ambas direcciones.

Continúa la ruta Aprende

• Anterior: Cómo viaja un mensaje en Meshtastic
• Siguiente: Cómo interpretar RSSI y SNR en Meshtastic — próximamente.
• Repasa canales: Canales, regiones y configuración básica
• Observa el hallazgo original: FS001: terreno, estructuras y orientación de antena
• Configura tu equipo: Cómo configurar tu primer nodo

Fuentes técnicas

• Algoritmo oficial: ACK, reintentos, managed flooding y next-hop
• Configuración oficial de LoRa
• Cifrado oficial y mensajes directos con PKC
• API de Python: paquetes, destinos y respuestas
• FS001 de MeshHubPR

---

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