Somewhat related is the desire to set precision levels for different channels. Possibly through a bitmask that gets AND'd with the location at https://github.com/meshtastic/firmware/blob/master/src/modules/PositionModule.cpp#L110 before sending the packet.

Seems really complex, uses a bunch of airtime and is of marginal benefit, still not sure why secondary channels need position. Also has to be done in 3.0.

we really don't want to send the same packet multiple times in different channels. this would have a huge impact in total airtime considering rebroadcasts/ACKs.

I agree with Garth and Andre. The suggestion to let it send on a different channel at each opportunity is good, but then again if you want frequent updates on one channel, you’ll need to set the updates really high. Duplicating the settings for each channel seems very cumbersome.

Indeed someone can already spam the channel by setting the position updates to every 5 seconds, but it’s pretty clear that that creates a lot of traffic. However, it’s not intuitive that enabling it on an additional channel means that for each update your device will need to send a separate packet there.

Allowing someone to request position with less precision on secondary channels might be an alternative solution. You can already request telemetry on secondary channels.

Seems really complex, uses a bunch of airtime and is of marginal benefit, still not sure why secondary channels need position. Also has to be done in 3.0.

Adds complexity, sure. The idea is to round-robin the location data among the channels where it's enabled, so no additional airtime.

For use case, I want my family to know exactly where I am, but I only want the world at large to see approximate location.

Why would it need to be 3.0? A receiving device has no clue if a position was sent over a secondary channel. All we need is added config on the protobuf, and some code to send out messages on different channels.

For use case, I want my family to know exactly where I am, but I only want the world at large to see approximate location.

Assuming you don't want the whole world to be able to follow you in real-time, wouldn't it be better to allow manual imprecise position requests on secondary channels? I'd argue that it's an even better user experience, because you will get a response immediately, instead of having to wait for the next broadcast opportunity, whose interval you don't know.

Assuming you don't want the whole world to be able to follow you in real-time, wouldn't it be better to allow manual imprecise position requests on secondary channels?

Does that work for MQTT? Another use case for this is to let people send their location data to a public MQTT server, to have a more accurate map of where nodes are at. Local trusted mesh gets full accuracy location, public channel gets reduced accuracy, and is shared with MQTT.

I think we have enough agreement to get started. Whether to enable the automatic position broadcast on a secondary channel is a relatively minor implementation detail. For that matter, it could be disabled by default, and just turned on for custom firmware builds.

It's already been mentioned I will reiterate that the intent is not to broadcast this information on multiple channels and increase utilization, it's to broadcast at the same interval but spread among the selected channels. No additional position updates will be sent out; please review the example I provided in the original summary.

We do need to think about better control mechanisms for which portnums can communicate over which channels IMO, because we have the same problem w/ MQTT. For instance, users want to be able to send nodeinfo, telemetry, or position over secondary uplink channels and those don't necessarily have the same affect on airtime.

I had originally envisioned that being an enum w/ flags for portnums on each channel with mqtt uplink. Not trying to highjack this issue, just noting that there are similarities in the two in the fact that users want more control over what information goes out over secondary meshes, be that lora or mqtt.

I had originally envisioned that being an enum w/ flags

We could do that with the GPS stuff, too. Maybe define high, mid, and low accuracy GPS flags.