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!
[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 am posting here rather than in the development thread proper because, unfortunately, I have all of five posts, Development requires ten, and I'm more the type to lurk for months and only post useful material rather than spamming up a board BTW, this report has also been sent to a developer using the tweak.)
There's a particular "HSPDA tweak" implemented as a patch to build.prop (http://forum.xda-developers.com/showpost.php?p=17158831&postcount=10381) meant to improve radio performance on Cyanogenmod nightlies-based ROMs mentioned in the Cyanogen nightlies thread proper.
At least ILWT CM7 has implemented this patch in its variant/fork of the 186 nightlies; in that particular nightly implementing the changes as a patch seems to partially break GPS in the following manner:
a) GPS Test, GPS Status do get a fix; GPS Status is slow to get a fix but does manage.
b) Google Navigation receives fixes as usual with AGPS on and off.
c) Google Maps proper cannot obtain a fix without AGPS and seems to be relying on towers and previously stored fix information.
d) Copilot Live Professional (v. 8.2.0.368--last multi-country version that takes POI files from outside sources) cannot obtain a fix--it DOES see satellites, but has issues pulling NMEA fix data from the satellites (as if the receiver can't get a full lock) and eventually times out.
I can confirm that solely the sections of the patch pertaining to HSPDA fixes can be applied in ILWT CM7 based on nightly 185, and that these do NOT break GPS; the problematic section in the patch may be a reference to AGPS which is not meant to actually be changed (but some patchers may misbehave and misinterpret this part of the script), or it may be an issue for nightly 186 (though I have a hard time with the latter--seeing as it and build 185 are pretty much identical for the Vision/G2/Desire Z).
At any rate, it's not so much the changes break GPS as that the patch might not be implemented properly. (I AM seeing some improvements with HSPDA and wifi, and with the changes applied manually GPS still works.)
Hi there.
Well, first of all, I am (hopefully) not insane. Second, I'm a network engineer for 20+ years, so my technical skills are not subject to any doubt. Third, I'm absolutely new to android, thus I don't exactly know the API and especially hardware interfaces.
OK.
I bought a Fire, axed the native shell, installed TWRP2 and CM7. Downloaded a nice ereader, a video player, and a local maps application, called Yandex Maps, I like it for instant and quite precise traffic info. Tapped the location button and found the crossfire within 30 meters around the actual location.
Then I drove to work and, while checking with traffic info, pressed "locate me" again. And the Maps has found me right in place.
"GPS is working" I said to myself.... and some days after, browsing this forum, found out that Fire HAS NO GPS SENSOR.
Need to say that I have the same IP network at home and at work (I'm the ISP in both places). And even if its location can be found via RIPE, it is declared to reside in my office. Not my home, which is 12km away.
Digging further, I installed Google Maps. This app refused to find my location. Tried Navitel - same result. But Yandex does its best - in an anonymous internet cafe (third place!) with free wifi it pinned me RIGHT on the building.
I googled for the radio chip of the kindle. According to ifixit, it's a hybrid with TI WL1271 inside. According to TI, WL1283, the chip that does have GPS in addition to wifi and BT, is pin-compatible with older WL1271 - so there *is* a small chance that WL1271 is replaced with 1283/81 in most recent devices.
That's the ONLY explanation I can believe in. Otherwise I'm totally lost. I even have posted the same issue to BT/GPS thread. Heard no answer there.
Your ideas?!
cu6apum said:
Hi there.
Well, first of all, I am (hopefully) not insane. Second, I'm a network engineer for 20+ years, so my technical skills are not subject to any doubt. Third, I'm absolutely new to android, thus I don't exactly know the API and especially hardware interfaces.
OK.
I bought a Fire, axed the native shell, installed TWRP2 and CM7. Downloaded a nice ereader, a video player, and a local maps application, called Yandex Maps, I like it for instant and quite precise traffic info. Tapped the location button and found the crossfire within 30 meters around the actual location.
Then I drove to work and, while checking with traffic info, pressed "locate me" again. And the Maps has found me right in place.
"GPS is working" I said to myself.... and some days after, browsing this forum, found out that Fire HAS NO GPS SENSOR.
Need to say that I have the same IP network at home and at work (I'm the ISP in both places). And even if its location can be found via RIPE, it is declared to reside in my office. Not my home, which is 12km away.
Digging further, I installed Google Maps. This app refused to find my location. Tried Navitel - same result. But Yandex does its best - in an anonymous internet cafe (third place!) with free wifi it pinned me RIGHT on the building.
I googled for the radio chip of the kindle. According to ifixit, it's a hybrid with TI WL1271 inside. According to TI, WL1283, the chip that does have GPS in addition to wifi and BT, is pin-compatible with older WL1271 - so there *is* a small chance that WL1271 is replaced with 1283/81 in most recent devices.
That's the ONLY explanation I can believe in. Otherwise I'm totally lost. I even have posted the same issue to BT/GPS thread. Heard no answer there.
Your ideas?!
Click to expand...
Click to collapse
Have you tried doing this with wifi turned off? Do you get the same results?
Just to clarify, you say your map app is showing you your current location without any wifi connection? i.e it updates as you drive?
From my own experience, apps like google maps can approximate your location based off your wifi. (I assume this is done because google collects wifi locations.)
Your assumptions that the kindle fire may have GPS could infact be correct. We know that the chipset does infact have BT even though there may never be working drivers for it.
Also, since amazon doesn't spec the KF for either BT or GPS the chips they get could be of lower quality. Since the only thing they need working is the wifi. This could mean the even if there is GPS or BT, there is no guarantee that they would even work. and if they did, they wouldn't work on everyone's KF.
airmaxx23 said:
Have you tried doing this with wifi turned off? Do you get the same results?
Click to expand...
Click to collapse
airmaxx23, unfortunately this is the only app that shows my location correctly, AND does not have offline map cache; even if I fill the cache manually, it requires internet connection to start. As of now, I cannot find a hacked version to try. Still looking for an alternative.
Sambena , no. Still no offline experience, see the post. Google can't locate, for the wifi at home does NOT have my location info.
Is there any way in CM7 to display exact hardware config without desoldering the device? As I suggest from above, the standard GPS API is unavailable (Google, Navitel) but Yandex is able to find some low-level interface (famous Russian coders!)
You could get into a shell and look at lspci > lspci.txt
You could also run dmesg > dmesg.txt& and then try to find your location via your maps app. Between that and a location, you should be able to see what's going on.
Sent from my PG86100 using XDA App
cu6apum said:
Hi there.
Well, first of all, I am (hopefully) not insane. Second, I'm a network engineer for 20+ years, so my technical skills are not subject to any doubt. Third, I'm absolutely new to android, thus I don't exactly know the API and especially hardware interfaces.
OK.
I bought a Fire, axed the native shell, installed TWRP2 and CM7. Downloaded a nice ereader, a video player, and a local maps application, called Yandex Maps, I like it for instant and quite precise traffic info. Tapped the location button and found the crossfire within 30 meters around the actual location.
Then I drove to work and, while checking with traffic info, pressed "locate me" again. And the Maps has found me right in place.
"GPS is working" I said to myself.... and some days after, browsing this forum, found out that Fire HAS NO GPS SENSOR.
Need to say that I have the same IP network at home and at work (I'm the ISP in both places). And even if its location can be found via RIPE, it is declared to reside in my office. Not my home, which is 12km away.
Digging further, I installed Google Maps. This app refused to find my location. Tried Navitel - same result. But Yandex does its best - in an anonymous internet cafe (third place!) with free wifi it pinned me RIGHT on the building.
I googled for the radio chip of the kindle. According to ifixit, it's a hybrid with TI WL1271 inside. According to TI, WL1283, the chip that does have GPS in addition to wifi and BT, is pin-compatible with older WL1271 - so there *is* a small chance that WL1271 is replaced with 1283/81 in most recent devices.
That's the ONLY explanation I can believe in. Otherwise I'm totally lost. I even have posted the same issue to BT/GPS thread. Heard no answer there.
Your ideas?!
Click to expand...
Click to collapse
I'm sorry to burst your beautiful little bubble here but the kfire doesn't have any GPS. What you are seeing is Google being a clever bigger. You see, when they rolled down nearly all the steers in North America, they took snapstops of the wifi, and coordinated with the GPS location. The reason you can transfer between your home network and your work with the same IP is because they used they use the Mac addresses of the networks in range, and cross reference it with their database to give you an approximation of where you are
tldr; android uses the Mac address of in range also to approximate where you are
I will have no disappointment even if my fire has no gps. I was buying the cheapest 7" tablet and I'm fine with it.
Please keep in mind that I'm almost an antipode to North America: Moscow Russia here. So neither Google, nor Amazon are aware of my IP, MAC, or even street address. I can imagine (although it's hardly probable) that Yandex is polling public wifi places for their locations, but none of mine are public!
The VERY only lifelike hypothesis that goes in groove with your idea is that Yandex cached the location of my iphone at home (the phone does have GPS and Yandex maps installed) and locates me based on the IP subnet. But: a) I never used the phone to locate the cafe I mentioned before. b) I cannot even imagine the cache size that Yandex has to have in this case.
I think this time you missed the goal. Any other thoughts?
It doesn't matter if Google knows your MAC or not when you have WiFi on it polls for acess points and bases your location off the signal strength of all of them.
You cracked the case!!!
Maybe you can teach me also, why it does NOT work here?!
afazel said:
You could get into a shell and look at lspci > lspci.txt
You could also run dmesg...
Click to expand...
Click to collapse
Indeed, thank you.
dmesg says it's a TI WL-1273, sadly... ven=0x104c, dev=0x9066. Well, at least it's proven to support BT and FM radio.
Kindle has no GPS, and Yandex is smart enough to cache locations even in NATted networks. Thanks for attention.
Starfire70 said:
It doesn't matter if Google knows your MAC or not when you have WiFi on it polls for acess points and bases your location off the signal strength of all of them.
Click to expand...
Click to collapse
It's not the Mac address of your device, it's the Mac address of the APs, they broadcast it with the probe signals. Its also more reliable to go on than the name of their AP. People change the name all the time, but who would change the Mac?
I am using the latest incarnation of CM7.2-RC0 for the Aria. The GPS is very slow to lock if not used for a while or if manually reset using a GPS app. It will always lock eventually but requires about two to five minutes as it slowly aquires each satellite, locking after getting a fix on the fifth or sixth satellite. It is behaving as if it is doing a cold-start every time.
I have found that the AGPS data (xtra.bin) is never downloaded. I can see on my DNS server that the Aria never attempts to resolve any of the XTRA_SERVER names. Because of this, there is no way that xtra.bin file can ever be downloaded.
As a test, I reset the GPS using the "GPS Status" app and then restarted the phone. After it reboots, I can see a DNS query for the NTP_SERVER but no DNS queries for any of the XTRA_SERVERs. When I perform a manual download within the "GPS Status" app, a popup message immediately says "GPS assistance data downloaded" but I don't see how that is really possible since I never see a DNS request to resolve the XTRA_SERVER names.
If someone familar with the GPS code can take a look and see what is causing this behavior, that would be great. I think once the AGPS data is actually downloaded, the locks should be fast.
This GPS issue is the only major problem that I have come across with CM7.2.
-John
This issue is already known. The current version of the GPS libs in the CM repo are not working correctly, although functional. However, you can flash different versions of the GPS libs over your current ROM to fix the issues you are having.
The flashable zips are at the bottom of this post: http://forum.xda-developers.com/showpost.php?p=19106745&postcount=3688
liberty-cm-htc-stock-gps-signed.zip - original HTC drivers
liberty-cm-reverted-src-gps-signed.zip - older CM drivers from before they were messed up
liberty-cm-current-src-gps-signed.zip - current CM drivers
I knew about reverting to the older GPS libs. It's just that I've never seen any specifics on why the current CM7 GPS libs are not functioning correctly and thought I'd bring a data point to the discussion.
-John
My understanding was that someone submitted a fix to the repo to get GPS working properly on another device (I don't know which device), but although it fixes a problem on that device it created one on the Aria (and possibly others). Not sure on the timespan for if/when this will be corrected.
drumist said:
My understanding was that someone submitted a fix to the repo to get GPS working properly on another device (I don't know which device), but although it fixes a problem on that device it created one on the Aria (and possibly others). Not sure on the timespan for if/when this will be corrected.
Click to expand...
Click to collapse
that device was the supersonic (evo4g). doesn't look like it'll ever be fixed.