yashsingh1/xdaforums huggingface dataset:
[Touch CDMA Android Development] jnadke:
It's not accurate, but it should be close enough for practical purposes. He's basically calculating the hypotenuse of the latitude and longitude difference. The speed will be off by 5-10%, but I'm refraining form putting too many unnecessary calculations that would slow things down in the code.

As far as reverse engineering the GPS chip, you'd have to talk to srwalter about the best way to attack it, since he has experience. I'd assume he had Windows set up the GPS device, then probed registers, or use the Qualcomm debugging tools to probe what windows is doing (dunno how far the debug tools can go), but he may have figured it out elsewhere.

It may be possible to see if it can be turned on through radio commands, since these things support e911. I was looking at this when I was looking at fixing non-GPS location-based google maps reporting.
[Touch CDMA Android Development] jnadke:
Also, I found your error:

deltaLongitude = location.longitude - last_lat;
adjLongitude = sin(deltaLongitude) * cos(location.latitude);
adjLatitude = cos(last_lat) * sin(location.latitude) - sin(last_lat) * cos(location.latitude) * cos(deltaLongitude);
location.bearing = atan2(adjLatitude, adjLongitude) * 360 / (6.282);

Should be:

deltaLongitude = location.longitude - last_lon;
adjLongitude = sin(deltaLongitude) * cos(location.latitude);
adjLatitude = cos(last_lat) * sin(location.latitude) - sin(last_lat) * cos(location.latitude) * cos(deltaLongitude);
location.bearing = atan2(adjLongitude, adjLatitude) * 360 / (6.282);

Note: You mixed up last_lat and last_lon on deltaLongitude (which is why it wasn't working before). I also swapped adjLongitude and adjLatitude to the way it was before in that code.
[Touch CDMA Android Development] jnadke:
Here's a corrected vogue_gps.c:
[Touch CDMA Android Development] hideffer:
How Do I Incorporate Your Corrected Vogue_gps.c File?

Excuse the newbie question but how do I incorporate the corrected vogue_gps.c file into libgps.so? I would like to use ABD File Explorer to replace the old libgps.so. .

I see that the libgps_source_v1.2.zip file contains a vogue_gps.c file but I don't know how to create the corrected lipgps.so file after replacing it with your corrected vogue_gps.c file. Thanks and I only have a Win7 PC.
[Touch CDMA Android Development] jamezelle:
it has to be compiled in with the source.....just be patient
[Touch CDMA Android Development] Shidell:
Good catch, jnadke--I see that you changed the nautical miles/meters conversion from 1853 to 1852 as well. Was that just slightly off?

Anyhow, the compiled new library (v1.3) is now available on the first page. :)
[Touch CDMA Android Development] dzo:
Good work with this so far but I think it can be improved.

I think that the speed, bearing and altitude are sent in the rpc message from the A9. I've changed the kernel to include the raw values but your library will need updating.

See here:

http://git.linuxtogo.org/?p=groups/...ff;h=16a3f61f24732bf636688c43696fc2ff5021bbab

It just sends the raw values so you will have to figure out what to do with them. It looks like the bearing may be in degrees*4 and the speed in kph.

I also think you need a git repo for this library, there's one here:

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

It's very out of date, so just replace it with your current code and make changes from there. PM me if you need access.

Thanks.
[Touch CDMA Android Development] dzo:
OK, I made a start at changing the library to use the new kernel interface, it's pushed to the git in the previous post, not tested properly yet though.
[Touch CDMA Android Development] jnadke:
Thank Martin! I wasn't sure if the the data was pushed out through another message, or if srwalter just hadn't decoded it yet. Looks like it was the latter.

It should be pretty straightforward now to change the rest.

Question: Does librpc work on the vogue?

I was pondering porting the GPS functions to userspace. I understand there must be an interface to access the rpc from userspace, which is how Qualcomm makes their proprietary driver. The main benefit is responsiveness, since then we can ditch the threaded design.
[Touch CDMA Android Development] dzo:
No, librpc doesn't work because the rpc interface on 7x00a devices is very different. It would be possible to get userspace rpc working but I think it's probably better to keep it in the kernel. I think the only reason google doesn't put it in the kernel is so it can be proprietary.

I tested my new lib and it seems to work but I haven't tested speed and bearing (I'm pretty sure the values will be wrong).
[Touch CDMA Android Development] stickus:
I love seeing all this coming together, but I'm having trouble pushing the new libgps.so to /lib . Even though I have used adb many times to push files to my system, I can't for the life of me mount /lib as read/write. I continuously get an error telling me: "failed to copy '~/Downloads/libgps.so' to '/lib/libgps.so': Read-only file system". I'm using Ubuntu 8.04 and have an up to date version of adb from the 1.6 SDK... any suggestions?
[Touch CDMA Android Development] jamezelle:
in linux

