Editing gps.conf file on Android 11

[Name_not_avail 64]

So although some people have reported their 1x to have decent gps fix performance, it's been rubbish for me. Pretty small issue relative to the rubbish voice calling bug, but annoying nonetheless.

Then I read a recent comment by @claude0001 that it was possible on the old Pro 1 to modify the gps.conf file for improved performance:

He pointed out that changing those settings on LOS 20 would require Magisk scripting, which he had no experience with. So down the rabbit hole I went.

What I found was a script package that will convert the /system files and folders to be writable. Without that conversion, no changes can be made to the gps.conf file, certainly not on my Magisk rooted 1x with v.2.1.5 gms-less Android 11, anyway.

Over at XDA forums this tool caught my eye as being just the ticket, although the dev seems to have been involved in a bunch of angry IP drama and was recently banned from there: https://forum.xda-developers.com/t/closed-universal-systemrw-superrw-feat-makerw-ro2rw-read-only-2-read-write-super-partition-converter-by-lebigmac.4247311/

I don't care about the drama, I just want to mod my gps.conf file. So I found the dev had set up his own website for downloading his script, and off I went: https://lebigmac.2ix.ch/download.php

I used the older version 1.36, (new version is 1.42) and followed the instructions as explained in that XDA thread for "manual installation". I didn't specify any variables or options, just did the basics through adb and let it do its thing.

It seemed to work fine, and generated several files, including super_patched.bin, which I then flashed to the 1x with "fastboot flash super super_patched.bin".

Amazingly it worked like a charm, my system folder is now writable, so I can edit the gps.conf file that @claude0001 discussed.

Don't blame me for any ill effects, like a bricked 1x, or security exposure, or loss of automatic updates (ya, right!) if you follow me down this rabbit hole. I am just reporting something some of you may find iinteresting

I have not yet edited the GPS.conf file, but if I get something that works better than stock, I will report back.

[Hook 3,043]

On Lineage 20, it's a lot easier. Having flashed the Magisk zip in recovery to give me SU when I first set up Lineage, I open Root Explorer and grant it Superuser privileges, mount root as r/w, go to System/vendor/etc/gps.conf. Tapping the file opens it in a text editor, I added #test at  the top of the file  and saved.  Remounted root as r/o and bob's your uncle, as far as I can tell.

No reason  it shouldn't work if you rooted stock, but I never tried so can't say for sure.

[Name_not_avail 64]

Interesting about LOS!

As I have said before, I have two of these boat anchors, one with official LOS and one with 2.1.5 gms-less stock Android. I was only fooling with this on the latter device.

I can say with certainty that in 2.1.5 gms-less, rooted with Magisk, it was not possible to edit and save, or to copy and paste, into that folder. I tried with MixPlorer and various adb efforts as SU.

After running this "lebigmac" tool, there are no obstructions now.

Still rubbish GPS reception, but I can play with gps.conf now, and maybe come up with something that is an improvement.

If so, I will post here.

 

[Hook 3,043]

39 minutes ago, Name_not_avail said:

rooted with Magisk

I'm glad you are happy with the script, but it sounds like you were, in fact, not successfully rooted with Magisk.

[Name_not_avail 64]

11 minutes ago, Hook said:

I'm glad you are happy with the script, but it sounds like you were, in fact, not successfully rooted with Magisk.

I can't speak to that, as every other app that required root seemed to behave normally.

But I have had a Eureka! moment in editing the gps.conf file!

Until now both 1xs could do no better than 0 to a max of 3 satellites ever seen by the device, and neither could ever get a fix. I had all but given up until trying to play with gps.conf.

Initially, the mods proposed by @claude0001 did not help, but then I "unremarked" the line # ACCURACY_THRES=5000

That didn't help either initially, but then I changed the 5000 to 3000, and BANG, the 1x instantly saw the whole constellation of satellites and got a fix for the first time!

I did not even have to reboot. That surprised me, that editing gps.conf would have such an effect in real time, before reboot. Live and learn.

Screen shots attached, and I will post my final gps.conf file too.

Eureka!

 

[Name_not_avail 64]

Here is the full text of the gps.conf file that unlocked the ability of my 1x to get a GPS fix. Thank you, @claude0001

