yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] askpcguy:
Kenn are you using the most recent plumb Bob GPS fix?

I believe its version 2 beta-11.

A majority of the time I use GPS with wifi off.

Only reason I find to enable wifi is to get a GPS lock indoors where it definately helps.

Also what operation mode are you using?
[Captivate Android Development] Kenn Lynch:
Hey Guy!

No I'm not, it seemed to me

the 2.0 versions all both had initial inaccuracy or quickly lost it

I had the feeling the gldata.sto and lbsdata.sto files were not being updated as I believe Ryan also suspected because most all of the 2.0s seemed to degrade with time.

Till you pointed out the yaffs explorer (Thanks again bro) I had no way to

confirm deny or provide any feedback. (nothing I tried found those files)

Right now I'm kinda old school and trying to keep everything as close to the developers description (troubleshooting sanity) So I am running 1.0 (again)

and as suggested with wifi enabled and all the LBStestmode params as

described. I'm trying to get a baseline before I try mods because I was simply losing track of what was installed for my own self, let alone trying to describe my situation and symptoms to anyone else <BG>

I'm surprised you run with Wifi disabled? it's supposed to be used during the

initial fix to ball park to the area of the tower (a known general lat longs)

Mine does seem to do this and if Sat data is good, it attempts to locate me

more accurately. For whatever reason I believe it often loses the Sat fix and

then drops back to the local tower.

What I'd also like to understand is the interplay between GPS-Status

clear and reset are these referring the files in data/gps ?

Are they being used by Google maps? Any way to manually force update of

data in Googlemaps

Plumbbob has already come along way I just hope the developer can get us

over this "last" hurdle which seems to me to be getting proper updates and maybe improving accuracy but that may not be possible with the Samsung antenna.

I used to run an HTC Diamond it also needed to preload "emphemeris" data

but once locked it held on to it. I could easily tell which room in the house I was presently walking in,

On the cappy there is a longer initial fix and lot of jumping rotating etc if you watch with GPS-Status you can see the speed change with the unit not moving

