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
So https://beacondb.net/ for both of them?
1 Like
You need to put the whole URL.
beaconDB hosts an endpoint at
https://beacondb.net/v1/geolocatewhich is compatible with Ichnaea’s request format. if your software has a large amount of users, please don’t use this as a default location service. beaconDB infrastructure is not yet capable of handling a large amount of requests.
2 Likes
One more project worth checking out is tpikonen/ols: Offline Location Service - Codeberg.org, though I personally haven’t tried it yet. You could set up an offline database of your provider’s cellular towers to let you get at least an approximate location fully offline (as long as the modem is on).
IMO, Purism should at least set up an Ichnaea-compatible endpoint for retrieving OpenCelliD-based location and use that by default in PureOS. That won’t get us WiFi-level accuracy, but it would be much better than status quo.
3 Likes
Thanks!
I‘ve updated and it works much better. It downloads the data within a minute. Where the data gets stored? If I start after running it the Maps app, this needs many minutes to show the blue location point which is a few hundred meters off.
How is Maps using what was downloaded?
1 Like
In the GNSS module’s flash.
It doesn’t. This data contains current positions of the satellites around the Earth and allows to extrapolate future positions for some time. It’s used by the GNSS module when looking for satellite signals. The position as reported by the GNSS module is one of the sources that can be used by Geoclue, and, in turn, the blue dot in GNOME Maps running natively (not inside Flatpak due to the bug mentioned above).
4 Likes
I did this change in the config of geoclue:
55,60d54
< # added July 2024 by guru@unixarea.de
< # see also: https://forums.puri.sm/t/random-gnss-enquiry/24041/27
< # dont forget: service geoclue restart
< #
< url= https://beacondb.net/v1/geolocate
<
restarted the geoclue service. Then I started the Maps app, but switched off the display (the L5 in question was shipped in September 2021). I switched it on again after 30 secs and Maps had already the blue dot and relatively exact, maybe 30 feet from my position in the garden. The sky is cloudy.
Can’t say when Maps got the fix exactly, because the display was off. Does write Maps some debug log and if so how I could turn it on?
Update 1:
With the above change for the service geoclue I see messages like this in /var/log/syslog:
Jul 13 12:04:23 pureos geoclue[78495]: Failed to query location: Query location SOUP error: Not Found
I watched with tcpdump and MLS is not contacted but the server https://beacondb.net/v1/geolocate
“error: Not Found” means perhaps that the server answered the HTTPS request with 404…
1 Like
Where is this exactly and does it survive a boot?
Re/ the test tool gnss_test.py I’ve got this some years ago from @angus.ainslie :
As far as I understand it and its output, it reads directly the device as one could do it as well with
sudo grep -a '$..GSV' /dev/gnss0
1 Like
Inside the Teseo-LIV3F module, and yes.
That script changes the configuration of the module to an invalid one every time it’s launched (self.set_constellation(143)). Don’t use it. You’ll have to redo the original instructions.
If you want a script that interprets NMEA output, use usr/bin/gnss-test · main · Librem5 / librem5-agps · GitLab. It’s still somewhat buggy though, I’d just look at the NMEA output, it’s not much harder to read once you know what to look at 
Sounds like a GNSS fix, unrelated to beaconDB which wasn’t able to locate you.
2 Likes
Isn’t that basically the same script? It also does a self.set_constellation(143) on line 185 vs. the other script on line 193.
1 Like
Yes, a diff gnss-test guru/gnss_test.py shows, that it is (apart of some print polishing) the same code.
1 Like
Ha. It is indeed. Don’t use that one either then 
That whole repo predates my work on Assisted GNSS.
1 Like
Downloding almanaces (…) with 1207/agps.py works fine but the flag -i makes it hang for ever. What could be done with geoclue ?
$ diff 1207/agps.py 1207/agps.py.orig
71d70
< logging.info("running Geoclue.Simple.new_sync() ...")
73d71
< logging.info("running initgps() ...")
75d72
< logging.info("done initgps() ...")
$ sudo 1207/agps.py -i /dev/gnss0
INFO: Checking approximate location...
INFO: running Geoclue.Simple.new_sync() ...
Terminated
purism@pureos:~/guru$ sudo 1207/agps.py /dev/gnss0
INFO: Checking the latest Galileo almanac...
INFO: Downloading https://www.navcen.uscg.gov/sites/default/files/gps/almanac/current_sem.al3
(... from ~20 sites ...)
INFO: Downloading https://storage.puri.sm/agps/ephemeris.raw
INFO: Downloaded. Generating...
$ sudo 1207/agps.py -i /dev/gnss0
INFO: Checking approximate location...
INFO: running Geoclue.Simple.new_sync() ...
(hangs for "ever")
1 Like
I wrote a small python script to simplify, but this hangs also:
#!/usr/bin/env -S python3 -u
import logging
import gi
import struct
import os, sys
import argparse
from datetime import datetime, timedelta
from time import sleep, time
gi.require_version('Geoclue', '2.0')
from gi.repository import Geoclue
clue = Geoclue.Simple.new_sync('something',Geoclue.AccuracyLevel.NEIGHBORHOOD,None)
location = clue.get_location()
print(location.get_property('latitude'), location.get_property('longitude'))
1 Like
You get that when you have Geoclue configured to use MLS (which has shut down) or beaconDB (which is mostly empty). If you configure it to use a service that’s actually functional where you are (like Google, an OLS instance with MLS/openCelliD dumps etc.) it will work again.
1 Like