yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] D12AKO:
Intial Results of Testing: v2.0 Beta #6

Ok here's the breakdown of my GPS Test with v2.0 Beta #6:

I had done a clean install of Cognition v4.2.2 SHO with eXistZ Beta#7 KB1 Kernel. Since I was too busy this last week, I hadn't done any GPS Fix yet except whatever DG's ROM brings by default.

Today I used SGSTools to setup the GPS as per your OP... the usual. I then deleted the GPS Data to see how this new 2.0 Beta#6 would do with a clean slate. I then went into recovery mode and installed the GPS Fix and rebooted.

Initial Results:

Unlike most... my initial Lock on first try with Google Maps took around 10sec or less. I was surprised at this since it normally takes 20 to 30sec on initial launch of GPS. I then left it on for a min or so and turned off Google Maps.

I then launched GPS Status and got a lock in 3sec. however to me it seems I have less birds overall compared to v1.0. The locks were really solid though for the most part. All of this in front of my house with fairly clear skies. I haven't gone on a ride yet but will do so soon for better overall analysis.

I then decided to check and see if I had the: /data/gps/lto.dat file but nope... It's not there.

Apparently it's more than confirmed now that Beta #6 does not download the file automatically.
[Captivate Android Development] rajendra82:
I checked my phone, and I have no lto.dat file while running 2.0 beta 6 either.

Edit:

Reflashed 1.0, because I had missed the change in the instructions about not deleting gps data in lbstestmode. After running gps test under 1.0, lto.dat got downloaded again. Then reflashed 2.0.3 beta 6. At what point in time should the lto.dat file get downloaded or updated again?
[Captivate Android Development] Rrryan2:
Unfortunately yes, performance in initial locks will begin to degrade gradually. If I don't manage to get it fixed shortly, using the GPS Aids app afterward will download lto.dat manually on demand and at every boot, so at least there's a known workaround and your GPS won't be perma-crippled in a few days.

Can't figure it out though, my lto.dat gets downloaded at every boot (even without GPS Aids installed any more.) I beginning to think it may be a kernel issue, as from what I understand not all kernels support init.d user scripts.

Hmm...

Well, since you deleted data in contravention to the instructions, all this anecdote really proves is that not following the directions doesn't help the download situation any either.

If you're not getting the lto downloaded you're not going to be able to track some of the birds with weaker SNR. All you really need is 4 birds to get a fix though.

Should be downloaded once a day, so if it doesn't get downloaded in a another day or so give it a reboot and see if it catches.

I'm having a tough time deciding how the new daemon/driver manages the timing of lto.dat refresh. On the old drivers in 1.0, deleting gps data reliably forced a refresh but that doesn't seem to always be the case now, leading me to think it's storing the last refresh time somewhere and not just looking at the age of the lto.dat file or in the LtoStatus.txt. I'm also wondering if by changing LbsSyncLtoThresholdDays="0" (stock setting is 3) I might be throwing a wrench in things and might try 1 instead.

Guess I've got some experimenting to do...
[Captivate Android Development] D12AKO:
I saw the instructions... I did this on purpose to see if it ever would download the file under my specific condition since I hadn't installed any prior GPS Fix. Just to give you another confirmation that on some occasions it will never download... more of an experiment destined to fail...LOL

Hope you figure out how to fix this issue.

I will eventually test it the correct way using GPS Aid or whatever is necessary to get the files updated correctly.

UPDATE:

Just attempted to use GPS Aids v2 and it actually ruined my GPS. Takes long as all hell to get a fix now and with less birds. Check for: /data/gps/lto.dat File and it never actually loaded it even though it says it does. So at least with my current phone setup... no force download work-around currently works.
[Captivate Android Development] Harveythedog:
Worked OK here, did take a few trys to get a lto.dat to actually appear, but once it was there I got a TTFL in less than 1 min..
[Captivate Android Development] Rrryan2:
lto.dat

Also, for those having trouble getting lto.dat to download properly, if you know what you're doing you can download it yourself if desired until I get the automated update working right:

http://gllto.glpals.com/7day/latest/

Just download the file and copy to /data/gps/
[Captivate Android Development] kodos96:
Well I'm running Cognition, with Cogkernel, which definitely does support init scripts, so I don't think that explains why I'm not getting updates.
[Captivate Android Development] Rrryan2:
If you're using stnadalone, you're not using AGPS/SUPL at all so the settings wouldn't matter. You're just fortunate enough to be getting good un-augmented GPS-only location. (Congratulations!)

Type www.spirent-lcs.com intro your browser. Just try it.

