yashsingh1/xdaforums huggingface dataset:
[Epic 4G Android Development] mkasick:
I'm curious as to what the exact issue is that you originally suffered. Actually, getting a logcat dump after a reboot, even now with the working GPS, would likely indicate the issue.

Anyways, it sounds similar to jdelanos, where the network conditions are such that your phone is unable to download assistance data on boot, and never attempts to do so subsequently. By downgrading to DI18, the phone uses the older method of acquiring assistance data which works in that instance. So should running GPS Status or GPS Aids and downloading assistance data one time, I imagine.

This is from memory, I don't have a link conveniently available, but I recall the problem with the downgrade fix is that, eventually, and likely after a period of not using the GPS for a while, the inability to acquire a satellite lock returns. This is consistent with the idea that, by downgrading to DI18, the phone acquires assistance data once, but is unable to reacquire it on subsequent reboots. It can still use the old assistance data, but unless you use the GPS every day afterwards, the ephemeris data will eventually go stale. If you do use the GPS every day, it can download and keep the ephemeris/almanac data up-to-date that way.

The workaround I posted is a bit more robust about downloading assistance data on boot (or when the GPS is toggled), so it should be a long-term solution to that problem.

The nature of GPS is such that your phone has to download new assistance data every few days, otherwise if you go a long period of time without using it, it will take a very long-time to get a standalone lock. If nothing else, this is supposed to be done on the Epic on reboot, but a bug prevents it from happening for some folks. I agree though, that running a background application to do it is suboptimal.

Edit: I should mention, it appears that gpsonextra.net updates their XTRA data once every hour at half-past. So while the assistance data doesn't need to be updated that frequently, it's not strictly redundant to do it no less often than once an hour.

I'm happy the downgrade fix works for you and hope it continues to. However, as it requires a downgrade, it's an involved solution for some. The goal of this workaround is, eventually, for it to be included in ROMs so that folks don't have to worry about the assistance issue either--it's all automatic.

Also, we've identified and confirmed-via-logs at least one other GPS bug unrelated to assistace issues that is not solved by downgrades. Due to its nature, it's likely to significantly affect only those who are "heavy" users of GPS apps. So while it may not represent a significant concern for most folks, it's particularly annoying to those who frequently encounter the problem. At present, I'm working on a solution for that as well.
[Epic 4G Android Development] buggerritt:
I understand most of what you're saying. I'm not a coder or programmer but, after using this fix on previous froyo releases, I never has the problems return.. I don't use my GPS every day but, I do when I travel for work (2 days/week at least). I trend to test the gps with status & tool quote often after performing the fix. Soon after, I'll go weeks without testing and just use navigation when needed. The symptoms I had, before the fix, included long times without locking, seeing satellites but not locking, no lock at all, and terrible accuracy o30-90 meters). Generally, a reboot would solve the issues and within a few hours of up time, they would return.

I'll figure out how to do a log cat and submit it later.
[Epic 4G Android Development] mkasick:
That may be enough to keep it fresh.

I believe GPS Status has an option to download new assistance data if it's been 24 hours since the last time. I forget if it's enabled by default. Didn't work in DI18, but it appears to in Froyo. That may be related here as well, although if you tried GPS Status's assistance download before preforming the downgrade fix, that should've worked, unless something else fouls it up. For one, I don't really know how the GPS handles getting new assistance data while actively seeking a fix, which GPS Status does.

There's other factors here too. For example, even without recent assistance, the GPS can get locks outside on a clear day in 30-60s typically. Indoors, or downtown (between high-rises), the signal is weak enough or suffers too much multipath for the receiver to get a fix without assistance.

Also, when not in cold start, the GPS should remember the satellite positions of those it saw previously. But that's not a replacement for having knowledge of where each satellite should be at any given time, which recent assistance provides.

Awesome! If you're familiar with adb, the most useful kind would be to do a reboot, wait a minute, then do:

adb shell "logcat -v time -d > /sdcard/logcat.txt"

