Connection Interval and Througput

[wrani]

Hi, 

I am a bit confused about the effect the Connection Interval has on BLE throughput. 

SoftDevice documentation :

https://infocenter.nordicsemi.com/index.jsp?topic=%2Fsds_s140%2FSDS%2Fs1xx%2Fmultilink_scheduling%2Fextend_connection_event.html

Claims that higher connection interval increases throughput 

Other have claimed just the opposite 

https://punchthrough.com/maximizing-ble-throughput-on-ios-and-android/

which claims 
" BLE throughput requires context for it to be meaningful and the context starts by determining the connection interval (the smaller generally gets you faster throughput, though there are some interesting exceptions)" 

my logic is the if device communicate more oftern ( lower connection interval ) we achieve higher throughput. 

So - what is it  ? 

Thanks, 

Ran 

[Dmitry]

Hi Ran,

There isn't any contradiction here. With enabled event length extension, SoftDevice can fit as many packets into one event as connection interval permits. The space between consecutive packets within a connection event is 150 usec that is in any case shorter than between connection events - so the longer connection interval, the less time is wasted. To take any gain from this feature, event length extension has to be supported by both sides.
Android and iOS don't allow long connection events, they have some hardcoded number of packets per connection interval - as second document claims, it's 4 for iOS and 6 for Android (though there may be different values for different phones and OS versions). In this case, shorter connection interval gives more connection events per second -> better throughput.

[wrani]

I see.

So when testing throughput between 2 NRF52840-DK, Conn. Interval = 200 will give a better throughput then conn. Interval =30 .

When testing throughput between 1 NRF42840-DK and Android , Conn. Interval = 30 give a better throughput then Conn. Interval = 200, this is due to the limited number of packet each connection event can exchange.

Did I get this right ?  

If so  - I have a NRF52840 sampling device which connect to an Android phone. 

Occasionally, I need to send a 2K of data ( containing sampling data ) . 

My flow is to use Interval=300 in Idle ( to reduce power consumption ) 

When sending 2K ( 20 chinks of 100 bytes )  , I asking the master to update Connection Interval =75 .

(for few seconds and then lower back ) 

Does that sounds right ? 

[Dmitry]

wrani said:

So when testing throughput between 2 NRF52840-DK, Conn. Interval = 200 will give a better throughput then conn. Interval =30 .

When testing throughput between 1 NRF42840-DK and Android , Conn. Interval = 30 give a better throughput then Conn. Interval = 200, this is due to the limited number of packet each connection event can exchange.

Did I get this right ?  

Yes.

wrani said:

When sending 2K ( 20 chinks of 100 bytes )  , I asking the master to update Connection Interval =75 .

(for few seconds and then lower back ) 

The problem is that host can reject your request, and you need to handle this case somehow. An alternative way is to set a large latency value when connecting, and then temporary disable latency when you need to transfer sampling data.

[wrani]

- The problem is that host can reject your request

Today, In this case, I add a "sleep" between data chunks. 

( waiting for UPDATE_CONN_PARAM event before sending the chunks ) 

- Alternative way is to set a large latency value

But my understanding of "slave latency" - if i don't have any data to send, peripheral can choose to skip connection events and stay asleep. But when sending sample, I do have data. why sould I disable latency in that scenarion ? 

[Dmitry]

wrani said:

why sould I disable latency in that scenarion ?

You're right, if data are sent just as a bunch of notifications (without any interaction or acknowledgement), it may not be needed. 

[wrani]

Also - what about switching to 2Mb PHY ? I know not all phone supports this , but I can send a request and check if it was granted . right ? 

Ran

[Dmitry]

Yes, you can enable 2M PHY, and also increase MTU and maximum packet length (both NRF_SDH_BLE_GAP_DATA_LENGTH and NRF_SDH_BLE_GATT_MAX_MTU_SIZE) - in combination with shortest connection interval, you should get a throughput close to phone's limit.

[wrani]

Thanks, another questions :

1.I am using NUS service, so each call to "ble_nus_data_send" ( which calls sd_ble_gatts_hvx ) equals a "packet" ? 

2.if maximum data buffer I'm sending over NUS is ~160 Bytes, is it still better to set NRF_SDH_BLE_GATT_MAX_MTU_SIZE=247 and  NRF_SDH_BLE_GAP_DATA_LENGTH =251 ? 

3.Having done all the suggested above, how do I handle NRF_ERROR_RESOURCE if and when calling sd_ble_gatts_hvx ? wait for HVN_TX_COMPLETE_EVENTS as suggested in other posts ? 

4. Is there any reason to change HVN Q size ? I remember reading it will be automatically calculate based on connection params ? 

Thanks Again - Much appreciated 

[ovrebekk]

Hi 

wrani said:

1.I am using NUS service, so each call to "ble_nus_data_send" ( which calls sd_ble_gatts_hvx ) equals a "packet" ? 

Each call to ble_nus_data_send constitutes one attribute (host) packet, but the link layer might split this packet into multiple on air packets if the data length is not large enough to send the entire packet in one go. 

Assuming the data length is larger than your NUS packet + 7 bytes it will be sent in one packet over the air (the 7 bytes is used for the L2CAP and attribute headers). 

wrani said:

2.if maximum data buffer I'm sending over NUS is ~160 Bytes, is it still better to set NRF_SDH_BLE_GATT_MAX_MTU_SIZE=247 and  NRF_SDH_BLE_GAP_DATA_LENGTH =251 ? 

In general there is no drawback having a GATT MTU and data length larger than what you need, but it does increase the RAM consumption of the SoftDevice a bit, so if you are running out of RAM you might consider optimizing this. 

A GATT MTU of 163 and a data length of 167 is the minimum needed to support 160 bytes of user data in a single on air packet. 

Regarding question 3, it is correct that waiting for the HVN_TX_COMPLETE_EVENT is the correct way to handle the NRF_ERROR_RESOURCE error. Then you ensure that the SoftDevice buffers are full at all times, which ensures optimal data transfer. 

wrani said:

other posts ? 

4. Is there any reason to change HVN Q size ? I remember reading it will be automatically calculate based on connection params ? 

In order to maximize data throughput you can increase the SoftDevice buffers through the NRF_SDH_BLE_GAP_DATA_LENGTH parameter in sdk_config.h

This parameters determines how long you can keep transmitting packets back to back in a single connection event. 

Best regards
Torbjørn

[wrani]

Thanks. 

Does any of what we've discussed changes if I am running a multilink setup ? 

for ex , aggregator for 15 devices, all NRF's .

What special attention\calculation in need to consider in such case ? 

[ovrebekk]

Hi 

In a multilink scenario you essentially need to divide the available RF time between all the running links. 

In this case I would probably use a longer connection interval, to ensure that each connection gets a longer connection event before the central has to switch to the next link. 

On the peripheral side there isn't much you can do in this case, it is mainly up to the central to decide the most efficient connection parameters for multiple links. 

You could try a connection interval of around 400ms for instance, and use a long GAP event length to maximize throughput. 

Best regards
Torbjørn

[wrani]

so , the ""GAP event length" is the actual time the radio is on, and conn. interval is the interval in which  "GAP event length " correct ? 

Do I need to change "GAP event length " in the central \ Peripheral \ Both ? 

Currently - this are set to 50 in both Master and Peripheral, because I was unsure where to set them. Also - what is the effect "gap length" have on softdevice memory ?