Unreliable BLE connection for continuos high bandwidth data stream

RE: Unreliable BLE connection for continuos high bandwidth data stream

ovrebekk — Wed, 31 Jan 2024 07:45:06 GMT

Thanks Hugh, looks correct to me at least 🙂

RE: Unreliable BLE connection for continuos high bandwidth data stream

hmolesworth — Tue, 30 Jan 2024 20:30:48 GMT

I wrote this to // | // +-------------------- // | // +----------+--------+ // | | Access | // | Preamble | Address| // +----------+--------+ // | 1 (2) | 4 | // | | // | | // | | // | | // | | | // | | | // | | | // | | | // | | | // | | | // | | | // | | | // | | | // | 1 (2) | 4 | 2 // +----------+--------+ include in the code, as an aide memoire, hopefully it's about right :-)

// +-----------------------------------------------------------------------------------------------------------------+ BLE Data Packet Min/Max                                             | ---------------------------------------------------------------------------------------------+ 1MHz: 10/265 octets, 2MHz: 11/266 octets                            | --------------------------------------------------------------------------------------+------+ |      | Protocol Data Unit PDU                                                       | CRCC | --------------------------------------------------------------------------------------+------+ 2-257                              |  3   | +-----------+------------------------------------------------------------------+-------+      | | LL Header |  Payload                                                         |  MIC  |      | +-----------+------------------------------------------------------------------+ (opt) |      | |   2       |                                       0-251                      |   4   |      | +--------+---------------------------------------------------------+       |      | | L2CAP  |                                                         |       |      | | Header |  ATT Data                                               |       |      | +--------+---------------------------------------------------------+       |      | |   4    |                              0-247                      |       |      | |        +-----+-------+-------------------------------------------+       |      | |        | ATT | ATT   |                                           |       |      | |        | Op  | Attrib|  ATT Payload                              |       |      | |        +-----+-------+-------------------------------------------+       |      | |   4    |  1  |  2    |                0-244                      |  (4)  |  3   | -----------+--------+-----+-------+-------------------------------------------+-------+------+

RE: Unreliable BLE connection for continuos high bandwidth data stream

timonsku — Tue, 30 Jan 2024 19:04:40 GMT

ah I see! Thanks for the clarification

RE: Unreliable BLE connection for continuos high bandwidth data stream

ovrebekk — Tue, 30 Jan 2024 15:11:10 GMT

It's a bit of semantics I guess, what you define as the payload or not.

The total packet length is higher, that is correct. You get either 10 or 14 bytes in addition to the payload I mentioned, depending on whether or not encryption is enabled.

The total packet looks like this:

1 byte preamble + 4 byte access address + 2 byte packet header + 0-251 byte data payload + 3 byte CRC (+ 4 byte MIC)

This totals 265 bytes when using 251 byte payload and encryption.

Best regards
Torbjørn

RE: Unreliable BLE connection for continuos high bandwidth data stream

timonsku — Mon, 29 Jan 2024 21:11:54 GMT

oh maybe I misunderstood something about the L2CAP layer. I thought the packet length was 265 and with overhead its 251 data bytes
Was going by interrupt.memfault.com/.../ble-throughput-primer

RE: Unreliable BLE connection for continuos high bandwidth data stream

ovrebekk — Mon, 29 Jan 2024 12:46:12 GMT

Hi Timon

[quote user="DiodesDelight"]You mean as in setup the data stream so I send 244bytes per transaction/notification?[/quote]

Yes, split your data into 244 byte chunks to avoid link layer segmentation.

[quote user="DiodesDelight"]but where does the 244 comes from, isn't the maximum 251bytes of actual data?[/quote]

The on air payload is 251 bytes, correct (or 255 with encryption enabled, since you need 4 bytes for the MIC), but the L2CAP layer reserves 4 of those for the L2CAP header, and the ATT layer reserves 3 for the ATT header, leaving you with 244 bytes for user data.

Best regards
Torbjørn

RE: Unreliable BLE connection for continuos high bandwidth data stream

timonsku — Sat, 27 Jan 2024 02:40:44 GMT

