yashsingh1/xdaforums huggingface dataset:
[Touch CDMA Android Development] jnadke:
I'll commit the changes to linuxtogo. However, for anyone testing it:

Can you type 'dmesg' in a terminal/console.

It should spit out a whole bunch of stuff. There should also be lines for the satellite data (you know because it's plain text.

There should be the following lines:

time=, hlat=, llat=, hlon=, llon=

speed=, bearing=

fix=

date=

I'd also like to know the lat/lon gps coordinate of where you tested it (and gave me the hlat, llat, etc data).

Put the location of where you are in google maps, then hit link. You can either past the link, or if you look at the link, the lat/lon coordinates are in the link (which is what I want). If you want it to be private, PM it to me.

This will greatly help me debug any issues that may arise.
[Touch CDMA Android Development] polyrhythmic:
dbl post please delete :)
[Touch CDMA Android Development] jnadke:
Looks like I accidentally decoded magnetic variation rather than date, which is why it's way off! I'll fix that. Also I realized I botched the fix mask. I did ev_mask |= prn-1 rather than ev_mask |= 1 << (prn-1)

It looks like everything else is working fine though. Bearing and speed are being encoded properly. Time looks right.

I'm not sure what's wrong with lat/lon though. Both your outputs are significantly off from where they should be. So much that I can't attribute it to errors in my calculations (I'm only modifying minutes).

I'll probably put out another zImage that fixes the above, and spits out the raw nmea lat/lon for GGA/GSA/RMC to console to see what's wrong. Then I outta be able to fix everything.

Are the nmea messages already in the dmesg logs? If they are, can someone give me them?
[Touch CDMA Android Development] kubino99:
Hi

I've tried to look at this, but seems like also the information that comes from emea are not OK, here are some debugs from kernel with NMEA :

<4>[ 978.430582] GPGGA,221249.0,4810.445170,N,01658.853999,E,1,05,2.2,218.0,M,,,,
<4>[ 978.430634] Handling GGA data
<4>[ 978.430712] time=79969000 hlat=0 llat=966869370 hlng=-1 llng=-1744301630
<4>[ 978.430755] GPRMC,221249.0,A,4810.445170,N,01658.853999,E,,,090210,,,A
<4>[ 978.430794] Handling RMC data
<4>[ 978.430817] date : 0date after : 2000GPGSA,A,3,28,15,27,18,17,,,,,,,,4.5,2.2,3.9
<4>[ 978.430874] Handling GSA data
<4>[ 978.430907] PDOP 2.2
<4>[ 978.430929] GPVTG,,T,,M,0.0,N,0.0,K
<4>[ 978.430954] Handling VTG data
<4>[ 978.430979] speed=0 bearing=0
<4>[ 979.420489] NMEA read. Size 133
<4>[ 979.420567] GPGSV,2,1,08,28,33,053,27,15,65,199,18,27,56,296,22,12,02,223,
<4>[ 979.420612] Handling GSV data
<4>[ 979.420679] GPGSV,2,2,08,18,23,289,28,17,41,111,20,09,,,20,22,10,322,15
<4>[ 979.420717] Handling GSV data
<4>[ 979.430486] NMEA read. Size 212
<4>[ 979.430572] GPGGA,221250.0,4810.445535,N,01658.853712,E,1,05,2.3,220.5,M,,,,
<4>[ 979.430617] Handling GGA data
<4>[ 979.430694] time=79970000 hlat=0 llat=967234370 hlng=-1 llng=-1744588630
<4>[ 979.430741] GPRMC,221250.0,A,4810.445535,N,01658.853712,E,,,090210,,,A
<4>[ 979.430781] Handling RMC data
<4>[ 979.430802] GPGSA,A,3,28,15,27,18,17,,,,,,,,4.4,2.3,3.8
<4>[ 979.430859] Handling GSA data
<4>[ 979.430894] PDOP 2.3
<4>[ 979.430914] GPVTG,,T,,M,0.0,N,0.0,K
<4>[ 979.430937] Handling VTG data
<4>[ 979.430962] speed=0 bearing=0

