Connection Event Length problem with coded phy

[YHT]

I am currently working on a project involving the Nordic nRF52840-DK development boards (1 Central and 11 Peripherals communication),  with LE PHY Coded S8. In this project, I have encountered challenges related to the connection interval and packet transmission, and I am seeking your guidance to resolve these issues.

 

1. Connection Event:
   • In some occurrences the observed packet duration is over 12 ms.
   • The current connection event is set to 10 ms. CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=10000
     Connection Interval is 60ms.
   • Based on calculations, if the packet duration is 12 ms and all eleven Peripherals are exchanging packets with the Central, the total duration would be 132 ms, which exceeds the interval for a single connection event.

In this regard, I request your assistance to clarify the following aspects: a. What factors could contribute to the observed packets duration exceeding the desired connection event? Which Zephyr configuration options should I modify to achieve optimal connection event length in this specific use case?

 

        2. Optimizing Packet Transmission:

• I have already reviewed the payload size and data rate in my code to optimize packet transmission efficiency.
• However, I would appreciate your guidance on the following aspects related to Zephyr and the Nordic nRF52840-DK boards: a. Are there any specific BLE parameters or Zephyr configuration options that can be adjusted to optimize packet transmission further? b. What are the recommended settings and values for these parameters to achieve efficient packet transmission in this context? 

To provide more context, here are the relevant details of my configuration and environment:

• Nordic nRF52840-DK development boards with LE PHY Coded S=8.
• Central Specific Config:
  • CONFIG_BT_MAX_CONN=12
  • CONFIG_BT_CTLR_SDC_MAX_CONN_EVENT_LEN_DEFAULT=10000
  • CONFIG_BT_L2CAP_TX_MTU=255
  • CONFIG_BT_BUF_ACL_TX_SIZE=83
  • CONFIG_BT_BUF_ACL_RX_SIZE=83
  • CONFIG_BT_CTLR_DATA_LENGTH_MAX=39
  • CONFIG_BT_CONN_TX_MAX=100

[Simonr]

Hi

Since you're communicating on the Coded PHY, all transmitted data takes ~8 times longer than "normal" BLE packets on the 1MBPS PHY, as sending the packets 8 times is how the extra range is eeked out with Coded PHY. This means that transmitting data will take a lot longer, and throughput will be a lot lower. You can't expect more than 125kbps (max) with Coded PHY. I would recommend checking out this blog post on NovelBits to see how Coded PHY can be set up optimally, and this one to maximize BLE throughput in general.

Best regards,

Simon

[grzegorz]

Hi Simonr I looked at provided blog post and I don't see any specific settings mentioned. The packet format is a little bit different and symbol rate is lower for Coded, but what else is changed in respect to 1M PHY? I ran Nordic throughput demo and got 64 kbps for Coded S2. This is much less than theoretical 500 kbps, even with protocol overhead. The speed for S8 was 40 kbps, which is 1/3 of theoretical 125 kbps. At the same time 1M gave 700 kbps, which is exptected. So why I get 70% of theoretical speed on 1M and 12% on Coded S2? Is this some SoftDevice limitation?

[Simonr]

Hi

This ticket is more than 2 years old at this point, so if you want a deeper dive into what is happening here I recommend you create a new ticket where you describe your issue in detail and share details on which SDK version you're working on. 

That being said, the data rates you are seeing sounds a lot lower than what's expected. At what range and in what kind of environment are you testing?

Best regards,

Simon

[grzegorz]

Hi

I just ran Nordic throughput demo on two NRF54L15 DK boards placed 10 cm apart, nRF Connect SDK 3.1.1.

[Simonr]

Understood. I see you have an open ticket with my colleague Amanda here:  Coded PHY throughput Please continue on in that ticket. In general I think tweaking the connection and throughput parameters should give you better throughput in the Coded PHYs as well.

Best regards,

Simon

[grzegorz]

Hi Simon

As you can see I can't get any meaningful answer from your colleague.

I suppose people at Nordic ran the throughput demo many times and information about expected throughput should be easily available. But maybe I'm wrong.