I’ve just recently done a re-flash. There was no noticeable improvement.
When you get it done. No rush from my end. I’m pretty comfortable pulling these sorts of devices apart and have already had it apart to change the battery.
Same as ever. Works and has worked. Sometimes it needs a few minutes but it just works for bicycle, car and motorbike navigation.
XA2, OSM Scout, Here Wego and Pure Maps.
No patches, no hacks, no tricks.
Start navigation, keep moving in the direction of your target. Wait. Enjoy.
Lucky you. 
I wonder why you have no issues
@AlanBreen sometime ago I also did internal cleaning of XA2 and it improved things a bit. Reflash never worked for me.
I also wonder why some XA2’s have no problems at all with gps, but Im assuming those devices are younger and haven’t degraded that much.
There is no believe or not believe that hardware issue is also a problem. But another point supporting hardware issue is that if it was software only Jolla would already fix that or it was at least ComingSoon™ but in the meantime they say they cannot repoduce this issue with their XA2 
I already moved away from XA2 but still carry it in my backpack as backup device. Somday I may need navigation in the middle of nowhere and XA2 is only thing to play with, so it would be nice to back home safely
Serious mistake!
Corrected here
Voila! It finally became a new topic. But pics and description are also here.
As stated before suplpatcher is currently not working for Xperia 10 Mark III as diag structure for AOSP 11 has changed from previous releases (you will get error 22 when executing the binary).
However I already patched my dev version and on my first QA test on a freshly flashed device I made some very interesting observation.
[root@Xperia10III defaultuser]# ./suplpatch --disable --aosp 11
______ _____ __ ___ __ __
/ __/ / / / _ \/ / / _ \___ _/ /_____/ / ___ ____
_\ \/ /_/ / ___/ /__ / ___/ _ `/ __/ __/ _ \/ -_) __/
/___/\____/_/ /____/ /_/ \_,_/\__/\__/_//_/\__/_/
SailfishOS Xperia X devices A-GPS SUPL Patcher v0.0.1.8 (git: 2c48d52, build: 08.06.2022 09:11)
2022/06/08 09:16:01 ------------------------------------------------------------------------------------------
2022/06/08 09:16:01 SailfishOS Xperia X devices A-GPS SUPL Patcher v0.0.1.8 (git: 2c48d52, build: 08.06.2022 09:11)
2022/06/08 09:16:01 Command line './suplpatch' launched with the following flags ...
2022/06/08 09:16:01 --aosp=11
2022/06/08 09:16:01 --disable=true
2022/06/08 09:16:01 --enable=false
2022/06/08 09:16:01 --info=false
2022/06/08 09:16:01 --remove=false
2022/06/08 09:16:01 --upload=false
2022/06/08 09:16:01 --version=false
2022/06/08 09:16:01 Executable launched as user 'root@Xperia10III'.
2022/06/08 09:16:01 Secure SUPL mode already deactivated.
2022/06/08 09:16:01 Bye.
On my first run of the fixed patcher binary I was told that secure SUPL was already disabled. That means that an unlocked Xperia 10 Mark III devices can change to the non-secure Google SUPL port without patching the device, i.e. just follow my suplpatcher instructions without running the patcher binary and you are sound.
FYI: I updated my device to latest Android 11 via OTA update and then did the flash dance.
2 Likes
Thanks for the news @nekron, for the patch and the effort sharing knowledge and solutions.
I am still on XA2 and had a question:
What do mmcblk0p4 and mmcblk0p5 (modemst) contain, finally?
I compared the backups of respective partitions from two DUAL XA2 (made before using suplpatch) and they are different. Shouldn’t they be the same?
I also tried to dd nonsense text files into them, dd them back by switching 4 and 5 and GNSS was still working and having a fix (each time after a reboot).
Are these partition kind of rewriten, or partially rewriten during boot?
Basically, I was trying to (blindly) locate where could ephemerides/almanac data be stored bay comparing before/after etc…
I came back to this too.
Not working because ImportError: No module named dbus
Although dbus-python3 is installed.
Any advices?
I don’t have an XA2 device, and cannot comment much on the issue for this specific device. But I didn’t see any comment in this thread (I may have missed it though) explaining how to debug the hybris geocode provider.
As far as I understand, the location is provided to Qt by Geocode. This daemon is responsible to broadcast over DBus the location and related data. It is using two sources on device to get the location : Mozilla location service based on tower ids in the surrounding, and an hybris layer that can talk to the on-board GPS via Android interface.
This hybris layer is open source, see https://github.com/mer-hybris/geoclue-providers-hybris repo. In particular https://github.com/mer-hybris/geoclue-providers-hybris/blob/master/binder/binderlocationbackend.cpp
You can then run the layer from command line and see what the on-board GPS is actually sending back to the user land. This may help to understand if it’s hardware related or software related :
- don’t run any application requesting location,
- from command line run
QT_LOGGING_RULES="*.debug=true" /usr/libexec/geoclue-hybris - start any application requesting location.
The layer is initializing and outputting something like :
[D] unknown:0 - QConnmanEngine: ofono dbus service registered: "org.ofono"
[D] unknown:0 - QConnmanEngine: connman dbus service registered: "net.connman"
[D] unknown:0 - QConnmanEngine: setup connman configurations
[D] unknown:0 - QConnmanEngine: initialize
[D] unknown:0 - QConnmanEngine: setup connman configurations
[D] unknown:0 - Cellular technology not available
[D] unknown:0 - Default data modem changed to ""
[W] unknown:0 - Initialising GNSS interface
[D] unknown:0 - capabilities 0x363
[D] unknown:0 - GNSS set system info
[W] unknown:0 - Initialising AGNSS RIL interface
[W] unknown:0 - Initialising GNSS Debug interface
[W] unknown:0 - Setting SUPL server to supl.sonyericsson.com (7275) failed
[D] unknown:0 - true true true true QFlags<LocationSettings::DataSources>(GpsData)
[D] unknown:0 - Default data modem changed to "/ril_0"
[D] unknown:0 - Cellular technology available and not connected
[D] unknown:0 - true true true true QFlags<LocationSettings::DataSources>(GpsData)
[D] unknown:0 - Cellular connected false
[D] unknown:0 - Connection manager valid changed
And then GPS data from Android starts to flow in like :
[D] unknown:0 - new watched service, stopping idle timer.
[D] unknown:0 - Starting positioning
[D] unknown:0 - Engine on
[D] unknown:0 - Injecting position 3 1654677624 45.2005 5.62935 nan 9000 nan
[D] unknown:0 - Injecting position 3 1654677624 45.2005 5.62935 nan 9000 nan
[D] unknown:0 - 1654677626286 "$GPGSV,3,1,12,02,02,036,,04,06,314,,05,15,074,,11,00,000,,1*66"
[D] unknown:0 - 1654677626286 "$GPGSV,3,2,12,16,16,296,,18,52,161,,20,11,043,,22,01,227,,1*60"
[D] unknown:0 - 1654677626286 "$GPGSV,3,3,12,25,35,112,,26,45,300,,29,61,047,,31,55,234,,1*6A"
[D] unknown:0 - 1654677626286 "$GLGSV,3,1,10,74,59,140,,66,00,000,,86,06,216,,73,11,140,,1*7D"
[D] unknown:0 - 1654677626286 "$GLGSV,3,2,10,76,04,320,,75,59,322,,84,59,033,,83,00,000,,1*7A"
[D] unknown:0 - 1654677626286 "$GLGSV,3,3,10,85,52,219,,67,04,002,,1*7E"
[D] unknown:0 - 1654677626286 "$GAGSV,2,1,08,01,42,118,,03,00,000,,09,00,000,,10,00,000,,7*7C"
[D] unknown:0 - 1654677626286 "$GAGSV,2,2,08,12,23,198,,24,27,303,,31,78,317,,33,67,149,,7*7F"
[D] unknown:0 - 1654677626299 "$GPGSA,A,1,,,,,,,,,,,,,,,,*32"
[D] unknown:0 - 1654677626299 "$GPVTG,,T,,M,,N,,K,N*2C"
[D] unknown:0 - 1654677626299 "$GPDTM,,,,,,,,*4A"
[D] unknown:0 - 1654677626299 "$GPRMC,,V,,,,,,,,,,N,V*29"
[D] unknown:0 - 1654677626299 "$GPGNS,,,,,,N,,,,,,,V*79"
[D] unknown:0 - 1654677626299 "$GPGGA,,,,,,0,,,,,,,,*66"
[...]
The actual output corresponds to a timestamp and the content of the Nmea string. If you read the above source, you’ll see that this string is actually not directly used to get the location, but it may give information of what the on-board GPS is receiving and if it is properly functioning. Compiling the above source in SDK is very easy if one what to add more debug statements and investigate deeper.
Good luck ; )
5 Likes
Thanks!
Does that mean we could be in the middle, compute these data and compare with what SFOS computes, in order to see if the problms stands before or after this communication stage?
And, here:
Who injects position to who?
modemst contains non-volatile modem data like certificates, ephemeris and almanac data and other modem stuff (e.g. VoLTE provider configs, enabled HF bands). Basically the SoC uses some special embedded file system (EFS) to store data into this partition that can be read by proprietary diagnosis tools.
Since modem is storing a lot of stuff inside this EFS dumps from two different devices are not equal.
2 Likes
I think the injection is done by the Geoclue daemon based on the last known position.
The idea of following the hybris provider is to check what the GPS is sending to the user land. I’m doubting of a bug in the calculation, particularly because the same code has no issue on other devices. But like that you can check when data are received and which kind of data. It may help finding the culprit, hopefully.
2 Likes
Perhaps, as other user also supposed, it might more be something related to ephemeris/almanac remaining into the chip…
Poking around there must be interesting!
I’d love if an angel would slide those tools in my mailbox one day …
It seems that for my XA2 the suplpatch and change in gps.conf made a big difference. Used for biking mostly I can get a fix in less then 2-3 minutes. Just my two cents here.
2 Likes
My old X without a sim card will generally beat that on any given day, and by a significant margin. Having to wait for 2 minutes each time you use the GPS is worse than frustrating.
If it weren’t for the better Android support that the XA2 gives I’d have thrown the XA2 away a long time ago and gone back to the X.
I’d upgrade to the 10iii if I knew it would work on VoLTE where I live. The 10iii isn’t offered by any of the network operators here and of the imported 10iii’s I am aware of none could be made to work on VoLTE using Andoid even when flashed to the EU ROM.
For people like me the likes of the GPS issue with the XA2 and other things like VoLTE support are sadly making Sailfish less and less practical as an OS. Slowly there are becoming too many compromises.
3 Likes
Hey, here seem to be a way to kind of reset the GNSS receiver on the XA2.
I fixed my XA2 and it works well since weeks in various situations now.
I don’t need the very useful @nekron supl patcher any more.
After reverting the installation of the patcher, I saw that stored Satellites are at 0 instead of 20 or 30 in GPSinfo.
As advised, before using the patcher, I backed up the modem settings.
When I restore the backup, the stored satellites are 0.
Then, a fix happens in about 3 minutes (being offline, no WIFI, no GPRS)
Concretely, for the XA2 only:
Backup the modem partitions:
As root:
dd if=/dev/dev_mmcblk0p4 of=/home/defaultuser/some_file_of_your_choice_4
dd if=/dev/dev_mmcblk0p5 of=/home/defaultuser/some_file_of_your_choice_5
Restore the modem partitions:
dd if=/home/defaultuser/some_file_of_your_choice_4 of=/dev/dev_mmcblk0p4
dd if=/home/defaultuser/some_file_of_your_choice_5 of=/dev/dev_mmcblk0p5
Maybe, XA2 users having problems with location can try this?
But the best way IMO still is the hardware fix.
It lovely restored my XA2 location functionality.
1 Like
Are you planning to release your dev-build? On my X10iii changing to supl.google.com:7256 makes no difference, so i assume it is not working. I’m also on the latest Android 11 build.
I think in your configuration file is a typo (it’s port 7276):
# FOR SUPL SUPPORT, set the following
SUPL_HOST=supl.google.com
SUPL_PORT=7276
Sorry, these are exactly the lines i got in my /vendor/etc/gps.conf. But there is no difference to the original settings. Time to first fix is at least 40 seconds.