the NMEA shows 4810.445535,N,01658.853712,E but im located cca 60km east . Do you have any idea what can cause that ?
[Touch CDMA Android Development] jnadke:
Nevermind.
[Touch CDMA Android Development] kubino99:
NMEA position

Hi jnadke

the good news is that the NMEA position is 100% accurate, I've made mistake in calculation. but afterwards used online coordinate converter and the position was OK. now propably I'll be able to see if lon and lat are correctly calculated ;-)
[Touch CDMA Android Development] jnadke:
Here's a new kaiser zImage:

http://dl.dropbox.com/u/58383/kaiser_zImage.zip

I added some more debug info, and changed how lat/lon are interpreted.

Now it prints out GGAlat when it reads the NMEA message, and the lat after it's interpreted (before I multiply by 1000 to convert it to 64-bit scale factor).

adb shell "dmesg | egrep -e lat\|fix\|speed\|date"

should produce everything I'm looking for.

Here's a link of all my changes:

http://dl.dropbox.com/u/58383/kaiser_fixes.patch
[Touch CDMA Android Development] kubino99:
Hi good work, I think I've found where is the problem. In lon and lat has wrong calculation, the problem is in dmin :

lat = deg * 100000000 + min * 1000000 * 10 / 6 + dmin * 10/6

instead of

lat = deg * 100000000 + min * 1000000 * 10 / 6 + dmin * 1000

right changed that in kernel and flashed, will post you the result later.
[Touch CDMA Android Development] jnadke:
I already made that change. the patch file is actually two patches.

