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,

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