nRF52840 - DLE update issue.

RE: nRF52840 - DLE update issue.

Einar Thorsrud — Thu, 27 Jan 2022 14:32:41 GMT

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

RE: nRF52840 - DLE update issue.

Srinivasan C — Wed, 26 Jan 2022 16:28:54 GMT

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.

RE: nRF52840 - DLE update issue.

Einar Thorsrud — Wed, 26 Jan 2022 14:37:19 GMT

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.

RE: nRF52840 - DLE update issue.

Srinivasan C — Tue, 25 Jan 2022 13:32:41 GMT

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

RE: nRF52840 - DLE update issue.

Einar Thorsrud — Tue, 25 Jan 2022 12:57:52 GMT

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

[quote user="AKV"]1. Why is that packet loss happening when we increase the MTU with given EL?[/quote]

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.

[quote user="AKV"]2. What is the maximum MTU we can set with the Even length 3.75ms and 5ms without any packet loss?[/quote]

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.

[quote user="AKV"]3. Why is it dependent on the number of connections (Each node has its own EL time anyway)?[/quote]

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

RE: nRF52840 - DLE update issue.

AKV — Tue, 25 Jan 2022 11:58:04 GMT

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

RE: nRF52840 - DLE update issue.

Einar Thorsrud — Mon, 04 Oct 2021 07:46:27 GMT

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.

RE: nRF52840 - DLE update issue.

Srinivasan C — Fri, 01 Oct 2021 15:01:54 GMT

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

RE: nRF52840 - DLE update issue.

Einar Thorsrud — Fri, 01 Oct 2021 11:43:52 GMT

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.

RE: nRF52840 - DLE update issue.

Srinivasan C — Thu, 30 Sep 2021 12:42:23 GMT

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 ?

RE: nRF52840 - DLE update issue.

Einar Thorsrud — Wed, 29 Sep 2021 15:32:07 GMT

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.