BLE UART Bridge Throughput Limitation at 1Mbps PHY and 7.5ms CI — Packet Count per Interval?

[Pedro]

Hi Nordic team,

I'm implementing a BLE UART bridge (emulating the old SPP profile) using a custom service. The central device (dongle) I'm using only supports the classic BLE packet structure with 20 bytes of application payload per packet.

I'm currently running at 1 Mbps PHY with a connection interval of 7.5 ms. Given the 150 µs inter-frame spacing (IFS), in theory I could fit up to 16 packets per connection interval, which would result in a maximum data throughput of about 0.34 Mbps for application payload.

However, I'm not achieving that throughput in practice (I start having problems if I try to transmit with an application payload data throughput of more than 0.13 Mbps). I have a few specific questions regarding how this works in the Nordic BLE stack and Zephyr:

1. Are 16 packets per connection interval actually transmitted? Or is there a limit imposed by the BLE stack that reduces this?

2. Is the number of packets per connection interval configurable in Zephyr? If so, How can I set this limit?

3. Is there a requirement to leave a "gap" at the end of each connection interval? In other words, what happens if the last packet transmission overlaps with the start of the next connection interval? Does the stack prevent this and enforce idle time before the next interval?

I’m trying to optimize the link throughput as much as possible within the constraints of classic BLE (no DLE, 1M PHY), and I’d appreciate any insight on these low-level scheduling details.

Thanks in advance for your help!

Best regards,

Pedro.

[Kenneth]

Hello,

If you want to understand better timing and what is the limitation etc. I recommend to for instance attach a BLE sniffer or you can consider an Nordic PPK II to measure the current in real-time, this will then show the time-on air and find what is limiting the throughput.

There will be some pre- and post-processing required for each interval, adjustment for clock drift, and this may have quite a large impact when the connection interval is only 7.5ms. It may also be that the dongle you have for some reason close the connection event before you reach the entire period.

You can also indirectly use the online power profile app: https://devzone.nordicsemi.com/power/w/opp/2/online-power-profiler-for-bluetooth-le 

I can see it show a maximum 230kbps. 

From blogpost: https://novelbits.io/bluetooth-5-speed-maximum-throughput/ I can see he measure

Case 1 (PHY: 1 Mbps, ATT MTU = 23 bytes, DLE: enabled, Connection interval: 7.5 millisecs)

Data throughput reported by firmware:

Time: 36.11 seconds elapsed.
Throughput: 232.29 Kbits/s.
Sent 1048580 bytes of ATT payload.

Edit: I didn't really answer your questions directly, but I think the above blog post from novelbits explain what you should expect here and how it works.

Kenneth

[Pedro]

Hi Kenneth,

Thank you very much for the quick and detailed response. That definitely helps clarify things.

I’ve also come across another post on DevZone (link) which mentions the possibility of adjusting the following parameters to optimize throughput:

CONFIG_BT_BUF_ACL_TX_COUNT
CONFIG_BT_L2CAP_TX_BUF_COUNT
CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT

Any other config parameters I can tune for optimizing throughput?

Thanks again for your help!

Best regards,
Pedro

[Kenneth]

Check out the https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/samples/bluetooth/throughput/README.html example in specific. That one should be optimized for throughput, even if the peer may not support all the features.

Kenneth

[Pedro]

Thanks Kenneth!