SoftDevice BLE chained advertisement not reassembled by Bluez Stack

[rory0]

Hi,

I am trying to configure an Xiao Seeed Studio nrf54l15 sense to transmit pre-processed sensor data via BLE extended advertisements. As the payload is more than 251 bytes the advertisement packets should be chained.

In the nrf Connect App, it seems the full data is transmitted.

My receiver skript however only gets the first package and drops the rest of the payload. It is written in python using bleak and running under up-to-date linux, therefore leveraging the bluez stack in the current version 5.86. The computer hardware supports Bluetooth 5.1.

I post this here rather than in a bluez channel as I suspect the error to be in the package structure transmitted by the device, therefore within the proprietary softdevice driver.

Below I post the output of btmon, that hopefully clarifies the issue to someone more experienced with BLE than me:

> HCI Event: LE Meta Event (0x3e) plen 255                     #833 [hci0] 597.158289
      LE Extended Advertising Report (0x0d)
        Num reports: 1
        Entry 0
          Event type: 0x0020
            Props: 0x0000
            Data status: Incomplete, more data to come
          Address type: Random (0x01)
          Address: DF:F5:D6:F4:AE:E3 (Static)
          Primary PHY: LE 1M
          Secondary PHY: LE 2M
          SID: 0x00
          TX power: 127 dBm
          RSSI: -68 dBm (0xbc)
          Periodic advertising interval: 0.00 msec (0x0000)
          Direct address type: Public (0x00)
          Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
          Data length: 229
        Advertising Data[229]:
        08 09 54 65 73 74 41 64 76 31 21 73 6f 70 68 65  ..TestAdv1!sophe
        72 2d 73 65 6e 73 6f 72 2d 61 78 00 7f d1 3d 44  r-sensor-ax...=D
        7d 8e 3c 00 40 d0 40 00 00 c7 03 00 00 00 00 00  }.<.@.@.........
        00 00 00 00 00 00 00 00 00 00 00 31 21 73 6f 70  ...........1!sop
        68 65 72 2d 73 65 6e 73 6f 72 2d 61 79 dd 3f f6  her-sensor-ay.?.
        3d f9 e8 a6 3c 00 40 d0 40 00 00 43 02 00 00 00  =...<.@[email protected]....
        00 00 00 00 00 00 00 00 00 00 00 00 00 31 21 73  .............1!s
        6f 70 68 65 72 2d 73 65 6e 73 6f 72 2d 61 7a 00  opher-sensor-az.
        fd 07 3e e6 e3 a3 3c 00 40 d0 40 00 00 d9 03 00  ..>...<.@.@.....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 31  ...............1
        21 73 6f 70 68 65 72 2d 73 65 6e 73 6f 72 2d 76  !sopher-sensor-v
        78 00 00 00 00 00 00 00 00 00 40 d0 40 00 00 c7  x.........@.@...
        03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 31 21 73 6f 70 68 65 72 2d 73 65 6e 73 6f 72  .1!sopher-sensor
        2d 76 79 00 00                                   -vy..           
        Name (complete): TestAdv
        Service Data UUID 128: Vendor specific 
          Data[32]:
        00 7f d1 3d 44 7d 8e 3c 00 40 d0 40 00 00 c7 03  ...=D}.<.@.@....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        Service Data UUID 128: Vendor specific 
          Data[32]:
        dd 3f f6 3d f9 e8 a6 3c 00 40 d0 40 00 00 43 02  .?.=...<.@[email protected].
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        Service Data UUID 128: Vendor specific 
          Data[32]:
        00 fd 07 3e e6 e3 a3 3c 00 40 d0 40 00 00 d9 03  ...>...<.@.@....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        Service Data UUID 128: Vendor specific 
          Data[32]:
        00 00 00 00 00 00 00 00 00 40 d0 40 00 00 c7 03  .........@.@....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        31 21 73 6f 70 68 65 72 2d 73 65 6e 73 6f 72 2d  1!sopher-sensor-
        76 79 00 00                                      vy..            
