yashsingh1/xdaforums huggingface dataset:
[HD2 Android NAND Development] mcorpuz:
Is anyone in this thread from the US? If so found an app called Gas Buddy and I'd like for someone else use the app to see if they get a lock on their location as I am in an enclosed building and when I launch the app it gives my exact location. GPS does not give me my location when in the building.

Sent from my HD2 powered by HyperDroidGBX
[HD2 Android NAND Development] AngelDeath:
Thats probably cause your using either data or wifi.
[HD2 Android NAND Development] memin1857:
If I edit my samsung phones gps.conf file to standalone (instead of msbased), the download button for agps data in gps status app becomes inactive. FYI
[HD2 Android NAND Development] AngelDeath:
Thats because Standaloneis the same thing as a GPS Unit, it only recieves its signal from the Sats with no help, I stated this when the commands were being discussed. What we want for AGPS to work if memory serves me right is MS Assisted, because MSBased I think is No GPS. Where Assisted is both.
[HD2 Android NAND Development] slbenz:
Gas Buddy works for me without any problem. Indoors or out. At least indoors near a window.
[HD2 Android NAND Development] AngelDeath:
WIN Mo GPS Files

I pulled all the gps files from Windows Mobile for the HD2. Two external programs called agps confirmation and quick gps. Then the rest are win mo files.

There are 3 hidden files so make sure you can see hidden files, and they are:

gpsid.dll, gpssecurity.dll and gps_oem_apiext.dll

But I think the focus might need to be on two folders: gpsdriver.dll and gpsapi.dl.

Hope it helps.
[HD2 Android NAND Development] memin1857:
I know AngelDeath, I was the one who wrote those :)

What I meant was this was additional proof that gps status only causes standard commands to be issued. (It is just a trigger) And conf file affects this.

You are wrong about msbased btw, msbased IS the agps mode we want. Msassisted is one step further, which does the calculation at a remote server by uploading the raw gps data. But this was designed for early devices with low performance cpus assuming remote servers have powerful cpus. HD2 (and any modern phone) has quite fast cpu to do the calculation quickly by itself. MSassisted is unnecessary because it consumes more data, makes the calculation actually slower because of waiting for data connection and transfer, hd2 has a very fast cpu when you think about when msbased msassisted modes were designed.

MSBASED does download and inject the agps data, and calculation is done at the MS (mobile station = your phone = UE = user equipment)

When I turn on msassisted on my samsung, I see alot of data activity. MSBASED works quite well.
[HD2 Android NAND Development] AngelDeath:
I stand corrected, and obviously my memory is fried with all this, sorry for mixing the two up, thought it was the other way around.
[HD2 Android NAND Development] chungkai:
Who really can fix show libgps.so:confused:
[HD2 Android NAND Development] dlsniper:
I've tested this on Tyween's Typhoon rom and think for the moment is ok.

If you let the GPS working 10 minutes / day you will be able to get locks within 2-3 mins after a couple of hours since the GPS is working but without AGPS (scope of this thread).

For the APGS we might need to consider that our radio is called different that one from a native Android device since HD2 is a WinMO device on it's origin.

I've tested the attempts that Charnsingh had on fixing AGPS and from what I've seen he was the closest so far in fixing it (from the public tests I have access to) but he doesn't have a HD2 and he quited for the moment in his tries to fix it.

Maybe someone else could pick his work? I don't know if he shared his sources or not but I guess he could help if needed.
[HD2 Android NAND Development] Mafioso:
From what the little technical knowledge i have...

I was to make out that since the radio for HD2 was designed for WM, it calls different RPC that what is there in Android for reading AGPS data?

So if someone has to fix it, somebody has to rewrite the radio(don't think that's gonna happen/possible) so it calls rpc which android have or somebody has to modify libgps.so, so that it contains the same rpc's which the radio calls for agps...that would only be possible if somebody reverse engineer's Windows GPS drivers/dlls to find out the rpc which are being called by the radio

