Develop Reference

Android temperature zones?

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.

How to get RSCP, SINR and EcNo values in Android

I need to find RSCP, SINR and EcNo. So far i am able to calculate RSRP and RSRQ values from android.telephony.SignalStrength.
My questions are:
When I try to get SignalStrength#getTdScdmaDbm() via reflection it
returns Integer.MAX_VALUE (if i debug at line 300 its value
is 0)
According to AOSP RIL (Radio Interface Layer)
The Received Signal Code Power in dBm multipled by -1. Range :
25 to 120, INT_MAX: 0x7FFFFFFF denotes invalid value. Reference:
3GPP TS 25.123, section 9.1.1.1
Is there any other way to calculate RSCP.
EcNo = RSCP / RSSI where RSCP is unknown so i can not calculate Ec/No.
SINR = 1 / (1 / 12 . RSRQ) - x, where x = RE / RB, Resource Element RE and Resource Block RB are unknown. Both RE and RB are unknown.
Should i need to write native code to find/calculate these values or is their any other way to achieve this?

Estimating beacon proximity/distance based on RSSI - Bluetooth LE

I've got a simple iOS app which displays the proximity of the Bluetooth LE beacons it detects using such expressions as "immediate", "near" etc. and I need to write something similar on Android.
I've followed the tutorial at Android developer and I'm able to list detected devices and now want to estimate the distance/proximity - this is where it's become a problem. According to this SO thread it's just a handful of mathematical calculations. However, they require me to provide a txPower value.
According to this tutorial by Dave Smith (and cross-referencing with this Bluetooth SIG statement), it should be broadcast by the beacon devices as an "AD structure" of type 0x0A. So what I do is parse the AD structures and look for the payload of the one that matches the type.
Problem: I've got 4 beacons - 2 estimotes and 2 appflares. The estimotes don't broadcast the txPower at all and the appflares broadcast theirs as 0.
Is there anything I'm missing here? The iOS app seems to be handling it all without any problem, but using the iOS SDK it does it behind the scenes so I'm not sure how to produce the exact same or similar behaviour. Is there any other way I could solve my problem?
In case you'd like to take a look at the code I'm using to parse the AD structures, it's taken from the aforementioned Dave Smith's github and can be found here. The only change I did to that class was add the following method:
public byte[] getData() {
return mData;
}
And this is how I handle the callback from the scans:
// Prepare the callback for BLE device scan
this.leScanCallback = new BluetoothAdapter.LeScanCallback() {
#Override
public void onLeScan(final BluetoothDevice device, int rssi, byte[] scanRecord) {
if (!deviceList.contains(device)) {
MyService.this.deviceList.add(device);
Log.e("Test", "Device: " + device.getName());
List<AdRecord> adRecords = AdRecord.parseScanRecord(scanRecord);
for (AdRecord adRecord : adRecords) {
if (adRecord.getType() == AdRecord.TYPE_TRANSMITPOWER) {
Log.e("Test", "size of payload: " + adRecord.getData().length);
Log.e("Test", "payload: " + Byte.toString(adRecord.getData()[0]));
}
}
}
}
};
And what I see in the console is:
04-01 11:33:35.864: E/Test(15061): Device: estimote
04-01 11:33:36.304: E/Test(15061): Device: estimote
04-01 11:33:36.475: E/Test(15061): Device: n86
04-01 11:33:36.475: E/Test(15061): size of payload: 1
04-01 11:33:36.475: E/Test(15061): payload: 0
04-01 11:33:36.525: E/Test(15061): Device: f79
04-01 11:33:36.525: E/Test(15061): size of payload: 1
04-01 11:33:36.525: E/Test(15061): payload: 0

The txPower mentioned by #davidgyoung is given by the formula:
RSSI = -10 n log d + A
where
d = distance
A = txPower
n = signal propagation constant
RSSI = dBm
In free space n = 2, but it will vary based on local geometry – for example, a wall will reduce RSSI by ~3dBm and will affect n accordingly.
If you want the highest possible accuracy, it may be worthwhile to experimentally determine these values for your particular system.
Reference: see the paper Evaluation of the Reliability of RSSI for Indoor Localization by Qian Dong and Waltenegus Dargie for a more detailed explanation of the derivation and calibration.

