Add an option to set the GPS logging interval

[GoogleCodeExporter]

Suggested to me by email from a user: It would be nice to have an option to set 
the GPS logging interval, in the hope of saving some battery juice when 
tracking long journeys.

Original issue reported on code.google.com by nicolas@guillaumin.me on 29 Nov 2010 at 11:54

[GoogleCodeExporter]

Original comment by nicolas@guillaumin.me on 29 Nov 2010 at 11:54

• Changed title: Add an option to set the GPS logging interval

[GoogleCodeExporter]

What kind of interface should we have for this?

"GPS logging interval:"

* A "spinner" that accepts values from 1 - 1000 (in seconds)

* A list of perhaps:
 - as often as possible
 - 5 Seconds
 - 10 Seconds
 - 30 Seconds
 - 1 Minute
 - and so on

* simple input field

I'd prefer the spinner. It's easy to handle and allows all possible values.

What would you prefer?

best regards
Matthias

Original comment by matthias...@gmail.com on 29 Nov 2010 at 11:49

[GoogleCodeExporter]

Do you have a screenshot of a Spinner somewhere so we can be sure we talk about 
the same thing ?

I find spinner/lists useful when there are few values, but annoying when there 
are too much (Selecting the 500th could be difficult ?).And usually the value I 
want is NEVER in those ;-)

The input field would be my preferred option but I'm ok with the other choices 
if it's the majority vote.

Original comment by nicolas@guillaumin.me on 30 Nov 2010 at 8:03

[GoogleCodeExporter]

Hi,

I just relized that a "Spinner" in Android differs from a JSpinner in Java 
Swing.

I was thinking about something like one of the parts of the DatePicker:
http://developer.android.com/resources/tutorials/views/hello-datepicker.html

Another possibility could be a SeekBar:
http://www.google.com/images?q=android+seekbar

Original comment by matthias...@gmail.com on 30 Nov 2010 at 7:05

[GoogleCodeExporter]

I would be in favour of either the input field of the date-picker like thing. 
The seekbar don't seem enough precise to me.

Original comment by nicolas@guillaumin.me on 1 Dec 2010 at 7:56

[GoogleCodeExporter]

Original comment by nicolas@guillaumin.me on 2 Dec 2010 at 10:31

• Changed state: Started

[GoogleCodeExporter]

I've implemented it using an EditText, however it's difficult to tell if it's 
really working, it seems to make no difference with the emulator, and with my 
device hooked to my computer the location doesn't really update as I don't move 
! :)
Will have to ask the missus to drive me around with the laptop in the car ;-)

The only problem is that changing this setting will only be active for the next 
track, since if there is a current track it's already listening to GPS event 
and apparently setting the interval could only be done when you start listening 
(cannot be changed afterwards)...

Original comment by nicolas@guillaumin.me on 2 Dec 2010 at 11:19

[GoogleCodeExporter]

Looks great, but i didn't test it yet.

There are 3 things I would change/add:
* the interval should be set as seconds (its annoying to check if you have 
enough zeros if you would like to set it to 10sec :-) )
* remove the DigitsKeyListener n Preferences.java and add 
'android:inputType="number"' to the preferences.xml instead
* we should display a detailed description (attribute 'android:dialogMessage') 
to the dialog saying something like: "Set GPS logging interval. A low value 
will make detailed tracks. Setting a higher value will save battery." (perhaps 
we should use better english here)

I'll test functionality in the next days.

best regards
Matthias

Original comment by matthias...@gmail.com on 2 Dec 2010 at 11:43

[GoogleCodeExporter]

Nice :-)

I was keen on the hint dialog too but wasn't sure how to do it simply. Same for 
the number-restricted input, I wasn't very happy with the DigitsKeyListener, 
your solution is much better.

By the way don't hesitate to use the code review feature of Google Code (Go to 
"Source" tab, then "Changes" then click on a rev. number, the click on "diff" 
for a file and there if you double click on a line you can enter a comment. 
Looks handy !)

Concerning seconds/ms I set it to seconds at first, then I realized that it 
would be handy to be able to use some values between 0 and 1 seconds like 250ms 
or 500ms... I'm not sure what's best ?

Original comment by nicolas@guillaumin.me on 3 Dec 2010 at 8:11

[GoogleCodeExporter]

Thanks, i didn't know this code review feature, I'll give it a try if needed.

concerning sec/ms: My Motorola Milestone updates location every second, as my 
external bluetooth GPS device does. I'm not sure if there are devices that will 
update the location more often. The accuracy is (in best case) 5m.

if the position data is retrieved every second the following distances between 
two GPS fixes have been passed:
           speed     distance between 2 GPS fixes
Walking:   5-6 km/h       1.3 - 1.6 meters
Running:   9-15 km/h      2.5 - 4.2 meters
Cycling:   10-25 km/h     2.7 - 6.9 meters
Car (city):  - 50km/h         - 14 meters

IMHO it doesn't make sense to set it to less than a second, but we could 
provide the "0" which is the setting to retrieve position data as often as 
possible. (on my Milestone this will result in getting the location every 
second)

Could you check how often your GPS updates position?

Original comment by matthias...@gmail.com on 4 Dec 2010 at 1:33

[GoogleCodeExporter]

Agreed, I just changed that.

Assuming everyone's happy with that I'll close this one and try to release 
today. Feel free to re-open if needed.

Original comment by nicolas@guillaumin.me on 5 Dec 2010 at 1:56

• Changed state: Fixed

