DLE goes to 27 when using PHY_2M

[plippo]

Hello,

We're trying to optimize the data transfer rate from our nRF52832 based peripheral device to the mobile phone. Tested with two different BLE >= 5 Android phones we encountered a weird behavior and would like to get your help to resolve it.

Our device uses SoftDevice s132 v6.1.1 and SDK 15.3 and in the beginning of the connection we set

MTU: 161 (RAM limited)
DLE: rx: 165 , tx: 165

The phone that I use (OnePlus 8) approves the MTU and requests DLE rx: 251, tx: 27 so the final negotiation results 165 (periph->central), 27 (central->periph). The phone is typically content using PHY_1M and this results the throughput (measured with Ellisys sniffer) of about 60kB/s which is pretty much what I would hope for it.

As soon as I change the connection to PHY_2M (either with nRF Connect debug mode on the phone or requesting it from the device software) the speed drops by about 50% resulting around 30-35 kB/s. The sniffer revealed the reason to be that the data length was dropped to 27 resulting a lot of very small packets. Initially I thought that the reason for this was the nrf_ble_gatt -module which I had enabled to take care of DLE and MTU settings since the RTT logs revealed some GATT module printouts and there was this really weird comment in the code ("The SoftDevice only supports symmetric RX/TX data length settings."), so I removed the GATT module and replaced the funtionality with direct SD calls.

However even after specifically setting DLE to (165,165) the connection defaults to 27 byte packets and really slow connection as soon as I set PHY_2M. This is really weird since the 1M PHY works great and I didn't think there was any extra limitations on DLE because of different PHYs. I did try to search for help in SoftDevice specification but did not find anything that sounded relevant...

Thank you in advance,

Petri L.
ps. I have the Ellisys logs available (the PHY_2M case with GATT module) but would like to keep them confidential if possible. 

 

[Hung Bui]

Hi Petri, 
The size of the TX buffer of the softdevice is automatically determined by the configuration of NRF_SDH_BLE_GAP_EVENT_LENGTH  and the supported PHYs. 

In theory the softdevice is capable of transmitting data in the full event length configured. I would strongly suggest to try to test with the throughput example we have in the SDK where we can achieve 1.3Mbps with 2Mbps PHY. 

Note that it's not always correct that the smaller the interval the higher the throughput you will have. For larger packet size there will be a sweet spot that you can fit the most of the packets inside the connection event without any "idle" period. 

I'm not very certain about this "the SD has already "gotten tired of waiting" . As far as know, the softdevice is capable of refilling the buffer on the go when it's transmitting its buffer. So if there is available buffer it will accept the queue. 

Note that the HVN_TX_COMPLETE only comes after the connection event is finished. So you may have to think about queueing the packet even before the event. 
But it's still strange to me that the buffer is not big enough to cover the transmitting of the whole registered event length. There could be a chance that it's only calculated for 1Mbps PHY not 2Mbps PHY. And that's why you would need to refill the buffer even before the HVN_TX_COMPLETE event. 

[plippo]

Hung Bui said:

The size of the TX buffer of the softdevice is automatically determined by the configuration of NRF_SDH_BLE_GAP_EVENT_LENGTH  and the supported PHYs. 

Yes, I saw that in the documentation but in practise I've never gotten more than 4 packets (of DLE=165) before getting NRF_ERROR_RESOURCES no matter how much I give SD memory or attribute space.

Hung Bui said:

Note that the HVN_TX_COMPLETE only comes after the connection event is finished. So you may have to think about queueing the packet even before the event. 

How is this compatible with the sample code you sent? In that code the new packet is sent in the HVN_TX_COMPLETE -handler so by definition it would not make it to the same connection event.