Is it right interpretation or is there something else too, like agps data not being injected into chipset :confused:
[HD2 Android NAND Development] arne182:
This is probably what gauner1986 has done. But he is not giving out the source code. Will try and disassemble the gpslib.so and see if I can't modify it that way. The GPS is working, its just not working 100%. It might be worth it to go back and check out the drivers for WM.
[HD2 Android NAND Development] Mafioso:
That's bad...just wondering, are driver's/fixes not a part of GPL :confused:
[HD2 Android NAND Development] AngelDeath:
The radio doesnt need to be re-written in my opinion, because rpc calls from what i know are just that, commands, the gps driver I agree needs to be either re-written, or the commands need to be added. Based on what I have seen in the logs, I think its getting the info, I just think it doesnt have the commands to inject the info, because alot of the logs I looked thru in my phone, has inject failed, which will lead me to believe that its pulling the info, but has no idea what to do with it.

Arne, I dont know if you saw, but I already posted the WM drivers, and the 2 EXT programs that was in the HD2 roms. If you need anything else let me know.
[HD2 Android NAND Development] thehustler:
Bump. Any updates on this front?
[HD2 Android NAND Development] maroxxx:
it worked well
[HD2 Android NAND Development] arne182:
Finished GPS testing

The lock times are dependant on how long ago the previous lock was.

With the adjusted gsp.conf there is only a slight improvement over one without.

I do not have enough knowledge to disassemble the dll and create the so with the RPC calls but I am sure we have accumulated enough knowledge to know what is wrong with the current gpslib.so to fix the source code. Getting our hands on that source code has not been easy.

Hopefully the dev's can help.
[HD2 Android NAND Development] AngelDeath:
Thats what i dont understand, why is releasing the source code such a big deal? Obviously its not finished, and I would think that the one who created it and knows its not done would release it so that it could be finished and complete, why hold it hostage for this long when clearly its not complete :(
[HD2 Android NAND Development] QBANIN:
Hi,

I've just seen that my GPSfix app works @ HD2 devices :) so if you want me to develop/add some features to it just say it :)

BTW: This app is available on Android Market. Just search for QBANIN Spica GPSfix
[HD2 Android NAND Development] arne182:
Please Help

Hi Qbanin, thanks for the helping hand. Our main problem is that our libgps.so has not been written properly. Some RPC calls have been implemented so that we can use it on gingerbread but we are missing some for example. The ability to see the GPS satellites before we get a lock. And there is some incorrect calculation with the GPS to NTP time. If you could help us disassemble the current libgps.so and creating a new one with the corrections it would be greatly appreciated. The origional so was done by gauner1986 but he is unreachable for the current source code.
[HD2 Android NAND Development] memin1857:
Guys I have been in Czech Republic for the last week with no data connection available. (I normally live in Turkey) Roaming.

I used gps like 10 times a day. Almost every single gps lock was VERY VERY slow. (Waiting for minutes every time, even within very short time of last lock!)

Back in Istanbul with proper data connection, 50 seconds first lock, a few seconds relocks again.

This absolutely proves that even without complete agps support in hd2, there is some assistance working and the locks are accelerated a lot with proper config files and data connection. Most likely ntp time server syncs are helping a lot.

FYI
[HD2 Android NAND Development] tytung:
I think your thought is not complete correct.

I have studied all the related GPS code from Java, JNI to C source code, and know how the GPS works on Android from the top to the bottom in these two weeks.

In order to implement and improve my new libgps.so, I even studied some documentation from the QUALCOMM.

They are the documentation for an employee of QUALCOMM only, but we can still find them from the Web. :)

All gps.conf settings, including default NTP and XTRA, won't be transferred into libgps.so, so changing them won't make anything different.

If you feel it makes any difference, I believe it's due to the psychological feeling.

To see is to believe.

I will release my new GPS libraries tomorrow.

With my new libraries, you can see the numbers of satellites before getting a location fix.

And more.
[HD2 Android NAND Development] djsolidsnake86:
agps on gingerbread?
[HD2 Android NAND Development] mike2518:
I'm really excited about this development Tytung. Your work its always solid, so I have full confidence in you!
[HD2 Android NAND Development] Mafioso:
Wow, as always awesome work tytung :D

