yashsingh1/xdaforums huggingface dataset:
[Captivate Android Development] CuriousTech:
Well, it beats a sharp stick in the eye.

I have a BT-759 sitting here that I keep forgetting about, but rather than have only that to rely on if I remember to bring it, I like having the built-in one working as best it can even if it is crippled and sadly limping along.

It worked great today BTW.

Edit: Made all the changes. It didn't work the first on first try. Rebooted and it's back but no change to lto.dat and works the same. Haven't looked at logcat to see if anything is failing.
[Captivate Android Development] Rrryan2:
Oh.

<removes stick from rear end>

I see what you were getting at I guess, and you're quite right that no matter what we do the hardware and design issues will persist. I understand perfectly why devs with more knowledge and sanity have had the good sense to stay away from the GPS issue.

I was just looking at it oppositely I suppose. I knew enough about GPS to see that there was room for improvement, and with a little more effort made even more progress.

With plumbBob 1.0, GPS got to usable if still sub-wonderful performance. In 2.0 (when it's working right, grr...) it's almost a reasonable approximation of a standalone handheld GPS. Except of course that it's also got free access to Google's worldwide, always-updated map database, real time traffic info etc.

If stable versions of this fix are baked into ROMs (like plumbBob 1.0 is in Cog 4.31 now) the user doesn't have to do anything at all either.
[Captivate Android Development] Rrryan2:
The goal of this fix was to (partially) port JV1/JVK Gingerbread to Froyo ROMs, none of which have /system/vendor/ at all. The init.rc in all of them invokes the old /system/bin/gpsd/glgps_samsungJupiter -c Jupiter.xml and I sure didn't want to try messing with people's init.rc. However, simply dropping the new daemon into /system/bin/gpsd/ didn't work either, as the new daemon doesn't act nicely if the pathname/filename are incorrect, as if they're hard coded with the daemon itself. I chose a workaround that included putting an appropriately renamed copy of JV1 gpsd in /system/bin/gpsd/ but with a launch script that triggers /system/vendor/gspd instead. It's stupid but it works, and the add'l overhead is only about 600k.

As it was intended to port Gingerbread GPS to Froyo, 2.0 might not be a good match for CM7. Some users have inexplicably had good results applying 1.0 to CM7 though.

But yes, /system/bin/gpsd/ ought to be unnecessary on CM7.

LOL. Feel your pain. About every 3rd day I wind up messing up my gps so bad that I need to re-flash. Unfortunately, I don't have any ideas what might be causing that one.

Thanks again for all your help too. I had written a long-ish response addressing each item but it got lost to a Win7 update automatic reboot. I'll try to re-create it later.
[Captivate Android Development] CuriousTech:
Try this change at the bottom of S_plumbBob_gps

rm /data/gps/lto.dat
rm /data/gps/ltoStatus.txt
exec /system/vendor/bin/gpsd -c $CONFIGFILE

It seems to update lto.dat on each reboot, but ltoStatus.txt remains the same date. Yeah, odd.
[Captivate Android Development] TheMathMan:
Wondered if you guys could help.

MIUI RC5 - no GPS lock at all. Nothing. Files include the gps _extlna ones.

CM7 (0415 Nightly) - perfect lock in seconds! Does not have any gps _extlna files present in system.

Now by deduction I'm assuming that's causing the problem in MIUI.

Is there a way to fix this? Can I pull the CM7 ones and replace into MIUI? Or is there an XML I can edit to fix?

This is for Armani S.

Thanks.
[Captivate Android Development] polyrhythmic:
Well the main problem I saw was that the exec paths pointed to directories instead of the binary -- exec can't execute directories. Interesting that the location seems to be hardcoded into the gps daemon.

There are slight differences between the CM7 XMLs and the plumbbob XMLs, the Ext_LNA XML is closest to the CM7 stock. I'll try switching them around and see if I get improvement.

Also, where did the GPS driver gps.s5pc110.so come from? It does work with CM7, I'll have to take a drive later and see if it provides any advantage.
[Captivate Android Development] Rrryan2:
The differences in the XMLs are mostly tweaks I put in to improve things.

The driver is from the Samsung JVK 2.3.3 leak.
[Captivate Android Development] movrshakr:
I see the acronym JVK all over. What does it mean?
[Captivate Android Development] CuriousTech:
That's a shame. At least it's usable now. You should look at the NMEA output sometime, or maybe use some PC software to graphically watch it. Another oddity is the GSA sentence. Every second it spits out 2 of them. This is supposed to show the fix as 1=no fix, 2=2D and 3=3D. For some reason it always has one as no fix and the other as 3D fix no matter what. Really odd stuff.
[Captivate Android Development] CuriousTech:
Just an update. I found another app called Aspara that dumps raw NMEA and I don't see the false data in the stream, so all my info is invalid and should be disregarded. Argh.
[Captivate Android Development] Rrryan2:
Was wondering about that. Really though, from a pragmatic standpoint I'm not sure how helpful it is to comb the NMEA output from the GPS. All it could really tell us is what we already know: that GPS performance is kinda mediocre. Without the means to manipulate the driver though there's basically quite little that could be done to address any problems that might be even be uncovered.
[Captivate Android Development] nyydynasty:
well, this "fix" really depends on the area because near my house and my job, the initial lock and tracking was near perfect. Then I was in northern NJ this evening and I couldn't get a lock at all. I left it on my dashboard for about 10 minutes and it never got a signal.

oh well.
[Captivate Android Development] CuriousTech:
True. I was able to compare the two devices finally and could see that with what little it can pick up, the SNR was roughly 20 vs 30 on the other GPS meaning it's pretty weak. I think around low 20's is what it needs for a lock. That's inside the house though. Outside it can get much better, but being weaker it just needs a better view. Plus the driver of course. The only part of the phone that isn't open source doesn't work well. That's a clue for you, Samsung. LOL

So like we already know, try to get as clear of a 180 degree view in all directions as possible to at least get the signals up high enough to keep a fix and it won't be as much of a problem (for the readers).
[Captivate Android Development] Rrryan2:
If you're in a new area and having a problem like this, it can be helpful to go into LBStestmode (SGS Tools or dial *#3214789650#) to force a new AGPS download.
[Captivate Android Development] xsteven77x:
Running cognition 3.04 and this tis the first fix that had made it at least functional! Thank u for sharing what you know.
[Captivate Android Development] iXNyNe:
just flashed this

im a big fan of reading before i flash something so i was expecting the gps signal to not work at first (until it downloaded the almanacs or whatever those are)

after getting over the initial setup period (only took about 3 minutes for me) the gps seems to lock very fast and very accurately while stationary - i will report back about navigation after my car ride home

in any case, aside from ms based, what other settings should be set on that screen? i got all the google server settings in the other screen
[Captivate Android Development] Rrryan2:
Hmm. That's puzzling, as if were properly loading AGPS data (over WiFi or 3g) it should have been much quicker than that provided you have good signal.

Try deleting GPS data in SGS Tools or the dialer above and try to re-acquire a GPS fix.

Be sure mode is set to "SUPL" too.
[Captivate Android Development] iXNyNe:
Doesn't the first post say it could take around 15 minutes for the first lock?

Also, ride home seemed good but my battery was low so ill be testing the ride into town today instead :)

