yashsingh1/xdaforums huggingface dataset:
[Touch CDMA Android Development] kallt_kaffe:
Yes it's based on the 26/4 code, my current version is updated with the latest 29/4 and I'm going to let it sit i GPS Test over the night and post a new build tomorrow if it survived the night.

It honestly works so much better now. Not just that the freezing is gone. That problem is related to the parsing code of the satellite info that is currently disabled. But I also found a bug which made it drop a lot of information which explains the sometimes long delay between coordinate updates. I've also polished the NMEA parsing to drop corrupted information and some other things. Before I could get really wierd date and time readings from time to time and sometimes all date and time fields in GPS Test turned to zeros and stuff like that.

Apart from the missing satellite data it seems rock solid right now.
[Touch CDMA Android Development] jfg69:
I'll post back tomorrow and let you know how it works for me. What info can I give you that may be of help?

On a non-related note, I noticed when hex editing a mention of battery being 2700, when its a 1350.. would changing that in the .nbh have any effect on the battery readings?
[Touch CDMA Android Development] kallt_kaffe:
Dunno really, I'm optimistic and I expect it to run fine for you. If it crash you can try to get the /proc/last_kmsg and post the last bits of it here.

Your guess is as good as mine. 2700 (which is 2x1350) is the default value and I've just put it in IF someone want to try to mess around with it. Someone asked for it and I added it.
[Touch CDMA Android Development] mrkite38:
So, is any of this work applicable to the vogue side?
[Touch CDMA Android Development] kallt_kaffe:
No. The Vogue GPS code is different. Doesn't the Vogue GPS work fine allready?
[Touch CDMA Android Development] berardi:
The GPS loses signal in navigation mode
[Touch CDMA Android Development] kallt_kaffe:
What kernel version are you using I know DZO did some GPS fixes for the Vogue on the 5th of April: http://git.linuxtogo.org/?p=groups/...it;h=e1f9fb67448ebea3463d0a56b628db6c910b9594
[Touch CDMA Android Development] berardi:
I'm using the April 27th version. I haven't tried to use navigation in a while though, so I'll try it out again.
[Touch CDMA Android Development] erpocoyo:
Tested with Sygic Navigation and now don't loses signal. ;)
[Touch CDMA Android Development] kallt_kaffe:
Latest (Final?) Kaiser version posted here: http://xdaforums.com/showthread.php?t=660158

Satbars fixed and back. Works really well IMHO. :)

Btw, which GPS code are the Polaris using? Does this fix also apply to Polaris users or are they using the Vogue GPS code?
[Touch CDMA Android Development] kallt_kaffe:
Now to the next GPS issue...

Neither the Kaiser, nor the Vogue has an electronic compass.

Still if I install some software to read Sensors it believes it has one. Some GPS softwares like c:geo and GC Droid can be told to always use the GPS for compass values but other softwares like Google Maps reverts to electronic compass when movement drops to something like 2-3 kph.

It can easily been seen as the marker turns upwards (north) as soon as you walk slowly or stop.

Is there a reason why we pretend to have electronic compass and accellerometer? Or can we easily remove that sensor? If not, can we forcefully insert the GPS heading into it somehow?
[Touch CDMA Android Development] kallt_kaffe:
On my Kaiser it turned on the Airplane mode then I got a Force Close. I'll try changing the source instead. If it works like I hope it will then maybe it could be controlled with a kernel parameter. I went geocaching today with my new GPS code and while the GPS works flawlessly it suffers badly from static navigation so it's useless for me. As long as you keep a steady pace it works just fine but if you stand still for a while and then starts walking you have to walk 40 meters or so before it starts updating your position correctly again.

This also exactly what to expect if it is running in mode 2 so it's working "as designed".
[Touch CDMA Android Development] jnadke:
I used to have some code in there (I have some in the Vogue), that only updates the direction if the speed is > 0. This worked for the most part in maintaining direction when you were stopped.

Compass can only be calculated from GPS velocity. GPS Velocity is actually calculated from different information than GPS Position.
[Touch CDMA Android Development] kallt_kaffe:
You missed my point. GPS calculated direction and velocity as from GPVTG is not the problem. The problem is that some software switch to Magnetic Compass sensor for direction when you move slow enough. Google Maps is an example of that.

This is normally a good thing (and how most "real" GPS units with electronic compasses behaves) but in our case we don't have a Magnetic compass (electronic compass) so our non-existing compass reports bearing 0 degrees all the time.

In some software I can switch between using the GPS reported bearing or the compass reported bearing by choice but others automaticly switch to compass bearing at somewhere around 2-3 kph.

