yashsingh1/xdaforums huggingface dataset:
[Touch CDMA Android Development] jnadke:
Google Navigation isn't a good test. Google processes the data (such as the noisy lat/lon) to make it fit the map. It's probably locking up. It's not gonna point the arrow backwards if your position is moving forward (cars don't drive in reverse down the road usually...). They do this because, like I said, GPS is noisy. To compensate for this, Google can make assumptions about how you're driving (you don't go off-road, you drive forward always, etc). Our broken GPS violates these assumptions.

Just download GPS Test from the market. It puts your speed, bearing, and altitude on the screen in nice, big letters.
[Touch CDMA Android Development] jnadke:
The unit choice doesn't completely make sense to me, honestly. But it's the simplest mathematical explanation that fits the data, so it's highly likely that it's right.

EDIT: I realized this is a least-plausible explanation, because the units make no logical sense. I think they're just normalizing the data by 360.0 and then bit-shifting it by 10 bits (1024) (that's far more typical in the GPS industry). The units are circles (a lot of satellite parameters are specified in semicircles).
[Touch CDMA Android Development] Shidell:
lol. I'm just fishing for laughs from everyone else who is following along. :)

I've got GPS Test downloaded and I'll test it tonight here in Wi. Have you compiled your changes into a new library? Might as well test with the latest, if it's available.
[Touch CDMA Android Development] jnadke:
Hah, that's how I felt about srwalter's 1.035631 correction factor (for opposite reason). I'll probably tackle that one later.

No, I'm at work. I probably won't get a chance to compile until Monday. That and I'd like to figure out what's wrong with altitude before making changes.

Though, you can get dzo's latest tree here:

http://androidhtc.git.sourceforge.net/git/gitweb.cgi?p=androidhtc/gps.git;a=tree
[Touch CDMA Android Development] Shidell:
Hm. So you want me to implement the changes you suggested and compile when I get home to test with?
[Touch CDMA Android Development] jnadke:
Sure.

Altitude seems to be reported in feet, so for that, do:

const double altitude_scale_factor = 0.3048; // Convert feet to meters
location.altitude = (double)data.altitude * altitude_scale_factor;

