La comunidad Meshtastic en su afán legítimo de proteger su red y evitar usos abusivos limita el número de hops (saltos) entre nodos de la misma red a 7. En general y en una red urbana en la que se puede instalar un repetidor en un lugar alto que da servicio a los usuarios, eso es más que suficiente, incluso con los 3 saltos que de serie se recomiendan. Sin embargo en una cavidad no hay un punto alto que dé señal a la zona de trabajo, hay que progresar por ella instalando una red lineal que pronto supera los 7 saltos, por muy eficiente que seas en su topología y asignación de roles.
Como se vio en el artículo https://espeleosocorro.es/red-meshocan-de-comunicaciones-inalambricas-en-cueva/ Cuando envías un mensaje desde la aplicación Meshtastic, este se retransmite a la radio mediante Bluetooth, Wi-Fi/Ethernet o conexión serie. La radio emite el mensaje y, si no recibe confirmación de ningún otro dispositivo tras un tiempo determinado, lo retransmitirá hasta tres veces si no contacta con otro nodo antes.
Puesto que cada nodo recibe y rebota el mensaje, si no se le pone ningún tipo de restricción este mensaje podría saturar la red al entrar en bucles infinitos
Por este motivo cuando una radio receptora captura un paquete, comprueba si ya ha escuchado ese mensaje. Si lo ha escuchado, lo ignora. Si no lo ha escuchado, lo retransmite.
Por cada mensaje que una radio retransmite, reduce en uno el «límite de saltos». Cuando una radio recibe un paquete con un límite de saltos de cero, no retransmite el mensaje.
Dados los diversos casos de uso y escenarios que admite Meshtastic, la mayor parte del protocolo se basa en la inundación (cada paquete entrante se envía a través de cada enlace saliente, excepto el que llegó), lo que significa que cada nodo retransmite un paquete que recibe hasta alcanzar un límite de saltos determinado. Sin embargo, una diferencia importante en Meshtastic es que, antes de retransmitir, un nodo escucha durante un breve periodo para comprobar si otro nodo ya ha retransmitido el paquete. En caso afirmativo, no lo retransmitirá. Por lo tanto, «inundación controlada» es un término más adecuado.
El principio es el siguiente: si un nodo de la malla recibe un paquete con la variable HopLimit distinto de cero, lo decrementará e intentará retransmitirlo en nombre del nodo emisor original, los nodos que lo reciban actuarán de igual manera mientras HopLimit sea distinto de cero.
Esta limitación en el número de saltos (máximo 7) se puede mejorar con la topología de la malla diseñada sin bucles, trabajando con la red «Mosquito», una asignación de roles a las radios correcta, o programando los nodos en Zero Hop Repeater. Además, la comunidad científica que da soporte a esta comunidad está trabajando para poder comunicar en línea y P2P sin esta limitación. En esta línea P2P, la comunidad Meshtastic ha sufrido una “deserción” de parte de programadores “disidentes” y como consecuencia de ello ha nacido Meshcore: MeshCore al igual que Meshtastic es un sistema / biblioteca de código abierto (escrito en C++) diseñado para crear redes de radio de malla descentralizadas basadas en tecnología LoRa
Hardware
MeshCore está disponible en una variedad de dispositivos LoRa de 433MHz, 868MHz y 915MHz. Y agregan más dispositivos regularmente.
Firmware
MeshCore tiene cuatro tipos de firmware que no están disponibles en otros sistemas LoRa. A diferencia de Meshtastic, cada rol tiene un firmware específicio que ha de flashearse cada vez que queremos cambiar el rol a la radio:
Firmware de radio complementaria
Las radios acompañantes (jefes de equipo, coordinador, sanitario) son para conectarse con la aplicación de Android o con la aplicación web como cliente de mensajería. Hay dos versiones de firmware de radio complementarias diferentes:
- Complemento Bluetooth. El firmware de BLE Companion se ejecuta en un dispositivo LoRa compatible y se conecta a un dispositivo inteligente (teléfono móvil) que ejecuta el cliente Android o iOS MeshCore a través de BLE (Bluetooth Low Energy)
- Complemento USB El firmware USB Serial Companion se ejecuta en un dispositivo LoRa compatible y se conecta a un dispositivo inteligente o a una computadora a través de USB Serial ejecutando el cliente web MeshCore
Repetidor
Los repetidores se utilizan para ampliar el alcance de una red MeshCore. El firmware repetidor se ejecuta en los mismos dispositivos que ejecutan el firmware del cliente. El trabajo de un repetidor es reenviar paquetes de MeshCore al dispositivo de destino. No reenvía ni retransmite todos los paquetes que recibe, a diferencia de otros sistemas de malla LoRa.
Servidor de sala (room server)
Un servidor de sala es un simple servidor BBS (Bulletin Board System) para compartir publicaciones. Los servidores de sala almacenan el historial de mensajes en ellos y envían los mensajes almacenados a los usuarios. Los servidores de sala permiten a los usuarios de roaming volver más tarde y recuperar el historial de mensajes. Con Meshtastic, los mensajes se reciben cuando se envían o no se reciben y se pierden si el usuario del canal está fuera de rango. Los servidores de sala son diferentes. Si en un momento dado un jefe de equipo o el vehículo lanzadera se queda temporalmente fuera de cobertura, al llegar a un servidor de sala, se pondrá al día con los mensajes que no recibió. Cuando un cliente inicia sesión en un servidor de sala, el cliente recibirá los 32 mensajes no vistos previamente.
Aunque el servidor de sala también puede repetir con el comando de línea de comandos set repeat on, no se recomienda. Un servidor de sala con repetición establecido en on carece del conjunto completo de funciones de repetición y administración remota que solo están disponibles en el firmware del repetidor.
La recomendación es ejecutar repetidores y servidores de sala en dispositivos separados para obtener la mejor experiencia.
Número de saltos:
En MeshCore no hay un límite fijo de “hops” (saltos) impuesto por el software.
El número máximo práctico depende de tres factores principales:
- Arquitectura de MeshCore
MeshCore implementa multi-hop routing sin un límite duro establecido. En teoría, pueden hacerse tantos saltos como la red necesite, siempre que cada nodo pueda recibir, procesar y reenviar el paquete. En teoría los saltos son ilimitados. En la práctica dependerá del rendimiento de la red.
A diferencia de Meshtastic, Meshcore envía un mensaje a través de la red en modo inundación, pero una vez que el mensaje llega al destinatario, este de forma automática envía de vuelta la ruta seguida al emisor, de tal forma que, a partir de ahí, si no hay cambios en la red (desaparición de nodos o pérdida de señal) los siguientes mensajes ya no inundan la red, si no que siguen esa ruta. En el caso de que la ruta se rompa (desaparición de algún nodo), vuelve a inundar la malla buscando una ruta nueva que será la que sucesivamente sigan los mensajes. Esta forma de proceder es más óptima, reduce el consumo de batería, tiempo de conexión, casi elimina por completo el ruido etc.
Permite en nuestro caso de redes lineales superar el límite de los 1+7+1 de forma directa, pudiendo llegar desde el PMA hasta el límite físico de la red con el uso de nodos LoRa.
- Limitaciones técnicas reales
En redes LoRa-mesh, el límite práctico viene por:
- Tiempo aire (airtime)
Cada salto retransmite el paquete usando LoRa, que es lento comparado con WiFi.
Más saltos = más airtime = más riesgo de colisiones y retrasos.
- Consumo y carga de nodos
Cada retransmisión consume energía y tiempo de procesador.
Si un paquete necesita demasiados saltos, algunos nodos pueden saturarse.
- Retardo acumulado
Cada salto añade latencia. Redes con más de ~10–15 saltos pueden volverse muy lentas, dependiendo de la configuración.
- Lo que se observa en la práctica
Según pruebas típicas en redes LoRa-mesh similares (y la arquitectura que MeshCore usa):
- 3–7 hops: Operación estable y rápida.
- 8–15 hops: Aumenta la latencia pero sigue siendo usable en la mayoría de casos.
- Más de 15 hops: Puede funcionar, pero no está garantizado; depende del tamaño del mensaje, congestión, potencia LoRa y densidad de nodos.
Para un ejemplo de red lineal de 50 nodos con MeshCore, partiendo de la realidad técnica (latencia y airtime en LoRa) y de las opciones de configuración reales del firmware, una cadena lineal pura de 50 hops punto a punto es poco práctica (muchísima latencia y riesgo de pérdida). Por eso proponemos una alternativa de segmentación/backbone para que la red funcione de forma fiable.
MeshCore permite multi-hop y el software no fuerza un límite rígido por diseño, pero el rendimiento real (airtime, colisiones, batería y latencia) degrada la comunicación con muchos saltos. Para 49 hops end-to-end (50 nodos lineales) tendremos latencias altas y fragilidad. Por este motivo No confiamos la red en 49 hops seguidos. Dividimos la línea en segmentos mantenemos el número de hops prácticos por segmento ≤ 10–12 para fiabilidad y cada 10 repetidores intercalamos un servidor de sala.
Diseño concreto para 50 nodos
Objetivo: que ningún paquete tenga que pasar más de ~10–12 hops hasta un backbone repetidor.
- Segmentación y repeaters backbone
-
- Dividimos los 50 nodos en 5 segmentos de ~10 nodos (Nodos 1–10, 11–20, …).
- En el punto 10, 20, 30, 40 y 50; colocamos un Repeater (nodo con el rol de repetidor de sala). Esos 5 repeaters forman el backbone.
Un backbone repetidor es:
La “columna vertebral” de la red: una cadena fija, estable, alimentada y optimizada de repetidores que transportan el tráfico principal interior ↔ exterior.
Es decir:
- Es la infraestructura central de la red.
- Está formada por repetidores fijos, bien colocados, bien alimentados, con buena antena y configuración optimizada.
- Su función es asegurar que los mensajes cruzan largas distancias dentro de la cavidad (muchos cientos de metros o kilómetros) sin depender de nodos móviles o nodos débiles.
- Es la parte de la red que nunca debe fallar, porque todo el tráfico pasa por ella.
- Permite que radios móviles (jefes de equipo, sanitarios) se conecten a cualquier punto usando solo unos pocos saltos, sin colapsar la red.
Colocar un servidor de sala (room server) cada 10 repetidores mejora la línea de 50 repetidores, y bastante. Un room server actúa como punto de agregación y puente local para un tramo de la red.
Beneficios concretos
- Menos retransmisiones innecesarias → menos colisiones y mejor relación entrega/paquete.
- Latencias menores para tráfico local (no tiene que recorrer 25–50 hops).
- Posibilidad de filtrar / priorizar tráfico.
- Despliegue remoto: actualizar firmware de nodos del tramo desde el server local.
Arquitectura recomendada para 50 nodos
Dividiremos la línea en 5 segmentos de 10 nodos:
Exterior en el PMA (PC/gateway) ←→ Segmento A (Nodos 1–10 + room Server A) ←→ Segmento B (11–20 + room Server B) ←→ … ←→ Segmento E (41–50 + room Server E)
En cada segmento, el room server estará físicamente junto a uno de los nodos (p. ej. el nodo 10, 20, 30, 40 y 50) y conecta
