Personal background: Associate degree in Laser Electro Optics. 12 years research and development semiconductor manufacturing, 15 years as an EMT, last 10 years as a 911 telecommunicator for Austin-Travis County Emergency Medical Services. 6 of those years as a Training Officer.
The reason for my (cough) resume is so everyone understands I have the technical background and experience to explain the differences between e911 and 911.
Public Safety Answering Point: the local organization tasked with answering emergency request phone calls and dispatching appropriate emergency resources. PSAP's are broken into two types, primary and secondary. The primary PSAP is typically the local police department for city's and the local sheriff's department for unincorporated areas. Some colleges have their own police department and may have their own PSAP. So realistically a person can connect to a different 911 call center depending upon their location within a small geographic area.
Large urban areas typically have secondary PSAP's. The secondary PSAP usually consists of public safety departments not related to law enforcement such as fire and/or emergency medical services (ambulance services) specially trained to send request specific resources dependent upon the emergency. In Austin and Travis County we run 120 thousand EMS 911 calls per year. The police department takes about 2000 911 calls per day.
911: a simple to remember phone number nation wide allowing everyone access to emergency services. No location information is transmitted or received. The PSAP is responsible for determining location by interrogation of the caller. This can a problem if the caller is altered or otherwise unable to give accurate information.
e911: Enhanced 911 was created to ensure location information was transmitted to the 911 call center regardless of the callers ability to give this information. The phone companies are responsible for ensuring this information is available and transmitted to the PSAP. Conventional e911 is effective for landline phones. Cell phones present a completely different problem.
Cell phones are required to meet two different location technology standards.
Phase 1 wireless data: as cell phone use skyrocketed in the nineties, legislation was passed requiring provider's to transmit location data based on the cell phone tower that the cell phone was connected to. While this is helpful, it is problematic due to the sheer size of the area that had to be searched if the caller was unable to give their location.
Phase 2 wireless data: legislation now requires GPS location data be provided by the cell phone company. This location information can be transmitted via the gps chip from the cell phone or via radio location triangulation using the cell towers in the immediate area of the caller.
So in a nut shell, my test of neobuddy's ICS indicated that 911 worked for a sim loaded phone. I did not test the phone with the sim pulled. I also did NOT verify that GPS data was being received by the PSAP.
If 911 works with your phone it should work in any area. I was connecting with two different PSAP's as I live right between two different area's and sometimes connect to one or the other.
Hope this clears some of the confusion. A good explanation is located at en.wikipedia.org/wiki/Enhanced_9-1-1.
genesis3 and I are still working on the cm7 issue and getting closer to a resolution.
Later tators
Sent from my Touchpad using xda premium
thanks a lot. i can confirm cm7.1 has 911 issue.
Sent from my SGH-T959 using XDA Premium App
Developers should also note that as technology continues to advance, video conferencing and text message 911 activation requirements will also be legislated in.
I firmly believe that Google should begin requiring manufacturers make their modem software and audio software open source. Manufacturers should also be required to provide detailed explanations of how the relevant library's interface with the operating system, modems and audio system when activating an emergency call. This is Androids achilles heel. All it will take is one national media event to slam the door on open source operating systems for cell phones. I love the freedom Android provides and the exceptional programing skilss of our developers.
Im sorry, while this is a great explanation, i really didnt get the bottom line....
What we have on nonsamsung roms then is just a plain 911 incapable of transmitting location?
Sent from a cell tower to the XDA server to you.
Im sorry, while this is a great explanation, i really didnt get the bottom line....
What we have on nonsamsung roms then is just a plain 911 incapable of transmitting location?
Click to expand...
Click to collapse
correct as none had the source code....but for 2.3 onwards rom.
genesis3 and I are still working on the cm7 issue and getting closer to a resolution.
Click to expand...
Click to collapse
made my day.....thanks a lot....will be keeping a close eye on this thread...
My understanding is the issue is only without a sim right?
The 911 issue is with SIM, i don't know about without and im not planning on finding out.
HaloMediaz said:
My understanding is the issue is only without a sim right?
Click to expand...
Click to collapse
It has to do with emergency mode (no dim) and when no compatible roaming network is around (no service) .
Sent from my HTC Sensation 4G
hmmm I havent called 911 in YEARS but it still feels nice to have the ability and this was a nice explantion thank you
MIUI 360 in Asheville NC works fine but not in other areas?
Hopefully they can test the cm9 test ports that are out now.
Sent from my SGH-T959 using xda premium
http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.
Genesis3 said:
http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.
Click to expand...
Click to collapse
Can we get independent confirmation of this? (not that I don't believe you)
Sent from my SGH-T959 using xda premium
Uh, the guy who tested and verified it is the OP on this thread.
Read the first post.
You typed all that from your touch pad? props
Sent from my SGH-T959 using XDA App
Genesis3 said:
Uh, the guy who tested and verified it is the OP on this thread.
Read the first post.
Click to expand...
Click to collapse
No, I get that. Just wanted to make sure he verified was all..
Genesis3 said:
http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.
Click to expand...
Click to collapse
Don't know who you are or where you came from but, you sir may have saved CM development for the vibrant community. Here's hoping and you're the man!!!
Sent from my SGH-T959
Genesis3 said:
http://www.mediafire.com/?czo03t36py5sai4
CM7 with WORKING 911 (oh yeah, GPS works too and is VERY fast to lock. Insanely so in fact -- pretty much identical to what you expect with the LG Optimus! Those who say the GPS is broken in the hardware in these phones -- you're wrong.)
No support available at this point from me since the original source for the replaced bits hasn't been disclosed. Had there been some documentation on where the original source for those bits came from I bet this would have been fixed a lot faster. If that is disclosed in the future I'll consider supporting it, but for those who want it, here it is.
Incidentally it works on CM9 too.
Click to expand...
Click to collapse
I just downloaded your kang and running great so far, Thanks for you work !!
Question, is this 911 fix kernel dependent ? ie will it break if I flash another cm7 kernel ?
Thanks again for your hard work !!!
will replacing the kernel break both 911 and gps fixes?
I didn't save anything.
Here's the bottom line, if you're interested in it.
In the original Vibrant device directory there was a set of sources for libaudio -- one of the shared libraries that Android depends on to talk to the audio hardware in the phone. There was no documentation as to where this source came from, but I know where it didn't come from -- it didn't come from a public Gingerbread source for the Vibrant, because there isn't one.
It turns out the library this source builds does not work correctly but exactly why I'm not certain of. One of the problems with debugging this is that I have to have someone else test for me, which means I can't do the sort of testing I like to when I'm tracing things like this (a highly-iterative process that requires that I actually be staring at the debugging screen while doing the deeds that cause the bad behavior) since I can't call 911 myself.. Had the provenance of this code been documented originally (or lack thereof) I would have investigated this possible connection, as I knew the problem lay in the audio connectivity due to myriad kernel and application traces a couple of months ago. I didn't chase that library down and attempt to graft in other related versions because I assumed that the CM people knew what they were doing building that library from source rather than using a cribbed copy from, for example, Froyo or a different gingerbread build off a similar device.
Picking up a different shared library does work. Exactly what the provenance of that library is (e.g. was it grabbed from a binary, was it built from DIFFERENT source, where did it come from?) is also unknown.
Now that I have a working shared library on this device and a non-working one I'm going to compare traces. Maybe I'll get lucky and find the changes necessary in the source that's in the build tree and be able to fix that, at which point I'll know what I've got rather than having a "magic" library from God-knows-where.
Now here's the part that annoys me -- I was all over some of the CM guys about audio problems with other Samsung devices and tried to get access to the "not yet finished" repos because I expected that if I could run down the same sort of problem with ordinary calls in one of the OTHER Samsungs it was rather more likely than not that the same fix would be pertinent in some way on the Vibrant -- simply because manufacturers tend to use the same chipsets and bits, along with APIs, between different devices (it makes it easier for their coders and maintainers to do their jobs.) In addition when I started working one this one of the other protagonists didn't give me jack and crap about the provenance of anything in the device tree and, again, there's no docs embedded in the tree either. You can find the flamewar and slander aimed at me here if you'd like. It turns out I was on the right path; the problem this library allegedly fixed was having to hit <MUTE> twice to turn off and on the audio path. Sound familiar? Well, the pointer to the file that I found and integrated was from a bug logged against the I-9000, a similar phone to the Vibrant, and that library version works. What's changed in it? There's no set of commits logged against the ZIP file provided in that patch; is it a binary lift from a different build (e.g. some factory build) or did someone fix the source?
Who the hell knows because again, it's not documented in the bugtracker. Until I know where it came from and, if there's source, I have access to it, I won't support it. I don't play the "hide the sausage" game when it comes to alleged community coding projects.
I ran into something similar with the Triumph in that there was a different set of parameters coming up from the hardware when a wired headset was plugged in. That was easy to run down because I could do it and see what was going on; it was a literal couple of line change in the code once I found it. There are a couple of places in the libaudio source that might be the cause of this now that I have a reason to look in there, but without being able to easily reproduce the condition that creates the failure (e.g. call 911) it's a guess.
The ICS builds out at present have a different copy of the same compiled library and it also works. I bet that one works too on CM7 as it's fairly close to the metal and thus the API's probably the same (or close) on the Android side but I haven't tried it yet. I've got little reason to since I now have a libaudio.so that's functional on CM7 in any event.
While I've been working on the 911 issue (for a couple months on and off) I also traced down some actual working (properly) GPS libraries that handle the AGPS assist data in the correct way, something that other sets of them do not, and added those too. I also made a few other changes. The battery life is reported to be rather impressive, and the near-instant GPS locks most-definitely are. I can't speak much to the battery life view of the world as of yet but I will be looking at that; that's an area I know quite a bit about (getting these devices to properly go into deep sleep as they should) and the source tree I'm working with does have kernel source.
Any sideloaded kernel that leaves libaudio.so alone (check the zip file to make sure that /system/lib/libaudio.so is NOT present) should be ok, but no promises. Before you go screwing with kernels make sure you want to --you might break GPS performance as a number of the kernels have various attempts to get the GPS to work right and load various libraries along with the kernel itself with varying degrees of success.
I'd be willing to maintain this port but there are two conditions -- first, I expect apologies from the CM people who attacked me, in public, and second, I expect a formal commitment that there will be no more hiding of information. "I don't know" is an acceptable answer provided you run down the person who does -- someone does know because someone DID either import or code the material in question; silence and lack of documenting where things came from and how they came to be is not acceptable. When things go into the codebase through review they damn well ought to be documented. I played "talking to the brick wall" with the Triumph and now the Vibrant and I won't do it if I'm taking on responsibility for maintaining something.
If CM wants me involved in this that's the deal. If not I'll consider setting up a parallel build and set of repos for the bits that have to be changed from the base CM7 Gingerbread branch as I did for the Triumph if there are people interested in it, but my time is not unlimited and in all honesty my taste for working with the CM people and the CM code in general has been seriously damaged, never mind that what I have here seems to work just fine. As such the benefits of continued efforts are likely to be relatively small. If I decide against a continuing effort I will take the build environment that produced that I have now and attempt to set up a manifest so it can be cloned by anyone else who cares to do so, which should take care of others being able to build and run the KANGs from source if they wish. The latter may take a while as I need to find a day when I'm not busy and can put that together (again, lack of documentation doesn't help) and then pull a clean test from a zero base and make sure it builds and runs.
The Vibrant is no longer my daily device but I do still own one, and given its relatively modest resale value I'll probably keep it as a spare device -- it's a very credible phone and with working GPS code it actually locks faster and better than my Hercules does. It's biggest shortcoming is that it's relatively RAM-starved compared to more-modern devices.
Fancy that.
Related
Has anyone pulled the phone apart and read the serial number off the chip. We are trying to compair it to the US phone. If you have the info thanks Ours is a Broadcomm BCM4751 (Captivate)
Can I ask how you know the Captivate has a BCM4751 chip? Did you disassemble and see it? It appears that the Galaxy S generic being sold everywhere else outside the US has the BCM2075 chip that integrates BT and FM radios; at least that's what's being reported by others here.
If it were true that the Captivate/Fascinate/Vibrant in the US are using the BCM4751 chip, then it would truly mean these phones have no FM capability at all and there is no prospect of rooting the phone to disable a software level crippling.
This pisses me off. I was willing to forgo the front facing camera of the US versions, but the fact that they (apparently) went so far as to have samsung supply a different GPS chip to eliminate the FM radio so you are FORCED to use some ****e, data intensive service like AT&T radio instead is just outrageous. With the GPS/compass/antenna problems seemingly going ignored by samsung, maybe I won't get this phone at all.
http://www.broadcom.com/products/GPS/GPS-Silicon-Solutions/BCM2075
bugmenever said:
Can I ask how you know the Captivate has a BCM4751 chip? Did you disassemble and see it? It appears that the Galaxy S generic being sold everywhere else outside the US has the BCM2075 chip that integrates BT and FM radios; at least that's what's being reported by others here.
If it were true that the Captivate/Fascinate/Vibrant in the US are using the BCM4751 chip, then it would truly mean these phones have no FM capability at all and there is no prospect of rooting the phone to disable a software level crippling.
This pisses me off. I was willing to forgo the front facing camera of the US versions, but the fact that they (apparently) went so far as to have samsung supply a different GPS chip to eliminate the FM radio so you are FORCED to use some ****e, data intensive service like AT&T radio instead is just outrageous. With the GPS/compass/antenna problems seemingly going ignored by samsung, maybe I won't get this phone at all.
http://www.broadcom.com/products/GPS/GPS-Silicon-Solutions/BCM2075
Click to expand...
Click to collapse
Well the Galaxy S might have the BCM20751 but untill someone tears down the phone and checks with their eyes. The US Captivate was torn down and it is a 4751. But the 4751 doesn't have BT on it. So it could be all the phones have a 4751 with a seprate BT and FM. The 4751 is supposed to be a better GPS unit then the BCM20751 though.
ah, I see it on the Captivate general forum now. The only teardown of the generic Galaxy S that I have seen anywhere is the original one done in Korea a month ago. The pictures from that disassembly are too low-res for me to make out chip IDs. I tried going through their video of the teardown frame by frame too, but again, I can't see the numbers clearly and I saw nothing that resembled a broadcom chip. The Captivate board layout is much different than the Galaxy S, I can't really even see where the broadcom chip should be on it either.....
You're gonna love this. On my Galaxy S, According to jupiter.xml:
<gll
LogPriMask="LOG_DEBUG"
LogFacMask="LOG_GLLAPI | LOG_NMEA"
FrqPlan="FRQ_PLAN_26MHZ_2PPM_26MHZ_300PPB"
RfType="GL_RF_4751_DANUBE"
BrcmRFwildBase="0x1E2D6409"
BrcmRFclkDiv="21"
BrcmRFclkRefHz="26000000"
pps-enable="false" pps-offset-ms="0" pps-width-ns="100"
/>
Click to expand...
Click to collapse
I changed the RfType to GL_RF_2075_BRCM and it just didn't work.
Well thats good. We've accomplished something. But Broadcomm says this is the best GPS they have ever made some hopfully samsung messed up the code and we get a super good GPS.
TBH - I think we may actually be waiting on the driver from Broadcom. Something about Broadcoms reputation as an open source provider is in question.
sjdean said:
TBH - I think we may actually be waiting on the driver from Broadcom. Something about Broadcoms reputation as an open source provider is in question.
Click to expand...
Click to collapse
Yeah it could deff. be broardcoms side. They better fix it.
Is the 4751 used in any other phones just want to see the performance of the gps on this chipset in other devices..
The mere fact that we have Broadcom chip for GPS and not some off brand that I've never heard before like InCrystal really, really points to a serious issue with the drivers/firmware for the GPS. The phone should be operating in MS-Based mode out of the box anyway and I don't know why it isn't. That's not the only problem it has but standalone mode is not what it should be operating in. Nearly all phones GPS' are truly the pits without network assistance.
Lots of phones use Broadcom for GPS, right off of the top of my head, the iPhone is one of them!
Well I really hope it can operate in stand alone mode reasonably well, it should be able to, I dont see why a phone couldn't. agps is mainly just for helping get locks faster at startup and possibly in areas where gps signals are weak but agps is not going to help you out of the city much etc etc.
However yeah I really hope it is a driver issue and if so broadcom and samsung need to get together or its going to drag both their names down.
Kilack said:
Well I really hope it can operate in stand alone mode reasonably well, it should be able to, I dont see why a phone couldn't. agps is mainly just for helping get locks faster at startup and possibly in areas where gps signals are weak but agps is not going to help you out of the city much etc etc.
However yeah I really hope it is a driver issue and if so broadcom and samsung need to get together or its going to drag both their names down.
Click to expand...
Click to collapse
Well like I said there appears to be some other issues besides the fact that they ship in standalone mode which is awful for any phone.. aGPS is the first choice for most phones (Galaxy S is an exception I suppose!) before falling back to standalone mode which does take 2-3 minutes for a fix. Standalone GPS will always take a few minutes to get a lock, a phone certainly isn't going to perform better than a Garmin and I have yet to see one of those in standalone mode lock faster than a phone with aGPS. aGPS is for an initial fix regardless of other circumstances and it's why phones get such snappy fixes.
Ok, but I posted elsewhere that there's a whole stack of a lot happening behind the scenes, which Im not even Samsung know what's going on.
First, even in Standalone mode, you see data being streamed in the initial few seconds, so there must be something in there.
But Ok, we have:
Operation Mode under LBSTestMode - MS Based, MS Assisted, Network Provider or standalone
GPS Plus - Uses the OneXtra servers
Skyhook - Another form of AGPS
SUPL Settings
And irrespective of what you set the SUPL settings to:
Jupiter.xml - Points to both www.spirent-lcs.com as an acSuplServer then points to bcmls2.glpals.com as the LbsServer.
Then under Location and Security, we have the ability to Use Wireless Networks (using WiFi and Cellular Networks). Even if this is switched off, the phone still wants to enable Wireless and see what's out there.
So that's what, 6, perhaps 7 or even 8 seemingly different settings, different methods, of A-GPS.
No wonder the phone is getting confused.
Cya
Simon
sjdean said:
Ok, but I posted elsewhere that there's a whole stack of a lot happening behind the scenes, which Im not even Samsung know what's going on.
First, even in Standalone mode, you see data being streamed in the initial few seconds, so there must be something in there.
But Ok, we have:
Operation Mode under LBSTestMode - MS Based, MS Assisted, Network Provider or standalone
GPS Plus - Uses the OneXtra servers
Skyhook - Another form of AGPS
SUPL Settings
And irrespective of what you set the SUPL settings to:
Jupiter.xml - Points to both www.spirent-lcs.com as an acSuplServer then points to bcmls2.glpals.com as the LbsServer.
Then under Location and Security, we have the ability to Use Wireless Networks (using WiFi and Cellular Networks). Even if this is switched off, the phone still wants to enable Wireless and see what's out there.
So that's what, 6, perhaps 7 or even 8 seemingly different settings, different methods, of A-GPS.
No wonder the phone is getting confused.
Cya
Simon
Click to expand...
Click to collapse
Interesting, so standalone isn't really standalone at all
I wonder if any of the problems are actually being caused by agps especially as a lot of the "fixes" by users were basically changes to the agps.
Curious....., if you google skyhook and you see how samsung and I think even apple used skyhook etc and all the big fanfare etc over it but it seems to be disabled in this phone.
and some of the fixes were to use the google location server right?
(weren't google roasted around the world for wardriving and recording wifi sites and also the data? hehe), now i know why they did it.. for location services I guess... a bit off topic but just now seeing why there were even interested in wifi sites etc.
So.. this broadcom chip... its supposed to be good? can we eliminate the hardware as being a bad gps chipset?
Other things to keep in mind when determining the chip are BT and wifi. The 2075, for example, provides bt 2.1, which rules out its presence on the SGS, unless samsung decided to install multiple bluetooth chips. So, the chip we are looking for provides either bt, version 3.0 and wifi N and GPS, or one or 2 of those 3, which makes the 4751 way more likely indeed. I also don't see a reason to change the internals of the phone.
Gps is a Qualcomm RTR6285 like desire, nexus, some blackberry.
careace.net/2010/06/09/disassembly-of-the-samsung-galaxy-s/
news.danawa.com/News_List_View.php?nModeC=4&nSeq=1742568
sesamee said:
Gps is a Qualcomm RTR6285 like desire, nexus, some blackberry.
careace.net/2010/06/09/disassembly-of-the-samsung-galaxy-s/
news.danawa.com/News_List_View.php?nModeC=4&nSeq=1742568
Click to expand...
Click to collapse
This:
news.danawa.com/News_List_View.php?nModeC=4&nSeq=1742568
must be the korean version (hardware is diferent)
for example :
http://www.careace.net/wp-content/uploads/2010/06/galaxy-s-disassembly-29.jpg
http://www.danawa.com/cms/popup_image.php?url=http://img.danawa.com/cms/img/2010/07/06/14.jpg
Audio codec is the same (wolfson)
Configuration files show tha GPS chip is bcm4751 in european galaxy s (not GPS BT FM BCM20751 or BCM2075) in captive there are photos also.
it REALLY seems like a driver issue. I can get a lock within seconds in MS based mode like all other Android phones with 6 meter accuracy tracking in my car but the performance diminishes after that and the phone requires a reboot for another fix -- IF GPS doesnt cause a lock up trying to get a lock.
Anyone else notice the same behavior in MS based mode?
Sent from my SGH-T959
as i have said in the gps issue thread my settings are as they were from the factory, and at least for now my gps works, in test mode it sees 9-11 satalites, and locks 5-7 of then in about 9 secs, it even suprised me today when i was stood on my staires surrounded by brick walls it managed to get a fix.
this was however not the case with the first one i had, no matter what i tried i could not get a reasonable fix, so it seems to me like some phones are better then others, even thought they are the same phones, this is why i suggested it could be a faulty batch but that is not the case, so i have no idea why this one works and the other never.
if you want the settings: gps is set to oo
application setting
session type: tracking
test mode: s/w test
opperation mode: standalone
start mode: hot start
gps plus: on
dynamic accuracy: on
accuracy: 50
skyhook: off
use pc tool: off
supl/cp setting
sever fqdn: custom
server: www.sprint-lcs.com
server port: 7275
supl secure socket: on
agps mode: supl
hope these can be of use for someone, please note im in the uk.
edit: just tested out my window and got 8 found / 8 locked satalites in 12 secs
Things are getting even more weird...
I was browsing around in the jupiter.xml file shipped in the JP2 firmware and found what I suspect must be a a typo:
arp-supl-reaiding-time-sec = "1200"
Shouldn't that be: arp-supl-reading-time-sec = "1200" ?
With all that mucking about with wads of configuration files and a bazillion places where (conflicting) settings can be made, this doesn't exactly make me feel better about the reliability of AGPS on this device.
edit: nah, probably not a typo (read as 're-aiding', duh) but an unfortunate name choice anyway. At least it appears consistent with what the app is expecting.
Since some think that the GPS hardware (that can't be fixed by software settings) in the Captivate is crap, do you think that Samsung should use hardware from a different GPS provider in their next version of the phone? Does Broadcom have any GPS hardware in other phones that work well? Other than buying a Garmin phone, are there any other phones out there that use "true" GPS, as in one that you would find in a "real" handheld GPS device? I see/hear a lot of people returning their phones strictly because of the GPS not working well.
I'm just wondering if there will ever be a GPS fix for my Captivate, if the hardware is at fault. If it is a poor GPS chip in the phone, there's not much we can do about it, unless the GPS manufacturer updates their driver and they produce some type of software fix.
I updated my Captivate with the OTA update that claims to "fix" GPS performance. It has improved from never getting a fix to providing one relatively quickly. However it loses the fix moving, it loses the fix for NO REASON when stationary (sitting on a surface with a clear view of the sky), goes nearly a minute without updating at times and isn't accurate. People that are using it and saying it works great have never used a real GPS before. The Captivate is useful for location based services at best and hopefully with more improvements navigation.
I compared it side by side with a 9 year old Garmin eTrex and the ancient eTrex blew the Samsung out of the water. Initial fix on the Samsung was faster (thanks to AGPS) but while the Garmin hovered between 6-8ft CEP and the Galaxy S was about 32ft CEP. This makes the Garmin about 30x more accurate in my book.
This was both outside and INSIDE in my home. To the naysayers that say GPS shouldn't be working indoors please take a walk. It depends on the construction of your home. The fact that a 9 year old GPS receiver that was never known for its sensitivity beats the pants off off the Galaxy S really speaks to how much of a terrible joke the phone's GPS is.
If I could I would return the phone. This OTA update was AT&T and Samsung's fix for the GPS and I believe they're going to say it's "done". Because they'll claim to have fixed it already I hold out no hope that this issue will be further addressed and am upset I have the phone. GPS is a basic feature for such a well-spec'ed phone - we shouldn't be thankful when features work - we should demand that they do.
I'd say probably that's all Samsung can do for its crapy implementation of BroadCOM 4751 chip. The GPS chip may be the latest and greatest (newer than the one used in iPhone4, BCM4750) but we are the beta testers for BroadCom/Samsung as the chip is very new (released in April 2010) and never field tested in any devices.
I have no doubt that we will see great GPS performance from this chip later on from other phones or GPS devices. Just not from any of the current Samsung Galaxy S phones. There is only so much they can do to compensate in software for the bad hardware implementation. Ultimately they have to change the board design and/or chip designs to address the real issue. I just can't see Samsung willing to recall millions of existing SGS phones back and replace the motherboard on each one of them.
The update was certainly discouraging. The phone really has no ability to track you correctly on GPS when moving and it loses its lock frequently. Wasn't there a leaked vibrant rom that fixes the tracking part of GPS? Having something like that come to the Captivate is really the only hope we have left at this point.
I'm not a GPS expert, but since basically every phone that comes out these days has a working GPS, I really can't understand how Samsung managed to screw this up. I'm sure that GPS is quite complicated, but aren't the methods and alrogithms for calculating position from the data pretty well established at this point? I don't know why its this difficult for them to get this right. They souldn't have to reinvent the wheel with this; just implement an existing algorith. I wish I knew what is so challenging for them, it seems way to easy for this much time to go by without addressing this properly.
This needs to go in Q&A or General.
TheSopranos16 said:
They souldn't have to reinvent the wheel with this; just implement an existing algorith.
Click to expand...
Click to collapse
It is not the algorithm, it is the chip. For what ever reason, Samsung decided to use the latest and greatest, but untested, GPS chip that was officially anounced only the spring of 2010. Basically, we are beta testers for BroadCom for its BCM4751 version 1.0 sillicon. Of course, adding a slighly bigger or better GPS atenna inside the phone probably will help too but Samsung has to cut corners somewhere (they always do)
I'm also disappointed with the GPS in this phone. I have a standalone Garmin that I bought this summer, but its nice to know that I can use the phone if I don't have my Garmin with me...but I can't rely on this thing.
I had the Nexus One before this and its GPS was great. I used it on a 300+ mile trip between St. Louis and Chicago and it never lost its fix.
I like the Captivate better for its screen, true multitouch and better graphics processor (although I don't really notice a difference there).
I like the Nexus One better for more ROMs (Cyanogen), stock Android, WORKING GPS, first for updates.
IF (and that's a big IF), they can get GPS to be reliable while driving, then I will prefer this phone.
It is very frustrating. I purchased 2 Captivates, one for my wife and one for myself. Both phones are factory still. The wifes gps works excellently, fix within 5 seconds (indoors too).....whereas my gps couldn't find me if I was the only crumb on the plate.
I returned the first phone. The second phone handed to me worked just as my wifes did. Excellent gps fixes. This phone unfortunately had the turn off problem. If the phone was in my pocket for any period off time it would turn off.
I returned this one for a third phone. The third phone stays on but still has the gps problem.
Is it the device, the hardware or the software, you be the judge!
Sent from my SAMSUNG-SGH-I897 using XDA App
drez22 said:
It is very frustrating. I purchased 2 Captivates, one for my wife and one for myself. Both phones are factory still. The wifes gps works excellently, fix within 5 seconds (indoors too).....whereas my gps couldn't find me if I was the only crumb on the plate.
I returned the first phone. The second phone handed to me worked just as my wifes did. Excellent gps fixes. This phone unfortunately had the turn off problem. If the phone was in my pocket for any period off time it would turn off.
I returned this one for a third phone. The third phone stays on but still has the gps problem.
Is it the device, the hardware or the software, you be the judge!
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
Its still hard to say. Signs are starting to point towards hardware, but it could also just be poor drivers, which will eventually get fixed hopefully.
I've said this in another post.. but these phones are being produced on an assembly line - errors get made - the phones are all using the same hardware.
this is my #5 captivate - the last 2 phones were battery issues, but att replaced the entire phone.. I tested gps before I left the store with the new phone -
everyone needs to understand that there will ALWAYS be problems - It's technology. If your GPS didn't work within the first 29 days, take it back!
There is a reason Samsung is creating a "fix" for the GPS - they aren't RECALLING the phone because of a hardware problem. I will eat my words if the phone gets recalled because of a bad "GPS chip." But for now, if you are within 30 days and you aren't happy, please go return it, test the new phone in the store before you leave!
There is still SOME home for this chipset. Nokia is developing a device with the same chipset. I made a thread in i9000 - Android Development forum with the linux driver source code written by Nokia. We'll have to see. If Nokia releases a device with this chip and the GPS works, we know it's Samsung's fault.
Has anyone ever tried to get a comment from Broadcom about the GPS issues? Since its their chip and there are over a million Galaxy S phones out there, I would think it would be appropriate for them to weigh in on this...
born_fisherman said:
I've said this in another post.. but these phones are being produced on an assembly line - errors get made - the phones are all using the same hardware.
this is my #5 captivate - the last 2 phones were battery issues, but att replaced the entire phone.. I tested gps before I left the store with the new phone -
everyone needs to understand that there will ALWAYS be problems - It's technology. If your GPS didn't work within the first 29 days, take it back!
There is a reason Samsung is creating a "fix" for the GPS - they aren't RECALLING the phone because of a hardware problem. I will eat my words if the phone gets recalled because of a bad "GPS chip." But for now, if you are within 30 days and you aren't happy, please go return it, test the new phone in the store before you leave!
Click to expand...
Click to collapse
You have to realize that the percentage of the bad SGS with GPS issues are too high to be caused by any reasonable manufacturaing defects.
You can't test GPS properly in a store without going through a driving test. Period. The problem with the GPS is not about whether or not you get a lock, it is whether or not the phone can keep an accurate lock on you while driving. Unfortunately, most ppl didn't realize this at all.
Samsung will not recall the phone even if it turns of the GPS chip or motherboard is the problem. It is not some kind of safety issue.
TheSopranos16 said:
Has anyone ever tried to get a comment from Broadcom about the GPS issues? Since its their chip and there are over a million Galaxy S phones out there, I would think it would be appropriate for them to weigh in on this...
Click to expand...
Click to collapse
Broadcom made some small fixes in the driver. That's why with JH7, you can see your phone can lock on to more than 8 satellites now. Old drivers will only allow max lock of 8 satellites and minimal SNR value of 20. New driver allow lock on to more than 8 satellites and minimal SNR value of 10 or so. But unfortunately, it didn't improve moving accuracy.
So when you go to the AT&T store take the phone outside and the phone you are going to walk away with doesn't see any satellites, you should just take it and run?
I'm saying this with experience. I've had 2 phones that didn't pickup any satellites even after waiting 5 minutes.
My current phone immediately saw satellites and got a lock within 45 seconds.
Regardless if you are moving or not, the phone should be able to see satellites - I understand the problem is when you are mobile and keeping the lock, this is not my argument.
my argument is that people are still complaining that they can't get a lock even after the OTA update - Test your phone before taking it home. That's all. Not a big deal if you ask me! If your new LCD TV with HD tuner isn't picking up HD channels, you would bring it back right??
My gps was pretty terrible until I flashed Cognition the first version. Now my gps works amazingly and never has the blue circle of ambiguity. Very happy with the gps performance now. So much that I haven't flashed the cognition that is updated with JH7. Worried it could brea kit haha. might as well try though.
Yeah, the new one (Cognition v2.1) with OTA JH7 in it is pretty bad based on my reading. JH7 is an old firmware. Original Cognition has some files from T-Mo Vibrant JI2 firmware which is newer than JH7.
Our only hope is that the final version of Froyo has some improvement baked into.
I have the 4G version, is this specific model have a working CM10 ROM? I know the Wi-Fi model does, just want to make sure this won't brick mine or anything.
I'm new to this, just got this today!
It does not. Our version (i957) uses a different chipset then the Wi-Fi version. Best to not flash.
Sent from my Galaxy Nexus using Tapatalk 2
CM10 will eventually support this device -- In fact, the device tree was just created by cyanogen yesterday @ https://github.com/CyanogenMod/android_device_samsung_p5att -- However, work still remains to get this code to even boot, let alone be functional as a daily driver. It will get there, eventually.
The ICS (4.0.4) ROM from Samsung for this device is currently in test with the carriers. The Korean variant (SHV-140) just received the ICS update a few weeks ago, and some of that code might help speed along the Cyanogen update.
The CM10 code currently on github does build, but the kernel does not seem to fully boot -- Locks up just after displaying the initlogo, with adb unavailable, so I have no idea how to get the dmesg. I suspect there are some needle-in-a-haystack sort of details that need to get ironed out, the kind of which probably will require some hardware hacking (ie: serial and/or jtag access) to get at... or for the official i957 kernel to get released.
The shv rom has to be out there somewhere
Sent from my SGH-I727 using xda premium
In for the first screenshot of a p5att (SGH-I957) running jellybean, in case you need some encouragement you won't be stuck on honeycomb forever...
No, it's not even close to stable.
Yes, pretty much everything is broken. IE no LTE, audio, and probably everything else I didn't try.
works: wifi, touchscreen.
No, I won't be maintaining a release for this, the people way smarter than me on the cyanogen team did all the real work on this.. I just built and kludged until I got it to boot with graphics If things go well you'll see a real release from the CM team sometime. For all I know they'll run into a horrible problem and give up, but you know how those guys are.. totally badass.
basic idea:
- breakfast cm_p5att-userdebug
- replace msm-8660-common kernel with code from jb-full branch
- *** edit to update: it seems there is no longer a jb-full branch, there is now just jellybean and jb-old. I'm guessing the out of date msm8660-common kernel from what was jellybean is now jb-old, and jb-full has become jellybean.. hmm.. working on seeing if this is the case (need to clone/build/boot it)
- hack p5att boardconfig
- pick your combination of samsung proprietary files, good luck, the note and/or skyrocket CM10 releases are your best starting point
- brunch p5att, consume more coffee and stuffs
- hack resulting .zip to remove assert for 957 (TWRP has wrong product ID lulz)
- hack ramdisk to enable adb on boot so you can debug why it doesnt come up
- hack proprietary files until you get working graphics
** (not for the faint of heart)
nrvate said:
In for the first screenshot of a p5att (SGH-I957) running jellybean, in case you need some encouragement you won't be stuck on honeycomb forever...
No, it's not even close to stable.
Yes, pretty much everything is broken. IE no LTE, audio, and probably everything else I didn't try.
works: wifi, touchscreen.
No, I won't be maintaining a release for this, the people way smarter than me on the cyanogen team did all the real work on this.. I just built and kludged until I got it to boot with graphics If things go well you'll see a real release from the CM team sometime. For all I know they'll run into a horrible problem and give up, but you know how those guys are.. totally badass.
basic idea:
lunch cm_p5att-userdebug
replace msm-8660-common kernel with code from jb-full tree
hack p5att boardconfig
pick your combination of samsung proprietary files, good luck, the note and/or skyrocket CM10 releases are your best starting point
brunch p5att, consume more coffee and stuffs
hack resulting .zip to remove assert for 957 (TWRP has wrong product ID lulz)
hack ramdisk to enable adb on boot so you can debug why it doesnt come up
hack proprietary files until you get working graphics
(not for the faint of heart)
Click to expand...
Click to collapse
nice job man!
EDIT: I created a separate thread for doing the CM10 build: http://forum.xda-developers.com/showthread.php?t=1867579
Cheers!
Still hacking stuff.. lol.. using the file list from the msm-8660 common proprietary file list, i grabbed that set of files from the CM10 i717 ROM and dropped them onto the i957. Working audio! Don't know about the mic, but it plays sound now. Also, it almost got LTE working... logcat -b radio shows the LTE radio finding the LTE cell and reporting signal strength, but the data session doesn't actually establish, even with the proper APN config. GPS looks like it might even eventually lock on, it found 2 sats after a while, but didn't get a lock. I suspect when full 4G comes up, it'll be able to use SUPL to get it's initial location then actually get a fix.
Downloading the gigantic i717 stock image, going to see if 4G plays nicer with the note radios, since I'm using the note RIL now.. Dan had mentioned he had successfully got the note radios running on the tab 8.9 LTE in an attempt to get voice calls up... the honeycomb RIL stuff just results in lots of errors, so thats straight fail.
I didn't realize how many software pieces go into the cellular data connectivity, yikes!
The more I delve into code and binary packages... the more it appears the 957 is very close to a supersized note! sweet.
Also, bluetooth finds my neighbors macbook, so it probably works, but my headset is at work and I haven't been there in a while (hence having time to do this fun stuff).
If anyone has any suggestions on getting LTE up, I'm all ears. If I can get LTE working, I might be tempted to try to package this beast up.
More fun...
Good grief, it looks like the userdebug variant compiles with all the radio debug flags on, thousands and thousands of lines of everything from verbose text to hex dumps!
i957 honeycomb radio: baseband shows unknown, isn't worth anything
i717 ICS radios, both UCLF5 and 6: entire tablet slows to a crawl once rild starts, fail! Nothing useful in the logs as to why, nothing hogging CPU time... no idea, abort
i727 skyrocket ICS radio I727UCALC4 (no idea how current or valid this radio really is): gets HSPA+ on old 3G "wap.cingular" SIM, no luck with tablet only LTE "Broadband" APN SIM. ~2-2.5mbit download speed.
i727 skyrocket ICS radio UCLD2: Obtained HSPA+ with Broadband APN data-only SIM. ~4.0-5 mbit download speeds. After ~10 minutes, found an LTE cell and pulled 30-35mbit down. After each radio reset (reboot, airplane mode, etc) it takes the 3-10 minute period to get LTE again, and it's also slow (10-50 seconds) to get on HSPA. All around sluggish to jump on a cell, but returns nice speeds once it does so.
i727 skyrocket ICS radio UCLF6 (latest I could find): Pretty much the same as UCLD2 above, similar speeds, but seemed to jump on LTE quicker after a reboot, but still takes a while when coming back from airplane mode. It's the latest, i think, and it works, so it's probably the way to go.
Pending investigation: RIL files -- going to try the skyrocket UCLF6 RIL and see how it works out. Currently still using the note RIL files. Tried UCALC4 skyrocket RIL and it didn't work at all, will try UCLF6 from stock skyrocket ICS release...
Looks like it doesn't like the Broadband APN on a tablet (data-plan-only) SIM. I tossed in a "old school phone SIM" from the 3G days, which is set up on an unlimited phone/data plan (as you could get ages ago) and gave it wap.cingular, and whamo, HSPA+ connectivity. Looks more like a configuration issue and/or the phone RIL/radio combination refuse to play nice with data-only SIM.
I've never tried to debug getting onto 3G/4G service at the RIL radio log level, so not totally sure what to look for, but... guessing it's trying to set up a voice bearer and the UMTS system says F you. need foods, sleep, etc... haha.
And more fun... Skyrocket UCLD2 radio returns HSPA+ connectivity on data-only SIM with Broadband APN, but no LTE. Set APN type to "supl" to enable SUPL, got the first GPS fix in about 2 minutes, after 5 more minutes found 12 sats and obtained 12m accuracy.. sweet!
Update: UCLD2 radio, after sitting around idling for 10 minutes while I made some munchies, decided it would pick up an LTE cell. No idea why it took so long, I'm really close to an LTE cell and both my other LTE devices have never (and don't presently) exhibit this behavior at my location. I suspect this is probably normal behavior of UCLD2 or UCLD2 plays less than optimally with the i957 radio... which should be the same as a skyrocket radio, considering both identify as an M8260 when inquired with "ati" via ttyACM0. Whatever the case, 50ms ping and 30 mbit down works for me...
I really should go to bed sometime...... and make a backup of this device before I bust something!
Adding a little more info: I modified device/samsung/p5att/BoardConfig.mk a little before building... Other devices with no SD card slot had BOARD_HAS_SD_CARD_INTERNAL defined, so i tossed that in. The BOARD_SDCARD_DEVICE_PRIMARY, BOARD_SDCARD_DEVICE_SECONDARY and BOARD_SDEXT_DEVICE_SDEXT values seemed bogus, and I knew the init scripts would set up /sdcard as a fuse device on the /data partition anyways, so I just commented them out.
I don't know if anything uses the 3 values I commented out, but since there's no actual mmcblk device for the fuse (filesystem in user space) emulated sdcard, it doesn't seem a valid value could be found, so, why set one.... Seems to work!
BOARD_HAS_SDCARD_INTERNAL := true
#BOARD_SDCARD_DEVICE_PRIMARY := /dev/block/mmcblk1p1
#BOARD_SDCARD_DEVICE_SECONDARY := /dev/block/mmcblk0p28
#BOARD_SDEXT_DEVICE := /dev/block/mmcblk1p2
Click to expand...
Click to collapse
But, this is my first attempt at hacking cyanogenmod onto a half-baked device, so... don't take my word for it
And before anyone asks, yes, I plan on releasing a flashable update for this, but first... figuring out enough to start from a fresh source tree and build from scratch so I can document how I did this... Let's beat the carriers to jellybean and forget ICS
(yes, I'm editing this post a bazillion times as try stuff, I'll put together something a little more coherent soon)
Hi. This developer gathering sounds promising, I'm glad you guys help each-other for the benefit of users and leave personal fame aside.
But. GT-S5830i Spain (Moviestar) (S5830IBGLH4 S5830IXECLH2)
All your kernels have the Sim contacts not available critical bug. And I say critical as it's a basic function of a phone.
There is only one workaround, flashing the S5830CVJKL4 baseband (odin-izing just the phone=modem part is enough).
- then I've noticed that it greatly affects network reception with 30-70% less signal and no signal at all in some places.
- and it does not end here: antutu gpu scores goes down from the already low 290~ish to <190~ish.
- flashing the whole stock S5830CVJKL4 firmware with it's stock kernel has the same bad network reception and low antutu gpu scores.
So this workaround ends up doing more harm than good.
So now I have some questions for all of you, Rafael.Baugis, axyllum, hell-lock:
- what source do you use for building as Samsung provides no less than five S5830i sources: GT-S5830I_CHN_GB,
GT-S5830I_HK_GB, GT-S5830I_MEA, GT-S5830I_SEA_SWA_GB and GT-S5830i (I'm guessing none of them, but some C/M version).
In the light of these findings, can we say:
- "The kernel can be used on any rom." notice in all your releases is just wishful thinking and a bit misleading?
- there is yet another hardware difference (the modem) at least with this Moviestar version and should be blacklisted for now?
- there is something special with this S5830CVJKL4 firmware?
Thank you very much for your hard work.
It's not really critical if there's a workaround.
Also, simpler workaround: use your Google account to sync contacts.
WHAT THE ****!! That bug is on my kernel too??!!
---------- Post added at 04:21 PM ---------- Previous post was at 04:20 PM ----------
I am using GT-S5830I_CHN_GB ...
hell_lock said:
That bug is on my kernel too?
Click to expand...
Click to collapse
Unfortunately.
I've checked the 3 custom kernels vs. 6 stock roms and 6 custom roms for the s5830i. This Moviestar version does not work, and from the number of complains all over the threads here, I'm guessing there are other models that simply do not work. These should be blacklisted so people don't get their hopes up and start flashing each time one of your kernel versions is updated (this needs input from all the people complaining, a forum search should be a good start, maybe I will do it later).
It's a shame that all that is missing is a suitable config/driver for the kernel - or could the problem be in the locking mechanism - the phone I'm testing is factory unlocked. The source code will clear this up I think, but who do we have to push to get the Moviestar source code as I understand they are bind to release it on request? I will look into this.
Bottom line, there is nothing wrong with your kernels other than not addressing this phone's issues.
GermainZ, there are people that can live with the google contacts sync, good luck with that, but for people that use many sim cards interchangeably it would be a problem (requiring multiple g-accounts, selective syncs). What would you say if your sdcard does not work and the answer you get from support is: "You can use the skydrive cloud instead". Easy to spot unsuitable tasks.
bobdynlan said:
Unfortunately.
I've checked the 3 custom kernels vs. 6 stock roms and 6 custom roms for the s5830i. This Moviestar version does not work, and from the number of complains all over the threads here, I'm guessing there are other models that simply do not work. These should be blacklisted so people don't get their hopes up and start flashing each time one of your kernel versions is updated (this needs input from all the people complaining, a forum search should be a good start, maybe I will do it later).
It's a shame that all that is missing is a suitable config/driver for the kernel - or could the problem be in the locking mechanism - the phone I'm testing is factory unlocked. The source code will clear this up I think, but who do we have to push to get the Moviestar source code as I understand they are bind to release it on request? I will look into this.
Bottom line, there is nothing wrong with your kernels other than not addressing this phone's issues.
GermainZ, there are people that can live with the google contacts sync, good luck with that, but for people that use many sim cards interchangeably it would be a problem (requiring multiple g-accounts, selective syncs). What would you say if your sdcard does not work and the answer you get from support is: "You can use the skydrive cloud instead". Easy to spot unsuitable tasks.
Click to expand...
Click to collapse
Do you know what file is missing? I may fix it.
bobdynlan said:
Hi. This developer gathering sounds promising, I'm glad you guys help each-other for the benefit of users and leave personal fame aside.
But. GT-S5830i Spain (Moviestar) (S5830IBGLH4 S5830IXECLH2)
All your kernels have the Sim contacts not available critical bug. And I say critical as it's a basic function of a phone.
There is only one workaround, flashing the S5830CVJKL4 baseband (odin-izing just the phone=modem part is enough).
- then I've noticed that it greatly affects network reception with 30-70% less signal and no signal at all in some places.
- and it does not end here: antutu gpu scores goes down from the already low 290~ish to <190~ish.
- flashing the whole stock S5830CVJKL4 firmware with it's stock kernel has the same bad network reception and low antutu gpu scores.
So this workaround ends up doing more harm than good.
So now I have some questions for all of you, Rafael.Baugis, axyllum, hell-lock:
- what source do you use for building as Samsung provides no less than five S5830i sources: GT-S5830I_CHN_GB,
GT-S5830I_HK_GB, GT-S5830I_MEA, GT-S5830I_SEA_SWA_GB and GT-S5830i (I'm guessing none of them, but some C/M version).
In the light of these findings, can we say:
- "The kernel can be used on any rom." notice in all your releases is just wishful thinking and a bit misleading?
- there is yet another hardware difference (the modem) at least with this Moviestar version and should be blacklisted for now?
- there is something special with this S5830CVJKL4 firmware?
Thank you very much for your hard work.
Click to expand...
Click to collapse
all kernel sources from samsung have this issues in SIM contacts!
the roms VJKL4 and rajrocks work SIM contacts!
but need to flash param.lfs in ODIN.
hell_lock said:
Do you know what file is missing? I may fix it.
Click to expand...
Click to collapse
That's the problem. I guess the Spain Moviestar version is based upon GT-S5830I_EUR_XX source (GT-S5830i_Opensource.zip). If that's so, there are quite a few differences between the european kernel and the chinese one you are using, confirming my theory that you can't build an universal kernel that works on all roms.
Differences are mostly incremental patches, touchscreen stuff, but also the suspected different locking stuff. modules\drivers\char\brcm\fuse_ril. I have zero inside knowlege of this stuff, but I interpret lines like #define BCM_CFG_SIM_LOCK_SUPPORTED as: CHN kernel enforces a check for SIM LOCK & other SIM related stuff while the EUR kernel does not.
Samsung will not help modders with this (network sim stuff) instead will direct you to mod the kernel from the right source. So the feasible solution is to build different kernels for phone models that have this issue - bye bye universal kernel (it never was universal, it just worked cause samsung did a great job; samsung would have not bothered to keep each platform with a coresponding kernel source).
Attached the actual different files (not a diff patch) between the CHN and EUR Samsung opensource.
Rafael.Baugis, did not know that all samsung sources are having this issue. Did you also test build from this EUR one?
bobdynlan said:
GermainZ, there are people that can live with the google contacts sync, good luck with that, but for people that use many sim cards interchangeably it would be a problem (requiring multiple g-accounts, selective syncs). What would you say if your sdcard does not work and the answer you get from support is: "You can use the skydrive cloud instead". Easy to spot unsuitable tasks.
Click to expand...
Click to collapse
I never said it shouldn't be fixed, I simply said it's not critical (considering not many people use more than a sim card; you're right I didn't think of all possible scenarios, I never thought of yours).
And I'm most certainly not the support.
Also, regarding the EUR kernel, it's outdated. I could try compiling the stock kernel from it if you want.
Is sim working on any source based kernel??
Sent from my GT-S5360 using XDA
Hi all, I hope I can provide reliable good news: LG support says some providers made some changes to some repeaters (e.g. E-Plus in Germany). They have a solution and provide us with an update released around the end of October.
Now is probably a good time to point LG to some of the major problems introduced with the JB update (4.1.3), as the new Update will likely be a smaller improvement of the latter.
In my case:
- very slow return to home screen when closing apps and problems navigating the home screens, when some more icons and widgets are present
- can't write onto external SD with some backup apps (e.g. Super Backup)
EDIT: I would be totally happy about a way to port the updated system files, once they are out, to other Roms (e.g. the ICS Stock Rom).
I'm extremely skeptical that LG would release an update for our phone. Are you sure our model is on the list?
I called them personally regarding a prior support case (repair order -> "no error found") because somebody reported the techs had replaced some parts (new IMEI) and solved the problem. I wanted the same for my P880. They told me about the changes to some repeaters, the upcoming update, and the soon following update for the P920 (?) Optimus 3D.
I am as surprised and sceptical as you are. But as I have read about this update from a second, independent, source (the German forum at AndroidPit.de), I am starting to believe and, thus, spreading the news.
pegnose said:
I called them personally regarding a prior support case (repair order -> "no error found") because somebody reported the techs had replaced some parts (new IMEI) and solved the problem. I wanted the same for my P880. They told me about the changes to some repeaters, the upcoming update, and the soon following update for the P920 (?) Optimus 3D.
I am as surprised and sceptical as you are. But as I have read about this update from a second, independent, source (the German forum at AndroidPit.de), I am starting to believe and, thus, spreading the news.
Click to expand...
Click to collapse
Can you please point us to that article on androidpit.de. Thanks
I Tried to find but no result.
See here (look for "FETTES UPDATE" on top of the page):
http://www.androidpit.de/forum/562054/lg-optimus-4x-hd-reorganisation-interner-prozesse/page/2
Sorry, this is a German post. Although the writer confused repeater with router, P920 with P990, and another user confused software and hardware update.
EDIT: My support guy explicitly statet that this will be an OTA update. I am sceptical, as it happens often with LG that updates have to be installed manually/via PC. Very likely he meant that I won't have to "bring in" my device again.
I just called them again and explicitly named the increasing delay when returning to and browsing the home sreen as the major problem with the official JB rom on the P880. If some hundred more users do the same, LG hopefully addresses the issue as well.
pegnose said:
I just called them again and explicitly named the increasing delay when returning to and browsing the home sreen as the major problem with the official JB rom on the P880. If some hundred more users do the same, LG hopefully addresses the issue as well.
Click to expand...
Click to collapse
I just don't think that some repair guy from LG can do anything else then told you what you want to hear and mark it as solved. I think they are just waiting till you buy new device. I'm lucky because I have no such problems with RIL. I disabled PIN protection and installed Mahdi. Now I sometimes (once per day?) can see no signal for second or two but it's ok.. no problems (there is no way for no signal, I'm living next to the mobile transmitter and I usualy have full signal bar). There is only one thing which gets me so angry - lags, usualy when listening music from youtube on background and browsing the Internet. My friend with Galaxy S laughs when my phone gets his lucky mood and he sees it, his phone is more smooth then mine, it's crazy.
Of course, this might all be a big hoax. BUT:
By now, I know of three different people who got pretty much the same information from LG support. Although you never know, for my part, I wouldn't like to suspect that LG internally agreed on certain standards on how to efficiently lie to their customers in this particular matter through personal communication - especially by giving an approximate release date (end of october) for the update AND outlining the release for the P920 as well. But that's just me thinking positively of other people and of the future.
Btw, could you elaborate a bit on this Mahdi thing you mentioned? I tried different Roms (Cyanogen, OmniRom) and none of them solved the RIP (Reorganizing internal processes) issue. Plus I unsuccessfully tried to fix it with EPRJ RIL implementation following this guide (experts might go *facepalm*, I tried anyways):
http://forum.xda-developers.com/showthread.php?t=2496075
Therefore I came to believe that RIP (my ideosyncratic acronym) and RIL are two pairs of shoes. No? Also, I don't really understand, what PIN protection has to do with anything.
pegnose said:
Of course, this might all be a big hoax. BUT:
By now, I know of three different people who got pretty much the same information from LG support. Although you never know, for my part, I wouldn't like to suspect that LG internally agreed on certain standards on how to efficiently lie to their customers in this particular matter through personal communication - especially by giving an approximate release date (end of october) for the update AND outlining the release for the P920 as well. But that's just me thinking positively of other people and of the future.
Btw, could you elaborate a bit on this Mahdi thing you mentioned? I tried different Roms (Cyanogen, OmniRom) and none of them solved the RIP (Reorganizing internal processes) issue. Plus I unsuccessfully tried to fix it with EPRJ RIL implementation following this guide (experts might go *facepalm*, I tried anyways):
http://forum.xda-developers.com/showthread.php?t=2496075
Therefore I came to believe that RIP (my ideosyncratic acronym) and RIL are two pairs of shoes. No? Also, I don't really understand, what PIN protection has to do with anything.
Click to expand...
Click to collapse
Mahdi is mod like Cyanogenmod, we have unofficial support from alfsamsung (he's great developer) you can find the thread in Optimus 4x development section (without "original"). He did a lot of changes in baseband driver & ril. Btw that reorganising bug is only in stock isn't it? I think in CM based roms is only crashing ril and asking for pin again or full crash of ril and baseband driver so you have to reboot your phone.
When I was running stock I never saw it (that reorganising..) I only saw someone talking about it here on xda.
I'm not optimistic because LG said that our phone won't get any update in future. I just don't think that they changed their opinion because of few people crying to their hotlink.
I'm so sorry about my english, my skills are just terrible
An update for Germany is out:
http://www.android-hilfe.de/lg-optimus-4x-hd-p880-forum/623458-update-v20c.html
Looks like the problem is gone!!!