CODEWITHSUNDEEP
androidbluetooth-lowenergy
Ryan
Ryan

Reputation: 36

Bluetooth BLE reliable write is not working as expected

Following is my reliable gatt characteristic reliable write function and byte array byte1 is having value more than 20 bytes.

private void beginReliableWriteToGattServer(BluetoothDevice device, UUID serviceUUID,UUID charUUID, byte[] byte1){

        if(mGatt != null){
            BluetoothGattService service = mGatt.getService(serviceUUID);
            if(service != null){
                BluetoothGattCharacteristic gattCharacteristic = service.getCharacteristic(charUUID);
                if(gattCharacteristic != null){
                    Logger.d(TAG, "BeginReliable Write="+mGatt.beginReliableWrite());
                    gattCharacteristic.setValue(byte1);
                    mGatt.writeCharacteristic(gattCharacteristic);
                    Logger.d(TAG, "ExecuteReliable Write="+mGatt.executeReliableWrite());

                }
            }
        }
    }

Below are write Gatt characteristic logs 
BeginReliable Write=true
ExecuteReliable Write=false
D/Bluetooth_GATTCallBack: onCharacteristicWrite 17

Upvotes: 0

Views: 1436

Answers (1)

Emil
Emil

Reputation: 18452

First, you can't have multiple GATT requests outstanding at the same time. Since both writeCharacteristic and executeReliableWrite are requests to the peer device (beginReliableWrite is not a request but only sets a flag in Android's BLE stack that the following writes are "reliable writes"), you need to first wait for the onCharacteristicWrite until you are allowed to send executeReliableWrite.

Now, regarding error code 17, I assume this corresponds to the ATT error code Insufficient Resources 0x11. To handle that you need to check why the peripheral sends that error code.

You should also know that Android has a design bug that reliable writes aren't really reliable. The protocol is that the data is first sent to the server, then the server sends the same data back to the client. According to the GATT specification, the client must then verify that the received data is equal to the sent data, otherwise it must abort. Unfortunately that info gets lost between the C and Java layer in Android's Bluetooth stack so there is no way to verify this.

Upvotes: 3

Related Questions