yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] SlickyFats:
v2.0 Beta 6

Running Cog 4.3, virtually NO GPS at all.

version 1 only made it where I would get a lock after 40-50 seconds and if I moved it lost the signal.

2.0 Beta 6 works 98% of the time at full speed and perfectly when stationary. Picks up in some buildings too.

Thank You
[Captivate Android Development] halfsoul:
attributes = special permissions

All,

Two things I'd like to explain as I understand them.

1) If lbsdata.sto doesn't exist, then it is the permissions of the parent directory (/data/gps) that determines if it can be created:

drwxr-xr-x system	system	gps

=> Only "system" user can create files (w+x required for creating files)

2) The S & T are called attributes.

S = SGID, no execute (since it substitutes x in group permissions)

T = sticky bit, no execute (since it substitutes x in others permissions)

SGID without execute (S) means: the file is subject to mandatory locking during access (if the filesystem is mounted to support mandatory locking with mount -o mand).

Sticky either means:

a) file cannot be renamed or deleted except by owner (source: Wikipedia)

b) On non-executable files the bit never had any effect (source: Wayne Pollock)

---xr-SrwT system	system	lbsdata.sto

=> In summary (as I understand it):

- Owner "system" can execute only *

- "system" group (but not "system" user) can read only (SGID, no x) **

- Others (not "system" user or group) can read and write only (sticky, no x) ***

- File is locked while being accessed (depending on mount options) ****

* This only makes sense if lbsdata.sto is a compiled program. Scripts require both r+x

** Since there is no /etc/passwd file I don't know how to list the users that belong to the "system" group.

*** I assume this is who we are, but I have no clue.

**** I think different kernels use different mounting options, maybe this is why some peoples' file gets updated whereas others' don't.
[Captivate Android Development] askpcguy:
A snowstorm of useless information?

Posting my observations is not useless information.

I am using cognition 4.2.1 with the overstock 1.1 kernel and no GPS tweaks.

Instead of calling someones post useless information, how about taking the time to point to an external link for more information which will help everyone learn.
[Captivate Android Development] anneoneamouse:
I was referring to my post not yours.

A o N
[Captivate Android Development] askpcguy:
Too funny. I got back from a quick drive using GPS and when I checked I did see the lto.dat file in /data/GPS with the weird permissions.

This GPS frustration is taking its toll.

I apologize for being defensive and no hard feelings.
[Captivate Android Development] Rrryan2:
Lbsdata.sto is where locally stored wireless locations and their known locations are written. It can help speed first fix times by giving an approximate initial location. It can be helpful if you're frequently starting gps at the same locations (home, work etc.).
[Captivate Android Development] Rrryan2:
The weird permissions turned out to not be the problem. I've managed to get it working properly even with the odd permissions and I'm trying to get a test version ready.
[Captivate Android Development] CuriousTech:
Mine starts every hour even if I don't want it to. I use Fancy Widget Pro with GPS location disabled but it opens the GPS for 10 seconds anyway. That could be a problem since it's not always in a good location. A lot of widgets can do that so another thing to test with and without.
[Captivate Android Development] askpcguy:
I see the same behavior and its annoying.

Seems my laptop interferes with the GPS. If the laptop is powered off I can get a GPS fix indoors.
[Captivate Android Development] Rrryan2:
Already known. See http://xdaforums.com/showthread.php?p=11628954#post11628954

It's basically evidence that Samsung still has some laughably flawed GPS configurations somewhere deep in the innards beyond where we can reach it.

Other than that I don't think it's much of a problem as long as there's an existing secgps.conf with non-stupid settings.

As I wrote previously, lbsdata.sto is the local Location Based Services file, the locally stored history of wireless networks with known locations is kept to help give an approximate initial location. Since lbsLocal is not ennabled in the stock config it never gets written by your setup. It's not that big a deal and is really only even helpful when you're attempting to get a fix in a place where you have before previously (i.e. home, work, etc.).
[Captivate Android Development] Rrryan2:
Use something like Root Explorer, Terminal Emulator or ADB to view. Not all explorer apps handle permissions right and some can't view the system partitions. You're looking for /data/gps/, not /sdcard/data/gps. Hint: you definitely have a /data/ somewhere because your phone basically wouldn't work at all otherwise.

