nRF52840 - DLE update issue.

[AKV]

Hi,

We are facing some issues with the DLE update.

The given table shows that the softdevice set data length and time.

Event Length (ms)	ATT MTU (bytes)	Data Length (bytes)	Tx and Rx Time (us)
2.5	60	64	737
2.5	70	74	737
2.5	80	78	737
2.5	90	78	737
3.75	100	104	1362
3.75	120	124	1362
3.75	140	144	1362
3.75	160	156	1362
3.75	170	156	1362

Parameters being set are,

Connection interval = 15ms.

Scan window = 6.25ms.

Advertising interval = 152.5ms

Peripheral Role Count = 1

Central Role Count = 2

1. Why is the softdevice is set constant time for event length (737us for 2.5 event length and 1362us for 3.75ms)?

If the MTU is 170 bytes then the Tx time = 170+18 (LL header) = 188 *8 =1504us.

and then we can add IFS as well so the total time is 1504+150= 1654us. 

Total ttime for both Tx and Rx = 1654 * 2 =3308us.

We have getting the NRF_ERROR_RESOURCES when trying to set the DLE (174/1654) manually by calling the function sd_ble_gap_data_length_update(connHandle, &ble_gap_data_length_params, nullptr).

2. The DLE requested time is less than the event length (3.75ms) then why it's giving the error?

[Einar Thorsrud]

Hi,

The SoftDevice will need to fit all connections and scanning, see Connection timing with Connection Event Length Extension.

By the way, do you use the SoftDevice handler module in the SDK? If so it calls sd_ble_cfg_set() with the event length from NRF_SDH_BLE_GAP_EVENT_LENGTH in sdk_config.h.

[Srinivasan C]

Hi Einar, thanks for the links .

Still have a question on the relation between the Event Length  and the Tx / Rx Timing.  If we have an Event length of 2.5ms

the Tx and Rx lengths can be 1.1ms each  ( removign the 150uS CIFS ).  This should have corresponded to about 137 bytes.

But we are seeing about 78 bytes only.    This seems to suggest a time about 750usec being used up for other activities ( this seems to fit when we tried with 3.75ms Event length ).  Where does this extra 750us come from ? Is this the radio prepare time ?

[Einar Thorsrud]

Hi,

This is expected. Before the connection event starts, the SoftDevice reserves 183 us for configuring the radio. After the the last packet has been received, it  reserve 350 us for post processing. In addition comes 200 us for scheduling. This adds up to the numbers you have seen. Also note that the SoftDevice will not start a new packet pair if there is not enough available time.

[Srinivasan C]

Thanks for the clarification. Will the situation be any different if we switch to nRF Connect ?

[Einar Thorsrud]

The numbers are currently a bit smaller with nRF Connect SDK. These numbers are caused by implementation details though, and can change at any time with new releases so you should not rely on this.

[AKV]

Hi Einar,

We are developing a mesh network. Our requirement is the one device can connect to three other devices. Using one connection as a peripheral and up to two connections as a central for mesh connections.

So we have to check what is the maximum MTU we can set with given Event length.

The maximum possible MTU is 152 bytes with the connection Event length 3.75ms when the DLE set by Softdevice (DLE result 156/1362,  The DLE setting table have already attached above). 

We have observed that when we increase the MTU the packet loss happening (Application packet size is MTU-3 and sending the packet in every 30ms).

The below table you can see that packet loss is happening when we increase the MTU and total mesh connections.

Mesh Size	Event Length (ms)	Connection Interval (mS)	Scan Window (mS)	ATT MTU (bytes)	Tx and Rx Time (us)	Packet Loss
2	3.75	15	3.125	126	1362	NO
2	3.75	15	3.125	130	1362	NO
2	3.75	15	3.125	152	1362	YES
3	3.75	15	3.125	126	1362	NO
3	3.75	15	3.125	130	1362	NO
3	3.75	15	3.125	152	1362	YES
4	3.75	15	3.125	126	1362	NO
4	3.75	15	3.125	130	1362	YES
4	3.75	15	3.125	152	1362	YES
2	5	20	3.125	180	1987	NO
2	5	20	3.125	200	1987	NO
2	5	20	3.125	220	1987	YES
3	5	20	3.125	180	1987	NO
3	5	20	3.125	200	1987	NO
3	5	20	3.125	220	1987	YES
4	5	20	3.125	180	1987	NO
4	5	20	3.125	200	1987	YES
4	5	20	3.125	220	1987	YES

1. Why is that packet loss happening when we increase the MTU with given EL?

2. What is the maximum MTU we can set with the Even length 3.75ms and 5ms without any packet loss?

3. Why is it dependent on the number of connections (Each node has its own EL time anyway)?

[Einar Thorsrud]

Hi,

I assume when you write packet loss here it is not that the packets are lost on air, but that they cannot be sent within the event as there is no time, and so the scheduler will not do it and you will have to wait for the next event? (if so, you could see this as a increased latency for instance, but not as packet loss).

AKV said:

1. Why is that packet loss happening when we increase the MTU with given EL?

With longer packets (higher MTU), the packet takes more time on air, so you will eventually not be able to fit the same amount of packets in the same event if the event length is not increased accordingly.

AKV said:

2. What is the maximum MTU we can set with the Even length 3.75ms and 5ms without any packet loss?

You need to fit everything within this time limit, including overhead described in this earlier post in this thread, which can change with different stack versions. If you need to squeeze in as much as possible in short event lengths then I suggest you do this by experimentation. You should probably leave 1 byte for margin, and remember that if you do it this tight, you may need to adjust this with future SDK updates.

AKV said:

3. Why is it dependent on the number of connections (Each node has its own EL time anyway)?

For the central this should not be a problem as long as you have time to fitt all the connections with the specified event length and also have time for scanning. Is the mesh size row what describes the number of connections? If so, then with higher numbers you will not have time for it all (e.g. if I am reading this correctly then you have for instance 4 times 5 ms event lengths in 20 ms connection interval, which should also include 3.125 scan  window  - assuming you do scanning also here).