This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

MTU_SIZE and NRF_ERROR_RESOUCES

Hello.

When Notifying about 100 bytes of data, sd_ble_gatts_hvx() is sent 5 times.
Occasionally NRF_ERROR_RESOUCES occurs.
Currently MTU_SIZE is 23, and the actual data length that can be Notify is 20 bytes.

1. If MTU_SIZE is increased to 103 and 100 bytes of data is notified by sd_ble_gatts_hvx() once, NRF_ERROR_RESOUCES will not occur.
Is this correct?

2. When I extend not only MTU_SIZE but also the characteristic data length to 100 bytes, I think it is possible to connect and communicate with most recent phones, but if I try to connect with an old phone with MTU_SIZE 23, I don't think I can connect. In such a case, does the user have to implement the selection process, such as adjusting the data length of the characteristic according to the MTU_SIZE of the connection partner?

Thank you.

  • Hi Yoshino-san,

    1. If MTU_SIZE is increased to 103 and 100 bytes of data is notified by sd_ble_gatts_hvx() once, NRF_ERROR_RESOUCES will not occur.
    Is this correct?

     Increasing MTU_SIZE and increasing the event length would decrease the frequency of TX buffers filling up and hence the reduced frequency of NRF:ERROR_RESOURCES. Please note that this error is not a panic error, it just means that the application have to try to send the data again after sometime as the TX Buffers are all used up.

     

    2. When I extend not only MTU_SIZE but also the characteristic data length to 100 bytes, I think it is possible to connect and communicate with most recent phones, but if I try to connect with an old phone with MTU_SIZE 23, I don't think I can connect. In such a case, does the user have to implement the selection process, such as adjusting the data length of the characteristic according to the MTU_SIZE of the connection partner?

     There are connection parameter negotiations that will happen just after the connection is established. And if the peer does not support any other MTU size apart from 23, then your device will fall back to MTU size 23. Hence it is very important that you handle the NRF_ERROR_RESOURCES error properly in your application by waiting and re-sending the data.

  • Susheel-san
    Thank you for your reply.

    And if the peer does not support any other MTU size apart from 23, then your device will fall back to MTU size 23.

    If the device reads/writes a characteristic with a data length of 100 bytes, should I change the characteristic data length to 20 bytes instead of 100 bytes in case the MTU_SIZE falls back to 23?
    (When performing BLE communication with various phones, I want to adjust the data length of the characteristic that reads and writes according to the MTU_SIZE of the phone.)

    I recognize that when MTU_SIZE is 23, the characteristic data length is 20 bytes at maximum. When MTU_SIZE is 103 bytes, the maximum data length of characteristic data is 100 bytes. Is this correct?

    Thank you.

  • Yoshino-san,

    suke said:
    If the device reads/writes a characteristic with a data length of 100 bytes, should I change the characteristic data length to 20 bytes instead of 100 bytes in case the MTU_SIZE falls back to 23?

     No, When you write to a characteristic with data of 100 bytes, it gets automatically split 100/(23-3) = 5 packets by the BLE stack and written to the peer after all the 5 packets are transmitted. So the application does not have to do anything. The transmit of 100 bytes is slower since with MTU = 23 then data is split and transmitted in smaller chunks.

     

    suke said:
    (When performing BLE communication with various phones, I want to adjust the data length of the characteristic that reads and writes according to the MTU_SIZE of the phone.)

    You can set the maximum MTU size that the application can handle (for example 247) and when the peer only supports smaller size, then the BLE stack on your application will fall back automatically to smaller size that the peer supports. Falling back to smaller size is no problem, but supporting bigger MTU size than what you application can handle does not happen automatically. 

     

    suke said:
    I recognize that when MTU_SIZE is 23, the characteristic data length is 20 bytes at maximum. When MTU_SIZE is 103 bytes, the maximum data length of characteristic data is 100 bytes. Is this correct?

     That is correct, please take a look here

Related