I’ve been playing around with the meshtastic-python interface and plotting maps and noticed, that sometimes the GPS position is really off.
That’s because of my test setup with only partially visible sky, but I imagine it can happen in the real world too, so it would be useful to know how precise the coordinates are.
As far as I know most GPS chips already calculate such a value, so the big question would be is it worth enlarging the messages to transmit it or not.
2 Likes
one of the nice things about protobufs is that they only actually use bytes on the wire for fields that are set (blank fields are free). So if someone wanted to add “hdop” (or pdop - I forget which one is more useful) to the Position message that would be pretty straightforward. You’d want to add this in src/plugins/PositionPlugin.cpp.
Initially that higher cost of payload could just be on all the time. But if we want to optimize further someone could add an “include_hdop” bool to the UserPreferences protobuf.
I’d prefer a value in meters instead of an abstract one. uBlox 6 and up later have a parameter called Hacc that gives you that.
I assume that’s what you’ll get with getHorizontalAccuracy from the SparkFun_Ublox_Arduino_Library, but I wasn’t able to track it down.
Having this as a userPreference would of course make sens. Should that be another value for LocationSharing or a separate parameter?
1 Like
Ooh good idea. A new enum in locationsharing would be optimal.
Also we could always store hdop (or whatever) in Position and just strip it before sending if “VerboseLocationSharing” is not the current selected mode. This would allow the local app to always see that info even if we don’t want to pay that wire cost for packets sent in the mesh.
3 Likes
How about adding a “maximum allowed GPS error threshold” setting, or called something more professional. 
If the threshold is met, the GPS error would be shown <x meters/feet, and no extra mesh load would be used. If the threshold is exceeded, the error rate would be sent? Indoor nodes could be a problem, as they would always add the error rate to the packets…
The default allowed GPS error could be rather large, for example ~30m? Outdoor users would then get information about inaccurate location reports by default, with minimal air time usage.
As always, all comments are appreciated! 
1 Like
Users should be able to enable or disable the feature, and adjust the threshold for reporting (according to their need for accuracy).