I want my Android application to be notified when the user is moving fast.
(lets say faster then 5 meter/second)
It must be battery efficient - so I can not use GPS for example, but can use a sensor.
Latency is not very important - it can be up to 30 seconds after reaching a fast speed.
I am only interested in continues movement. fast tilting the device can be ignored.
How can this be done ?
Related
I'm currently working on an app that I want for my app to detect a beacon in background mode just when it gets close to it(Immediate). Based on articles that I've read it cannot be done with didEnterRegion and I should use ranging while it's running in the background mode(Location Update). is there any solution that directly reduces the didEnterRegion threshold? or Should I use the other method? and if that's the case does it work like didEnterRegion but with a limited range of RSSI? does it work when my phone entered the region and it's locked and the screen is off?
Monitoring APIs give you no control over the distance at which you get detection callbacks. You always get a callback the first time a beacon goes within radio range, typically at around 40 meters.
There are two ways to trigger on beacons only at close range:
Configure a lower radio transmission power on your beacon, if the manufacturer supports it.
Combine Ranging APIs with Monitoring, and range for as long as possible in the background (180 secs max on iOS without special background permissions), then trigger your logic when a ranging callback says the CLBeacon accuracy field is immediate.
Option 1 is simpler, but less reliable as it will often trigger at greater distances than you'd like and sometimes has trouble triggering at all even at extremely close range.
Option 2 is more reliable, so long as background ranging time does not run out. If a phone's radio triggers at 40 meters to start ranging, if the user takes more than 180 secs to get to immediate proximity then ranging time runs out and you are unable to get a trigger until the beacon disappears and reappears to reset the ranging time allowed.
I'd like to use Unity for cross platform non game development but the battery consumption is painful. Most of the usage is read only / static, i.e., the canvas doesn't change, just panning at most (sometimes zooming, but not frequent). Is it possible to turn the FPS to 0 and reduce CPU usage?
Hesitant "yes" because there might be side effects you'll have to handle on your own that aside from some general predictions I cannot know, or may not actually save any CPU usage.
But you can try fiddling with Time.timeScale so that the game updates less frequently, but it has some rather wide-ranging implications (if TimeScale is 0, then your panning and zooming aren't going to work either if they're reliant on either deltaTime (which would be zero) or use FixedUpdate (which won't be called)).
Generally speaking though, if something's using a lot of CPU then you need to go in and figure out why and optimize it. Use the Profiler. If you're absolutely sure that your application is doing nothing and the CPU is still cranked, then there might not be anything you can do (it's an Engine problem).
Application.targetFrameRate sets how many frames per second will be calculated and rendered, so setting this to a low value will actually save power. Not sure how well supported this is on mobile devices though. Especially iOS frame rate may depend on a static setting inside your XCode project.
The Unity documentation for Application.targetFrameRate states:
- On mobile platforms the default frame rate is less than the maximum
achievable frame rate due to need to conserve battery power. Typically
on mobile platforms the default frame rate is 30 frames per second.
This should mean that setting the target frame rate to a lower value will consume less battery power.
We are developing an app that has heavy GPS usage, and we are unable to optimize the battery life.
Even when the device is not moved, there is significant battery drainage that, according to the code, should not happen.
Here is the code:
locationManager = [[CLLocationManager alloc] init];
locationManager.distanceFilter = 100;
locationManager.desiredAccuracy = kCLLocationAccuracyHundredMeters;
[locationManager startUpdatingLocation];
Ideally we want to trigger GPS every 20 minutes (if there is no location change then save battery) OR every 5 minutes if there is location change. According to my developer this cannot be done
Previously we were using kCLLocationAccuracyBest, which was consuming battery very fast and now we are using kCLLocationAccuracyHundredMeters.
startUpdatingLocation - is to get the GPS coordinates. There is another call startMonitoringSignificantLocationChanges which is to get AGPS coordinates which I believe returns the coordinates whenever cell tower will change, and hence consumes battery really fast.
distanceFilter - The minimum distance (measured in meters) a device must move laterally before an update event is generated. On the basis of distance filter we get the GPS fix from the device and then we send the updated GPS coordinates to the server.
Any help will be greatly appreciated
Thank you!
There is another call startMonitoringSignificantLocationChanges which
is to get AGPS coordinates which I believe returns the coordinates
whenever cell tower will change, and hence consumes battery really
fast.
That's exactly what it does, but you're jumping to conclusions about the power required for that. The GPS receiver and WiFi transceiver can be used to help determine location, but they're extra devices that have to be powered to be useful. But mobile phones like the iPhone need to keep in touch with the nearest cell tower anyway in order to receive phone calls, so using cell towers as a source of location information should be very efficient with respect to power. Here's what the CLLocationManager reference page says about -startMonitoringSignificantLocationChanges:
This interface delivers new events only when it detects changes to the
device’s associated cell towers, resulting in less frequent updates
and significantly lower power usage.
It also describes the service as providing "tremendous power savings," so it seems the right tool for the job you describe. Of course, if you're also using the standard location updating mechanism at the same time you won't see that power savings, so make sure you're not using both.
Ideally we want to trigger GPS every 20 minutes (if there is no
location change then save battery) OR every 5 minutes if there is
location change. According to my developer this cannot be done
It sounds like there's some sort of misunderstanding here. You can certainly fire up the GPS every 20 minutes to get a fix if that's what you want, although you can't do that from the background. The significant location change service will notify your app even if it's running in the background, so perhaps your developer is talking about background updates.
Your belief that startMonitoringSignificantLocationChanges consumes the battery really fast is likely incorrect. Cell tower changes usually occur far less frequently than movements of 100 meters. And an iPhone checks for this event even when idle and all apps are sleeping.
However, keeping a cell phone on (e.g. Airplane mode off) when far from any tower (barely 1 bar) will drain the battery of the device whether or not an app is doing any location monitoring.
On stock iOS devices, an app cannot trigger location monitoring purely on a timer basis such every 20 minutes or every 5 minutes, without keeping the device on and your app running in the foreground, which will drain the battery.
If you require a good level of precision, you should startUpdatingLocation and as soon you get the first fix you should then stopUpdatingLocation and then startMonitoringSignificantLocationChanges.
This is enough for most app purposes.
Ideally we want to trigger GPS every 20 minutes (if there is no
location change then save battery) OR every 5 minutes if there is
location change. According to my developer this cannot be done
This could be done using an NSTimer that calls a startLocating (a custom method that creates the CLLocationManager and calls startLocating on it) method every 20 minutes. Make sure you call CLLocationManager's stopLocating once you've found a CLLocation with an accuracy of your liking.
However, doing so mean that for 20 minutes you might be using a location that is totally off. It depends on how you plan to use the location and how precise it needs to be, but maybe what your dev means by "not possible" is that your app needs the user's actual location at all times.
I made a board game with includes just some little animations. I reduced the fps from 60 to 30 to reduce the processor load. But the device still gets very warm.
Another application made without cocos2d is not heating it so much.
Are there any methods to calm the iPhone down?
The device state is as follows:
Wifi is always enabled
The app uses gamecenter
GPS is inactive
fps is always on 30
I use cocos2d-iphone as engine
It might be worth experimenting with different director types, e.g. kCCDirectorTypeNSTimer, and seeing if that helps at all. Those will have the biggest effect on the main loop of the game.
You should also spend some time with Instruments if you've not already, as that will show you where the CPU is spending its time and give you some hints on where you could ease things up.
I've noticed that a sequence of small time animations in cocos2d takes a lot of processor time. I've tried making tips at the level which will pulse in size. 0.1 second pulse up, 0.15 down and 0.2 stay. And i've put it all in a repeat forever sequence. Everything was terribly slow. Then i've just made the animation manually and the device calmed down and fps increased back to 60
When showing menus or dialogs that do not require animation, you can actually lower your framerate even further.
I have developed a test for iPod/iPhone (with MonoTouch if that is relevant) that measures reaction time. But I need to take into consideration the time between touching the screen and actual triggering of the button event. Is there any documentation of that?
It's already very hard to almost impossible to get predictable interrupt latency on real time operating systems.
But on the iPhone? Imho impossible. A capacitive touchscreen is not optimal to get results that are exactly the same for each body and location. And if mail.app decides to poll for emails just at the moment you'll touch the screen there will be a bigger delay.
But to make one thing clear, we are speaking about some micro seconds or even less than that.
If you want accurate results you shouldn't use an iPhone. But I guess your app will be some kind of game, so nobody cares if your result is 0.01 seconds off. But I wouldn't show results as 0.381829191 seconds, that fakes accuracy you'll never get on any smartphone.
What is the lowest reaction time you got in your app?
The time between an actual touch and the system registering it will be negligable.
One key thing: if you are detecting the press using touch events like touchUpInside, consider using the touchesDownInside event because touchesUpInside, will not fire until the user's finger leaves the screen.