yashsingh1/xdaforums huggingface dataset:
[Epic 4G Android Development] mkasick:
OK, I've seen that before. I've also had problems where the GPS will eventually see satellites and fix, but it takes a rather long time, upwards of five minutes. The latter mostly happened under DI18, I don't think I've waited around long enough to differentiate between the two problems the few times it's happened in EC05.

This is actually quite interesting.

To my knowledge, a "reboot" only reboots the Hummingbird CPU. I suspect (but have not confirmed) that the baseband CPU actually stays running throughout. Or at least, when I have had occasional wonky-radio issues, a simple "reboot" would not clear them. It requires a full device powerdown, which should reset the baseband as well.

It's relevant because, the stock EC05 behaior is to download XTRA data on reboot. It wasn't clear to me before whether GPS issues were being resolved as a function of receiving new XTRA data, or as a function of a baseband reset. However, if you find that a "reboot" doesn't always fix the GPS problems, that suggests that once it's in a sad state, it's possible that only a baseband reset will fix it. Alternatively, it may also be that a "reboot" doesn't always download new XTRA data, if it's attempted before a network connection is fully up.

I suppose we'll find out in a day or two, but if it is the case that the GPS won't recover from it's "sad state" without a power cycle, we might be able to keep it from ever reaching its sad state by keeping the assistance data fresh before attempting fixes. This would require consciously toggling the GPS before attempting a fix if one hasn't been performed in a long time. So, if you do run into a problem in the next day or two, this might be worth trying next.

I suppose it's also possible that some Epics just have bad GPS chips. If so, the existence of a separate assistance problem that was present in DI18 for so long makes it difficult to differentiate between the two. Hopefully this isn't the case.

Anyways, let's see what logcat says.
[Epic 4G Android Development] mkasick:
Actually, thinking back to the DI18 GPS issues, I recall the exact GPS behaior was erratic under "Hot Start", but fairly regular under "Cold Start".

With "Cold Start", I found fixes to be very reliable as long as the 3G data connection was up, and it's well known that fixes with WiMAX, WiFi, or (obviously) no connection would result in the GPS being unable to get new assistance data. The catch was, if I accidentally started the GPS w/WiMAX or WiFI, stopped it, dropped down to 3G, it wouldn't recover right away. But if I did a full power cycle it would, or if I waited 10-15 minutes and tried again (on 3G), usually it would work.

Perhaps this means that the GPS can get into a "sad state" in which it doesn't immediately recover (i.e., it "refreshes" the stale cache and rejects additional assistance data), but if the assistance information is kept up to date it won't enter it.

There's also a "radio" logcat buffer that I haven't spent much time with--that's probably worth taking a look at too.
[Epic 4G Android Development] jdelano:
midNight v5.2 + this = NICE

Ok well I went ahead and put this bad boy on my phone. Using the midnight version of the zips at the bottom of post 1. It made a stark difference in speed of lock and accuracy for me.

I tested before application (I ran aLogCat to capture the background info) then flashed and ran the same test. Much nicer for sure.

EDIT: after further review; my phone gets a great lock after reboot and then it slowly gets worse. We also confirmed that the midNight update didn't change anything. mkasick is looking at the jars and logs I sent him.
[Epic 4G Android Development] mkasick:
The original update.zips I uploaded don't actually flash in ClockworkMod. Apparently /system needs to be mounted, which it already is in stock recovery. They're fixed now, sorry about that folks.

Thanks to jdelano for the testing on that.
[Epic 4G Android Development] jdelano:
No problems at all, I'd like to report this has indeed made a very nice improvement on my GPS experience :D
[Epic 4G Android Development] mrhocuspocus:
So whats the verdict? This work around only works when you reboot phone?
[Epic 4G Android Development] jdelano:
Please see my post above yours ;)
[Epic 4G Android Development] mkasick:
We hashed it out a bit over email. jdelano's problem is a bit unique compared to others whereby fixes regularly take 4+ minutes, all the time too.

It seems that his 3G is slow-enough to come up on boot that the assistance (XTRA) data is never downloaded. With the workaround, the 3G connection is up before the download takes places, so it works and he can get locks in a few seconds.

