• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

SGS, glgps, jupiter.xml, and you (how we can control the GPS behavior better)

Search This thread

Da_G

Inactive Senior RD / Moderator Emeritus
Aug 20, 2007
3,320
1,553
Riverside, CA
OK. Here we go for a long post, this is the work that came from disassembling glgps daemon and spending quite a few hours/nights driving around to test things. I also drew on my knowledge of GPS systems and used my Bluetooth GPS as a comparison.

The glgps daemon is responsible for communication between the GPS chipset in the SGS and the android userspace. It pulls settings both from NVRAM and some files in /data/gps and /etc. It uses this information to initalize the GPS system at startup and hold it ready to service location requests. This is where all the tweaking that will make a difference regarding GPS output should take place. (If we can get into NVRAM there's more stuff there too.)

I've attached to this post an update.zip with the latest build of the glgps daemon (/vendor/bin/gpsd from nexus s), relocated to /system/bin/gpsd/glgps_samsungJupiter where it sits on the SGS ROMs. I've also included secgps.conf and jupiter.xml, which i've commented with all possible values I could find disassembling it, and the various effects I observed testing them. I also outfitted the jupiter.xml with the most optimal settings I ran into.

A simple breakdown of what I did was to turn off smoothing and interpolation, by using pedestrian mode and a few new variables available in the nexus s daemon. This yields an output as close to what the GPS chip is seeing as possible. It doesn't necessarily mean that it will be more accurate to reality, only that the firmware and daemon won't filter out results that it thinks don't match what it should see. This behavior is more desireable for me than the GPS chip trying to guess, I can be aware of the variations by looking at the accuracy indicator.

[size=+2]How to get logging out of the glgps daemon so you can observe the effects of tweaks, environmental effects, etc. (A.K.A. lets not stab at the dark!)[/size]

1. Root your device
2. adb shell
3. $ su
#
4. cd /system/bin/gpsd
5. mv glgps_samsungJupiter glgps
6. reboot

Now the glgps daemon won't load at startup. After your device reboots, repeat steps 2-4. Then:

7. cp /system/etc/jupiter.xml /sdcard/
8. adb pull /sdcard/jupiter.xml .
9. edit jupiter.xml on your pc as desired.
10. adb push jupiter.xml /sdcard/
11. adb shell
12. su
13. cd /system/bin/gpsd/
14. ./glgps -c /sdcard/jupiter.xml
alternate command line for activating a "job" in glgps:
11. ./glgps -c /sdcard/jupiter.xml jobname <---------- jobname can be anything defined in your jupiter.xml as a job. Examples from mine: normal cold-single-supl freq-aid-test sim-cold-auto. Some jobs will exit immediately after you stop attempting a fix.


Now the glgps will be loaded, and if bPrintToConsole="true" cLogEnabled="true" are both set, you will start seeing debug output in the console. It will indicate the file it is saving log data to, all initialization information, and display info throughout the time you are connected with adb.

To revert glgps back so that it starts again at bootup as normal, rename glgps back to it's original name. It will then continue to load /system/etc/jupiter.xml on the next reboot as normal. (replace this file with your edited one if you want to continue using the settings)

NOTE: Occaisionally i've had the logging verbosity so high that the GPS cannot get a lock at all. To a certain extent you can work around this by adjusting the "niceness" of the process using the program "renice" (which makes it "meaner" giving it a higher priority over other processes (thus more CPU power to work with) - "renice -20 -p $(pidof glgps)" to make it highest priority.

[size=+2]How do I change what goes in the log file (verbosity)?[/size]

<gll LogPriMask="LOG_FLAG | LOG_FLAG2" LogFacMask="LOG_FLAG | LOG_FLAG2" > control this. Possible LOG_FLAGs are as follows, seperated by a | (pipe)

LOG_EMERG | LOG_ALERT | LOG_CRIT | LOG_ERR | LOG_WARNING | LOG_NOTICE | LOG_INFO | LOG_DEBUG | LOG_GLLAPI | LOG_NMEA | LOG_RAWDATA | LOG_ASIC_IO | LOG_RF_DEBUG | LOG_BBTEST | LOG_DEVCV | LOG_DEVET | LOG_DEVJG | LOG_DEVIA | LOG_DEVKF | LOG_DEVMR | LOG_DEVMS | LOG_DEVSP | LOG_DEVDH | LOG_DEVRA | LOG_DEVRS | LOG_DEVVG | LOG_USR1 | LOG_USR2 | LOG_USR3 | LOG_USR4 | LOG_USR5 | LOG_USR6 | LOG_UNITTEST | LOG_DEFAULT

I've documented some of the logging switches in the jupiter.xml comments. Some of these generate HUGE logs. (large enough to use so much I/O and CPU that glgps can't determine your location at all) - be aware that using full verbosity will also probably result in never getting a fix :)

