$ ./geoclue-mlsdb-tool_mcc310316 -c Spain MLS-full-cell-export-2021-01-17T000000.csv
Reading data from file and caching cell locations which are within the bounding boxes...
Progress: 11440000 lines read, 2371172 cell locations inserted
Finished reading data: 11447488 lines read, 2371172 cell locations inserted
Writing data (596603 entries) to mlsdb.data file: ./1/mlsdb.data
Writing data (569987 entries) to mlsdb.data file: ./2/mlsdb.data
Writing data (497477 entries) to mlsdb.data file: ./3/mlsdb.data
Writing data (358144 entries) to mlsdb.data file: ./4/mlsdb.data
Writing data (155940 entries) to mlsdb.data file: ./5/mlsdb.data
Writing data (67372 entries) to mlsdb.data file: ./6/mlsdb.data
Writing data (43605 entries) to mlsdb.data file: ./7/mlsdb.data
Writing data (38372 entries) to mlsdb.data file: ./8/mlsdb.data
Writing data (43672 entries) to mlsdb.data file: ./9/mlsdb.data
Done!
I tried this on my Xperia X, but the time to get the position first is still in the 5-minute range. Am I doing something wrong, or is this normal? Is this due to ephemeris/almanac download? Is there really no way to get it at least below 1 minute?
No.
It really seems to depend on last stored/received satellite data (which might get lost?).
This offline calculation only helps to fix the location roughly to the location where you are logged in to cell network.
Normally I would expect this to help getting a fix faster but it does not
Even being same location, no movement, just a 24h time frame in between and getting the offline calculation in under 30s (depending on if only Country or whole World/Europe compiled) the real fix might take at least 2-5 minutes. Again depending on satellite signal strength.
So as much as I hoped this can “fix” GPS fix, it does not!
And I am afraid this will stay as is as there was no response from @Jolla lately.
Working great. Thanks… btw - how often should these be updated? Is it something that would be obsolete or not work properly at some point if not kept updated?
The notion that we should accept waiting several minutes for a GPS fix reminds of the entertainer, Victor Borge, once arriving at an elevator, exulting: “Ahh, just in time for the two o’clock elevator!”
I’d wish the developers would somehow chime in and let us know if we can expect any relief in the upcoming release.
It depends on what type of A-GPS you are talking about. With a usable almanach (i.e. almanach and coarse position and time estimate) 30-60 seconds seem ok under perfect conditions, since the download of ephemeris data from satellites takes about that time (c.f. GNSS Ephemerides and Almanacs). In this case A-GPS provides the position estimate and maybe the almanach, but that’s usually cached on device anyhow.
With a working SUPL server a fix should be much quicker, since the ephemeris data is also transmitted via TCP. But I’ve never seen a SUPL request from my XA2 even though a server is configured in /etc/gps.conf and I’ld be curious to know the reason.
I have to agree that the culprit is missing or none-working SUPL function for the Sony devices even like @martinh wrote that everything in the configs is in place.
So what is happening when you turn on your GPS?
Depending on your settings the raw GPS allamanc / ephimeris is used when running in offline mode. Therefor the GPS RX has to "“download” the data from the GPS satellites and this takes a long long time (15 minutes or even longer when you have a lot of noise / multipath signals).
To speed things up Jolla used Mozilla location based service when you allowed it in the settings or used the manually imported offline celltower databases. The device did an online / offline query using your WiFi / celltower IDs to ask for an approximate position. This position was then used as a first time GPS fix however with a lot of inaccuracy and non-updating GPS position. Now that the device knows your approx. position it queries some online SUPL service to download the needed allmanac / ephimeris data. This data would normally be injected into the GPS unit via Android lib hybris functions and you would get a regulary updated high-accuracy position fix.
The latter steps (query SUPL, download data and inject it into GPS) is broken since a few releases and eventually worked before (my memory might be wrong on this but I used GPS to track irregulary road trips and got a GPS fix within seconds on Xperia X).
Often an advanced location service is not even needed. geoclue-master maintains the file ~/.local/share/qtposition-geoclue that should contain last position and corresponding timestamp. That is sufficient most of the time to have an initial position estimate. The following script allows to dump the contents of that file:
#!/usr/bin/python3
import os
import struct
import time
FNAME = os.path.expanduser("~/.local/share/qtposition-geoclue")
def build_geoclue(lat, lon, alt):
now = int(time.time()) - time.timezone
days, seconds = divmod(now, 86400)
with open(os.path.expanduser(FNAME), "wb") as f:
f.write(struct.pack(">iiib", 0, days + 2440588, seconds * 1000, 0))
f.write(struct.pack(">dddi", lat, lon, alt, 0))
def read_geoclue():
with open(FNAME, "rb") as f:
pad, days, seconds, _ = struct.unpack(">iiib", f.read(13))
bb = f.read(28)
lat, lon, alt, _ = struct.unpack(">dddi", bb)
print(time.ctime((days - 2440588) * 86400 + seconds / 1000 + time.timezone))
print(lat, lon, alt)
# build_geoclue(50, 7, 300)
read_geoclue()
When I think about it, I like the idea of using “offline” data. And it would be cool to have a package, that has the geoclue-mlsdb-tool as dependency and a setting page, where you can (initial) download and update the full-cell export…
geoclue-mlsdb-tool --help country show countries, which can be used, e.g. [root@XperiaXA2-DualSIM Downloads]# geoclue-mlsdb-tool -c Austria MLS-full-cell-export-2021-01-23T000000.csv
Check an RPM for your country:
!