and send over the resulting logcat.txt file.
[Epic 4G Android Development] buggerritt:
I had to reflash, due to a battery pull/boot loop issue. Not sure if a logcat will be any use immediately after flashing. I made one anyway. Should I just attach it here, send it to someone, or wait a few days and make another one?
[Epic 4G Android Development] keith5039756827:
EC05 GPS works fine I get 1 meter lock on satellites alone in 5 or less seconds.
[Epic 4G Android Development] buggerritt:
You must not have read the 5th paragraph in the OP. This thread may not personally apply to you. Or, you aren't noticing the exact issues stated. It takes a period of up-time (ranging from 3-7 hours in some cases) for them to surface. A reboot tends to temporarily solve the problems discussed.

However, 1M lock in 5 or less seconds is very impressive. Do you reside on the roof of the Sears Tower?
[Epic 4G Android Development] mkasick:
If it's a Froyo log it should be useful. If you feel comfortable attaching it to the thread, that's fine. Alternatively you can email it to me, see PM.
[Epic 4G Android Development] keith5039756827:
No I live on top of the twin towers. My phone hasn't been down since update and gps works. I wonder why it only affects some handsets, same hardware should all work the same, right?
[Epic 4G Android Development] buggerritt:
Sent
[Epic 4G Android Development] mkasick:
That probably helps.

There's a few different problems that affect the GPS. The one I believe buggerritt and others with similar symptoms suffer comes down to a timing issue whereby the phone is not ever able to get assistance data on boot in Froyo.

The factors that influence it is the type of network connection left present across a reboot (3G, 4G, or WiFi), and either the behavior of the connecting-to equipment (cellular base station or acces point) or the amount of locally present traffic. In overly simple terms, "slow" networks may ultimately result in GPS problems while "fast" ones don't.
[Epic 4G Android Development] mkasick:
Hey thanks a lot!

I see the /dev/log/main portion starts with GPS requests already present, so it's missing everything that happened before then. When you have a chance, would you mind generating a log shortly after boot, roughly a minute after the data connection comes up, but before manually running other apps and using the GPS?

Unfortunately the log doesn't maintain very much information so it has to be done relatively early, I think that would contain the most interesting detail.
[Epic 4G Android Development] buggerritt:
That's exactly what I did. I read what your request was for and followed it to the letter. I rebooted and immediately made the logcat file as soon as the boot up media scan had finished.
[Epic 4G Android Development] mkasick:
That's definitely the right procedure.

Looking at the log, there's events from /dev/log/system as early as "04-16 08:46:51.678", but /dev/log/main starts at "04-16 09:01:33.182". So it looks like the log I received was taken no earlier than 15 minutes after the phone was booted, and unfortunately, doesn't contain any GPS information earlier than active fix cycles.

Could it have been overwritten by a later logcat? Otherwise something weird is going on.
[Epic 4G Android Development] buggerritt:
I'll make another when I get home. I'm out of town visiting my grandfather, who is on hospice. I haven't had any service for the last 24 hours. I just got into a service area. Sometime tonight or. tomorrow
[Epic 4G Android Development] mkasick:
Sure, take your time, no rush. And thanks a lot!
[Epic 4G Android Development] jdelano:
Things are still working well for me.
[Epic 4G Android Development] squshy 7:
Seems awfully connected to TWS bug.
[Epic 4G Android Development] buggerritt:
Not sure what I am doing wrong, now. I typed the command (adb shell "logcat -v time -d > /sdcard/logcat.txt") in cmd and it said daemon starting blah blah blah device not found.

I did adb devices and get D700cc23fd0f. Then I do the command again and it just says

C:\Users\myname>

I had it working before. wtf?
[Epic 4G Android Development] mkasick:
It happens from time-to-time. Disconnect the device from USB, run "adb kill-server" on your computer, and toggle "USB debugging" off & on again on the phone (which respawns adbd if it died). You'll probably have to restart your phone again in this particular case to get the log from the beginning.