@ MGMT Event: Device Found (0x0012) plen 223               {0x0001} [hci0] 597.158380
        LE Address: DF:F5:D6:F4:AE:E3 (Static)
        RSSI: -68 dBm (0xbc)
        Flags: 0x00000004
          Not Connectable
        Data length: 209
        Data[209]:
        08 09 54 65 73 74 41 64 76 31 21 73 6f 70 68 65  ..TestAdv1!sophe
        72 2d 73 65 6e 73 6f 72 2d 61 78 00 7f d1 3d 44  r-sensor-ax...=D
        7d 8e 3c 00 40 d0 40 00 00 c7 03 00 00 00 00 00  }.<.@.@.........
        00 00 00 00 00 00 00 00 00 00 00 31 21 73 6f 70  ...........1!sop
        68 65 72 2d 73 65 6e 73 6f 72 2d 61 79 dd 3f f6  her-sensor-ay.?.
        3d f9 e8 a6 3c 00 40 d0 40 00 00 43 02 00 00 00  =...<.@[email protected]....
        00 00 00 00 00 00 00 00 00 00 00 00 00 31 21 73  .............1!s
        6f 70 68 65 72 2d 73 65 6e 73 6f 72 2d 61 7a 00  opher-sensor-az.
        fd 07 3e e6 e3 a3 3c 00 40 d0 40 00 00 d9 03 00  ..>...<.@.@.....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 31  ...............1
        21 73 6f 70 68 65 72 2d 73 65 6e 73 6f 72 2d 76  !sopher-sensor-v
        78 00 00 00 00 00 00 00 00 00 40 d0 40 00 00 c7  x.........@.@...
        03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00                                               .               
        Name (complete): TestAdv
        Service Data UUID 128: Vendor specific 
          Data[32]:
        00 7f d1 3d 44 7d 8e 3c 00 40 d0 40 00 00 c7 03  ...=D}.<.@.@....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        Service Data UUID 128: Vendor specific 
          Data[32]:
        dd 3f f6 3d f9 e8 a6 3c 00 40 d0 40 00 00 43 02  .?.=...<.@[email protected].
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        Service Data UUID 128: Vendor specific 
          Data[32]:
        00 fd 07 3e e6 e3 a3 3c 00 40 d0 40 00 00 d9 03  ...>...<.@.@....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        Service Data UUID 128: Vendor specific 
          Data[32]:
        00 00 00 00 00 00 00 00 00 40 d0 40 00 00 c7 03  .........@.@....
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
> HCI Event: LE Meta Event (0x3e) plen 45                      #834 [hci0] 597.161225
      LE Extended Advertising Report (0x0d)
        Num reports: 1
        Entry 0
          Event type: 0x0020
            Props: 0x0000
            Data status: Incomplete, more data to come
          Address type: Random (0x01)
          Address: DF:F5:D6:F4:AE:E3 (Static)
          Primary PHY: LE 1M
          Secondary PHY: LE 2M
          SID: 0x00
          TX power: 127 dBm
          RSSI: -68 dBm (0xbc)
          Periodic advertising interval: 0.00 msec (0x0000)
          Direct address type: Public (0x00)
          Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
          Data length: 19
        Advertising Data[19]:
        00 00 00 00 00 00 00 40 d0 40 00 00 43 02 00 00  .......@[email protected]...
        00 00 00                                         ...             
        00 00 00 00 00 00 00 40 d0 40 00 00 43 02 00 00  .......@[email protected]...
        00 00 00                                         ...             
@ MGMT Event: Device Found (0x0012) plen 14                {0x0001} [hci0] 597.161266
        LE Address: DF:F5:D6:F4:AE:E3 (Static)
        RSSI: -68 dBm (0xbc)
        Flags: 0x00000004
          Not Connectable
        Data length: 0
