Database Users

GPS to be unlocked by Sprint in Q4

I was told by my friend who works at Sprint today that they will be unlocking the GPS in Quarter 4 of this year.
She said that originally they did not unlock it as they were having issues with the hardware and software, but are prepping to unlock it soon to us.
Sorry if this has been put out there already, but thought I would share what I heard. hopeful anyway, huh?

Is this guy a reliable source of info? Or is he a rep who hears stuff through the grapevine like the rest of us? (I've heard some crazy misunderstood info coming from people who "work for sprint")
Over at ppcgeeks.com someone dissasembled their Mogul and the general conclusion was that the GPS had been disabled via hardware, although they admit they're not sure.
The rumor also was that it would be available to us with the Rev A update due to come out soon. Although no one knew for sure where this info came from. Could be someone made it up, wishful thinking.
So, yes, this rumor has been around, but we're still waiting for someone to actually confirm it.
Honestly, I'll beleive it when I see it.

Dishe said:
Is this guy a reliable source of info? Or is he a rep who hears stuff through the grapevine like the rest of us? (I've heard some crazy misunderstood info coming from people who "work for sprint")
Over at ppcgeeks.com someone dissasembled their Mogul and the general conclusion was that the GPS had been disabled via hardware, although they admit they're not sure.
The rumor also was that it would be available to us with the Rev A update due to come out soon. Although no one knew for sure where this info came from. Could be someone made it up, wishful thinking.
So, yes, this rumor has been around, but we're still waiting for someone to actually confirm it.
Honestly, I'll beleive it when I see it.
Click to expand...
Click to collapse
This person is a software engineer at Sprint, and she said that the reason they didn't have it unlocked in the beginning was due to a hardware/software conflict, but that it will be unlocked in an upcoming ROM update. She said that Sprint had announced it somewhere internally.

I have a few contacts in sprint, I'll try verifying this tommorow

From what I understand, the Mogul has A-GPS. This is the same GPS that allows them to find you if you make an emergency call. It does not work off sattelites but rather from cell towers.
On the bright side, it shares the same Qualcomm 7200 chip that the Kaiser will use.
Some maintain that the Kaiser has built in GPS, others claim it has no satellite antenna and requires an external antenna.
Sprint originally advertised the phone as having GPS. Now that has been removed from their advertisement.
It will be ineresting to see what will happen with the evdo rev. a upgrade later this year.

rambo6 said:
From what I understand, the Mogul has A-GPS. This is the same GPS that allows them to find you if you make an emergency call. It does not work off sattelites but rather from cell towers.
Click to expand...
Click to collapse
Exactly. The bottom line from what I understand is that the Mogul does not have the built-in hardware to do full GPS that will work with independent mapping software (Google, etc).

[RANT]This is getting a bit old - people claiming that A-GPS does not work off satellites.
Please do some research before posting this type of mis-information.
A-GPS is Assisted GPS. It uses information from the cellular network to ASSIST the GPS for faster TTFF.
And the Mogul uses a different chipset than the Kaiser. One uses the 7200, while the other 7500.[/RANT]

Ok... so now that you ranted... is it your opinion that the Mogul will or will not be able to do full GPS?
And actually.... A-GPS doesn't directly work off of the satellites. Since it takes a long time for a cell phone device to download the positioning data from the GPS satellites, what the A-GPS system does is let the A-GPS servers at the cell towers download and accumulate the data, the cell phones then talk to the A-GPS servers to get the data (which happens within seconds).

When A-GPS is enabled, would it have the possibility to work with Mobile GMaps ? Or is the Java still restricted?

Don't we have A-GPS already enabled? Isn't that the little GPS icon in the phone dialer? I know I have the option to turn it off/on in the phone settings just like all other agps handsets.
If something is going to be "enabled" with a new update, that means it will most likely be real standalone GPS.
TC1, no one knows that for sure. It was speculated.

I AM POSTING THIS FOR THE LAST TIME
The Mogul has the Qualcomm msm7500 as its cpu. BUILT INTO the cpu is the gpsone chipset. This is able to achieve AGPS as well as GPS. It runs in 4 different modes. To have the serial link to work with applications the chipset must be run in standalone mode.
It is on the damn phone as it is part of the cpu! It is currently not in standalone mode so there is no way to access the chip. The only true thing up in the air is whether or not the phone can obtain a satellite lock in standalone mode.

Dishe said:
Don't we have A-GPS already enabled? Isn't that the little GPS icon in the phone dialer? I know I have the option to turn it off/on in the phone settings just like all other agps handsets.
If something is going to be "enabled" with a new update, that means it will most likely be real standalone GPS.
TC1, no one knows that for sure. It was speculated.
Click to expand...
Click to collapse
Correct, like almost every modern cell phone, A-GPS is enabled. There is no debate there.
I agree with you regarding speculation on the "stand-alone GPS" aspect. I've never seen definitive info from HTC that says yes or no on this subject. If there is real info regarding this, some links would be nice.

HTC's site says:
It is widely rumored that this phone has a GPS chip that has been disabled. Will there be a hack or workaround to enable GPS capabilities?
Answer: Not likely, it is AGPS which requires a connected call to get data location.
Click to expand...
Click to collapse

Sonix6 said:
HTC's site says:
Click to expand...
Click to collapse
thats from their wiki site, so its not necessarily true
/me keeps fingers crossed

This would be good news. I'll be keeping my fingers crossed for this.

gpsone (in most all msm chipsets including kaiser and mogul):
How gpsOne Works:
The gpsOne technology functions in four different modes of operation. Chosen automatically or specified by software, the
four modes are Standalone GPS, Mobile Station (MS)-based, MS-assisted and MS-assisted/Hybrid. In the A-GPS modes,
gpsOne technology utilizes assistance data from a location server in the wireless network in combination with A-GPS circuitry
and software in the wireless device.
Note: The common term used by standards bodies for the handset/terminal device in CDMA2000 is "Mobile Station" (MS) and in WCDMA (UMTS)/GPRS/GSM/HSDPA/EDGE is
“User Equipment” (UE). For simplicity in this document, references to the handset/terminal will be "MS," but this use implies both MS and UE.
Standalone GPS: The GPS receiver calculates a position without using any assistance data and without a connection to
the wireless network.
MS-Based: The GPS receiver calculates the position using assistance data from a location server to increase cold-start
sensitivity and reduce the start time for an initial position calculation.
MS-Assisted: The GPS receiver uses assistance data from a location server to make measurements related to its distance
from the GPS satellites, then sends this information to the location server where the position is calculated. This mode also
increases cold start sensitivity and reduces the start time for an initial position calculation.
MS-Assisted/Hybrid: Wireless network information is added to GPS measurements as part of the position calculation by
the location server, integrating the relative strengths of GPS information and available wireless network location information
for increased positioning reliability in difficult GPS environments.
In assisted operation, a gpsOne-enabled handset receives
a small “assistance data” message from a network location
server using standardized protocols
• The handset then reads information from GPS satellites to
measure its distance from all the satellites it can see (called
“ranging” information).
• The handset then uses this ranging information to create a
position “fix,” or sends the ranging information back to the
server where it can be combined with network information
to produce an even better fix.
• gpsOne also operates in Standalone mode, without requiring
any assistance data from the network
straight from the gpsOne document.

interesting indeed... question is, will Sprint release firmware that allows it to run in standalone mode?
I suppose the truth is, even if it doesn't, someone can figure out how to enable it with some sort of hack eventually since its just software controlled according to this document.

has anyone played with this reg key?
\HKCU\ControlPanel\PhoneExtendFunction\CDMA\GPSOneSetting = 0
Edit: the value does not contain a space between "GPSOne" and "Setting", but vbulletin modifies my text when i post....

I don't know if this info helps or not... I spoke to a HTC TS and they told me the 6800 has GPS but is sprint decision to enable it or not. He also told me that it can be unlock but sprint is the only one with the code and he can not provide me with that info.

New poster old reader, may be found some info.
I found Many info that may me can help somebodies about the msm 7500 (gpsOne technologie)...It is hard to know what to believe 'cause half/half
people say that this is impossible, and the other half say that gonna happen soon. I think that we should make our own idea by our own knowledge . I found many topic on many forum (htc, gpsunderground,here...ask me if interressed) One Qualcomm offical site i've got pdf about msm chips, and gpsOne tech... (Snap track location service for gpsOne may be a good start point to invest)
Interessing link's:
FCC test repport for tita100 (titan) (That include plane mode settings):
https://gullfoss2.fcc.gov/oetcf/eas...lledFromFrame=N&application_id=391628&fcc_id=
Here it seem to be codes:
http://www.wlt.net.cn/index0/FD-800/pdf/CNI FD-800 gpsOne Menual ver1 0_0117.pdf
Similar:
http://www.wlt.net.cn/index0/FD-800/pdf/FD-800_Application_Guide ver1 0(1).pdf
And found other about SDK from Qualcomm API's seem to be aivalaible to third party dev. Also seem to be hard to be registred as dev. But hope...
And if internal budies have code it is just a time question before a solution.
So i wish that i'm not making more mistake or false info...if tell me.
And for gps freak who will tell that different anthenna needed, diffrent frequencies for GPS...see the end of the document FD-800 manual (2nd link).
So thank for this helpfull forum, forgive my poor english expression, and lack of programming knoledge , my is disignig pcb, and electrical pannels, but not to programme them's( not enough )...

DEV: PPP Issues. Improvement + Summary

This possibly needs to be in the dev section but I will start here.
First off this is not a complaint. What I initially want to do is get an understanding (Technical) of the issues around the PPP dropouts and locks ups.
From where I sit this is the only outstanding issue around the current android builds. Simply the phone rocks on SD card and is ultra stable and fun.
I have noticed various wiki'sstate that internet access is complete however obviously not.
There are a number of issues such as
1: Network dropout. Data connectivity will stop responding. Restart of the radio or mobile data needed
2: Network freeze. Android restart as the radio will not turnoff.
3: console level networking not avail. Eg ping etc simply does not work. DNS does not resolve and ping cannot find a route. Std Android this works fine.
4: Related issues. GPS-A data not downloadable. Only via application layer tool.
Is PPP the default connection type on factory android builds?
What is the difference between the HD2 in dev and a std android with the implementation of the data connection.
How can I help. I have over 20 years in IT and have a thorough understanding of TCP IP layers and routing. I have reasonable understanding of Linux and the kernel IP stack but zero understanding of the android kernel or application layer.
I also have dollars to contribute.
Update:
Currently I am trying all four with isome improvements
1: Updated the Ril WRapper with no luck.
http://forum.xda-developers.com/showthread.php?t=794309
2: Change the phones default connection to GSM PL.
Change the setting found in the menu phone info when you "call" *#*#4636#*#*. There is a option to choose your preferred network. Set to GSM auto (PRL)
3: Update DNS settings.
http://forum.xda-developers.com/showthread.php?t=812930
4: Ensure the correct APN's are being used.
This is no internet versus unstable Internet.
Note. Currently trying all four and things are improving. Had my first dropout after 36 hours versus 2 per day. It happened whilst using the GPS and making a call which always tend to be a stresser anyway. Will try to keep this thread updated.
This thread also has a number of updates http://forum.xda-developers.com/showthread.php?t=813148
I am running a stock WinMo Rom (Latest European release 3.14 I believe). 2.15 radio on a Telstra Network in Australia. My phone is a T8585. Also running [19.10.10]|<<Mdeejay FroYo Sense Series>>|2.25.771.1| cos I like the transparent titlebars
Now I have been running all 4 of the above for around a week now and have to say there is a def improvement. Where it was common to get multiple disconnects per day I have only had 3 in the last week. Mainly when I use the GPS.
I am still searching and have yet to find a 100% fix the stability is now at a point of reasonable reliable. Also noted that the Devs are still hard at work on this.
Update 31-10-2010
A good test is to open google maps while driving. Its about the only time I get a drop out now.
The GPS kicking in always stresses the radio and that combined with the handover of cell sites is a great deal breaker.
This also seems to be consist with my suspicions around the poor handling of corrupt connections.
Eg the system on fresh boot only has a table for handling 50 connections line. This ensures it can handle multiple simultaneous connections as well as background coms.
Now when a connection is damaged or locked normally it should timeout and/or then be deleted from the table. My suspicions is that this is not happening and all the avail connection handling are slowly filling up until there are now free. Frozen this is why it seems to be very unlikely for a freeze to occur straight after a restart but more likely after a day. Also dependent on stress environments. Homes with lots of RF noise, Long way from cell towers, driving, lots of gps use, Wifi cut over.

http://forum.xda-developers.com/showthread.php?t=812930&page=7
http://forum.xda-developers.com/showthread.php?t=794309

Thanks for the response.
I was not looking for work around but more technical information to try and identify where the issue lies. curious to see if ppp is the default and if the ppp implementation should work or is it still a hack/work around.
The steps I have tried are
1: Updated the Ril WRapper with no luck. No improvement
2: Change the phones default connection to GSM PL. No improvement
3: Update DNS settings. Still testing however does not resolve console level network issues and unlikely related to ppp freeze. No logic?
4: Ensure the correct APN's are being used. No improvement
Note. Currently trying all three
This is also separate to a lot of people issues around APN's. From the application layer internet works fine except for the freeze.

I believe rmnet is android's default connection and ppp is winmo's. I think dft reengineered ppp for Android. Remember seeing it some where when ppp first started to appear. Of course this is how I remember it and my life is hectic so it might be the opposite.
Sent from my Mytouch HD2

So I understand that one of the issues with RMNET was dropped packets. Was this due to it not being correctly engineered/implemented or just a nature of the beast?
Also with the issues everyone is having why are we not continuing to investigate RMNET as at least this was initially more stable and more of a native option.

dusty_nz said:
So I understand that one of the issues with RMNET was dropped packets. Was this due to it not being correctly engineered/implemented or just a nature of the beast?
Click to expand...
Click to collapse
That is because it isn't implemented correctly. The radio receiver in our phones was made for PPP, not for RMNET. Latter is standard in native android devices. And there it works very fast and stable. So the devs had to implement PPP in android, which isn't proper working. But they're working on it to improve the stability, I'm pretty sure 'bout that. At least it does work and I had never problems with loosing my connection and bad speeds.
Edit: Those are the known steps to get it at least halfways stable working.
Cheers

Okay.
Did some more playing.
Both RMNET and PPP allow pinging from the console. Just had to enable SU first.
Thanks everyone for your info. Will try my best to be patient.

dusty_nz said:
Okay.
Did some more playing.
Both RMNET and PPP allow pinging from the console. Just had to enable SU first.
Thanks everyone for your info. Will try my best to be patient.
Click to expand...
Click to collapse
But did you also have a delay till it worked? It took me about 20 seconds before any reply came up. And does your ping test work if you try it in the hidden menu when you "call" *#*#4636#*#*?

Aye.
There was a delay and the hidden menu ping does not work either.
Still needs work.

dusty_nz said:
Aye.
There was a delay and the hidden menu ping does not work either.
Still needs work.
Click to expand...
Click to collapse
Right.
Have you seen this thread? It might be a possible solution.
Some people have reported that it works. But I had no time to test it. Had to move servers

That is fix number 3. Update DNS. Testing now. Only been 24 hours however no drops.
Seems strange thou. Hard to imagine it is a DNS issue.

On a side note. Does anyone know what changes to the Rom are needed when installing an RMNET kernel?
Eg If I took the latest MDeejay rom and changed the kernel?

Update
Update on first post.
Def improvements to be found. DNS seems to be the biggest improvement for me but also running all 4 at once.

dusty_nz said:
On a side note. Does anyone know what changes to the Rom are needed when installing an RMNET kernel?
Eg If I took the latest MDeejay rom and changed the kernel?
Click to expand...
Click to collapse
No one who knows cares enough to answer.
As far as I can tell, no 'modern' build uses an rmnet kernel anymore, because apparently the chefs either don't care about data reception, or don't think that there is a problem because they don't leave a build on long enough for it to start developing problems.

enneract said:
No one who knows cares enough to answer.
As far as I can tell, no 'modern' build uses an rmnet kernel anymore, because apparently the chefs either don't care about data reception, or don't think that there is a problem because they don't leave a build on long enough for it to start developing problems.
Click to expand...
Click to collapse
any build that says it uses michyprima r11 is still rmnet based. I don't think the nexus one-based kernels worked with ppp at all.
on another note, I was getting loads of Network Freezes (where flicking airplane mode wouldn't reset the data connection) since last week despite not fundamentally changing anything in my Android setup (see sig). However been doing some research around xda yesterday and may have found something else that's improved my ppp connection stability (so far) and resolved my constant network freeze issue... will update when I've tested this for a few more days.

Some improvment?
APNs are correct, Did the RIL_WRAPPER with no significant improvment. This morning I changed to GSM PRL and noticed an improvment.
Before the GSM PRL, I had many PPP drops, especially when streaming large amounts of data. After the GSM PRL update, I did try streaming youtube, Last.FM, slingpalyer together and NetTest, concurrently, everything is working with no PPP drop.
This is not enough to reach a conclusion, but nevertheless, I never could have done it before
Have a look here.
Stock rom 1.48 WWE, radio 2.15.50 and Froyostone 3.2
Thanks for the support!
BTW: How can I obtain the DNS information for my mobile carrier?

Just report.
I didn't believe change dns will work.
But after I change dns, the data suddenly work ( no need to restart!).
So I think it have something relate to dns.

Same thing. Updating the DNS in the build.pro file seems to have the greatest benefit.
I have a suspicion that the issues are caused with the network driver not flushing dead connections. Eg outgoing requests that to not get a reply. Ideally they should be flushed other wise the connection cache will fill until it can no longer take more connections. Symptom dead/frozen internet
All the symptoms seem to relate to this sort of issue
Things like ppp drop out more likely when on the move (More dropped packets). GPS and wifi but back. etc.

@Dusty_Nz,
Thanks for your help, this is a great thread and its certainly appreciated (the devs are busy enough as it is, xda member contributions are a great help).
As it was asked a few posts up, how do I obtain the DNS settings for my carrier? I am using TMobile US and I'd like to test your observations.
Thanks!
Sent from my HTC HD2 using XDA App

tgtoys said:
@Dusty_Nz,
Thanks for your help, this is a great thread and its certainly appreciated (the devs are busy enough as it is, xda member contributions are a great help).
As it was asked a few posts up, how do I obtain the DNS settings for my carrier? I am using TMobile US and I'd like to test your observations.
Thanks!
Sent from my HTC HD2 using XDA App
Click to expand...
Click to collapse
Follow the link on post 3
will then lead you here.
http://www.opengear.com/faq383-Confi...-APNs.html#USA

[FIX]◊[JVK]◊ PlumbBob GPS Fix [UPDATE 4/10/2011] <Insert unfunny Bob joke here>

[FIX]◊[JVK]◊ PlumbBob GPS Fix [UPDATE 4/10/2011] <Insert unfunny Bob joke here>
UPDATE: plumbBob GPS Fix for Captivate v2.0 BETA 11 [JVK] is now available for testing
http://forum.xda-developers.com/showthread.php?p=12761703#post12761703
UPDATE: plumbBob GPS Fix for Captivate v1.1 RC1 is now available for testing
http://forum.xda-developers.com/showthread.php?p=12781991#post12781991
In short, I've managed to get the GPS running as well as I can, at least given the tools and sources available to me. Version 1.0 of the fix is now believed stable and effective on all platforms and ready for release.
Problem Summary:
Hardware:
- The Samsung Galaxy S series (and the Captivate in particular) make several design compromises to fit the superslim candybar form factor, some of which tend to limit GPS performance. Among them are the use of a very small patch antenna located in a less-than-optimal position (behind/underneath) as the primary antenna. The effect of this is worsened by an under-engineered attempt to use the aluminum battery door (of suboptimal size and material for this role) as an auxiliary antenna, a problem worsened by using only a weak hinge spring as the connection. In a nutshell, the Broadcom BCM4751 GPS chip itself might potentially be capable of very acceptable performance, but Samsung's design and implementation cripples it badly. There's quite little we can do about any of this, and many previously published hardware hacks risk permanent damage to the phone.
- Design and/or manufacturing faults may cause potentially problematic levels of electromagnetic interference (EMI) within the housing and/or lead to intermittent power starvation of the GPS unit (this hypothesis gains credence since GPS performance is frequently improved by plugging in to a car adapter) . Additionally, strategies for managing GPS processes and CPU load seem under-optimized with GPS processes not being properly prioritized. There's quite little we can do about any of this either, especially with the driver being closed source.
Software and Configuration:
- Samsung's drivers are proprietary closed source, greatly limiting the ability to date of open source developers to improve GPS performance. Since Samsung receives the chips from Broadcom sans driver and with only an SDK, this might be reasonable and tolerable ̶— if the drivers actually worked. However, nothing that can be done about this short of hoping for a leak or some other misplaced miracle.
- The stock Samsung driver and configuration does not make use of WAAS augmentations at all even though the chip is actually capable of utilizing WAAS. Modern WAAS-capable receivers are typically capable of at least <3m accuracy but SGS users seldom see accuracy of even 5-10m. Again, closed source driver = nothing can be done about this.
- The stock Samsung/AT&T configuration for the GPS settings is horribly, laughably, and inarguably flawed. The out-of-box configuration is essentially incapable of ever allowing acceptable AGPS-aided performance. This fix attempts to remedy the flawed configuration settings.
- In a slim mobile phone application AGPS (Assisted GPS) augmentations are not just optional performance enhancers. Indeed, AGPS augmentation is fairly necessary for a GPS receiver with such a small under-optimized antenna as once AGPS data is loaded weaker signals can be utilized. This fix attempts to make sure the AGPS augmentations are properly downloaded and implemented.
Description:
plumbBob GPS Fix uses a markedly different strategy from most previously released GPS fixes, most of which attempted to turn off some of the various augmentations and improvements to the raw GPS position data like AGPS and position smoothing. These strategies apparently operated under assumptions that the implementation of these features was simply too flawed to be useful and that eliminating these features would feed only "pure" data to apps instead.
It seems however that these features may have been more necessary than had been assumed. Since with previous fixes many users could get satisfactory stationary fixes but unsatisfactory tracking on the move, I decided some of the "purification" feature-deactivating strategies used by previous fixes might be instead feeding unusably "jittery" location data to the navigation app, confusing the app and causing some of the weird tracking errors many of us were getting.
Many previous fixes also focused inappropriately only on one or a few areas where configuration settings might be applied. Instead, plumbBob attempts to present a "whole solution" answer to the problem rather than hoping that a single magic bullet might do the trick reliably.
The plumbBob GPS fix has two primary goals:
- Make configuration changes to get the necessary AGPS augmentations working properly to allow the device to function as its designers presumably hoped for, and
- Reduce the mobile tracking errors that seem to persist under most previous GPS fixes
Features:
- Updated GLGPS daemon binary from Nexus S Gingerbread (which is also same as UCKB1 AT&T stock Froyo)
- Updated shared object libraries from stock UCKB1 release
- Official AT&T certificate file (usually omitted in most custom ROMs adapted from non-AT&T platforms) to allow Secure SUPL for security & privacy
- Regionalized NTP (internet time sync) server configuration for improved TTFF (Time to First Fix) performance
- Tweaks to configuration files needed to allow proper download and application of AGPS augmentations and improved mobile tracking
Supported Platforms:
- Captivate only, at least for now. In initial testing some Vibrant testers managed to successfully implement this fix with good results, but others experienced some fairly major problems. There are some important differences in the GPS handling on the different Galaxy S variants that may limit the effectiveness of this fix on other platforms. For instance, the Vibrant uses the AGPSD daemon for GPS handling but for some inexplicable, inscrutable reason the Captivate uses GLGPS instead even though they both use the same BCM4751 chip. And then the Galaxy S I9000 series uses a completely different chipset (Broadcom BCM20751) that includes Bluetooth and FM radio. Configuration interfaces vary considerably between the various models and as such installation on any other platform can only be undertaken completely at your own risk. Developers interested in porting and testing the plumbBob GPS Fix for other platforms are encouraged to contact me by PM.
Changelog:
See 2nd post.
Thanks to Da_g, CLshortfuse, and Adam Holden/Team Phoenix for their previous work that guided my research. And many thanks to the many testers who weathered my mistakes and contributed to the final product.
IMPORTANT: LbsTestMode settings must be manually updated as well!
SUPL/CP Settings: Server FQDN = Custom Config, Server: supl.google.com, Server Port: 7276, SUPL Secure Socket = ON, AGPS Mode = SUPL
Application Settings: Tracking, S/W Test, MS Based, Hot Start, GPS Plus = On, Dyn accuracy = on, Accuracy = 40, GPS logging = off
Installation Instructions:
Download the appropriate .zip for your region
BEFORE FLASHING - Use LbsTestMode to apply new SUPL/CP and Application Settings (see above) and delete GPS data
Copy to /sdcard/ root and flash using CWM recovery
Ensure Settings -> Location and Security -> Use GPS Satellites is ON
Ensure Settings -> Location and Security -> Use wireless networks is ON
Note: If your country or region is not listed or if you need to change regions while traveling etc., the easiest way to customize the NTP setting as needed is to use the free Faster Fix app from the market.
Note: At present Southern California is still located in the USA.
CAUTION: Though it works great for some, Serendipity 6.0+ and above DOES NOT seem to work well with plumbBob 1.0 for all users. I don't know if it's related to the JS7 base or Serendipity-specific customizations, but several Serendipity users have reported that this fix pretty much wrecks GPS. I'm continuing to look into it and hopefully future versions of this fix may be compatible. And FWIW in my testing I actually had very acceptable GPS performance using stock Serendipity 6.0 settings, so this fix is probably less necessary anyway....
The most recent stable version 1.0 is below. Advanced users who might wish to try out the latest 2.0 Beta version instead may get it at http://forum.xda-developers.com/showthread.php?p=12761703#post12761703

Changelog
Development/Discussion
irc.freenode.net
#plumbBob
Changelog
0.8.2b - Initial public beta release
Replacement GLGPS daemon binary from Nexus S. Thanks to Da_G
Modified jupiter.xml
Enabled position smoothing to help reduce tracking errors
Re-enabled SUPL augmentation
Dynamic Operation Mode set to Automatic
Remove large chunks of unhelpful commented-out debugging code to help speed load time during GPS initialization
Include secgps.conf
Set operation mode MS Based
Include NTP and gpsonextra configuration in gps.conf
0.8.3b
Added regional localization for NTP (Network Time Protocol time synchronization) servers in gps.conf to improve speed and accuracy of time sync, especially for international users. This was reported by many users especially in Europe to improve speed of initial acquisition (TTFF). For best performance download the version for your region, or if your region isn't listed or you frequently move between regions use the GLOBAL version. [This is also the same thing that the "GPS Fix" option in SGS Tools does but provides options besides North America and Europe.]
0.8.4b
added supl.google.com configuration lines to gps.conf. Another fix I found tried this with some apparent success and it really can't hurt. Performance seems roughly the same.
Add the SSL certificate file copied from stock JF6 to /system/bin/gpsd/supl_att_root.cer. This is the certificate used for Secure Socket SUPL connection. This seems to be missing in most to all of the ROMs not based on AT&T code and adapted from Non-AT&T carriers (i.e., pretty much 100% of them). This should allow SUPL secure socket to be used for better security and privacy, but can still be disabled by user with LBSTestMode if performance degrades. Secure SUPL must be enabled in LbsTestMode to be activated!
0.9
0.9:
- updated libsecgps.so from KB1 leak
- updated jupiter.xml from KB1 leak
- updated secgps.conf from KB1 leak
- glgps daemon in Nexus S is the same as KB1, retained
0.91
0.91
- changed operation mode in secgps.conf to MSBASED
- modified jupiter.xml:
* deleted extraneous, commented-out anyway debugging documentation markup
* corrected path to supl certificate to /system/bin/gps/ vs. /system/bin/gpsd/
0.93
0.93
- Fixed /system/bin/gpsd folder name bug
- changed permissions for shared libraries in install script
- tweaks to help reduce jitter and reduce road snapping errors in mobile tracking incl. dynamic accuracy, stop forcing pedestrian, MS Based operation mode
- added additional driver library copied from I897UCKB1 to (maybe) help backward- and cross-platform compatibility
0.94 (Withdrawn)
Withdrawn.
0.942
0.942
-Bug repairs from 0.94(since withdrawn)
- jupiter.xml
- decided Da_g was right and re-enabled forcing pedestrian mode for most frequent location updates
- configured to use supl.google.com instead of 3GPPnetwork.org
- secgps.conf
- changed to supl and port settings to google
1.0
1.0
- enabled PPS (Pulse Per Second) Mode in Jupiter.xml. This is (or would be) a highly accurate means for providing timing control within the unit, but although the chip seems capable it's not clear if the drivers actually make use of it
- increased the WarmStandbyTimeout times to 3 and 6 seconds to help reduce drops
- used a different method of signing the .zip that should (hopefully) allow it to be installed on systems using stock kernels by renaming to update.zip and choosing "reinstall packages" from recovery
2.0 BETA 1
- port of GPS files and new configurations from JV1 Gingerbread for I9000 leak
- improved everything pretty much
Control Plane:
I have continued to experiment with adding the Control Plane supplement (ie using the cell towers' own organic time and location services for controlling call handoff between towers etc.) but in testing I still can't get consistently improved results. For this reason I have decided to not make any changes to the configuration for now. If anything adding Control Plane often seems to degrade acquisition times and # of birds initially acquired slightly, which could indicate that it's not working at all and simply introducing a timeout delay. Or it might just indicate that it doesn't work very well. It's another one of those things that's hard to sniff out inferentially in the absence of GPS driver source, SDK etc.
I did manage to discover that there's even a whole separate control app for implementing Control Plane augmentation. Yes, in yet another example of Samsung's consistently, laughably, schizophrenically fragmented implementation of the GPS controls, there's yet another undocumented place to change settings. No wonder it doesn't work for so many.
I have left the control plane method allowed as an option in the configuration files supplied with PlumbBob 0.8.4b, so users who are still not getting satisfactory GPS performance might experiment with adding Control Plane augmentation by doing the following:
OPTIONAL/EXPERIMENTAL PROCEDURE FOR ACTIVATING CONTROL PLANE SUPPLEMENT:
Open LbsTestMode by using SGS Tools, select "secret codes" and then choose LbsTestmode OR use the phone dialer to enter *#3214789650#
Select "SUPL/CP Settings"
Under AGPS Mode choose "Control Plane" from the dropdown
Open the phone dialer and enter *#1575#
Choose "CHANGE CP STATUS"
Choose "CONTROL PLANE ENABLE"
Reboot
Control Plane settings from dialing *#1575#:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Again - I can't promise that performance will improve any if at all by using Control Plane and I do not recommend this for all users. However, it could potentially be useful in locations for which supl.google.com doesn't have accurate or up-to-date info, so still it might be worth trying for some users. But if you're already getting reasonably good GPS performance I recommend it be left alone. And indeed, there might be some good reasons *#1575# has Control Plane disabled by default - it may not even work.

General GPS Tips
General Overview of Unaided/Standalone GPS:
http://gpsd.berlios.de/gps-hacking.html
Pay particular attention to the "Locking and Loading" section as it helps give an idea of what GPS is doing on startup in the various scenarios.
General Overview of GPS in Samsung Galaxy S series phones:
I had been considering writing a discussion of sorts of the general issues involved, but frankly I think this really excellent post would be tough to improve upon:
http://forum.xda-developers.com/showthread.php?t=842694
Be sure to give the author a well-deserved thanks.
General GPS Tips:
In Settings -> Location and Security make sure "Use GPS satellites" (duh) as well as "Use Wireless networks" are enabled. This is especially helpful when getting an initial fix in an area where you haven't used the GPS recently
It's best to leave WiFi on when navigating if possible. Google has mapped the location of wifi networks and can use their location to help figure out where it is even if it's not connected to WiFi
"Use Sensor Aiding" should not be turned on. This was mostly intended for pedestrian use. The sensors really aren't sensitive enough to provide useful info at vehicle speeds, and the use is problematic unless the phone is held at a fixed position relative to the direction of travel
Avoid reorienting the screen if possible when navigating. Using the GPS and Google Navigator actually involves a lot of simultaneous computation between determining the position and downloading and rendering the map data. Reorienting the screen seems to pull too much power and causes the GPS to lose fix and re-acquire a lock.
Plug in the car power adapter if you have one. More than a few people report that this helps substantially, lending more credence to the power starvation theories
Position the unit if possible where it has as much unobstructed view of the sky as possible. There's a reason in-car nav systems are mounted either on the windshield or the dash. If it's sitting on a lap or seat, between the ceiling doors and engine block the ability to get good reception to enough satellites is very limited. Even an expedient mount can make a real difference
You can try cleaning the antenna contacts on the inside of the battery cover with a pencil eraser. Just scrub a little at the white parts; don't remove the white material completely. I *do not* recommend bending up the contact as some suggest as it's extremely fragile and can break.
Acquisition times will be best under a "warm start" i.e. when the GPS already has current almanac (within a week-ish since last extended GPS use) and ephemeris (expires after 4 hours) data downloaded and when its last computed position is fairly close to its current location. In practice this means that initial acquisition times will be best when the GPS has been activated in the last few hours. A weather widget or similar that updates itself by GPS location every 4 hours or so accomplishes this neatly with a fairly small impact on battery life. Fancy Widgets seems to work just great for me.
GPS Troubleshooting Techniques:
Test the complete GPS + AGPS Augmentation:
As best I can determine, LbsTestMode will apply AGPS data if it has already been downloaded, but doesn't ever actually download AGPS supplement on its own no matter what configuration is specified.
To Test the overall functioning of the complete system:
Apply whatever fix or configuration settings to be tested
Use LbsTestMode to delete GPS data
Reboot
Use an app like Google Maps or GPS Status & Test to force download of AGPS data
Once you've followed these steps, LbsTestMode acquisition times will be much faster.
Test the GPS Only:
A great way to test the functionality of the GPS on its own is to turn on airplane mode and the use LBSTestMode or an app like GPS Test to see if you can get a fix.
If you get a fix quickly, this means that a)the GPS itself is capable of functioning, and b)the almanac data is already stored on the phone and is current
If you use LBSTestMode to delete GPS data and then try to get a fix this way, it's normal for it to take several minutes to get an initial fix, and as long as 15 minutes or so before attaining an accurate (<30m) fix. This is because the almanac data is being slowly accumulated over the satellite signal, which takes a long time
There is some indication that doing this once a week or so (almanac data usually expires after 7 days) can be helpful as it forces a complete alamanac reconstruction. It seems likely that Samsung's driver may not be updating the GPS-only almanac properly when using AGPS so doing this will help keep it "fresh."
Some users have reported that using other GPS apps (or even loading the AT&T Navigator app and letting it sit at the disclaimer screen for 15 min) improves GPS performance. This is probably why — it's forcing an almanac update.

subscribed

Let me know if you need help doing the auto configuration of the GPS settings.

It made my GPS worse, but my phone has had a hardware repair and has good GPS (was just curious).

opcow said:
It made my GPS worse, but my phone has had a hardware repair and has good GPS (was just curious).
Click to expand...
Click to collapse
Worse how? Accuracy/tracking/acquisition times?
Sent from my SAMSUNG-SGH-I897 using XDA App

I will install and test in more detail tomorrow on the way to work but based on the indoor test that I ran before and after this "fix", there is no difference.

lock times are diminished but just sitting here, test mode shows signal all over the place and maps has me jumping around erratically.

I am running a 9.1.2 rom kitchen rom. Jl2 modem with todays speed mod kernel. 1007 build captivate.
Maps is good for me. Really good.
I am going to do a my tracks run and well report back in alittle bit.
Edit: not spectacular on the my navigator. Had better.
Sent transparently through the tubes.

I've noticed little improvement (possibly even worse performance) in stationary locks; although I tested only for about 20 minutes.
Serendipity 5.8; GB steam Kernel 12-28

nyydynasty said:
I will install and test in more detail tomorrow on the way to work but based on the indoor test that I ran before and after this "fix", there is no difference.
Click to expand...
Click to collapse
Many of the adjustments I've made relate more to the tracking in motion than stationary fixes. If your configurations before were already allowing for proper AGPS download you might not notice much of a diff. at first.

Rrryan2 said:
Worse how? Accuracy/tracking/acquisition times?
Click to expand...
Click to collapse
I didn't go as far as testing it while driving. It couldn't have been better since my tracking has been virtually perfect since the repair. Acquisition was as fast as far as I could tell, but I got fewer in-views/locks and signals were up and down more. Of course it's possible with several back and forth trials it would even out, but I just played with it a bit and then flashed an undo zip I made and played with it more.
But like I said, my phone has been through Samasung repair and has really good GPS now. I was just curious if I could get better/faster locks indoors or something. If it works for people with bad GPS that's what matters.

This was the first time I've ever been able to drive home without it dropping its tracking. I only had one instance where it went off track, and it readjusted within 5 seconds. Not sure what you did but it seems to make a difference for me! So far...
Sent from my Captivate

xtremekilla09 said:
Let me know if you need help doing the auto configuration of the GPS settings.
Click to expand...
Click to collapse
Thank you, I will! I want to get some more feedback and see if the settings need more tweaking first though.
I've been toying with compiling it all as an .apk too once I'm done. Would at least make things simpler for novices.

Does it matter what ROM you are currently running (ie. 2.1 vs 2.2, etc)?
Sent from my SAMSUNG-SGH-I897 using XDA App

vn1977 said:
Does it matter what ROM you are currently running (ie. 2.1 vs 2.2, etc)?
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
It shouldn't. Some *modems* do seem to handle GPS better according to some reports, but I'm not altogether convinced that's not because ROM authors have already included their own GPS fixes adn it's being mistakenly attributed to the modem.
Note: installing a new ROM (or re-installing one) may overwrite the settings this fix makes. So if you flash a new ROM and aren't happy with the GPS, just re-flash the GPS fix.

The reason I was asking is that I'm on stock 2.1 (JF6) and was curious if this was made with Froyo in mind. Thanks!
Sent from my SAMSUNG-SGH-I897 using XDA App

Worked pretty well for me. But testing it out once is not a proper experiment. Locked in ~15 seconds and held lock. I was stationary on my balcony.

Rrryan2 said:
It shouldn't. Some *modems* do seem to handle GPS better according to some reports, but I'm not altogether convinced that's not because ROM authors have already included their own GPS fixes adn it's being mistakenly attributed to the modem.
Click to expand...
Click to collapse
The modem can change the GPS performance. I did a lot of modem testing before my phone was repaired. For me jl3 and kp1 were best.

Make mobile data priority over WiFi connection

Any way to do this? Looking at some hardware for my car, problem is that I want WiFi based system for least amount of lag while having active data as said hardware won't be a Internet access point.
Other wise I suck it up and buy Bluetooth version or get it hardwired with USB which will suck for when I'm outside the vehicle.
Any thoughts?
This is most likely the wrong place to post, but I am using a V20 (note 7 refugee)
Found a link, amongst others they no good without root.
http://forum.xda-developers.com/showthread.php?t=1640472&page=4

Medtactics said:
Any way to do this? Looking at some hardware for my car, problem is that I want WiFi based system for least amount of lag while having active data as said hardware won't be a Internet access point.
Other wise I suck it up and buy Bluetooth version or get it hardwired with USB which will suck for when I'm outside the vehicle.
Any thoughts?
This is most likely the wrong place to post, but I am using a V20 (note 7 refugee)
Found a link, amongst others they no good without root.
http://forum.xda-developers.com/showthread.php?t=1640472&page=4
Click to expand...
Click to collapse
There are some tweaks under Developer Options to change how the phone prioritized cell/WiFi traffic. Maybe one of them will help.
Sent from my iPhone using Tapatalk

Ya it's there, except for the little note "for fast network switching". Although aggressive handover might work depending on how it handles high strength vs all data packets lost. But with both on it might work with it keeping cell data enabled.

wlan_rx_wake issue again keeps device awake

It seems that the current Android version on the LG G6 has that annoying wlan_rx_wake issue again. It keeps Android OS and Android System awake for hours (awake and CPU using) and makes nearly 25 percent of battery usage.
In this case Android is just reacting to broadcasts on WiFi but the way it handles it is simply bad. I created a guest network with my device only and this fixed the issue or it circumvents it. But since it's only an issue on LG's Android 7 and no other of my devices has it, it must be a bug.
Is there a settings to ignore broadcasts more aggressively? I've no root fore some reasons.

I've been there myself and have posted what little progress I've made in the Standby drain thread. I don't think this is a problem specific to LG's Android 7 nor do I think it is LG's or Android 7's problem on their own. I thought this affected most (if not all) devices using any modern release of Android when connected to a "noisy" network, but don't quote me on that. I've had this problem on several different android devices running different distributions of Android, including the G6 running both Stock and AOSP-based 7.X ROMs. However, most of my other devices had a custom kernel that did allow me to block this wakelock. It's any easy fix that I've implemented myself in the G6's stock kernel by adding a few lines to LG's publicly released source code, which effectively got rid of wlan_rx_wake for me by changing a setting on my phone. I assume that you say you don't have root not because of personal preference but because you have an unlockable bootloader. If the latter is the case, this kernel fix wouldn't apply to you. You may be able to fix the issue on the other end though. If this happens in your own personal network you might just have to disable a problematic app in a device connected to it or change a router setting. If, however, this happens in an institutional network that you can't control and that a lot of people simultaneously access, you'll have a harder time working around it. In any case, ditching DHCP for a static IP and disabling IPv6 could help. It might also be worth analyzing your network traffic with a packet sniffer and checking what is waking your device. If it turns out be a single or a handful of devices sending packets throughout your network and you don't have access to them, you might be able to block and/or ignore them by running some custom iptables scripts on a firewall app (not sure if this feature is available without root access). I'm assuming that by creating a guest-net you isolated your phone from all of these alleged requests circulating in your main network and that's why your phone isn't woken up as often,. I'm not 100% sure we're facing the same problem nor that any of this could be of any hep at all. Be sure to let us know if you find a fix for this. Cheers!