BLE Data Length Extension Issue

[J Ch]

I was able to find the feature to enable data length extension through the btstack_config file: #define ENABLE_LE_DATA_LENGTH_EXTENSION

Using the GATT Streamer example, now it does appear that it **says** it should send a max TX packet size of 251 bytes per packet.  However it is still only sending 27 byte packets.

Here's what I get when I connect to the GATT Streamer example with the LightBlue app on my iPhone:

A: ATT connected, handle 0x0040, test data len 20
- LE Connection 0x0040: connected - connection interval 30.00 ms, latency 0
- LE Connection 0x0040: data length change - max 251 bytes per packet
A: ATT MTU = 252 => use test data of len 200

But when I enable notifications and view the packets via WireShark, I am still only seeing 27 byte packets being sent. Any thoughts on what I can try next?

[Matthias Ringwald]

HI Jacob

Yes, ENABLE_LE_DATA_LENGTH_EXTENSION is needed to enable support for it in the stack.


What Bluetooth Controller do you use?

If the Controller supports it, please check the HCI log. The stack should check and send a
hci_le_read_maximum_data_length command to learn the max size and then set is as default with
LE Write Suggested Default Data Length command to the Controller.

Best
Matthias

> --
> You received this message because you are subscribed to the Google Groups "btstack-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to btstack-dev...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/544a6b39-f130-4dc5-bd90-a3015c6818a0n%40googlegroups.com.

[J Ch]

Hello Matthias,

Thanks for your response. I am using the Pi PicoW which has a Infineon CYW4343 chip.

As I mentioned, I am seeing that the BT stack replies with a LL_LEN_RSP with a Max Tx Octets: 251. But then it only sends 27 btye packets.

I apologize that I don't know how to enable or view the HCI log. Can you let me know if there is a guide to doing that?

Thank you.

[Matthias Ringwald]

Hi Jacob

Sorry, I've missed the detail in your console log:

> > - LE Connection 0x0040: data length change - max 251 bytes per packet
> > A: ATT MTU = 252 => use test data of len 200

The first one confirms that DLE is used for that connection and the second shows that an ATT MTU of 252 bytes was used, which should result in long packets being used for all ATT PDUs.

--

How to get HCI trace on the Pico W isn't documented well.

In pico_w/bt/picow_bt_example_common.c, please add

#include <hci_dump_embedded_stdout.h>

at the beginning and in picow_bt_example_init(..), add

hci_dump_init(hci_dump_embedded_stdout_get_instance());
hci_dump_enable_packet_log(true);

after the cyw43_arch_init() block.

You can then convert the console output with tool/create_packet_log,py into a .pklg that can be viewed in Wireshark.

Cheers
Matthias

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/85d2985c-3f6e-4d67-b967-98e6df3fec41n%40googlegroups.com.

[J Ch]

Hello Matthias,

Thanks for your help. I am seeing, I think, that it is not actually sending the long ATT packets.  For example, I am running the btstack example "GATT streamer" using my iPhone and the PicoW.  When I use Wireshark and an NRF52840 dongle to sniff, it does appear that only smaller ATT packets are being sent over the air and then after so many of them, I get the ATT notification.

I did enable the HCI output on PicoW and processed the log file with the Python tool, but it only appears to show me details at the ATT level. So I am unsure of how to use it.

Can you let me know what you think?

Thank you.

[Matthias Ringwald]

Hi Jacob

You could have posted the HCI logs, but your observation is correct that it only shows that BTstack sends 200 byte ATT notifications.
As it uses the ACL LE buffer from the Controller, this will be the case with/without DLE.

As for the other screenshot, there will be a number of regular GATT queries for services and discoveries that are usually short anyway.

Could you share your log anyway? If you could share your sniffer logs, that would help, too.


I have some older logs from a CYW02704 as GATT Server. It's not clear if DLE was enabled on the Pico W.
It shows an LE Data Length Change event with TX = 251 and RX = 27. This asymmetry could be because Pico didn't enable DLE. But it's good to check.

Best
Matthias

> On 26 Jul 2023, at 14:00, J Ch <jacob.ch...@gmail.com> wrote:
>
> Hello Matthias,
>

> Thanks for your help. I am seeing, I think, that it is not actually sending the long ATT packets. For example, I am running the btstack example "GATT streamer" using my iPhone and the PicoW. When I use Wireshark and an NRF52840 dongle to sniff, it does appear that only smaller ATT packets are being sent over the air and then after so many of them, I get the ATT notification. <Capture.JPG>

>
> I did enable the HCI output on PicoW and processed the log file with the Python tool, but it only appears to show me details at the ATT level. So I am unsure of how to use it.
>

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/c80d1184-8922-49b4-ab77-7c6addb98ebfn%40googlegroups.com.
> <Capture.JPG><Capture2.JPG>

[J Ch]

Hello Matthias, 

Thanks for all your help. 

I have attached a link to the hci logs and the sniffer log. 

Also, I was able to get some time using an Ellisys Explorer. I did confirm that it is only sending the smaller size packets instead of the extended packets. 

Should I open a Github issues? (I've never done that before...)

Thanks,

Jacob

[Matthias Ringwald]

Hi Jacob

Thanks for the logs. You could have added the Ellisys log, too, but the one from the Nordic sniffer is clear.

In the HCI log, the LE Data Length Change event indicates 251 bytes in both direction, so there's no reason for the 43439 to not use it.

Jan 01 18:00:14.214 HCI Event LE - Data Length Change RECV
Parameter Length: 11 (0x0B)
Connection Handle: 0x0040
Max Tx Octets: 251 (0xFB)
Max Tx Time: 328 (0x148)
Max Rx Octets: 251 (0xFB)
Max Rx Time: 2120 (0x848)

Oh! While it shows 251 Tx octets, it only lists 328 us instead of the expected 2120 us. With the Tx time only 328 us, I guess this does only allow for short packets.

So the question is now: why does it report a max tx time of 328 us instead of the expected 2120 us?

--

I've opened an issue at the Pico SDK: https://github.com/raspberrypi/pico-sdk/issues/1465
Let's see if they can look into this.

Best
Matthias

> On 29 Jul 2023, at 03:53, J Ch <jacob.ch...@gmail.com> wrote:
>
> Hello Matthias,
>

> Thanks for all your help.
>
> I have attached a link to the hci logs and the sniffer log.
>
> Also, I was able to get some time using an Ellisys Explorer. I did confirm that it is only sending the smaller size packets instead of the extended packets.
>
> Should I open a Github issues? (I've never done that before...)
>
> Thanks,

> Jacob<ellisys.JPG>

> To view this discussion on the web visit https://groups.google.com/d/msgid/btstack-dev/a058f8f2-b6aa-4234-9483-8ffd3880e6f2n%40googlegroups.com.
> <ellisys.JPG>