Related
Here's that donate button you guys were looking for. >_>
https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=7ELH2CPLUZLQY
ANECDOTAL EVIDENCE IS NOT REAL EVIDENCE!!!
Get My Tracks from Google Market and post your GPS trip.
My first Froyo 2.2 test:
http://maps.google.com/maps/ms?ie=UTF8&hl=en&msa=0&msid=108472444080796738089.000491a2c10ac25693114
Jupiter.XML
Jupiter.XML is not a Samsung specific file.
Jupiter mods
I've been modifying some information from the Jupiter XML to get different results. After installing a new jupiter.XML, got to LBSTestMode and select Delete GPS Data.
They can be installed by:
Code:
adb push jupiter.xml /system/etc/jupiter.xml
or (if permission denied)
adb push jupiter.xml /sdcard/jupiter.xml
adb shell
su
busybox cp /sdcard/jupiter.xml /system/etc/jupiter.xml
rm /sdcard/jupiter.xml
I made some changes to Jupiter (hopefully) enabled low noise amplification and remove a lag while trying to regain a hot fix.
View attachment Jupiter-v001.zip
Here's a v002 without ANY AGPS data. Because of a theory that AGPS is causing inaccuracy problems, I've disabled it completely. The fix will take longer, but maybe it'll be more accurate. With AGPS off, you won't get signal indoors. Remember that please and this is for the sake of testing.
AGPS doesn't have anything to do with accuracy. Stick with v001
Removed
You should also disable AGPS within Android
You can disable AGPS this way
Code:
adb shell
su
cd /dbdata/databases/com.android.providers.settings
sqlite3 settings.db
update secure set value="0" where name = "assisted_gps_enabled";
.quit
reboot
v003 has AGPS again. Make sure you enable AGPS in android provider settings (see above). I also switched the SUPL to supl.google.com:7576 instead of spirent. I changed the FrqPlan to match the Blackberry devices FrqPlan.
View attachment Jupiter-v003.zip
v004 is based on XWJP4 from a i9000 build.
I changed a lot. I made my changes to jupiter.xml (disabled the LNA for testing) and I'm using unstable 300ppb (even though I think ppb are meaningless since ppm are more important). It has LBS data enabled from this firmware. Also, I put the new drivers and forced SUPL to supl.google.com in both jupiter and gps.conf
pulled for more testing
v005 are tweaks from XWJP4. I couldn't get the new libgps.so to work on our Captivates (crashes on boot). gps.conf goes in (/system)/etc
View attachment Jupiter-v005.zip
v006 is JI6 compatible. JI6 (the Froyo build) uses the same GPS driver structure as i9000 XWJP4, so we might be able to swap files. This also means it's compatible with i9000 devices. This is mostly playing with SUPL to point to Google and remove a possible fix lag.
/system/etc/jupiter.xml
/system/etc/gps.conf
/data/gps/secgps.conf
View attachment Jupiter-v006.zip
Jupiter Research
It's a interface configuration file for GLGPS from Broadcom. If Samsung messed up, IT'S HERE
These are Samsung's settings (with OH7 OTA)
LogPriMask="LOG_DEBUG"
LogFacMask="LOG_GLLAPI | LOG_DEVIA | LOG_NMEA | LOG_RAWDATA | LOG_DEVMS | LOG_ASIC_IO | LOG_BBTEST | LOG_DEVET | LOG_MESM | LOG_DEVKF | LOG_DEVJG | LOG_DEVMR"
FrqPlan="FRQ_PLAN_26MHZ_2PPM_26MHZ_300PPB_UNSTABLE"
RfType="GL_RF_4751_DANUBE"
BrcmRFwildBase="0x1E2D6409"
BrcmRFclkDiv="21"
BrcmRFclkRefHz="26000000"
pps-enable="false"
pps-offset-ms="0"
pps-width-ns="100"
THIS IS WHAT WE SHOULD PLAY WITH!
I'm done some research and these are values for FrqPlan:
The TCXO has to be accurate +/- 2.0 ppm.
The number after FRQ_PLAN_ describes the type of TCXO used, for example,
FRQ_PLAN_13MHZ_2PPM is a 13MHz reference clock.
FRQ_PLAN_13MHZ_2PPM
FRQ_PLAN_16_8MHZ_2PPM
FRQ_PLAN_26MHZ_2PPM
FRQ_PLAN_10MHZ_2PPM_10MHZ_50PPB
FRQ_PLAN_20000_2PPM_13MHZ_50PPB
FRQ_PLAN_27456_2PPM_26MHZ_50PPB
FRQ_PLAN_33600_2PPM_26MHZ_50PPB
FRQ_PLAN_19200_2PPM_26MHZ_100PPB
RfType values:
GL_RF_PALS7
GL_RF_BARRACUDA
GL_RF_2075_LN22
GL_RF_2075_BRCM
GL_RF_PALS7_BRCM
GL_RF_BARRACUDA_BRCM
GL_RF_BARRACUDA_EXT_LNA
I found this info here:
http://openembed.com/files/pdk15_imx35__Linux_RM.pdf
Captivate Settings from OTA OH7:
Code:
I stripped everything else because we don't need it. We're not debugging. In fact, that might be a reason for the lag (all that unnecessary debugging).
This is the HTC Legend's XML file
Code:
See a difference? NO debugging and different FRQPlan (different chip anyway)
I FOUND SOMETHING WORTHWHILE!!!
Blackberry device that uses the same chip. Here are the settings for gl1
Code:
Blah blah blah! Re-education part
I think a lot of you are playing with options, not knowing what you're doing. I've written some GPS applications for WinMo (check my post history) and have taken a look at this issue. I'm currently working on a project that uses the GPS and Android phones. I negotiated a deal with AT&T to get 50 Samsung Captivates (@ $150 each) with 2GB/mo ($25/mo) for a client and I think I'm going to cancel that.
I don't think many of you understand what's going on with the phone or what AGPS does. AGPS is basically GPS support with cell towers. There are different levels of cell tower support.
MS-Based usually just uses the cell tower's location (not yours) to figure out where you are. This will allow you to go online, and get the cell tower number and find out it's GPS location. From there, the GPS using satellite charting data to find and keep a fix. GPS almanac data (says where the satellites are in the sky) can be supplied by the cell tower (the point of MS-Based), downloaded over the internet or downloaded from GPS signals (the last of the 3 being the slowest). Getting a fix without having any satellite data or positioning is known as a cold fix.
MS-Assisted does what you guys would already figure is happening. It uses the cell tower positioning and cell tower signal central to triangulate your position. In WinMo this would disable your data connection but it seems that's not the case in Android. Regardless it might slow down your internet. Obviously the accuracy here is poor.
SUPL just tells you the lat/long position of the cell towers so changing servers does nearly nothing. Google may have faster SUPL servers than spirent but the data should be the same. Once you have that data, it should be cached locally (but who knows, this is Samsung we're talking about.)
The problem is, technically speaking, the GPS should work even without AGPS. I have a couple of GPS devices with SIRFIII and it works beautifully, no AGPS needed. It should be able to download the almanac, ephemeris and time from the GPS satellites without any cell towers. That's how you know the issue isn't your settings.
Disable AGPS and you'll realize you have no options to play with. You're all playing with AGPS settings which aren't really hardware based GPS (and thus inaccurate). AGPS is not accurate. It was never meant to replace hardware GPS (which is why they put hardware GPS in phones). Hardware GPS has much more accuracy but the fact is, hardware GPS is NOT working on the Samsung Captivate. That's the baseline problem. Forget your AGPS settings. AGPS should only help you with almanac data and getting faster fixes but after that it should be running on standalone hardware and only fall back to the inaccurate AGPS when you lose a clear view of the sky (like when you're in a tunnel).
I notice little issue when I'm standing still. It's when I'm moving that the accuracy dies. With further investigation, it seems the GPS literally stops updating the location after a couple of seconds. You don't notice if you're standing still since you're in the same spot, but when you're driving you'll see it. The GPS freezes for about 20 to 30 seconds.
The question is: Why is it not working?
Here are my hypotheses.
1) There's a function running that borks the GPS and makes the GPS driver crash or lag. The GPS driver quietly reboots and then it gets a fix. This could be the reason why, after disabling and enabling GPS, it grabs a hot-started fix of a location it was struggling to get before. You manually reset the GPS driver. I've tested it with Google Maps/Navigation. The GPS doesn't move for 30 seconds. It freezes, but when I close (disable GPS) and open the app (enable GPS) it gets a hot started fix in 5 seconds. Had I not disabled and enabled the GPS, it would have lagged there. This could be a software issue.
2) The GPS isn't using the almanac data. The almanac data says where the GPS satellites are now and where they will be. The GPS uses this to track. If this isn't used, it needs to get a fix again every so often.
3) Cell towers are actually messing you up because their times are desynchronized or almanac data is outdated. (and we all would love to blame AT&T)
As for my project, I'm ready to change my order from 50 Captivates to 50 Xperia X10 phone. The X10 actually has a WORKING GPS (meaning my app works fine and isn't the cause). I have both phones that AT&T gave me to develop my application. I wis
Thank you for the info. I am eagerly awaiting a true fix
makes sense, let us know of your future findings
I just want to say this is an excellent post and very informative. Thanks for writing it. Unfortunately, I'm seriously debating returning my Captivate over this whole fiasco. The OTA hotfix that's pushing out today does nothing to fix this issue and I some how doubt this will be resolved any time soon.
There are two test ROMS that were leaked, JH2 and JH3, that already have GPS logging enabled by default. We've been turning it off since the data isn't useful to us and it fills up the phone's storage quickly. Would those logs be useful to you?
I have a Captivate, so I don't need the logs really. What are your experiences with Dynamic Accuracy off? I feel like that could be the issue. I know the GPS disables after 120 seconds with Dynamic Accuracy off, but when it does work, how well does it work for you guys?
Also, is the GPS issue for ALL Galaxy S devices? (Vibrant/Captivate/i9000)
I just got my captivate so i havent been around long, but i know for sure it affects all the US versions of the Galaxy S series (Fascinate, epic 4g, captivate, vibrant), im not sure about the European i9000
It affects all Galaxy S phones regardless where you bought them. And the issue is with BroadCom (the GPS chip maker). There is a faulty driver and/or faulty chip firmware. From what I gather, BroadCOM gave Samsung the updated driver at the end of the August which our latest JH7 probably doesn't have.
faspalma said:
I just want to say this is an excellent post and very informative. Thanks for writing it. Unfortunately, I'm seriously debating returning my Captivate over this whole fiasco. The OTA hotfix that's pushing out today does nothing to fix this issue and I some how doubt this will be resolved any time soon.
Click to expand...
Click to collapse
According to Engadget, the latest update being pushed by AT&T "fixes" the gps issues: http://www.engadget.com/2010/09/22/samsung-captivate-gets-gps-fix-other-galaxy-s-versions-wait-pat/
compuguy1088 said:
According to Engadget, the latest update being pushed by AT&T "fixes" the gps issues: http://www.engadget.com/2010/09/22/samsung-captivate-gets-gps-fix-other-galaxy-s-versions-wait-pat/
Click to expand...
Click to collapse
Engadget is full of it.
foxbat121 said:
Engadget is full of it.
Click to expand...
Click to collapse
I think it is more that samsung "is full of it", because they are stating the gps is fixed. Engadget is just relaying what Samsung is saying....
Wasn't the source released for the captivate kernel? I would love to see the GPS source code
Sent from my SAMSUNG-SGH-I897 using XDA App
CLShortFuse said:
Wasn't the source released for the captivate kernel? I would love to see the GPS source code
Sent from my SAMSUNG-SGH-I897 using XDA App
Click to expand...
Click to collapse
GPS and most all of the drivers are not part of the source release.
Can we recompile the driver, does anybody know?
This is the source code for Nokia's driver for the same chip.
http://www.mail-archive.com/[email protected]/msg03733.html
But I don't think they use NMEA
Ok I hear what you are saying, I never messed with the settings and claimed that it was fixed. I am under the impression that my gps is working and always was but with the new jh7 firmware (ota version) it definitely works better, I had the samsung-firmwares.com release and it made no difference but designgears rooted decided version of thee ota release made a difference. What settings need to be changed to disable all network assisted location to test if I'm actually getting a gps fix without agps?
Sent from my SAMSUNG-SGH-I897 using Tapatalk
Dani897 said:
Ok I hear what you are saying, I never messed with the settings and claimed that it was fixed. I am under the impression that my gps is working and always was but with the new jh7 firmware (ota version) it definitely works better, I had the samsung-firmwares.com release and it made no difference but designgears rooted decided version of thee ota release made a difference. What settings need to be changed to disable all network assisted location to test if I'm actually getting a gps fix without agps?
Sent from my SAMSUNG-SGH-I897 using Tapatalk
Click to expand...
Click to collapse
Network assist is not a problem. There is no need to disable it.
Just take a test drive using Google Navigation. Ignore the fact that it always seems to be dead on your position (because all navigation software snap you to the nearst road). Instead, pay close attention to:
1. Whether or not you see a blue circle surrounding your position. If you do see that, your GPS has failed at that time and the size of the circle is the estimated inaccuracy of the GPS. You need to be patient because blue circle comes and goes randomly.
2. Pay attetion to certain landmarks like bridges, overpasses and intersections. And compare that to your position on the map to see if you experience lags.
3. The navigation software snaps you to the wrong road nearby even though you didn't see the blue circle.
In my personally experience, all three showed up randomly. I have no problem getting a quick lock at all.
foxbat121 said:
Network assist is not a problem. There is no need to disable it.
Just take a test drive using Google Navigation. Ignore the fact that it always seems to be dead on your position (because all navigation software snap you to the nearst road). Instead, pay close attention to:
1. Whether or not you see a blue circle surrounding your position. If you do see that, your GPS has failed at that time and the size of the circle is the estimated inaccuracy of the GPS. You need to be patient because blue circle comes and goes randomly.
2. Pay attetion to certain landmarks like bridges, overpasses and intersections. And compare that to your position on the map to see if you experience lags.
3. The navigation software snaps you to the wrong road nearby even though you didn't see the blue circle.
In my personally experience, all three showed up randomly. I have no problem getting a quick lock at all.
Click to expand...
Click to collapse
This has been my experience too...and while Cog 2.1 has made it better, I still experience these same problems.
I changed the first post and hope to make this a community effort.
The problem seems to be position estimation. When you take a sharp turn, the GPS position will keep going "expecting" you to follow the same path. After a few seconds, the GPS position will slowly return back to your real position.
If we could just remove position estimation / interpolation, we might see improvement.
You can see what I am talking about in my post here:
http://forum.xda-developers.com/showpost.php?p=8295858&postcount=2
Thank you ShortFuse.
This is the most truly helpful GPS thread in a while. I hope we can get to the bottom of this soon.
Everyone needs to contribute to this thread!
UPDATE JAN 11:
XDA member Da_G has done some excellent work on GPS performance. To summarise the situation as of Jan 11:
1. There is clearly an antenna issue for some users as highlighted by Samsungs Oct 10 redesign and the reports of good results from some users modifying the GPS antenna connection
2. The GPS implementation is indeed buggy out of the box. In particular my guess at some form of interpolation (see below) appears to be accurate. However I commend this post http://forum.xda-developers.com/showthread.php?t=881941 in the Captivate forums to you. Da_G has done excellent work and has made the gps daemon binary from the Nexus S available to SGS users in addition to modified jupiter.xml and gpssec.conf files which disable interpolation as well as refining several other parameters. He deserves thanks for his work and I can report that with hardcore's Speedmod kernel and the gpssec.conf, jupiter.xml and glgps_samsungJupiter from Da_G's downloads I have GPS performance I am completely happy with on my i9000. Root and some basic shell knowledge required for his fix.
The original post begins below.
Regards
dangrayorg
I’ve tried very hard to write a definitive post on SGS GPS performance. Below I try to give a balanced view of GPS performance in the SGS and provide definitive explanations of the various functions offered by the Broadcom BCM4751 chipset and their effects on the quality of the GPS fix. There is a lot of noise and conjecture on this subject in the XDA-developers forum; some right, some wrong, some missing the point entirely. Below is some educated guess work and some hard facts about exactly what will and will not help with GPS performance on the Samsung Galaxy S i9000.
I have tried to remain non-technical while telling you ‘why’ things happen they way they do. At the very least I hope you come away from reading this post with a good understanding of the various settings available to you and which will actually affect the accuracy of your position fix. There are several excellent technical articles on GPS in the references below.
Mobile Device Design:
I’d like to start by making three points:
1. Obviously The Samsung Galaxy S is not a single-purpose GPS device. There will be inevitable design compromises when trying to fit all the hardware into the phone and in particular the GPS antenna will inevitably be inferior to the one in a standalone GPS or GPS Dongle. Having seen the GPS antenna it is indeed tiny, and halfway down the side, and at the back. But it needs to fit with the constraints of the hardware and has what appears to be a very sensitive chipset attached to it. I cannot find a full technical spec for the chipset but include a link to a technical overview in the footnotes. The GPS antennna on the i9000 is at the back of the main body, 1/4 of the way down the body on the left-hand-side as you view the phone in portrait mode. Image Here
2. If my conjecture is correct then I believe that Samsung/Google have made some design compromises in their software setup of the GPS on the Galaxy S that compromise positional accuracy, these can be overcome.
3. I do not believe that the GPS on any Samsung Galaxy S is fundamentally broken in any models. I do believe that the factory configuration choices are poor and I do believe it is hampered by hardware designs and their interactions with everyday use environments. Obviously any phone may have a one-off manufacturing defect but I cannot account for those.
Available Navigation Modes:
Verizon has this to say about the MS- modes, two of the three fundamental ways (MS-Based, MS-Assisted and Standalone) that you can gain location information:
What is MS-Assisted mode of operation?
In MS-Assisted mode, the network elements calculate the location of the device. This mode is suitable for one-shot fixes, wherein the location does not need to be updated frequently.
What is MS-Based mode of operation?
In MS-Based mode, the network provides the satellite information to the device, based on a rough estimate of where the device is located, and the device acquires the GPS signals from the satellites and calculates its location. After the initial fix, the device operates like an autonomous GPS receiver, until the satellite information must be refreshed, at which time the device goes back to the network to update the satellite information. MS-Based mode is appropriate for applications that require the device location to be updated rapidly, such as a navigation application.
Click to expand...
Click to collapse
The current advice seems to be to enable MS-Assisted as it appears to improve navigation performance. I believe that this is incorrect. When using MS Assisted positioning I see considerable wander occurring as the position is not GPS derived. The MS-Based settings send the GPS Almanac and ephemeris date to the device and save on initial lock times, particularly if the GPS has been unused for many weeks, however in terms of positioning once up-and-running MS-Based and Standalone should deliver identical results.
Environmental factors limiting GPS performance:
Many users are primarily using the GPS in their cars. Here the hardware design compromises come in, but there are also some properties of GPS signals which users should be aware of. Firstly, RF Interference (RFI) is unlikely to be a primary culprit. The problem with a Car is that it’s made of metal which rapidly attenuates the already very low power GPS signal. When dealing with GPS the Signal-to-noise (SNR) ratio is important. Satellites giving the best SNR are always overhead, rather the near the horizon where the signal is competing with any number of other nearby frequencies causing RFI/ general background noise. So in a car, particularly given the design compromises with the GPS antenna, you will be attenuating the overhead signal because of the roof and relying more then you should on the GPS satellites near the horizon with their lower SNR, multipath propagation etc. When driving in a town where there is no horizon you can see where the problems arise. When the SNR becomes too great the GPS can no longer compute the pseudo range from the signal and you loose the ability to use a satellite. You can see a maximum of 12 GPS satellites at any one time if you have a full sky view - if you take away the overhead ones you can see why the number of useful signals drops below the minimum (4) very quickly.
This is a problem not just for Samsung but also for Google, who tout the Google Maps nav as a killer feature in a whole group of phones which have designs compromised by requirements to squeeze a lot of functionality into a small form factor. Samsung may have done a worse job of GPS antenna positioning in the SGS then maybe HTC in the Desire but they were faced with a different set of design constraints.
Before I tell you how to fix the GPS settings for best performance, here are some hints for in-car reception:
1. Place the phone as far forward in the windscreen as you can. Note that Satnav systems usually come with a short-arm windscreen mount for this very reason as it ensures a great view of the overhead sky, yet we insist on comparable performance from our design-compromised phones when we attach them to the air vents or mount them in cup holders.
2. If you really want flawless in-car nav invest in a cheap bluetooth dongle. You will benefit from more flexible positioning options giving a better sky view, a larger antenna giving a better signal gain (and more directionality if it is pointing up) and if you get a SirfIII unit an extremely capable GPS chipset utilised without design constraints . Note that SirfIII does not always include WAAS while the Galaxy BCM4751 does, however for the requirements of in car navigation WAAS is really overkill and the quality of the signal/number of satellites in view is the real issue. It is no surprise that users find a bluetooth GPS unit gives better accuracy then the built in GPS – the antenna is massive and has a completely clear view of the sky!
Phone Settings:
Right, back the the phone.
One recommendation that I keep seeing is to activate "MS Assisted". This is what is responsible for all the drift. Standalone and MS-Based will give a pure GPS signal. MS Assisted tracks based on cell tower signals and gives worse results.
One issue that comes up in particular is the problem of 'position offset', where users see themselves consistently offset from a road by a few meters, often Google navigation will then erroneously re-route you, particularly in built up areas with high street density. There is one thing which I can say with absolute certainty... There is no GPS error I can think of which would generate a consistent offset. The only cause of this would be if you physically positioned your antenna meters away from your phone and this is clearly not the case. The inaccuracies in GPS position (and there are some, caused by timing errors and a low number of satellites available for positioning) are RANDOM. The only phenomena that I can think of that WOULD generate a consistent offset would be doppler-shift, and the mode this would be most likely to influence would be cell-tower based positioning. If you are experiencing consistent offset along straight tracks please double check that you are not using MS-Assisted mode.
About my SGS:
FROYO JPO
Hardcore's 'Speedmod' Kernel
ext4 lagfix
Battery dated: 2010.08.30
So not a ‘post October’ phone (but I think that’s a false lead anyway). The installation of a custom ROM made no significant difference to GPS performance for me. In addition I can assure all readers that I have previously experienced absolutely abysmal navigational accuracy both in-car, walking and running giving tracks so bad that I looked like the worlds only blind, drunk, crack-addicted runner. (as an aside I thoroughly recommend the installation of a custom Kernel and lagfix as it transforms the performance of the Galaxy S).
I have written my own custom GPX logging program to test all this and so have a high level of confidence. I will amend this post with some proof tracks when able.
LbsTestMode:
Here is a complete run-down of the GPS settings (explanations of the functionality they govern and the effects they will or will not have on the GPS signal) that take away the issues described above as set in LbsTestMode and result in the best observed GPS performance:
LbsTestMode can be enabled with the following key combinations in the dialler:
Android 2.1 - *#*#1472365#*#*
Android 2.2 - *#*#3214789650#*#*
Application Settings:
1. Session Type: Tracking
A chipset feature which helps to boost SNR in poor RF environments)
2. Test Mode: S/W Test
3. Operation Mode: Standalone
The most important setting as this is the setting. Standalone or MS-Based. Not MS Assisted. I have had the best results with Standalone, cutting the whole Assisted-GPS segment out of the equation. That way I don't have to worry about who's databases are up to date, which base stations might inaccurate etc. The standalone mode is able to do everything you need at the cost of slightly increased start times if not used for some time.
4: Start Mode: Hot Start
This has nothing to do with re-downloading almanacs. It simply resets precise satellite timing data that must be extracted from the GPS signal to compute an accurate pseudo range. It’s good for about 4-6 hours. If you leave your GPS off for longer then the ‘ephemeris’ data will be re-downloaded anyway regardless of the Hot/Cold start settings. The GPS can’t be ‘more or less accurate’ with or without it, its simply a case that the ephemeris must be updated before you can get any position. You can sync the clock every time if you want, personally I’d choose ‘Hot Start’ and save a few minutes every time a GPS app is destroyed!
5: GPS Plus: On
The GPS Plus is the Wide Area Augmentation Service, extra satellites that transmit a deviation correction to correct minor positional inaccuracies within the space segment of GPSl. Not available globally (North America and Japan, maybe Europe and India by the time the phone is obsolete). Having it on will not cause problems if WAAS is unavailable in your region.
6: Dynamic Accuracy: On
This setting is used to filter data that is judged statistically to be in error based on deviation from the Circular Error Probability (CEP) calculated by the GPS system.
7: Accuracy: 30m
I believe that this is a cut-off for the overall GPS positional accuracy. If over this threshold the GPS will not report the position. I have yet to see a figure of more then 20 meters, so leave at 30. GPS precision is far more complicated then a simple inaccuracy based on distance)
8: GPS Logging: Off
SUPL/CP Settings:
This is a network layer operated by cellular operators. It delivers the AGPS data like timing corrections and the almanac to your phone as well as allowing a network operator to provide you with various location based services (and make more money from you). If you wanted to download the almanac from satellites it would take a minimum of 12.5 minutes and would need to be done every time you turned your GPS on if it had been off for weeks/months. The almanac has a long lifespan, so won’t age out in days, and the GPS receiver is still capable of downloading it from satellites if it can’t get it from the network, It also provides information to your mobile provider about where you are, regardless of your Google privacy settings so that they can provide you with location based services (so Google isn’t the only geolocation bogeyman!)
Again, I think there are lots of false leads here. The one thing that may be true is that the original SUPL provider on
handsets was providing inaccurate data. Recommended settings:
Server FQDN Type: Custom Config
Server: supl.google.com
Server Port: 7276
SUPL Secure Socket: OFF
AGPS Mode: SUPL
Use wireless networks option
Google do map WiFi hotspots in large cities, which is enabled by the "Use Wireless Networks" option in the android Menu. This may allow you to locate yourself accurately in an urban area where GPS is unusable. However, it is unlikely to provide tracking information for runners, probably providing street-corner location to pedestrians.
Use sensor aiding option
Google's own documentation states that this is for use in areas where GPS performance is degraded. I am unsure if the selection of "use sensor aiding" will have an effect if a good GPS signal is available. For those trying to troubleshoot their GPS setup I would advise that the low cost MEM sensors contained in mobile phones (solid state gyroscopes), while good for games are poor over more then a few meters in terms of accurately measuring velocities to determine distance travelled.
It is possible to use solid-state accelerometers when coupled with a GPS to refine positions and attitude information but it is unlikely that android employs the filters needed to do this well. If you navigate frequently in cities or environments with tunnels etc. you may wish to enable this feature but for most navigational needs I would advise leaving it off as the integration of sensor data with GPS positions may well be a source for positional bias and drift seen in the Galaxy S.
And that’s all you need.
I hope that that will be definitive. Using the above settings I get entirely accurate tracks from my phone using my GPS logging program. I may post that soon with my example logs. The reason I wrote from scratch was because I wanted to be sure that I was getting the pure output from Android dumpLocation with no adulteration to allow for a fair analysis.
HOWEVER (and here is where what I know comes to a end…):
When your app selects a location provider it won’t necessarily be ‘GPS’. A developer can select getBestProvider() and use something other then gps to save power. I assume that most developers use ‘gps’ but it would take a knowledgeable android programmer to tell us if we can guarantee to always get unadulterated GPS positions into the application layer with no mixing sneaking in!
References:
http://www.broadcom.com/press/release.php?id=s443754
http://www.broadcom.com/collateral/wp/SUPL-WP100-R.pdf
http://www.broadcom.com/products/GPS/Location-Based-Services/SUPL-SLP
http://www.topcon-positioning.eu/img/pdf/pdf_GPS/HIPer+_English_web.pdf
http://webone.novatel.ca/assets/Documents/Manuals/GPS+Reference.pdf
http://www.telemobilityforum.com/it/images/stories//madwar_telemobility.pdf
These are the settings I found as default ... I never had a problem with gps. Accuracy between 5 and 10 meters indoors. That's really nice in my opinion. But thank you for your time you spend to this “issue“ and I hope it helps other people.
Sent from my GT-I9000 using XDA App
I can tell you that I have those exact settings and my GPS signal is still **** when going into the city with tall buildings and such. In suburbs it's fine, tall city is bad. Had a touch HD previously and it worked FINE in the city.
SGS just got **** gps IMO
How can I enter to the gps settings?
When I enter the code *#*#1472365#*#* the number disappears and nothing happens!
2.2 JPO DocRom v7
I've been running settings similar to these recently and getting 'better' performance than my stock settings, so I'm inclined to agree with the OP here.
It's no where near what I'd call good performance though, my old HTC HD & Nokia 95 running TomTom had no issues keeping track on the road (mounted on the same windscreen position), whereas still GoogMaps Navigation will occationally position me on nearby roads by mistake. I think it's just going to be one of those things I'll have to live with.
That said, at least now I'm occasionally getting proper lock on the little navigation triangle when driving, not a 100m circle around it. So things are improving.
Which side is the GPS antenna on?
If the antenna is small, on one side, and at the back, then running the phone in landscape with the aerial side facing up is bound to have the best chance of "seeing" the sky. Without knowing which side is "up" for the aerial, we have a 50/50 chance of getting it right or wrong.
So do you know which side it is on, and therefore whether we are better having landscape with the buttons to the right, or landscape with the buttons to the left?
Also does firmware version make a difference (other than the default config of these settings)? Or in other words, would all firmware versions have similar performance if set to these recommended settings, or do some firmware versions have better drivers or sensitivity too as well as different settings?
Thanks for the excellent info!
Mike
dangrayorg said:
1. Obviously The Samsung Galaxy S is not a single-purpose GPS device. There will be inevitable design compromises when trying to fit all the hardware into the phone and in particular the GPS antenna will inevitably be inferior to the one in a standalone GPS or GPS Dongle. Having seen the GPS antenna it is indeed tiny, and halfway down the side, and at the back. But it needs to fit with the constraints of the hardware and has what appears to be a very sensitive chipset attached to it. I cannot find a full technical spec for the chipset but include a link to a technical overview in the footnotes.
Click to expand...
Click to collapse
I appreciate the effort here but this is a tad bogus. I have a 3+ year old dedicated GPS device, it's an extra-sensitive Garmin handheld and my puny little 3 year old HTC Touch rivals it's performance track for track. They both blow away the Galaxy S with their 3 year old technology. ...so no it is not expected to be inferior, maybe to the latest and greatest dedicated gps, however I can assure you their is no exscuse not to rival 3 year old technology.
sorry for yet more gps ranting.
Neil
NeoXTC said:
I can tell you that I have those exact settings and my GPS signal is still **** when going into the city with tall buildings and such. In suburbs it's fine, tall city is bad. Had a touch HD previously and it worked FINE in the city.
SGS just got **** gps IMO
Click to expand...
Click to collapse
Well you are talking about the urban canyon effect. There are very few high end GPSes that can deal with that. So you can not judge the GPS in urban canyon environments because then nearly all GPSes has problems.
I thank the OP for a well written "guide". I think that it will enlighten lots of people how a GPS really works and we hopefully can skip the strangest advices on the forum. I still think you could optimize the code better because it seems to slow and imprecise in some aspects. However I have used it daily and are satisfied with it even if I wished for the military grade GPS that many seems to have in there old phones and GPS's.
You are wrong on the "Use Wireless Networks" setting not using WiFi. It *does* also use your WiFi to help triangulate. It says so right in the android UI for pete's sake. It really only works in large cities where Google has mapped APs and APs are dense.
The way the triangulation works is Google has mapped all the ESSIDs in a city and for all the road GPS positions recorded their strengths. Therefore in a city whenever you see 2 or more ESSIDs you can use that info along with your cell tower triangulation to compute a pretty OK estimate of your GPS coordinates - at the very least a much more accurate picture than you can get by the cell towers alone, because the range of a WiFi network is so much smaller.
Basically - if you are in a city and you have this checked and your wifi is enabled you may get more acccurate readings without GPS than you would otherwise.
Great post, I changed the spirent-lcs to supl.google.com and a few other niceties. This is totally unscientific, but before changing (using gps test) I could only see 1 satellite and stayed like that forever. After applying the changes, I had a 30 m fix in about 3-5min. Have to say that my SGS has always been totally unpredictable, some days, it couldn't get a fix in under an hour, others it took 10min, all that while walking outside. I hope these setting will allow me to use the GPS a bit more reliably now. thanx!
Thank you for your guide, however the fact is that other phones that I had or currently have have perfectly functioning GPS. It is only the Galaxy that has problems.
Second "use wireless networks" does use Wi-Fi networks for positioning - an easy way to see that is to turn on "Flight Mode" and then turn on Wi-Fi only, Google Maps will still be able to find your position.
Superb post Dan, one of the best I've read on here in a long time.
Cheers,
BS...
Thanks for all the comments, positive and negative.
I'm not arguing by by any stretch that the Galaxy S GPS is fine (if it were there would be no need for the original post). I am as ****** as the rest about its troublesome performance, that said there is more that can be done then just 'playing with settings'
If Google has mapped WiFi hotspots then I will correct the post. However, using a WiFi signal strength together with a triangulated hotspot location is a HORRIBLE way to locate yourself in a city - what if someone moves the router? Stands in front of the aerial? Moves shop fittings around? That said I guess it could locate you "You are near a starbucks",
However, I will alter the post because I want it to factually accurate. If anyone really does have better results in a city using the wireless locations please let everyone know.
I'll also add the codes to allow access to LbtTestMode in 2.1 and 2.2
neil85ae86 said:
I appreciate the effort here but this is a tad bogus. I have a 3+ year old dedicated GPS device, it's an extra-sensitive Garmin handheld and my puny little 3 year old HTC Touch rivals it's performance track for track. They both blow away the Galaxy S with their 3 year old technology. ...so no it is not expected to be inferior, maybe to the latest and greatest dedicated gps, however I can assure you their is no exscuse not to rival 3 year old technology.
sorry for yet more gps ranting.
Neil
Click to expand...
Click to collapse
You don't say if you've tried any/all of these settings or not. We need to all work together to find the solution. I think the OP might be on to something here, although as he says, some of it is guess work, so there is probably room for improvement!
I would disagree with the OP about the hardware faults, as I'm sure there are bound to be at least some units that have a fault that needs returning to be fixed too. But everyone should at least try these settings to see if it helps at all, as there are bound to be multiple factors at work here.
Also which way up do you have your phone when in the car? That is something very tangible we can sort out to optimise the signal reception in these phones. I currently don't know which side has the GPS antenna, so which way up we should out our phone for optimal signal strength. Once we've found that, we might well find that many have their phones with the antenna pointing down which won't be helping either!
Apologies if you've tried these settings too, and they didn't work, but we need to ask, so that we build a fuller picture! Just disagreeing with the OP without saying what you've tried doesn't help anyone move this forwards.
We all want the GPS fixed, and I for one will try anything in that quest.
Here's hoping the next discovery by Samsung or the community fixes it for good for everyone!
Mike
xpcomputers said:
I currently don't know which side has the GPS antenna, so which way up we should out our phone for optimal signal strength.
Click to expand...
Click to collapse
OP now contains info on GPS antenna position. Answer is straight upright on rotates clockwise (antenna on Left Hand Side 1/3 of way down).
xpcomputers said:
I think the OP might be on to something here, although as he says, some of it is guess work, so there is probably room for improvement!
Click to expand...
Click to collapse
I am on to something - unfortunately that 'thing' is that I think the settings given deliver the best performance the SGS is capable of because its teeny tiny antenna. It simply doesn't have the gain for those awesome feats of satellite lock that we see from other GPS units (either that or the internal wiring generates some huge losses along the signal path to the chip).
This also plays out the earlier comments about "three year old technology". Chipsets move on and Broadcom have clearly had to pour a load of research into optimizing signal strength for mobile devices. Unfortunately the laws of physics don't change. If there is not sufficient signal at an antenna with insufficient gain you will only keep a lock on the strongest satellites.
Once I get the tracks on the OP you'll see what I mean. Where I am with a good clear sky view there is no problem at all, excellent correlation with ground trace and no complaints with the SGS strapped onto my arm while running. Once you increase signal attenuation by adding trees and buildings things start to 'go south' rapidly.
Is this the price for that huge bright screen....?
t1mman said:
Any way to force disable the AGps overall?
Click to expand...
Click to collapse
Isn't that what the OP does with the "Standalone" setting (instead of one of the MS A-GPS options)?
Mike
Op: thanks for the info. To bad all settings accept for accuracy is default on froyo.
I also working on this issue.
Wifi is a bad thing to use.
This is often the main thing people do have on and they get very poor accuracy and blame the gps for it.
When i flash the phone i always put the accuracy to 150.
This is a strange setting and normal i would like it to be less the 5.
So i should use 5 on accuracy, but that don't work good. I have found that putting accuracy over 150 will make the phone use the satellites better. Strange...
I also use standalone made. That's works great for me.
A also think all people should try different settings and se if some works better for them.
There is other things you can tweak to help the navigation.
Also don't use Google map. Use a standalone navigation program.
They works alot better.
Sent from GT-I9000 jpo. My own kernel for z4mod and with 342MB Ram
t1mman said:
I know AGps is only used for the first fix, and shouldn't affect the accuracy once fixed, but what if (this is speculation, it should need further investigation) the GPS status accuracy issue was more likely caused by a lost and retreival of a fix? In this case, the fact that the fix was lost/regain would mean that the aGPS would affect the accuracy as it is constatly regained.
Any way to force disable the AGps overall?
Click to expand...
Click to collapse
AGPS provides you with timing corrections and satellite position data to allow the GPS reciever to 'sync' with the signal transmitted by the satellites. The satellites still provide the location, the AGPS data helps it get there quicker.
MS Based would save 15 minutes month-to-month downloading almanac data, a minute or two day-to-day updating timing data but 'hotstart' will work just fine if you are turning on and off many times in a day.
dangrayorg said:
OP now contains info on GPS antenna position. Answer is straight upright on rotates clockwise (antenna on Left Hand Side 1/3 of way down).
Click to expand...
Click to collapse
So I am hearing you correct? That theoretically the GPS will work best with the phone in landscape, with the home button (and the bottom of the phone) on the left hand side.
If that is the case, then at a guess, I suspect that most right hand users are instinctively using the phone with the buttons on the right hand side, and therefore the GPS antenna at the bottom, which might not be optimal positioning. (this purely is based on an observation of only my own usage of using it the other way up as a right hander, so hardly a large observed sample! I could just be weird!!)
Now of course this is totally hypothetical anyway, and needs to be something that gets tested in the real world, but this alone could account for some of the difference noted by users in the real world, but before we jump to conclusions, we need to test if the theory bears out in the real world.
I am assuming that the phone will work best that left edge facing upwards, as close to the windscreen (and as close to the bonnet as possible). Ideally the phone will be vertical in that landscape orientation, (or even slightly tilted down at the front, so the back is pointing upwards ever so slightly?). But this is pure guess work. unfortunately, I haven't the time, skills or equipment to able to test this theory out. But hopefully someone here can run some meaningful real world tests to see if this position really does give the optimal signal to the antenna compared with other orientations of the phone.
Every little helps...
Mike
Hello,
I was wondering if anyone was familiar with the control plane option in SUPL settings.
The reason I ask is that I was playing around in the secret code area of SG Tools and noticed an area marked GPS
SGS Tools -> Secret Codes -> ServiceMode, Debug, Netz, Audio, Common -> Common -> GPS -> Display and Change CP Status.
I enabled the Control Plane and then set SUPL settings in lbstest to supl.google.com etc and change SUPL Mode to Control Plane. My gps has been crazy awesome since then. Also change application settings Accuracy to 25.. I do have the jupiter file gps fix installed but GPS would still loose me until I made these changes. I was hoping someone could explain Control Plane and or someone would test these settings for themselves and let me know how it works. I am running Axura Beta 5 with Setiron Kernel 1.4.2
None of those settings "fix" GPS.
Thanks for the reply. Are you aware of what the control plane setting is for?
Not that I'm actually interested in this "fix", but is your "crazy awesome" GPS just giving you faster initial position locks?
Getting a position lock is one thing, but having the GPS actually be able to track your movement and be accurate is different...which many overlook when they say their GPS works. If you were to use to Captivate in the car to navigate with, would it be accurate? If you can say yes to that, you could consider your GPS working then.
norcal einstein said:
Not that I'm actually interested in this "fix", but is your "crazy awesome" GPS just giving you faster initial position locks?
Getting a position lock is one thing, but having the GPS actually be able to track your movement and be accurate is different...which many overlook when they say their GPS works. If you were to use to Captivate in the car to navigate with, would it be accurate? If you can say yes to that, you could consider your GPS working then.
Click to expand...
Click to collapse
I am getting faster locks.. more sattelites.. I also tested while driving and it stayed good the entire time.. I am going to test again on my hour drive home tonight..
Sent from me to you over wires using only 1's and 0's
Also my main interest is in finding out more information on what this setting does as well. It is my opinion that this has helped and I wanted more imformation and also to see if it helps qnyone else..
Sent from me to you over wires using only 1's and 0's
+1
I dunno why but set as control plane gives me more sats and faster locks even better tracking.
This is the first thing i do every time after flashing a new rom to my cappy.
ms base mode, google supl sever with control plane mode and secure socket off.
Sent from ATT Captivate operated by Perception build 5
drancid said:
+1
I dunno why but set as control plane gives me more sats and faster locks even better tracking.
This is the first thing i do every time after flashing a new rom to my cappy.
ms base mode, google supl sever with control plane mode and secure socket off.
Sent from ATT Captivate operated by Perception build 5
Click to expand...
Click to collapse
Have you checked to see if the control plane is enabled via sgstools?
Sent from me to you over wires using only 1's and 0's
mpencexda said:
Have you checked to see if the control plane is enabled via sgstools?
Sent from me to you over wires using only 1's and 0's
Click to expand...
Click to collapse
nope but i'll check it now..
Sent from ATT Captivate operated by Perception build 1
Control Plane is an alternative method of accessing the AGPS server from User Plane (SUPL). Control Plane goes over the cellular providers Control Plane (fancy that!) whereas SUPL goes out over the GPRS network (HSPA, 3G, etc.)
For Control Plane to work, the cellular provider has to have in place specific technology intended for use with AGPS. All older AGPS solutions prior to the deployment of SUPL use Control Plane. Basically it's "the old way"
Note that you can obtain the exact same AGPS data through a SUPL connection to the same set of servers AT&T maintains. This is the default setting for "Server FQDN Type" - AUTO Config.
Basically, setting it to AGPS Mode - Control Plane (regardless of other server settings) is the same as setting AGPS Mode - SUPL, SUPL Secure Socket - ON, Server - h-slp.mnc410.mcc310.pub.3gppnetwork.org, Server Port - 7275. AND is also the same as using "Server FQDN Type" - AUTO Config, providing your cellular provider is AT&T (MNC 410 MCC 310).
Note that the specifications for AUTO Config will read the MCC/MNC of your network provider (in my example above, AT&T) and change the mncXXX.mccYYY part to match your providers MNC/MCC. Per the 3gpp SUPL spec, when in a home network, the URL to access for SUPL services is h-slp.mncXXX.mccYYY.pub.3gppnetwork.org, which breaks down to:
h-slp - Home SUPL Location Platform
mncXXX - MNC of the current network the phone is parked on
mccYYY - MCC of the current network the phone is parked on
pub.3gppnetwork.org - A (purposefully) un-registered domain name free for use by cellular providers.
When you are roaming, the URL changes to:
v-slp.mncXXX.mccYYY.pub.3gppnetwork.org
where v-slp instead means Visiting SUPL Location Platform.
So, to sum that up, if your cellular provider is following 3gpp SUPL recommendations properly, when you attempt a SUPL connection to h-slp.mncXXX.mccYYY.pub.3gppnetwork.org, your cellular provider should connect you to THEIR provided SUPL server. In the case of AT&T this is fully functional. Note that this will NOT work on Wi-Fi, the DNS will not resolve (since you aren't connected to a cellular network, the ISP you're on will not maintain a SUPL server for you, unless they are just THAT nice)
Note that if you use a program like MarketAccess to change your MNC/MCC to allow access to other markets, the SUPL address will also change (to reflect the altered MNC/MCC) and thus be broken in automatic mode.
Anywho, all of this only affects the initial lock time, when set to MS-Based. (Defaults on the stock ROM to standalone, which doesn't use AGPS at all, and sane people will use MS-Based)
Tracking once you have a lock should NOT be affected by any of these changes.
In case you're wondering where I got my information, it's not my first go-round to this particular party. I did all the legwork for this a bit over a year ago, and put up a compendium post about it in March 2009: http://forum.xda-developers.com/showthread.php?t=489887 All the info I reference from the SUPL specifications is obtained by spending hours reading the actual, incredibly boring whitepapers.
I haven't had time to properly devote to the GPS problem for captivate like I have for previous WM devices (I just got the cappy), but i'm guessing there's some errors in either the satellite correlation done in the baseband, or in the driver's interpretation of the output in the kernel code. It might also be the case that the phone is relying on a clock generator that isn't putting out the exact cycles they have it programmed for, thus introducing clock drift into the correlation algorithm. The clock has to be precise and synced up to the GPS clocks in order to properly trilaterate location. This might explain the drift over time and then snapping back to a real location once the clocks are properly synced again. (GPS satellites send the complete information required to sync a clock accurately every 12.5 minutes.)
Do note that the clock i'm referring to is the internal GPS reference clock, which is not related in any way to the time set on the device. Internally, the device does keep track of the offset between GPS time and Device Time, but Device Time is not used in the GPS calculations (a different internal clock is used, and synced to the satellites themselves with each transmission) - Previously it has been suggested that ensuring the phones clock is as accurate as possible would make a difference, but that is not the case (due to it not being the same clock)
Either way, any changes to gps.conf or secgps.conf aren't gonna cut the mustard with this particular issue. Initial fix time and number of initial sats, sure. But once the GPS is fired up and running, and has time to pick up a constellation update from the satellites, you're in the same boat as anyone else.
BTW. You can read the adb logcat output to easily see if your phone is utilizing AGPS. You will get an initial fix with an accuracy of appx. 1500m and the log will show that it is not a GPS fix but instead a network provided location. It will then show this location being injected into the GPS driver (AGPS)
Thanks for the info.. that was amazing. I really hope that you get some time to devote to this as you seem informed
Sent from me to you over wires using only 1's and 0's
Thanks
DA G,
Thanks for the information, glad to have you in cappy land!
Da_G said:
Control Plane is an alternative method of accessing the AGPS server from User Plane (SUPL). Control Plane goes over the cellular providers Control Plane (fancy that!) whereas SUPL goes out over the GPRS network (HSPA, 3G, etc.)
For Control Plane to work, the cellular provider has to have in place specific technology intended for use with AGPS. All older AGPS solutions prior to the deployment of SUPL use Control Plane. Basically it's "the old way"
Note that you can obtain the exact same AGPS data through a SUPL connection to the same set of servers AT&T maintains. This is the default setting for "Server FQDN Type" - AUTO Config.
Basically, setting it to AGPS Mode - Control Plane (regardless of other server settings) is the same as setting AGPS Mode - SUPL, SUPL Secure Socket - ON, Server - h-slp.mnc410.mcc310.pub.3gppnetwork.org, Server Port - 7275. AND is also the same as using "Server FQDN Type" - AUTO Config, providing your cellular provider is AT&T (MNC 410 MCC 310).
Note that the specifications for AUTO Config will read the MCC/MNC of your network provider (in my example above, AT&T) and change the mncXXX.mccYYY part to match your providers MNC/MCC. Per the 3gpp SUPL spec, when in a home network, the URL to access for SUPL services is h-slp.mncXXX.mccYYY.pub.3gppnetwork.org, which breaks down to:
h-slp - Home SUPL Location Platform
mncXXX - MNC of the current network the phone is parked on
mccYYY - MCC of the current network the phone is parked on
pub.3gppnetwork.org - A (purposefully) un-registered domain name free for use by cellular providers.
When you are roaming, the URL changes to:
v-slp.mncXXX.mccYYY.pub.3gppnetwork.org
where v-slp instead means Visiting SUPL Location Platform.
So, to sum that up, if your cellular provider is following 3gpp SUPL recommendations properly, when you attempt a SUPL connection to h-slp.mncXXX.mccYYY.pub.3gppnetwork.org, your cellular provider should connect you to THEIR provided SUPL server. In the case of AT&T this is fully functional. Note that this will NOT work on Wi-Fi, the DNS will not resolve (since you aren't connected to a cellular network, the ISP you're on will not maintain a SUPL server for you, unless they are just THAT nice)
Note that if you use a program like MarketAccess to change your MNC/MCC to allow access to other markets, the SUPL address will also change (to reflect the altered MNC/MCC) and thus be broken in automatic mode.
Anywho, all of this only affects the initial lock time, when set to MS-Based. (Defaults on the stock ROM to standalone, which doesn't use AGPS at all, and sane people will use MS-Based)
Tracking once you have a lock should NOT be affected by any of these changes.
In case you're wondering where I got my information, it's not my first go-round to this particular party. I did all the legwork for this a bit over a year ago, and put up a compendium post about it in March 2009: http://forum.xda-developers.com/showthread.php?t=489887 All the info I reference from the SUPL specifications is obtained by spending hours reading the actual, incredibly boring whitepapers.
I haven't had time to properly devote to the GPS problem for captivate like I have for previous WM devices (I just got the cappy), but i'm guessing there's some errors in either the satellite correlation done in the baseband, or in the driver's interpretation of the output in the kernel code. It might also be the case that the phone is relying on a clock generator that isn't putting out the exact cycles they have it programmed for, thus introducing clock drift into the correlation algorithm. The clock has to be precise and synced up to the GPS clocks in order to properly trilaterate location. This might explain the drift over time and then snapping back to a real location once the clocks are properly synced again. (GPS satellites send the complete information required to sync a clock accurately every 12.5 minutes.)
Do note that the clock i'm referring to is the internal GPS reference clock, which is not related in any way to the time set on the device. Internally, the device does keep track of the offset between GPS time and Device Time, but Device Time is not used in the GPS calculations (a different internal clock is used, and synced to the satellites themselves with each transmission) - Previously it has been suggested that ensuring the phones clock is as accurate as possible would make a difference, but that is not the case (due to it not being the same clock)
Either way, any changes to gps.conf or secgps.conf aren't gonna cut the mustard with this particular issue. Initial fix time and number of initial sats, sure. But once the GPS is fired up and running, and has time to pick up a constellation update from the satellites, you're in the same boat as anyone else.
BTW. You can read the adb logcat output to easily see if your phone is utilizing AGPS. You will get an initial fix with an accuracy of appx. 1500m and the log will show that it is not a GPS fix but instead a network provided location. It will then show this location being injected into the GPS driver (AGPS)
Click to expand...
Click to collapse
Da_G? In my Captivate thread? This brings me back to playing with with GPS on the HTC Touch Pro...
It's crazy that was 2 years ago.
Hi, CLShortFuse, long time no see
Actually i've been lurking for a while now, just trying to learn things before I get down to the nitty gritty of modding source code (and writing some new stuff of my own!)
To be fair, I was a GPS fan before I became a PDA fan I remember doing firmware hacks to the SirfStar III chipset to enable functionality above 18,000m, faster than 515m/s, and bypassing the acceleration and motional jerk limiters Why? Because my GPS should work to its full ability, dammit!
As I understand, we don't have access to any of the baseband source. This is probably where a large amount of the GPS calculations are handled (It is so with Qualcomm, at least) and so it may not be something we can address. But a good thorough look at the kernel driver(s) should answer that question.
I wonder if the chipset is even SBAS Capable (WAAS/EGNOS, i'm quite sure it doesn't have a receiver for any land based solutions). The accuracy reminds me of GPS back in the days when Selective Availability was up (artificial GPS accuracy limitations put in place by the military) before DGPS came about.
Ironically, my hacked bluetooth GPS from 2005, a Globalsat BT338 remains the most accurate consumer level GPS I have used to date, with accuracies down to .3 meters in ideal conditions. (During normal in the field conditions like stuck in a backpack, in the back seat of a car, with perhaps a 5 degree view of the sky, and wicked multipath from skyscrapers it's accurate to around 2 meters) - basically, you can count on it to be accurate down to what lane of traffic you are in
The same chipsets are made available to smartphone manufacturers. (The current model being the SirfStar IV, and capable of even better accuracy than that older one) - I only wish more manufacturers would actually use them!
I actually currently use that BT GPS for any navigation I do. But nonetheless, we don't have such a nice platform to work with, so let's see what we can do with what we have Perhaps tomorrow i'll take a drive with 2 captivates, both loaded to stock firmware (updated to the "gps fix" build) + the samsung GPS fix on the market (which we know is worthless, but just for S&G)
I'll record raw NMEA output from both GPS units (Captivate using internal GPS, and Captivate using BT-338 GPS through bluetooth serial NMEA), and post that up along with a google earth .kml for easy comparison. The difference between the two is quite striking. I'll be using that GPS unit as my baseline for "great performance" when the hackery begins
(edit: taking a quick look at the kernel source it looks like we have a BCM4751 and i'm fairly certain all the relevant calculations are handled in the baseband. The good news is that chipset does support SBAS. I doubt it's properly handling it however, as it doesn't even perform up to the level of a GPS without SBAS. If everything IS being handled in baseband, i'm going to need to get my hands on source code to the radio to fix it, which won't be the easiest thing ever )
Getting interesting now...
Did anyone come across this yet? Is this real or a joke?
Samsung Captivate And Vibrant Finally Get GPS "Fix" Via GPSSamsungRestore App
The Galaxy S phones are, without a doubt, among the best Android phones out there, but for some time now, the handsets have been plagued by one potential showstopper – malfunctioning GPS capabilities. Worry not, though – in addition to an update that rolled out a few months ago, Samsung has developed an app called GPSSamsungRestore which is now available from the Android Market for all users of AT&T’s Captivate and T-Mobile’s Vibrant. So what does it do? It undoes any modifications to the GPS and basically reverts it to its original state. While it remains to be seen how reverting the GPS to its original, broken state fixes it, I suppose it can’t hurt to give it a shot if you’re a Captivate or Vibrant owner.
Note: The app only shows up in the Market for Captivate and Vibrant owners, so if you’re looking for it just for kicks, you won’t find it unless you’ve got one of those devices. It isn’t listed on AppBrain, either.
Click to expand...
Click to collapse
Quote from Android Police
Is there a validity with that GPSSamsungRestore fix.
and +1 on awesome person joining this awesome group!
Wow..very informative read there. Looks like we've found our Cappy GPS fixer-upper! Nice to have you aboard.
Sent from my couch on my phone.
Da_G I'm glad to see you have a captivate. Used your roms all the time on my Touch Pro. Glad to see another great dev on this phone. Looking forward to any work you do with it.
Amazing explanation, we are all aware of the AGPS -GPS relation but we like to lie to ourselves that some of these tweaks are actually working and that our devices are as good as any other. The truth is that our device is waaaay better with the latest developments than any other device on the market, and mine is simply perfect.
Honestly, I've been running Cognition 2.3b6 with the Jupiter v6 tweaks and had no problems with the GPS on a trip in the mountains, between trees and under heavy snow (300km round trip). Absolutely none! A bit slow lock but great tracking.
Now I'm using 2 different tweaks, the JM9 GPS drivers + this control plane thing on the same rom, Cog 2.3b6. Got a lock in 10-15 sec on 7 sats (tested for about 10 mins) but didnt have the chance to take it for a test drive. Hopefully will get the same results like before. If not, I'll just revert back to "stock" Cog with jupiter tweaks, that was the best.
[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.
I wonder if it is possible to use my GPS without my mobile connection. I like to use GPS in the airplane with an offline navigation.
Whenever I turn off my mobile connection of my HTC DESIRE, the GPS gets lost too . Is there a way?
What application are you using for your GPS? Most apps pull the actual maps from the internet and don't store them internally which might be the reason you can't use your GPS when your network is off. I guess if you could find an app that has the reference to the maps locally and install the maps locally (about 1GB for the US) then you shouldn't have a problem.
http://androidcommunity.com/forums/f12/offline-gps-maps-20226/
Some discussion on the thread above regarding your topic. Many people have posted about it. Not sure what's out there.
it's first bcoz it can't download the maps from the net.
But even without this, if you're using GPS Essentials or GPSTest for example -apps which only display the GPS stats- you'll notice it doesn't work either. And this is because the chips in s-phones are A-GPS chips, which need an internet connection to download precalculated data about satellites approx. positions, almanach data, etc etc. This helps the chip in getting a GPS lock faster, but makes it internet-dependant (the data is valid for 6 days, provided you don't change location by more than 50 miles or so. But usually the device tries to download fresh data each time the GPS is 'cold-started' -first start after a reboot or some prolonged inactivity period- and falls back to the old data if there's no connection. Past 6 days, the data is flagged as 'deprecated' and isn't used anymore whatever the case may be)..
At first only a handful of smartphone makers implemented those chips because they're cheaper to produce and take less space (most of the calculations for determining the user's position is done by the CPU, the A-GPS chip mostly only collects the data, filters it and forwards it), but then some american government agency (can't remember if it was the one regulating automotive transportation or some other though) made it mandatory for all devices sold in the US, to help paramedics and other rescue services in locating injured car-drivers quicker and more efficiently (the theory behind being that an A-GPS chip equipped device demands less interaction from the user to start up the GPS function and get an accurate fix on the position. An A-GPS chip is *supposed* to be able to get a lock and fix all by itself once the GPS is started, so that'd be only a movement of the thumb for the injured person to launch a distress call -provided he/she is able to grab the phone, of course...). But they were a bit shortsighted -as usual, if I may say- in that if the driver 'choses' to crash in a remote location where there's no 2G/3G/4G carrier coverage, he's pretty much screwed anyways, unless he resorts to the good old voice-comm'..
And of course since the US is one of the main phone markets in the world, the same phones are winding up all over the world by now.
thanks for all replies.
it actually worked well in FLIGHT MODE. I used to pre-cache some maps which is possible since the new google maps update.
worked like charm
yea but this is because you got a HTC phone.. They're typically embarking better A-GPS chips than the norm (Qualcomm-made, for the most part).
They're better than the SirfStarIV I have in my SGS2 for example, not by their precision (which is roughly the same and even a bit superior for the SirfStarIv) but by their lock-on times and the quality of their reception (which relies a lot on the built-in antenna which seems to be better by HTC).
With my HTC Desire "S" I was often able to get a lock-on even within a building (=with no clear overview of the sky), just by standing near a window... With the Galaxy S2 I have to extend my arm as far out the window as I can to be able to lock a puny 4-5 sats... :/