yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] Peaster111:
Da_G,

The Captivate forum is starting to feel like old home. A bunch of folks seems to be coming over from the dark side. My defunct Blackjack and Fuze still have much of your WM work on them.

I've been able to customize the cappy to my liking and work out many of its quirks except for the GPS. Thanks to this great forum I've been able to improve the GPS from lousy to marginal. I've tried several fixes with mixed results. I use my own ROM nowadays with CLShortfuse's v006 fix in it. His fix was the best I've had until now.

I read your extensive first post and much of the thread. Excellent write-up. I've leaned some things about the cappy's setup and GPS interactions. I teach GPS for a search and rescue team, so I can appreciate the effort/time you taken to learn how the GPS works specific to the Captivate. No small task.. I'm impressed. Thanks!

I snagged your ATT GPS files, matched my lbsmode setting to yours, cleared my GPS data and rebooted my phone. I took my wife (non-tech person) on 30+ mile trip it test it out. Some back roads and some highways. My wife asked what I did to the phone. That is usually a bad thing... so I thought now what. She said the GPS was tracking really good (best she could tell). I didn't know whether I was more amazed by her noticing it or the actual changes... Holy smokes! Later in the day she drove and I observed. Wow... It seems to track spot on now. No more wandering, intersection overshooting, etc. The results have held true for two days now. I'm impressed. ... this is still a dev effort? :D

What I'm gathering now is that several files along with the "correct" setup and cell network must work together if any substantial improvements are to be made. One "fix" is not going to work for all. This may explain why so many "fixes" have had mixed results. I would surmise that results have been more potluck than a calculated "fix".

I have not seen any discussion here regarding the modem and its relationship with the GPS performance. A lot of talk on other threads about this or that modem being better for GPS. I think most of the conversation is anecdotal. Assuming the GPS can run standalone reasonably well, the only thing I can think of is that the modem effects AGPS performance (i.e. startup timelines and to assist in positioning during lost GPS track). I'm not convinced it that big of a deal outside of that. I'm using the JL3 modem currently and get about 10-60 second startup on average which seems reasonable... so many things can effect startup timelines.

You thoughts on the modem?

Thanks again for all your efforts. Your dedication shows.

Best Regards
[Captivate Android Development] slider2828:
Works awesome!

Hey Da_G: This fix works awesome for me. Currently I guss I have Jupiter Fix V006, with your fix and a JK4 modem on Assonance 5.0. Man this is the best it has ever been. Locks very quickly even in Apps, which is notorius for not locking well, like yelp or Google Maps. I mean it currently feels fully functional AND accurate.

Expect a donation from me end of the month. THanks again for your hardwork!!!
[Captivate Android Development] Da_G:
@compuguy1088:

No, I don't believe anyone has tried these on anything other than a Captivate. I'll go make some posts in other SGS forums so they are aware of it :)

@nephets0:

The 5m increment accuracy reporting is probably just the granularity the firmware reports. I haven't gone so far as to reverse engineer the MEIF protocol, but if we were to, i'm sure we'd see the 5m accuracy reporting there too.

@Krynn!:

I think the issue may be different, possibly EM noise generated when the CPU/GPU is running at a high duty cycle. If it was purely a CPU issue, using "renice -20 -p $(pidof glgps)" would fix it. But on broadcoms product page for the BCM4751, they say it's designed to have very little load on the host CPU, and not require real-time performance from it. The ASIC is designed to handle all functions onboard and pass data via a UART. I've noticed no improvements from renicing the glgps process other than more reliable function when a high level of logging is on.

@Peaster111:

Glad it's working out well! Still a dev effort until i'm confident we've rung the most performance out of the GPS as possible. I still see it rejecting satellites at -154dBm, when it should be able to continue tracking them down to -162dBm. That's more than 2x less sensitive than it should be!

Regarding the modem and it's role in GPS, there is definitely a part played here. The glgps daemon requests AGPS data by talking with the RIL (Radio Interface Layer) which then in turn sends some commands and the server info to the Radio ROM. The Radio ROM then handles the actual injection of the AGPS data. I'm not sure if it handles any calculations (from the limited paperwork i've been able to find on the chipset, it should all be handled internally) - but i'm still disassembling to find out :)

@slider2828:

Woo hoo!
[Captivate Android Development] drancid:
This is just a test report. ;)

I disabled control plane in service mode and did 15 mins driving test as usual, couldn't feel any diffs between on/off control plane in service mode.

I flashed ATT one this time and match the settings with jupiter file (i guess:)).

Will do the same driving test after work. Will post result after.

Keep it up da_G!!

Sent via ATT Captivate.

