BLE Notification Throughput & Characteristics

[leonhart88]

Hi All,

I'm working with SDK 12.3.0 and an nrf52832.  I currently have 3 characteristics in my custom service.  They are 17, 11, and 6 bytes long and are used to send sensor data in various configurations.

What I've noticed is that if I send 20,000 notifications, the throughput drops proportionally to how large each characteristic is.  For example, if I send 20,000 characteristic updates as fast as I can, I get the following throughput (using a Pixel 2 and nrfConnect timestamps):

• 17-byte characteristic: 8.7kB/s
• 11-byte characteristic: 5.5kB/s
• 6-byte characteristic: 3.5kB/s

I'm assuming this is because there is overhead associated with the sending of each PDU and every time I send a notification it sends out a PDU.  This means that in order to maximize my throughput, I actually want to cram as much data that will fit into my PDU as I can.

I suppose one way around this would be to create a characteristic which is, say, 20 bytes in length, and then buffer the sensor data and then send out 20 bytes every time.  However, in the case of larger MTU sizes and DLE, I guess I would need to take care of the following:

1. I need to keep track of the connection MTU size so I can send the optimal number of bytes per notification
2. I need to set the characteristic max length to the max MTU size and enable the variable length attribute

Is my perception here accurate?

I was having difficulty with setting and verifying the MTU size on connection for SDK 12.3.0 (I have it working fine for SDK 14.0.0), but I'll start another thread for that if necessary.

[Edvin]

Hello,

It is correct that a characteristic with shorter payload will have a larger header/payload ratio, and thus will have a lower payload throughput.

I don't know what sort of characteristics you have, but if you need as much throughput as possible, I would recommend that you put them all in a single characteristic, and increase the MTU, and send as large packs as possible.

 

You can use the function nrf_ble_gatt_att_mtu_periph_set() which is described (for central and peripheral) here. Also there is a description on how to check the MTU for a connection.

I have not tested too much with increased MTU in SDK12, but I can confirm, as you say, that it works in SDK14(.1.0).

What problems do you have in SDK12.3.0?

 

Best regards,

Edvin

 

[leonhart88]

Thanks for the confirmation Edvin.  Glad to know my thought process and observations are expected.

I've inherited an existing code base with SDK 12.3.0 and S132 v3.0.0 and it looks like nrf_ble_gatt_att_mtu_periph_set() is called in the gatt_init() function as well as an MTU update handler.

However, I call nrf_ble_gatt_eff_mtu_get at several times in the code to check the actual MTU size but it always shows 23.  I know that my phone supports more than that based on tests with a modified UART example on SDK 14.0.0.

I need to compare the existing code more closely to other SDK 12.3.0 examples, but do I need to call nrf_ble_gatt_att_mtu_periph_set() after the connection has been established?

[leonhart88]

Also, if I do a MTU request from nrfConnect mobile, my MTU update handler gets called properly and I don't get any error from setting the MTU.  But if I check the MTU size later using nrf_ble_gatt_eff_mtu_get, it still shows me the MTU is 23.

I basically see something like what was reported in this post:

devzone.nordicsemi.com/.../changing-mtu-size-in-ble_peripheral-problem

[Edvin]

Hello,

Please see the attached project. I used Keil µVision, but except for changing the ram start and size, I don't think there were any changes to the project, except for the main.c file and the sdk_config.h file, so any IDE should work.

 

Notice how the nrf_ble_gatt_att_mtu_periph_set() is called on the connected event (on line 720 in main.c). and where it is printed in the gatt event handler (on line 1020 in main.c). Try to connect with both the nRF Connect app, and the desktop application, and see that you will probably receive different MTUs. The MTU is printed on the UART, so open Putty or Termite to see what is going on.

ble_app_hrs.zip

The project is for SDK12.3.0.

Best regards,

Edvin

[leonhart88]

Thanks Edvin.  I'll take a look at this after I finish some other implementation work.  Will let you know if I have further questions or if this solves the issue.  Thanks!