Or if you really want to be thorough, try to telnet to that port.
[Captivate Android Development] nakedninja42:
i applied the update to my phone last night (running Dorian JS5 Beta, JK4, K13B) and tried out the GPS this morning. While sitting at a light (its pouring rain outside too) I got a lock in under 10 seconds on Maps. I tested the LBS and was able to get a 30 meter lock in 4 seconds with 8 sat. When I tested my GPS two days ago before applying the fix, I got a lock in 26 with 4 sats on 100 meter. I can't believe the difference, it stayed accurate while driving.
[Captivate Android Development] bames:
That was what i assumed originally.

But here is what i don't understand is then why are my results better/worse when a different server is entered on the supl settings when using standalone?

IE When spirent entered as the supl server then i rarely even have a hiccup in tracking. With google supl minor hiccups (jump off maps or continue straight briefly after a turn). And with the default similar to google only slightly worse.

If its not using that data in anyway when standalone is enabled why the differing results?
[Captivate Android Development] mnjm9b:
Even if the spirent server was working...

And even if it was working while you were in standalone mode.

It still has NOTHING to do with in route tracking...

Those servers only get initial locks to be faster from agps data.

Your results are coincidence.
[Captivate Android Development] bames:
Sorry its more than coincidence.

Have had the phone since june and it has been consistent regardless of variables (ie: geography, different roms, etc).

Almost every GPS fix or rom advertising great GPS gives directions to change settings to supl.google.com (or already implement it by default). One EVERY rom (probably 15+ roms) i have been on the ONLY way to improve the tracking inaccuracies have been to set my supl back to spirent....that is not a coincidence. It may be a software flaw...but even when in standalone mode the server supl and/or port settings are having an effect on tracking accuracy.
[Captivate Android Development] nyydynasty:
well, with the phone on the dashboard, I'm getting consistently accurate locks within 5-10 seconds. Tracking is near perfect, so I'm happy.
[Captivate Android Development] fatttire:
I feel like if the GPS issues were such an easy fix that you just had to patch a few things here and there, or update a config file, that Samsung would have jumped on this long ago. They're taking a terrible PR hit for releasing a phone with broken GPS. The fact that it's been 6+ months means it's permanently broken. Really wish there was a class action lawsuit
[Captivate Android Development] bay_wolf:
I don't think it's consider an easy fix and this will never truly fix the gps but it'll make the locks and tracking much better in my testing.
[Captivate Android Development] Rrryan2:
It's not an easy fix. There are a number of potential hardware and firmware (driver, not fixable with ROM swapping etc.) issues. I just noticed that the existing software configuration had a lot of room for improvement so it could at least be made to be noticeably less crappy for at least some people.

Samsung and AT&T seem unconcerned by the issue, taking the position that GPS is a non-critical accessory. AT&T even told me explicitly that the GPS issue was non-warrantable because "it's not part of the phone." It's a terribly low priority for anyone but us and the various vendors involved are far more concerned with covering their own butts.

If it were a hardware issue, with 10 million+ Galaxy S units sold worldwide it would be massively expensive to fix (if it's even possible to do so without redesigning and replacing the phone!), so of course that won't ever happen unless they're forced by court order (which of course wouldn't apply worldwide).

The best chance of GPS being improved anytime in the near future is in this thread and others like it. Otherwise it's a matter of waiting and hoping for Samsung to invent a new kind of magic.
[Captivate Android Development] nyydynasty:
I hear 'black' is in these days :/
[Captivate Android Development] Rrryan2:
No. You're drawing the wrong conclusions from this. What is much more likely is that the AGPS data wasn't being properly applied before. By forcing the non-reachable server it's instead successfully relying on the GPS-only attained almanac data and you're just getting lucky enough to get good performance. This is not true for many of the rest of us.
[Captivate Android Development] Rrryan2:
And come to think of it... in a sense, Samsung only has incentive to *not* provide proper configuration settings. Because if they did, they know it probably still wouldn't completely fix the problem. And then their flaws would be uncovered and they would have to do something to actually address the other faulty areas. And that would be really expensive, so there's no way they would want to start down that road.

As long as they can keep stalling they can keep selling and the more likely it is that it will just blow over. Keeping the bad configuration (and releasing a "fix" in the market that only rewrites the bad configuration!) helps accomplish this and helps shield them from liability.

/foilhat

Anyhow, this is getting OT for the Development forum and doesn't actually help move things forward so let's try to stay technically-oriented.
[Captivate Android Development] bames:
that would make some sense.

