yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] Harveythedog:
Something still a little flaky is going on with the lto.dat. I updated mine with GPS aids (since it didn't seem to be updating automatically), after that the GPS seems not to be using it? Even tried changing file permissions but no luck.
[Captivate Android Development] crazililazn:
Well do LTO files only break AGPS? or does it actually break the GPS as well? Because with earlier fixes, even with airplane mode on, I could get a GPS lock.
[Captivate Android Development] Harveythedog:
My experience without a lto.dat (beta 6) is that the GPS will take a good 5 or even 10 minutes to lock and will have trouble locating/tracking birds with a weaker signal. It's easy in this situation to conclude it's just broken.
[Captivate Android Development] Liv33viL:
No Files.... Still... No Files

Anything is possible, but in this case I would suspect it would be highly unlikely.

Let me ask - what application are you using to view your "rooted" directories with?

Just and FYI - some file explorers do not reveal "all" data that exists on the device.

Is your device currently Temp Rooted, Full Rooted or a Nand Rooted?

The more imformation you provide, the easier it will be to isolate the issue your device is experiencing.

Prior to performing the below - reboot into recovery, wipe the dalvik cache (again) and if you have a good cache cleaner installed - run that as well.

Try flashing the 1.0 - if the first flash doesn't take - flash again. You may need to flash a few times for a result.

If it doesn't take, I was going to recommend copying and pasting the both files directly to the file path /data/gps - but if the file files fail to create initially, the odds of the files collecting any data is null.

If this doesn't work - try downloading a fresh copy of the file you are trying to flash - delete the existing one (don'y overwrite the file) on your SD card and copy the new file to flash.

See how it goes...

Peace-
[Captivate Android Development] CuriousTech:
No trouble with airplane mode. 4s? Okay, that was odd but it works a lot better at night. Actually I'm somewhat serious about that. My lto.dat is still 5-Apr-11 though.
[Captivate Android Development] kevria:
It took awhile for mine to get a lock and then it dropped down through accuracies of 200, 100, 50, 30, 10.
[Captivate Android Development] WirelessMike:
Worked for me!

I had just flashed the full firefly 2.7 rom and the speedmod k13d kernel, then the ugkc1 modem. I was getting locks quick enough, and they narrowed down pretty quickly, too. Trouble was it was typically about 50' off my actual location, even when it reported it was within 16'.

I thought it might be google maps, so I cleared the cache for that app. I also cleared cache and dalvik in recovery before reboot. Still couldn't get very close to my actual, physical location, so I tried the older ugjk4 modem, which had been pretty good for me. Now the locks were slower, it almost never got down to 16', and it was STILL a good ways off my location, even after clearing the maps cache again.

So I figure, heck, it can't get much worse without simply not working, so why not try one of these fixes?

I followed the instructions carefully, making the appropriate edits in SUPL settings and clearing gps cache. I also cleared maps cached again. Then I flashed your fix.

It took a little longer to lock (I did go back to ugkc1, by the way) the first few times, but the more I used it, the more accurate it got.

Now my gps is typically about 6' off me within just 10 to 15 seconds!

I really wish it worked this well for everyone, because this is the best my gps has ever been-- standing still or on the move.
[Captivate Android Development] akuru:
Thanks again for your help, got the files under /data/gps after clearing cache and dalvik first then downloading through GPS Aids, as both you and kevria advised. Except, my first try with GPS aids successfully downloaded the lto.dat and ltostatus.txt, didn't need a second try.

Considering it might be useful for other members experiencing similar issues, I still want to answer your questions for further clarification of the matter:

I'm using terminal emulator to list the contents of /data/gps. Executing a "#ls -a -l" command, which should list all files and directories, including hidden ones.

I don't know what exactly "Temp Rooted", "Full Rooted" or "Nand Rooted" means, but I'm using Darky's v9.5, which comes rooted.

I was using PlumbBob's v1.0 prior v2.0. I installed v2.0b4 onto that first, then upgraded to v2.0b10.

Manually downloading the lto.dat and putting it under /data/gps didn't really helped me on getting quicker fixes, was still taking 30+ (sometimes 60+) seconds for the first fix.