[quote]

XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin

XTRA_VERSION_CHECK=1

# Error Estimate
# _SET = 1
# _CLEAR = 0
ERR_ESTIMATE=0

#NTP server
NTP_SERVER=north-america.pool.ntp.org

#XTRA CA path
XTRA_CA_PATH=/usr/lib/ssl-1.1/certs

 

# DEBUG LEVELS: 0 - none, 1 - Error, 2 - Warning, 3 - Info
#               4 - Debug, 5 - Verbose
# If DEBUG_LEVEL is commented, Android's logging levels will be used
DEBUG_LEVEL = 3

# Intermediate position report, 1=enable, 0=disable
INTERMEDIATE_POS=1

# supl version 1.0
SUPL_VER=0x10000

# Emergency SUPL, 1=enable, 0=disable
#SUPL_ES=1

#Choose PDN for Emergency SUPL
#1 - Use emergency PDN
#0 - Use regular SUPL PDN for Emergency SUPL
#USE_EMERGENCY_PDN_FOR_EMERGENCY_SUPL=0

#SUPL_MODE is a bit mask set in config.xml per carrier by default.
#If it is uncommented here, this value will overwrite the value from
#config.xml.
#MSA=0X2
#MSB=0X1
#SUPL_MODE=

# GPS Capabilities bit mask
# SCHEDULING = 0x01
# MSB = 0x02
# MSA = 0x04
# ON_DEMAND_TIME = 0x10
# default = ON_DEMAND_TIME | MSA | MSB | SCHEDULING
CAPABILITIES=0x17

# Accuracy threshold for intermediate positions
# less accurate positions are ignored, 0 for passing all positions
ACCURACY_THRES=3000

################################
##### AGPS server settings #####
################################

# FOR SUPL SUPPORT, set the following
# SUPL_HOST=supl.host.com or IP
# SUPL_PORT=1234
SUPL_HOST=supl.google.com
SUPL_PORT=7275

# FOR MO SUPL SUPPORT, set the following
# MO_SUPL_HOST=supl.host.com or IP
# MO_SUPL_PORT=1234

# FOR C2K PDE SUPPORT, set the following
# C2K_HOST=c2k.pde.com or IP
# C2K_PORT=1234

# Bitmask of slots that are available
# for write/install to, where 1s indicate writable,
# and the default value is 0 where no slots
# are writable. For example, AGPS_CERT_WRITABLE_MASK
# of b1000001010 makes 3 slots available
# and the remaining 7 slots unwritable.
#AGPS_CERT_WRITABLE_MASK=0

####################################
#  LTE Positioning Profile Settings
####################################
# LPP_PROFILE is a bit mask
# 0: Enable RRLP on LTE(Default)
# 0x1: LPP User Plane
# 0x2: LPP Control Plane
# 0x4: LPP User Plane for NR5G
# 0x8: LPP Control Plane for NR5G
LPP_PROFILE = 2

####################################
#Datum Type
####################################
# 0: WGS-84
# 1: PZ-90
DATUM_TYPE = 0

################################
# EXTRA SETTINGS
################################
# NMEA provider (1=Modem Processor, 0=Application Processor)
NMEA_PROVIDER=0

################################
# NMEA TAG BLOCK GROUPING
################################
# NMEA tag block grouping is only applicable to GSA
# Default is disabled
# 0 - disabled
# 1 - enabled
NMEA_TAG_BLOCK_GROUPING_ENABLED = 0

# Customized NMEA GGA fix quality that can be used to tell
# whether SENSOR contributed to the fix.
#
# When this configuration item is not enabled (set to any value that is not 1),
# GGA fix quality conforms to NMEA standard spec as below:
# PPP/DGNSS/SBAS correction fix w/ or w/o sensor: 2
# RTK fixed fix w/ or w/o sensor: 4
# RTK float fix w/ or w/o sensor: 5
# SPE fix w/ or w/o sensor: 1
# Sensor dead reckoning fix: 6
#
# When this configuration is enabled (set to 1), GGA fix quality
# will be output as below:
# PPP fix w/o sensor: 59,                  w/ sensor: 69
# DGNSS/SBAS correction fix w/o sensor: 2, w/ sensor: 62
# RTK fixed fix w/o sensor: 4,             w/ sensor: 64
# RTK float fix w/o sensor: 5,             w/ sensor: 65,
# SPE fix w/o sensor: 1,               and w/ sensor: 61
# Sensor dead reckoning fix: 6
#
# any value that is not 1 - disabled
# 1 - enabled
CUSTOM_NMEA_GGA_FIX_QUALITY_ENABLED = 0

