WebBluetoothCG / ble-test-peripheral-android

A BLE Peripheral Simulator App
https://play.google.com/store/apps/details?id=io.github.webbluetoothcg.bletestperipheral
Apache License 2.0
388 stars 129 forks source link

Problem with Thermometer #89

Open aydinakcasu opened 7 years ago

aydinakcasu commented 7 years ago

It appears the logic for the Temperature may be off.
I think the bits for the Centigrade values may need to be shifted by one more: C Value: Byte 3,4 actual, Byte 3,4 expect 1: Actual 0, 7f, Expect 80, 3f 2: Actual 0, 80, Expect 00, 40 3: Actual 40, 80 , Expect 40, 40

beaufortfrancois commented 7 years ago

Here's what I'm doing: https://github.com/WebBluetoothCG/ble-test-peripheral-android/blob/785012e3437615055a3ea3c43c3976fb73307837/app/src/main/java/io/github/webbluetoothcg/bletestperipheral/HealthThermometerServiceFragment.java#L237-L262

aydinakcasu commented 7 years ago

Upon further investigation, it seems like your logic is correct. For example, if '1' is the input value,
the internal hex bytes are (https://gregstoll.dyndns.org/~gregstoll/floattohex/): 3f 80

This works out to be:

On the reading end, if we look at the raw bytes (byte 3,4), we get: 7f 00 We should have:
3f 80 unless we are not storing in standard float formats. Maybe it is storing bytes directly as exponent, mantissa, which will cause problems down the line.

It appears that maybe 'setValue(mantissa, exponent" is not working correctly.

image

aydinakcasu commented 7 years ago

Some more info: https://android.googlesource.com/platform/frameworks/base.git/+/master/core/java/android/bluetooth/BluetoothGattCharacteristic.java

1) setValue(int mantissa, int exponent, int formatType, int offset) is consistent with what we are seeing.
It is not storing as a regular float, just the raw bytes of the mantissa, and exponent.

2) Furthermore, the code for the getFloatValue is odd. It eventually calls bytesToFloat, and uses the wrong logic.

bytesToFloat(mValue[offset], mValue[offset + 1], mValue[offset + 2], mValue[offset + 3]); It does this to the last parameter (b3): (mantissa * Math.pow(10, b3)) It seems like it should not be based on powers of 10.

Maybe this is old code.

akapelrud commented 3 years ago

I know this is an old issue, just commenting for future reference. It seems that BLE uses IEEE 11073 encoded floating numbers, which are based on base-10. So there are 8bits assigned to the exponent and 24bits assigned to the mantissa. No sign bit, as usual; the mantissa is instead signed.