I've never had that problem persist after doing the above. If it does, try rebooting your computer, different USB cable, etc. Definitely annoying.

Edit: If you're leaving your phone plugged into USB while rebooting, try rebooting with it unplugged and plugging it back in only after the system comes up. I definitely have to unplug/replug mine to get it to be recgonized again.
[Epic 4G Android Development] buggerritt:
Ok, I just made this one:View attachment logcat.rar
[Epic 4G Android Development] mkasick:
Thanks! That was rather illustrative.

So on that particular boot your phone was able to download new assistance (XTRA) data successfully. Assuming it's able to do that somewhat regularly on reboot, I wouldn't expect you to have GPS problems in the future due to inability to retrieve updated assistance data--that's good the news.

There's two other interesting things I noticed in the log:

First, it looks like you have quite a few apps & background services launch on boot and use the network, many more than I do, although I have very few. On my phone, pre-workaround, NTP & XTRA is attempted as soon as GpsLocationProvider reports "updateNetworkState available", which is usually what happens when the download fails. On your phone, there's enough going on at boot that a full seven seconds elapsed between the network becoming available and the download attempt. This is quite similar to what the workaround does, but it's a byproduct of the services you have running.

So while that means you shouldn't have much trouble form here-on-out, I do wonder if the download does fail on your phone just after reflashing it, before installing third party apps and setting up syncrhonization services. I don't think it's worth bothering to find out, but it's interesting to know that "doing a lot of network stuff on boot" is quite possibly a factor in whether the GPS works well for some folks.

Second, 39 seconds after your phone's data connection first becomes available, it goes down again for 11 seconds. The phone still hasn't booted to a steady state yet, and some of the running apps (e.g., k9mail) experience network connectivity issues. Not sure why this happens, but if it happens regularly for some folks, this could affect the assistance download if it was done slightly later.

Meanwhile, slwelsh and I successfully debugged the problem he's been running into. It's due to a synchronization bug that results in the GPS crashing on occasion. I've put together a second workaround to fix it that he's been testing, and I'll update the OP in the next day or two with the second workaround and a detailed description of that problem.

One thing to note about it, is that it's often triggered by GPS Status's assistance download. So if you try to download new assistance data in GPS Status while the GPS is actively fixing, most every time the GPS crashes and subsequent fix attempts won't work until power cycled. For folks who have difficulty downloading assistance data on boot, this is one of the methods I would've expected to fix their GPS problems, much like the downgrade method does. But since the crash bug often results in this method failing, I expect that prior to this workaround, most folks were only able to get their GPS to work (initially) via the downgrade method. It's amusing how two otherwise separate issues would interact in that way.
[Epic 4G Android Development] buggerritt:
The reason the data connection goes out and back on after boot, is because i have Tasker set to toggle airplane mode at boot. This solves the TWS bug that seems to still be present in EC05. As far as all the apps that are running at boot, I have had pretty much the same exact setup for a long time. I have things the way I like them and have no reason to change. Before I did the workaround, that I mentioned earlier, I had problems with GPS. The workaround seems to actually fix these issues. I don't know why. It has shown the same results on others, as well. I already mentioned the issues that were present and they are not present, after the workaround. It may seem like a long process but, as a shortcut, it actually has worked on at least 2 devices with a restore. Check out post #9 in the thread. What I really like about it, is that there is no extra software installed. It just works.
[Epic 4G Android Development] mkasick:
OK, that explains it.

It is. I pached it shortly prior to EC05's release, and it's fixed in Bonsai, midNIGHT, SRF, and I'd guess other ROMs too. So airplane mode toggling shouldn't be needed anymore in custom ROMs, although there's nothing wrong with doing it as a precaution.

And it didn't work then?

So we have two confirmed problems that exist with EC05's GPS that I'm trying to address with these workarounds. I believe they exist independent of the downgrade solution. That is, even for folks who do downgrade, their device is still succeptable to these other two problems after upgrading again, although they may not encounter them in practice (as is the case with any EC05 device).