adb shell mount -o remount,rw /lib
adb push ./libgps.so /lib/donut/libgps.so
adb shell mount -o remount.ro /lib

if eclair replace /lib/donut with /lib/eclair
[Touch CDMA Android Development] stickus:
Thanks for the prompt reply, but now I keep getting:"mount: can't find /lib in /proc/mounts"

If it helps, I'm using a fresh install of plemen's HeroBlend Donut ('cause it's fast and sexy :) )

What am I not doing right?
[Touch CDMA Android Development] jamezelle:
well then just try

adb shell mount -o remount,rw /lib /lib

if that doesnt work try

adb shell mount -o remount,rw / /

but dont remount it ro after!!! wait till you do a reboot to set the mounts right after you are done, you never want to remount root("/") as read only :p :rolleyes:
[Touch CDMA Android Development] stickus:
Awe-some! That did it. Thanks!
[Touch CDMA Android Development] myn:
What if it's put into /system/lib ?
[Touch CDMA Android Development] jnadke:
Nevermind, I didn't notice you already incremented GPS_VERSION...

I'm also guessing accuracy/evpe/ehpe is burried in one/three of those 4 pad values. I guess perhaps I'll get to work setting up a build environment...
[Touch CDMA Android Development] Shidell:
That's probably for the best. :) I'm in over my head here (I've only taken an intro to C course thus far). My original ambition was simply to add something to the effect of the "last_bearing" to help smooth things out; clearly you and Martin have a much better understanding of what needs to be done here.

I'd be happy to continue contributing, compiling, etc. in any facet I can. (I'd love to learn more about this, and what better opportunity?) Clearly you've got pretty strong knowledge in this field, so you'd make a lot more progress if you could make changes independently.

If I can help along the way, be it with setting up your build environment, compiling intermittently, etc., just say the word. :)
[Touch CDMA Android Development] r3dpnt:
Well, ****.

I was using ADB File Explorer to push the new lib and thought it worked. But I just did an 'ls -l' on on my lib directory and the gps lib is dated 12/5, so i guess i was still using the old one.
[Touch CDMA Android Development] bzo:
sounds like some great new developments on the GPS front!

Though soon to be obsolete, FWIW, the latest 1.3 version is working a lot better. Navigation was working pretty well this morning. Lost signal after about 8 miles though and didn't come back.
[Touch CDMA Android Development] jnadke:
Eh, it may take me a while to find the motivation. This is what I would do:

1. Copy the vogue_gps.h from the kernel source to the libgps.so tree:

vogue_gps.h

2. In send_position_data modify the DEBUG messages to print out our fake speed/bearing values and dzo's new speed/bearing values.

3. Upgrade to the new kernel (or build it). Run GPSTool to collect some data. Check /sdcard/dmesg to see what the values are. Figure out the scale factors (keeping in mind our values have some error).

4. Replace our values with the new ones, scaling the data to the right outputs.
[Touch CDMA Android Development] dzo:
I've made some improvements, seems to work OK now.

The speed and bearing don't get reported immediately after it's found the position because it needs a bit more information so give it some time.

I've been testing it with an app called GPSTest, I don't know if it works with Google Maps navigation.

libgps.so is attached

Note that you need a new kernel for this and it won't work on kaiser or polaris yet.

I've put vogue nbh files (with -gpstest- in the name) on my site.
[Touch CDMA Android Development] Shidell:
Thanks Martin, I just flashed your 1-19-2010 NBH. I'll see if I can get this working to some degree for the drive home so I can post results.

EDIT: I can confirm that the new library with the latest NAND doesn't appear to be working in Google Maps--it is constantly "Waiting for GPS...". I'll push the v1.3 library to see how it seems to react, if only to update the first post with details so others don't get mixed up.
[Touch CDMA Android Development] dzo:
All i can think is that it needs the speed and bearing always reported, try this:

speed should be more accurate too.
[Touch CDMA Android Development] Shidell:
I can confirm that the last package does work with the kernel and with Maps. Additionally, I put together a new Eclair 2.1 build (v1.1) which includes this library. Google Maps got a GPS lock faster in Android than I've ever seen before--it was almost immediate.