Perception Build 9!!
[Captivate Android Development] Peaster111:
@Da_G:

Thanks for the reply. Good info (as always)...

Sounds like there is a lot of work still to be done. 2x down in sensitivity is still pretty bad. I guess that means it'll track to an ant hill with reasonable sensitivity levels. You can put away the bluetooth GPS then. :)

Good luck on the AGPS effort. I'd recommend focusing on the getting the base GPS sensitivity where it needs to be, then worry about the AGPS... just a thought. I'd hate to see ya overloaded. ;) I'm sure you'll do well all around.
[Captivate Android Development] android.francis:
Hi there. I saw your thread in the other sgs forum. Is this for North america users only or folks from lets say Asia can try this as well?
[Captivate Android Development] Da_G:
@android.francis

Hi francis. I just replied to the other thread :) the short answer is yes, it will work! But may require some minor jupiter.xml tweaks on your part.

@Everyone

I'm very reliably able to reproduce the issue where tracking is excellent with lbstestmode in the foreground, and my tracks in the background recording a track (5-10m accuracy, no overruns when coming to a stop or other odd gps behavior) - the moment i bring my tracks to the foreground, tracking goes very bad and the satellite lock is lost alltogether. It comes in and out after that, seemingly affected by CPU/GPU or cell radio usage. I'm going to attempt to narrow it down on my next trip with the laptop in tow. Can anyone replicate this behavior?

Note that it seems to be more sensitive to this issue using the FrqPlan in the last jupiter.xml i posted on pastebin. I don't see the issue as starkly on other FrqPlans, although tracking is not as good overall on those. The fact that changing the oscillation seems to affect the performance of the gps with my tracks in the foreground is what's leading me to think theres an EM noise problem. At differing frequencies it would change the effect of interference. This definitely needs more testing - it might be that as the CPU/GPU frequencies change (scaling, overclocking, undervolting, etc) the gps FrqPlan also needs to change to reject the different interference.

I'll try testing My Tracks in the foreground with the CPU frequency scaler locked to 800mhz/1000mhz, etc.

[Edit: Locking the CPU speed down did not affect My Tracks tracking, still near perfect in the background and very bad in the foreground. So this is not (directly) related to the CPU clock. I tried 400mhz, 800mhz, 1000mhz, and 1200mhz with no effect.)

Updated the first post with more info on the <hal LbsEnable="true"> and related settings, mostly about using LbsLocal="true" to seed your own local AGPS database.]

[Edit 2: It appears as though this user may have identified the same problem with foreground apps. Although he traces it to another cause, it sounds like the same problem.]
[Captivate Android Development] ari197:
yesterday I drove my car around for about 30 minutes.. I use waze to track .. what I noticed is that I lost GPS lock quite often .. also that sometimes the accuracy is quite bad..

anyhow, I still feels that it's better than before :)

I'll make some more testing later today.
[Captivate Android Development] Lavundra21:
so is this for people who never got a lock on their gps??? because that would be me.. ill try this if it solves that problem, if not it will just waste my time. but good work tho.
[Captivate Android Development] poormkp:
I was able to replicate DaG's pattern of MyTracks in the foreground vs the background. My test was - first tried get position test in lbs test mode - that worked great with under 15 second lock and kept lock on the move. Next closed lbs test mode ad started MAPS - occasional lock at best. Then started My Tracks and it locked OK but soon drifted in and out while in foreground. Then let My Tracks continue in the background, and the recoded track was spot on for rest of trip.

My setup is Assonance 5.0, plus DaG's Google Tweak.
[Captivate Android Development] Dani897:
Hard to say. You may just have a bum phone all together but if not there is a chance that this can fix it. It depends on the nature of your problem.

I might suggest the samsung gps restore app. It resets things that are normally only reset with a factory reset. Certainly not a "fix" but it helps my phone when I run into a bug with the daemon stopping on its own.

Try an alternate program for your initial lock like my tracks. Some phones aren't playing nice with google and mine doesn't even play nice with lbs test at times.
[Captivate Android Development] born_fisherman:
Tried using the att version with perception9.5 and everytime gps is used the phone keeps vibrating
[Captivate Android Development] Da_G:
@poormkp

Thanks for testing that scenario. So far you are the 4th person to replicate the results. I think we are getting much closer to finding the root cause of the GPS problem with this finding.

@born_fisherman:

The zip won't work without modification to the jupiter.xml for Eclair (not sure if that ROM is Eclair, Froyo, or Gingerbread) - this may perhaps be the cause. There are instructions to edit the jupiter.xml in the first post. Anywho, what's going on there is the glgps daemon is crashing for some reason. The services daemon automatically restarts it (so thats why you get the vibrating each time, from the force close)

