This is an old revision of the document!
FAQ - Meshtastic en Navarra
1. ¿Qué es la red Meshtastic Navarra 868 MHz?
Es una iniciativa ciudadana que busca establecer una infraestructura de comunicación descentralizada, resiliente y autónoma utilizando la tecnología LoRa en la banda libre de 868 MHz (EU868).
2. ¿Cuál es el propósito principal de esta red?
Su objetivo es ser una herramienta de comunicación esencial en situaciones donde las redes convencionales (móviles, internet) fallan o se ven comprometidas (ej. apagones, desastres naturales). También es útil en zonas con cobertura deficiente, como las áreas montañosas.
3. ¿Qué tipo de información se transmite por esta red? Permite el intercambio de mensajes de texto y datos (telemetría, ubicación GPS), formando una malla que se adapta dinámicamente a las condiciones del entorno.
4. ¿Cuáles son las limitaciones regulatorias de la red?
La red debe operar dentro de las normativas de banda libre, respetando un límite de 500 mW de potencia y un Ciclo de Trabajo (Duty Cycle) limitado al 1% del tiempo, lo que requiere un uso responsable para evitar la saturación.
5. ¿Cómo se organizó la comunidad inicialmente?
El proyecto comenzó con la creación de grupos de coordinación (en mayo de 2025) con el fin de establecer la infraestructura y compartir conocimientos, siendo un esfuerzo totalmente comunitario.
6. ¿Cuáles fueron las primeras acciones técnicas clave?
Inicialmente, se realizaron mapas de cobertura y se identificaron ubicaciones ideales para el emplazamiento de los nodos fijos, teniendo en cuenta la orografía para maximizar el alcance.
7. ¿Qué tipo de recursos aportó la comunidad?
Los miembros aportaron la electrónica (nodos LoRa), recursos para crear las carcasas protectoras (impresión 3D) y equipos de medición especializados (Nano VNA o Tiny SA Ultra) para optimizar las antenas.
8. ¿Cómo progresó la instalación de nodos? Se pasó de la planificación a la operación con el despliegue de los primeros nodos fijos de infraestructura en ubicaciones estratégicas (ej. zonas altas de Pamplona/Comarca). También se definieron planes de expansión hacia el sur de la región (ej. Tudela, Arguedas).
9. ¿Qué capacidad de alcance inicial se demostró? Bold Text
El proyecto demostró una capacidad excepcional al registrar enlaces de hasta 28.3 km entre nodos fijos, confirmando que la red, bien configurada, puede superar los desafíos del terreno.
10. ¿Se ha planificado el uso de la red en escenarios de desastre?
Sí. La comunidad ha desarrollado un Protocolo de Emergencia (Borrador) para optimizar el uso de la red en situaciones críticas donde las comunicaciones tradicionales fallen.
11. ¿Qué implica la activación del “Modo de Emergencia”?
En caso de desastre, se activa un Canal de Emergencia específico. Se solicita a todos los usuarios que limiten drásticamente su actividad y mantengan un silencio operativo para priorizar únicamente las comunicaciones críticas.
12. ¿Cómo deben ser los mensajes durante una emergencia?
Los mensajes deben ser breves, claros y estructurados para facilitar su rápida comprensión. Se recomienda el uso de un formato específico, como [EMERGENCIA] Descripción - Ubicación, y códigos predefinidos (INCENDIO, HERIDO, etc.).
13. ¿Se colabora con autoridades en caso de emergencia?
Sí. El protocolo contempla la entrega inmediata de nodos Meshtastic a autoridades competentes (SOS Navarra, Bomberos, Protección Civil) en el momento de la emergencia, junto con un manual de uso rápido y el mapa de cobertura.
14. ¿Por qué se propone entregar los nodos durante la emergencia? Para garantizar que el personal receptor esté consciente de la situación, asegurar el uso activo e inmediato del dispositivo y facilitar una capacitación rápida y contextualizada que aumente la probabilidad de éxito.
15.¿Qué roles de nodo se recomiendan para la gran mayoría de usuarios?
Los roles CLIENT o CLIENT_MUTE son los únicos recomendados, ya que contribuyen a la estabilidad de la red utilizando retrasos automáticos en la retransmisión.
16.¿Cuándo debo configurar mi nodo como CLIENT?
El rol CLIENT es ideal para nodos de infraestructura fijos (en techos, torres o azoteas altas) o en zonas con buena visibilidad, ya que retransmite mensajes de forma inteligente, ampliando la cobertura de manera efectiva. Importante, en la comarca de Pamplona NO se necesitan mas Clientes repitiendo. Configure por favor sus nodos en client_mute en
17.¿Cuándo debo usar CLIENT_MUTE?
El rol CLIENT_MUTE es perfecto para dispositivos en zonas con cobertura redundante o para dispositivos móviles que no están en puntos altos. Este rol envía y recibe mensajes, pero no retransmite los de otros, lo que reduce la congestión innecesaria y el consumo.
18.¿Qué roles deben evitarse?
Se debe evitar el uso de ROUTER y ROUTER_LATE. Los Routers retransmiten paquetes constantemente sin control inteligente y, además retransmiten cualquier paquete sin importar su origen, lo que provoca alta congestión, colisiones y una pérdida de rendimiento global.
19.¿Dónde se deben instalar los nuevos nodos de infraestructura?
Los nuevos nodos (rol CLIENT) deben colocarse en zonas SIN cobertura o en los extremos de la malla para ampliar el alcance. No se deben añadir nodos CLIENT donde ya hay buena cobertura, ya que solo añadirían ruido y saturación.2. Límite de Saltos (Hop Limit) y Gestión de la Saturación#PreguntaDirectrices de la Comunidad sobre el Tráfico
20.¿Cuál es el límite de saltos (Hop Limit) máximo recomendado?
Se debe mantener en 3 o 4 saltos como máximo. Evitar valores superiores (5, 6 o 7) es fundamental, ya que aumentan drásticamente la congestión del canal y el tiempo de ocupación.
21.¿Por qué es vital limitar los saltos?
Cada salto ocupa más tiempo de transmisión, aumenta las interferencias y puede llevar a la red a un estado de saturación donde un solo mensaje o traceroute podría ocupar la red por 30 a 65 segundos.
22.¿Cuántos saltos son ideales según la geografía de la zona?
Centro de Malla o Zona Urbana: 2–3 saltos. Zona Intermedia o Rural: 3–4 saltos. Extremo o Enlace de Zonas: 4–5 saltos (máximo).
23.¿Cuál es el problema de saturación más grave que se ha observado?
Se ha observado que paquetes innecesarios pueden rebotar multiples veces, lo que resulta en latencias de 74 segundos en el traceroute, bloqueando la red e impidiendo la llegada de mensajes críticos.
24.¿Cómo se propone gestionar la saturación de manera inteligente? Se busca implementar, a nivel de firmware, una reducción automática de saltos. Esto significa no limitar los saltos al máximo, sino que, ante la detección de alta saturación del canal, los nodos puedan “comerse más de un salto” en una retransmisión para optimizar el rendimiento solo cuando sea necesario.
25.¿Qué debe priorizar la red: alcance máximo o estabilidad?
La prioridad es la estabilidad y la fluidez sobre la distancia. Una buena red no es la que llega más lejos (ej. Huesca), sino la que utiliza los saltos justos para ser rápida, estable y útil en momentos de necesidad.
26. ¿Qué consejos de “higiene de red” deben seguir los usuarios?
Evitar el tráfico innecesario (balizas, telemetría constante o pruebas excesivas) y mantener los mensajes cortos (preferiblemente bajo 160 caracteres). Esto reduce el “ruido” y asegura que el tiempo de transmisión sea mínimo.
27. ¿Cómo influye la calidad de la antena en la eficiencia de la red? Una antena mal ajustada desperdicia potencia de transmisión. Se recomienda utilizar herramientas como el Nano VNA o el Tiny SA Ultra para medir y sintonizar la antena a la frecuencia de 868 MHz, garantizando la máxima eficiencia dentro del límite de 500 mW ERP (27dBm).
28. ¿Se deben modificar ajustes desconocidos?
No. Si no se entiende el efecto de un campo o ajuste, se debe dejar en su valor por defecto para evitar efectos adversos y la inestabilidad de la red.
29. ¿Cuándo se debe activar la telemetría (datos GPS o de carga)?
Solo cuando sea estrictamente necesaria y justificada (ej. en un cambio de tiempo o para una medición puntual). Activar la telemetría constantemente genera ruido que puede retrasar o bloquear mensajes críticos.
30.¿Cuál es el propósito del Protocolo de Emergencia?
Optimizar el uso de la red Meshtastic en situaciones críticas (apagones, desastres) para garantizar que, a pesar de las limitaciones inherentes de la red (ej. bajo Duty Cycle), se maximice la eficiencia y la entrega de mensajes vitales.
31.¿Cuál es la frecuencia principal utilizada por la red en la región?
La frecuencia es 869.525 MHz.
32.¿Cuál es el límite legal de potencia para esta frecuencia?
El límite de potencia legal es de 500 mW ERP (Potencia Radiada Efectiva), o, lo que es lo mismo, 27 dBm.
33.¿Qué pasos activan el “Modo de Emergencia”? Se activa ante una emergencia que compromete las comunicaciones tradicionales. El primer paso es activar el Canal de Emergencia en la red Meshtastic y solicitar a todos los usuarios que limiten su actividad solo a ese canal.
34.¿Qué es el “Silencio Operativo” y por qué es fundamental?
Es una fase crítica en la que se insta a todos los usuarios a abstenerse de enviar mensajes no esenciales. El objetivo es evitar la congestión y la pérdida de mensajes, priorizando únicamente las comunicaciones críticas relacionadas con la emergencia en curso.2. Formato de Mensajes y Coordinación de la Información#PreguntaBuenas Prácticas para la Comunicación Crítica
35.¿Cómo deben estructurarse los mensajes durante una emergencia? Los mensajes deben ser breves, claros y estructurados para su rápida comprensión. El formato recomendado es: [EMERGENCIA] Descripción - Ubicación.
36.¿Se utilizan códigos o abreviaturas?
Se recomienda el uso de códigos predefinidos para tipos comunes de emergencias (e.g., INCENDIO, HERIDO, INUNDACIÓN) para facilitar la velocidad y la estandarización de la información.
37.¿Por qué es crucial mantener los mensajes cortos? Los mensajes deben ser inferiores a 160 caracteres (idealmente). En una emergencia, los mensajes largos consumen más tiempo de transmisión y ocupan el canal, lo que podría bloquear la red para otros mensajes de vida o muerte.
38.¿Cómo se relaciona la limitación de saltos con la emergencia?
Para garantizar la máxima fluidez, los usuarios deben mantener un límite de 3-4 saltos. Un número alto de saltos podría ocupar la red por 30 a 65 segundos por cada paquete enviado (telemetría, traceroute, mensaje), agotando el canal en momentos críticos y no permitiendo que el resto de sus usuarios puedan realizar envios.
39. ¿Qué papel juega la comunidad con las autoridades en una emergencia?
La comunidad se compromete a la entrega inmediata de nodos Meshtastic a las autoridades competentes (Policía Municipal, SOS Navarra, Bomberos, Protección Civil) en el momento de la emergencia.
40. ¿Qué se entrega junto con cada nodo a las autoridades?
Cada nodo se entrega con un Manual de uso rápido con instrucciones concisas, el Mapa de cobertura real de la red en Navarra, y el Protocolo de actuación específico para el uso del canal de emergencia.
41. ¿Por qué se propone la entrega solo en el momento de la emergencia? Esta estrategia busca evitar que los nodos sean “almacenados y olvidados”. Asegura que el personal receptor esté consciente de la situación y facilita una capacitación rápida y contextualizada, garantizando el uso activo y efectivo del dispositivo.
42. ¿Se deben enviar datos de telemetría (GPS, carga) en modo de emergencia?
No. Los datos de telemetría deben desactivarse si no son estrictamente necesarios, ya que generan “ruido” constante y contribuyen a la saturación, lo que va en contra del principio de Silencio Operativo.
43. ¿Qué es la conclusión final sobre la red Meshtastic en Navarra?
La red es una herramienta valiosa para la comunicación en situaciones de fallo de infraestructura. Su eficacia y supervivencia dependen de un uso responsable, coordinado y el adherirse estrictamente al Protocolo de Emergencia por parte de todos los participantes.