I'll test this on the drive to work tomorrow (~20 miles) and report back. Looks promising so far!
[Touch CDMA Android Development] myn:
You guys have made outstanding progress on this.

Thanks so much for your contributions. ;)
[Touch CDMA Android Development] Shidell:
I compiled the code I changed; it seemed to lock as well, but as far as coordinates/positioning, I'll have to wait until tomorrow morning to test it out.

Dzo, I tried your library again on the drive home, and this time the bearing was accurate (no longer facing the wrong degree/bearing). Needs more testing--maybe my first shot was a fluke?

Anyhow, here's the changes I made as a .so. I'll give a whirl tomorrow and see how bad I mucked things up. :)

Also, I'm pretty green with linux yet, so I've never used a git hub/repository previous to pulling down Android. I'll try to learn that and get the hang of updating the libraries you linked to.

Additionally, I noticed that the code I've modified includes '/r' statements, as if a new line character, on the git repository. I'm guessing I caused this by editing the files in Visual Studio. Does this affect your environments? Sorry for the trouble.
[Touch CDMA Android Development] jnadke:
Dzo's code is most correct, I'd stick with that. I'm not sure what the cause of the stuck bearing was.

Ideally, we want the bearing reported from the GPS receiver directly, as dzo has created, keeping in mind that bearing is only accurate when we're moving. The code I created was a hack to simulate bearing, however it can't even come close to what the GPS receiver produces. That's because my bearing code is sensitive to position noise. The GPS bearing is derived from velocity/speed, which is in turn derived from the carrier doppler, which is far, far more accurate than position.

I'm setting up a build environment to help fix the GPS library.
[Touch CDMA Android Development] Shidell:
Fantastic. :)
[Touch CDMA Android Development] dzo:
Yes, I can't see how this can be more or less reliable than it was before since it's not really doing anything different.

I'm sure there is more info in the result from the pdsm_get_position rpc call that we can use too.

here is an example:

rpc_read_command(86d,0,2,31000004,0,1,0,0,0,0,5,19da000,8,1,da3,c
,8,ff97830f,1f0f340,387e3e2a,a,3,5,a3,24a,331,42,1,0,5,1,0,0,0,0,0,0,0,0,0,0,0,0
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0
,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,7,4
2400000,b08a82,0,0,1c8,0,10,27,4398,e7,213,0,19,20,26,2b6e,259,28b,0,13,b,20,ffffeb26,8,34a,0,2e,1e,1d,ffffd715,1f2,2f0,0,2c,16,1d,ffffb9de,ff,175,0,3b,1f,19,fffff8c1,f2,158,0,25,e,19,ffffd5fc,252,2ca,0,41,1e,1e,ffffd7d2,1c7,2c1,0,2c,e,1e,ffffd678,226,105,0,27,b,29,ffffeb2a,3e2,1e7,0,1c,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,78,0,4,1,1,0,0,0,0,0,0,0,0,0,ffffffff,250c3cc5,4,1158dc77,360,13f,24f,b37,1,2,15,5,ca8,103952a,b,16,12,e0202400,0,0,1,1,7,10,14,3ab,20,34,58d2,b,f,69fc,1e,15,32e5,16,10,e91,1f,50,453d,e,22,291d,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,ffffffff,0,0,0,0,0,0,0,ffffffff,0,0,0,0,0,)

This is using 7 sats 0x10,0x20,0xb,0x1e,0x16,0x1f,0xe and it seems to be reporting lots of stuff about them.

Near the end, the 0xe0202400 is a bit mask saying which sats are used for the fix I think and then each sat has 2 numbers e.g. 0x14,0x3ab for sat no 0x10. I don't know what these are but perhaps they can be used to get the azimuth and elevation. Earlier in the message are some more numbers about the sats, e.g. for sat 0x10 there is 27,4398,e7,213,0,19.

Android wants to know which sats are used in the fix and also the azimuth and elevation.

Out of interest, does anybody have working agps in android, I think this should be handled by the A9 but mine never worked in winmo.

I'm away for about a week after tomorrow so if somebody else wants to do some work on this stuff it would be good.

Thanks,
[Touch CDMA Android Development] jnadke:
Where's the end of the header on that message (start of the data?) I assume it's 6 bytes long, then 7 pad values, then lat/lon/time. Also, through what mechanism did you output it (looks like you intercepted it earlier).

