• State Not Answered
  • Replies 4 replies
  • Subscribers 25 subscribers
  • Views 277 views
  • Users 0 members are here
Attachments (3) Download All
Nordic Case Info
  • Case ID: 285579
Options
nRF5 SDK is not maintained anymore
More Info: Consider nRF Connect SDK for new designs

L2CAP fragmentation with a data length of 251 bytes

user114027

Hello all,

Background:
-NRF5340
-NRF SDK 1.9
-Zephyr 2.7.99

My objective is to send a data of 768 bytes by BLE.

I use 4 notify to send this 768 bytes data (192 packets)
I configured the bt ctlr with a data length of 251 byte. The peripheral is my board and the central is the PC.
I receive in two different ways:
- a web interface
- the nordic BLE application with the 52840 dongle

However, I observe an unexpected behavior with the web interface:
-the data length is 251 bytes after checking with the sniffer.
-the mtu is 247 bytes
-with the web interface the max tx time is 328 us while with the dongle 2,1 ms
-Connection interval 7,5 ms


With the web interface when sending a notify, the packet is fragmented into 27 bytes packet despite the fact that the data length is 251 bytes which I do not understand.
With the dongle I don't have this fragmentation.
 The only difference is the max tx time. Is this parameter the cause of the fragmentation which induces a decrease in throughput? How is it possible to improve the throughput?


Thank you.

Parents
  • 0

    Hi, 

    Sorry for the late reply. 

    The problem here is that the client PC has Max Rx time set to 328 microseconds which don't allow our nRF5340 to transmit the 251 bytes in one packet. The suitable time for 251 bytes packet would be 2120us. Our device set such value for the Rx and Tx max time in a response to LL_LENGTH_REQ. But in request from the PC, our device gets that PC max Rx time is 328 microsecond even if max Rx octets size is 251 bytes. For 1MB PHY the 328 microsecond allows our SoC to set packets not longer than 27 bytes because we cannot transmit packets that transmission time would be greater than PC Rx max time. But in a reverse direction from PC to our SoC, it should be possible to send a packet of 251bytes.  I hope that this clarifies your issue.

    To improve the throughput the client PC needs to request the data length update with Rx time set to 2120us (for 1M PHY). This is only possible when the client PC BLE controller supports such Rx max time. The other solution can be switching to use 2M PHY it will increase throughput in all cases even with the dongle which can handle a packet of 251 bytes. In your case if increasing Rx max time on the PC side is not possible then you can try to use 2M PHY, it gives you faster data transmission in the air and you will send about two times more data in one packet.

    -Amanda

Reply
  • 0

    Hi, 

    Sorry for the late reply. 

    The problem here is that the client PC has Max Rx time set to 328 microseconds which don't allow our nRF5340 to transmit the 251 bytes in one packet. The suitable time for 251 bytes packet would be 2120us. Our device set such value for the Rx and Tx max time in a response to LL_LENGTH_REQ. But in request from the PC, our device gets that PC max Rx time is 328 microsecond even if max Rx octets size is 251 bytes. For 1MB PHY the 328 microsecond allows our SoC to set packets not longer than 27 bytes because we cannot transmit packets that transmission time would be greater than PC Rx max time. But in a reverse direction from PC to our SoC, it should be possible to send a packet of 251bytes.  I hope that this clarifies your issue.

    To improve the throughput the client PC needs to request the data length update with Rx time set to 2120us (for 1M PHY). This is only possible when the client PC BLE controller supports such Rx max time. The other solution can be switching to use 2M PHY it will increase throughput in all cases even with the dongle which can handle a packet of 251 bytes. In your case if increasing Rx max time on the PC side is not possible then you can try to use 2M PHY, it gives you faster data transmission in the air and you will send about two times more data in one packet.

    -Amanda

Children
No Data
Related
Terms of service