yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] aleadam:
I really appreciate what you're doing here.

I just flashed it and gave it a quick test. GPS Test app does not show any difference in number of satellites, time to first fix nor signal strength before and after flashing the update. Don't know if there is any setting that should modify it.

What really changed is tracking. My tracks path is now a little more shaky (barely, really), but dead on when changing direction or even changing lanes, i. e., I did not see any overshoot in the corners whatsoever. That is clearly the expected behavior if I understood your explanations correctly. When I looked at it, it had 10 m accuracy.

I only tested the AT&T version. Will post some logs later on when I have the chance to read your comments in gps.conf file.

Thanks again.
[Captivate Android Development] TheSopranos16:
I find its much improved and I lock more satellites as compared to JF6, but I still find that when moving, the number of satellites locked fluctuates a lot. If I turn on LBStestMode when driving and watch the number of satellites locked, it will go from 10 to 4 to 6 to 4 to 8...etc. its not very stable and the accuracy fluctuates as well. Other phones take a few seconds to get the accuracy down to 5 or 3 meters and then it pretty much stays at that level without big fluctuations...
[Captivate Android Development] calfman:
When trying to install any of those files using CWM, I am getting the following error messages:

Installing update...

Copying files...

E:Failure at line 2:

copy_dir PACKAGE:system SYSTEM:

Installation aborted.

I am using Axura 2.2. Any ideas?

Thanks!
[Captivate Android Development] rajendra82:
Copy the files inside the zip manually using adb, terminal, or root manager, and then fix ownership and permissions. Either that, or get a better kernel with the latest CWM integrated.
[Captivate Android Development] tiger4j:
I'm having the same problems. I tried doing it manually, but GPS doesn't work at all now. GPS just cuts itself back off after about 2 sec. GPS test doesn't start up either. Using latest clockwork with voodoo kernel. Maybe its ROM related... I don't know.
[Captivate Android Development] crazililazn:
Haven't gone on a drive with these installed, but what I have noticed is that, whichever one i try, the gps keeps thinking i am moving, even though the phone is stationary... on my desk...

Anyone else experiencing something like this.

I installed this on Assonance 5.0.
[Captivate Android Development] drancid:
Nice Da_G!!

Just flashed control plane one.

Will do driving test after work and post the result asap!!

Sent via ATT Captivate.

Perception Build 9!!
[Captivate Android Development] IamSonoma:
It did that to me too. I was moving 2-3 MPH sitting at my desk. I did take a test drive. It did not works so well for me. I am still testing though.
[Captivate Android Development] warpkid:
Interesting that the GPS antenna is sub par.

Incidentally, is the chip used in the SGS used in any other phones? If so, I wonder how it performs in those?

(better im guessing)
[Captivate Android Development] Da_G:
@warpkid:

The GPS Chip is the Broadcom BCM4751 (Revision A1)

I'm not aware of it being used in any phones aside from the SGS line and Nexus S. It's interesting to note that the Nexus S does include a different antenna. There are varying reports about the behavior of the Nexus S GPS, really need some objective data rather than anecdotal reports to make a judgement on the behavior.

The iPhone4 uses the BCM4750 (predecessor to our GPS, built on a larger process, so uses more power/larger size) - Broadcom states that it supports tracking down to -164dBm. You would think this translates to our newer model chip but I can visibly see it drop a satellite from a fix at -155 dBm. This is a good bit less sensitive than broadcom states!
[Captivate Android Development] TheSopranos16:
@Da_G: Thanks for the explanation, it was extremely helpful. Does the TCXO that you talked about have any software governing it or is it entirely hardware? If all it does is keep time, it would seem like a pure hardware component. Also, could the drift in its frequency account for poor accuracy as well as dropped satellites? An inaccuracy with something as fundamental to GPS as time (which the system is based on) seems like a very plausable root cause for most of our issues. If its only in hardware, I'd say we are probably screwed for a true fix. All we can do is try to tweak software to compensate for faulty hardware, but we'll never have a great GPS on this phone.