Decoding the GPS receiver data is better for speed and bearing. There are 2 signals in GPS, code (~1 Mhz) and carrier (~1500Mhz). Position information is generated from the code signal, but is subject to some error. GPS tracking is done by creating a fake signal that you should see, and matching it with what you actually see. You then slide the fake signal until the two match up. Unfortunately this matching process contains some error (the circuitry that measures the difference between these signals can do so only so fast). Really good gps receivers can match these up to within 1 or 2 percent of each other. Ours can probably only do this to 3 to 5 percent, optimistically. The full error of a GPS signal is 300 meters, so 3 to 5 percent of that is 9 to 15 meters. 3 GPS signals are needed to report position (the 4th time), fortunately combining these signals does reduce the error a bit.

This error is partially why, when you stand still and look at the output in GPSTool, your position moves around a lot (usually around half an arcsecond, 1 arcsecond = 30 meters). Keep in mind GPS on these receivers for your benefit is a side-effect. GPS is there to meet e911 standards, which is about 90 meters of position error.

The carrier signal gives a initial place to search when finding GPS, among other reasons. As above, the receiver creates a fake carrier, subtracts it from what it sees, and the code signal should be left. However, by the same way cops measure your speed, GPS receivers have to account for doppler drift. They have to modify the GPS fake carrier very accurately to account for you moving, or GPS can't track at all. As a side effect of this measurement, you know your speed. Combine 3 satellites, and you know velocity (velocity = speed with direction). Hence that's where speed and bearing comes from. This measurement is about 500 times more accurate than the position one (GPS velocity is accurate to ~10 cm/sec).

However you can't use the carrier for position, because it's not unique, meaning you can't tell the difference between one GPS satellite and another, and it's subject to all sorts of jumps (cycle slips). However, it can be averaged, giving you speed and bearing.

There you go. For all practical use, what we were doing is fine, but that's why they're different.
[Touch CDMA Android Development] Shidell:
That's fascinating. Interesting how technology can captivate oneself.

Is there more to be done beyond Dzo's implementation? For build purposes, I'm going to list his library as the ideal implementation (v1.4) for anyone using the latest NAND/zImage--at least until I hear from you or him regarding whether more needs to be done (or will be done.)
[Touch CDMA Android Development] jnadke:
There's very little value in azimuth and elevation. They would be there purely for diagnostic reasons, and provide little use for navigation. Satellite az/el is actually computed from your estimated position, hence it's subject to the same error as position.

I'm not sure if AGPS is working, but I do get a fast fix (<10 seconds), so I assume it is. Otherwise normally a fix should take about 30 to 60 seconds.

The main things that need to be done:

1) Make sure bearing / speed reporting are working properly.

2) Find accuracy or evpe/ehpe (1 or 2 values depending how it's reported, should be easy, because it generally continually decreases from the time GPS is turned on).

3) Fix lock-up issues. I assume there's some issues with the software watchdog in the library (or some hardware watchdog is turning GPS off, and we need to turn it back on (or reset the hardware watchdog timer). Can someone tell me if it locks up repeatedly? After about the same amount of time?)

4) Possibly report az/el.
[Touch CDMA Android Development] jnadke:
Actually it's my job. A majority of the information in making a GPS receiver is on the internet. 90% of it is in the freely available GPS ICD-200.

A neat fact is that in figuring out the doppler, consumer GPS receivers are locked to under 999mph (by order of the US government). Beyond that and it won't track. This is so a foreign government can't strap a TomTom to a cruise missile.
[Touch CDMA Android Development] Shidell:
lol--that is crazy, but makes sense. So do you work for one of the major GPS providers, then, to have all this knowledge regarding integrated GPS functionality?
[Touch CDMA Android Development] Shidell:
Updated the first post with new information regarding the current state of the kernel & GPS library.
[Touch CDMA Android Development] jnadke:
Gah, my stupid internet provider has been down all day. Probably won't get around to working on it till next week now.

Guess I might as well ask: When you were compiling libgps, what android repo did you check out (latest, donut, cupcake, etc)?

Checked android out from the repo last night, and got a nice little error compiling trace_reader.cpp. Bah.
[Touch CDMA Android Development] Shidell:
I followed the demo and made a "mydroid" directory of cupcake, and later pulled down Eclair.

Note that Eclair right now is v2.0.1, at least that's what AOSP is providing.

I don't think the libgps library is build-specific, I've compiled it in both the cupcake and eclair directories and it seems to work on 1.6-2.1 just fine. No idea on 1.0-1.5, though.
[Touch CDMA Android Development] dzo:
Yes, it works fine on 1.5 too, you don't need to build all of android, just the c library (bionic). do ". ~/mydroid/build/envsetup" and then mm to compile only the gps lib.