Will these new library also address the missing AGPS/XTRA implementation on HD2?
[HD2 Android NAND Development] :
amazing work tytung, can't wait to test it! I can smell the next donation on my site (;
[HD2 Android NAND Development] AngelDeath:
This is awesome news, And I am patiently waiting for this as I am eager for this, If anything if this works as it should, then my file will further enhance the gps, since it seems the success is much better with agps support.

So do I get first crack at this before anyone? LOL
[HD2 Android NAND Development] ozkaya:
I'm really excited about the "And more" section, hope we get AGPS too! Thanks in advance tytung, you ROCK!!
[HD2 Android NAND Development] :
[28.May.2011] GPS Libraries v1.0 for HD2 Gingerbread
[HD2 Android NAND Development] YZ:
http://xdaforums.com/showthread.php?t=1100114

my gps is working better than on Wm now, lol :D
[HD2 Android NAND Development] memin1857:
I believe in you tytung but this is absolutely not physchological.

I always use gps a lot every day. In prague, locks were definitely a lot slower. If ntp data isn't used then there must be some other logical explanation for this behaviour. Even hot starts didn't work in prague.

I am very excited about your work btw. I'll be testing your libs asap.

Thank you

EDIT: I tested the new libs and they are working great. Based on what you wrote I know it will be much better when full implementation is complete. Thank you very very much!
[HD2 Android NAND Development] tytung:
Well, maybe there'is something I missed.

But I can ensure Diem's libgps.so doesn't get the settings of gps.conf.

My libgps.so get them, but doesn't send them to the GPS chip.

So modifying gps.conf won't affect the GPS chip.
[HD2 Android NAND Development] memin1857:
Time also comes from the network operator. You know the actual radio is seperate from the whole phone hardware including its own processor. For qualcomm, the gps chip is internally integrated and there may be some communication inside radio that we don't see. I am still unsure why even RElocks were slow in Prague (while under network roaming) but I am sure everything gps related were slow. This a blind test so it must not be psychological. (I didn't think about gps behaving differently in prague, but I found it out in like 2 days) I was in Czech Republic for 5 days and even relocks within minutes of last lock took more than a minute. It was torture for me to wait for gps a lot every single time. (I turned used gps like 10-20 times a day)

The weather was perfect and I was in very large open air places, still it took a lot longer than I used to. (minutes) Sometimes in taxis it wouldn't lock at all for the whole trip. (It does lock perfectly in cars in Turkey)

Maybe Control Plane is affecting this and time sync (not ip) is not accurate under roaming, I don't know. I didn't know about your libs before I came back.

I returned to Turkey (home town Istanbul) and instantly gps is working just as fast as before (around 50 second cold locks and a few seconds relocks)

If this information wouldn't help your agps implementation project than just forget it, but I hope it would be helpful.

Due to excessive charges data was disabled in roaming. But I could make voice calls.

For testing maybe if you pull out your sim card and see if it affects your gps? Of course wait for a few hours or travel some distance after your last lock.

About not sending time to gps chip, this is my theory:

I also had some blind tests about ntp. Sometimes I update roms but forget to update my gps.conf (so it becomes us.pool.ntp.org) I use gps for a few days without knowing that gps.conf has changed. (blind test) I find out in a few days that gps is a noticably slower locking and I remember to set the gps.conf back to europe or tr and in the next few days gps locks become just as fast as before. MAYBE android syncs the clock to radio (and gps chip gets the time from inside without us seeing the info because our lib doesnt send the time directly to gps) I agree with you that what most people write/feel are psychological but I always to controlled or blind tests for this matter.

Again, this info would be irrelevant if you fully implement agps. BTW I haven't yet tested the supposedly agps working miui rom for hd2 yet. I know a lot about gps and how it behaves in our hd2s so if miui has some different behaviour I will post it here.

EDIT: I posted about MIUI here: http://xdaforums.com/showpost.php?p=14254070&postcount=104
[HD2 Android NAND Development] chovav:
From my experience there is no change in how long it takes to get a fix by modifying gps.conf. I tried it with and without your fix in The Netherlands (Vodafone) with 3G connection on.. I also changed the gps.conf from stock (pool.ntp...) to NL (nl.pool.ntp...).

both the times a cold boot will take over a minute, hot fix around 10 seconds.

