iPhone : Does a rapidly updating (60Hz) accelerometer drain battery? - iphone

I'm making an accelerometer-based app using cocos2d, and I noticed that it's possible to set the accelerometer update interval.
[[UIAccelerometer sharedAccelerometer] setUpdateInterval: (1.0f / 60.0f)];
Is updating the accelerometer very often like this (60 times a second) a significant battery drain?

Given the numbers in the accepted answer the power usage by the actual accelerometer is trivial. Your real hit will come from your app having to process the events and thus making the CPU not sleep more often.
The 3GS has a 4.51 Watt hour battery. Drain from only the accelerometer when running at 100 hz would kill the battery in (roughly) 6000 hours (assuming the 0.75 mW value is correct)
(Also, the iPhone 4 has a 5.25 Watt-hour battery, 4S 5.3 Whr and 5 5.45 Whr, in case you're curious)

According to the LIS302DL accelerometer data sheet, it consumes ~0.75 mWatts of power at an update rate of 100Hz, and 0.0025 mWatts of power when in stand-by mode (i.e., no readings taking place).
So, the short answer is "Yes", but off the top of my head, I can't put those numbers in perspective to give you an idea of, say, "how many minutes of on time" it drains from the battery.
My recommendation would be to do a bit of testing. Find the lowest update rate that provides satisfactory results.

From the Event Handling Guide for iPhone OS:
When configuring the update interval
for acceleration events, it is best to
choose an interval that minimizes the
number of delivered events and still
meets the needs of your application.
Few applications need acceleration
events delivered 100 times a second.
Using a lower frequency prevents your
application from running as often and
can therefore improve battery life.
According to this, the more expensive part of having a high update frequency may be the fact that your application has to process each of those accelerometer events, rather than idling for a longer period.
Also, from the iPhone Application Programming Guide:
If you use the UIAccelerometer class
to receive regular accelerometer
events, disable the delivery of those
events when you do not need them.
Similarly, set the frequency of event
delivery to the smallest value that is
suitable for your needs.

http://www.google.com/search?hl=en&client=firefox-a&hs=7ew&rls=org.mozilla%3Aen-US%3Aofficial&q=iPhone+accelerometer+battery+drain&aq=f&aqi=m1&aql=&oq=&gs_rfai=
My answer would be yes. It does drain battery faster. And 60 times / seconds is excessive.

Related

CLLocationManager geo-fencing/startMonitoringForRegion: vs. startMonitoringForSignificantLocationChanges: vs. 10-minute startUpdating calls

I am trying to set up an app that will be able to check people's locations in the background, see if they are at a given location, and send a ping to a server if they are. We do not want to drain the energy of our users, so we are attempting to figure out the best solution.
I've done substantial reading and I have not found very much information on these methods. I'll go through the pros and cons as I understand them right now
startMonitoringForSignificantChanges
Description: Based off of wi-fi and cell tower changes the system wakes up the app.
Docs:
Apps can expect a notification as soon as the device moves 500 meters
or more from its previous notification. It should not expect
notifications more frequently than once every five minutes. If the
device is able to retrieve data from the network, the location manager
is much more likely to deliver notifications in a timely manner.
Pros:
Most battery efficient
Cons:
Dependent on wi-fi/cell tower changes
Can only assume that this will be called every 200m to 2km (if not more in certain areas)
More on accuracy
Thus, inconsistent and imprecise
10-minute start-updating or "n-minute updating":
Description: This basically asks the app for more time, when that extra time is about to expire, it calls [self.locationManager startUpdating], grabs the location and extends the background thread for 10 more minutes.
Pros:
Consistent
Can be as accurate as you want it to be as consistently as you
want it
Cons:
Has to do a call every ten minutes or less to keep the app running in the
background (ie n can't be greater than 10 for the calls)
Questions:
What effect does this have on the battery? Does waking up the GPS and shutting it off hurt the battery more? I couldn't imagine running a brief location check in the background would drain the battery that much... but then again, I don't know what goes into powering up the GPS and getting a usable signal.
startMonitoringForRegion (geo-fencing):
Simply put, your app gets woken up when you enter into a pre-defined region. This is the oddball of them, it is more recent and there is less documentation on it. I can't find a good description on how the "system monitors" the boundary crossing. For all I know it is some really smart algorithm, or they are constantly pinging the GPS which would make it less effective than the other methods for doing this.
Pros:
Simple implementation
Managed by the system so you don't have to invent your own ad hoc geo-fences Only triggers on boundary crossing... no unnecessary data to just throw out in exchange for a battery hit
Thus, should be the best for this sort of thing, accurate, managed by the system
Cons:
People question its effectiveness
Huge conflicts on whether or not it is good for battery life or if it
drains battery life terribly.
How is the system monitoring this!?
Basically, indeterminate behavior.
I guess my question boils down to how does startMonitoringForRegion: compare to these other methods of testing user location in the background when it comes to battery life, consistency, and precision. Has anyone thoroughly tested this? Or used it in their app and gotten at least some feedback? Likely, for my purposes, the trade-off is between geo-fencing and the 10 minute update method. (Also given what Apple has publicly said about iOS7 there will be some background tasks... will this change the calculus for the trade-off between these two methods?) Does anyone have an idea of how these two compare?
Thanks so much! Looking forward to seeing if we can get to the bottom of how to compare these methods.
I've been working on vehicle tracking using GPS for 2 years. Learned a lot the hard way... In my experience startMonitoringForRegion or Geo-fencing depends upon cell change events, didEnter or didExit events doesn't fire up until there is a cell/wifi change event. So it doesn't make any difference w.r.t battery consumption. However it does extra computation which depends on how many regions currently are being monitored. Even Apple's Reminder app doesn't give good results for location based reminders because it uses geo-fencing.
The other approach starting GPS for n minutes after each m-minutes is good option, it should not affect the battery life, if done wisely. What exactly effect the battery is constant GPS activation in high precision mode. Like for instance If you enable GPS with kCLLocationAccuracyBest and distance-filter = 0, you can literally observe battery drainage and soon your device will also start getting hotter.
If I was you, I would go for activating GPS after every 10 minutes for 5 sec with kCLLocationAccuracyBest (or may kCLLocationAccuracyNearestTenMeters to use less battery, if accuracy is not that much important) and distance-filter = 5 (meters). Battery consumption in this case will be unnoticeable. You can play around with similar settings which can address your specific case and finally find out what is best you.
BTW: iPhone uses AGPS, A-GPS additionally uses network resources to locate and use the satellites in poor signal conditions. So, when you do startUpdatingLocation it will also use nearby cell tower information. see http://en.wikipedia.org/wiki/Assisted_GPS

iPhone: Battery Efficient way of Realtime GPS Reporting

What I want to do:
I want to have my iPhone to frequently (formally defined later) upload my GPS location to a central server. I want to do this in the most battery efficient way.
Research I'm aware of:
Apple Documentation:
https://developer.apple.com/library/ios/#documentation/CoreLocation/Reference/CLLocation_Class/CLLocation/CLLocation.html#//apple_ref/doc/uid/TP40007126
Stack Overflow Links:
Response 1
Response: proof of existence; some other tool can do it
How to reduce iPhone battery consumption while using GPS
Response 2
Response: track only cell tower changes
iPhone GPS - Battery Draining Extremely Fast
iPhone running periodical process in the background - battery optimized way
Question
My question is a bit vague in that my definition of "frequently" is really dependent on what the battery life can tolerate. For example, if the battery can take updates of every 5 minutes, I'd like to do it every five minutes; if the battery could do this every 10 seconds, I'd like to do it every 10 seconds.
I really want to understand
the different ways (change on significant location, timer, background?) continuously uploading GPS locations can be implemented
advantages / disadvantages
approximately how long the battery life can last in each case
This seems like a fairly generic and common problem. Does anyone know of either:
an in depth analysis of the various methods
or if there is a single "optimal" way to do this?
[Moderators: feel free to mark this comment wiki. I'd love to just get lots of different answers + cost benefit analysis of them.]
Have a look at the Apple Documentation Here.
The significant-change location service offers a low-power location service for devices with cellular radios. This service is available only in iOS 4.0 and later and can also wake up an application that is suspended or not running.
It all depends on the use case. If the user will stay at a certain location and all you want to do is to track if he is leaving the country, tracking the significant location changing will be most suitable. However, this will not be precise enough for navigation apps.
One advantage of choosing the "Apple-Algorithm" is that they'll optimize it for you, if battery issues occur. (-:

Is it possible to use only region monitoring + GSM and to get not more than 5 km horizontalAccuracy?

I would like to share the info of my performed testing scenarios and to ask you to share your experience with region monitoring. So, I have registered two opposite regions (A and B) with 5 km radius and 1 km desiredAccuracy, with the 20 km distance between them. However, I haven't received any didEnterRegion/didExitRegion events when traveling from A to B. In my app prototype, I also put two buttons (for testing purposes): one starts significant change and another standard location monitoring. Both prints didUpdateToLocation events on-screen-log.
So, after getting to the center of region B and being very annoyed about the unpredictable functionality, I have enabled significant monitoring. After that, I have received several didUpdateToLocation with horizontalAccuracy of ~8.5 km! Wow, that hurts, because all I want to do is to have a functionality where a user would be notified, that his desired place is somewhere in radius of 5 km from his current location position, and I want to rely on GSM cell triangular location detection method only (for preserving the battery).
So, back to my case. After getting such a big 8 km error, I have enabled standard monitoring with best accuracy (GPS). And bingo, I have received didUpdateToLocation event with horizontal accuracy of 399 m, and only then, I have received didExitRegion from my initial place (region A), and another event with didEnterRegion (B). Another updates from didUpdateToLocation where a little bit more accurate - 50m.
In previous scenarios, I was getting unstable accuracy also. Sometimes there were 4 km horizontalAccuracy, sometimes less. But the main question that is, if we want to preserve the battery (Apple teaches us that in docs) then can we rely only on region monitoring + GSM without using GPS? There's a sample of Apple code with "proper use of region monitoring" (here), however there are some unacceptable things there:
1) They state that sample code works only for iPhone4, though Apple docs state that both region monitoring and significant monitoring are supported on iOS4.0+. Cool, ha?
2) The sample code uses all 3 location methods: significant, standard, region. It uses region monitoring all the time but in addition in uses standard location with best accuracy. When app enters background it stops standard and starts significant change monitoring. When entering foreground then app stops significant and starts standard location. Seems like apple docs are quite vague, it's unclear what penalties (horizontalAccuracy) do we get if we use only region monitoring, or do we have always to use all three methods?
3) Apple docs state that we need to preserve the battery and to use as minimum location services as we need, if we don't need GPS then we should use GSM (for example, 1 - 3 km desired accuracy). But the sample code uses best desired accuracy (GPS) both for region monitoring and standard monitoring (when app is in foreground). I do understand that GPS would solve all my problems with errors and accuracy, but what about using GSM only? After getting 8.5 km horizontalAccuracy in my scenario, I'm not sure is it possible to use region monitoring at all because it's unable to provide at least 5 km acceptable error.
In my experience, the region monitoring is pretty accurate without a significant loss to battery life. I have a use scenario of regions that are only 30-50 meters wide. No issues at all with accuracy. One thing I will say, I have only targeted iPhone 4 devices and up. I will need to implement some of the changes you talk about if I want to support the 3GS models.
When relying purely on -startMonitoringForRegion, your updates automatically trigger on the -didEnter and -didExit events. These are triggered through a combination of location tracking events. Significant changes, cell tower transfers, connection to WiFi, another app requests location, and a few others. The OS handles when the callbacks are triggered from these other shared location events. In my experience, it has been very accurate. But this is only for iPhone 4 and up.
I also used the example app from Apple to get things set up, but there isn't a lot of detail in the documentation about the specifics of the when/where you will get your trigger. You can read up on what Apple provides in the Location Awareness Guide. Hope this helps.

