Are you running it from a user shell or a root shell? It needs to be launched with sudo from a user that has location services active.
That said, if you commented the initgps line out, you can just comment out that line as well.
1 Like
FWIW I just updated the script to not require Geoclue by default (you can still use it by passing -i argument to it).
1 Like
As I wrote I running it from the user purism, ssh’ed into the L5, with sudo and the L5 has “location service” active. Or do you mean something else?
1 Like
I modified the script 1207/agps.py with some logging and commented out as recommended:
...
print("$PSTMGPSSUSPEND")
logging.info("Checking approximate location...")
logging.info("skipped Geoclue.Simple.new_sync() ...")
# geoclue = Geoclue.Simple.new_sync('agps', Geoclue.AccuracyLevel.CITY, None)
logging.info("skipped initgps() ...")
# initgps(geoclue.get_location())
logging.info("running almanac.get_almanac() ...")
...
and run it from a SSH session with
sudo ./agps.py 2>&1 | tee /tmp/agps.out
cat /tmp/agps.out
sudo ./agps.py
[sudo] password for purism:
$PSTMGPSSUSPEND
INFO: Checking approximate location...
INFO: skipped Geoclue.Simple.new_sync() ...
INFO: skipped initgps() ...
INFO: running almanac.get_almanac() ...
INFO: Checking the latest Galileo almanac...
INFO: Downloading https://www.navcen.uscg.gov/sites/default/files/gps/almanac/current_sem.al3
INFO: Downloading ftp://pub:tarc@ftp2.csno-tarc.cn/almanac/2024/tarc1940.24alc
...
$PSTMEPHEM,331,68,1209fc1cfcdc1a6b0030c00000585627bd7b27004fdc04aab580eb5fab2863e074f5d0bbd87f24266207f61c8e0a2a06f6ff310052c0ff1fc0ebffffd95ff87f00000000*5E
$PSTMEPHEM,333,68,1209e81ce85c1a6b00982f3e8f25be28824b1900d4e904aad82d2c786a969f35396068696a40ff1813055f16a211d70300001100f4c5ff21000600f8aa95030000000000*5D
$PSTMEPHEM,334,68,1209e81ce85c1a6b0020a0003346bc28b5b22e0007db04aa608d870613b38c35e04a435a3c408b1956041d1198153e0303001e00c2c5ff2240d9ffff8afcdf7f00000000*50
$PSTMEPHEM,336,68,1209fc1cfcdc1a6b0034e0002802be28d1a4120040e404aa343a0a5f3bdc9f35a079c927e1402118a1064e12ad1431053100150082c6ff2480a3fffff67cbd7f00000000*52
$PSTMGPSRESTART
The tool sudo ./gnss_test.py needed 150 secs for a Fix, also Maps needs long time to show my location, very exact though.
Is this the expected best result?
1 Like
@dos What is the reason that MLS… perhaps does not work for me? What is MLS at all? Please, forgive me my missing knowledge. That’s why I was asking for a comprehensive document explaining the details and its background.
And, can you please spend some word how I could I hardcode some starting location and how I get the values for it? Thanks
2 Likes
Mozilla Location Services:
It is used by geoclue.
In Settings -> Privacy -> Location Service I have it enabled, but it says No Applications Have Asked for Location Access (even while Maps is still running and showing my correct location. What do I miss here.
And, what is geoclue. I have a process running as /usr/libexec/geoclue .
2 Likes
geoclue is used for providing location services with applications that support it. Normally it relies on Mozilla Location Services, but that is currently undergoing retirement:
Adding to that, geoclue is configured via /etc/geoclue/geoclue.conf and that enables / disables all the possible sources of location information that can be used on a computer, of which MLS is one possible source (maps any visible Wireless Access Points to their GPS coordinates).
2 Likes
I think we are talking at cross-purposes. I am talking about a database that maps Wireless Access Points to GPS coordinates.
My point is that I did not ask for, or consent to, or in any way ever get to choose regarding, my WAP being in either Mozilla’s database or Google’s database or anyone else’s database.
In Google’s case, Google just collected it by scooping at the ether.
2 Likes
I removed the un-commenting again and let the proc
sudo ./agps.py
$PSTMGPSSUSPEND
INFO: Checking approximate location...
run, id does so now since two hours. In parallel I watch with strace the geoclue daemon threads and see that from time to time connects to remote server:
33547 connect(12, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("35.190.72.216")}, 16) = -1 EINPROGRESS (Operation now in progress)
$ nslookup
> 35.190.72.216
216.72.190.35.in-addr.arpa name = 216.72.190.35.bc.googleusercontent.com.
Authoritative answers can be found from:
2 Likes
Well, you did broadcast it on the electomagnetic spectrum for nearby people to pick up. Apparently if you didn’t broadcast an SSID for everyone to see, Mozilla wouldn’t collect/store your AP’s BSSID.
1 Like
Can we please stay focused on the issue of GNSS enquiry, i.e. what can be done and must be configured to get a faster Fix and current location. Thanks
2 Likes
Update the script to its latest version and follow the instructions (remember about keeping the module on during the process). When you’re outside with reasonable sky visibility you should get the first cold fix in under a minute (in good conditions I was sometimes able to get one in just 10 seconds). Subsequent warm fixes should be even faster.
If you’re using an older phone (from 2020-2021), it may be helpful to turn the screen off while it tries to acquire the fix.
I don’t know what sudo ./gnss_test.py does, so can’t help there.
MLS means Mozilla Location Services, which is what Geoclue - the geolocation middleware that apps use to retrieve position information from - used in order to implement cellular- and WiFi-based location. It has recently shut down, breaking these capabilities. That’s why the older version of the script hangs - it tries to approximate your location using MLS, which isn’t online anymore. You can reconfigure Geoclue to use different service than MLS, but realistically the only alternative you have right now with enough data to be useful would be Google.
On other phones people often see WiFi-based location and assume that they got the GPS fix already because it can be really accurate. After configuring Geoclue to use Google on my phone, it places the dot in my backyard right away even with no GPS fix at all. Unfortunately, MLS has shut down (after its quality had been slowly deteriorating for years anyway) and Google’s accuracy comes from vast amounts of data collected from people’s phones that we don’t have access to, so to get accurate position without being worried about privacy and other big-techy concerns you have to let your phone see the sky and wait for a fix from the satellites; there’s no real way around it unless projects like beaconDB gain good worldwide coverage. You can configure Geoclue to submit data there whenever you use GNSS if you want to help.
4 Likes
Note that PureOS byzantium is on geoclue 2.7.0.
I think there are some important fixes in geoclue 2.7.1 to make map applications more usable.
2 Likes
Byzantium’s Geoclue has the important fixes backported (had them even before they were upstreamed ;)). The only problem remaining that I’m aware of is that Flatpak applications using location portal can’t access the high accuracy data due to a bug in xdg-desktop-portal. Pure Maps uses Geoclue API directly instead of portals and works fine as a Flatpak, but flatpaked GNOME Maps does not.
5 Likes
I installed Satellite (and did some ugly tweaks to get it working), and I had today the impression that Satellite indicated that there was a 3D fix, but Pure Maps (from flathub) indicated that there was no fix. I was driving so I could not investigate in detail. But I will test if this happens more often.
1 Like
@dos,
Which of these should be altered for beaconDB usage? (Or both?)
# URL to the WiFi geolocation service. If not set, defaults to Mozilla's
# Location Service with a hardcoded key. To use a custom key, uncomment this URL
# while changing YOUR_KEY to your MLS API key.
#url=https://location.services.mozilla.com/v1/geolocate?key=YOUR_KEY
# URL to submission API of Mozilla Location Service. If not set, defaults to
# Mozilla's API with a hardcoded key. To use a custom key, uncomment this URL
# while changing YOUR_KEY to your MLS API key.
#submission-url=https://location.services.mozilla.com/v2/geosubmit?key=YOUR_KEY
And what is YOUR_KEY?
1 Like
As the comment describes - the first one is location retrieval URL, the other one is submission URL (which is only relevant once you switch submit-data to true). YOUR_KEY is the API key, relevant for MLS and Google as both require one, but not relevant in case of beaconDB.
Note that while beaconDB should theoretically fallback to the last cellular data export from MLS, I didn’t see that happening over here and in turn it just didn’t work for me where I live.
2 Likes