Extremely Slow BLE Throughput on the nRF52840, using the BMD-340

RE: Extremely Slow BLE Throughput on the nRF52840, using the BMD-340

Vidar Berg — Thu, 01 Oct 2020 10:13:47 GMT

Hi,

The BLE_ERROR_GATTS_SYS_ATTR_MISSING error indicates that the FW app tried to send a notification right after connection before it had been re-enabled by the client. I see now that this is something that can happen with the ble_app_uart example because it doesn't clear its internal "is_notification_enabled" flag on re-connect like it should. CCCD settings are only supposed to stay valid for the duration of a connection session when not bonded. I.e. notification(s) must always be re-enabled on re-connect.

That said, it's perfectly ok to call sd_ble_gatts_sys_attr_set() on connect, this will make it so that you get NRF_ERROR_INVALID_STATE error which is ignored by default, instead of the BLE_ERROR_GATTS_SYS_ATTR_MISSING error you get when sys attributes are not initialized.

I'm more surprised about the disconnect. The softdevice stack has no problem to keep up with the incoming data so I'm wondering if there is something else that's crashing in the app. Are you catching all code assertions with with the Error module? As you can see from the link, the default error handling is to try recovering with a system reset.

Cheers,

Vidar

RE: Extremely Slow BLE Throughput on the nRF52840, using the BMD-340

tyrelkostyk — Wed, 30 Sep 2020 16:27:22 GMT

Hi Vidar,

Thank you for your prompt and detailed response! It had been one of our main concerns that the ACK'ing of every packet was causing the low throughput - we just didn't expect it to have such a dramatic impact.

And yes, we have tried modifying the protocol to be "batch-based" - we tried ACKing only after receiving 4KB worth of payload data (32 packets). This meant our central device would blast out 32 155 byte packets, before the peripheral would respond with its 27 byte ACK. The issue with this was that we saw the BLE Peripheral (the BMD-340 with the nRF52840) simply disconnect and crash... the initial fatal error we were seeing was a disconnect, then a reconnect attempt immediately followed by the BLE_ERROR_GATTS_SYS_ATTR_MISSING. We resolved that by adding in:

err_code = sd_ble_gatts_sys_attr_set(m_conn_handle, NULL, 0, 0);
APP_ERROR_CHECK(err_code);

After the BLE_GAP_EVT_CONNECTED case within ble_evt_handler(). Now, this resolved the crashing, however our BLE Peripheral was still sometimes disconnecting and reconnecting, and after the reconnect our central and peripheral couldn't communicate properly, despite the negotiation seemingly going smoothly. We lowered our batch size to only 10 packets instead of 32, which seemed to mostly resolve the issue - but we were still skeptical, since we lack an understanding of why this change worked, or why it even failed to begin with.

Since the purpose of the BLE Peripheral in this context is to facilitate the file transfer for a bootloader, reliability was considered of utmost importance, and the strange (and very unreliable) results we were seeing was considered not worth the risk, despite the improved throughput (we were seeing up to ~1.4KB on the Android tablet - didn't test on the iPad Air 2). Do you have any suggestions or ideas that immediately come to your mind? I can recreate the problem again and give you a more detailed explanation, if that helps. I should also mention that we arbitrarily added a 5-10ms (we experimented) delay between each packet, since we were worried about "flooding" the GATT client with write notifications. But that didn't seem to have any impact on the behavior.

Thanks again Vidar! I'll take a look at the throughput project you sent as well. I hope you have a great rest of your day.

Cheers,

RE: Extremely Slow BLE Throughput on the nRF52840, using the BMD-340

Vidar Berg — Wed, 30 Sep 2020 13:17:17 GMT

Hello,

Thanks for your detailed problem description. I actually think the "ACKing" of every 128-byte is what's causing the main bottleneck - the central will effectively be limited to sending 128 bytes of payload on every other connection event if it has to wait for the target to ACK the packet. First connection event to send the data, then the next to receive the ack, and so on.

I haven't worked with this particular protocol, but is there a way you can increase the required ACK interval? In our DFU transport we usually compute and report the checksum once for every 4096-byte data object. And we are using the GATT write without response procedure for the data transfer (GATTC Characteristic Value Write Without Response).

[quote user=""]For reference, when completing this process over a straight serial UART cable (115200 baud), we see a data rate of ~7.50-8.50KB/s.[/quote]

This is close to the same throughput we get with our BLE DFU implementation. It varies a bit depending on which phone is used.

Also, I have modified the ble_app_uart example to measure notification throughput which is similiar to write without response except that it's sent from the GATT server. It can be helpful if you want to play around with different connection paramaters and see what effect it has. All you have to do on the client side is to enable notifications (in nrf connect app or similiar). The nRF5 will log the measured transfer rate over RTT.

Throughput test example:

devzone.nordicsemi.com/.../nrf5_5F00_sdk_5F00_17.0.2-_2D00_-ble_5F00_app_5F00_uart_5F00_throughput.zip

Cheers,

Vidar