I guess that the Vogue should have the same problem? If you start Google Maps and start walking in a straight line in a fast pace you get the marker to point where you are going. Slow down and at some point it will start switching between point in your movement direction and north. Move even slower and it will always point north. If I do the same in a software where I can force it to not use the electronic compass then this will not occur.

I've tried this in both polymod 2.1d and Myn RLS4 and the behaviour is exactly the same. I also tried renaming the sensors.trout.so to sensors.trout.s_ in polymod 2.1d but it had no effect.

Any ideas.
[Touch CDMA Android Development] kallt_kaffe:
I realized this is not kernel code, right? I guess hexediting libhtc_ril.so may be the easy way to go if I want to experiment with this.

And I can confirm that msg.msg[6] in the rpc call was not the GPS mode. It sucked just as bad when I changed that to 1. However I've changed msg.msg[18] to 1 instead now but I haven't had time for anything more than a short test. I need to try it out a bit more but the short test gave me some hope.
[Touch CDMA Android Development] kallt_kaffe:
New kernel version here: http://xdaforums.com/showthread.php?t=660158

I was so occupied with testing the GPS function that I did not notice untilo today that the official 2010-04-29 code broke audio on my Kaiser. I have now reverted this commit: http://git.linuxtogo.org/?p=groups/...it;h=e31a36fc22b4d122261eb6d99596584854234459
[Touch CDMA Android Development] kallt_kaffe:
Found more problems with the satellite data parsing. New version here: http://xdaforums.com/showthread.php?t=660158 (Kaiser)
[Touch CDMA Android Development] cb2002:
kallt_kaffe, I think two or three version back of your kernel I was able to get network / cell phone tower location showing up on my Kaiser with Myn's warm donut. It showed a wide blue circle when I open up Google Maps immediately even before searching for GPS, same thing with Navigation, immediate wide area location then more precise location as GPS lock.

Then I upgraded to later version and it went away. Any idea?
[Touch CDMA Android Development] kallt_kaffe:
No idea... I've never ever had cell tower location work and I can't think that any code I have touched has anything to do with it.
[Touch CDMA Android Development] kallt_kaffe:
Now, here's something to try for those who are fed up with the "static navigation" (GPS mode 2) in Android.

Background

Default in WinMo the Kaiser GPS is configured in way that makes it behave in a way that is often called "static navigation". Start Google Maps. Take a walk and walk in a steady pace for a while, then stop. Stand still for a minute or two and notice how your position slowly moves a bit furter and then stops. Start walking again and notice how your position won't change until you've moved a bit. The distance can vary. I've seen everthing between 10 to 70 meters. Then the position "snaps out" of "static navigation" and starts updating again.

In Android-Kaiser this behaviour is the same. OK for car navigation, sucks at anything else.

WinMo fix

Now in WinMo you can change this registry key:

[HKEY_LOCAL_MACHINE\Software\HTC\SUPL AGPS]

"GPSMode"=dword:00000002

to

[HKEY_LOCAL_MACHINE\Software\HTC\SUPL AGPS]

"GPSMode"=dword:00000001

Do, that, restart the phone and the "static navigation" is magically gone... Stop and your position stop. Walk again and it instantly starts updating.

Possible Android workaround

I'm currently HaRET booting so I took a walk yesterday with Android running. I made sure I was experiencing "static navigation". Then I restarted the phone into WinMo and made sure the "static navigation" was still pestering me.

Then I used a Registry Editor (Solace v3.1 comes bundled with one) and changed GPSMode to 1 and restarted my phone. Fired up Google Maps and made sure "static navigation" really was gone and there was no sign of it.

While having Google Maps running (with GPS fix) I fired up HaRET and booted into Android. Fired up GPS Test and had an instant fix. Fired up c:geo (geocaching application) and locked onto a nearby geocache. Tried a few walk, stop, walk and no sign of static navigation.

I need to do some more test to be really sure I wasn't just lucky.

Testing is time consuming and if anyone else want to help, then please try this and report back. If it works then also try booting WinMo and start Android without first using the GPS in WinMo. It will likely help to know if the GPSMode is sent to the GPS at (WinMo) boot or when starting the GPS for the first time.
[Touch CDMA Android Development] kallt_kaffe:
jnadke, there is a strange GPS hang that can occur sometimes that I cannot find a reason for.

Example: Application that is using the GPS is running. You get a mail and bring down the notifications and enter gmail through that. While you are reading the mail the GPS icon is still on and when you return to the GPS application it hangs. You can exit to the launcher by using the home button but any GPS software your start hangs. Only way to resolve is to restart the phone.