> HCI Event: LE Meta Event (0x3e) plen 87                      #835 [hci0] 597.167236
      LE Extended Advertising Report (0x0d)
        Num reports: 1
        Entry 0
          Event type: 0x0000
            Props: 0x0000
            Data status: Complete
          Address type: Random (0x01)
          Address: DF:F5:D6:F4:AE:E3 (Static)
          Primary PHY: LE 1M
          Secondary PHY: LE 2M
          SID: 0x00
          TX power: 127 dBm
          RSSI: -67 dBm (0xbd)
          Periodic advertising interval: 0.00 msec (0x0000)
          Direct address type: Public (0x00)
          Direct address: 00:00:00:00:00:00 (OUI 00-00-00)
          Data length: 61
        Advertising Data[61]:
        00 00 00 00 00 00 00 00 00 00 00 31 21 73 6f 70  ...........1!sop
        68 65 72 2d 73 65 6e 73 6f 72 2d 76 7a 00 00 00  her-sensor-vz...
        00 00 00 00 00 00 40 d0 40 00 00 d9 03 00 00 00  ......@.@.......
        00 00 00 00 00 00 00 00 00 00 00 00 00           .............   
        00 00 00 00 00 00 00 00 00 00 00 31 21 73 6f 70  ...........1!sop
        68 65 72 2d 73 65 6e 73 6f 72 2d 76 7a 00 00 00  her-sensor-vz...
        00 00 00 00 00 00 40 d0 40 00 00 d9 03 00 00 00  ......@.@.......
        00 00 00 00 00 00 00 00 00 00 00 00 00           .............   
@ MGMT Event: Device Found (0x0012) plen 14                {0x0001} [hci0] 597.167298
        LE Address: DF:F5:D6:F4:AE:E3 (Static)
        RSSI: -67 dBm (0xbd)
        Flags: 0x00000004
          Not Connectable
        Data length: 0

 

What I notice is that already the first packet triggers a MGMT event and that it's data length differs from the HCI Event, and that subsequent MGMT Events have a data length of zero.

Why does the bluez stack fail to reassemble the packets?

What are the necessary KConfig options to advertise more than 251 Bytes of data?

Big thanks in advance!
-rory

[tesc]

Hi,

The output that you provided are from btmon, which is part of Bluez, which is where you experience the issue. This means there is no way to know if the issues with the output stems from the original packets sent over-the-air, or if it stems from Bluez. Would you be able to provide a sniffer trace, either using the nRF Sniffer or a different BLE sniffing tool which is not part of Bluez? That way, we could have a look at what has actually been sent over-the-air, in order to diagnose further if anything is off with the transmission.

Regards,
Terje

[rory0]

Hi!
Thank you for your answer and sorry for the late reply!

Unfortunately I do not have a sniffing device availabe, and running wireshark on my laptop gives more or less the same information as btmon. What I can say (and forgot to mention in my first post) is that nRF Connect app on my phone manages to reassemble the packets just fine. Is there any export from there that would be useful for you?

Are you able to tell from the btmon logs whether the packets in the HCI events look healthy?
For me, not knowing much about the BLE standards, the question was if there are maybe different timings for the chaining that in this case fail to work together? And I am also suprised that there are 3 packets rather than just 2 that would be sufficient for the size of data. Can you think of a reason for that?

Also, in the meantime I learned that chained advertising is just an optional feature in the bluetooth 5.1 standard, so maybe my laptop doesn't even support chaining. What contradicts this in my understanding, however, is the fact that I see all packets in the HCI events. Do you have any thoughts on this?

Many thanks and best regards!
-rory

[tesc]

Hi,

rory0 said:

Unfortunately I do not have a sniffing device availabe, and running wireshark on my laptop gives more or less the same information as btmon.

If you have an additional nRF device, either a DK or a Dongle, you can use that for the nRF Sniffer.

rory0 said:

Are you able to tell from the btmon logs whether the packets in the HCI events look healthy?

It would help significantly to know what data was being sent for those packets, and the total data length. To me it looks like a number of packets of different length, but without information about what is supposed to be sent it is hard to tell if anything is off or missing.

rory0 said:

Also, in the meantime I learned that chained advertising is just an optional feature in the bluetooth 5.1 standard, so maybe my laptop doesn't even support chaining. What contradicts this in my understanding, however, is the fact that I see all packets in the HCI events. Do you have any thoughts on this?

If you see all the packets, it may still be btmon listing all packets, but not necessarily having the ability to reassemble them. If btmon simply lists all HCI events between controller and host, and reassembly is done at a higher level (i.e. in the host), then I would not expect to see any reassembled packets from the btmon logs.

Regards,
Terje