Connection Interval and Througput

RE: Connection Interval and Througput

ovrebekk — Fri, 23 Oct 2020 13:26:39 GMT

[quote user="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 ? [/quote]

The GAP event length is the maximum time the stack can spend sending and receiving packets in one connection event, yes.

The connection interval is the time between the start of each connection event.

[quote user="wrani"]Do I need to change "GAP event length " in the central \ Peripheral \ Both ? [/quote]

You need to change this on both sides, yes. If one device has a lower GAP event length than the other, then the lower value will set the maximum GAP event length for that connection.

[quote user="wrani"]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 ? [/quote]

I don't know if there is a precise relationship between the GAP event length and memory consumption, since this is affected by many factors. The critical point is that you keep logging enabled when changing these parameters, so that you get a warning message in the log if you don't have enough RAM set aside for the SoftDevice.

Best regards
Torbjørn

RE: Connection Interval and Througput

wrani — Thu, 22 Oct 2020 05:51:06 GMT

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 ?

RE: Connection Interval and Througput

ovrebekk — Wed, 21 Oct 2020 09:29:52 GMT

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

RE: Connection Interval and Througput

wrani — Tue, 20 Oct 2020 18:09:52 GMT

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 ?

RE: Connection Interval and Througput

ovrebekk — Tue, 20 Oct 2020 12:59:00 GMT

[quote user="wrani"]1.I am using NUS service, so each call to "ble_nus_data_send" ( which calls sd_ble_gatts_hvx ) equals a "packet" ? [/quote]

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).

[quote user="wrani"]

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 ?

[/quote]

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.

[quote user="wrani"]

RE: Connection Interval and Througput

wrani — Fri, 16 Oct 2020 11:53:58 GMT

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

RE: Connection Interval and Througput

Dmitry — Fri, 16 Oct 2020 08:03:57 GMT

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.

RE: Connection Interval and Througput

wrani — Fri, 16 Oct 2020 05:28:06 GMT

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

RE: Connection Interval and Througput

Dmitry — Thu, 15 Oct 2020 18:18:57 GMT

[quote userid="93120" url="~/f/nordic-q-a/67249/connection-interval-and-througput/275186#275186"]why sould I disable latency in that scenarion ?[/quote]

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

RE: Connection Interval and Througput

wrani — Thu, 15 Oct 2020 17:43:42 GMT

- 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 ?

RE: Connection Interval and Througput

Dmitry — Thu, 15 Oct 2020 17:32:51 GMT

[quote userid="93120" url="~/f/nordic-q-a/67249/connection-interval-and-througput/275181#275181"]

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 ?

[/quote]

Yes.

[quote userid="93120" url="~/f/nordic-q-a/67249/connection-interval-and-througput/275181#275181"]

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

(for few seconds and then lower back )

[/quote]

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.

RE: Connection Interval and Througput

wrani — Thu, 15 Oct 2020 17:02:34 GMT

I see.

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

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 ?

RE: Connection Interval and Througput

Dmitry — Thu, 15 Oct 2020 15:14:23 GMT

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.