Lastly, I haven't tried my GPS after GPS Aids downloaded the lto.dat yet, will try it tomorrow and inform you about the results. Hope it works this time :)
[Captivate Android Development] Rrryan2:
Good to hear - which version did you flash, 1.0 or 2.0b?
[Captivate Android Development] kevria:
One thing I am still noticing is that my gps frequently loses its lock but it could just be my location.
[Captivate Android Development] msmalin1984:
I'm running Cognition 4.3 and was getting absolutely no lock whatsoever. I installed PlumbBob 1.0 and it got a lock, but took a little while. Cognition 4.3 causes my device to freeze (even before installing PlumbBob 1.0), so after some research I found ExistZ's KB1 kernel fixes the freezing, so I flashed it onto my device. Now I'm getting GPS fixes within 15 seconds or less.
[Captivate Android Development] Rrryan2:
v2.0b BETA 11 UPDATE 4/9/2011

Changelog:

Beta 11

- adjustments to secgps.conf and changed permissions for secgps.conf from 0644 to 0775 (thanks to ondoteam for these)

- updated install script to use Edify for CM7 compatibility

- modified permissions to init.d script

Again, beta versions are optimized for USA so if you need a different region use the Faster Fix app from the market to customize NTP settings.

Also, if you're still having trouble getting locks and/or LTO updates, try clearing the Dalvik cache and/or the /cache/ partition and rebooting.

Updated installation instructions:

1. Use LbsTestMode to delete GPS data before flashing and perform settings as described in the OP.

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 to recovery, clear Dalvik cache, and reboot.

MD5: a69de2a81aade21e1bbbdb1aa1752b61
[Captivate Android Development] askpcguy:
Whether or not the GPS obtains a fix in seconds is only one front to measure the Captivate's GPS performance.

I can usually see a GPS fix in car, while driving in a minute. The problem I continually see is the gps position cursor being lost while making a turn. This causes google maps to reroute at least twice, and ends up in a turn being missed.

I still would like to see any differences in Google Maps while using driving directions. As well as if the circle around the GPS cusor stays small or does it bounce between large/medium and small?

** And I need to find Bob also, something about back taxes =)
[Captivate Android Development] Rrryan2:
Again - yes, tracking in Google Maps Navigation is improved over stock. 'Blue Circle' (accuracy) problems are greatly reduced but will never go away completely without redesigning the antenna. "Ghosting" problems while turning have almost completely gone away and occur only rarely for me now.
[Captivate Android Development] Rrryan2:
There's generally less interference and the ionosphere changes at night to give conditions that are generally more conducive to GPS. See http://www.loran.org/Meetings/Meeting2008/Papers/Filjar_8A4.pdf for way more than you wanted to know.

EDIT: Also, I've noticed that 2.0 benefits greatly in a hot start if a fix has been attained recently. If you can get a fix, turn off GPS, wait a little, and then start GPS again TTFF <5s are not uncommon, and I've had 2s and even 1s hot start fixes.

I think I found and fixed (in Beta 11) a problem with the LTO updating. The user script in /etc/init.d apparently defaults to non-executable permissions on many systems. Permissions are now set to 0755 and I'm getting a fresh LTO with every boot now, which is actually more often than I would have expected and would really prefer but it sure won't hurt GPS any. And it's only like a 40k footprint anyway.
[Captivate Android Development] Rrryan2:
v1.1 BETA 1 UPDATE 4/9/2011

Since some users still aren't comfortable using v2.0b and seem to prefer a stable, tried-and-true 'native' Froyo-based approach like that of v1.0, I decided 1.0 could stand an update even if it's only a minor one.

Changelog

1.1 Beta 1

- added the 'mystery binaries' in /system/bin/gpsd. I don't know what they do and they never seem to change, but since they're even still included in JVK leak maybe they're doing something

- minor tweaks to secgps.conf

- changed install method to Edify to allow easier installation on CM7

Re: the 'mystery binaries': these are the mysterious .0 files that are in /system/bin/gpsd. I don't know what they are or what they do. They never get written or updated, and things seem to work just fine without them. But as noted above as they're still contained in the the JVK Gingerbread update so I'm giving Samsung the benefit of the doubt and folding them in to 1.1.

If anyone has any idea what these files are or what they do I'd be very grateful for some clarification.

Edit: Apparently they're Uuencoded SSL certificates.