i will put that to the test tonight.

i have entered captivate.com for supl server and 7280 for port.

Will see how my tracking is on the way home.
[Captivate Android Development] IStern:
Just installed, only in-house stationary testing so far, but it looks really good. Beats the iPhone4 in lock accuracy and time. Will test tracking on the commute home.
[Captivate Android Development] IStern:
Wow this is the real deal. On the way home there are a few on-ramps that always gave my gps fits. Stuck like glue with this fix applied!
[Captivate Android Development] amtrakcn:
Significant improvement of my GPS:D
[Captivate Android Development] CuriousTech:
I tried this earlier today and could see some improvements. Before flashing I found a good spot where no birds were locking because the signals were just below the threshold, flashed this and it fixed quick. Then did 2 moving tests and the first time it got a fix within around 20 seconds at 55mph and the second time I was going about 40mph for around 60 seconds and it fixed as soon as I was stationary.

I don't understand why it can't hot start though. You can exit an app and restart it 5 seconds later, and it goes through a warm start. Why is that? And without the goofy pseudo-dead reckoning on, it sticks when it loses fix. Does it lose the almanac/ephemeris data as soon as it shuts off? I get the feeling some of this is incomplete or a poor antenna like the Captivate has wasn't taken into account but some more improvements could be made. It would all be code though, by saving a timestamped state that could be used to hot start it, or is it already doing all it can?

But here's the strangest thing. I had a BU-359 sitting right next to the Captivate and had an app running that sends NMEA over bluetooth. Both were being logged on the PC and I was dumping Sat# + SNR. Side by side the Captivate was showing higher SNR for the same sat. That doesn't make sense does it? It could be the app not converting to NMEA properly though. Not really sure. The app is called Bluetooth GPS Output.

Great work though. It's getting a fix in more troublesome situations as far as I can tell.
[Captivate Android Development] CuriousTech:
Thanks Rrryan2. You filled in a lot of gaps for me. I was under the assumption that it was a kind of soft GPS and didn't know where that code was. It's a shame that isn't open source since that's most likely where the problem is. Here's a head scratcher. I stripped the PGLOR (some kind of debug left in it) and the others. Just GSV. It's seriously messed up so don't stare at it too long. LOL

$GPGSV,2,1,8,14,30.0,104.0,27.0,16,37.0,185.0,30.0,20,38.0,298.0,23.0,23,16.0,303.0,26.0*41

$GPGSV,2,2,8,25,19.0,42.0,12.0,30,55.0,174.0,13.0,31,64.0,26.0,26.0,32,60.0,268.0,24.0*45

$GPGSV,3,1,12,31,64,026,25,32,60,268,23,20,38,298,22,16,37,185,29*7F

$GPGSV,3,2,12,48,23,240,26,23,16,303,25,24,08,249,20,30,55,174,*77

$GPGSV,3,3,12,51,39,213,,14,30,104,,25,19,042,,29,11,074,*76

$GPGSV,2,1,8,14,30.0,104.0,12.0,16,37.0,185.0,30.0,20,38.0,298.0,23.0,23,16.0,303.0,26.0*47

$GPGSV,2,2,8,24,8.0,249.0,21.0,30,55.0,174.0,26.0,31,64.0,26.0,26.0,32,60.0,268.0,24.0*4B

$GPGSV,3,1,12,31,64,026,25,32,60,268,23,20,38,298,22,16,37,185,29*7F

$GPGSV,3,2,12,48,23,240,24,23,16,303,25,24,08,249,20,30,55,174,*75

$GPGSV,3,3,12,51,39,213,,14,30,104,,25,19,042,,29,11,074,*76

$GPGSV,2,1,8,14,30.0,104.0,12.0,16,37.0,185.0,30.0,20,38.0,298.0,23.0,23,16.0,303.0,26.0*47

$GPGSV,2,2,8,24,8.0,249.0,21.0,30,55.0,174.0,26.0,31,64.0,26.0,26.0,32,60.0,268.0,24.0*4B

$GPGSV,3,1,12,31,64,026,25,32,60,268,23,20,38,298,22,16,37,185,29*7F

$GPGSV,3,2,12,48,23,240,19,23,16,303,25,24,08,249,18,30,55,174,*70

$GPGSV,3,3,12,51,39,213,,14,30,104,,25,19,042,,29,11,074,*76

$GPGSV,2,1,8,14,30.0,104.0,12.0,16,37.0,185.0,30.0,20,38.0,298.0,23.0,23,16.0,303.0,26.0*47

