nRF52832 BLE UART Service Send Big Data

[Ritesh Panchal]

I am using nRF5_SDK_14.2.0_17b948a on a Fanstel BT832 module which is having nRF52832 SoC. And I am using s132_nrf52_5.1.0_softdevice.hex.

In my application, I need to send around 60KB of image data from host to device.

In my case host is Raspberry Pi3. I am using Nobel node.js BLE application. And BT832 module running ble_peripheral\ble_app_uart example.

Currently, i can send 64 bytes of data at once. But if I try to send more data, then I am not getting in nus_data_handler.

For 60KB transfer, it takes about 1 min 30 sec. Initially, i received data faster(i get into nus_data_handler faster) but gradually it slows down. Like around 15 KB of data i received in 20 sec and remaining 40 KB takes around 1 mins.

I have also disabled loops that send received data to UART. Actually, i need to send that data to SPI Display. So what I am doing, I copied 64 bytes data in a local array and set a flag in interrupt. and send to SPI in while loop. This works perfectly but takes a long.

So how can I increase data rate? Should i use any other service than uart?

[Kenneth]

Hi, 

For firmware updates I typically recommend to use as little as possible of the new BLE features (such as data length extension), because in many cases I have seen that the problem may be related to the implementation of the new features, and you may end up in a deadlock situations if you rely on them for the firmware update (you write 'image' in your text, so thereby I think you are doing some kind of firmware update here). However even with 20bytes payload you should still be able to get decent throughput, for instance split up the image in data packets of 20bytes, write for instance 10 *20bytes of them from the central to the peripheral, and then wait for an notification from the peripheral that the data has been successfully received, before sending the next 10 *20bytes. This may be a bit inefficient, but considering you want to write data to flash etc., it may be a good idea to handshake the data.

However one feature you should implement is conn_params_init(), this to ensure that you have a short connection interval and slave latency of 0 during the image update:

#define MIN_CONN_INTERVAL               MSEC_TO_UNITS(20, UNIT_1_25_MS)             /**< Minimum acceptable connection interval (20 ms), Connection interval uses 1.25 ms units. */
#define MAX_CONN_INTERVAL               MSEC_TO_UNITS(75, UNIT_1_25_MS)             /**< Maximum acceptable connection interval (75 ms), Connection interval uses 1.25 ms units. */
#define SLAVE_LATENCY                   0                                           /**< Slave latency. */
#define CONN_SUP_TIMEOUT                MSEC_TO_UNITS(4000, UNIT_10_MS)             /**< Connection supervisory timeout (4 seconds), Supervision Timeout uses 10 ms units. */
#define FIRST_CONN_PARAMS_UPDATE_DELAY  APP_TIMER_TICKS(3000)                       /**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(5000)                      /**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */
#define MAX_CONN_PARAMS_UPDATE_COUNT    3                                           /**< Number of attempts before giving up the connection parameter negotiation. */

Doing it this way you should be able to efficiently get a throughput of around 1 - 4kB/s, for a 60kB image that equal about 15-60seconds. So not that far off what you have today I guess.

If you are mainly interested in maximum throughput, you can take a look at:
\nRF5_SDK_14.2.0_17b948a\examples\ble_central_and_peripheral\experimental\ble_app_att_mtu_throughput 

Best regards,
Kenneth

[Ritesh Panchal]

Hello Kenneth,

For default MIN_CONN_INTERVAL = 20ms, I am getting below result.

For 20 bytes bunch takes around 3 min 30 sec for 60 KB.

60 bytes bunch takes 2 min 25 sec for 60 KB.

For default MIN_CONN_INTERVAL = 7.5ms, I am getting below result.

For 20 bytes bunch takes around 1 min 37 sec for 60 KB.

60 bytes bunch takes 35 sec for 60 KB.

Raspberry Pi sends all 60KB data in 60 bytes data chunks to Bluetooth buffer data at in few ms. I think this is writing data into Raspberry pi's BLE buffer. And Raspberry Pi and BT832 so some synchronous communication.

I don't know why I am getting the difference in timing for 20 bytes and 60 bytes if internally MTU is 20bytes? 

For more than 64 or more data length, BT832 not getting any receive interrupt.

[Kenneth]

Hi, if you can do a sniffer log I may find the cause:
http://www.nordicsemi.com/eng/Products/Bluetooth-low-energy/nRF-Sniffer/(language)/eng-GB