[GoogleCodeExporter]

This needs some fixing,

if i set GPS logging interval to 10 seconds my GPS signal gets lost every 10 
seconds.
GPS points are still requested every second... ?!?

Something's strange here.
I'll try to figure out what's happening here.

Since then I'll reopen this issue.

@nicolas:
I'm not sure whats excactly happening but i think we should remove this feature 
from the market app.

best regards
Matthias

Original comment by matthias...@gmail.com on 5 Dec 2010 at 11:32

• Changed state: Started

[GoogleCodeExporter]

I just checked the behavior:

changing minTime for "requestLocationUpdates" does not work as I expected.

If minTime is set to e.g. 60sec I saw the following behavior after:
- GPS will try to get MIN_FIX_COUNT fixes (seems to be 10 fixes)
- GPS will stop for 60sec
- GPS will try to get MIN_FIX_COUNT fixes (seems to be 10 fixes)
- GPS will stop for 60sec

because these fixes do have very low accuracy (in my case) we cannot use this 
method.

A possible solution is to request location updates as often as possible to be 
sure gps won't loose it's position and only track the points for the given 
interval.
But this will not save as much battery as disabling gps for 60sec could save.

best regards
Matthias

Original comment by matthias...@gmail.com on 5 Dec 2010 at 4:38

[GoogleCodeExporter]

Odd... I've tried and got the same behaviour on my device (HTC Magic 1.6)

Could it be related to http://code.google.com/p/android/issues/detail?id=4336 ?
See also: 
http://groups.google.com/group/android-developers/browse_thread/thread/4bbd1593f
41d1e97/dfaa7da78bc89ea7

It more or less match the requestLocationUpdate() doco but the implementation 
is completely dodgy ;-) I'm not sure whether we should remove or not the 
feature as it relies on an Android "bug".

Original comment by nicolas@guillaumin.me on 6 Dec 2010 at 7:53

[GoogleCodeExporter]

I'm not really sure if this is related to the links you provided. I didn't read 
the whole story...

For most cases i think the behavior of requestLocationUpdate() suits well. e.g. 
a weather forecast does not need to know if you are in street x. It's ok if the 
application knows you're in city x.

But OSMTracker needs to know if you are in street x, the best case would be 
that it gets a location with an accuracy of 1m.
So i think we cannot rely on this feature of android because the accuracy is 
too bad. I think it doesn't matter if it's an android bug or not.
We need to somehow save battery in another way.

best regards
Matthias

Original comment by matthias...@gmail.com on 6 Dec 2010 at 11:57

[GoogleCodeExporter]

Yep after testing again the behavior is definitely not suitable for OSMTracker. 
I'll look at remove it in the next release. Too bad :(

I don't know if trying to simulate that by only picking every Nth location 
update is worth doing ? I'm not sure it'll make a huge difference in battery 
life.

Original comment by nicolas@guillaumin.me on 7 Dec 2010 at 1:49

• Added labels: Priority-High, Type-Defect
• Removed labels: Priority-Low, Type-Enhancement

[GoogleCodeExporter]

Option removed in r257.

Original comment by nicolas@guillaumin.me on 7 Dec 2010 at 10:29

• Changed state: WontFix

[GoogleCodeExporter]

Nicolas,

i gave the "simulated logging interval" a try (see attached patch against 
rev#254) 

My results:
I tracked for 10minutes on my device and then checked battery status within the 
android system.

First case: tracking with logging interval set to 0 sec
- OSMTracker: 66%
- Display:    32%
- System:      2%
- Standby:     2%

CPU time of OSMTracker: 1m48s

Second case: tracking with logging interval set to 5 sec
- OSMTracker: 64%
- Display:    33%
- System:      2%
- Standby:     2%

CPU time of OSMTracker: 29s

The percentages don't seem to be very precise but the needed cpu time could be 
of interest.
So I think we can save battery with a simulated logging interval, because sql 
insert statements are very expensive. (have a look at attached trace with 
traceview)
Also it is possible to limit the count of trackpoints with this preference...

best regards
Matthias

Original comment by matthias...@gmail.com on 7 Dec 2010 at 6:59

Attachments:

• simulate_logging_interval.patch
• TrackLogger.trace

[GoogleCodeExporter]

Hi Nicolas,

I just gave this one another try because of issue #106 and thought about the 
"simulated logging interval".

I think it will not give us the "battery life boost" we expected to get with 
this preference, but it really heavily reduces CPU usage (see comment #18). 
Most of the power is used for GPS, I think, but reduced CPU time won't be bad.

As users might already have noticed this feature, i think removing it from the 
app could result in some confusion.
Another point is that one could massively reduce the number of recorded points 
and this will reduce the size of the exported gpx file, could save time to 
export a track because of less points and could save us time and data transfer 
when implementing the "Upload to OSM" (see issue #43).

IMHO the preference has no cons but (little) pros, so I would like to integrate 
the "simulated interval" into trunk if you're ok with it.

best regards
Matthias

Original comment by matthias...@gmail.com on 9 Jan 2011 at 12:35

• Changed state: Started

[GoogleCodeExporter]

Since nobody complained, i integrated the simulated interval into trunk.

best regards
Matthias

Original comment by matthias...@gmail.com on 15 Jan 2011 at 1:04

• Changed state: Fixed

[GoogleCodeExporter]

Sorry I lacked time recently, thanks for committing that !

Original comment by nicolas@guillaumin.me on 26 Jan 2011 at 12:50