There's nothing in this fix that would trigger GPS hourly like that, or at least nothing in the configs we can see. Could triggered by any number of widgets or apps though. Weather apps and some social networking apps would be likely culprits, but even some ad-supported apps might be invoking gps periodically to help them feed you 'better' ads. As long as it times out in a reasonable time so as not to drain battery unnecessarily, it's not that big of a deal I don't think. You're not going to get 'penalized' for failed attempts as the last known fix is not overwritten or such.
[Captivate Android Development] askpcguy:
Super Manager is a great free file explorer, similar to Root Explorer. I use it instead of Root Explorer.

Only problem is, you have to pay if you want to open files from Super Manager. Instead, I copy the files to /sdcard/ so I can open them with a text editor.
[Captivate Android Development] CuriousTech:
Oh I'm positive that it's Fancy Widget Pro. I guess I'm stuck in old school GPS thinking where if a fix times out it reverts back to cold start which is the usual 30 seconds from first signal.

Edit: You're right. I can confirm that by the aluminum foil test. Unless it was lucky every time, it got first signal from start in just seconds after running blind for 60 seconds. So that's not a problem.
[Captivate Android Development] askpcguy:
It is fancy widget, use a task killer and end it's process. Notice the GPS icon in the status bar will go away.

I think it updates the weather but I am not postive.
[Captivate Android Development] CuriousTech:
Yes it uses location for weather, but if you set it to a location it disables the "use GPS for location" which should make not access GPS resources, but it does anyway.
[Captivate Android Development] Rrryan2:
It does to an extent. If it attempts a warm start and can't make the computed position close to the last known location, it will discard it and attempt a cold start instead. However, it doesn't completely dump the last known good position permanently, and if it fails to get a fix it will still re-attempt warm start next time.

I've never worked with any GPS devices that would permanently toss the last known fix on a failed warm start, but my experience only dates back about 10 years or so and was mostly with full-featured systems.

EDIT: whoops, cross-postedit. NVM.
[Captivate Android Development] CuriousTech:
Oh good. I have a little GPS background as well. LOL

It's my understanding that not all satellites can be received at once and the device can't assume it knows where it is on Earth or where the satellites are in association with each other or the Earth if it's not hearing anything, so it has search. And in searching it has to push out the most stale data replacing it with each new attempt to find one of the 32 or 31 birds using 12 channels. And that's pretty cold. But this is just my understanding of the SirfStar type chipsets. I haven't studied much of the internals in quite a long time.
[Captivate Android Development] Kirby64:
Props to all you guys are doing, unfortunately I'm convinced it's a hardware issue. I got a new Captivate after my old one bit the dust, and the GPS works flawlessly (yes, even while driving around) and has never been an issue thus far, even with numerous different ROM flashes.

Keep up the good work though, I know every little bit helps.
[Captivate Android Development] askpcguy:
Again for all those who get a new captivate and say the GPS is working better, please include the build number found on the white sticker under the battery.

It's a four digit number, for example 10.08 for 2010, August.
[Captivate Android Development] CuriousTech:
I'd like to see screenshots of GPS Status or GPS Test with SNR levels, accuracy and a few TTFFs just to see what the difference is if possible.
[Captivate Android Development] Kirby64:
Sorry about that. For reference, my build number is 10.10 (So, October 2010?)
[Captivate Android Development] NascarFastcar:
How does this matter to those who have their phone send in for repair and receive the same one?
[Captivate Android Development] Rrryan2:
Your thinking is correct, just a little too chip-centric. In a smartphone implementation there's lots more resources available than in just a chip, tons of memory and storage available so keeping it stored is trivial. It's another one of those ways in which a gps-enabled smartphone potentially has some big advantages over standalone gps, but in this case it's crippled by flawed design and implementation.

Unhelpful and incorrect. If it were solely a hardware problem then software changes like this would have no effect, yet they can clearly provide substantial benefit for a whole lot of users. Not all users who exchanged have gotten one back with a working GPS, and strictly speaking AT&T regards gps issues as non-warrantable anyway so that's not an option for many.

