[26.Aug.2011][Dev] GPS Libraries v2.1 with AGPS support for HD2 Gingerbread

sebasmiles · Jun 4, 2011

htcvidi said:
Only for information, i tested this morning the accuracy of information returned by the new driver.
These tests were performed with Copilot.
1 - Latitude, longitude and precision are ok.
2 - Elevation returned is too large.
For example, instead of displaying 165 meters, it displays 220-230. (I can not remember the results with the native driver, i will test this week end)
3 - When i move slowly, my position on the map does not change until i have moved several tens of meters. Then, suddenly it jumps to the new position.

Hope this help.

1) It should've always given a good longitude and latitude, I don't think I have ever heard anyone get something far off.

2) Elevation with GPS has always had high inacuracy. I remember seeing sailing GPS systems telling me I was flying a few thousand feet above water. Its just the nature of the beast due to the way how the configuration of satelites are placed. If the earth didnt exist, you would have satelites on the oposite side which would give you a more precise "elevation" but right now you only see what is ontop of you. Other systems like WAAS can reduce this error alot. As of right now, altitude should be off by a factor of atleast 3 from what I understand so by 30m in the best conditions and escalating quickly once you factor in the VDOP.

3) The true precision in the best conditions should be like 10m. This is close to the natural error of the GPS unit itself, the degree of precision can easily increase this by a few magnitudes and still be considered a good position. Earlier in the thread I explained a bit about how "accuracy" is calculated.

RiNo808 · Jun 4, 2011

I'm just chiming in and letting you ask know that I flashed v1.1 on my At&t inspire and my gps improved...where I was getting 5-6 satellites and 9-10 meters...I'm now getting 7-10 satellites and 6-8 meters...thanks...

Sent from my Inspire 4G

arne182 · Jun 4, 2011

GPS Testing

I have downloaded the fix and will be doing some extreme testing today. Will take my two HD2's out and see the difference between the two tonight.

Thanks for the update, will let you know how it goes.

ozkaya · Jun 4, 2011

RPC calls

OK, I have disassembled HD2 winmo DLL's and here is the result:

(@tytung, proc addresses are commented in the code)

Code:

pdsm_xtra_set_data

