GPS stopped working

Sorry for the inconveniance, I think I have to update my README now :open_book:

@martinh :slight_smile: :+1: Yep that’s it! I’ll fix my documentation about this issue with 10 II. I was braindead when writing my docs and sure it was /system/etc where gps.conf is located.

Just in case libgeoclueprovider is looking for /etc/gps.conf a symlink to /system/vendor/etc/gps.conf would be a good thing to add like it’s on other SailfishOS devices.

UPDATE: Geoclue provider uses

void HybrisProvider::loadDefaultsFromConfigurationFile()
{
    QFile gpsConf;
    bool parseXtraServers = false;
    const char *paths[] = {"/vendor/etc/gps.conf", "/system/etc/gps.conf", NULL};
    int i = 0;
    while (paths[i] != NULL) {
        gpsConf.setFileName(paths[i]);
        if (gpsConf.open(QIODevice::ReadOnly)) {
            break;
        }
        ++i;

(https://github.com/mer-hybris/geoclue-providers-hybris/blob/a411045e66470cf3aee2c92e0145b0e3520c9980/hybrisprovider.cpp#L278)

So either edit symlinked /etc/gps.conf or /system/etc/gps.conf or /vendor/etc/gps.conf (my brain still works :wink: ).

Alas in your case geoclueprovider just parsed the first entry (/vendor/etc/gps.conf) which points to /system/etc/gps.conf so your newly created /system/etc/gps.conf was never ever parsed → no SUPL host or XTRA data injected into GPS.

2 Likes

Right, so I symlinked /etc/gps.conf → /vendor/etc/gps.conf, and walking outside, experienced best insta-lock I’ve ever seen on this X10 II, very great Androidish experience.

But now am not able to get any lock indoors. Am I not supposed to? Never seen Android phones having trouble positioning in Uber, indoors or out.

1 Like

Stupid questions…if it is that easy, why it is GPS still a problem?

1 Like

EDIT (Moved my post as “reply”)

Nekron’s suplpatcher seems to be a very good medicine.

I would say there is still something to solve because:

  • it is not a native solution and AFAIU sources cannot be available.
  • it finally relys on google even if anonymized (and who knows what the proxy does with our data (btw, same question for all “alternatives” ))
  • it does not solve the soft/hardware issue with pure GPS/GNSS use .

I personally like the idea to be able to localize my position in RX mode only.
Free and discrete. Totally anachronic and unproductive!
More seriously, a well working pure GPS can become very useful as soon as one gets far from urban environments. Trekking, mountain, water, nature in general.

And for the sake of well made things: solid bases are needed to elaborate well.

(about bold use, I think it clarifies but dunno … If it hurts, just tell me, I’ll remove it :–) )

2 Likes

At least I know what my proxy does.

I have a Qstarz BT-Q1000XT bluetooth GPS receiver fully integrated with SailfishOS just in case there’s no cellular connection possible. Setup is not easy but it works quite nicely.

3 Likes

This is interesting, thanks a lot for the py script. What a lambda like me would have to do to have one/do the same?
Install something like that somewhere on my webserver? Or use yours?

Great but a bit redundant, if I dare. Would be cool to have all in one device!

Using mine won’t work, since it filters my IMSI, not yours. To host your own you need a server that you can configure in your phone (IP or name) and a way to run some TCP server. A webserver is not sufficient since SUPL is plain TCP, not HTTP.

2 Likes

Is there a how-to for self hosted SUPL proxy for those of who have e.g. a personal VPS to use with that?

I’m trying to use the Python-proxy on my XA2. I’ve edited the file to use my IMSI, and changed the port on which it listens to 7276. In /vendor/etc/gps.conf I’ve added SUPL_HOST=127.0.0.1 and SUPL_PORT=7276. I’ve ran ./suplpatch --disable. GPS in “high accuracy”. Rebooted. Then, I ran ./supl-hack as root. It shows it is listening at port 7276, but it never shows that a connection is made when using a GNSS app.

I do get a fix after a minute or two, but I never had so much trouble with it anyway. Anything I did wrong or something I can try?

I’ld be suprised if that were possible at all. The SUPL request comes out of the SOC and bypasses the OS of your phone. It aleays uses the cellular connection (i.e. no WiFi) and does not even use the DNS server configured but its own (whichever that might be).

Like @martinh said there are two systems running on your SoC: the Sailfish OS executing in the non-secure world and Qualcomm RTOS / applets executing the in the secure world. The interesting part is that ARM Trusted Zones do not start the secure world as some kind of hypervisor for the non-secure world’s OS (like Virtual Box, VMWare, HyperV, KVM) but run in parallel. The SoC simply implements some kind of hardware boundry between them (TEE).

Now that non-secure worlds SailfishOS injects the SUPL host and port via geoclueprovider/mer-hybris bindings to Android GNSS service that uses some QMI/DMA interface into secure-world’s GNSS service 127.0.0.1 will be resolved to localhost on the secure-world’s network stack and not the non-secure SailfishOS.

To get this possibly working you must:

  • bind the Python scripts port to 0.0.0.0 (any network interface)
  • dynamically update the gps.conf SUPL_HOST entry matching your current public mobile IP
  • start a GPS session only after you modified the settings

In the end it’s much easier to run the script on some static VPS or even using a dynamic DNS resolver forwarding the request to your private network.

Respect and thanks guys for sharing all these explanations.
I really wish I could elevate from the mortal common to get the light in all you say. Maybe one day…

Much more down to earth and boring, only not-assisted GPS speaking:
Doing intense tests, flashes and re-flashes and other HW things since a week,
Here is not a solution to make GPS work but at least something to avoid it not to work in some cases (!).

I noticed a strange phenomenon, maybe kind of a bug:
If you flash SF, install MLS package and enable Location with “custom” ON ON OFF right away, fix will not happen.
Even though online MLS is not available any more, you will have to tick “high precision” and accept the license. Then, it has a chance not to fail fixing.
(It might also work accepting the licence with “custom” ON ON NO → licence)

To sum up:
Accept the Mozilla licence or you will lose time with false negatives while testing.

This is a really interesting observation @ric9k, and thanks for sharing it. I’ve logged an internal issue about it, as if it’s the case, I can see how it’s liable to cause confusion.

1 Like

Thanks for the info. I’ve been thinking about the “external IP”-route as well, after @martinh’s remark. But you don’t want to run the proxy for the world to (ab)use. One could adapt the script to only accept requests coming from the phone’s own WAN-address. For now I’ll relent, and use google’s SUPL for the time being.

As I wrote earlier, now confirmed with several further tests, ever since I changed the setting to “GPS only” (i.e. without any online or offline assistance) I’ve been getting fix within half a minute outdoors or 1-2 minutes indoors, which is quite acceptable for me.

Good job @nekron , I still have to test that

BUT

if redirecting SUPL to Google fixes the issue, why doesn’t it work with offline Mozilla data?

Goopple are more…everything :–)
More seriously, could the Google antennas list be more complete?
While I was observing the output of

QT_LOGGING_RULES="*.debug=true" QT_MESSAGE_PATTERN="%{time} [%{type}] %{appname} (%{file}:%{line}) - %{message}" /usr/libexec/geoclue-hybris

and saw multiple times that antennas were unknown (W EU Package).
Maybe Google do know them?

Weird, since positioning did work until Mozilla online data were accessible.
Maybe Mozilla offline data are not the same as online data?

Doesn’t it work at all with offline Mozilla?
MLS should help a bit. Or not at all?
Very hard to compare because data stays recorded somewhere…