CODEWITHSUNDEEP
androidbluetooth-lowenergybluetooth-gatt
elcuco
elcuco

Reputation: 9208

BLE read RSSI values unreliable

I am trying to properly read the RSSI of a BLE device I am connected to in order to send it to an upstream server.

I found that the RSSI returned by BluetoothGatt.readRemoteRssi() has a lot of "jumps". I started doing a running average (over the last 10 seconds) to get a more smooth value. This did not help as the value had a lot of spikes.

I found that doing mBluetoothAdapter.startLeScan(null); makes the values smoother. I know that the official documentation discourages from scanning while being connected to a device, but in practice - on an LG and Samsung devices it does work.

Further on - if I pass null as the callback, this method should do nothing (see https://github.com/aosp-mirror/platform_frameworks_base/blob/master/core/java/android/bluetooth/BluetoothAdapter.java#L2833). Which leads me to believe that Samsung and LG do modify the Android Bluetooth stack a lot.

Can anyone explain what am I seeing? Can anyone offer a better solution for reading "real" RSSI values?

edit:

I found that onCharasteristicWritten() is called several (?) times with the same value, even tough the HW did send it only once. We are filtering those values manually right now. Also onRssiRead() is called several times.

This may be the reason why Android documentation suggests not scanning while connected to a BT device.

Upvotes: 0

Views: 856

Answers (1)

Emil
Emil

Reputation: 18517

The readRemoteRssi method returns the rssi value for a connected device, as measured by the Bluetooth controller. Note that a BLE connection operates on up to 37 channels, and jumps on every connection event.

The rssi values you get when you scan, are the rssi values for every advertising packet. Advertising happens on only three channels.

The Bluetooth stack on the host side, i.e. the software in Android running on the main CPU does not alter the rssi value measured by the Bluetooth controller.

So the only reason I can see for your different results is that different radio channels have different noise/quality or similar. And as you probably can read much about on the net is that rssi will vary quite much, and that's just what we have to live with. See https://www.google.com/search?q=ble+channels for details about the different radio channels.

Also note that far from all peripherals continue to advertise when they are already connected to something.

If you think passing null does nothing, maybe you could check logcat and see if the expected error message is printed? I can't however explain how a scan would alter the values returned by readRemoteRssi for an already connected device, since that makes no sense. If you think that's black magic you have to ask the Bluetooth controller company ;)

Upvotes: 2

Related Questions