51822 bluetooth


Using 51822 with BLE stack, I was faced with the problem of low transfer rates (5kb) on my android device (phone). It is very slow.

Can work 51822 with standart Bluetooth (not BLE)?

  • FormerMember
    0 FormerMember


    Unfortunately, the nRF51822 does only work with BLE. Your data transfer rate is a little low, which Android version do you have?

    By theory, with BLE, you can have maximum 6 packets per connection interval and minimum 7.5ms connection interval. This results the maximum throughput of (1000/7.5) * 6 * max_payload_size. Currently the nRF51822 supports max_payload_size = 20 bytes. (MTU = 23 byte, 1 byte opcode, 2 byte handle).

    So the maximum data throughput that the nRF51822 can achieve is in best case = (1000/7.5) * 6 * 20 = 16 kB/s.

    However, usually you will not be able to achieve this speed due to limitations on the host. On iOS and Android usually you will have maximum 4 packet per connection interval. On Android devices you can get as low as 7.5ms connection interval. On iOS device, you can get something around 20 ms connection interval.

    On the test here with a Samsung S4 running Android 4.2.2, we transferred 20kB in ~1850ms (~10.8 kB/s) from the nRF51822 to the phone.

    Throughput on the other direction should be very similar.

    How quick the host can support depends much on the available resources on the host stack, if it have to handle several slaves which also require high bandwidth, the throughput for each will be reduced (less packets per connection interval).

    Same apply for PC, not all PC BLE stack and driver support 6 packets per connection interval and 7.5ms connection interval.

    Also note that with Android 4.3 on S4, the minimum connection interval is 30 ms, leading to lower data rate.

    Regards, Kristin

  • Hi Kristin, I think your comment regarding the packet limit needs some clarification:

    On the PHY, the max data packet size is: payload 27bytes + the 4 byte MIC + 2 byte header + 1 byte preamble + 4 byte access address + 3 byte CRC, in total this is 41bytes = 328 bits, this takes 328us on the PHY. So if both the master and the slave sends these maximum size packets back and forth in the connection event, then the maximum number of packets (x) in each direction at maximum packet has to satisfy 2 * x * (328 + 152 (max. IFS)) < connection interval [us]

    Even at 7.5ms this is 7 packets, but there is no reason the LL can not send more packets than this if the connection interval is longer if I'm not mistaken.

  • note also, to get those rates you will need to set the MIN_CONN_INTERVAL and MAX_CONN_INTERVAL to something smaller than the defaults they use in the sample apps. I've used SECOND_1_25_MS_UNITS / 20 for example, to get a nice steady stream of events from my device to my phone. The defaults are set to 1/2 a second which makes for a very low bandwidth indeed.

  • It is true that there is theoretically time to transfer more packets, but the S110 supports maximum six packets per event, no matter how long the interval is. This has to do with RAM usage for the internal buffers.

  • Yes, connection parameters will significantly affect the throughput. Take a a look at this question for details on what connection parameters are: https://devzone.nordicsemi.com/index.php/what-is-connection-parameters

    PS: In the latest SDKs, there is a nice macro you can use instead of the SECOND_1_25_MS_UNITS define, to set the intervals like this if you want 7.5 ms: MSEC_TO_UNITS(7.5, UNIT_1_25_MS)