I tried your google configuration on the way home from work. It seems to be more jumpy, which makes sense since interpolation and smoothing are removed. I did notice that the accuracy fluctuated more than with my previous config. I will try to tweak settings as you described to see if I can achieve results that are more suitable for my use.
[Captivate Android Development] andars05:
So I've been keeping track of all of your threads Da_G. The information you have provided has been extremely helpful and educational! I know you mentioned earlier that part of the problem may lie in the baseband. I believe you also stated that the chip uses MEIF, a proprietary Nokia data format, that is then later translated into NMEA data. The NMEA data is in turn used by Google Nav/Maps.

This is my understanding at least. These are all new terms to me, so please correct my interpretation if needed :P

Assuming Samsung does not fix the problem, how likely is it that the SGS will be able to have a permanent fix implemented? If the primary problem is in the baseband code, how probable would it be for you or another dev to obtain the needed code and implement a fix?

I'm considering getting a bluetooth GPS receiver, as they are quite cheap ($20-30). I figure the GPS works well enough for everyday app location needs, and I can use the BT receiver for extended trip navigation. That said, the optimal solution would be to not need an alternative BT receiver. I'll give your update.zip a shot and play with some of the unstable settings. I'm always hopeful for better performance:)
[Captivate Android Development] Krynn!:
I seem to remember a post from CLShortFuse a few months ago where he had found a Blackberry device that used the same chip. He never did say exactly which Blackberry device it was though...
[Captivate Android Development] Da_G:
@TheSopranos16:

The TCXO is an entirely hardware component (a pretty cheap one in comparison to other components, too) - From what I can tell without disasssembling the device, it's built into the GPS package (It's a monolithic package with all components contained inside) - If the TCXO is indeed the problem the best we can hope for is to compensate.

@andars05:

The baseband handles initial bring-up of the system, and provides a UART for the glgps daemon to connect with to pass MEIF data. glgps then takes this MEIF data, makes measurements and calculations, and then provides it's own NMEA data to the system, so yes, correct :) My Tracks shows the data as received, Maps does some further filtering to the received data.

It would be great to have access to the baseband source, but it contains alot of source code from 3rd parties that samsung licensed, it's highly unlikely to ever be purposefully released (these other companies would not allow it) - also pretty unlikely to get ahold of the source through an unofficial method, i've not yet seen baseband source for ANY device on the market.

Through jupiter.xml we're going to get as close as we can to addressing the issue. Potentially a newer glgps daemon could help too. This one is newer than any found on the SGS devices (it's nov 07 build from Nexus S)

@Krynn!:

I did make sure to read through all the posts I could find about the topic and saw that :) The linked post shows a different TCXO in use on that one. If the TCXO is indeed the problem, that device might not have the same problems due to using a different one. It would be interesting to get some data from that.

I've documented all the possible values for FrqPlan and RfType in the config, that are supported by the glgps daemon. So we can certainly experiment and possibly find a combination that yields better results :) Again some people may have better results without using _UNSTABLE and with _EXT_LNA.

@Everyone:

I'll continue testing until I feel I can't do any better! One avenue of approach we haven't tried yet is supplying a proper EE (Extended Ephemeris) file, which I believe should be xtra.bin. I tried downloading it on my PC and sticking it in the proper place per the jupiter.xml (/data/gps/xtra.bin) but the daemon log output complains about it being corrupted. If we can determine exactly what it's looking for here and where to get it, this should help a bit :) On all stock configurations i've examined these parameters are not even in the jupiter.xml so it will NEVER use EE data.

Debug output using xtra.bin:

EE file [/data/gps/xtra.bin] opened for reading (fd=54)
EEFileRead: Corrupt entry(s) detected. Not using EE.
Closed EE file (fd=54)

Another object for testing would be the following setting: "<periodic_hor_acc_remap> <remap in="50" out="55" /> </periodic_hor_acc_remap>" - this is present in the nexus s config and not any of the SGS configs. I'm not yet sure exactly what it means! Testing with and without it would yield some good data. There's still plenty of disassembly and testing to be done :)
[Captivate Android Development] crazililazn:
Hmm, changing it to "DYN_Auto" seems to fix it. When i change it to "DYN_VEHICLE", it was still jumping around :]