The above example happend to me yesterday, but it's intermittent. Also there are some variations. Sometimes the GPS icon is off, sometimes it is flashing. Sometimes it is trigger by a mail, sometimes by a phone call and sometimes just by using a software that turns the gps off and on quickly between different parts of the software. But it always leave the GPS application and any other GPS application you try to start hanging.

My guess is that they hang when trying to enable the GPS but I can't find anything in the kernel code that would possibly do that so I suspect that the problem may be in the libgps code. Since the GPS icon usually stays in it's last status when this happens I assume that it may be the GPS disable that fails somehow? Once I tried to turn on "Airplane" mode when this happend but the statusbar didn't even change to indicate that unless I rebooted the phone.

Have you seen this behaviour on the Vogue? I suppose it should have the same problem if it is the libgps that is causing it? Any ideas where to look, all the thread and mutex thingys are new and confusing for me.

What do I need to do to be able to compile my own libgps.so? I've done a git clone so I have the source and an Android.mk file.
[Touch CDMA Android Development] jnadke:
Fortunately GPS is one of the easier things to compile.

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

Pretty much check that out to a directory, source build/envsetup.sh, and compile it using 'mm'.

You do need a compiled SDK (which you have already). You probably already have it checked out in vendor/htc/libgps. You can do a mm there, if it isn't already compiled.

I don't have an initial clue as to why it's crashing in that scenario. Lately for me with Google Maps, GPS has been a bit more glitchy (temporarily freezing the phone when GPS first starts). I haven't tried abnormally closing a GPS app, or switching to a different app while GPS is running.
[Touch CDMA Android Development] kallt_kaffe:
Could someone with a Vogue confirm that this (attached) kernel works? I've done some changes to the accuracy calculation for Kaiser and I made the same changes for the Vogue but I want to make sure it works before I push my changes to the official kernel source.

Background

Both the Vogue and the Kaiser/Polaris GPS kernel code sends the pdop value to libgps.so. The problem is that Android applications treats this value as EPE or propably even HEPE (in meters).

PDOP = Positional Dilution Of Precision (3D)

EPE = Estimated Position Error (3D) (in meters)

HEPE = Horizontal EPE (in meters)

PDOP is a combination of HDOP and VDOP.

HDOP = Horizontal DOP

VDOP = Vertical DOP

You can have a low HDOP and a high VDOP and that would give you a high PDOP but unless you are landing a plane in thick fog most people only care about HDOP.

DOP is not the same as accuracy in meters but since it is how we use the PDOP value at the moment Google Maps can tell you that your position is accurate with a 2 or even 1 meter margin. This is of course a lie.

Solution

Calculating a good EPE propably needs more information than we can get but I've made a simple calculation that I'm sure is at least a lot closer to the truth than just using the PDOP value.

As I understand PDOP=1 is about as good as it gets so a simple EPE calculation would be to multiply PDOP with the best our GPS can perform under optimal conditions. I believe the best a non WAAS/EGNOS GPS can perform is an accuracy of around 3 meters so a optimistic and simple EPE calculation would be EPE=PDOP*3.

However I think most consumer GPS units actually shows HEPE so a better approach would be HEPE=HDOP*3. Although I've noticed that HDOP values as low as 0.8 so HDOP*3 would go as low as 2.4 meters which isn't realistic.

So what I am currently using is HEPE=HDOP*4 and I've compared side-by-side with my Garmin Nüvi and the numbers seems to be realistic. It's propably still a bit optimistic but it'll do.

Compared to my Garmin units the value is a bit jumpy as it is a realtime calculation every second and I believe the Garmin units has a "slowness" built into their updating. So I've added a mild averaging calculation to keep the worst temporary peaks and dips away.

End result: HEPE = (OLDHEPE*3 + HDOP*4)/4

Remember it's not a fact, it's estimated position error but it "feels" much better than before.

Why do this the kernel?

The proper way to do this would propably be to send hdop to libgps and let libgps do the hepe calculation but in order to keep compability between the current libgps and older and later kernels it's just simpler to have it done in the kernel. I've changed the variable names in the kernel and if someone ever make a new version of libgps then pdop could be renamed to hepe and everything will be fine. It's just a cosmetic change.

So please, try it on a Vogue and let mw know if it works.

EDIT: Attached the file...

EDIT2: Updated the file to a new version, changed to formula to HEPE = (OLDHEPE*3 + HDOP*5)/4 and also fixed a rounding error.
[Touch CDMA Android Development] kallt_kaffe:
Well, actually I do not think I have the SDK. I have some toolchain that allows me to complile the kernel. But I'll look into it when I get time.

