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.
Stupid questions…if it is that easy, why it is GPS still a problem?
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:
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 :–) )
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.
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.
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:
gps.conf SUPL_HOST entry matching your current public mobile IPIn 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.
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…
I had fixes after one hour these days, although I did get the offline fix with 9000 m accuracy.
Therefore, it looks like it is used somehow, but it does not speed up the fix.