What is the max data throughput with S132 v3?

[jmc]

The absolute max throughput for the nRF52 using S132 v2 was 128 kbps.

The new S132 v3 was recently released and boasts throughput increases by 400%. Has anyone tested this and found the actual max throughput rather than an estimate? Is there example code for testing this?

[Ulrich Myhre]

Internally I have been able to reach speeds just shy of 800kbps, and over that if you look at the raw L2CAP traffic.

To reach the maximum throughput, you need a peer that also supports Data Length Extensions. The length of these should be configured so that it is 4 bytes longer than the ATT MTU size, so that the full packet (including 4 bytes of L2CAP overhead) fits into a single packet. Example values could be an ATT MTU of 247 and a DLE size of 251. Additionally, there is a possibility to enable extended connection events, which will boost the throughput a lot when on a single connection. This simply lets the softdevice keep the connection event running until the next event, or until the peer NACKs a packet.

Mini-guide on how to accomplish this:

1. During SoftDevice enable, set enable_params->gatt_enable_params.att_mtu to 247.
2. Set DLE size with sd_ble_opt_set(BLE_GAP_OPT_EXT_LEN, &opt) where opt.gap_opt.ext_len.rxtx_max_pdu_payload_size = 251 (This step should be optional, but if DLE has been disabled earlier it has to be done).
3. Enable event extension with the options API. sd_ble_opt_set(BLE_COMMON_OPT_CONN_EVT_EXT, &opt) where opt.common_opt.conn_evt_ext.enable = 1.
4. Establish a connection as normal, preferably with a very long connection interval, and initiate an MTU exchange using the relevant APIs. The SoftDevice will automatically initiate DLE negotiation after the MTU exchange has completed. If successful, this produces an extra event stating that the data length was increased.
5. Send longer data packets than before. Remember that for notifications and write commands, 3 bytes are lost in overhead. This means you should be able to segment your data into ATT_MTU-3 = 244 byte payloads.

Keep in mind that long link layer PDUs are more sensitive to noise, as they take longer to transmit. Some peers might limit both ATT MTU and DLE sizes, so it is had to say exactly what you should expect when not testing nRF52 vs. nRF52.

[Ulrich Myhre]

By "raw L2CAP traffic" I meant inlcuding ATT headers and L2CAP headers. Not counting preamble, access address and other baseband parameters. Actual user-defined ATT data traffic is slightly lower, but it should be in the same ballpark - i.e. around 775kbits depending on noise and connection parameters. Very long connection intervals are better with extended connection events, because the SoftDevice can keep on sending without spending time opening/closing events.