It also works fine for me in France.
Thanks a lot!
Thank you for this workaround. Today I was in need of the GPS, and even after 40 min I couldn’t get a lock (GPSInfo reported 18 satellites in view). So this is a very needed solution.
To confirm: to either add a new country, or extract for the whole world, we have to change the source code and recompile? Is it possible to compile directly in the phone or is an SDK needed? I couldn’t find instructions in the linked github repo.
Thank you
This is my issue, (United States), but I’m not clear on your directions - I don’t have this file anywhere… is it in the source? So you would have to build it yourself, and not use the mlsdbtool from pkcon?
Yes, the modified and compiled source code from github.
If you want I’ll create the files for you tomorrow. Do you need Guam and Virgin Islands cell data?
I would also appreciate those files. In my case, continental US would suffice. Thank you
No thanks - mainland us would be great. Thanks
$ ./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.
As carmenfdezb said you must install geoclue-provider-mlsdb-tool:
devel-su pkcon install geoclue-provider-mlsdb-tool
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.
I see, thank you. Sad to see that this piece of the system got broken and there is no fix in sight.
It works for me. It now takes minutes instead of tens of minutes to get a fix.
I would not say so.
With A-GPS a fix should be there within 30-60 seconds.
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
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.
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.
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.
Maybe somebody should raise this issue (slow GPS lock at least for 2+ years) on next meeting.
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).