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

[Srinivasan C]

Hi, 

 Thanks for the quick response.  Still the issue is not clear though.  We have choosen 20ms as the Connection Interval with  EL of 5ms and Scan interval of 3.75ms.  We let any node connect to 3 other nodes at the max  ( 1 as a slave and 2 as a master ).  So the CI interval is enough for this ( 3 * 5 + 3.75 = 18.75ms )

Now, for a choosen MTU, Say 200,  we see that when a node is connected to 2 other nodes ( mesh size is 3), there is no loss of packets,  but when the node is connected to 3 others ( mesh size ids 4 ) , then we see loss of packets ( loss of packet means that the packet was not xmitted ).

This shouldnt happen as there is sufficient time in each EL / CI for each of the connection to send out the set MTU length. 

Obviously we are missing / not understanding some subtle point. Any help in this will be helpful

[Einar Thorsrud]

I am also not getting this to add up. Can you explain more details about your configuration and use case? While having 3 current connections, do you still scan or try to establish another connection? Or do you write to flash, or do anything else that affects SoftDevice scheduling (see scheduling priorities table)? Please elaborate.

[Srinivasan C]

So when 3 connections are established, we disable Scan and advertising both ( the adv is disabled when we connect as a slave to another device and Scan is disabled after 2 connections as Master is made ).   We do not write to the Flash at all.

when only 1 or no connections have been made as a master, the scan is still active. 

As the number of connections increase ( to a max of 3 ), the MTU that work without packet drop decreases.  This is what we are trying to understand.

[Einar Thorsrud]

I see. I am not able to make this add up. Can you share sniffer traces and the relevant parts of the firmware (show configurations like NRF_SDH_BLE_GAP_EVENT_LENGTH and NRF_SDH_BLE_GATT_MAX_MTU_SIZE and any code you have for doing data length updates etc)?