cancel
Showing results for 
Search instead for 
Did you mean: 

STM32WBA BLE Data Throughput example : throughput optimization

SnoZek
Associate II

Hello everyone,

I'm currently working with the STM32WBA65RI Nucleo board.

For my upcoming application, I require a stable BLE throughput of over 800 kbps. However, using the provided example, I can only achieve around 600 kbps.

So far:

  • I'm using an MTU of 244 bytes.

  • 2M PHY 
  • Manage to minimize connection interval : 11.25 ms when using the ST BLE Toolbox app, and 7.5 ms when using a custom script on Windows.

  • I’ve tested with several smartphones/ configuration and also tried increasing the MCU clock, but none of these changes improved the performance significantly.

Has anyone managed to achieve a higher throughput with this setup or found effective optimizations?

Thanks in advance for any insights.

1 ACCEPTED SOLUTION

Accepted Solutions

Hello @SnoZek 

As you can see on the Data throughput measurement - stm32mcu chapter 6, you may need to modify parts on the APP_BLE_Init function to achieve the TX expected results.

Best Regards.

STTwo-32 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

View solution in original post

8 REPLIES 8
Lina_DABASINSKAITE
Community manager
Community manager

Hello @SnoZek,

This post has been escalated to the ST Online Support Team for additional assistance.  We'll contact you directly.​  

Best regards,​  

Lina


In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
_Joe_
ST Employee

Hi SnoZek,

This limitation originates from the smartphone used.
We conducted data throughput benchmarks.
For downloads (from STM32 to the smartphone) at PHY 2M, the average throughput was approximately 600 kbps.

For uploads (from the smartphone to STM32), the results are even more dependent on the smartphone and range from 250 kbps to 680 kbps.

The following wiki page will be updated with graphs in the coming days:
STM32WBA Bluetooth® LE – Data throughput measurement - stm32mcu

Between two WBAs, data throughputs of around 950 kbps can be achieved.

BR, Joé



SnoZek
Associate II

Hi Joé,

Thanks a lot for your answer and for sharing your benchmark results, they really helped me better understand my own measurements.

To verify, I made sure the parameters were correctly set:

  • DLE enabled

  • ATT MTU = 247

  • PHY = 2M

  • Tried several connection intervals (9, 11.25, 26.25, 30, 50, 300 ms…)

I observed that the shorter the connection interval, the higher the throughput.

You mentioned:

"Between two WBAs, data throughputs of around 950 kbps can be achieved."

I was aiming to reach similar performance using a NUCLEO-STM32WBA65RI (server) and a NUCLEO-STM32WBA55CGA (client).
I first flashed the ST example applications without any modifications, but I wasn’t able to match your performance.
Even after reducing the connection interval to 8.75 ms, I couldn’t achieve more than ~60,000 bytes/s.

Could you share me the configuration you did to acheive 900 kbps ?

Thanks, 
Yvan

Hello @SnoZek 

As you can see on the Data throughput measurement - stm32mcu chapter 6, you may need to modify parts on the APP_BLE_Init function to achieve the TX expected results.

Best Regards.

STTwo-32 

To give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.

Hello,

Yes, I saw the updates on the Wiki.
With these changes, I was able to reach a stable throughput of 900 kbit/s (WBA server to WBA client).

@_Joe_  I also tried applying what’s described in chapter 6 of the Wiki:

void APP_BLE_Init(void)
{
  ...
  
  /* USER CODE BEGIN APP_BLE_Init_2 */
  const uint8_t a_BLE_rx_pckt_count_and_rx_pckt_len[2] = { 0x07, 0x00 }; /* rx_pckt_count , rx_pckt_len */
  aci_hal_write_config_data(CONFIG_DATA_LL_RX_ACL_CTRL_OFFSET, 2, a_BLE_rx_pckt_count_and_rx_pckt_len);
  /* USER CODE END APP_BLE_Init_2 */
}

With this modification, I achieved even better one way throughput with my phone — about 100 kB/s.
It seems the limitations were not only due to the phone’s Bluetooth stack. I’d recommend testing again with several different phones after applying these updates.

Thanks to everyone for your help and support,
Yvan


@SnoZek wrote:

I observed that the shorter the connection interval, the higher the throughput.


Yes, that would be expected:

https://punchthrough.com/ble-throughput-part-4/#:~:text=Connection%20Interval%3A%20The%20connection%20interval%20is%20the%20time%20period%20during%20which%20the%20central%20and%20peripheral%20devices%20communicate%20with%20each%20other

The trouble with testing against a phone (or tablet, computer, etc) is that the phone decides on the Connection Interval to use.

Your software can request a particular interval, but the phone decides what interval will actually be used.

What interval the phone chooses can change from connection to connection.

 

https://interrupt.memfault.com/blog/ble-throughput-primer

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.
SnoZek
Associate II

That’s correct, the phone has the final word on the connection interval. However, with the BLE Throughput example, you can still request a specific interval. (using Button)

On iOS, the system is more restrictive and typically enforces an interval around 30 ms. On Android, though, you can often achieve much lower values down to 7.5 ms, or at least 11.25 ms which makes it possible to reach significantly better throughput.

Yvan


@SnoZek wrote:

with the BLE Throughput example, you can still request a specific interval. (using Button)


Indeed - but it's still up to the phone whether it grants that or not.

 


@SnoZek wrote:

On Android, though, you can often achieve much lower values down to 7.5 ms, 


It's admittedly a while since I last tried it, but even Android phones can be reluctant to give the lowest intervals.

maybe newer phones and/or newer Android versions are more disposed to give the higher rates?

As noted in one of the linked articles, BLE was originally very much about small amounts of data; now that has changed, maybe phones & mobile OS have upped their game?

A complex system that works is invariably found to have evolved from a simple system that worked.
A complex system designed from scratch never works and cannot be patched up to make it work.