SpeleoMesh

Documents and notes about the speleomesh project


Project maintained by DaneEvans Hosted on GitHub Pages — Theme by mattgraham

Tasmanian SAREX, 19-20/2/2026

Location: Kazahduhm, Junee-Florentine Routes: Wet Way - 4 pitches / Serpentine - 4 pitches

Scope

Tasmanian SAREX, Multi agency including Cave Rescue from Tas, NSW, QLD, SA, VIC & WA, NSW police rescue, Tasmanian Police & paramedics.

The mesh system was run in conjunction with Michie phones, and UHF radios. This was to be it’s first test at full scale - with some people from each team on it, and testing a lot of hops through the system.

The wet way in particular is the area in which michie phones struggle in out systems - Lots of noise on both the transmitting and recieving end make it hard to reliably pass messages.

Goals

Due to time constraints, this test was primarilly focussed on hardware and some procedural changes.

Report

As we were trying to wire up both sides, and there is limited mobility, I suggested that we add the network the day before, this also gave the devices longer in a typical (hostile) cave environment.

Wet way

Jess and I started with the Wet way, Placing one at the usual entrance base area (~40 m outside), another in the entrance itself, then a series down the streamway and pitches.

The terrain in this direction was well suited to the mesh radios, and it took only 5-6 radios within the cave to cover the area of the exercise.

Internal antennas were used primarilly, especially in or close to spray.

The last one placed was a external antenna, with a 5m coax, with 2 areas stripped, one close and one at the end. It was placed above the third pitch, as we elected not to descend it on that day. The coverage at the bottom was apparently very good, and these antennas (or plain leaky feeders) should be investigated further.

Placements were quite easy with the LEDs, although lightpipes should be white or transparent for colour clarity.

One issue found was that it appears that the ADRT ON command was able to be sent by channel, not just by DM, this has not been tested on the bench yet

Using skewers or dowels + drilling holes allowed a lot more placements, out of the way, with good sightlines etc. Unfortunately the one halfway up the second pitch was not well placed, nor tied on, and it was knocked down the pitch repeatedly. This was patched quite quickly. Apparently the antenna on the last one was also moved and caused some confusion, but no issues with Comms can be attributed to it.

Laying the whole of the wet way took 90 - 120 minutes, including returning to the top.

At some point during this day, the surface server stopped sending the ADLED messages. This was not debugged at the time.

Serpentine

Serpentine is a nasty piece of passage from a radio perspective - constantly winding, 30-50cm wide, and requires approximately 120m of wire to span. I had 2 pairs of RS4885 devices available, but from the map I had expected to be able to do 2 30-40m sections, and use radios for the rest, but a quick walk through suggested this was unwise.

We laid the first roll of cable (80-90m), starting just inside the entrance. This took multiple hours, as the entire passage would be taken up by a stretcher, so positioning it in a way that it could be rigged as well was time consuming. When the cable ran out, we were 20 - 30m short of the end of serpentine, so we added some additional cable. That done, we tested it, and were unable to get messages through tot he initial node. I tried doing just the short (30m) length of cable, and that seemed fine, but the surface one was non-responsive.

During one or more of the connections, and the rolling of the cable, several of the connectors were exposed to dust, silt and water. They are quite fine pin connectors, and while waterproof when attatched, should be protected the rest of the time.

It was left in place like this, and we awaited the exercise the next day.

Exercise

On arrival the next morning, I set up the surface server again, and tested which units were visible - The list included the ones at the bottom of the wet way so I started the day trying to get serpentine connected properly. I ran all of the excess (10m) on the short wire back towards the start, hoping to be able to remove 20-30m from the long wire with a short radio hop. The hope was that if it was the resistance of the wire that was causing issues, reducing it may solve the issue. Unfortunately this did not work, and I wasn’t able to reestablish a connection on the short link either. This still makes me think the connectors are at fault, but it could be a combination of factors.

Further testing on the bench 2 weeks later was unable to reproduce this failure - one radio (1A) had a bad configuration - pins wrong, and baud set to 37600. But the other 3 seemed to be set properly, and were able to reliably do a 200m link, with multiple connectors of different varieties. However one of the connector halves from the test had come off - so it’s possible that there was an issue with the soldering on that connection, which was where / how it broke.

With no link through serpentine, I went with the alternate ‘traditional route’ which bypasses the serpentine with 3-4 radios of rift passage about 8m above the level of the streamway and serpentine. Once this was complete, I ran out the remainder of the radios down the dry route, and was able to hear messages from the base of the Wetway through 8+ hops.

Around this time the surface complained about not getting messages reliably from the wet way - this is unverified, and in the case of at least one message was proven false. The surface team changed personel several times, and had several comms interfaces to monitor. A possible explanation is that without using ‘router’ mode, it is possible that messages were being piped to / from the traditional route, rather than making their way to the surface.

My source of truth for the early part of the exercise was Henry who was in the streamway / cave entrance. This meant that he stayed in contact with the wet way as I moved in and out of reception. Unfortunately he lost his phone at about the time that the dry teams were connected to the mesh, and thus my ability to compare messages recieved there, and the surface was removed.

Next time we need the surface server, and logging to be working so these can be spotted at the time, and verified afterwards.

Radios

At the end of the exercise, I had 8+ radios on the traditional route, ceasing between the second and third team (out of 5) and ~5 radios on the wet way covering all groups, + 2 hops to the surface command.

Two or three radios didn’t boot properly - likely flat due to the reed switch not turning off fully in the box - these need to be assembed with more care, and possibly the magnet needs to be repositioned slightly. One of the two that were thrown down the pitch was removed from service.

Another few were likely available to extend the dry way radios, but the next group was a lot further down the cave, and reaching them seemed unlikely with the hardware available.

Conclusions

Overall, the wet way teams liked it a lot, and found it much preferable.

Surface noted that they ‘didn’t hear anything after the patient was moved’ - but this was: A) Possibly related to a change in surface personel B) likely due to a reduction in comms in general, as there was less downtime C) found to not be true in at least one case - they’d responded to such messages

The dry way was effectively unserviced by the mesh, due to the issues with the wired link. As the wires should be very reliable, this should be a matter of figuring out what went wrong, resizing the wires / connectors, and it’ll work reliably next time. It’s also easy enough to test on the surface.

Objectives met

Overall the hardware worked perfectly - it all survived 36 hours in situ, one battery may have run down, but it also may have been fine, some units were not giving battery telemetry reliably.

2 units were tested with impacts and water, several more were left in spray for the entire time.

Placement with the LEDs was good, as was the connection LED when it was working.

The Wired link failed completely, but was not adequately tested prior, and I believe it’ll be reliable once we define a suitable cable diameter. AWG26 or 28 may be too thin, or may be too thin when combined with small connectors.

Traffic was never too busy - people are busy doing other things. Spamming was non-existant, and we should not be concerned with giving 1 device per group.

The auto response was great when it was working in the classroom, but it needs to be robust for use in the field (UPS, USB radio / in built, autostart and restart)

Additional tests / questions