Closed kokroo closed 2 years ago
It's up to the connected device (phone, whatever) to send the position if connected. Moving to android.
It's up to the connected device (phone, whatever) to send the position if connected. Moving to android.
It doesn't work like this. I've tested it with several phones and boards and I even read it on the forums. If there's on-board GPS, then the phone location is never used.
This issue has been mentioned on Meshtastic. There might be relevant details there:
https://meshtastic.discourse.group/t/no-sats-no-gps-lock-tried-a-few-different-things-already/4517/5
It's up to the connected device (phone, whatever) to send the position if connected. Moving to android.
It doesn't work like this. I've tested it with several phones and boards and I even read it on the forums. If there's on-board GPS, then the phone location is never used.
Code for this is in PositionPlugin::handleReceivedProtobuf which also calls nodeDB.updatePosition.
Noting in there filters out GPS. Happily accept a PR if there's a fix needed.
when "Provide location to mesh" is enabled, Google Play Services provides phone GPS location data to be used in Position packets sent from the app.
for the feature to work, besides Google Play Services and Android permissions, device settings can't have: LocationSharing.LocDisabled
or fixedPosition
.
Position packets with location data (lat, long & alt) are sent every positionBroadcastSecs
(default 15 minutes);
unless: the device sent a Position packet less than positionBroadcastSecs
ago.
room for improvement:
positionBroadcastSecs
ago;positionBroadcastSecs
(even empty lat0, lon0, alt0) replacing any previous phone GPS data sent;when "Provide location to mesh" is enabled, Google Play Services provides phone GPS location data to be used in Position packets sent from the app.
for the feature to work, besides Google Play Services and Android permissions, device settings can't have:
LocationSharing.LocDisabled
orfixedPosition
.Position packets with location data (lat, long & alt) are sent every
positionBroadcastSecs
(default 15 minutes); unless: the device sent a Position packet less thanpositionBroadcastSecs
ago.room for improvement:
- app phone GPS data is not sent even if last Position packets from the device has empty fields (lat0, lon0, alt0), as long as it was less than
positionBroadcastSecs
ago;- sometimes device also sends Position packets every
positionBroadcastSecs
(even empty lat0, lon0, alt0) replacing any previous phone GPS data sent;
I think this might be the bug. Either way, I think changes will need to be made to both the Android app as well as the firmware.
A check like "if device has empty fields for GPS, use the ones from the phone".
My basic logic for acquiring location is:
We can obviously make the phone location opt-in with a privacy warning.
What do you guys think?
This issue has been mentioned on Meshtastic. There might be relevant details there:
https://meshtastic.discourse.group/t/heltec-lora-32-issue/4414/16
related #345
many improvements were made to "provide location to mesh" feature in the latest 1.2.54 release. please verify if that solves this issue.
@andrekir I will check it out and close the issue if it works. Will need more testers to confirm this.
@andrekir Was this issue thoroughly checked before closing?
sure, doesn't take much to check either. as always you're welcome to reopen if you find anything wrong.
A lot of the Meshtastic boards have GPS antennas which aren't the best. In addition to that, a lot of times the GPS chip only detects one constellation. All of these lead to initial GPS locks which require 10-20 minutes.
I propose this: if a smartphone is connected to the board, and has an accurate position available, then the board should use and broadcast this location.
It is entirely possible that some hiker might get injured away from their group and their board might keep failing to get a GPS lock by itself but their phone might be able to get a lock. That way, even if the hiker is unconscious, the others will be able to find the injured person.
Modern smartphones almost always have multi-constellation detection including GPS, GLONASS, Galileo, BeiDou, NaVIC, QZSS, and have really amazing reception too.
I think it's a no-brainer to prioritize the phone's location if available, and if not, only then resort to the board's GPS.