What I don't know, is what the exact issue is that folks run into that the downgrade solution is required to fix. Nor do I know if these workaround also address that issue, or if it's separate. If it's possible to discover that it's a separate problem, and if there's a way to incorporate a fix into these workarounds, that would be ideal.

Unfortunately the log you sent me was inconclusive on that particular issue. We may not know what the actual problem is unless someone who is currently still suffering from it can provide a boot-time logcat.

When exactly did you start having GPS issues that required the downgrade? Was it when upgrading from EB13 to EC05? That is, just after upgrading to EC05 did it no longer work? And it continued to not work even after you setup all the third party apps & synchronization stuff before running the downgrade?

Could you guess how many times you rebooted between upgrading to EC05 and downgrading again? Was it just once, or "quite a few"?
[Epic 4G Android Development] buggerritt:
I can't confirm that it wasn't fixed on my device. I saw that others had experienced the bug in latest midNIGHT ROM so, I just kept my setup the same as it has been for a long time.

No

The issues that we were experiencing was the inability to lock on satellites, after 2 to 5 hours of up-time, poor accuracy, and seeing satellites without being able to lock on them.

I almost wish I could make my GPS not work again just to log/fix it.

I noticed it April 5th after upgrading to EC05. I had already installed all of my apps and had rebooted numerous times.

