I just tried this, and it didn’t make any difference. Will try leaving the phone outside with Maps running continuously.
The phone now has an accurate location after leaving it outside for 1 hour with Maps running. The location is precise enough that I could see my movement back indoors in real time on the map. So, GNSS is working fine; I just didn’t know how to use it properly until now.
Having got a GNSS fix, turning WiFi back on does not seem to be pulling me back to the old, incorrect location. I assume GNSS takes precedence over WiFi. So, I guess the problem is solved.
I spoke too soon. It has jumped back to the incorrect address again! But maybe with the GNSS active it will eventually update the location database. (I don’t know if that’s how it works.)
You need to be outside, or at least near a window with good view at the sky, to maintain a GNSS fix - that’s just how these nav systems work. When you lose the fix (plus some delay) Geoclue reverts back to GSM/WiFi based location.
Could you clarify what is the proper way to use it?
The place it keeps quantum leaping to is not linked to a cell tower, it is a location based on ip address (presumably looked up via Mozilla Location Services or some other database). GSM tower locations are inaccurate as well, but they do tend to be relatively close to your actual location.
Edit: from a quick read on the MLS website, I take it that the jump location is based on a GeoIP lookup - the least accurate of the methods MLS uses.
I believe you are incorrect. There are no public IP addresses in common between my current real location and the location it leaps to.
The incorrect location that it jumps to is a multi-tenant building. At the time when I lived there, the landlord-provided internet connection was load balanced across, IIRC, three VDSL lines, each with a static IP address. Those IP addresses may well have got into one or more of the various location databases with an accurate location. There were plenty of other tenants who could have caused that to happen.
But those IP addresses were tied to the internet connection in that building. They were statically assigned. Nobody else was using them. They have absolutely no relation whatsoever with any network or internet connection at my current location. I currently have a dynamically assigned IP address from a different ISP. My mobile phone service provider is different too, but I was using a 2G dumbphone with no WiFi or GPS when I was living at the old location anyway. Most of the time, my phone was not even connected to GPRS Internet, because it wasn’t worth paying for a data allowance for that phone, so I was charged money for every day it was connected. Even if I was using the same phone provider, in my experience they all give you a different IP address every time your phone re-connects to the network anyway.
The only IP addresses that are the same between my current location and the location it thinks I am at are the local addresses in my local network. But it would be silly to use those for geolocation, because local addresses are potentially being re-used by countless networks in countless different locations. In any case, as I accidentally discovered last night, my phone still jumps to the incorrect location when my own WiFi access point is completely switched off. In that situation, there are no IP addresses whatsoever, local or otherwise, to relate my phone to the location it jumps to.
The location it jumps to is a residential location and is not the headquarters, exchange or peering point of any communications company or public internet infrastructure. There is no cell tower there. It’s just a normal street. If I were still living there, then the blue location dot would be right outside my window. Just to reiterate: my Librem 5 has never physically been there. I didn’t own it until after I left that address.
It is well known that location services databases use the location of WiFi networks, typically recorded by passers by with GNSS-enabled phones, to figure out locations. It seems to me that the simplest and most likely explanation is that one or more people who had a phone gathering data for the Mozilla Location Service happened to be outside my window at my old address at some point in time, causing my WiFi networks’ location to be recorded. Fewer people pass by my current address, and it’s also more difficult now to contribute data to MLS, because Mozilla discontinued the software for doing so. It is conceivable that nobody with a GNSS-enabled phone that contributes to MLS has passed within range of my WiFi networks at their current location, or at least not enough people to counteract the number of reports at their old location.
Based on the newly-established fact that my phone still jumps to that location even when my own WiFi is completely switched off, I now believe that, because my phone did not have an accurate GNSS fix, over the course of months, it must have caused other WIFi networks in my current vicinity to get added to the Mozilla Location Services database in the same incorrect location that it had determined from my own networks. It would be an astonishing coincidence if any of these other WiFi networks had any relationship with my former address other than existing in the vicinity of my own networks which used to be located there. So, I am hopeful that, with a GNSS fix, my phone will eventually cause the location of all these networks to be corrected.
I understand that, but I had hoped that the fact it had just had a GNSS fix might cause the WiFi location database to get updated so that WiFi would give a correct location. I still think this might happen over time, but perhaps not immediately.
dos explained it:
Yes, the app needs to stay open and the whole phone should stay active too (as in, not go into system suspend). The GPS module isn’t powered up at all when it’s not used (otherwise it would waste plenty of power).
I didn’t realise there needed to be a location-using app running in order to obtain an initial GNSS fix. I thought the location services software on the phone would just do that in the background with no apps running, but it is necessary to leave, for example, the Maps app running until it gets a fix.
I went for a walk today and tried to let the Maps app running and within 3-5 minutes I got a GNSS fix and I had my position accurate within meters the rest of the walk.
I didn’t know either that it should have some minutes in clear sky and with the app open.
I gave up and changed my WiFi SSIDs, (so that now both the ESSIDs and BSSIDs are different than they were at my former address). Going to mark dos’ post about leaving Maps open as a solution, since that’s been really helpful, even if it wasn’t a solution to the original problem I posed.
For the record, by default Geoclue doesn’t upload the location data back to MLS. You can turn it on in its settings, although I’d wait with that until 2.7.0 lands in PureOS as it will have plenty of fixes to avoid garbage data being uploaded.
For the record, by default Geoclue doesn’t upload the location data back to MLS.
Thanks! I was thinking about looking at the docs or the source code to figure out whether it does that, so you’ve saved me some time by anticipating that question. It makes sense that it would not upload by default in a privacy-focused configuration.
I’m still getting the location of my own previous address, even if I completely power off the WiFi access point that used to be located in that wrong location. (When WiFi is enabled on the phone and there is no GNSS signal.)
For the record, by default Geoclue doesn’t upload the location data back to MLS. You can turn it on in its settings, although I’d wait with that until 2.7.0 lands in PureOS as it will have plenty of fixes to avoid garbage data being uploaded.
I did this, and it didn’t seem to have any effect. I eventually thought to check the logs, and figured out that the AppArmor profile for Geocliue does not include access to the /etc/geoclue/conf.d/ directory and its contents, so Geoclue was unable to read the configuration file I added. I amended the AppArmor profile to give it permission and it no longer complains about being unable to read the directory, so hopefully it will now be working.