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.