UART example data packet size

[axel_s]

Hallo,

currently I want to test a connection between an nRF52840-DK and a Smartphone. For that, I used the Nordic UART Bridge Service (NUS) sample to start with.

When testing the data packet size, I found that I can transmit only 20 Bytes without error. In case of e.g. 21 data bytes, There is an error:

W: No ATT channel for MTU 24
W: No buffer available to send notification

From  UART BLE Example - Data size limit I learned that maybe I have to look at ATT_MTU Throughput Example, but hopping from example to example can't be a good solution.

I wonder why I have to modify a lot of things to have more than 20 bytes of data. Within bt_nus_send(..), there is a length parameter, which is uint16_t. This definition alone leads to the assumption that at least more than 255 bytes should be possible. Also the fact that it is a UART example means in my mind that it should be possible to transfer larger data packets.

That's why I want to know what parameters I have to change to transmit (and receive) packets of maybe 1000 byte by means of the UART example.

As a general hint: Please design examples with max. values for whatever parameters, not for minimal or totally random values.

Kind regards

Axel

[Karl Ylvisaker]

Hello Axel,

Could you specify which SDK you are working with - nRF5 SDK or nRF Connect SDK?

In general it is the Central device (phone, in this case) that determines the connection parameters that will be used for the connection.
A peripheral may only request to have these parameters updates to its preferred values, but the central has the last say and can ultimately just reject these requests.
The peripheral then only have the choice to either accept the parameters that the central is using, or to terminate the connection.

When testing the data packet size, I found that I can transmit only 20 Bytes without error. In case of e.g. 21 data bytes, There is an error:

W: No ATT channel for MTU 24
W: No buffer available to send notification

You could also modify the Nordic UART service to expect larger transfers.

This definition alone leads to the assumption that at least more than 255 bytes should be possible. Also the fact that it is a UART example means in my mind that it should be possible to transfer larger data packets.

The maximum total packet length in BLE is 255 bytes, and you also loose a couple of bytes to overhead, and so your max MTU size is 247 bytes.
You might also benefit from seeing the SoftDevice Throughput documentation for more information about how the chosen parameters affects your throughput.
If you do queue more than the MTU size for transfer the transfer will be split into multiple packets, and reassembled on the receiving side once the last fragment is received.

Best regards,
Karl

[axel_s]

Hallo Karl,

thanks for the info, I'll do some more tests. I currently use Zephyr 2.7.99 and ncs 1.9.1.

"The maximum total packet length in BLE is 255 bytes, and you also loose a couple of bytes to overhead, and so your max MTU size is 247 bytes." That's true for single packets. But in case of a service I want to hand over a larger packet to the service, expecting that larger packet delivered automatically to the receiver, which should hand it back also as one large packet. As I wrote, the bt_nus_send(..) contains a uint16_t length parameter, indicating that my intention is possible.

And in general I won't modify any service nor create a new one. I simply want to transfer a number of bytes from A to B or vice versa. I can't understand why this most primitive issue isn't existing as a kind of basic service as well as in a basic example (Yes, there is no maximum for "larger packets". But an example for e.g. 1000 Byte combined with the statement "length limit according to available memory" would be nice.). Everything else is more specialised. But in the end, only a simple solution is a good one.

Kind regards

Axel

[Karl Ylvisaker]

Hello again, Axel

axel_s said:

currently use Zephyr 2.7.99 and ncs 1.9.1.

Thank you for your patience with this, and thank for you clarifying.

axel_s said:

That's true for single packets. But in case of a service I want to hand over a larger packet to the service, expecting that larger packet delivered automatically to the receiver, which should hand it back also as one large packet. As I wrote, the bt_nus_send(..) contains a uint16_t length parameter, indicating that my intention is possible.

Yes, you can indeed queue more than the packet limit for sending, in which case the SoftDevice Controller will divide the data into packets that conform to the limit before sending. How much data you can allocate at any one time depends on your configuration of the buffer that the service is using.

axel_s said:

And in general I won't modify any service nor create a new one. I simply want to transfer a number of bytes from A to B or vice versa. I can't understand why this most primitive issue isn't existing as a kind of basic service as well as in a basic example (Yes, there is no maximum for "larger packets". But an example for e.g. 1000 Byte combined with the statement "length limit according to available memory" would be nice.). Everything else is more specialised. But in the end, only a simple solution is a good one.