################################
# NMEA Reporting Rate Config, valid only when NMEA_PROVIDER is set to "0"
################################
# NMEA Reporting Rate
# Set it to "1HZ" for 1Hz NMEA Reporting
# Set it to "NHZ" for NHz NMEA Reporting
#Default : NHZ (overridden by position update rate if set to lower rates)
NMEA_REPORT_RATE=NHZ

# Mark if it is a SGLTE target (1=SGLTE, 0=nonSGLTE)
SGLTE_TARGET=0

##################################################
# Select Positioning Protocol on A-GLONASS system
##################################################
# 0x1: RRC CPlane
# 0x2: RRLP UPlane
# 0x4: LLP Uplane
A_GLONASS_POS_PROTOCOL_SELECT = 0

##################################################
# Select technology for LPPe Control Plane
##################################################
# 0x1: DBH for LPPe CP
# 0x2: WLAN AP Measurements for LPPe CP
# 0x4: SRN AP measurement for CP
# 0x8: Sensor Barometer Measurement LPPe CP
#LPPE_CP_TECHNOLOGY = 0

##################################################
# Select technology for LPPe User Plane
##################################################
# 0x1: DBH for LPPe UP
# 0x2: WLAN AP Measurements for LPPe UP
# 0x4: SRN AP measurement for UP
# 0x8: Sensor Barometer Measurement LPPe UP
#LPPE_UP_TECHNOLOGY = 0

##################################################
# AGPS_CONFIG_INJECT
##################################################
# enable/disable injection of AGPS configurations:
#     SUPL_VER
#     SUPL_HOST
#     SUPL_PORT
#     MO_SUPL_HOST
#     MO_SUPL_PORT
#     C2K_HOST
#     C2K_PORT
#     LPP_PROFILE
#     A_GLONASS_POS_PROTOCOL_SELECT
# 0: disable
# 1: enable
AGPS_CONFIG_INJECT = 1

##################################################
# GNSS settings for automotive use cases
# Configurations in following section are
# specific to automotive use cases, others
# please do not change, keep the default values
##################################################

# AP Coarse Timestamp Uncertainty
##################################################
# default : 10
# AP time stamp uncertainty, until GNSS receiver
# is able to acquire better timing information
AP_TIMESTAMP_UNCERTAINTY = 10

#####################################
# DR_SYNC Pulse Availability
#####################################
# 0 : DR_SYNC pulse not available (default)
# 1 : DR_SYNC pulse available
# This configuration enables the driver to make use
# of PPS events generated by DR_SYNC pulse
# Standard Linux PPS driver needs to be enabled
DR_SYNC_ENABLED = 0

#####################################
# PPS Device name
#####################################
PPS_DEVICENAME = /dev/pps0

#####################################
# Ignore PPS at Startup and after long outage
#####################################
IGNORE_PPS_PULSE_COUNT = 1

#####################################
# Long GNSS RF outage in seconds
#####################################
GNSS_OUTAGE_DURATION = 10

#####################################
# AP Clock Accuracy
#####################################
# Quality of APPS processor clock (in PPM).
# Value specified is used for calculation of
# APPS time stamp uncertainty
AP_CLOCK_PPM = 100

#####################################
# MAX ms difference to detect missing pulse
#####################################
# Specifies time threshold in ms to validate any missing PPS pulses
MISSING_PULSE_TIME_DELTA = 900

#####################################
# Propagation time uncertainty
#####################################
# This settings enables time uncertainty propagation
# logic incase of missing PPS pulse
PROPAGATION_TIME_UNCERTAINTY = 1

