• State Verified Answer
  • Replies 7 replies
  • Subscribers 88 subscribers
  • Views 5293 views
  • Users 0 members are here
Attachments (1) Download All
Nordic Case Info
  • Case ID: 268137
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

BLE using Notify of length less than current MTU size issue

tlgage

Hello, 

I am tinkering with some BLE configurations specifically related to MTU and throughput optimization, and my question relates to using Notify on my attribute value and how it relates to the currently set MTU size in a connection. 

I am using the following part, SD and SDK: 

NRF52832

SD132 v5.1

SDK v14.2

My device is running as a BLE peripheral Server, there is a mobile application connecting to it as a client. 

The client is subscribing to a characteristic which my device then uses Notify to send data to the mobile app client which works fine. In order to notify on the attribute I am using the standard function from the SD API:

uint32_t sd_ble_gatts_hvx

(

uint16_t 

conn_handle,

 

 

ble_gatts_hvx_params_t const * 

p_hvx_params 

 

)

 

 

My question centers around the data length specified in the “p_hvx_params” field and how that relates to the MTU size and what actually gets sent to the device. 

I am seeing a mismatch in what I set for the “p_hvx_params->p_len” and what actually gets sent to the mobile application. Every notify, the app sees the amount of data sent as the currently set MTU size, and not what I set for p_hvx_params->p_len.

For example, say I connect to the mobile app and MTU size is being set to 100 bytes. If I want to do a Notify less than 100 bytes, Iet's say 10 bytes, I do the following essentially: 

uint16_t len = 10;

p_hvx_params->p_len = &len;

sd_ble_gatts_hvx(conn_handle, p_hvx_params);

 

The mobile app is claiming to receive 100-3 bytes = 97 bytes of the data I send padded with 0s. This is the MTU size, - ATT header (3 bytes). I am expecting it to receive 10 bytes. 

 

So in summary, my question boils down to: As a peripheral server device, can you do a BLE Notify on a characteristic of length less than the MTU and am I doing it wrong with example code above? Maybe there is some configuration or step I am missing here. 

 

It is entirely possible there is a mobile application bug and I really am sending up data correctly, but interacting with other non-Nordic MCUs, the app is able to receive less data than the MTU length no problem, wondering if there is a specific difference with the Nordic SD here or I am doing something wrong. My next step is to get a sniffer setup to try and debug, but wanted to leave a post here to see if anyone has any advice or help they could give me.

Parents
  • 0

    Hello,

    As you mention, I also suspect that this might be an issue on the smartphone side. With a sniffer trace we would be able to pinpoint exactly which side the issue is on, and it would be very helpful if you could capture one and share here. We could then see exactly what is being sent on-air. The SoftDevice does not add padding to meet the maximal MTU size - this would be very wasteful in terms of power and radio time. Without seeing more code, or a trace, there is little more I can say at this point.

    I also notice in the code you use to illustrate the notification queueing that you are not checking the returned error code from sd_ble_gatts_hvx - this might have been omitted since it was besides the point you were illustrating, but I need to ask just in case.

    Looking forward to resolving this issue together!

    Best regards,
    Karl

  • +1 in reply to Karl Ylvisaker

    I think I just figured out my problem.

    When adding the attribute to the GATT table, when configuring the attribute meta data I noticed a field "vlen" which looks like it is for "variable length" which was set to 0. Just set it to 1, and now it seems working as expected, the app is able to receive smaller packets. 

    /**@brief Attribute metadata. */
typedef struct
{
  ble_gap_conn_sec_mode_t read_perm;       /**< Read permissions. */
  ble_gap_conn_sec_mode_t write_perm;      /**< Write permissions. */
  uint8_t                 vlen       :1;   /**< Variable length attribute. */
  uint8_t                 vloc       :2;   /**< Value location, see @ref BLE_GATTS_VLOCS.*/
  uint8_t                 rd_auth    :1;   /**< Read authorization and value will be requested from the application on every read operation. */
  uint8_t                 wr_auth    :1;   /**< Write authorization will be requested from the application on every Write Request operation (but not Write Command). */
} ble_gatts_attr_md_t;

    Woohoo! Appreciate all the help Karl. So happy to get this resolved. 

Reply
  • +1 in reply to Karl Ylvisaker

    I think I just figured out my problem.

    When adding the attribute to the GATT table, when configuring the attribute meta data I noticed a field "vlen" which looks like it is for "variable length" which was set to 0. Just set it to 1, and now it seems working as expected, the app is able to receive smaller packets. 

    /**@brief Attribute metadata. */
typedef struct
{
  ble_gap_conn_sec_mode_t read_perm;       /**< Read permissions. */
  ble_gap_conn_sec_mode_t write_perm;      /**< Write permissions. */
  uint8_t                 vlen       :1;   /**< Variable length attribute. */
  uint8_t                 vloc       :2;   /**< Value location, see @ref BLE_GATTS_VLOCS.*/
  uint8_t                 rd_auth    :1;   /**< Read authorization and value will be requested from the application on every read operation. */
  uint8_t                 wr_auth    :1;   /**< Write authorization will be requested from the application on every Write Request operation (but not Write Command). */
} ble_gatts_attr_md_t;

    Woohoo! Appreciate all the help Karl. So happy to get this resolved. 

Children
No Data
Related