also the * 1000 needs to be in there because the nmea data is in min.dmin format or the position will be wrong
[Touch CDMA Android Development] kubino99:
I've used the formula from my post before and found something realy interesting. Longtitue is always correct but lattitute is calculated wrong way even if the math formula is right, I don't understant the numbers :-(

<4>[ 187.694808] GPGGA,072818.0,4810.433407,N,01658.859471,E,1,04,7.9,175.0,M,,,,
<4>[ 187.694863] 48 * 100000000 = 505032704 <---- this one is really interesting
<4>[ 187.694889] deg : 48,	min : 10,	dmin : 433407
<4>[ 187.694928] deg : 16,	min : 58,	dmin : 859471
<4>[ 187.694961] lat : 522421715 -->wrong!	lon : 1698099117 --> this one ois right

deg * 100000000 gives weird number, instead of 4800000000 it gives allways 505032704, i've tried to roubleshoot that but didn't find why it's so.

the code for computing lat and the lon is the same :

int32_t deg=0, min=0, dmin=0;

lat = deg * 100000000 +
min * 1000000 * 10 / 6 +
dmin * 10 / 6;

lon = deg * 100000000 +
min * 1000000 * 10 / 6 +
dmin * 10 / 6;

most propably it's limit of int32_t, but when I've tried to use the following code :

lat = (int64_t) deg * 100000000 +
(int64_t) min * 1000000 * 10 / 6 +
(int64_t) dmin * 10 / 6;

the LD allways throw error with unresolved symbols :-(
[Touch CDMA Android Development] kubino99:
Seems like on kaiser it's no min.dmin but min.sec and the sec is 6 digits number therefore seems the position is right without * 1000

48 10 .433407 N

deg min . sec
[Touch CDMA Android Development] kubino99:
Hi jnadke

finaly the positioning in GPS is correct, I've change the calculation of lat/lon :

/* Lat */
sscanf(args, "%d.%d", &whole, &frac);
printk("GGAlat=%d.%d ", whole, frac);
deg = whole / 100;
min = whole % 100;
dmin = frac;
// Reformat to the 1E8 scale factor
lat = deg * 100000;
lat *= 1000;
lat += (min * 1000000 * 10/6) + (dmin) * 10 / 6;
printk("lat=%d ", (uint32_t)lat);
args = ADVANCE(args);
sscanf(args, "%c", &c);
if (c == 'S')
lat = -lat;
args = ADVANCE(args);

/* Lon */
sscanf(args, "%d.%d", &whole, &frac);
printk("GGAlon=%d.%d ", whole, frac);
deg = whole / 100;
min = whole % 100;
dmin = frac;
// Reformat to the 1E8 scale factor
lon = deg * 100000;
lon *= 1000;
lon += (min * 1000000 * 10/6) + (dmin) * 10 / 6;

if I used the old calculation the position was a bit far from reality. Thank you very much for you effort made on this.
[Touch CDMA Android Development] jnadke:
The compiler can't do mul(long lon int, long long int). It can do mul(long long int, long int). I don't know why (probably because its a clib thing on a 32bit system and there isn't an instruction?). That's why the code was written they way it was.

Then again, I wasn't paying much attention to the compiler error I was getting, I may have misread a long and those 2 above are reversed (which makes more sense). I was trying to do int64_t lat = (int64_t)deg * 1E8. I didn't try int64_t lat = (int64_t)deg * (int64_t)1E8. That may be it.

I guess I assumed it conformed to NMEA spec. I didn't realize the Kaiser put out 6 digits of fractional minutes. That does explain a lot though.

Here's a new zImage:

http://dl.dropbox.com/u/58383/kaiser_zImage.zip

And a new patch:

http://dl.dropbox.com/u/58383/kaiser_fixes.patch

Note: I tweaked your calculation to save some extra math ops. I also cleaned up some warnings generated by nmea.c.
[Touch CDMA Android Development] Shidell:
My handset seems to be having a difficult time maintaining a solid GPS signal for Navigation. I've tried Eclair and also just loaded up Myn's Donut builds, both using GPS v5.0, and I always receive the "Searching for GPS..." message only a few minutes into my trip.

I was using radio 3.42.30 (Sprint), and moved to 3.42.50 hoping it would improve GPS, but it doesn't seem to have much of an effect.

What's a bit boggling is that when I lose GPS signal (for Nav), my phone is still receiving coordinates, and my Google Maps location will update/travel, but apparently not well enough to switch into "drive" mode.

If that isn't clear, typically when driving, you have the moving arrow that indicates where you are and your bearing as you drive. I lose signal, and get a top-down look at the map, with my location marked as little blue dot--and that dot will travel with me as I move, but doesn't report enough information to allow Nav to switch back to "driving" mode, where you get more of a first-person perspective as I go.

Is anyone else facing results like this? Maybe it's the Wisconsin air?

Or perhaps this has something to do with the satellites being picked up/dropped and not adapting for it appropriately?
[Touch CDMA Android Development] polyrhythmic:
Y'all rock!! GPS is fully working on the Kaiser now as well. I'll have to test Nav later when I go for a jog but I got a solid fix in Maps from a fresh install in under 30 seconds.
[Touch CDMA Android Development] hideffer:
Shidell,

Tatnai and I are having the same experience as you with the V5 Libgps. Jnadke was kind enough to posted a new zImage on February 6th (post 72) which I am currently testing and it appears to correct the problem but it is too early to tell. When I have lost gps fix with the new zImage, Google Nav has recovered on all occasions so far and goes back into the 3D view again. So far so good but it appears to lose gps fix more often but it does recover and it is very functional.
[Touch CDMA Android Development] jnadke:
I included the Vogue fix in the kaiser patch. Dzo should be pushing them into the mainline probably today. NANDs should show up after that.

The fix doesn't hurt anything (though I don't know for certain if I actually fixed something....).
[Touch CDMA Android Development] tatnai:
thx, will run it when it is available.
[Touch CDMA Android Development] Shidell:
Hm, thanks for noting that, hideffer.

jnadke, any idea as to what might be causing this behavior? As you noted (and I cited), could it be related to the GPS satellites and how many are being monitored, and then adding a new one, losing two, etc.?

EDIT: I'm slow, just read the update about the new kernel being available. I'll give that a go and see if it makes a difference when it's available.
[Touch CDMA Android Development] jnadke:
Probably not. The fix I did, was checking if the GPS Position message length was greater than 1750 bytes (it's usually 1760 bytes). One day I was seeing some GPS Position messages coming in as ~800 bytes, which is problematic because the new high-accuracy GPS data I'm using is in those 800 missing bytes. The GPS interpreter will interpret this 800byte message as 1760bytes, meaning lat/lon/alt/accuracy values would garbage (not as in '0' values, but as in whatever is in memory, 273 degrees latitude 2859 longitude, etc). If maps gets these incorrect values, all bets are off on how Google Maps decides to fail gracefully (i.e. stop listening).

I never double-checked if the 800byte messages were indeed GPS Position messages, which is why I'm not sure if I actually fixed anything.

There are a number of bugs in both libgps and the zImage that have bothered me for some time (some of which are easily fixable).

In the kernel gps.c: wake_up is being called before spin_unlock. Once wake_up is called, all bets are off on what order things are being accessed. If the GPS interpreter is calling wake_up while libgps is waiting for data, it may run instantly. However, since the GPS interpreter still has a lock, it can't get data, slowing things down. A lot of things may barf. In fact, the gps_tickle function could be getting run in that condition, and it may be causing issues.

In [lib]gps.c: There's a single thread that gets both the satellite and position data. Similarly, there's a single data structure for both satellite and position data. However, satellite and position data is reported to android separately. Also, satellite and position come in from GPS separately. Having both being passed from kernel-to-user space together makes no sense, because there's no guarantees both messages are fresh. Satellite data may come in, and wake_up gets called before the position data comes in, so libgps runs with old position data. Maps might not like this (same time twice in a row), leading to barfing (what you're seeing). The FIX is to have 3 threads: 1 for satellite data, 1 for position, and 1 for a watchdog (to make sure GPS is running and to tickle if we stop getting updates to restart it).

The first one is fixable. The second requires a new GPS_VERSION.

Though, it could be possible to fix the second without a new GPS_VERSION. I've been trying (but temporarily gave up) looking at the satellite msm_read_rpc messages to see if there's a flag that indicates a GPS fix. If there is, it'll be an obvious value that changes when the position RPC messages start coming out, and reverts/goes away when you lose a lock (sandwiching the phone between your legs is an easy way to lose a lock). With this flag, it'd be easy to not report data until the position message comes in (so the data is synchronized and data isn't repeated twice).

If someone could figure the above out, that'd be a big help. The satellite messages are the msm_rpc_read messages that have 31000004,0,4 in them (from dmesg output). Position messages are the 31000004,0,1 messages (the really big messages).
[Touch CDMA Android Development] polyrhythmic:
jnadke since you seem to be active atm, can you build a GPS kernel for Kaiser with the installer-access key as Camera? Vilord changed it to dpad-center in the latest release which does not work for Kaiser.
[Touch CDMA Android Development] jnadke:
Not at the current moment.

Dzo told me he'd push the changes later, so I'd imagine a new zImage/NAND should appear then. I probably won't get around to it before he does.
[Touch CDMA Android Development] dyetheskin:
kudos to the updates,looking forward for a fully functional kaiser build for 2.1
[Touch CDMA Android Development] dzo:
OK, I've pushed all the changes to git and built a kernel and NBHs for all devices and panel types. I also fixed what looked like a problem in board-kaiser-gps.c on line 273.

http://it029000.massey.ac.nz/vogue/files/?C=M;O=D

None of these are tested at all.
[Touch CDMA Android Development] Shidell:
Thanks, I'll test the update on the drive home and report back this evening.
[Touch CDMA Android Development] polyrhythmic:
WOW :eek: dzo you are quick. Thanks, I'll be happy to test it for you :D

EDIT: Well, zImage-11-02-10 can't enter into installer with either middle-button (dpad center) or camera button. Seems to run well so far otherwise, GPS working properly!
[Touch CDMA Android Development] jnadke:
I also had dzo fix the locking issues (item 1 on my list above).

Hopefully it doesn't break anything.
[Touch CDMA Android Development] manu33xtro:
Hi DZO. I use your nbh (480) for my polaris. I can see boot menu when I press vol-up !!

Thanks.
[Touch CDMA Android Development] dyetheskin:
when did you press it? i've tried vol-up,top center,center,half and long press camera on kaiser
[Touch CDMA Android Development] jnadke:
On Vogue I generally hold vol-up during the entire bootup from the moment I power it on.

Try that.
[Touch CDMA Android Development] Shidell:
Testing on the way home seemed more successful, but to be sure, I'll need to test it a few more times.

So far, so good. I'll keep reporting in.
[Touch CDMA Android Development] Dark-Side:
Here, a new zImage with jnadke gps improvement for kaiser and hw3d for eclair.
[Touch CDMA Android Development] polyrhythmic:
wait....what!

hw_3d for Kaiser??? Downloading for testing now.

EDIT: No, hw_3d for vogue, GPS for both. Was worth a try.
[Touch CDMA Android Development] Shidell:
After a stellar maiden voyage yesterday, GPS functionality returned to it's previous ways this morning--dropped signal twice, once with the GPS location updating (but never resuming to Navigation mode, just moving the indicator about) and once where it simply seemed to hang.
[Touch CDMA Android Development] Dark-Side:
Working on my Kais130 :confused:
[Touch CDMA Android Development] jnadke:
Odd, might have to spit out more debug data to see what's going on under the 'hood.

Perhaps I'll put out a version as well that doesn't report new data available until it puts out a position message. Right now it claims new data when only satellite data is present, which could lead to a race condition. Although, in libgps I am still checking if we receive the same time position twice, so I don't think this is happening.

It could also be glitching due to more satellites being reported than sv_info.num_svs. I get num_svs from the data message, however I never clear out the satellites. When you're traveling, you could be picking up more satellites, making num_svs and the satellites in the database not match.

I don't clear out the satellites because some satellite info comes from the position message (azimuth and elevation). The two messages arrive separately. Perhaps I'll just clear out the prn and snr, and not the az/el. Or like I said, only report data back once position data comes in (that makes this way easier).

I guess I'll make a zImage that has more debug data. Then, when it decides to barf, back out of Google Maps/Nav quickly so GPS shuts off. Wait till you get home and dump the dmesg output. Then
[Touch CDMA Android Development] polyrhythmic:
WHOA now that I look again, you're right. I'm able to launch Neocore but it crashes when I click 'benchmark'. Rock on, Darkside.

Do I need to

chmod a+rw /dev/msm_hw3d*

? At what point in the boot process? Can I just add that line into my init.rc/sysinit.rc? Uhh sorry not to threadjack :D GPS is still working well for me, I'll test nav now! :)
[Touch CDMA Android Development] Dark-Side:
I don't do it... Neocore crash sometime for me too. reboot and it's ok
[Touch CDMA Android Development] hideffer:
I have not had this problem with the new zImage until this AM (for the first time) but it would not recover from "searching for gps" until I rebooted my phone and then everything worked well again for the rest of the drive. Mine did not freeze, it just did not recover from the lost lock. BTW the new "night mode" in Google Nav 4.0 is nicely done graphically. It was a pleasant surprise on my way home last night.
[Touch CDMA Android Development] tatnai:
was your sattelite icon locked (not blinking) or searching for a lock (blinking) when it was searching?

I tested this morning (new .nbh up from dzo's site). lost GPS a couple of times with quick recovery. then had one freeze (lost gps, GPS icon began flashing looking for a lock, and entire android froze at that point, had to soft reset). this is different then the problem before where the GPS icon was locked, but google nav was still searching. booted back up and ran it for 20 min, worked normally always regaining a lock. need to test more. will post back.
[Touch CDMA Android Development] jnadke:
Odd that it wouldn't work until reboot. You've explicitly tried exiting google maps and then starting it back up. Though exiting will only shove it to background, try killing it completely using a task manager (try both ways). Next time it gets an outage, wait till you get to your destination (don't crash!), exit google maps, make sure it's killed using a task manager market app, then start it back up. It should re-enable GPS.

Perhaps something is getting screwed up in the PDSM (the gps_tickle function?) and it stops sending all the data?
[Touch CDMA Android Development] polyrhythmic:
Ok, I've got Neocore running and I got a 17.9 FPS score, not bad for an unoptimized 2.1 build :D

Here's what I did, and it seems to make everything smoother overall:

Mount the system read-write, and look for this line in your sysinit.rc/init.rc:

chmod 0777 /dev/vogue_gps

and add after it these two lines:

chmod a+rx /dev/msm_hw3dc
chmod a+rx /dev/msm_hw3dm

I'm going to have my OpenEclair Kaiser build packaged up with these improvements very shortly, if you'd like to run that.

-----

As for the GPS freezes, I'm experiencing them sometimes as soon as I start GPS. I can't run GPSTest at all, but that may be unrelated. When GPS crashes the whole system freezes instantly, and I'm forced to reboot. It freezes so fast that I'm thinking the issue must be in the kernel? I'll try to use HaRET to dump dmesg if I can catch it next time.
[Touch CDMA Android Development] drewden123:
I cannot get GPS to work for the life of me. I believe my vogue was shipped with the MR1 update to lockdown gps, so I flashed to bell 3.42.50 radio and flashed back to android and still nothing. Does anybody know what the easiest/cleanest steps would be to roll back the MR1 update so I can finally use GPS?

I'm running Myn's latest build (NoMoRootfs NAND), radio 3.42.50, and the nbh from 1-30-10 that was updated for opengl.
[Touch CDMA Android Development] tatnai:
did your gps work in win mo? if you did not unlock with hardspl 2.31, just flashing 3.42.50 won't do anything to get gps for you, your gps will still be locked. follow the steps in my nand install guid to flash the unlocker - see FAQs in my sig.
[Touch CDMA Android Development] drewden123:
Yes, I have had the vogue for over a year but got a replacement recently and forgot about the MR1 issue. As soon as I got the replacement I unlocked with hardspl 2.31 and flashed to android NAND, so I didn't even try to use gps in winmo, but it came to me that the MR1 was probably the issue so I flashed to bell 3.42.50 and then back to android but still no luck.
[Touch CDMA Android Development] hideffer:
My satellite was locked (not blinking) when Nav went from 3D to 2D view while it was "searching for gps" but the 2D map was still moving. It never froze but Nav would not go back to 3D view...I rebooted.
[Touch CDMA Android Development] tatnai:
after unlocking, did you flash a gps enabled full carrier rom? just flashing the bell radio only won't do it. if you flashed the GPS enabled bell rom, it would.
[Touch CDMA Android Development] hideffer:
I did exit out of Google Nav completely twice and same behavior when I restarted the app. I also started and stopped GPSTest (good readings with it) and then started Nav again with the same behavior.

Next time I will try killing it with a task manager and see how it works. I had thought just exiting out of Nav would completely stop the gps process since I do not see the satellite radar icon anymore when I am back to the main screen. BTW, is android on the vogue truly multitasking? The reason I ask is, in WinMo, I could have multiple GPS programs running and sharing the same gps information, i.e., google maps, garmin mobile xt, gps viewer, etc. and switch them at will, but it does not appear to be the case with android on the vogue even with a task switcher.
[Touch CDMA Android Development] drewden123:
No, I only unlocked and flashed bell radio. I didn't think gps was dependent on the actual rom, just the radio. So...should I flash to a custom WM rom? it seems to me that the gps would still be locked down if i did this.
[Touch CDMA Android Development] jnadke:
It is truly multitasking, however Google Maps shuts down GPS when it's put into the background to save battery power.

I don't know of any apps that will use GPS when they are put in the background (unless they were designed to). However, as far as I know it is possible to have multiple Listeners in the Java Android API.