$GPGSV,2,2,8,24,8.0,249.0,19.0,30,55.0,174.0,26.0,31,64.0,26.0,26.0,32,60.0,268.0,24.0*40

$GPGSV,3,1,12,31,64,026,25,32,60,268,23,20,38,298,22,16,37,185,29*7F

$GPGSV,3,2,12,48,23,240,26,23,16,303,25,24,08,249,15,30,55,174,*71

$GPGSV,3,3,12,51,39,213,,14,30,104,,25,19,042,,29,11,074,*76

I hate to think that's what is coming out of it. Notice the number of sats in view for example. 8,12,8,12,8,12... I think it has bipolar disorder. There are 2 sets of GSV pages formatted differently.
[Captivate Android Development] Rrryan2:
I hadn't spent lots of time examining NMEA output. For one thing it makes my head hurt, but there's little we can do to influence it anyway. Again, Samsung has to rewrite the driver.
[Captivate Android Development] Rrryan2:
:( So much for that idea...
[Captivate Android Development] akuru:
What should be the given rights? 666 and system:system?
[Captivate Android Development] rajendra82:
The original lto.dat was 770 and system.system, before I did anything to it.
[Captivate Android Development] sremick:
"even with"? Smaller is better. Small the circle, the more-accurate the satellite tracking data it's receiving and therefore the more-precise the fix.
[Captivate Android Development] rajendra82:
I think at the highest precision of 5 m, maps shows only the arrow, and no circle. When precision drops to 10 m or 30 m a circle starts to be shown. He is sayings it's tracking well even with a circle arund the location, versus a strong lock resulting in just the arrow being shown.
[Captivate Android Development] movrshakr:
For LbsTestMode,

SGS Tools>Secret Codes says

GPS-Test and settings (LBSTestMode): *#*#1462365#*#*

Post 2 says

use the phone dialer to enter *#3214789650#

Which is correct?
[Captivate Android Development] rajendra82:
The first was the pre Froyo code, which no longer works. The second works on Froyo.
[Captivate Android Development] anneoneamouse:
The second one works, first didn't. Would have been faster for you to try it, than posting?

AoN
[Captivate Android Development] movrshakr:
Or a bad code could mess something up, huh?

My approach is to KNOW, before commanding something for which I do not know for sure what the results will be. Just me. Others like to live dangerously. Sorry if my posting offended you.
[Captivate Android Development] movrshakr:
OK, did the second dialpad code, *#3214789650# and set things as stated for lbstestmode.

Now strangeness has happened in the flashing of the fix...

I put the zip in dropbox on my PC. It appears in Dropbox app on the phone, but NOT in /sdcard/dropbox on the phone. I have no clue how I would use Root explorer to move it to /sdcard thus to be available for CWM flashing.

HOWEVER, when I touched the filename in dropbox app, a window popped up offering to CWM install it.

get:

...blue Samsung recovery (3e) ...

(how did this get on? I have red from Cog 4.3)

reboot system now

reinstall packages

delete all user data

delete cache data

format internal sd-card

-------- begin yellow------

update media, wait

update media, finished

finding update package

opening update package

verifying update package

E:signature verification failed (red)

--Appling Muti-CSC (sic)

Installing Multi-CSC

Installation Aborted. (red)

I selected reboot. [

Apparently 'plumbBob-1.0-CWM-USA.zip' was not flashed. Still need to flash--how can I get the zip into /sdcard so I can use the red CWM and select the file to flash?

And why did that "automatic flash" happen? And why can I not see the file using root explorer in /sdcard/dropbox (to move it to /sdcard for flashing) even though file shows in dropbox on the phone!?

Not going very smooth today.
[Captivate Android Development] kodos96:
So nobody seems to be around on IRC, so I'll post this here...

I seem to have found a solution to the the lto.dat not getting updated problem, or at least the version of it that I was experiencing - for me the file existed, since I had never deleted my gps data before flashing plumb2.0, but it was an old version of the file and not getting updated.... if I recall, some of you are having a different version of the problem: you don't have an lto.dat at all... if that's what you're seeing, then I don't think this will fix it for you, but if you have an lto.dat that's just not getting updated, check the permissions on it. Mine was set to "---xr-SrwT", which is weird - I don't know what the S and T bits are for, probably something related to android's security model, but whatever they are, they seemed to be preventing gpsd from overwriting it. So I just chmodded it 770, rebooted, and now it's started getting updated like it should. Went outside and tested it - with a fresh lto.dat I got a 16 second TTFF, off a cold start (first time today I'd used GPS). So it definitely seems to be working.

For those of you who don't have an lto.dat at all (and gpsd won't download one), could you check the permissions on the directory /data/gps/ and let me know what you see?
[Captivate Android Development] Harveythedog:
drwxrwx--x system system 2011-03-31 13:30 gps

GPS Aids was able to download me a lto.dat if that might mean anything.

-rwxrwxr-x root root 40701 2011-03-31 13:16 lto.dat
[Captivate Android Development] movrshakr:
Mine is same, and file time is 4 hours ago, about the time I flashed plumbBob. GPS has been running ever since then. Is this file supposed to be updated more often? How often? How do I change the permissions if needed. I have Root Explorer.

And how does plumbBob work for so MANY people if this file is not getting proper Write permissions?
[Captivate Android Development] kodos96:
Hmmm, ok well then I guess there's something else going on here.
[Captivate Android Development] kodos96:
Well it's supposed to get updated on reboot, and then periodically after that, though I'm not sure how often.

I'm not sure whether setting the permissions in root explorer will change the S and T bits (it might, I'm not sure).... just open terminal (or ssh in) and do "su" then "chmod 770 /data/gps/lto.dat"

Well different people are ending up with different setups depending on what ROM/kernel they're running, what gps fixes they had flashed previously, whether they deleted their gps data before flashing, the phase of the moon, etc. So for people that it's working for, obviously they ended up with correct write permissions.

Also, just to be clear, this issue only started with the 2.0 betas, which not very many people are using yet. All the people saying they flashed plumbbob and it works for them are probably talking about 1.0, which uses entirely different binaries etc.
[Captivate Android Development] Rrryan2:
Mine is set to the xr-SrwT too yet updates properly at boot too. Weird.

770 would make much more sense though. I was already considering including a copy of lto.dat in the fix to hopefully help give things a 'jump start' so I guess I'll go ahead and do that so I can modify permissions too.

If nothing else it might get things working for 7 days at least. :rolleyes:
[Captivate Android Development] surfed.tk:
I also have had those weird permissions set.

Sent from my Samsung captivate.
[Captivate Android Development] wgarrido:
Mine were okay, but it takes forever to get a lock if it does it tracks well, but getting that lock sometimes never happens.

I tired playing with GPSAids. Runing gps test/status first and getting a lock seems to help and then running gmaps.
[Captivate Android Development] surfed.tk:
gave up on gps

The tracking issue caused me to give up on my build in gps and i bought myself a Canmore GT-750F external bluetooth gps receiver. I get 2.5 m accuracy under cloudy sky and have seen 1.1 m under clear skies.... tracking is dead on.
[Captivate Android Development] ifederov:
Thanks!

Thanks for the great gps fix. GPS wouldn't work at all - regardless of the ROM I was running (Perception, Cognition, Phoenix, Supernova, Firefly, Continuum). I skeptically tried the gps fix - and WOW, what a difference. I get lock in under 20 seconds @ 10m accuracy (which is good by me). Using CoPilot or TeleNAV, my phone tracks perfectly.

Thanks again!
[Captivate Android Development] askpcguy:
What app are you using to test the gps tracking? Do you mean using google maps the gps position follows you precisely without jumping to different roads?

The problems I've seen come from using Google Maps for driving directions.

Also, in /data/gps I have a file named lbsdata.sto which had those weird permissions. I used super manager to change it to 770, went to lbstestmode to get position test, went back to Super Manager and discovered the fille date/time changed. The size of the file also increased.

Not sure what that indicates and there still is the matter of testing google maps driving directions for accurate tracking while driving.
[Captivate Android Development] tpadela:
i dont even have a /data/gps folder... only /data which is empty....

i flashed PB 2 after flashing existz beta #8 kernel to cog 4.3. i did not delete gps data as per instructions...

i am using ES file explorer to look for the folder...
[Captivate Android Development] anneoneamouse:
Rrryan2,

While looking for gldata.sto in /data/gps (got it), I noticed a file called secgps.conf in the same directory. I'm using Cognition 4.3, stock.

The secgps.conf file gets rebuilt on boot if renamed, but the configuration details listed do not match your recommended settings set in lbstestmode (which are set, confirmed). Secgps.conf contains the default "wrong" settings (spirent, port 7275 etc) that a brand new ROM fires up with. Is this anything to be concerned about?

Edit: Just saw askpcguy's post. Here's the contents of /data/gps:

gldata.sto

secgps.conf

I don't have an lbsdata.sto in that location. Hope all this helps, and isn't just a snowstorm of useless info.

Thanks,

AoN.