@Everyone:

To summarize:

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) - This is really just a minor problem, as it only affects TTFF (Time To First Fix) - After that, the GPS chip is perfectly capable of tracking by itself.

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.

I'll copy this information to the 2nd post for better exposure. Really need more people to test the "My Tracks in Foreground/Background of lbstestmode" scenario :)
[Captivate Android Development] Da_G:
Just did another trip, here's the track, as you can see it's nearly perfect, 5m accuracy the whole time.

http://maps.google.com/maps/ms?ie=U...73840170072199.0004982f9c15e59a48133&t=h&z=14

There is one hiccup in the track, where I switched to the desktop instead of having lbstestmode in the foreground. The rest of the track is done with lbstestmode in the foreground. I've got 4 consecutive days of tests showing some kind of interference with an intensive program in the foreground, so it seems that's certainly the problem!
[Captivate Android Development] born_fisherman:
Da_G - the perception rom is based on 2.2, i beleive its vibrant based if im not mistaken
[Captivate Android Development] tk44uk:
When using 'GPS Test' app, I noticed the satellite lock is lost if I rotate the device through 90 deg. (from portrait to landscape view)

It takes a few seconds to re-establish lock again.

I thought it was just a quirk with that particular app, but then I found the same thing with another app. 'MapDroyd'. - the little sat icon starts flashing, indicating loss of sat lock, when I turn the phone through 90 deg.

After unticking the 'auto change orientation' in display settings, no loss of sat. lock occurs when rotating the phone through 90 degs.

Just thought this might indicate some issue regarding the GPS problems...
[Captivate Android Development] poormkp:
More My Tracks / Interference testing. Started My Tracks and waited to get a lock then let it run in the background. Then watched GPS Lock Icon while doing other functions to see any impact on the GPS Fix. First tried running Quadrant, Linpack and Speed Tests - these did not affect the GPS Lock at all. Next tried some Solitaire - still no impact. Then dialed some calls to the local weather line - here there was definite impact.....I would lose the lock and get the flashing GPS icon consistently within 3 to 10 seconds of dialing. Was also able to see the same thing with a google search followed by 5 or 6 clicks to other pages. Some other apps also seemed to not cause any issues.

Thing I found most interesting was that once the lock was lost the GPS would be trying to get a new lock for quite some time after each of these disturbances, but I was able to get an instant lock any time by just pressing power to lock the screen, then waiting about 10 seconds then unlocking the screen. This routine for getting the My Tracks lock back in place worked 100% of the time, and I probably did it at least 20 times. So, there's obviously certain things that cause the lost lock, but then also an immediate re-lock by getting the phone into screen lock mode.

So, is it interference, or could it also be some kind of processor priority issue as the GPS process takes a back seat to one of these other processes?
[Captivate Android Development] korgmotif:
i read on the forums that the back metal panel acts as an antenna for not only the cell radio, but the gps radio as well. it may be possible the two can't alway work together very well?
[Captivate Android Development] TXRangerXDA:
I mentioned the foreground/background issue back in your first thread on this issue, on Dec. 3rd, so yes, I can also confirm it. At the time I had hoped that it would help you to not rely to heavily on my tracks data as they can be misleading when it comes to telling us if the gps tweaks are really doing anything useful.

My original post quoted below.
[Captivate Android Development] Dani897:
Have you looked into the reason the daemon crashes on some phones with eclair and early froyo leaks?

Also this may be anecdotal but on eclair we had a kernel that had the gpu overclocked. It seemed to me that gps worked better without the gpu overclock. It was difficult to isolate and repeat though because the gps on the eclair roms was pretty touchy for me. I had the daemon crash on me alot.

Also fyi perception 1-8 are bell vibrant froyo based which we know as a gt i9000m

Perception 9+ is telus fascinate which strangely is a t-959 ( t-mo vibrant) the canadian roms have the same bands as ATT so the modems work well for us. The telus modem even seems to help initial gps locks (anecdotal I know)

Another observation that is repeatable for me is with eugenes gingerbread clone ( froyo with some gingerbread apps and theme) which im not sure what build it is based off of, I get fast locks using the telus jl3 modem and you're update.zip with you're settings but having network location on seems to help my speed and accuracy (10 meters in under 10 seconds). But without network location I only get 30 meters in 20 or so seconds without network location and it never gets better than that. Strange thing is this is the opposite of experience I've had on other roms.

Network location alone only gives me 4100 meters acuracy and I find it difficult to believe it is having a positive influence. Im thinking there is another factor but what? Does the network location toggle have an effect on an agps feature?

