Introducción:
En anteriores artículos hemos conocido la base tecnológica de las redes basadas en tecnología LoRa/Arduino/Meshtastic. Posteriormente hemos dado a conocer como configuramos nosotros los nodos. Ahora vamos a indicar como desplegamos la red y la usamos.
Al tratarse de una red lineal, la garantía de funcionamiento depende de que todos los nodos funcionen, si falla uno, se rompe la red (la línea de comunicación). Por este motivo es fundamental que la configuración de los nodos sea correcta y debemos verificarla antes de empezar a su instalación. Nosotros tenemos una lista de chequeo que nos permite comprobar esto previamente.
Esta lista posteriormente nos permitirá comprobar que se han retirado todos los nodos de la cavidad.
Despliegue de la red:
Diferenciamos tres arquitecturas de red:
- Red sencilla.
- Red doble
- Red avanzada.
Arquitectura sencilla:
Conexión desde boca de cueva al interior de ésta y viceversa. Sin trasladar información más allá.
Esta red comienza en la boca de la cueva o en sus proximidades. Desde un punto de conexión con telefonía móvil o emisora se coloca una carpa o un punto caliente y un nodo inicial. Este conecta con el de boca de cueva (puede ser el mismo) y a partir de aquí se empieza a disponer de tantos nodos como sea posible para llegar hasta el punto cero del accidente o lo mas cerca posible de él.
Arquitectura de doble red:
A partir de la arquitectura sencilla llevamos la señal hasta el Puesto de Mando Avanzado con un repetidor intermedio situado en un punto estratégico que comparta cuenca visual PMA/Boca de Cueva.
Una vez en el PMA un nodo recibe la señal y hace de puerta de entrada al ordenador del coordinador del rescate. De esta forma los mensajes van y vienen sin intermediarios.
Arquitectura avanzada:
Si tenemos conexión a internet, tanto en el PMA como en boca de cueva, y aquí un lugar cómodo para instalar una carpa, podemos obviar las conexiones exteriores y hacerlo a través de la red Mosquitto:
Tendido de la red sencilla:
A partir de la boca de la cueva o de sus proximidades colocamos un nodo y vamos entrando en la cavidad comprobando la señal de este nodo de tal forma que cuando perdamos su señal, retrocedemos un poco hasta recuperarla. En ese punto colocamos el siguiente nodo. Procediendo de este modo de forma continua vamos avanzando por el interior de la cavidad, bien hasta llegar al punto del accidente o hasta quedarnos sin nodos.
Para conocer donde nos quedamos sin señal del nodo anterior hay varias formas:
La más básica es utilizar nuestro nodo/radio y en la opción de red, ver la señal que nos llega del nodo anterior.
Si pulsamos en la parte inferior de nuestro teléfono móvil en el icono de malla se nos despliega el listado de nodos disponibles. En este ejemplo tenemos solo tres, el nodo que hemos llamado “coordinador20fc” que es el que porta el operador de malla y el “d244” que es el que hemos dejado en boca de cueva y sobre el que vamos a comprobar su alcance para instalar el siguiente puente. Además aparece otro llamando “sanitario796c” que no nos da señal en este momento, está fuera de alcance.
El móvil nos indica el SNR (relación señal/ruido) en este caso 5,75 dB y el RSSI -80 dBm (Indicador de Intensidad de Señal Recibida)
El RSSI y el SNR están relacionados, pero miden cosas distintas y se complementan:
RSSI (Received Signal Strength Indicator)
Mide la potencia total de la señal recibida, incluyendo:
- señal útil
- ruido
- interferencias
Se expresa en dBm (valores negativos).
Es un valor que muestra qué tan fuerte llega la señal de radio desde otro nodo.
Algunos puntos importantes:
- Se mide en dBm (decibelios respecto a un miliwatio).
- Los valores suelen ser negativos:
- -40 dBm = señal muy fuerte
- -80 dBm = señal moderada
- -100 dBm o menos = señal débil o casi inutilizable
- Un RSSI mejor (menos negativo) generalmente significa conexión más estable y menor pérdida de paquetes.
En resumen: RSSI te indica la calidad de la señal que recibe tu nodo Meshtastic desde otro.
SNR (Signal-to-Noise Ratio) Relación señal/ruido
Mide cuánta señal útil hay respecto al ruido.
Se expresa en dB (puede ser positivo o negativo).
- SNR alto (≥ 10 dB) → señal clara
- SNR cercano a 0 dB → señal difícil de decodificar
- SNR negativo (–10 dB, –20 dB) → LoRa aún puede decodificar, pero con limitaciones
LoRA puede trabajar incluso con SNR negativos gracias a su modulación de espectro expandido.
Relación entre RSSI y SNR
Aunque están relacionados, no dependen directamente uno del otro.
Puedes tener:
▶ Alta potencia (RSSI bueno) pero SNR malo
Ejemplo:
- RSSI: –60 dBm (fuerte)
- SNR: –10 dB (mucha interferencia)
Ocurre en ambientes ruidosos, donde llega una señal fuerte pero hay ruido o interferencia que la ensucia.
▶ RSSI malo pero SNR excelente
Ejemplo:
- RSSI: –110 dBm (débil)
- SNR: 9 dB (clara respecto al ruido)
Ocurre cuando la señal es muy débil, pero el entorno es silencioso.
Esto es típico en zonas rurales y permite que LoRa funcione sorprendentemente bien a largas distancias.
En Meshtastic para que un paquete sea decodificado correctamente, lo ideal es:
- RSSI: mejor que ~ –100 dBm
- SNR: mayor que ~ –5 dB (depende del SF)
Ambos juntos te dicen si tu enlace Meshtastic es bueno o no.
Ejemplo secuencial de instalación:
Aquí os enseñamos una secuencia de lecturas tomadas conforme avanzamos por la cueva. La cuarta lectura ya puede no ser operativa (este criterio es personal), por lo que retornaríamos en busca de una RSSI aceptable y colocar otro nodo sobre el que volver a escanear su señal y así sucesivamente hasta completar la red.
Los nodos leen la señal cada cierto periodo de tiempo (30 segundos aunque se puede configurar para 15 segundos, pero consume rango y batería)
Otra forma que permite mayor optimización en la colocación de los nodos y la rapidez es utilizar la radio Lyligo T-deck de forma visual:
Esta radio tiene dos utilidades muy interesantes, una es su detector Mesh que permite encontrar los nodos que están dentro del rango de escucha.
Y el otro es el escáner de señal, que permite ir viendo que parámetros SNR/RSII vamos obteniendo conforme avanzamos por la cueva:
Su uso es sencillo e intuitivo a partir de su pantalla táctil. Veamos su uso.
Primero, tras encender la radio pulsamos en el logo de configuración:
Deslizamos la pantalla a la ventana de “herramientas”
Ahora seleccionamos Detector Mesh para ver que nodos hay al alcance.
A continuación, volvemos a herramientas y seleccionamos la opción escáner de señal. Nos pedirá que seleccionemos el nodo sobre el que deseamos medir la señal.
Lo elegimos y vamos midiendo la señal y avanzando por la cueva hasta que los rendimientos no sean aceptables, momento en el que colocaremos otro nodo y repetimos las tareas. Esto para tantos nodos como sea necesario
Esta radio (y cualquiera que tenga salida de sonido) permite hacer esto por medio de señales acústicas, cada 15 segundos (este intervalo es programable, pero hay que buscar un equilibrio entre señales y duración de la batería), si hay señal da varios pitidos, y deja de pitar cuando ya no hay alcance.
Para hacerlo de esta forma hay que configurar el “Range Test” del nodo de origen y del nodo móvil de control (en este caso nuestro Lyligo T-deck)
Cómo funciona el módulo Range Test cuando tienes varios nodos:
El módulo Range Test tiene dos modos posibles en cada nodo:
- Sender (emisor) → envía paquetes periódicos
- Responder → responde automáticamente cuando recibe un paquete de test
- Ambos → lo hace todo (pero en la práctica no se recomienda en varios nodos simultáneamente)
En nuestro caso concreto:
Tenemos una red fija de nodos Heltec V3 y te mueves con un nodo móvil que también tiene activado el Range Test. Con esta configuración recibirás notificaciones de cobertura siempre que el nodo móvil RECIBA los paquetes de prueba que envían los nodos fijos.
Cada vez que reciba un paquete, tu nodo móvil puede sonar. Esto es equivalente a “estás en cobertura”. Y puedes continuar progresando por la cavidad hasta perder la “cobertura” y en ese momento colocar otro nodo.
Pero hay un detalle importante: No es recomendable que todos los nodos tengan activado “Range Test Sender” (modo emisor) al mismo tiempo.
- saturas el aire LoRa
- la red se vuelve más lenta
- se generan colisiones
- te pueden llegar paquetes mezclados de muchos nodos → resultados confusos
Configuración recomendada:
Los nodos fijos:
Los configurados solo como receptores o como responders, NO como senders continuos.
O bien uno solo como sender (el de boca de cueva o el del PMA dependiendo de la arquitectura de la red), el resto responders.
Ejemplo:
- Nodo Fijo 1 → Sender (envía el paquete cada 15 s)
- Nodos Fijos 2,3,4… → Responder
- Nodo Móvil → Responder + alerta acústica o simplemente receptor.
Tu nodo móvil: en vez de que también sea sender, ponlo en modo responder (o solo receptor) + alertas acústicas así recibirás sonidos solo cuando un nodo de la red te escuche o tú escuches a ellos.
Resultado final mientras te mueves:
- Si el nodo móvil recibe un paquete de Range Test desde cualquier nodo fijo ✔️ Eso significa que estás en cobertura
✔️ El buzzer puede sonar (si lo configuraste)
- Si no recibes nada por unos ciclos (15 s) → ❌ Estás saliendo de cobertura
- CONFIGURACIÓN DE LOS NODOS FIJOS (Estáticos)
1.1 Uno solo debe ser el SENDER
Elige un único nodo fijo como transmisor principal.
Nodo Fijo A (boca de cueva o PMA)
Activar Range Test Sender = 1 (activo)
Intervalo recomendado: 15 s (o 10 s si realmente lo necesitas)
Responder = off (no hace falta si es el sender)
Este nodo será el que “marque” el ritmo de los beacons.
1.2 El resto de nodos fijos → RESPONDER (a lo largo de la cueva)
Ejemplo: Nodo Fijo B, C, D…
Configurar:
Sender = 0
Responder = 1
Esto hace que cuando reciban un paquete del nodo A, respondan automáticamente. Así amplían el alcance efectivo de la prueba sin congestionar la red.
- CONFIGURACIÓN DEL NODO MÓVIL
Este será el nodo que llevas contigo mientras te desplazas.
2.1 Desactivar Sender
Para evitar congestión:
Sender = 0
2.2 Mantenerlo como receptor (o Responder si deseas)
Si quieres que responda cuando lo escuchen los nodos:
Responder = 1
Si solo quieres escuchar:
Responder = 0
- ALERTAS ACÚSTICAS (BUZZER) EN EL NODO MÓVIL
Requisitos:
Módulo: External Notification
external_notification.use_pwm = true
Cada vez que el nodo móvil reciba un paquete del Range Test, sonará el buzzer.
Esto te indica “estoy en cobertura de al menos un nodo de la red”.
- PRUEBA DE FUNCIONAMIENTO
Enciende el nodo fijo A (sender).
Enciende el nodo móvil.
Muévete alejándote.
Cada vez que el nodo móvil reciba un paquete → Beep = estás en cobertura.
Al perder la señal durante 1–3 intervalos → Silencio = estás fuera del rango de ese nodo o de la red.
Tendido de la doble red:
Con la red sencilla tendida, tal y como hemos indicado anteriormente, podemos llevar la señal del nodo de boca de cueva al Puesto de Mando Avanzado.
Si hay línea visual y el PMA y la boca de cueva están dentro del rango de distancias de las antenas, esto es tan sencillo como poner un nodo en el PMA que se conecte con la boca de cueva. Pero en nuestro caso difícilmente va a haber línea visual entre ambos puntos, por lo que será preciso colocar al menos un nodo repetidor en un punto que comparta cuenca visual con boca de cueva por un lado y Puesto de Mando Avanzado por otro.
Detectar este punto en ocasiones puede ser evidente, basta con estudiar la orografía buscando un punto desde el que se vea tanto la boca de cueva, como el PMA. No podemos elegir la boca de cueva, pero quizá si podamos elegir dentro de lo posible la ubicación del PMA. Sin embargo la ubicación de este lugar no ha de estar condicionado por la visual con la boca de cueva y estar mejor condicionado por otros parámetros:
.- Acceso rodado
.- Aparcamiento suficiente.
.- Acceso a internet.
.- Servicios básicos de alojamiento, aseo, estancia, mando y control etc.
El lugar de colocación del repetidor lo podemos hacer con QGIS calculando la cuenca visual de la boca de cueva y por otro lado la cuenca visual del PMA. Allí donde se compartan cuencas visuales, esté dentro del rango de alcance 2,5-3 Km. Y sea fácil de llegar pondremos un nodo. Este nodo en entornos rurales y en puesto estratégico lo configuramos con el rol Router, así dará señal a todos los nodos dentro de su alcance. Haremos un anexo explicando esta metodología. Podéis ir viendo los rudimentos de QGIS en el micromanual que tenemos en nuestra Escuela. https://www.escueladeespeleologia.es/micromanuales-ede/
En el PMA podemos poner un nodo conectado por USB-C a un ordenador portátil y gestionar la red con la aplicación web del proyecto Meshtastic: Meshtastic Web
Este ordenador tendrá que tener instalado el driver para convertir el puerto USB en puerto COM. Esto se vio en el artículo anterior. Además, podemos poner una amplificador de señal y una antena supletoria para ganar alcance de señal.
Arquitectura avanzada:
Si tenemos cobertura de internet en boca de cueva y en el PMA, podemos conectar la red del interior de la cueva desde la boca, con la red del exterior (PMA, vehículos lanzadera, coordinador…..) a través de la red Mosquitto.
Mosquitto es un servidor (broker) MQTT de código abierto que permite que dispositivos, sensores, aplicaciones y servicios se comuniquen entre sí usando el protocolo MQTT.
En MQTT no existe comunicación directa entre dispositivos; todos hablan a través de un servidor, y Mosquitto es uno de los brokers más usados en el mundo.
MQTT es un protocolo de mensajería basado en estándares, o un conjunto de reglas, que se utiliza para la comunicación de un equipo a otro. Los sensores inteligentes, los dispositivos portátiles y otros dispositivos de Internet de las cosas (IoT) generalmente tienen que transmitir y recibir datos a través de una red con recursos restringidos y un ancho de banda limitado. Estos dispositivos IoT utilizan MQTT para la transmisión de datos, ya que resulta fácil de implementar y puede comunicar datos IoT de manera eficiente. MQTT admite la mensajería entre dispositivos a la nube y la nube al dispositivo.
El protocolo MQTT se ha convertido en un estándar para la transmisión de datos de IoT, ya que ofrece los siguientes beneficios:
Ligero y eficiente
La implementación de MQTT en el dispositivo IoT requiere recursos mínimos, por lo que se puede usar incluso en pequeños microcontroladores.
Escalable
La implementación de MQTT requiere una cantidad mínima de código que consume muy poca energía en las operaciones. El protocolo también tiene funciones integradas para admitir la comunicación con una gran cantidad de dispositivos IoT. Por tanto, puede implementar el protocolo MQTT para conectarse con millones de estos dispositivos.
Fiable
Muchos dispositivos IoT se conectan a través de redes celulares poco fiables con bajo ancho de banda y alta latencia. MQTT tiene funciones integradas que reducen el tiempo que tarda el dispositivo IoT en volver a conectarse con la nube. También define tres niveles diferentes de calidad de servicio a fin de garantizar la fiabilidad para los casos de uso de IoT: como máximo una vez (0), al menos una vez (1) y exactamente una vez (2).
Seguro
MQTT facilita a los desarrolladores el cifrado de mensajes y la autenticación de dispositivos y usuarios mediante protocolos de autenticación modernos, como OAuth, TLS1.3, certificados administrados por el cliente, etc.
Admitido
Varios lenguajes, como Python, tienen un amplio soporte para la implementación del protocolo MQTT. Por lo tanto, los desarrolladores pueden implementarlo rápidamente con una codificación mínima en cualquier tipo de aplicación.
El protocolo MQTT se inventó en 1999 para su uso en la industria del petróleo y el gas. Los ingenieros necesitaban un protocolo para un ancho de banda mínimo y una pérdida de batería mínima para supervisar los oleoductos vía satélite. Inicialmente, el protocolo se conocía como transporte de telemetría de Message Queue Server debido al producto de IBM MQ Series que admitió por primera vez su fase inicial. En 2010, IBM lanzó MQTT 3.1 como un protocolo gratuito y abierto para que cualquiera pudiera implementarlo, que después, en 2013, se envió al organismo de especificación de la Organización para el Avance de Estándares de Información Estructurada (OASIS) para su mantenimiento. En 2019, OASIS lanzó una versión 5 de MQTT actualizada. Ahora MQTT ya no es un acrónimo sino que se considera el nombre oficial del protocolo.
Línea temporal de MQTT
1999 – Creación del protocolo
- Andy Stanford-Clark (IBM) y Arlen Nipper (Arcom, hoy Cirrus Link) desarrollan MQTT.
- Diseñado para comunicaciones ligeras en redes satelitales con recursos limitados.
2003–2010 – Primeras versiones internas y adopción inicial
- IBM utiliza MQTT internamente para proyectos M2M.
- Comienza a usarse en sistemas SCADA, petróleo y gas, y telemetría industrial.
2010 – MQTT se libera públicamente
- IBM publica MQTT bajo una licencia abierta, lo que facilita su adopción comunitaria y académica.
2011 – Lanzamiento del servidor MQtt Mosquitto
- Roger Light libera Eclipse Mosquitto, un broker MQTT gratuito y de código abierto que impulsa enormemente su popularidad.
2012 – Formación del OASIS MQTT Technical Committee
- Se funda el comité para estandarizar MQTT como protocolo abierto.
2013 – MQTT 3.1 es presentado a OASIS
- Se propone oficialmente como estándar abierto.
2014 – Publicación del estándar OASIS MQTT 3.1.1
- Se convierte en el estándar de facto en IoT.
- Más tarde, la ISO lo adopta como ISO/IEC 20922:2016.
2016–2018 – Gran expansión en el IoT
- MQTT se consolida como protocolo dominante en plataformas IoT industriales y en servicios cloud (AWS IoT, Azure IoT Hub, Google Cloud IoT Core).
2019 – Lanzamiento de MQTT 5.0 por OASIS
- Mejora importante que añade:
- Propiedades ampliadas del protocolo.
- Mejores códigos de razón.
- Sesiones independientes del estado del cliente.
- Flujo más rico de control y errores.
- Soporte para request–response.
2020–2024 – Popularización en Web y Tiempo Real
- Aparecen MQTT over WebSockets, brokers en la nube y runtimes serverless.
- Entra con fuerza en domótica (Home Assistant, Tasmota, Zigbee2MQTT, etc.).
Actualidad
- MQTT es uno de los protocolos más usados en IoT, industria 4.0, automatización, agricultura, domótica, movilidad y telemetría en general.
- Ecosistema muy activo: EMQX, Mosquitto, HiveMQ, VerneMQ, NanoMQ, entre otros.
Puedes usar Mosquitto para conectar dos redes LoRa independientes, pero no directamente entre radios LoRa, sino a través de gateways LoRa que conviertan LoRa → IP/MQTT. Por ejemplo la red del interior de la cueva con la red del Puesto de Mando Avanzado o cualquier equipo en cualquier parte del mundo con conexión a internet.
- LoRa no puede conectarse directamente a Mosquitto
Las radios LoRa solo transmiten LoRa físico.
No entienden MQTT, ni TCP/IP, ni Wi-Fi.
Por eso no pueden conectarse personalmente a Mosquitto.
Necesitan un equipo intermedio.
- Lo que sí puedes hacer: usar LoRa + Gateway + Mosquitto
Para conectar dos redes LoRa separadas a un mismo Mosquitto necesitas:
🔹 Red LoRa A (cueva)
- Radios LoRa → conectados a → Gateway A (uno de nuestros nodos)
- Gateway A convierte: LoRa → MQTT (nuestro nodo conectado al ordenador)
- Publica los datos en el broker Mosquitto (nuestro ordenador se conecta a la red)
🔹 Red LoRa B (independiente de A) (Puesto de Mando Avanzado)
- Radios LoRa → conectados a → Gateway B
- Gateway B también convierte LoRa → MQTT
- Publica en el mismo Mosquitto
o en otro Mosquitto remoto al que ambos estén conectados
El gateway: (ordenador portátil o teléfono móvil en nuestro caso conectado a una radio LoRa)
- Recibe paquetes LoRa desde un nodo por el USB-C.
- Los interpreta.
- Los envía por Ethernet al broker MQTT.
- MQTT los distribuye a los clientes finales.
Resultado
Dos redes LoRa aisladas físicamente pueden intercambiar datos entre sí a través del broker Mosquitto sin interferirse a nivel de radio.
MQTT Broker (Mosquitto)
- Representado por el cuadrado morado central.
- Es el centro de comunicaciones IP (no de radio).
- Recibe mensajes MQTT desde Gateway A y B (ordenadores o teléfonos móviles conectados a mqtt.meshtastic.org)
- Reenvía los datos a suscriptores MQTT
- Permite que clientes de ambas redes intercambien información
Función: unir dos redes LoRa independientes a través de Internet.
Servidor MQTT Público
El proyecto Meshtastic proporciona un servicio MQTT público al que los usuarios pueden conectarse, con ciertas restricciones para garantizar la estabilidad de la red. Este servicio permite a los dispositivos meshtásticos puentear a través de Internet, proporcionando conectividad global para redes remotas.
Configuración básica
Nodos de puerta de enlace
Cualquier nodo meshtastic que tenga una conexión directa a Internet (ya sea a través de una aplicación auxiliar o un hardware instalado de USB-C/WiFi/4G/satélite) puede funcionar como un «nodo de puerta de enlace».
Conecta tu ordenador portátil a: Meshtastic Web
Conecta tu nodo (en nuestro caso el llamado y configurado como PMA)
- Conecte su nodo de puerta de enlace al portátil o teléfono móvil. Al portátil lo puedes hacer a través del puerto USB-C. al móvil también con el puerto USB o a través de la wi-fi compartida de tu móvil.
Elige el nodo que está emparejado
Valores de configuración de módulo MQTT
Habilitado
Habilita el módulo MQTT.
Dirección del servidor
El servidor a utilizar para MQTT. Si no está configurado, se utilizará el servidor público predeterminado.
Nombre de usuario (el que tu quieras)
Nombre de usuario de MQTT Server para usar (lo más útil para un servidor MQTT personalizado).
Contraseña (la que tu quieras)
Contraseña MQTT para usar (a tu elección). El usuario y contraseña han de ser las mismas para la puerta de enlace del PMA y de la boca de cueva (y de cualquier otro ordenador conectado en cualquier parte del mundo al que quieras dar señal)
Encriptación Habilitada
Ya sea para enviar paquetes cifrados o no cifrados al servidor MQTT. Los paquetes no cifrados pueden ser útiles para sistemas externos que desean consumir paquetes de malla.
Nota: Todos los mensajes se envían al broker MQTT sin cifrar si esta opción no está habilitada, incluso cuando sus canales de enlace ascendente tienen claves de cifrado establecidas.
Proxy del cliente habilitado
Si es cierto, deje que el dispositivo utilice la conexión de red del cliente (por ejemplo, el teléfono) para conectarse al servidor MQTT. Si es falso, utiliza la conexión de red del dispositivo que tiene que habilitar a través de la configuración de red.
Si vas a tener una puerta de enlace en el PMA y otra en boca de cueva tendrás que configurar ambas de igual forma. Obligatorio tener acceso a internet en ambas localizaciones.
Una vez configurado el ordenador portátil del PMA y el de boca de cueva, ya puedes enviar y recibir mensajes entre estos dos puntos (y cualquier otro punto del mundo con enlace) a través de internet sin nodos intermedios.
Los participantes deberán inscribirse previamente y deberán contar con una tarjeta deportiva que cubra las labores de rescate, o un seguro privado.
En condiciones estivales de agua, en la base del P80 te mojas, así como en la base del P58 ya en el Cañón de Cellagua. Si entra en carga desde la base del P58 hasta la cabecera del P80 puede ser difícil o imposible la progresión.
Garma Ciega X: 454.022 / Y: 4.786.895 (EPSG 25830)
Este es el perfil original de la topografía de Balart. Hasta el Comedor la ficha no cambia. A partir de aquí se toma una vía lateral que te deja en la Sala Blanca.
No habrá campamento base, la idea es que los participantes elijan libremente el alojamiento en la comarca del Alto Asón. Pinchando en la imagen puedes planificar tu viaje.
La recepción e información de entradas y salidas se centralizará en la Oficina del ESOCAN en Ramales de la Victoria.
Todos los participantes deben llevar (además de su equipo personal de progresión vertical completo) manta térmica, comida, iluminación suficiente y ropa de abrigo para soportar las temperaturas del interior. Llevar un hornillo, sbit o alcohol en gel puede ser interesante.
El tamaño mínimo del grupo para moverse por la cueva es de 2 personas, 4 es el ideal. Grupos de más de 6 deportistas pueden retrasar la marcha.
En el vivac de Titanes se dará prioridad al equipo que sube del sifón.
