Add dynamic usage mode selection for GPS Position.

[fifieldt]

Most of the GPS chips we support have the ability to change their operating model "dynamics" based on the intended activities.

We currently assume everyone is a pedestrian and configure as such.

However, there are users out there on bikes, planes, balloons, and with fixed devices. Where GPS chips support it, we can configure for each of this circumstances and improve performance.

For example, fixed nodes might no longer jump around on the map. Planes will have a more responsive and less filtered position. Balloons' GPS won't simply cut out because its gone over an altitude limit. Boats won't have altitudes that make them appear to be floating in the air.

Additionally, this could provide the opportunity for a bit of fun in the apps - surface information about the use case so people know when they're connecting to a plane or balloon :)

Related to: meshtastic/firmware#3984
Related to: #619
Related to: meshtastic/firmware#5281

[thebentern]

I think this is a really neat idea, but I have some questions and concerns:

1. We already have a huge density of Position module / GPS levers to turn for users, which can be confusing for some. This could add to the confusion, indecisiveness, and configuration cults 😅
2. I think at some level, this would likely end up being a CLI feature or even preferably a UsersPrefs one, which makes sense for the ballooners who already self-curate some firmware modifications for their niche.
3. What is the distribution like in terms of support for each of these modes for each GPS family / module? I would imagine most support a subset of these but not all, outside of uBlox likely. I am only familiar with a subset of these being available in the ATMG336H modules I've experimented with. My assumption is BALLOON is our own creation here though.
4. Is there a possibility we have these modes just internally on-device and use some heuristics to toggle between various modes based on the context of the last positions we observe? E.g. normal operation starts as PEDESTRIAN, if our last position is high altitude + high speed, we switch to PLANE, if high altitude + insignificant speed we switch to balloon, if normal altitude + moderate speed, switch to CAR, etc.

[fifieldt]

Very fair!

So, I'd say on average, a cheap GPS chip only supports about 4 of these (default, pedestrian, vehicle, and airborne). I went with the maximal set to try and make it easier for users to select an option for their use case. The firmware would need to map these into the correct configuration for the GPS. I'm not necessarily wed to these specific 7 choices - they just matched with the Meshtastic use cases I've seen.

Regarding Balloon, taking ublox as an example, there are 3 different airborne modes. The labels for those modes are typically specified in terms of G (as in, acceleration). Balloons tend to be slow (relative to other airborne things) and care about altitude :) So, implementing this is looking up the altitude table for the GPS chips and choosing the right one.

I don't think heuristics would work here. We don't store enough positions and trying to DIY what the GPS hardware already does well could end badly. For example, a fixed position node can jump by 10km instantaneously - using that and determining it's a plane from then on is probably going to make things worse :)

[fifieldt]

There's another angle to consider here, which is -- are these use cases something that could be useful outside of a GPS sense?

May choosing a "bike" be more intuitive than understanding the difference between "client" vs "router", for example? Maybe it could be a way to have users feel they are selecting the 'right' mode for them, while providing the firmware enough information to make healthy networking choices in terms of broadcast packets? :)

[fifieldt]

Oh, and on the proliferation of variables. What do you think about making PositionFlags CLI/UserPrefs only?

It could be influenced by this setting too - boats don't need altitude, pedestrians don't get speed.

[thebentern]

Oh, and on the proliferation of variables. What do you think about making PositionFlags CLI/UserPrefs only?

Phenomenal idea! Sensible defaults and then unlock everything else for UserPrefs only. Get them out of the config entirely, IMO.

[garthvh]

Both sped and heading are useful for hiking / pedestrian use

[fifieldt]

OK, I think to move on this I need to make a patch in firmware that shows what it looks like if we nuke the PositionFlags, and add these other usage mode selectors. Then everyone can take a look and determine if such a change to protobufs is worth going for.

It's a bit more work than I anticipated (though worthwhile!), so it may take me a while to get to this :)