I am confused about the Battery Manager Parameters. can someone please explain below points:
BATTERY_PROPERTY_CHARGE_COUNTER -
Battery capacity in microampere-hours, as an integer.
Ques - Is it the remaining battery capacity or total battery Capacity.
If its total , why does it change
If its remaining( when i charged my phone 100% ) the values were somethign like 3366079 but total capcity of my phone's battery is 3300 mAh( read from power profile )
How can this be greater than 3300 mAh ?
Integer chargeCounter = mBatteryManager.getIntProperty(BatteryManager.BATTERY_PROPERTY_CHARGE_COUNTER);
Integer capacity = mBatteryManager.getIntProperty(BatteryManager.BATTERY_PROPERTY_CAPACITY);
Long energyCounter = mBatteryManager.getLongProperty(BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER);
long batteryCapacity = (chargeCounter/capacity) *100;
logs are as foolow :
Charge Counter: 3366079
capacity 100
Battery Capacity is :3366000
BATTERY_PROPERTY_ENERGY_COUNTER
Battery remaining energy in nanowatt-hours, as a long integer.
This parameter returns 0 ( tested on 2 devices )
Ques - Should this value be the remaining battery capacity value off 3300 mAH? or else what does this mean ?
Devices Used - LG G6 and Pixel 1
Thanks
There are a lot of physics behind these questions, for the first one,
How can this be greater than 3300 mAh ?
When manufacturers make a new battery they make them using a range, if your battery says it is 3300mAh there will be a range of error of +/- some error percentage.
Also to measure the battery they use a sensor which is prone to certain percentage of error too.
All these measures are converted from analog to digital which also conducts to another error.
I think this link could help: https://source.android.com/devices/tech/power/device
For your second question, check this post:
Android BATTERY_PROPERTY_ENERGY_COUNTER returning fixed value?
Related
I'm trying to measure I/O throughput in Android. I tried a simple test by running Androdbench, and sampling /proc/diskstats for /dev/sda every second. But the results dont match.
Androbench tells me that my phone's storage is capable of a maximum 160MB/s sequential write throughput. But when I diff the "sectors written" field of diskstats I find that the disk writes 500 MB/s at one point. Which doesnt make sense. Here are the two strange samples
207808 53404 19437816 332280 230564 26206 49888720 1100720 0 103030 1433600
207808 53404 19437816 332280 230590 26229 50937672 1100900 0 103210 1433780
These should be block layer results, so to my understanding there should be no cache involved. What am I missing?
I've seen numerous questions/answers showing how to get temperature information from an Android device - using this approach:
int zoneNumber = 0; // Usually 0 or 1
String temperatureFileLocation = "sys/devices/virtual/thermal/thermal_zone" + zoneNumber + "/temp";
File temperatureFile = new File(temperatureFileLocation);
scanner = new Scanner(temperatureFile);
double temperatureC = scanner.nextFloat(); // Degrees C
...
scanner.close(); // finally
I wasn't really sure what each zone is for (i.e., in which part of the device the sensor is located) but I just discovered that there is also a file that describes the type of each zone - for example:
String zoneTypeFileLocation = "sys/devices/virtual/thermal/thermal_zone" + zoneNumber + "/type"; // NB - that's "/type" not "/temp" !
Now, when using Scanner to read in what type each zone is, I get values back such as this:
mtktswmt
mtktscpu
mtktspmic
mtktspa
mtktsabb
mtktsbattery
tsen_max
sec-fuelguage
Can anyone explain what locations/components all these zone names are actually referring to?
(Ideally, I would like to obtain the temperature of the device's NFC hardware.)
I guess that's the Hardware thermal sensors of the mobile. They usually give the temperature of the given zones when the mobile is working or even when you perform some benchmarks results.
like
mtktswmt is Wifi Chip temperature zone.
mtktscpu is cpu temperature zone.
mtktspmic is Multi IO and Regulator Chip temperature zone.
mtktspa is Thermal sensor MD1
mtktsabb is processor temperature zone.
mtktsbattery is the battery temperature zone.
tsen_max is the maximum temperature sensor capacity(I dont know for sure).
sec-fuelguage is the fuel gauge chip.
the mtkt prefix is just the name of the maker. In this case it is Mediatek
That's pretty hardcore hardware stuff. These are actually used by the makers of the android mobile phone(I guess). Even the above mentioned data is searched from google android open source project where the values were found in kernal drivers. Hence it's pretty hardcore hardware to play with it.
For using the Hardware Properties that actually gives you your desired results try HardwarePropertiesManager.
I hope it Helps.
I'm trying to get the energy consumption of my phone. I'm doing as follows but the result is 0 while I was specting any amount of nanowatts per hour.
int status2 = mBatteryManager.getIntProperty(BatteryManager.BATTERY_PROPERTY_ENERGY_COUNTER);
What is my problem?
I think BATTERY_PROPERTY_ENERGY_COUNT should be retreived using getLongIntProperty
rather than an answer I'm looking for an idea here.
I'd like to measure the scheduling latency of sensor sampling in Android. In particular I want to measure the time from the sensor interrupt request to when the bottom half, which is in charge of the data read, is executed.
The bottom half already has, besides the data read, a timestamping instruction. Indeed samples are collected by applications (being java or native, no difference) as a tuple [measurement, timestamp].
The timestamp follows the clock source clock_gettime(CLOCK_MONOTONIC, &t);
So assuming that the bottom-half is not preempted, somehow this timestamp gives an indication of the task scheduling instant. What is missing is a direct or indirect way to find out its corresponding irq instant.
Safely assume that we can ask any sampling rate to the sensor. The driver skeleton is the following (Galaxy's S3 gyroscope)
err = request_threaded_irq(data->client->irq, NULL,
lsm330dlc_gyro_interrupt_thread\
, IRQF_TRIGGER_RISING | IRQF_ONESHOT,\
"lsm330dlc_gyro", data);
static irqreturn_t lsm330dlc_gyro_interrupt_thread(int irq\
, void *lsm330dlc_gyro_data_p) {
...
struct lsm330dlc_gyro_data *data = lsm330dlc_gyro_data_p;
...
res = lsm330dlc_gyro_read_values(data->client,
&data->xyz_data, data->entries);
...
input_report_rel(data->input_dev, REL_RX, gyro_adjusted[0]);
input_report_rel(data->input_dev, REL_RY, gyro_adjusted[1]);
input_report_rel(data->input_dev, REL_RZ, gyro_adjusted[2]);
input_sync(data->input_dev);
...
}
The key constraint is that I need to (well, I only have enough resources to) perform this measurement from user-space, on a commercial device, without toucing and recompliling the kernel. Hopefully with a limited mpact on the experiment accuracy. I don't know if such an experiment is possible with this constraint and so far I couldn't figure out any reasonable method.
I might consider also recompiling the kernel if the experiment then becomes straightforward.
Thanks.
First Its not possible to perform this measurement without touching the kernel.
Second I didnt see any bottom half configured in your ISR code.
Third if at all Bottom half is scheduled and kernel can be recompiled , you can sample jiffie value in ISR and again resample it in bottom half. take the difference between the two samples and subtract that offset from timestamp that is exported to U-space.
How to convert WiFi level (i.e. -45 , -88 ) in to percentage ?
I want to convert WiFi level in % . I get WiFi level using level ( in dBm format)
I try lot of google but not get proper ans
Problem with this is that is very dependent on the receiving antenna. Some antennas register no useable signal at -90 dBm, some already at -80. You will have a hard time finding 0% (100% strictly being 0dBm).
I have created a Wifi scanner application where I use -100dBm as 0% and 0dBm as 100%, in Java it turns into something like this (MIN_DBM being -100):
public int getPowerPercentage(int power) {
int i = 0;
if (power <= MIN_DBM) {
i = 0;
} else {
i = 100 + power;
}
return i;
}
This is what Microsoft does for dBm <> percent conversion:
https://stackoverflow.com/a/15798024/2096041
Basically -50 .. 0 dBm maps linear to 100 .. 0 %.
Like MS, i would prefer to sit on the safe side and not use -100 as 100% as some answers here suggest.
The WifiManager class has a function calculateSignalLevel, but as it states here, it results in an error if numLevels is greater than 45. Possible workaround could be something like this:
double percentage = WifiManager.calculateSignalLevel(int rssi, 40) * 2.5;
but of course, this will be in steps of 2.5 percents - I don't know your use case but maybe this is sufficient.
As others have stated, calculating percentages is problematic, and there's no simple precise solution for that.
You could derive the percentage from the signal-to-noise ratio, rather than the signal intensity alone, if this information is available. This is probably the desired metric.
An android.net.wifi.ScanResult does not publish the neccessary information (as of Dec 2012), but you might be able to get this information through other means.
Signal = Noise => unusable signal, so you could set 0dB SnR = 0%. Also you could set 10dB SnR to 90% (90% of the signal power is not drowned out in noise), and 100% = no noise at all. More generally,
p = 100% * (1 - 10^(SnR / (10dB)))