It is hard to imagine these phones have so many gps related issues. Crashing daemons, poor reception, interference. Will this require a combination of software tweaks and hardware mods to get right?
[Captivate Android Development] developer58:
Hey man, you rock!

Installed the control plane version and had indoors in 7 secs a fix!!! (Netherlands)
[Captivate Android Development] aleadam:
I would think that is a problem with those particular apps not handling correctly the fact that android restarts the activity when flipping the phone. I may be wrong, though.

2.2 kernels and modems do seem to increase the sensitivity. In fact, with a jpy rom, setiron's kernel and the latest ugjl2 modem I could see 6 sats with over 40 snr. On stock eclair I remember seeng low 30s at the most.

Problem is, accuracy should have increased enormously from that sensitivity increase, and this was not the case. It improved, but not by that much.

If it was actually interference the problem, I would expect to see more noise measured as an increased st dev of each 1 sec point from the average (in a stationary position) or from the average line (in continuous movement). That may be something easy to see from parsing the nmea data and using very basic statistical tools. What do you think?
[Captivate Android Development] Dani897:
Sorry it specifically says "use wireless networks" and is a check box in settings>location and security.

It is odd because in the past it seemed to hinder gps locks but on my current setup it seems to improve even accuracy. I must have toggeled it 15 time and with "use wireless networks" set to on I get 10 meters. But without it on I get 30-50meters fluctuating.

Is there a specific set of things I should log? Right now I don't have any logging. Also any hardware mods you'd like to test im willing. Im more hands on than software savy. Just give me an idea of what to log to test it.

Happy Holidays. And thank you, there are many good devs but your contributions may be the most significant as it applies to everyone with a galaxy s phone.
[Captivate Android Development] foxbat121:
It is easy to test this theory. Google Navigation is capable of cache the route information if you setup a destination and picked a route to follow. So, you just need to:

1. Fire up Google Nav, type in a destination, let it finish setup routing and start navigation.

2. Turn on flight mode. This will turn off all radio. You will find your Google Navigation still works as long as you don't go off the track that requires re-routing.

I've tested this couple times and it made no difference in improving my GPS accuracy. So, I think the interference from Cell Radio theory is debunked.
[Captivate Android Development] ari197:
I'm currently using Axura CE v2.4 with a kernel capable of Over Clock and Under Volt. What I notice is that whenever I configure the UV, it's harder to lock and bad accuracy. I don't know how this help though.
[Captivate Android Development] poormkp:
While testing various scenarios to do with the foreground/background gps performance I stumbled on to a scenario that has produced surprisingly the best results I have seen with my phone to date. I had been reading some of the posts about cleaning/scraping the two plates on the inside of the back cover, and while trying that out I began to wonder how would antenna reception be affected by not having the back cover on at all. While inside the house I proceeded to remove the back cover and test. I was surprised to see no loss of signal quality with either the cell radio reception or with Wi-fi. Still with cover off I made several test calls, internet searches, and speed tests. Voice and data functions all performed well with no quality loss.

I then proceeded to test gps in the car. First keeping the cover on I tried starting up Google Maps and as usual had trouble locking on and staying locked. So then I removed the cover, so battery, SIM, etc are exposed, then fired up Google Maps. For the first time in my phone’s history I get solid lock in Maps, and get very accurate tracking while on the move. Drove several miles til I was convinced it was no fluke. Decided to fire up My Tracks to record the findings and ended up with the recordings below that I wanted to share:

The first one is with My Tracks started – keeping it in the foreground, with back cover on the phone as usual. You will notice this track only shows a start and end point as the phone was unable to lock at all while driving in this scenario.

(Sorry for address only as I am too new to post links)

maps.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=211929289599497149208.00049868f80eec283d53c&z=14

The one below is exact same route, still running My Tracks, keeping it in the foreground, with the only difference being the back cover is removed. It shows solid lock and while not perfect accuracy, probably good enough for my typical needs. This is the first time I have ever been able to get either Maps, or MyTracks, to work well in the foreground !!

maps.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=211929289599497149208.00049868f444e5a6a7ad9&ll=39.790534,-85.816355&spn=0.027436,0.064716&z=14

In summary, I think this just re-inforces Da_G’s conclusions that the gps antenna is a little bit sub-par, and also that in it’s typical configuration the phone has trouble with gps tracking when something in the foreground interferes with it. But, at least for me, this finding also shows that by removing the back cover the gps reception can possibly become just enough stronger to overcome whatever that interference is, and provide solid tracking in a heavy usage foreground app such as Maps or MyTracks. While my cover was removed, I tried Co-pilot as well and it stayed with me too. I know this is a very simple finding, but I offer it in case it helps us get to the ultimate fix.