Which is an interesting case, as I was wondering if this would help folks who always have fixes that take minutes, or who never have fixes. The jury is still out on whether it helps folks whose ability to get a fix degrades with time since reboot--it will probably take a few days before we can make a claim on that.

It was a bit confusing earlier as the first version of the mod jdelano tried didn't actually take, but coincidentally the XTRA download on boot did, but it works now.
[Epic 4G Android Development] mrzood:
Apologies for the late reply.

This is only with 3g/4g. I rarely connect to my wifi at home. Yes, I consistently get fixes without "Wireless networks" checked.

I just tried it with GPS off and Networks ON. My location is only accurate to 1300 meters now. I just now switched the settings back to what they were and it seems like the cache has been cleared cause not it's taking its sweet time to get a lock compared to the near instant locks I was getting, that is if it will even get a lock now.. It just locked as I'm typing this out, actually, under 2 minutes without "Use Wireless Networks" checked while indoors. Initial lock was 100m accuracy and it is working its way back down.

Phone uptime just ticked over 100 hours since last reboot.
[Epic 4G Android Development] mkasick:
Any difference between 3G or 4G here?

So it might be that the location data that's injected is bogus. I've been tracking it for a few days, and while I'm not sure I understand the exact format, it's a bit suspicious. For one thing, I drove all over the city and the location data only updated once.

I'll poke at that some more.

That accuracy is expected. If you run Maps (or whatever) with GPS & wifi off, it can only pinpoint your location based on the cell tower you're communicating with.

The subsequent long GPS fix time, however, is not expected.

Any chance you'd be willing to install CatLog and record a logcat while playing with those settings? I'd be interested in seeing if a bogus location injection preceeds your inability to get a timely lock.
[Epic 4G Android Development] mrzood:
Logging with 4g on and Use Wireless Networks off right now. Letting the accuracy improve a bit.

Since I changed the settings from my very first post in the thread, my gps seems flaky.. Taking much longer to lock, consistently dropping but it does reacquire a lock fairly quickly after it drops(most of the time).

PM'd you the link to my the logfile.
[Epic 4G Android Development] slwelsh:
Does that apply to the one for SRF, too? I did not notice any errors when I did an Install Zip in CWM.

-Sean
[Epic 4G Android Development] mkasick:
Quite likely. No, it doesn't raise an error, that's in part why it wasn't obvious right away.
[Epic 4G Android Development] mrhocuspocus:
hmm.. well, im willing to give it a shot and report back, but im not sure what to do.

I never reboot myphone unless the battery dies, which is rare. My gps always works but it takes like five minutes to get a lock, and for a while after that the lock is pretty instant. Ive had this problem since day 1, its not ec05 specific for me.

The triangulation location method works within seconds on my phone every time.

Im also not sure what the difference between all the files are in the first post.. going by the filename it seems like some of them are to enable silent mode w/out vibration.

Im using a deodexed rom.
[Epic 4G Android Development] mkasick:
I was able to recreate the "Use wireless networks" weirdness.

Everytime that setting is enabled, location data is injected into the GPS. It shows up in logcat as:

D/libgps ( 2445): sec_gps_inject_location: latitude: ######, longitude: ######, accuracy: #######

with #s being numbers of yet-to-be-determined interpretation. Now, with either 3G or wifi on, my longitude value is nearly always the same, but the latitude value is often wildly different. On 3G, it tends to be the same value for a while, then change to something completely different, whether I've moved or not. On wifi, each toggle of "Use wireless networks" uses a different value of a set of five or so.

Which is bogus. The inconsistency in location interpretation suggests it's just wrong. Now, one of the times I toggled it, the GPS seized and wouldn't fix. I forced it to redo NTP & XTRA and it started working again (which is good). Once I got a fairly accurate fix, I wasn't able to get it to seize again later.

Based on your experience and what I briefly observed, the may very well be vulnerable to bogus location data. Perhaps once it does acquire an accurate fix, it just ignores subsequent location injections (too low accuracy?) for some time.

It might be worth seeing if the 24-48 hourish post-reboot GPS death still happens if "Use wireless networks" is left off the entire time.
[Epic 4G Android Development] mkasick:
Which ROM?