Could you go into detail what you mean with "scale the notifications after the data length"?
You mean as in setup the data stream so I send 244bytes per transaction/notification? That would make sense to me to make sure to send only one packet per notification and do more frequent notifications but where does the 244 comes from, isn't the maximum 251bytes of actual data?

RE: Unreliable BLE connection for continuos high bandwidth data stream

ovrebekk — Fri, 26 Jan 2024 08:21:41 GMT

Very good to hear that you found the issue 🙂

Another tip to maximize throughput is to scale the notifications after the data length, to avoid packet fragmentation. If you send 244 bytes of data per packet you should get the most efficient transfer when using the maximum data length.

Best regards
Torbjørn

RE: Unreliable BLE connection for continuos high bandwidth data stream

timonsku — Thu, 25 Jan 2024 18:47:02 GMT

heh okay I found the issue. There was a
CONFIG_BT_USER_DATA_LEN_UPDATE=y
CONFIG_BT_USER_PHY_UPDATE=y
lurking after my
CONFIG_BT_GAP_AUTO_UPDATE_CONN_PARAMS=y

which disabled actually updating the phy and data length as I'm not doing that explicitly in my app as its done in the throughput example. I'm guessing this fragment made it in when copying some connection parameters over from the passthrough example.
I also noticed while both sides advertised 2M PHY initially they never actually switched to it.
Removed those config lines and now its updating everything automatically and runs just fine at full sampling bandwidth :)
Thanks for your pointers ovrebekk they put me on the right track. I compared captures between throughput sample and my app and saw that that exchange was missing.

RE: Unreliable BLE connection for continuos high bandwidth data stream

timonsku — Thu, 25 Jan 2024 16:30:12 GMT

Yea sure, is there a way to privately share it? Would like to avoid sharing MAC addresses of the BLE devices publicly.

It's odd, both in Zephyr it confirms the MTU via bt_nus_get_mtu() and also sniffing the traffic it seems to ack the MTU.

RE: Unreliable BLE connection for continuos high bandwidth data stream

ovrebekk — Thu, 25 Jan 2024 12:56:24 GMT

Hi Timon

Looking at the trace excerpt it seems that the data length is not increased, which means all the data needs to be segmented in 27 byte packets (of which only 20 bytes include user data), and this will severely impact the overall throughput.

This could either be caused by a limitation on the Windows side (hopefully not), or a configuration issue after establishing the connection.

Would you be able to save the full trace to file and share it in the case?

Then I can take a look at it and see if I can spot an issue with the data length request procedure.

If you can share your project configuration this could also be useful (prj.conf).

Best regards
Torbjørn

RE: Unreliable BLE connection for continuos high bandwidth data stream

timonsku — Wed, 24 Jan 2024 23:20:15 GMT

I'm mostly testing with my Windows machine as the central. It has a Mediatek chipset for Bluetooth.
I had also tried out the NUS Central sample but similar behaviour occurred though I have not dug deeper there other than upping the UART baud rate.
In the end the application would have to work at least with your average Windows or Mac for now, later on also with phones so it would have to be somewhat reliable enough with third party chipsets too in any case.
For bandwidth testing I stuck to the nRF5340DK instead of the custom hardware.

Good call with testing dummy data, I don't think I have done that so far. From the profiling so far it didn't seem too much of a data handling issue as it was usually hanging at nus_send but good to double check.
Below is a short block of what I captured with a 16hz sampling rate being transmitted.

Both MTU size and 2M PHY were ack'ed by the central during connection handshake.
But there are multiple L2CAP fragments between each event. I'm not knowledgable enough on the BLE PHY end to know if that is how a transmission works or if that should show up as a single packet equal to MTU size.

RE: Unreliable BLE connection for continuos high bandwidth data stream

ovrebekk — Wed, 24 Jan 2024 10:28:34 GMT

Hi Timon

It is odd that you would get such low rates. Are you running Nordic devices on both sides of the link, or are you communicating with something else, like a smart phone?

Are you using custom hardware or standard devkits?

Did you confirm from the sniffer trace that data length and large MTU is probably utilized?
Could you see many packets sent back to back within a connection event, or only a single packet pr connection event?

For testing purposes I would recommend starting with dummy data just to rule out an issue in the handover between the DMIC reading and the Bluetooth transmission.

Best regards
Torbjørn