#######################################
#  APN / IP Type Configuration
#  APN and IP Type to use for setting
#  up WWAN call.
#  Use below values for IP Type:
#  v4 = 4
#  v6 = 6
#  v4v6 = 10
#######################################
# INTERNET_APN = abc.xyz
# INTERNET_IP_TYPE = 4
# SUPL_APN = abc.xyz
# SUPL_IP_TYPE = 4

#####################################
# Modem type
#####################################
# This setting configures modem type
# (external=0 or internal=1)
# comment out the next line to vote
# for the first modem in the list
MODEM_TYPE = 1

##################################################
# CONSTRAINED TIME UNCERTAINTY MODE
##################################################
# 0 : disabled (default)
# 1 : enabled
# This setting enables GPS engine to keep its time
# uncertainty below the specified constraint
#CONSTRAINED_TIME_UNCERTAINTY_ENABLED = 0

# If constrained time uncertainty mode is enabled,
# this setting specifies the time uncertainty
# threshold that gps engine need to maintain.
# In unit of milli-seconds.
# Default is 0.0 meaning that modem default value
# of time uncertainty threshold will be used.
#CONSTRAINED_TIME_UNCERTAINTY_THRESHOLD = 0.0

# If constrained time uncertainty mode is enabled,
# this setting specifies the power budget that
# gps engine is allowed to spend to maintain the time
# uncertainty.
# Default is 0 meaning that GPS engine is not constained
# by power budget and can spend as much power as needed.
# In unit of 0.1 milli watt second.
#CONSTRAINED_TIME_UNCERTAINTY_ENERGY_BUDGET = 0

##################################################
# POSITION ASSISTED CLOCK ESTIMATOR
##################################################
# 0 : disabled (default)
# 1 : enabled
# This setting enables GPS engine to estimate clock
# bias and drift when the signal from at least 1
# SV is available and the UE�s position is known by
# other position engines.
POSITION_ASSISTED_CLOCK_ESTIMATOR_ENABLED = 1

#####################################
# proxyAppPackageName
#####################################
# This is a string that is sent to the framework
# in nfwNotifyCb callback
PROXY_APP_PACKAGE_NAME = com.google.android.carrierlocation

#####################################
# CP_MTLR_ES
#####################################
# CP MTLR ES, 1=enable, 0=disable
CP_MTLR_ES=0

##################################################
# GNSS_DEPLOYMENT
##################################################
# 0 : Enable QTI GNSS (default)
# 1 : Enable QCSR SS5
# 2 : Enable PDS API
# This setting use to select between QTI GNSS,
# QCSR SS5 hardware receiver, and PDS API.
# By default QTI GNSS receiver is enabled.
# GNSS_DEPLOYMENT = 0

##################################################
## LOG BUFFER CONFIGURATION
##################################################
#LOG_BUFFER_ENABLED, 1=enable, 0=disable
#*_LEVEL_TIME_DEPTH, maximum time depth of level *
#in log buffer, unit is second
#*_LEVEL_MAX_CAPACITY, maximum numbers of level *
#log print sentences in log buffer
LOG_BUFFER_ENABLED = 0
E_LEVEL_TIME_DEPTH = 600
E_LEVEL_MAX_CAPACITY = 50
W_LEVEL_TIME_DEPTH = 500
W_LEVEL_MAX_CAPACITY = 100
I_LEVEL_TIME_DEPTH = 400
I_LEVEL_MAX_CAPACITY = 200
D_LEVEL_TIME_DEPTH = 30
D_LEVEL_MAX_CAPACITY = 300
V_LEVEL_TIME_DEPTH = 200
V_LEVEL_MAX_CAPACITY = 400

##################################################
# Allow buffer diag log packets when diag memory allocation
# fails during boot up time.
##################################################
BUFFER_DIAG_LOGGING = 1

#######################################
#  NTRIP CLIENT LIBRARY NAME
#######################################
# NTRIP_CLIENT_LIB_NAME =

##################################################
# Correction Data Framework settings
# Default values:
# CDFW_SOURCE_PRIORITY_1 = INTERNAL_1 RTCM
# CDFW_INJECT_DATA_INTERVAL = 600000 //10 mins
# CDFW_RTCM_MESSAGE_INTERVAL = 1000  //1 second
#
# If multiple sources coexist on a PL,
# the prorioty sequence can be set by the integer number.
# PRIORITY_1 is higher than PRIORITY_2, for example,
# CDFW_SOURCE_PRIORITY_1 = INTERNAL_1 RTCM
# CDFW_SOURCE_PRIORITY_2 = CV2X RTCM
##################################################

