Unfortunately, there is no guarantee about being able to get a lock with GPS in a specific amount of time. There are too many variables to be able to do that (the biggest being able to get a good signal from the satellites). You'll also find issues with lots of vegetation, the clock on your phone being wrong, signal bounces off buildings, and (in my experience with an Android phone) rainy weather and thick cloud cover was the biggest interference.
You are quite correct that the software keeps track of where you are from the last time the GPS was turned on (I seem to recall there is a ".getLastPosition()" in the Android SDK that will gives you the most recent position (even from before the GPS module was activated this time around)). But the biggest reason is the GPS wants to be able to keep track of which satellites it might expect to see above the horizon; the software computes orbits and listens for the satellites it expects; it takes much longer for a cold start (ie, you moved a large distance from the last time the GPS was on, or its been several days and the clock on your phone has drifted a couple seconds to a couple minutes) because the receiver has to try and sort out which satellites it is hearing signals from right now. Here's a pretty decent tutorial about how GPS works: http://unavco.org/edu_outreach/resources/how_gps_works/Larson_GPS_MiddleSchool.ppt I've not used the Geocoder functionality, so I can't speak about that. -Matt On Tue, Apr 27, 2010 at 3:13 AM, Fabrizio Giudici < [email protected]> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > My Android application basically allows to record geotagged notes, > with precision (entering exact information, in my case the information > about an observed bird species) and in the shortest possible time. I > am a bit worried about the battery performance of the GPS thing: for > instance, I've measured that MotoNav (the Motorola Navigator available > with the Droid) drains the battery in about two hours of use. I first > thought it was a matter of other things (e.g. the 3D rendering of the > terrain), but disabling it doesn't seem to make a big difference. My > application should be available for use en plein air for several hours > (possibly the whole day), so it must save the battery. So my current > design keeps the GPS off and starts / stop it only when a new > geotagged note is to be entered (optionally, when you get the GPS > fixture, the Geocoder is used to retrieve the location name). > > The first implementation, when tested of the field, was problematic. > The workflow was a sequence of screens "get the GPS location" -then- > pick-the-species (which is done by a couple of screens on its own). > Unfortunately, having to turn on the GPS every time is a pain, since > it takes a few seconds and slows the whole thing down. Things seem to > be much better after a change, in which I reversed the sequence of > screens, but turning on the GPS immediately: in this way, the fixture > is computed in background while the user picks the species, and it > seems that in 90% of cases when you get to the final screen the > coordinates are already there. I'd like to know whether I have some > timing guarantee: that is, supposing that I'm in a place with a good > reception of at least 4 satellites, is there a guaranteed max. amount > of time for the sequence "turn the GPS on and get a fixture" to > complete? While I can't assume the AGPS is always available (there > could be no mobile radio signal), most of times you have collected > another fixture in the past few minutes and didn't move too far from > the past location, and I suppose that the GPS software is able to > remember the latest position, which AFAIK helps a lot in fast > computing the new fixture. > > *** > > Second point, about the Geocoder. For practical purposes in my typical > scenarios, the unique and only geocoder available (which of course I > bet talks with the Google geocoder) is useless, because you often > either don't have a mobile connection, or the radio signal is so weak > that it takes a long time to get results (I'm always puzzled in facing > with the common assumption of most technology providers that > everything that you'll do with a smartphone will be in a urbanized > area with excellent radio signal). Furthermore, the Google geocoder is > good in some circumstances, getting a meaningful name of the location, > while more often it only provides a generic (and useless) "Province of > XXX"; and of course doesn't provide meaningful information in the > context, such as "Observatory #5 in the FooBar Wildlife Sanctuary" - a > thing that can be only implemented as user-provided data. > > Well, the obvious solution is to use another geocoder (I think I > should be able to use my stuff from forceTen, which includes a > Geonames geocoder and the capability of plugging others, so I could > aggregate all the available information). I wonder whether any > existing FLOSS package for managing user-provided locations exists. I > must say I am surprised that Android doesn't offer this feature > out-of-the-box given the strong geo-characterization of Google, at the > point that I've a strong feeling that I was unable to find the right > stuff in the documentation... Am I missing something? > > Thanks. > > PS I'm referring to Android v1.6, which is the platform I'm targetting. > > - -- > Fabrizio Giudici - Java Architect, Project Manager > Tidalwave s.a.s. - "We make Java work. Everywhere." > java.net/blog/fabriziogiudici - www.tidalwave.it/people > [email protected] > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.14 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkvWqskACgkQeDweFqgUGxfWrQCfbaYaFdnA6mofB6v8Ye4KHBRC > GzMAn2je9KzmnYQGtDqn1UL/+VGZDBlO > =WgTi > -----END PGP SIGNATURE----- > > -- > You received this message because you are subscribed to the Google Groups > "The Java Posse" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > > -- Calvin: Know what I pray for? Hobbes: What? Calvin: The strength to change what I can, the inability to accept what I can't, and the incapacity to tell the difference. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