It also might not be wise to assume either that refurbed units necessarily come with the same software and configurations as the OTA updates.

Build number isn't necessarily meaningful WRT gps in my experience. There are 1008's with flawless gps, 1012's with barely working gps.

I'd like to see MD5's on glgps_samsungJupiter and the .so libraries myself before customizations start getting flashed and overwriting them. But I'm just suspicious that way.
[Captivate Android Development] Soccer_Dad:
This is how I tested my GPS: I drove a consistent path around the neighborhood last evening with different settings and modems, to see how the tracks compared. I am looking for GPS that will work away from cell towers, so I used Standalone mode and turned off GPS Plus (assuming that also used cell towers).

For the tests, I went into recovery, loaded what I wanted to test, cleared the cache, cleared the Dalvik cache, and rebooted. Then in LBStestmode, I would delete GPS data (except for the Plumbbob test), then get a position fix. Once the fix was established, I would leave LBStestmode going in the background, start Maverick (my choice of track recording software), start a new track, record, then start driving around my neighborhood, clockwise (so I know which is the early fixes, and which are the later ones).

The attached pictures record the results for different modems and for a couple different GPS fixes. I used Adam's GPS fix on all but the one labeled Plumbbob (labels are in the notification bar).

I evaluated the test drives based on three criteria - none of which is speed to first fix, which is unimportant to me as long as it is under a minute (all were):

1) Crispness - when I make a turn, I expect the GPS to see it as a turn, and not an arc.

2) Overshoot - the Captivate is known to show that your course has continued for tens/hundreds of feet after you have turned.

3) Overall accuracy - does the GPS place me on roads during the straight portions, or does it look like I'm driving through homes.

Lastly, the first one was recorded using a Bluetooth GPS dongle. In case you want to see the exact route, refer back to this one.

I'll won't bias anything by telling you my conclusions. I wish I could have run longer tests, and multiple tests for each modem/fix, but it was at least 90 minutes and a gallon of gas to do this much. I am shocked at the difference between a GPS receiver and a phone that is actually a bit larger. Samsung could have done better - but we all know that by now.
[Captivate Android Development] CuriousTech:
Yeah, this is a bit reminiscent of soft modems. 1 step forward, 2 steps back, but eventually we'll move several steps forward. I can see a lot of potential. Wouldn't you love to get ahold of the supporting code? :)

Soccer_Dad, you need to lay off the sauce. :p
[Captivate Android Development] askpcguy:
Rrryan what would you think about getting a newer captivate, say a build 10.10 and looking for any software differences?
[Captivate Android Development] Moxie3000:
Is PlumbBob 2.0 Beta only for i9000?

I had flashed PlumbBob V1.0 immediately after flashing Cognition 4.2.2 and fixing the SUPL config. GPS was decent, though not stellar. LBSTest TTFF was around 20-30s. So I flashed PB 2.0 Beta 6 without wiping the GPS data as instructed and it basically broke my GPS. LBSTest was never able to pull more than 3 satellites and it never did give me a TTFF. I downloaded GPS Aids to download LTO to no avail.

I re-flashed PlumbBob 1.0 and now my GPS is even BETTER than the first time I flashed it. I get a TTFF of about 11-12s. I'm guessing that it's the LTO data helping out, but I speak out of ignorance. All I know is that PB 2.0b6 broke GPS, re-flashing back to PB 1.0 fixed it.

So for all that hassle, since I'm on a KB1 modem/kernel, should I NOT have flashed PB 2.0? Reading carefully, it seems that the 2.0 fix is only for i9000 phones.
[Captivate Android Development] rajendra82:
The 2.0 fix is not meant for i9000 phones, but the binaries used in the fix do come from a i9000 Gingerbread leak. It was unstable for me too, but luckily flashing back to 1.0 gets you back to where you were.
[Captivate Android Development] Rrryan2:
Mine's a 1010 and its out-of-box GPS performance sucked so bad I was inspired to begin the research that led to this fix. So if that were the strategy then I would want to look for something newer than 1010 (1012 or even 1101) but as I've said before I don't think build number has much to do with the GPS performance. All the builds are crippled by design compromises and bad configuration, and users of basically all of them report GPS problems.