LOG_DEVVG output: GetSigMeasForClockModel:: SvId 23 Snr 0.000000 mode 1 accepted!
LOG_DEVRA output: GlMeasEng::EnableLowPowerExt(F) GlMechanMgr::UpdateTo12Chan() - Update to 12 full channels AcqMgr::LogAgc() vga_ctrl=0x18 agc=9
LOG_DEVDH output: Raw calculation data (large log)
LOG_DEVMS output: Raw calculation data (large log)
LOG_DEVMR output: #240355D BlndMgr TerminateSearches(2) #240366D BlndMgr(otLstOfSvIdScanNonTrk:686): #240366D BlndMgr(otLstOfSvIdDrillNonTrk:687): #240367D BlndMgr(otSvIdKillLst:691):
LOG_DEVKF output: Fix Data (Lat, Long, Alt, Estimated Accuracy
LOG_DEVIA output: SNR, Latency, Vector, Measurement (large log)
LOG_DEVJG output: Per channel SNR, Latency, Vector, Measurement (large log)
LOG_DEVET output: TCXO calibration data, Doppler calculations (large log)
LOG_DEVCV output: SATAID data, Oscillator data
LOG_DEFAULT output: All on! Realllllllllllllllllly Big!

NOTE: For NMEA output, set LOG_NMEA and also set "GPS Logging" to ON in lbstestmode app. This will generate /sdcard/gps/tracking/NMEA-<DATESTAMP>-<TIMESTAMP>.txt files for each track (from the time you are using the gps til the time you release it) - These .txt files follow the NMEA standard and you can use them to generate tracklogs or do other nifty GPS related things (check out the PC program gpsbabel, for example)

NOTE2: If you want to restart the glgps daemon on the fly, to load new jupiter.xml settings for testing, open a concurrent adb shell connection in root, and type: "kill $(pidof glgps)" this will kill the glgps daemon in the other shell window and you can restart it with a new jupiter.xml :)

[size=+2]Sample output from logging:[/size]

Code:
H187754I OpenFifo: Opened "/data/gps/glgpsctrl"
H187765I Certificate Path : /system/bin/gpsd/ 
H187765I TLS enable = 1 
H187768I Certificate Path : /system/bin/gpsd/ 
H187768I TLS enable = 1 
H187768I LBS_A: starting event handler
H187768I LBS_I: ASN1 manager:  1237d4, 2044 bytes
H187768I LBS_I: Encode/decode buffer:  123fd4, 6120 bytes
H187768I LBS_I: Dynamic memory buffer: 1257bc, 24480 bytes
H187769I LBS_I: @(#)Broadcom LBS ver. 2.1.0.0 86303, 2010/Nov/07, 13:12:55
H187769I LBS_I: API: gllbs_init(32768)
H187769I LBS_I: CB: nv_open
H187769I LBS_I: CB: nv_read
H187769I LBS_I: CB: nv_close
H187769I LBS_I: 3 cells loaded

Take a look at my provided jupiter.xml for more info on the possible parameters. I've documented it as I went along with comments. I'll update the 2nd post here with more info soon.

[size=+3]Attached file[/size]: CWM update.zip with new glgps daemon from nexus s, jupiter.xml with pedestrian mode settings
NOTE: CWM update.zips will not work in eclair, you must change the following:
Code:
       gpioNStdbyPath="/sys/class/sec/gps/GPS_PWR_EN/value"

       gpioNResetPath="/sys/class/sec/gps/GPS_nRST/value"
to:
Code:
       gpioNStdbyPath="/sys/class/gpio/gpio121/value"
       gpioNResetPath="/sys/class/gpio/gpio120/value"
[size=+2]Notable Settings[/size]:

<hal acEEDir="/data/gps/" acEEFileName="xtra.bin" /> : Defines an Extended Ephemeris file for the glgps daemon to load for AGPS data. The drivers normally do not appear to download this file successfully and the daemon says it is corrupt.

<hal bPrintToConsole="true" cLogEnabled="false acLogDirectory="/sdcard/gps/log"" /> : Determines of the logging output should be printed to console and/or to a text file. The text file will be placed in the directory provided and named gl-<TIMESTAMP>.txt. Inside will be the logging output at the verbosity you defined using LOG_FLAGs in <gll LogPriMask="LOG_FLAG | LOG_FLAG2" LogFacMask="LOG_FLAG | LOG_FLAG2" >

<hal arp-supl-enable="true" arp-supl-cap-msb="true" arp-supl-cap-msa="false" arp-supl-cap-ecid="true" arp-supl-reaiding-time-sec = "600" /> : These settings tell the glgps daemon what the SUPL AGPS server provided next is capable of. MS-B means Mobile Station Based, MS-A is Mobile Station Assisted, ECID is unknown. Reaiding time defines the minimum amount of time before attempting to re-inject AGPS data to keep the fix tight in seconds.

<hal acSuplServer="h-slp.mnc410.mcc310.pub.3gppnetwork.org" SuplPort="7275" tlsCertPath="/system/bin/gpsd/" /> : This defines the AGPS server to use for SUPL data (only used if enhanced-assisted="true") - if cp-enhanced-assisted="true" is set, will use the providers control plane rather than normal packet data to access SUPL server. Note that the provided SUPL server is AT&T's SUPL server, which is only accessible within their network. Use google's if you are not on AT&T's network. tlsCertPath defines the location in the filesystem to search for SSL certificates used when connecting to the AGPS server. Most ROMs come with AT&T's, if yours doesn't have it, you'll need to add it for the connection to work.

<hal LbsEnable="true" LbsLocal="true" LbsServer="bcmls2.glpals.com" LbsPort="7275" LbsSyncTimeSec = "60" LbsSyncLto="true" LbsSyncCells="true" /> : These settings tell the glgps daemon to use this server for LBS aiding (Location Based Services.) When LbsLocal is true, the glgps daemon will record all cell sites it sees and your reported GPS location at the time. Any future fix attempt will use these coordinates to seed your fix if the current cell tower you are on matches one the glgps daemon has seen before. This data is stored by default in /data/gps/, so note that it will get erased if you clear the /data partition. It might be useful for frequent flashers to modify the jupiter.xml to store data in /sdard/gps/ or some other less volatile location instead, so the local cell db gets a chance to populate.

<gll CNoSmoothEnable="true" > : This disables some of the glgps daemon's internal smoothing algorithms, makes the GPS a little more accurate to its readings. POSSIBLE VALUES: true false

<gll DynMode="DYN_PEDESTRIAN" > : Defaults to automatic mode which makes the glgps daemon determine on the fly if you are on foot or in a vehicle. This affects the interpolation algorithms used (In GPS land, pedestrian mode means the GPS will report each fix it gets, usually 1 per second.) Vehicle mode will not report movement under a certain amount (usually 3-5 meters) in order to keep the indicator more "stable" POSSIBLE VALUES: DYN_AUTOMATIC DYN_PEDESTRIAN DYN_VEHICLE

<gll RfAtt="GL_RF_ATT_DISABLED" > : I haven't tested this enough to be sure if the chip actually has a built in attenuator you can adjust with this parameter, but if so, it goes all the way up to 18dB. The function of an attenuator is to lower the overall incoming signal in order to better compensate for enviornmental noise. Cordless phones, WiFi, Microwaves, and any number of devices work on frequencies close enough to GPS to cause interference. Assuming there is an attenuation circuit present and it's controllable via this parameter, it will yield better performance for various people in various situations. Requires testing :)

