Sending large file with BLE notifications: throughput seems limited

[JuanHG]

Hello,

I am trying to send a large file through BLE from an nRF52811 to a Raspberry Pi 4. File size is about 77 kilobytes.

Here is BLE setup on the nRF side:

• Custom profile
• Data characteristic has a 509 bytes length
• Notifications enabled
• For throughput testing purpose, nRF sends 509 bytes notifications back to back:
  • Send first notification as soon as notifications have been enabled
  • Send the next notification as soon as the BLE_GATTS_EVT_HVN_TX_COMPLETE event has been triggered in ble_evt_handler() function on main.c
  • etc.

On the Raspberry Pi side:

• Use gatttool in interactive mode
• Change mtu to 512 by "mtu 512" command
• Activate notifications by writing 0100 value to characteristic CCCD
• gatttool prints the values (succesfully gets the 509 bytes for each notification)

My problem is that I cannot make the nRF send more than about 4 notifications per second.

I tried to decrease the connection interval as low as I could while keeping the nRF from crashing but the lowest values I could get are:

• MIN_CONN_INTERVAL = 8 x 1.25 ms
• MAX_CONN_INTERVAL = 50 x 1.25 ms

Anything lower than that cases the nRF to stay stuck either right away when really fast, or after having sent a few notifications.

If I try to send multiple notifications without waiting for the BLE_GATTS_EVT_HVN_TX_COMPLETE  event the nRF also gets stuck.

I've seen on this post  dealing large data packet's through ble to call the sd_ble_gatts_hvx() multiple times until the BLE_ERROR_NO_TX_BUFFERS error is returned but in my case the function returns 0 (ok) but stays stuck.

Is there a way to increase the rate of notifications without the nRF being stuck ?

BTW the Softdevice is s112.

Thanks in advance.

[Kenneth]

Hello,

An on-air sniffer log, e.g. using nRF sniffer for BLE could be helpful to understand what may be limiting the throughput in specific. 

There is a nice blogpost here that describe how to improve throughput:
https://novelbits.io/bluetooth-5-speed-maximum-throughput/ 

Have in mind that S112 does not support Data Length Extension (DLE), which means the maximum packet that can be sent on-air is only 23bytes (so the ~500byte MTU will be split into several 23byte on-air packets), this will decrease the throughput a lot. I recommend to consider the S113 that support up to 244bytes of data in each packet.

Best regards,
Kenneth

[JuanHG]

Hi Kenneth,

Thanks a lot for your answer !

I have succeeded in using the BLE sniffer and thus saw that notification payloads are indeed split into multiple PHY packets.

I was able to switch to S113 but unfortunately this leads to the following runtime error because of lack of flash:

<error> peer_manager_pds: Could not initialize flash storage. fds_init() returned 0x860A.
<error> peer_manager: pm_init failed because pds_init() returned NRF_ERROR_STORAGE_FULL.
<error> app: Fatal error
<warning> app: System reset

How can I know how much data I need to save in my code to make the peer manager have enough memory available ?

Thanks in advance

Best regards

[JuanHG]

Hi Kenneth,

Do you have an idea of how I may solve the described issue ?

Thanks in advance

[Kenneth]

If you compile in SES you should for instance see something like:

then, it depends on whether you also have a bootloader at the end of flash how much flash will be availble for FDS.

Typically the *.map file in your build output should give information about RAM and code usage, look for 'Image component sizes' for instance if compiled with Keil. 

Kenneth