What is the max data throughput with S132 v3?

RE: What is the max data throughput with S132 v3?

Nivetha — Thu, 24 Aug 2017 11:00:55 GMT

Thanks, Ulrich. Currently, im using att_mtu as 48 bytes which is given as NRF_BLE_GATT_MAX_MTU_SIZE. Now for this case, the connection interval is 10ms and 10 samples each sample of 12 bytes are transmitted. Can the attribute data be 44 bytes ? or do I need to reduce to 20 bytes to send more packets in 1connection interval?

RE: What is the max data throughput with S132 v3?

Ulrich Myhre — Thu, 24 Aug 2017 10:10:08 GMT

You will have to do some experiments. At 10ms, the length of each connection event will be limited in order to start the next one.

RE: What is the max data throughput with S132 v3?

Nivetha — Thu, 24 Aug 2017 09:46:05 GMT

Hi, Ulrich! my question is posted here. I want to keep the connection interval to 10ms, Can I still set MTU 247, DLE 251 to achieve max throughput with nrf52 DK. Please help!

RE: What is the max data throughput with S132 v3?

Ulrich Myhre — Mon, 14 Nov 2016 13:34:05 GMT

Good catch! I have notified the team that works on the SDK, and they will track this internally.

RE: What is the max data throughput with S132 v3?

Martin Roa Villescas — Mon, 14 Nov 2016 10:16:13 GMT

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?

RE: What is the max data throughput with S132 v3?

Ulrich Myhre — Mon, 14 Nov 2016 10:07:26 GMT

Have you also enabled event extension on both sides? And is the peer pulling the events as fast as you are sending them? With event extensions enabled, the connection interval should be as high as possible during data transfer. This lets the SoftDevice continue to send data without closing the connection event.

Unfortunately, the length extended packets are more prone to noise due increased radio time, so this can be a factor in your lower throughput. If you are able to put the devices closer, or shield them from other 2.4GHz sources, does this help?

RE: What is the max data throughput with S132 v3?

Martin Roa Villescas — Tue, 08 Nov 2016 22:22:15 GMT

Hi Ulrich. I've been playing with the MTU, DLE and Connection Interval parameters but I haven't been able to reach the high throughputs that you mention. In your post you suggest MTU=247, DLE=251, a notification p_len of 244, and a long connection interval. How long should this connection interval be? By the way, I have an app_timer running in parallel that I use to calculate the throughput every 2 seconds. Could this timer be the reason why I cant pass a throughput of 496 kbps? Thanks.

RE: What is the max data throughput with S132 v3?

Ulrich Myhre — Wed, 26 Oct 2016 07:18:27 GMT

When the number of peers increase, you generally want to use shorter connection intervals if latency is important. This puts a hard limit on the amount of data you are able to send each connection interval, because the central must end the connection event in order to process the next. There are throughput numbers in the Softdevice Specification for these scenarios, and those should be relevant in that case. However, there is a special case, where latency is not important, but sending bursts of data to each slave in order is good enough. In that case, you can live with a longer connection interval and send as much as possible to each device when possible. In short, with many devices, throughput is limited in order to serve all the peripherals. You can tweak the connection parameters (with event ext. on) to balance throughput, power efficiency and latency to your needs.

RE: What is the max data throughput with S132 v3?

djqtsg — Tue, 25 Oct 2016 07:18:17 GMT

HI Ulrich,

I wonder whether you have tested throughput in a case whereby there are multiple slaves, let's say maximum 7. We have an application where multiple sensors transmit data packets (30+ bytes long, 50~100Hz) to a gateway. Previously we used nrf24l01 as the radio, now we are considering BLE 4.2; so we want to know the BLE 4.2 performance in 1-many case.

RE: What is the max data throughput with S132 v3?

djqtsg — Tue, 27 Sep 2016 07:46:04 GMT

Hi Ulrich,

Can you take a look at my Q here? Thx.

RE: What is the max data throughput with S132 v3?

Ulrich Myhre — Mon, 26 Sep 2016 08:35:43 GMT

I work more on the SoftDevice directly than through the SDK, but if that define is used in the att_mtu field it should be updated. Outside of the things I mentioned (ATT_MTU, rxtx_max_pdu_payload_size, conn_evt_ext.enable) nothing else needs to be done, except initiating the MTU exchange procedure once the link is set up.

sd_ble_opt_set() for setting DLE size should be set after enabling the stack, but before going into a connection. It might not be needed in some cases, as it should default to ATT_MTU+4 automatically. Increasing MTU size will indeed change the memory requirements, as the stack needs larger buffers to reassemble the PDUs.

RE: What is the max data throughput with S132 v3?

djqtsg — Mon, 26 Sep 2016 02:08:18 GMT

Are there any other parameters that need to be changed, like NRF_BLE_MAX_MTU_SIZE?

I am using UART sample code to test DLE feature. If I change NRF_BLE_MAX_MTU_SIZE to a bigger size than GATT_MTU_SIZE_DEFAULT, the app_ram_base should also be changed accordingly; otherwise softdevice_enable() returns error.

In the UART sample code, I cannot find where sd_ble_opt_set() is called. So if I want to call it, where should I do, in softdevice_enable()?

RE: What is the max data throughput with S132 v3?

Ulrich Myhre — Wed, 21 Sep 2016 00:30:09 GMT

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.

RE: What is the max data throughput with S132 v3?

jmc — Tue, 20 Sep 2016 23:39:14 GMT

Actual data throughput with overhead removed was almost 800 kbps? Wow!

RE: What is the max data throughput with S132 v3?

Ulrich Myhre — Tue, 20 Sep 2016 22:12:55 GMT

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:

During SoftDevice enable, set enable_params->gatt_enable_params.att_mtu to 247.
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).
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.
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.
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.