Re: Edify and CM7 support: I've personally decided not to play with CM7 until it's more stable just because my dev phone is also my daily driver and I need reliable stability. And this fix is still *not* developed with CM7 in mind and does not officially support CM7. And indeed the wisdom of applying a Froyo-based fix onto a Gingerbread base is perhaps questionable. However, some users have reported substantial improvement to CM7 GPS performance using 1.0 and since modifying the install script to support CM7 and Gingerbread kernels was a fairly trivial matter I went ahead and did it.

Feedback reports in the thread are always greatly appreciated, but please be sure to specify what version you installed. :)

And as always you're welcome to join the discussion on irc.freenode.net #plumbBob.

Installation Instructions:

Same as for 1.0 in the OP. However, Beta versions are optimized for the USA so if you need a different region please use the Faster Fix app from the market after installing to customize the NTP settings as needed.

MD5: 6aa34180a1ae0fb2c4e9536dd02da519
[Captivate Android Development] askpcguy:
Just flashed the beta 2 update 1_1 and while I am outdoors in my vehicle, I saw a speedy GPS fix.

Stay tuned for an update on Google navigation tracking.

Cog 421 with overstock kernel 1.1
[Captivate Android Development] CuriousTech:
Uuencoded SSL certificates.

I just flashed 1.1b1 and so far so good.

Yesterday I had a couple of instances where I'd start an app and never get a fix, then exit and restart and it gets a <10s fix. That's why think the underpowered thing is only random. As if when it powers up the GPS, something fails randomly. But then I only noticed it recently (2.0 betas), not that I know of with 1.0.

It doesn't seem to need any waiting period though. Just wait a second and try again.
[Captivate Android Development] Liv33viL:
Mystery Binaries

Hey Ryan,

Currently I have not attempted the 2.X on my device, being as I am content with the results I am currently receiving with the v1.0 and some minor mods that I have made, specific to my device.

I have, however, been reading along, the changes and results that those are receiving while having the 2.x installed.

I am a tweak freak by nature and always enjoy finding a better result and a better way to accomplish a process. Being as the results I am receiving on my KB1 are quite favorable with the 1.0 fix, I will be investigating a little further into if this next level of version 1.x is likely to eek out a little more stability, a quicker fix time and overall a more reliable and consistent accuracy.

I have just read this post and haven't had the time yet to unpack and dissect the file structure in the Jupiter XML nor the components therein.

I had a thought. First to at least get a truer perspective on what these binaries are and what these binaries may even be capable of doing... one must first know the origin of the JVK leak. (The following is rhetorical - but worthy of exploring) Was this a direct JVK leak from Samsung? - Was it leaked from a Samsung developer who may have been experimenting with porting and implementing this aspect from a 2.2 to a 2.2.1, 2.2.3, 2.3 etc...?

Was this leak a virgin when it became available?

Just a few questions to ask to at least get a proper perspective on where to start looking to retrieve a viable answer.

Another thought... it is possible that these binaries were kept in, added in or additionally added in to allow for a less mature file system to support some framework, file structure and applications written for a more mature file structure.... again, I'm just thinking out loud.

If / When I find some solid or post worthy information on this.... I'll be layin' it down in the thread.

Now - It's simply a fantastic day out today -

Goin' to go get some sun on ... :)

Peace-
[Captivate Android Development] Rrryan2:
Doh. Something that simple?

I guess I need not have bothered then, but anyway...

Never seen that happen yet, and no other reports so far. At least it can be gotten around quickly.
[Captivate Android Development] Rrryan2:
As CuriousTech said, they're Uuencoded SSL certificates used for the SUPL connection.

As to the source of the JVK leak, I haven't seen anything definitive about the source but it's presumed to be a Samsung product. Frankly though I've had my doubts that many of these very, very many 'leaks' are not inadvertent.
[Captivate Android Development] DarkDvr:
V2.0 beta 11:

AT&T Captivate

Latest Cognition (as of today), brand new fresh install (with Stock ROM flash)

Installed v2.0 beta11 - no lock.

Followed instructions, cleared all cache, cleared Dalvik cache.

Clear blue sky, around 6pm. USA, CA.

Been driving today - first lock in about 35 minutes (thirty five). Tracked for several seconds, lost signal.

Driving back from home - lock in about 15 minutes, terrible tracking, kept losing signal.

v2.0 is absolutely unusable, even worse then stock Cappy.
[Captivate Android Development] WirelessMike:
I flashed 1.0