I am definitely set on supl. All my settings match your screenshot for supl settings. There's the other page (application settings?) Where the Ms based setting is (also hot start or cold start and other stuff) my question was about those. What should they be?
[Captivate Android Development] iXNyNe:
Tested driving. Worked flawlessly.
[Captivate Android Development] Rrryan2:
15 minutes should really only be needed in "dumb gps" mode. With aGPS working right it should be much faster.

Getting another update ready to publish tonight. Will include screencaps for all the lbstestmode settings when I do.
[Captivate Android Development] nakedninja42:
another update! I thought it couldn't get any better. I think one of the best things I read on a fix for this is changing from landscape to portrait when its in my Car Dock. I can't believe how fast locks I have been getting, (faster than my garmin and my wifes tomtom) and it seems to never drop or go to a side street while I am driving on the freeway. Since most of the places I have tested the GPS with were locations I already knew, I would test to see how fast and accurate the rerouting is, and it seems I can't trick it! I can't believe how much better this is than before!
[Captivate Android Development] max_82:
Is it compatible with stock ROM froyo i897ucji6?
[Captivate Android Development] nyydynasty:
ahh, good idea. I'll try that next time.

thanks!

yes it does but this is the first time it's ever done that to me. I've always gotten a lock within the first 5-10 seconds while its on the dashboard.
[Captivate Android Development] Rrryan2:
Should be, but I haven't tested that configuration myself. So far as I can tell though it should work with just about any Captivate (AT&T or Rogers) or Armani based ROMs. Or, for that matter Fascinate, Epic, or Vibrant.