nice work with studying up on the GPS.. you're one of those guys that make me keep my phone another year! :) (ohh just imagine still being stuck on WM6.5 :S)
[HD2 Android NAND Development] tytung:
I don't have unlimited data plan, so I use WiFi at most time.

Having a SIM card won't affect the GPS because I don't enable my 3G/HSDPA mobile network at most time.

In other words, when I tested GPS outdoor, I didn't have any network. (Sometimes I have WiFi if I'm near a building which I can access WiFi).

So I can only receive my location fix from the satellites.
[HD2 Android NAND Development] memin1857:
The network operator time doesn't come from 3G/HSDPA (data channel)

It comes from the WCDMA/GSM channel. So even when data is disabled you WILL get time sync from the cellular network meaning operator. (do not confuse with ntp network time protocol which is based on ip and it requires data) And the clock is inside qualcomm chipset which does have the gps integrated, so most likely gps chip receives the time too. (we can't see the communication inside radio, the actual phone hardware) IP Network is different than Cellular Network. Cellular network has its own communication protocol. I did setup hundreds of cellular base stations in the past.
[HD2 Android NAND Development] tytung:
OK.

So network operator time is not related to gps.conf which is used for getting time from NTP server, right?

Then, as chovav said, there is no change in how long it takes to get a fix by modifying gps.conf.
[HD2 Android NAND Development] memin1857:
It might be possible. Yes we can't inject time to gps chip because we don't have the rpc calls, OK. But from wherever you get the time (ntp or cellular) your phones clock will be updated. I think the hardware clock is inside the phone hardware. (not the hardware that runs linux/android) There is radio hardware that has its own processor its like a seperate computer that handles gsm. Android interfaces with that phone hardware. Think of your device as two seperate computers in one box. So as the clock and the gps chip are likely inside same chipset, gps chip might be getting time from it (from the inside) Since this communication would occur inside phone hardware and not within linux/android we can't intercept it. The software that runs phone hardware is the radio rom. We don't know what it does.

This is purely theory, but only feasible reason I can think of how with our current libs time affects gps locks. From blind and controlled tests I can tell it makes a difference in locking time. It is never full agps because we are not getting the ephemeris data. A lot of peoples comments are either psychological or due to uncontrolled tests, but NOT all of them.

There is ALSO another kind of agps which uses gsm/cellular network to do real agps. It is called control plane, (which means operator) The agps we are trying to implement is user plane (which means you get assistance via IP) If you can instruct the phone hardware it does all the assistance by itself but your operator must support the protocol. This is an alternative way to do real assisted-gps. But it again requires correct rpc calls.

Since the world has moved to user plane agps, control plane is seldom used. But it may be affecting hd2 because user plane agps doesn't work.

The stuff I am talking about is not really important, since if you can implement agps the way vendors implement (user plane agps with rpc calls) then all above information is unnecessary.

It is just possible explanation how gps locks are generally faster when there is proper time sync. We know android DOES get time from ntp/gsm, and DOES update phones hardware clock. Maybe you should look into how the hardware clock is updated?
[HD2 Android NAND Development] tytung:
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.

See more info in this post.
[HD2 Android NAND Development] tytung:
Some info about our processors.

Source: http://tjworld.net/wiki/Android/Qualcomm/MsmChipsets

Source: http://tjworld.net/wiki/Android/Qualcomm/ProcComm
[HD2 Android NAND Development] securecrt:
Yes I have set the GPS to the standalone or agps mode in build.prop file. There is no different in the time to first lock time.

I have several years of experience in develop the GPS firmware. Here is my thinks about the AGPS working in the gpsONE. becasue I am not working in Qualcomm so I just guess. maybe something is wrong.

The A-GPS means assistance GPS. the assistance data includes the ephemeris, almanac and accurate time.

The basic idea is that the GPS chip get the very accurate time and the almanac from the network. then use these data to turn the Acquisition Engine to acquire the GPS satellite , It should take very short time to search all the 32 satellites with these information typically short than 3 seconds. then track the GPS satellite to decode the navigation data from the GPS satellites. if there is no ephemeris you should wait at least 18 to 30 seconds to download all the ephemeris from all satellites then calculate the position (stand alone). but

in AGPS mode the ephemeris is already there , the main thing is to find the data bit stream position, this is used for pseudo-range (the distance from GPS device to satellite) calculation so you will wait very short time to get it if the signal level is very high (CN0 > 30dBm) typically should short than 40ms.

So the mainly work in the android layer to make the AGPS works should include :

1. inject the xtra.bin to the gpsONE engine.

2. get the ntp time and sync to the gpsONE engine. (why not use the GSM and CDMA time? the ntp is more accurate)

I just do some test with your new libgps.so file and it is really better than the previous one.

there is another interface is the /dev/smd27

I use the adb shell command to connect the phone ( running gps status or other gps app)

and run cat /dev/smd27

it will show you the NMEA data which is the raw output of the GPS engine.

when you test the NTP you can use this to verify the time

pay attenation to the GPGGA, 073520.1,.............. sentence

the 073520.1 is the GPS engine 's internal time.

sorry for my poor english.
[HD2 Android NAND Development] memin1857:
Last three posts contain great information. Thanks.

Tytung when you are finished with the code beta testing would be easy since there are a lot testers eagerly waiting and your thread will be flooded with mostly accurate comments.

As long as xtra.bin injection works we can work on snr and accuracy since we have native phones to compare to.
[HD2 Android NAND Development] tytung:
Thanks. Great post.

I'm from Taiwan. My English is also not very good. :o

I compared NMEA sentences (from /dev/smd27) to make sure fix.accuracy in line 368 in leo-gps-rpc.c is not real accuracy.

It should be HDOP value.

Without NMEA, who knows what is data[75]? haha

line 368 　fix.accuracy = (float)ntohl(data[75]) / 10.0f;

In current version, I don't read NMEA from /dev/smd27 in leo-gps.c.

If I open /dev/smd27 and read NMEA from it, libgps.so will cause the phone to reboot.

I don't know the reason so far.
[HD2 Android NAND Development] memin1857:
Agps has finally been implemented. It all started with this thread but released here:

http://xdaforums.com/showthread.php?t=1100114

FYI
[HD2 Android NAND Development] tytung:
Well, I just let dlsniper and AngelDeath know that AOSP source code dlsniper mentioned is for producing lib, not for kernel.

source: http://source.android.com/porting/gps.html

It seems GPS is not related to the kernel.

Does anyone know if Diem released the modified source code of his GPS fix (.so) or not?
[HD2 Android NAND Development] dlsniper:
Heh, like I've said, I don't know much about kernel coding and such, I just wanted to try and help the best I know. Thanks for your interest in this matter ^^

Best regards.
[HD2 Android NAND Development] Mafioso:
BTW HD2 is not the only device suffering from flaky GPS implementation on gingerbread, similar is the case for nexus one

http://www.gizmocrunch.com/android/6108-gps-nexus-one-gingerbread-update
[HD2 Android NAND Development] SNK180:
i think you are in to something. run gps status in 2 different occasions after doing this and got fast locks.
[HD2 Android NAND Development] Lozone:
I'm on Hyperdroid V11.

After a reboot, the first look took 4 seconds.

After first lock, it's between 4 and 10 seconds to get a lock.

This is also all done indoors.

Great Job!

Thank you.
[HD2 Android NAND Development] AngelDeath:
WONDERFUL!!! Now, which file did you use of mine if any, and What rom are you using, cause I have someone in my other Q&A Post, in your location that cant get any locks.

TyTung, first let me start by saying I'm flattered and floored that you think I can do kernels, I wish! Thank you for your input to helping, but you guys are far more good at this then I am, I cant even begin to rank with you guys.

Having said that, Based on my reading, the gps.h and the gps.c are part of the kernel, and you have to created a shared lib. But not knowing how a kernel works, wouldnt the first step be to put these files .c and .h into the kernel so the code is there and then create the shared library? And how useful or un-useful would the huashan rom that was posted help in this?

And lastly isnt Diem's gps fix for gingerbread?

Grab an Oar buddy, cause I'm in the same boat LOL

So Gingerbread has the same issue. I still say the Huashan Rom might be some insight, or a android phone/rom that has support to be looked at?

Thank you for letting me know!

Now I just wish I can get the same results for everyone, then I'd be happy, but its one more step in the right direction to make people happy.