<gll RfType="GL_RF_4751_DANUBE" > : GL_RF_4751_BLUEFIN GL_RF_4751_DANUBE GL_RF_4751_DANUBE_EXT_LNA are values that I have tested working with our GPS. _EXT_LNA comes default on Nexus S, DANUBE default on ours. BLUEFIN I haven't seen set anywhere, but does work. Danube and Bluefin are likely different revisions of the 4751 chipset.

[size=+2]Other settings not found in jupiter.xml[/size]

glgps also seems to heed what the user has set in Settings -> Location and Security, for "Use wireless networks" and "Use sensor aiding". Wireless networks causes nearby WiFi access point info to be used for a faster first fix, and Use sensor aiding attempts to save power by putting the GPS in low power mode when it sees you moving in a straight line, and shutting off entirely when the accelerometer detects that the phone is stationary. This can cause issues when the compass or accelerometer are providing false values (due to interference, mismatched kernel, etc.)

Also, glgps reads settings from NVRAM that are set by the lbstestmode app. These settings are also stored in secgps.conf, but the settings in NVRAM do NOT necessarily match up. Make sure you set your lbstestmode to "standalone" operation so that Android relies on the glgps daemon for AGPS support. My settings are:

Code:
Session Type: Tracking
Test Mode: S/W
Operation Mode: Standalone
Start Mode: Hot Start
GPS Plus: ON
Dynamic Accuracy: ON
Accuracy: 80
GPS Logging: OFF (use ON and LOG_NMEA to get NMEA logs)
Server FQDN Type: Custom Config
Server: h-slp.mnc410.mcc310.pub.3gppnetwork.org <MATCH THIS WITH YOUR JUPITER.XML>
Server Port: 7275 <MATCH THIS WITH YOUR JUPITER.XML>
SUPL Secure Socket: ON <VARIES WITH SERVER, GOOGLE IS OFF>
AGPS Mode: SUPL <OR CONTROL PLANE, MATCH WITH JUPITER.XML>
 

Attachments

  • dagnarf-gps-tweak-att.zip
    635.4 KB · Views: 2,880
  • dagnarf-gps-tweak-google.zip
    635.4 KB · Views: 4,618
  • dagnarf-gps-tweak-control-plane.zip
    635.4 KB · Views: 2,082
Last edited:

Da_G

Inactive Senior RD / Moderator Emeritus
Aug 20, 2007
3,320
1,553
Riverside, CA
[SIZE=+3]To summarize the problem i've identified with our GPS so far:[/SIZE]

  • AGPS was not properly deployed at the factory, or in any of the updates pushed to the Captivate. Only Control Plane AGPS mode is properly configured, but not active by default. As a result, out of the box, the phone is essentially always in standalone mode regardless of settings (without a modified jupiter.xml)
  • The GPS chip appears to be receiving some kind of interference from other component(s) on the mainboard. This appears to only manifest itself when the handset is under a heavy usage pattern (such as G Maps/G My Tracks plotting your position, scrolling the map, using cell data, reading gps). This interference is causing the GPS chip to have a major drop in performance. I suspect the phones that don't experience this have an exceptional unit that can perform regardless of this interference (I suspect if they tested with raw signal strength showing, the drop would show)
  • The glgps daemon attempts to do post processing on the data received in the stream from the GPS chip. Because the data received is generally already incorrect, this further compounds the issue. My jupiter.xml already has these post processing algorithms disabled.

That drop in GPS signal due to interference is the kicker. I haven't yet narrowed down the exact cause of the interference, but suspects are:

1.) Cellular Radio - if this is the case, testing with wifi on and the cell radio off should yield a more desireable result (although hard to test while moving in that situation without another device to tether to for mobile data)

2.) CPU Usage on Host CPU - I don't think this is the case. The only CPU intensive thing that runs on the Host CPU is the glgps daemon, and if this were the case, "renice -20 -p $(pidof glgps_samsungJupiter)" would fix the problem. It does not.

3.) GPU usage - This is a possibility.

4.) CPU usage on baseband CPU - There are also some GPS functions handled in the baseband. I doubt this is the cause but possible.

5.) EM leakage from other system components - I'm leaning towards this right now. I'll have to open up the captivate and throw an EM shield over the GPS chip and see what the results are.
 
Last edited:

bamonkey

Senior Member
Jan 21, 2010
510
168
OK
Been watching the progress on this lately and have to say big props on all the research. Will try it out and see how it goes

Sent from my SAMSUNG-SGH-I897 using XDA App
 

Da_G