It won't work well on i9000 devices though since they use a different GPS chip that also has FM radio, but if things keep going well I might end up making a version for it too.
[Captivate Android Development] iXNyNe:
Well you're doing an amazing job. I haven't had a GPS fix work wonders like this EVER!
[Captivate Android Development] Rrryan2:
0.8.4b update 2/21/2011

Changelog (0.8.4b)

added supl.google.com configuration lines to gps.conf. Another fix I found tried this with some success and it really can't hurt, but performance seems roughly the same.

Add the SSL certificate file from stock JF6 to /system/bin/gpsd/supl_att_root.cer. This is the certificate used for Secure Socket SUPL connection. This seems to be missing in most to all of the ROMs not based on AT&T code and adapted from Non-AT&T carriers (i.e., pretty much 100% of them). This should allow SUPL secure socket to be used for better security and privacy, but can still be disabled by user with LBSTestMode if performance degrades.

I have continued to experiment with adding the Control Plane supplement (ie using the cell towers' own organic time and location services for controlling call handoff between towers etc.) but in testing I still can't get consistently improved results. For this reason I have decided to not make any changes to the configuration for now. If anything adding Control Plane often seems to degrade acquisition times and # of birds initially acquired slightly, which could indicate that it's not working at all and simply introducing a timeout delay. Or it might just indicate that it doesn't work very well. It's another one of those things that's hard to sniff out inferentially in the absence of GPS driver source, SDK etc.

I did manage to discover that there's even a whole separate control app for implementing Control Plane augmentation. Yes, in yet another example of Samsung's consistently, laughably, schizophrenically fragmented implementation of the GPS controls, there's yet another undocumented place to change settings. No wonder it doesn't work for so many.

I have left the control plane method allowed as an option in the configuration files supplied with PlumbBob 0.8.4b, so users who are still not getting satisfactory GPS performance might experiment with adding Control Plane augmentation by doing the following:

Open LbsTestMode by using SGS Tools, select "secret codes" and then choose LbsTestmode OR use the phone dialer to enter *#3214789650#

Select "SUPL/CP Settings"

Under AGPS Mode choose "Control Plane" from the dropdown

Open the phone dialer and enter *#1575#

Choose "CHANGE CP STATUS"

Choose "CONTROL PLANE ENABLE"

Reboot

Again - I can't promise that performance will improve any if at all by using Control Plane and I do not recommend this for all users. However, it could potentially be useful in locations for which supl.google.com doesn't have accurate or up-to-date info, so still it might be worth trying for some users. But if you're already getting reasonably good GPS performance I recommend it be left alone. And indeed, there might be some good reasons *#1575# has Control Plane disabled by default - it may not even work.

(Updated international versions can be found in original post as soon as I get this coded)
[Captivate Android Development] sjavvaji:
is this better or worse than the jm9 gpsfix?...ill try it out in the morning.
[Captivate Android Development] Rrryan2:
Should be better. I included some of the same tweaks the JM9 fix used, but it still had some problems like using the now-lapsed spirent-lcs.com as the LBS server.
[Captivate Android Development] polyrhythmic:
So it would be reasonable to see improvement on CM7 when using JVK radio, JVK GPS driver, and your XMLs, I think. (JVK is also rumored to have the best power consumption according to Zachy's kernel thread.) Thanks for helping me sort this all out.

Now if only ServiceMode was accessible through CM7 so that the 850 band could be set as default on JVK for those that need it...
[Captivate Android Development] Rrryan2:
Your logic is problematic at best. The ExtLNA files relate to an as-yet unreleased

Ext

ernal

L

ow

N

oise

A

ntenna mode. They're certainly not causing your problems, and manipulating them or removing them basically won't affect anything at all at this point.

This might be a better question for the MIUI thread.
[Captivate Android Development] lilmanx01:
I'm trying to read and understand. JVK is the modem type required or?
[Captivate Android Development] Rrryan2:
JVK = leaked build of Samsung Gingerbread 2.3.3 for I9000. Or more specifically, 'JVK' is the designation for the modem therein and as the modem is often exclusive to a particular build the entire package is often informally referred to by its modem designation. I put 'JVK' in the subject to indicate that this fix makes use of files from the JVK build.

Using the JVK modem is not a requirement for this fix to work properly.
[Captivate Android Development] lilmanx01:
Got it, thanks!!
[Captivate Android Development] CuriousTech:
I made the mistake of reinstalling GPS Aids today. It froze every time on downloading XTRA data, so FC and no data files. It seems to delete them before that point, and since all the right files aren't there the GPS doesn't work.

Rebooting gives me the lto.dat but not the others (PB 2.0) so switched to 1.1b1 and all the files show up. The 1.0/1.1 version has much better data management (at least on Cog/Android 2.2) but different operating performance.

I don't understand why though. Is it really just the deamon? I took a quick look at them in an ELF decompiler but didn't get into it too much since it had trouble with the code section.

Oh well, so I'm back on 1.1b1 now. lol
[Captivate Android Development] Kenn Lynch:
Typos fixed yet?

It seems about a half dozwn typos in the xml were posted here recently.

Have these been corrected and put in a later revision some place?

The latest Cognition Rom apparently had some version of PB 1 or 2

installed in it, but it doesn't tell which version or which corrections were

included.

I'm getting conflicting results with Cog 4.3.1 and PB 1.01b1, Its very slow to fix, and only finds a few Sats

And with 2.0b11 it finds many more Sats right away but its very "twitchy"

The reading jumping around showing 3 mph while stable. Neither version is now

creating or DLing the LTO files. It used to DL and or create 7 files in data/gps

now I only see 4 files there (for both versions)

gldata.sto, glgpsctrl, ics.socket and secgps.conf are there but

The 2 lto files (and I think it was a text file )are no longer in that data/gps

Thanks

KJL
[Captivate Android Development] Rrryan2:
Yes, there is a test version with the corrections in irc. As soon as I get a few more feedback reports I'll release it here as well.
[Captivate Android Development] Kenn Lynch:
Typo corrections

Great looking foreword to it

I have since discovered that the two "missing" lto files are now in the

data/gps directory (lto.dat and ltostatus.txt) At one time I believe there was

a final seventh (???.sto) file it still has not re-appeared in data/gps

Is there a convenient way to determine which version and number is presently installed? (even by file size) I've been jumping between versions and am also not sure which was included in Cog (but that will presumably be overwritten by this new version you mentioned as soon as you release it anyway).

Well If you would like another field tester for feedback just let me know

Right now it (v1.1b1)seems to be find 8 and more birds locks and tracks fairly well. The only thing that bothers me is it still appears jumpy or twitchy (GPS-Status and GPS-test) show erratic mph reading (up to 4 MPH while at rest)

the heading and compass point also jumps about every 10 secs even with 7/7 Sats. GoogleMaps seems to very quickly pop an icon somewhere on my home

but some of the older version could easily put the icon right on the corner of the room I was standing in. It also seems now the compass function is (direction my phone points) is not as tight as earlier versions (as much as 45 degs off)

So I hope you add those corrections to both versions 1 and 2 (assuming they both have the same typo errors)

Thanks Again Later

KJL
[Captivate Android Development] jsbac:
I installed Beta13 last night -- going into GPStatus (and Maps), it did the deal where the GPS comes on for 3 seconds or so and then shuts down. I was previously on Beta11. I ended up flashing v1beta1 just to try something different. It works (although for me I believe Beta11 works better).

Also, wanted to give you a Thanks. Last week I flew out to California and drove back to Arkansas. Using Continuum4, TUBJP9 modem, and PB2Beta11 my GPS was essentially perfect all the way from Ontario, CA to Albuquerque, NM. I don't know what happened after that -- it just went crazy on me. No locks, slow locks, intermittent locks, etc. Interstate driving the whole way. I flashed Heathen's GPS fix (which generally works good for me too), and didn't have much better success. I can't explain it -- I would have good cell/data signal, wide open spaces -- basically everything that seems conducive to promoting good GPS. The further east I drove the closer I got to a storm, but was always behind the storm. But really, didn't even get near the storm until Oklahoma. So maybe that had something to do with it -- it's hard to say.

Anyway, here is what I find the main difference between PB2Beta11 and Heathens:

PB2Beta11 -- slower to lock (but not "slow" to lock -- usually < 15 seconds), accuracy is reported as being 10 to 15m, but it's usually pretty accurate, navigation is where this PB really shines (for me).

Heathens -- faster to lock, accuracy gets down to 5m quickly, Navigation is fair, but I tend to get more drifting, and quick snapping to side-roads (but usually returns fairly quickly).

Anyway, Rrryan, thanks for your continued work on this. It really seems to have made a difference on my GPS.

jsbac
[Captivate Android Development] eliminat:
beta 11 gps.conf:

NTP_SERVER=north-america.pool.ntp.org

XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin

XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin

XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin

SUPL_HOST=supl.google.com

SUPL_PORT=7276

gps.conf I tried and had better luck with so far:

NTP_SERVER=0.us.pool.ntp.org

NTP_SERVER=1.us.pool.ntp.org

NTP_SERVER=2.us.pool.ntp.org

NTP_SERVER=3.us.pool.ntp.org

XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin

XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin

XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin

XTRA_SERVER_4=http://xtra4.gpsonextra.net/xtra.bin

INTERMEDIATE_POS=0

ACCURACY_THRES=0

DEBUG_LEVEL=3

ENABLE_WIPER=0

ENABLE_XTRA=TRUE

SUPL_HOST=supl.google.com

SUPL_PORT=7276

SUPL_SECURE_PORT=7275

SUPL_NO_SECURE_PORT=3425

SUPL_HOST=supl.skyhook.com

SUPL_PORT=7278

CURRENT_CARRIER=common

#REPORT_POSITION_USE_SUPL_REFLOC=1

DEFAULT_AGPS_ENABLE=TRUE

DEFAULT_SSL_ENABLE=FALSE

DEFAULT_USER_PLANE=TRUE

#START_MODE=WARM

#OPERATION_MODE=STANDALONE

PHONE_TYPE=UMTS

Can someone else do some testing and see if it's placebo or if these settings actually are helping?
[Captivate Android Development] movrshakr:
How did you come up with that set of configurations?
[Captivate Android Development] eliminat:
Pulled from a HTC Inspire 4G thread.
[Captivate Android Development] movrshakr:
In GPS Test and GPS Status, the circular compass is always 90 deg off. N points E, and so on.

Any ideas? (1.0-USA)

LATER--think it is fixed. Found a compass calibration in GPS Status>menu>Tools (rotate it around each axis, then press OK).

It was impossible to do the flip end-over-end axis because it would sense to flip the display while doing that, thus erasing the OK button. I did it by holding phone vertical first, rotating around the vertical axis, and pressing OK. No change; N still at E.

Then I held it flat horizontal and rotated it flat in that plane (around the perpendicular axis through the center of glass), and pressed OK. N moved close to where it really is, but just a little bit W of where it should be--but only a tiny bit, maybe 5 deg.
[Captivate Android Development] Kenn Lynch:
New Beta yet

Any chance of getting a copy of the new Beta releases? I was getting bored waiting and did find that the same typo as noted earlier in 2.0 betas

was also in Plumbbob-1.1 beta1 its in

Meta-INF/com/google/Android/updater-script

a lower case "J" was in jupiter in "samsungjupiter"

line 15 should be "/system/bin/gpsd/glgps_samsungJupiter");

(I'll take your word that its case sensitive)

but I'm sure you have since a few other tweaks in version 2

(I see someone already has a version 13, Sorry to admit I don't "sabe" IRC)

Unfortunately even after changing the "j" to "J" it still doesn't load the either of the lto files or the or lbs file (but last time it seems to re-synched later, not yet)

Time for a new release to toy with

Come on throw us bone <G>

KJL
[Captivate Android Development] Kenn Lynch:
I've also see about the same offset even after using the compass and calibrates in SGS-Status. By any chance do you have a leather case with a magnetic latch? (I did not now) any magnetic or ferric material near the phone (magnets iron or headphones) will cause the compass to deflect. I was surprised because the HTC phone that I previously had, did not have a compass chip but used the Sats to derive the GPS bearing info, So check for any metal near the phone.

There is also Magnetic declination (true north vs mag compass north) its about 13 degs in NY and 13 degs in the opposite direction in AZ. (forgot direction EW)

I think the phone has to derive/lookup the local mag deflection based on cell tower location coordinate info so that it can take more acurate bearings on the Sats and derive where it actually is (I'm just guessing to the actual scenario)

But on a similiar line of thought, how stable and accurate are your speed

(with phone flat and immobile mine often shows 2 or more mph.

Also the reported altitude above sea level is often off by close to 100 ft

I think there are a surprising number of interrelated pieces that all effect the

overall accuracy. (each version and beta seemed somewhat different)

My Hats off to Plumbbobs author for handling it

(hint hint I hope he releases the latest revised versions to XDA real soon)

KJL

Hope I wasn't preaching to the choir" just comparing my experiences to yours