It is hard to make a simple example that works ideally for every use-case, without having to make any modifications or change any configurations.
Please see this answer by my colleague Amanda regarding how you could increase the MTU size to the maximum allowable size.

Are you encountering any specific issues when you are making these modifications?
If so, please elaborate, so that we may help you resolve them.

Best regards,
Karl

[axel_s]

Hallo Karl,

at first, meanwhile I updated to ncs 2.2 and Zephyr 3.2.

We did a few more tests, using extended versions of the UART example. We want to connect an nRF52840-DK and a smartphone with our own app.

By setting in the config file:

CONFIG_BT_BUF_ACL_RX_SIZE=2048
CONFIG_BT_BUF_ACL_TX_SIZE=2048                   (max. for both sizes is 65535)
CONFIG_BT_L2CAP_TX_MTU=2000                        (max. is 2000)
CONFIG_BT_CTLR_DATA_LENGTH_MAX=251       ( max. is 251)

we managed to have 505 bytes transferred by means of a single call of bt_nus_send(..). The maximum might be a few bytes higher, but 510 didn't work. Within an automatically generated autoconf.h (including our settings unchanged) I couldn't find any other number corresponding to the 505..510 bytes. Also on smartphone side there is no number explaining that maximum size.

In the air, there is a split into three frames with PDU lengths 253/253/13 (verified by our sniffer). Obviously, the stack manages the split and the re-assembly on reception side.

In the core specification v5.2, there is a statement in Vol.3, Part F, 3.2.9: "The maximum length of an attribute value shall be 512 octets." which seems to fit to our findings (a few bytes might be used e.g. for some control information).

But anyway, I wonder about these results. When it is necessary to use three frames on air because of the max. length of a single frame, why limit the overall length in this way to 512 bytes? Especially from the energetic point of view (BT LOW ENERGY), it is a waste of resources to have the third frame of 13 bytes PDU only. In my mind, limiting to about 500 bytes would be ok to have two frames on air, or extending the limit to about 750 bytes to fill up the third frame too. And one could ask why it isn't possible to use four/five/... frames on air to have larger maximum packets transferred. Such a wish doesn't contrast to "low energy": I might use it, but I don't have to.

I know that the standard writers usually don't care about implementation, but isn't there any feedback regarding those points, which obviously don't fit to "low energy"?

Merry Xmas

Axel

[ovrebekk]

Hi Axel

Karl is currently out of office and I will handle your case in the mean time. 

axel_s said:

we managed to have 505 bytes transferred by means of a single call of bt_nus_send(..). The maximum might be a few bytes higher, but 510 didn't work.

What about 509 bytes?

The ATT protocol adds a 3 byte header to most packets (one byte for the ATT opcode and 2 bytes for the ATT handle), but to be honest I always assumed that the header would come on top of the 512 byte packet, and not be counted as a part of it. This could be an implementation issue though. 

axel_s said:

In the core specification v5.2, there is a statement in Vol.3, Part F, 3.2.9: "The maximum length of an attribute value shall be 512 octets." which seems to fit to our findings (a few bytes might be used e.g. for some control information).

Correct. This is a spec limitation. The only way to have longer packets be automatically de-assembled and assembled would be to forego the ATT layer altogether, and use L2CAP connection oriented channels. 

axel_s said:

I know that the standard writers usually don't care about implementation, but isn't there any feedback regarding those points, which obviously don't fit to "low energy"?

I can only speculate what the spec designers where thinking when making these decisions, but when the LE mode was added the primary uses cases where on sensor or peripheral type applications where you didn't have to send large amounts of data very often. Keep in mind that in the Bluetooth 4.0 specification the maximum amount of data you could send in one packet was only 20 bytes, and overall throughput was typically limited to no more than 100kbps or less. 

Then this was improved with the ability to send up to 244 bytes of user data in BT 4.2, and the inclusion of the high speed 2M mode in BT 5, to take the total throughput up to around 1.3Mbps in cases where both the central and peripheral supports these features. 

It is a fact though that if you want to achieve the optimal throughput and power efficiency when streaming lots of data over GATT you should handle the de-assembly and assembly manually in the application, and scale the notifications after your data length to ensure that you don't get into these kind of unevenly sized on air packet situations. 

Best regards
Torbjørn