If it's just stock deodexed, i.e., there's no framework modification from EC05, you can use "tws_fix_ringer_vib_silent_gps-EC05-deodex.zip". Yes it also includes the TWS bug fix and the ringer volume control mod. The former is harmless. You'll only notice the latter if you have "vibrate on silent" enabled and you press down on the volume rocker a bunch. Basically it just restores the ringer behavior of DI18 where the volume rocker allows for both "vibrate" and "completely silent" options.

If it's another ROM (SyndicateROM Frozen and midNIGHT are already posted), I can prepare a modified framework for that. Alternatively, if the TWS/ringer mod is a showstopper for you I can make a stock+GPS workaround only build. They're only included together as the modifications are to the same file, and I wanted to make this workaround available to folks who were using my previous fixes without having to choose between them.
[Epic 4G Android Development] mrzood:
Seems that after turning on wireless networks and turning them back off I'm no longer able to get a gps lock with both options ON. I'll grab another log file.
[Epic 4G Android Development] mrhocuspocus:
okay i installed it, gps still takes a long time to get a lock about 60s. It does seem like its a little faster, but it could be just be how long it normally would take right now.

Im using wifi and in a building.

how else do you want me to test it? wifi, 4g, 3g, building, outside, driving....?
[Epic 4G Android Development] mkasick:
What kind of building? It could take a while because of that, but usually it's all or nothing.

If you can install CatLog, and then go to Menu -> Record before toggling GPS on and attempting to lock, then stop and send over the logfile after getting a fix that takes a long time.

That way I can see if the modification is actually doing what it should, and perhaps get a clue as to why it might not be making a difference for you.

Edit: Also, if you can test a GPS enable & (good) fix and grab a logcat while doing so, and either check it yourself or send it over, just to verify the modification is working.

To verify it's working, there should be a

D/GpsLocationProvider(...): handleEnable

message at the time when GPS is toggled/enabled. Between then, and when you attempt a fix, there should be a message from "D/GpsXtraDownloader" and eventually a

D/libgps (...): inject_xtra_bin: length = 701, current part 40/40, dc_status = 1

message that indicates XTRA data was successfully downloaded & injected.

A fix starts with a

D/GpsLocationProvider(...): startNavigating

message, and ends with:

D/GpsLocationProvider(...): stopNavigating

Finally, when the GPS is toggled off there's a message:

D/GpsLocationProvider( 2445): handleDisable

Now, if you see "startNavigating" before "inject_xtra_bin" finishes, that means you have to wait longer between toggling the GPS enable button and starting Maps, GPS Test, or whatever. A solid five seconds should be sufficient.
[Epic 4G Android Development] slwelsh:
Just thought I would update everyone. I have captured a log and sent it to mkasick for review.

The mod seems to work, inasmuch as toggling the GPS off and on does generate an NTP request as well as an XTRA data download.

In my case, however, after the download the XTRA data fails to inject to the GPS.

For me, at least, the symptoms suggest the GPS receiver is actually powered down, even though the icon is lit and clearly the position location service is calling for it. Not sure how to validate that theory, or how to force it back on if it's correct.

I am thinking now that I am going to have to record the log from boot time all the way through failure to try to capture the event that is causing the GPS to fail.

CatLog seems to only be able to record the complete log. Is there a utility that will record only events matching a filter such as a regular expression?

-Sean
[Epic 4G Android Development] mkasick:
I can't say if it's powered down, but somewhere between the RIL and the GPS chip there's code that get stuck in a wonky state from which it can't recover.

I've never seen such before. I'm curious if other folks who have symptoms similar to slwelsh see this as well. After the GPS fails, it's apparent from CatLog. Among others, messages similar to the following should appear frequently as the result of any GPS request:

D/libgps (#####): request_location_fix_callback: stack state ERROR_GPS_STATE, prev stack state SPR_GPS_STOPPED
...
E/libgps (#####): RIL Request: ERROR 1 (n=110, r=0)

Indeed, two minds think a like. I sent you information on doing that.

As for others, collecting a continuous log of GPS events is a slightly involved process. Let's see if slwelsh finds anything interesting while doing that, and if so, I may request others to do the same.
[Epic 4G Android Development] aero1:
A: thanks for the work

B:How does that jive with the widely reported success rate of prior cold start default?

Fails to inject, some routine not recognizing it as more fresh, there are ahlf a dozen possibilities.

I have seen the problem on one epic we are running bonsai on, so bonsai doesn't fix it.

GPS Status will not properly inject new xtra data.

Again the GPS condition I am seeing iwith ec05 s identical to the DK and all pre db13: intermittently (about 20% of the time) seeing sats and not placing them in use which is almost always indicative of old ephemeris in device xtra (assistance)cache not properly renewed. This occurs in good GPS conditions, is more likely and frequent the longer it has been since battery pull or full reset, and is immediately fixed with a good instant fix immediately following a reset.
[Epic 4G Android Development] slwelsh:
These are two different problems. Mine is not fixed by a cold start.

According to the log, the injection is failing:

04-12 08:46:22.753 D/libgps ( 2934): inject_xtra_bin: OEM_XTRA_SET_DATA request failed.

As I said, I seem to have a completely different problem. Once my GPS fails, it no longer even sees any birds. Fixes don't take a long time... they don't happen at all. Toggling the GPS off/on, running GPSCLRX, or using GPS Status or other tools to (attempt to) load fresh ephemeris data have no effect. Even a reboot does not always fix it, unless I power down fully and then restart. It's almost as if the GPS receiver is powered off completely.

I have seen several reports from other users with these same symptoms, but they do not seem as common as a host of other GPS problems including the stale cache issue.

I'll keep everyone posted as we continue to drill down on this. I have logging running full time now to try to capture the event that is triggering the GPS shutdown (if it is even logged).

-Sean
[Epic 4G Android Development] mrhocuspocus:
sent some logs to mkasick, hope it helps.
[Epic 4G Android Development] mkasick:
So it seems the GPS is a complicated mess. Folks here are reporting five distinctly different issues. Here's a summary, which I hope is reasonably accurate:

mrzood: Can't reliably get fixes with "Use wireless networks" enabled. I've confirmed that injected location "latitude" data appears to be bogus. Unclear if this (aside from mrzood's case) actually affects the GPS. Currently unresolved, although a patch to prevent location injection is straightforward.

slwelsh: GPS completely seizes up on the radio side, randomly upon termination or backgrounding of a GPS-utilizing app. All subsequent GPS requests return error. Is not fixed even by a "reboot" and requires a full power cycle (suggests radio issue). Have one log at present which contains the error as it first manifests, which suggests the issue is due to an interleaving of RIL "location_fix" and "stop" requests due to insufficient locking. Likely happens at random, possibly a 5-6% chance of seizure on any GPS app exit. Experienced (although not log-confirmed) by mrhocuspocus as well.

jdelano: Locks always take 3-4 minutes, likely due to failure to download assistance (XTRA) data on boot. Probably consequence of the "network available" problem identified in OP. Workaround gets lock in ~10 seconds.

mrhocuspocus: Somewhat lengthy Maps lock times (~60 s), particularly in doors, often 1-4 satellites appear (fixed?) in logs. Not significantly changed by workaround (correct?). Edit: Issue may be similar to mrzood's, toggling "Use wireless networks" off appears to help.

aero1: 20% chance of seeing satellites, but not fixing on them. This is more likely to happen with increased time since last power cycle. Presently unknown if workaround helps.

Also it's worth noting that nomenclature here differs a bit. I consider a "GPS fix" as an instance in which GPS Test reports satellites in use with a green "GPS on" indicator. Others who use Maps to test are reporting the length of time until the "My Location" triangle gets far more accurate than the coarse cellular-based location radius. These are related concepts, although I think Maps method does takes longer than fixes as reported by GPS Test.
[Epic 4G Android Development] mkasick:
Uncertain. Actually, you're the first person in the thread to report the ability to see satellites but not "use" them. I had that same problem frequently in DI18, never ran DK28, have not had it in EB13 or EC05. Although I certainly believe it exists, and there are folks who suffer from it.

Would you be willing to try the posted workaround to see if it helps resolve the cache issue?

Alternatively (or in addition), would you be willing to record and generate a logcat during an instance when attempting to fix and experiencing the stale cache problem you describe?
[Epic 4G Android Development] mrhocuspocus:
you guys seen this?

http://xdaforums.com/showthread.php?t=955395

alot of people are having success with it, as a member of xda im sure the guy would share his source code with you if you asked.
[Epic 4G Android Development] mkasick:
I hadn't, thanks for the link!

Based on the app description, it appears to make modifications to /etc/gps.conf (or at least the NTP/XTRA server properties), and also serve as an interface for GpsLocationProvider::sendExtraCommand, namely "delete_aiding_data", "force_time_injection", "force_xtra_injection".

The latter two (NTP & XTRA injection) is what the workaround here already does. I didn't bother with "delete_aiding_data" as (I believe) it's not used by the phone in normal operation, thus I didn't know if it works properly and doesn't cause side-effects.

So yes, it looks like a quite useful debugging tool, particularly for anyone who wants to test NTP/XTRA injection without flashing a modified framework. But since the API it uses is documented, the source code isn't necessary for our purposes.
[Epic 4G Android Development] jdelano:
Hmmmm

Well this patch had been giving me excellent results.

Last night I opened Maps and got a lock in 4 seconsd :eek:

(after the phone had been on since I flashed the last update I was given about 26hrs previous)

Today though, I can not get a lock at all. (1d 21hrs since unplugged)

Tried for 10 minutes; decided then to run LogCat and then attempt again. It has been running for about 9 minutes. I'll give it some more time then email the log.

Thanks for working on this!!
[Epic 4G Android Development] mkasick:
From the log it appears that the GPS went into an error state mid fix:

D/libgps ( 2751): request_location_fix_callback: session timeout occurs in spr gps stack. set error state
D/libgps ( 2751): request_location_fix_callback: stack state ERROR_GPS_STATE, prev stack state SPR_GPS_RUNNING

It appears to stay like that and responds error to every subsequent location_fix requet, like slwelsh's. If I understand correctly, merely closing the application and launching another corrects the error state and the GPS works again.

It appears the cause and nature of the error is distinct from slwelsh's problem. I don't know what caused it, but it appears the GPS ran into an error internally that it's able later to reset, whereas in slwelsh's the radio "gets confused" and GPS functionality ceases until a power cycle.
[Epic 4G Android Development] Anon9mouz:
Idk if ne one requested but a update for midnight rom that works both journaling on and off if that should make a difference idk
[Epic 4G Android Development] mkasick:
I believe the midNIGHT 5.2 modification should work on all midNIGHT 5.2 rfs & ext4 variants.
[Epic 4G Android Development] buggerritt:
I've been running midNIGHT Roms for some time, now. It's the best setup for my personal use. But, as soon as it switched to EC05, I couldn't get a lock on satellites, after 3-5 hours of up-time. What did fix it was this. I've been using midNIGHT v5.2 steadily for a week after performing those steps and have not come across a time where I cannot get a lock on satellites within 1-3 seconds. Within 10 seconds, I have 10-12 satellites locked and within 15 seconds, accuracy improves to 1 meter. This fix has worked for other users, as well. This also fixed my GPS on DK17 and DK28. I never had an issue with EB13 so, it was not needed. Try it, if you like. Don't try it, if you don't. I have been scoffed at by Aero1, who seems to be trying to help out here. Honestly, I don't care if anyone else does try it. I just want to show it as a solution and if it helps people, I am happy for them. I looked at GPS Aids and I would hate to have to download something every few days to make my GPS work. I also don't have a desire for another app to run in the background and have to rely on updates for it. As it is, my GPS is perfect and I don't have to do anything. I can be a lazy sod and pull the phone out of my pocket, at any time, and know that I can get a lock, in mere seconds, without having to think about it.

I am not taking credit for the fix. I originally found it as a fix for DK17 and the one who posted it was ahmgsk. I just linked to his post and edited the rest for use on the latest update. This may seem, at first, to be the cold start workaround. But, the details go further than that. You would have to read this workaround, in it's entirety, to realize that it is more than just that.

Locking on satellites

,

in each startup mode

,

and then flashing the latest stock update

is key.