1 Reply Latest reply on May 3, 2018 9:05 AM by epr_1639216

    Best way to handle dropped Write Requests

      I am working an application whereby I have a Central and multiple Peripherals.  The desire is for the Central to send data to the Peripherals.

       

      It goes through a process of scan, connect, write data, disconnect, etc…

       

      Initially I was using :

         CyBle_GattcWriteWithoutResponse

      but sometimes the messages were getting dropped.

       

      I changed to using:

      CyBle_GattcWriteCharacteristicValue

       

      This function results in CYBLE_EVT_GATTC_WRITE_RSP if the response is received.  I have a time monitor so that if the response does not come back in time (80ms), I try to send the write a second time with another call to: CyBle_GattcWriteCharacteristicValue

      If I call that function a second time, I get a CYBLE_ERROR_INVALID_OPERATION

       

      Is there a way to resend a message if I don’t get a response?  Is there a better way to determine that a write was not successful and resend it promptly?  Or do I need to disconnect, reconnect, and resend?

       

        • 1. Re: Best way to handle dropped Write Requests

          The function CyBle_GattcWriteCharacteristicValue() will return the event CYBLE_EVT_GATTC_ERROR_RSP or CYBLE_EVT_GATTC_WRITE_RSP depending on successful write of the characteristic.

          You should be waiting until you get one of those responses.

          Potentially, you can try the function CyBle_GattcReliableWrites() to reliably write the data. (See the BLE datasheet/API reference by right-clicking on the BLE component in the PSoC Creator IDE and selecting the "Open Datasheet"/"Open API Documentation")

          Calling another write request should be fine, but it could be you are sending the request too quickly depending on your BLE Tx/Rx windows/timing/latency before the chip has time to timeout/try the request.

           

          You shouldn't have to reconnect to try a BLE request command. Try bumping your time from 80ms up to say 1 or 2 seconds to see if you are getting one of the two write responses before attempting a new write. The INVALI_OPERATION error generally occurs if you are trying to do something that is impossible (connect while scanning, advertise while in central mode, etc.) or if the BLESS can't perform that operation ATM (calling again later may or may not work).