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.confSUPL_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…
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.
1 Like
To try understand better the results ob my tests, I’d need to know:
Does any of you know, for sure:
Does the hardware(or un-flahed part of the system) keep track of any GPS related data that would help to locate, even at a “cold” start?
and
Does a battery removal delete this datas if they are in HW?
I honestly do not know how to explain the behavior.
I have now also tested intensively for a week.
no matter whether MLS completely off or offline data on. after 20Sek I have an accuracy of 9000 meters.
If I have a GPS fix and then turn off GPS for an hour, when I use GPS again I get a fix within seconds. But if I have to restart the phone after a GPS fix, all previously (temporarily) saved GPS data seems to be gone. Then a new fix can take between 5 - 30 min.
It is also interesting how much the quality of the GPS signal varies.
I did a reboot session and under the same conditions, satellites are displayed once with a great signal and again with a very poor signal on the next reboot. And within 5 minutes the satellites have not moved away so much that would be an explanation.
But with me it does not matter what quality the signal has. I also get a fix from satellites that are in the red or yellow range of the signal quality.
it is all very strange
1 Like
I guess it does store data for some time on-device. The gps.conf on my system mentions this:
XTRA_SERVER_1=http://xtrapath1.izatcloud.net/xtra2.bin
XTRA_SERVER_2=http://xtrapath2.izatcloud.net/xtra2.bin
XTRA_SERVER_3=http://xtrapath3.izatcloud.net/xtra2.bin
From their site:
The Qualcomm Location XTRA Service generates and provides accurate Satellite positions for extended periods of time to a mobile device. This assistance data is provided in compact form and allows the mobile device to perform positioning for an extended period of time (up to seven days). The assistance data files are made available to a Data Distribution Network for global distribution.
I don’t know if this is actually used.
The GPS receiver should keep the latest almanac and ephemeris data known; to do this it should be provided a backup power source, since I don’t think this unit has access to flash to store them. Therefore, removing battery will probably cold start the receiver.
That’s likely to enable AGPS online services which include downloading XTRA data (almanac) and injecting NTP time into modem.
If only MLS services are selected AGPS online functions in geoclue provider are not triggered thus not downloading the required data to speedup a GPS fix.
But speaking of XTRA data: I switched my XA2 from “high precision” (which enables XTRA data download) to device-only mode (no MLS, no data connection). This will stop injecting NTP, XTRA and MLS’ed approx. position into modem. However having a lot of SVs in sight and GPS was receiving many signals there was no fix for more than 15+ minutes so I aborted my test.
What I did next was doing a GPS cold start (manually removing cached GPS + GLONASS almanac and ephemeris data from modem), rebooting my device and see how fast it would get a fix from zero to hero without AGPS online services.
The GPS receiver now needs to download the full almanac and ephemeris data on it’s own which should take about 12 minutes. I got a fix after 10 minutes in the end which is a “normal” duration starting cold.
So from my subjective experience here is that cached almanac data and possibly the injected XTRA data might confuse the GPS receiver to prioritize the wrong SVs (GLONASS or GPS) and keeps waiting to fetch a specific signal that is weak or even not there.
1 Like
Many people testing and reporting! We are going to fix it!
@nekron thanks for the explanations. Have to read them again but for sure, at the moment, it would be extra useful to know how you do this:
My only way ATM is to unplug the battery hoping to get a cold start 