Frankly though, I think stock gps performance is going to be about the same until we see 2.3 for Captivate (if we ever do). Unlike KB1 Foryo when we were all just had to have faith and hope for GPS to be fixed, if JV1/JVK can be taken as a guide then there is some evidence that Samsung has finally gotten serious about making gps work.

I think there's a faint possibility that configuration/software on models handed out as replacements might be improved, but that's really just unsubstantiated speculation on my part right now.

2.0 is an an attempt to port I9000 Gingerbread gps to Captivate, so no, it's not for I9000 phones. It's just still in beta and has some issues that keep it from working reliably. When it's working, 2.0 works just *great* but I'm having trouble getting stable, consistent performance out of it for all users.

So far as I'm aware there's nothing that would prevent either fix from working on any particular modem/ROM. Some Serendipity users have had issues with 1.0, but for others it works just great. To make things weirder still, I made no promises about CM7 but some users have reported that using 1.0 (KB1 Froyo based) on CM7 (AOSP Gingerbread based) works wonderfully. Go figure.

As for the difference in results you were seeing after re-flashing 1.0, there's a simple explanation. Since you didn't wipe GPS data it still had the last known fix in memory, so the device was able to achieve a 'warm start' when it figured out it was still close to that location. A 'cold start' with no stored location in memory like when you first flashed 1.0 sometimes takes a little longer.
[Captivate Android Development] CuriousTech:
Yeah, it's a good idea to check it over the next few days and see if it gets worse or not. Flashing 2.0b6 then 1.0 leaves any additional files as well. So you get the LTO stuff with KB1 binaries. I think I tried that and it didn't do anything.
[Captivate Android Development] Kenn Lynch:
Must be Wonderful for you........???????

were you planning on sharing any of your customizations?

or did I miss that part?
[Captivate Android Development] kodos96:
Hmmm... I wasn't aware of that. My copy of this file isn't getting updated, despite the fact that my lto.dat IS getting updated... both files originally had the funky permissions, but I set them both to 770, but only lto.dat gets updated. Any ideas why that might be?
[Captivate Android Development] CuriousTech:
Excelent observation really. I've noticed the same. Wait, South Carolina? I've seen 10/10 and almost nothing depending on which sats are in the sky at the time. Some are older, some newer and probably have different signal strengths. We normally don't give that any thought except in this instance. Given different atmospheric conditions, and few weaker SVs and it won't fix at all. It makes me wonder if some reports are coincidentally at in/opportune times, including my own.
[Captivate Android Development] movrshakr:
I've seen 11/11 drop to 5/5 instantly. I don't think geometry changes that fast.
[Captivate Android Development] CuriousTech:
It's possible. Those birds are flying at 6563 mph... roughly.

:)
[Captivate Android Development] Liv33viL:
Yes - It certainly is !!!

Yes.

Yes. [Hint] Perhaps you should read the post again, I'm certain you'll find the answer there...

Peace-
[Captivate Android Development] Liv33viL:
I hear ya CT,

Just taking a quick break and thought I'd do a fly by.

When I get a lock / fix, it's usually pretty solid, whereas I've seen readings that fluctuate from 0 birds to 7 and 8 and back down and up again like a sliding scale.

I'll most like do a fly by later this evening... gotta get back to work...

Peace-
[Captivate Android Development] askpcguy:
Has anyone watched the SNR in GPS Test, specifically the levels moving up and down? I'll see a channel which was tracked jump to a low number and stop being tracked. Things will repeat like that but overall, the GPS lock will persist.

Rrryan, oh well was worth asking about the build dates. To this date, I am still on cog 4.2.1, overstock 1.1 and no gps changes except the supl.google.com server and standalone operation. The only problem I notice is often while driving (highway speeds or city speeds) turning will cause the gps tracking to go crazy leading to the mapping app trying to re-route you.
[Captivate Android Development] movrshakr:
Immaterial. The angular change from your position on the surface is not rapid.
[Captivate Android Development] CuriousTech:
True, but my point was more about patience. Some may get no fix but if they tried later they may, or the opposite. Just like the users who say "I flashed this ROM 15 minutes ago and my battery is lasting only 4 hours." WTH? We know to ignore that, but it's kind of the same deal with feedback on this as well.