Inactive Senior RD / Moderator Emeritus
Aug 20, 2007
3,320
1,553
Riverside, CA
Yes, the attached zip is a CWM zip. Note that these settings are only what I found optimum, and as this is the development forum, I encourage you to tinker with the possible values (commented inside the jupiter.xml) to figure out what works best for you :)
 
  • Like
Reactions: Greg767

bamonkey

Senior Member
Jan 21, 2010
510
168
OK
Just walked from inside heavy building to outside...after 10 Seconds I had a full lock while walking showing 5m distance...holy [email protected]$#& s&$#$ that is already amazing. I'll use it driving home after work....mad props

Sent from my SAMSUNG-SGH-I897 using XDA App
 

1randomtask

Senior Member
Sep 28, 2010
91
1
Orange, NSW
<hal acSuplServer="h-slp.mnc410.mcc310.pub.3gppnetwork.org" SuplPort="7275" tlsCertPath="/system/bin/gpsd/" /> : This defines the AGPS server to use for SUPL data (only used if enhanced-assisted="true") - if cp-enhanced-assisted="true" is set, will use the providers control plane rather than normal packet data to access SUPL server. Note that the provided SUPL server is AT&T's SUPL server, which is only accessible within their network. Use google's if you are not on AT&T's network. tlsCertPath defines the location in the filesystem to search for SSL certificates used when connecting to the AGPS server. Most ROMs come with AT&T's, if yours doesn't have it, you'll need to add it for the connection to work.

So can I change this before flashing the rom? if so, how? is it possible you can push a "AT&T" version and a "Google" version?
 

Da_G

Inactive Senior RD / Moderator Emeritus
Aug 20, 2007
3,320
1,553
Riverside, CA
Sure, you can edit the file /system/etc/jupiter.xml in the zip before flashing it to the device. I'll make one with settings for google and control plane and post them in a sec.
 

koreancanuck

Senior Member
Feb 11, 2010
869
64
Vancouver
:( I would soooo try this out right now if I was not overseas atm. It'll be 3 weeks before I can try this out but to Da_G thank you for doing something that Samsung should be working on the most! :)
 

Da_G

Inactive Senior RD / Moderator Emeritus
Aug 20, 2007
3,320
1,553
Riverside, CA
Ok, updated first post with AT&T, Google, and Control Plane versions. Control Plane should work on any cellular provider (if they have implemented it, which all should have)

Regarding changing the NTP server that can't hurt, but should only affect the TTFF (Time To First Fix) as it should sync up to the GPS satellites after that.
 

1randomtask

Senior Member
Sep 28, 2010
91
1
Orange, NSW
Ok, updated first post with AT&T, Google, and Control Plane versions. Control Plane should work on any cellular provider (if they have implemented it, which all should have)

Is there any value of Control Plane vs Google SUPL? should one be "better" than the other?

Regarding changing the NTP server that can't hurt, but should only affect the TTFF (Time To First Fix) as it should sync up to the GPS satellites after that.

Cool. Didn't quite understand how it was used in relation to GPS.

Is there a rough laymans terms of why having WIFI on (and connected to an AP) leads to far more accurate results faster, when its a new AP that i've not connected to before? I was thinking it might have something to do with Time Servers and Latency (as latency to an NTP would be *dramatically* lower over Wifi VS any form of cellular comms) - given your explanation re NTP, I don't think thats the case now.

It certainly can't be "google knows where the AP's are", given that I work in IT Services and create/delete/move AP's all the time.
 

Da_G

Inactive Senior RD / Moderator Emeritus
Aug 20, 2007
3,320
1,553
Riverside, CA
In the case of AGPS, your current CellID, along with MNC and MCC are sent to the database (your cell providers control plane server, google, or any other SUPL server provided in jupiter.xml) in order to obtain approximate Latitude/Longitude for an initial fix. (due to the nature of GPS, having an initial "guess" as to your current location helps to seed a faster initial fix, which is the main function of AGPS) The reason your Cellular Provider's database could be better is that it is more likely to be up to date than googles. But of course this varies! Some providers don't even maintain a CP server for AGPS.

The reason WiFi helps the time to first fix is similar. Google actually does have your phone report its visible APs (by MAC address) and current best-guess location to its servers. Everyone else's does this too (assuming they have the wireless tick box on) - This allows them to build a large database with which to seed AGPS from. You may have noticed the first time you turn on "Use wireless networks" in Settings - Location and Security, you get a boilerplate disclaimer about allowing google to collect anonymous connection data. That's what this is for :)

Adding some info to the first post about "Use sensor aiding" and "Use wireless networks" now.
 
Last edited:
  • Like
Reactions: Rred

Mac11700

Senior Member
Aug 16, 2010
1,367
163
St.Louis
In the case of AGPS, your current CellID, along with MNC and MCC are sent to the database (your cell providers control plane server, google, or any other SUPL server provided in jupiter.xml) in order to obtain approximate Latitude/Longitude for an initial fix. (due to the nature of GPS, having an initial "guess" as to your current location helps to seed a faster initial fix, which is the main function of AGPS) The reason your Cellular Provider's database could be better is that it is more likely to be up to date than googles. But of course this varies! Some providers don't even maintain a CP server for AGPS.

The reason WiFi helps the time to first fix is similar. Google actually does have your phone report its visible APs (by MAC address) and current best-guess location to its servers. Everyone else's does this too (assuming they have the wireless tick box on) - This allows them to build a large database with which to seed AGPS from. You may have noticed the first time you turn on "Use wireless networks" in Settings - Location and Security, you get a boilerplate disclaimer about allowing google to collect anonymous connection data. That's what this is for :)