How to reduce iPhone battery consumption while using GPS

I am using GPS to actually monitor if I have entered a regions (radius 100 m).
I am using a hybrid of significantLocationChanges and hardware GPS, startUpdatingLocation.
As significantLocationChanges are not as accurate as I require I am using them only to check if I have entered a outer circle of X m. Then I use hardware GPS to check if the user enters an inner circle (100m).
The problem with it is that battery is getting drained pretty quickly, can anyone help me out.
I was concerned about the same issue and today i have made a simple test with MotionX on iPhone 4 , covering the distance of 15 km in 4 hours, with frequent audio coaching, taking photos, saving waypoints, checking the position on map and tracking the route. After 4 hours i had still 50% of battery power. Which shows that it would probably covered 8 hours route. Good enough, or?
So there must be some ways of wise GPS management, which MotionX knows (they say it proudly in their tech. description)
Here's a preview of a nice read (High Performance iOS Apps):
https://www.safaribooksonline.com/library/view/high-performance-ios/9781491910993/ch04.html
You'll see it covers battery usage in general, so search for "gps" for specifics. I use this as a reference so I don't forget any of it's tips. Enjoy the read :)

What is active GPS effect on mobile devices battery life?

How much does active GPS drain the battery? Without the overhead of the gps navigator software. s
ay I want to sample the gps every 2 minutes and save it to a file. how much battery power will that cost me?
Will I get 10% shorter life? 20%? ..?
I think this can't be answered that easy without measuring it. But you could measure it. Just try how long it takes to empty the whole battery. Once with GPS and once without.
It will be noticeable by the user. You definitely don't want to do this kind of thing unless it is a feature the user is explicitly aware of and able to clearly turn on and off depending on whether at any particular time they think that feature is worth the impact on their battery.
On my HTC Desire, RunKeeper with GPS always active, battery was near to down after about 5 hours of usage (in forrest).
But the screen was down while it was running, 2 hours of reading pdf drains about 40-50% of battery, so GPS working in background drains about same or less energy than screen active.
When you turn the GPS on, you must wait, depending on where you are, before you get the read, so if you want to save position every 2 minutes, I think GPS will be on about 25%-50% of time. 10 hours of work in background would be max in that case...
Maybe the question about increasing battery life on Windows Mobile using GPS will give some hints, since the device used in test was manufactured by HTC, which is one of the most popular manufacturer of Android Devices nowadays...