Related
Hi
i have no issues with wifi but
i am on android 2.2.1 cyanogen rom on htc magic 32B.. sometime 2G connection gets silenced. any ping thing using less data to keep it alive ?pinging every 10-20 seconds or similar? how can i keep 2G awake with least data traffic used and least battery usage. any app out there for 2G?
P.S. not asking about wifi.
irisiris said:
Hi
i have no issues with wifi but
i am on android 2.2.1 cyanogen rom on htc magic 32B.. sometime 2G connection gets silenced. any ping thing using less data to keep it alive ?pinging every 10-20 seconds or similar? how can i keep 2G awake with least data traffic used and least battery usage. any app out there for 2G?
P.S. not asking about wifi.
Click to expand...
Click to collapse
I've never heard of a cellular connection having such issues, but I guess it'll drop after a while with no traffic. I personally have email on IMAP idle going all of the time so I guess I'd never have this problem. What's the issue, it takes a second to reconnect?
I am also looking for an app to do this. my epic touch data connection keeps dying. once I get it if I keep using it its fine. but if i let it go idle it won't "reconnect" I can turn off 3g and then turn it back on and usually get it back as long as I keep it active.
SO also looking for a background "pinger" to keep the data connection alive till I get a fix for the connection issues.
DRiVER_helsinki said:
that "3G reconnet" - app didnt work as required...
i found solution:
"Android Terminal Emulator" , from google play.
Type in “ping -i5 www,google.com” , to start pinging with 5 second interval.
Press Home button and the Terminal Emulator will run in the background until you decide to stop it manually.
(Do this only if you have Unlimited Data Usage plan ofc )
[ps. i replaced first dot in the ping address with comma ,because xda think i as new member , are linking outside and complains. )
____________________________________________________
Shoutout to Kimi Räikkönen !
Click to expand...
Click to collapse
Clearing this up...
type:
Code:
ping -i 5 8.8.8.8
Where:
-i = interval of the address to be pinged with.
5 = number of seconds after a successful/unsuccessful ping.
8.8.8.8. = Address to be pinged onto.
So by that command, you'll ping the Google Server (8.8.8.8) within every 5 seconds...
Oh yeah, by the way, after you exit the Terminal Emulator, the pinging stops. So just run TermEmu on background (Home)...
Great tip. Thank you.
Since the middle of November (the 14th is the best guess of the date) network location services have not worked properly for a number of people using network-unlocked android phones on the Rogers network. Network location services refers to cell tower location information used to determine the rough location of the phone without using GPS or WiFi.
The problem:
1. Devices are able to determine location using network location after a fresh OS install (ROM Flash) or a factory data reset and full wipe of all caches.
2. Devices are not able to determine location using network location after the phone has been restarted.
What is known:
1. The problem occurs on different hardware (Nexus one, HTC Desire, HTC Desire Z, Samgung i9000m).
2. In Canada the problem is specific to Rogers’/Fido network. These same devices use network location services without problems when used with a Bell or Telus SIM card. There are reports in this thread of similar problems occurring on US carriers as well.
3. The problem appears to be specific to Froyo (Android 2.2).
Temporary Work Around:
Manually stopping the Google Services Framework, clearing data and cache (via Settings>Applications>Manage Applications>All) and rebooting allows the device to use network location services again - until the next reboot. This procedure will mess up your Market temporarily...simply uninstall one of your market apps and re-install and it will work. Alternatively Force Stop Market and clear data and cache (may need to be done twice).
Dec 4th Update:
I've found a fix that works for some devices (mine included). See: http://forum.xda-developers.com/showpost.php?p=9576852&postcount=108
Other Device Specific Threads related to this topic:
N1: http://forum.xda-developers.com/showthread.php?t=849969
DZ: http://forum.xda-developers.com/showthread.php?t=848793
SGS: http://forum.xda-developers.com/showthread.php?t=850784
Google thread dealing with this issue:http://www.google.com/support/forum/p/Google+Mobile/thread?tid=310dd072d5f565ee&hl=en&start=40
Ok...I've done some more digging and am really stumped by my problem...and am hoping someone more experienced could help shed some light on what might be going on...
After no less than 15 full wipes (from recovery) and reflashes (with 4 different ROMs) I experience the same following problem with location services;
1) On the very first boot up following a ROM flash, once I enter my APN settings my HTC Desire immediately picks up my location (GPS and WiFi Off) and correctly displays my home location in the HTC weather widget. If I launch Google Maps, it can also track my location without GPS or WiFi (i.e. just cell network connection).
...but
2) As soon as I reboot my device after a fresh flash, all location services stop working. HTC weather widget will for ever after just show "Current Location" and Google Maps will no longer track my motion without WiFi or GPS.
Pulling some logcats shows the following;
After initial boot up following a full Wipe and ROM flash I get the following logcat entires for the weather widget collection my home location (Toronto).
11-21 08:24:45.070 D LocationMasfClient 184 getNetworkLocation(): Location not found in cache, making network request
11-21 08:24:45.090 V AlarmManager 184 Adding Alarm{47e71b30 type 2 com.google.android.location} Dec 31 07:14:56 pm
11-21 08:24:45.410 D dalvikvm 184 JIT code cache reset in 8 ms (1048452 bytes 1/0)
GC_FOR_MALLOC freed 36270 objects / 1612088 bytes in 92ms
11-21 08:24:45.650 D LocationMasfClient 184 getNetworkLocation(): Number of prefetched entries 1
getNetworkLocation(): Returning network location with accuracy 1100.0
11-21 08:24:46.400 I HtcLocationService 585 agent - search location by name: toronto, country: canada
11-21 08:24:46.421 I HtcLocationService 585 agent - location was found, code: NAM|CA|ON|TORONTO, name: Toronto, country: Canada, state:
11-21 08:24:46.701 I HtcLocationService 585 agent - send current location notify intent, name: Toronto, state: Ontario, country: Canada, lat: 43.635040, lng: -79.468483,tzid: America/New_York
11-21 08:24:46.720 D AutoSetting 585 service - CALLBACK - onSetWeatherProvider, result: success
11-21 08:24:46.740 I WSP 585 [Receiver] EVENT - CURRENT LOCATION CHANGED
Click to expand...
Click to collapse
Following my first reboot (after all 15+ wipe and ROM reflashes) I get the following entries in my logcat...showing location service failing.
11-21 07:13:05.421 W System.err 338 java.io.IOException: Unable to parse response from server
at android.location.Geocoder.getFromLocation(Geocoder.java:117)
at com.htc.htclocationservice.HtcLocationServiceAgent.searchSyncFromGgeocoder(HtcLocationServiceAgent.java:519)
at com.htc.htclocationservice.HtcLocationServiceAgent.access$400(HtcLocationServiceAgent.java:31)
at com.htc.htclocationservice.HtcLocationServiceAgent$6.run(HtcLocationServiceAgent.java:914)
at java.lang.Thread.run(Thread.java:1102)
11-21 07:13:05.561 I HtcLocationService 338 agent - send current location notify intent, name: , state: , country: , lat: 43.635196, lng: -79.470171,tzid:
11-21 07:13:05.581 D AutoSetting 338 service - CALLBACK - onSetWeatherProvider, result: failed
Click to expand...
Click to collapse
Any thoughts/clues as to what could possibly be causing location services to work on first bootup...and then for ever after stop working after the first subsequent reboot!? Makes no sense.
Ok, first, I have (had) the same problem. As I already answered on Leedroid thread, I've "solved" it by deleting town I'm in from Weather, than added it again. If it doesn't help, nevertheless stop flashing, it sorts itself out after some time, I know cos I already had they problem earlier.... ROM manager does not help, nor does maps/GPS. Cheers!
Damn it, it's back Well, that much for "solution", as soon as I turned wifi on (data went off) it shows Surgutski reyon...
This is so weird.
So to troubleshoot further;
1) A friend with the same phone on a different network (Telus vs Canada) was able to get cell-tower-only location based services (HTC Weather and Google Maps) to work while we were in the same location. So HTC+Telus = Works. HTC+Rogers = Fail
2) Another friend with a different phone (Samsung) on the same network and the same physical location was able to get google maps location based services working on cell phone towers only...while mine still did not work. So Samsung+Telus=Works. HTC+Rogers=Fail
3) Putting the sim card of my friend's (#2 above) into my phone still did not get location based services to work. So not a problem with my sim card (suggested by Rogers)
4) I've fully wiped my phone. Reformatted my SD card and repartitioned it. Reflashed a ROM....location based services work initially. So it is not a hardware or radio problem.
5) After first reset it stops working and never comes back....so wtf!?
wtf... I one thing I haven't tried is put a Telus sim-card into my phone to see if my phone/ROM will get location based services through Telus. Or I guess I could flash a stock ROM...maybe I'll wait for a week to see if things settle themselves out as you suggest...
*groan* I hate it when things don't work the way they should...
Rumball said:
*groan* I hate it when things don't work the way they should...
Click to expand...
Click to collapse
yes, I know what you mean. Last night when my location went bananas, my clock also went bananas, that is it went 2 hours ahead of our local time. Since I use Desire for alarm, I went to Clock, Menu, Local time Settings, and cleared Automatic (use network-provided values). The clock returned to normal, and so did the location.
I'm surprised only two of us reported this problem. TheIntruder claims it's Google related - there was a box to be checked during setup, something like "allow Google to use your location". I did checked that box, if I remember correctly.
This "method" of mine is like shooting in the dark, I'm afraid.
Hey there Rumball!
Just wanted to let you know that I'm also having the same problem with my unlocked Nexus One (I'm also with Rogers). It started around the same time as your first post. I can get the cell tower location working after I get a WIFI fix but if I moved out of my "zone" after that it just doesn't update.
Anyway I guess I'm happy because I'm not the only one with the problem and it does seem related to Rogers. I do have a friend working as a field tech at Rogers, I'll try to contact him and I'll let you know.
Greetings all,
I am experiencing precisely the same problem. I am using a Samsung i9000M (Bell Vibrant) unlocked on the Rogers network, and sometime in the last two weeks cell-based network location ceased working.
I can add a little information to the discussion, though:
I have a rogers-branded Bold 9000
I have an unlocked Samsung i9000M (currently running Doc's deodexed Bell Froyo leak)
I have a Rogers SIM and account
I have a Bell SIM and account
I just got a new SIM from Rogers (at 16:00 today)
A friend has a Bold on Rogers
i9000M + Old Rogers SIM = fail
i9000M + various ROMS + Old Rogers SIM = fail
i9000M + Bell SIM = SUCCESS (1 trial, no ROM changes)
Bold + old Rogers SIM = fail
Bold + new Rogers SIM = success (1 trial)
Bold + Bell SIM = N/A (i didn't have the apn settings, and don't have a Bell BIS account)
and finally
i9000M + new Rogers SIM = fail (both before and after wiping cache and dalvik)
Friend's Bold = always success
when I get the chance (probably tomorrow afternoon, or Friday) I will attempt to verify:
i9000M + new SIM + fresh ROM flash
i9000M + Bell SIM + multiple trials
Bold + new SIM + multiple trials
until then...
I sure am tempted to switch to Bell full time, if that's the only way to use a good android phone in Canada.
Here's an update:
i9000M + Rogers SIM + wipe (cache, factory, dalvik) = fail to find location
i9000M + Rogers SIM + wipe + flash Doc_V1.1_Bell I9000UGJK3 = finds and tracks location
BUT... fails (network location temporarily unavailable) after first restart (absolutely nothing else changed)
Bold 9000 + Rogers SIM = success
i9000M + Bell SIM = success, every time (app installs, restarts, etc.)
Colour me baffled. It's as if the phone itself doesn't want to work with Rogers (or vice versa).
Quantus/jehuty140,
Thank you thank you thank you! I was starting to go crazy trying to reflash my device over and over again. It seems fair to say that something is going on with Rogers.
I contacted Rogers recently because "coincidentally" on around the day that my cell phone location services stoped working, Rogers announced "Rogers Catalyst" which is a network API functionality they have opened up to developers...and one of these API features is Rogers location based services. I don't like coincidences so I contacted them. There response to me was
"The introduction of Rogers Catalyst location APIs has no correlation to the use of on-device location services. The Cell Tower triangulation for mapping features on Android devices such as your HTC device is a function provided by Google. We do not block these services from working on our network"
Now that I see there are others with the same problem I will respond to them and let them know that something is going on with their network (especially since both me and Quantus have tried another Rogers SIM card with no success, while a Bell SIM card does work).
Just noticed that in all cases that we have mentioned, it is the unbranded phones on the Rogers network that fail network location services. Rogers branded phones seem to work fine.
What's interesting is that if you download the app "Antennas" from the android market place, you can successfully locate yourself via the cell tower triangulation. So there is nothing wrong with our phones's hardware...it has something to do with how Rogers and google location services interect...
Yeah I noticed that too. Although I have yet to try a branded Rogers phone myself, it does seem a little bit odd that only the unlocked unbranded ones aren't working properly. I hope Rogers is not messing with that service because otherwise they're about to lose a customer. After all, that's the reason why my phone is unlocked. I don't wanna be tie to a carrier.
Yes, it does seem a little short sighted, IF Rogers has intentionally messed with network location for unbranded phones. After all, they make their money on the service, and not on the phone. But, it is SO short sighted that I have a hard time believing that Rogers has done it intentionally.
FWIW, I started another thread here: http://forum.xda-developers.com/showthread.php?t=850784 (as I have an SGS i9000m). Over there AllGamer (one of the first buyers/unlockers of the SGS) is using his i9000m on Fido without problems.
I wish I had access to a Fido SIM card!
For the record, did we all begin experiencing the problem at about the same time? Something like Nov. 14th?
Quantus said:
For the record, did we all begin experiencing the problem at about the same time? Something like Nov. 14th?
Click to expand...
Click to collapse
Yep...Nov 14th is about the timeframe when my problems started to occur.
FYI...I have also been in contact with HTC technical support and their response was that it was likely a Rogers problem. Suggesting; "It may be that your phone isn’t properly provisioned on the network, and it is sticking to one tower. They will need to reprovision you, the same as if you were with a different carrier." Will be contacting Rogers support later today to give it a try.
I have the same problem, I jsut re-flashed my Sony Ericsson x10 to the factory rom and everything was fine, the only change i made was i rooted the phone.
do you think google started checking the phone status before validating the location?
ratheen said:
I have the same problem, I jsut re-flashed my Sony Ericsson x10 to the factory rom and everything was fine, the only change i made was i rooted the phone.
do you think google started checking the phone status before validating the location?
Click to expand...
Click to collapse
Interesting question. Are you on Rogers network as well?
Are we all using rooted phones with custom ROMs? I am.
My phone is rooted, I use LeeDrOiD 2.2f, and I'm on Russian Beeline. Problem started earlier than Nov.14th. And, if I'm sticking to one tower, that one is 2000km away. Not likely.
Sent from my HTC Desire using XDA App
Hey folks. I think I found a work around.
Go to Settings>Applications>All
Find Google Services Framework. Force Stop, Clear data and Clear Cache.
Reboot your device and cell tower location services should work again.
After doing the above your market place will be all messed up. To fix, go to Settings>Applications>All, find Market, Force stop, clear data and clear cache. Market place should now work.
The above works for me. Unfortunately the next time you reboot the device it looks like location services are lost again...but doing the above steps restores it again.
Hope it works for others.
I have a bone stock Nexus One with the latest version of 2.2.1 and I am experiencing the same problem. My brothers Girlfriend has a bone stock Nexus One as well but on Telus and is not experiencing a problem.
Not sure if that helps the troubleshooting process but thought I would chime in.
Thanks for the tip Rumball.
It seems to be the only workaround so far.
I talked to my friend working on the antennas at Rogers and he told me that nothing special was going on that could affect the location. In fact, even is unlocked iPhone 4 was working perfectly. Maybe the problem is a combination of both Google and Rogers.
I've had my SGS4G for about a month now and, until recently, it seemed reliable in connecting to wifi networks, both open and WPA2/PSK. Recently, it has started to not be able to connect when "turning on" the wifi, generally through the pull-down from the status bar, or through WiFi Widget. Going to the Settings > Wireless and network > Wi-Fi settings page shows, when it had failed, "Error" under the "Wi-Fi" heading. Generally, if I try to turn it on from there, it will "try" for a while and usually result in "error" again. Sometimes returning to the home screen (Go Launcher, in my case) and trying again will result in a connection, but not consistently.
Stock kernel, firmware, etc.
Looking at the logs, it appears that the kernel module is not loading. For example
Code:
V/WifiProgressStore(18818): WifiProgressStore Created
E/WifiHW ( 2482): return of insmod (args:firmware_path=/system/etc/wifi/bcm4329_sta.bin nvram_path=/system/etc/wifi/nvram_net.txt dhd_watchdog_ms=10 dhd_poll=1) : ret = -1, Invalid argument
E/WifiService( 2482): Failed to load Wi-Fi driver.
as opposed to a "good" load
Code:
I/WifiHW ( 2482): [WIFI] Load Driver
I/WifiHW ( 2482): [WiFi.c] insmod() Start!!
I/WifiHW ( 2482): [WiFi.c] start init_module() Start!!
Removing WiFi Widget (com.rb.wifiwidget) has not resolved the situation.
Is this something that anyone else has run into?
Amusing update -- For a brief while, I was seeing both the WiFi and 4G emblems in the status bar.
I'm trying removing mirin browser, which has a wifi-state listener (who knows why) and will try killing DriveSmart if the problem persists.
jeffsf said:
I've had my SGS4G for about a month now and, until recently, it seemed reliable in connecting to wifi networks, both open and WPA2/PSK. Recently, it has started to not be able to connect when "turning on" the wifi, generally through the pull-down from the status bar, or through WiFi Widget. Going to the Settings > Wireless and network > Wi-Fi settings page shows, when it had failed, "Error" under the "Wi-Fi" heading. Generally, if I try to turn it on from there, it will "try" for a while and usually result in "error" again. Sometimes returning to the home screen (Go Launcher, in my case) and trying again will result in a connection, but not consistently.
Stock kernel, firmware, etc.
Looking at the logs, it appears that the kernel module is not loading. For example
Code:
V/WifiProgressStore(18818): WifiProgressStore Created
E/WifiHW ( 2482): return of insmod (args:firmware_path=/system/etc/wifi/bcm4329_sta.bin nvram_path=/system/etc/wifi/nvram_net.txt dhd_watchdog_ms=10 dhd_poll=1) : ret = -1, Invalid argument
E/WifiService( 2482): Failed to load Wi-Fi driver.
as opposed to a "good" load
Code:
I/WifiHW ( 2482): [WIFI] Load Driver
I/WifiHW ( 2482): [WiFi.c] insmod() Start!!
I/WifiHW ( 2482): [WiFi.c] start init_module() Start!!
Removing WiFi Widget (com.rb.wifiwidget) has not resolved the situation.
Is this something that anyone else has run into?
Amusing update -- For a brief while, I was seeing both the WiFi and 4G emblems in the status bar.
I'm trying removing mirin browser, which has a wifi-state listener (who knows why) and will try killing DriveSmart if the problem persists.
Click to expand...
Click to collapse
this happens to me all the time, i see 4g and wifi on and supposedly connected. I think we are going to need a patch from samsung to fix it. I love this phone but wifi on this thing is totally ridiculous
Ok I think I have found the cause of this problem. Everytime when my RAM runs low the Wifi have trouble turning on. Especially when I have less than 50MB Ram. If I go to Task Manager and free up some RAM the Wifi will start working again.
kirbychiu said:
Ok I think I have found the cause of this problem. Everytime when my RAM runs low the Wifi have trouble turning on. Especially when I have less than 50MB Ram. If I go to Task Manager and free up some RAM the Wifi will start working again.
Click to expand...
Click to collapse
I did the fota fix (frees up about 200 megs of ram) and I still have wifi connectivity issues...
Sent from my DAMN Galaxy 4G¡!
Success100 said:
I did the fota fix (frees up about 200 megs of ram) and I still have wifi connectivity issues...
Sent from my DAMN Galaxy 4G¡!
Click to expand...
Click to collapse
No I mean the RAM, not the internal storage. If you hold the home button and go to task manager, there is a RAM manager and it lets you clear up memory by closing down some apps. Wifi should work after that.
I experience these issues as well.
Galaxy S 4G
It's not an available RAM issue and killing DriveSmart does not resolve this (as suggested in another thread). Removing Mirin Browser and WiFi Widget did not resolve either.
Seems as if the wifi issue is a factor in the wifi not connecting. I just got the wifi error and clearing the ram made the wifi hooked right up
Sent from my DAMN Galaxy 4G¡!
Hello,
Wanted to see if someone found a solution for this?
I'm facing the same problem on a Vibrant, same messages in the logs.
Unrelated to RAM unfortunately.
Just curious, anyone here running JuiceDefender?
Thanks,
Sinan.
4/20/11 Update: Added a second workaround for the libsecgps synchronization bug that otherwise allows multiple GPS requests to be sent to the RIL, causing the GPS to crash on assistance downloads (via GPS Status & Toolbox) and on application switch/exit. Details on this and the assistance workarounds, which are complementary to each other, follow below.
To folks with GPS problems:
If your GPS reliably works after a reboot, but ceases to work after appreciable uptime, it's quite likely that one or both of these workarounds will address the issue. Try the crash workaround first, as all EC05 Epics are vulnerable to the libsecgps synchronization bug, whereby the GPS crashes and is only recoverable by a full power cycle. If you continue to have issues, the assistance workaround may further help by keeping your assistance data fresh.
If your GPS rarely or never works in EC05, even outdoors with clear skies, even after a reboot, it's quite possible the assistance workaround will help. But please post in the thread or PM me first, as I'm interested in obtaining a boot-time logcat that would confirm the exact issue you're suffering.
Summary of issues discovered and/or resolved in this thread:
NTP/XTRA data doesn't download/inject on boot (jdelano; addressed by assistance workaround).
Synchronization bug with RIL that causes the GPS to crash (slwelsh; addressed by crash workaround).
Stale ephemeris (from XTRA data) after a few hours to a day of uptime. Possibly addressed by assistance workaround, needs confirmation (aero1, buggerritt, slwelsh?).
Time until ephemeris becomes stale differs across devices. Unknown cause, although a separate workaround exists to improve this to a day or longer (buggerritt).
4/11/11 Update: Fixed the update.zips so they actually flash in ClockworkMod. Apparently /system needs to be mounted, which it already is in stock recovery.
GPS assistance workaround:
Attached is a platform source patch against android-cts-2.2_r2 that, hopefully, works-around most assistance-related EC05 GPS problems by modifying the GPS location provider to download & inject time (NTP) and assistance (XTRA) data every time the "Use GPS satellites" setting is enabled. Also attached is a smali patch against EC05's /system/framework/framework.odex that implements this workaround in bytecode.
Finally, attached are testkey-recovery (e.g., ClockworkMod) flashable "update.zip"s including modified a modified framework.odex or framework.jar for: (i) the EC05 stock ROM, (ii) deodexed (framework-unmodified) ROMs, (iii) SyndicateROM Frozen 1.1.0 and (iv) midNIGHT ROM 5.2. All three implement the GPS workaround, and the first two also contain the TWS bug fix and ringer volume control mod. I'll try to take requests for additional ROMs as I can.
Assistance workaround directions:
Once flashed, keep the "Use GPS satellites" setting/notification widget toggle off until you're ready to use GPS. While having (any) active data connection, toggle GPS on and wait about five seconds before attempting a GPS fix.
Alternatively, if you always keep the GPS toggle on, toggle it off & on again to download new assistance data when you have difficulty getting a fix.
Assistance background:
In Froyo, the Epic GPS works in "standalone mode" with various types of supplemental assitance data pushed ("injected") by the GPS location provider if they're available. This includes:
XTRA (ephemeris & almanac) data: Downloaded and pushed automatically on reboot after a network connection is established.
NTP time: Nominally pushed after reboot and every four hours thereafter.
Location: Location data from other providers (e.g., cellular, wifi, etc.).
The XTRA ephemeris data, combined with a rough estimate of current location and an accurate (NTP-synced) clock, provides the GPS receiver with precise orbital positions of each satellite, allowing the receiver to quickly lock onto them even in weak signal (e.g., indoor) conditions or in the present of multipath (e.g., high-rise buildings). The gpsonextra servers appear to update XTRA data every hour at half-past. It's ephemeris data is (to the best I can discern) supposed to be valid for one week, although it's speculated that the Epic GPS may consider this data stale after a much shorter period of time, perhaps a few days, and in some cases, no more than a few hours.
The almanac data provides the GPS receiver with coarse orbital parameters of each satellite, allowing the receiver to locate the satellites reasonably quickly when outdoors with clear sky visibility. However, in absence of recent ephemeris (e.g., from XTRA or a previous fix), the receiver must download the current ephemeris from each satellite. Satellites broadcast their own ephemeris every 30 seconds, and thus, the receiver requires 30-60 seconds of strong signal from each satellite in order to obtain its ephemeris and lock onto it. The ephemeris broadcast from the satellite is valid for five hours, much less than that of the XTRA data. Each satellite also broadcasts the almanac data for the entire constellation every 12.5
minutes, and this data is valid for a few months.
This all means that, an Epic with recent XTRA data, NTP sync, and location estimate should be able to lock onto any visible satellite quickly (less than 10 seconds), possibly even indoors, whereas an Epic with stale ephemeris will fall back to using almanac data and should fix within a minute outdoors with clear sky visibility. Thus, Epics that take a long time to fix or can't fix indoor likely suffer from stale ephemeris. However, as long as these phones retain a GPS fix for at least fifteen minutes once every month or so, their almanac data will be fresh enough to operate indefinitely in this degraded mode.
Assistance workaround details:
XTRA data is downloaded automatically on boot, but it isn't downloaded again unless requested by the GPS receiver. Although this data is supposed to be valid for one week, folks report that their Epics take a long time to fix (30+ seconds) after a day, or even just a few hours of uptime, suggesting that the ephemeris downloaded at boot data becomes stale.
I don't know the root cause of why this data becomes stale, although it seems that temporarily downgrading and obtaining fixes in DI18 will improve the amount of time the ephemeris is considered valid to a day or longer in instances where it's only good for a few hours.
The idea behind this workaround is to exploit a simple heuristic: by activating the GPS toggle the user intends to use GPS for a while, so that's (probably) the best time to download new assistance data. Even if the toggle is left on all the time, it's an intuitive means to "reset" the GPS that most users will try, so it should download new assistance data every time. So while this might not directly fix the stale-ephemeris issue, hopefully this workaround will make the current and future assistance problems less relevant since they're easily bypassed.
A second issue is that NTP time and/or XTRA data often fails to be acquired on boot. The GPS location provider waits until there's an available network connection before connecting to the NTP and XTRA servers. However the "network available" notification doesn't quite work right, and the initial NTP request may happen before DNS resolvers are registered and the NTP request fails hostname lookup. While I never observed a failed XTRA download on my phone due to lookup failure, this seems to be the case with others. If you have trouble acquiring a fix even after a reboot, failed XTRA downloads may be to blame.
Since this workaround doesn't attempt to do NTP/XTRA until the GPS is enabled, this should no longer be an issue. However, to ensure it works in most instances when the GPS is left enabled across a reboot, I've added a network-notification settle delay of 5 seconds, which should be long enough (2.5 seconds is the longest it took my phone to settle) that NTP/XTRA will work on boot in that instance.
GPS crash workaround:
Attached is a platform source patch against android-cts-2.2_r2's liblog that avoids the GPS crash that happens when multiple GPS requests are sent via libsecgps to the RIL, which occurs during assistance downloads (via GPS Status & Toolbox) and on application switch/exit.
Also attached is a testkey-recovery (e.g., ClockworkMod) flashable "update.zip"s including a patched liblog.so for all EC05 (stock, deodexed, and custom) ROMs. I've also attached a "backout" update.zip that replaces liblog.so with the original EC05 version, should anyone wish to revert to it.
Crash workaround directions:
None, it works automatically once flashed.
Crash background:
The Epic's GPS receiver is integrated into the baseband, and communication with it is done via the Radio Interface Layer (RIL). The native library, libsecgps.so, implements various GPS-oriented commands (open, stop, location_fix, inject_time, xtra_set_data, and others) as requests, via the RIL, to be performed by the baseband processor and GPS receiver.
When a GPS app runs, location_fix requests are issued (synchronously) by a native library timer once every second while the app is actively seeking fixes. When a GPS app is closed or suspended, a stop request is issued to the GPS to cease fixing on satellites. Regarding these stop requests, it's important to note that: stops are often asynchronous, being the result of user action; and there appears to be no locking to ensure that a stop request is performed outside a location_fix cycle.
That is, a stop may come: (i) just prior to a location_fix request being issued, (ii) just after a request is issued but before it's sent to the baseband, (iii) after the baseband receives the request and performs the fix, and (iv) after the resulting location data is sent back (which completes a location_fix cycle).
A stop performed outside a location_fix cycle (iv) is most preferable, but due to the length of a location_fix cycle (~0.7 s) this happens only a third of the time. Most often, a stop if performed while a fix is actively being performed (iii) which results in a harmless recoverable error. However, if a stop is performed just before a location_fix is issued (i) or just after (ii), before the baseband can fully receive it, then the two requests may collide, throwing the baseband-side GPS functionality into an unrecoverable error state that is resolved only by a power cycle.
The critical window here is approximately 60 ms wide, meaning that the GPS crashes with 5% probability during a stop, or any other asynchronous request that occurs while the GPS is actively fixing. In other words, on average, every 20 GPS app closes/suspsends results in a GPS crash. For folks who use the GPS once or twice the day during a long navigation session, a crash may rarely be observed. For folks who use various GPS-utilizing apps throughout the day, crashes happen regularly after a day or two of uptime on average.
It's also worth noting that an XTRA download issues 40 xtra_set_data requests in a short window of time (~7 s). While these are safe outside an active fix (e.g., on boot or GPS toggle w/assistance workaround), if an assistance download is performed during active GPS use, e.g., via GPS Status & Toolbox, the GPS almost always crashes and the download fails. This is actually why GPS Status's assistance features appear not to work in Froyo, although with the crash workaround, I believe they do.
GPS workaround details:
Ultimately the GPS crash is due to insufficient locking in libsecgps that enables the interleaving of simultaneous requests to the RIL. Although we've observed instances where libsecgps appears to defer requests, it's locking behavior is insufficient to prevent interleaving in many instances.
For illustrative purposes, here's an excerpt of the log statements produced by libsecgps when properly processing a location_fix request:
Code:
...
D/libgps ( 2931): send_ril_gps_location_fix_req: start_mode 1
D/libgps ( 2931): newGpsRequest: new gps req 0x4303c8 cmd 5, idx 1
D/libgps ( 2931): send_ril_gps_request: cmd 0x05 plen 18
D/libgps ( 2931): ril_gps_wait_for_ril: req 0x4303c8 wait 1000
D/libgps ( 2931): ril_gps_wait_for_ril: +++entering
D/libgps ( 2931): ril_gps_wait_for_ril: current tv_sec 1302648124 tv_nsec 519263548
D/libgps ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302648125 tv_nsec 519263548
D/libgps ( 2931): onRawReqComplete: oem_function_id 0x0E cmd 0x05 len 4
D/libgps ( 2931): process_response: req 0x4303c8 cmd 0x05 plen 1
D/libgps ( 2931): recv_ril_gps_location_fix_req: status 0
D/libgps ( 2931): ril_gps_wakeup: 0x4303c8
D/libgps ( 2931): ril_gps_wakeup: Entered critsec
D/libgps ( 2931): ril_gps_wakeup: Left critsec
D/libgps ( 2931): ril_gps_wait_for_ril: (n=0, r=0)
D/libgps ( 2931): removeGpsRequest : removed req with cmd 5
...
The newGpsRequest function is called by the issuing thread for each request. Requests are then sent to the RIL (send_ril_gps_request) and the issuing thread waits on a condition varible (ril_gps_wait_for_ril). The RIL wakes up (ril_gps_wakeup), sends the request to the baseband, and signals the issuing thread to wake again. The issuing thread then deletes the request (removeGpsRequest).
For comparison, here's an excerpt of the log when a stop request interleaves a location_fix:
Code:
...
D/libgps ( 2931): send_ril_gps_stop_req:
D/libgps ( 2931): newGpsRequest: new gps req 0x3900f8 cmd 6, idx 2
D/libgps ( 2931): send_ril_gps_location_fix_req: start_mode 1
D/libgps ( 2931): newGpsRequest: new gps req 0x390958 cmd 5, idx 1
D/libgps ( 2931): send_ril_gps_request: cmd 0x05 plen 18
D/libgps ( 2931): ril_gps_wait_for_ril: req 0x390958 wait 1000
D/libgps ( 2931): ril_gps_wait_for_ril: req 0x3900f8 wait 1000
D/libgps ( 2931): ril_gps_wait_for_ril: +++entering
D/libgps ( 2931): ril_gps_wait_for_ril: +++entering
D/libgps ( 2931): ril_gps_wait_for_ril: current tv_sec 1302652321 tv_nsec 191173085
D/libgps ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302652322 tv_nsec 191173085
D/libgps ( 2931): ril_gps_wait_for_ril: current tv_sec 1302652321 tv_nsec 210846213
D/libgps ( 2931): ril_gps_wait_for_ril: timeout tv_sec 1302652322 tv_nsec 210846213
D/libgps ( 2931): ril_gps_wait_for_ril: (n=110, r=0)
E/libgps ( 2931): ril_gps_wait_for_ril: pthread_cond_timedwait error. (n=110, r=0)
E/libgps ( 2931): RIL Request: ERROR 1 (n=110, r=0)
D/libgps ( 2931): removeGpsRequest : removed req with cmd 6
D/libgps ( 2931): ril_gps_wait_for_ril: (n=110, r=0)
E/libgps ( 2931): ril_gps_wait_for_ril: pthread_cond_timedwait error. (n=110, r=0)
E/libgps ( 2931): RIL Request: ERROR 1 (n=110, r=0)
D/libgps ( 2931): removeGpsRequest : removed req with cmd 5
...
This time, a second newGpsRequest (location_fix) appears before the first (stop) request completes. Both threads appear to send their requests to the RIL, but the RIL never wakes up (no ril_gps_wakeup). Although it likely does, sees invalid data in its request buffer, and dies or something. Meanwhile the two issuing threads wait on the condition variable, which is never signaled. Eventually the condition variable times out and the request fail. At this point, the GPS has effectively crashed, as any subsequent GPS request to the RIL fails with the same error.
Fixing this synchronization bug involves either repairing the existing libsecgps locking logic, or adding new logic to prevent the interleaving of two or more requests. Unfortunately it's quite difficult to diagnose, repair, patch, and subsequently maintain said patch for source-code-less native libraries.
However, as libsecgps frequently makes use of logging statements, as illustrated above, during the processing of GPS requests, we can instrument the logging library to hijack the log calls and provide the necessary synchronization. Since libsecgps uses the logging routines provided by liblog, a library unmodified-by-Samsung for which we have source code, this is where the workaround code is placed.
Specifically, this workaround modifies liblog's __android_log_print's to look for logging messages made by libsecgps (libgps). Each newGpsRequest log statement signifies the creation of a request. When a second request (newGpsRequest statement) is encountered before an outstanding request completes, liblog defers the request by forcing the issuing thread to wait on a condition variable that's later signaled by the completion of RIL receiving the first request (ril_gps_wakeup). This prevents two requests from interleaving, and provides the necessary synchronization to prevent a GPS crash.
Final notes:
At this point the assistance workaround has been tested by multiple parties, some of whom have reported an improvement in GPS fix times, and none of whom have reported side-effects or adverse behavior.
The crash workaround has been tested by myself and slwelsh for three days now without either of us experiencing a crash or side-effects. At this point, I invite others to test the crash workaround, particularly if you experience them on a frequent basis as well.
As usual, please keep a copy of Odin and a stock/custom ROM tar file on hand, just in case something silly happens and your phone is bricked.
Also, while we've had a lot of feedback on folks's GPS issues already in this thread, I'd still appreciate feedback on whether these workarounds help you, or if you have a different GPS-related problem that you believe is not yet addressed by these.
Assistance workaround (mirror links, do not require forum login):
platform_gps_xtra_on_enable.diff
platform_gps_xtra_on_enable_smali.diff
tws_fix_ringer_vib_silent_gps-EC05-odex.zip
tws_fix_ringer_vib_silent_gps-EC05-deodex.zip
gps_xtra_on_enable-SRF110.zip
gps_xtra_on_enable-midNIGHT52.zip
Crash workaround (mirror links, do not require forum login):
platform_gps_request_sync.diff
gps_request_sync-EC05.zip
orig_liblog-ECO5.zip (to backout the crash workarond)
Wow, nice work
Isn't this just doing what the app GPS status already does?
Does the phone still pull data even if use wireless networks is NOT checked? I've tested my gps a few times WITHOUT it checked and I'm getting a lock to 10 meter accuracy in under 5 seconds while indoors.
I thought the GPS app doesn't work properly for our phones? I could be wrong though
theimpaler747 said:
Isn't this just doing what the app GPS status already does?
Click to expand...
Click to collapse
Sent From My Evo Killer!!!
musclehead84 said:
I thought the GPS app doesn't work properly for our phones? I could be wrong though
Sent From My Evo Killer!!!
Click to expand...
Click to collapse
Huh, not sure.... either way, nicely done
Before I flash yet another piece of code on my phone, I'd like to know if this mod will do something more or different than the "Reset GPS State" and "Download Assistance Data" commands in the GPS Status and Tools app. I've tried those buttons numerous times with no results, so I am reluctant to flash a mod that doesn't do anything different, as I can't see how it will behave differently.
Also, could you please post the instructions for backing this mod out in the event that it does not fix the problem?
Thanks.
-Sean
theimpaler747 said:
Isn't this just doing what the app GPS status already does?
Click to expand...
Click to collapse
I'm not sure exactly what GPS Status & Toolkit does, but this suggests that the "Download Assistance Data" approach should be the similar. Although it's possible that the API GPS Status uses to do that doesn't work for other reasons.
One difference might be that GPS Status downloads new assistance data after attempting to start a fix, which happens when starting the application. Whereas this workaround (can) download assistance data before attempting a fix. I don't know if this is the case, but I understand how new assistance data might be ignored by the GPS while a fix is attempted, and even shortly thereafter.
mrzood said:
Does the phone still pull data even if use wireless networks is NOT checked? I've tested my gps a few times WITHOUT it checked and I'm getting a lock to 10 meter accuracy in under 5 seconds while indoors.
Click to expand...
Click to collapse
I believe the XTRA data is downloaded on boot regardless of that setting, although I've not confirmed that. However, what may be different is that with that setting disabled, location data is never injected.
Are you consistently getting fixes without "Wireless networks" and not with it? Is this when using 3G data, 4G data, wifi, or all of the above?
If it's with wifi, is the location data for your access point accurate? That is, if you pull up Maps with "Wireless networks" enabled, wifi on, and GPS disabled, is your location on the map accurate or far off?
musclehead84 said:
I thought the GPS app doesn't work properly for our phones? I could be wrong though
Click to expand...
Click to collapse
It definitely didn't under DI18/Eclair, although I don't believe Eclair supported the XTRA download interface. I've not tried it since upgrading to Froyo.
slwelsh said:
Before I flash yet another piece of code on my phone, I'd like to know if this mod will do something more or different than the "Reset GPS State" and "Download Assistance Data" commands in the GPS Status and Tools app. I've tried those buttons numerous times with no results, so I am reluctant to flash a mod that doesn't do anything different, as I can't see how it will behave differently.
Click to expand...
Click to collapse
Have you tried them under Froyo, or just in Eclair?
This workaround doesn't do "Reset GPS State". It should do somthing similar to "Download Assistance Data". The two differences is that I've confirmed this workarond actually downloads assistance data, I'm not sure that GPS Status does. The second is that the assistance data is, nominally, downloaded and pushed before a GPS fix is attempted (in recent history), wheras the GPS Status approach does it after a recent fix is attempted, which may influence whether the data is actually used.
slwelsh said:
Also, could you please post the instructions for backing this mod out in the event that it does not fix the problem?
Click to expand...
Click to collapse
If you're running EC05 stock, before installing this, make a backup copy of "/system/framework/framework.odex" to "/data/local/tmp". If nothing else, this can be done with an "adb shell":
Code:
cat /system/framework/framework.odex > /data/local/tmp/framework.odex
sync
then go ahead and install the appropriate update.zip.
If you wish to backout the modification, make sure "USB debugging" is enabled and reboot into ClockworkMod. Connect the USB cable, pull up an "adb shell", and run:
Code:
cat /data/local/tmp/framework.odex > /system/framework/framework.odex
sync
then reboot. Once rebooted, feel free to delete the backup /data/local/tmp/framework.odex.
If you're running a deodexed ROM instead of stock, replace "framework.odex" with "framework.jar" in the above directions. Note that replacing "framework.jar/odex" is best done in recovery since it's not used then. If you replace it while the phone is running under a normal boot, it should still take, but it might cause your phone to panic and reboot.
Alternatively, you can replce "framework.odex" or "framework.jar" in one of the update.zips with the copy from your phone and install that update.zip from ClockworkMod. Or if you prefer, I can prepare an update.zip containing the appropriate file in place--which ROM?
mkasick said:
Have you tried them under Froyo, or just in Eclair?
Click to expand...
Click to collapse
Just FroYo. I'd have to roll back to Eclair to try any of this (or even see if my GPS has problems on that release).
This workaround doesn't do "Reset GPS State". It should do somthing similar to "Download Assistance Data". The two differences is that I've confirmed this workarond actually downloads assistance data, I'm not sure that GPS Status does. The second is that the assistance data is, nominally, downloaded and pushed before a GPS fix is attempted (in recent history), wheras the GPS Status approach does it after a recent fix is attempted, which may influence whether the data is actually used.
Click to expand...
Click to collapse
Fair enough, that sounds like a good reason to at least give this patch a try. My GPS reliably stops working within a day or two after boot, so, in theory, just toggling GPS off and then back on again should inform us whether this patch resolves my issue.
... Or if you prefer, I can prepare an update.zip containing the appropriate file in place--which ROM?
Click to expand...
Click to collapse
I'm on SRF 1.1.0 now, although I had exactly the same issues on stock EC05 delivered as an OTA update to the DI18 that came on the phone.
-Sean
Also, it would be really helpful for folks who do find they have problems, to start CatLog's log recording feature before enabling GPS, then enable and attempt a fix, stop the log record, and send the recorded log if the fix didn't work.
Or if you run into a bad fix when not actively recording, you can still run CatLog and save its latest buffer, although it might not contain information from far enough back to be useful, hence recording is preferred.
If you're concerned about the contents of the log, you can filter for lines containing "gps" (case insensitive, please) after pulling it to a workstation.
slwelsh said:
Just FroYo. I'd have to roll back to Eclair to try any of this (or even see if my GPS has problems on that release).
Click to expand...
Click to collapse
I don't think it's worth doing that. Eclair's GPS problems are well known, Froyo does things completely differently.
slwelsh said:
I'm on SRF 1.1.0 now, although I had exactly the same issues on stock EC05 delivered as an OTA update to the DI18 that came on the phone.
Click to expand...
Click to collapse
SRF shouldn't make a difference. Did you want an update.zip for SRF's stock framework.jar, or were the above directions sufficient?
Also, reinstalling SRF will get rid of it, but that's a bit more of a hassle.
Bonsia version?
i'd love to check this out; any chance of a Bonsai version?
midNight is based off of Bonsai.
I have aLogCat installed; I'll run it it and capture what my GPS does (gps only use networks is turn off) and then what it captures after flashing this fix.
If you think what would be useful to you.
mkasick said:
... Did you want an update.zip for SRF's stock framework.jar, or were the above directions sufficient?
Click to expand...
Click to collapse
I think I can get by with the directions. That said, I would not turn you down if you wanted to post a flashable back-out zip.
I flashed your mod this morning. In order to capture useful data, I am leaving my GPS on full-time, so that when it fails, I can turn recording on in CatLog before attempting to toggle. If experience is any guide, that will be sometime in the next 48 hours. Whatever happens, I will post the results here.
-Sean
jdelano said:
i'd love to check this out; any chance of a Bonsai version?
midNight is based off of Bonsai.
Click to expand...
Click to collapse
I take it you are having GPS fix problems on Bonsai? I ask because in several other threads there are posts from Bonsai users (and developers) stating that Bonsai does not suffer from this same GPS problem. To the point where I had been considering switching from SRF to Bonsai just to get rid of the GPS issues.
-Sean
slwelsh said:
I take it you are having GPS fix problems on Bonsai? I ask because in several other threads there are posts from Bonsai users (and developers) stating that Bonsai does not suffer from this same GPS problem. To the point where I had been considering switching from SRF to Bonsai just to get rid of the GPS issues.
-Sean
Click to expand...
Click to collapse
I'm using midNIGHT Rom which is based off of bonsai, and i have absolutely 0 gps issues. I get a lock within a few seconds.
jdelano said:
i'd love to check this out; any chance of a Bonsai version?
Click to expand...
Click to collapse
To avoid complications, I'll only post modified frameworks for ROMs found in the Development section of this site. But if you want, feel free to send me a copy of /system/framework/framework.jar from your phone and I'll patch it for you. I'll PM details.
Also, I did add a modified framework for midNIGHT ROM 5.2 to the OP. It's in the "mirror links" section to avoid too many large attachments.
jdelano said:
I have aLogCat installed; I'll run it it and capture what my GPS does (gps only use networks is turn off) and then what it captures after flashing this fix.
Click to expand...
Click to collapse
Does aLogCat allow active recording, or only postmortem capture? I didn't see an active recording option when I checked. The postmortem capture didn't contain enough history. Either way, if you do use aLogCat, please make sure to use the "time" format in the settings--logs are much more useful with timestamps.
slwelsh said:
That said, I would not turn you down if you wanted to post a flashable back-out zip.
Click to expand...
Click to collapse
Alright, I'll try to get to it in a bit. OK, here it is:
orig_framework-SRF110.zip
slwelsh said:
In order to capture useful data, I am leaving my GPS on full-time, so that when it fails, I can turn recording on in CatLog before attempting to toggle.
Click to expand...
Click to collapse
Prior to this modification, did you leave GPS on all the time? Off most of the time? If both, did the issues happen in either case, or with only one of them?
slwelsh said:
I ask because in several other threads there are posts from Bonsai users (and developers) stating that Bonsai does not suffer from this same GPS problem.
Click to expand...
Click to collapse
It's not clear to me exactly how widespread the EC05 GPS problems are. Before I wrote this, I only had bad fixes a good three or so times. I probably wouldn't have thought much of it except other folks were reporting issues too.
In which case, it wouldn't surprise me that no Bonsai users have experienced the issue. That's not quite the same as definitively saying that Bonsai users can't sufffer from it.
It's also not clear to me that the problems are limited to EC05 either. Some folks haven't been able to get fixes from as far back as DK28--I'm actually rather curious to know if this helps them or not.
mkasick said:
To avoid complications, I'll only post modified frameworks for ROMs found in the Development section of this site. But if you want, feel free to send me a copy of /system/framework/framework.jar from your phone and I'll patch it for you. I'll PM details.
Also, I did add a modified framework for midNIGHT ROM 5.2 to the OP. It's in the "mirror links" section to avoid too many large attachments.
Does aLogCat allow active recording, or only postmortem capture? I didn't see an active recording option when I checked. The postmortem capture didn't contain enough history. Either way, if you do use aLogCat, please make sure to use the "time" format in the settings--logs are much more useful with timestamps.
Click to expand...
Click to collapse
yes aLogCat has a start and stop logging option. with active recording.
my gps locks but its not very close and if i have use networks it grabs the next town over.
Thanks for the zip; I'll give it a go (doing a backup before hand of course) ...
mkasick said:
Alright, I'll try to get to it in a bit. OK, here it is
Click to expand...
Click to collapse
Thanks.
Prior to this modification, did you leave GPS on all the time? Off most of the time? If both, did the issues happen in either case, or with only one of them?
Click to expand...
Click to collapse
I've tried it both ways and problems happen either way.
My issue is the one where I can get 7-12 bird fixes in under two seconds when the GPS is working, and it works fine after reboot for an indeterminate period of time. When it fails, not only do I not get a fix, but I see no birds, either. The symptom is almost as if the GPS receiver is powered off. As near as I can tell, it does not matter how long I leave the GPS on after this happens, it will never see a single bird.
Furthermore, there have been times when a simple reboot (from SRF's reboot option on the shutdown menu) does not fix the problem (although some times it does) and I have to actually "power off" then restart.
Neither toggling GPS nor using the tools in GPS Status to reset the A-GPS state or download assistance data fixes it. GPSCLRX has no effect. And I have tried various configurations of /etc/gps.conf and /data/secgps.conf all with no success.
It's not clear to me exactly how widespread the EC05 GPS problems are. ... It's also not clear to me that the problems are limited to EC05 either. Some folks haven't been able to get fixes from as far back as DK28 ...
Click to expand...
Click to collapse
I've had this problem since the day I got my phone. It came with DI18 on it, and I was told that FroYo was going to fix it. The OTA EB13 rollout had been suspended the day before I got the phone, so I patiently waited for the rollout to resume, resisting the temptation to flash a ROM or even root the phone until I had the OTA FroYo update from Sprint.
Of course, when Sprint resumed the OTA rollout it was with EC05. My problem did not go away. A quick check of the forums revealed that users who had the EB13 upgrade had their GPS problems resolved under EB13, only to have them return under EC05. By this time, I only had a day or two left under the 30-day return policy to make a decision, and I figured that if they had fixed the problems under EB13 that surely there would eventually be a way to fix them under EC05. I am beginning to regret that decision, since I use LBS apps constantly and they are a key reason for me to have a smartphone in the first place.
Thanks so much for all your assistance. I have given up on Sprint/Samsung fixing this in any kind of reasonable timeframe and I have high hopes that the development community will figure this out and resolve it soon.
-Sean
slwelsh said:
My issue is the one where I can get 7-12 bird fixes in under two seconds when the GPS is working, and it works fine after reboot for an indeterminate period of time.
Click to expand...
Click to collapse
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.
slwelsh said:
Furthermore, there have been times when a simple reboot (from SRF's reboot option on the shutdown menu) does not fix the problem (although some times it does) and I have to actually "power off" then restart.
Click to expand...
Click to collapse
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.
slwelsh said:
I've had this problem since the day I got my phone.
Click to expand...
Click to collapse
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.
Hi experts,
I got an unlocked Atrix-2 thro' a friend, two days back. Phone is great and working nicely (in BSNL network in India). Everything about the phone and android is great. I have two problems.
1st Prob:- Whoever unlocked the phone, has used his google (and market) account. So, I'm unable to access market.android.com and so no app downloads Deleting that guy's account can only be done by factory resetting the phone (so says the phone). My Question is "if I factory reset my Atrix-2, will the phone get locked again? OR is there anyway I can delink the other market account from my phone ?"
2nd Prob:- As BSNL's 3G coverage is scattered (yes we are still at 3/3.5G and not 4G in India), I was primarily using 2G earlier. My old workhorse Nokia 5800XM (tears for ditching it) allowed me to switch between 2G/3G/Dual modes. My new Atrix-2 doesn't give me an option. It tries to latch onto 3G (it shows 4G, whenever 3.5G signal is there), if not changes to 2G (it shows E - for Edge). Problem is, I drop calls, when going from 3G area to 2G area. Specially, some rooms in my house are hit and miss for 3G . Nothing changes by selecting network manually or automatically (Frustuuuuu). My Question is "how can I toggle between 2G & 3G ?". I saw a few apps in android market for this, but, pls remember I'm unable to log into the market using 'the market app', without the password of the guy who unlocked my Atrix 2. I request your valuable suggestions and help. Thanks in anticipation. And sorry for the looong question.
Go ahead and do a factory reset you will be fine.
Keep in mind when you delete that Google account it will delete all contacts associated with it also so if you want to keep them you need back them up another way before you remove that account.
As far as locking in in either 3G or 2G I dont see how that would help, the phone should be automatically searching and locking on the best signal available.
First time Android user, I am and with an unlocked phone. Bit reluctant now. One more advice like yours, and I'm game.
I'm concerned about 2g/3g switching, because where my 5800 XM held signal, Atrix-2 is loosing, due to lack of 3g and search time for 2g. And, Web pages wash out, if I'm opening a link. A big thanks.
Factory resetting worked . My Atrix-2 is still UNLOCKED and going great. Without advice from JRW 28, I wouldn't have given it a serious thought.
Regd 2G/3G:- Installed and tried about 5-6 apps from android market on "2G/3G switch". Atrix-2 doesn't allow them to go anywhere near. Anyone got solutions ? I'll live with the problem till BSNL improves the 3G coverage.
E is actually 3g on this phone I think. I've never gone down to Edge in the city.
My 2G/3G problem also got solved !
I installed an app called "network" by Philipp Mangelow (downloaded from market.android), and changed the 'preferred network type to 'GSM only".
Procedure is self explanatory, upon opening the app. It solved all my problems.
I needed to force the n/w to 2G (it says E), as the 3G signal strength in my:
house : -80dBm to -97dBm (settings -- about phone --- status).
office : -60dBm to no signal. As you all know, every 3dBm less signal means that half the strength of earlier value.
Whereas 2G signal strength is at least 10 to 15 dBm better than 3G strength.
So poor Atrix-2 kept hunting for signal (me not knowing) and draining battery (though this served my battery conditioning purpose). Now that both my problems are sorted out, I've become a happy Moto-A2 user.
So, anyone residing in India, with an unlocked Moto-A2, can safely "factory reset" the phone (IF needed), use above network app, and enjoy the A2 happily, for a longer battery life. Thanks everyone.
You can also Update
you can also update the phone wiithout it loosing your unlock. I did that with an Unlocked ATT i bought from amazon and carried to Venezuela, after i got it, i hit the update button, and it upgraded OTA, restarted, and still unlocked.
thanks a ton buddy:.. these stupid at&t people switched off the 2g network and locked the option to change it...
Sent from my HTC Sensation Z710e using XDA App
vijay_968 said:
I installed an app called "network" by Philipp Mangelow (downloaded from market.android), and changed the 'preferred network type to 'GSM only".
Procedure is self explanatory, upon opening the app. It solved all my problems.
I needed to force the n/w to 2G (it says E), as the 3G signal strength in my:
house : -80dBm to -97dBm (settings -- about phone --- status).
office : -60dBm to no signal. As you all know, every 3dBm less signal means that half the strength of earlier value.
Whereas 2G signal strength is at least 10 to 15 dBm better than 3G strength.
So poor Atrix-2 kept hunting for signal (me not knowing) and draining battery (though this served my battery conditioning purpose). Now that both my problems are sorted out, I've become a happy Moto-A2 user.
So, anyone residing in India, with an unlocked Moto-A2, can safely "factory reset" the phone (IF needed), use above network app, and enjoy the A2 happily, for a longer battery life. Thanks everyone.
Click to expand...
Click to collapse
Hi, I have an Atrix 2 MB865 unlocked and on the CLARO network in Nicaragua. In settings it says I have EDGE as my mobile network type. I have an E and full bars on the top of my phone. I can use voice and texts but can't use the Internet; 'Web page is not available'. If I install the app called "network" by Philipp Mangelow (downloaded from market.android), and change the 'preferred network type to 'GSM only" Do you think it will solve my problem?
THANKS!!
sounds like you need to check your apn settings
Enable "2G or 3G"
I don't know if you (vijay_968) need help yet but case someone need enable just 2G or 3G, I know how to do it.
Your A2 need be rooted!
Open /system/etc/motorola/com.android.phone/defaults.xml and change this key:
Original:
Code:
<boolean name='network_select_menu' value='[B]false[/B]' />
Changed:
Code:
<boolean name='network_select_menu' value='[B]true[/B]' />
Save the file and delete the backup file with .bak extension (/system/etc/motorola/com.android.phone/defaults.xml.bak). Some file's explorer don't show hidden files. Check the program configs.
Repeat the step 2 and 3 with these files:
/data/data/com.android.phone/shared_prefs/_has_set_default_values.xml
/data/data/com.android.phone/shared_prefs/Settings.xml
Make a copy of "com.android.phone_preferences.xml" in the same folder with the name "com.android.phone_preferences.xml.bak" and repeat the step 2 and 3
You need delete "com.android.phone_preferences.xml.bak.bak"!!
Reboot...
Now, if you go "Settings > Wireless & Networks > Mobile networks > Select network" you can select 2G or 3G only.
Credits: drock212
That would be a fantastic feature to have easily accessible!
I'm trying to modify the files in the way you said, but even though I've found the files I'm unable to edit them, how did you go about that?
Did you have to pull them from the phone, edit, and put back.
Or were you able to edit them with an app directly on the phone?
Alperon said:
That would be a fantastic feature to have easily accessible!
I'm trying to modify the files in the way you said, but even though I've found the files I'm unable to edit them, how did you go about that?
Did you have to pull them from the phone, edit, and put back.
Or were you able to edit them with an app directly on the phone?
Click to expand...
Click to collapse
Use Root Explorer, mount R/W, then edit on the phone
Works great thanks
Enviado desde mi MB865 usando Tapatalk 2
Hi, in my case i didn't find this file
/data/data/com.android.phone/shared_prefs/Settings.xml
So i reboot after changing the other 2 and i worked.
Thanks a lot.
Sent from my MB865 using xda premium