The point to Ryan's fix is to make lemonaid from a lemon. ;) We all know there will be drastic signal fluctuations from interference or whatever it is. Statistically it's basements, but really try it every few hours and you'll get different results.
[Captivate Android Development] BillShepp:
My warranty replacement is build 1102 and the GPS has worked flawlessly, without any GPS fixes. I've flashed with Cognition 4.3, however, so there's no reason to think my software is any different than the software in other builds which are running Cognition (other than perhaps firmware in the phone which can't be user-updated).

- Bill
[Captivate Android Development] Rrryan2:
Could be any number of things. Interference (either in local environment or even inside the case) is probably a likely culprit.

That's the biggest problem this fix is trying to solve. Many previous efforts have managed great initital TTFF, but poor mobile tracking was previously the norm. Cog 4.0+ in particular is typically reported to have great results with 1.0 and I'd recommend you try it out. Not to be snotty, that's just pretty much the focus of this entire thread and I can't quite help you very much otherwise.
[Captivate Android Development] Rrryan2:
v2.0b BETA 10 UPDATE 4/5/2011

Beta 5-9 were not all publicly released and basically turned out to use a mistaken strategy attempting to get lto.dat (Long Term Orbit AGPS data) downloading and updating properly.

Changelog:

Beta 10

- rollback to Beta4 and resumed development. Forcing the lto.dat and modifying its permissions turned out to not be too helpful or necessary

- minor modifications to install script and gps.xml

Updated installation instructions:

1. Use LbsTestMode to delete GPS data before flashing.

2. Flash the fix.

3. If you're not in the USA, use the Faster Fix app from the market to customize your NTP settings.

4. If you can't get a GPS fix, check to see if lto.dat and ltostatus.txt are present in /data/gps/. If they're not there, simply reboot.

It turns out that lto.dat just simply doesn't download at boot all the time for some reason, even if you have a solid data connection. Inserting a copy of lto.dat and modifying its permissions turned out to be unnecessary since simply rebooting fixes it pretty much all the time. Go figure.

Since initial testing reports have been very positive, subject to testing reports Beta 10 will likely be final beta or close to it for 2.0.

MD5: 2edd60ff2daf09d7a6e3027435874170
[Captivate Android Development] Rrryan2:
That's one of things that really makes troubleshooting these things such a pain. Ceteris paribus basically never applies and no two tests are really ever completely the same, so it's hard to tell what's causing variation flash to flash and day to day.

My previous speculation was that the software on stock replacement units *might* be a little different from the OTA software. If you've flashed anything else over it since then, there's no way of knowing what was on there previously. In any case some replacement units still have GPS problems too, so it's probably not worth expending too much brainpower on trying to find out.
[Captivate Android Development] max_82:
I don't know why after I flashed v1.0 my GPS lock time is longer than before. My previous fix is 0.8.4b. I'm using overstock kernel v1.3 and KB1 modem. Should I flashed the latest version? Thank you for your help.
[Captivate Android Development] Liv33viL:
Decisions...Decisions...

Care to Clarify?

Your lock time is longer or your fix time takes longer?

You need to advise on what you are currently flashing from (with details) and what your device has loaded currently. I can't be sure from your post if it is 1.0 or 8.4b.

If your fix time is taking a bit longer (which is what I believe you are referring to)

Wipe the GPS data from within LBSTestMode or any method you prefer, then reboot into recovery mode and wipe the dalvik cache. After the final boot flash the 1.0 (whatever your region is) and configure your settings accordingly.

Reboot the device after the settings are plugged in, enable sensory aiding and WiFi then perform a data push or data assist (forcing data to load without having it called upon to load).

Then from LBSTM - run a series of Hot Start tests to prime the data.

Now go check you fix times.

Although stated that 2.0B10 will most likely be close to the final beta before the RC - IMO - stick with what you know already works and then build from there.

This should help out with your situation.

HtH

Peace-
[Captivate Android Development] Harveythedog:
Seems to work OK here so far flashing from Beta6.

30 second TTFL, and only a few seconds to lock starting the gps after that.