1

I resolved the previous using but unfortunetly now , When I am writing the end byte doing this :

   case "OTAEND":
                Log.d("OTAEND", "Called");
                handler.postDelayed(new Runnable() {
                    @Override
                    public void run() {
                        writeOtaControl((byte) 0x03);
                    }
                },500);
                break;

Using this method : 

  /**WRITES BYTE TO OTA CONTROL CHARACTERISTIC*****************************************/
    public boolean writeOtaControl(byte ctrl) {
        Log.d("writeOtaControl", "Called");

        if (bluetoothGatt.getService(ota_service)!=null){
            BluetoothGattCharacteristic charac = bluetoothGatt.getService(ota_service).getCharacteristic(ota_control);
            if (charac != null) {
                Log.d("Instance ID", "" + charac.getInstanceId());
                charac.setWriteType(BluetoothGattCharacteristic.WRITE_TYPE_DEFAULT);
                Log.d("charac_properties", "" + charac.getProperties());
                byte[] control = new byte[1];
                control[0] = ctrl;
                charac.setValue(control);
                bluetoothGatt.writeCharacteristic(charac);
                return true;
            } else {
                Log.d("characteristic", "null");
            }
        } else {
            Log.d("service", "null");
        }
        return false;
    }

Inside this callback I got status with error code 129 which is not even in documentation on BLE.

  @Override //CALLBACK ON CHARACTERISTIC WRITE (PROPERTY: WHITE)
        public void onCharacteristicWrite(BluetoothGatt gatt, BluetoothGattCharacteristic characteristic, int status) {


            if (status != 0){ // Error Handling
                Log.d("onCharWrite", "status: " + Integer.toHexString(status));
                final int error = status;
                runOnUiThread(new Runnable() { //Display error on Toast
                      @Override
                      public void run() {
                          Toast.makeText(getBaseContext(), charErrorHandling(error), Toast.LENGTH_LONG).show();
                      }
                });

Here is my HCl log :

HCL LOG

Another LOG

trOnk12
  • 713
  • 6
  • 10
  • 129=0x81 means "Application Error" according to the ATT specification. Unfortunately, Android also emits this error if something else went wrong if I'm not mistaken. You should read the HCI log to see what happens. And do you see any write on the peripheral side? – Emil Apr 13 '18 at 16:43
  • What do you mean with HCl log ? ;) And no i dont see write i think – trOnk12 Apr 13 '18 at 16:45
  • https://stackoverflow.com/questions/23877761/sniffing-logging-your-own-android-bluetooth-traffic – Emil Apr 13 '18 at 16:53
  • thank you very much for at least some direction i can go :) Does this HCI show me the request I am making with peripheral ? do you have any idea why this is happening ? Could it be on peripheral side or is it on Android side ? – trOnk12 Apr 13 '18 at 16:56
  • 1
    Most likely the peripheral side. You can see all ATT packets in the HCI log, so you should be able to see on which side the problem is. – Emil Apr 13 '18 at 17:11
  • And last question before Ill start working on it again on tuesday . Can you send me some good information about ATT as i cant find much how it works and stuff and thank you I hope you can help me further after weekend :) – trOnk12 Apr 13 '18 at 17:13
  • @Emil hey emil so i used HCi log and this is what I get when trying to send data : Error Response - Request not supported, Handle0x0000 – trOnk12 Apr 18 '18 at 11:44
  • Can you upload the full log? – Emil Apr 18 '18 at 15:46
  • I added the link to my log on the post @Emil – trOnk12 Apr 19 '18 at 09:40
  • Ok so I opened the log in Wireshark. You can see that the Android side tries to write a "long" value to a characteristic (more than 20 bytes). But Long writes are not supported by the peer; it fails with Request not supported. You could try to increase the mtu using requestMtu in the Android API, or simply make sure you write smaller data. You could also try Write Without Response to increase the throughput (setWriteType of the characteristic in Android). And when you finally write your 0x03 to the control point, the peer responds with 0x81 (Application error), probably due to no received data – Emil Apr 19 '18 at 11:35
  • How do you know all that stuff ? That it is not being supported for example ? How can you see it in log ? And by 0x81 you mean that because the data send from my file is too long and thats why it says application error ? – trOnk12 Apr 19 '18 at 11:46
  • If you open it in Wireshark, check out packet number 36814. "Error Response - Request Not Supported". And packet number 38042, the response to the final write to the "ota control" characteristic, contains error code 0x81 which means Application Error. Application Error codes are not defined to mean something particular by the standard, but is up to the specific implementation what it means. It is like when a HTTP server returns 500 or similar. – Emil Apr 19 '18 at 12:29
  • Hey @Emil your suggestion solved one problem - not supported request . But now I got error 129 even when I am trying to send data . I uploaded another HCi log , I really really hope you can help me out ... as there is totally nothing to guide me in this issue. – trOnk12 Apr 19 '18 at 12:51
  • Ok so now the peripheral responds with 0x81 Application Error on every write you perform. You need to figure out why the peripheral doesn't like your write requests. – Emil Apr 19 '18 at 14:30
  • And do you have any idea how I can find it out ? – trOnk12 Apr 19 '18 at 14:30
  • Your Question only contains details and code about the client side. Since it is the server that return results that are not understandable without further information, you could show the server code and the lines where it returns error 0x81 (application error). Also make sure first that you have correctly followed the documentation or similar for the GATT profile you are trying to interact with. – Emil Apr 19 '18 at 21:02

0 Answers0