Connection Event Length problem with coded phy

RE: Connection Event Length problem with coded phy

Simonr — Thu, 15 Jan 2026 13:27:04 GMT

Thank you for your thorough feedback/conclusion Grzegorz. I'll take this up internally to see if we can make this clearer in our documentation somewhere.

Best regards,

Simon

RE: Connection Event Length problem with coded phy

grzegorz — Wed, 14 Jan 2026 11:38:50 GMT

Thank you very much for testing and analysis.

I knew about repetition, but it wasn't whole answer. Yes, the problem is in big part of connection event being idle. However I don't know how 17.6 ms was calculated. In my opinion it should be 2.3 ms for a packet, 0.6 ms for ACK and 2x0.3ms for inter frame space. My calculator app is here. Anyway most important thing seems to be Link Layer PDU limited by Nordic to 27 bytes. This makes it not possible to use connection event more efficiently. I know it is done intentionally and it's not a bug. It was just hard to find. For un-Coded PHY there is no such limitation and much better efficiency can be achieved.

The efficiency for S=2 is worse than for S=8 becaue header is repeated 8 times just like for S=2. This way S=2 is not 4 times faster than S=2 mode.

RE: Connection Event Length problem with coded phy

Simonr — Thu, 18 Dec 2025 13:58:29 GMT

I have tested and confirmed this behavior (777kbps ~77% on 1Mbps and 55kbps ~44% on Conded PHY) on the throughput sample yesterday, and it took discussing the results I saw with a colleague to realize why the Coded PHY performs noticably "worse" than the 1Mbps PHY.

It's rooted in how Coded PHY is built up. Essentially, every packet of data is sent 8 times, with all header and preamble data also being transmitted 8 times, which affects the total throughput. The throughput was never the goal with Coded PHY and it is made for range and stability over throughput performance.

The math including all overhead etc. would be something like:

1 M PHY after headers: 1 920 bits / 2.468 ms = 0.777 Mb/s (~78 % efficiency).
S=8 PHY after headers: 1 920 bits / 17.644 ms = 108.8 kb/s (~87 % efficiency). But each coded packet already occupies 17.6 ms on air; with typical connection intervals (e.g. 30 ms) you can only fit one coded packet per event, so the rest of the interval is idle. That reduces user throughput to 1 920 bits / 30 ms = 64 kb/s (~51 % efficiency).

Best regards,

Simon

RE: Connection Event Length problem with coded phy

Simonr — Mon, 15 Dec 2025 18:32:01 GMT

Hi again

I'm sorry about the delay on this ticket. I have not been able to take a proper look into this yet. I'll try to set up this test on my end this week and see if I can reproduce it. The main difference between the 1Mbps PHY and Coded PHY is that you're restricted to the 27 byte MTU packets instead of 247 MTU.

The throughput tests has been tested on our side and we've seen similar throughput to what the Novelbits blog post reports, but I'll try it on my end to make sure that's still the case on NCS 3.1.1.

Best regards,

Simon

RE: Connection Event Length problem with coded phy

grzegorz — Tue, 09 Dec 2025 14:07:37 GMT

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.

RE: Connection Event Length problem with coded phy

Simonr — Mon, 08 Dec 2025 08:22:48 GMT

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

RE: Connection Event Length problem with coded phy

grzegorz — Thu, 04 Dec 2025 11:08:45 GMT

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

RE: Connection Event Length problem with coded phy

Simonr — Thu, 04 Dec 2025 08:30:56 GMT

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

RE: Connection Event Length problem with coded phy

grzegorz — Wed, 03 Dec 2025 12:24:39 GMT

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?

RE: Connection Event Length problem with coded phy

Simonr — Fri, 16 Jun 2023 09:31:07 GMT

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