Now i just have to give it a test drive and see how it works :]
[Captivate Android Development] Krad:
I flashes the att version over assonance 5 with sent kernel 1.4.3 and jk4 modem.

Took about two minutes for inital lock but after that it was spot on. It clearly showed me turning in intersections and the arrow would speed up and slow down depending on my speed.

I think you solved the GPS! where can we donate?
[Captivate Android Development] Dani897:
im following this all because it interests me but i havent provided any data becasue it would be useless. my mytracks results are perfect down to my lane in traffic in most cases. i have never had a lock under 10 meters with the stock roms or the ji6 froyo leak but my actual estimated position is very near my actual position. it seems that the phone only locks to multiples of 5 meters, so it's not nessesarily poor positioning but just like the phone settles for either 5 or 10 and stops there. now on jj4 roms and ported bell vibrant roms i get 5 meters but it spends alot more time trying to lock especially on the bell vibrant rom.

my issues mostly come from google navigation that always thinks im taking exits. if i run mytracks in the background the gps turns off after some time with ji6 jf7 jf6 jh2 and jh3 but not with jj4 or jk3. the bug continues to happen afterward on many gps programs untill i A) factory reset and restore data with cwm B) flash a rom or C) run that samsung app to reset the gps, clearing gps data in lbs test mode doesn't help. jj4 and jk3 take longer to lock but give less trouble with navigation and dont have the bug that causes my gps to turn off, ji6 is extremely fast to lock.

intersting thing is that 3rd party software seems to play nicer with my gps, i dont know what the difference is but navdroyd although not as polished as others is always good. very very good. but other gps programs that have been recommended by other users cause my bug where gps turns off.

when i say my gps turns off well the settings location and security page says it is on and the toggle on the notification pulldown menu says it is on but the tell tale icon that shows the status is missing from the notification bar. the phone faisl to track and it shows my location as stationary. navigation says "gps signal lost" others have reported this bug in conversation but some do not experience it.

ill continue to track your work and hope i can get my phone to play nice with googles own software. untill then i will use navdroyd.
[Captivate Android Development] drancid:
Just finished about 15 mins short driving test but i couldn't feel any improvement compare to Perception build 9's.

Will flash ATT one and try again.

My LBStestmode settings were

Session Type: Tracking

Test Mode: S/W

Operation Mode: MS Base

Start Mode: Hot Start

GPS Plus: ON

Dynamic Accuracy: ON

Accuracy: 50

GPS Logging: OFF

Server FQDN Type: Custom Config

Server: supl.google.com

Server Port: 7276

SUPL Secure Socket: OFF

AGPS Mode: Control Plane
[Captivate Android Development] Da_G:
@Krad:

There's a link just to the left of this text if you're on the forum's website :) Appreciated but not necessary in any way!

@Dani897:

The bug you describe with the icon missing from the notification bar is the behavior when the glgps daemon quits unexpectedly. If you were to load it with logging on, there would be an entry in the log detailing exactly why it stopped! This would be very useful towards fixing that issue :)

At the point that occurs you could load up a terminal and start the glgps daemon manually, to restore functionality, also. I've run into that happening many times with my daemon, usually due to some odd settings in jupiter.xml that it doesn't like.

@drancid:

You'll need Operation Mode set to Standalone for things to work properly with the Nexus S glgps daemon. Give that a shot!
[Captivate Android Development] drancid:
Oh.... :eek:

Got it!!! :D
[Captivate Android Development] Cezar`:
Here are my tracks done with both CP enabled and with google supl server... (no i didnt mix them, i just tried them both)

I .. have no words.. maybe my device is reaaaaaly stupid

http://maps.google.com/maps/ms?ie=U...303434853613496094.000497ee25266309c9705&z=17

http://maps.google.com/maps/ms?ie=U...9.202097,16.599577&spn=0.016432,0.045018&z=15

Location: tram, phone in the window, signal was great but not getting better accuracy than 30m. One thing I noticed, when going fast, it was keeping the straight line.

Running JPX i9000 ROM with reoriented kernel 2.2.2 and with stock gps files the lock is in max 30 sec with cold start. Tracking is great as well, set as standalone. Didn't try MS Based
[Captivate Android Development] Dani897:
is there an explaination on how to pull that log? i was gonna flash a rom that i know to work better from personal experience but for the sake of the effort i can stick to ji6 and recreate the situation. it seems to happen alot in msbased mode. at one point i could predict when it would happen. at nearly exactly 6 minutes of use it would loose the icon. id turn gps off then back on and another 6 minutes it would go again. it seemed to be affected by lbs settings and especially if i had left lbs running in the background too long which i did because it seemed to track better at the time.
[Captivate Android Development] ari197:
just flashed this on Axura CE 2.4 .. it's working good while stationary (with 50 meters accuracy) .. will try tracking later on ..
[Captivate Android Development] K-mart Shopper:
LOL. Those tracks are embarrassing... for Samsung. I've come to realize the only time I use the GPS is to test if it's working - that's not exactly an ideal use for it... I think it's just gonna be turned off from now on, unless by some miracle a real fix beams itself to my phone.
[Captivate Android Development] reinbeau:
This is exactly what I've thought all along, the Captivate doesn't handle the ephemeris data properly. There's always a lag for any GPS getting a fix, and it's worse if you've shut the GPS off and turned it back on miles away from the shut-off area. I'm still having a hard time accepting that any data or wifi connection should be needed, if it were properly set up in the first place that shouldn't be necessary.
[Captivate Android Development] mindfrost82:
For the EE data, you could try GPS Status from the Market. It has an option to download AGPS data (which I assume is an EE file), and you can set it to automatically download it every day or xx hours.

There's also some other settings for GPS. I'm not sure if they really work on the SGS, but you might be able to try some things in there and see if it helps.
[Captivate Android Development] aleadam:
And you didn't get any ticket for driving like that? ;)

I'm wondering what the difference might be. I'm using setiron's kernel, wich is also based (in part, I think) on jpx.
[Captivate Android Development] Mac11700:
I know you think the issue with the gps is software related...but have you looked at this...http://xdaforums.com/showthread.php?t=876179

If these solution really works..might one trry both a software fix...and this slight modification and see real net results. I am keenly interested in the antenna plug mentioned here in the thread...since we have the same receptacle for it inside...http://blog.wpsantennas.com/2007/05/samsung-blackjack-i607-external-antenna.html If this would work..looks like a better solution for those actually needing/wanting a better chance at having a good signal in their vehicles..don't you think ?

Mac
[Captivate Android Development] drancid:
This is very interesting.

Imma give it a shot!

And i changed operation mode to standalone like da_g said but feel the same. Lost signal 4 times on my way work. Revert route from yesterday.

Edit. I enabled control plane mode in service mode with dial

*#*#197328640#*#* ->

common ->

Gps

should i disable it?

Sent via ATT Captivate.

Perception Build 9!!
[Captivate Android Development] pinoymutt:
Da_G it's nice to see you made the plunge over to the Android side.

I remember that much of your work made life on the Tilt2 in the WM world much more enjoyable, so if anyone can crack this GPS pain, you're the guy I'd put the chips on!

I have a feeling this forum is going to get a whole lot more interesting!
[Captivate Android Development] Maliberti:
Excellent!

Great work, thank you.
[Captivate Android Development] Da_G:
@icezar1:

Impressive! mine behaves like this all the time. I think I got a particularly bad performer when it comes to GPS. Makes testing interesting :)

@Dani897:

The first post is pretty much dedicated to how to get logging data out of the glgps daemon :)

@mindfrost82:

I tried GPS Status, it said it downloaded AGPS data. It doesn't report where it sticks it on the system and it doesn't read jupiter.xml to know where to put it according to where the daemon looks. (/data/gps/cbee.cbee on my current configuration, nowhere by default) - I ran strace on the process and I don't see it ever open any files other than it's own settings.xml. Is the AGPS part of this program a placebo? :) Or maybe it's just intended to work with some other chipset that accepts AGPS data in some other way. Either way it has zero effect on ours! I haven't yet been able to find a source of Broadcom-compatible EE data (plenty of SiRF compatible floating around and updated)

@Mac11700:

I did try this also on my device, with little to no effect. I monitored signal strength before and after, really just about no change. There is however a noticable signal strength difference based on the orientation of the device (back up seems to get the best reception during my testing, hardly practical for use)

The antenna port on the back is more than likely connected to the Cellular RF circuit and not the GPS RF circuit (it would be the first time I ever saw that.) - if you click through on the link you provided, you'll note the following from the product page: "# FME Male: Connects to Wilson Cellular Cell Phone Antenna "

@drancid:

It's possible that's affecting things. Hard to say. Please tool with the jupiter.xml _EXT_LNA and _UNSTABLE setting to see if you get a better result at the other one.

@pinoymutt:

I love a challenge :) I'm not really doing it for myself either as I have a BT GPS sitting right here that works perfectly tethered to the Captivate, and the battery lasts through about 5 full charge cycles on the Cappy! But I still want my onboard GPS to work, dangit :)
[Captivate Android Development] Krynn!:
Interesting... GPS Status tells you how old the AGPS data is. I'm not 100% certain, but I'm pretty sure that I've noted it being only a day or two old when it had been a week or more since I launched GPS Status. On the other hand, I've never seen it make any difference either.
[Captivate Android Development] Da_G:
While doing some testing with Ferman in IRC, I noticed that I forgot to mention this jupiter.xml will not work as is in Eclair, only Froyo. (due to differences in the kernel layout.) This was probably the problem with a few of the users who said their GPS stopped working after trying it.

I'll update the first post with info on a quick edit to jupiter.xml that will make it compatible. Thanks Ferman for testing :)
[Captivate Android Development] nephets0:
I don't know how much difference it makes but I just flipped on gps on my gfs aria. And it measured in 1' increments. Whereas I've only seen the cappy do intervals of five. Maybe that's part of the problem?
[Captivate Android Development] compuguy1088:
Curious, has anyone tried these daemons on a vibrant?
[Captivate Android Development] joedoe:
For the price of that antenna I would rather buy a bluetooth GPS reciever!
[Captivate Android Development] Dani897:
[Facepalm] sorry, once I got down to the commands and adb stuff I just started skimming. Didn't notice.
[Captivate Android Development] Da_G:
http://pastebin.com/rdvtnSfg

This config is working best for me currently. I noticed an interesting issue, though.. when I switched from having My Tracks in the background, to My Tracks in the foreground, my accuracy dropped considerably. (Coincided with a drop in the number of satellites the phone could see)

Here's a My Tracks map I made alternating between My Tracks in the foreground, and lbstestmode in the foreground.

http://maps.google.com/maps/ms?ie=U...73840170072199.0004980df68855dceff4e&t=h&z=14

I started in the upper left hand corner and moved towards the bottom right hand corner. During the areas where you can see the track considerably off-road, I had My Tracks in the foreground. During the areas where you see the track spot on, I have lbstestmode in the foreground. Nothing else is running on the phone at the time.

Seems from testing that the optimal FrqPlan can vary by device.
[Captivate Android Development] Krynn!:
Curiouser and curiouser....

This seems to indicate that the GPS may be more CPU dependent than I thought. Maybe Google is giving display updating threads higher priority than GPS handling threads? Or maybe they intentionally cut back on the priority for GPS to try and save battery power, and they cut it back far enough that this chipset goes slightly nuts?

And I was always wondering about people claiming that third party nav apps were much more accurate. Nobody figured out how to prove it though. Good catch!

If I can ever get out of Heathrow and get back home, I'll see if I can replicate your results.