Este documento recopila las preguntas frecuentes (FAQ) sobre la red Meshtastic Navarra, una iniciativa comunitaria que promueve una red de comunicación alternativa basada en tecnología LoRa en la banda libre de 868 MHz.
FAQ - Meshtastic en Navarra
Bloque 1: Introducción y Conceptos Básicos
Lo fundamental para entender qué es el proyecto, su alcance y el marco legal.
1.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).
1.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.
1.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.
1.4. ¿Cuál es la frecuencia principal utilizada por la red en la región?
La frecuencia es 869.525 MHz.
1.5. ¿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.
1.6. ¿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.
1.7. ¿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.
1.8. ¿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.
1.9. ¿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 y equipos.
1.10. ¿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).
1.11. ¿Qué capacidad de alcance inicial se demostró?
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.
1.12. ¿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.
Bloque 2: Hardware y Guía de Compra
Qué comprar, qué evitar y qué dispositivo elegir según el uso.
2.1. ¿Por qué es crítico comprobar la frecuencia antes de comprar un dispositivo en AliExpress o tiendas internacionales?
Es el error más común. Muchos dispositivos vienen configurados por defecto en 915 MHz (frecuencia para EE. UU.) o 433 MHz. Para la red de Navarra (y Europa en general), es imprescindible comprar la versión de 868 MHz. Si compras un equipo de 915 MHz, no podrá comunicarse con el resto de la malla y su uso puede ser ilegal en esta región.
2.2. ¿Por qué se desaconseja comprar “lo primero que aparece” en las búsquedas de AliExpress?
Los vendedores de AliExpress a menudo mezclan versiones antiguas con nuevas, o venden placas con chips de radio falsos o de frecuencias incorrectas (433/915). Además, los precios fluctúan mucho; un equipo que hoy vale 40€, mañana puede estar a 30€ en otro enlace. Se recomienda encarecidamente pedir el enlace verificado en el grupo antes de pagar.
2.3. ¿Qué diferencia principal existe entre usar placas con chip ESP32 y placas con chip nRF52840 para montar un nodo?
La diferencia fundamental radica en el consumo energético. Las placas con ESP32 (como Heltec V3 o LilyGO T-Beam) son más potentes y tienen WiFi, pero consumen entre 80 y 100 mA en reposo, lo que las hace menos ideales para nodos solares autónomos, siendo mejores para uso en casa o vehículo. Por el contrario, el chip nRF52840 (usado en los kits Xiao o T1000-E) tiene un consumo mucho menor, rondando los 10-12 mA en reposo, lo que permite una autonomía de semanas con baterías estándar o el uso de paneles solares más pequeños para nodos desatendidos.
2.4. ¿Qué dispositivo se recomienda para usuarios que buscan un “tracker” o baliza de seguimiento sin complicaciones?
Para usuarios que no quieren montar electrónica (“soldar cables”), se recomienda el Sensecap T1000-E. Es un dispositivo “llave en mano” (listo para usar), con batería integrada, GPS y sensores, del tamaño de una tarjeta de crédito. Utiliza el chip nRF52840, lo que le da una excelente autonomía, ideal para senderistas o llevar en la mochila.
2.5. ¿Qué ventajas ofrece el nuevo Heltec T114 frente al clásico Heltec V3?
El Heltec T114 es la evolución recomendada. A diferencia del V3 (que usa chip ESP32 y consume mucha batería), el T114 monta un chip nRF52840. Esto significa que tiene un consumo energético mucho menor, lo que permite que la batería dure mucho más tiempo, haciéndolo apto para nodos portátiles o solares pequeños, manteniendo la pantalla y el GPS.
2.6. Si ya tengo un Heltec V3, ¿para qué uso es más adecuado?
Debido a su alto consumo de batería, el Heltec V3 no es ideal como nodo solar o portátil de larga duración. Sin embargo, es excelente como nodo base en casa (conectado siempre a la corriente) o en un vehículo (con alimentación USB constante), donde el consumo no es un problema y su potencia de procesador es una ventaja, configurado en CLIENT_MUTE.
2.7. ¿Qué son las “Faketec” que se mencionan en el grupo?
Son nodos diseñados y ensamblados de forma personalizada por miembros de la comunidad. Surgen para cubrir necesidades que los dispositivos comerciales no cubren bien (como la gestión eficiente de energía solar o configuraciones específicas de hardware). Las versiones (V4, V5) van evolucionando con mejoras como mejores gestores de batería (BMS) o resistencias para lectura de voltaje.
2.8. ¿Qué problema suele haber con las antenas que vienen incluidas en los kits baratos?
La mayoría de las antenas “de porra” pequeñas que vienen de regalo con los nodos tienen un rendimiento muy pobre o no están bien ajustadas a 868 MHz (a veces son antenas genéricas de Wi-Fi). Para asegurar un buen alcance, se recomienda sustituirlas por antenas probadas o fabricadas por la comunidad, una recomendación adicional es disponer de un NANO VNA-H4, dispositivo que sirve para dejar las antenas calibradas en su punto óptimo.
Bloque 3: Taller: Montaje, Antenas y Energía
Detalles técnicos avanzados para mejorar el rendimiento físico del nodo.
3.1. ¿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 para medir y sintonizar la antena a la frecuencia de 869.525 MHz, garantizando la máxima eficiencia dentro del límite de 500 mW ERP (27dBm).
3.2. ¿Por qué se recomienda el uso de antenas tipo “J-Pole” en ubicaciones altas o expuestas a tormentas?
La antena J-Pole, que puede ser auto-construida con varillas de aluminio o cobre, ofrece un rendimiento superior a las antenas comerciales básicas (“de porra”) y tiene la ventaja eléctrica de estar cortocircuitada en corriente continua (DC-grounded). Esto ayuda a proteger el nodo de la electricidad estática generada por las tormentas, que ha llegado a dañar o dejar “sordos” a nodos con otras antenas en nodos ubicados en cumbres.
3.3. ¿Qué importancia tiene el uso de filtros (SAW o de cavidades) en nodos ubicados en repetidores o cumbres?
En ubicaciones compartidas con emisoras de FM comerciales, TV o telefonía (como San Cristóbal o Zaldiaran), la fuerte radiofrecuencia (RF) del entorno puede saturar y dejar “sordo” al nodo LoRa, impidiendo que reciba mensajes aunque pueda emitir. La instalación de un filtro pasabanda (como un filtro SAW o, mejor aún, de cavidades, cada situación requiere un filtro diferente) entre la antena y el nodo es crucial para limpiar la señal y permitir que el dispositivo escuche correctamente.
3.4. ¿Qué es el fenómeno de “Brownout” que puede afectar a los nodos solares?
Es un fallo crítico donde el microcontrolador del nodo se bloquea cuando el voltaje de la batería baja de cierto umbral y luego intenta recuperarse con la entrada del sol, pero no logra arrancar correctamente, quedando en un estado “zombie” o de reinicio constante. Esto ocurre a menudo por la interacción entre el regulador MPPT, la batería baja y el consumo de arranque del nodo. Para solucionarlo en nodos remotos, se han implementado sistemas de “auto-reset” externos (watchdogs) y chips específicos de supervisión de voltaje.
Bloque 4: Configuración y Software
Ajustes necesarios en la aplicación y el firmware.
4.1. ¿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.
4.2. ¿Qué significa que un nodo aparezca como “!ffffffff” en un traceroute?
Este identificador hexadecimal indica que el nodo es “desconocido” para quien realiza el rastreo. Suele ocurrir si el nodo remoto no tiene la clave de cifrado correcta del canal (o se ha reseteado y generado claves nuevas), si tiene un firmware muy antiguo incompatible, o si hay problemas de configuración que impiden que se identifique correctamente ante la solicitud.
4.3. ¿Mi nodo es un ESP32, puedo conectarme a el por bluetooth y wifi?
Si, pero no simultaneamente. Cuando se establece en sus ajustes que se conecte a una red inalámbrica, se desactiva el acceso por bluetooth.
4.4. ¡Ayuda!. Mi nodo se desconecta constantemente de mi smartphone
Has de saber que Bluetooth tiene un rango limitado de alcance, también es popular que la antena integrada de estos equipos tiene un alcance bastante limitado. Prueba a no separarte demasiado de él ó bien, si es un ESP32 en tu casa, conectalo a la red inalámbrica de tu proveedor de acceso a internet, recuerda que ésta misma también está sujeta a que llegue correctamente a tu nodo.
Bloque 5: Funcionamiento de la Red y Buenas Prácticas
Normas de convivencia para mantener la malla sana y evitar saturaciones.
5.1. ¿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.
5.2. ¿Qué rol deben tener configurado los nodos personales o secundarios para no saturar la red?
Se recomienda encarecidamente configurar los nodos que están a pie de calle, en vehículos o ventanas (nodos secundarios) en el rol CLIENT_MUTE. Esto permite al usuario enviar y recibir mensajes, pero evita que su dispositivo retransmita automáticamente los paquetes de otros, reduciendo el ruido innecesario y la congestión de la malla. Solo los nodos en ubicaciones estratégicas altas deberían actuar como repetidores activos.
5.3. ¿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.
5.4. ¿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.
5.5. ¿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.
5.6. ¿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.
5.7. ¿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.
5.8. ¿Cuál es el límite de saltos (Hop Limit) recomendado para la red de Navarra?
Para mantener la red fluida y evitar latencias excesivas (que pueden bloquear la red durante más de 30 segundos), se recomienda configurar un límite de 3 saltos para toda Navarra. Un límite de 4 o 5 saltos debe reservarse solo para nodos en extremos de la malla o enlaces entre zonas lejanas, ejemplo: Quieres hablar con otra provincia que sabes que llega la malla, estableces TEMPORALMENTE mas saltos de lo habitual, luego, vuelta a 3 maximo. Configurar 7 saltos por defecto es contraproducente y satura el canal.
5.9. ¿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.
5.10. ¿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).
5.11. ¿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.
5.12. ¿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.
5.13. ¿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.
5.14. ¿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.
5.15. ¿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.
Bloque 6: Protocolo de Emergencias
Instrucciones críticas para situaciones de apagón o desastre.
6.1. ¿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.
6.2. ¿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.
6.3. ¿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.
6.4. ¿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.
6.5. ¿Qué es el “Silencio Operativo” y cuándo debe aplicarse?
El Silencio Operativo es una medida del protocolo de emergencia que insta a todos los usuarios a abstenerse de enviar mensajes no esenciales (charlas triviales, pruebas, saludos) durante una crisis activa. El objetivo es liberar el ancho de banda de la red para garantizar que las comunicaciones críticas y de auxilio no se pierdan por congestión.
6.6. ¿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.
6.7. ¿Cómo deben estructurarse los mensajes en caso de una emergencia real?
Para facilitar la comprensión rápida y la respuesta, los mensajes deben ser breves y seguir un formato estructurado que incluya una etiqueta de emergencia, la naturaleza del incidente y la ubicación exacta. Ejemplo: [EMERGENCIA] Persona atrapada en ascensor - C/ Guelbenzu 2.
6.8. ¿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.).
6.9. ¿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.
6.10. ¿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.
6.11. ¿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.
6.12. ¿Por qué se desaconseja el uso de MQTT en situaciones de emergencia real o “Off-Grid”?
Aunque MQTT permite conectar nodos a través de internet, en una situación de emergencia real (como un gran apagón), es probable que la infraestructura de internet y telefonía caiga. La red Meshtastic debe ser capaz de funcionar de manera autónoma vía radio (RF). Además, el tráfico excesivo proveniente de internet (uplink/downlink) puede saturar la malla local de radio inútilmente si no se gestiona bien.
6.13. ¿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.
6.14. ¿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.
6.15. ¿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.
6.16. ¿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.
6.17. ¿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.
6.18. ¿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.