[Feature Request] Camp Mode Discussion

[tmacinc]

I've been working on an app for backcountry use that gives a team good SA about team member locations, history, and connectivity within the network. I'm currently using a custom build of the firmware that enables forwarding on companions under certain conditions and am working on a smart algorithm to minimize forward events to only what's needed to maintain connectivity of the group.

A discord member recommended that I post this here to see if any of this would be useful to the future camp mode that has been discussed. I personally haven't come across talks of this but would love to be able to utilize standard firmware if possible.

My goal is to only have this feature available in a way that doesn't interfere with established infrastructure, and to enable dynamic mesh networks for small groups when needed. I think MeshCore would really benefit from this.

I'm posting here to gauge interest and have a discussion if there is.

[liamcottle]

Hello, thanks for the post!

I've converted this issue to a discussion.

We have plans to enable companion repeat functionality for camping/search and rescue use etc, where repeater infrastructure is non existent, and/or infeasible to set up.

This needs to be done in a way to avoid allowing companion repeat on public meshes, and we are looking at allowing this to be enabled on demand, but only on a select few frequencies or range of frequencies.

My thoughts are to also add a new "Custom Presets" section to the app, where you can quick switch between other presets that might be used for camping etc. Along with the ability for other users to quick scan a QR code to jump onto that preset.

[tmacinc]

This has been one of my main goals also. I think it's an incredibly useful feature to have, but I didn't want to create any issues with established mesh networks. One thing about forcing a frequency is that you'd want to make sure the frequency is optimal for backcountry use, it would suck if you dropped connectivity because you didn't have access to the ideal radio settings.

I'm not an expert in all the intricacies of MeshCore and issues that can pop up as I've been learning as I go. But since these types of groups are relatively small and share potentially more information compared to an established mesh, there's potential for building smarts into the forwarding rules. I'm currently sharing telemetry packets via a private channel that defines the group, and each user uses that information to build a network connectivity map. So each user knows who in the group is connected to who and where everyone else is. Then using an algorithm each user determines which users messages they should forward, and the firmware gets updated with a whitelist. I've added some fallbacks that wait for repeats heard and have other nearby users forward if the primary fails. It's still a pretty untested idea, but with groups that share telemetry it can reduce the number of total transmits pretty decently.

This is certainly more complicated than just pushing everyone to an unused frequency. I do like this also and I think this could also be a really easy method for the user, basically have a enable camp/backcountry mode that opens a configure group page to create a channel and share the QR, and the QR could also include the radio settings.