Or Continue to Thread: SGS, glgps, jupiter.xml, and y…
Find Your Device:
21st December 2010, 10:56 AM   |  #2  
Da_G's Avatar
OP Moderator Emeritus / Senior Recognized Developer
Flag Riverside, CA
Thanks Meter: 1,533
3,298 posts
Join Date:Joined: Aug 2007
Donate to Me
To summarize the problem i've identified with our GPS so far:
  • 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 by Da_G; 24th December 2010 at 10:46 PM.
The Following 19 Users Say Thank You to Da_G For This Useful Post: [ View ]