LDR     R0, [SP,#0x4C+var_28]
BL      oncrpcxdr_mem_free
LDR     R3, =unk_100B35CC
STR     R3, [SP,#0x4C+var_48]
LDR     R3, =unk_100B35D8
STR     R3, [SP,#0x4C+var_4C]
MOV     R3, #0x1A       /// proc 
MOV     R2, 0x10001     /// vers 
MOV     R1, 0x3000005B  /// prog
LDR     R0, [SP,#0x4C+var_28]
BL      xdr_call_msg_start
LDR     R0, [SP,#0x4C+arg_0]
BL      rpc_clnt_callback_register


pdsm_xtra_inject_time_info

LDR     R0, [SP,#0x50+var_2C]
BL      oncrpcxdr_mem_free
LDR     R3, =unk_100B35CC
STR     R3, [SP,#0x50+var_4C]
LDR     R3, =unk_100B35D8
STR     R3, [SP,#0x50+var_50]
MOV     R3, #0x1E        ///proc
MOV     R2, 0x10001      ///vers
MOV     R1, 0x3000005B   ///prog
LDR     R0, [SP,#0x50+var_2C]
BL      xdr_call_msg_start
LDR     R0, [SP,#0x50+arg_0]
BL      rpc_clnt_callback_register

let me know if you need anything else.

ozkaya · Jun 4, 2011

tytung said:
I finished 95% code of gps_xtra_inject_xtra_data(char* data, int length) and pdsm_xtra_set_data(...) which are responsible for injecting xtra.bin (ephemeris data) to the GPS chip.
But I don't know which RPC call I should invoke.
I also cannot ensure how many parameters in pdsm_xtra_set_data(...) I should use.
RPC server is a black box for me.

Code:

For example, why we use [B]proc=[COLOR="Red"]0xb[/COLOR][/B] in [URL="http://gitorious.org/htc-hd2-android-libraries/libgps/blobs/master/leo-gps-rpc.c#line293"]pdsm_get_position()[/URL]. 293 if(clnt_call(clnt, amss==A6125 ? [B][COLOR="red"]0xb[/COLOR][/B] : 0xc, (xdrproc_t)xdr_args, (caddr_t)&par, (xdrproc_t)xdr_result_int, (caddr_t)&res, timeout))

And which proc should I use in pdsm_xtra_set_data(...)?
Unless someone can find it out, AGPS won't be finished.

proc - the server procedure to call

I saw this post right now, the reason your calling the proc 0xb in pdsm_get_position is because that's its proc in winmo:

Code:

pdsm_get_position
LDR     R0, [SP,#0x60+var_34]
BL      oncrpcxdr_mem_free
LDR     R3, =unk_100B35CC
STR     R3, [SP,#0x60+var_5C]
LDR     R3, =unk_100B35D8
STR     R3, [SP,#0x60+var_60]
MOV     R3, #0xB		///proc
MOV     R2, 0x10001		///vers	
MOV     R1, 0x3000005B		///prog
LDR     R0, [SP,#0x60+var_34]
BL      xdr_call_msg_start
LDR     R0, [SP,#0x60+arg_0]
BL      rpc_clnt_callback_register

I thought you were interested in proc of pdsm_xtra_set_data and pdsm_xtra_inject_time_info, sorry if pdsm_get_position was just for example.

ChrisM001 · Jun 4, 2011

OruxMaps which is my reference navigation app because of it' s stability, doesn't work correctly with these GPS Libaries. It keeps showing the blinking searching for gps icon in the status bar. It would be nice if the GPS libraries would use the same interfaces as the original libraries, so that all apps could work with them in the same way. I'm going back to the original library until these errors are fixed.

Sent from my HTC HD2 using XDA App

Olioaglio · Jun 4, 2011

tytung, this is absolutely marvelous. Thanks a thousand times for your efforts. Just installed your library v1.1 on raf4.0.2 desire hd froyo 2.2.1 and it works just great. Got an instant fix and also icon appeared and disappeared instantly as promised. Also satellites are seen before fix. This is a real step forward on completing native android power on our devices. Will definitely donate you.

Cheers, Olioaglio

Sent from my HD2 with XDA Premium App

tytung · Jun 4, 2011

ozkaya said:

Have you already tried MSM values? Looks easy, but they might work?

Code:

name	 prog	 proc,vers	 function name

0x3000005B	 0x1A, 0x0	 pdsm_xtra_set_data
0x3000005B	 0x1B, 0x0	 pdsm_xtra_client_initiate_download_request
0x3000005B	 0x1C, 0x0	 pdsm_xtra_set_auto_download_params
0x3000005B	 0x1D, 0x0	 pdsm_xtra_query_data_validity
0x3000005B	 0x1E, 0x0	 pdsm_xtra_inject_time_info

Thank you so much.
I didn't get too much free time these days.
I used your proc number yesterday, but I didn't get success so far.
I think the problem may be the wrong parameters of pdsm_xtra_set_data() I used.
I was wondering if the data types of parameters I sent to RPC server were wrong.

Code Review Time:
You can see the complete source code here.
Please help review my code.

Partial code is as follows.

Code:

int [B]gps_xtra_set_data[/B](unsigned char *xtra_data_ptr, uint32_t part_len, uint8_t part, uint8_t total_parts) 
{
    //D("%s() is called", __FUNCTION__);
    uint32_t res;
    res = pdsm_xtra_set_data(_clnt, 0, client_IDs[0xb], 0, xtra_data_ptr, part_len, part, total_parts, 0);
    D("%s() is called: res=%d", __FUNCTION__, res);
    return res;
}

Code:

int [B]pdsm_xtra_set_data[/B](struct CLIENT *clnt, int val0, int val1, int val2, unsigned char *xtra_data_ptr, uint32_t part_len, uint8_t part, uint8_t total_parts, int val3) {
    struct xtra_data_params xtra_data;
    uint32_t res = -1;
    xtra_data.data=malloc(sizeof(int)*4);
    xtra_data.data[0]=val0;
    xtra_data.data[1]=val1;
    xtra_data.data[2]=val2;
    xtra_data.xtra_data_ptr = xtra_data_ptr;
    xtra_data.part_len      = part_len;
    xtra_data.part          = (int8_t) part;
    xtra_data.total_parts   = (int8_t) total_parts;
    xtra_data.data[3]=val3;
    enum clnt_stat cs = -1;
    [COLOR="red"][B]cs[/B][/COLOR] = [B][COLOR="Red"]clnt_call[/COLOR][/B](clnt, 0x1A, 
            (xdrproc_t) xtra_data_xdr_args, 
            (caddr_t) &xtra_data, 
            (xdrproc_t) xtra_xdr_result_int, 
            (caddr_t) &res, timeout);
    D("%s() is called: clnt_stat=%d", __FUNCTION__, cs);
    if (cs != RPC_SUCCESS){
        D("pdsm_xtra_set_data(%x, %x, %d, %x, %d, %d, %d, %d) failed\n", val0, val1, val2, (int) xtra_data_ptr, part_len, part, total_parts, val3);
        free(xtra_data.data);
        exit(-1);
    }
    D("pdsm_xtra_set_data(%x, %x, %d, %x, %d, %d, %d, %d)=%d\n", val0, val1, val2, (int) xtra_data_ptr, part_len, part, total_parts, val3, res);
    free(xtra_data.data);
    return res;
}

After calling clnt_call(), cs is 11 which means RPC_CANTDECODEARGS=11, /* decode arguments error */
Then the phone will enter the reboot loop.
So it's very time consuming to test the new libgps.so.

Logcat is as follows.

Code:

D/gps_leo_rpc(  118): pdsm_xtra_set_data() is called: clnt_stat=11
D/gps_leo_rpc(  118): pdsm_xtra_set_data(0, 1f40, 0, 40832180, 400, 1, 97, 0) failed
D/gps_leo_rpc(  118): gps_xtra_set_data() is called: res=-1

tytung · Jun 4, 2011

ChrisM001 said:
OruxMaps which is my reference navigation app because of it' s stability, doesn't work correctly with these GPS Libaries. It keeps showing the blinking searching for gps icon in the status bar. It would be nice if the GPS libraries would use the same interfaces as the original libraries, so that all apps could work with them in the same way. I'm going back to the original library until these errors are fixed.

Sent from my HTC HD2 using XDA App

I think it should be the app issue.

GPS interface (GpsLocationProvider, etc.) has already changed between Froyo and Gingerbread.
If you have got a GPS lock, but still see the blinking searching for gps icon in the status bar, it may mean that your app, OruxMaps, still use the Froyo method to get GpsLocationProvider.

Google MyTracks is working well with the new libs.

Olioaglio · Jun 4, 2011

Can confirm working all right function of all tested apps so far (igo8, my tracks, cardio trainer, gps status, google maps/navigation, Velox Pro, Satellite AR, location, etc.)

Cheers, Olioaglio

Sent from my HD2 with XDA Premium App

webvan · Jun 4, 2011

Working pretty good here on AmericanAndroid but the altitude is completely off, as it shows 4294966640 meters right now!

arne182 · Jun 4, 2011

GPS Testing

I have been out and about.

For the time (fix.timestamp):
The GPS time is converted correctly to NTP correctly. Syncing with NTP and checked against "GPS Time" shows a difference of about 1 second and sometimes below. Might be the delay in GPS and system and app. Will do more testing but Someone else needs to confirm this.

For the Height (fix.altitude):
Between 40 and 50 m above Google earth's topology map. This has been measured between 35 and 185 m above sea level. Want to hop in a plane soon and check it out at higher altitudes. Should actually compare with a Garmin or similar GPS unit. Can Someone check the difference between Commercial GPS and the new Lib.

Difference between old lib and new lib for height on average is less than 1% and max at 10% again between the heights specified above.

Suggested fix (fix.altitude = (double)ntohl(data[64]) / 10.0f-40)

For Accuracy:
Still I find that the accuracy could still go up at least double. I have been testing in various locations and moving around and comparing to Google map satellite data and seeing if I can move outside my specified accuracy drawn on the map as a circle. I would suggest bringing the accuracy multiplication up to 4.

Suggested fix (fix.accuracy = (float)ntohl(data[75]) / 10.0f * 4)

For the satellites showing up before lock is establishes does work well.

For GPS lock times though it is quite slow. Compared to the old lib the warm start GPS lock time is about 90 seconds for both. But the relock time for the old lib is faster than the new one. This will need more testing as this takes time.

FYI
The "GPS Status" application shows some new information about AGPS being available on the new lib.

Tomorrow is speed and bearing.

P.S.
Thanks for the leap time correction, credit, tytung.

arne182 · Jun 4, 2011

webvan said:
Working pretty good here on AmericanAndroid but the altitude is completely off, as it shows 4294966640 meters right now!

On what rom are you?
Which application shows this?
What is the height at your position? (You can use Google Earth to check this)
Is this a once off error or is this all the time?
Is it fixed by going back to the old gps.lib?

webvan · Jun 4, 2011

arne182 said:
On what rom are you?
Which application shows this?
What is the height at your position? (You can use Google Earth to check this)
Is this a once off error or is this all the time?
Is it fixed by going back to the old gps.lib?

1. AmericanAndroid 05/29
2. Locus but others too, like GPS Status
3. 10 meters
4. All the time
5. Would have to try. A bit of a hasle since I did manual installs with RootExplorer. Haven't figured out how to use the "ROM Manager" with my Dual Boot setup.

Diem · Jun 4, 2011

Tytung, All, many thanks for taking the time getting in to it! Real life takes alot time and same applies for the other way around

Rgds,
Diem

ChrisM001 · Jun 5, 2011

tytung said:
I think it should be the app issue.

GPS interface (GpsLocationProvider, etc.) has already changed between Froyo and Gingerbread.
If you have got a GPS lock, but still see the blinking searching for gps icon in the status bar, it may mean that your app, OruxMaps, still use the Froyo method to get GpsLocationProvider.

Google MyTracks is working well with the new libs.

Hi tytung,

thanks for your quick answer and great job. The developer of OruxMaps said, that OruxMaps is used by many users from rel 1.6 to 2.3.4 and no one reported such problem. The developer himself uses a nexus with 2.3.4 without any problem. Could you take one more look at your libraries to make it more universal usable? MyTracks is not really an alternative to OruxMaps. The latter is IMHO the far better offroad navigation app.

Thanks and Regards,

Chris

memin1857 · Jun 5, 2011

arne182 said:
...
Syncing with NTP and checked against GPS Time shows a difference of about 1 second and sometimes below. Might be the delay in GPS and system and app. Will do more testing but Someone else needs to confirm this.

For the Height (fix.altitude):
Between 40 and 50 m above Google earth's topology map. This has been measured between 35 and 185 m above sea level. Want to hop in a plane soon and check it out at higher altitudes. Should actually compare with a Garmin or similar GPS unit. Can Someone check the difference between Commercial GPS and the new Lib.

Difference between old lib and new lib for height on average is less than 1% and max at 10% again between the heights specified above.
...
For Accuracy:
Still I find that the accuracy could still go up at least double. I have been testing in various locations and moving around and comparing to Google map satellite data and seeing if I can move outside my specified accuracy drawn on the map as a circle. I would suggest bringing the accuracy multiplication up to 4.
...
For GPS lock times though it is quite slow. Compared to the old lib the cold start GPS lock time is about 90 seconds for both. But the relock time for the old lib is faster than the new one. This will need more testing as this takes time.
...
Thanks for the leap time correction, credit, tytung.

I think the fast relock behaviour with old libs was because the old lib didn't know that the gps usage session has ended, it actually restarted where it left off, as if it was suspended/slept. My samsung phone instantly showed loss of sat when going inside a tunnel but with hd2+diem's libs it just froze the signals at the last known level and did not find out about signal loss until several seconds later. (So when you closed the gps app, when you later reopen it it just continued from where it left off and if you are near your last location it took only 2-3 seconds to relock, but now it takes about 10-15) When relocking within short time, old libs just resumed exactly where it left off but new libs seem to do a small reset/restart of some sort. Maybe old libs were doing a "hot start" but new libs it is doing "warm start".
So I confirm cold lock times are about the same but relocks are faster with old libs which seems like a good side effect of wrong implementation

With 1.1 libs:
HD2 gps time is 16 seconds behind my samsung native android phone in GPS STATUS app but EXACTLY the SAME in clock sync app (without syncing with ntp) HD2 gps time is 1 second behind atomic time which also the case with my native android samsung phone. (clock sync app)
SO I confirm gps time is 1 sec behind atomic time BUT that is also the case with my samsung phone. I don't know why my samsung reports 16 seconds ahead in gps status app but hd2 also reported like that with old libs.

My locations altitude is 135 meters in google earth, but around 168-171 meters in gps status of both hd2 and samsung phone. Altuide is OK I guess. I did once see around 412552452453 altitude and it actually caused text corruption in gps status due to too long text but restarting the app (so turning gps off/on) fixed altitude back.

Accuracy is now "generally" similar to samsung phone but not always. With Diem's libs, HD2 showed unrealistically too accurate (reported 1 meter), with 1.0 tytung libs hd2 showed bad accuracy (reported around 22 meters), with 1.1 it seems on par with samsung phone when sat signals are good. (around 4-5 meters accuracy at best) But sometimes the two phones accuracy numbers differ a lot, so I guess hd2 1.1 lib accuracy is OK when you have good sat visibility but reports better than actual when sat signal levels are bad due to conditions.

HD2 sat signal levels are reported lower than the samsung phone. about 5-10db less with hd2. (they were reported higher with diems libs if I remember correctly)

Still, when using nav apps, when you come to a complete stop, your gps speed indicator won't stay at 0, it will flicker at 3-4-6-2 like that, somehow still location reporting changes a little by itself.

GPS status complains about data connection with my samsung phone but agps still works flawlessly so I guess samsung implemented agps differently and it doesn't really matter what gps status app says.

corrsea · Jun 5, 2011

I have been testing this on tytungs nexus hd2 since it was released. I have used igo, sygic aura, copilot and google maps. In addition I have used gps status, gps test and gps aids.
First fix (warm start) varies between 30 to 120 secs. (BTW I doubt if anybody is actually reporting cold starts as this would involve switching the device off for a considerable period or travelling a considerable distance with the phone switched off.)
Hot starts are between 3 and 13 seconds.
All the navigation programs appear to measure speed correctly. Both igo and sygic correctly indicate 0 when at rest. (i'm not sure if they even use gps data when under 5 kph)
IMO altitude is a red herring as i've never come across a gps that could accurately measure this, however all 3 are within a couple of meters of each other.
I have not yet had any drop of signal while navigating.
There does appear to be a lag of a couple of seconds which gives the appearance of my position jumping at slow speed.
I would add that I also had a reasonably good gps with the old libs. The main improvements are that I see more sats 10/11 as opposed to 6/7, the sats are visible prior to lock and the gps switches on and off instantly.

itais · Jun 5, 2011

Hi,

Will this fix work also on Desire HD ?
If not are you planning to make one ?

Thank you in advance,
Itai.

ozkaya · Jun 5, 2011

data types

@tytung,

I had a look at your source code and the documentation.
pdsm_xtra_set_data is originally documented with 8 variable constructor,whereas your implementation seems to have 9 variables and only 4 of them seems to match. Their data types look correct, but for some of the remaining ones you are feeding integer values like val0,val1,val2 and val3. Where do they come from and are you sure they should be integers?

[26.Aug.2011][Dev] GPS Libraries v2.1 with AGPS support for HD2 Gingerbread

Senior Member

Senior Member

Inactive Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Inactive Recognized Developer

Inactive Recognized Developer

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Senior Member

Similar threads

Top Liked Posts