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.

[Martin Roa Villescas]

I actually found that there is a bug in the ble_nus_c.h. Now that the SoftDevice supports the Long ATT MTU increase, the uint8_t data_len variable inside the ble_nus_c_evt_t definition is not large enough to store values higher than 255. I changed the type to uint16_t, increased the MTU to the maximum, and started seeing throughputs close to 800 kbps. Could you report this bug?