This question already has an answer here:
Closed 10 years ago.
Possible Duplicate:
time remaining until charge is complete,iOS
I am using below code to get the battery level
UIDevice *myDevice = [UIDevice currentDevice];
[myDevice setBatteryMonitoringEnabled:YES];
float batLeft = [myDevice batteryLevel];
int i=[myDevice batteryState];
batinfo=(batLeft*100);
But i am not able to figure out, how to calculate/estimate the time remaining in full charge , i.e when battery level = 100%.
I m trying to get something like
time remaining full charge = 01:30:10
Suggestions is always appreciated.
Thanks
An example of battery specs on Apple's site, you would probably need to record all the devices and use conditions to see which one is which:
Talk time: Up to 8 hours on 3G, up to 14 hours on 2G (GSM)
Standby time: Up to 200 hours
Internet use: Up to 6 hours on 3G, up to 9 hours on Wi-Fi
Video playback: Up to 10 hours
Audio playback: Up to 40 hours
The code to get the percentage of battery left is:
[[UIDevice currentDevice] setBatteryMonitoringEnabled:YES];
float batteryLevel = [myDevice batteryLevel];
Thats all you can do, so anything else an app uses is guesswork and calculations on your half.
Credits -- copied from here, had to do it because you said it is "not what i needed" even though it is the exact answer.
So to conclude it is not possible using the native API, you must setup conditions to find what model the device is and do the calculations by using specs from apple's site.
Related
I am using estimote beacons for an iOS app and implemented CLLocationManager delegate method didRangeBeacons to determine the proximity of each beacon.
Based on the .immediate, .near, .far proximities, i have some functionalities written.
This was working perfectly before in iOS 11. After iOS 12 upgrade .immediate proximity is not at all getting called. Only .near and .far is getting called.
I searched a lot and couldn't find any solution for this. What could be the reason for not detecting .immediate alone even if i place the iPhone just above the beacon?
Check to see what the CLBeacon accuracy field returns. This is an estimated distance in meters, derived from RSSI and the measured power calibration value configured into the beacon. Basically, you will get an .immediate proximity if the accuracy is 0.5 meters or less. And you only get an accuracy of 0.5 or less if the RSSI (measured in dBm) is significantly stronger (less negative) than the measured power calibration value (also measured in dBm) configured into the beacon.
You may be able to get your device to return an .immediate value by adjusting the measured power calibration value configured into the beacon to be a more negative number.
The above suggestion of course, will not help it work the same way across both iOS 11 and iOS 12 if you really see that there is a difference between the two. I would be curious to hear if you can reproduce this difference with a second device.
i want to calculate time for
3D gaming,3G Talk time,Video use,WiFi Internet,2G Talk time,Audio use and Standby depending on the current battery level.
There are many app do this, but i didnt found any resource to calculate that in iOS.
I calculated the battery level
[myDevice setBatteryMonitoringEnabled:YES];
float batLeft = [myDevice batteryLevel];
int i=[myDevice batteryState];
int batinfo=(batLeft*100);
now on the basis of batinfo,i need to calculate the time remaining for other parameters.
Thanks
Apple provide some data in device specification. You can use it for your calculation.
For example Apple say, app. 8 hours talk time on 3G (Iphone 5).
Now,
int batinfo=(batLeft*100);
int minutes3G=480; //minutes of 8 hour (static)
int talk3G=(minutes3G*batinfo)/100;
hour=talk3G/60;
min=talk3G%60;
lbl3Gtalk.text=[lbl3Gtalk.text stringByAppendingFormat:#"Remaining Time : %dh %dmin",hour,min];
I'm making a multiplayer game with GameKit. My issue is that when two devices are connected the game starts running with a slight time difference. On of the devices starts running the game a bit later. But this is not what i want. i want it to start simultaneously on both devices. So the first thing that i do is i check time of the beginning on both devices like this:
startTime = [NSDate timeIntervalSinceReferenceDate];
and this is how it looks:
361194394.193559
Then I send startTime value to the other device and then i compare received value with startTime of the other device.
- (void)balanceTime:(double)partnerTime
{
double time_diff = startTime - partnerTime;
if (time_diff < 0)
startTimeOut = -time_diff;
}
So if difference between two start times is negative it means that this device is starting earlier and therefore it has to wait for exactly the difference assigned to startTimeOut variable, which is a double and usually is something like 2.602417. So then i pause my game in my update method
- (void)update:(ccTime)dt
{
if (startTimeOut > 0)
{
NSLog(#"START TIME OUT %f", startTimeOut);
startTimeOut -= dt;
return;
}
}
But it unfortunately it doesn't help. Moreover it even extends the difference between start times of the devices. I just can't get why. Seems like everything i'm doing is reasonable. What am i doing wrong? How do i correct it? What would you do? Thanks a lot
As Almo commented, it is not possible to synchronize two devices to the same time. At the lowest level you will gnaw your teeth out on the Heisenberg Uncertainty Principle. Even getting two devices to synchronize to within a tenth of a second is not a trivial task. In addition, time synchronization would have to happen more or less frequently since the clocks in each device run ever so slightly asynchronous (ie a teeny bit faster or a weeny bit slower).
You also have to consider the lag introduced by sending data over Wifi, Blutooth or over the air. This lag is not a constant, and can be 10ms in one frame and 1000ms in another. You can't cancel out lag, nor can you predict it. But you can predict player movements.
The solution for games, or at least one of them, is client-side prediction and dead reckoning. This SO question has a few links of interest.
I'm trying to acquire the current location on an iOS device (specifically, my iPhone).
I'm using this Apple example.
The timeout before I call stopUpdatingLocations is 60 seconds.
When I set the desiredAccuracy to be kCLLocationAccuracyHundredMeters, only 3 newLocations arrive to the didUpdateToLocation:fromLocation. The first one is the cached one, from long time ago. The next two ALSO have timestamps from more than 15 seconds, despite the fact that all 3 arrive within 5 seconds interval. All three of them contain bad horizontal accuracy.
On the other hand, when I set the desiredAccuracy to be kCLLocationAccuracyNearestTenMeters, newLocations continue to arrive until I get an appropriate, exact one.
My WiFi is off and I'm indoors.
My question is: why when using the kCLLocationAccuracyHundredMeters accuracy I stop receiving updates early?
Because when the location returned immediately satisfies the nearest accuracy, it stops? If this is not the case, can you show any logs or anything to further explain the situation if I have perhaps missed the point.
I know the iPhone Bluetooth capabilities won't be accessible through the SDK until 3.0, but how long should it take to find devices in the area? Is it dependent on the number of devices in the area? If there are around 5 devices in range, should a scan to discover all of them take <5 seconds, or >30 seconds?
I know there are a lot of unknown factors, but I'm trying to determine if I can do a Bluetooth scan on startup if the time is minimal, or if I have to tell the user it is about to do a scan and there could be a long delay. I am unable to test this in the real world as the other Bluetooth devices aren't available, but I am trying to get a sense of how it could be designed.
Not sure what the API will let you do but the Bluetooth Host Controller Interface (HCI) command underlying this is the 'Inquiry Command'
This will let you inquire about devices either for a fixed time and/or a fixed number of responses.
I'm a Bluetooth neophyte, not an expert but...
To get at least 1 response from a Bluetooth device that is in a low power mode takes 1.28 seconds, so inquiry time is in multiples of that period up to a maximum of 61.44 seconds (48 periods), so the time range is 1 (1.28 seconds) to 48 (61.44 seconds).
There might be several devices that could respond in a single 1.28 second period though.
You can also specify the number of responses you will accept (1..255) or 0 for unlimited e.g. until the time runs out.
You can also cancel an inquiry, if you found a particular device you were looking for.
Unscientific test from my desk using a CSR bluetooth chip with Bluetooth 2.1 +EDR firmware running inquiry on the chip with debug output via the chip UART. Ran each inquiry 10 times and took an average of the results:
1 period inquiry time (1.28 seconds)
yeilded an average of 10 unique
bluetooth addresses.
5 period inquiry
time (6.4 seconds) yielded an average
of 23 unique bluetooth addresses.
10
period inquiry time (12.8 seconds)
yielded an average of 29 unique
bluetooth addresses.
I say 'unique', actually the results repeated a lot of the same addresses over and over, this may be implementation dependent though and the Apple API may only return unique addresses.
However, this is not representative of the 'real world' as most of the Bluetooth Devices around here (my office) are not in a low power mode. I guess, I could filter out PCs, laptops and test kit by Class of Device. That would get mobile phones, headsets that were discoverable etc...
Inquiry can also be combined with RSSI to get the the devices with the strongest signal but they may not necessarily be the closest.
For your scenario you might want to do an inquiry bases on time and number of devices e.g 4 * 1.28 seconds or 10 devices.
To summarise:
The shortest time you can do an inquiry for is 1.28 seconds and that could get 10+/-? devices in the area IF they are awake and near by.
If you've got a saturated Bluetooth environment or (a microwave oven going in the same room) it could take longer to find all the devices within range.
I know this is an old question, but I thought I might add something for anyone who finds this question later.
As Simon Peverett mentions, device discovery is performed by an underlying "Inquiry Command" that is carried out by the Bluetooth Host Controller Interface. In the Bluetooth spec V4.0, Volume 2, Part E, Section 6.1.4, the spec says:
When general inquiry is initiated by a Bluetooth device, the INQUIRY state
shall last TGAP(100) or longer, unless the inquirer collects enough responses
and determines to abort the INQUIRY state earlier.
Elsewhere, TGAP(100) is explained to be 10.24 seconds and is described as the recommended value for the time span that a Bluetooth device performs device discovery.
In other words, a good baseline for the minimum amount of time to perform an inquiry is 10.24 seconds, or 8 of the 1.28 second periods that the Inquiry Command measures time by.