Another question. Is the is assumption correct?

Android uses sv_info.used_in_fix_mask to know if there is a satellite fix or not.

If that is true then we have an issue. At least on the Kaiser. For some reason the NMEA data on the Kaiser sometimes reports some sats as 255 in the fix mask and sometimes all the sats are reported as 255 even though there is a fix and we have PDOP, HDOP and VDOP.

Some selected lines from NMEA dumping I did when debugging the Kaiser GPS code:

<4>[ 491.233115] NMEA:GPGSA,A,3,255,255,255,255,255,,,,,,,,5.6,5.6,1.0|48
<4>[ 492.143134] NMEA:GPGSA,A,3,255,255,255,255,255,,,,,,,,25.5,25.5,25.5|51
<4>[ 499.172591] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,25.5,25.5,25.5|48
<4>[ 1106.173044] NMEA:GPGSA,A,3,255,255,255,255,255,,,,,,,,11.6,7.4,8.9|49
<4>[ 1111.180564] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,2.8,2.6,0.9|45
<4>[ 1112.180684] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,25.5,25.5,25.5|48
<4>[ 1113.174582] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,25.5,25.5,25.5|48
<4>[ 1142.191105] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,2.8,2.6,0.9|45
<4>[ 1143.182450] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,25.5,25.5,25.5|48
<4>[ 1148.171932] NMEA:GPGSA,A,3,255,255,255,,,,,,,,,,25.5,25.5,25.5|45
<4>[ 1170.200618] NMEA:GPGSA,A,3,255,255,255,,,,,,,,,,2.9,2.7,0.9|42
<4>[ 1178.190896] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,3.5,3.4,0.9|45
<4>[ 1179.182905] NMEA:GPGSA,A,3,255,255,255,,,,,,,,,,3.5,3.4,0.9|42
<4>[ 1181.172916] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,6.1,6.0,0.9|45
<4>[ 1200.190619] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,13.4,10.0,8.8|47
<4>[ 1207.180652] NMEA:GPGSA,A,3,255,255,255,,,,,,,,,,6.0,5.9,0.9|42
<4>[ 1209.183299] NMEA:GPGSA,A,3,255,255,255,,,,,,,,,,25.5,25.5,25.5|45
<4>[ 1233.180508] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,25.5,25.5,25.5|48
<4>[ 1254.200737] NMEA:GPGSA,A,3,255,255,255,255,255,255,,,,,,,4.9,3.5,3.4|51
<4>[ 1256.200632] NMEA:GPGSA,A,3,255,255,255,255,255,255,,,,,,,5.3,3.9,3.6|51
<4>[ 1265.191846] NMEA:GPGSA,A,3,255,255,255,255,255,,,,,,,,5.5,4.1,3.6|48
<4>[ 1269.200623] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,8.6,5.4,6.6|45
<4>[ 1270.181719] NMEA:GPGSA,A,3,255,255,255,255,,,,,,,,,8.6,5.4,6.6|45
<4>[ 1273.174559] NMEA:GPGSA,A,3,255,255,255,255,255,,,,,,,,5.8,4.7,3.4|48
<4>[ 1279.191961] NMEA:GPGSA,A,3,255,255,255,255,255,,,,,,,,5.6,4.1,3.7|48

The above lines whould create an empty fix_mask and if my assumption is right it would fool Android into thinking we lost the fix.

EDIT: I've made changes to avoid a zero fix_mask for the Kaiser just in case, but you may also want to do some logging on the Vogue to see if it use the same kind of reporting even though it is not using NMEA.

