This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Transfer speed secure DFU SDK14

Hi,

I wonder what transfer speed can be expected on a BLE DFU update on a nRF52832 based device in the following condition?

-SDK14.0 Secure DFU, nRF52832, Android tablet (Oreo, Bluetooth 5.0), nRF Connect

We are currently facing a transfer speed of about 1 Kbytes/sec, which sounds way too low. On a 350 Kbytes file, it will take almost 6 minutes to transfer.

Regards, Jan

Parents
  • Hi

    Here are some thoughts from one of the DFU gurus:

    There are no hidden tricks, unfortunately. I think SDK version 12.3.0 went as fast as 3.5kb/s, but this was degraded to 1.5kb/s after some changes in SDK 13 and improved again in SDK 14 up to 4.5kb/s.

    There are many variables to take into account and the unfortunate thing is that the transfer might fail if only one of the variables is updated and the rest is not. This is because the current DFU protocol does not implement any kind of flow control.

    The variables that can be tweaked are NRF_FSTORAGE_SD_MAX_WRITE_SIZE (smaller), connection interval (smaller is faster), and event length might help too. I think the latter depends on which SDK version you are running, since increasing the event length basically steals time from flash access, which is the real bottleneck when we approach higher speeds. It might however help on crippled implementations running as low as 1.5kb/s.

    Connection interval is the obvious thing to tweak here because I reckon most Android phones will request a higher interval and the bootloader does not request it by itself. It just accepts whatever the peer requests. That would explain why some phones run faster than others against the same fw implementation.

    @janR, can you try to increase the data length as suggested here, but set the data length in ble_stack_init() in addition to setting the value in sdk_config.h? I was made aware that increasing the value in sdk_config.h alone doesn't configure the Softdevice with long lengths from the get-go.

  • Hi,

    I think this blog post might help clarify what is going on: Maximizing BLE Throughput on iOS and Android

    Your tablet probably has an outdated BLE stack and/or chipset which simply can't handle more than 4 packet per connection interval. With the PCA10040 and the Softdevice there isn't really a limit for how many packets you can send per CI, as long as you stay within the borders of each connection event.

    What is happening with your tablet is probably an attempt of power optimization. It starts off with a high interval to get the connection process and database discovery done as fast as possible, but afterwards it throttles the parameters back a little to a more power friendly setting. This is a pretty common procedure in a lot of devices (at least for Samsung devices I believe).

Reply
  • Hi,

    I think this blog post might help clarify what is going on: Maximizing BLE Throughput on iOS and Android

    Your tablet probably has an outdated BLE stack and/or chipset which simply can't handle more than 4 packet per connection interval. With the PCA10040 and the Softdevice there isn't really a limit for how many packets you can send per CI, as long as you stay within the borders of each connection event.

    What is happening with your tablet is probably an attempt of power optimization. It starts off with a high interval to get the connection process and database discovery done as fast as possible, but afterwards it throttles the parameters back a little to a more power friendly setting. This is a pretty common procedure in a lot of devices (at least for Samsung devices I believe).

Children
No Data
Related