Adding some info to the first post about "Use sensor aiding" and "Use wireless networks" now.

Pardon my ignorance...but does this mean after the initial boot with google it is no longer needed to have wi-fi on to get good locks ?

Mac
 

Da_G

Inactive Senior RD / Moderator Emeritus
Aug 20, 2007
3,320
1,553
Riverside, CA
With stock settings (JF6/JH7), all the aiding data was not saved, but with the proper settings in jupiter.xml, aiding data should be saved into /data/gps and NVRAM so that the GPS chip can use it on the next fixes. This data is only good for a short period of time (hours to days) so unless you are using the GPS that frequently, WiFi on is still beneficial. You only need to have it on at the time you get the first fix, after that you can shut it off.
 

Mac11700

Senior Member
Aug 16, 2010
1,367
163
St.Louis
With stock settings (JF6/JH7), all the aiding data was not saved, but with the proper settings in jupiter.xml, aiding data should be saved into /data/gps and NVRAM so that the GPS chip can use it on the next fixes. This data is only good for a short period of time (hours to days) so unless you are using the GPS that frequently, WiFi on is still beneficial. You only need to have it on at the time you get the first fix, after that you can shut it off.

Cool...thanks for that detailed explaination

Mac
 

Top Liked Posts

  • There are no posts matching your filters.
  • 64
    OK. Here we go for a long post, this is the work that came from disassembling glgps daemon and spending quite a few hours/nights driving around to test things. I also drew on my knowledge of GPS systems and used my Bluetooth GPS as a comparison.

    The glgps daemon is responsible for communication between the GPS chipset in the SGS and the android userspace. It pulls settings both from NVRAM and some files in /data/gps and /etc. It uses this information to initalize the GPS system at startup and hold it ready to service location requests. This is where all the tweaking that will make a difference regarding GPS output should take place. (If we can get into NVRAM there's more stuff there too.)

    I've attached to this post an update.zip with the latest build of the glgps daemon (/vendor/bin/gpsd from nexus s), relocated to /system/bin/gpsd/glgps_samsungJupiter where it sits on the SGS ROMs. I've also included secgps.conf and jupiter.xml, which i've commented with all possible values I could find disassembling it, and the various effects I observed testing them. I also outfitted the jupiter.xml with the most optimal settings I ran into.

    A simple breakdown of what I did was to turn off smoothing and interpolation, by using pedestrian mode and a few new variables available in the nexus s daemon. This yields an output as close to what the GPS chip is seeing as possible. It doesn't necessarily mean that it will be more accurate to reality, only that the firmware and daemon won't filter out results that it thinks don't match what it should see. This behavior is more desireable for me than the GPS chip trying to guess, I can be aware of the variations by looking at the accuracy indicator.

    [size=+2]How to get logging out of the glgps daemon so you can observe the effects of tweaks, environmental effects, etc. (A.K.A. lets not stab at the dark!)[/size]

    1. Root your device
    2. adb shell
    3. $ su
    #
    4. cd /system/bin/gpsd
    5. mv glgps_samsungJupiter glgps
    6. reboot

    Now the glgps daemon won't load at startup. After your device reboots, repeat steps 2-4. Then:

    7. cp /system/etc/jupiter.xml /sdcard/
    8. adb pull /sdcard/jupiter.xml .
    9. edit jupiter.xml on your pc as desired.
    10. adb push jupiter.xml /sdcard/
    11. adb shell
    12. su
    13. cd /system/bin/gpsd/
    14. ./glgps -c /sdcard/jupiter.xml
    alternate command line for activating a "job" in glgps:
    11. ./glgps -c /sdcard/jupiter.xml jobname <---------- jobname can be anything defined in your jupiter.xml as a job. Examples from mine: normal cold-single-supl freq-aid-test sim-cold-auto. Some jobs will exit immediately after you stop attempting a fix.


    Now the glgps will be loaded, and if bPrintToConsole="true" cLogEnabled="true" are both set, you will start seeing debug output in the console. It will indicate the file it is saving log data to, all initialization information, and display info throughout the time you are connected with adb.

    To revert glgps back so that it starts again at bootup as normal, rename glgps back to it's original name. It will then continue to load /system/etc/jupiter.xml on the next reboot as normal. (replace this file with your edited one if you want to continue using the settings)

    NOTE: Occaisionally i've had the logging verbosity so high that the GPS cannot get a lock at all. To a certain extent you can work around this by adjusting the "niceness" of the process using the program "renice" (which makes it "meaner" giving it a higher priority over other processes (thus more CPU power to work with) - "renice -20 -p $(pidof glgps)" to make it highest priority.

    [size=+2]How do I change what goes in the log file (verbosity)?[/size]

    <gll LogPriMask="LOG_FLAG | LOG_FLAG2" LogFacMask="LOG_FLAG | LOG_FLAG2" > control this. Possible LOG_FLAGs are as follows, seperated by a | (pipe)

    LOG_EMERG | LOG_ALERT | LOG_CRIT | LOG_ERR | LOG_WARNING | LOG_NOTICE | LOG_INFO | LOG_DEBUG | LOG_GLLAPI | LOG_NMEA | LOG_RAWDATA | LOG_ASIC_IO | LOG_RF_DEBUG | LOG_BBTEST | LOG_DEVCV | LOG_DEVET | LOG_DEVJG | LOG_DEVIA | LOG_DEVKF | LOG_DEVMR | LOG_DEVMS | LOG_DEVSP | LOG_DEVDH | LOG_DEVRA | LOG_DEVRS | LOG_DEVVG | LOG_USR1 | LOG_USR2 | LOG_USR3 | LOG_USR4 | LOG_USR5 | LOG_USR6 | LOG_UNITTEST | LOG_DEFAULT

    I've documented some of the logging switches in the jupiter.xml comments. Some of these generate HUGE logs. (large enough to use so much I/O and CPU that glgps can't determine your location at all) - be aware that using full verbosity will also probably result in never getting a fix :)

    LOG_DEVVG output: GetSigMeasForClockModel:: SvId 23 Snr 0.000000 mode 1 accepted!
    LOG_DEVRA output: GlMeasEng::EnableLowPowerExt(F) GlMechanMgr::UpdateTo12Chan() - Update to 12 full channels AcqMgr::LogAgc() vga_ctrl=0x18 agc=9
    LOG_DEVDH output: Raw calculation data (large log)
    LOG_DEVMS output: Raw calculation data (large log)
    LOG_DEVMR output: #240355D BlndMgr TerminateSearches(2) #240366D BlndMgr(otLstOfSvIdScanNonTrk:686): #240366D BlndMgr(otLstOfSvIdDrillNonTrk:687): #240367D BlndMgr(otSvIdKillLst:691):
    LOG_DEVKF output: Fix Data (Lat, Long, Alt, Estimated Accuracy
    LOG_DEVIA output: SNR, Latency, Vector, Measurement (large log)
    LOG_DEVJG output: Per channel SNR, Latency, Vector, Measurement (large log)
    LOG_DEVET output: TCXO calibration data, Doppler calculations (large log)
    LOG_DEVCV output: SATAID data, Oscillator data
    LOG_DEFAULT output: All on! Realllllllllllllllllly Big!

    NOTE: For NMEA output, set LOG_NMEA and also set "GPS Logging" to ON in lbstestmode app. This will generate /sdcard/gps/tracking/NMEA-<DATESTAMP>-<TIMESTAMP>.txt files for each track (from the time you are using the gps til the time you release it) - These .txt files follow the NMEA standard and you can use them to generate tracklogs or do other nifty GPS related things (check out the PC program gpsbabel, for example)

    NOTE2: If you want to restart the glgps daemon on the fly, to load new jupiter.xml settings for testing, open a concurrent adb shell connection in root, and type: "kill $(pidof glgps)" this will kill the glgps daemon in the other shell window and you can restart it with a new jupiter.xml :)

    [size=+2]Sample output from logging:[/size]

    Code:
    H187754I OpenFifo: Opened "/data/gps/glgpsctrl"
    H187765I Certificate Path : /system/bin/gpsd/ 
    H187765I TLS enable = 1 
    H187768I Certificate Path : /system/bin/gpsd/ 
    H187768I TLS enable = 1 
    H187768I LBS_A: starting event handler
    H187768I LBS_I: ASN1 manager:  1237d4, 2044 bytes
    H187768I LBS_I: Encode/decode buffer:  123fd4, 6120 bytes
    H187768I LBS_I: Dynamic memory buffer: 1257bc, 24480 bytes
    H187769I LBS_I: @(#)Broadcom LBS ver. 2.1.0.0 86303, 2010/Nov/07, 13:12:55
    H187769I LBS_I: API: gllbs_init(32768)
    H187769I LBS_I: CB: nv_open
    H187769I LBS_I: CB: nv_read
    H187769I LBS_I: CB: nv_close
    H187769I LBS_I: 3 cells loaded

    Take a look at my provided jupiter.xml for more info on the possible parameters. I've documented it as I went along with comments. I'll update the 2nd post here with more info soon.

    [size=+3]Attached file[/size]: CWM update.zip with new glgps daemon from nexus s, jupiter.xml with pedestrian mode settings
    NOTE: CWM update.zips will not work in eclair, you must change the following:
    Code:
           gpioNStdbyPath="/sys/class/sec/gps/GPS_PWR_EN/value"
    
           gpioNResetPath="/sys/class/sec/gps/GPS_nRST/value"
    to:
    Code:
           gpioNStdbyPath="/sys/class/gpio/gpio121/value"
           gpioNResetPath="/sys/class/gpio/gpio120/value"
    [size=+2]Notable Settings[/size]:

    <hal acEEDir="/data/gps/" acEEFileName="xtra.bin" /> : Defines an Extended Ephemeris file for the glgps daemon to load for AGPS data. The drivers normally do not appear to download this file successfully and the daemon says it is corrupt.

    <hal bPrintToConsole="true" cLogEnabled="false acLogDirectory="/sdcard/gps/log"" /> : Determines of the logging output should be printed to console and/or to a text file. The text file will be placed in the directory provided and named gl-<TIMESTAMP>.txt. Inside will be the logging output at the verbosity you defined using LOG_FLAGs in <gll LogPriMask="LOG_FLAG | LOG_FLAG2" LogFacMask="LOG_FLAG | LOG_FLAG2" >

    <hal arp-supl-enable="true" arp-supl-cap-msb="true" arp-supl-cap-msa="false" arp-supl-cap-ecid="true" arp-supl-reaiding-time-sec = "600" /> : These settings tell the glgps daemon what the SUPL AGPS server provided next is capable of. MS-B means Mobile Station Based, MS-A is Mobile Station Assisted, ECID is unknown. Reaiding time defines the minimum amount of time before attempting to re-inject AGPS data to keep the fix tight in seconds.

    <hal acSuplServer="h-slp.mnc410.mcc310.pub.3gppnetwork.org" SuplPort="7275" tlsCertPath="/system/bin/gpsd/" /> : This defines the AGPS server to use for SUPL data (only used if enhanced-assisted="true") - if cp-enhanced-assisted="true" is set, will use the providers control plane rather than normal packet data to access SUPL server. Note that the provided SUPL server is AT&T's SUPL server, which is only accessible within their network. Use google's if you are not on AT&T's network. tlsCertPath defines the location in the filesystem to search for SSL certificates used when connecting to the AGPS server. Most ROMs come with AT&T's, if yours doesn't have it, you'll need to add it for the connection to work.

    <hal LbsEnable="true" LbsLocal="true" LbsServer="bcmls2.glpals.com" LbsPort="7275" LbsSyncTimeSec = "60" LbsSyncLto="true" LbsSyncCells="true" /> : These settings tell the glgps daemon to use this server for LBS aiding (Location Based Services.) When LbsLocal is true, the glgps daemon will record all cell sites it sees and your reported GPS location at the time. Any future fix attempt will use these coordinates to seed your fix if the current cell tower you are on matches one the glgps daemon has seen before. This data is stored by default in /data/gps/, so note that it will get erased if you clear the /data partition. It might be useful for frequent flashers to modify the jupiter.xml to store data in /sdard/gps/ or some other less volatile location instead, so the local cell db gets a chance to populate.

    <gll CNoSmoothEnable="true" > : This disables some of the glgps daemon's internal smoothing algorithms, makes the GPS a little more accurate to its readings. POSSIBLE VALUES: true false

    <gll DynMode="DYN_PEDESTRIAN" > : Defaults to automatic mode which makes the glgps daemon determine on the fly if you are on foot or in a vehicle. This affects the interpolation algorithms used (In GPS land, pedestrian mode means the GPS will report each fix it gets, usually 1 per second.) Vehicle mode will not report movement under a certain amount (usually 3-5 meters) in order to keep the indicator more "stable" POSSIBLE VALUES: DYN_AUTOMATIC DYN_PEDESTRIAN DYN_VEHICLE

    <gll RfAtt="GL_RF_ATT_DISABLED" > : I haven't tested this enough to be sure if the chip actually has a built in attenuator you can adjust with this parameter, but if so, it goes all the way up to 18dB. The function of an attenuator is to lower the overall incoming signal in order to better compensate for enviornmental noise. Cordless phones, WiFi, Microwaves, and any number of devices work on frequencies close enough to GPS to cause interference. Assuming there is an attenuation circuit present and it's controllable via this parameter, it will yield better performance for various people in various situations. Requires testing :)

    <gll RfType="GL_RF_4751_DANUBE" > : GL_RF_4751_BLUEFIN GL_RF_4751_DANUBE GL_RF_4751_DANUBE_EXT_LNA are values that I have tested working with our GPS. _EXT_LNA comes default on Nexus S, DANUBE default on ours. BLUEFIN I haven't seen set anywhere, but does work. Danube and Bluefin are likely different revisions of the 4751 chipset.

    [size=+2]Other settings not found in jupiter.xml[/size]

    glgps also seems to heed what the user has set in Settings -> Location and Security, for "Use wireless networks" and "Use sensor aiding". Wireless networks causes nearby WiFi access point info to be used for a faster first fix, and Use sensor aiding attempts to save power by putting the GPS in low power mode when it sees you moving in a straight line, and shutting off entirely when the accelerometer detects that the phone is stationary. This can cause issues when the compass or accelerometer are providing false values (due to interference, mismatched kernel, etc.)

    Also, glgps reads settings from NVRAM that are set by the lbstestmode app. These settings are also stored in secgps.conf, but the settings in NVRAM do NOT necessarily match up. Make sure you set your lbstestmode to "standalone" operation so that Android relies on the glgps daemon for AGPS support. My settings are:

    Code:
    Session Type: Tracking
    Test Mode: S/W
    Operation Mode: Standalone
    Start Mode: Hot Start
    GPS Plus: ON
    Dynamic Accuracy: ON
    Accuracy: 80
    GPS Logging: OFF (use ON and LOG_NMEA to get NMEA logs)
    Server FQDN Type: Custom Config
    Server: h-slp.mnc410.mcc310.pub.3gppnetwork.org <MATCH THIS WITH YOUR JUPITER.XML>
    Server Port: 7275 <MATCH THIS WITH YOUR JUPITER.XML>
    SUPL Secure Socket: ON <VARIES WITH SERVER, GOOGLE IS OFF>
    AGPS Mode: SUPL <OR CONTROL PLANE, MATCH WITH JUPITER.XML>
    19
    [SIZE=+3]To summarize the problem i've identified with our GPS so far:[/SIZE]

    • AGPS was not properly deployed at the factory, or in any of the updates pushed to the Captivate. Only Control Plane AGPS mode is properly configured, but not active by default. As a result, out of the box, the phone is essentially always in standalone mode regardless of settings (without a modified jupiter.xml)
    • The GPS chip appears to be receiving some kind of interference from other component(s) on the mainboard. This appears to only manifest itself when the handset is under a heavy usage pattern (such as G Maps/G My Tracks plotting your position, scrolling the map, using cell data, reading gps). This interference is causing the GPS chip to have a major drop in performance. I suspect the phones that don't experience this have an exceptional unit that can perform regardless of this interference (I suspect if they tested with raw signal strength showing, the drop would show)
    • The glgps daemon attempts to do post processing on the data received in the stream from the GPS chip. Because the data received is generally already incorrect, this further compounds the issue. My jupiter.xml already has these post processing algorithms disabled.

    That drop in GPS signal due to interference is the kicker. I haven't yet narrowed down the exact cause of the interference, but suspects are:

    1.) Cellular Radio - if this is the case, testing with wifi on and the cell radio off should yield a more desireable result (although hard to test while moving in that situation without another device to tether to for mobile data)

    2.) CPU Usage on Host CPU - I don't think this is the case. The only CPU intensive thing that runs on the Host CPU is the glgps daemon, and if this were the case, "renice -20 -p $(pidof glgps_samsungJupiter)" would fix the problem. It does not.

    3.) GPU usage - This is a possibility.

    4.) CPU usage on baseband CPU - There are also some GPS functions handled in the baseband. I doubt this is the cause but possible.

    5.) EM leakage from other system components - I'm leaning towards this right now. I'll have to open up the captivate and throw an EM shield over the GPS chip and see what the results are.
    6
    reserved for more two
    3
    Since the theme of this thread is hard data vs anecdotal, I ran some tests to try and quantify how much signal degradation might be occuring due to the back cover properties. To do this I ran a series of five one-minute tests with the phone in the same location, first with the cover on, then with the cover off. Using lbs test mode I first deleted gps data, then manually recorded the highest signal strength I saw for the next 60 seconds.

    The results were as follows:

    Test 1
    Cover On – High Signal Avg 25dBHz
    Cover Off – High Signal Avg 30 dBHz
    Test 1 difference 5 dBHz

    Test 2
    Cover On – High Signal Avg 18dBHz
    Cover Off – High Signal Avg 32dBHz
    Test 2 difference 14 dBHz

    Test 3
    Cover On – HS Avg 30 dBHz
    Cover Off – HS Avg 32dBHz
    Test 3 difference 2 dBHz

    Test 4
    Cover On – HS Avg 29 dBHz
    Cover Off – HS Avg 31 dBHz
    Test 4 difference 2 dbHz

    Test 5
    Cover On – HS Avg 29 dBHz
    Cover Off – HS Avg 32 dBHz
    Test 5 difference 3 dBHz

    Test 1 thru Test 5 average degradation 5.4 dBHz.

    While the magnitude of the signal loss varied, the direction was very consistent. While doing this I also observed improved signal strength on the cell radio but do not have numbers to share on those.
    3
    @TheSopranos16:

    I haven't tested with the proper equipment yet to verify this, but in the debug output you can see that the TCXO (Temperature Controlled Crystal Oscillator) used as a clock source for the GPS chipset does not calibrate to the proper value (a normal TCXO will always kick back the same frequency, +/- a small variance) - our TCXO seems to be more sensitive than it should be, it's frequency output drifts over time. As GPS is an entirely time based function (your location is calculated by determining the time it takes for each signal to reach you, and doing some math to correlate that with with the location of each satellite)

    For several of the frequency plans glgps can be initialized with, there is an added _UNSTABLE plan which tells the daemon to frequently re-calibrate the TCXO to compensate for this clock drift. I believe this is the main cause of satellites drifting in and out of view (TCXO drift causes the GPS to search for them in the wrong place temporarily) - I noted that in the Nexus S the _UNSTABLE frequency plan is not used, presumably they replaced the TCXO with a more reliable one. All TCXO's do not seem to be created equal, judging by data provided here by us, so it may well be that some devices can perform better without the _UNSTABLE frequency plan used in this jupiter.xml. Try changing it! :) You can also try the _EXT_LNA parameter which tells the daemon that the RF circuit has an External Low Noise Amplifier on it (i.e. the SNR should be higher than normal, thus reject less of the signal) - I haven't diassembled the unit to see if there actually is an LNA in the RF circuit (I doubt it, we'd be seeing higher signal strength)

    The GPS Chip internally needs about -155dBm signal strength to use a satellite for a fix. This is reported in LbsTestMode as roughly 16 dBHz (not sure of the exact value) - when a satellite's reported signal strength drops below this value the GPS drops it from the current fix calculation.

    To sum it up it's my opinion that the antenna is sub-par, but not bad enough to account for all our problems. Certainly providing a better antenna should result in a better positional calculation (I've not once seen it go sub-5m, but my BT GPS can do .3m) Again i'm only trusting the debug output of the daemon, I haven't gone into the phone with an oscilloscope to actually measure the TCXO output.

    @aleadam:

    Tracking should indeed be the major change here. If AGPS was functioning correctly in your previous setup, the TTFF, etc. should not be affected. Although more aiding data should be saved to /data/gps now for use with future locks :)

    @calfman, @tiger4j:

    Here's what the updater-script in the .zip does (you can open it in a text editor to read it yourself, also,) copies files into /system: /system/bin/gpsd/glgps_samsungJupiter, /system/etc/jupiter.xml, and copies files into /data: /data/gps/secgps.conf, then sets permissions on these files (chmod 0755 glgps_samsungJupiter, chmod 0644 jupiter.xml, chmod 0644 secgps.conf. It looks like the install failed copying files to /system, hard to say why without knowing more about the setup of that ROM/Kernel. You can do it manually from ADB easily enough :)

    @crazililazn:

    That's expected behavior with this supplied jupiter.xml. All interpolation algorithms i've found a switch for thus far have been disabled. The reason for that is that alot of the tracking issues are related to those algorithms. GPS Pedestrian Mode tells the GPS to report each fix, and not filter any out (because they don't match typical movements of a vehicle) if you do not desire this behavior, change CNoSmoothing="false" and DynMode="DYN_VEHICLE" (or DYN_AUTO)

    @everyone:

    I'd like to stress that this isn't intended to be a fix for everyone as-is. Rather to educate you on how you can use jupiter.xml to tailor the GPS output to YOUR needs. If you only ever use the GPS for navigation, and get better results with smoothing/vehicle mode on, by all means, turn it on :) Thats the purpose of all the detail i've put in the first post, so you can make your own decisions. The provided settings are only what works best FOR ME.