##################################################
# RF LOSS
# The loss in 0.1 dbHz from the C/N0 at the antenna port
# These values must be configured by OEM if not
# supported in QMI LOC message
# There is one entry for each signal type
##################################################
RF_LOSS_GPS = 0
RF_LOSS_GPS_L5 = 0
RF_LOSS_GLO_LEFT = 0
RF_LOSS_GLO_CENTER = 0
RF_LOSS_GLO_RIGHT = 0
RF_LOSS_BDS = 0
RF_LOSS_BDS_B2A = 0
RF_LOSS_GAL = 0
RF_LOSS_GAL_E5 = 0
RF_LOSS_NAVIC = 0

[/quote]

[EskeRahn 5,471]

Interesting! But the leading text for ACCURACY_THRES seems to indicate that you now include some that were previously thought to poor quality signal to use.

Obviously what you got is much better than nothing 😁, but the really interesting question is why the receptions of these are so poor that they go under the default threshold? 🤔

[claude0001 1,352]

3 hours ago, EskeRahn said:

ACCURACY_THRES seems to indicate that you now include some that were previously thought to poor quality signal to use.

That variable has nothing to do with individual signal levels. It works in conjunction with the INTERMEDIATE_POS=1 setting, and causes also the very early iterations of position estimates to be reported to client apps as a "fix".

The unit of ACCURACY_THRESH is meters. Setting it to 3000 means that early position estimates are reported, even if they are still uncertain by 3 km. However, to my knowledge, the variable does not actually influence how the iteration towards the final solution for the position progresses.

To me, the fact that @Name_not_avail saw their phone getting the fix while editing the gps.conf (without reboot!) suggests that the change of ACCURACY_THRESH from 5000 to 3000 did not have any part in getting things working. Rather, I think the other edits enabled AGPS in the first place.  Note that, even with AGPS, getting the initial fix after a reboot can take some time. If the "A" in AGPS is not working for whatever reason (for example if there is no cell tower or internet connection), a phone GPS is often not able to get an initial fix at all - that's perfectly normal and expected.

Edited April 28, 2023 by claude0001

[Name_not_avail 64]

8 hours ago, EskeRahn said:

Interesting! But the leading text for ACCURACY_THRES seems to indicate that you now include some that were previously thought to poor quality signal to use.

Obviously what you got is much better than nothing 😁, but the really interesting question is why the receptions of these are so poor that they go under the default threshold? 🤔

If I can get the previously useless GPS going this way, it makes me wonder whether there is a similar configuration file for the LTE modem, that I could force the 1x to use a SNR that would normally be below its threshhold.

A sort of "perfection is the enemy of the good" configuration, that would stabilize voice calling.

[Name_not_avail 64]

5 hours ago, claude0001 said:

To me, the fact that @Name_not_avail saw their phone getting the fix while editing the gps.conf (without reboot!) suggests that the change of ACCURACY_THRESH from 5000 to 3000 did not have any part in getting things working. Rather, I think the other edits enabled AGPS in the first place.  Note that, even with AGPS, getting the initial fix after a reboot can take some time. If the "A" in AGPS is not working for whatever reason (for example if there is no cell tower or internet connection), a phone GPS is often not able to get an initial fix at all - that's perfectly normal and expected.

This analysis makes good sense. I was surprised that the gps.conf file would be read at any time other than boot.

I now think I let "coincidence imply causation", and the GPS was actually using the gps.conf file as last edited for the prior boot.

[SchattengestaIt 559]

Thank you guys @Name_not_avail and @claude0001 for your suggestions and explanations, they were a huge help.

I edited gps.conf using Root Explorer, which is a file explorer where you can mount the system files to be writable (=changeable). I've tried a few things but it feels that editing the file alone already fixes faulty GPS.

Since my phone still has poor GPS accuracy (which wasn't the case before), I'll try some different settings discussed here and in the other thread of Claude to see if that affects the GPS signal strength.

If I find anything, I'll post it here!