BLE Data Length Extension doesn't work well #42779
Replies: 5 comments 3 replies
-
https://github.com/nrfconnect/sdk-nrf/tree/main/samples/bluetooth/throughput |
Beta Was this translation helpful? Give feedback.
-
@cvinayak can you please comment on this thread? |
Beta Was this translation helpful? Give feedback.
-
@LingaoM Please check whether have the below in your prj.conf, if not, then only the default 27 byte PDUs will be used by the Controller.
|
Beta Was this translation helpful? Give feedback.
-
I'm facing similar issue with nrf sdk 2.0.2, nrf5340 DK and this particular example. |
Beta Was this translation helpful? Give feedback.
-
Please check if your hci_rpmsg sample has the above mentioned Kconfig values. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Describe the bug
I used nRF52840dk as a peripheral which run ./example/bluetooth/peripheral_ots example, and my iOS device as central. I also used nRF Sniffer as packet tracer.
I found that nRF52840dk did a LL_LENGTH_REQ after the connection established, but max tx octets and max rx octets are 27. I think the correct value should be 251 because nRF52840dk as a Bluetooth controller support Data Length Extension.
Please also mention any information which could help others to understand
the problem you're facing:
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The max tx octet and max rx octet of LL_LENGTH of nRF52840dk are 251
Impact
This impacts the performance of throughput of Zephyr BLE application.
Logs and console output
DLE works abnormal.pcapng.zip
Beta Was this translation helpful? Give feedback.
All reactions