[Touch CDMA Android Development] jnadke:
What's wrong?

Position should work (mostly) fine. Try GPS Test.

It's definitely the kernel side, there are still some changes dzo didn't make to the scale factors in nmea.c

Namely, bearing is still at the old (* 4.0) rather than the new (* 10.0). If you update all the scale factors it outta work. Check speed too, it should be speed = nmea_speed * 10.0

The same for altitude.

Other changes:

Fix lat/lon the right way. Dzo just took the old values and multiplied by 556 (the real adjustment should be 555.5, but you can't do floating point math in the kernel).

In reality, the functions should be changed from int lat to int64_t lat (and lon appropriately) in nmea.c (and the callbacks in kaiser_gps.c).

Then the calculation should be

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

10/6 is to convert minutes to the right 'base' (go from scale factor of 60 to 100). dmin doesn't need to be changed (it's already base 10).

Then in the kaiser_gps.c callback (change the function prototypes to be int64_t lat instead of int lat)

state->user_state.latitude = lat;

The new values (latitude) are floating-point values * 1E8, then truncated as 64-bit integers. This is how the Vogue outputs its high-precision data. The Kaiser should be adjusted equivalently to use the same libgps v5.

For NMEA spec:

http://www.gpsinformation.org/dale/nmea.htm#nmea

Here's how nmea.c should be written (callbacks for each of these messages should be created)

GGA - time (break it up as hours, minutes, centiseconds -- seconds * 100), lat * 1E8, lon * 1E8

GSA - PDOP * 10 (currently using HDOP, change it)

GSV - num_sats, prn, az * 100, el, snr * 10

VTG - bearing * 100 (true track), speed (km/h) * 10

RMC - date (you'll need to reformat this as ddmmyyyy):

date_temp = date / 100;
date_temp2 = date % 100;
date = date_temp * 10000;
if (date_temp2 > 79)
date = date_temp2 + 1900;
else
date = date_temp2 + 2000;

or if you're fancy :-)

date = (date / 100) * 10000 + (date % 100) + (((date % 100) > 79) ? 1900 : 2000);

GPS epoch is 1980, so this code supports if a satellite decides to output the wrong date (or if you time travel :-) )

This is where all the data should come from. I've included the scale factors the NMEA data should be multiplied by. I believe you can assume the number of digits after the decimal (sscanf %f should not be done in the kernel -- I'm not sure if it uses floating point registers).

Read decimals in as sscanf(buf, "%d.%d", whole, frac)

I believe you can assume a certain number of digits from that NMEA page for frac, so applying scale factors should be simple, for bearing:

bearing = whole * 100 + frac * 10;

You can't do floating point in the kernel because the register contents aren't saved/restored when the kernel takes over. The kernel can interrupt a user program whenever it wants, so if you do a floating point calculation, the program might crash (or worse, continue operating normally with wrong data the kernel injected).

In addition, in the user_state->state for time:

Copy 'time' to both state.time and state.utc_time (hours, mins, centiseconds).

I left srwalter's code in libgpsv5 to quickly check 'time' first to see if we have unique data before processing it (the vogue would output its data twice per second). Then it uses the state.utc_time to actually report time to Android.

In board-kaiser-gps.c, handle_pos_data function

state->user_state.utc_time.hours = time / 10000;
state->user_state.utc_time.minutes = (time % 10000) / 100;
state->user_state.utc_time.centiseconds = (time % 100) * 100);

One more glitch that should be changed (in board-kaiser-gps.c)

on the line that says if (last)

take the code that zeroes out the sat_state, and put it to the top of the function with

if (index == 1)

I'd highly advise you adjust the kernel itself, because libgps v5 shouldn't need to be changed. All the data the vogue puts out is similar to NMEA, just scale factored for integers. This way, you won't have to push new a libgps everytime you use a Vogue Android System build.

If you make these changes, and send me your board-kaiser-gps.c and nmea.c/h, I promise I'll look at them and fix whatever bugs there are.

These aren't hard changes, but there are a lot.

Sorry, I don't have much time to make these changes on my own. I've known what needs to be changed for a week and a half but haven't gotten around to it (and I don't have a Kaiser to test with). I'm currently typing this during my lunch.