If you don’t accept hardware as one cause, then you are probably able to explain the following:
… and …
I don’t know why this should be a Hardware Problem. I had no GPS issues on my XA2 in the beginning, that first appeard with Sailfish OS 4 and worked well before on Sailfish 3.
Unfortunately not so easy:
I have done lots of tests with four XA2 under SFOS and Android.
I was, and still am, convinced there is also a HW problem.
But
A freshly flashed Android with
-locally installed apps to delete gnss data
-never provided any network nor SIM card
still finds a fix faster than SFOS. (https://forum.sailfishos.org/t/gps-stopped-working/1181/546)
But it was freshly flashed.
Equally, if you flash SFOS, you will get a fast fix in the beginning.
Then, it will degrade. (Several times reported in this thread)
Let’s postpone this debate until someone with a lab can make scientific objective tests!
2 Likes
To contradict myself in stopping the HW/SW debate,
Just to say; I noticed clear improvement in signal reception when cleaning and re-bending the spring-type contacts inside some of the XA2 I opened.
This leaded me to think that the XA2 HW ages badly. Contacts can get loose and, (as not soldered/screwed) get dirty.
New today’s tests with good HW condition devices:
SFOS just flashed:
I just installed Jolla MLS, Storeman, Direc85 Gpsinfo. GPS custom settings ON, ON, OFF, Moz license accepted.
Fix in 4 minutes.
Android just flashed:
No internet connection ever. Installed Gpstest (USB apk copying). No SIM, no BT, no WIFI.
Fix in 3 minutes.
These values are pretty comparable and don’t indicate anything special apart that… @Jolla should help us!
This would be worth it as the XA2 will last 6 more years in France as 3G will be cut in 2028 only and in 2025 in the rest of europe for Orange (source).
2 Likes
Can you provide pictures and or details on what contacts need cleaning/re-tensioning? I’ll give anything a go to improve GPS functionality on the XA2.
I’m still sceptical about hardware being the main issue. These are my reasons;
- Nekron’s suplpatcher made a good improvement
- The time to achieve a lock on can vary from day to day, same atmospheric conditions etc
Neither of these are hardware related. 4 minutes to lock on isn’t all that wonderful in my opinion, though is better than it was before I applied the suplpatcher fix. Even then there are times after I applied the fix that a lock on takes many minutes.
It’s confusing, really.
From what I understood, 4 min. is pretty good for a “cold start”. Some talk about 12.5 minutes to download the sat datas. Am I wrong, maybe? (I didn’t RTFM about SAT technology, I admit)
No warranty it will work though. You might ruin your phone and have no GPS improvement. Backup first, of course.
My daily XA2 is becoming really GPS catastrophic, event with Nekron’s patch now. So I’ll open it and try to “arrange” it too. I’ll make some picture that I could give here.
Edit: I’ll take care not to unplug the battery during the operation so eventual improvements causes don’t mix together.
1 Like
Thanks.
It’s getting late here now, it’s almost tomorrow. 
I’ve just been outside to see how long to get a lock on. I started GPS Info and the app said 34 satellites in view. After more than 4 minutes still wasn’t even a partial fix where the accuracy is several thousand metres and there were no satellites in use.
I did a re-boot then restarted GPS Info. Now there was only 27 satellites in view and within a minute or so I had an accuracy of 9000 metres. It started raining so I didn’t wait for a lock on.
My take away was the re-boot cleared out some old Info and allowed a faster lock on. To be sure of this I do need to do more testing.
1 Like
Forget it ! :–(
However, a reflash would help. Very handy for everyday use ;–)
Yeah, anyway, I’have to find some time to do the whole process. Don’t promise it’ll be ready for your tomorrow, not even mine!
Also, I have to clone the phone to another one first.
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