It's perfectly possible I just got some bad data, which is why I'd like someone else to download GPS Test and test out the libgps.so + zImage I posted (it's the same as the v1.4 you posted + 1/19/10 voguimg.nbh).
[Touch CDMA Android Development] jnadke:
After looking at the data more, I fixed the error in my scale factor.

Now altitude and bearing for GPS should be correct. We still have to find where accuracy is being output, and set that. This way Google Navigation doesn't think you have GPS when you don't. Currently GPS is always-on even if you don't have a valid acquisition.
[Touch CDMA Android Development] Shidell:
I just tested the v1.4 library; speed was extremely accurate, but bearing was off--North was accurate, but East was reporting as "60" degrees, and south was reporting as "120" degrees, while West was "180" degrees.

Sounds like you've corrected this already, jnadke?

If you don't mind, please post your source wherever you wrap up tonight, and I'll compile it when I get home and post a library and give it another shot to see what we get.
[Touch CDMA Android Development] jnadke:
Here's a new libgps.so! With source!

I also fixed the scale factor for speed. He was using 1/4 instead of 1/3.6.
[Touch CDMA Android Development] Shidell:
Rock on, nice work man.

I did use GPS Test on the way home and your findings match my own almost perfectly. Additionally, GPS was only reporting a maximum of roughly ~260 degrees, which was the last threshold before returning to 0.

(If that isn't clear, I was walking & driving N/NW to what is almost due North, and rather than being 345 degrees or 350 degrees, it was reporting 260. So it appears that the calculation was off, as you mentioned?)

Anyhow, I'll push your updated library and go pick up something for dinner tonight and report back a little later. I've gotta get an AOSP build of 2.1 going to so I can try and tackle LiveWallpapers. :p
[Touch CDMA Android Development] jamezelle:
whats wrong with live wallpaper?

i would imagine they wouldnt be working as we have no OpenGLES support in eclair(libs), or do they just f/c?

EDIT: sorry didnt realise what thread i was in :o
[Touch CDMA Android Development] Shidell:
Just the Nexus One LWP's don't work, they F/C because of a missing class. (There's a LWP thread in the Android Development Section off the main main forum.)

Anyhow, nobody seems to be able to figure out what dependency it needs or why it isn't working. :\

That's why Starfield works on the Vogue in 2.1, but not Grass, Water/Ripple, Nexus, etc.
[Touch CDMA Android Development] jnadke:
260, or 255? I saw 255, but if it's more than 255, then that means the new code is/was wrong.

Anyways, I'm fairly confident everything should be right now, and new work can be put into finding the accuracy, then cleaning things up functionality wise.
[Touch CDMA Android Development] Shidell:
I just went for a late night cruise and must've pushed the lib incorrectly (or something..) as I was still receiving an erroneous bearing of "255-260" as roughly North.

I don't know if I was seeing 255 or 260 exactly; I recall seeing 253 and then it flipping to 2 or 4, so I knew they were very close.

For reference, with the latest code you just posted, it should truly use 360 degrees, correct? N=0, E=90, S=180, W=270 (in terms of degrees) ?
[Touch CDMA Android Development] jnadke:
I just took it for a walk, and it works perfectly (of course at walking pace the bearing is very noisy, but it was near 359/0). You must've pushed it wrong.

Did you remount before you pushed?

Did you push it to the /lib/eclair and /lib/donut directories too (I assume those versions use those directories)?

Check the file timestamp with:

adb shell ls -l /lib/libgps.so

Here's a little bat file I use with adb from windows to upgrade the libgps.so:
[Touch CDMA Android Development] jnadke:
So it looks like the accuracy values are probably the innermost 2 pad values between lat/lon/time and altitude/bearing/speed.

Looks like lat, lon, time, something, EHPE, EVPE, a3, alt, bearing, speed.

The something value seems to do it's own thing. Sometimes I see it decrease with EHPE and EVPE (around 0xf to 0x9), sometimes I see it start from 0 and go up. I'll have to look at it further to see what it is.

I see a steady state value for EHPE and EVPE indoors of 5 and 5.

Anyway, here's some new images with FULL GPS POSITIONING SUPPORT!

Remains:

-Time is off, way off (always has been -- need to figure out scale factor) -- will probably have to decode this from the other values

-Which satellites are contributing to position (not important)

-Make sure satellite PRN/SNR are correct (seemed too weak)

SORRY, zImage (SD) only, I don't know how to build NBH files.

NEW LIBGPS.SO REQUIRES NEW KERNEL (1/19/10 won't work).
[Touch CDMA Android Development] jnadke:
Sorry, I realized that my change yesterday broke speed.

I assumed dzo's comment was correct (output was km/hour), and his data.speed / 4 was wrong. Instead output is in (meters/sec * 4). Hence the / 4 is right.

Here's a fixed zip file. Same zImage as above (removed the above zip file).

Accuracy reporting works well. It's "the right way", because accuracy is 0 when there isn't a valid navigation solution (before it would output 3.0 all the time so google nav might think you're somewhere that you're not). Most of the time accuracy estimated is better than 3.0 (though it can change when you go under overpasses, etc).
[Touch CDMA Android Development] tatnai:
got the latest set up on donut from ext2. quick walk test seems to have speed, altitude. will test on drive tomorrow. thx all for the contribution!
[Touch CDMA Android Development] bchi49:
Thanks! With the new zImage for SD Android 2.1's Live Wallpaper works! I haven't test GPS yet.
[Touch CDMA Android Development] Reddog80p:
The built-in wallpapers like water?
[Touch CDMA Android Development] bchi49:
I had to download them from the market place, otherwise the default crashes (probably they weren't included by default). I tested couple of live wallpapers from market place, they all works.
[Touch CDMA Android Development] Shidell:
Can you put up this version as source/.so?

Thanks much man--great work.
[Touch CDMA Android Development] Shidell:
Alright, just made the change you detailed and recompiled, here's those changes and the source for such. Going to implement this into a new build of 2.1 Eclair.

Everything looks great so far--elevation (appears) accurate, and the first bearing was 270 degrees, which is beyond what was previously possible. I haven't tested Google Nav yet, but I'm willing to bet that's working well, too. More on that later.

Great work man, this is fantastic. I'm going to tenatively call the latest "v1.5" to tracking sake, and I'll update the first post.
[Touch CDMA Android Development] jnadke:
The libgps_zImage.zip file already contained the libgps.so.

Your file is out of date unless you grabbed the new files from androidhtc. I made other changes in the kernel and libgps to get the accuracy values.
[Touch CDMA Android Development] Shidell:
I grabbed the last source files you put up, previous to posting the changes from / 3.6 to / 4. Did I miss additional changes between those two?
[Touch CDMA Android Development] jnadke:
I commited all the changes to the official androidhtc repo (http://xdaforums.com/showpost.php?p=5437670&postcount=85)

http://androidhtc.git.sourceforge.net/git/gitweb.cgi?p=androidhtc/gps.git;a=summary

Unfortunately I had some issues commiting the kernel changes to the kernel tree.

The better thing to do is figure out how to embed my zImage into an nbh file.

nbh = zImage + initrd

There's probably a build script somewhere.
[Touch CDMA Android Development] jnadke:
I looked at androidhtc, and Martin did put a compile script for making nbh files.

Unfortunately it requires Wine + some windows files.

Your 1.5 is still valid -- it'll work with the 1/19/09 NBH. However my zImage would be the latest version, as I added accuracy reporting to the kernel and libgps.so.
[Touch CDMA Android Development] Shidell:
Hm. So is it best to stick with the last version, as the new one will not work without the updated NBH?

EDIT: Ok, just caught your last post. So you'll have an updated version, once you/Dzo can update the kernel itself (including NBH), at which time we can label the latest v1.6?
[Touch CDMA Android Development] jnadke:
I've updated the kernel, but for now it's just for SD card users, until dzo can make an nbh.

New zImage included here: http://xdaforums.com/showpost.php?p=5437670&postcount=85

Either that or until I bother to set up Wine + kitchen tools (which is how it looks like he made the NBH files).

Either way, likely tomorrow I'll be posting a new kernel + final GPS support.
[Touch CDMA Android Development] Shidell:
Awesome. :) Thanks much, jnadke.
[Touch CDMA Android Development] grktaurus83:
So I got lost somewhere along the way it seems...

Is everything now being decoded from the GPS data directly? Or are we still calculating heading and a few things based on the difference between two points/values?

I thought it was the former, but maybe I misunderstood.
[Touch CDMA Android Development] jnadke:
All fields needed are being decoded correctly (position, heading, speed, bearing, and now accuracy/PDOP), but:

- Time is wrong (way wrong -- year 2030)

- Satellite az/el aren't being decoded

- A few minor things need to be populated

- Test stability / reliability
[Touch CDMA Android Development] mssmison:
If you need help updating the kernel git please get in contact with DZO or vilord.

Great work on this guys!
[Touch CDMA Android Development] jnadke:
Yeah, I already got access to the kernel git.

Unfortunately when I was pushing my htc-vogue branch, it seemed to be taking unusually long so I sigkilled it. Now some files are locked... I gotta talk to dzo to fix it.... my bad.

Full todo list:

Kernel:

-Decode UTC Time fields in gps data and put into struct

-Decode satellite az/el

-Decode satellite fix flags (dzo identified)

-Check if SNR and PRN are correct (SNR seems wrong)

-[Not Important] Attempt to find flags for ephemeris/almanac data

Library:

-Convert kernel struct UTC time to unix time using mktime for timestamp

-Populate satellite az/el

-Populate used_in_fix_mask

-[Not Important] Populate ephemeris/almanac mask
[Touch CDMA Android Development] Shidell:
Now I'm definitely out of my league. Anything I can do to help?
[Touch CDMA Android Development] hideffer:
Everytime I use the above zImage file via Haret, I cannot get a GPS lock. I have replaced my original zImage file with the new one on two separate occations and the result is the same, no lock. When I replace it with an older zImage and update the libgps.so using your bat file and the libgps.so 1.5, I do get gps lock but the 1.5 lipgps.so has me traveling in the wrong direction in google nav at times and the speed is not steady when using GPS Test. Any suggestions?
[Touch CDMA Android Development] jnadke:
Did you update the libgps.so using the one in the zip file? You need to use both the zImage and libgps from the zip file together. Use my script to push the one in the zip file.

There's a GPS_VERSION flag that prevents mingling of dissimilar libgps and zImage files. That's why it doesn't get a lock. It doesn't even run.

My script spits out a timestamp for the libgps.so as the last thing it does. Make sure it matches the timestamp on the file (1/23/09 ~14:20).
[Touch CDMA Android Development] hideffer:
Great, thanks jnadke for the additional info. I can't remember exactly what I did previously but I will follow your instructions exactly when I get home.
[Touch CDMA Android Development] bchi49:
Here's the extract of the script:

adb shell mount -o remount,rw / /

adb push libgps.so /lib

adb push libgps.so /lib/donut

adb push libgps.so /lib/eclair

adb shell ls -l /lib/libgps.so

then reboot device to reload libgps.so
[Touch CDMA Android Development] jnadke:
Oh yeah, I also found you need to reboot before the libgps takes effect. It may be the fact that the fs is mounted wrong (shouldn't matter). All I know is the first time I pushed libgps.so, it wouldn't get a lock. After a reboot, and reload from haret, everything worked.
[Touch CDMA Android Development] jamezelle:
you need a reboot for ANY lib changes to take effect

adb shell stop and start wont do it. im pretty sure its something in the init.rc that needs to be run.
[Touch CDMA Android Development] jnadke:
It's more likely that the libgps functions are already loaded into ram, hence pushing the lib doesn't effect changes.

An easy test would be to see if disabling GPS in location updates and then re-enabling forces a library re-load. That is, assuming whatever android middleware is affected by that checkbox reloads as well.

Either way, I don't care. A simple reboot fixes it :-)
[Touch CDMA Android Development] jamezelle:
lol, well put :)
[Touch CDMA Android Development] hideffer:
I used both the your zImage and libgps.so from the libgps_zImage.zip file, place the zImage in the android folder, started haret and once in myn's donut build, I connected it to my Win7 pc and used your script (bat) file with your included libgps.so file in the same folder. When the script finished, the time stamp said "9436 Jan 23 23:38". I rebooted and I was able to get a lock with GPSTest easily with multiple satellites. I then went on a 6 mile run. Speed and distance were correct when compared to my Garmin Forerunner 305 and heading was also correct. Altitude changed with differing grade but it was always around 400 feet higher that the actual elevation here when compared to topographic data in my area. Altitude may not be working correctly or fixed yet in this libgps.so, IDK. Overall, except for altitude, which I understand is one of the least accurate interpolated data, everything is working much better than before. I will test Google Nav tomorrow and make sure the direction doesn't "flip" like it usually does. Thanks for everyone's contribution,
[Touch CDMA Android Development] vilord:
i tried your stuff out with an nbh i put together (but it has *lots* of changes, so i can't post it yet), and it worked great in the regular google maps view... navigation got stuck and wouldn't do anything, waiting for gps signal...

I was going to try copilot, but i didn't have the right map downloaded, i'll try that tomorrow now that i have my massachusetts map installed...

-Jesse
[Touch CDMA Android Development] dzo:
Kernel git should be fixed now.
[Touch CDMA Android Development] jnadke:
Broke it again :-)

As soon as I get all this stuff commited (and work out this one last Google Maps bug), I'll be putting up the final versions with full gps support. I've managed to decode everything android needs.

Google Nav is working beautifully :-) The one time I tried Google Maps it didn't get a lock the first try. Then I went to Google Nav and back into Google Maps and it worked.

GPS is finished :-)
[Touch CDMA Android Development] grktaurus83:
Did that just happen?
[Touch CDMA Android Development] jnadke:
Here, go nuts.

I did add a constraint that speed has to be > 0 mph before bearing can change. This is to prevent it from going screwy while at a stoplight. At least until better filtering for the bearing can be added. I haven't tested this filter while driving, so it may need to be raised (although I wouldn't want to go over 3/4 mph, so it doesn't affect walking).

GPS may not initiate right away. I get super-fast locks because of AGPS, but because of the accuracy reporting, you won't get a position (or Google Nav to shut up) until you get a full lock. This is because before accuracy was locked to 3.0. Now it's tied to the gps signal.

Otherwise, all the API stuff is ironed out. This means libgps and zImage/nbh's will be compatible once again.

FILES REMOVED (WILL BE POSTING NEW FILES LATER)
[Touch CDMA Android Development] Shidell:
Great work man. :)

Are you able to produce a .nbh, or is Dzo going to put a release out?
[Touch CDMA Android Development] hideffer:
Please clarify. Does the above referenced ROOTFS.IMG file already contain the 2.0 libgps.so changes OR do I have to use the script file to add it? Also is the zImage file above different from the one previously posted? I used Google Nav this morning using your previous libgps.so and zImage and it worked beautifully. It did change directions at a stop but never changed directions while driving.
[Touch CDMA Android Development] jnadke:
Rootfs + zImage = full working GPS (libgps already pushed in).

I provided the libgps for those who opt to go that route (it's probably easier to push libgps than flashing the NAND).

Dzo will have to make an NBH with the zImage.

I can say GPS works very well. At a few stops, the bearing didn't change at all.

There is still one bug left: For some reason on the first boot, the first time you try to use GPS in Google Nav or Google Maps, it fails (annoying because Nav uses GPS for search). You just back out of it, and reload, and it's fine.

Otherwise, I think I'm mostly done here, I want to move onto the RIL and get Location Updates working. I don't think it has ever worked.
[Touch CDMA Android Development] hideffer:
Thanks for the clarification. I'm thrilled you got it working correctly. It seems altitude readings still needs work?
[Touch CDMA Android Development] jnadke:
Other than fudging it, there's nothing that can be done. Someone else said they were seeing it being 400 feet off (though I'd like to know what altitude they're at), I was seeing it being 140 feet off (730 ft vs 870 ft actual). That's 16 percent off.

Maybe if people collect some data for various locations, and it's linear, I can fudge it like srwalter does for lat/lon.

If everyone wants to help, post your steady-state altitude, and look up the altitude for your position here:

http://www.daftlogic.com/sandbox-google-maps-find-altitude.htm

(Please be outdoors, on the ground, and wait a minute or two for best altitude accuracy).

Otherwise, Android produces the same as WinMo for altitude. I assume Qualcomm or HTC wrote the WinMo driver, so they'd know best. I assume this is the best we can do.
[Touch CDMA Android Development] jnadke:
Looks like there _may_ be a better altitude buried deeper in the message.

Can someone do the following (doesn't matter what libgps version):

1. Fire up GPS, get a lock.

2. Close out of GPS.

3. Go to a Terminal on your phone (App List > Dev Tools > Terminal Emulator).

4. Type dmesg and hit enter.

5. Scroll up and look for the big, big long message (fills the screen). Should be the msm_rpc_read_command.

6. Start at the beginning, look for the a3 value (should be 3 values after 3 very large numbers). I want the value just after a3:

bigvalue,bigvalue,bigvalue,num,num,num,a3,altitude < the altitude

7. Now look down toward the bottom of the message, you should see fffffffd sandwiched between two large values:

bigvalue1,fffffffd,bigvalue2,altitude?

Give me both of these.

I'm pretty sure the other value is altitude * 100, in units of meters, but I want to make sure (from someone that is located somewhere else). The second value seems more accurate (more in line with my true altitude).
[Touch CDMA Android Development] hideffer:
I will try to get you that information when I get off work. I was the one who reported the altitude reading being about 400 ft too high. My house is at 85 ft above sea level and GPSTest was reading about 490 ft as was another gps software (run.gps.trainer.uv). Using 6.1 WinMo NFSFan's ROM, I am only off by about 80-100 feet as I recall. Will report later.
[Touch CDMA Android Development] jnadke:
I didn't quite need that much, but thanks.

Yeah, looks like the other one is more accurate (within expected altitude noisiness). The 2nd value might be MSL altitude and the first one WGS84 ellipsoid altitude (which is what GPS calculates). They're close, but they're not the same.