I could only guess how many times I rebooted but, it was an upgrade from the previous version (that I had been running, since it's release, with no problems). I had been using the ROM for 2 days before applying the downgrade/lock on all startup modes/upgrade workaround. I imagine it was many reboots, since I was unsuccessfully attempting different fixes.
[Epic 4G Android Development] mkasick:
Symptomatic of having a valid almanac, but no-longer-valid ephemeris data.

I may have missed something. So before performing the downgrade, did you always (more or less) have fast fixes just after a reboot, but then they'd "reliably" go to crap 2-5 hours later until the next reboot?

I was under the impression that between upgrading to EC05 and performing the downgrade you never had good fix times. If the former is the case, oh dear, that's something else entirely different from what we've seen as present problems.
[Epic 4G Android Development] buggerritt:
I had great fix times and accuracy before upgrading to EC05. After upgrading, I had good fixes and accuracy at boot but, problems arose after extended up-time.

Some added info: This is a newer phone than the one I had problems on DK28 with. I had lost that phone, had several replacements (refurbs with hardware clitches on each one) until the Sprint store finally gave me a brand new one (with battery, cord, headset, owners manual). I immediately flashed EB13 when I got the new phone and had no problems with it, until EC05.
[Epic 4G Android Development] mkasick:
My apologies. You explained this twice earlier, but somehow I didn't "get it" at the time. We've been looking at a number of GPS issues over the past week or so, and I've been trying to pidgeon hole them in my understand of exactly how many things are going wrong here. Sorry about that.

OK, so now it seems we have four issues with the EC05 GPS:

NTP/XTRA data doesn't download/inject on boot (jdelano; workaround fixes).

Synchronization bug with RIL that causes the GPS to crash (slwelsh; second workaround fixes, will update OP soon with details on it when I finish it).

Ephemeris data becomes stale after H hours. Possibly worked around by keeping ephemeris data up-to-date. But the data is "going stale" in a much shorter period of time (H) than the week XTRA ephemeris data is supposed to be valid for (aero1, buggerritt, slwelsh?).

The amount of time (H) that the XTRA data is consider valid differs across devices (aero1 vs buggerritt).

So it sounds like you suffered the "ephemeris data becomes stale too quickly" issue. Rebooting updates the ephemeris with new XTRA data, which possibly resolves that.

Here's the interesting part: somehow, between upgrading from EB13 to EC05 your phone changed its idea of how long said data is valid for, to ~5 hours. I don't know if this is due to some parameter that acutally is responsible for how long the data is valid, or if it's a matter of the GPS caching a much smaller portion of the ephemeris than it could (only ~5 hours worth).

Downgrading appears to change this, either by changing some "amount of time the ephemeris data is valid for" parameter, or by resetting the cache, or something else. It's unclear at present exactly how long the ephemeris is valid for after downgrading, might be the whole week, but it may still be shorter than that. Since you haven't run into it since, what's your longest phone uptime?

Meanwhile other folks who upgraded from EB13 to EC05 are able to go much longer from boot before seeing invalid ephemeris problems. But it seems in some instances (aero1, slwelsh w/crash fix) it still goes bad in less than 24 hours. I think mine survives the 24 hour mark--I'll check again tomorrow.

So it seems that for folks who have an absurdly low "valid ephemeris" time, downgrading will at least extend it out much longer. For folks whose ephemeris is valid for roughly a day, downgrading might not be worth the trouble to extend it out further, particularly if the workaround here (GPS toggle) will refresh it for another day.

However, it's still not clear to me that the GPS will ever request new XTRA data if it eventually needs it. So even in the best case, the GPS may not survive a week's uptime without an ephemeris refresh. I'm trying to figure that out now, but it takes a week to do so.

I was going to ask that next, thanks!
[Epic 4G Android Development] buggerritt:
I have had up-time go as far as 40+ hours. I almost always charge batteries in a standalone charger and pull them when they gets to about 2-15% charge left. But, I leave the phone on charge some nights when my battery is down to the 20% mark.Most times I just let it go and swap batteries in the am, though. I have 4 batteries so, it's never an issue.
[Epic 4G Android Development] buggerritt:
One of the users, who used the downgrade/workaround, had never experienced fast locks, since owning the device (since the day it was available on the market). After the downgrade workaround, he is getting locks in seconds rather than minutes. The workaround seems to solve more than just the exact issues that I had at this time. It also solved the issues I had back in DK17 and DK28, where I could never almost never get a lock, at all. I think that locking on satellites on all startup modes is key. Something about that ends up sticking to the phone even through an upgrade. I tried the cold start workaround and that didn't do anything for me. So, it's more than just a downgrade and more than just the cold start workaround. It can't be coincidence, either. I've seen positive results too many times from too many people with various GPS issues for me to believe that. So, whatever is sticking, after the fix, is what you might want to look for. If you know anyone else, who is still having GPS issues, maybe they could make a logcat file, do the workaround steps, and then make another logcat file (after noticing the fix).

I'm thinking that we should call it something else. Just to avoid confusion, maybe we could call it the multi-lock workaround. Downgrade sounds like we just flash back to an old version and then re-flash to the new.
[Epic 4G Android Development] mkasick:
Updated the OP with the crash workaround and revised content.

Feel free to test the crash workaround, particularly if you encounter GPS crashes on a regular basis.
[Epic 4G Android Development] supercluver:
Here is my GPS issue, which seems to have gotten quite a bit better since DK28. In fact with EB13 and then EC05 it happens pretty rarely, but I still see it from time to time, I just don't use GPS (google navigation) that often.

I get VERY fast locks on my location. Even in-doors. I'll start driving and google navigation is fine. After a while though, it stops following me, then it will say the GPS signal is weak or it has been lost. Then after a while, several seconds to several minutes, I will see on the map a blue dot with a huge circle around it which is where I am, more or less. It will get more accurate, until it is back to following me exactly at my location. Toggling the GPS off/on will quickly get it back to following me exactly if I don't feel like waiting.

Like I said, it happened all the time with DK28, but it is much less frequent now on EC05. What are your thoughts mkasick? Would the crash workaround help? I've read through this thread but it's still not entirely clear to me.

I'm using Bonsai 4.0.1 ROM, Genocide 1.0 kernel, EC05 modem.
[Epic 4G Android Development] mattallica76:
I had this issue a couple times on DK28 based ROMs. I thought it was related to the GPS config files ROM devs were dropping into their ROMs to "fix" GPS.