Any replacement plan for Mozilla location service?

General
#21 
$ ./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!

According to https://en.wikipedia.org/wiki/Mobile_country_code US MCCs are 310-316 (excluding Guam and V.I.).
US cell data as of 2021-01-17: https://gofile.io/d/lkmFp4

PS You might need to devel-su chown root.root -R /usr/share/geoclue-provider-mlsdb/ afterwards.

2 Likes
#22

As carmenfdezb said you must install geoclue-provider-mlsdb-tool:
devel-su pkcon install geoclue-provider-mlsdb-tool

#23

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?

#24

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 :frowning:

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.

1 Like
#25

I see, thank you. Sad to see that this piece of the system got broken and there is no fix in sight. :frowning:

#26

It works for me. It now takes minutes instead of tens of minutes to get a fix.

#27

I would not say so.
With A-GPS a fix should be there within 30-60 seconds.

3 Likes
#28

I created the required mlsdb.data files by passing India as Country param. But when I checked the logs, getting no cell id information available

[D] unknown:0 - have 5 neighbouring cells
[D] unknown:0 - have neighbour cell: “type: LTE, cellId: 232044301, locationCode: 51701, mcc: 404, mnc: 40” with strength: 20
[D] unknown:0 - ignoring neighbour cell with no cell id with type: 3 mcc: 2147483647 mnc: 2147483647 lac: 2147483647 tac: 2147483647 pci: 2147483647 psc: 2147483647
[D] unknown:0 - ignoring neighbour cell with no cell id with type: 3 mcc: 2147483647 mnc: 2147483647 lac: 2147483647 tac: 2147483647 pci: 150 psc: 2147483647
[D] unknown:0 - ignoring neighbour cell with no cell id with type: 3 mcc: 2147483647 mnc: 2147483647 lac: 2147483647 tac: 2147483647 pci: 482 psc: 2147483647
[D] unknown:0 - ignoring neighbour cell with no cell id with type: 3 mcc: 2147483647 mnc: 2147483647 lac: 2147483647 tac: 2147483647 pci: 16 psc: 2147483647
[D] unknown:0 - geoclue-mlsdb data file “/usr/share/geoclue-provider-mlsdb/5/mlsdb.data” contains 56798 cell locations, but not for: “type: LTE, cellId: 232044301, locatio
nCode: 51701, mcc: 404, mnc: 40”
[D] unknown:0 - no geoclue-mlsdb data files contain the location of composed cell id: “type: LTE, cellId: 232044301, locationCode: 51701, mcc: 404, mnc: 40”
[D] unknown:0 - no cell id data to calculate position from
[D] unknown:0 - GetPosition: no valid current location known
[D] unknown:0 - calculating new position information
[D] unknown:0 - have 6 neighbouring cells
[D] unknown:0 - have neighbour cell: “type: LTE, cellId: 232044301, locationCode: 51701, mcc: 404, mnc: 40” with strength: 22
[D] unknown:0 - ignoring neighbour cell with no cell id with type: 3 mcc: 2147483647 mnc: 2147483647 lac: 2147483647 tac: 2147483647 pci: 2147483647 psc: 2147483647
[D] unknown:0 - ignoring neighbour cell with no cell id with type: 3 mcc: 2147483647 mnc: 2147483647 lac: 2147483647 tac: 2147483647 pci: 150 psc: 2147483647
[D] unknown:0 - ignoring neighbour cell with no cell id with type: 3 mcc: 2147483647 mnc: 2147483647 lac: 2147483647 tac: 2147483647 pci: 482 psc: 2147483647
[D] unknown:0 - ignoring neighbour cell with no cell id with type: 3 mcc: 2147483647 mnc: 2147483647 lac: 2147483647 tac: 2147483647 pci: 16 psc: 2147483647
[D] unknown:0 - ignoring neighbour cell with no cell id with type: 3 mcc: 2147483647 mnc: 2147483647 lac: 2147483647 tac: 2147483647 pci: 131 psc: 2147483647
[D] unknown:0 - no cell id data to calculate position from

#29

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?

#30

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.

2 Likes
#31

I’m not sure. Depends on how often your cell operator installs/upgrades cell towers.
I’d update files every couple of years.

PS If/when you operator starts installing 5g towers that it would make sense to update more often.

1 Like
#32

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.

6 Likes
#33

Maybe somebody should raise this issue (slow GPS lock at least for 2+ years) on next meeting.

2 Likes
#34

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).

4 Likes
#35

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()
3 Likes
#36

Thanks @cbalanescu - I wrote a quick article with some simplified steps, using your above post :slight_smile:

5 Likes
#37

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…

#38

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

#39

I made an RPM spec file for building an RPM of latest MLS data directly on your device (hard coded but easily changed: Austria):

I wanted to upload an RPM file… but @BlacksheepGER was faster :wink: Check an RPM for your country:

1 Like
#40

Sorry for beeing faster :laughing:!

I created a small bash script doing the job for me. Only the icon needs to be modified manually and this makes me fast!

1 Like