I tested it twice while I was out and about today. It tagged me in the very parking spots I was parked in.

:D
[Captivate Android Development] Rrryan2:
Not sure how it is you're arriving at such a bold conclusion. With more than 160 downloads and counting of Beta 11 and exactly one problem report so far -- yours -- it would seem to me that calling 2.0 "absolutely unusable" might be at least a little bit of stretch.

I'm developing 2.0 on more or less the same platform and it works splendidly for me and plenty of other Cog users so it's quite possible you got a bad download and/or flash of either Cognition or 2.0. Recommend that you re-download 2.0, check the MD5 checksum, re-flash, and wipe Dalvik.
[Captivate Android Development] Harveythedog:
Hmmm, I still can't automagically get a lto.dat or ltostatus.txt even after clearing the dalvik and rebooting to the utmost?

Could the script be timing out grabbing the lto.dat due to me using a non-AT&T network (Telstra)? My Captivate might take longer to connect/get a data connection, looking for a non-existent AT&T first, then connecting to Telstra?

Actually it's working surprisingly well without, especially after an initial fix.
[Captivate Android Development] Rrryan2:
Weird. A few testers were having problems getting it to go too which were solved by doing a clean wipe, master clear and doing a fresh ROM install.

No. The script only triggers the daemon, which uses the same data connection as everything else. As long as you'ge got data (either WiFi or APN) it should work fine. It doesn't actually look for AT&T-anything, and 2.0 is in fact ported from JV1/JVK which are I9000 (non-AT&T) builds and have nothing to do with AT&T either.

I've noticed too that performance on 2.0 is surprisingly good even without LTO, but it's still quite a bit better with it.
[Captivate Android Development] askpcguy:
Here's my initial observation from using v2.0 beta-11 on Cog 4.2.1, overstock v1.1 kernel.

I deleted the GPS data, boot to recovery, wipe dalvik cache and finally flashed the fix. Allowed to boot up, I didn't touch the gps functions for a good 4 hours.

Indoors lock required wifi to be on, not connected. But I did see a lock indoors, close to a window.

During my drive from a job site back home, with wifi off, I experienced the most amazing gps location tracking in Google Maps to date. Not one re-route, gps cursor followed each turn and even when stopped at a cross-street, the cursor was dead center on. Normally I'd see the gps cursor slide forward a tiny bit.

Now, the twist. I'm still operating (in lbstestmode) as Standalone, accuracy is 90 and my SUPL secure socket is OFF.

Next to test is an extended drive, possibly including heavy city driving. Maybe even some downtown LARGE buildings to see if the gps tracking can keep up.

Question: Would providing My Tracks results be more helpful? I've got my external GPS receiver that I can use as a baseline.
[Captivate Android Development] Rrryan2:
v1.1 RC 1 UPDATE 4/10/2011

Again, since some users still aren't comfortable using v2.0b and the trickery it requires to make Gingerbread GPS backward-compatible to Froyo and seem to prefer a stable, tried-and-true 'native' Froyo-based approach like that of v1.0, I decided 1.0 could stand some updating.

RC1 includes some additional changes. 1.0 originally used a KB1 base since it (foolishly) seemed to me at the time that KB1 might offer the best compatibility and optimum experience on a Captivate. This turned out to not really be the case, as it seems AT&T held up UCKB1 so long that it was relatively outdated by the time it dropped. plumbBob v1.1 RC1 uses JS8 (i9000 2.2.1) base files instead.

This hopefully will also help with compatibility issues on JSx ROMs that were having sporadic problems with 1.0 like Serendipity 6.x.

Changelog

1.1 Beta 1

- added Uuencoded SSL certificates (xxx.0 files) in /system/bin/gpsd

- minor tweaks to secgps.conf

- changed install method to Edify to allow easier installation on CM7

RC1

- updated daemon and libraries from JS8 release

- added /data/gps/plumbBob_version.txt for clarification

Re: Edify and CM7 support: I've personally decided not to play with CM7 until it's more stable just because my dev phone is also my daily driver and I need reliable stability and all the features. And this fix is still *not* developed with CM7 in mind and does not officially support CM7. And indeed the wisdom of applying a Froyo-based fix onto a Gingerbread base is perhaps questionable. However, some users have reported substantial improvement to CM7 GPS performance using 1.0 and since modifying the install script to support CM7 and Gingerbread kernels was a fairly trivial matter I went ahead and did it.

