Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Is it necessary handle BLE_EVT_USER_MEM_REQUEST, respectivly is it required to support prepared writes?

Until lately, I have never used characteristics longer than the 20 Bytes and if the length of application data was longer, I would fragment it on the application layer.

Recently, I started experimenting with increasing the Att MTU size and the link layer PDU size. To really be able to make use of this, it is of course useful if characteristic length is increased to accommodate the larger MTU of up to 247 Bytes, i.e. I increased characteristic size to 244 Bytes variable length characteristic.

I then noticed, that if I connect to the device using an older smart device (e.g. iPad 4, using Light Blue), a write of more than 20 Bytes of data will result in a prepared write request being transmitted and thus, the Softdevice will emit BLE_EVT_USER_MEM_REQUEST. For the time being, I do not see any benefits in supporting prepared writes - I'm planning to make use of the higher characteristic length only if an increased MTU size is actually used during the connection.

  • Do I have to handle BLE_EVT_USER_MEM_REQUEST? What happens if I do not handle this event?
  • If I handle the event by calling sd_ble_user_mem_reply with p_block == NULL, I will receive a BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST. How do I have to respond to this request if I don't want to support prepared writes?
  • Would it be easier to just support prepared writes?
  • What happens if I pass a buffer that is too small to sd_ble_user_mem_reply?

Thank you for your response,

-mike

Parents
  • Hi,

    I have some answers to your bullet points:

    • Do I have to handle BLE_EVT_USER_MEM_REQUEST? What happens if I do not handle this event?
      If you don't handle the event the write request will time out and the peer will probably disconnect. Whether it disconnects or not is up to the peer. 

    • If I handle the event by calling sd_ble_user_mem_reply with p_block == NULL, I will receive a BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST. How do I have to respond to this request if I don't want to support prepared writes?
      You can see how it can be done in the Heart Rate Application example. 

    • Would it be easier to just support prepared writes?
      That is probably up to you to decide.

    • What happens if I pass a buffer that is too small to sd_ble_user_mem_reply?
      Passing a buffer smaller than requested results in error NRF_ERROR_INVALID_LENGTH.
Reply
  • Hi,

    I have some answers to your bullet points:

    • Do I have to handle BLE_EVT_USER_MEM_REQUEST? What happens if I do not handle this event?
      If you don't handle the event the write request will time out and the peer will probably disconnect. Whether it disconnects or not is up to the peer. 

    • If I handle the event by calling sd_ble_user_mem_reply with p_block == NULL, I will receive a BLE_GATTS_EVT_RW_AUTHORIZE_REQUEST. How do I have to respond to this request if I don't want to support prepared writes?
      You can see how it can be done in the Heart Rate Application example. 

    • Would it be easier to just support prepared writes?
      That is probably up to you to decide.

    • What happens if I pass a buffer that is too small to sd_ble_user_mem_reply?
      Passing a buffer smaller than requested results in error NRF_ERROR_INVALID_LENGTH.
Children
No Data
Related