double getDistance(int rssi, int txPower) {
/*
* RSSI = TxPower - 10 * n * lg(d)
* n = 2 (in free space)
*
* d = 10 ^ ((TxPower - RSSI) / (10 * n))
*/
return Math.pow(10d, ((double) txPower - rssi) / (10 * 2));
}

It is unclear whether your inability to read the "txPower" or "measuredPower" calibration constant is due to the AdRecord class or due to the information being missing from the advertisements you are trying to parse. It doesn't look to me like that class will parse a standard iBeacon advertisement. Either way, there is a solution:
SOLUTION 1: If your beacons send a standard iBeacon advertisement that includes the calibration constant, you can parse it out using code in the open source Android iBeacon Library's IBeacon class here.
SOLUTION 2: If your beacons DO NOT send a standard iBeacon advertisement or do not include a calibration constant:
You must hard-code a calibration constant in your app for each device type you might use. All you really need from the advertisement to estimate distance is the the RSSI measurement. The whole point of embedding a calibration constant in the transmission is to allow a wide variety of beacons with quite different transmitter output power to work with the same distance estimating algorithm.
The calibration constant, as defined by Apple, basically says what the RSSI should be if your device is exactly one meter away from the beacon. If the signal is stronger (less negative RSSI), then the device is less than one meter away. If the signal is weaker (more negative RSSI), then the device is over one meter away. You can use a formula to make a numerical estimate of distance. See here.
If you aren't dealing with advertisements that contain a "txPower" or "measuredPower" calibration constant, then you can hard-code a lookup table in your app that stores the known calibration constants for various transmitters. You will first need to measure the average RSSI of each transmitter at one meter away. You'll then need some kind of key to look up these calibration constants in the table. (Perhaps you can use the some part of the string from the AD structure, or the mac address?) So your table might look like this:
HashMap<String,Integer> txPowerLookupTable = new HashMap<String,Integer>();
txPowerLookupTable.put("a5:09:37:78:c3:22", new Integer(-65));
txPowerLookupTable.put("d2:32:33:5c:87:09", new Integer(-78));
Then after parsing an advertisement, you can look up the calibration constant in your onLeScan method like this:
String macAddress = device.getAddress();
Integer txPower = txPowerLookupTable.get(macAddress);

use the getAccuracy() method in the library, it gives you the distance of the beacon

How to convert WiFi level (i.e. -45 , -88 ) in to percentage?

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)))

Polar Wearlink Bluetooth packet

i am looking at the code of a project called MyTracks:
http://code.google.com/r/jrgert-polar-bluetooth/source/browse/MyTracks/src/com/google/android/apps/mytracks/services/sensors/PolarMessageParser.java?r=ebc01faf49550bc9801633ff38bb3b8ddd6f5698
Now I am having problems with the method isValid(byte[] buffer). I don´t understand what exactly is he checking here. We want to know if the first byte in the array is the header containing 0xFE. I don´t quite understand the following lines :
boolean goodHdr = ((buffer[0] & 0xFF) == 0xFE);
boolean goodChk = ((buffer[2] & 0xFF) == (0xFF - (buffer[1] & 0xFF)));
return goodHdr && goodChk;
any ideas?

Ewoks is correct, refer to this blog post:
http://ww.telent.net/2012/5/3/listening_to_a_polar_bluetooth_hrm_in_linux
"Digging into src/com/google/android/apps/mytracks/services/sensors/PolarMessageParser.java we find a helpful comment revealing that, notwithstanding Polar's ridiculous stance on giving out development info (they don't, is the summary) the Wearlink packet format is actually quite simple.
Polar Bluetooth Wearlink packet example
Hdr - Len - Chk - Seq - Status - HeartRate - RRInterval_16-bits
FE - 08 - F7 - 06 - F1 - 48 - 03 64
where
Hdr always = 254 (0xFE),
Chk = 255 - Len
Seq range 0 to 15
Status = Upper nibble may be battery voltage
bit 0 is Beat Detection flag."

&0xff simply converts signed byte to unsigned int for doing the comparison

First line is checking is received buffer are starting with 0xFE as it should be with this Polar Wearable.
Second line is checking if length byte is correct as well because it's value by specification is 255-value writen is size byte..
This together is super simple verification that messages are correct (more complicated implementation would include CRC or other verification methods). cheers