Anyone know why my GPS fix is so slow? It takes at least 10 minutes to get a fix..
I'm running - VaniljEclair RLS6
TW,
It really depends on the weather. If you look up and see clouds, it's going to be a while. If it's raining then it may never connect.
It also helps the have the best tools for the job. Use kallt_kaffe's latest kernel, and download and use "GPS Test" for connecting your GPS.
Dukenukemx said:
It really depends on the weather. If you look up and see clouds, it's going to be a while. If it's raining then it may never connect.
It also helps the have the best tools for the job. Use kallt_kaffe's latest kernel, and download and use "GPS Test" for connecting your GPS.
Click to expand...
Click to collapse
It's clear outside so its not weather related.
I'm curious what the"GPS Test" tool actually does? and just exactly what the phone is doing causing it to take so long.
Thanks,
The way GPS works is as follows.
In order to know your position on a 2 dimensional plane, you need 2 coordinates, X and Y, however in order to know your position on a 3 dimensional object, you need 3 coordinates, X, Y and Z, what we need to know is our position in a 4 dimensional space, which requires not only X, Y Z and V, so that's a lot of data right there, and to further complicate things, the satellites themselves are in motion, also in 4 dimensions.
Ok if that hasn't messed with your head, consider this, your phone only receives GPS data from the satellites, it does not transmit anything, so how does your phone know where the satellites are? simple, the satellites transmit their position, the time, their velocity and heading, ( actually it's slightly more complicated, but I'm not getting into orbital mechanics, lol).
So in order to be able to fix a position, your phone must download this data from each satellite in view, process and compare it with all the other data in order to get an initial fix.
As if this was not complicated enough, you must also realise that the satellite data is continually transmitting in an updating loop, so if the receiver gets bad data from one sat, it must discard that set and start again.
Once the initial fix is made, it's a simple matter to continually update the devices position, but once the gps is turned off, it may take some time to resynchronise, especially if the user has moved to another location before restarting gps.
To operate with reasonable accuracy, (within a few tens of metres), you must have a good signal from at least 4 satellites, more just refines the accuracy.
So why ten minutes? Well there are a number of factors, weather does play a part, but not as much as some think, typically you will lose lock on the weaker satellites, giving less accuracy.
Surrounding buildings and trees are actually great at blocking GPS signals, so in wooded or built up areas, expect slower fixes, less accuracy, and dropped locks.
Movement, this is actually the biggest problem, if you are in motion during the initial fix period, there is a high probability that your own motion will cause problems, since the gps data may be changing too fast for the device to cope with, which will cause it to continually discard data that may be valid.
All in all, the best practice is to find somewhere stationary, away from buildings and trees, turn on GPS, and just wait for it to lock, it will usually take 5 minutes from cold start, perhaps up to 10 minutes in some cases.
Once the initial fix is established, it takes less time to refix after gps is turned off, since the last data is kept in the device for future reference, (which is why it can take more time to fix if you turn off gps and then move 10K or so before turning it on again).
Winmo has a few advantages over Android for gps, since on WM you can download a 'snapshot' of the satellite data in order to 'jump start' the gps to get a faster fix, that plus cell location and agps make it much faster to get up and running compared to Android on our hardware, which lacks cell location and agps.
What GPS Test does is simply show you a lot more data than you would normally see, satellite positions, signal strengths, number of sats visible, number in use by you. Basically it lets you see that some data is actually being received by your device, how strong the signal is, and if the device has locked to a satellite. I highly recommend getting GPS Test from market if you use gps, used it on WM, and the Android port is just as good, ( I got the paid version, but the free one is excellent too).
Any questions?
zenity said:
The way GPS works is as follows.
...
Winmo has a few advantages over Android for gps, since on WM you can download a 'snapshot' of the satellite data in order to 'jump start' the gps to get a faster fix, that plus cell location and agps make it much faster to get up and running compared to Android on our hardware, which lacks cell location and agps.
...
Click to expand...
Click to collapse
Terrific write up!
So, GPS Test won't help speed up the positioning so therefore there isn't a need to download it unless your curious about any of the other settings, thanks.
Since the WM version was a bit quicker in getting the position by downloading a file is there something in the works to try and incorporate this process into Droid?
After it finds a fix, if the handset suspends is there a need to re-aquire the sats or wait again for the same process?
Thanks,
Well GPS Test won't speed up the initial or subsequent fixes, but it does give a good indication that gps is actually working, and receiving/processing the data, and once fixed, you just close that and start your preferred gps app, which will fix almost instantly since the data is current.
I don't think we have anything for android that does the same as the WM gps app, could be wrong, but have not seen anything yet.
The slowest is the initial fix, after that it usually fixes faster, suspended or powered down, only reinstall/wipe data will usually require such a long fix time again, however as I said, there are a number of factors, movement being perhaps the biggest cause of delay.
However once fixed, Android is comparable to WM, even better in some cases, since I never could get my all time favourite GPS software (trekbuddy), to work in WM, it is great in Android though
I don't think we have anything for android that does the same as the WM gps app, could be wrong, but have not seen anything yet.
Click to expand...
Click to collapse
i also looked and found nothing
The slowest is the initial fix, after that it usually fixes faster, suspended or powered down, only reinstall/wipe data will usually require such a long fix time again, however as I said, there are a number of factors, movement being perhaps the biggest cause of delay.
Click to expand...
Click to collapse
mine also takes forever every time unless i havnt moved and switch apps within 10 minutes.
However once fixed, Android is comparable to WM, even better in some cases, since I never could get my all time favourite GPS software (trekbuddy), to work in WM, it is great in Android though
Click to expand...
Click to collapse
i lose gps on the highway, unlike when i had wimo
i still think its odd that i can see 6, 7, 8 sats for 2 or 3 minutes before getting a lock
Thinking about trying this on a friends Eris, but other android devices get a lock very quickly. The other devices have working tower location, so does the android gps system use the tower location to speed up gps lock?
I'm going to take my friends Eris and turn off all radio functions, then run GPS test to see what happens and how long a lock takes...
Ok, tried a few things on the Eris. In airplane mode, launched GPS test in a lock in under 10 seconds. Restarted the phone, still in airplane mode, and immediatly launch gps test and a lock in under 10 seconds.
Do these other phones have GPS chips have almanac caching or does the OS have some way of storing almanac data to assit the GPS.
As far as I am aware, from previous experience of GPS devices, the last ephemeris data is cached in the device chipset, allowing a faster start up, provided the user has not moved too far, or left gps off long enough to make the data too old. However I do not have enough information to make more than guess that it is hardware based rather than OS based caching.
Cell tower location allows GPS to establish a 3 dimensional fix, (remember gps needs more than 3 dimensions to establish a true fix), not enough to be totally accurate, but within 20-50 Metres, which is ideal for 'seeding' the incoming gps data from satellite, allowing even faster start up, since the gps chipset does not have to do nearly as much calculation and correlation on the data, since it already knows roughly where it is.
So the delay we experience in getting a gps fix with Android on our devices has one main cause, lack of cell tower location, and it's possible that the ephemeris data cache may not be getting processed, if this is indeed cached by the hardware, and not by the OS.
Some of you may have noticed a file called gps.conf in /system/etc
It looks like this:
Code:
NTP_SERVER=north-america.pool.ntp.org
XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
SUPL_HOST=supl.google.com
SUPL_PORT=7276
NTP is a protocol for getting accurate time from servers on the internet.
xtra.bin is asfaik the satellite almanac.
SUPL_HOST is for AGPS.
My guess is that a "real" android libgps uses this information to do a few things to help the GPS out.
1. Give it the current time
2. Prime it with the almanac
3. Use the AGPS data to provide it with correction data etc.
We could do some HaRET magic to monitor what the QuickGPS software send to the GPS chip and make our own QuickGPS tool for android or even build that into libgps.so. It's possible but is it worth the time? I don't know. I would give it a go if I wasn't allready lacking time to do everything I want to do.
kallt_kaffe said:
Some of you may have noticed a file called gps.conf in /system/etc
It looks like this:
Code:
NTP_SERVER=north-america.pool.ntp.org
XTRA_SERVER_1=http://xtra1.gpsonextra.net/xtra.bin
XTRA_SERVER_2=http://xtra2.gpsonextra.net/xtra.bin
XTRA_SERVER_3=http://xtra3.gpsonextra.net/xtra.bin
SUPL_HOST=supl.google.com
SUPL_PORT=7276
NTP is a protocol for getting accurate time from servers on the internet.
xtra.bin is asfaik the satellite almanac.
SUPL_HOST is for AGPS.
My guess is that a "real" android libgps uses this information to do a few things to help the GPS out.
1. Give it the current time
2. Prime it with the almanac
3. Use the AGPS data to provide it with correction data etc.
We could do some HaRET magic to monitor what the QuickGPS software send to the GPS chip and make our own QuickGPS tool for android or even build that into libgps.so. It's possible but is it worth the time? I don't know. I would give it a go if I wasn't allready lacking time to do everything I want to do.
Click to expand...
Click to collapse
Ah, that makes sense, since Agps uses an internet server to prime the gps chipset, and if I recall correctly QuickGPS is similar, but provides the weeks Ephemeris data. Ephemeris, Almanac and Time are the three main data components of GPS, ( almanac being the one I tend to forget about....).
Perhaps changing a few server addresses in gps.conf may provide us with some aggps functionality, but I am now wondering if perhaps agps is 'broken' in our builds, or perhaps I have never noticed any data activity.
Just had a look at the website address http://xtra1.gpsonextra.net/xtra.bin, which allows me to download what I assume is the data file, so what we need to complete the puzzle is, what uses gps.conf, and where does it put the data file?, Also does anything use that data file if present?
GPS is currently pretty much useless in that it just never gets a fix, today I waited 10 minutes and still nothing - I went back to WM to use GPS, so any development in this area would be sweet!
TW,
Not sure exactly what is going on there, last night I installed the latest nbh from kallt, plus his RLS7b eclair build, this morning I started gps for the first time, using gpstest I got a first fix in under 3 minutes, which is faster than average.
Sent from my HTC Kaiser using Tapatalk
zenity said:
Not sure exactly what is going on there, last night I installed the latest nbh from kallt, plus his RLS7b eclair build, this morning I started gps for the first time, using gpstest I got a first fix in under 3 minutes, which is faster than average.
Click to expand...
Click to collapse
I'm using the same setup at the minute, tried GPS this morning and it got a fix on the move in about 5mins which isn't bad, my girlfriends HTC Hero got a fix in under a minute though and it's the first time it has connected and it's true that WM is much faster when quickGPS is updated. Any improvements here are very welcome, maybe i'll have a look into it too.
you could edit gps.conf according to your own pool server
a list of these servers can be found here. May make a small difference for some people.
Please post if this helped getting a quicker fix
http://www.pool.ntp.org/en/
Update:
i used the appropriate time server for my country (netherlands),
i used a fresh device (android had never ran on it, though the android on sdcard has been used on other devices)
i went to the toilet very quick, when i came back there was a fix.
So please go see if this makes a difference for you, and post your experiences in here
I seriously don't think it will matter what you put in gps.conf at the moment. What we need to know is how this is used on a "real" android phone.
I've tried to find some GPS code in the Hero kernel source in the past but found almost nothing and the libgps for HTC devices are asfaik closed source so I guess it's in libgps all the "magic" takes place. (I fact, for Kaisers the it would be more "right" to do our NMEA parsing in libgps instead of doing it in the kernel but since libgps evolved around the Vogue it was made in the kernel to make it appear just like the vogue gps data to libgps.so.)
So I'm guessing that a "real" libgps.so reads gps.conf, get's some data and feeds it to the GPS. Likely with AT-commands. It is possible though that it is the ril interface that does it. We have the source for our ril lib and our gpslib and I know for sure we don't do any prime:ing in the our libgps. (The sources are here: http://androidhtc.git.sourceforge.net/git/gitweb-index.cgi?p=gitroot/androidhtc/bootenv/)
It is possible to do dump stuff with HaRET when you for example enable the GPS (I've done it in the past following instructions from dzo) and also when you run QuickGPS and try to match the information sent with the information in xtra.bin. I also expect we should find it sending the current UTC time which by it self propably could speed up fix times.
Once we know what to do we either build it into libgps or we make an Android app similar to QuickGPS.
In fact, I found some dumps laying around....
At boot WinMo sends the system time to the Radio with this command:
[email protected]=2,21,43,2010,5,12
I would say the format is H,M,S,YYYY,M,D even though values are a bit strange because the files are dated 2010-05-11 but it's possible that the WinMo clock was a bit f*cked up at the moment.
Perhaps our rild is allready sending this (someone should check the source)
Otherwise you could try this and se if it helps:
echo -e "[email protected]=x\r" > /dev/smd0
(replaceing the x with the current time and date of course)
Just tried and it was going on 10 minutes with no fix...
TW,
Have you tried gpstest to see if it's actually receiving a signal at all? It is possible that you have a hardware issue, perhaps a broken antenna connection?
If that were the case then it shouldn't work in Windows and it does... ???
Strange...
Does Android require a data connection when getting a GPS fix?
TW,
I have looked around the threads, and have not found a similar posting. Please no flames if this is a dupe!
I am having a bizarre conundrum on Froyo with the Moto Defy and the stock camera app.
I have not used the phone with 2.1 and so do not know if this is an issue on 2.1
THE ISSUE: Latitude is being recorded into the EXIF data as a negative number. This means 3rd party apps interpret the location as being off the coast of Chile.
So why is this an issue? I AM IN NEW YORK CITY.
Additionally, despite my best efforts to fix this, when the Auto Location Tag function starts up it says "Retrieving City Name" and always returns with "null, New York" as my location.
This occurs with or without GPS enabled, and with or without a satellite lock. It even happens with A-GPS enabled.
Google Maps, and other apps, are able to correctly figure out my position -- even with just WiFi enabled.
Has anyone else encountered this issue?
Update
I'm curious to know the interplay between gps.conf and gpsconfig.xml
I tinkered with both, and now I have a faster lock on GPS satellites.
However, the BlurCamera.apk app still inverts the latitude to a negative number in the EXIF data it writes.
Anyone have any ideas?
luxdesigns said:
I have looked around the threads, and have not found a similar posting. Please no flames if this is a dupe!
I am having a bizarre conundrum on Froyo with the Moto Defy and the stock camera app.
I have not used the phone with 2.1 and so do not know if this is an issue on 2.1
THE ISSUE: Latitude is being recorded into the EXIF data as a negative number. This means 3rd party apps interpret the location as being off the coast of Chile.
So why is this an issue? I AM IN NEW YORK CITY.
Additionally, despite my best efforts to fix this, when the Auto Location Tag function starts up it says "Retrieving City Name" and always returns with "null, New York" as my location.
This occurs with or without GPS enabled, and with or without a satellite lock. It even happens with A-GPS enabled.
Google Maps, and other apps, are able to correctly figure out my position -- even with just WiFi enabled.
Has anyone else encountered this issue?
Click to expand...
Click to collapse
I see, I'm not the only one with this problem. I made a similar thread (http://forum.xda-developers.com/showthread.php?p=11769279#post11769279) because i found this one just today, but what i want to know: did you fix this problem?
edit: lol. nevermind, didn't notice that it was you answering in my thread. but still no fix, damn
See other thread. (short answer: no.)
So its all over the news that Iphones, and Ipads are tracking the coordinates of their users, along with timestamps 24/7 UNENCRYPTED. I was researching this topic and found an article clearly suggesting that the same thing is going on with the Rhodium/Tilt 2, this was hinted at by this site showing HTC Sense's "Privacy" policy, which clearly states that HTC has the right to collect, store, transmit, and share a users location data. So can anyone do some filesystem digging and figure out to what extent were being subjected to this on our phones? On the Iphone you cant turn off the automatic tracking at all, unless you jailbreak the phone. Im wondering if the same is the case for our phones?, also wondering where this location history file could be stored, how much is stored, how much its accessed/transmitted, and most importantly whether its encrypted or not? And anything else that may be interesting. We all have a right to privacy, having an unencypted history of everywhere you've been should be disturbing to anyone, because well, first of all its unencrypted. Second of all, this feels like the gov't's solution to not having to put a chip in each of our necks like a dog, one by one. You want your girlfriend snooping and seeing on a map that you were at the nudie bar? This can cause all kinds of problems in peoples lives. Access to a map like with the Iphones location history is a stalkers dream. Unencryptedly disturbing. So lets figure out how data is used, stored, and gathered on our phones, and what to do about it, based on what the Iphone does I'm not confident right now that turning off the location setting will stop this. Below is HTC Sense's "Privacy" Policy.
From HTC’s Sense Privacy Statement:
"To provide location-based services, HTC and its partners may collect, use, transmit, process, store and share precise location data about your device. Location information may be transmitted even when you are not using a third party location-sharing service. This information may include but is not limited to your device ID and name, device type and real-time geographic location of your device. This location data is collected anonymously in a form that does not personally identify you and is used by HTC and its partners to provide and improve location-based products and services. You may also be able to submit to HTC location data such as “Points of Interest,” voice notes to share with friends, and other information. HTC may also supplement the information it collects with information obtained from other companies. HTC may share geographic location data with application providers when you opt in to use their location-based services. By enabling or using the location-based services or features (such as displaying your phone location, posting Footprints, etc.) and applications that depend on location-based information, you agree and consent to HTC collecting, using, transmitting, processing, storing and sharing information related to your account and the devices registered to your account for purposes of providing such location-based services or features to you. You may withdraw this consent by turning off the “HTC Locate” function in the location settings (as applicable) on your device. Some location-based services that HTC offers, such as the “HTC Locate” feature and remote lock or remote erase functions, require your Personal Information for the feature to work. If you use third party services that use or provide location data as part of the Service, you are subject to and should review the third party’s terms and privacy policy regarding the third party’s use of location data. Location data provided by the Service is not intended to be relied upon. HTC and its partners do not guarantee the availability, accuracy, completeness, reliability, or timeliness of location data or any other data displayed by the Service. The “HTC Locate” feature is intended for your personal use only to locate, send a message to, or remote lock or remote erase your own device. The location-based services are not intended or suitable for use as an emergency locator system."
Turn GPS off, problem solved?
Would using a non HTC/Sense rom solve the problem, if it exists?
I use android, no problems on my end
rhod 110
ryannathans said:
I use android, no problems on my end
Click to expand...
Click to collapse
Hahaha!
Good one.
(Android tracks your location too)
toadlife said:
Hahaha!
Good one.
(Android tracks your location too)
Click to expand...
Click to collapse
I know, not as serious as everyone has made the iphone issue though
With the Iphone, turning off the GPS doesnt disable this, the phone will resort to cell tower triangulation instead, which is something even an old school Nokia can achieve, nevermind our phones. The only way to turn the tracking off w/ the Iphone is to jailbreak it, or take the battery out. Ill bet anything that our phones are the same way. Its so cute having the weather right on your phone displaying the exact town you're in and temperature, but i'm sure after reading that "privacy" policy that thats all recorded somewhere on the phone, coordinates etc. And even if you can somehow be sure the location feature is turned off and not recording, theres got to be a history file still left behind, which needs to get tossed.