I’ve noticed some hubub over the role of GPS within Meshtastic; some requests to shut it off, a pinch of disdain for it, admiration by others, and elusions to the less efficient Disaster.Radio project. Simply put, GPS inside Meshtastic is a bit controversial.
Disclaimer: I am not poo-pooing on DR --It’s just not as blessed with as active a development cycle and I hope it finds its stride once again. It still looks like a very purposeful, valuable project, and I fully understand it’s apples/oranges. Maybe in another post we can discuss the differences, but for now let’s stick to GPS.
In this case, I’d like to learn more about the role of GPS in Meshtastic for myself and others; why it’s there, why it’s valuable, how it is utilised, and whether or not a fork that removes it would or wouldn’t make any sense (and the difficulty level of such a project to do so), how it could be perceived as a privacy concern (if at all), and to see if anyone wants to present constructive, logical reasons for or against it in the comments.
So, what’s the dill with GPS?
I recall from videos I viewed while researching Meshtastic before I bought into it that it was used in analytics and calibration, but can we put the subject to rest with a clear explanation for us noobs?
I’m all for asking “evergreen” questions that might be annoying up front for technical people who may feel obligated to answer them, but valuable in the long-term because when it comes up again, this post can be linked to, referenced, and save time on responses surrounding the subject in the future. I hope the makers of Meshtastic don’t hate me for asking.
New here, and don’t want to kick a can of bees --but shouldn’t GPS broadcasting from nodes and/or phones be optional?
A use-case for it being optional; opening up my network of 24 nodes to the general public. I don’t want that kind of power or awareness of users. Or a protest some developing country (ie. Arab Spring).
Some want it for all messages sent, I understand that use case. But with multiple use cases, a toggle may serve them all.
I would like to second an easier way to disable GPS. For teaching it is not legal or safe for students to test from home and have their address being shared to the whole group
Yes @roostercrab - the requested feature was already implemented (even when this was originally requested in January). But to elaborate:
“meshtastic --set location_share LocDisabled” should do what you want.
@Havealoha, the distinction between location_share and gps_operation is subtle. If location sharing is turned off, the GPS may still be used sometimes to get highres time (which is slightly useful now, but super useful for our eventual goal of letting even the radio RX modules sleep, to allow micro solar nodes to run indefinitely). See the docs for radioconfig.proto with details.
Each person or group will form their own use-cases that are important. In the case of small teams of people wanting to communicate over a mesh network while hiking in the back woods, then clearly the roll of the GPS is to allow you to have information on where the other team members are.
In the case of a gliding use-case, then very accurate time measurement is important, so you know if that location was determined 20 seconds ago or 20 minutes ago… which would be hugely different in location for someone flying.
If the use case was to create a communicator for say a large public event, but you want absolute best power economy and there is no real use for the GPS component and no use for accurate time management, then turning it off sounds like a better option.
The other option that comes into play that has not yet been mentioned is the security built into defining your own channel.
When you create your own channel and share that channel info to ONLY your friends, then the other devices out there will not be able to see your GPS location. The communication path is encrypted, and that channel information is part of that encryption.
Now… I would not take that to mean you have complete location security. Direction finding gear is not that hard to come by. RF on a localized network gives away the fact that you are “in the region”. You can’t transmit on the Lora network, be observed by many stations and then later claim that device was not there… it’s easily documented that it was. Turning off GPS does not make the device a magic ghost that can’t be seen in terms of general location.
If the concern is to not broadcast your location, then forming community with those that you want to share your location with by creating a custom channel is a good start.
Lastly: Small teams is an important concept. 40 people trying to communicate often at the farthest reaches of Lora range and using a lot of store and forward would probably find that to be a lot of chatter on the RF channel. I’m not saying it won’t work… but it would depend a lot on how often each station is trying to send information into the mesh. If that setup ran into a lot of retransmission being required, end to end latency could be significant.
I may be over simplifying the issue but if you really don’t want to share location rather than relying on software why not go for one of the supported boards without a GPS module? Then disable location services on your phone…
Because we have the boards that we have and I don’t think that I could convince the school to buy different ones.
My use case specifically is that we are teaching LoRa using Meshtastic and students don’t want to share their locations with the other students. It just seems like it should be an option that you should have to opt into rather than opt out of.
Whether it is easy to find you with directional antennas or not doesn’t mean that there is always a need to make it as easy as possible to find you I would think.
This is using the Meshtastic CLI application that’s bundled in with Meshtastic-python.
Installation instructions are located here. Soon this will be on the documentation site. We are still migrating the docs over there.
I think it should remain opt-out. Especially early on in this project alot is gained from knowing where and what distance you are from other nodes. A random house having a node doesn’t really give any useful information other than the fact that someone spent $25 on some hardware. I do agree that children in schools should not have the location on, so maybe an educational build or asking their parents to change the setting, but I think locations should be on by default. A private school only channel changed in the beginning would mitigate some of the risk to start.
Edit:
I especially think that all nodes configured as routers or permanent powered installations should be always sharing their location (even if only once every 12 hours) to create a map of the local area. User location sharing may be different or only channel based
Since the main use cases are around safety opt out of the default still seems important, but @roostercrab has a cool use case that should be supported too. Seems like the main issue is really getting the setting out of the more technical Python API into the more accessible app.