Feedback reports in the thread are always greatly appreciated, but please be sure to specify what version you installed.

And as always you're welcome to join the discussion on irc.freenode.net #plumbBob.

Installation Instructions:

Same as for 1.0 in the OP. However, Beta versions are optimized for the USA so if you need a different region please use the Faster Fix app from the market after installing to customize the NTP settings as needed.

1.1RC1 Withdrawn, further update pending
[Captivate Android Development] Rrryan2:
Lol. You didn't follow directions but want to complain about the results anyway? But I guess at least you finally bit the bullet and applied a fix. :)

The WiFi issue is more than likely a red herring. In standalone mode AGPS data isn't (necessarily) downloaded or applied so the unit was having trouble getting a standalone fix indoors. After a while (usually under a min or so) and near a window it was likely just finally able to get enough usable ephemerides downloaded over the satellite signal to get a good fix. That this occurred after Wifi was enabled is probably just coincidence, though SUPL does use Wifi networks with known locations to help get an approximate additional position which might have also helped.

Turning secure SUPL off doesn't really impact performance much and is more for security/privacy reasons. With it off your location is sent unencrypted over the internet. It's not a big deal performance-wise though as long as the proper certificates are present to allow it to work. I recommend it be turned on.

And I agree, mobile tracking in 2.0 is the best I've seen on the Captivate, which is why I've continued to put so much effort into developing it vs. 1.0. When 2.0 works, it works GREAT.

Mytracks examples against an external receiver might be interesting to see and might help convince other holdouts, but don't spend too much effort at it. In reality, with closed source drivers it's another one of those things where there's probably not much that can be done even if any problems were identified.

What would be more helpful is if you gave feedback that followed directions, as a lot of thought and testing is behind them. Otherwise the results are just anecdotal. :)
[Captivate Android Development] askpcguy:
Whoops did not intend to give the impression my results was a complaint.

App: yaffs explorer, free.
[Captivate Android Development] CuriousTech:
1.1 RC1 has problems. It's like an older version where the GPS stops after 1 second (GPS icon goes off) and never turns on again. Turning GPS off and back on can get it to turn on again for 1 second.

1.1b1 appears to work the same as 1.0 except lto.dat updates on reboot. Same higher signals but jumpy and losing fix, getting fix, losing it if it's right at that (wide) threshold. But then it doesn't have the problem of not starting right sometimes that I see with 2.0.
[Captivate Android Development] Kenn Lynch:
Hi

I pretty much have to concur your results

V1.1 RC1 seemed a total bust here, no lock or anything but I might have missed the initial icon before it dissappeared as you described.

I re-re-installed 1.1b1 and am also having new stability problems. on start up icon consistantly moves to a location about 1/2 mile away (very possibly a tower?) and if its feeling inclined to do so it will swing back to very near my current location or back to the mysterous "tower" (Sauron?)

I must thank (and I did) Askpcguy for identifying and posting the name of

the free App: "yaffs explorer". That actually worked and allowed me

to see my data/gps directory (I was going nuts with 4 other file managers)

Using PB Ver 1.1b1 with Cognition 4.2 with 4.3 kernel update (been 98% stable)

using all the recommended settings in the OP

A reboot does update the (gldata.sto, libsdata.sto and ics.socket) files to

the approx time and date of the reboot.

Apparently secgps.conf dated 2008-08-01 05:00am?? is not new or refreshed?

(lto.dat, ltostatus.txt and glgpsctrl) appear to be dated about the time of my last Plumbbob install (earlier today) and are not refreshed at re-boot

Are the "protection" of these files still an issue or of interest?

Much thanks for all the work, time and dedication here

How can I help? Anything we can test for you?

At this point I'm going to try going back to 1.0 and re-group

my understanding of whats working with 1.0 and see if I can

determine why/if I need to upgrade it to any of the the later versions

(not clear enough on the long range effects of the stale update data)

KJL

BTW

1) accuracy is currently set for 40 in the params should we try small

tweaks (there was some talk of moving it back to 50) was that ever

resolved?

2) Should we now always wipe the "dalvik cache" along with clearing GPS data

when we install a new release? (if so, be a good idea to update the OP)

Thanks again