Android Question Change GPS Delay while started

Scantech

Well-Known Member
Licensed User
Is there an alternative way to change GPS Delay while its running?

I have it this way
B4X:
        GPS1.Stop
        Sleep(2000)
        GPS1.Start(5000, 0)
I was hoping i can change it without stopping it?
 

emexes

Well-Known Member
Licensed User
Is there an alternative way to change GPS Delay while its running?

I was hoping i can change it without stopping it?
My first thought was: why throttle incoming readings? Most consumer GPS give one reading per second, and so:
- MinTime < 1000 unlikely to make any difference, but I can see that it is a useful protection against being overloaded by future high-rate GPS
- MinTime > 1000 means that you might be missing out on readings that have been done anyway; why throw away free information?

If your app is at risk of overload by GPS readings at 1 Hz, then perhaps you are better doing the filtering yourself - presumably your custom filtering can be made to better fit your use case and requirements better than the GPS.Start(time, distance) default. Eg, if you are starved for processing capacity, then you could use a simpler-but-not-as-accurate method for calculating distance than the default filter, which probably involves a trig function or two so that it is unarguably accurate.

My second thought is from this post:

Android Question: GPS start parameters

where, in the absence of good reason for doing otherwise, probably best to keep to the advice:

You should not call GPS.Start multiple times without stopping the GPS (as will happen if it takes longer than one minute to get a fix).
 
Last edited:

Scantech

Well-Known Member
Licensed User
I am at full throttle GPS.Start(0,0). I do a Battery Save Mode check. It monitors the speed and if its below a threshold, then GPS.Start(30000, 10). To wake up from BSM, it will require speed above threshold. This is what i am doing so far. I will test the battery usage in android settings.

I was hoping i can turn of speed check with GPS.Start, that way there will be no battery usage unless 10 meters have gone by.

Does anyone knows what the GPS.Start(X, 0) is?. X = Limit??
 

Scantech

Well-Known Member
Licensed User
I believe i misunderstood how GPS.Start works. When i am at GPS.Start(30000, 10). The 30 seconds will not fire up unless there is a difference in distance above 10 meters. Even if its above 10 meters before 30 seconds, it will have to wait for 30 seconds to be completed then it will fire up the event. That is how i observed it with the emulator.
 
Last edited:

emexes

Well-Known Member
Licensed User
that way there will be no battery usage unless 10 meters have gone by
Hang on... how will it know it has moved 10 m or whatever without GPS reading?

If you are looking to trigger on movement, then an initial filter might be the accelerometers - read them once a second, and if there is no change from the previous reading (other than random noise) then the phone is sitting stationary somewhere. Well, it could be aboard a moving vehicle, but (i) you wouldn’t enter this mode until GPS read 0 for a few seconds, and (ii) moving vehicles usually read higher than random noise.
 

emexes

Well-Known Member
Licensed User
Even if its above 10 meters before 30 seconds, it will have to wait for 30 seconds to be completed then it will fire up the event.
If the purpose of the Start parameters is to reduce battery use, then this is how it would have to operate. I have always just used (100, 1), never worried about battery since apps were all for driving and thus phone charger would be available, so I never investigated the Start parameters in detail like you are here.
That is how i observed it with the emulator.
Practice (even emulated) beats theory :)

If I have some spare time at lunch or this evening, I’ll give it a burl on some phones here.

I am a bit sceptical about the MinTime parameter actually powering-down the GPS between readings, because the GPS would immediately start drifting out of sync with the satellites, and thus the first reading on re-power would take longer (or be less accurate). On the other hand, even if it took 10 seconds to resync and get a new good position reading... if it only did that once every 30 seconds, that’d still be a 66% power saving, so hey, perhaps your interpretation is right :)
 

emexes

Well-Known Member
Licensed User
I believe i misunderstood how GPS.Start works. When i am at GPS.Start(30000, 10). The 30 seconds will not fire up unless there is a difference in distance above 10 meters. Even if its above 10 meters before 30 seconds, it will have to wait for 30 seconds to be completed then it will fire up the event. That is how i observed it with the emulator.
This tallies with the documentation at:

https://developer.android.com/reference/android/location/LocationManager.html#requestLocationUpdates

which states:

The location update interval can be controlled using the minTime parameter. The elapsed time between location updates will never be less than minTime, although it can be more depending on the Location Provider implementation and the update interval requested by other applications.

Choosing a sensible value for minTime is important to conserve battery life. Each location update requires power from GPS, WIFI, Cell and other radios. Select a minTime value as high as possible while still providing a reasonable user experience. If your application is not in the foreground and showing location to the user then your application should avoid using an active provider (such as NETWORK_PROVIDER or GPS_PROVIDER), but if you insist then select a minTime of 5 * 60 * 1000 (5 minutes) or greater. If your application is in the foreground and showing location to the user then it is appropriate to select a faster update interval.

The minDistance parameter can also be used to control the frequency of location updates. If it is greater than 0 then the location provider will only send your application an update when the location has changed by at least minDistance meters, AND at least minTime milliseconds have passed. However it is more difficult for location providers to save power using the minDistance parameter, so minTime should be the primary tool to conserving battery life.
 
Top