DLE Update in nRF5340 by using nRF Connect SDK

RE: DLE Update in nRF5340 by using nRF Connect SDK

Einar Thorsrud — Mon, 08 Jan 2024 09:41:13 GMT

Hi,

[quote user="AKV"]We've observed that setting a large Data Length Extension (DLE) and sending shorter packets leads to extended radio time, consequently diminishing the overall range.[/quote]

Do you have a sniffer trace with and without it? It would be interesting to see the actual difference. In what way does the packet get larger. Is it for instance that you have long GATT writes and want these to be fragmented on the GAP layer, and that does not happen?

[quote user="AKV"]We are using write without response. And each transmission is sent as a separate packet.[/quote]

If you are sending data from a GATT server to a client, I would consider using notifications (write wihtout response is normally used the other way). But the key is to ensure you send less in each transaction if the reason you are seeing a change is that you get your desierrable shorter packets due to fragmentation (but this is just an assumption for now).

[quote user="AKV"]Is there any benefit if we use notification to send the packets?[/quote]

For transfering data from a client to a server that is the simplest and most common way way to trensfer large amounts of data or data when a specific event happens or simpilar and it can give you higher throughput, but that may not be not relevant in this case.

RE: DLE Update in nRF5340 by using nRF Connect SDK

AKV — Mon, 08 Jan 2024 05:06:48 GMT

HI,

We've observed that setting a large Data Length Extension (DLE) and sending shorter packets leads to extended radio time, consequently diminishing the overall range. Therefore, we are working to minimize the DLE time for shorter packets.

We are using write without response. And each transmission is sent as a separate packet.

int bt_gatt_write_without_response_cb(struct bt_conn *conn, uint16_t handle,

const void *data, uint16_t length, bool sign,

bt_gatt_complete_func_t func,

void *user_data);

Is there any benefit if we use notification to send the packets?

RE: DLE Update in nRF5340 by using nRF Connect SDK

Einar Thorsrud — Fri, 05 Jan 2024 11:15:16 GMT

Hi,

You are right that there is a higher probability for packet loss the longer the packet is. But there is no obligation to send long packets just because it is allowed on the link. I assume you send the data as notifications? And each notification is sent as a separate packet (and sometimes fragmented into several), so if you send shorter notifications, you will have shorter packets. Is that something you have considered?

RE: DLE Update in nRF5340 by using nRF Connect SDK

AKV — Fri, 05 Jan 2024 09:22:02 GMT

Hi,

Thanks for the response.

Our application aims to facilitate music streaming over a mesh network with voice capabilities.

In our mesh configuration, each device can connect with up to three other devices.

We've noticed that configuring a large Data Length Extension (DLE) results in increased radio time, subsequently reducing the overall range.

As a result, our objective is to transmit large data packets for combined music and voice transmission, while receiving fewer bytes exclusively for voice.

For a clearer understanding, I have included application diagrams below.

/resized-image/__size/640x480/__key/communityserver-discussions-components-files/4/RideGrid_5F00_Dev_5F00_V2_2D00_Page_2D00_7.drawio.png

/resized-image/__size/640x480/__key/communityserver-discussions-components-files/4/RideGrid_5F00_Dev_5F00_V2_2D00_Page_2D00_8.drawio.png

RE: DLE Update in nRF5340 by using nRF Connect SDK

Einar Thorsrud — Wed, 03 Jan 2024 13:17:29 GMT

Hi,

That is not supported. The event lengths are independent of direction, and is also negotiated between the peers.

May I ask why you want to do this? What is the higher level goal you want to achieve?