[Feature Request]: Add Ability to Select a Specific Channel Index when Requesting Position

[rjDipcord]

Checklist

• I have used the search function for OPEN ISSUES to see if someone else has already submitted the same feature request.

• I have also used the search function for CLOSED ISSUES to see if the feature was already implemented and is just waiting to be released, or if the feature was rejected.

• I will describe the request with as much detail as possible.

• This request contains only one single feature, not a list of multiple (related) features.

• I have read and understood the Contribution Guidelines.

• I agree to follow this project's Code of Conduct

Contact Details

@rjDipcord

Feature or improvement you want

Current Behavior

The Meshtastic platform allows up to 8 channels to be defined on a node. Each of these channels can have their own position precision set independently of others. But at the time of writing, there is no easy way to utilize these different configurations. You simply must choose a maximum precision, and place that channel low on the index for it's setting to be utilized.

This behavior has it's drawbacks mainly due to position sharing via the primary channel - many folks don't wish to share their precise location with the greater mesh. But some users do wish to share their precise location only with trusted parties, family, and friends.

Proposed Feature

Since each channel can have independent location precision and the Meshtastic firmware already supports responding to position request packets on the channel in which it was received, simply adding the ability to choose what channel you send a "exchange position" packet on will allow users to request a precise location of a given node, while still permitting that node to maintain it's default telemetry settings over Primary.
This type of request works as expected if issuing it over the Meshtastic CLI.
meshtastic --request-position --dest "node-id" --ch-index "x"
Assuming both nodes have the same channel and key, the destination node will respond on that channel with a position packet at the precision set for it.

Why should this be added?

The obvious workaround for this is to place the desired channel as primary (or lowest-index with position sharing enabled) on the requesting node. However this has some undesirable friction for the end-user, since the primary channel governs the node's channel slot. Users must remember that moving the modem-preset's default channel away from primary will cause their slot to change from default. If not, then their node will cease to communicate with their local infrastructure at all until they override the slot in LoRa settings. Additionally, this behavior requires the user to be knowledgeable of the designated channel slot for their preset. For savvy users, this is an easy adjustment. Even still, it is an unnecessarily abrasive step for a rather trivial config.

And that is not to mention forgetfulness. Sometimes you may move channels to get a quick fix on a target node, and forget to move your primary back. At least, that's common with my use case.

Some use cases for this include family, friends, or personal item tracking. Tactical communications with specific precision modifiers per-channel that only certain roles within a unit have access. And general users who wish to share a broad location with the greater mesh, and precise location for their personal property, should the need arise to determine it.

I think this would be a valuable feature for the Meshtastic community and I hope that the devs think so as well. The app has come a seriously long way since I began using it in 2024 and I can't wait to see what's to come.

Thanks for considering this.

Screenshots / Drawings / Technical details

As a suggestion, (though I am terrible with UI design) we could implement this with a couple different methods.

• Implement a long-press to the exchange position button which presents a drop-down menu to select which channel name to use for the request. If it's not easy to display the name in this UI, channel-index would suffice.
• A node-specific settings dialog which gives the user the ability to change the channel in which default comms to and from the node are designated. This would effect all telemetry requests.
• A simple, clickable button next to exchange position which allows the user to set the designated channel-index for this node.