(I must admit that Then was in NY area now I'm testing in Tucson AZ)

I will probably try V2.0 b11 again but it was I believe a bust for me last time.

Need a installation check list for each new release

at least we'd all be on the same page.

I'm still not clear on the Cache wipe or the accuracy setting?

Thanks Again

will post anything new as I retry the latest versions

KJL
[Captivate Android Development] askpcguy:
Being honest, I never really bothered to look in /data/gps at all before this GPS fix, so I basically leave those files alone (present or not).

I've almost never left wifi enabled, unless I was at home, even when out driving around using the GPS. I simply will not accept Samsung released a device with internal GPS that is effectively a two-phase system. First is the wireless/cellular networks location then second is the GPS precise location.

Regarding the app GPS-Status, here's a link with some good information here I've also never messed around with that too much. Often I'll use LbsTestMode to delete GPS Data, and I've seen when attached to a debugger the GPS calculations start off with a location of 0.0.

I look at it this way, the cache GPS data is your location. If you enter a building, then return outdoors, the GPS will use the hot/warm start which means your last known location. Getting a location this way takes seconds. I am sad to see that I've not seen this behavior consistantly. If I switch between GPS aware apps, I'll find the second or third app will take 2-3 minutes to get a GPS location.

However, the GPS assistance data (which is the satellite orbit data, valid only 3-5 days) is cached and can shorten the math calculations needed to obtain your precise location. Clearing this will force the GPS system to re-download it from the Internet (using GPS Status) and can help with the initial GPS location fix.

Lastly, the dalvik cache is best explained here
[Captivate Android Development] Rrryan2:
No. Pretty much zero percent of the above is anything close to correct. I got so fed up trying to even come up with a response to this that I decided to spend my evening doing something non-GPS related for the first time in a while.

You can refuse to accept if you choose I guess; you can remain as ignorant as you choose. But an MS-Based strategy (cell towers for coarse position estimate, GPS for precision location) is actually quite common in mobile phones and has been used for years. It's more or less exactly what SUPL does for you. If you don't want to even Google it...

GPS Status actually doesn't actually do a great job of downloading AGPS data on the SGS (and Captivate in particular), something that you might know if you actually looked in the /data/gps/ folder that you've decided to refuse to look in. GPS Status is more focused on XTRA data (4 hour validity period), which is not used in the Captivate implementation and is redundant if LTO (4 day validity) is present anyway.

LTO contains information about the ephemeris (orbits) of the satellites. It has nothing at all to do with "shortening math calculations." On a 1GHz processor all necessary calculations can be performed basically instantaneously. LTO has much more to do with the receiver's attempt to sort out the weak satellite signals from background noise, which is what takes up 99.99% of the time needed to acquire a fix.

You can't just up and decide to make up your own arbitrary GPS mythology and then expect your phone to start believing in it. Read the links on the front page for actual facts about GPS implementations in mobile phones.
[Captivate Android Development] CuriousTech:
Ooh, I like yet another fu... yaffs explorer. I wanted something with more files on the screen.

I finally got 2.0b11 on the phone and haven't seen the usual 2.0 issues yet. It's working great here. I think it has more echo filtering or something. It's such a huge difference between the two and that jumpy one is what Samsung released for the i897. lol

What would be cool is to have a scheduler that downloads the LTO data every 2 days or so automatically. Android doesn't have anything like that built-in but there's probably an app for that, or do it manually I guess.

But anyway, this one looks promising. Here's to hoping it keeps going.
[Captivate Android Development] Rrryan2:
That's about the size of it. When 2.0 works, it works great. I don't know whether it's multipath filtering or what, and I guess we might never know.

LTO refresh is set in gps.xml to automatically update after 1 day (the default is 3 but I tweaked it) but inexplicably I get it at each boot for some reason. I haven't gone a day yet without having to reboot so I don't know, but as yet I have no reason to suspect it wouldn't auto-update. The footprint is pretty small though (~40k) so it's not like it's going to kill your data plan.

There is an app for that - GPS Aids - but results with it on Captivate have been decidedly mixed. It works for some, but in other instances it seems to totally bork GPS until a new ROM is flashed. I don't remember if it has scheduling, but if you really wanted to you could set a Tasker job I guess. Or, if you really knew what you were doing you could set a tasker job to d/l LTO on your own, but I expect both are unnecessary.
[Captivate Android Development] askpcguy:
Thank for you for the harsh words.
[Captivate Android Development] kevria:
I am on beta2-11 and according to ADB my LTO files are dated 4/6 from when I first got them to download via GPS Aids. My phone has been rebooted a few times since 4/6.
[Captivate Android Development] tpadela:
i have the same problem. i followed the instructions for beta2-11 and it did not download lto or ltostatus. i then wiped dalvik and cache partition and still no lto or ltostatus. i tried to run google maps... could not get a lock.. and still no lto or ltostatus.

however, gldata updates itself but lbsdata and secgps dont. lbsdata and secgps are dated as march 23, 2011 (when i installed Cognition) and july 31, 2008 respectively.. july 2008 doesnt make sense to me... i got my phone last summer in September 2010...

force LTO update works with gpsaids...

after force LTO update i get my first lock in 30 sec indoor with 30m accuracy

hot start still takes 30sec for lock.

more info:

running Cognition 4.2.2

existz beta 8 kernel

build date: 1007

plumbob beta2-11
[Captivate Android Development] wgarrido:
After lots of messing around I haven't had much luck. I just got back from a road trip so I was able to try various things.

Originally

Cog 4.3 / existz

flashed back and forth with 1.0 and 2.0beta11 seems like I could only get /data/gps files to download on 1.0 not on 2.0beta11

Seems like the more I messed with it the worse it got. I tired flashing 1.0 leaving the /data/gps files and then flashing 2.0b11 still didn't work.

So today I odin and reflashed cog4.3 with overstock(more about that in a sec.) first time i have flashed back to stock since the first ROM flash to Cog 2.3b8.

What is really gets me is I worked on my friends Captivate this weekend and got different results. He had a 1007 stock with 2.2. I did odin and flashed Cog4.3 and overstock. His GPS locked so fast I was like OMG! The /data/gps files where there and everything. He was able to launch the camera and take a picture and it locked before he even took the picture. I didn't get a chance to drive around but still. I did run GPS Aids for a second to launch lbstestmode to clear data to flash 2.0b11.

So I decided to do the same process, of course it didn't work the same for me!

The files won't just won't download on 2.0b11.

So should I try warranty and get another Captivate? I hate getting someone else's left overs and mine is from launch day. (I get attached).

He is on his 4th phone because it kept getting too hot to touch.

Edit: Cleared cache / Dalvik many many times. Only way I could get files to download was in GPS Aids, first option Reset/Download LTO, but still getting get usable results.

Edit: I went ahead and did the manually LTO download again in GPS Aids and was able to get a lock after awhile. I will see how it is later on. If it worked with having to do the manually download every few days I would be happy with that, lame but it would work. The HTC FUZE was kinda of like that anyway. It was a quickgps app that auto downloads every 6 days.
[Captivate Android Development] wgarrido:
I am having mixed results. Either way if I do lock tracking is off and delayed. I think its time for warranty and there happens to be a device service center near by.

Do you guys think I should do online replacement, so I can try the phone before I send mine back, or in store so I can check the build and make sure they give me a 1100 build?
[Captivate Android Development] Kenn Lynch:
Feedback mostly V1.1b1

Hey

I started to write a rather large post about my experiences with PB v1.1b1

but I decided to hold it until I could get a better understanding of what I'm reporting. Here is the situation thats bothering me (its true for any version))

Good News! V1.1b1 seems to be updating at least 5 of the 7 files found in data/gps and the lto.dat and ltostatus.txt files are being created on launch

But I often see a situation in Google Maps I have not seen in other GPS

that makes me question the choice of words "accuracy" used to describe

our evaluations. Simply stated, I often have situation in Googlemaps where

I see a small 32 ft blue circle that is maybe 200 feet on the map from the

actual physical location of the device.

With other phones on Google maps, my phone has alway been somewhere

within the circle, but not always at the central arrow. The way I always interpretted the circle and icon was the central icon was where the phone

was calculated to most likely be, and the blue disk was the range of possible error

What doesn't make sense to me is as said earlier

"32 ft blue disk that is maybe 200 feet on the map from the actual physical location of the device."

My guess is the blue circle is reduced to a smaller tighter 32 ft because calculations from several strong Sats corroborated each other and so accuracy is assumed to be higher. But if they are all similarly and strongly incorrect that would seem to point to stale time, lto or ephemeris data?

So its a strong calculation (many strong fixes shrinks circle) but if its based on stale data it will be centered on the wrong location

Believe me I'm just guesstimating here but small circle far from the actual location has me very bothered (reminds me of precision vs accuracy lectures)

But I've never seen (noticed?) this to be the case with Google Maps or other GPS systems?

Appreciate any input

Its hard to provide useful feedback without

agreement on basic terminology and test methods

What do we mean by "the latest Plumbbob is pretty accurate"?

Be glad to give more specific details in a followup

Hope this is of help to someone

KJL
[Captivate Android Development] nappent:
I live in a city that has a elevation of 120 feet but my phone (LbsTestMode) is saying I'm at 475 meters (1476 feet). That is using fix 1.0. I just thought that was interesting to see.
[Captivate Android Development] D12AKO:
Testing PlumbBob GPS Fix v2.0 Beta #11

Ok, I just installed Beta #11 over #10 and so far so good. My LTO Files are still updating. I made sure to delete them prior to install and they once again were updated after Beta #11 install.

On initial testing, standing in front of my house as usual, I got locks on all the birds I expected but noticed that my error was fluctuating between 10m and 30m. Before with v1.0 it would stay closer to 10m and on occasions even 5m.

However on a Plus note, I did notice that the birds seem to have a higher signal strength than before and most seem to stay locked compared to before.

I will have to take it for a few trips on my Jeep to see how it tracks both on City and highway. Will give yah more feedback as soon as i take it for a spin.

Later...:D
[Captivate Android Development] Rrryan2:
I'm sure it was like that before applying 1.0 GPS itself (in the civil band especially) is not good at fixing altitude for a number of reasons. And not only that, but GPS is attempting to snap your location to the WGS84 reference ellipsoid, which is an attempt to approximate a globe-shaped earth on a flat map datum.

WAAS gorund-based augmentations to GPS can help substantially, but although the chip is capable of it Samsung's drivers don't make use of it and there's nothing I can do about it.
[Captivate Android Development] Rrryan2:
Day-to-day test variances can vary considerably anyway as there are so many constantly changing variables like weather conditions, interference, and the location/range/angle to the various satellites. And that's before we even start factoring in all the hardware oddities and even things like the way you're holding the device.

I've noticed on 2.0 that a cold start is often a few seconds slower than 1.0, but SNRs are generally higher and more stable. 2.0 is slower to come down to 5-10m accuracy but generally fluctuates less once it does. Mobile tracking is also greatly improved, which is really one of the main goals. An ability to get quick one-shot fixes in a known location doesn't do nearly as much to make the GPS useful for navigation as mobile tracking.
[Captivate Android Development] CuriousTech:
I've been using 2.0b11 for the past few days. I'll switch to 1.1b1 if you need more feedback, but right now it's working great. Not once has it failed and the files are updating as far as I can tell so far. The fixes are timely and hold well.

I've never cleared my dalvic on any update, since those are just java classes from akp/jar files. Changing those during a reboot (CWM) can cause it to get out of sync. Any data would be in the main cache.

I'm trying to stay on one long enough to see updates right now. I think I deleted the files once using either GPS Status or GPS Aids (reset data) then the update failed. Of course you don't notice until you look and wonder what happened.
[Captivate Android Development] Rrryan2:
Watch out for false positives: if installed, GPS Aids attempts to download LTO at boot too.
[Captivate Android Development] D12AKO:
GPS Aids = EPIC FAIL for Me <---

Hell, I'd also add to avoid GPS Aids like the plague... In my case, that software always messes up my GPS. I had to uninstall it and do a Clean Install of ROM, Kernel, and GPS Fix to get it back to working condition.

Just my 2 Kilos
[Captivate Android Development] CuriousTech:
Thanks guys. Removing it for now. Hopefully that's not why it's been working.
[Captivate Android Development] movrshakr:
Why in the world are you removing GPS Aids if your GPS was working well?!
[Captivate Android Development] CuriousTech:
Because it's there? :p
[Captivate Android Development] reinbeau:
Probably because, for some of us, it really screwed our GPS, it didn't 'aid' anything.
[Captivate Android Development] movrshakr:
You apparently missed the part where he said his was working fine (as in, NOT 'screwed our GPS'). I wasn't asking why people removed it when their GPS was bad. I asked why someone removed it when their GPS was working fine.
[Captivate Android Development] CuriousTech:
I can always reinstall it. I'd just like to know if it keeps working without help which so far it is. I also do about 2 nandroid backups per week and dump them on the PC, so what could go wrong? :)

I can't wait to see what happens when data is 7 days old.
[Captivate Android Development] kevria:
The only way my lto files get updated is through manual use of gps aids (they dont update on boot). I wonder what GPS aids is doing to host up some peoples GPS.
[Captivate Android Development] kevria:
That takes all of the fun out of beating my head against a wall trying to get this to work reliably.

I did just build a zip file to revert the GPS files back to Serendipty 6's but haven't tried it yet. All I did was look into the Plumbbob 1.0 CWM zip file, figure out what files it overwrites and created a zip with the same files from 6.4 full along with deleting /system/bin/gpsd/supl_att_root.cer that was added.

Edit: Im currently backing my phone up before trying it incase I did something really wrong with it.

Edit2: Finished backing up my phone, ran my reversion update and GPS is actually more accurate, really weird (15meter accuracy in 11 seconds vs normal 100 meter in 20 seconds).
[Captivate Android Development] eliminat:
I flashed Beta 11 on my phone, and while the accuracy was worse than it was before, but the tracking was much better. It never had lost GPS or had to Re-route during my drive.
[Captivate Android Development] Rrryan2:
Getting the onboard GPS is indeed worth it at least to some people. Like those who travel frequently and/or just want to reduce the number of devices they have to carry and charge for instance. And those who just want to have their $600 smartphones actually work like advertised and are out of patience waiting for Samsung to fix it.

Comments like this and those of the goofballs who say things like "Hurr just go buy a Lexus lol" do nothing to actually help address the problem.

You don't have to like my work Mike, but posting comments like this in my thread is not helpful or appreciated. Take it somewhere else please.
[Captivate Android Development] compuguy1088:
(Note: I know the vibrant isn't supported, but this fix has worked in the past)

I followed these steps, and I still do not have a lto.dat or ltostatus.txt in /data/gps/.
[Captivate Android Development] polyrhythmic:
Small bug, I noticed some malformed XML in gps.xml. Line 3:

<!-- plumbBob GPS Fix 2.0 BETA 10 --!>

should be

<!-- plumbBob GPS Fix 2.0 BETA 10 -->

(closing tag should have no exclamation point)

...although android probably ignores the error. Also, it says BETA 10 instead of BETA 11.

also while I was in there, in both gps.xml and gps-ExtLNA.xml:

<!--HAL Confguration -->

(missing the i in configuration -- but now I'm just being pedantic.)

Last, for whatever reason, secgps.conf did not install to anywhere on my system. I had to put it there with adb and set permissions manually.

If anyone needs a JVK modem package that will install via CWM 3+, it's in my sig.

Overall, thanks for the nice work!! I'll test more and post back with results.

EDIT: in launch_gps.sh, line 5:

CONFIGFILE=system/vendor/etc/gps_ExtLNA.xml

Should there be a leading forward-slash in the path? i.e.:

CONFIGFILE=/system/vendor/etc/gps_ExtLNA.xml

EDIT 2:

No LTO files were created at boottime or since. GPS sees many satellites but of course is taking a while to get a lock. Using the LTO files that I had from before I installed PlumbBob fix gets me a lock in under 15 seconds.

EDIT 3:

In updater_script:

run_program("/sbin/mount", "/dev/block/stl9", "/system");
run_program("/sbin/mount", "/dev/block/stl10", "/data");
run_program("/sbin/mount", "/dev/block/stl11", "/cache");

These devices don't exist for CM7/CWM3.

# mount
...
/dev/block/mtdblock2 on /system type yaffs2 (rw,relatime)
/dev/block/mtdblock3 on /cache type yaffs2 (rw,nodev,noatime,nodiratime)
/dev/block/mmcblk0p2 on /data type ext4 (rw,nodev,noatime,nodiratime,barrier=1,data=ordered)
...

EDIT 4:

In updater_script:

set_perm(0, 0, 0755, "/system/bin/gpsd/glgps_samsungjupiter");

should have the J capitalized:

set_perm(0, 0, 0755, "/system/bin/gpsd/glgps_samsungJupiter");

glgps_samsungJupiter will not have executable permissions until this is fixed (or until it is done manually.)
[Captivate Android Development] Rrryan2:
Wow, thanks!

I'll look over them and get an update out in a day or so. Edit#4 in particular could really be gumming things up.
[Captivate Android Development] movrshakr:
Now THAT is what open source is all about! Thanks guys.

Does any of that affect plumbBob 1.0?
[Captivate Android Development] polyrhythmic:
Just found a few more things:

I'm not sure why there are both /system/bin/gpsd and /system/vendor/bin directories that are nearly identical. CM7 only has /system/vendor/bin.

Furthermore, the last line of both /system/bin/gpsd/launch_gps.sh and /system/etc/S_plumbBob_gps is:

exec /system/bin/gpsd -c $CONFIGFILE

That won't work, because /system/bin/gpsd is a directory.

I diff'd /system/bin/gpsd/glgps_samsungJupiter and /system/vendor/bin/gpsd and they are identical. I'm not sure that glgps_samsungJupiter ever gets called by anything.

On the other hand, /system/vendor/bin/launch_gps.sh seems to be written correctly, and uses the same location as CM7. So in addition to the previous fixes I'm going to remove the directory /system/bin/gpsd and change the last line of /system/etc/S_plumbBob_gps to read

exec /system/vendor/bin/gpsd -c $CONFIGFILE

And then do some more testing.

EDIT: Well, now that the scripts are fixed and running, GPS is broken and I have an endless amount of this in logcat:

E/GPS ( 1752): [gps_lcsapi_init][line = 442] : Failed to call BrcmLbs_init(errno = 13)
I/GPS ( 1752): [gps_state_done][line = 293] : successfully called

So, must still need a little work ;)
[Captivate Android Development] kevria:
I think I now know what was meant by this messing serendipity up. Now that I reverted back to the original files although leaving the lbs settings my gps seems much better but ned to test it traveling.
[Captivate Android Development] CuriousTech:
What are the parameters for exec? Is it exec -d directory -c inline_command?

Maybe I'm thinking of another command.

D'oh! gpsd is the command. Got it.
[Captivate Android Development] MikeyMike01:
It has nothing to do with you.

The forum has been at this for almost a year and gotten more or less nowhere. Certainly nowhere near "This is how a GPS should work". At this point I feel it simply not worth the trouble the user has to go through in order to get kind-of-maybe-sort-of-perhaps-somewhat-working GPS.

Do I want it to work? Yes.

Do I think it will ever work? No.

Are you welcome to try? Be my guest. And I wish you the best of luck. :cool:

That's all I meant.