EDIT2: I'll checked the Vogue code and it gets the event mask directly so it propably does not suffer from this issue. But if you have problems with sudden temporary loss of fix then you may want to add some logging of the ev_mask and some other element that is only reported when there is a fix and compare the results.
[Touch CDMA Android Development] berardi:
Jnadke, does your Maps Navigation still get stuck on "lost signal" at times? Mine has been decent but still does it sometimes.
[Touch CDMA Android Development] kallt_kaffe:
No Vogue users here at all?
[Touch CDMA Android Development] mrkite38:
vogue user stuck at work with no GPS reception here... :) sorry m8
[Touch CDMA Android Development] kallt_kaffe:
Oh, well, maybe I should go ahead and push the changes anway. It't not likely that it would break anything.
[Touch CDMA Android Development] berardi:
Apologize, I'm away from my home computer / 512 mb card so I can't flash right now :( Would love to try it when I get back if no one else can get to it. It's a .nbh right?
[Touch CDMA Android Development] kallt_kaffe:
Both NBH and zImage included. I've pushed the changes now anyway. But let me know if anything got broken and I'll change it back.
[Touch CDMA Android Development] berardi:
Thanks for your work!
[Touch CDMA Android Development] tatnai:
i'll flash it tonight when I get home, stuck inside without gps reception.
[Touch CDMA Android Development] inertone:
will the nbh work on donut?
[Touch CDMA Android Development] kallt_kaffe:
Yes if you use a hexeditor or loserskaters NBH editor and change it to Donut.
[Touch CDMA Android Development] inertone:
oh awesome!

just edited using loserskaters NBH editor

lets see f this works!

will i get a signal even if i had NO gps working prior to flashing?
[Touch CDMA Android Development] kallt_kaffe:
Could some Vogue users please confirm that the kernel I just posted here works fine on the Vogue. The changes to the Vogue GPS code are minor but it would be nice to know if I broke anything before I go ahead and push the changes.
[Touch CDMA Android Development] kallt_kaffe:
Nevermind, I've pushed the changes now.
[Touch CDMA Android Development] jnadke:
I put rootfs with libgps-2.2 up. Should be correct.
[Touch CDMA Android Development] jamezelle:
so you need new nbh files, the three i made were for 2.1
[Touch CDMA Android Development] jnadke:
Nope, kernel-2.1 is compatible with libgps-2.2.

I can change the number if you want :-)
[Touch CDMA Android Development] jamezelle:
no its cool :)
[Touch CDMA Android Development] jnadke:
I put up one last rootfs-2.2-fixed.

I verified that libgps-2.2 was in the /lib folders. I also fixed some file permissions.

In reality, these are libgps and zImage V4.0 (there's a version flag in the files that makes sure they're compatible, and it's at 4 right now).
[Touch CDMA Android Development] hideffer:
Not Working Correctly For Me

Here is some feedback on the latest zImage and libgps2.2:

I am using the SD method and replaced the zImage from zImage-libgps2.1.zip and rootfs.img from rootfs-libgps2.2-fixed.zip into my android folder. I ran haret then launched GPSTest after full boot. I do see satellites but speed and bearing does NOT change when walking and my altitude reading was about 1,409,110,004 ft. The gps time was correct. I rebooted and still the same result with no speed or heading change and erroneous altitude readings. I went back to the previous version from the development thread and it is working as it should (except for the altitude being off by around 400 ft).
[Touch CDMA Android Development] nabicat:
I've flashed the new nbh and loaded rootfs with libgps2.2. GPS status now reports an elevation of 429496704 m. Any suggestion on what I might have missed?
[Touch CDMA Android Development] dmulligan:
I've got the new NBH flasshed and the new rootfs.img file installed. GPS works great now. Google earth and GPS Test both show me at 1186m. Well I think there was a 1m discrepancy. I am happy! Thank you

jnadke: In the first post you said that we can flash rootfs.img. I am new to this, is that possible or did you mean copy the file to the microSD card?

Thanks!
[Touch CDMA Android Development] jamezelle:
copy it to your card and create a blank file named rootfstonand
[Touch CDMA Android Development] jnadke:
Edit: NEVERMIND!

There was a bug with handling negative altitudes, it should be fixed now!

Negative altitudes are perfectly normal, GPS usually estimates low. Just means you guys are probably in Florida or something.
[Touch CDMA Android Development] mrmedz:
Works great!

Thanks for the fix. Great work!
[Touch CDMA Android Development] plemen:
Great work on the gps lib jnadke!
[Touch CDMA Android Development] tatnai:
Think it was the rootfs that was the problem. Using zimage 2.1 and rootfs2.2 all is well. Donut on sd with ext2.
[Touch CDMA Android Development] c0wb0ycliche:
Hey, I am running Myn’s Warm Donut on a Verizon XV6900, running from the SD card.

I followed the instructions on the first post, and put the new zimage and rootfs in my android directory, but when I open maps or Nav I still get searching for GPS or wating for GPS and it doesn't connect.

If someone could point me in the right direction I'd be much obliged.
[Touch CDMA Android Development] jnadke:
Try again with 5.0.

I use Myn's ROM too and I can say it definitely does work. I posted a new zImage and rootfs.img
[Touch CDMA Android Development] jnadke:
New version posted!

Should hopefully be the last one. There was a regression bug with handling negative altitudes. Apparently I reverted the shared header file and the altitude got changed from signed to unsigned.

Because of this I also had to increment the GPS_VERSION flag in the files (so you can't use the wrong zImage/nbh with the wrong libgps).

I took that opportunity to revise my file naming. The current GPS_VERSION is 5, so the new one is 5.0