To get the rpc messages just type dmesg from a console, either using adb or on the phone using connectbot or similar.

Looking at the messages again, it looks like there may be another set of numbers before the sat info with more precise position.

Here's what I have so far:

still:

250e7811,4,114f7ff3,7e1,0,0,0,1,2,16,12,82a,103952a,19,1b,a,

250e7d5a,4,114f8008,7f8,0,0,0,1,2,16,12,910,103952a,19,1b,a

250e7ece,4,114f8030,7fe,0,0,0,1,2,16,12,9ec,103952a,19,1b,a

walking:

250f9d58,4,114cdd0b,317,25,44,ce2,1,2,16,1a,fc8,103952a,22,39,2e

250fa9a3,4,114cd689,30b,22,3f,d9d,1,2,16,1a,1090,103952a,22,39,2e

250fbc8f,4,114cd269,313,33,5f,dce,1,2,16,1a,1158,103952a,22,39,2e

change direction walking:

250fc9b0,4,114ccb55,31f,22,3f,d47,1,2,16,1a,1220,103952a,22,39,2e

250fd458,4,114ccab8,32e,20,3c,dca,1,2,16,1a,12e8,103952a,22,39,2e

250fd5d5,4,114cced6,324,f,1c,438,1,2,16,1a,13b0,103952a,22,39,2e

250fd22f,4,114cd611,318,f,1b,47e,1,2,16,1a,1478,103952a,22,39,2e

driving:

250b7d44,4,115d9b06,347,1ac,319,aed,1,2,15,5,730,103952a,c,13,f

250b9775,4,115cdaec,353,1a6,30e,ae8,1,2,15,5,802,103952a,c,13,f

250bb22f,4,115c1f81,364,1ae,31d,aef,1,2,15,5,8c0,103952a,c,13,10

looks like it goes something like:

lon, 4, lat, alt, speed1, speed2, bearing, time and date

103952a is 17012010, which was the date.

These appear after a 0xffffffff before the final set of sat info.
[Touch CDMA Android Development] myn:
You guys rock :).

This thread is a great example of collaboration.

So is there going to be a new rootfs release coming as well that incorporates this new libgps?
[Touch CDMA Android Development] jamezelle:
editeddddd
[Touch CDMA Android Development] hideffer:
This version is working the best so far in terms of not changing directions at a stop or while driving.
[Touch CDMA Android Development] jnadke:
Here's a new zImage (1/20/10) and libgps.so (v1.4)

Nothing fixed, same as before, but zImage for people who use SD.

I haven't tested gps out yet (zImage works fine).

Edit: zImage in a future post.
[Touch CDMA Android Development] myn:
Thanks man :)
[Touch CDMA Android Development] jnadke:
Tested GPS.

My observations:

Speed seems to be spot on.

Bearing was being reported wrong. It was about 65 degrees for due east, 130 degrees for due south (walking, not as accurate), and 254 degrees for due north. I ploted this and it matched an error almost perfectly of 0.7095 for all 3 data points (well 4, origin = 0, 0). This means there's a problem with the scale factor, currently he's dividing by 4.

Altitude seemed to be off by a little more than a factor of 2. I was seeing2400 feet when the actually altitude around here is 900 feet. I'll have to check this outfurther.

I'll look at the data and figure out what's wrong. If someone else wants to download GPS Test (in Market) and confirm this, let me know.
[Touch CDMA Android Development] Shidell:
I can confirm that the bearing is almost consistently off; in driving tests with Google Navigation, it almost constantly points me roughly +315 degrees, or about 45 degrees "left".. it seems to hold to the left, regardless of travel North or South.. which is confusing, because one would assume it would have an error to East or West, not just "left", unless the problem with the bearing is being off by X degrees constantly.

Google Navigation is also tending to revert to "Searching for GPS...", and my point actually hard locks when this happens and requires as physical reset.

Have you experienced any issues with the walking test and Market app.?
[Touch CDMA Android Development] jnadke:
I think I figured out the actual scale factor for bearing:

// Bearing output is normalized by 360 degrees and shifted 10;
location.bearing = (float)data.bearing * 360.0f / (1<<10);

Nevermind, I'm retarded. This is the far more likely scale factor. That way it's just a bit-shift in hardware.

I'll check out altitude later.

Edit:

C99 drops math.h M_PI, so might need to put this at the top of vogue_gps.c (below the #includes):

#ifndef M_PI
#define M_PI 3.14159265358979323846
#endif
[Touch CDMA Android Development] Shidell:
o_O

/head asplode